Photo by Álvaro Serrano on Unsplash

Publish-Subscribe messages from Azure Service Bus Queues from Mule

0Shares

This article uses Anypoint Studio 7.3.4 and Mule runtime 4.2.0. There are two mule flows:

  1. A Publisher flow that publishes message to Azure Service Bus Queue.
  2. A Subscriber flow that reads the message from Queue.

In order to use Microsoft Service Bus module in the mule flows, first we need to add the module to the application. You can add the module by clicking on the “Search in Exchange…” in the Mule Palette as shown in the Figure 1 and search for “Microsoft Windows Service Bus” and click the “Add” button and then “Finish” button as shown in the Figure 2.

Figure 1 – Search in Exchange
Figure 2 – Search and Finish

Let us design the Publisher flow first. Add HTTP Listener in the Canvas and create a Connector configuration by clicking “+” icon in the “Basic Settings” section of the Connector properties window. Add port with some valid port number that has not been used in your computer. In my case, I am adding 8087.

Figure 3 – Adding port

Now go to “Global Elements” tab and create a Service Bus configuration. Clic on “Create” button and search for “service” and select “Microsoft Service Bus Config” as shown in Figure 4. Add “Shared Access Key Name“,”Shared Access Key” and “Service Namespace” values in the properties and click OK.

Make sure you get the right values by going to right key name, key and service name space values by logging into Azure Portal portal.azure.com as shown in the Figure 6.

Figure 4 – Search “Microsoft Service Bus Config”
Figure 5 – Add Shared Access Key Name, Shared Access Key and Service Namespace
Figure 6 – Namespace, key name and key values in Azure Portal

Now coming back to Publisher flow, add the logger component to log the messages and then add the “Queue Send” connector in the “Microsoft Service Bus” module as shown in the Figure 7.

Figure 7 – Publisher Flow

Add properties for the “Queue Send” connector as shown in the Figure 8. All the properties are default except the “Destination queue” which should be the queue name created in Azure Portal.

If you want you can run the flow and check if a message is added in the queue by going to Azure Portal and checking Queue messages count.

Now adding Subscriber flow which reads messages from Queue and logs the message. I am using manual acknowledgment in this application instead of other options available. If you are using manual acknowledgement it is your responsibility to acknowledge message once the flows are executed. Otherwise, you may end up in scenarios where duplicate messages may be subscribed at the subscriber’s end.

Add “Listener” connector from Microsoft Service Bus module on the canvas and configure the properties as shown in Figure 9.

Figure 9 – Listener configuration

Add logger components to log the message and then at the end you need to add “Ack” connector from the Microsoft Service Bus module to acknowledge the message. I have add another “Ack” connector in the “Error Handler” so that we process steps on what to do when there is an exception and then acknowledge the message.

When you check the message attributes in debug mode, you will see each message read from Queue has an attribute “ackId” that we need to capture and add it in the Ack id input of the “Ack” connector. By default, the value used is payload. But there might be chances where the payload is changed in the flow and so the acknowledgement fails. In order to make sure the acknowledgment is not failed, we will track the “ackId” attribute.

Best practice is you read the attribute “ackId” at the beginning of the flow and store it in a variable and access the variable. If the original message is changed during the flow execution you will lose the attribute.

Figure 10 – AckId

My final Subscriber flow looks like below:

Figure 11 – Subscriber flow

Now run your flow and post a message using Postman and check the logs. If you are working on the Microsoft Service Bus connector for the first time you can run the application in debug mode and check the attributes and changes happening during the execution. Best way to learn is to change the acknowledgment values of the listener and check how the flow works.

Figure 12 – Postman Request
Figure 13 – Logs

If you check the logs, the one highlighted in green color are for Publisher flow and one highlighted in red are for the Subscriber flow. In a typical project, you might or might not need both flows.

Hope this helps to go with a basic flow. If you want to check the exception flow and how acknowledgment works, add “Raise Error” component before “Ack” and check if it goes to the exception block and the error is handled with acknowledgment or not.

The code for the post is available in github at https://github.com/ivaturia/testabqueueswithmule

Hope this helps. If you find this post useful, do not forget to share with your friends. Happy coding!!!

0Shares