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:
generateTransformerName() is used to generate an automatic name if one is needed.
isAcceptNull() is set to return false to prevent transformers from accepting null values.
isSourceTypeSupported() checks whether a source type is supported by the transformer. Source types would have been pre-registered using the
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.
– 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
– Implement the
Transformer interface only if you need to tweak the behaviour implemented in these abstract classes.