``` After aggregation, the variables are: `{var1: "var1", var2: "newValue", var3: ["appleVal, bananaVal, otherVal"], var4: "val4"}` ## Error Handling Inside Scatter-Gather Routes To handle errors that a route’s event processors generate, use a Try scope in each route of the Scatter-Gather component. After all routes execute, if any route fails with an error, the Scatter-Gather component throws an error of type `MULE:COMPOSITE_ROUTING`. Event processing doesn’t continue past the Scatter-Gather component in the flow. Instead, the flow branches to your error-handling event processors. The `MULE:COMPOSITE_ROUTING` error object gathers the errors from the routes that failed and the Mule events from the routes that completed successfully. Your error-handling event processors can then process the Mule events from the completed routes. For the full list of fields available in the error, see [MULE:COMPOSITE\_ROUTING Error Fields](#composite_routing_fields). These two cases show how error handling works in a Scatter-Gather component: - Each route in a Scatter-Gather component contains a Try scope. One route generates an error. The `on-error-continue` error handler in that route’s Try scope handles the error, so the route completes successfully. The Scatter-Gather component consolidates the Mule events from all routes into a new Mule event and passes the consolidated event to the next event processor. - One route in a Scatter-Gather component has no Try scope, has a Try scope with an error handler that can’t handle the error type, or has an `on-error-propagate` error handler. An error occurs in this route and causes the route to fail. As a result, the Scatter-Gather component throws a `MULE:COMPOSITE_ROUTING` error. The flow branches to your error-handling event processors, which can process the Mule events from the completed routes. This example shows how to handle these errors: ```xml

``` ### MULE:COMPOSITE\_ROUTING Error Fields When the Scatter-Gather component throws a `MULE:COMPOSITE_ROUTING` error, the error message payload (`error.errorMessage.payload`) contains the outcome of every route. Both `failures` and `results` use the route index as the key. The route index is a string that matches the order of the routes in the XML configuration, starting at `'0'`. Each route appears in only one of the two collections, so looking up its index in the other collection returns `null`.

Field	Description
`error.errorMessage.payload.failures`	Errors from the routes that failed, keyed by route index. For example, `failures['0']` returns the error thrown by the first route. If the route at that index completed successfully, the value is `null`.
`error.errorMessage.payload.failures['<index>'].errorType`	Type of the error that the route threw. The component that raised the error defines this type. In the example, this value is `APP:MYERROR`, which matches the `type` attribute of the `raise-error` component. To get each part of the type separately, use `errorType.namespace` and `errorType.identifier`, for example, `APP` and `MYERROR`.
`error.errorMessage.payload.failures['<index>'].description`	Description of the error. The component that raised the error defines this description. In the example, this value is `Details on what caused this application error`, which matches the `description` attribute of the `raise-error` component.
`error.errorMessage.payload.failures['<index>'].detailedDescription`	Description of the error that’s the same as or more extensive than `description`.
`error.errorMessage.payload.failures['<index>'].errorMessage`	Optional Mule message that the failing component associates with the error, such as the response of a failed HTTP request. If the component doesn’t provide a message, as with the `raise-error` component, the value is `null`.
`error.errorMessage.payload.failures['<index>'].cause`	Underlying Java `Throwable` that caused the route to fail.
`error.errorMessage.payload.results`	Mule messages from the routes that completed successfully, keyed by route index. For example, `results['1']` returns the message from the second route. If the route at that index failed, the value is `null`.
`error.errorMessage.payload.results['<index>'].payload`	Payload of the message that a successful route returns. In the example, `results['1'].payload` is `apple`.
`error.errorMessage.payload.results['<index>'].attributes`	Attributes of the message that a successful route returns.
`error.childErrors`	Collection of the errors that the failed routes threw.

Each failure provides the same fields as any other Mule error. For more information, see [Selector Expressions for Mule Errors](https://docs.mulesoft.com/mule-runtime/latest/mule-error-concept#selector_expressions). ## Handle Timeout Errors in a Scatter-Gather Component If you configure a timeout for a Scatter-Gather component and a route doesn’t complete processing before the timeout expires, the route throws a `MULE:TIMEOUT` error. The Scatter-Gather component handles this error the same way as any other error from a route. After each route completes, either successfully or by throwing a `MULE:TIMEOUT` error, the Scatter-Gather component collects the successful results and the errors in the `MULE:COMPOSITE_ROUTING` error. Your configured error handler then processes this error. ## Example Project To learn more about how to use the Scatter-Gather component, download and open the example project _Scatter-Gather Flow Control_ from Anypoint Exchange in Anypoint Studio. This example shows how to use the Scatter-Gather component to aggregate data in parallel and return the result in JSON. The example uses prepared data as input for two resources to aggregate. The data represents information about two contacts and has this structure:

Resource	`firstname`	`surname`	`phone`	`email`
contacts-1.csv	John	Doe	096548763	john.doe@texasComp.com
contacts-2.csv	Jane	Doe	091558780	jane.doe@texasComp.com

A DataWeave script aggregates the contact information into a JSON structure that represents the data from both resources. To download and open this example project in Anypoint Studio, click the Exchange icon in the upper-left corner. In the window that opens, log in to Anypoint Exchange and search for the project name. ## Scatter-Gather XML Reference

Element	Description
`scatter-gather`	Sends a request message to multiple targets concurrently. It collects the responses from all routes and aggregates them into a single message.
Attributes
`timeout`	Sets the timeout for responses from sent messages, in milliseconds. A value of 0 or lower thatn 0 means no timeout.
`maxConcurrency`	Determines the maximum number of concurrent routes to process. By default, all routes run in parallel. If you set this value to 1, the Scatter-Gather component processes the routes sequentially.
`target`	Name of the target variable.
`targetValue`	Value of the data to store in the target variable. If not set, the default value is `#[payload]`. This field accepts any value that a variable accepts: Any supported data type DataWeave expressions The keywords `payload`, `attributes`, and `message`, but not the keyword `vars`

Child Element	Description
`route`	A route in the Scatter-Gather router.

### Throws - `MULE:ROUTING` - `MULE:COMPOSITE_ROUTING` ## See Also - [Core Components](https://docs.mulesoft.com/mule-runtime/latest/about-components) - [How Transactions Affect Scopes and Routers](https://docs.mulesoft.com/mule-runtime/latest/transaction-management#tx_scopes_routers) - [Error Handling](https://docs.mulesoft.com/mule-runtime/latest/error-handling) - [Try Scope](https://docs.mulesoft.com/mule-runtime/latest/try-scope-concept)

1	The Scatter-Gather component receives a Mule event and sends a reference to this Mule event to each processing route.
2	All processing routes start executing in parallel. After all processors inside a route finish processing, the route returns a Mule event. This Mule event is either the same Mule event without modifications or a new Mule event that the processors in the route create.
3	After all processing routes finish, the Scatter-Gather component creates a new Mule event that combines the resulting Mule events from each route. Then the Scatter-Gather component passes the new Mule event to the next component in the flow.