You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by al94781 <an...@harmel-law.com> on 2013/07/16 14:13:54 UTC
Canonical Way to Create a New Message Given Certain Conditions
Hi there,
We have a situation in our route whereby, when we encounter an error in
processing an inbound message, we want to flag the original as "Failed" (in
a header) prior to further processing, and also generate a new message to
request a tidy up of resources the original failure may have left behind
which we put on a new request queue.
The question I have is therefore: What is the canonical way to achieve this
with Camel?
- A splitter isn't the right way as the new (tidy up) message is not in the
original message to split it out.
- A wiretap feels like it might be a possibility, (looking for messages
with a "Failed" header, and reacting as a result by creating the new
message) but I'm not clear if this can operate within the original
transaction (we can't lose messages, and want to ensure a failure at least
guarantees a clean up is attempted).
- Alternatively we can just use a plain old processor, but this feels as if
we're missing something and a little ad-hoc.
Can anyone help? We're pretty sure this must be a very common use case.
TIA
Cheers, Andrew
--
View this message in context: http://camel.465427.n5.nabble.com/Canonical-Way-to-Create-a-New-Message-Given-Certain-Conditions-tp5735721.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Canonical Way to Create a New Message Given Certain Conditions
Posted by al94781 <an...@harmel-law.com>.
Hi @claus, @ceposta
Thanks for this. I'm keenest to ensure we don't go against the grain of
the "Camel-way". I've pushed against frameworks before and it always ends
badly. :D
To that end, both options you propose make a lot of sense. @caposta, your
option sounds like it keeps the handling and creation of the compensatory
message all in one place which I like from a conceptual-code perspective.
Have you seen others do this? Most important to us is that it's all
within the same transaction. We can't lose messages (which includes these
compensatory-messages that the onException handler would create.) If so, it
sounds like it might be for us. if not, I think we go down the route
@claus suggests.
Thanks for your input so far.
Cheers, Andrew
*Andrew Harmel-Law*
twitter: @al94781 <http://twitter.com/al94781>
blog: the-music-of-time.blogspot.com
flickr: flickr.com/photos/andrewbrucelaw
On 20 July 2013 14:24, ceposta [via Camel] <
ml-node+s465427n5735933h88@n5.nabble.com> wrote:
> Can you just use the regular onException handlers? If there is an error
> processing, throw an exception, and in the onException handler enrich with
> a Failed header and create your new message and send to a queue.
>
> On Saturday, July 20, 2013, Claus Ibsen wrote:
>
> > Hi
> >
> > If its a new inbound message maybe you can use an intercept from and
> > then do your check / whatever you want
> > http://camel.apache.org/intercept
> >
> > On Tue, Jul 16, 2013 at 2:13 PM, al94781 <[hidden email]<http://user/SendEmail.jtp?type=node&node=5735933&i=0><javascript:;>>
>
> > wrote:
> > > Hi there,
> > >
> > > We have a situation in our route whereby, when we encounter an error
> in
> > > processing an inbound message, we want to flag the original as
> "Failed"
> > (in
> > > a header) prior to further processing, and also generate a new message
> to
> > > request a tidy up of resources the original failure may have left
> behind
> > > which we put on a new request queue.
> > >
> > > The question I have is therefore: What is the canonical way to achieve
> > this
> > > with Camel?
> > >
> > > - A splitter isn't the right way as the new (tidy up) message is not
> in
> > the
> > > original message to split it out.
> > > - A wiretap feels like it might be a possibility, (looking for
> messages
> > > with a "Failed" header, and reacting as a result by creating the new
> > > message) but I'm not clear if this can operate within the original
> > > transaction (we can't lose messages, and want to ensure a failure at
> > least
> > > guarantees a clean up is attempted).
> > > - Alternatively we can just use a plain old processor, but this feels
> > as if
> > > we're missing something and a little ad-hoc.
> > >
> > > Can anyone help? We're pretty sure this must be a very common use
> case.
> > >
> > > TIA
> > >
> > > Cheers, Andrew
> > >
> > >
> > >
> > > --
> > > View this message in context:
> >
> http://camel.465427.n5.nabble.com/Canonical-Way-to-Create-a-New-Message-Given-Certain-Conditions-tp5735721.html
> > > Sent from the Camel - Users mailing list archive at Nabble.com.
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > Red Hat, Inc.
> > Email: [hidden email]<http://user/SendEmail.jtp?type=node&node=5735933&i=1><javascript:;>
> > Twitter: davsclaus
> > Blog: http://davsclaus.com
> > Author of Camel in Action: http://www.manning.com/ibsen
> >
>
>
> --
> *Christian Posta*
> http://www.christianposta.com/blog
> twitter: @christianposta
> http://www.christianposta.com/blog
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://camel.465427.n5.nabble.com/Canonical-Way-to-Create-a-New-Message-Given-Certain-Conditions-tp5735721p5735933.html
> To unsubscribe from Canonical Way to Create a New Message Given Certain
> Conditions, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5735721&code=YW5kcmV3QGhhcm1lbC1sYXcuY29tfDU3MzU3MjF8ODYwODY1MjIy>
> .
> NAML<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://camel.465427.n5.nabble.com/Canonical-Way-to-Create-a-New-Message-Given-Certain-Conditions-tp5735721p5736070.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Canonical Way to Create a New Message Given Certain Conditions
Posted by Christian Posta <ch...@gmail.com>.
Can you just use the regular onException handlers? If there is an error
processing, throw an exception, and in the onException handler enrich with
a Failed header and create your new message and send to a queue.
On Saturday, July 20, 2013, Claus Ibsen wrote:
> Hi
>
> If its a new inbound message maybe you can use an intercept from and
> then do your check / whatever you want
> http://camel.apache.org/intercept
>
> On Tue, Jul 16, 2013 at 2:13 PM, al94781 <andrew@harmel-law.com<javascript:;>>
> wrote:
> > Hi there,
> >
> > We have a situation in our route whereby, when we encounter an error in
> > processing an inbound message, we want to flag the original as "Failed"
> (in
> > a header) prior to further processing, and also generate a new message to
> > request a tidy up of resources the original failure may have left behind
> > which we put on a new request queue.
> >
> > The question I have is therefore: What is the canonical way to achieve
> this
> > with Camel?
> >
> > - A splitter isn't the right way as the new (tidy up) message is not in
> the
> > original message to split it out.
> > - A wiretap feels like it might be a possibility, (looking for messages
> > with a "Failed" header, and reacting as a result by creating the new
> > message) but I'm not clear if this can operate within the original
> > transaction (we can't lose messages, and want to ensure a failure at
> least
> > guarantees a clean up is attempted).
> > - Alternatively we can just use a plain old processor, but this feels
> as if
> > we're missing something and a little ad-hoc.
> >
> > Can anyone help? We're pretty sure this must be a very common use case.
> >
> > TIA
> >
> > Cheers, Andrew
> >
> >
> >
> > --
> > View this message in context:
> http://camel.465427.n5.nabble.com/Canonical-Way-to-Create-a-New-Message-Given-Certain-Conditions-tp5735721.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: cibsen@redhat.com <javascript:;>
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta
Re: Canonical Way to Create a New Message Given Certain Conditions
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
If its a new inbound message maybe you can use an intercept from and
then do your check / whatever you want
http://camel.apache.org/intercept
On Tue, Jul 16, 2013 at 2:13 PM, al94781 <an...@harmel-law.com> wrote:
> Hi there,
>
> We have a situation in our route whereby, when we encounter an error in
> processing an inbound message, we want to flag the original as "Failed" (in
> a header) prior to further processing, and also generate a new message to
> request a tidy up of resources the original failure may have left behind
> which we put on a new request queue.
>
> The question I have is therefore: What is the canonical way to achieve this
> with Camel?
>
> - A splitter isn't the right way as the new (tidy up) message is not in the
> original message to split it out.
> - A wiretap feels like it might be a possibility, (looking for messages
> with a "Failed" header, and reacting as a result by creating the new
> message) but I'm not clear if this can operate within the original
> transaction (we can't lose messages, and want to ensure a failure at least
> guarantees a clean up is attempted).
> - Alternatively we can just use a plain old processor, but this feels as if
> we're missing something and a little ad-hoc.
>
> Can anyone help? We're pretty sure this must be a very common use case.
>
> TIA
>
> Cheers, Andrew
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Canonical-Way-to-Create-a-New-Message-Given-Certain-Conditions-tp5735721.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen