Windows Workflow Foundation is one of main new technologies that are included in .NET 3.0.
What Is Workflow?
In the business world, workflow is how an item is moved from one person to another through a process. That process is the business process, and it defines the steps necessary to complete a piece of work. Steps in the process can be required or optional. For example, a business process for a vacation request might be that the employee must provide some information, such as the dates requested, to his or her supervisor. Then, the employee's supervisor must determine if the employee has vacation time to use, and if the date or dates requested are available for vacation. The supervisor must provide the date information to the human resources department. Finally, the human resources department verifies that all policies have been followed, and provides the information to accounting at the appropriate time so payroll adjustments can be made.
Notice that I didn't mention technology in my explanation of the business process. Business processes should be defined absent of technology. However, you can see there's a flow to the work. Also, notice that at several points in the flow, decisions need to be made. For example, the supervisor must make sure the employee has vacation time to use, and the company might have specific requirements about the number of employees that can be on vacation at the same time within a department. Because the flow can't move from one step to the next without some criteria being met, this is a state-based workflow. A state-based workflow means that each step of the flow has criteria that must be met before the flow can continue to the next step. A state-based workflow waits on external entities to perform some action before moving to the next step.
This example of workflow has a large amount of potential branching. Within a workflow, branching is when a decision needs to be made, such as when the supervisor must determine if the employee has enough vacation time to use, and if company policies related to staff size within a department will be met. In this case, two decisions need to be made: first, if the employee has vacation time to use, and second, if policies have been met. For each branch in a workflow, there must be at least two alternatives. You can't have a workflow just stop at a decision point. For example, the supervisor can't determine that the employee doesn't have enough vacation time and simply stop the workflow. Some step must still be taken to let the employee know the vacation request has been denied. So in the supervisor step, the branching involved would be as follows: if the employee has vacation time then approve, and if the employee doesn't have vacation time, don't approve the request and send it back to the employee.
Another type of workflow is sequential. Sequential workflow is a workflow whose steps are performed one right after the other, but might include branching. In this case, sequential refers more to continuous operation, instead of the order in which actions are performed. The traditional concept of sequential in programming is without branching, but when related to workflow, sequential means continuous, instead of without branching. Steps in a Sequential workflow don't wait for an external entity to perform the next step. You can think of the Sequential workflow as close to continuous. There might be some external entity's action required to begin the flow, but once the flow is started, little if any external action is needed. Technology must be applied to a business process. For example, you might have a process that automatically updates a sales order as complete, and sends an e-mail notice to the customer and the sales person when a sales order is shipped. An external entity must start the process by saying that the sales order has shipped, but then some system would mark the sales order as complete, determine the customer's e-mail address, determine the sales person's e-mail address, and then send the e-mail. Once an external entity initiates the flow, the flow continues until an exception is encountered or the flow is completed.
When to Use Which Workflow Type
Sequential workflow within WF follows the traditional thinking of workflow. That is, the workflow is in control. As long as the process is simple and rarely goes outside the bounds, then a Sequential workflow will work. For example, an employee performance review workflow might have an employee's supervisor create a review and send the review to the employee. The employee sends the review back to the supervisor, and the supervisor sends the review to the employee. The supervisor is involved twice, but there's little room for deviation from the flow. This is a good example of a Sequential workflow. Again, remember that just because the flow is sequential doesn't mean it can't have branching and looping.
On the other hand, State Machine workflow deals with different states. A process that can have many different iterations is a candidate for a State Machine workflow. A help desk system would be a good candidate for a State Machine workflow. For example, a user creates a ticket and that ticket goes into a queue. The state of the ticket is pending. The help desk manager reviews the queue and sets a priority. Also, the help desk manager then assigns the ticket to a technician. The state of the ticket is now assigned. The technician says to begin work on the ticket. The state is now Working. However, the technician must wait for information from another vendor. The state goes to pending vendor. After some time, the vendor returns information. However, the technician doesn't have time to work on the ticket, so he assigns it to another technician. The state is back to assigned. The technician begins and completes the work and the ticket is closed. The state is now closed. Performing this type of process with a Sequential workflow would require a lot of while loops and if branching, because there are so many possible statuses and not every ticket would use each state. Most tickets wouldn't use the pending vendor status, but some tickets might.
Why Use Workflows?
Why might you even want to use workflows? I can, and have, created a help desk application with the same complexities mentioned earlier as an ASP.NET application with Visual Basic. The biggest reason to create workflow, especially with WF, is that you're creating a model. Most projects that facilitate a business process have some type of model associated with them. This model might be use cases and UML diagrams, or it might be as simple as a flow chart. These are models—ways to look at the process. With WF, the model and the workflow are the same thing. You use pieces of the business process to make a workflow, and you piece together the business process, which makes a model. Before WF, you'd create UML diagrams that showed how classes were to interact, and with some tools you could get the diagrams to create class definitions automatically, along with method and property definitions. With WF, when you're laying out the business process—that is, modeling the business process—you're also building the application. WF also has other facilities that help take care of a great deal of the plumbing related to workflow. For example, you can persist workflow data, so that even during a reboot, running processes can be started from the point they stopped. Finally, WF allows processes to change on the fly. You can change the process while instances of the process are running, and the instances will adhere to the new process.
