Introduction to Hosting Windows Workflow Foundation

 

Moustafa Khalil Ahmed
Program Manager
Microsoft Corporation

August 2006

Applies to:
   Windows Workflow Foundation
   Microsoft .NET Framework 2.0
   Microsoft .NET Framework 3.0

Summary: Provides an overview of how an application hosting Windows Workflow Foundation (WF) can manage and monitor running workflows and gives an overview of the runtime services and their out-of-box implementations. Readers should be familiar with the Microsoft .NET Framework, C#, and the WF programming model. (16 printed pages)

Contents

Introduction
Managing Workflow Instances Life Cycle
Manageability and Monitoring
Reliability and High Availability
Base Runtime Services
Conclusion
For More Information

Introduction

This article is intended for developers who use Windows Workflow Foundation (WF) to help them understand the different options available for enabling their applications to manage and monitor running workflow instances. The article assumes the reader has a basic understanding of the Microsoft .NET Framework, C#, and WF.

WF consists of an activity library and a framework, a runtime engine, and a runtime services components that must run within a host application process. Workflows are constructed as a set of activities that are executed by the runtime engine. The runtime engine must run within a host application process. The following illustration shows how workflows, activities, and the workflow runtime engine are all hosted in process with a host application.

Figure 1. Windows Workflow Foundation host process

WF provides a runtime engine, which is responsible for workflow execution and state management. The WF runtime can be hosted in any .NET process, including ASP.NET, Windows Services, console applications, and Windows Forms applications. The developer is responsible for writing this host process when building a workflow-enabled application. The runtime services work in the host process to provide additional functionality to the runtime engine as it manages the execution of workflows.

There are many issues to consider when you implement a host application for WF. This article provides an overview of how the host application can manage and monitor workflows, and a summary of the base runtime services and their out-of-box implementations.

Managing Workflow Instances Life Cycle

WF provides out-of-box activities and control operations methods on the WorkflowInstance class to manage the workflow states and life cycle. The Managing Workflow Instances Life Cycle section describes the various workflow instance-specific run-time events and the transitions between those events and their relationship to the workflow states.

Persistence Points

Workflows are frequently long running and effectively idle, waiting for an input from a user or other systems to continue. Because it is impractical to hold the idle workflows in memory, it is recommended that you persist the workflow instance state to a storage medium until the workflow receives the event that it is waiting for. Additionally, saving the workflow instance state helps to resume the workflow from that point in case of a failure later in the process.

Figure 2 describes how you can use persistence points to resume running workflow instances.

Figure 2. Using persistence points to resume running workflow instances

If a workflow instance state is persisted at point B, and a failure occurs at point C, your application can resume the workflow instance from point B without losing the work done between points A and B. However, if a persistence service is not available or the workflow instance state is not persisted, the work done from point A to B is lost.

If a WorkflowPersistenceService is present (that is, added to the WorkflowRuntime instance) the workflow runtime engine uses this service to persist workflow instance state to a storage medium. This might occur at the following points:

• On the completion of activities that are marked with the PersistOnCloseAttribute (for example, transaction scope activities)
• Before workflow instance completion
• Before workflow instance termination
• When the workflow goes idle
• When WorkflowInstance.Unload or WorkflowInstance.TryUnload are called

The WF runtime engine calls the SaveWorkflowInstanceState() method on the WorkflowPersistenceService to save the workflow instance state. It calls the LoadWorkflowInstanceState() method to retrieve the workflow instance 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 the workflow instance ID are serialized and saved to the persistence store. In addition, all other necessary information to resume the workflow instance execution (for example, queues) is included in the serialized, saved state.

Workflow Instance Events

A workflow instance can be in one of five states: Created, Running, Suspended, Completed, and Terminated. Workflows have 13 events that occur throughout the lifetime of the workflow instance. Those events can indicate a transition to a different state. For example, the WorkflowCompleted event indicates that the instance has transitioned from Running to Completed. Some events do not indicate that the instance has transitioned to a different state. For example, the WorkflowPersisted event indicates that the instance is Persisted but still in the Running state. Of those 13 events, 11 are communicated to the host application via runtime events and tracking workflow events. Two events, Changed and Exception, are communicated to the host application via the tracking workflow events only.

