Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.4)
  3. Developing
  4. Routers

  5. Splitter Flow Control Reference

Splitter Flow Control Reference

The Splitter Flow Control splits a message into separate fragments, then sends these fragments one at a time to the next message processor in the flow. Segments are identified based on an expression parameter, usually written in Mule Expression Language (MEL), but other formats can be employed also. You can then use a Collection Aggregator Flow Control to reassemble the parts of the original message. You can also include a Resequencer Flow Control to put the parts back into the original sequence in case they are shuffled out of order.

Splitting and aggregating the message is especially useful when you intend to process the splitted parts in asynchronous flows running on separate servers. Together, the splitter and aggregator flow controls allow you to share the workload among several servers and still be able to reassemble the message after it’s processed.

Splitter Configuration

STUDIO Visual Editor

Studio_splitter
Field Description Default Value Example XML

Display Name

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

Splitter

doc:name="Splitter"

Enable Correlation

Specifies whether Mule should give outgoing messages a correlation ID. Options are:

  • IF_NOT_SET (existing correlation IDs are maintained)

  • ALWAYS (existing correlation IDs are overridden)

  • NEVER (no action)

IF_NOT_SET

enableCorrelation="IF_NOT_SET"

Message Info Mapping

Optional. If this child element is not configured, MuleMessage.getCorrelationId() is used, which is optimal for most use cases. Maps attributes from incoming data to construct Correlation ID and Message ID on outgoing messages.

<expression-message-info-mapping messageIdExpression=""[java.util.UUID.randomUUID().toString()]``" `correlationIdExpression="[xpath('//order/@id')]"/>`

Expression

Expression to define how to split the message. This is a required field.

expression="#[xpath('//item')]"

XML Editor or Standalone

A Simple Splitter

<splitter expression="#[xpath('//item')]" doc:name="Splitter" enableCorrelation="IF_NOT_SET"/>
Element Description

splitter

Splits a message into separate fragments, then sends these fragments one at a time to the next message processor in the flow.
Attribute Description

doc:name

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

Note: Attribute not required in Mule Standalone configuration.

expression

Expression to define how to split the message. This is a required field.

enableCorrelation

Specifies whether Mule should give outgoing messages a correlation ID. Options are:

  • IF_NOT_SET (Default. Existing correlation IDs are maintained)

  • ALWAYS (Existing correlation IDs are overridden)

  • NEVER (No action)

An Advanced Splitter Including a Child Element

Note that this example includes the optional child element, expression-message-info-mapping. Use this child element only if your aggregation (later in your flow) is extremely customized and the standard correlation id set by Mule does not meet your needs. 
<splitter expression="#[xpath('//item')]" doc:name="Splitter" enableCorrelation="IF_NOT_SET">
            <expression-message-info-mapping messageIdExpression="#[java.util.UUID.randomUUID().toString()]" correlationIdExpression="#[xpath('//order/@id')]"/>
</splitter>
Child Element Description

expression-message-info-mapping

Optional. If this child element is not configured, MuleMessage.getCorrelationId() is used, which is optimal for most use cases. Maps attributes from incoming data to construct Correlation ID and Message ID on outgoing messages, according to the expressions in the attributes listed below.
Attribute Description

messageIdExpression

An expression that sets a custom message ID for each of the split messages. Must result in unique message Ids.

correlationIdExpression

An expression that sets a custom correlation ID for the split messages.

Basic Splitting Example

In this simple example, we’ll take an XML input and use the splitter to split it into several messages.

