This is quite accurate I think - the idea is that you can have retries on
the
send ****t and BizTalk will know how to handle those, but indeed if the
orchestration get's suspended it does so after receiving the response
(albeit
an error one) and so cannot be resumed without development to sup****t
that.
Setting the send ****t to provide delivery notification would allow you to
catch the error in the orchestration and handle it (at a performance cost
though) and in any case it would not help you remain "resumable" so you
will
still need the loop.
--
Yossi Dahan
MVP BizTalk Server
http://www.sabratech.co.uk/blogs/yossidahan
"Zoe Hart" wrote:
> Disclaimer: I am no expert, but I've been asking the same question.
Here's
> what I think the answer is.
>
> You're correct that the orchestration has suspended at a point where it
has
> received the response indicating that the web service is unavailable. So
> when you resume it, it fails again.
>
> There is no quick configuration setting to fix this. The fix involves
> modifying your orchestration to put the web service send and receive in
a
> loop. Also put a scope around them and add an exception handler to the
> scope. You use the exception handler to catch the Soap Exception that
occurs
> when the web service is unavailable. In that catch block you use a
Suspend
> shape to suspend the orchestration. Now when the web service is back up,
you
> resume your orchestration and it loops back up and tries the Send again
(so
> you might not want to resume the suspended Soap Adapter instance so the
> message isn't sent twice).
>
> Of course you'll need some exit criteria for the loop, so you could have
a
> messageSuccess variable initialized to false and loop until it's true.
Put
> an expression shape after the Receive shape that gets the response from
the
> web service and use that to set messageSuccess to true. That way when
you
> get through with no exception you won't loop. Alternatively I guess you
> could initialize messageSuccess to true and then set it to false in your
> catch block. Six of one, half dozen of another.
>
> It seems to me that there ought to be an easier way to handle this not
> uncommon scenario, but from everything I've been told, you have to
> explicitly code your orchestration to handle it.
>
> Maybe others wiser and more experienced will have better suggestions. I
hope
> so.
>
> Zoe
>
> "EllenB" <EllenB@[EMAIL PROTECTED]
> wrote in message
> news:E66F9F24-A412-4AC1-AC7F-FEFD7BFE08A2@[EMAIL PROTECTED]
> > Hi there,
> >
> > Here's my problem. I've got a orchestration which sends a message to a
> > webservice using a very straight forward send-receive pattern. Nothing
> > special there. This works fine without any problems.
> > Now i take down the webservice and i see 2 kinds of suspended Service
> > Cl***** appearing in the MessageBox (as expected). For each message a
> > suspended instance for the Soap Adapter and one for the orchestration.
> > When i
> > enable the webservice again and resume the instances, the Soap Adapter
> > instances are resumed correctly and the message is send to the
webservice
> > correctly but the instance for the orchestration keeps on failing and
> > keeps
> > getting suspended with the same error as if the webservice is still
> > offline.
> > The message is
> >
> > Uncaught exception (see the 'inner exception' below) has suspended an
> > instance of service
> > 'CCC.VIP.VIP1.Biztalk.orchVIP1(5023481b-d86c-91a9-aac1-ac1f2f14753c)'.
> > The service instance will remain suspended until administratively
resumed
> > or
> > terminated.
> > If resumed the instance will continue from its last persisted state
and
> > may
> > re-throw the same unexpected exception.
> > InstanceId: 121a1703-7328-4adf-85e4-bffdcaf847cf
> > Shape name:
> > ShapeId:
> > Exception thrown from: segment -1, progress -1
> > Inner exception: An error occurred while processing the message, refer
to
> > the details section for more information
> > Message ID: {41170AA8-082F-4C13-B786-B75A4B0C1230}
> > Instance ID: {8504D3C1-3AE5-4B81-B174-8E569B1808EF}
> > Error Description: WebException: The request failed with HTTP status
404:
> > Not Found.
> >
> > It looks like the orchestration is suspended at a state where it
already
> > contains the response from the webserver saying that the webservice is
not
> > available and when i resume it evaluates the message again and decides
> > again
> > to suspend. In other words it will never be able to be resumed again
(my
> > humble but hopefully wrong conclusion).
> >
> > How can i prevent this from happening?
> >
> > Thanks very much
> >
> > Ellen
>
>
>
|