WF provides control operations methods on the WorkflowInstance class to enable host applications to manage the workflow life cycle. In addition, an application can set policies to manage the workflow life cycle. For example, an application can have unload policies to instruct the WF engine to unload workflow instance. WF provides out-of-box activities that can affect the workflow instance stats. For example the SuspendActivity and the TerminateActivity activities can be used to suspend and terminate the workflow instance respectively. The following sections describe various workflow instance-specific events that are raised by the workflow runtime to communicate workflow instance events and stat transitions of the workflow instance.

WorkflowAborted

A workflow instance is considered to be aborted when the workflow runtime engine throws away the in-memory instance. The host applications can abort the workflow instance by calling WorkflowInstance.Abort(). Aborted workflow instances can be resumed from their last persistence point by calling WorkflowInstance.Resume(). Aborting a workflow instance is used in extreme situations where an application decides to discard all the work that was done from the last persistence point until WorkflowInstance.Abort() is called.

WorkflowCompleted

A workflow instance is completed when the instance finishes executing. At that time, the host application can examine the queues for messages and other events that were not consumed by the workflow instance.

WorkflowCreated

A workflow is created when the instance is completely constructed, but before activities start to execute. The workflow instance is created by calling any of the several WorkflowRuntime.CreateWorkflow() overloaded methods.

WorkflowIdled

The workflow instance is idle when it is waiting for an external event (timer, message, or other custom events) to continue execution. To save system resources, an application can set its unload policy to unload the workflow instance from memory when it is idle. If the host application is using the out-of-box SqlWorkflowPersistenceService, you can set an UnloadOnIdle flag in the application configuration file to instruct the WF runtime engine to persist the workflow state when the instance is idle.

WorkflowLoaded

The WorkflowLoaded event is raised when the instance state is loaded into memory from a persistence store.

WorkflowPersisted

When either the out-of-box SqlWorkflowPersistenceService or a custom persistence service has been added to the WorkflowRuntime instance, the workflow instance is persisted when the workflow instance state is saved to the persistence store.

WorkflowResumed

The workflow instance is resumed when WorkflowInstance.Resume() is called on a suspended or aborted workflow instance.

WorkflowStarted

The WorkflowStarted event is raised when WorkflowInstance.Start() is called. The workflow started event is raised before the workflow runtime engine starts executing workflow activities.

WorkflowSuspended

Suspending the workflow instance is done via a WorkflowInstance.Suspend() call or when a SuspendActivity activity executes. As a result, the workflow instance is in a suspended state.

WorkflowTerminated

Terminating the workflow instance is done via a WorkflowInstance.Terminate() call, when a TerminateActivity activity executes, or when an unhandled exception occurs in the running workflow instance. After this event is raised, the workflow instance is in the terminated state.

WorkflowUnloaded

The WorkflowUnloaded event is raised when the workflow instance is unloaded from memory to a persistence store. This is done depending on the persistence policy, or via a call to WorkflowInstance.Unload() or WorkflowInstance.TryUnload().

Workflow Instance Events Transitions

The workflow instance events are communicated to the host via workflow runtime events and tracking workflow events. The host application can subscribe to runtime events or use a tracking service to be notified. Exception and Changed events are only communicated to the host application via the tracking services. An Exception event indicates that an exception occurred while executing the workflow instance. A Changed event indicates that the workflow instance was dynamically updated while executing.

Figure 3 illustrates the transitions between various workflow events and the workflow states.

Figure 3. Transitions between workflow events and states (click image to enlarge it)

If a persistence service is enabled, the persistence points occur as shown in Figure 3. Those host applications should expect to see WorkflowPersisted, WorkflowUnloaded, and WorkflowLoaded events when applicable. If the workflow instance is not in memory, and a persistence service is enabled, any valid operations on the instance (Resume, Abort, Terminate, and so on) cause the workflow instance to load first, and then continue fulfilling the request. For example, if you have a suspended but unloaded workflow instance, calling Resume on it causes it to load first and then continue to raise the Resumed event as indicated in the diagram.

