Windows Workflow: Build a custom activity to extend the scope of your workflow

This article is written based on a pre-release version of the. NET Framework 3.0. All information contained in this article is subject to change.

This article discusses:

Building basic activities and composite activities

Asynchronous and event-based activities

Custom design Experience

Validation and error handling

This article uses the following techniques:

. NET Framework 3.0

Custom workflow activities are one of the most important aspects of Windows®workflow Foundation, and many features need to be considered when building them. Don box and Dharma Shukla in their January 2006 article, "Simplifying development with a declarative model of Windows Workflow Foundation", explores the core view of building workflows and the interaction between workflow runtime and activity (please Read msdn.microsoft.com/msdnmag/issues/06/01/windowsworkflowfoundation). In this article, I'll cover the core components needed to build custom activities for your business domain, including run-time responsibilities, design-time experiences, and asynchronous activity development.

When building a custom activity, the first choice you have to make is to build a simple or composite activity. Simple (or basic) activities are those activities in which logic and execution are encapsulated within the active code. Examples of simple activities are: SendEmail activities in the Windows SDK or activities that query data from a database.

In contrast, a composite activity relies on the execution of a child activity to achieve its goal. You can create composite activities in two different ways, depending on your needs. One way to do this is to build a composite activity that allows users to add child activities at design time and control the execution of these child activities. For example, the while activity that is included with Windows Workflow Foundation allows you to add child activities and then configure the looping functionality of the while activity. While composite activities are primarily used to manage the execution of their child activities. Another way to build a composite activity is to create an activity that derives from an existing composite activity (for example, a Sequence activity) and to add a set of activities as a child activity to define reusable components.

There are several stages in which reusable activities, such as manager approval activities, are easiest to simulate using an existing set of activities. Manager approval activities can use activities such as ifelse to determine whether a manager is online. If you are online, you can send an instant message, or you can send an email. This activity encapsulates all the complex logic that requests approval, the request approval is in the workflow, and it is itself a workflow. Users of this activity simply use the composite activity in their own workflows to get rid of the complex transactions and details that they must deal with when they actually contact the manager.

To begin to understand the concept of building activities, it is best to start with a very basic activity and then gradually build it into more complex activities. To illustrate these concepts, this article uses two main activities: one for creating users in the ASP.net membership library and one for customizing the Switch activity to simulate execution similar to the code concept of the same name. The complete source code for these two activities and other activities can be found in the code download provided in this article.