A common integration scenario is where a single message needs to be sent through multiple routes.
Take for example a case in which you're receiving a message about a new client's on-boarding. The message needs to be routed through the CRM to create the client, to marketing who will want to know how the client heard about the company, and finally passed to provisioning and stock systems so they can work their magic as well.
In this case, the message is broadcasted in a “fire and forget” fashion, meaning you don't need a response from any of these systems to continue your processing. Each of those systems are responsible for handling their own logic and their own errors. In mule ESB, you could do this like this:
There are other cases, however, in which you do
Mule ESB
- It uses serial processing! It means that all routes are executed in order, one after the other in one single thread. This means that the total amount of time that we have to wait until we can get our hands on all the responses is the sum of all routes' executing times.
- It doesn't do a very good job in error handling: Suppose you have 4 routes like in the example above. If the second route fails, routes 3 and 4 will never be executed. On top of that, you only get information on route number 2 failing, no information on route 1 is available.
- It's not very customisable
To overcome these limitation, Mule 3.5 Early Access release
Introducing the Scatter-Gather
The Enterprise Integration Patterns defines the Scatter-Gather: “The Scatter-Gather routes a request message to the a number of recipients. It then uses an Aggregator to collect the responses and distill them into a single response message.“
- Parallel processing: Scatter-Gather uses a thread pool to concurrently execute all routes. This means that the total time the caller thread needs to be waiting for routes to respond is no longer the sum of all route's time, but just the longest of them.
- Better Error Handling: Because all routes execute in parallel, one (or many) failing routes do not prevent other routes from being executed. Also, in case of exception, you will get a CompositeRoutingException, which not only contains information of all failed routes, but also the responses from the successful ones.
- Configurability:
Scattering in Action!
this post. In this example (which basically explores the Google Connectors Suite and DataMapper), we take a Google Spreadsheet with super heroes contact information and we use it to create Salesforce Accounts, Google Contacts, Google Calendar appointments and Google tasks. Details of that example are available in the original post, so I'll just focus in the part of it that broadcasts the original message (each superhero found on the spreadsheet) into several routes (salesforce and google apps). At an XML level, it finally comes to this:
When executing this in my local PC, it takes 9 seconds to complete the whole integration (this number might vary depending on your geographical location, bandwidth, and laptop processing power). Now, let's see the same example with the new router:
In this case, time was reduced to only 5 seconds: 45% faster.
Custom AggregationStrategy
Let's go back for a second to the cheapest flight example. Suppose that once all routes responded you want to filter the ones that had errors (if any) and then choose the cheapest one. You could do that in Mule using flows, but consider this simpler solution:
That's cool! I can easily customise how the response events are aggregated without worrying about the aggregation complexity itself! But how do I use that class? Check it out:
Take Aways
- It's also more customizable and provides better error handling.
- Scatter-Gather is available since Mule's 3.5 Early Access release
Thank you for reading and looking forward for your feedback!