Workflow Instance Operations

As previously discussed, the WorkflowInstance class has methods for controlling the life cycle of the workflow instance. This section describes these methods.

WorkflowInstance.Start()

Starts the execution of the created workflow instance. WorkflowInstance.Start() causes the workflow runtime to raise the WorkflowStarted event, and the workflow instance is in a Running state. An InvalidOperationException is thrown if Start() is called on an already-started workflow instance.

WorkflowInstance.Abort()

Aborts the workflow instance. When the abort is successful, the workflow runtime raises the WorkflowAborted event.

WorkflowInstance.Load()

Loads an unloaded workflow instance from a persistence store into memory. The instance is then scheduled for execution from the state it was in before it was unloaded. When the loading is successful, the workflow runtime raises the WorkflowLoaded event.

WorkflowInstance.Resume()

Resumes (continues execution of) a suspended or aborted workflow instance. The workflow runtime raises the WorkflowResumed event just before execution of the workflow instance is resumed.

WorkflowInstance.Suspend()

Suspends the execution of the workflow instance. When the call to WorkflowInstance.Suspend() is successful, the workflow runtime raises the WorkflowSuspended event.

WorkflowInstance.Terminate()

Terminates the workflow instance and clears the in-memory workflow instance. The workflow runtime informs the registered persistence service that the workflow instance has been cleared from memory. For the SqlWorkflowPersistenceService, this means that all state information for that workflow instance is deleted from the database upon termination. You cannot reload the workflow instance from a previously stored persistence point. When WorkflowInstance.Terminate() is successful, the workflow runtime raises the WorkflowTerminated event.

WorkflowInstance.Unload()

Unloads the workflow instance from memory to the persistence store. WorkflowInstance.Unload() is synchronous. It blocks until the currently scheduled work is finished, or the end of a transaction scope is reached, in order to perform the unload successfully. When WorkflowInstance.Unload() is successful, the workflow runtime raises the WorkflowUnloaded event. An InvalidOperationException is thrown if Unload() is called when there is no registered persistence service.

WorkflowInstance.TryUnload()

Unlike WorkflowInstance.Unload(), WorkflowInstance.TryUnload() does not block until the workflow can be unloaded. WorkflowInstance.TryUnload() unloads the workflow instance from memory to the persistence store and returns true when the instance is suspended or idle. Otherwise, the call returns false. An InvalidOperationException is thrown if TryUnload() is called when there is no registered persistence service.

See the Windows Foundation SDK for more information about various control methods on WorkflowInstance.

Manageability and Monitoring

The applications that host workflows are responsible for managing and monitoring the workflows that they host and execute. WF provides the support for various manageability and monitoring tools. For example, WF provides end-to-end tracing that you can use for low-level debugging and also tracking infrastructure for workflow data extraction and monitoring.

This section discusses the manageability and monitoring infrastructure in place and how to use it in your host applications.

Tracking

WF provides a tracking infrastructure for capturing workflow, activity, and user events and data while workflow instances execute. Any workflow runtime instance can have multiple registered tracking services, or none. The tracking information is sent to the registered tracking services. The tracking services are responsible for storing and processing this information per the needs of the host application. WF provides an out-of-box SQL-based tracking service (SqlTrackingService) that a host application can use. In addition, host application developers can write their own custom tracking services and use them for host applications.

You can use tracking to examine the history of your workflow instance execution and determine the current state of the workflow instances running on your system. In addition, tracking can provide information that you can use together with the workflow definition to predict the future expected execution paths of workflow instances that are running on the system. WF provides an application sample, Workflow Monitor Sample, which uses the out-of-box SqlTrackingService and the workflow designer controls to display workflow and activity status information about completed and currently executing workflows.

For more information about monitoring workflows by using tracking, see the Workflow Monitor SDK Tool in the Applications Samples/Workflow Monitor Sample. For examples that show how to build a custom tracking service, see the ConsoleTrackingService Sample and File Tracking Service and Query Sample in Technology Samples/Tracking. For examples that show how to use the out-of-box SqlTrackingService, see the Simple Tracking Sample and Query Using SQLTrackingService Sample in Technology Samples/Trackingout-of-box.

