Currently, Microsoft has no consistent model for the amazing technology among the workflow implementations in BizTalk (Framework 3.0), SharePoint 3.0 (Framework 3.0), and Visual Studio 2008 (Framework 3.5). Until there is a unified, consistent, and well-documented paradigm for incorporating workflows into applications, this reviewer will not implement workflows to a large extent in production applications, but sparingly will use workflows in a minor way to provide experience only.
At some point, business analysts should be able to understand the drag-and-drop, visual part of workflows, and programmers will just supply the code to implement activity functionality. The business analysts (with a little technical expertise) should then be able to design a visual layout of business logic much like analysts are now providing in detailed business flow diagrams.
Programmers or technically savvy business analysts can easily convert procedural steps in business process diagrams into Sequential Workflows as shown below (see Figure 5 below):
When converted by the programmers or technical analysts to a Workflow, the sequential business activity would look like (see Figure 6 below):
Figure 6: The Visual Studio Sequential Workflow Diagram
The “AnInitialProcessActivity” activity sets the “ifElseActivity1” condition to true, and the Workflow processing follows the “YesBranchOfIfElse” branch by executing the “AnotherActivity” code. If the “AnInitialProcessActivity” activity had set the “ifElseActivity1” condition to false, then the “AlternativeActivity” branch code would have executed. Notice that the application processes drive activities in the above Workflow above which is a prerequisite for a Sequential Workflow.
Windows Workflows can eventually control business processing through policy and rules based on declarative execution that is not compiled, but is rather interpreted as the application executes. Some of the features in .NET are declarative without writing code and include data binding and templated controls. WF has similar concepts that implement business processes by binding rules and policies rather than data.
In procedural code, applications apply imperative or procedural processing methods that are based on relationships, and these often translate to many nested “if” statements, “switch” or “select” statements, and loops. Workflows have a better way since the developer can build declarative rules and utilize a rules engine to process them. Declarative rules describe relationships and are well suited to applying priorities to potential decisions. The rules engine accepts XML-encoded rules and applies those rules to methods and fields in a workflow. With WF, programmers can combine both imperative and declarative rules to form a new type of an application solution.
The Windows Workflow Foundation provides three main types of Workflows: Sequential, State Machine, and a new variation called Data-Driven. For the construction of Workflows, developers need to utilize Activities, the smallest piece of action that the flow employs. Additionally, a Workflow requires a Host in which context the process will be executed (e.g., an ASP.NET application, a WCF service or, beginning with .NET Framework 3.5, self-hosted in a WCF/WF combination called Workflow Services).
A Sequential Workflow is a top-down process, also known as a human flow process, where the activities execute from a beginning situation and end after a predefined sequence of steps. Each human activity can be described as a function of a Sequential Workflow; business authorization activities are a well-known type of this Workflow. Consider tasks such as appeals processing, expenses disapproval, or purchase requests as typical scenarios of this kind of flow. Sequential Workflows are self-driven, and once they are initiated, they have a totally predictable behavior throughout the execution of the activities.
The State Machine Workflow does not have a defined path but represents a set of states and transitions between these states. State Machine Workflows are event-driven; that is, each state can be activated after a predefined action has taken place; then, the engine executes the activities needed and stops after completion of the next state. There is no deterministic execution path between the steps because the Workflow does not execute in a chronological order.
State Machine Workflows are the solution for complex modeling processes. Visualize an order supply process where an order can have different states: received, approved, and shipped. In a sequential model, the only way to realize a Workflow is by using loops and decision algorithms that code all possible paths of the order (if received appeal data is not complete then..., if an appeal is already accepted by the SSA, wait until..., and so forth). The State Machine provides a very convenient design pattern that defines a state of the process and includes all the variables to make it valid (following the last example; a state can be received when all the data of the appeal is present before the process can go on to the next state: approved. Each state is stopped after completion and an external event, generated by the state itself, can promote it to the next state).
Not every Workflow problem lends itself to a State Machine over a Sequential Workflow. State Machine Workflows offer a natural, rational model where the state and the present activity of the process that is being executed are more important than the order of the steps to complete. In situations requiring many unplanned steps to track and where it may not be possible to represent all the possible paths to follow, a State Machine Workflow can be easier and more orderly to program.
Activities are the construction blocks and the smallest constitutive element of a Workflow. An Activity represents an action in a Workflow; it can be anything from a straightforward action (as a timer) to a composite action that consists of an assembly of several activities. They can be aggregated into a Workflow by using Microsoft Visual Studio 2008, an external tool, or programmatically to form a complete process. Activities can also be sequential, as the whole Workflow itself, where the order of the steps is predetermined at design time, or it can be event-driven, where the order of the actions is determined at run time in response to external events, as in the State Machine Workflow.
The WF contains a library of standard Activities and also provides the mechanisms to create your own, thus ensuring reusability between different Workflows. The included Activities provide functionality for communication with services and applications, control flow, event handling, conditions and looping, and state management. Some Activities can act as a container for other Activities: Exception handlers, Compensation, and Event handlers can host every kind of activity; so defined, the Sequential Workflow and the State Machine Workflow are also Activities of a special kind that contain complex definitions.
Different types of Activities are the Condition Activities—Sequence, Parallel, While, IfElse, ConditionedActivityGroup and Replicator—that contain conditions and rules to control the flow of the actions. Another group of Activities are the "Workflow Lifetime Activities:" InvokeWorkflow, Suspend, Terminate and Delay that affect the life and handling of time in the Workflow. With the latter group of activities, it also is possible to execute other Workflows asynchronously, allowing for cascading Workflows and the reuse of existing ones.
The Event Waiting Activities group, namely EventDriven and Listen Activities, enable the processing of a Workflow to be stopped until some external action occurs; the Listen Activity contains multiple EventDriven activities and works as a container for events of a different kind. The Transaction and Exception Activities group, TransactionalContext, Throw, ExceptionHandler, and Compensate Activities, catch and throw exceptions, permit the processing to continue after any exception has occurred, and make it possible to define short- and long-term transactions inside the Workflow.
As a final point, the Code Activity is considered the most utilized Activity for programming custom algorithms in the Workflow because it permits adding code handlers everywhere in the Workflow. This Activity enables developers to insert .NET code—such as C# or Visual Basic .NET code—into the Workflow and to compile this code together with the code-behind of the Workflow. However, developers also can create and deploy many Custom Activities to accomplish tasks like FTP file transfer and other specialized functions added to the Workflow 3.0 toolbox. The developer can drag-and-drop these Custom Activities onto a Sequential or State Machine Workflow or Activity container (called a composite activity made of other activities).