Service Bus message properties come in very handy when working with multiple subscribing systems. In this example, we will show you how easy it is to route a message to different message listener subscribers using user-defined properties.

To work with this use case, we have created a logic app that will receive an HTTP request through a request trigger and post the message to the topic using content data and message properties. The logic app will set the message properties on each published message to the Service Bus topic using a defined key-value JSON string. This will enable the appropriate client application to subscribe to a message based on the filter condition.

To work with this, we have JSON inventory request data containing a set of properties for the message-subscription routing, along with the request body. The sample request data is shown in the following snippet and is used in the Logic Apps workflow to set the required message data and routing properties:

{
  "properties": {
    "MessageType": "MessageType='Orders'",
    "department": "Inventory"
  },
  "RequestBody": {
    "OrderId": "000000000012",
    "OrderQuantitiy": 10
  }
}

The logic apps will use the JSON body and parse the content on the request trigger. This will enable the Logic Apps workflow to iterate through the incoming JSON and set the dynamic properties based on the request content. You can have n number of properties, which can enable an enterprise to have multiple subscription filters based on request content. For this specific payload to be subscribed to the end application, the filter condition is set as follows:

"properties": {
  "filterType": "SqlFilter",
  "sqlFilter": {
    "sqlExpression": "MessageType='orders AND department ='Inventory'",
    "requiredProcessing ": false
  }
}

Within the Logic Apps publishing workflow, we have set the required properties based on the dynamic requests coming through the request trigger:

Enabling duplicate detection on the specified topic or queue helps the enterprise to minimize the risk of having duplicate data in the backend system, and it also minimizes the overall processing cost of the integration framework when you work with the consumption-based model. To enable duplicate detection for messages coming through a Service Bus topic or queue, we need to enable the duplicate detection feature. This can be done either through code or by using the Azure portal, as described here:

In the preceding topic, we have enabled duplicate detection. Any order that comes to this topic with the same MessageId within 15 minutes will be treated as a poisoned message and will not flow through the subscribing system. By changing only one MessageId property within the publishing framework, duplicate detection will be enabled:

The last thing to do now is to publish and test a sample message with some properties and verify that content-based routing is working well. As this is the HTTP request trigger, we have used Postman to invoke the publishing logic app workflow. We have submitted the same order twice, and can see only one order getting through to the subscribed logic apps:

This exercise brings this chapter to a close. In the next chapter, we will cover more patterns that can help you to get a firm grasp of integration patterns and how you can work with multiple flow controls within Logic Apps.