Tracing and End-to-End Tracing

You can use traces to monitor the health of your application, and isolate and fix problems without disturbing a running system. WF uses System.Diagnostics APIs to trace information about workflow runtime and workflow instance execution, including rule set evaluation information. By default, the traces are turned OFF, but you can turn them ON if you want.

In addition, WF participates in end-to-end tracing. The end-to-end tracing capabilities enable trace viewers to view continuation tracing information across various components, and the transitions between those components. This facilitates end-to-end debugging.

If you are using an application configuration file, you must add the following to enable logging tracing for several WF namespaces:

<system.diagnostics>
    <switches>
        <add name="System.Workflow LogToTraceListeners" value="1" />
        <add name="System.Workflow.Runtime" value="All" />
        <add name="System.Workflow.Runtime.Hosting" value="All" />
        <add name="System.Workflow.Runtime.Tracking" value="All" />
        <add name="System.Workflow.Activities" value="All" />
        <add name="System.Workflow.Activities.Rules" value="All" />
    </switches>
</system.diagnostics> 

When LogToTraceListeners is used, WF enumerates each TraceListener that is created within your host application and sends all logging information to them. The remaining lines in the example let you specify the namespaces to capture logging information for and also the amount of information that is traced. The possible values for the value attribute include All, Off, Critical, Error, Warning, Information, and Verbose. See the WF SDK for more information about the use of the value attributes.

Workflow Runtime Events

Runtime events are raised by the workflow runtime and provide the host application with the means to manage the life cycle of workflow runtime and workflow instances. The event handlers are defined on the WorkflowRuntime class, and the host application must subscribe to those events to use them.

Runtime events act as a lightweight notification system when the host application needs to act on a specific event rather than store those events and their associated data for querying purposes. For the latter, it is advised that you use the tracking infrastructure.

An instance of WorkflowRuntime might be running multiple workflow instances; each workflow instance has its own life cycle. Therefore, the event arguments for workflow instance events contain the workflow instance ID and other information. This information could be used to correlate the event with the workflow instance that is causing the workflow runtime to raise this event.

The following sections describe the available workflow runtime events.

WorkflowRuntime.ServiceExceptionNotHandled

This event is raised when the service-owned thread throws an exception. A service that is derived from the WorkflowRuntimeService class can call the RaiseServicesExceptionNotHandledEvent() method to inform subscribers to the ServicesExceptionNotHandled event that an exception occurred during its execution, and that it was unable to handle this exception. The out-of-box services raise this event in such conditions. The host application can subscribe to this event to implement a recovery mechanism. The event argument that is associated with this event is ServicesExceptionNotHandledEventArgs.

WorkflowRuntime.Started

This event is raised when the specified instance of the WorkflowRuntime starts. The event argument that is associated with this event is WorkflowRuntimeEventArgs.

WorkflowRuntime.Stopped

This event is raised when the specified instance of the WorkflowRuntime stops. The event argument that is associated with this event is WorkflowRuntimeEventArgs.

Table 1. WorkflowInstanceEvents

Event	Description	Event Argument
WorkflowAborted	Raised when the workflow instance is aborted.	WorkflowEventArgs
WorkflowCompleted	Raised when the workflow instance is completed.	WorkflowCompletedEventArgs
WorkflowCreated	Raised when the workflow instance is completely constructed, but before activities are processed; that is, before the workflow starts executing.	WorkflowEventArgs
WorkflowIdled	Raised when the workflow instance enters an idle state; that is, the workflow instance is waiting for an external event (for example, a timer, message, and so on) to continue execution.	WorkflowEventArgs
WorkflowLoaded	Raised when the workflow instance is loaded into memory, usually from a persistence store.	WorkflowEventArgs
WorkflowPersisted	Raised when the workflow instance is persisted.	WorkflowEventArgs
WorkflowResumed	Raised when the workflow instance is resumed, usually from a suspended or an aborted state.	WorkflowEventArgs
WorkflowStarted	Raised when the workflow instance starts executing.	WorkflowEventArgs
WorkflowSuspended	Raised when the workflow instance is suspended.	WorkflowSuspendedEventArgs
WorkflowTerminated	Raised when the workflow instance is terminated.	WorkflowTerminatedEventArgs
WorkflowUnloaded	Raised when the workflow instance is unloaded from memory to a persistence store.	WorkflowEventArgs

