So you are running into a blocking issue, try to find a solution and you gets back a reply like ‘Sorry, I cannot repro your problem’. You go back and try again, and sure the problem is still there. You dig deeper, go to the Advanced search options on Google, but still cannot find the answer. Desperately, you try again and, surprise, the problem has vanished. Sounds familiar?

I know of one such problem that appears again and again when discussing Service Broker, Database Mirroring and, to a lesser extent, SQL Server 2005 Cryptographic facilities. I want to show you what the problem is, what’s causing it and even drill a bit into how something so basic has slipped into the product.

Certificate Not Yet Valid

Lets do a very simple example of a Service Broker conversation that uses a certificate. First create a test database, then create a service that we will use for our test:

create master key
	encryption by password = 'Password#123';
go

create certificate test with subject = 'test';
go

backup certificate test to file = 'test.cer';
go

create queue testQueue;
create service testService
	on queue testQueue ([DEFAULT]);
create remote service binding testBinding
	to service 'testService' with user = [dbo];
go

This setup allows us to send a message on a conversation from service testService to service testService:

declare @h uniqueidentifier;
begin dialog conversation @h
	from service [testService]
	to service 'testService';
send on conversation @h;
go

And now check the sys.transmission_queue:

waitfor delay '00:00:05';
select transmission_status from sys.transmission_queue;
go

And you will see this message: The security certificate bound to database principal (Id: 1) is not yet valid. Either wait for the certificate to become valid or install a certificate that is currently valid. Or you won’t see anything. Wait! Is there an error or isn’t there one? Well.. it depends on where you live. And it also depends whether is summer or winter outside.

Universal Time

Any sort of communication between machines must rely on UTC, because machines can be distributed across the globe and have different local times. Using UTC timestamps solves this issue. This also applies to certificates. The fields Validity/Not Before and Validity/Not After must be expressed in UTC so that the certificate issued on one part of the globe is safely used on another part of the globe. As I write this post from Bucharest that is on the GMT+2 time zone and summer daylight saving time is in effect, my local time is 3 hours ahead of the UTC time. I can test this from SQL:

select getutcdate(), getdate()

I get back the values 2008-08-25 09:25:16 (my local time) and 2008-08-25 06:25:16 (UTC time). When I created the certificate I did not specify a the START_DATE nor the EXPIRY_DATE values, so the certificate was created using the creation moment as Validity/Not Before and creation moment + 1 year as Validity/Not After, which are the X.509 fields corresponding to START_DATE and EXPIRY_DATE. Is there some way to verify this? Yes, we can export the certificate and then open it in the system certificate viewer:

backup certificate test to file = 'test.cer';
go

The test.cer file was saved in the same location your master files are. Double-click this file and you get to see all the details of the certificate, and we can check the Valid from:

But you can see that the time displayed is … Monday, August 25, 2008 12:25:19 PM. That is not the 9:25 AM reported by GETDATE() neither the 6:25 AM reported by GETUTCDATE(). OK, so my computer local time is 3 hours ahead of UTC and the Certificate Viewer displays the times in local time, that means that the certificate has it’s UTC time stamp at 9:25. Isn’t this wrong? It sure is. And in fact that is a SQL Server 2005 bug. When creating a new certificate, it stamps the certificate valid and expiration dates with the local time values instead of the UTC time values. However, when it uses the certificate the time fields are used correctly, so the time value in the field is interpreted as a UTC time value. This is why the certificate I created at 9:25 AM is not valid until 12:25 PM the same day!. And this is because I did the test in Bucharest during summer. If I’d repeat the same test in Moscow in winter, the certificate would not be valid for 3 hours. In London during summer is not valid one hour. In Mumbai would be 5 hours and 30 minutes. As I said, the result depends on where you’re doing the test and also whether daylight saving time is in effect or not!

So why some of you did not see any problem? Because if you live on the Western Hemisphere and you are behind the UTC clock, then the certificate is valid immediately as you create it. In fact, is it stamped as being valid few hours in the past, depending on your time zone.

Redmond, WA, USA

So when you post your problem on the forums, somebody from the SQL team is looking at it, trying to repro, and doesn’t see any problem. Of course, they are located in Redmond so they don’t see the problem :). Or perhaps an MVP or a forum moderator is trying to help you. Again, if they are US based (and many are), they would not repro the issue, since their local time is safe from this problem.

