Last month, one of my friend called me and asked me if I can help him integrating Dynamics CRM with an on-premises line of business (LOB) application using Azure Service Bus. He was a SharePoint expert, with reasonable experience of Dynamics CRM and Azure Service Bus also and he had to develop a POC for his client to win a project. By then I didn’t have any experience with Microsoft Azure. So, I looked it as an opportunity for me to learn something new, the Microsoft Azure Service Bus. I spent few days studying and watching concepts and demos regarding Microsoft Azure, Azure Service Bus and Dynamics CRM-Azure integration. Eventually, we both started working on the project. The project had few other challenges too, but mainly I learned enough about Azure Service Bus and Dynamics CRM integration while working on this project. In this two part series of blog post I would like to explain fundamentals of Dynamics CRM integration with Azure Service Bus.
In the first part, we will learn about:
- Microsoft Azure (short introduction)
- Microsoft Azure Service Bus (fundamentals)
- Elements of Dynamics CRM-Azure integration
Is it Windows Azure or Microsoft Azure? The word “Windows” or “Microsoft” before Azure should not confuse us as both are not a different product. In fact, in March 2014 Microsoft rebranded what was formerly called “Windows Azure” to “Microsoft Azure” as Azure was not all about Windows only.
Microsoft Azure is a cloud computing platform and infrastructure created by Microsoft that provides both PaaS and IaaS services. That means you can build, deploy and manage applications and services and you can also create virtual machines of which you have complete control. All these on Microsoft-managed datacenters just using your cloud clients.
Cloud Computing Layers accessible within a stack (image from Wikipedia)
Microsoft mentions about Azure as follows:
You can see in the image below – taken from my trial Azure portal – that for example, an Azure user can create VMs for not only Windows Server, but also for Red Hat, Ubuntu Server and many others.
The apps and services shown in the left navigation bar are few of the Azure offerings. You can see the complete list of these by clicking browse. Visit Wikipedia to see the complete list and short description of some of the prominent services.
Microsoft Azure Service Bus
You have probably heard about “bus” concept in computer hardware. In computer architecture, a bus refers to a communication system used to transfer data between components inside a computer, or between computers. Similarly, a software bus is a software architecture model that enables communication between software modules. A software bus is conceptually similar to the term “bus” used in computer hardware. It is also referred as an ESB (Enterprise Service Bus) product.
Microsoft Azure Service Bus is Microsoft’s ESB product that facilitates messaging between decoupled systems. As Microsoft mentioned:
“(Azure Service Bus) Runs anywhere and connects nearly anything.
Azure Service Bus is a generic, cloud-based messaging system for connecting just about anything—applications, services, and devices—wherever they are. Connect apps running on Azure, on-premises systems, or both. You can even use Service Bus to connect household appliances, sensors, and other devices like tablets or phones to a central application or to each other.”
Azure service bus supports four different communication mechanisms. Each mechanism connects applications differently.
- provide one-directional communication
- each message is received by a single recipient
- store sent messages until they are received
- provide one-directional communication using subscriptions
- a single topic can have multiple subscriptions (a Pub/Sub model)
- each subscription can use a filter to receive only messages that match specific criteria
- provide bi-directional communication
- do not store in-flight messages,
- It just pass them to the destination application
- provide event and telemetry ingress to the cloud at massive scale, with low latency and high reliability
Creating a Service Bus Namespace
To begin using Service Bus, you have to create a service bus namespace. Then you can create named queues, topics, relays and event hubs inside a namespace. Applications want to connect to the service bus need to provide these information as an address for using service bus resources.
Service Bus Authentication
There are two ways for the applications to authenticate to Azure Service Bus. “Shared Access Signature (SAS)” authentication, or “Azure Active Directory Access Control Service (ACS)”. The SAS is now the default authentication.
When you used to create a service bus namespace, for example democrm.servicebus.windows.net, a companion ACS namespace was provisioned by default at democrm-sb.accesscontrol.windows.net. This was changed by August 2014. Now when you create a service bus namespace a SharedAccessAuthorizationRule with KeyName set to RootManageSharedAccessKey is created by default. How this change affected Dynamics CRM integration part, is discussed ahead.
Elements of Dynamics CRM-Azure Integration
Before we go to discuss and create a sample integration between Microsoft Azure Service Bus and Dynamics CRM it is worthwhile to go through how this integration works. This will help understanding the sample scenario.
To integrate Dynamics CRM with Azure service bus we need to register a service endpoint in CRM organization using plugin registration tool. Service endpoint represents a Microsoft Azure platform endpoint. When we register a service endpoint Dynamics CRM configures service identities, rule groups and number of other settings for us in Microsoft Azure that otherwise we would have to configure manually through our service bus’s ACS Management Portal.
Out-of-the-box Azure-aware Plugin
After registering a Service Endpoint, we need to register a plugin step inside the registered service endpoint to define what message and entity combination should trigger the plugin to execute. The service endpoint will then use the internal, out-of-the-box, Azure-aware plugin (ServiceBusPlugin) to post the execution context to the Azure Service Bus. Then the Azure listener solution will take charge of the execution context from the Azure Service Bus.
Custom Azure-aware Plugin
The OOB plugin can post execution context to the Azure but it can’t use any string data returned from the Azure Service Bus (where bi-directional relay service is used). If you need string data back from the listener you need to write your own custom plugin that is “Azure aware” instead of registering a step inside a Service Endpoint. Writing a custom plugin is just similar to writing an ordinary Dynamics CRM plugin except that the plugin must include code to initiate posting the execution context to the Azure service bus.
Whether you use OOB plugin or custom Azure-aware plugin, you have to register a Service Endpoint mentioned earlier because a custom Azure-aware plugin code will still use the Service Endpoint, configured with Azure Service Bus, to post the execution context to the Azure.
Azure listener solution
For the CRM-Azure integration there must be at least one listener solution in a Microsoft Azure Service Bus. For a relay endpoint contract, a listener application must be actively listening on the Service Bus endpoint for the CRM request. For a queue endpoint contract, a listener application doesn’t have to be actively listening.
A listener solution should be CRM-aware so that it can listen and read the CRM execution context from the service bus. We can made a listener “CRM-Aware” by adding Microsoft.Xrm.Sdk assembly so that we can define RemoteExecutionContext type.