Posts Tagged ‘Service Bus’

Writing a simple app to use Service Bus messaging

The Service Bus 1.0 for Windows Server is a really cool way to have a local instance of what Azure uses on the cloud for messaging. What’s cool about it? Well for one, you can write applications on your local box like you would for the cloud. So in other words, you can write applications that are cloud-ready and have them run on an on-premise environment too. For another, it is a great way to write loosely coupled applications based on messaging while leveraging the benefits of the underlying technology with transport reliability and availability.

I was enamored by the Service Bus enough to want to write a simple application to test its awesomeness but found guidance in several places, doing things in different ways in a somewhat disconnected fashion. So here’s my attempt at putting together a very basic application (or two) from scratch and doing the minimum work required to get messaging working. This test will use the Brokered Messaging capability of the Service Bus.

NOTE: All of the following was done on a single server installation of Service Bus 1.0.

Firstly, I wanted to create a new namespace that custom applications that I build to work with Service Bus can use called MyAppNamespace. I did this from the Service Bus PowerShell console using the following command

New-SBNamespace -Name MyAppNamespace -ManageUsers spdev\administrator

The -ManageUsers parameter is used to specify one or more user accounts that will have the ability to managed this namespace.

Then I used the following command to get the endpoint information for this new namespace I just created. This will be useful when I need to set up the connection string using which my application will need to connect to Service Bus.

Get-SBClientConfiguration -Namespaces MyAppNamespace


Then I launched Visual Studio and created a new console application project called MessageGenerator. I added reference to the following:

  1. Microsoft.ServiceBus.dll – which can be found typically at C:\Program Files\Service Bus\1.0.
  2. System.Configuration – needed to read the configuration from App.config
  3. System.Runtime.Serialization – needed by the namespace manager


Next, I brought up the App.config file for my application and added the following to it to define the connection string that the application can use to connect to the Service Bus. The value of the connection string appSetting is the one that is returned when Get-SBClientConfiguration is run from the Service Bus PowerShell for the namespace. It is not all visible here but the entire string was copied.

And while I was at this, I added another appSetting for the path (or the name) of the queue that I am going to create through my application.


In the Main function of my program, I set up the following to read from configuration and prepare the relevant strings


Next, I set up the console to

  1. Create a namespace manager
  2. Create a queue at the specified path if one doesn’t exist
  3. Spin up a queue client that will be used to send messages at the specified queue path
  4. Prompt user for messages until they no longer want to send one
  5. Read each message input by the user, create a brokered message and send it

Some exception handling is included to catch anything that may fail.


And finally (no pun intended), some clean up code.


Now since I have an application that sends messages, I created another quick console application that receives them called MessageReceiver. It is set up in exactly the same way as the sender in terms of settings and configuration. A couple of differences are

  1. This application does not need the System.Runtime.Serialization reference we added above since it doesn’t use the namespace manager to create a queue.
  2. As already mentioned above, it doesn’t use the namespace manager. It assumes that a queue exists at the specified path.


The main receiver code is a little different as seen below. There is no namespace manager here. The code

  1. Creates a client
  2. Connects it to the queue
  3. Receives a message every second
  4. Writes it to the console

And this goes on until the application is terminated by the user.


And the finally block


And that’s about it. Compiled and ran the applications and here’s the output.


Well there you go. Nothing really fancy in there but a really simple publish-subscribe model in action. You’ll need to be a geek to appreciate how cool this is. And a Pink Floyd fan to see what I did there. Happy messaging!

Categories: Service Bus Tags: ,

Troubleshooting configuration problems with Workflow Manager and Service Bus

June 2, 2013 4 comments

This post covers some of the problems I have encountered during the configuration of the Service Bus for use by Workflow Manager which was being setup to be used by SharePoint 2013. For step by step guidance leading up to the steps described below, refer to Installing Workflow Manager 1.0 and Configuring Workflow Manager 1.0.


A failure occurs after the creation of the Service Bus and Workflow Manager farms is completed, as the host is being added to the service bus farm. The failure occurs with the following error message: None of the declared nodes is for the current machine. This is pictured in the screenshot below from running configuration through the UI but the same message is displayed even when using PowerShell in the console.



Every time this happened to me, I was able to work around it by checking the hosts file on the machine on which installation is being performed. If there are any loopback entries to a localhost IP in the hosts file, comment or remove them temporarily and retry configuration.


On occasion, the Service Bus Message Broker service gets stuck in a perpetual “Starting” state.


And eventually times out


Look in the event viewer and you should be able to see what may have failed. Not that it always helps you but it may. In this case, it looks like the Messaging Broker is waiting for the Fabric service.


And looking further up the list, it looked like the Fabric was having its own problems.


The fabric host service was running fine



Stopped and started this service and this had the effect of restarting the Service Bus Message Broker and it went into the running state. I have found from running service bus configuration on various different environments that the fixes for these issues are neither consistent nor predictable. I have had to try several things before I could make it work and the solution is not always the same. That said, in general stopping and starting the services seems to help when the Service Bus Message Broker is started last in sequence.

That’s fixed now but what is the status of the service bus host configuration? You can always figure this out by using the Get-SBFarm cmdlet. As you can see below, the host has been added but the configuration state is HostConfigurationStarted. It should read HostConfigurationCompleted if it was all done.


A look at the registry shows that everything seems to be configured alright except the host configuration value is set to Started.


So I tried removing the host from the farm to try and re-add it.


As you can see below, the host is gone


And the Service Bus services too.


Now to try and add the host again


And done. As you can see, the steps it did not get to complete the last time because the Service Bus services failed to start correctly were just to restart the SB farm and update the registry.


The farm information now looks as shown below


The registry doesn’t look very different except for the indication that the host configuration is Completed. Technically, it may have all worked after restoration of Service Bus services above unless there was something referencing the registry to check if the host was properly added. But it is always so much better to get it done cleanly.


For good measure, a couple of quick additional tests before we move on.


The above checks show that the services are up and running and the farm is connected to an active message container. In other words, it is ready to go.


Yet another problem that I have faced a couple of times is after configuration, on checking the status of the Workflow Manager farm, I found that certain services were responding with an HTTP 403 (Forbidden) error.



In my case, checking the connection settings on Internet Explorer revealed that a proxy was configured to be used on the errant machine. Upon removal of the proxy settings, the service endpoint came online and was shown in the Running state.

Please note that all of the above is based on what worked for me on my environment. Not a guarantee that it will solve similar issues in other environments but certainly worth checking if it applies. I may be adding updates to this article based on new information obtained on any of the problems stated here or new ones that I encounter.

%d bloggers like this: