Ok, you're in the integration business and we both agree that MuleSoft is the perfect tool to bring all the client’s tough requirements to life, but are you following the best practices and the industry standards?
Enterprise Integration Patterns (EIP for short) is a compendium of the most used application integration design patterns, its limitations, benefits and relationship to each other. It is written by several brillant minds, including Martin Fowler and Gregor Hohpe.
In this article I will demonstrate 3 Integration Patterns and how they can be implemented using MuleSoft out of the box components, after all, MuleSoft is heavilly inspired (and also inpiration) for EIP.
Scenario: You have to put back together a message that was split in several small pieces that were processed by individual parallel flows.
Proposition: How do you aggregate several messages that were processed by different asynchronous flows?
The Mule Collection Aggregator is a component that aggregate messages based on its MULE_CORRELATION_ID property. Components like the Mule Split will add this property automatically to each message.
In the example below we are splitting a message, sending it to a VM endpoint for processing and then aggregating all the messages together in a single message.
Flow in XML may be found here: https://github.com/javabr/muleesb/tree/master/aggregator
How to invoke the http endpoint for the aggregator application:
curl -i -X POST -H "Content-Type:text/plain" -d '{ "items" : ["a","b","c","d"] }' 'http://localhost:8081'
Scenario: You are writing integrations that will read information from several applications and each one has its own internal data format. Moreover, you want to minimize dependencies between your source applications (the ones that read from the different data souces) with the target applications (the ones that will consume the data).
Proposition: You need a common data model that will be the central repository for the portion of the data that your target applications will consume from. You need a data canonical model.
On the example below, two flows consume data with different formats and deliver it to a single data format (the canonical data model).
The flow source code: https://github.com/javabr/muleesb/tree/master/canonical-data-model
The consumers of the VM endpoint understand the common format in JSON and can consume the data.
For simplicity, this example uses Mule VMs to host and distribute the canonical data model. Real life applications will be probably hosting the canonical model in a intermediary repository such as a messaging system, a distributed cache, a database or a combination of those.
This is how you can invoke source1 endpoint:
curl -i -X POST -H "Content-Type:text/plain" -d \
'<?xml version="1.0" encoding="UTF-8" ?><data> <order>OSKWSSS</orde> <custId>77655</custId> <total>$898.21</total> </data>' \
'http://localhost:8081'
This is how you can invoke source2 endpoint: curl -i -X POST -H "Content-Type:text/plain" -d \ '{ "cid" : "4321" }' 'http://localhost:8082'
Scenario: You have received a big message in your application and need to deal with it. What you do if you do not need the whole message?
Proposition: Use content filter to produce a simpler message with lower footprint.
This EIP consists in filter the message received and remove from the payload all the unecessary parts, leaving behing only what you need.
The sample application below connects to a Photo REST api to download a list of Photos that has more than 5000 items. Our app only needs the 10 first! so it uses the set payload component to reduce the payload from 5000 to 10 items.
In this example it is clear how benefical it is to lower the size of the message. Sometimes the operation of applying content filter is not so visible for everyone, after all creating a new payload is creating new objects. For those, I would advocate that reducing the message payload to only what is necessary also brings code clarity, manutenabilty and scalability (remember smaller messages navigate/serialize faster).
This is the source code: https://github.com/javabr/muleesb/tree/master/content-filter
Conclusion:
In this article I have demonstrated basic implementation for 3 of the most used Enterprise Integration Patterns on the recent project that I have been working on. There are so many more documented EIP. You can find some good documentation on the web, mainly on the official web site: www.enterpriseintegrationpatterns.com . The book is much deeper and really delivers it. If you do not have a copy, grab one!
Share this Blog with colleagues
