Service Bus Queues & Power Automate

The announcement at Build 2020 that there is finally a Service Bus Explorer in the Azure Portal prompted me to write a post about using a Service Bus Queue with Power Automate.

What are Message Queues?

Messages queues are used to build scalable integration between platforms where a sender application puts messages on a queue and a receiver application reads the messages from the queue. The sender and receiver are “decoupled” in that the availability and speed of either application does not impact the other. The sender can create 000’s of messages on a queue and the receiver can process them as and when it is ready to process. This makes message queues highly scalable. In the past queues could only have been utilized by developers using code however they can be used from Power Automate without writing any code. In this example, I am creating a Power Automate Flow to read Json messages from a queue which then calls a UI Flow to complete an RPA task that creates a ledger entry on an accounting system. It need to operate like this as this is an attended UI Flow and the user needs to log on the accounting system first for it run.

Creating Azure Service Bus Queues

Queues are created from the Azure portal by first creating a service bus namespace and then adding a queue to the namespace.

Securing Access to Service Bus Queues

Shared Access Signatures (SAS) are used to create security policies for a queue with access to either manage the queue, send messages to the queue or listen (read) messages from the queue. Here I have created two different policies for my queue payablequeue one with Send rights and the other with Listen rights. My Power Automate Flow will use the Listen policy connection string to read messages from the queue.

Service Bus Flow

The Power Automate Flow to carry this out is pretty straight forward. The trigger is when a message is received on the queue. The message is read in peek-lock mode meaning it remains locked on the queue until it is either completed or removed. This is good practice when reading messages from queues in case anything goes wrong when processing the message. The alternative is a destructive read which deletes the message from the queue as soon as it has been read.

Parse message and call Ledger UI Flow

There are two actions in this scope. The first parses the received messages which is a Base64 encoded Json object using expression @base64ToString(triggerBody()?[‘ContentData’]) The schema was generated based on the sample { “ponumber” : “AB13219”, “description”: “materials”, “amount” : “123.45” }

The second action calls the UI Flow I created in my post https://joegill.com/rpa-power-automate-ui-flows passing in the values from the received Json message as parameters

The second action call the UI Flow I created in my post https://joegill.com/rpa-power-automate-ui-flows

Concurrency

An important setting I configured on my Flow was to set the concurrency control setting on and set its value to 1. This ensures that only one instance of the Flow will run at a time otherwise, the UI FLows would conflict with each other. More more details on the concurrency control setting check out my post https://joegill.com/logic-apps-429-failed-dynamics-365/

Running the Power Automate Flow

The payable inbound flow should be turned off when not in use and messages will be queued up in the service bus queue until it is turned on. The user can logon to the PC configured for the UI Flow and turn the flow on. The messages will be processed one at a time from the queue and the message contents will be used to call the UI Flow and create an ledger entry. The Run After setting of the scope is configured to Complete the message on the queue if it is successful. This removes the message from the queue. If one of the actions fails then the message is removed from the queue and moved to the dead letter queue for correcting.