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. 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.
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.
Will Drop an Anypoint MQ Subscriber as a source in our flow and configure the required details.
MQ Configuration:
The Complete Demo Flow:
The Request Payload logger will display the payload received from the Queue and the DateTime logger will display the current execution DateTime.
Request Payload logger DateTime logger
Http Requester Configuration:
Note: The requestor path is pointed to a non-existing resource on purpose so that the flow will through error so we can demonstrate the functionality of DLQ.
The Response Payload logger is to display the payload received as a response from Http Requester.
All the configuration and Creation of the MQ and Flows are done. Now we will look at working.
Working:
Click on the name of the MQ, a new window will open, in that we will add the message we want to process through the Subscriber.
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: demo-DLQ:
The Message from the demo-MQ is processed but as the flow has an error so the message is routed to DLQ.
So the message is not lost and it’s saved in the DLQ. Hence the message wasn’t lost.
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 Error Handling:
In the existing flow, we will add on Error Propagate and a Publisher 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
error-demo-MQ:
MQ Window:
At present the Error Queue is empty.
Now will again send a message in the demo-MQ (Parent Queue) and execute the flow.
Again as the retry attempt for the demo-MQ is 2 so the message will be processed 2 times if an error is encountered, so in this case, also the message will be processed 2 times.
The error-demo-MQ will have 2 messages:
Where as the DLQ have one message only:
The Reason behind demo-DLQ having 1 message and error-demo-MQ 2 message is:
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 as the message is processed two times and the error handler captures the error two times so the message is saved two times in the Error Queue.
Reference: www.apisero.com
