In SQL 2008, is there a way to specify a service_broker_guid instead of simply taking whatever GUID is given to you by:
ALTER DATABASE MyDB SET NEW_BROKER
Our current (broken, in my opinion) release methodology is to restore two databases which have a codependent relationship. One is a “source” database, and one is a star-schema BI database. Part of the regression test plan is to restore backups of both databases in a “gold” state across different servers and even on the same server.
We generally do not include BROKER_INSTANCE variables on our routes because most places, we do not need them (i.e. the combination of SERVICE_NAME and ADDRESS is enough to guarantee delivery). However, when we have 2 databases running on the same instance both with broker enabled, one of these will need a new BROKER_ID. In addition, all routes to these databases will now require a BROKER_INSTANCE qualifier, since there are 2 SERVICE_NAME’s on the same ADDRESS.
We use Visual Studio Database Professional to generate our build output scripts, and there’s simply no simple way to include a BROKER_INSTANCE as part of it’s SQLCMD variable replacement technique, unless you know it before hand.
No. NEW_BROKER would generate a new guid.
There is no way to use a specific guid and that is very much intentional. If you explain what is the underlying problem that is making you ask this question, perhaps we can work toward a solution to that problem.
After your edit.
The broker_instance, as well as routing information, is considered runtime, deployment specific information. As such, it was not designed to accept fixed, predetermined values, which is what a VS GDR project or a set of SQLCMD scripts would like to use. Besides, the broker_instance_id is really meant to be a unique, database instance specific value, and allowing users to specify their own would quickly result in duplicates, which would confuse the heck out of conversation endpoints trying to exchange messages.
The problem you’re facing though is a legitimate one. How to automate deployment of routing information (and it’s associate problems of automating the deployment and exchange of certificates, configuring users w/o login and granting appropiate permissions, configuration of remote service bindings and service broker transport endpoints). There simply is no Wizard to do this. Quest has a set of tools that handle this actually.
Once upon a time I made a tool, called ssbslm.exe, that automated this entire process and was designed to be usable from scripts. This tool did everything to set up the routes, certificates and endpoints between two arbitrary services. While this tool is no longer available (long and boring story why that is the case), the gist of this story is that is not that hard to write one. Took me few days back in the day.