19.1. Introducing Workflow Concepts
Most businesses have processes that involve steps or stages in which work is performed. Every stage might have its own logical implementation related to or completely oblivious of other stages. These stages and the actions performed in them form a workflow for a process. To facilitate implementation of such workflows in applications, Microsoft provides a framework for developing workflow-based applications. This framework is part of .NET Framework 3.0 and is called the Windows Workflow Foundation (WF).
Workflow applications, like many business processes are, can be very complex and long-running. They might involve human interactions that are unpredictable and have to accommodate dynamic changes that are inherent in today's business processes. For example, it might take weeks for an approver to review a document and decide what action needs to be taken next in the workflow process. If the workflow application is allowed to keep running for the entire duration while the approver reviews the document, it would just be a waste of resources of the machine on which it's running. There might be many approvers and many more documents. Think of the multiple long-running workflow applications running at the same time on the machine. You can imagine that the computer running these workflow applications will soon run out of all resources.
This and many such design considerations and issues with workflow applications have been innovatively addressed in the WF framework. Like most Microsoft frameworks, WF isn't a workflow application nor does it have a user interface. It's mostly an architectural implementation that provides the class libraries, functions, and a WF runtime engine that facilitate the development and functioning of the workflow applications. Using a development tool, such as Visual Studio, you can develop a Windows- or Web-based workflow application by using the class libraries provided in the WF framework. When an instance of the workflow application runs, the WF framework is loaded into the application's process and provides the runtime engine and services to the workflow instance. In the case of SharePoint, which is a Web-based application, the WF framework is loaded into the Internet Information Services (IIS) worker process where the workflow instance runs.
NOTE
A workflow instance is a running state of a workflow application. You might have multiple instances of the same workflow running at the same time with different states. For example, two instances of the same approval workflow may be running when the approval process begins on two documents. The WF framework is responsible for maintaining the states of these workflows without them interfering with each other.
Windows Workflow Foundation provides the runtime engine and services that execute the workflow and provide support for persistence, tracking, transaction, and interaction with other processes.
19.1.1. Exploring the workflow architecture
Technically, a workflow is a set of activities that define the business process for which it's being developed. By default, the WF provides a number of base activities that developers can use to design their workflows. Alternatively, developers can derive workflows from the existing activities and create their own to implement a specific business logic. After the workflow is developed, the WF provides a number of components that help in the execution of the workflow.
19.1.1.1. Workflow runtime engine
Windows Workflow Foundation makes available a runtime engine responsible for executing WF workflows. This runtime engine is basically a library that can be hosted in any Windows process, including console applications, forms-based applications, Windows Services, ASP.NET Web sites, and Web services. Also, it's customizable and allows developers to have their own version of the runtime with specific implementations.
The runtime engine provides the workflow instances running in the host process with scheduling services and the framework to communicate with the host process and the other processes. The runtime engine uses a number of services to provide workflows with persistence, scheduling, transaction, and tracking services. Figure 19.1 shows an example of a workflow execution architecture.
Figure 19.1. A diagrammatical representation of a workflow execution architecture
19.1.1.2. Workflow runtime services
The Workflow runtime engine described previously relies on a number of services when it runs a workflow instance. Although these runtime services are pluggable, which means developers can derive their own implementation of these services, the WF provides out-of-the-box implementations of the runtime services:
Persistence: As indicated earlier, it's innate to workflows that they're long-running applications. A real-time implementation of a business process, such as document approval, can take days, weeks, or even months. Keeping the workflows running while waiting for user input is simply a waste of resources. Persistence services in WF provide the runtime engine with the capabilities to enable workflows to remain active for long periods of time and survive application restarts. While waiting for user input, the state of the workflow instances can be unloaded from memory and serialized into a storage device, such as an SQL database or an XML file. This process is sometimes called dehydration. Whenever the input is received, the workflow runtime engine rehydrates the workflow instances by loading the workflow state back into memory and continues execution of the workflow. While the runtime engine decides when to persist workflow instances, the persistence service decides how and where to save the workflow state.
Tracking: Tracking services provide the runtime engine with the ability to extract and store information about the workflow instances currently running in a host process. Whenever an event occurs during the life cycle of a workflow instance, the tracking framework allows the runtime engine to track a specific field, property, or column and then extract values. For example, the WF tracking service can be use to track when a particular activity in a workflow was started, when it ended, and what the state of the fields were during these events. This information can later be used for display, monitoring, and notification purposes.
As mentioned previously, while the WF provides default implementations for these runtime services, it enables developers to replace the default implementations with their own customization versions. SharePoint in particular uses this nature of workflow runtime services and uses customized implementation of persistence, tracking, notification, and messaging runtime services.
19.1.2. Types of workflows
The Windows Workflow Foundation has been primarily designed to cater to all workflow types in a single architectural implementation. System workflows are the workflow types that don't require or rely on human interaction. While these workflows are easier to implement, they're not the commonly used or desirable ones. Most business processes demand that the workflows entail human interaction at some level. These workflows, commonly referred to as human- or people-driven workflows, depend on or even encourage human participation. Human workflows in general have the following characteristics:
The key characteristic of human workflows is that they're designed to support long-running processes with life cycles measured in days, weeks, and even months. Human intervention implies that the workflow's execution stops at some point of time until an external event, usually triggered by some user interaction or system event, progresses the workflow. The success of the workflow solution is defined by how efficiently it can handle the pause in the activity and resume later.
The ability to monitor the state and progress of the workflow is another key piece. Humans tend to be critical and need data for analysis of the state of a business process. The workflows should be able to display, monitor, and notify the state of the process at durations governed by humans.
While the WF accommodates the previous characteristics in its architecture, it provides the following choices for workflow design:
Sequential workflows: Sequential workflows progress in steps like a flowchart. Based on the conditions encountered, the flow of the process can be directed to perform the associated activities. You can decide whether you want to execute steps one at a time or in parallel. These workflows are characterized by the fact that they have a defined path of execution and have a beginning and an end. Figure 19.2 shows an example of a sequential workflow. Most workflows created by SharePoint Designer fall into this category.
State machine workflows: Unlike the sequential workflows, the state machine workflows transition between various stages or states. Although one state might be considered as a final state, it's not mandatory for the state machine workflows to have an end. The workflows are characterized by providing the ability to the end user to move from one state to another and then back to the previous state. Figure 19.3 shows an example of a state machine workflow.
Workflows can be created by using any .NET programming languages, such as C#, Visual Basic, etc., or defined in XML style by using Extensible Application Markup Language (XAML). While Visual Studio is the development tool for advanced workflow creation, SharePoint Designer provides Web designers with an interface-based designer tool for developing workflows specifically for SharePoint Web sites.
Figure 19.2. An example of a sequential workflow
Figure 19.3. An example of a state machine workflow
