WF Tracking 101

Read on if you want to know what Windows Workflow Foundation Tracking is, what you can use it for, and an overview of its components...

Tracking Defined
Tracking in Windows Workflow Foundation is a feature that allows you to capture specific information about your workflow instances and store them as the instances execute. Tracking allows you to capture Events and data on the Workflow instance level or events and data on the Activity level. You can also send custom tracking data and events from your code beside. Those are known as user events. As a runtime service, you can implement your own tracking service that fits your business needs and supply it to the runtime or you can use the OOB SQL-Based SqlTrackingService.

Tracking Business Usage
Past, Present and Future
As far as how you can use Tracking for your business needs. You can use it to look at the history of your workflow instance execution, you can use it to determine the current status of the workflow instances running on your system – whether they’re running, suspended or terminated. In addition, tracking can also give you information that you can use in conjunction with your workflow definition to predict the future expected execution paths of your workflow instances.

Key Performance Indicators
You can build tools on the top of Tracking to get KPI measurements per your organization’s need. For example, if you have an order processing workflow application you can use tracking to determine the time it takes to fulfill an order or to get information on the number of orders received within specific period of time. You can also use Tracking to determine how many orders were processed successfully and how many were rejected or find number of orders with a specific order value.

You can use tracking to capture and store all workflow and activity events, all activity properties and their values, and all workflow data. You can use that log for auditing purposes during and after instances execution.

Tracking Architecture
There are three main components in the tracking architecture Tracking Runtime, Tracking Services and Channels and Tracking Profiles:

Tracking Runtime
Tracking runtime requests Tracking Profiles from registered Tracking Services. When the workflow instance start executing the tracking runtime will call into all tracking services and request a profile for the instance’s type that was created. Upon instance execution, tracking runtime will filter instance’s events and data based on the Tracking profile and will send tracking information that the service has asked for via the Tracking Profile.

Tracking Service and Channels
Tracking services are responsible for supplying tracking profiles and tracking channels to tracking runtime. The tracking runtime uses this tracking channel to send tracking records associated with the workflow instance when a track point in the tracking profile is matched. The tracking channel is responsible for storing the tracking information. It is a single threaded receiver of events per instance.

Tracking Profiles
Tracking Profiles are the mechanism to identify what events and data Tracking Services are interested in. There are three types of events that you can track:

  • Workflow Events: Events on the workflow instance level. E.g. Started, Created, Suspended, Resumed, Terminated
  • Activity Events: Events on the Activity Level. E.g. Executing, Closed
  • User Events: User events are custom events where workflow authors can send out tracking data from the workflow code by calling TrackData method on the Activity and pass the object they want to track

You can also specify to track data along with various events. For example, you could decide to track a specific activity property and its value or all activities’ properties and their values. Authoring tracking profiles can be done in a declarative way by creating a tracking profile XML file, or by code using the tracking profile object model.

There are many sections in the WF documentation about Tracking, there is also tutorial and samples – check them out.