Windows Workflow Foundation

In January 2006, Don Box and Dharma Shukla introduced Windows®workflow Foundation and discussed the overall architecture of the framework and its constituent components (see WinFX workflow:simplify De Velopment with the declarative Model of Windows Workflow Foundation [English]). This article prompts me to discuss this topic further, and describes how to use Windows Workflow Foundation to handle this common business scenario where automated processes and human activities cross through. It provides a framework for developing and executing multiple applications based on complex processes. Typical examples include document management applications, enterprise-enterprise applications, and enterprise-consumer applications. Users can use Visual studio®2005 to help design the underlying workflow and related top-level applications and assemblies.

Common Business Scenarios

For tasks such as order processing, purchase requisitions, and travel expenses, organizations often have many internal processes. Workflows enable these independent processes to proceed sequentially in a transparent, dynamic, and efficient manner.

Let's look at a typical technical support workflow process. The process begins when a support person receives a customer call and opens a ticket that records the customer's name, time of call, and a brief description of the problem. Once the ticket is created, the technical support staff will put the matter aside and wait for another call. When he gets off work, he will log off the computer and go home. At this point, in another department, possibly in another city, a team of technicians is focusing on resolving these unresolved issues. Each working technician selects the request and then resolves the request or upgrades the request to a second level of help. How do I write code to implement this process?

You can use a Windows forms application to collect related input data for a phone and create a record in the database: A ticket that contains a time, description, status, and unique ID. Users of the second Windows forms application will see a live list of pending requests, then select a request. The operator will then try to resolve the problem (call back to the customer, retrieve the requested information, send an e-mail message, or perform some remote activity) and indicate whether the issue is resolved or needs further study. This decision can be represented by an imperative action, such as clicking a button to update a ticket in the same underlying database. Finally, if other categories of users are involved, the custom front-end will enable these users to indicate that the issue has been successfully closed or aborted.

Although this process clearly expresses the need for a user to make certain decisions, the workflow can be easily implemented using traditional sequential code written in standard programming languages and databases.

Apply Windows Workflow Foundation

If users have a workflow-based system composed of various activities, such as Windows Workflow Foundation, you can implement the application using a powerful combination of imperative code and declarative activity maps, as well as declarative rules that bind them. The main benefit is that users can model the solution (or even visually model it), embed Windows Workflow into the Run-time server to interpret the chart, and have Windows Workflow follow the links defined in the creation block. The more complex the process, the simpler the process is designed and implemented for it. The easier it is to process dynamic changes, the less code users need to write and maintain. Let's look at how to implement the Windows Workflow Foundation solution for the technical support solution.

Technical Support Solutions

By creating a ticket, the technical support workflow that is created starts, and then stops while waiting for the connection user or technician to give a response. Whether the ticket is turned off or upgraded, the workflow obtains external events and updates the internal state of the application to track the event. Therefore, workflows need to interact with the outside world. This type of asynchronous activity is one of the inherent problems with the actual workflow process that Windows Workflow Foundation solves. Because of the need to interact with entities outside the system, host applications and workflows can define conventions for any necessary data exchange. The Ihelpdeskservice interface shown here illustrates the communication interface established between the workflow and its host:

[DataExchangeService]
public interface IHelpDeskService
{
event EventHandler<HelpDeskTicketEventArgs> TicketClosed;
event EventHandler<HelpDeskTicketEventArgs> TicketEscalated;
void CreateTicket(
string description, string userRef, string createdBy);
void CloseTicket(string ticketID);
void EscalateTicket(string ticketID);
}