Ariel Schapiro’s Blog

Monitoring workflows is going to become an essential functionality in almost every BPM implemented with Windows Workflow Foundation. It allows administration users to get a fast and smart track of what’s going on with their multiple running workflows. This way, they can get a better control, summarized information and customized reports about running or closed workflows.

Here is a little example on how to configure and use the Workflow Monitor, using a simple workflow launcher solution to make a brief analysis of what can Workflow Monitor do for us.

This WM is an application that let you see the running or completed workflows, all along with some information like their activities and even a design view of the selected workflows.

Getting and configuring the WM:
This WM sample comes with Windows Workflow Foundation and you get it this way:
1) Open Windows Workflow Foundation Help: \Documents and Settings\<user>\Start Menu\Programs\Windows Workflow Foundation\Windows Workflow Foundation Help
2) Navigate to: Windows Workflow Foundation Samples -> Application Samples -> Workflow Monitor.

This WM can show workflows details because it reads tracking information from the tracking database, so you must have installed the out-of-box SqlTrackingService. So once you have installed WM, just follow the “Configuring the SqlTrackingService Database” steps of the Windows Workflow Foundation Help up to step 4.

Step 5 is important because adds some stored procedures to the database which WM needs. In step 5, maybe you won’t find the monitor_queries.sql file, but don’t desperate!!! Its on the WorkflowMonitor folder that you just got from the Windows Workflow Foundation Help!!!

WorkflowLauncher installing and configuration:
Download WorkflowLauncher solution from here.
In the App.config file of the WindowsApplication1 from the WorkflowLauncher solution, change the Initial catalog and Data Source properties of the ConnectionString for the SqlTrackingService type of service writing your own catalog and data source strings (Initial Catalog should be "Tracking" if you used the names suggested by the Windows Workflow Foundation Help).

Note the TrackWorkflowDefinition propery is set True!!!
Build the solution.

Making that the Workflow Monitor can see the sampleWorkflow:
You must add the WorkflowProject1 assembly to the WM folder so that it can show you the design of the workflow we are going to run:

Copy
WorkflowLauncher\WindowsApplication1\bin\Debug\WorkflowProject1.dll

file to WorkflowMonitor\CS\bin\Debug folder.

Using the Workflow Monitor:
If you did the 3 last steps, we are good to go. Open the WorkflowMonitor solution, set the active solution configuration to “Debug”, build the solution and start it.
Start the WorkflowLauncher solution. The WorkflowLauncher just launch a simple sequential workflow with a delay of the amount of seconds that you enter on the textbox. You can launch workflows that last as long as you want while you analyze the WM window.

Both windows should look like this:

Turn ON the monitor by pressing the green play button on the WM window. Open the Settings window and set the Polling Interval to 500 ms. Use the WorkflowLauncher to launch a 15 seconds lasting workflow:

As you can see, as the WM reads the Tracking information stored on the SQL database, shows the workflow details including the design of it. It even shows which activities are closed and which ones are running!!!:
When the 15 seconds period finishes, the WM reads the updated information from the tracking service, which says that the workflow is done:

And that’s how you can start playing with the WM…

Some benefits:
This WM works with the SqlTrackingService, so it shows the main information that services provides. But a great advantage is that you can make your own persistence service and make your own monitor to read it.

Imagine that you could organize your workflows by type so you monitor them and see in which step is every one of them or how many of them reached some point, etc…. Possibilities are countless!!!!!

If you start a 60 seconds workflow, you close the WorkflowLauncher window (closing the Runtime) and open it again before the 60 seconds, that workflow will complete right on the 60 seconds time. That’s because when the runtime is started, the persistence services are also started so the runtime can take in count persisted but not closed workflows and continue running them.

Some issues:
Multiple Definitions of the Same Workflow Type:
The SqlTrackingService will persist the workflow markup definition the first time a new workflow type is used. However, if the definition changes and the type version remains the same a new record is not persisted in the tracking database. This will result in the monitor always showing the first definition. You should check the “Workflow” Table on the Tracking database.

Dynamic Update:
The Workflow Monitor does not recognize dynamic changes to a workflow instance. If a workflow instance is changed while executing the Activity Pane will show the correct status information but the Workflow View Pane will not show the updated workflow definition and may not show the correct highlighted activity.

So use it, make your own conclusions and tell me how it was!!!

If you are new to WWF, this simple explanation can help.

The InvokeWorkflow Activity does a great job calling workflows asynchronously. This way you can call a workflow to start from your current workflow and keep going.
But what if you want to start it synchronously? What if you want to chain workflows in a hierarchical architecture and you don’t want to use the "fire and forget" pattern to call your workflows?
That’s why I created the InvokeWorkflowSync Activity. It’s an easy way of calling workflows the way InvokeWorkflow does but with the difference that the main workflow won’t continue until the invoked workflow has completed.
So give it a try and tell me how was it!!!
Using it:
Once you build the ActivityLibrary that contains the InvokeWorkflowSync Activity, drag it from the Toolbox to the workflow you want to use it on:

In this version, you have the same main parameters as the regular InvokeWorkflow Activity has:

• TargetWorkflow: Type of workflow to invoke.
• Invoking: Event that fired before the workflow is invoked.
• Invoked: Event that fired after the workflow is invoked.

Once you run your application, invoking workflows will continue running just after their invoked workflows complete its execution.
You can see it in the demo, where I used 2 InvokeWorkflow activities: the first one invokes a workflow where another InvokeWorkflow activity calls the third and last workflow in the chain. The idea is to make easier a hierarchical chaining system made of workflows.

 

How it works:
As I first took a glance at InvokeWorkflow activity I realized that its a sealed class so lamentably I had to made my own InvokeWorkflowSync inheriting it from System.Workflow.ComponentModel.Activity.
Execution:
    The overriding InvokeWorkflowSync.Execute method is the one that has the activity execution logic, and mainly performs the following tasks:

• Get Runtime from the context:
• Start listening for passed Workflow to complete:



• Start passed workflow:



• And once the workflow is completed, goes on:



Validation:

    The InvokeWorkflowSync is validated by the InvokeWorkflowSyncValidator class with its Validate method. This one checks that the TargetWorkflow Parameter isn’t null retrieving an indicating smart tag in case it is:




Some issues:

Workflow Parameters: passing parameters to workflows is not allowed in this version. Will be ready for next version.

Time out Parameter: Since workflow is called synchronically, it would be nice to have a time out parameter for which the main workflow would keep its execution terminating the invoked workflow. Will be ready for next version.