Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Gain Architectural Control with Windows Workflow Foundation : Page 4

Windows Workflow Foundation helps you design both sequential and state-driven workflows, simplifying the process of building applications to handle complex human-centric processes.

Applying Windows Workflow Foundation
There are a number of scenarios that lend themselves to solutions that involve workflows; to help you determine when to use workflows, here are some guidelines. Consider using a workflow when you need to:

  • Model a long-running process
  • Model a process that has multiple states with complicated relationships
  • Coordinate work where some portions are done by people and some by software
  • Coordinate multiple processes based on their outcomes
  • Compensate for cancelled processes automatically
  • Track and audit multiple processes
Automating a Simple Approval Process
Approval processes often need to coordinate work done both by people and by software, and so lend themselves to solution with a workflow. For example, as discussed in the preceding section, Office 2007 already includes a rather sophisticated Approval workflow that involves sending email through Outlook and getting secure approvals via SharePoint, which I won't go into here.

But consider a very basic Approval workflow that needs only one IfElse activity, with two branches, as in Figure 5.

Figure 5. Basic Approval Workflow: The figure shows the process of debugging a simple workflow with Visual Studio 2005.
This happens to be a standard Microsoft workflow sample, called SimpleSequentialWorkflow. It's unrealistic because the code behind the IfElse activity always sets the result to true and forces the result to the Yes branch:

private void IsUnderLimit(object sender, ConditionalEventArgs e) { e.Result = true; }

A somewhat more realistic example could obtain the yes/no result from a user, employing a dialog to retrieve the result, either in a console window or in a pop-up message box or form. For even more realism, you might use the XML result of an emailed InfoPath form to determine the result, or go whole hog and invoke a workflow that generates a secure Web page for the approver, sends an email approval request, listens for the approval or rejection, and then deletes the generated Web page.

Dynamic User Interfaces
One of the more interesting uses of workflows is to present the best user interface for the current state of a complex event-driven application dynamically. For example, a customer support representative may take incoming telephone calls for multiple products. For each product, there can be dozens of possible symptoms, and there will be a possibly complex fault diagnosis tree for each symptom.

While it's possible to code this application as a series of menu picks, scripts to read to the customer, and collections of radio buttons and checkboxes, the application would tend to be difficult to use and difficult to maintain, and the agent would have to do quite a bit of screen-switching. A backward-chaining expert system might be another alternative, but it might be even more flexible to model the diagnosis process as a state machine workflow. At each state, the user interface presented would take into account the knowledge gathered so far and the possible choices, which would trigger transitions to more refined states.

One of the major car rental companies has done exactly that, implementing a dynamic user interface system controlled by workflows for its rental agents. Depending on the information and goals presented by the customer, the system looks up what data it needs from the corporate database, presents the agent with the appropriate form to gather the additional information needed from the customer, and eventually triggers the correct printed contract. This saves the agent quite a bit of time, and makes the company look good to the customer.

Figure 6. Accounts Payable State Machine: Here's one possible state machine workflow to handle the process of paying an invoice.
Modeling a Business Process
Earlier, I introduced the classic Accounts Payable business process for handling an invoice. Figure 6 shows one possible state machine workflow to handle this.

This is merely a first cut at the model. One obvious refinement would be to automatically invoke a new workflow to listen for the next invoice whenever the InvoiceArrives event fires. Another would be for the RequestApproval initializer in the InvoicePending state to generate an email and secure Web page specifically intended for the approver or approvers, as discussed earlier. Still another might be to combine the InvoiceApproved and InvoicePayable states, and have the AgePayable and SendPayment steps be an internal sequence inside the InvoiceApproved state.

It might also be useful to add additional steps in certain cases. For example, if the process reaches the InvoiceRejected state, there might be reasons for the rejection that require taking other actions. For example, if the invoice was rejected because the PO has insufficient funds, but the contract supporting the PO has funds, the InvoiceRejected state could invoke a workflow to ask for an extension to the PO.

I have discussed how Microsoft Windows Workflow Foundation works, when you might want to use it, and how you might choose different types of workflow—but I have only touched the surface in showing you its capabilities; I hope that you'll follow up by downloading the product and trying it yourself.

Martin Heller is a Web and Windows programming consultant. He writes from Andover, Massachusetts.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.