Contact Us 1-800-596-4880


Sometimes referred to as "wrappers", the message processors known as Scopes appear as processing blocks when you first place them on the Message Flow canvas. Certain scopes such as, Poll, Message Enricher, and Until Successful require you to embed only one message processor within the processing block. Variously, these scopes add functionality to the embedded message processor by:

  • Triggering the message processor periodically

  • Enhancing the message processor’s payload

  • Triggering the message processor until an associated event succeeds

Typically, the other sub-group of scopes (which includes Composite, Async, and Sub Flow) accepts more than one message processor.


In the case of Composite, the embedded processors are actually message sources, also known as inbound connectors that listen in parallel on different channels for incoming messages. Whenever any of these receivers accepts a message, the Composite scope passes it to the first message processor in the flow, thus triggering that flow.

For the Async and Sub Flow scopes, the embedded message processors form a single, combined message processor (or event) sequence.

Synchronous means that processing on the main flow halts, and all the message processors in the child flow execute before the parent flow resumes processing; in other words, no processing takes place in the parent flow while the synchronous child flow is executing.

Asynchronous means that as soon as the child flow receives a message, it immediately sends one copy of that message to the next message processor in the parent flow so that processing in the parent flow continues, essentially uninterrupted. The asynchronous child flow also starts processing another copy of the message with its own sequence of message processors. These two simultaneous processing branches continue independently until each completes.

The Async scope sits in the parent flow sequence, and when it receives a message, it sends a copy of the message on to the next message processor in the parent flow, while simultaneously (and asynchronously) processing another copy of the message through its own sequence of embedded message processors.

The Sub Flow scope exists as a synchronous branch flow with respect to the parent flow. After it receives a message from a Flow Reference component, it processes that message through the entire sequence of embedded message processors, then passes the message back to the next message processor in the parent flow for further processing. This process repeats each time a Flow Reference component in the main flow "calls" the Sub Flow processing block.

Code Example

The following code shows the use of a composite source for FTP and HTTP, and the use of an Async scope containing a Java transformer and a Logger.

<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns:http="" xmlns:ftp="" xmlns="" xmlns:doc=""
    <http:listener-config name="HTTP_Listener_Configuration" host="localhost" port="8081" doc:name="HTTP Listener Configuration"/>
    <flow name="scope-Flow">
        <composite-source doc:name="Composite Source">
            <ftp:inbound-endpoint host="localhost" port="21" responseTimeout="10000" doc:name="FTP"/>
            <http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP"/>
        <async doc:name="Async">
            <custom-transformer class="myclass" doc:name="Java"/>
            <logger level="INFO" doc:name="Logger"/>

Scopes Available in Studio

Scope Description

async icon


Creates a block of message processors that execute asynchronously while the rest of the flow continues to execute in parallel. For instance, you can populate an Async scope with a sequence of processors that perform logging so that logging does not slow down the rest of the application flow.

For specific information on configuring the Async Scope, see the Async Scope Reference page.

cache icon


Caches data produced by part of a flow. Wrap a cache scope around message processors in your flow so that it caches the response events produced within the scope. For specific information on configuring the Cache Scope, see the Cache Scope page.

composite source icon

Composite Source

To accept incoming messages from multiple input channels, place two or more message sources (also known as receivers) into a Composite Source. A message entering the Composite Source on any supported channel triggers the processing flow.

foreach icon


Splits any type of message collection apart into individual messages for processing, and then aggregate them again at the end of the scope. For specific information on configuring the Foreach Scope, see the Foreach Scope page.

message enricher icon

Message Enricher

Appends information to a message, often using an expression to determine what part of the payload to evaluate so as to return an appropriate value to append to that payload. For example, the expression can evaluate a ZIP code and then append the associated City and State to the payload. The message processor is executed and the enricher scope uses the result of that execution to enrich the message coming into the scope.

poll icon


Periodically polls an embedded message receiver for new messages. For example, set a Poll to retrieve email at regular intervals by placing a request-response connector such as SMTP within the Poll processing block.

sub flow icon

Sub Flow

A flow that is called by another flow. Sub flows inherit their properties from the flow reference and are always synchronous. This type of scope can be very useful when you need to reuse code at several points within the same flow. Simply place (and configure) Flow Reference Components wherever you want the sub flow processing block to execute.

transactional icon


Mule applies the concept of transactions to operations in application for which the result cannot remain indeterminate. In other words, where a series of steps in flow must succeed or fail as one unit, Mule uses a transaction to demarcate such a unit.

until successful icon

Until Successful

Attempts, at a specified interval, to route a message to an embedded message processor until one of the following occurs:

  • The message processor succeeds

  • The maximum number of retries is reached

  • An exception is thrown

Thus, Until Successful can prove useful in sending messages to resources, such as shared printers, which might not always be immediately available.