iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Mule 4’s Scatter-Gather router sends one event through multiple routes and combines the returned events into a route-indexed result. Routes run in parallel by default; the router waits for them to finish before continuing. You can control concurrency, shape the output with DataWeave, and choose whether route errors are handled locally or reach the flow as a composite routing error.
How Scatter-Gather works in Mule 4
Scatter-Gather fans one Mule event out to separate routes. Each route runs its own sequence of processors using a reference to the input event. A route can return the original event or an event with changed payload, attributes, or variables. Once the routes finish, the router aggregates their results into a new event and passes it downstream if the routes completed successfully.
MuleSoft’s Scatter-Gather Router reference describes the default behavior: “The Scatter-Gather component executes each route in parallel, not sequentially.” The router requires at least two routes; MuleSoft says an application with fewer than two does not start.
Free tools Windows power users keep installed
One-click scans. No signup required.
Control route concurrency and timeouts
- Parallel by default: Routes can execute concurrently.
maxConcurrency: Sets the maximum number of routes running concurrently. Set it to1to make routes run sequentially.timeout: Sets the route response timeout in milliseconds. A value of zero or less means no timeout. A route that exceeds a configured timeout raisesMULE:TIMEOUT.
These are current Mule Runtime reference details. Confirm the configuration against the Mule Runtime version used by your application, particularly when maintaining older Mule ESB flows.
#1 Best Overall
What result does Scatter-Gather return?
The aggregated payload is indexed by route, illustrated in MuleSoft’s reference as {0: messageFromRoute0, 1: messageFromRoute1, …}. It is not automatically a flat array of payloads. Use a DataWeave transformation after the router when the next processor expects an array or another application-specific shape.
MuleSoft documents this DataWeave expression for extracting route payloads into an array:
flatten(valuesOf(payload) map ((item, index) -> item.*payload))Choose the transformation to match the downstream contract; retaining the indexed route results may be appropriate when route identity matters.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →How variables behave across routes
Every route starts with the same initial variable values. A change made in one route does not alter a sibling route’s values while the routes are running. After aggregation, if only one route changed a variable, that changed value is used. If multiple routes changed the same variable, the aggregated value is a list of those route values. Unchanged initial values remain available, and variables introduced by a route can appear in the aggregated event.
Rank #3
For clearer flow behavior, make each route’s returned data explicit and transform the aggregate after Scatter-Gather into the structure the next processor needs.
Handle a failure in one route
An error handled inside a route with a Try scope and on-error-continue lets that route complete, so its result can be aggregated with the other routes. Without a suitable local handler, or when the route uses on-error-propagate, the route failure causes Scatter-Gather to raise MULE:COMPOSITE_ROUTING. The flow follows its configured error path instead of running processors after the router.
Rank #4
The composite routing error is not necessarily an all-or-nothing loss of results: its data can include failed-route information as well as successful route results, which the flow-level error handler can inspect. When a configured timeout expires, the route raises MULE:TIMEOUT; the timeout participates in the composite routing error path. The Anypoint Code Builder Scatter-Gather reference also documents timeout and composite-error behavior.
Set a target for selected output
The target and targetValue options let you store selected output in a target variable. If no target value is supplied, the default is #[payload]. Documented target-value expressions include supported data types, DataWeave expressions, and the keywords payload, attributes, and message; vars is not among the allowed keywords. Check the current runtime reference for the precise configuration syntax applicable to your version.
Check stream repeatability
Scatter-Gather supports repeatable streams and does not process nonrepeatable streams. Mule streams are repeatable by default unless a component’s streaming strategy is configured as nonrepeatable. If a flow uses a nonrepeatable streaming strategy, account for that constraint before routing the event through Scatter-Gather.
What changes between Mule 3 and Mule 4?
Do not apply Mule 3 aggregation examples to Mule 4 without adapting them. MuleSoft’s Scatter-Gather migration guide identifies aggregation strategy as the key change: Mule 3 examples may use a Java class via custom-aggregation-strategy, while Mule 4 exposes a collection of route messages that can be aggregated with DataWeave. Verify version-specific XML and configuration against the runtime in use.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
