How to solve the following:
We have 4 seperate OTAP environments with each their own (identical in case of structure) SQL database.
ServiceControl manager is setup on a different machine.
When I configured to run SenviceControl on the O (of OTAP) It generates tables and uses the error and audit queues as entry for the endpoints.
Those error and audit table (queues) exist on every environment.
Now I created the ServiceControl for the O environment, I want to create the ServiceCOntrol Instance for the T (and A and P) the same way. Only difference: Database connection string.
Here is the problem, I cannot create an ServiceControl Instance next to the O with the same name because the Windows Service Name and SQL tablenames are identical and I am not allowed to have multiple Windows Services (which is also generated by the ServiceControl creation) with the same name.
Am I right in saying that you want to have 4 instances of ServiceControl running on 4 separate machines (one for each in OTAP), but you also want each of those 4 instances to have the same name?
Or do you want each of those 4 instances running on the same machine, but consuming messages from different queues?
If it’s the latter and you want all 4 instances running on one machine, wouldn’t it be better to have a different name for each instance so that you can tell which environment it is for?
It is possible to create an instance with a different name, but have it consume messages from a queue of a different name using the InternalQueueName setting. This would allow you to create 4 instances named ServiceControl.Ontwikkeling but have it consume messages from the ServiceControl queue.
This also sounds like something that should be an environment variable, since it’s describing the environment that the instance is consuming messages from (but this requires each instance to be on a separate machine).
A word of caution though: Your P environment is at risk of being affected by everything else happening in your OTA environments. I strongly recommend against doing this and keeping your P (at least) separate.
Thank you William. I think the InternalQueueName could help me.
But how do I use it or how do I set it before I I am going to create a serviceinstance from the Service Control management tool.
Create a new instance of ServiceControl using SCMU (called ServiceControl.Ontwikkeling with a connection string pointing to your ontwikkeling environment)
Use SCMU to stop the instance from running
Add a new appsetting key <add key="ServiceControl/InternalQueueName" value="ServiceControl" /> to the servicecontrol.exe.config file
Open a command prompt and navigate to location of the ServiceControl.exe file
Run ServiceControl.exe --setup
Start ServiceControl again via the SCMU.
At this point, you will see in SCMU that you have an instance of ServiceControl called ServiceControl.Ontwikkeling connected to your ontwikkeling environment database, but consuming messages from a queue within that database called ServiceControl
You can repeat the process for the other environments too.
I have run the servicecontrol.exe --setup and of course stopped the service first.
But in the eventviewer I keep getting the error:
Microsoft.Data.SqlClient.SqlException (0x80131904): Invalid object name ‘OGRJ01OTKETENMESSAGEBUS.dbo.Particular.nServiceBus_O’.
So it keeps looking for the table with the name of the service.
The internalQueueName setting should overwrite this?
Any thoughts are welcome.
EDIT:
In the log directory there was a file Particular.nServiceBus_O-configuration.txt that has the following section:
I double checked it but it’s really an ServiceControl instance… I looked at the code (of github) of teh servicecontrol and can’t figure out why he is ignoring the setting.
The setting works when creting the queue’s, but not when the service control is running and it is going to consume the queue.
Perhaps that clarifies it a bit
I think it’s probably best to escalate to a support case then so that we can get on a call and look closer at what’s happening. Can you log a ticket through one of our support options here: Support options • Particular Software
Looks like we have a bug. The internal queue name is not applied all the way through the stack with SqlTransport.
Until we get that bug fixed, a workaround involves a tweak to the above steps:
Create a new instance of ServiceControl using SCMU (called ServiceControl.Ontwikkeling with a connection string pointing to your ontwikkeling environment)
Use SCMU to stop the instance from running
Add a new appsetting key to the servicecontrol.exe.config file
Open a command prompt and navigate to location of the ServiceControl.exe file
Run ServiceControl.exe --setup
Change the windows service to specify the parameter as a command line arg
Run (in an elevated cmd prompt): sc config Particular.nServiceBus_O binPath= "C:\Program Files (x86)\Particular Software\Particular.nServiceBus_O\ServiceControl.exe --serviceName=Particular.OTKeten"