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.

 

You might file this under the "it has always been this way and I'm late in figuring it out" category, but I just found the three letter snippet shortcut for Workflow dependency properties and events.  I didn't see this in earlier builds and was getting tired of CTRL+K -> CTRL+X then drilling into the menus to get to Worfklow Dependency property.  Especially since the EventHandler snippet always came first and the way they are worded I had to either move to the cursor keys or type 25+ characters to get it to move down to the property item. 

 

Now I just WDP + Tab + Tab and I'm happily editing a workflow dependency property. 

Or, I can WDE + Tab + Tab and edit my dependency property for an event handler. 

 

Awesome!

Next month Pluralsight has our first public offering of Introducing Windows Workflow Foundation right in my own town of Minneapolis.  We did a Double Feature with WF and WCF back in August and it was great.  If you are looking for some training on WF, check out the information page and register now "Space is limited" as they say.  

 

We'll have great hands on labs mixed in with lecture to give you the right balance of concepts with experience.  Hope to see you there. 

 

Minneapolis not convenient for you?  Leave a comment as to where you would like to see us do public Workflow courses.  Boston?  Dallas?  Seattle? Denver?  Atlanta?  Vegas?  :)  If we get enough interest for a location, we'll get a course up and running and I'll be sure to announce it here. 

 

I've seen several requests for tracking the current state in a state machine workflow.  There are several options including adding custom activities, using call external method, or using the WorkflowIdled event and the StateMachineWorkflowInstance to do this.  They all have their drawbacks however. 

 

 

The ideal solution would give you the current state when it is entered and allow you to get that information without having to do anything specific in your workflow in order to track it.  I've created a sample that uses a custom tracking service to track the state changes in a state machine workflow. 

 

The tracking service is pretty simple, defining a single activity tracking location to track the executing state of the StateActivity.  The tracking channel just writes out the state name to the console.  In your use, you can customize the tracking channel to do whatever makes sense in your application (write to DB, raise an event, etc.). 

 

Find the sample here and leave any feedback as comments. 

 

If you are working with Windows Workflow Foundation and hosting the designer, then this article provides some good background and context information for you about the general designer hosting support in .NET 2.0.