You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by greenbean <Ke...@ngc.com> on 2009/04/23 15:41:47 UTC
Best Practices For Data Propagation Through Pipeline
Can anyone provide a "best practice" for data propagation and manipulations
through a pipeline?
Say I have a bunch of beans, each carrying out a specific type of
processing. I would like the beans to be generic in that they take in the
data they require and spit out their results. However, with these beans I
lose the original input data if each takes the payload as input and returns
the results of their processing as output for the payload.
In general I want to take input data from a queue and process it using
several beans, some concurrently, some in a pipleline. The beans in the
pipeline may require the original data, plus the output from one or more
other beans. What is the best way to create these types of routes without
designing the input and output of beans to be directly dependent on each
other? I could have the original data propagate in the payload and have
beans do their processing and add the results as properties, but that
requires my generic processing beans to understand that it needs to put the
results in a property.
Thanks.
--
View this message in context: http://www.nabble.com/Best-Practices-For-Data-Propagation-Through-Pipeline-tp23197204p23197204.html
Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
Re: Best Practices For Data Propagation Through Pipeline
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
In Camel 2.0 we have introduced the enricher DSL you can use to invoke
another endpoint and aggregate the output (you have the original input
and the response from the enricher).
http://camel.apache.org/content-enricher.html
As for loosing the original message when you use bean binding parameters.
You can use Exchange as parameter for your beans, then you have access to it all
You could also store the original input in a header so you can use
java types for your beans
For instance something like this:
public String myCoolBean(@Body String body, @Headers Map headers) {
// store input in header
headers.put("originalBody", body);
return "A new body";
}
You can also use Exchange property to store the original message.
There should be a @Properties annotation as well to get hold of the
properties in the method signature.
See more:
http://camel.apache.org/parameter-binding-annotations.html
On Thu, Apr 23, 2009 at 3:41 PM, greenbean <Ke...@ngc.com> wrote:
>
> Can anyone provide a "best practice" for data propagation and manipulations
> through a pipeline?
>
> Say I have a bunch of beans, each carrying out a specific type of
> processing. I would like the beans to be generic in that they take in the
> data they require and spit out their results. However, with these beans I
> lose the original input data if each takes the payload as input and returns
> the results of their processing as output for the payload.
>
> In general I want to take input data from a queue and process it using
> several beans, some concurrently, some in a pipleline. The beans in the
> pipeline may require the original data, plus the output from one or more
> other beans. What is the best way to create these types of routes without
> designing the input and output of beans to be directly dependent on each
> other? I could have the original data propagate in the payload and have
> beans do their processing and add the results as properties, but that
> requires my generic processing beans to understand that it needs to put the
> results in a property.
>
> Thanks.
> --
> View this message in context: http://www.nabble.com/Best-Practices-For-Data-Propagation-Through-Pipeline-tp23197204p23197204.html
> Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Apache Camel Reference Card:
http://refcardz.dzone.com/refcardz/enterprise-integration