Patterns for Fault Handling Transition in State Machine

Fault handling is one of the few things that people have asked about in WF4 StateMachine.  The most common scenario is to catch an exception when the StateMachine is executing, and then, do either of the followings:

• Remain in the current state
• Jump to a Fault-Handling state and complete the workflow gracefully and restart again.

However, there is no built-in fault-tolerant mechanism in StateMachine.  And there are very good reason for that.  One, we want to keep StateMachine simple (so it is as easy to understand as Flowchart).  Secondly, we really want all the movements within a StateMachine to be driven by Transitions – so if you do implement some fault-handling mechanism, you should be able to draw it in a State diagram and implement it.

Long ago, I did a very small doc on fault-handling.  Assuming most of the heavy-lifting of StateMachine happens in Trigger, you can put a Try-Catch in a Trigger and then StateMachine scheduling mechanism should do all other things for you (so you don’t need to schedule activity yourself.

Fault Handling Pattern for Non-Shared Receive/SendReply transition using Try-Catch Handler by adding a Shared Trigger transition

Step 1: Create a boolean value with “True” default value. Encapsulate a Try-Catch to the current operation in the Trigger. In the original “Condition” section, specify the boolean variable there.  Under normal condition, this variable should always be true, so the State would transition out as normal.
Step 2: In the Catch block, you define the Exception that you want to catch, and also the error-handling logic.  The boolean variable would be assigned to ”false”. So if an exception happened, the boolean variable would be ‘false’.  In this case, no transition would happen and the StateMachine would remain in the current State
Optional Step 3: If you want the StateMachine to transition to an error handling state, then you simply create a shared triggered transition out of the current state.  In this Transition, the condition if the negation of the boolean variable.  So it would transition out if an Exception occurs!

The good thing about this approach is that you can re-use the execution mechanism to prevent a StateMachine from transition.  The constraint though, is that it requires your Trigger to be non-shared.  I would imagine that this approach would be more useful in Workflow Service scenario (where each “Receive” activity is its own transition). 

However, if you already have a shared trigger and you want to handle error this transition, what can you do?  The most elegant way that I could think of (at the same when I was drafting it) was to use an intermediate state to catch the error:

Fault-Handling Pattern with Shared Trigger with one Receive and Multiple Fault-Handling SendReply by Using Null Trigger

Between the original Source and the Destination State, create two State: 1. One "immediate" state designed to evaluate the result of the Action 2. Another "fault-handling" state that could be the destination of the "immediate" state
Within the original transition, if we want to handle any potential fault from Transition.Action activity: 0. encapsulate any activity with a Try-Catch activity 1. In the Catch block, have an "Assign" activity that would set a flag to false (NOTE: because this flag must be shared between two states, it has to be declared at the StateMachine level) 2. The Transition is target at the immediate "Verifying state"
Within the Fault-Decision State: 1. Create a Null-Trigger transition, that would transition to original Destination state if the result is "true" (by default) 2. If the flag is evaluated to "false", transition to the Fault-Handling (i.e "Bad State", or event the original State)

See if these patterns would be helpful to you!

Isaac @ Shanghai

Comments

• Anonymous
  September 13, 2011
  The comment has been removed