- Describing Workflow and Workflow Systems
- .NET Framework 3.0 and 3.5
- Overview of WF
- Standard Modeling Activities
- Multiple Workflow Styles
- Hosting
- Tracking
- Rule Capabilities
- Custom Activities
- XAML Workflows and Serialization
- Dynamic Update
- WF and WCF
- SharePoint Workflow
- Designer Rehosting and External Modeling
- Summary
- Installation Instructions
This chapter is from the book
This chapter is from the book
This chapter is from the book
Dynamic Update
Two of WF's primary goals are to support long-running processes and to provide increased process agility. One common denominator to both these goals is the ability to evolve processes. It is a simple fact that processes change. If software cannot handle it, the changes are implemented out-of-band. This not only diminishes the efficiency of the process itself but reduces reporting accuracy because the data used to compile reports does not include the out-of-band operations. With dynamic update, activities can be added and removed from workflows (a change can be implemented via an add-remove combination). Declarative rules can also be changed.
The next code listing demonstrates adding a Delay activity to a workflow. The details will be covered in Hour 15, "Working Dynamic Update," but this is all the code necessary to change a running workflow.
// use WorkflowChanges class to author dynamic change and pass
// it a reference to the current Workflow Instance
WorkflowChanges workflowTochange = new WorkflowChanges(this);
// Crete a new Delay, initialized to 2 seconds
DelayActivity delayOrder = new DelayActivity();
delayOrder.Name = "delayOrder";
delayOrder.TimeoutDuration = new TimeSpan(0, 0, 2);
// Insert the Delay Activity to the TransientWorkflow collection
// (the workspace) between the two Code Activities
workflowTochange.TransientWorkflow.Activities.Insert(1, delayOrder);
// Replace the original Workflow Instance with the clone
this.ApplyWorkflowChanges(workflowTochange);
Although the capability to change a running workflow is powerful, it is also unnerving. WF has controls in place to make changing running workflows more palatable. The first is that each workflow can be set to stipulate when and if dynamic update should be permitted. The default is always. Workflows have a DynamicUpdateCondition property (Figure 1.21 shows it set to a Declarative Rule Condition). This property can be set to determine when and if dynamic update should be permitted. If you want to disallow it completely, return false from the Condition property. If you want to selectively permit it, for example, to be allowed at one part of the workflow that changes from instance to instance, apply the appropriate condition.
)
Figure 1.21 Declarative update rule condition.
The second is that two ways exist to store per-workflow instance changes. If using XAML workflows, each instance can be saved to a database and changes can be compared to other instances and to the baseline process. If trends are noticed, the baseline process can be changed. If using tracking, it will store the changes, and the mechanism you use for displaying tracking information can include them. The WorkflowMonitor SDK application, for instance, will show changes made when viewing the workflow instances. It is not always appropriate to view each and every workflow. However, if you store each XAML workflow instance in a database or use tracking, the information is there and available to report on.
The third is that WF's validation is called when dynamic update changes are applied. This prevents erroneous changes from being made to running workflow instances.
Dynamic update is an extremely powerful feature that goes hand-in-hand with WF's per-instance tracking capabilities. It seems feasible that processes will continually be changed going forward with WF and controlled with strong reporting tools that leverage tracking. The capability to change running workflows is common in BPMSs, and WF provides a solid set of tools to do it and build even more powerful solutions to change running workflows and track these changes.
XAML and dynamic update can appear to overlap. XAML can be loaded at runtime without precompilation but cannot be changed on a running workflow. XAML is good for tools and for database loading. Dynamic update is used to change an actual running process. Dynamic update can be performed on workflows expressed in either XAML or code. Rules are a little different. Declarative rules (those expressed in .rules files) are also more tool friendly than their code counterparts and can also be loaded without precompilation, which makes database storage compelling. Only declarative rules can be changed with dynamic update, though. Hour 13 demonstrates loading declarative rules from a database. Hour 15 covers Dynamic Update.