See the "Managing Workflow Life Cycle" section earlier in this article for more information about various events and how the workflow enters various states.

See the Windows Workflow Foundation SDK Samples for information about how to use various workflow runtime events.

Performance Counters

You can monitor workflow performance by using the Windows performance tool. It is composed of two parts: System Monitor, and Performance Logs and Alerts. Through Performance Logs and Alerts, you can configure performance counters to record performance data and set system alerts to notify you when a specified counter's value is above or below a defined threshold.

WF provides a set of performance counters with the WF performance object that you can use to track the performance of a workflow. See the Workflow Performance Counters section in the WF SDK for a complete list of performance counters.

For the details of how to add performance counters to the Performance tool, see the Microsoft TechNet Web site.

Unload Policy

Systems could have thousands of workflows running simultaneously at a given time. It can become impractical to allow all of them to remain in memory. To better manage a system's resources, you can set an unload policy to persist workflow states and unload them from memory.

WF provides an unload on idle policy if you use the out-of-box persistence service. The policy is active when you set the UnloadOnIdle property on the SqlWorkflowPersistenceService class to instruct the runtime engine to unload the workflow when it is idle. If the host application is enabling the SqlWorkflowPersistenceService via a configuration file, you could do this by setting the UnloadOnIdle flag to true. If the SqlWorkflowPersistenceService is constructed and enabled via code, the host application must construct it using the SqlWorkflowPersistenceService (String, Boolean, TimeSpan, TimeSpan) constructor. Your host application could implement other complex unloading policies.

In addition, you can call the WorkflowInstance.Unload() method to request to unload this specific workflow instance from memory and persist its state. The host application can later call the Load() method on the instances to continue executing them from the last persistence point. When workflow instances are unloaded, a runtime event, the WorkflowUnloaded event, is raised.

Reliability and High Availability

WF supports hosts that choose to be reliable and highly available by providing support for the following:

SQL Clustering

Out-of-box SQL-based services support clustering installation. The WF out-of-box SQL-based services provide retries when committing the batch to SQL Server. Therefore, support fail over scenarios or temporarily inaccessible SQL servers. The retry logic can be set on a combination of any of the following services:

• DefaultWorkflowCommitWorkBatchService
• SharedConnectionWorkflowCommitWorkBatchService
• SqlTrackingService
• SqlWorkflowPersistenceService

By default, the retry logic is OFF. The host application must explicitly turn the retry logic ON to use the feature. Applications can choose to enable retries per service or on all the services previously mentioned. You can do this by setting the EnableRetries property on the services classes, or via the configuration file. With a configuration file, the host application can use a shared flag, EnableRetries, to set enable retries to ON or OFF on all affected services. If the EnableRetries property is set on a service, its value overwrites the EnableRetries shared flag value. The WF out-of-box SQL-based services retry for a constant number of times. The number of retries is not configurable. However, applications can adjust the connection time-out in the services' connection string to partially adjust the time between retries.

Setting Retries

The following example shows how to set EnableRetries for all out-of-box services by adding a common parameter, EnableRetries, and setting its value to True. It shows how you can disable EnableRetries for the SqlWorkflowPersistenceService by adding an EnableRetries flag for this service and setting it to False.

<WorkflowRuntime Name="SampleApplication" UnloadOnIdle="false">
    <CommonParameters>
        <add name="ConnectionString" value="Initial Catalog=WorkflowStore;Data Source=localhost;Integrated Security=SSPI;" />
        <add name="EnableRetries" value="True" />
    </CommonParameters>
    <Services>
        <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, 
System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35" EnableRetries="False"  />
    </Services>
</WorkflowRuntime>

Generally, it is recommended that you set retries on all services to either ON or OFF.

