Understanding Windows Workflow Foundation
- Describing Workflow and Workflow Systems
- .NET Framework 3.0 and 3.5
- Overview of WF
- Standard Modeling Activities
- Multiple Workflow Styles
- Hosting
- Tracking
- Rule Capabilities
- Custom Activities
- XAML Workflows and Serialization
- Dynamic Update
- WF and WCF
- SharePoint Workflow
- Designer Rehosting and External Modeling
- Summary
- Installation Instructions
This chapter is from the book
This chapter is from the book
This chapter is from the book
What You'll Learn in This Hour:
- What workflow is in general
- What Windows Workflow Foundation (WF) is
- The main components of WF one-by-one
- Installation instructions and requirements
This hour begins with a general description of workflow because many definitions exist. It then covers Windows Workflow Foundation (WF), first with an overview and then by diving into many of its main elements. Finally, it provides installation instructions and requirements to get you ready for the next 23 hours that are packed full of hands-on exercises.
Describing Workflow and Workflow Systems
This section provides a general overview of workflow and related topics. In addition to offering a general overview, it is intended to give you an understanding of Windows Workflow Foundation's goals as you continue through this hour and the rest of the book.
A Conceptual Description of Workflow
Workflow is another overloaded technological term. One reason for this is that its meaning has been defined by companies with a vested interest that it matches the features of their products. Another reason is that it is commonly bound to current technology capabilities. These reasons prevent it from being objectively defined. A workflow is logic—consisting of one or more steps that are predicated by one or more conditions—that a system or person must perform to complete a function. Because the logic or process automated by a workflow generally consists of more than one step that may occur over a period of time, it must track the state of the overall process. Here are some examples of workflows: an order process, an expense report, and rescheduling a missed meeting.
The order process is almost always automated using a traditional computer language. Its control flow is supported through if, while, foreach, and other statements in the C# language. The expense report may be automated using a traditional computer language or a workflow product with a graphical designer. The rescheduling is almost always performed manually. All of these are workflows, or logic. Why, then, are they automated differently? Expense reports are generally routed and escalated to people that must act on them. These touch points are called human intervention. Workflow systems are generally well suited at handling these scenarios that call for human intervention. Therefore, systems with prevalent human intervention are prime workflow system targets. The rescheduling is not automated, or rarely, because for the most part, systems are not yet ready to automate these types of tasks.
Both the order and expense report would generally have lifetimes that span hours, weeks, or months. Therefore the system used to automate them must be able to track their progression, or state. Rescheduling a meeting may only require logic to change the meeting, unless it must also await confirmations. In short, workflow consists of both logic and managing the process state.
A Sample Expense Report Workflow
A sample expense report workflow can make concrete some of the concepts about process discussed so far. Figure 1.1 illustrates a simplified workflow. The process is described directly following the figure.
)
Figure 1.1 Sample expense report workflow.
The workflow receives an expense report and checks the amount; if it is less than or equal to $500, the expense report is approved. Otherwise, manager approval is required. The workflow then removes itself from memory to free resources, and the workflow product waits for the response. The manager may either approve or reject the expense report. In either case, the workflow product reactivates the workflow. If the manager approves, the expense report is marked approved and an approval email is sent to the submittee. If the manager rejects, the corollary rejection process occurs. If the manager does not approve in time, the timeout option is triggered and manager approval is rerequested, which is depicted in the line going back to the Request Manager Approval shape.
Let's look at some of the benefits gained by using most workflow systems to automate this process:
- Design-time transparency—It is clear what the expense report process does just by looking at it.
- State management—The workflow system manages keeping track of the current step, removing the process from memory when waiting for manager approval, and going back to the approval step when required. A workflow system provides these state management features for you. In contrast, a process automated via a traditional computer language generally requires the developer to create tables and fields to manage the state themselves.
- Runtime transparency—The workflow system can also visually show the current step and the execution path of the process. This feature is generally referred to as tracking (you will learn more about it in the "Tracking" section of this hour).
Many think that there is no way to graphically model application logic because any complex process will have so many control flow statements the diagram will be unreadable, eliminating the promised transparency. A process automated with a graphical workflow application should be self-describing. It should serve the same benefit that a flowchart currently supplies (or at least most of it). Just as a flowchart does not include every single control flow statement, neither should a graphical workflow. Figure 1.1 provides a solid understanding of the process without detailing every control flow statement or diving into the individual steps. Some of the detail held is not relevant to understanding the process and does not need to be added to a workflow at all. Other steps, such as approve order, may be their own workflows with their own detail. They still show on Figure 1.1 as one step, which is appropriate because the details of the expense report approval step aren't needed to achieve a general understanding of the expense report process.
Workflow Segmentations
Workflow is also frequently segmented along in-application, human, and integration lines. Traditional languages, like C#, are generally associated with in-application workflow. Human workflow systems arose from the desire to better support human-centric scenarios. Integration systems or integration-centric workflow systems arose from the need to better automate integration scenarios using dedicated integration systems. Let's look a little closer at the human- and integration-centric workflow and the tools created to support them, because they are the roots of modern workflow systems.
Human workflow generally describes processes that require substantial human involvement and escalation. Human processes are also frequently nonlinear. A proposal, for example, may go to final approval only to be sent back to initial approval. Tasks and forms to request feedback are critical components of human workflow systems. The tasks and forms will generally be delivered to the requisite people via email, as Outlook tasks, or via a portal (such as SharePoint).
Integration-centric workflow systems are frequently used when connecting systems. Deciding whether an order should be added to SAP that is received from Microsoft CRM, for instance, may require a number of validations, such as whether all the required fields are filled out. These validations are logic, and logic is workflow.
Human workflow systems generally have better form and task support, and integration-centric ones generally process faster and have better transactional support. Although traditional computer languages are still used to automate many human and integration workflow scenarios, these other purpose-built systems have arisen as alternatives.
What Is a Business Process Management System?
The purpose of a business process management system (BPMS) is to create a system that manages processes more completely than human workflow and integration workflow systems and traditional computer languages. There are largely two, potentially overlapping, paths to this process completeness. One is to combine the strengths from human workflow and integration workflow systems. In the previous Microsoft CRM to SAP integration example, a BPMS could be used to integrate the systems and then call on its human workflow support to request human intervention in case of an exception.
The second path is application life cycle and human workflow driven. The application life cycle features generally include tools to deploy the process. Strong monitoring tools are frequently referred to as business activity monitoring (BAM). BAM builds multiple graphical views, portal integration, and business intelligence integration on top of tracking (mentioned in the "A Sample Expense Report Workflow" section) to provide enhanced analysis and monitoring of running processes. BPMSs sometimes allow running processes, such as an order, to be changed. An additional approval step, for instance, could be added to an order. Depending on their roots, human workflow or integration, a BPMS will generally be stronger at either human or system workflow. The human workflow element is gaining market momentum as the ability to interject people into processes is key to increased flexibility, a BPMS staple.
BPMSs also promise businesses better visibility into their processes. That the processes are graphically created and therefore visible combines with BAM to help achieve this visibility. They also frequently promise that business analysts can use their design tools to create processes without IT assistance.
Many BPMS proponents predict that a BPMS is a better way to do all workflow, including in-application. A mass move to using a BPMS for all workflow hasn't occurred, although this idea has attracted much interest and this may change.
This is one perspective of workflow and BPMSs. If you are interested in learning more or gaining additional information, Wikipedia is a good place to start.