Is this problem still in SQL Server 2005? I tested on build 9.00.3042 which is SP2, and the problem is present. How could Microsoft not be aware of this issue when they released the product? Very simple: the entire test infrastructure is running on Redmond time! In fact the problem was reported early by users: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=125262 but was closed as not repro. Of course, the person who tried to repro was based on Redmond, where the issue does not repro. Other people are still running into this issue today, look at this post on the MSDN forums, or here.

Workaround

How do you resolve the issue? Very simply, specify an explicit START_DATE when you create the certificate:

create certificate test
	with subject = 'test',
	start_date = '2008-08-24';

Why does the problem seem to sometimes magically fix itself when you try again later? Because after the number of hours that is the difference between your local time and the UTC time has passed, the certificate is valid.

And one last note: what start date is displayed in the certificate meta data view?

select * from sys.certificates

Yes indeed, that is 2008-08-25 09:25:19.000. Confusing? You bet. Correct? Not a chance…

I have previously talked here about the queue monitors and the role they play in launching activated procedures. If you recall, I’ve mentioned that the Queue Monitors will enter the NOTIFIED state after they launch a stored procedure and not launch again the procedure until the Queue Monitor notices that RECEIVE statements are being issued against the queue. In an older post I have also talked about how difficult is to get error handling right, and in particular cast and convention errors. This may seem a trivial problem but in the Service Broker programs it is actually a serious problem because of the frequent conversation to and from XML. These two separate issues can actually ‘cooperate’ into a somehow surprising behavior. Namely if the activated procedure hits an error before it completes the RECEIVE statement, the Queue Monitor will stay in NOTIFIED state and won’t activate again the procedure. Although this looks similar to the typical poison message behavior when the queue is automatically disabled, this is a different issue. And unlike the poison message case, in the case when the Queue Monitor is stranded in NOTIFIED state you can not get a notification that the queue is no longer functional.

This post continues with an example showing how a relatively safe activated procedure can end up in this situation.

Lets consider what happens when a typical Service Broker activated procedure is presented with an invalid XML fragment in a message. First, lets create a pair of services:

