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
|
