This is another integration pattern used quite extensively in the integration world. It is used when a message is required to be routed to several endpoints in a particular order using some form of routing list. Depending on your business requirements, the message being routed may be enriched or replaced before sending it to the next service endpoint in the list.
This is probably one of the easiest integration patterns to implement using Logic Apps and Service Bus Actions. There are probably other methods to implement this pattern, but I wanted to abstract the routing logic away from the Logic App itself and leave it to focus on the business process and not worry about setting up the next routing endpoint.
By using the Actions feature of the service bus I can defined the routing order of the next service endpoint, or in this case the next service bus subscription by setting properties to match the next subscriber filter condition. A service bus action is executed after the filter condition has been met and is used to set the value of either a system or custom property before the message is consumed from the service bus. It is set in a similar way to the T-SQL “Set” command where you set a field to a value.
For this scenario I have a sales order message that is required to be passed to several logic apps in a particular sequence. There is a sales order header logic app, sales order line logic app, sale order payments logic app and finally a sales order completion logic app. The sales order message will look similar to this below.
Provisioning Azure Service Bus
The method involves creating a service bus topic called “salesorder” with the following subscriptions.
The filter and action rules are setup as in the following table. There are 2 custom properties “MsgType” and “ItineraryLeg” used for the subscriptions. The MsgType is just used to group the messages and the ItineraryLeg defines the order of the subscribers.
The action is used to specify the next subscriber to send the message to after the current process by setting the ItineraryLeg property.
| Seq | Subscription Name | Rule Filter | Rule Action |
| 1 | SOHeader | MsgType=’salesorder’ and ItineraryLeg = ” | set ItineraryLeg = ‘solines’ |
| 2 | SOLines | MsgType=’salesorder’ and ItineraryLeg = ‘solines’ | set ItineraryLeg = ‘sopayments’ |
| 3 | SOPayments | MsgType=’salesorder’ and ItineraryLeg = ‘sopayments’ | set ItineraryLeg = ‘socompletion’ |
| 4 | SOCompletion | MsgType=’salesorder’ and ItineraryLeg = ‘socompletion’ |
A sample of the SOHeader rules are shown below:
Creating the Logic Apps
Next we will provision the 4 logic apps to create the SO header, process the line items, apply the payments and complete the sales order.
The logic apps (SalesOrderHeaderProcessor, SalesOrderLinesProcessor, SalesOrderPaymentsProcessor) are constructed in a similar manner as shown below and the only difference is the topic subscription names for the service bus trigger action. The Delay action is where you would implement your business process logic on the received message.
Expanding the service bus trigger shape has the following properties set. The other logic apps will have different Topic subscription names set.
The real smarts of these workflows are the “Republish message” service bus action shape. You will need to add this shape to every logic app that is involved in processing the message. Here we set the ItineraryLog and MsgType property values to the same values in the Trigger service bus action shape. Also I am adding another custom property called “Tracking”. This is used to track the name of logic app the message was routed to in a chorological order and can be useful for debugging. The content property is just set the received message from the service bus trigger. Depending on your business requirements, you may be required to publish a totally different message.
Below is the code behind for the Republish message shape showing how to setup the properties section.
“body”: {
“ContentData”: “@{triggerBody()?[‘ContentData’]}”,
“Properties”: {
“ItineraryLeg”: “@triggerBody()?[‘Properties’][‘ItineraryLeg’]”,
“MsgType”: “@triggerBody()?[‘Properties’][‘MsgType’]”,
“Tracking”: “@concat(coalesce(triggerBody()?[‘Properties’]?[‘Tracking’],’Begin’),’,’,workflow()?[‘name’])”
}
},
The other logic app SalesOrderCompletionProcessor simply pulls the message from the last subscription and sends the Tracking property value to RequestBin.
Messages are placed onto the service bus using the MessagePublisher logic app which accepts a json message and initialises the service bus custom properties “ItineraryLeg” and “MsgType”. Here the ItineraryLeg is set to an empty string and the MsgType being set to “salesorder”. The body of the HTTP request trigger is used as the message content for the Send message action shape.
Testing
Using PostMan we can POST a message to the MessagePublisher logic app. If you set the delays long enough in the logic apps, you can see the message being published and consumed by the subscribers in the correct order as defined in the service bus actions.
Here is the result of the message being posted to the MessagePublisher logic app and the output from the SalesOrderCompletionProcessor logic app which sends it to RequestBin.
Begin,SalesOrderHeaderProcessor,SalesOrderLinesProcessor,SalesOrderPaymentsProcessor,SalesOrderCompletionProcessor
Now if I wanted to change the order of the message processing, say I wanted to process the payments before the sales order lines. Here I would simply update the actions on the service bus subscriptions as follows:
| Seq | Subscription Name | Rule Filter | Rule Action |
| 1 | SOHeader | MsgType=’salesorder’ and ItineraryLeg = ” | set ItineraryLeg = ‘sopayments’ |
| 3 | SOPaymentsSOLines | MsgType=’salesorder’ and ItineraryLeg = ‘solines’ | set ItineraryLeg = ‘socompletion’ |
| 2 | SOPayments | MsgType=’salesorder’ and ItineraryLeg = ‘sopayments’ | set ItineraryLeg = ‘solines’ |
| 4 | SOCompletion | MsgType=’salesorder’ and ItineraryLeg = ‘socompletion’ |
Now the output of the SalesOrderCompletionProcessor looks like this below. You can clearly see the payments logic app being executed after the sales header process.
Begin,SalesOrderHeaderProcessor,SalesOrderPaymentsProcessor,SalesOrderLinesProcessor,SalesOrderCompletionProcessor
In Summary
Use service bus actions to manage the itinerary list to abstract the routing logic away from the normal business process of the logic apps.
Typically you would use Azure Resource templates to setup the service bus subscriptions and rules under TFS control.
Keep a watch out for my next article on Content Based Routing using Azure Logic Apps and Service Bus.
Enjoy…