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.
Posted
Nov 25 2006, 09:22 PM
by
matt-milner