The Ultimate Guide to Async Scope in Mule 4

This is an absolute beginner’s guide to Async Scope in Mule 4.

Asynchronous processing is a crucial aspect of modern application development, allowing you to improve performance and scalability by executing tasks concurrently.

In Mule 4, the async scope enables you to execute parts of your Mule flows asynchronously, ensuring that your application remains responsive even during long-running operations.

This guide will cover the Async Scope definition, use case, and implementation with an example.

Prerequisites

Before you begin, ensure you have the following:

• Basic understanding of Mule 4 and Anypoint Studio.
• Anypoint Studio is installed on your machine.

Async Scope in Mule 4

The Async scope in Mule 4 allows you to execute message processors or components asynchronously, meaning that these operations will run in the background without blocking the main flow execution thread.

This is useful for handling long-running tasks such as making HTTP requests, database queries, or I/O-bound operations.

Here, uber.12 and uber.15 are threads used to process messages.

The main flow uses uber.12 to process the message, whereas the Async scope uses uber.15 to process the message asynchronously.

Threads are dynamic and will be allocated by MuleSoft. You don’t need to worry about allocating threads. Read Thread Management in Mule 4 to understand about threads.

Realtime Example

Let’s understand how Async scope works with the help of a restaurant analogy.

Imagine you’re running a restaurant where you take orders and prepare food. Sometimes, preparing certain dishes takes a long time, like cooking a steak or baking a cake. Meanwhile, you don’t want customers to wait for their orders to be taken just because one dish takes longer to cook.

In Mule 4, the async scope works similarly. It helps you handle tasks that take longer to complete without holding up the entire process.

We’ll break down this example later in the implementation section.

When to Use Async Scope

You should consider using async scope when:

• You have long-running tasks in your Mule flow that could block the main execution thread.
• You want to improve the performance and responsiveness of your application by executing tasks concurrently.
• You need to prevent a slow task from affecting the processing of other messages or requests.

Don’t use Async scope for logging purposes. You can make use of the Async Logger in Log4j.xml.

Limitations of Async Scope

While async scope in Mule 4 offers significant advantages regarding concurrency and performance improvement, it also has limitations. Knowing these limitations is important when designing and implementing your Mule applications.

• Resource Consumption: Async processing increases resource usage, potentially impacting system performance.
• Order of Execution: Messages may not be processed in the order they’re received.
• Complex Error Handling: Error handling can be more challenging due to asynchronous execution.
• Race Conditions: Concurrent execution may lead to data inconsistencies or race conditions.
• Limited Scalability: Async processing may not scale linearly with increasing workload.
• Debugging Complexity: Debugging asynchronous code can be more complex.
• Context Propagation: Context propagation may behave differently in async execution.
• Thread Management Overhead: Creating and managing threads adds overhead to the application.

There are a few other limitations in Developers’ point of view:

• Does not pass the response back to the main flow.
• A Flow Reference component does not call it.
• It is not reusable.
• Does not inherit the exception strategy of the main flow.

Implementing Async Scope in Mule 4

Here’s a beginner-friendly example using a restaurant analogy:

Suppose you have a restaurant with a simple flow:

1. Taking Orders: When customers come in, you take their orders.
2. Preparing Food: After taking orders, you prepare the food.
3. Serving Food: Finally, you serve the food to customers.

Now, let’s assume you have ten customers and two chefs. One customer ordered a steak while other customers ordered Hot dogs.

How do you handle these orders?

• The steak will be prepared by Chef 1
• Hot dogs will be prepared by Chef 2

With this, the other nine customers can be served with Hot dogs without waiting for steak to be prepared.

Here, Chef 1 is uber.12 thread, and Chef 2 is uber.15 thread.

