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
>
>
>
|
