Anyway, this post is not about the job service’s use per se, but rather how to deal with it in development and staging environment. Frequently in those cases we have need to run multiple instances of the SalesLogix web client for different databases. But with the default configuration, all those instances will connect to the same job service – which only interacts with 1 database at a time! So for example you could be running a report in instance B, but instead it will return the records from instance A.
In order to work around this problem, 2 things need to be done:
- The job service needs to be deployed to a separate folder instead of the default “
C:ProgramDataSageSchedulingTenantsSlxJobService“. It has to be a subfolder of the Tenants folder though (
- The Infor CRM / SalesLogix client has to be told that it needs to communicate with this alternate “tenant” instead of the default SlxJobService. This is done by editing the
sage.platform.scheduling.tenantIdvariable inside of the appSettings.config file:
<add key="sage.platform.scheduling.tenantId" value="SlxJobService" />
That’s it! I have not had to restart the “Saleslogix Job Service” itself (it’s a Windows service) – it seems to pick up new deployments automatically.