Scatter-Gather Integration Pattern (Mule 4) Part 2
GitHub repository with the Mule Project can be found at the end of the post.
In the previous post, Intro to Scatter-Gather Integration Pattern, we have discussed the basics of the Scatter-Gather message routing Enterprise Integration Pattern and also demonstrated a simple case of the pattern using MuleSoft Connector. Moving forward, from a happy path scenario, we will see the demonstration on how Mule 4 Scatter-Gather connector behaves in case of processing errors with or without Mule Error handlers. Additionally, we will explore the example of processing multiple services using the Mule 4 Scatter-Gather connector.
Gathering thoughts from the previous blog:
Scatter-Gather processes messages in-parallel and the result is an aggregated response of the routes.
To live up to its merits, Scatter-Gather needs more than one message processing route.
When the process responses are independent of each other, it is efficient to use Scatter-Gather.
Use Scatter-Gather for multicasting scenarios.
Scatter-Gather is concurrent processing and there is no sequence of execution.
Scatter-Gather will not stop processing messages to other successful routes during failures.
How does the input message get processed in Scatter-Gather?
The input payload/message is distributed or copied across all the routes of the Scatter-Gather. Our previous example of the MuleSoft Scatter-Gather is modified, by adding a new Set Payload component to check the status of the payload during the Scatter-Gather processing. As shown below from the log results, the payload is copied or distributed across all the routes of the Scatter-Gather. In the listed example, the payload value “result0: 42” is not honored by the three flows, as they have their payload values.
In short, the Set Payload value before the Scatter-Gather component is overwritten by the flow's payload value.
However, the Set Payload information can be very well used to add business logic to the multiple routes accordingly. For demonstration purposes, Flow One payload is modified to retrieve the “result0” information.
Error Handling in Scatter-Gather
In our previous post, we stated that the Scatter-Gather avoids a complete meltdown, unlike sequential processing. But, without an effective error handling in place, you can question the merits of the latter statement. One can use a MuleSoft Try scope in the routers of a Scatter-Gather component for error handling purposes.
If a particular route encounters errors, the Try scope will take care of the error using the On-Error-continue error handler, which would make the route successful by handling the error logic. The Scatter-Gather route failures are handled well to process the error unless it is required to end the process abruptly. Let’s try to prove the same using some twists in our current Scatter-Gather example.
Happy Path ☺
Everything is green, life’s pretty smooth and happiness sways around. The Scatter-Gather route flows one, two, and three payloads have been modified to implement a simple addition, subtraction, and division of numbers (ex: 10+2, 16-2, 30/2) to be aggregated as an output result of each flow. In the screenshot below, results are displayed as expected, all looks good! Yay!!
Not so Happy Path
Well, life isn’t all rainbows and unicorns as the above result made you believe for a while. If the flow-three fails due to a division by zero error, the Scatter-Gather will fail as there isn’t any mechanism to avert the catastrophe. The process will halt, and the error will be displayed as given below.
