Access Keys:
Skip to content (Access Key - 0)
Cancel    
Cancel   
 

Async Scope Reference

Jul 01, 2013 11:42

Janet Revell

May 01, 2014 13:07

Mulesoft Current Mule Documentation

Async Scope Reference

Mulesoft Documentation Page

Contents

Async Scope Reference

An async scope is a branch processing block 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 sending a response back to the initiating flow. In other words, the main flow can continue execution while it initiates and processes 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).

Since they operate on a copy of the message on a different 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.

If no processing strategy is configured for the async scope, Mule applies a queued-asynchronous processing strategy.

 Contents

Skip to the code

 

Async Scopes versus Asychronous Flows

An async scope is similar to an asynchronous flow in that:

  • it processes the message asynchronously with the main flow, so the message is simultaneously processed in the async scope without pausing the processing in the main flow thread
  • does not pass data from the scope back into the main flow thread
  • it can have its own processing strategy

However, unlike an asynchronous flow, an async scope:

  • exists in-line with the main flow thread
  • is not called by a flow reference component
  • is not re-usable
  • cannot have its own exception handling strategy – it inherits this from the flow in which it resides

Async Scopes versus Subflows

An async scope is similar to a subflow in that it inherits the exception strategy of the main flow. 

However, unlike a subflow, an async scope:

  • processes messages asynchronously
  • does not pass data back to the main flow
  • exists in-line with the main flow thread
  • is not called by a flow reference component
  • is not re-usable

Even though the Async scope receives a copy of the Mule message, the payload is not copied. The same payload object(s) will be referenced by both Mule messages: the one that continues down the original flow and the one processed by the Async scope.

In other words, if the payload of your message is a mutable object (for example a bean with different fields in it) and a message processor in your async scope changes the value of one of the fields, the message processors outside of the Async scope will see the changed values.

 

 

Configuration

    1. Drag the async scope to the canvas and position it within the sequence of message processors that make up your flow at the point where you want to initiate an asynchronous processing block.



    2. Within the scope area, add and configure the sequence of message processors that you want to execute asynchronously with the main flow. See example below.



    3. Optionally, configure the async scope itself with a Display Name. If you wish to specify a Processing Strategy, see the instructions in the next section.



    1. Add an async element to your flow at the point where you want to initiate an asynchronous processing block. Refer to the code sample below.
    2. Configure the scope according to the tables below.

      ElementDescription
      asyncUse to create a block of message processors that execute asynchronously while the rest of the flow continues to execute in parallel.
      AttributeDescription
      doc:name

      Customize to display a unique name for the async scope in your application.

      Note: Attribute not required in Mule Standalone configuration.


    3. Configure one or more child elements within the async scope to define the processing that should occur within the asynchronous processing block. Refer to code sample below. If you wish to specify a Processing Strategy, see the instructions in the next section.

      Child ElementDescription
      processingStrategy Optional. Specify the name of a processing strategy that you have defined as a global element.


     

    Configuring a Processing Strategy

    Configuring a processing strategy is optional. Unless you explicitly define a different one, Mule will apply the queued-asynchronous processing strategy to the scope. You can configure the Processing Strategy of the async scope to one of the following available processing strategies.

    Strategy

    Description

    Asynchronous Processing Strategy

    Same as queued-asynchronous processing strategy (which is what Mule applies if no other processing strategy is configured) except that it doesn't use a queue. Use this only if for some reason you do not want your processing to be distributed across nodes.

    Custom Processing Strategy

    A user-written processor strategy.

    Queued-Asynchronous Processing Strategy

    Uses a queue to decouple the flow's receiver from the rest of the steps in the flow. It works the same way in a scope as in a flow. Mule applies this strategy unless another is specified. Select this if you want to fine-tune this processing strategy by:

    • Changing the number of threads available to the flow.
    • Limiting the number of messages that can be queued.
    • Specifying a queue store to persist data.

    Queued Thread Per Processor Processing Strategy

    Not applicable to most use cases. Writes messages to a queue, then every processor in the scope runs sequentially in a different thread.

    Thread Per Processor Processor Strategy

    Not applicable to most use cases. Every processor in the scope runs sequentially in a different thread.

    For more information about processing strategies, see Flow Processing Strategies.

     

      1. Click the (plus) to the right of the Processing Strategy field. 

      2. In the Choose Global Type window, select from the list of available processing strategies, then click OK



      3. Configure the processing strategy as needed. For more information, see Flow Processing Strategies.

      1. Define your processing strategy as a global element, with any necessary configuration or optional fine-tuning. (For more information, see Flow Processing Strategies.) Refer to code sample below.
      2. Add a processingStrategy attribute to your async element to specify the processing strategy by name, as in the code sample.

       

      Complete Example Code

       View the namespace

       

      Go Further