Power Automate and Azure Service Bus Queue Use Case

As you all know Power Automate is really cool!  It has got a lot of connectivities. This post aims to focus on Power Automate and also a scenario in which it can be utilized.

Consider a scenario. Payments are managed by another system and no payment / bank details are stored in Dynamics 365 CRM. But still need the capabiltiy to update it occasionally from Dynamics 365 CRM. Power Apps can be very handy in this context. An embedded Power App ( Canvas App) in Model Driven App is used here to capture the details. It triggers a Power Automate ( Flow) from a button. And then Power Automate publishes an Azure Service Bus message to the queue ( Azure Topics are also supported here in complex scenarios). An Azure function listens to Azure Service Bus queue and it gets triggered when a message arrives in the queue. Please note that it could be a console app as well. I chose Azure function for demo purpose. Azure function calls APIs of payment system and the details get updated there.

Obviously there are other ways to do it. This is just one option. Service bus is known for it'd resilience and also it has other features like retry message mechanism etc.These are just some guidelines, feel free to update as per your requirement / scenario.

Here is a small diagram to understand this sample scenario.

There are plenty of posts about Embedded Power Apps which triggers a Power Automate. So I am skipping screen shots for those. Assumption is that there is a bank wizard Canvas App and user access it when bank details need to be updated. On submission a Power Automate gets triggered from the button.

 First things first! Let's create a Service Bus and a queue. 

Navigate to htts://portal.azure.com/ and choose create new Service Bus option. Here , I chose a basic pricing tier.

 

  Important part of the Service bus is of course it's connection. This is required to establish a connection. It is  found in the Shared Access Policy section.

Primary connection string is what we need.

 

   

Next part is the queue. Select the Queues section.

 

 

Let's call the queue as bankwizardq. Properies of the queue is left as it is. But this can be changed accordingly.

 

Service Bus has a cool feature in preview - Service Bus explorer. This bit is interesting because I used to use a third party tool for this (https://github.com/paolosalvatori/ServiceBusExplorer). Now Microsoft provides this feature within the service bus.

 

 

Messages can be viewed using the Peek button. Currently no messages available. But it is ready to receive messages.

At this stage, assumption is that an Embedded canvas app triggers a flow with 4 Parameter values. Skipping this, as there are plenty of posts about this part. 

Next part is the Power Automate. It has mainly 3 steps. PowerApps is the trigger point of this Power Automate. Compose step forms a Json message from the values sent across. Send Message step is for sending a service bus message.

 

 

 Session Id is set to a new guid but feel free to set whichever you prefer. Output of the compose message is set to the Content. 

Service Bus connection part is shown below. Service bus connection from the Shared Access policy is provided here.

 

 

 

 Power Automate is triggered from the Power App and a message is received in the queue.

 

Power Automate run sample is below.

 

 

 Next part is to have an Azure function to gets triggered as soon as the message arrives in the queue. As mentioned earlier this could be a console app as well.

From Visual studio select a new project and choose azure function

Choose Service Bus Queue trigger and provide queue name and connection string values. This can be updated later as well. At this point, just put myqueue and mySBConnection.

 

 

 Connection string is updated in loal.settings.json file.

Queue name is updated as bankwizardq in the function. Next step is to run the function using the run button. When a message arrives in the service bus queue, function gets triggered.

 Console window output is below.

Azure function can call Third party APIs to udpate the details / Udpate DB as per the requirements. These are guidelines only. As per your requirement, things change.

 

How to Send a Webhook from Dynamics 365 CRM?

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.

Dynamics user updates marketing preferences of a contact record in Dynamics. This triggers a webhook and sends / posts to an API endpoint.

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.

 

 

This trigger gets logged in Request Bin straightaway.

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.

(Ref: https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/use-webhooks#query-failed-asynchronous-jobs-for-a-given-step )

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