{Azure-CRM Integration Blog Series} 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/2016/05/12/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.

image

 

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.

image

 

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.

image

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.

image

 

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.

image

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.

image

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

image

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.

image

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

image

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

image

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.

image

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.

image

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.

image

 

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/2016/05/12/azure-crm-integration-blog-series-part4-developing-a-queue-listener-to-read-messages-from-the-queue/

Advertisements

Author: Debajit

I am a Dynamics CRM Most Valuable Professional (MVP) with 10 years of experience in Microsoft .NET Technologies and 7 years of dedicated experience in Microsoft Dynamics CRM. I have worked with companies like Microsoft, SanDisk, PwC, TMF Group and have extensive experience of implementing complex CRM solutions from both offshore and client side. Currently the face of XrmForYou.com with significant experience in delivering corporate training on Dynamics CRM and have already delivered multiple projects to client through XrmForYou.com Author of multiple tools on codeplex including the 'Role Based Views' and 'CRM-Sharepoint Metadata manager & Attachment Extractor' which are available for commercial use under XrmForYou.com For consulting/ training, drop me a note at info@xrmforyou.com or visit our website www.xrmforyou.com

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