Compensation Strategy for Scatter Gather Component in MuleSoft
This article gives some high-level idea about how to achieve Parallel processing in MuleSoft using the scatter gather and in case of failure in the Parallel processing how that can be handled and compensated.
What is Parallel Processing and When it’s Required?
Parallel processing is a technic where multiple task/operation/action can be executed concurrently. Let’s try to understand the parallel processing with help of below problem statement.
Flight Booking Organization Problem Statement
For e.g., let’s consider one of the leading flights booking origination app, the app connects to multiple airlines provider and capture the airline details and render that on the application. Now let’s see how it work in case of parallel processing is not implemented.
In this scenario mobile app makes a call to integration, and internally integration will make a call to different third-party services to get the flight information. Below are some observations -
- Every call to third-party system is made sequentially because of which the overall response time increased.
Airline 1 average response time - 2 Sec
Airline 2 average response time - 1 Sec
Airline 3 average response time - 2 Sec
→ So overall response time would be around 5 to 6 seconds- Again, we would need a temp storage to hold the response from each third-party service as we need to send data from each system to consumer in this case mobile app.
- All the third-party services are independent of each other.
These are some key factors which will badly impact on user experience (response time) and integration memory (temp storage); this issue can be resolved or improved by making use of parallel processing.
In next section, we will see how this issue is resolved by making use of parallel processing.
Parallel Processing through MuleSoft Scatter Gather Component
Before directly jumping on flight booking organization problem statement lets understand what scatter gather is and how it works.
What is Scatter-Gather
The Scatter-Gather component is a routing event processor that processes a Mule event through different parallel processing routes that contain different event processors. Each route receives a reference to the Mule event and executes a sequence of one or more event processors.Each of these routes uses a separate thread to execute the event processors, and the resulting Mule event can be either the same Mule event without modifications or a new Mule event with its own payload, attributes, and variables.
The Scatter-Gather component then combines the Mule events returned by each processing route into a new Mule event that is passed to the next event processor only after every route completes successfully. The Scatter-Gather component executes each route in parallel, not sequentially. Parallel execution of routes can greatly increase the efficiency of your Mule application and may provide more information than sequential processing.
For more details Refer — Scatter-Gather Router | MuleSoft Documentation
Now we know how scatter gather works, lets resolve the problem statement.
Flight Booking Organization Proposed Solution
Let’s see how Scatter Gather help’s, flight booking organization to resolve their key issues (performance and memory)
As per above diagram all calls to the third-party systems are happing parallelly and the responses of the third-party system would be part of scatter gather component response payload only. So now,
- Additional memory is not required to store the response payload of third-party system.
- And overall response time is reduced to 2 to 3 seconds from 5 to 6 seconds.
Now we understand the scatter gather flow, so let’s focus on bit advance use case where we must handle the exception in case of any failure in the scatter gather flow and apply the compensation strategy wherever required.
Compensation Strategy for Scatter Gather Component in Mulesoft.
Problem Statement
- Client has a web application where user will enter inputs and same input needs to be persisted in different independent services.
- Each service will take at least 2 seconds to process the records and client has the SLA to complete the transaction in 4 seconds.
- And the one of the critical requirements is the data should be synch across all three system, for e.g., if system 1 and system 2 data insertion completed successfully but for some reason system 3 failed to insert the record in that case system 1 and 2 should roll back the data. (Here assumption is all system should provide the rollback endpoints or services.)
Most of the requirement can be achieved through the typical scatter gather component, except the key requirement i.e. compensate the flow in case of transaction failure as shown in below diagram. (i.e. all three system should be in synch).
To achieve flow compensation requirement, we need to extend our scatter gather flow, as explained in below section.
Proposed Design with Scatter Gather Flow Compensation Strategy
- Above diagram is the extension of typical scatter gather flow, here we have added the flow compensation strategy as well.
- The key part of this design is to identify the successful and failed routes.
Scatter Gather Successful and Failed Routes Identification in case of Exception.
When exception occurred inside scatter gather flow, error object holds two set of attributes
o error.errorMessage.payload.results — Holds information about the success routes
o error.errorMessage.payload.failure — Holds information about the failed routes
Scatter Gather Flow Compensation Strategy Implementation
- Create an application with Scatter Gather Component
Let’s Look at the Compensation Logic.
- Use for each to iterate over a success route and invoke the compensation logic.
- Using flow reference make a call to respective route compensation logic.
- Below is the compensation implementation for each flow.
- Debug Mode
Summary
In this article we have learned about, how to achieve Parallel processing in MuleSoft using the scatter gather and in case of failure in the Parallel processing how that can be handled and compensated.