STUDIO Visual Editor

  1. Create a new Mule Studio project and drag an HTTP endpoint onto an empty canvas.

    Studio-splitterflow0

  2. Keep the default configurations on the HTTP endpoint, so that it listens on localhost:8081.

  3. Drag a Splitter Flow Control into the flow, to receive messages from the HTTP endpoint.

    Studio-splitterflow1

  4. Configure the Splitter as shown. In the Expression parameter, provide the XPath expression //actor, wrapped inside a MEL expression. This XPath expression selects every XML element named 'actor'. The splitter will make each of these (together with its children) into a new message.

    Splitter
    Parameter Value

    Display Name

    Splitter

    Enable Correlation

    IF_NOT_SET

    Expression

    #[xpath('//actor')]

  5. Add a Logger after the Splitter and set its message to #[message.payload] so that it logs the entire payload of each message that it receives.

    Studio-splitterflow

  6. Run the Mule project.

  7. You must now send the HTTP endpoint an HTTP request that includes a body with an attached XML file. You can use a browser extension such as Postman (Google Chrome), or the curl command line utility.

    Send a Post request to http://localhost:8081/ attaching XML to the body of the message. Sample XML is provided below.

    <root xmlns:foo="http://www.foo.org/" xmlns:bar="http://www.bar.org">
    <actors>
        <actor id="1">Christian Bale</actor>
        <actor id="2">Liam Neeson</actor>
        <actor id="3">Will Ferrell</actor>
    </actors>
    <foo:singers>
        <foo:singer id="4">Dave Grohl</foo:singer>
        <foo:singer id="5">B.B. King</foo:singer>
        <foo:singer id="6">Weird Al</foo:singer>
    </foo:singers>
</root>

    How to send the XML file as attachment with the curl utility

    Save the XML code provided above to a file on your local drive.

    Open a terminal and run the following command:

If everything worked well, you should see three messages logged into the console, one for every "actor" XML element.

XML Editor or Standalone

  1. Add an HTTP inbound endpoint into a new flow, and use the default values for its attributes.

    <http:inbound-endpoint exchange-pattern="request-response" host="localhost" port="8081" doc:name="HTTP"/>
    Attribute Value

    exchange-pattern

    request-response

    host

    localhost

    port

    8081

    doc:name

    HTTP

  2. Add a Splitter below, to receive messages from the HTTP endpoint. In the Expression parameter provide the XPath expression //actor , wrapped inside a MEL expression. This XPath expression selects every XML element named 'actor'. The splitter will make each of these (together with its children) into a new message.

    <splitter expression="#[xpath('//actor')]" doc:name="Splitter" enableCorrelation="IF_NOT_SET"/>
    Attribute Value

    expression

    #[xpath('//actor')]

    doc:name

    Splitter

    enableCorrelation

    IF_NOT_SET

  3. Include a logger after the splitter to log the entire payload of each message received.

    <logger message="#[message.payload]" level="INFO" doc:name="Logger"/>
    Attribute Value

    message

    #[message.payload]

    level

    INFO

    doc:name

    Logger

  4. The finished flow should look like this:

    <flow name="SplitterExampleFlow1" doc:name="SplitterExampleFlow1">
        <http:inbound-endpoint exchange-pattern="request-response" host="localhost" port="8081" doc:name="HTTP"/>
          <splitter expression="#[xpath('//actor')]" doc:name="Splitter" enableCorrelation="IF_NOT_SET"/>
        <logger message="#[message.payload]" level="INFO" doc:name="Logger"/>
    </flow>

  5. Run the Mule project

  6. You must now send the HTTP endpoint an HTTP request that includes a body with an attached XML file. MuleSoft recommends using a browser extension such as Postman (Google Chrome).
    Send a Post request to http://localhost:8081/ attaching an XML to the body of the message. Sample XML is provided below.

    <root xmlns:foo="http://www.foo.org/" xmlns:bar="http://www.bar.org">
    <actors>
        <actor id="1">Christian Bale</actor>
        <actor id="2">Liam Neeson</actor>
        <actor id="3">Will Ferrell</actor>
    </actors>
    <foo:singers>
        <foo:singer id="4">Dave Grohl</foo:singer>
        <foo:singer id="5">B.B. King</foo:singer>
        <foo:singer id="6">Weird Al</foo:singer>
    </foo:singers>
</root>

If everything worked well, you should see three messages logged into the console, one for every "actor" XML element.

Full Example Code

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

<mule xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
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">

    <flow name="SplitterExampleFlow1" doc:name="SplitterExampleFlow1">
        <http:inbound-endpoint exchange-pattern="request-response" host="localhost" port="8081" doc:name="HTTP"/>
        <splitter expression="#[xpath('//actor')]" doc:name="Splitter"/>
        <logger message="#[message.payload]" level="INFO" doc:name="Logger"/>
    </flow>
