There is a frequent need for integration of Dynamics CRM system with other lines of business applications. In modern enterprises, systems residing in silos are generally candidates for an uplift or replacement, and any new system deployment generally takes integration into account.
Traditionally, when we integrate Dynamics CRM with other business applications; we use connectors like Scribe, SSIS along with KingswaySoft or CozyRoc, MuleSoft or even build-your-own-code based solutions.
With the increasing adoption of Microsoft Azure, we now have another great ESB option called Azure Service Bus as an Integration solution for Enterprises. Azure Service Bus hosted in Azure data centre provides a cloud-based ESB and allows an enterprise to take advantage of its Azure investments.
In a series of posts, I’ll try to discuss how we can integrate lines of business applications with Dynamics CRM using Azure Service Bus as an ESB. Within this series, I’ll take Dynamics CRM Online as an example; however, it works with Dynamics CRM On-premises as well.
Dynamics CRM and Azure Service Bus Integration
One of the most common integration scenario is to propagate a Dynamics CRM trigger to an external system; for example, send a notification to an external system when a Case record is resolved in Dynamics CRM.
The following diagram outlines the design pattern for such scenarios.
The sequence of the events as identified in the diagram is as follows:
- A New Service End Point is registered within Dynamics CRM Plugin to make the Plugin Azure Aware.
- A listener application is registered on Azure Service Bus endpoint, which begins actively listening for any event execution within Dynamics CRM Online.
- When a user performs an action (or the action is triggered by the system), Azure-aware Dynamics CRM plugin receives the trigger and can post the request data (as .NET binary/JSON/XML) to Azure Service Bus using the asynchronous service.
- The claims posted by Microsoft Dynamics CRM Online Plugin are authenticated. The Azure Service Bus then relays the remote execution context to the listener. The listener processes the contextual information and performs some business-related task with that information. The service bus notifies the asynchronous service of a successful post and sets the related system job to a completed status.
DO NOT WORRY! I shall slow down now.
Here are some short explanations for some of the terms.
Microsoft Azure Service Bus
Microsoft’s definition of Azure Service Bus is “a generic, cloud-based messaging system for connecting just about anything – applications, services and devices – wherever they are. Use this learning path to understand how to connect apps running on Azure, on premises or both.”
Browse to this link to learn more about Azure Service Bus.
Service Bus is a multi-tenant cloud service, which means that the service is shared by multiple users. Each user, such as an application developer, creates a namespace then defines the communication mechanisms he or she needs within that namespace.
Within a namespace, we can use one or more instances of four different communication mechanisms, each of which connects applications in a different way. The choices are:
- Provides one-directional communication
- Each message is received by a single recipient.
- Stores the sent messages until they are received
- Provides one-directional communication
- A Single topic can have multiple subscriptions
- Each subscription can optionally use a filter to receive only messages that match specific criteria.
- Provide bi-directional communication.
- Doesn’t store in-flight messages. Instead, it just passes them on to the destination application.
- Event Hubs
- Provide event and telemetry ingress to the cloud at a massive scale with low latency and high reliability
What else do I need to know about a Dynamics CRM and Azure Service Bus Integration?
- Service Bus Authentication: There are two authentication protocols for Azure Service Bus, namely:
- Shared Access Signature (SAS)
- Azure Active Directory Access Control Service (ACS)
For Dynamics CRM Integration, we use ACS.
- Service End Point: Service End Point represents the Azure Service Bus Endpoint. This is important to integrate Dynamics CRM with Azure Service Bus. We need to register a Service Endpoint in our CRM Organisation using Dynamics CRM Plugin Registration Tool. The beauty is when we register a new Service Endpoint in CRM, service identities, rule groups and a number of other settings are automatically configured for us.
- Out-of-the-box Azure-aware Plugin: To post CRM events to the Azure Service Bus, we have to register a CRM Plugin step within the registered Service Endpoint to define what message and entity data should trigger this plugin to execute. The Service Endpoint thereafter uses out-of-the-box Azure-aware Plugin to post the execution context to the Azure Service Bus.
- Custom Azure-aware Plugin: The OOTB Azure-aware plugin cannot process any data returned by the Azure Service Bus in case bi-directional relay service is used. In such a case, we need to develop a custom plugin and make sure our custom plugin can post to Azure Service Bus.
- Azure listener Solution: For the external LOB applications to act when a CRM event is fired, we need an active Azure Listener solution. The listener solution should be Dynamics CRM-aware so that it can process the CRM execution context (sent either as Binary data or JSON or XML) from the Azure Service Bus.
In the next post, we will see the step-by-step process for integrating a Dynamics CRM Online system to Azure Service Hub queue.