camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fintan Bolton (JIRA)" <>
Subject [jira] Created: (CAMEL-1106) Add enrich() processor to implement Content Enricher pattern
Date Thu, 20 Nov 2008 11:29:10 GMT
Add enrich() processor to implement Content Enricher pattern

                 Key: CAMEL-1106
             Project: Apache Camel
          Issue Type: New Feature
          Components: camel-core
    Affects Versions: 2.0.0
            Reporter: Fintan Bolton
             Fix For: 2.0.0

Add an enrich() processor with the following overloaded variants:

	from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>)...
	from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...

The motivation for this feature comes from a problem that Mark Fynes encountered while trying
to integrate an Artix Data Services example with Camel. The Artix DS example had multiple
inputs, but it turns out that it is difficult to represent an Artix DS transform with multiple
inputs in Camel.

After thinking about it for a bit, I realized that the problem can be solved using the Content
Enricher EIP pattern. Currently, however, writing a Camel content enricher mostly involves
rolling your own code. The aim of the 'Content Enricher Pattern' is to generalize the solution
of Mark's problem so that you can create a content enricher quickly and easily in the future.

Use Case 1 - Enriching from a flat file:
In the original example that Mark worked on, there were two sources of input:

1. A stream of credit card transactions (e.g. containing a Name, Credit Card Number, TransactionAmount,
and so on). This input can be represented by the start of a Camel route, e.g. from(<SourceURI>).

2. An XML file containing credit ratings for different customers (e.g. a list of associations
between Names and credit ratings). This input represents the data that will be fed in through
the content enricher processor.

The two sources of input could be handled by a new 'enrich()' processor, which is specified
as follows:

	from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...

Where the <SourceURI> specifies the source of incoming credit card transactions (e.g.
from a message queue), <EnricherURI> specifies the flat file containing the credit ratings,
<Aggregator> is a Camel aggregator, and <CachingFlag> indicates whether the flat
file (from <EnricherURI>) should be read only once (true) or every time a transaction
comes in (false).

For the <Aggregator>, probably the most generally useful implementation would be a ListAggregator
that combines the incoming exchange and the enricher exchange into a java.util.List instance.
The value list.get(0) would return the exchange from <SourceURI> and list.get(1) would
return the exchange from the <EnricherURI>.

If you chain enrichers as follows:

		.enrich(<EnricherURI01>, listAggregator)
		.enrich(<EnricherURI02>, listAggregator)

You would obtain a list with list.get(0) from <SourceURI>, list.get(1) from <EnricherURI01>,
and list.get(2) from <EnricherURI02>.

If you consider ListAggregator to be a good default, you could define the following overloaded
variants of enrich:

	enrich(<EnricherURI>, <Aggregator>)
	enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)

Where the default value of <CachingFlag> probably ought to be true(?).

The attached ZIP file contains a partial demo of this functionality. To run the demo, unzip
the archive and run the command, 'mvn test'.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message