create queue [initiator];
create service [http://rusanu.com/2008/08/13/initiator] on queue [initiator];
go

create queue [target];
create service [http://rusanu.com/2008/08/13/target]
	on queue [target]
	([DEFAULT]);
go

Lets say the target service is used to log user logins from workstations. We have a table that keeps these login events:

create table [user_log] (
	[id] int not null identity (1,1) primary key,
	[user_name] varchar(256),
	[workstation] varchar(256),
	[login_time] datetime not null);
go

The initiator service is sending XML messages that embed the user, workstation and time for a login event:

<login_info xmlns="//rusanu.com/2008/08/13" time="2008-08-13T08:00:00">
  <user>John Doe</user>
  <workstation>PCLAB36X</workstation>
</login_info>

So we create an activated procedure that is extracting the name, workstation and time from the XML and inserts the information into the [user_log] table:

create procedure usp_target
as
begin
	set nocount on;
	declare @h uniqueidentifier;
	declare @mt sysname;
	declare @msg xml;

	begin try
		begin transaction

		waitfor (receive top(1)
			@h = [conversation_handle],
			@mt = [message_type_name],
			@msg = cast(message_body as xml)
			from [target]), timeout 1000;

		if (@h is not null)
		begin
			if (@mt = N'DEFAULT')
			begin
				with xmlnamespaces (DEFAULT '//rusanu.com/2008/08/13')
				insert into [user_log] (
					[user_name],
					[workstation],
					[login_time])
				select T.c.value('user[1]', 'varchar(256)'),
					T.c.value('workstation[1]', 'varchar(256)'),
					T.c.value('@time', 'datetime')
					from @msg.nodes('/login_info') T(c);
			end

			end conversation @h;
		end
		commit;
	end try
	begin catch
		declare @error int, @message varchar(4000), @xstate int;
		select @error = ERROR_NUMBER(), @message = ERROR_MESSAGE(), @xstate = XACT_STATE();
		if @xstate != 0
			rollback;

		----------------------------
		-- Error logging goes here
		----------------------------
		print @message;

	end catch
end
go

alter queue [target] with activation (
	status = on,
	procedure_name = [usp_target],
	execute as owner,
	max_queue_readers = 1);
go

So we go ahead and test the procedure, by sending a message that will activate the procedure:

declare @h uniqueidentifier;
declare @msg nvarchar(max);
select @msg = N'<?xml version="1.0" encoding="utf-8"?>
<login_info xmlns="//rusanu.com/2008/08/13" time="2008-08-13T08:00:00.000">
  <user>John Doe</user>
  <workstation>PCLAB36X</workstation>
</login_info>';
begin dialog conversation @h
	from service [http://rusanu.com/2008/08/13/initiator]
	to service N'http://rusanu.com/2008/08/13/target'
	with encryption = off;
send on conversation @h (@msg);
go

And when we check the [user_log] table, nothing is there. How come? Well, we did send an invalid XML message. Because we assigned the XML to an NVARCHAR variable, it is stored as Unicode encoding. But our XML fragment declares itself as UTF-8 encoding, hence it is invalid and casting it to XML datatype will fail. This sort of XML errors are less obvious and I’ve seen in real life situations encoding mixed up like this.

If we check the server ERRORLOG or the system Event Log (eventvwr.exe) we’ll find the error message from the XML convertion:

The activated proc [dbo].[usp_target] running on queue test.dbo.target output the following: ‘XML parsing: line 1, character 38, unable to switch the encoding’

This error happens during the RECEIVE statement. This interrupts the statement before the Queue Monitor is notified that RECEIVEs are occurring, and thus the activated procedure exists but the Queue Monitor is left in NOTIFIED state. We can check this in the DMV sys.dm_broker_queue_monitors. Although the queue is active, it refuses to activate again the procedure.

The workaround for this is failry easy: simply move the cast after the RECEIVE statement:

alter procedure usp_target
as
begin
	set nocount on;
	declare @h uniqueidentifier;
	declare @mt sysname;
	declare @msg xml;
	declare @msg_bin varbinary(max);

	begin try
		begin transaction

		waitfor (receive top(1)
			@h = [conversation_handle],
			@mt = [message_type_name],
			@msg_bin = [message_body]
			from [target]), timeout 1000;

		if (@h is not null)
		begin
			if (@mt = N'DEFAULT')
			begin
				select @msg = cast(@msg_bin as xml);
				with xmlnamespaces (DEFAULT '//rusanu.com/2008/08/13')
				insert into [user_log] (
					[user_name],
					[workstation],
					[login_time])
				select T.c.value('user[1]', 'varchar(256)'),
					T.c.value('workstation[1]', 'varchar(256)'),
					T.c.value('@time', 'datetime')
					from @msg.nodes('/login_info') T(c);
			end

			end conversation @h;
		end
		commit;
	end try
	begin catch
		declare @error int, @message varchar(4000), @xstate int;
		select @error = ERROR_NUMBER(), @message = ERROR_MESSAGE(), @xstate = XACT_STATE();
		if @xstate != 0
			rollback;

		----------------------------
		-- Error logging goes here
		----------------------------
		print @message;

	end catch
end
go

With this modified procedure the conversation error is causing the RECEIVE to rollback, but the Queue Monitor has already entered the RECEIVES_OCCURRING state and will activate the procedure again. Five consecutive rollbacks are triggering the poison message detection mechanism and the queue is disabled as expected. Why is this a better behavior than before? Because you can have monitoring set up around the BROKER_QUEUE_DISABLED event notification and intervene: remove the poison message and re-activate the queue.

XML message validation

In my example I intentionally used the DEFAULT message type, with no validation, and did not use a message type with well_formed_xml message validation. The later would had muted the whole point of the errors occurring during XML cast since and invalid message would not event be enqueued int the [target] queue. Indeed, using message type validation is the best option for such a case, but none the less, I have seen situations like the one I’ve described in production. It can happen when the developers intentionally omit the XML message type validation in the message type declaration to gain a bit of performance, or because they consider themselves safe from an invalid XML ever being sent.

Conclusion

Always make sure your RECEIVE statement is being executed in your activated procedure. If you are doing any cast, is better to receive into intermediate types that do not require a cast and only perform the cast after the RECEIVE statement has finished. Otherwise you may end up with your service not activating but your notification infrastructure never detecting this problem.

In case you miss it, the SQL Server Service Broker has recently started posting in an MSDN team blog: http://blogs.msdn.com/sql_service_broker. The team members have already made strides and covered some hot topics like shipping near real-time OLTP data to ETL, some advanced discussion of SSB routing, poison message handling, some juicy internals how-it-works details and also revisited that never exhausted topic of setting up your first remote dialog.

Marcin Policht has a series of articles on databasejournal.com covering Service Broker. So far the series has covered an introduction, a presentation of SSB objects and a conversation primer.

These series are part of a SQL Express cover done by Database Journal and they are to continue with more SSB goodies.

A major class of Service Broker applications have nothing to do with the distributed application capabilities SSB was designed for. Instead they leverage SSB’s capability to run a stored procedure outside the context of the user connection. This capability enables to schedule execution and don’t wait for it to finish, or to schedule multiple procedures to execute in paralel. Often the developers that use these capabilities don’t care for the reliable message delivery SSB offers and many see the complex infrastructure of message types, contracts and services as a mere hurdle. Nonetheless sooner or later they have to troubleshoot an issue and then is when many of you find my blog and my articles. Troubleshooting activated procedure is not difficult, but one simply has to know where to look and what to look for.

In this entry I want to shed some light in the soul that drives the activation process: the Queue Monitors.

A Queue Monitor is a state machine that resides in the SQL Server and decides when to launch a new instance of activated procedure into execution. The sys.dm_broker_queue_monitors DMV is used to view the Queue Monitors:

This DMV is described in BOL at http://msdn.microsoft.com/en-us/library/ms177628.aspx where the columns types and decriptions can be found.

There is a Queue Monitor for each queue with activation enabled in the SQL Server instance. The DMV does not contain the database name nor the queue name, but you can join with sys.service_queues on queue_id to get the queue names. Note that even when you run this query on a brand new install of SQL Server you will get two Queue Monitors: InternalMailQueue and ExternalMailQueue. These are the queues placed in msdb used by the Database Mail feature of SQL Server.

Queue Monitor States

To start troublesooting an activation problem you need to understand the Queue Monitor states:

• INACTIVE: there are no messages available to be received in the monitored queue.
• NOTIFIED: messages are available and the activated procedure was launched into execution.
• RECEIVES_OCCURING: the activated procedure is issuing RECEIVE command against the monitored queue.

The important thing to notice here is that the Queue Monitor will go into NOTIFIED state when an activated procedure was launched and will not launch again any procedure until a RECEIVE statement is issued against the monitored queue. This is done in order to prevent situations when a queue is incorrectly configured and launches the wrong stored procedure into execution. Altough in practice is the activated procedure that is expected to execute the RECEIVE statement, this is not enforced by the Queue Monitor. Any connection that executes a RECEIVE while the Queue Monitor is in NOTIFIED state will cause the Queue Monitor to enter the RECEIVES_OCCURING state.

This activation state machine also handles sending the QUEUE_ACTIVATION events for Event-Based Activation. The only difference that instead of launching a stored procedure into execution the Queue Monitor sends a message of type http://schemas.microsoft.com/SQL/Notifications/EventNotification to the notification subscriber. Again, same as with internal activation, once the notification is sent the Queue Monitor enters the NOTIFIED state and will not send more notifications messages until a RECEIVE statement is executed on the monitored queue.

The Queue Monitor will go back to INACTIVE state when there are no more messages ready to be received in the queue.

Queue Monitor Timers

The Queue Monitors are also responsible for handling the activation ramp up for handling a higher load by launching more instances of the activated procedure. Once the Queue Monitor enters the RECEIVES_OCCURING state (ie. a RECEIVE statement is issued) it will start an internal timer. Each time a RECEIVE statement on the monitored queue returns an empty rowset this timer is reset. If this timer ever reaches a threshold then a new instance of the activated procedure is launched. The reasoning behind this mechanism is that activated procedures are supposed to issue RECEIVE statements and process the received messages. If RECEIVE does not find any available messages and returns an empty rowset the activation timer is reset because it means that there are no messages available for receive, so there is no reason to launch a new instance of the procedure. The timer threshold is 5 seconds and currently is hardcoded.

This timers are also used for sending new QUEUE_ACTIVATION event messages if the Event-Based Activation is used instead of internal activation.

Troubleshooting

If you find yourself looking at Queue Monitors in sys.dm_broker_queue_monitors is usualy because of one reason: your activated procedure is failing to launch.

If there is no record for your queue in sys.dm_broker_queue_monitors then this indicates that the Service Broker activation is not even monitoring the queue. For activation to monitor the queue several settings have to be properly configured:

• The queue has to be enabled. Check is_receive_enabled and is enqueue_enabled in sys.service_queues.
• Activation has to be enabled on the queue. Check is_activation_enabled in sys.service_queues.
• Activation has to be properly configured. Check activation_procedure, max_queue_readers and execute_ss_principal_id in sys.service_queues.
• The Service Broker in the database has to be enabled. Check is_broker_enabled in sys.databases.

If there is a record for your queue in sys.dm_broker_queue_monitors and its state is INACTIVE then there are no messages in the queue ready to be received. Check the content of the queue with a SELECT * FROM [<your_queue_name>]. Messages ready to be received have to be unlocked and the status has to be 1 ready. Note that the BOL documentation of RECEIVE erroneously shows the state 0 as ready, which is incorrect.

If the Queue Monitor for your queue is in NOTIFIED and it stays in that state is an indication that your activated procedure is not issuing the correct RECEIVE statement. Check your activated procedure. Note that if you change the procedure the Queue Monitor will not detect this change and launch again the procedure. The easiest thing to do is to recycle the Queue Monitor by disabling and then enabling activation on the queue:


ALTER QUEUE [<your_queue>] WITH ACTIVATION (STATUS = OFF);

ALTER QUEUE [<your_queue>] WITH ACTIVATION (STATUS = ON);

Finally if the Queue Monitor for your queue is in the state RECEIVES_OCCURING then it indicates that the RECEIVE statement is being issued against the queue. Make sure your assesment that the procedure is not being launched is correct. Check if there are other applications or procedures that are erroneously receiving from your queue.

Demo Caution

I will end with a cautionary tale. I was at a presentation where the speaker was showing a very nice monitoring facility he had built around the event notifications for DDL that he was using to monitor a farm of SQL Server instances. As he was making his way through the demo, he showed how it attaches a stored procedure to the queue to monitor for the notification messages. But in order to not perturb the presentation flow (at moment focused on setting up activation) he did not create the whole procedure, just a stub for it. Something like this:

CREATE PROCEDURE usp_NotificationProcessor

AS
BEGIN
–TODO: add code here

END;


The speaker then continued with his demo and attached the procedure to the queue for activation. Now since he had already created the subscription for all DDL events on the demo database, his queue was receiving the notification messaged as he was creating and altering objects in the database.

He finaly reaches the point when he changes the stub procedure to actually process the notifications and then the audience eagerly awaits the results. And nothing happens.

Can you guess what was wrong? Go back and read this for a hint.

Since activation was enabled and there were messages to received, the Queue Monitor has launched the procedure altough it was nothing but a stub. The Queue Monitor has entered the NOTIFIED state and would not launch again the procedure until a RECEIVE was issued. Later when the stub procedure was changed to do the actual processing, the procedure would not be launched by the Queue Monitor because it would still wait for RECEIVE. This can be easily fixed by turning activation on the queue off and back on, as I showed before.

Those who played with the original Terrarium project back in .Net 1.1 now have a chance to revisit this fun project. The Terrarium2 for .Net 2.0 was released on codeplex, including the project sources.
If you never had a chance to see the Terrarium, check it out. Terrarium allows you to create creatures with behavior you program in .Net and set them up into a virtual peer-to-peer world of Terrarium instances. You can track your creature in the wild, how does it do against other creatures. A nice incentive to learn some basic AI stuff and keep your programming skills sharp in a fun virtual fight-to-the-death competition with other programmers.
Read more on the Windows SDK team blog

On my last post I’ve said that the Toad tools from Quest lack the option to configure Dialog Security for Service Broker. I stand corrected, as they actualy do. Not only that, but they support both full security and anonymous security, and the configuration is also done through a wizard. The Dialog Security Configuration Wizard is launched from the context menu of a service.

The wizard is explicit for security and does not combine security and routing, like the Service Listing Manager does. So to fully configure a pair of services you have to run the Service Broker Application Wizard first and then to follow up with the Dialog Security Configuration Wizard.

The Dialog Security Wizard will guide you through the steps of creating the certificates, set up a database master key, create the users needed, exchange the certificates and set up the remote service binding.

My one comment on this Wizard is that it somehow contradicts the Broker Aplication Wizard. The Service Broker Application Wizard automatically grants SEND permission to [public] on the target service. In practice this allows any sender to send message to this service. Even if later the Dialog Security Wizard is run, the [public] role is still allowed to SEND on the target service. This is irelevant from a functional point of view, the two services configured through the Wizard will work as expected, but from a security/surface area point of view the service is exposed to a potential attack.

Technically Service Broker can offer a huge value over any other comparable technology, but every project faces in the early stages the same barrier: the extremely steep learning curve faced by developers and dba in order deploy a Service Broker solution. As the adopters try to set up a simple scenario to ‘play’ with the technology before making a decision they are facing an apparently insurmountable challenge: set up the configuration for that very first message to get through. Not only services, queue, contracts and message types have to be correctly configured, but also the transport security (endpoints and certificates, logins and endpoint connect permissions), service routing and last but not least service security (remote service bindings, again certificates, users without login and service send permission). These are all new concepts, not trivial ones, and they all have to be correct. And I haven’t even mentioned database master keys! So one is faced with the task of configuring more than ten new object types, never encountered before, just to test his first message. No wonder some feel frustrated and may abandon the technology before even seeing what is capable of.

Tools are the biggest missing piece of this puzzle. A wizard that would walk the new developer or dba through the maze of new concepts and objects to help him get that very first test scenario to work would be tremendous help. Unfortunately the set of tools that ship with SQL Server is in dire need of such wonder. For years my recommendation was to give a try to the Service Listing Manager tool. This tool, specially the command line version, takes all the headake out and can do all the work for you, configuring everything needed for two services to be able to exchange messages. But this tool is not an officially supported Microsoft release, and therefore many organizations cannot afford to use it in their environment.

Recently I have learned that 3rd party vendors stepped up to the challenge and have come up with a set of tools designed for Service Broker. Quest Software’s Toad is a well known toolset, and on Oracle environment is the toolset, the one everybody uses. And now it contains the Service Broker Manager, a set of tools that covers everything related to Service Broker in SQL Server 2005. Organizations that are looking for a set of tools for Service Broker deployment, maintenance and administration have now a commercially supported alternative.

The Service Broker Manager tools for Toad are available on all versions (Professional, Xpert and Dev suite), according to this comparison chart. After you connect to a SQL Server instance from the Connection Manager you get the option to launch the Service Broker Manager in the tools menu:

The Service Broker Manager has a typical Object Explorer style tool, with a hierarchical tree view of all databases that are enabled for Service Broker and all broker related objects in each database.

One thing I like about the Toad model of the Object Explorer is that it has a brief description for each object type definition. If you are new to Service Broker and have never encountered before a Queue, you can click the Description tab and read the definition of a Queue, similar to what you would find in Books On Line on the same subject. The description tab also contains quick action links for the context of the object type, like a ‘Create Queue’ link. While the quick link action idea is nice, I find a bit confusing its placement on the ‘Definition’ tab.

As expected the context menu of each object in this tree view has options to view properties, create, modify and drop each object type. Interestingly the hierarchy of objects includes all the expected Service Broker types like services, queue and contract, but also object that are not ‘owned’ by Service Broker, but are indeed heavily used by it, like certificates and XML Schemas. I found this very interesting, that Quest has considered putting the object where they are used and needed as opposed to where they ‘officially’ belong in the Microsoft blessed taxonomy of objects in the database. For instance the SQL Server Management Studio shows the Certificates in the ‘Security’ node because they are a Security feature and the XML Schemas in the Programmability/Types/XML Schema Collections node, because they are an XML data type feature. Just like supermarkets place tomato sauce right next to pasta on the shelves, Quest has placed the objects where they are needed, not in the parent node of the team that owns the feature. Of course there are other tools in Toad like the Database Browser tool that are showing the Certificates where they ‘properly’ belong in the Security tab, since Certificates truly are a ‘Security’ feature and are used in code signing, encryption and other strictly security related roles.

The Service Broker Manager has functionalities that cover all the broker needs, including configuring endpoints, enabling and disabling broker in the database and even setting the trustworthy bit on or off on the database:

Another nice feature of the Service Broker Manager is the fact that it shows conversation endpoints, messages in queues, messages for each conversation and, last but not least, the database transmission queue. The current SQL Server Management Studio for SQL Server 2005 doesn’t have anything similar. The SQL Server 2008 SSMS has the Broker Statistics Report that also shows the conversations and messages as well as the transmission queue. But the Toad one goes not one, but two steps further. For one it allows you to actually Edit conversations:

The only ‘editable’ properties on a conversation are it’s conversation group and its timer. I reckon I was very surprised to see these two properties as editable. I was so used to see them as T-SQL statements (MOVE CONVERSATION and BEGIN CONVERSATION TIMER) that I have never thought about them as means to ‘edit’ a conversation property. Is true that they may appear so for an administrator looking at a conversation, but they serve clear application programming roles related to correlated messages locking (the MOVE CONVERSATION) or to retry mechanisms and time outs (the BEGIN CONVERSATION TIMER).

And the second ‘further step’ Toad offers in regard to conversations is that it actually has options to begin and end conversations and even send a message:

Now all these would make a nice tool for administering Service Broker, with some richer functionality that SSMS offers. But the I saved the best features for last.

The Wizards

What makes the Toad SSB tool really useful are its wizards:

• Transport Security Configuration Wizard
• Service Broker Application Wizard
• Server Event Notification Application Wizard
• Database Event Notification Application Wizard

The Transport Security Configuration Wizard will configure endpoints and transport security between two SQL Server instances, including the exchange of certificates in case of certificate based security. It allows the user to select the desired authentication mode (certificates and/or Windows) and it will take the user step by step through all the necessary settings involved, if needed, including configuring the database master key password, certificate creation etc. The Transport Security Configuration Wizard has to be run only once between any two SQL Server instances.

The Service Broker Application Wizard will take you step by step to setup a complete SSB application between two services. It allows you to create or choose an existing service for initiator and target, create or choose an existing contract and it will configure routing and security between the two services. If it detects that the two services are located on separate SQL Server instances it will launch the Transport Security Configuration Wizard if needed in order to configure the transport security separately. Not only that, but if you create a new queue it will also create a stored procedure for activation, based on a template with a message RECEIVE loop that handles the system Error and EndDialog message types and has a placeholder where you have to put the logic to handle your own contract messages.

The two Event Notification Wizards are for configuring a service queue  that can handle an event notification. The Wizard will let you choose the event notification scope and type, create an event notification subscription and can even automatically create the service and queue for you, with names derived from the subscription name.

Odds and Ends

I consider the Toad Service Broker Manager a much better alternative than SSMS for Service Broker. This should come as no surprise, after all the SSMS tools come for free with a SQL Server purchase and Quest has to make better tools if is to stay in business. I reckon though I was pleasantly surprised by the depth of coverage Toad’s has to offer for SSB. The Wizards are awesome and exactly what you need to get yourself started on SSB.

But there are some odds and ends, some rough edges in the Service Broker Manager too. Some examples would be that the Service Broker Application Wizard forces you to choose a stored procedure for activation, omitting cases like an external application that might read the queue. Also the Service Broker Application wizard only lets you configure public security between services and cannot configure secure conversations. How ironic that the Service Listing Manager only lets you configure secure conversations and cannot deal with public security :) [Correction 5/22: there is a separate Dialog Security Wizard that allows you to configure both anonymous and full security]

There are also some problems I encountered and had to work my way around. For instance the Transport Security Wizard uses the computer administrative share (MACHINE\Admin$) to exchange certificates, which requires the SQL Server instance to be able to access this share. Most times certificates are deployed exactly because the two machines cannot authenticate using Windows, so access to the administrative share is unlikely.

I must also add that this post is not an endorsement of any sort nor payed advertising. I simply heard about the tools and downloaded the trial version to test them, just like any of you can, but I am very pleased with what I see and I had to share with my readers.

I have uploaded here the slides I presented today at SQLPASS on Service Broker Administration, Monitoring and Troubleshooting:
SQLPASS 2008 Slides

I’m about to embark on my flight to Germany for this year PASS conference. My 2008 session is Service Broker Administration, Monitoring and Troubleshooting and is scheduled on Tuesday April 15 at 10:45, see
http://www.european-pass-conference.com/agenda.aspx

If you are at this years European PASS Conference stop by and say Hello!