- 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
Multiple Workflow Styles
WF ships with OOB support for three styles of workflows: sequential, state, and data. The third, data, is powered by an advanced control flow activity called the ConditionedActivityGroup that can be placed on both sequential and state machine workflows. It is not a standalone workflow style like the other two. It is included here as a separate workflow style because it is well suited for certain types of processes, as you will soon see. It is therefore sometimes referred to as an activity and at other times as a workflow.
Let's first start with sequential workflows (Figure 1.10), which is summarized following the figure.
)
Figure 1.10 Sample sequential workflow.
A sequential workflow, like a Sequence activity, serves as a container for a tree of activities. A sequential workflow lays out a process in a linear form from top to bottom. It is similar to a flowchart. The general convention is that sequential workflows are best suited for processes that have a linear path and that are not highly dynamic. The notion is challenged because advanced control flow activities (like the Replicator, EventHandlingScope, and ConditionedActivityGroup that you will learn about shortly) allow sequential workflows to handle some highly dynamic processes. All three styles of workflow are covered, so you can make your own decision.
The process begins with receipt of an order. It is then automatically approved, sent down the more information required path, or automatically rejected. If more information is required, it waits for manual approval or rejection with an option to timeout. As you can see, the process starts at the top, then branches, and continues to move down until completion. Sequential workflow coverage begins in Hour 2, "A Spin Around Windows Workflow Foundation." You will also want to look at many other hours that cover the different activities because it is these activities, placed on the sequential workflow, that dictate the workflow's behavior.
State machines are a very common modeling technique—for creating both executing programs and static diagrams—built on process milestones and events. State machines are largely predicated on the notion that processes are dynamic and take many divergent paths to completion. This is why state machines are frequently associated with human-centric processes. In fact, one reason WF proclaims to have the capability to support human workflow is that it includes state machine workflow modeling. Figure 1.11 illustrates a state machine workflow. Directly following the figure is a description.
)
Figure 1.11 Sample state machine workflow.
The business milestones are the states (Initial, Approval, and Completed). The events are the text within the states (Approved, Rejected). This means that in the Approval state both the Approved and Rejected event may be received. The lines from the event to the state represent the transition that occurs when that event is received. For example, when the Created event is received and the workflow is in the Initial state, the workflow transitions to the Approval state. When either the Approved or Rejected event is received in the Approval state, the workflow transitions to the Completed state. It would be just as easy to send the workflow back to the Initiation state from the Approval state if necessary. Processes with many states and many possible gyrations are solid state machine workflow candidates. No prescribed order exists. Each state is autonomous and equally accessible. Hours 6 and 7 describe creating state machine workflows.
Behind each event is a Sequence activity that holds the activities that process the work for the selected event. Figure 1.12 shows the sequential logic executed when the Approved event is selected. In essence, a state machine workflow is an inverse sequential workflow. The events are on top and the sequential logic embedded when using a state machine workflow. In a sequential workflow it is the opposite. Look at the sequential workflow and you will see the Listen activity and event embedded in the sequential logic.
)
Figure 1.12 Approval event logic.
The ConditionedActivityGroup (CAG) activity is an advanced control flow activity that can be placed on either a sequential or state machine workflow. From a process standpoint it can be viewed as an alternative style of workflow to the better-known sequential and state machine styles. Generally, sequential workflows are recommended for deterministic processes that have a well-defined beginning and end. State machine workflows are best suited for dynamic processes that iterate through states without a guaranteed order. Data-driven workflows, on the other hand, are best suited when the data determines the process execution order. Many pricing and promotional algorithms exist that may not execute a branch based on the data at the beginning of a process, but will do so later when other parts of the process change the data the branch depended on. For instance, the order may not be subject to a discount until after tallying the line items.
Depending on your needs, the CAG activity may be the only activity on a sequential workflow. In this case, all your child activities will be embedded in the CAG, and you will have created a data-driven workflow. In other cases, you may embed a CAG into a larger sequential or state machine workflow. In this case, only a subset of your workflow will be data driven.
The CAG (Figure 1.13) has three lanes. Each lane will execute one or more times during the lifetime of the CAG. The lanes execute when their When condition is true during the CAG lifetime (lanes with no When condition execute exactly once). The CAG is covered in Hour 11, "Creating Data-Driven Workflows."
)
Figure 1.13 Conditioned Activity Group sample.
Hour 2 begins covering sequential workflows. State machine workflows are covered in Hours 6 and 7. The CAG is covered in Hour 11. However, workflows are a composition of activities, so you will need to be familiar with the OOB activities, custom activities (covered in the forthcoming "Custom Activities" section of this hour), and other WF functions to create workflows of any type. These topics are interspersed throughout the book.