</mule>

Aggregating the Payload

When the splitter splits a message, it adds three new outbound variables into each of the output fragments. These three variables are later used by the Aggregator to reassemble the message:

  • MULE_CORRELATION_GROUP_SIZE: number of fragments into which the original message was split

  • MULE_CORRELATION_SEQUENCE: position of a fragment within the group

  • MULE_CORRELATION_ID: single ID for entire group (all output fragments of the same original message share the same value)

    variables+diagramv2

You can look at the values of these outbound variables by putting a break point after the splitter and running your flow with the Studio Visual Debugger:

variables

Thanks to these variables, when an aggregator receives a single fragment, it knows what group to put it into and how large this group should be. Once all of the fragments have arrived, it passes on the complete group as a single message.

diagram+ag+2

Aggregator Configuration

Studio Visual Editor

aggregator
Field Description Default Value Example XML

Display Name

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

Collection Aggregator

doc:name="Collection Aggregator"

Timeout

Defines a timeout in milliseconds to wait for events to be aggregated. By default the aggregator will throw an exception if it is waiting for a correlation group and a timeout occurs before it receives all group entities.

timeout="60000"

Fail On Timeout

If set, your app will fail if the aggregator times out.

false

failOnTimeout="true"

Message Info Mapping

Optional. If this child element is not configured, MuleMessage.getCorrelationId() is used, which is optimal for most use cases. Defines where to obtain Correlation ID and Message ID in incoming messages.

<expression-message-info-mapping messageIdExpression=""[java.util.UUID.randomUUID().toString()]``" `correlationIdExpression="[xpath('//order/@id')]"/>

Store Prefix

Defines the prefix of the ObjectStore names

storePrefix="split_"

XML View

A Simple Collection Aggregator

<collection-aggregator failOnTimeout="true" doc:name="Collection Aggregator" storePrefix="split_" timeout="60000"/>
Element Description

collection-aggregator

Reassembles a message from separate fragments. Once all fragments have arrived it sends the full message to the next message processor in the flow.
Attribute Description

doc:name

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

Note: Attribute not required in Mule Standalone configuration.

Timeout

Defines a timeout in milliseconds to wait for events to be aggregated. By default the aggregator will throw an exception if it is waiting for a correlation group and a timeout occurs before it receives all group entities.

Fail On Timeout

If set, your app will fail if the aggregator times out.

Message Info Mapping

Optional. If this child element is not configured, MuleMessage.getCorrelationId() is used, which is optimal for most use cases. Defines where to obtain Correlation ID and Message ID in incoming messages.

Store Prefix

Defines the prefix of the ObjectStore names

An Advanced Collection Aggregator Including a Child Element

Note that this example includes the optional child element, expression-message-info-mapping. Use this child element only if your aggregation (later in your flow) is extremely customized and the standard correlation ID set by Mule does not meet your needs. 
<collection-aggregator failOnTimeout="true" doc:name="Collection Aggregator" storePrefix="split_" timeout="60000">
            <expression-message-info-mapping messageIdExpression="#[java.util.UUID.randomUUID().toString()]" correlationIdExpression="#[xpath('//order/@id')]"/>
</collection-aggregator>
Child Element Description

expression-message-info-mapping

Optional. If this child element is not configured, MuleMessage.getCorrelationId() is used, which is optimal for most use cases. Maps attributes of the arriving messages to messageIdExpression and correlationIdExpression.
Attribute Description

messageIdExpression

An expression that maps attributes of the arriving messages to messageIdExpression. Must result in unique message IDs.

correlationIdExpression

An expression that maps attributes of the arriving messages to correlationIdExpression. Must result in unique message IDs.

Advanced Example 1: Splitting and Aggregating with Asynchronous Flows

This example builds upon the basic example above. Follow the steps below to run message fragments in asynchronous flows and then aggregate them back into a single message.

