2. A Mule transformer has simple behavior. It
strictly enforces the types of data it receives and
outputs. This can be relaxed by configuration: in
that case, a transformer won’t report an exception
for bad input, but will return the original message
unchanged, without enforcing the expected result
type (return class) .
A transformer can alter a message in different ways:
Payload type transformation —The data type of
the message payload is transformed from one
form to another. For example, a java.util.Mapis
transformed into a javax.jms.MapMessage.
3. Payload format transformation —The data
format of the message payload is
transformed from one form to another. For
example, a DocBook XML instance is
transformed into an XSL-FO instance.
Properties transformation —The properties
of the message are modified, whether by
adding new properties or by removing,
renaming, or changing the values of existing
properties. For example, a message needs a
particular property to be set before being
sent to a JMS destination.
4. Mule is extremely rich in terms of available
transformers: each Mule library you’ll use in your
project can potentially contain transformers:
The Mule core contains a wealth of general-
purpose transformers.
Modules can also contain transformers.
Transports may provide transformers as well.
5. A transformer element supports two common
configuration attributes, in addition to its name:
ignoreBadInput—This instructs the transformer to
perform no action and return the message
unchanged in case its type isn’t supported.
returnClass—This attribute allows you to
configure the fully qualified name of the type of
class that the transformer is expected to return.
This is useful if you want to strictly enforce a
stricter type than the transformer’s default (for
example, a transformer might target
java.lang.Object whereas you want it to produce
only java.util.Mapobjects)
