views:

179

answers:

2

Hi . I want to implement a solution in my workflows that will do the following :

In the workflow level I want to implement a Fault Handler that will suspend the workflow for any exception.

Then at sometime the instance will get a Resume() command .

What I want to implement that when the Resume() command received , the instance will execute again the activity that failed earlier ( and caused the exception ) and then continue to execute whatever he has to do .

What is my problem :

  1. When suspended and then resumed inside the Fault Handler , the instance is just completes. The resume of course doesn't make the instance to return back to the execution, since that in the Fault Handler , after the Suspend activity - I have nothing. So obviously the execution of the workflow ends there.

  2. I DO want to implement the Fault Handler in the workflow level and not to use a While+Sequence activity to wrap each activity in the workflow ( like described here: Error Handling In Workflows ) since with my pretty heavy workflows - this will look like a hell. It should be kinda generic handling..

Do you have any ideas ??

Thanks .

A: 

I am afraid that isn't going to work. Error handling in a workflow is similar to a Try/Catch block and the only way to retry is to wrap everything is a loop and just execute the loop again if something was wrong.

Depending on the sort of error you are trying to deal with you might be able to achieve your goal by creating custom activities that wrap their own execution logic in a Try/Catch and contain the required retry logic.

Maurice
Thank you for the answer.Well ... I'm aware of this solution. Yes , this is what is described in many articles on the web .But I'm still looking for an elegant solution of the type I've described.
Alex
+1  A: 

If you're working on State Machine Workflows, my technique for dealing with errors that require human intervention to fix is creating an additional 'stateactivity' node that indicates an 'error' state, something like STATE_FAULTED. Then every state has a faulthandler that catches any exception, logs the exception and changes state to STATE_FAULTED, passing information like current activity, type of exception raised and any other context info you might need.

In the STATE_FAULTED initialization you can listen for an external command (your Resume() command, or whatever suits your needs), and when everything is OK you can just switch to the previous state and resume execution.

axel_c