camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe San <codeintheo...@gmail.com>
Subject Re: enrich and pollEnrich
Date Wed, 15 Aug 2012 14:08:40 GMT
Yes. Your statement....

"The TO in the Camel routes is *always* a producer, eg you produce a
message to an endpoint.
In the http endpoint you would then do a request/reply to the http
service. So the message after the TO will
contain the response from the http service, and whatever the message
was before would be discarded."

....made sense. You don't need a stronger Coffee. You might probably need
to consider expanding your Chapter 1 in "Camel in Action" book with such
explanations.

Regards,
Jothi



On Wed, Aug 15, 2012 at 4:02 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:

> On Wed, Aug 15, 2012 at 3:32 PM, Joe San <codeintheopen@gmail.com> wrote:
> > Thanks for the explanation.
> >
> > From your example in the Camel in Action book in Chapter 3:
> >
> > from("quartz://report?cron=0+0+6+*+*+?")
> > .to("http://riders.com/orders/cmd=received&date=yesterday")
> > .process(new OrderToCsvProcessor())
> > .to("file://riders/orders?fileName=report-${header.Date}.csv");
> >
> > Your statement "Where as a http component may only support the
> producer". I
> > would understand the above route as follows
> >
> > From the quartz Producer to http Consumer, process and send to file
> > Consumer. Is it interpreted this way? or the role of a component
> (Producer
> > or Consumer) depends on the component type?
> >
>
> The TO in the Camel routes is *always* a producer, eg you produce a
> message to an endpoint.
> In the http endpoint you would then do a request/reply to the http
> service. So the message after the TO will
> contain the response from the http service, and whatever the message
> was before would be discarded.
>
> eg the TO follows the pipes and filters pattern (aka pipeline in Camel)
> http://camel.apache.org/pipes-and-filters.html
>
>
> If you use the content enricher then you can "enrich" instead, so you
> have the before and after message.
> And then use the AggregationStrategy to do your logic how to
> enrich/merge the messages together, whatever you want.
> http://camel.apache.org/content-enricher.html
>
>
> Now the example you refer to from the book, we dont use the content
> enricher EIP per see, as we dont really need to enrich the message. As
> the message from the quartz endpoint will be an empty message. So we
> can just use the pipes and filters EIP.
>
>
> Does my rambling make a bit of sense?
> Maybe I need a stronger coffee to explain it better.
>
>
> > Regards,
> > Jothi
> >
> > On Wed, Aug 15, 2012 at 3:00 PM, Claus Ibsen <claus.ibsen@gmail.com>
> wrote:
> >
> >> On Wed, Aug 15, 2012 at 2:53 PM, Joe San <codeintheopen@gmail.com>
> wrote:
> >> > Camel Riders,
> >> >
> >> > I fail to fathom the fact that enrich works with a Producer EndPoint
> and
> >> > pollEnrich works with a Consumer EndPoint. Is there a design
> >> consideration
> >> > behind this mechanism? Can anyone please clarify why a pollEnrich
> should
> >> be
> >> > used with a Consumer EndPoint and not with a Producer EndPoint? Has it
> >> got
> >> > something to do with the Message type (request only or request /
> >> response)?
> >> >
> >>
> >> Yes some components support both producers and consumers, and behave
> >> differently.
> >> For example file/ftp components. The producer will write a file, and
> >> the consumer read a file.
> >>
> >> Where as a http component may only support the producer, etc.
> >>
> >>
> >>
> >> > Regards,
> >> > Jothi
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> FuseSource
> >> Email: cibsen@fusesource.com
> >> Web: http://fusesource.com
> >> Twitter: davsclaus, fusenews
> >> Blog: http://davsclaus.com
> >> Author of Camel in Action: http://www.manning.com/ibsen
> >>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message