Webhooks are lightweight HTTP patterns for connecting to Web APIs. Dynamics CRM provides a nice out of the box feature for this. And that too no code option! It just need some configuration. So no coding in this post !!
Scenario: We all are familiar with Marketing preferences. Let's imagine we have another Marketing system ( Could be third party or internal) where we need to update this information. For instance, when a contact's preference is udpated it calls an API and sends that update. It is a POST operation.
Webhooks are very useful in this scenario. They are configurable and based on triggers. For instance, when a contact is updated / created it can send a webhook to an API.
Here is a small diagram to understand this concept. Please note that the API Management services is optional. But highly recommended. It accepts API calls and routes them securely to your backend services. API Managment services is not used in this demo and is optional.
Now the API app could be internal APIs or even external APIs depending on the requirements. There are different ways to mock this. One of the option is Requestbin (https://requestbin.com/ ). This is really cool one! And it is recommended in Microsoft documentations.
It acts like an API app. So it would help to do initial testing, How the webhook contents looks like etc. So let's configure one first.
So navigate to https://requestbin.com/
It is super easy to create an account. And then click on the create request bin option.
You could see your unique end point as shown in the picture. Also note on the left you could see the triggers. So leave this page open. When a webhook is triggered that gets logged here.
Now this is our mock end point ( API app to test this ). So copy that end point value.
Next part is to do the configuration in Dynamics plugin registration tool.
Plugin registration tool is a tool provided by Microsoft based on Dynamics CRM SDK. It can be downloed from the below link.
https://www.nuget.org/packages/Microsoft.CrmSdk.XrmTooling.PluginRegistrationTool
Once downloaded, click on the exe and connect to your organisation.
After connecting to your organisation, you could see the option to register a webhook.
Now name you could provide any. There are three types of authentication available. In this case WebhookKey option is chosen.Value doesn't matter in this case as Requestbin is a mock. End point URL is the url that is generated from Request bin. In real scenario this would the real API end point / Azure API management URL. After entering values click on Save.
Next step is to configure a trigger. So right click on the webhook end point and choose register a step.
Steps are based on operations. A step for record creation and another one for record update. Contact Update step is ok.
Few things to understand here.
Message - Operation
Entity - Entity for which the trigger is required.
Filter Attributes - This is quite useful. So it decides when the webhook gets triggered. For instance, we may only be interestered in certain attributes update and not all. So we could choose here. As it is a demo , its left as it is . But in real scenario, highly recommended to filter them.
Execution Mode - Make sure that this async.
Also make sure that delete asyncoperation if successful. Otherwise storage space would be wasted.
Webhook registration is below.
Time to see it in action!!!
Let's navigate to Dynamics CRM and update preferences on a contact record. Contact methods Email and Phone updated from Allow to Do Not Allow.
It is possible to inspect the data. That is the coolest part. The whole structure is available. This means you could see the values in the webhook content.
For instance, you could see the values that were udated on the CRM side.
So we managed to send an update happened in Dynamics to an API using webhook and that too in real time. So this is like a mock scenario. In a real scenario it could be an API that would update data in another system. All we need to do is to post a webhook to the API and then code should be written on the API side to update whereever needed. Sending part doesn't need any code. Just configuration will do. Please read Microsoft documentations for further details. As Azure service bus is also an out of the box integration, it is always confusing which one to choose. So Microsoft has provided some guidelines for this as well.
"When deciding between the webhook model and the Azure Service Bus integration, here are some items to keep in mind:
- Azure Service Bus works for high scale processing, and provides a full queueing mechanism if Dynamics 365 is pushing many events.
- Webhooks can only scale to the point at which your hosted web service can handle the messages.
- Webhooks enables synchronous and asynchronous steps. Azure Service Bus only allows for asynchronous steps.
- Webhooks send POST requests with JSON payload and can be consumed by any programming language or web application hosted anywhere.
- Both webhooks and Azure Service Bus can be invoked from a plugin or custom workflow activity."
No comments:
Post a Comment