Thanks, I got something working. I used a basic FILE Send ****t and
configured it to output a static filename of SuspendedMessage.xml with
Copy
Mode set to overwrite. That way I can consume lots of messages without
writing out lots of files and using an ever increasing amount of disk
space.
Any issue with file write contention here as BizTalk multi-threads or will
that take care of itself? Something to think about as I've only tested
this
in Dev under light load. Although hopefully my suspended message traffic
isn't too heavy.
I used a custom pipeline to wrap an envelope around the message to capture
the error information, but no custom pipeline component.
And yes, you're right about the messages being connected. I subscribe to
the
error message and that results in no suspended messages. Once I have my
SuspendedMessageConsumer Send ****t set up, I can resume a previously
suspended message and it gets consumed and that cleans up the
non-resumable
error message as well.
Thanks for your help.
Zoe
"Richard S*****er" <RichardS*****er@[EMAIL PROTECTED]
> wrote in
message news:4D6772A4-FBC7-484D-A7D4-D0D556740B4A@[EMAIL PROTECTED]
>I thought those two messages were tied together. That is, if you deleted
>the
> resumable message, the non-resumable error re****t was deleted too.
>
> That said, per your first response, the "eater" is simply a custom
> pipeline
> component where the "execute" method simply returns null. If you create
a
> custom send pipeline that uses that component, when a message comes into
> the
> pipeline, nothing comes out. So, if you had a send ****t using this
> pipeline,
> and this send ****t subscribed on "errorre****t.errortype = 'xyz' " then
> these
> left over SOAP exception messages should be cleaned up.
> --
> Richard S*****er
> http://s*****er.wordpress.com
>
>
> "Zoe Hart" wrote:
>
>> 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
>> >>
>> >>
>> >>
>>
>>
>>
|
