---
schema_version: "1"
id: ff77ae5849385076b9a718a83af344a3e0f85ab16d3771c85c758e0723358e58
title: Parallel For Each Scope
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-runtime/4.6/parallel-foreach-scope.md
canonical_url: https://docs.mulesoft.com/mule-runtime/4.6/parallel-foreach-scope
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 0efc2d4f96a111da39663c67d0982c845b93f85d804e28f383627a3c1ab7c77f
description: MuleSoft Documentation Site
release: "4.6"
latest: false
---
---
product: Mule Runtime
version: 4.6
keywords: anypoint studio, studio, mule, split, aggregate, scope, parallel, for, each
---

# Parallel For Each Scope

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The Parallel For Each scope enables you to process a collection of messages by splitting the
collection into parts that are simultaneously processed in separate routes within the scope of any
limitation configured for concurrent-processing. After all messages are processed, the results are
aggregated following the same order they were in before the split, and then the flow continues.

## Considerations

- Parallel For Each buffers all processing routes' results in a list to return it after the scope
  finishes processing, which can cause out-of-memory errors when processing a high number of
  entries. To process large payloads, use [Batch Processing](https://docs.mulesoft.com/mule-runtime/4.6/batch-processing-concept) instead.

- Anypoint Studio versions prior to 7.6 do not provide this feature in the Mule Palette view. To use
  Parallel for Each in those versions, you must manually configure Parallel For Each scope in the
  XML.

## Configuration

The Parallel For Each scope can be configured through the following fields:

<table><colgroup><col> <col></colgroup><thead><tr><th>Child element</th><th>Description</th></tr></thead><tbody><tr><td><p>Collection (<code>collection</code>)</p></td><td><p>Specifies the expression that defines the collection of parts to be processed in parallel. By default, it uses the incoming payload.</p></td></tr></tbody></table>

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute</th><th>Description</th></tr></thead><tbody><tr><td><p>Collection Expression (<code>collection</code>)</p></td><td><p>An expression that returns a collection. By default, the payload is taken as the collection to split.</p></td></tr><tr><td><p>Timeout (<code>timeout</code>)</p></td><td><p>Specifies the timeout in milliseconds for each parallel route. By default, there is no timeout.</p></td></tr><tr><td><p>Max Concurrency (<code>maxConcurrency</code>)</p></td><td><p>Specifies the maximum level of parallelism for the router to use. By default, all routes run in parallel.</p></td></tr><tr><td><p>Target Variable (<code>target</code>)</p></td><td><p>Specifies a variable to use for storing the processed payload. By default, the output is saved in the flow’s payload.</p></td></tr><tr><td><p>Target Value (<code>targetValue</code>)</p></td><td><p>Specifies an expression to evaluate against the operation’s output value. The outcome of this expression is stored in the target variable. By default, this is the same as the operation’s output value.</p></td></tr></tbody></table>

## Example

This XML example adds to every element in the collection the string `"-result"`:

```xml
<flow name="myFlow">

  <parallel-foreach collection="#[['apple', 'banana', 'orange']]">
      <set-payload value="#[payload ++ '-result']"/>
  </parallel-foreach>

</flow>
```

Every execution of the Parallel For Each scope starts with the same variables and values as before
the execution of the block.

New variables or modifications of already existing variables while processing one element are not
visible while processing another element. All of those variable changes are not available outside
the Parallel For Each scope, the set of variables (and their values) after the execution of the
Parallel For Each Scope remains the same as before the execution.

Consider the following example:

```xml
<flow name="myFlow">

  <set-variable variableName="var1" value="var1"/>
  <set-variable variableName="var2" value="var2"/>
  <parallel-foreach collection="#[['apple', 'banana', 'orange']]">
      <choice>
          <when expression="#[payload == 'apple']">
              <set-variable variableName="var2" value="newValue"/>
              <set-variable variableName="var3" value="appleVal"/>
          </when>
          <when expression="#[payload == 'banana']">
              <set-variable variableName="var3" value="bananaVal"/>
          </when>
          <otherwise>
              <set-variable variableName="var3" value="otherVal"/>
              <set-variable variableName="var4" value="val4"/>
          </otherwise>
      </choice>
  </parallel-foreach>

</flow>
```

After aggregation, the variables are:

`{var1: "var1", var2: "var2"}`

None of the modifications done inside the Parallel For Each scope are registered, including the
creation of new variables.

## Error Handling

Because every route is processed in parallel, if an error is thrown in one route, processing
continues in all of the other routes until all finish processing. After that, all results (and any
errors) are aggregated and then processed by the [Error Handler](https://docs.mulesoft.com/mule-runtime/4.6/error-handling), as shown here:

```xml
<flow name="myFlow">

  <parallel-foreach collection="#[['banana', 'apple']]">
      <choice>
          <when expression="#[payload == 'banana']">
              <!-- Processor that throws error -->
          </when>
          <otherwise>
              <set-payload value="#[payload ++ '-result']"/>
          </otherwise>
      </choice>
  </parallel-foreach>
  <error-handler>
      <on-error-continue type="COMPOSITE_ROUTING">
          <!-- This will have the error thrown by the above processor -->
          <logger message="#[error.errorMessage.payload.failures['0']]"/>
          <!-- This will be a null value -->
          <logger message="#[error.errorMessage.payload.failures['1']]"/>
          <!-- This will be a null value -->
          <logger message="#[error.errorMessage.payload.results['0']]"/>
          <!-- This will have the result of this (correctly executed) route -->
          <logger message="#[error.errorMessage.payload.results['1']]"/>
      </on-error-continue>
  </error-handler>

</flow>
```

### Throws

- `MULE:COMPOSITE_ROUTING`

## Differences between For Each and Parallel For Each Scopes

Both For Each and Parallel For Each split the defined collection, and the components within the
scope process each element in the collection. Also, in both cases, each route runs with the same
initial context. The difference between these two scopes are:

- For Each works sequentially, while the Parallel For Each processes in parallel. This difference
  affects _error handling_:

  Because of the processing differences, the execution of For Each execution is interrupted when an
  error is raised (and the Error Handler is invoked), while Parallel For Each processes every route
  before invoking the Error Handler with a `MULE:COMPOSITE_ROUTE` error type.

- For Each does not modify the payload, while the Parallel For Each outputs a collection of the
  output messages from each iteration.

## See Also

- [For Each Scope](https://docs.mulesoft.com/mule-runtime/4.6/for-each-scope-concept).

- [How Transactions Affect Scopes and Routers](https://docs.mulesoft.com/mule-runtime/4.6/transaction-management#tx_scopes_routers)