<mule xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:flow="http://www.mulesoft.org/schema/mule/core"
    xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
        http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
        http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
        http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd">
    <http:listener-config name="HTTP_Listener_config" doc:name="HTTP Listener config" doc:id="a9a981f9-0e68-4ee3-9379-694a50edd610">
        <http:listener-connection host="0.0.0.0" port="8081"/>
    </http:listener-config>
    <flow name="restaurantFlow">
        <http:listener config-ref="HTTP_Listener_config" path="/order" allowedMethods="POST"/>
        <logger level="INFO" doc:name="Logger" doc:id="d12e95fa-e2de-4cde-bea7-9569cb152626" message="Order taken" />
        <choice doc:name="Choice" doc:id="87c62f05-aec1-4c74-bd39-719b23c1c611" >
            <when expression='#[payload.order == "steak"]'>
                <async doc:name="Async Scope" doc:id="fffab97d-4e24-45ae-9f10-8d20c8fa531e">
                    <logger level="INFO" doc:name="Logger" doc:id="804e7cb7-7dee-4395-b0aa-a62c84b48696" message="[Async] Cooking steak..." />
                    <logger level="INFO" doc:name="Logger" doc:id="82b5eda9-d06d-404f-af34-ed2737f0c9b5" message="[Async] Steak cooked" />
                    <set-payload value="Food served" doc:name="Set Payload" doc:id="8bb3ec80-140b-418e-ba3d-625d3f5597ca" />
                    <logger level="INFO" doc:name="Logger" doc:id="ab59f5f1-f1c7-425b-9dfb-784ce0147013" message="#[%dw 2.0
import * from dw::Runtime
output application/json
---
payload wait 20000]" />
        </async>
            </when>
            <otherwise >
                <logger level="INFO" doc:name="Logger" doc:id="74d414b6-6d11-499f-9318-44a86df1c0e9" message="Food served" />
                <set-payload value="Food served" doc:name="Set Payload" doc:id="a3ffc75b-50b6-4823-a355-bd391d8a1ade" />
            </otherwise>
        </choice>
    </flow>
</mule>

In this example,

• Taking Orders: When a customer makes an order (sends a POST request to /order), the flow starts by taking their order. This part is quick and straightforward.
• Preparing Food: After taking the order, the flow enters the “async scope”. Here, cooking the steak is marked with <async>, indicating that this task will be done asynchronously. This means the restaurant staff can start cooking the steak without waiting for other orders to be taken or served.
• Serving Food: Once the food is prepared, it moves on to serve the food to the customer. This happens after the steak is cooked but doesn’t wait for other orders to be taken or prepared.

Using async scope here ensures that while one long task (cooking steak) is being done, the flow can continue with other tasks (taking orders or serving food) without waiting for the steak to be cooked. This helps improve the overall efficiency of the restaurant.

Now, let’s run this application and understand how Async Scope works.

Using Postman Runner, I’m running two different requests to replicate the restaurant scenario. Where one customer orders steak and the other customer orders hot dogs.

Here, Steak orders took 1037 ms, and Hot dogs took 270 ms. Hence, the steak order doesn’t block the Hot dog order.

Now, let’s dig into Mule application logs.

Can you see the difference?

Here, uber.01 is the main flow thread which takes and processes all the orders and uber.03 is an async scope thread that processes only steak orders.

All the orders are handled by uber.01 (Chef 2), however, whenever the order is steak, it will hand over the order to uber.03 (Chef 1).

The first customer ordered steak, and Chef 1 (uber.03) started preparing the order. Meanwhile, the second customer ordered hot dogs, Chef 2 (uber.01) prepared the order and served it to the customer while Chef 1 prepared the steak order.

Chef 1 and Chef 2 are just examples. However, there might be 100 chefs, and the restaurant owner(Mule) will decide which Chef to assign to prepare steak depending on his/her availability.

Likewise, Mule will take care of assigning threads to perform different tasks.

Using async scope here ensures that while one long task (cooking steak) is being done, the flow can continue with other tasks (taking orders or serving food) without waiting for the steak to be cooked. This helps improve the overall efficiency of the restaurant.

Conclusion

In this tutorial, you learned about the Async scope in Mule 4 and how it enables asynchronous processing in your Mule applications.

By leveraging Async scope, you can improve the performance and responsiveness of your applications, especially when dealing with long-running tasks. Experiment with Async scope in your Mule projects and explore its benefits further!