The concept makes sense, but I'm a little unclear what the "eater" pipeline
actually needs to do in order to "swallow" and "remove" the message.
Zoe
"Richard S*****er" <RichardS*****er@[EMAIL PROTECTED]
> wrote in
message news:BD8A444D-AFFE-4C71-95E4-907D635D502A@[EMAIL PROTECTED]
> Hey Zoe,
>
> We had (have) that problem a lot ourselves. One proposal out there is
to
> create a custom "eater" pipeline that simply swallows the message.
Then,
> create a send ****t that subscribes to suspended messages that originate
> from
> the SOAP send ****t. That new send ****t has the "eater" pipeline in it.
> This
> way, once any suspended messages persist from the SOAP ****t, they are
> quickly
> swallowed up and removed.
>
> --
> Richard S*****er
> http://s*****er.wordpress.com
>
>
> "Zoe Hart" wrote:
>
>> In my orchestration I send an authorize-order message to my partner.
>> Under
>> normal cir***stances I receive back and
authorization-amount-notification
>> message. Under some normal business cir***stances (e.g. the order
already
>> has a valid authorization) I receive back an HTTP 400 Bad Request. That
>> comes back to my orchestration as a SoapException, so I have the Send
and
>> Receive shapes wrapped in a scope with an exception handler to handle
>> that
>> normal business scenario. That all works fine except for the fact that
>> when
>> I receive back an HTTP 400, the original authorize-order message that
>> generated that response is left suspended. So while my orchestration is
>> handling the exception, I still have this growing collection of
suspended
>> messages that I continually have to clean up. Is there some way to
>> configure
>> and/or develop my orchestration so that these suspended messages that
are
>> associated with handled exceptions are automatically cleaned up?
>>
>> Thanks,
>> Zoe
>>
>>
>>
|
