Dynamics CRM Integration with Azure Service Bus–Part 1

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

Microsoft Azure

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.

image

Cloud Computing Layers accessible within a stack (image from Wikipedia)

Microsoft mentions about Azure as follows:

“Azure supports the broadest selection of operating systems, programming languages, frameworks, tools, databases and devices. Run Linux containers with Docker integration; build apps with JavaScript, Python, .NET, PHP, Java and Node.js; build back-ends for iOS, Android and Windows devices. Azure cloud service supports the same technologies millions of developers and IT professionals already rely on and trust.”

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.

image

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.

Queues

  • provide one-directional communication
  • each message is received by a single recipient
  • store sent messages until they are received

Topics

  • 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

Relays

  • provide bi-directional communication
  • do not store in-flight messages,
  • It just pass them to the destination application

Event Hubs

  • 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.

Service Endpoint

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.

Advertisements
Posted in Dynamics CRM, Dynamics CRM - Customization and Configuration, Dynamics CRM - Development, Microsoft Azure, Microsoft Azure - Srevice Bus
2 comments on “Dynamics CRM Integration with Azure Service Bus–Part 1
  1. […] the first part of this series we discussed briefly about Microsoft Azure, Azure Service Bus and elements of […]

  2. Khadim Ali says:

    Azure Access Control Service (ACS) has been deprecated by Microsoft Azure team. Any existing Dynamics 365 service bus that has been configured with ACS authentication will be impacted when ACS goes out of support.

    For information on how to update the endpoint configuration and other details please see:
    https://blogs.msdn.microsoft.com/crm/2017/05/24/update-service-bus-endpoints-to-use-sas-authentication/

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: