How To Use JMS ActiveMQ With Mule 4 - Part 4
In this blog, we will see how to use the Mulesoft JMS connector to perform the Request-Reply pattern using the JMS publish Consume operation.
Join the DZone community and get the full member experience.
Join For FreeThis is the fourth part of the JMS ActiveMQ with the Mule4 series. You can read previous parts here: Part 1; Part 2; Part 3. In this post, we will learn about the JMS Request-Reply pattern and how to use it in Mulesoft.
JMS Request-Reply/Response pattern in Mule :
Request-Reply or Request-Response is one of the mainly used messaging patterns, where a requestor application sends a request, a replier application receives the request and returns a reply back to the requestor, and the requestor receives the reply. It is a synchronous message communication method.
For implementing Request-Response Pattern we require 2 Queues:
A Request Queue which Requestor uses to send the request message to the Replier.
A Response Queue which Replier uses to send the reply message to the Requestor.
Below steps are involved in the exchange of messages using this pattern:
1. Requester publishes the message to the Request queue.
2. Consumer subscribes to the message from the Request queue.
3. Once the processing is completed, the consumer will send a response back to the Response queue.
4. The requestor will subscribe to the message from the Response queue.
In Mulesoft, Publish consume operation is used to implement the Request Reply pattern.
Publish Consume:
This operation combines the functionality of the JMS Publish and Consume Operation. It allows the user to publish a message to Request Queue and then wait for a response. If we set reply-to queue, then the response will be sent to that queue otherwise it will be sent to a temporary queue, created when the message is being sent.
JMSReplyTo header of the outgoing message contains the ID of the destination on which the application waits to consume a response.
Let's try to understand the functioning of publish consume operation by a demo for which we will create mule flows as shown in the below image:
First flow JMS-flow1 has an HTTP listener, we receive the message by triggering the HTTP endpoint, then we log it using a logger, then we are using JMS Publish Consume operation and in the end, we are using a logger to log the correlation_ID of the consumed message.
By looking closely at the configuration of the publish consume in the below image, we can find that the destination is set to testQueue1 and Request-Reply Pattern is set to CORRELATION_ID. For the Reply-To field, we select Edit Inline and set the destination Name as testQueue2 and destination type as Queue. In other words, testQueue1 is the Requestor Queue and testQueue2 is the Response Queue.
JMS-flow2 has a JMS On New Message Listener and listening to the queue testQueue1 (where the message is published by publish consume operation of JMS-Flow1). Next, we have a logger which is used to print the received message.
In the below image we can see that in the On New message configuration Request Reply pattern is set as CORRELATION_ID:
So, when we hit the HTTP endpoint URL, flow JMS-Flow1 receives the message and logs it, then publish consume operation publishes the message into the queue (testQueue1) and waits. As soon as the message gets published into the queue, the On New Message listener (JMS-Flow2) will pick up the message and processes it. Once this is done the publish consume operation resumes and continues the flow JMS-Flow1.
Here, after publishing a message to the destination queue (testQueue1), the Publish Consume operation consumes a message from Response Queue (testQueue2) using a selector that expects a message with the same correlation ID that was used to publish the request message.
We can see there are no messages in both the queues before running the request.
The request triggered by the postman is shown below.
When the request is triggered from the postman, JMS-Flow1 starts, and as we set a breakpoint at Publish Consume Operation. We can see that message is received and there is a correlation ID associate with it. The publish-Consume will publish the message to the requestor queue testQueue1. And after that, the control immediately passed to JMS-Flow2.
As the On New Listener of JMS-Flow2 is listening to the Requestor Queue (testQueue1) continuously for a new message, it will immediately pick the message published by Publish Consume operation of JMS-Flow1. We can see that it is the same message by looking at the payload and the Correlation_ID. As soon as the processing of the JMS-Flow2 was completed the control moved back to publish consume operation of JMS-Flow1.
Once the control is moved to JMS-Flow1, the publish-consume operation consumes the message from the response Queue testQueue2 and we can see that the Correlation-ID is the same. And the processing ends here.
We can see that Correlation_ID is the same across the whole processing. We can verify all these details by looking at the below logs:
INFO 2021-07-21 20:28:48,205 [[MuleRuntime].uber.06: [jms-demo].jms-Flow1.CPU_LITE @7c71e8cc] [processor: jms-Flow1/processors/0; event: 2e899bf0-d2a1-11eb-b894-c8b29becab99] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: Received Message is : { "message": "This is a demo" } INFO 2021-07-21 20:29:41,909 [[MuleRuntime].uber.02: [jms-demo].jms-Flow2.CPU_LITE @167b2ab6] [processor: jms-Flow2/processors/0; event: 2e899bf0-d2a1-11eb-b894-c8b29becab99] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: Message Received is : { "message": "This is a demo" } INFO 2021-07-21 20:30:01,819 [[MuleRuntime].uber.06: [jms-demo].jms-Flow1.CPU_LITE @7c71e8cc] [processor: jms-Flow1/processors/2; event: 2e899bf0-d2a1-11eb-b894-c8b29becab99] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: Publish Consume Flow Done for Correlation ID : 2e899bf0-d2a1-11eb-b894-c8b29becab99 |
On the ActiveMQ console, by looking at the Messages Dequeued column we can confirm that both the queues have successfully delivered 1 message.
This is how we can use JMS publish-consume operation to perform the Request-Response pattern in Mulesoft.
Opinions expressed by DZone contributors are their own.
Comments