Note that the WorkflowCommitWorkBatchService class is responsible for retrying all non-TransactionScopeActivity activities' related batch commits (persistence points). The WorkflowCommitBatchService class cannot do retries of work batch commits for the TransactionScopeActivity activities. This is because in this case, it did not start the transaction and therefore does not own it. Retries of work batch commits for TransactionScopeActivity activities must be modeled into the workflow. This is usually done in the form of a while loop and an exception handler outside the TransactionScopeActivity.

Retries on the out-of-box SqlTrackingService, if run in a non-transactional mode, and the out-of-box SqlWorkflowPersistenceService controls SQL-related work that is unrelated to work batch commits. This includes checking for expired timers and loading workflow instances.

Load Balancing and Front-End Scaling

The application that is hosting WF is responsible for managing load balance scenarios and front-end scaling scenarios. WF provides support in the engine and out-of-box SQL-based services to enable different host application instances to point to the same persistence or tracking SQL databases.

If you have multiple host applications connected to the same persistence store, any of them could load any workflow instance type from the database. WF out-of-box SqlWorkflowPersistenceService does not support assignment of workflow types or instances to be loaded on specific hosts when they share the same persistence store. You need to implement a custom persistence service if this behavior does not meet your host application needs.

The WF runtime engine provides locking semantics to support front-end scaling scenarios when multiple host applications use the same persistence store. The locking semantics prevents applications from loading a workflow instance that was already loaded by another application. The WorkflowPersistenceService class enables you to support this workflow runtime engine functionality by providing a parameter to the SaveWorkflowInstanceState() method 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() method should lock the state information for a workflow instance.

See the Windows Workflow Persistence Services and Creating Custom Persistence Services sections in the WF Programming Guide for more information about workflow instance locking semantics.

Base Runtime Services

The WF runtime engine executes workflows by using runtime services. The runtime service model gives the host application the flexibility to provide various services to the WF runtime engine. This section describes the runtime services that are provided by WF and the out-of-box implementations of those services.

See the Windows Workflow Foundation Services and Developing Windows Workflow Foundation Services sections in the WF Programming Guide for more information about the runtime service implementations.

The WF runtime provides four services. These services have out-of-box implementations, or, host applications can implement their own services and provide them to the workflow runtime.

Workflow Transaction Services

The purpose of the Windows workflow transaction services (WorkflowCommitWorkBatchService) is to enable custom logic regarding the commitment of work batches (also known as persistence points). When a work batch is committed, the runtime calls into the current transaction service and passes a delegate to call to do the actual committing of the work batch. The runtime still must do the commit, but letting a service insert itself into the process enables some customization around the commit process.

The WF framework does not support the ability to bring your own transaction from the outside into a workflow instance. The only types of ambient transactions supported by the WorkflowCommitWorkBatchService are transactions that are originated by the workflow instance. Ambient transactions that are originated by the host application executing the workflow runtime are temporarily removed from the current thread to reduce their side effects. After the workflow is idle, the host application original ambient transaction contained by is placed back in the thread.

WF provides two out-of-box implementations for transaction services: DefaultWorkflowCommitWorkBatchService and SharedConnectionWorkflowCommitWorkBatchService.

The WF runtime engine requires a workflow transaction service. By default, it uses the DefaultWorkflowCommitWorkBatchService. The host application can choose to replace the DefaultWorkflowSchedulerService with SharedConnectionDefaultWorkflowCommitWorkBatchService or with a custom service.

DefaultWorkflowCommitWorkBatchService

When workflow runtime engine starts, an instance of DefaultWorkflowCommitWorkBatchService is created and added to WorkflowRuntime if no other transaction service is added. This service creates .NET Framework transactions for each database connection. For example, connections between SQL Tracking Services and SQL Persistence Services are not shared. You can use this service in your workflows to support transactions that are needed for data integrity.

SharedConnectionWorkflowCommitWorkBatchService

This service is used for database transactions that use a shared connection between different objects. If the host application wants to use this service, it should add it to WorkflowRuntime by using the AddService method, or via the configuration file.

Workflow Scheduler Services

