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.
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.
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.
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.
// C#
partial class Workflow1
{
...
private CodeActivity codeActivity1;
}
' VB
Partial Class Workflow1
...
Private codeActivity1 As CodeActivity
End Class
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.
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.
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.
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.
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.
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.
// C#
partial class Workflow1
{
...
private CodeActivity codeActivity1;
}
' VB
Partial Class Workflow1
...
Private codeActivity1 As CodeActivity
End Class
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.
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.
WF Activities
Table of Contents
Copyright (c) 2008. 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.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
|
|
|
|
|
Services