- 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
XAML Workflows and Serialization
XAML (pronounced "ZAML") is an XML language used in both WF and WPF. It allows a hierarchal collection of objects, their relation to .NET types, and input and output data to be described. In WF, XAML can be used to describe the tree of workflow activities, the .NET types that encapsulate the logic, and the data sent to and received from the activities. In WPF it does the same for the user interface controls.
WF supports specifying the tree of activities in both code and XAML. Why the need for XAML? As an XML dialect, XAML receives the benefits of the investment being made in XML by Microsoft and others. These investments include the capability to store XAML workflows in SQL Server. WF will load a XAML workflow at runtime without requiring precompilation. If the workflows are expressed in XAML, each workflow instance can be stored in a database. Calculating the difference to the baseline process and between individual workflows is as simple as using XSLT, XQUERY, or other XML manipulation languages.
If no compilation occurs, can't invalid workflows be loaded? No, WF's validation capability, which you learn about in Hours 15 and 24, validates workflows when they are loaded. It checks the workflow for structural fidelity. You are free to extend the validation on any workflow to add business-specific checks, such as if a BankBeginTransfer activity exists on the workflow, ensuring there is also a BankEndTransfer activity.
As a whole, storing workflow models in a database and then retrieving them at runtime to execute is a compelling possibility. The capability to then store each workflow instance is also compelling.
No matter what format you choose, the graphical workflows are saved in a format that can be seen and edited. This means you can modify the code directly if needed.
The next listing shows a simple workflow with one Code activity expressed in XAML. The one immediately following shows the same workflow expressed in code. If you are familiar with Windows Forms development, you will notice that the code representation matches the format of a Windows Forms application.
<SequentialWorkflowActivity x:Name="Workflow2XOMLOnly"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/workflow">
<DelayActivity TimeoutDuration="00:00:00" x:Name="delayActivity1" />
</SequentialWorkflowActivity>.
The same workflow expressed in code:
this.CanModifyActivities = true;
this.delayActivity1 = new System.Workflow.Activities.DelayActivity();
//
// delayActivity1
//
this.delayActivity1.Name = "delayActivity1";
this.delayActivity1.TimeoutDuration =
System.TimeSpan.Parse("00:00:00");
//
// Workflow2
//
this.Activities.Add(this.delayActivity1);
this.Name = "Workflow2";
this.CanModifyActivities = false;
XAML workflows and serialization are covered in Hour 2.