Studio Visual Editor

  1. Drag a VM endpoint to the end of the flow.

    advanced1

  2. Drag a second VM endpoint outside the existing flow, below it. This will create a new flow.

    vm2

  3. Drag the existing logger you had in the first flow to the new second flow, after the VM endpoint.

    vm3

  4. Configure the two VM endpoints. Change both their Queue Path to step2.

    vm4

    Once both VMs have the same Queue Path configured, they will be linked. Messages that arrive to the first VM will continue their path out of the second VM. What you have at this point appears to work identically to what you built in the first example. There is, however, one key difference: each fraction of the message will be processed simultaneously rather than in sequence. If you deploy your app to a cluster of servers this will have a big effect on performance.

  5. Make the initial HTTP endpoint one-way, as there are no useful messages being returned

    http

  6. Add a Collection aggregator in the second flow, after the Logger.

    agg3

  7. Add one more logger after the Collection aggregator, to see how the final message is output.

    agg4

  8. Run the Mule project.

  9. You must now send the HTTP endpoint an HTTP request that includes a body with an attached XML file.
    Send a Post request to http://localhost:8081/ attaching XML to the body of the message. Sample XML is provided below.

    The easiest way to do this is sending posts via a browser extension such as Postman (for Google Chrome) or the curl command line utility. 
    <root xmlns:foo="http://www.foo.org/" xmlns:bar="http://www.bar.org">
    <actors>
        <actor id="1">Christian Bale</actor>
        <actor id="2">Liam Neeson</actor>
        <actor id="3">Will Ferrell</actor>
    </actors>
    <foo:singers>
        <foo:singer id="4">Dave Grohl</foo:singer>
        <foo:singer id="5">B.B. King</foo:singer>
        <foo:singer id="6">Weird Al</foo:singer>
    </foo:singers>
</root>

You should see four messages logged into the console: the first three should be short, one for every "actor" XML element (notice the ID attribute in each message). After these first three messages there should be a fourth, longer message, which is logged after the aggregator has run. Notice two things:

  • Although the aggregator was triggered three times, once for every fraction of the message that reached it, it produced one single output message, only when all of the fractions were in place

  • The aggregator assembles the message in the order in which fractions have arrived; the final message may be shuffled. If maintaining the original sequence is important to you, take a look at the Advanced Example 2 in this page

XML Editor

  1. Add a second flow to your project.

    <flow name="splitterFlow1" doc:name="splitterFlow1">
     <http:inbound-endpoint exchange-pattern="one-way" host="localhost" port="8082" doc:name="HTTP"/>
     <splitter expression="#[xpath('//actor')]" doc:name="Splitter"/>
     <logger level="INFO" doc:name="Logger" message="#[payload]"/>
</flow>

<flow name="splitterFlow2" doc:name="splitterFlow2">

</flow>

    1. Remove the logger in the first flow, add an identical one inside the second flow.

      <flow name="splitterFlow1" doc:name="splitterFlow1">
     <http:inbound-endpoint exchange-pattern="one-way" host="localhost" port="8082" doc:name="HTTP"/>
     <splitter expression="#[xpath('//actor')]" doc:name="Splitter"/>

</flow>

<flow name="splitterFlow2" doc:name="splitterFlow2">
     <logger level="INFO" doc:name="Logger" message="#[payload]"/>
</flow>

  2. Link both flows through a couple of VM endpoints, an outbound endpoint in the first flow and an inbound endpoint in the second flow.

    <flow name="splitterFlow1" doc:name="splitterFlow1">
     <http:inbound-endpoint exchange-pattern="one-way" host="localhost" port="8082" doc:name="HTTP"/>
     <splitter expression="#[xpath('//actor')]" doc:name="Splitter"/>

     <vm:outbound-endpoint exchange-pattern="one-way" path="step2" doc:name="VM"/>
</flow>

<flow name="splitterFlow2" doc:name="splitterFlow2">
    <vm:inbound-endpoint exchange-pattern="one-way" path="step2" doc:name="VM"/>
