Last week we introduced the new Workflow Tracking features in .NET 4.0.  In this post we’ll do a deep dive into tracking profiles and explain how to use them to track workflow execution in a flexible way. 

Tracking Profile Overview

Tracking profiles let you subscribe to events that are emitted by the runtime when the state of a Workflow instance changes.  Depending on your monitoring needs you may craft a profile that is very coarse, subscribing to a small set of high level state changes on a Workflow.  On the other hand you may create a very granular profile whose output is rich enough to reconstruct the execution later.  Tracking profiles can satisfy these extreme scenarios and anything in between.

Tracking profiles manifest themselves in one of two ways.  You can create tracking profiles programmatically in .NET or configure them as XML elements in the <system.serviceModel> section of a standard .NET configuration file.  This post covers configuration based profiles.  Here is an example tracking profile in .NET 4.0 Beta 1:




      <trackingProfile name="High_Level_Tracking_Profile">




              <state name="Started"/>

              <state name="Completed"/>










Tracking Profile Structure

Tracking profiles are structured as declarative subscriptions to events, or tracking queries that let you “query” the Workflow Runtime for specific event records.  There are a handful of query types that let you subscribe to different classes of events.  Here are the most common query types that you can try out in .NET 4.0 Beta 1:

%u00b7         WorkflowInstanceQuery – Use this to track Workflow instance lifecycle changes like Started and Completed.

%u00b7         ActivityQuery – Use this to track lifecycle changes of the activities that make up a Workflow instance.  For example, you may want to keep track of every time the “Send E-Mail” activity completes within a Workflow instance.

%u00b7         FaultPropagationQuery – Use this to track the handling of faults that occur within an activity.  This event occurs each time a FaultHandler processes a fault.

%u00b7         UserTrackingQuery – Use this to track events that you define in your code activities.  There will be a follow up to this post that shows you how to create user tracking records.

Variable Extractions

When tracking the execution of a Workflow it is often useful to extract data.  This provides additional context when consuming the tracking records post execution.  Tracking profiles make this easy.  In .NET 4.0 you can extract variables from any activity in a Workflow.  The following example activity query comes from the monitoring hands on lab that shipped with the WCF and WF samples for .NET 4.0 Beta 1.  It shows how to extract the “StockSymbol” variable whenever the “GetStockPrice” activity completes.


  <activityQuery activityName="GetStockPrice">


      <state name="Closed"/>



      <variableQuery variable="StockSymbol"/>






Annotations in Workflow 4.0 let you arbitrarily tag tracking records with a value that can be configured after build time.  For example, you might want several tracking records across several Workflows to be tagged with “Data Center” == “Contoso Data Center”.  This makes it easy to find all records with this tag when querying tracking records later.  To accomplish this, you would add an annotation to a tracking query like this:


  <activityQuery activityName="GetStockPrice">


      <state name="Closed"/>



     <annotation name="Data Center" value="Contoso Data Center"></annotation>





What’s Next

In the next post in the series, we will talk about the extensibility of Workflow tracking  in .NET 4.0.  This topic will dive into the following concepts:

%u00b7         Programmatically emit your own tracking events by creating UserTrackingRecords.

%u00b7         Programmatically consume events within the runtime by creating custom TrackingParticipants.

%u00b7         Programmatically create tracking profiles in .NET.