In this installment we will look at the tracking capabilities built into WF. Tracking basically allows you to "log" all the actions your workflows are performing. This includes both the standard trace messages which signal different things such as activities completing, state changes, rule executions exceptions and custom messages placed by the user.
Setting up the WF tracking is quite simple, you just have to add a service to the runtime. Like persistence, there is a ready made service for tracking which can we easily incorporate and should suffice for most cases. Let's add that service now to begin exploring the tracking capabilities. 
We have added the service to our program but we haven't yet setup the database for it. To do that pick up the two script files from C:\<WINDOWS DIR>\ Microsoft.NET\Framework\v3.0\Windows Workflow Foundation\SQL\<LANGUAGE DIR> and run them in the SQL Server database we created previously or in a new database if you like.
The WF runtime does its tracking using what is called a tracking profile. The tracking profile is simply a definition of what needs to be tracked. This tracking profile can be created using the object model or simply as an xml file which can be saved in the database. The default profile from the database looks like this:
<?xml version="1.0" encoding="utf-16" standalone="yes"?>
<TrackingProfile xmlns="http://schemas.microsoft.com/winfx/2006/workflow/trackingprofile" version="1.0.0">
<TrackPoints>
<ActivityTrackPoint>
<MatchingLocations>
<ActivityTrackingLocation>
<Activity>
<Type>System.Workflow.ComponentModel.Activity, System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35</Type>
<MatchDerivedTypes>true</MatchDerivedTypes>
</Activity>
<ExecutionStatusEvents>
<ExecutionStatus>Initialized</ExecutionStatus>
<ExecutionStatus>Executing</ExecutionStatus>
<ExecutionStatus>Compensating</ExecutionStatus>
<ExecutionStatus>Canceling</ExecutionStatus>
<ExecutionStatus>Closed</ExecutionStatus>
<ExecutionStatus>Faulting</ExecutionStatus>
</ExecutionStatusEvents>
</ActivityTrackingLocation>
</MatchingLocations>
</ActivityTrackPoint>
<WorkflowTrackPoint>
<MatchingLocation>
<WorkflowTrackingLocation>
<TrackingWorkflowEvents>
<TrackingWorkflowEvent>Created</TrackingWorkflowEvent>
<TrackingWorkflowEvent>Completed</TrackingWorkflowEvent>
<TrackingWorkflowEvent>Idle</TrackingWorkflowEvent>
<TrackingWorkflowEvent>Suspended</TrackingWorkflowEvent>
<TrackingWorkflowEvent>Resumed</TrackingWorkflowEvent>
<TrackingWorkflowEvent>Persisted</TrackingWorkflowEvent>
<TrackingWorkflowEvent>Unloaded</TrackingWorkflowEvent>
<TrackingWorkflowEvent>Loaded</TrackingWorkflowEvent>
<TrackingWorkflowEvent>Exception</TrackingWorkflowEvent>
<TrackingWorkflowEvent>Terminated</TrackingWorkflowEvent>
<TrackingWorkflowEvent>Aborted</TrackingWorkflowEvent>
<TrackingWorkflowEvent>Changed</TrackingWorkflowEvent>
<TrackingWorkflowEvent>Started</TrackingWorkflowEvent>
</TrackingWorkflowEvents>
</WorkflowTrackingLocation>
</MatchingLocation>
</WorkflowTrackPoint>
<UserTrackPoint>
<MatchingLocations>
<UserTrackingLocation>
<Activity>
<Type>System.Workflow.ComponentModel.Activity, System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35</Type>
<MatchDerivedTypes>true</MatchDerivedTypes>
</Activity>
<Argument>
<Type>System.Object, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35</Type>
<MatchDerivedTypes>true</MatchDerivedTypes>
</Argument>
</UserTrackingLocation>
</MatchingLocations>
</UserTrackPoint>
</TrackPoints>
</TrackingProfile>
As you can see the workflow tracking profile allows you to trace specific workflows using their type as the matching criteria, plus you can specify if all derived types should be tracked as well. In this case the type Activity has been chosen with derived types, meaning all activities would be tracked. Second, you can track activity execution states and third you can track workflow states. As, for user generated messages they can be anything and produced from anywhere.
Lets create a simple workflow that we want to track.
In every code activity we print a message on screen and each delay is of 2 seconds. Lets execute this twice and see what it generates in the database.
After the execution of the workflow, lets explore the generated data from top down that is by looking at the workflow first and then the activities within them. If you open the table Workflow you will see a row like this:
This table uniquely lists the workflows that we are tracking. The next level is at the instance of this workflow, for which you should open WorkflowInstance:
This table list the individual instances of the particular workflow tracked. There is a field called WorkflowTypeId which links it back to the previous database identifying the workflow type. At the next level we see what events get generated at each workflow instance level:
As you can see there are two sets of event lists, representing each instance of execution, and there are fields that link it back to the previous tables. As you can see the progression of data captured, you should be able to relate further information to it. For example, if we open the tables Activities the data should be obvious to us:
At the next level:
include another reference table in here:
and the table next lists down every state the activity went through:
I'll leave the database details at this level, so you can explore further.
Subscribe