</flow>

    Provide these same attributes for both VM endpoints:

    Attribute Value

    exchange-pattern

    one-way

    path

    step2

    doc:name

    VM

    Once both VMs share the same Queue Path, they will be linked. Messages that arrive to the first VM will continue their path out of the second VM. What you have at this point appears to work identically to what you built in the first example. There is, however, one key difference: each fraction of the message will be processed simultaneously rather than in sequence. If you deploy your app to a cluster of servers this will have a big effect on performance.

  3. Add a Collection aggregator in the second flow, after the logger.

    <collection-aggregator failOnTimeout="false" doc:name="Collection Aggregator"/>
    Attribute Value

    failOnTimeout

    true

    doc:name

    Collection Aggregator

  4. Run the Mule project.

  5. You must now send the HTTP endpoint an HTTP request that includes a body with an attached XML file. Send a Post request to http://localhost:8081/ attaching XML to the body of the message. Sample XML is provided below.

    The easiest way to do this is sending posts via a browser extension such as Postman (for Google Chrome), or using the curl command-line utility. 
    <root xmlns:foo="http://www.foo.org/" xmlns:bar="http://www.bar.org">
    <actors>
        <actor id="1">Christian Bale</actor>
        <actor id="2">Liam Neeson</actor>
        <actor id="3">Will Ferrell</actor>
    </actors>
    <foo:singers>
        <foo:singer id="4">Dave Grohl</foo:singer>
        <foo:singer id="5">B.B. King</foo:singer>
        <foo:singer id="6">Weird Al</foo:singer>
    </foo:singers>
</root>

You should see four messages logged into the console: the first three should be short, one for every "actor" XML element (notice the ID attribute in each message). After these first three messages there should be a fourth, longer message, which is logged after the aggregator has run. Notice two things:

  • Although the aggregator was triggered three times, once for every fraction of the message that reached it, it produced one single output message, only when all of the fractions were in place

  • The aggregator assembles the message in the order in which fractions have arrived; the final message may be shuffled. If maintaining the original sequence is important to you, take a look at the Advanced Example 2 in this page

Full Example 1 Code

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

<mule xmlns:vm="http://www.mulesoft.org/schema/mule/vm" xmlns:scripting="http://www.mulesoft.org/schema/mule/scripting" xmlns:tracking="http://www.mulesoft.org/schema/mule/ee/tracking" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
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/tracking http://www.mulesoft.org/schema/mule/ee/tracking/current/mule-tracking-ee.xsd
http://www.mulesoft.org/schema/mule/scripting http://www.mulesoft.org/schema/mule/scripting/current/mule-scripting.xsd
http://www.mulesoft.org/schema/mule/vm http://www.mulesoft.org/schema/mule/vm/current/mule-vm.xsd">
    <flow name="splitterFlow1" doc:name="splitterFlow1">
        <http:inbound-endpoint exchange-pattern="one-way" host="localhost" port="8082" doc:name="HTTP"/>
        <splitter expression="#[xpath('//actor')]" doc:name="Splitter"/>
        <vm:outbound-endpoint exchange-pattern="one-way" path="step2" doc:name="VM"/>
    </flow>
    <flow name="splitterFlow2" doc:name="splitterFlow2">
        <vm:inbound-endpoint exchange-pattern="one-way" path="step2" doc:name="VM"/>
        <logger level="INFO" doc:name="Logger" message="#[payload]"/>
        <collection-aggregator failOnTimeout="true" doc:name="Collection Aggregator"/>
    </flow>
</mule>

Advanced Example 2: Reordering Before Aggregating

This example builds upon the previous example.

If fractions of the message are being processed in parallel in different servers, there’s a good chance that they may take different lengths of time to be processed, and consequently fall out of order. The following example solves that problem.

Follow the steps below to:

  • run message fragments in asynchronous flows

  • arrange them back into the original sequence

  • aggregate them back into a single message that follows the original sequence

