One common scenario involves the need to enrich an incoming message with information that isn’t provided by the source system. You can use a content enricher if the target system needs more information than the source system can provide.
Consider a message from a source system contains a ZIP code but the target system needs the two letter state. A message enricher can be used to lookup the state using the ZIP code from an enrichment resource. The enricher calls out to the enrichment resource with the current message (containing the zip code) then enriches the current message with the result.
This is a very simple flow with one-way inbound and outbound endpoints, and which acts as part of an order processing pipeline. This flow uses an enricher to add a state flow variable to the current message with the state that the addressLookup endpoint returns. The ‘target’ attribute defines how the current message is enriched using a MessageEnricher which uses the same syntax as expression evaluators.
NOTE: Mule 3.1 currently supports enrichment of flow variables and message headers only.
In this particular example the 'addressLookup' endpoint receives the full message, in some cases this might be a generic service that doesn’t know how to parse our order message but rather just a ZIP string. It is very easy to improve the configuration to support this, consider the following snippet:
The “enrichment resource” can be any message processor, outbound endpoint, processor-chain or flow-ref. If using an outbound-endpoint then of course it should have a request-responseexchange pattern.
The <enricher> element also supports more advanced use cases where the message returned by the enrichment resource isn’t just a simple string which is exactly what we need to enrich the current message with, often you may want to enrich your message with just part of the information from the result of the invocation of an external service.
For example, if you have a requirement to validate the credit card used for the order as well as add the full address using the ZIP code. The credit card validation process should populate a header call “paymentValidated” with either true or false, this will be used later on. We can easily perform credit card validation by calling out to an authorization service like Authorize.Net to perform this validation, but we have a problem this cloud connector returns more than just a boolean.
The solution is to use the enrichers ‘source‘ attribute which will select a value from the result message before using it to enrich the target.
This approach allows you to map content in the response message from the enrichment resource to the current message. If you have a more advanced use case you can also map n values in the enrichment resource response to m values enriched in the current message, this is done using child <enrich> elements each of which has source and target attributes. Note: if you use child <enrich> elements the source/target attributes on <enricher> are not allowed.
You can find information on using a variable with any enricher listed on these pages:
Default enrichers are loaded at runtime.
Schema documentation for enricher element.
API documents: org.mule.core.enricher.MessageEnricher