The tracking service in Windows Workflow Foundation

Directory

Tracking architecture

Tracking configuration Files

SQL Tracking Service

Query trace Data

Custom Tracking Service

One of the most powerful features of Windows Workflow Foundation is tracing. It enables you to monitor events, activity properties, and custom data in your workflow. In this column, I'll examine the tracking infrastructure, show you how to use the built-in SQL Server™ tracking service, and how to create a custom tracking service for a variety of applications. Along this line of thinking, I'll show you how to use tracked information and how to meet some of the common requirements by using tracing.

Many applications need to understand the execution of program logic and processing steps. This helps businesses comply with regulations and manage risk lists based on milestones or other reasons. Windows®workflow Foundation provides a flexible infrastructure in which you can override your custom implementation without creating a different tracking system for each application. This simplifies the development model, allowing you to focus on the business requirements that are tracked.

Tracking architecture

When you host a workflow in Windows Workflow Foundation, you can either host the workflow runtime or host a set of Run-time services. Many run-time services, such as persistence services, must have at most one instance registered in the runtime. The tracking service is an exception that allows multiple tracking services to be added to the runtime to support different business requirements. This enables you to apply a number of different tracking tasks to an application where the tracking service is responsible for a specific implementation.

Tracing in Windows Workflow Foundation is based on a central listener, which monitors activity and workflow events and sends the corresponding data to the tracking service for each configuration. (This architecture is shown in Figure 1.) The trace listener receives notification of all events, but in most cases only one subset of these events is useful. Also, if you are using multiple tracking services, it is possible that each task will focus on only one subset of information. Therefore, the trace listener queries each configuration's tracking service to track the configuration files for each type of workflow.

Figure 1 Tracking architecture

The trace configuration file provides the listener with information about the type of event that the tracking service will receive. These events can be grouped into three categories: workflows, activities, and users.

Workflow events enable you to track the various states that a workflow may be in, and when they occur. For events that contain custom event parameters, such as workflowterminated or workflowcompleted, the event arguments themselves can be tracked and subsequently queried.

Activity events enable you to track when an activity enters a particular state and the specific activity property values when the activity enters that state. For example, if you have an activity that sends e-mail, you can track the to address property when the activity enters the Closed state.

Finally, user events allow you to manually track data in your workflow or activity.