Understanding Windows Workflow Foundation

Article
10/15/2014

This article provides an introduction to Windows Workflow Foundation (WF), followed by a list of what's new for WF in .NET Framework 3.5. In the companion topic, Developing Connected Systems, the concepts discussed here are illustrated with code from the DinnerNow.net sample application.

Overview

Windows Workflow Foundation, a core component of .NET Framework 3.0, provides a programming model, run-time engine, and tools for building workflow applications. A workflow is a discrete series of activities that model the steps involved in a business process.

A workflow is created and maintained by the workflow run-time engine. There can be several workflow engines within an application domain, and each workflow engine can support multiple workflows running concurrently. The run-time enables idle workflows to be unloaded from memory, persisted to a store, and reloaded whenever input is received.

Workflows can be authored in code, XAML markup, or a combination of both, known as code-separation, which is similar to the ASP.NET model. For more information, see How to: Compile Workflows.

Workflows are designed using the following styles:

Sequential (SequentialWorkflowActivity types)

Sequential workflows consist of a set of contained activities that are executed in sequential order until the last activity finishes. The sequential style executes code synchronously.
State machine (StateMachineWorkflowActivity types)

State machine workflows consist of a set of contained activities that represent specific states; transitions between states are event driven.
Data-driven

Data-driven workflows are executed in an order determined by conditional expressions.

For more information, see Workflow Authoring Styles.

Activities

Activities are the building blocks for a workflow. An activity encapsulates all of the logic necessary for a specific step within a workflow. Composite activities are activities that contain and manage other activities. The workflow itself is a composite activity that controls the execution of its contained activities. WF includes an activities library that can be extended with custom activities.

Activity Lifecycle

An activity can be in one of six states during its lifetime. Transitions are controlled by either the workflow runtime, a parent activity, or by the activity itself, depending on the state of the activity.

Initialized

When a workflow is started, the workflow runtime calls the Initialize method of all contained activities, after which the activities are in the Initialized state. For custom activities, the Initialize method provides the ability to perform startup initialization, such as creating an event handler or listening on a queue.
Executing

When program flow reaches an activity, the workflow runtime calls the activity's Execute method, which places it in the Executing state. When the Execute method returns, the runtime is notified of the current state of the activity.
Canceling

The workflow runtime can cancel a child activity that is executing by calling the child activity's Cancel method, at which time the child activity enters the Canceling state. After being in the Canceling state, an activity can transition only into the Closed or Faulting state.
Closed
Compensating

The only transition an activity can make from the Closed state is to the Compensating state, which is typically used to handle a business error that occurs in an activity farther along in the workflow. Once handled, the activity returns to the Closed state.
Faulting

An activity enters the Faulting state in response to an exception in the Executing, Canceling, or Compensating states. After the exception is handled, the activity transitions to the Closed state.

For more information, see Understanding the Activity State Model.

ActivityExcecutionContext

An ActivityExecutionContext (AEC) is the persistable environment under which an activity runs. When the workflow runtime starts a workflow, the runtime creates an AEC for the workflow. Each activity is passed the AEC under which it is being executed as an argument to several of its execution methods. Composite activities can create AECs for their child activities using the ActivityExecutionContextManager object obtained through the AEC's ExecutionContextManager property.

A parent activity uses the ExecuteActivity and CancelActivity methods of the AEC to schedule the execution and cancellation, respectively, of a child activity.

For more information, see Understanding the Activity Execution Context and ActivityExecutionContext in Workflows.

Included and Custom Activities

WF includes a library of activities that provide functionality for control flow, condition testing, event handling, state management, and communication with applications and services. For a list of these activities, see Windows Workflow Foundation Activities. For extensibility, WF allows the creation of custom activities.

A custom activity inherits from the Activity class, the CompositeActivity class, or one of the included activities. The execution logic is contained in an overridden Execute method. Various attributes can be applied to the custom type to indicate such things as toolbox behavior and which validator and visual designer to use.

An activity maintains state in terms of fields, dependency properties, or both, which can be implemented as either instance data or metadata. Metadata must be set at design time and is immutable at run time. For more information, see Creating Custom Activities.

Dependency Property

Instead of a private field, a WF dependency property can be used as a backing store for a regular property of an activity. A dependency property is used to participate in activity binding, which is discussed in the next section.

Dependency properties are of type DependencyProperty and must be declared public and static. The name of a dependency property must be equal to the name of the regular property it backs, suffixed with "Property". A dependency property is created by calling the DependencyProperty.Register method.

The regular property uses standard accessors that call the GetValue and SetValue methods of the base DependencyObject class to access the dependency property.

For more information, see Dependency Properties Overview. The following code example shows the declaration of a dependency property along with the property it backs.

public static DependencyProperty IncomingOrderProperty = 
    DependencyProperty.Register(
        "IncomingOrder", 
        typeof(DinnerNow.Business.Data.Order), 
        typeof(SaveOrderActivity));

public BusinessEntities.Order IncomingOrder
{
    get
    {
        return (DinnerNow.Business.Data.Order)base.GetValue(
                SaveOrderActivity.IncomingOrderProperty);
    }
    set
    {
        base.SetValue(SaveOrderActivity.IncomingOrderProperty, value);
    }
}

