I am fortunate to be a speaker at TechEd New Zealand and TechEd Australia this week. One of the sessions I am presenting on is “Building Human Workflows with Windows Workflow Foundation State Machines”. Admittedly, I am standing on the shoulders of giants as I borrowed the code and slides from Keith Pijanowski.
Those that have seen me speak on WF in the past know that I gush over the great work that Keith has done in this area, including his MSDN article, “Building State Machines with Windows Workflow Foundation“. This article and the code are fantastic resources for understanding the ExternalDataExchange mechanism in WF. His updated code (available here) includes a nice example of how to use tracking to reach into the workflow and find information such as what the available state transitions are and what the history of the current state workflow is.
A common question is, “how do you determine if you should use a sequential or state machine workflow?” You will find various answers, but the largest reason that I recognize is the ability to move the pointer back to some earlier point in the workflow. With a sequential workflow, you can’t tell the workflow runtime to move back to the beginning of the workflow and start over… with state machines, this is possible. State machines lend themselves for workflows that include human interaction where sequential workflows lend themselves to workflows that define processes more rigidly (such as system to system workflows).