I've seen many people in the forums trying to figure out the best way to get data from a workflow at runtime.  The root of the problem lies in the fact that while you can get a handle to a WorkflowInstance from the runtime, this is really a template and does not contain the values of properties on the workflow.  It is a common need to get the current state of your process, or get values from the class. 

 

One solution is to use the local communications activities and call back to the host and have a local service manage the values.  But, who wants to drop a bunch of CallExternalMethod activities in all of their workflows.  No the answer, not surprisingly, lies with tracking. 

 

Tracking in workflow provides so much power and flexibility to extract data that you are interested in. I've created a custom tracking service which tracks the workflow properties at runtime and stores them in a dictionary in the service.  When you want to get the current property values for a workflow, you get the tracking service from the runtime, then ask it for the properties which you get back as a Dictionary<string, object> just like the parameters you passed into the workflow. 

 

There are two keys to getting this work and both revolve around the tracking profile.  First, it is important to know that when you define an ActivityTrackPoint, you can add data extracts which define the data to extract and send to the tracking channel.  But those extracts can either be activity extracts, or workflow extracts.  So, I define an activity track point to track all activities on close and add Workflow level extracts to pull the properties off of the workflow at that point.  The second key piece is figuring out what properties are available on each workflow type.  This service would be pretty limited if it were tied to a specific workflow type.  Instead, when the profile is created based on a workflow type, I reflect on the type to get the public properties defined in this type (not the base classes though you can do that too) and build the extract definitions from them. 

 

So, when a workflow is run, the profile is created indicating that on each activity closed, the properties of the workflow should be sent to the tracking channel.  In the channel, I simply update the dictionary of values stored in the service.  Finally, when an instance completes or terminates, I remove the values from the dictionary. 

 

You could track more often by using other statuses on the activity tracking location, but beware of the overhead tracking may add in these cases. 

 

I hope this is helpful.  As always, comments and feedback are welcome. 

My article on building custom activities for Windows Workflow Foundation has finally posted to MSDN.  For those of you fortunate enough to get a printed copy, you got an entire week advanced screening. :) 

I tried to cover the basics of building an activity and the various components; designer, validator, etc, as well as touch on some of the things you can do for more advanced activities that need to listen for external data/events. 

 

I'll be writing more articles for MSDN Magazine on Windows Workflow Foundation in the coming months. If you have specific topcis that are of interest, post your feedback here and I'll consider it as I plan the next articles. 

 

Finally, working with released code! 

Get it here, along with the Visual Studio extensions and Windows SDK.

Now, if they could just get the Vista RTM out so I can do .NET 3.0 RTM development on my desktop.

I have been looking at scenarios involving Workflow and BizTalk and figured a good place to start was with Rules integration.  If you have rules already defined in the BizTalk BRE, then you should be able to take advantage of them from a Workflow instead of trying to translate all of those rules into the WF rules engine. 

 

The BRE activity allows you to reuse your investment in the BizTalk BRE be configuring and executing policies from your workflow.  It contains a custom activity designer that queries information about the policy/facts and builds a dynamic set of properties so that you can configure the facts right on the activity and use databinding. 

 

This is definitely a sample but works with my simple tests.  I have not added support for data connection or data row/table facts, but it should be easy enough for someone to add those into the designer. 

 

Hopefully this will be useful for some of you.  Any feedback is welcome. 

 

Grab the code here.