Activity Binding

Activity binding is where the (dependent) property of one activity is bound to the (independent) property of another activity. When the activity containing the dependent property is executed, the dependent property is passed the value of the independent property.

The dependent property must be backed by a dependency property, which the value of the independent property flows through. An ActivityBind specifies the independent property. The following XML example shows an activity binding between the preceding IncomingOrder property (of saveOrderActivity1) and the IncomingOrder property of the ProcessOrder activity.

<SaveOrderActivity Name="saveOrderActivity1" 
  IncomingOrder="{ActivityBind ProcessOrder, Path=IncomingOrder}" />

The WorkflowParameterBinding class is used to create a binding between a service operation parameter and a workflow property pointed to by an ActivityBind, as shown in the following example.

<WorkflowParameterBinding ParameterName="newOrder">
  <WorkflowParameterBinding.Value>
    <ActivityBind Name="ProcessOrder" Path="IncomingOrder" />
  </WorkflowParameterBinding.Value>
</WorkflowParameterBinding>

Run-Time Services

WF provides the following optional run-time services. Custom services can also be created.

Persistence service

Allows a long running process that is idle to be unloaded from memory, persisted to a store (such as a SQL database or XML file), and reloaded at a later time in the same state. Unloading a workflow saves memory and increases scalability. The following excerpt from the <serviceBehaviors> section of a host App.config file, shows the persistence service added to the workflow runtime.
```
<workflowRuntime name="WorkflowServiceHostRuntime">
  <services>
    <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, 
               System.Workflow.Runtime, Version=3.0.00000.0"
         connectionString="Data Source=DinnerNow;Initial 
                           Catalog=DinnerNowWF;Integrated Security=True;" />
  </services>
</workflowRuntime>
```
Tracking service

Enables a host to observe running workflows by capturing events that are raised during workflow execution.
Scheduling service

Manages how workflows are scheduled by the workflow runtime engine. These workflows can be handled synchronously or asynchronously.
CommitWorkBatch service

Enables custom logic to be inserted into the commit process of work batches (also known as persistence points).

For more information, see Windows Workflow Foundation Services.

Workflow Services

Workflow services, new for .NET Framework 3.5, is an integration between WF and Windows Communication Foundation (WCF). This integration allows WCF services to be authored and implemented as workflows, and workflows to be exposed as WCF services. The WorkflowServiceHost class, which derives from the ServiceHost class, encapsulates the functionality of the workflow runtime to route messages back and forth between WF and WCF. Two new default activities are provided to support WF services, the client-side SendActivity and the service-side ReceiveActivity.

The ReceiveActivity class implements a WCF service operation, which is specified using the ServiceOperationInfo property. ServiceOperationInfo can be set to an instance of either the OperationInfo or TypedOperationInfo class, depending on whether the activity implements a new or existing WCF service operation.

OperationInfo is used to define a new service operation. The ContractName and Name properties specify the name of the service contract and operation, respectively. The Parameters property is a collection of OperationParameterInfo instances that specify the name, type, and order of the operation's parameters, including the operation's return value.

TypedOperationInfo is used to specify an existing service operation. The ContractType and Name properties specify the service contract type and operation, respectively.

The SendActivity class communicates with a WCF service, which is specified using the ServiceOperationInfo property, a TypedOperationInfo type. The ChannelToken property, a ChannelToken type, specifies the name of the client channel and endpoint used to communicate with the service.

Both ReceiveActivity and SendActivity have a ParameterBindings property that is a collection of the bound properties of the activity.

The following example shows the XML specification of a ReceiveActivity.

<ReceiveActivity Name="receiveNewOrder">

  <ReceiveActivity.ServiceOperationInfo>
    <TypedOperationInfo
      ContractType="{Type DinnerNow.OrderProcess.IProcessOrder}"
      Name="Processorder" />
  </ReceiveActivity.ServiceOperationInfo>

  <ReceiveActivity.ParameterBindings>
    <WorkflowParameterBinding ParameterName="newOrder">
      <WorkflowParameterBinding.Value>
        <ActivityBind Name="ProcessOrder" Path="IncomingOrder" />
      </WorkflowParameterBinding.Value>
    </WorkflowParameterBinding>
  </ReceiveActivity.ParameterBindings>

</ReceiveActivity>

For more information, see Creating Workflow Services and Durable Services and Workflow Services Samples (WF). The companion topic, Developing Connected Systems, examines a sample application that uses workflow services.

New for .NET Framework 3.5

WF is enhanced with the following new and changed features in .NET Framework 3.5. For more information, see the WF section in What's New in the .NET Framework Version 3.5.

Workflow services

Integrates WF and WCF, allowing WCF services to be authored with WF workflows and workflows to be exposed as services.
New activities to support WF services

The SendActivity and ReceiveActivity classes are used to communicate through WCF services.
Changes in the WF rules engine

The WF rules engine now supports extension methods, operator overloading, and the use of the new operator. For more information, see Rule Changes in .NET Framework 3.5.