Studio Visual Editor

  1. Add a Resequencer Flow Control before the aggregator

    resequencer

    The Resequencer will wait for all of the messages in the group to arrive (keeping track of MULE_CORRELATION_ID and MULE_CORRELATION_GROUP_SIZE ) and then reorder them according to their MULE_CORRELATION_SEQUENCE index.

    The Resequencer will output three distinct messages, so the Aggregator is still needed to merge them into one.

  2. Run the Mule project.

  3. You must now send the HTTP endpoint an HTTP request that includes a body with an attached XML file. Send a Post request to http://localhost:8081/ attaching XML to the body of the message. Sample XML is provided below.

    The easiest way to do this is sending posts via a browser extension such as Postman (for Google Chrome), or the curl command-line utility. 
    <root xmlns:foo="http://www.foo.org/" xmlns:bar="http://www.bar.org">
    <actors>
        <actor id="1">Christian Bale</actor>
        <actor id="2">Liam Neeson</actor>
        <actor id="3">Will Ferrell</actor>
    </actors>
    <foo:singers>
        <foo:singer id="4">Dave Grohl</foo:singer>
        <foo:singer id="5">B.B. King</foo:singer>
        <foo:singer id="6">Weird Al</foo:singer>
    </foo:singers>
</root>

With the Resequencer in place, messages now reach the aggregator in the correct order and are assembled accordingly.

XML Editor

  1. Add a Resequencer Flow Control before the aggregator.

    <resequencer failOnTimeout="true" doc:name="Resequencer"/>
    Attribute Value

    failOnTimeout

    true

    doc:name

    Resequencer

    The Resequencer will wait for all of the messages in the group to arrive (keeping track of MULE_CORRELATION_ID and MULE_CORRELATION_GROUP_SIZE ) and then reorder them according to their MULE_CORRELATION_SEQUENCE index.

    The Resequencer will output three distinct messages, so the Aggregator is still needed to merge them into one.

  2. Run the Mule project.

  3. You must now send the HTTP endpoint an HTTP request that includes a body with an attached XML file. Send a Post request to http://localhost:8081/ attaching XML to the body of the message. Sample XML is provided below.

    The easiest way to do this is sending posts via a browser extension such as Postman (for Google Chrome) or the curl command-line utility. 
    <root xmlns:foo="http://www.foo.org/" xmlns:bar="http://www.bar.org">
    <actors>
        <actor id="1">Christian Bale</actor>
        <actor id="2">Liam Neeson</actor>
        <actor id="3">Will Ferrell</actor>
    </actors>
    <foo:singers>
        <foo:singer id="4">Dave Grohl</foo:singer>
        <foo:singer id="5">B.B. King</foo:singer>
        <foo:singer id="6">Weird Al</foo:singer>
    </foo:singers>
</root>

With the Resequencer in place, messages now reach the aggregator in the correct order and are assembled accordingly.

Full Example 2 Code

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

<mule xmlns:vm="http://www.mulesoft.org/schema/mule/vm" xmlns:scripting="http://www.mulesoft.org/schema/mule/scripting" xmlns:tracking="http://www.mulesoft.org/schema/mule/ee/tracking" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
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/tracking http://www.mulesoft.org/schema/mule/ee/tracking/current/mule-tracking-ee.xsd
http://www.mulesoft.org/schema/mule/scripting http://www.mulesoft.org/schema/mule/scripting/current/mule-scripting.xsd
http://www.mulesoft.org/schema/mule/vm http://www.mulesoft.org/schema/mule/vm/current/mule-vm.xsd">
    <flow name="splitterFlow1" doc:name="splitterFlow1">
        <http:inbound-endpoint exchange-pattern="one-way" host="localhost" port="8082" doc:name="HTTP"/>
        <splitter expression="#[xpath('//actor')]" doc:name="Splitter"/>
        <vm:outbound-endpoint exchange-pattern="one-way" path="step2" doc:name="VM"/>
    </flow>
    <flow name="splitterFlow2" doc:name="splitterFlow2">
        <vm:inbound-endpoint exchange-pattern="one-way" path="step2" doc:name="VM"/>
        <logger level="INFO" doc:name="Logger" message="#[payload]"/>
        <resequencer failOnTimeout="true" doc:name="Resequencer"/>
        <logger message="#[payload]" level="INFO" doc:name="Logger"/>
        <collection-aggregator failOnTimeout="true" doc:name="Collection Aggregator"/>
        <logger message="#[payload]" level="INFO" doc:name="Logger"/>
    </flow>
</mule>

See Also