Monday, June 20, 2016

CRM and Azure Service Bus Integration Part 1

I am writing a series of blog posts to look at different ways to integrate CRM and Service Bus. Most of the contents/code I will cover in this series is available on the MSDN site and in the CRM SDK. There is a lot of information on the internet regarding CRM and Service Bus integration but it is scattered everywhere. I am trying to create a beginners guide for the integration.

Prerequisite

You have to have knowledge of CRM Plugins and Workflow Assemblies to understand integration discussed in this blog. The blog will refer to IpluginExecutionContext, which will be posted to the Service Bus as a part of the integration. In short, the IpluginExecutionContext defines the contextual information passed to a plugin at runtime. It contains the information about the runtime environment that the plug-in is executing in, information related to the execution pipeline, and entity business information.

Common Integration Scenario

The most common scenario for this integration is to post the CRM data to Service Bus, to be used by the line of business (LOB) applications. The integration uses the data context available in Plugins and custom workflow assemblies, that will be posted to the Service Bus and Microsoft Azure Service Bus “CRM aware” solutions can listen and read the data from Service Bus and integrate with the other LOB applications.

How does it work

Dynamics CRM provides the functionality to create the service end points that connect CRM and Azure Service Bus. These service endpoints are the contracts between CRM and Service Bus that defines the handling and security of the messages. Registering a service endpoint in CRM is exactly like registering a new plugin assembly. Once the service endpoints are registered, you have to register the plugin ‘step’/steps in the event execution pipeline.
Once these steps are initiated (when a record is created or updated etc.) by the user, workflow or custom application, the service endpoint notification service notifies the Asynchronous service to post the data context to Service Bus, based on your registered step. Each post is performed by the system job of the Asynchronous service and the status of each job can be checked using the System Jobs view in CRM. If the listener or endpoint is not available then the message won’t be posted to the bus. The Asynchronous bus will keep trying to post these messages to Service Bus
The following diagram from Microsoft describes the physical elements of the integration

The sequence of events are as follows:
  1. A listener application is registered on a Microsoft Azure Service Bus solution endpoint and begins actively listening for the Microsoft Dynamics CRM remote execution context on Service Bus.
  2. A user performs some operation in Microsoft Dynamics CRM that triggers the execution of the registered OOB plug-in or a custom Azure-aware plug-in. The plug-in initiates a post, through an asynchronous service system job of the current request data context to  Service Bus.
  3. The claims posted by Microsoft Dynamics CRM are authenticated. Service Bus then relays the remote execution context to the listener. The listener processes the context information and performs some business-related tasks with that information. Service Bus notifies the asynchronous service of a successful post and sets the related system job to a completed status.

Contract Types

The service endpoints support the following types of contracts. Most of the definitions in this section come from Microsoft’s documentation.
  • Queue
    A queue contract provides a message queue in the cloud. With a queue contract, a listener doesn’t have to be actively listening for messages on the endpoint. For queues, there is a destructive read and a non-destructive read. A destructive read reads an available message from the queue and the message is removed. A non-destructive read doesn’t remove a message from the queue. It does not require an active listener.
  • One way
    Requires an active listener on the endpoint, otherwise the post to Service Bus fails.
  • Two way
    Similar to a one way listener except it can return a string to the plugin or workflow assembly.
  • REST
    Similar to two way listener but on REST endpoints.
  • Topic
    Similar to queue except one or more listener can subscribe to receive a message
  • Event Hub
    This contract applies to Azure’s Event Hub Solution

 

Security

Service Bus uses Shared Access Signature (SAS)  or Microsoft Azure Active Directory Control Service (ACS) for authentication and authorization.
The support for SAS authorisation is added in CRM Online 2016 Update 1 and CRM 2016 Service Pack 1 (on-premises), Before that, CRM only supported ACS for authentication and authorisation. For further information please check the following link
https://azure.microsoft.com/en-us/documentation/articles/service-bus-authentication-and-authorization/
It looks like SAS is the preferred method to work with Service Bus.
Use the SDK Plugin registration tool to configure Microsoft Azure Service Bus issuer, scope, and rules, which allow a listener application to read the Microsoft Dynamics CRM messages posted to the Microsoft Azure Service Bus.
For ACS configuration use the registration tool from SDK v8.1, and for SAS configuration SDK v8.1 or later.
For a CRM Service bus integration walkthrough for one way service contract, check my next blog CRM and Azure Service Bus Integration Part 2.

Note: I am no expert on CRM and Service Bus integration. I am learning myself. Please feel free to correct me if I am writing anything wrong.

No comments:

Post a Comment