Author: Abhishek Bathwal
Anypoint MQ is a multi-tenant, cloud messaging service that enables customers to perform advanced asynchronous messaging scenarios between their applications.
The dead-letter queue (or undelivered-message queue) is the queue to which messages are sent if they cannot be routed to their correct destination.
By the end of the document you get a clear picture of how to configure a Queue, the DLQ (Dead Letter Queues), Assigning a DLQ to the Parent Queue and how the message gets routed from the Parent Queue to the DLQ after failure.
Configuration:
Open Anypoint platform and select MQ in that:
Note: To access Anypoint MQ you need to buy it separately from MuleSoft.
In the MQ window we need to first select a Region where we want to create our Queues, Select a Region which contains the Data Center near to our geographical area. And then will click the plus ( + ) symbol to create the Queues. Every Region has its own dedicated url which will be used at the time or configuring the Queue in the Mule flow.
Here, we will create two Queues one will be named as demo-DLQ (DLQ) and the other one will be the demo-MQ (Parent Queue) in which the DLQ will be assigned.
DLQ Configuration vs. MQ Configuration
The demo-DLQ will have normal configuration.
While creating the demo-MQ, we toggle the Assign a Dead Letter Queue to On State. One the State is On we will get a dropdown option to select Dead Letter Queue Name where we can find the name of all DLQ present and here we will select our DLQ to be assigned in the Parent Queue. Down to that there is an option to assign the number of attempts, this option defines how many retries the parent Queue will do to process the message if there is any failure while sending the message to the destination. We will set the value to 2 attempts.
Once the Queues are created with the provided configurations, we can find it in the main window. To use the Queues in our Mule flow we also need to have Client App Id and Client Secret. To achieve this we need to select the client Apps option present at the left most corner over the Queue windows and then click the plus ( + ) to create credentials.
Once the credentials are created it can be seen in the Client App window.
The configuration and creating of MQ are done. Now, we will create flow and use the MQ’s.
We will drop an Anypoint MQ connector as a source in our flow and configure the required details.
MQ Configuration:
The Complete Demo Flow:
The Transform Message will capture the payload and transform in readable format. The logger will display the payload.
Transform Message Code Logger:
Http Requester Configuration:
Note: The requestor path is pointed to a non-existing resource on purpose so that the flow will go through error so we can demonstrate the functionality of DLQ.
All the configuration and creation of the MQ and Flows are done. Now, we will check how it functions.
Working:
Click on the name of the MQ, a new window will open, in that we will click on the Message Sender option and add the message we want to process through the flow.
We have pushed 1 message to the Queue.
The message processed through the flow and failed at the Http Requester as the endpoints are not valid.
While configuring the demo-MQ (Parent Queue), we have configured the Retry attempts as 2 so upon failure the MQ will try to process the message 2 times. And the same can be observed in the console.
Now let’s check the message status in the demo-MQ (Parent Queue) and demo-DLQ (DLQ).
demo-MQ vs. demo-DLQ
The Message from the demo-MQ is processed but as the flow has error so the message is routed to DLQ.
So the message is not lost and it’s saved in the DLQ.
Whenever we create any flow we also create Error Handling strategies. So let’s check how the DLQ will work if the Error Handling strategies are configured.
With Exception Strategy:
In the existing flow, we will add Catch Exception Strategy and a Publish Queue config to save the message in an error-demo-MQ (Error Queue) which is a normal Queue and not a DLQ.
Error Logger: Display the Request Payload
Anypoint MQ config for error-demo-MQ:
MQ Window:
At present the Error Queue is empty.
Now, we will again push a message in the demo-MQ (Parent Queue) and execute the flow.
Again, as the retry attempt for the demo-MQ was set to 2 but it executed only once.
Reason: This is due to the Exception Strategy. As the Exception Strategy came into picture unlike the first scenario it handled the exception and did not allow the MQ to have a 2nd attempt so the reroute failed and the payload got captured in the error-demo-MQ in 1st attempt.
The error-demo-MQ will have 1 message:
Where as the DLQ has No messages:
Conclusion:
As the DLQ is a part of the Parent Queue so it inherits the policies and properties of the Parent Queue, whereas the Error Queue is a separate normal Queue. So, in the first scenario as there was error in the flow the message processed two times and routed the message to DLQ.
But in the 2nd scenario the Exception Strategy overwrites the functionality of MQ and handled the exception which didn’t allow the MQ to have a 2nd Attempt.
Note: The 2nd scenario is similar to the behaviour of DLQ with On Error Continuous as Error Handling in Mule 4.
Functioning of Anypoint MQ DLQ in Mule 4:
Happy Learning!
