Warning: A non-numeric value encountered in /home/ricston2/public_html/blogarchive/wp-content/themes/Divi/functions.php on line 5766

One of the most common patterns in integration work is transformation – the ability to convert data from one format to another. If you want to create a new transformer, Mule has a Transformer interface that you would need to implement in your class. It also has an AbstractTransformer class. When would you need one and not the other?

Obviously, the abstract class has a number of features pre-implemented, namely:

1 – generateTransformerName() is used to generate an automatic name if one is needed.
2 – isAcceptNull() is set to return false to prevent transformers from accepting null values.
3 – isSourceTypeSupported() checks whether a source type is supported by the transformer. Source types would have been pre-registered using the registerSourceTypes() method.
4 – checkReturnClass() verifies that the result matches what is expected.

Deriving your transformer from the abstract class does have its advantages.

The only snag to all this is the fact that the data received in a transformer that is based upon AbstractTransformer is the MuleMessage payload. This is fine most of the time, but what if you want to transform the entire MuleMessage itself? What if you want to manipulate the MuleMessage properties for instance?
In this case, using the interface is still not necessarily recommendable – but using the AbstractMessageAwareTransformer class will do the trick.

Conclusion:
– Inherit from AbstractTransformer if you wish to implement a new transformer.
– Inherit from AbstractMessageAwareTransformer if you wish to implement a new transformer that can work on the MuleMessage.
– Implement the Transformer interface only if you need to tweak the behaviour implemented in these abstract classes.