VisualWorkflowTracking aka WorkflowSimulator

In the Beta2 SDK,  we shipped a sample called WorkflowSimulator. Essentially, the sample is using the tracking APIs to have a visual understanding of the Workflow execution logic.

Thus, as we hit “Run Workflow”, we get the debug kind of adornments on each activity that executed.

Let’s actually dwell deeper and understand how we used the Designer and the Debugger APIs to achieve the same.

To understand that, let’s take a step back and take a look at the debugging architecture:

The most important piece in the slide above are:

We have a 1:1 mapping between the activity objects on the designer surface and their corresponding line numbers

Similarly, we can also have a 1:1 mapping between the Activity Object that is executed at the Runtime and the unique Instance Id corresponding to the activity at the Runtime.

Thus from the above two bullets, we essentially have a mapping between the Activity Object <-> Xaml Line No <-> Activity Instance Id

This is achieved by the following lines of code:

 //Mapping between the Object and Line No.
Dictionary<object, SourceLocation> wfElementToSourceLocationMap = 
                                            UpdateSourceLocationMappingInDebuggerService();
            
//Mapping between the Object and the Instance Id
Dictionary<string, Activity> activityIdToWfElementMap = 
                            BuildActivityIdToWfElementMap(wfElementToSourceLocationMap);

With this mappings now in place, we essentially plug in our custom tracking participant and as the TrackingRecords are received, we map them back to the Activity Objects and thus to their specific Xaml Line Nos.

Something like:

These Xaml Line No (also called as SourceLocation) are now provided to the DebuggerService – which then provides us with the adornment on the activity corresponding to which the tracking record was just received.

 //Show the Debug like adornment
this.WorkflowDesigner.DebugManagerView.CurrentLocation = srcLoc;

 where srcLoc is the XamlLineNo. mapping to the activity that was just executed.

You can find the sample by downloading the SDK here. You want to browse to WF\Application\WorkflowSimulator sample.

Finally, a note about the title.

Though the sample itself is called as Workflow Simulator; we are not in any way simulating the Workflow runtime. The Workflow runtime is executing as is. It is about the applications that can leverage the functionality/APIs which we are trying to showcase through the sample. For example, developers can leverage it as a Workflow Replay sample by archiving all the tracking records in a database and then channeling it to this application one at a time so that you can specifically know how the runtime executed a specific Workflow sometime in the past.

To showcase, this functionality in a primitive manner, I printed out all the tracking records on the right side of the application as they are emitted one at a time. If you double click on any specific record, it will take you(in terms of debug adornment) to the activity in the workflow to whom the tracking data corresponds to.

Similarly, you can think about applications like a Workflow Simulator as well as Visual Workflow Monitoring for a better understanding of the Workflow behavior with various inputs to your domain specific Workflow.

Thanks,

 

Kushal.

Comments

• Anonymous
  December 22, 2009
  Thanks for sharing this information Kushal! Notre

• Anonymous
  August 04, 2010
  The comment has been removed

• Anonymous
  March 03, 2011
  Hi Kushal, In trying out the samples I faced a issue - whenever an activity is deleted or added to the workflow in the rehosted designer it does not participate in the highlighting / debugging for some reason. A little investigation reveals that any new activities added are not handled by the SourceLocationProvider.CollectMapping call for some reason. We are trying rehosting the designer for a major project and would appreciate your help. Thanks

• Anonymous
  December 20, 2011
  WARNINGin this sample if you have default values argument it no works because argument element is at the first item in xaml stream, you have to do a second moveNext. //Get the first child of the x:class !!! a workaround is : return WorkflowInspectionServices.GetActivities(wfFile).FirstOrDefault(c => c as IValueSerializableExpression == null);