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.
Prudhvi
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.
Prudhvi
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.
Prudhvi
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)
Prudhvi