Workflow Scheduler Services manage how workflow instances are scheduled by the workflow runtime engine, whether they are handled in an asynchronous or a manual synchronous mode. WF provides two out-of-box implementations for the WorkflowSchedulerService: DefaultWorkflowSchedulerService and ManualWorkflowSchedulerService.

The WF runtime engine requires a workflow scheduler service to execute workflows. By default, it uses DefaultWorkflowSchedulerService. The host application can choose to replace the DefaultWorkflowSchedulerService with ManualWorkflowSchedulerService or a custom service.

DefaultWorkflowSchedulerService

DefaultWorkflowSchedulerService creates and manages the threads that run workflow instances in an asynchronous manner on the workflow runtime engine and includes default support for having multiple workflow instances queued in the runtime thread pool. If no other workflow scheduler service instance is added to WorkflowRuntime, it uses the DefaultWorkflowSchedulerService by default.

ManualWorkflowSchedulerService

ManualWorkflowSchedulerService is used for synchronous execution of workflow instances. If this service is being used, the workflow instances are executed on the calling thread from the host application, thus blocking the execution of the host application until the workflow instance becomes idle.

Workflow Persistence Services

Persistence services are responsible for storing and retrieving (loading and unloading) workflow instance state. WF provides an out-of-box SQL-based implementation of the persistence service: SqlWorkflowPersistenceService.

SqlWorkflowPersistenceService

This out-of-box implementation stores the state and timer information to SQL Server/MSDE. The SqlWorkflowPersistenceService participates in the workflow transactions and implements locking access. In addition, SqlWorkflowPersistenceService provides functionality to enable retries when the SQL server is unavailable. This can be controlled by setting the EnableRetries property on the service. For more information about the SqlWorkflowPersistenceService, see the WF Programming Guide.

Workflow Tracking Services

Tracking services manage tracking profiles and storage of tracking information. WF provides an out-of-box SQL-based implementation of a tracking service implemented in the SqlTrackingService class.

SqlTrackingService

This implementation stores the tracking profiles and data to SQL Server/MSDE. The service supports the following:

• Participates in workflow transactions by default; the behavior is controlled by the SqlTrackingService.IsTransactional property.

• Provides a mechanism to use default tracking profiles for all types or associate tracking profiles per workflow types, or workflow instances.

• Supports data maintenance by providing live and on-demand partitioning functionality.

  Detailed information about data maintenance is provided in the Data Maintenance with SqlTrackingService section in the WF Programming Guide.

In addition, WF provides SqlTrackingQuery APIs that you can use to query the tracking data stored in the SqlTrackingService. For more information about the SqlTrackingService, see the WF Programming Guide.

Conclusion

WF provides a runtime engine and services to execute workflows and manage their state. A host application or a process must be written to host WF workflows. This host application is responsible for providing various runtime services to the workflow runtime engine. The WF out-of-box runtime services are meant to address common scenarios. However, if the out-of-box services do not meet the host application's needs, the host application should implement custom services and supply it to the workflow runtime.

Additionally, WF provides infrastructure to manage and monitor running workflow instances and to support host applications that choose to be reliable and highly available. The host applications should decide how to use the various options based on their hosting-specific scenarios.

For More Information

This article, together with the following resources, should help developers who are new to workflow technology learn about the technology and quickly become productive in using it.

• MSDN Workflow Developer Center
  • Contains documents and links to webcasts and labs.
• Community Site Samples
• Windows SDK Documentation
  • If you do not have the Windows Foundation SDK, please download it from the Windows SDK site.The Windows Workflow SDK is part of Windows SDK. It contains WF Programming Guide References, API References, and various Technology and Application Samples.
• MSDN Workflow Forum
  • Discussion forum that can provide answers to questions related to WF runtime hosting or WF in general.

 

About the author

Moustafa Khalil Ahmed is a Program Manager with the WF team at Microsoft Corp., Redmond, WA. Since joining Microsoft in 2000, he has been working on the development of various server components and has helped ship four server products, including Microsoft BizTalk Server. Prior to working at Microsoft, Moustafa was a Software Engineer, Business Analyst, and Account Manager at ITWorx, Cairo, Egypt.