With the recent rollout of CRM Online Spring Release, we can see a few new enhancements added to the Azure Service Bus integration which include SAS key authentication, JSON and XML message body content types and support for event hubs. Most of you who have designed enterprise solutions involving Dynamics CRM Online will know that Azure almost always plays a part in the solution architecture when integration is required between various other cloud and on-premise applications. The addition of JSON and XML message body types allows for cross-platform interoperability where non .NET clients can read data from the service bus.

Today I am going to cover the registration of a service bus endpoint via the updated plugin tool and I am going to create a small console application which can read a JSON message from the queue.

Firstly, you will need to download the latest CRM 8.1 SDK from https://www.microsoft.com/en-us/download/details.aspx?id=50032 as this contains the latest version of the plugin registration tool.

To start, I am going to create a new Azure service bus namespace. In the past you had to do this via PowerShell to ensure the creation of an ACS namespace (Access Control Service) but now with the enhanced SAS namespace (Shared Access Signatures) support you can do this via the Azure Portal.

New service bus namespace:

Once your namespace is created you will then need to create a new service bus messaging entity. For the sake of this post I am going to create a new Queue and hope to cover Topic and Event Hub entities in a future post.

Now that we have a new Queue, we will need to configure some of the shared access policies on the Queue. We do this by selecting the queue and clicking configure at the top of the page. You will need to add a new shared access policy with a minimum permission of Send. If you are configuring a two-way relay, then you will need Send and Listen.

For now, we are done with creating and configuring the service bus namespace and queue. Already you can see how much simpler it was with SAS than with ACS where one needed to configure the service identity, rule groups and rules and the scope.

Next we going to register a service endpoint in Dynamics CRM which will be responsible for pushing messages to the Azure Service Bus Queue. If you open the Plugin Registration Tool from the 8.1 SDK and connect your CRM tenant, click Register and then Register New Service Endpoint.

You will now need the SAS connection string from your service bus namespace. This is available when clicking on the namespace you created and then clicking on Connection Information at the bottom of the page.

Once you paste this connection string into the plugin registration tool connection string textbox and click Next, the Reg Tool will automatically populate the connection details.

At this point you can change the Name to be more suitable to your purpose and we also want to change the Message format to JSON and click Save. You will notice that in the past we only had .NETBinary available to us and now the options for JSON and XML are included which are part of the spring release enhancements.
Now register a new step on the Service Endpoint. I have created a step to execute on Create on a Contact.

Now to test the newly configured Service Endpoint is correctly talking to the Azure Service Bus Queue, I am going to create a new contact and then monitor the Queue in Azure. As seen below, when I do just that, my message is received by the Queue and we can confirm that our SAS policy is correctly configured along with the Service Endpoint registration.

Now once the message has been posted to the Queue from Dynamics CRM, in a real world scenario you would have your integrating technology, be it BizTalk, an Azure Worker Role, or an application sitting somewhere, read this message and follow and an appropriate course of action.
To demonstrate this simply, I am going to create a .NET console application which will execute as the message is received in the Queue and read the JSON contents of the message body.
In the code I have shown two ways of reading the message. One is to read the message into RemoteExecutionContext object which could then be serialized into a strongly typed CRM entity. The other way is to simply read the Json string from the message through a stream reader. The latter method is most likely used in scenario’s whereby the listener is loosely coupled from Dynamics CRM and has no reference to the SDK libraries.

Please follow and like us:

Leave a Reply

Your email address will not be published. Required fields are marked *