Note – we published an MSDN article that contains the information below and a lot of other related information. See http://blogs.msdn.com/moustafa/archive/2006/09/08/747265.aspx for more details.
Windows Workflow Foundation provides out of box (OOB) Activities and operations methods on Workflow Instance to manage the workflow statuses and lifecycle.
This document will describe the various workflow instance specific runtime events and the transitions between those events and their relationship to the workflow statuses.
If a WorkflowPersistenceService is present (i.e. added to the WorkflowRuntime instance) the workflow instance state is persisted to a storage medium at the following points:
- On the completion of activities which are marked with PersistOnClose (E.g. transaction scope activities)
- Prior to workflow instance completion
- Prior to workflow instance termination
- When the workflow goes idle
- When WorkflowInstance.Unload or WorkflowInstance.TryUnload are called
Windows Workflow Foundation will call appropriate methods on the persistence service to save the workflow instance state and to retrieve the persisted state when needed. The workflow runtime handles all semantics regarding when to perform persistence and the persistence services are responsible for the actual saving and loading of the workflow instance. Activity states and workflow instance ID are serialized and saved to the persistence store. In addition, all other necessary information to resume workflow instance execution (e.g. queues) is included in the serialized, saved state.
Workflow Instance Events
From an end user’s perspective, a workflow instance could be Created, Running, Suspended Completed or Terminated. Internally, Windows Workflow Foundation’s runtime engine has various workflow states throughout the lifetime of the workflow instance. Those states are communicated to the host via Runtime Events and Tracking Workflow Events.
The Windows Workflow Foundation provides operations methods on WorkflowInstance to allow applications to manage the workflow lifecycle. In addition, there are policies that the applications can set (e.g. Unload Policies) and OOB Activities that can affect the workflow instance states. The following is a description of various workflow instance-specific events that are raised by workflow runtime to communicate the internal state of the workflow instance:
A workflow instance is considered Aborted when the WorkflowRuntime engine throws away the in-memory instance. This is done by calling WorkflowInstance.Abort. Aborted workflow instances can be resumed from their last persistence point by calling WorkflowInstance.Resume. Aborting workflows is only valid when there is a persistence service. Aborting workflows is used in extreme situations where applications decide to discard all the work that is done from the last persistence point till abort is called.
A workflow instance is completed when the instances finished executing. At this time, the application can look at the queues that were not consumed by the workflow instance.
A workflow is created when the instance is completely constructed but before activities are processed. That is, before the workflow start executing. The workflow instance is created by calling WorkflowRuntime.CreateWorkflow().
The workflow instance is idle when it is waiting on an external event (e.g. timer, message, etc) to continue execution. An application can set their Unload policy to unload the workflow instance from memory when it is idle in order to save system resources.
The workflow instance is loaded when the instance state is loaded into memory usually from a persistence store.
The workflow instance is persisted when the workflow instance state is saved to a persistence store.
The workflow instance is resumed when WorkflowInstance.Resume is called on the instance in order to resume it from a suspended or an aborted state.
The workflow instance started event is raised when the workflow instance starts executing workflow activities.
Suspending the workflow instance is done via a WorkflowInstance.Suspend call or when a Suspend activity executes will get the workflow in a suspended status.
Terminating the workflow instance is done via a WorkflowInstance.Terminate call, when a Terminate activity executed, or when an unhandled exception occurs in the running workflow instance
The workflow instance is Unloaded when it is unloaded from memory to a persistence store.
Workflow Instance Events Transitions
The following diagram explains the transitions between various workflow events and workflow statuses
If there is a persistence service:
Persistence points will occur as shown
If the workflow instance is not in-memory any valid operations on the instance (resume, abort, terminate, etc) will cause the workflow instance to load first, and then continue fulfilling the request. E.g. if you have a suspended but unloaded workflow instance, calling resume on it will cause it to load first then getting in resumed as indicated in the diagram
Depending on the Unload policy, the workflow instance might get unloaded after getting persisted
Workflow Instance Operations
As previously discussed, WF provides control operations on form of methods on WorkflowInstance to control the workflow instance life cycle. Those methods are:
Starts executing the created workflow instance
Aborts the workflow instance
Loads an unloaded workflow instance from a persistence store into memory. The instance is then schedules for execution from the state it was in before it got unloaded
Resumes (continue execution of) a suspended or aborted workflow instance
Suspends the execution of the workflow instance
Terminates the workflow instance
Unloads the workflow instance from memory to the persistence store, this call will block until after the currently scheduled work is finished or end of a transaction scope
Unloads the workflow instance from memory to the persistence store when the instance is suspended or idle
Please see the Windows Workflow Foundation help for more information on various control methods on WorkflowInstance