Monday, June 20, 2016

CRM and Azure Service Bus Integration Part 2

This is the second part of the series. We have discussed the contract types, security and a general overview of CRM–Azure Service Bus integration in the previous blog. Please read part 1 for the context. In this blog we go through a step by step tutorial to setup a CRM-Azure Service Bus one way listener contract using ACS.

Prerequisite

A CRM Online instance

Microsoft Azure account

Microsoft Azure SDK

Visual Studio 2013/2015

CRM2016 SDK V8.0.1 or less ( We will be using the plugin registration tool and sample code from the SDK. The plugin registration tool does not have ACS options from SDK v8.1 onwards)

Here are the steps to create the integration.

Setting up a Service Bus Namespace

The first thing you need for the integration is a Service Bus namespace. If you already have an ACS namespace, you can skip this step.In the past you could login to the Azure portal and create an ACS namespace. But now, Azure portal does not allow the creation of ACS namespaces from the portal. It only creates a SAS namespace by default. We need to use PowerShell to create an ACS namespace.

Open “Windows PowerShell ISE”

Type Add-AzureAccount. It will open the login dialog. Enter the username and password for your Azure account and press login.If everything goes smoothly, the PowerShell output will look like the following screenshot.

Type the following command below to create a Service Bus namespace. Replace ‘MSCRMShopBus’ with the namespace you want and press enter

The output screen will look like the following screenshot. It will create a namespaces for both ACS and SAS.

This step is optional. Login to your Azure account and check the connection information of the Service Bus namespace. It will look like the following screen.

Get the Certificate file and Issuer name for CRM

For CRM OnlineTo get the security certificate and the issuer name for CRM go to Settings>>Customizations>>Developer Resources. Download the certificate file and also notice the issuer name of the certificate.

Contract is the type of contract we are using for the service endpoint. For the difference types of contracts check the last blog.

The registration tool will display the following screen. Enter the information below and press “Configure ACS”. Management Key is the default key when you create a Service Bus namespace. The certificate file and issuer name comes from the “Get the Certificate file and Issuer name for CRM” section of the blog.

Press “Yes” on the following screen.

It will create the management service, rulegroup and sample rules for the service endpoint. Press “Close”.

Press “Save & Verify Authentication”.It will test the authentication and save the configuration of the service endpoint. Press Close to close the screen.

Press “Save” to close the service endpoint registration screen.

Add a new step to the service endpoint as shown in the screenshot below. It is exactly the same as registering the step for a plugin assembly.

For this blog, I am creating a step for on creation of a new account. Choose the step values as required or copy the values as shown in the screenshot.

Setting up a listener application

For this blog, I am using the Azure sample code that comes with the CRM SDK. Open the “OnewayListener” project from the location \SDK\SampleCode\CS\Azure\OneWayListener.

Resolve the missing references. The 2 highlighted DLLs are available in the Azure SDK.

Run the sample code. It will prompt for the following information.

Service Namespace is the Service Bus namespace.Issuer name is the “Default Issuer” on the Service Bus connection information as shown in the step 5 of “Setting up a service bus namespace”. It is not the issuer name in CRM Online.Issuer Secret is the “Default Key” on the Service Bus connection information.

If everything is working properly it will display the service address as shown in the screenshot of step 3.

Testing the integration

The listener application should be up and running.

Login to CRM and create a new account. If everything is working properly, it will display the data context in the listener application.

To check the status of the jobs you can go to the “System Jobs” view.

If the listener application is not available, the status of the job will change to “Waiting for Retry”. It will keep trying to post the message and ultimately change to “failed” if it is not successful after X number of tries. The screenshot below display the details of the job with the status “waiting for retry”.