In-order message delivery using Azure Logic Apps

In some of our previous Turbo360 (Formerly Serverless360) tips, we have focused on how we can scale-out Azure Logic Apps to drive greater performance from the cloud integration platform.

One such requirement may include work order processing where we need to process any work order updates, before we process any work order closures. Usually these types of requirements are driven by the behaviors of upstream or downstream systems and how users interact with those systems. As a result, we need to implement a messaging pattern to address these requirements.

The messaging pattern we will implement is in-order delivery, meaning we want records processed in the order that they were modified. Another term you may be familiar with in the BizTalk world is creating a Singleton, meaning only one instance of the workflow (logic app) will be active at a given time. For those of you who have implemented this pattern in BizTalk, I have good news for you. It is much simpler in Azure Logic Apps!

To illustrate our scenario, we will retrieve work order updates from a SQL database. SQL is being used an example, it could just as easily be a messaging queue or http endpoint. When we receive work order updates from our work order management system, we need to update our CRM system so that our customer service agents have up-to-date information.

Within our logic app, we need to configure our trigger and will add an Order By clause which will order records based upon their update timestamp. An HTTP action has been added to the Logic App to reflect an update to our CRM system and a Delay shape has been added for illustrative purposes, so we can validate our singleton Logic App is working as expected.

We will also update the Settings for our trigger and enable Concurrency Control and set our Degree of Parallelism to** 1**. This will ensure that only 1 instance of our logic app can run at one time.

Testing

To test our logic app, we can update two records in our work order management database. The first record will reflect our work order update and the second record will reflect our work order being closed. These actions can take place seconds apart from each other, but since we cannot update a closed work order it is important that these records are processed in order.
When our Logic Apps kicks-off, we have one active logic app and one that is waiting which means our initial work order update is being processed, while our work order complete is waiting to be processed.

If we take a closer look into our running logic app, we will see our workflow is currently in its Delay action.

Once our Delay action has completed, we can see that our initial logic app has completed and now our second logic app’s state has changed from Waiting to Running.

Conclusion

In this post, we have reviewed a popular messaging pattern based upon in-order delivery and have addressed it using a Singleton inside of Logic Apps. Singletons can be implemented quite easily inside of Logic Apps by using Concurrency Control which is part of our Trigger. The Logic Apps engine will take care of the rest and we are able to focus on solving our core business requirements instead of building custom flow control functionality.