Back To Basics: Service Broker Routes

Routes are only needed when sending service broker messages from one server to another.  They define the SQL Server and TCP Port which the sending SQL Server will connect to in order to deliver the message.  If you are sending the message to a mirrored database, then you can specify the mirror as well as the primary database.

If you needed to you could setup three or more servers in a chain and have them forward the messages from one server to another.  This would be handy if you needed to get messages through firewalls and the source and destination servers were not permitted to talk to each other.  The only requirement to do this is that one server in each conversation must be a paid for edition of SQL Server.  In other words two SQL Express instances can not send messages to each other directly.  Those messages much be forwarded through a Workgroup, Standard, or Enterprise instance.

Before you can create a Service Broker Route, you have to have an endpoint on the remote machine.  For this purpose we’ll assume that the Service Broker endpoint was created on port 1234.  Our local server is SQL1 and the remote machine will be SQL2.  The only other piece of information that you need to know is the Service Broker Instance GUID from SQL2.  This is found in the service_broker_guid column of the sys.databases DMV on server2 (fifth column from the right in SQL 2005).  If the GUID is all 0s then you need to enable the service broker by using the ALTER DATABASE Command.

The CREATE ROUTE syntax is very easy.

CREATE ROUTE RouteName
WITH SERVICE_NAME = 'ServiceName',
BROKER_INSTANCE = 'ae8505fa-b84d-4503-b91f-3252825ccf09', /*Use your GUID here*/
ADDRESS='TCP://SQL2:1234'

If your target is using database mirroring set the MIRROR_ADDRESS to the name and port number of the mirror.  This way in the event of a fail over the sending server can continue to deliver messages.

If you need the route to expire on a specific date, for example you are sending data to a partner and you want to automatically stop sending them the messages when the contract ends, add the LIFETIME parameter with the number of seconds until the route expires.  If the LIFETIME is omitted the route will never expire.

Denny

Share

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trust DCAC with your data

Your data systems may be treading water today, but are they prepared for the next phase of your business growth?