Back to Blog Archive

Request-Reply trick! async to sync process

Posted on: December 18, 2017

In this article we show how to use the request-reply component to collect data from an asynchronous reply.


While working with APIs based on HTTP Restful services, the common pattern is to send a request and get a reply.

At the end, this is what we are looking for.

But, what would happen if suddenly this is not the scenario that we have to implement. What would happen if the information that we are expecting to receive is coming in an asynchronous reply and we need part of the data of this response to be sent in our original request?

Let me give you an example:

1)  The client makes an HTTP request to the Service A

2) Service A then forwards this request to a Service B (more like a notification), service B sends the acknowledgement (from now on I will call this “Ack”) back to Service A.

3)  Service A needs to wait for the right data from Service B.

4) After few seconds, Service B is sending the information to Service A via an HTTP request. Maybe this could happen because Service B has a async queue method of processing the orders.


I know what you are thinking; ‘Why does Service B behave like this and is not sending the information right away?’

While this pattern is not common… what if one day you encounter this situation?

This post provides instructions for implementing this use case!

What are the difficulties?

As you may notice, we have few challenges:

  • How to wait after we receive the Ack from Service B until we get the right data in step 3?
  • How to match or correlate the original message waiting by the client with the correct async answer of Service B. We need to provide the right data to the right client.

To solve these issues we are going to make use of the Request-Reply component and an object store!

Let’s get our hands dirty

Download the full project by clicking here

To begin with, let’s add the flows for the Service A and Service B:

In the first flow, we just have the listener for the service A. A variable to store the TransactionID and the request-reply component.

In the rest of the flows, we are just trying to replicate another listener for the Service B:

NOTE: Notice how the ACK of the Service B will return a message “Order Received!”

According to Mulesoft documentation

The Request-Reply scope enables you to embed a “pocket” of asynchronous processing within a Mule flow.  This functionality enables you to receive a response from an asynchronous flow without hardcoding the destination of the response.

We are going to use VM queues to store and receive transactions.

First, let’s see the store transaction flow:

Note that this is a simple VM inbound storing the TransactionID as a key in the object store and the MULE_CORRELATION_ID (this is a default property added when using the components above) as value.

For the reply flow:

In essence, this flow just retrieves the TransactionID from the response and then triggers the flow that is going to resume the original request.

Let’s have a look in the resume flow!

After receiving the real data from service B, the resume flow obtains the MULE_CORRELATION_ID  for a waiting TransactionID from the object store.

Now that we know exactly the ID of the Mule Message, we can resume the original message by sending this info to the ‘VM reply’ queue. This is the queue listener inside the request-reply block.

At this point, let’s run the application and make a request:

curl -H "TransactionID:1234" -s -w "\n" localhost:8190/serviceA

Wow, what happened?! Our Request-Reply didn’t wait for the reply of Service B that should come via the VM reply queue.

As a result, the flow ended and we received the result of the Ack from Service B, not the real data…   🙁

The Trick

Let’s solve this issue. Here is the trick to solve this scenario!

We need to add the below code inside the Request-Reply block:

Here is the hack, by removing the ‘MULE_REPLYTO’ property, the original request-reply will avoid resuming the original flow.

Therefore, only a reply to the VM reply queue will continue the flow!

Now that we have all of this in place, if we make the same call again as above, notice how the call does not provide any response:

At this stage, to continue the process, we need to simulate the asynchronous reply from service B:

curl -H "TransactionID:1234" -H "Content-Type: application/json"-s -w "\n" localhost:8190/serviceBreply

Voila! Now we get the data as expected!

I hope you enjoyed this blog post, please leave comments.


4 Comments for “Request-Reply trick! async to sync process”

  1. Kelvin Njaci says:

    very nice article Mario. one question though. i have tried it out and my resume flow outbound VM can’t sent to the reply scope VM when i trace via debug i see it dies at the resume flow outbound VM. Why this behavior?

  2. Kelvin Njaci says:

    Yes Mario, the main flow is waiting on the vm reply. There’s no error in the console. debug gets to that vm outbound and the flow shows it has completed but does not transfer to the reply part of the Request-Reply. When i send the reply to a different vm connector it is being delivered to that vm.


Contact Us

Ricston Ltd.
Triq G.F. Agius De Soldanis,
Birkirkara, BKR 4850,
MT: +356 2133 4457
UK: +44 (0)2071935107

Send our experts a message

Need Help?
Ask our Experts!