Windows Workflow Persistence Services

Many business processes take long periods of time to complete (up to many months or even years). Holding the workflow in memory is not only impractical (because of memory limitations), but it also prevents scaling because an instance must be processed on a single server. Many of these long-running workflows are not actively executing flow or process logic and are effectively idle, waiting for input from users or other systems. By unloading an idle instance, the host application can save memory and enable scalability across processing servers.

When certain conditions occur while a workflow is running, the workflow runtime engine uses a persistence service, if one is loaded in the runtime, to persist state information about the workflow instance. These conditions include such things as the following:

• When atomic transactions in TransactionScopeActivity activities and CompensatableTransactionScopeActivity activities are completed.

• When a workflow instance becomes idle and the UnloadOnIdle flag is set to true for a WorkflowPersistenceService. This occurs, for example, when you use a DelayActivity activity.

• When the runtime host application calls System.Workflow.Runtime.WorkflowInstance.Unload or System.Workflow.Runtime.WorkflowInstance.TryUnload on the workflow instance.

• When a workflow instance is terminated or finishes.

• When a custom activity using the PersistOnCloseAttribute attribute completes

If one of these conditions is met and a persistence service is added to the runtime engine, the runtime engine calls methods that are supplied by the persistence service to save state information about the workflow instance. Similarly, when the workflow runtime engine has to restore a previously persisted workflow instance, it calls methods that are supplied by the persistence service to load this state information. In other words, the workflow runtime engine determines when persistence should occur, but it is up to a persistence service to perform the necessary persistence operations.

Another piece of workflow state managed by the SqlWorkflowPersistenceService is Timer information. Every time you configure a DelayActivity activity inside your workflow definition and use a persistence service like the SqlWorkflowPersistenceService, the time span information associated with the activity is persisted as part of the workflow state. Every time the workflow instance is evaluated by the workflow runtime, pending timer events are processed.

Creating Persistence Services

You can create a persistence service by deriving a class from the WorkflowPersistenceService class. You can add your persistence service to the workflow runtime engine by calling AddService or by making an appropriate entry in the application configuration file. Windows Workflow Foundation provides the SqlWorkflowPersistenceService class, an out-of-box persistence service, which you can use as is or extend. For more information about creating a custom persistence service, see Creating Custom Persistence Services. For more information about using the SqlWorkflowPersistenceService class, see Using SqlWorkflowPersistenceService.

Note

.The WorkflowRuntime must only contain one persistence service.

Locking Workflow State Information

The workflow runtime engine has semantics for locking workflow state information for use in environments where persistence services that are running in different processes might have access to a single data store. The WorkflowPersistenceService class enables you to support this functionality of the workflow runtime engine by providing a parameter to SaveWorkflowInstanceState that specifies whether the state information of a workflow instance should be unlocked in the data store, and by providing the UnlockWorkflowInstanceState method to unlock previously locked workflow state information. In a persistence service that implements locking, a call to LoadWorkflowInstanceState should lock the state information for a workflow instance.

When you create your own persistence service, throw a PersistenceException if the service does not save state information to its data store or load state information from its data store. The workflow runtime engine expects this behavior.

Persistence Service Batching Behavior

A batching mechanism is provided for services that use a durable store to save workflow state information. It is important in these cases to maintain consistency between the durable store that is used by the persistence service and the internal state of the workflow runtime engine. You can add functionality that is defined by the IPendingWork interface to your service, and then participate in workflow transaction batching that is provided by the WorkflowCommitWorkBatchService service by adding changes to your data store as work items to the WorkBatch. For more information, see SaveCompletedContextActivity or SaveWorkflowInstanceState.

Complex Hosting Scenarios

A possible scenario for deployment of Windows Workflow Foundation solutions is to create multiple host applications, each with a different set of services that are running on different desktop and server configurations. Under such a scenario, a requirement may be that some workflows that are defined in the solution can only execute on certain systems. The out-of-box services in Windows Workflow Foundation, such as the SqlWorkflowPersistenceService service, do not support this kind of configuration. To control which workflow instances load on which systems, you must create a custom persistence service. For more information, see Creating Custom Persistence Services.

See Also

Reference

SqlWorkflowPersistenceService
SqlPersistenceWorkflowInstanceDescription
WorkflowPersistenceService
WorkBatch

Concepts

Using SqlWorkflowPersistenceService
Creating Custom Persistence Services

Other Resources

Windows Workflow Foundation Services
Exercise 4: Use Runtime Services
Using Persistence Services