Add enrich() processor to implement Content Enricher pattern
------------------------------------------------------------
Key: CAMEL-1106
URL: https://issues.apache.org/activemq/browse/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
Attachments: ContentEnricherExample.zip
Add an enrich() processor with the following overloaded variants:
from(<SourceURI>).enrich(<EnricherURI>)...
from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>)...
from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
Motivation:
-----------
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:
from(<SourceURI>)
.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>)
enrich(<EnricherURI>, <Aggregator>)
enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)
Where the default value of <CachingFlag> probably ought to be true(?).
Demo
-------
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.