Anypoint MQ on CloudHub: Part 2

My last article on MQ got a good response. As already decided, we will conclude the MQ details in this article. So, let us start on available features of Anypoint MQ.

I have provided many settings and configurations in the previous article. Here we will start with other settings and their usage. Now you can click on the queue name which you have already created and configured.

Message Sender 

The Anypoint platform provides the opportunity to send the message to the queue directly. It results in proper checks about the working of the queue. For example, I can check what messages I have put in the queue and what is the format related to it. 

The below image can provide you the type of message Anypoint MQ supports natively. JSON, Text(string), and XML are currently supported. These types are very common in day to day operations on the ESB layer.

The next image is to show an example of how to pass the values. Here I am inserting one JSON into the queue. The moment you place it in the Payload section, your Send button will be activated. Click on it and the message would be placed into your queue. You will see a green pop up, if successful. For a failure, the pop up would be red.

Message Browser

Now, click on the message browser and you can see the Get Messages button. You can configure the number of messages and polling frequency for the queue.

Now you can see the message what we have just inserted in the below image.

You can see the message ID, timing of push, and content of the message. The one problem Anypoint MQ is currently having that there is no messageId-based pulling from the queue. This feature is very common with most on-prem queues and on cloud available with SQS by Amazon. I hope soon we will have more teeth to Anypoint MQ over cloud.

I have marked one icon in top right corner, which is Return Message". Whenever we click on the messag,e it becomes unreadable for the client who is reading the queue. You have to click on this icon to return the read message back to queue to make it readable.

There is an individual delete and purge (group delete) option if you want clear the queue. Please note all such operations are possible from the Mule flow if you are using Amazon SQS. Here, Anypoint platform is the place where we have to come to perform such operations (i.e. group deletion).

Now I should move towards how to make an Async design using MQ.

Async Implementation Using MQ

The design decisions are merit-based. There can never be only one approach. However, I can suggest the one I have implemented. Say for example I have to do a transaction between three systems (A-->B-->C). In this scenario, A-->Mule-->B and then B's response has to be moved into C for consumption. To make all the processes async, we have to place queues in between.

Happy Path: In this situation, A-->Mule-->A's response Q. Now the second flow would be like A's response Q-->Mule-->B-->B's response. You can visualize the design here. In the first flow, only you can send the response back to A about the message being queued, since we will make all effort to make.

Error Path: Suppose we are contacting system B, which is down currently in this scenario, we can place the payload to errQ so that it can be retried on a fixed interval and fixed number of retries. Now the question may come: why we do not make a NACK and keep the message in the normal queue. The logic behind this is that maximum designs will ask you to wait for a particular period of time before retrying. If you combine this with the normal Q then it would be messy. We can have an independent processing for errQ with a Poll component on different settings.

Another approach may be that you can calculate the number of retries from normalQ and then place to errQ. The MEL for it is "#[message.inboundProperties.headers.deliveryCount >${maxretries}]". You can configure the max retries you want.

Poison Path: Suppose there is some issue with the request which we are making to system B and this is resulting in failure each time. Eventually, the request can not be processed, so in this situation, we will place this message to PoisonQ. At the same time, we have to notify system A that the request could not be processed. We can place email alerts on these poisonQs which will notify administrators for further action on it.   

I have tried to provide some detailed insight into Anypoint MQ's workings. I hope this will be helpful in working/designing with Anypoint MQ.