How to deal with 3+ message formats in mule?

Question

Let's suppose i'm dealing with 3 (very) different messages formats inside my Mule ESB, i'll call them A, B and C. They could be XML (via socket), some custom text-format and SOAP transporting another kind of XML (it's not the same that is transported via socket), for example. All of them can be transformed into each other. A, B and C carry the same information, only in different formats.

Each one of them will have it's own entry point in the flow, some format validations etc..

But, there's some (a lot) of logic that i need to be executed in all of them like dealing/extracting some information, routing based in the content, enriching etc etc..

What should i do? I mean, i did some research on integration patterns but didn't found anything about this situation or similar.

The easier approach sounds like taking one of the formats (let's take B) as the "default" one of my "main-flow" and implementing all the common logic based on it. Then, every message that arrives will be transformed to B and then transformed again to the destination format, even if the two points uses the same format.

Examples:

1) One "A" hit my app, then it's transformed to "B" to execute the common-logic, then it's transformed again to "A" to be delivered.

2) One "C" hit my app, then it's transformed to "B" to execute the common-logic, then it's transformed to "A" to be delivered.

Then, my question is, does Mule have a feature that provides me a better way on doing something like this or the solution above looks reasonable?

Thanks in advance.

Answer 1

The are a few options, any of these can be implemented in Mule. The first two are close to what you have suggested.

Normalizer: http://eaipatterns.com/Normalizer.html

Canonical Data Model: http://eaipatterns.com/CanonicalDataModel.html

Routing slip: http://eaipatterns.com/RoutingTable.html

Envelope: http://eaipatterns.com/EnvelopeWrapper.html

Which you use will depend on your messages and what you need to do with them.

With Canonical Data Model for example you could build a seperate flow for each incoming type that:

• Receives a object in their own format.
• Translates that object to the canonical object.
• Passes that message on to the main processing flow.

The main flow would only need to know how to process that object.

Any endpoints that need the original object back would sit behind a transformer that can reverses the transformation.

You could pick one of your existing objects and use message variables to remember the original format or create a new object that remembers the original type itself.