Have available data in several points of the route?
I am evaluating if I can use CAMEL to implement workflows. I have read in this same forum I can although CAMEL is not designed for it.
Anyway, I have been studying the different patters but the main problem I find is that I don't know how to have data available in different points of the route. What I am looking for is for something like the context in the springwebflow technology, where it's you can store any object and retrieve it by its key.
Re: Have available data in several points of the route?
I think you are looking for the Camel Exchange. The Exchange is a
container that contains the messages (in-message and depending on the
MEP also out-message) as well as properties. You can put and get any
data into/from the properties of the exchange.
On Tue, Mar 27, 2012 at 16:25, m.jimen.blazquez
<[hidden email]> wrote:
> I am evaluating if I can use CAMEL to implement workflows. I have read in
> this same forum I can although CAMEL is not designed for it.
> Anyway, I have been studying the different patters but the main problem I
> find is that I don't know how to have data available in different points of
> the route. What I am looking for is for something like the context in the
> springwebflow technology, where it's you can store any object and retrieve
> it by its key.
> Is this possible with CAMEL?
> kindest regards
> View this message in context: http://camel.465427.n5.nabble.com/Have-available-data-in-several-points-of-the-route-tp5598002p5598002.html > Sent from the Camel - Users mailing list archive at Nabble.com.
- you can store your data as Exchange properties
- you can use the enrich pattern  to enrich your message or message
headers and use an AggregationStrategy to merge the old and the new
claim-check is the prefered solution if you deal with big data.
Actually there is no requirement that the called services know camel.
You can for example save the original message body to an exchange
property then convert the body to the needed "request object" that is
the parameter for the called service. Then the service response
replaces the message body again. Now you can use the response directly
or store it also in an exchange property and finally restore the
original message body by getting it from the initially saved exchange
Pseudo code of such a route:
// save message body to exchange property to restore it later
// create service request parameter
// call searchService
// save service response to exchange property
// restore original message body
continue with route ...
I was wondering, what about if I need a context to store objects and access
them from a different exchange (next on one the same route)? But probably
in this case the best option is to have context object in the Registry and
access registry from each exchange. hhhmm