How to persist BizTalk orchestration before send shape - for resending

Question

I have an orchestration that calls a WCF Service, which is a 2-way request/response send port. Like so:

I've been trying to figure out a way to get the orchestration to persist in a state BEFORE the send shape. This is in hopes that when there are exceptions, or the endpoint is down, I can resume the orchestration and have it try to resend to the endpoint.

I've tried wrapping the send/receive shapes in all sorts of scope shapes in order to get it to persist above the send shape, but to no avail. I've read Seroter's blog up and down and tried all the things suggested in his post:

http://seroter.wordpress.com/2007/01/02/orchestration-handling-of-suspended-messages/

For example, if I take down the endpoint and send to it I get a

System.ServiceModel.ServiceActivationException: The requested service, 'https://my-service.svc' could not be activated. 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.

Which is to be expected. As it says, the instance may re-throw the same exception when resumed (which it does no matter what I've tried).

Things I've tried:

• Wrapping the Send shape in a atomic scope, but it still get suspended after the exception is thrown.
• Wrapping both Send and Receive shapes in atomic scope, but get an error when compiling:

  Error 1 an atomic scope may not contain or call a service or scope that contains both the send and the corresponding receive of a requestresponse operation on a 'uses' port or servicelink

• Tried wrapping the Send and Receive shapes in a Long-Running scope and catching the exception, then using a suspend shape - but this just results in a dehydrated instance that is waiting for a response from the WCF Service.

I'm not sure of anything else I could try. Basically what I'm asking is, how can I get the orchestration to persist at the "conWrapper" (or anywhere above the sendRCMR...) shape seen in the included image?

Answer 1

For what you're describing, you don't really need to force an Orchestration Persistence.

If the endpoint is down, or the Adapter throws any other error, the Messaging instance will first go into retry mode, then suspend. That's likely the 'instance' the error message you included is referring to.

Once the endpoint is running again, you resume the Messaging instance.

This is the most common scenario.

Answer 2

Have a variable defaulted to false.

Put a long running scope around the send/receive shapes and a expression shape that set the variable to true after the send, have catch blocks for all exceptions (usually one for SOAP, one for System.Exception and a General) to send out an alert and then have a suspend shape after the alert is sent.

Around the scope put a looping shape, while false, loop.

This will allow you to resume the Orchestration until it succeeds in sending.