Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

In some situations, the incoming message may not contain all of the data that will be necessary to be processed correctly, therefore additional information will need to be acquired and added to the message using the Content Enricher integration pattern.

When transmitting messages from one application to another it can be common that the target system requires more information than the source system has provided. As an example, an incoming Address message may only contain a ZIP code because storing a redundant state code would be considered superfluous. Yet another system may not actually use state codes, but spell the state name out because it uses free-form addresses in order to support international addresses.

There are many examples where our messages must be enriched with data derived from other systems.

Content Enrichment Support

There exist several manners to enrich content:

  • Message translator with arbitrary processor in the routing logic

  • The enrich() method, this method will obtain additional data from the external resource by sending a copy of the current exchange to a producer endpoint and then using the data in the resulting reply. The exchange created by the enricher is always an InOut exchange.

  • The pollEnrich() method, this method will obtain additional data by polling a consumer endpoint for additional information. Thus, the implication is that the consumer endpoint (main route) and the consumer endpoint in pollEnrich() operation are coupled. Therefore, an incoming message on the initial consumer in the route triggers the pollEnrich() method on the consumer to be polled.

  • No labels