[
https://issues.apache.org/activemq/browse/CAMEL-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49369#action_49369
]
Jonathan Anstey commented on CAMEL-1106:
----------------------------------------
This feature has been added in CAMEL-209 so I'm closing this one.
> 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
> Assignee: Jonathan Anstey
> 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.
