I've started to dig into this further. When my orchestration sends a
message, receives back an HTTP 400 response, and handles the resultant
SoapException, I'm left with two suspended messages.
The orginal message sent is Suspended (resumable) in its original form,
all
of its originally promoted properties remain promoted and it has no
promoted
error properties.
There is also a Routing Failure Re****t that is Suspended (non-resumable)
that has a copy of the original message but all of its originally promoted
properties have been demoted and a set of error properties are promoted
instead.
I think I can see how to subscribe to the second message based on the
error
properties,but I'm not sure how to subscribe to the first since it appears
to be indistinguishable based on its context from the same message in a
non-suspended state.
Am I making any sense?
Thanks,
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
>>
>>
>>
|
