Content Based Routing (CBR) is another pattern used in the integration world. The contents of the message determines the endpoint of the message.
This article will describe one option to develop this pattern using an Azure Service Bus, an Azure Function and a Logic App.
Basically the service bus will be used to route the message to the correct endpoint using topics and subscriptions. The Azure Function is used to host and execute the business rules to inspect the message contents and set the routing properties. A logic app is used to accept the message and call the function passing the received message as an argument. Once the function executes the business rules, it will return the routing properties in the response body. The routing information is then used to set the properties on the service bus API connector in the Logic App before publishing the message onto the bus.
To demonstrate a typical use-case of this pattern we have 2 message types, Sales Orders (SO) and Purchase Orders (PO). For the SO I want to send the order to a priority queue if the total sales amount is over a particular value. And for a PO, it should be sent to a pre-approval queue if the order value is under a specified amount.
The real smarts of this solution is the function which will return a common JSON response message to set the values for the Topic name and the custom properties on the service bus connector. The fields of the response message are described below.
- TopicName – the name of service bus topic to send the message to.
- CBRFilter_1 – used by the subscription rule to filter the value on. Depending on your own requirements you may need more fields to filter more granular.
- RuleSetVersion – used by the subscription rule to filter the value on. It’s a good idea to have this field as you may have several versions of this rule in play at any one time.
Let’s start with provisioning the service bus topics and subscriptions for the 2 types of messages. First create 2 topics called purchaseorder and salesorder.
Now add the following subscriptions and rules for each of the topics.
|Topic Name||Subscription Name||Rule|
|purchaseorder||Approved_V1.00||CBRFilter_1 = ‘Approved’ and RuleSetVersion = ‘1.00’|
|purchaseorder||NotApproved_V1.00||CBRFilter_1 = ‘ApprovedNot’ and RuleSetVersion = ‘1.00’|
|salesorder||HighPriority_V1.00||CBRFilter_1 = ‘PriorityHigh’ and RuleSetVersion = ‘1.00’|
|salesorder||LowPriority_V1.00||CBRFilter_1 = ‘PriorityLow’ and RuleSetVersion = ‘1.00’|
Next is the development of the Azure function. This is best developed in Visual Studio where you can include a Unit Test project to each of the rules. Add a new Azure Function project to your solution.
Below is code for the HTTP trigger function which includes the class definition for the RoutingProperties object. I am checking for specific elements SalesOrderNumber, PurchaseOrderNumber in the JSON message to determine the type of message and which determines what rule code block to execute. Each rule block code will first set the TopicName and RuleSetVersion properties.
The business rule for a SO aggregates all the line items and checks if the total amount is greater than 1000, if it is then set the property CBRFilter_1 to “PriorityHigh”.
The business rule for a PO also aggregates all the line items and checks if the total amount is less than 500, if it is then set the property CBRFilter to “Approved”.
The output of the function should look similar to this below:
Using PostMan we can send sample messages to the Logic App and then see them sitting on the service bus waiting to be processed by some other method.
CBR can be easily achievable using an Azure Function to execute your business rules on a message to set up the routing properties. Taking this a step further, I would abstract the business rules for each message type in its own class for manageability.
Also it is advisable to setup a Unit Test project for each of the classes holding the business rules to ensure 100% code testing coverage.