Workflow Tracking (Windows WF)

Introduction:

Tracking is one of the features provided in WF to gain visibility to the execution of workflow to the administrator. The other features are performance counters, tracing etc.

Though WF provides default implementation of these services. They are all replaceable. They can be replaced by custom implementation of services by hosting applications. Different implementation can be provided by various hosts like WPF, SharePoint etc.

Workflows in Windows WF are defined in terms of a group of activities. WF provides necessary interfaces, for workflow as a whole or activities in particular, to provide tracking data. This data can be collected by registering components.

Terminologies:

Tracking Profile:

Tracking profile helps runtime filter events and forwarding tracking service only those tracking records which are based on these filters. This results in tracking only relevant workflow details. So tracking profile is used to control tracking information passed to any monitoring application.

Theoretically, Tracking profile sits between Tracking Service and Tracking Runtime Engine. It helps runtime in providing data and events information to the tracking service from the workflow instance.

Tracking profiles can be designed using Tracking Profile Designer.exe. This is basically a sample application available as part of Windows SDK. We can also create and manipulate tracking profiles using TrackingProfile class. TrackingProfileSerializer class allows us to author these profiles in declarative fashion. Both of these classes are available in System.Workflow.Tracking namespace.

This consists of Workflow trackpoints, activity trackpoints and user trackpoints which in turn are consisted of annotations, conditions and extracts.

Based on the above discussion, you might already have developed this idea that there are three types of tracking events. They are as follows:

1. Workflow status events: These are defined for the whole workflow like Created, Started, and Terminated etc.

2. Activity status events: These events are related to individual activities like Executing, Canceling etc.

3. User events: These are defined to get user defined data from activities. They can be fired by using the Activity.TrackData() method.

There are classes available in System.Workflow.Runtime.Tracking namespace to define these trackpoints. They are WorkflowTrackpoint, ActivityTrackpoint and UserTrackpoint.

Filtered Locations: They specify the matching / excluding locations i.e. which events must be tracked. Excluded locations can not be specified for workflow trackpoints.

Annotations: They allow us to specify collection of string before an event is passed to the Tracking Service. This is used for tagging events so that their execution might be recorded accordingly.

Extracts: They are used to provide workflow / activity data during an event. We may specify the properties which might be passed with the event. Extracts can not be specified for workflow trackpoints.

Note:

In order to audit the evaluation of rules, we can register RuleActionTrackingEvent. This event can be registered to track the output of rules evaluation. We can use this to audit the rule evaluations.

Tracking Channel:

It is used to for communication of data from tracking runtime to tracking service. This is passed in the form of tracking records. This is in the form of the objects of following classes in the same System.Workflow.Runtime.Tracking namespace: WorkflowTrackingRecord, ActivityTrackingRecord and UserTrackingRecord.

Tracking channel knows about the instance being tracked and the WF runtime. It waits for specific message and passes it to the Tracking Service. Tracking records are persisted by calling Send() method on Tracking Channel be Tracking Service.

Tracking Runtime:

This is responsible for initializing tracking infrastructure. It is passed with Tracking Profile and channel information during initialization. It uses them to pass selected tracking information to tracking service.

Tracking Service:

It has central significance in the whole tracking infrastructure. During initialization, it passes tracking profile and channel information to the tracking runtime. Instead of directly storing tracking records to the tracking database using tracking channel, tracking runtime passes them to the service which in-turn is responsible for storing them to persistence store.

Its responsibility is to provide tracking channel and profile information to Tracking runtime. After a workflow starts running, it receives events information from Tracking runtime and stores them to Tracking Store using Tracking Channel.

It is possible that more than once service is registered with the runtime. In that case each service will have to provide its own tracking profile and channel.It can be added to the workflow both programmatically and declaratively. For programmatic support, it is directly added to the workflow runtime. Alternatively, it can be specified in the section of config file.

The partial implementation of this service is provided by default in Windows WF.

Tracking Store:

Tracking Service can use a tracking store for persistence of tracking records received from Tracking runtime. It can be any persistent storage like files, databases. As discussed, the default implementation for tracking service stores data in SQL Server database.

Note:
I think it would be a great implementation of Inversion of control (Unity) to define dependency between tracking service, channel and profile.

Performance Impacts of Tracking:

One of the feature to improve performance in the cases of very large tables and very large databases in partitioning database objects. In the same lines, if we partition tables used for tracking WF data, we might be improving performance of the workflow instance. WF provides out of the box support for partitioning tracking tables. This is basically a windowing technique which, by default, moves data to partitioned tables after completion of workflow instance. This can be set using the TrackingService class. You can also move data on demand using PartitionCompletedWorkflowInstances stored procedure.

If you want to study further about Partitioning and its support in SQL Server. You can read my article on SQLServerCentral.com:

http://www.sqlservercentral.com/articles/partition/64740/

Supported Applications and Utilities:

In this discussion, we have discussed about two sample utilities provided with Windows SDK for tracking. Let me mention their names again:

1. Tracking Profile Designer: This can be used to create custom tracking profiles.
2. Workflow Monitoring Tool: To monitor workflows currently executing.
   

Tracking information can be made available for business users by creating SQL Server Reporting Services based reports from the data created by WF tracking service in the tracking store.

We can use BizTalk Server 2006 R2 BAM Tracking Interceptor for Windows WF to intercept tracking information from Windows WF to Biztalk server. We can make use of Business Activity monitoring (BAM) features of Biztalk Server.