Async Scope Reference
An Async scope is a branch processing flow that executes simultaneously with the parent message flow. This type of processing block can prove useful for executing time-consuming operations (such as printing a file or connecting to a mail server) — as long as those operations do not require a response to the main flow. In other words, the main flow can resume execution as soon as it has called the asynchronous scope; it does not have to pause until the last message processor embedded in the asynchronous flow has completed its task.
To facilitate this simultaneous branch processing, the Async scope sends one copy of the message it has received to the first embedded message processor in its own processing block; at the same time it sends another copy of the message to the next message processor in the main flow (See: below).
Unlike sub flows which execute synchronously with respect to the parent flow, Async scopes are not called by Flow Reference components.
Also in contrast to sub flows, which inherit the processing strategies and exception handling properties of their parent flow, an Async flow does not inherit either the processing strategy or the exception handling properties of its parent flow.
Since they immediately pass a copy of whatever message they receive to the next message processor in the parent flow, then process another copy of that message on a child thread, Async scopes cannot, by definition, support request-response exchange patterns. Instead, they must implement one of several supported one-way processing strategies, as detailed in the configuration section, below.
Async Scope Configuration
After you drag the Async scope to the Message Flow canvas and position it within the sequence of message processors that make up the parent flow, you must embed it with its own sequence of message processors. Next, you must configure each embedded message processor by double-clicking on the icon representing each message processor to open its Properties pane, then completing the configuration fields. Your final step is to configure the Async scope itself.
By default, the following icon appears in the upper left corner of the Async scope’s title bar: 
. Double-click anywhere on the title bar to open the Properties pane.
About the Display Name and Documentation
Although both the Display Name and Documentation fields are optional, they can prove very useful during the development and deployment processes, if you populate them with meaningful information.
For example, the Display Name is Async by default. You can change it to something relevant to your application context, such as “Log Incoming Messages to DB”. This string will appear under the Async flow icon on the Message Flow canvas as well as in the administrative and performance analysis displays on the Mule Management Console.
Similarly, the text you enter into the Documentation field can prove valuable to future developers and system administrators because it appears in a yellow help balloon that pops up when you hover your mouse over the Async flow icon on the Message Flow canvas.
About Async Processing Strategy
Although it is optional, you can configure the Processing Strategy field, which resides on the Generic panel of the General tab of the Scope Properties pane (See: below).
Selecting a Processing Strategy
Complete the following steps:
-
To open the Choose Global Type panel, click Add, which is to the right of the Processing Strategy field (See: below).
+ . Click *Processing Strategies* to highlight the icon and display the *drop down arrow* immediately to the right (See: *Below*). +
+ . Click the arrow so that the arrow tilts downward, and the list of available one-way processing strategies appears (See: *below*). +
The following table lists and describes the available asynchronous processing strategies:
| Strategy | Description |
|---|---|
Asynchronous Processing Strategy |
After the inbound endpoint finishes processing the message, the rest of the flow runs in another thread. |
Custom Processing Strategy |
A user-written processor strategy. |
Queued Asynchronous Processing Strategy |
After the inbound endpoint finishes processing the message, it writes that message to a SEDA queue. The rest of the flow runs in a thread form the SEDA queue’s thread pool. |
Queued Thread Per Processor Processing Strategy |
After the inbound endpoint finishes processing the message, it writes that message to a SEDA queue. From that point onward, every remaining processor in the flow runs sequentially in a different thread. |
Thread Per Processor Processor Strategy |
After the inbound endpoint finishes processing the message, every remaining processor in the flow runs sequentially in a different thread. |