Tutorial Objectives:
• Understand the role of Windows Workflow Foundation (WF)
• Learn the building blocks of a WF-enabled application
• Understand the role of WF ‘activities’
• Work with the Code and While activities
• Work with the WF designers of Visual Studio
• Host workflow instances using the WF runtime engine
• Pass arguments to a workflow instance
• Examine ways to customize the hosting process
• Configure activities using declarative rule conditions
• Know the role of the Policy activity and declarative rule sets
• Handle exceptions within a workflow instance
• Learn to build custom activities
• Overview the three approaches to authoring a workflows / custom activities
Chapter Overview
.NET 3.0 introduced a new API termed Windows Workflow Foundation, or simply WF. This API enables
you to model and then execute business processes directly in your .NET assemblies.
Using tools such as Visual Studio, you are able to build workflows visually. At runtime, this same workflow
will be executed by the WF runtime engine.
In this chapter, you will be presented with a tour of the major components of the WF API, including WF
activities, the WF runtime engine, and Visual Studio project templates and tools. This chapter will serve as
the foundation for the remainder of the course.
The Motivation Behind WF
Most applications must be able to model various business processes. Simply put, a business process is a
conceptual grouping of tasks that work logically as a collective whole. A given business process consists of a
number of steps, substeps, and often further substeps that represent the entirety of the process.
Assume you are building an application that enables a user to purchase a product online. Once the user
submits the order, a large number of activities are set in motion. Take these, for example:
• You may begin by creating a new customer account, or by using an existing account, and perform a
credit check.
• You may need to verify that the item requested is in stock.
• You might start a database transaction in order to remove the entry from an ‘Inventory’ table and
add a new order in an ‘Orders’ table.
• After the database transaction is complete, you still might need to send a confirmation e-mail to
the buyer.
• You may then invoke a remote web service to place the order at the warehouse.
Collectively, all of these tasks could represent a single business process.
Historically speaking, modeling a business process was yet another detail that programmers had to account
for. This entailed authoring custom code to ensure that the application not only modeled but executed a
business process correctly. Programmers needed to author additional code to account for points of failure,
tracing, logging support (to see what a given business process is up to), persistence support (to save the state
of long-running processes), and more. As you may know firsthand, building this sort of infrastructure entailed
a good deal of manual labor.
Even after a development team built a custom business process framework for their applications, their work
was not yet complete. A raw code base cannot be easily explained to nonprogrammers on the team who also
need to understand the business process. Subject matter experts (SMEs), managers, salespeople, and
members of a graphic design team often do not speak the language of code.
Given this, developers were required to make use of other modeling tools (such as Microsoft Visio) to
represent the process graphically using skill set-neutral terms. The obvious problem here was having two
entities to keep in sync. If developers changed the code, they would also need to update the diagram and vice
versa.
The release of .NET 3.0 provided the Windows Workflow Foundation (WF) API. WF enables programmers
to design business processes declaratively using a prefabricated set of activities. Rather than authoring reams
of code to represent a given business process and the necessary infrastructure, developers can make use of the
WF designers of Visual Studio to create the business process at design time. In this respect, WF facilitates
building the skeleton of a business process, which can be fleshed out through custom code.
When programming with the WF API, a single document can be used to represent the overall business
process, as well as the code that drives it. As a single WF document is used to represent the code driving the
process, as well as a friendly visual representation of the process, you no longer need to worry about
multiple documents falling out of sync. Better yet, this WF document will clearly illustrate the process itself
and can be very useful to the nonprogrammers on your team.
There are many compelling reasons to make use of the WF API, rather than rolling your own infrastructure.
Consider:
• Using WF, you can focus on the business problem itself, rather than building a framework to
support it.
• The WF API provides a consistent way to build WF-enabled applications. Regardless of what you
are modeling, the overall WF behaves, looks, and feels the same.
• WF provides a number of additional services, such as persistence, transactional support, and
logging capabilities.
Be aware that the WP API can be integrated into any sort of .NET application. Desktop applications
(console programs, Windows Forms / WPF UIs) can host workflows. ASP.NET applications can use
workflows within a page on a web server. XML web services / WCF services can use and expose workflows.
.NET class libraries can contain workflows to be reused at a binary level.
Even though the WF API can be used within any .NET application, Windows Workflow Foundation is
certainly targeted at business apps. Business process management, application flow management, and
document management are prime candidates for the WF API. Video games, multimedia applications, and OS
extensions may not find the WF API very useful. Choosing when to incorporate WF into your projects is yet
another design issue to contend with.
• Understand the role of Windows Workflow Foundation (WF)
• Learn the building blocks of a WF-enabled application
• Understand the role of WF ‘activities’
• Work with the Code and While activities
• Work with the WF designers of Visual Studio
• Host workflow instances using the WF runtime engine
• Pass arguments to a workflow instance
• Examine ways to customize the hosting process
• Configure activities using declarative rule conditions
• Know the role of the Policy activity and declarative rule sets
• Handle exceptions within a workflow instance
• Learn to build custom activities
• Overview the three approaches to authoring a workflows / custom activities
Chapter Overview
.NET 3.0 introduced a new API termed Windows Workflow Foundation, or simply WF. This API enables
you to model and then execute business processes directly in your .NET assemblies.
Using tools such as Visual Studio, you are able to build workflows visually. At runtime, this same workflow
will be executed by the WF runtime engine.
In this chapter, you will be presented with a tour of the major components of the WF API, including WF
activities, the WF runtime engine, and Visual Studio project templates and tools. This chapter will serve as
the foundation for the remainder of the course.
The Motivation Behind WF
Most applications must be able to model various business processes. Simply put, a business process is a
conceptual grouping of tasks that work logically as a collective whole. A given business process consists of a
number of steps, substeps, and often further substeps that represent the entirety of the process.
Assume you are building an application that enables a user to purchase a product online. Once the user
submits the order, a large number of activities are set in motion. Take these, for example:
• You may begin by creating a new customer account, or by using an existing account, and perform a
credit check.
• You may need to verify that the item requested is in stock.
• You might start a database transaction in order to remove the entry from an ‘Inventory’ table and
add a new order in an ‘Orders’ table.
• After the database transaction is complete, you still might need to send a confirmation e-mail to
the buyer.
• You may then invoke a remote web service to place the order at the warehouse.
Collectively, all of these tasks could represent a single business process.
Historically speaking, modeling a business process was yet another detail that programmers had to account
for. This entailed authoring custom code to ensure that the application not only modeled but executed a
business process correctly. Programmers needed to author additional code to account for points of failure,
tracing, logging support (to see what a given business process is up to), persistence support (to save the state
of long-running processes), and more. As you may know firsthand, building this sort of infrastructure entailed
a good deal of manual labor.
Even after a development team built a custom business process framework for their applications, their work
was not yet complete. A raw code base cannot be easily explained to nonprogrammers on the team who also
need to understand the business process. Subject matter experts (SMEs), managers, salespeople, and
members of a graphic design team often do not speak the language of code.
Given this, developers were required to make use of other modeling tools (such as Microsoft Visio) to
represent the process graphically using skill set-neutral terms. The obvious problem here was having two
entities to keep in sync. If developers changed the code, they would also need to update the diagram and vice
versa.
The release of .NET 3.0 provided the Windows Workflow Foundation (WF) API. WF enables programmers
to design business processes declaratively using a prefabricated set of activities. Rather than authoring reams
of code to represent a given business process and the necessary infrastructure, developers can make use of the
WF designers of Visual Studio to create the business process at design time. In this respect, WF facilitates
building the skeleton of a business process, which can be fleshed out through custom code.
When programming with the WF API, a single document can be used to represent the overall business
process, as well as the code that drives it. As a single WF document is used to represent the code driving the
process, as well as a friendly visual representation of the process, you no longer need to worry about
multiple documents falling out of sync. Better yet, this WF document will clearly illustrate the process itself
and can be very useful to the nonprogrammers on your team.
There are many compelling reasons to make use of the WF API, rather than rolling your own infrastructure.
Consider:
• Using WF, you can focus on the business problem itself, rather than building a framework to
support it.
• The WF API provides a consistent way to build WF-enabled applications. Regardless of what you
are modeling, the overall WF behaves, looks, and feels the same.
• WF provides a number of additional services, such as persistence, transactional support, and
logging capabilities.
Be aware that the WP API can be integrated into any sort of .NET application. Desktop applications
(console programs, Windows Forms / WPF UIs) can host workflows. ASP.NET applications can use
workflows within a page on a web server. XML web services / WCF services can use and expose workflows.
.NET class libraries can contain workflows to be reused at a binary level.
Even though the WF API can be used within any .NET application, Windows Workflow Foundation is
certainly targeted at business apps. Business process management, application flow management, and
document management are prime candidates for the WF API. Video games, multimedia applications, and OS
extensions may not find the WF API very useful. Choosing when to incorporate WF into your projects is yet
another design issue to contend with.
WF Tutorial
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