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 =
//Mapping between the Object and the Instance Id
Dictionary<string, Activity> activityIdToWfElementMap =
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.
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.