The Role of WF Activities
Recall that the purpose of WF is to enable you to model a business process in a declarative manner, which is then executed by the WF runtime engine. In the vernacular of WF, a business process is composed of any number of activities. Simply put, a WF activity is a minute step in the overall process.
When you create a new WF-enabled application using Visual Studio, you will find a Windows Workflow toolbox that contains iconic representations of the built-in activities. You will notice two areas on the toolbox, one for .NET 3.0 activities (shown below) and another for .NET 3.5 activities. The .NET 3.5 area of the WF Toolbox (not seen below) contains activities for communicating with WCF services. It is also possible to create your own custom activities, which you will do later in the course.
The Windows Workflow toolbox provides numerous default activities that can be used to model your business process. Each maps to real types within the System.Workflow.Activities namespace and can therefore be represented by, and driven from, code.
Notice how the activity icons on the Toolbox (ex: Code) are simple names of the underlying class type (CodeActivity). As a naming convention, all WF activity classes have an -Activity suffix, for example, DelayActivity and WhileActivity. When looking up an activity within the .NET Framework SDK documentation, use the full name of the type, such as CodeActivity or IfElseActivity.
The WF API provides a core set of activities that enable you to represent the following:
- A block of code statements to execute at a given point in the workflow.
- Basic iteration and decision constructs.
- Event-handling constructs.
|Code||This activity represents a unit of custom code to execute within the workflow.|
|CallExternalMethod||This allows your workflow to invoke external methods, typically found on a registered ‘local service’.|
The first two provide basic looping and decision construct support
within a workflow.
The Policy activity performs actions based on a set of associated rules.
|These activities enable your workflows to respond to external events, typically sent from the host.|
The WF API also provides a set of activities that enable you to interact with traditional XML web services. As of .NET 3.5, it provides new types to interact with WCF services.
|These activities enable your workflow to invoke XML web services, as well as be exposed from an XML web service.|
|These .NET 3.5 activities enable you to interact with WCF services.|
Other WF activities enable you to do the following:
- Control the timing of a workflow’s runtime execution.
- Manage transaction support.
- Handle exceptions and threads.
|These enable you to define wait periods, pause, or terminate a course of action within a workflow.|
|These activities enable you to raise and handle exceptions within a workflow.|
|These enable you to execute a set of activities in parallel or in sequence.|
|These activities enable you to incorporate transactions within a workflow.|
Each of the WF activities is highly configurable at design time. For example, like a GUI application, an activity can be configured using the Properties window of Visual Studio. Depending on which activity you are configuring, you will find various properties and events to tweak. Here are some options for configuring a Code activity.
When you drag and drop an activity onto the designer surface, the IDE will declare a member variable of this type in the designer-maintained file. You can name the underlying member variable using the (Name) property found within the Properties window. You can then use this member variable within your code base.
Like other designer-maintained files, Visual Studio makes use of partial classes to partition designer-generated code from your primary code file. Here is some partial code found in the designer file, once you drag a Code activity onto the designer surface.
partial class Workflow1
private CodeActivity codeActivity1;
Partial Class Workflow1
Private codeActivity1 As CodeActivity
The Activity Base Class
All WF activities eventually extend the Activity base class. Activity is defined within the System.Workflow. ComponentModel namespace of the System.Workflow.ComponentModel.dll assembly. Like any base class, Activity provides a polymorphic interface to all child types. You can extend Activity to build custom activities.
Here is an overview of some members of interest. Consult the .NET Framework SDK documentation for full details. You will see many of these members in action during your lab time, so do not get overwhelmed with the specifics at this point.
|Description||Gets or sets the user-defined description of the Activity.|
|Enabled||Gets or sets a value that indicates whether this instance is enabled for execution and validation.|
|ExecutionResult||Gets the ActivityExecutionResult of the last attempt to run this instance.|
|ExecutionStatus||Gets the current ActivityExecutionStatus of this instance.|
|Name||Gets or sets the name of this Activity instance.|
|Parent||Gets the CompositeActivity that contains this Activity.|
Here is a list of common events defined by the Activity base class. Again, you will see many of these members in action during your lab time.
|Canceling||Occurs when the Activity execution is canceled.|
|Closed||Occurs when an Activity has completed execution.|
|Executing||Occurs when the Activity is run.|
|Faulting||Occurs when an exception is raised during the running of the instance.|
|StatusChanged||Occurs when the ActivityExecutionStatus of a running Activity changes.|
Copyright (c) 2008-2013. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.