Working with Windows Workflow Foundation in ASP.NET

In September of 2005, Microsoft unleashed Windows Workflow Foundation (Windows WF) at its semi-annual Professional Developer's Conference. As one of the pillars of the WinFX APIs, Windows WF provides developers with a common framework on which to develop process driven and workflow-centric applications.
Currently, when organizations wish to automate business processes the standard answer is to assemble a team of developers to write the appropriate code. While this approach has generally served organizations well, it has some inherent problems. To understand why, you need to understand some fundamental characteristics of a workflow.
A workflow is essentially a way of documenting the activities involved in completing a unit of work. Typically, work "flows" through one or more activities during processing. These activities can be performed by either machines or by people, and can be as simple as defining the sequence of pages in an Internet application, or as complex as managing documents or products that must be seen, altered, and approved by any number of people.

Because so many workflows must allow for human involvement, they can take long periods of time to complete, ranging from hours to months or longer. For example, people involved in the process may be unavailable, out-of-town, or busy with other tasks; therefore, workflows must be able to persist themselves during periods of inactivity. Furthermore, processes implemented solely using code can be difficult for non-technical people to understand and for developers to change. This and other factors are the target of generic workflow frameworks such as Windows WF, which aim to make creating, altering, and managing workflows easier, both by giving them a visual interface and by defining a common API
You can host Windows WF workflows in any type of .NET application, including Windows Forms, console applications, Windows Services, and ASP.NET Web applications. Each type requires special considerations. While examples that showcase hosting workflows in Windows Forms and console applications are already plentiful, this article focuses on issues facing ASP.NET developers who wish to integrate workflow into their applications.
Windows WF and the MVC Pattern
One common way in which you might use Windows WF in an ASP.NET application is to implement a Model-View-Controller (MVC) approach. Essentially, the goal of MVC is to separate the presentation layer, application logic, and application flow logic from each other.

To illustrate how this would be useful in an ASP.NET application, consider a help desk ticket workflow scenario. A business user starts the workflow by filling out an ASP.NET Web form and clicking a submit button. Next, a server notifies a help desk employee using a Windows Forms application that a new ticket is available. The help desk employee would then work on the problem, and eventually close the ticket. If this workflow scenario were developed using Windows WF, all the process logic and flow could be contained in the workflow itself, and the ASP.NET application would need to know nothing about the logic.

This scenario provides some solid evidence that separating presentation from logic is a good thing. Because the process of handling help desk requests is common, if the logic were implemented using C# or VB.NET code in several different .NET applications, you'd run the risk of duplicate code or worse, different implementations of the same business process in completely different code. But if you implement the process in Windows WF, the developers of applications that need the process would need to modify the steps in only one place—the workflow itself—without worrying about changing logic in their applications. Code duplication and the ambiguity of where to implement process can be mitigated with Windows WF.

When implementing the MVC architecture in ASP.NET using Windows WF, developers should attempt to build workflows independent of the applications in which they will be hosted. This will assist in keeping logic separate from presentationand maintain a high degree of independence between the order of workflow steps and page flow in the Web application.

A novice Windows WF developer might be tempted to develop a workflow with a set number of activities in a certain order and afterward, develop a set of ASP.NET Web forms that flow from one to another in the same order. Unfortunately, while that seems logical, it's counterproductive, because you would be implementing the workflow logic twice. Web page X should not need to know whether it needs to go to Page Y or Page Z to implement the workflow steps correctly. Instead, the workflow (the model) should tell ASP.NET (the controller) what the next step is, and then ASP.NET should determine which page (the view) to display. In this way, each page requires little knowledge of the overall process; it only needs to know how to complete one distinct activity and let the workflow worry about how the pages flow from one to the next. This separation provides developers with a great deal of flexibility related to the order of page flow. For example, if you decided to change the page display sequence, you could easily do that in the workflow, without changing one line of code in the ASP.NET application.

For Sample Application and Code ....> next Article

Read More

WWF Tutorial Understanding for Beginners

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.

Read More