Monday, October 16, 2006 1:15 PM bart

WF - Using the WorkflowMonitor in combination with Dynamic Updates

Introduction

In the past, I've been talking about making a workflow dynamic by applying changes to it at runtime:

Yesterday, you learned how to use tracking (and persistence) services to visualize what's going on inside a workflow in flight, using the WorkflowMonitor sample application that comes with the Windows SDK. Today, we'll combine both the dynamic adaptation of a workflow with tracking services.

Modifying the WorkflowMonitor

As discussed yesterday, the WorkflowMonitor tracks workflows by polling a tracking database used by WF. To visualize what's a workflow keeping itself busy with, it relies on the workflow definition type that gets loaded in the workflow designer that's rehosted by the sample application. However, when making dynamic changes, the WorkflowMonitor doesn't visualize the modifications made to the workflow, because the type doesn't get reloaded. To make things work in a quick-n-dirty fashion, you'll need to change the WorkflowMonitor sample a bit (one line to be precise).

Go to MainForm.cs and locate the method called UpdateActivities. Change the code as follows (only a few lines are displayed, just enough for you to find the spot where modification is needed):

...

ListViewItem
currentWorkflow = listViewWorkflows.SelectedItems[0];
if (currentWorkflow != null
)
{
   Guid
workflowInstanceId = workflowStatusList[(currentWorkflow.SubItems[0]).Text].InstanceId;

   SqlTrackingWorkflowInstance sqlTrackingWorkflowInstance = null
;
   if (true == monitorDatabaseServiceValue.TryGetWorkflow(workflowInstanceId, out
sqlTrackingWorkflowInstance))
   {
      //Edited by Bart De Smet - 10/05/06
      GetWorkflowDefinition(workflowInstanceId);
      //End edit

      listViewActivities.Items.Clear();
      activityStatusListValue.Clear();

      ...

Dynamic updates

To keep things easy, I'll rely on the results of yesterday's work, so follow those instructions first and make sure the app runs fine. Then go to Workflow1.cs in the TrackingDemoLibrary project and change the ExecuteCode eventhandler for allowAccess like this:

private void allowAccess_ExecuteCode(object sender, EventArgs e)
{
   Console.ForegroundColor = ConsoleColor
.Green;
   Console.WriteLine("You're granted access"
);
   Console
.ResetColor();

   WorkflowChanges wc = new WorkflowChanges(this
);

   CodeActivity hello = new CodeActivity("hello"
);
   hello.ExecuteCode +=
new EventHandler
(hello_ExecuteCode);

   IfElseActivity ageChecker = (IfElseActivity)wc.TransientWorkflow.Activities["ageChecker"];
   IfElseBranchActivity plusEighteen = (IfElseBranchActivity)ageChecker.GetActivityByName("plusEighteen");
   plusEighteen.Activities.Add(hello);

   this
.ApplyWorkflowChanges(wc);
}

Next, add another delay on top of the workflow, set to 10 seconds. This will give us the opportunity to see the dynamic change happen in the WorkflowMonitor:

Recompile and make sure to re-register the workflow definition assembly in the GAC:

You might need to recreate the tracking database too (that the easy way to clean it when doing demos), as explained in the post on Tracking Services. Just drop the SqlTrackingDatabase, create it again and execute the two .sql scripts.

Now start the adapted (see above) WorkflowMonitor and then start the TrackingDemo solution. Keep an eye on the WorkflowMonitor and see what happens:

The result of the execution looks as follows thanks to dynamic adaptation:

Conclusion

Tracking in a world of dynamic updates is even more interesting and with one simple change to the WorkflowMonitor sample code, one creates a very appealing piece of tracking functionality. Have fun!

Del.icio.us | Digg It | Technorati | Blinklist | Furl | reddit | DotNetKicks

Filed under: ,

Comments

No Comments