{Dynamics 365 + Azure + Queue} Part3 – ACS integration with Dynamics CRM and posting of messages to Queue

This is the third post in the series and if the you are directly in here, I strongly suggest to start from the link – https://debajmecrm.com/blog-series-complete-in-depth-walkthrough-of-dynamics-crm-plugins-with-azure-service-bus-queues/

Open Plugin Registration Tool and click on Register –> New Service Endpoint

• Name – Enter a suitable name.
• Description -  Don’t leave this blank. It is mandatory otherwise you would get object reference error
• Solution Namespace – This should be same as service bus namespace you created. I put the service bus namespace that we created in the previous step – crmdemo-ns
• Path – This should be the name of the queue. In my last article, we created queue named ‘testqueue’. So I put testqueue here.
• Contract – Since we are dealing with queues here, choose PersitentQueue from the list of values.

 

And you are done! Click on Save and Configure ACS button.

As soon as you click, you get a pop-up screen as shown in the screenshot below.

 

Management Key –

Open Azure Management Portal –> Service Bus –> Select your service bus –> Connection information (at the bottom of the screen). You should see a screen like below.

Copy the default key and paste in the management key box in plugin registration tool.

 

Certificate File –

The public certificate file that was used to configure Microsoft Dynamics CRM for integration with Microsoft Azure.

For Microsoft Dynamics CRM Online 2016 Update and Microsoft Dynamics CRM 2016 (on-premises), you can download this certificate file from the server. In the Microsoft Dynamics CRM web application click Settings > Customizations, and then click Developer Resources. Download and save the certificate file using the link provided below Microsoft Azure Service Bus Issuer Certificate.

 

Issuer Name –

The name of the issuer. This name must be the same name that was used to configure Microsoft Dynamics CRM for Microsoft Azure integration. You can obtain the issuer name from the Developer Resources webpage mentioned in the previous description.

 

Click “Configure ACS”. The system will create Rulegroups and relying party applications. Once done click on ‘Close’ and then click save on the main plugin registration window. So you have set-up Dynamics CRM to integrate with the queue to send messages. This steps you can even find in the SDK. Nothing new in that. But wouldn’t you like to know what happened inside. Come on – let’s explore it together.

Open Azure Management Portal –> Service Bus –> Select your service bus –> Connection information (at the bottom of the screen). In the pop-window click on ‘Open ACS Management Portal’ at the bottom of the screen.

Once the ACS management portal opens, go to ‘Relying Party applications’. Remember in the first post of this series, I explained that Queue would be set-up to trust the ACS for authentication. This is what CRM plugin registration tool has done. It has create an entry for the Relying Party.

Open the record. You would see a screen like below.

The field “Realm” is the path to the relying party. Any claims issued by ACS for realm would be valid.

In the ‘Authentication Settings’ section, the identity provider is selected as Windows Live Id. This is because Dynamics CRM online is based on the Office 365 credentials.

And then you have Rule Groups. Now these are the rules which dictates how the claims generated from Dynamics CRM identity provider are transformed into ACS token claims which is understood by the relying party. As you can as a part of the configuration process, Dynamics CRM has created a Rule group name ‘Rule group for testqueue’.

Let us open this rule group and check what rules are in there.

So as we can see, we have four rule groups. If you remember my first post in the series, the first thing that should happen is that when a user from Dynamics CRM posts a message to the Service Bus queue, CRM would validate the credentials and generate an IP token which will be passed to ACS in the next step. The rule which does that in the above screenshot is highlighted. If you see, the claim issuer is ‘crm.dyanmics.com’ which is the service identity that we set up in an earlier blog post in this series.

Unfortunately, ACS management portal does not support claim rules set-up from servic
e identities. It supports claim rules set-up for only identity providers. So if you open this record you would see something like below. You can access this programatically however. If interested please explore it.

But as far we know what is going on here, we are good.

Now comes the other three rules. Before I explain the above rules, we should first know that a queue has three set of permissions ‘Send’, ‘Listen’ and ‘Manage’. For e.g if you have listen permissions, you can just connect to the queue and receive messages from the queue. You cannot however send a message to the queue.

Now coming to the rules, you can see that dynamics crm configuration process has create three separate claims rules for three permissions

• sampleorgsendrule
• sampleorglistenrule
• sampleorgmanagerule

So now you understand why three claim transformation rules are set-up. I have been through many articles but in none I could find it properly explained regarding why these four claim rules. So I decided to pen it down.

Since we would be posting messages to the queue, I think you have already guessed it. We need to check the Send Rule. So let’s explore the ‘sampleorgsendrule’.

As you understand things, it becomes pretty obvious right. The first thing to notice here is the ‘Input claim Issuer’ section. As you can see Access Control service is selected. Remember I explained in the first post. The ACS converts the token from Identity Provider (IP) into claims which are understandable by the Relying party (queue).

However check for the value of the Input claim. It is specified as owner. Here we just want this rule to execute only if the input claims are from Dynamics CRM. For this I will substitute this value with the unique name of my CRM organization which you can find in Settings –> Customizations –> Developer resources.

One very important thing to remember here is for on-premises, you need to specify the Org Unique name. However for online it should be full host name. Since my organization name is sltraining, so for me the value would sltraining.crm.dynamics.com. Below is the screenshot after edit.

And finally the output claim value is set to ‘Send’. So basically ACS takes the name identifier claims and converts it into Send claim which is understood by the queue.

So now we are all set to send a message to this queue.

Open Plugin registration tool one more time. Right click on the service endpoint we created and click on register new step. Enter the below details.

What we are basically doing here is on-post create of an account we are posting the context information to the Queue. Remember to mark it asynchronous. CRM will not allow you to register Synchronous step here.

So all set and done. Let’s just go ahead and create a new account. Once account creation is completed, go to Settings-> System Jobs. If your configuration is correct, you would see that the post to queue is successful.

 

In my next article and which is the final article in the series, I will explain how to retrieve this message from the queue – https://debajmecrm.com/azure-crm-integration-blog-series-part4-developing-a-queue-listener-to-read-messages-from-the-queue/