Windows Workflow Foundation - A New Programming Concept

Posted by Sambeet Patra under .NET Software Development, Software Architecture

Windows Workflow Foundation (WF) is a framework developed in .Net to build workflow-enabled applications. It provides an extensive and powerful base for design and development of systems that incorporate both system workflow and human workflow across a variety of scenario. The framework provides seamless development experience with other .NET Framework 3.0/3.5 technologies, such as Windows Communication Foundation and Windows Presentation Foundation.

This perhaps sounds like an extract from the marketing text from the Microsoft brochure. But upon careful analysis you are bound to discover interesting facts about WF. WF takes a radically different approach towards conceptualizing workflow based systems. Since it breaks the conventional assumptions of application development, people find it difficult to understand how WF works and whether there is any benefit in adopting this framework. In this article, I will explain the key concepts driving the design of WF and present the framework features at a high level.

What is a Workflow?

A workflow is a sequence of activities that typically involves decision making. Here is a very simple example. The following is the workflow to process shipment request of goods from a warehouse.

• Receive the order.
• Identify if inventory is available.
• If sufficient inventory is not available,
  • Inform the requester about a back order situation.
  • Request refill of inventory to the vendor.
  • Wait for 3 days and check if a refill confirmation has been received.
• Once the order is processed, inform shipment agency for a pick up.
• Verify after 1 day and escalate if items have not been picked up.

There is nothing complex here from a business perspective. Let us look at the graphical representation of the workflow:

Each step is an activity with definite rules and restrictions. So, simply put, a workflow is a set of activities ordered in a definite sequence. An activity can be anything from execution of instruction to decision making.

So, Why a framework for Workflow?

If we have to design a software solution for the above process how do we go about it?

Following the conventional approach we will build windows / web based application and implement the individual steps.However, there are some constraints involved in this:

• Some of the steps involve manual intervention and decision making. For example, consider the step for receiving resolution when we escalate to courier agency. The flow from this point is entirely dependent on the courier agency. We do not know when the courier agency is going to respond back. So we need to write software that “reacts” to real life events. As developers / architects we will promptly implement a user interface to accept this event as an input from the user. However, in today’s world people look for end to end integration and it may not always be acceptable to expect the user to manually trigger such events through a UI.
• Not all workflow are composed of continuous steps. There are cases where there is predefined pause in the process. Consider the verification of verification of inventory refill after 3 days. The process comes to a waiting point here for 3 days. How do we write program for such cases? Technically it is possible to write programs that pause for a specific period of time. But it is not a scalable solution and if the system goes down the process terminates abruptly.
• As discussed in the first two points, using the traditional approach this process cannot be implemented by a UI based program itself. There needs to be some additional components for monitoring / asynchronous processing of certain events in the workflow. This is where the overall design becomes complicated. As a result, we have another potential issue to deal with. What if there are changes in the process. Let us say we have changed the courier and now there is a different set of rules / constraints to create shipping instructions. Imagine how many components we will need to change on an already existing complicated design.

The problems discussed here arise mainly because we are trying to solve workflow that can execute over a considerable period of time using programming approach that primarily deals with real time execution. Implementations like this pose a number of question in the mind of the developers. An elegant implementation needs to consider the following aspects

• How do you maintain information the state of the workflow for this length of time?
• How can the complications of asynchronous inter process communication be simplified?
• How can changes be applied to an existing process while the workflow is in execution?
• How do you handle human intervention?

Enter, Windows Workflow Foundation

WF adopts the following key strategies to address workflow requirements:

Framework Based Approach: WF is not a tool, it is a framework which is inbuilt to .Net. Developers can make use of the graphical workflow designer available in the VS 2008 [or VS 2005 extension]. However, they can also choose to write code to implement the workflow. In either case, it is the same framework that provides the workflow capability. Further, as with any other .Net feature, WF can be implemented in multiple languages. SO why is a framework based approach so critical? Consider the example above. Each activity or step requires us to implement logic in a specific problem space. The technology / solution for communication with shipping courier may be completely different from the solution for communicating with vendor. WF allows us to be able to implement the Workflow steps in a distributed manner andd yet orchestrate the overall flow as a single workflow.

Common Technology: Since WF is a part of the core .Net framework, it can be used by any .Net based solution. Microsoft products like Biz Talk Server, Microsoft Dynamics CRM etc are soon going to adopt WF to implement workflow requirements.

Human Factor: A real life workflow involves interactions among people. Applications interacting on behalf of people need to be much more flexible and extensible. A person taking part in a workflow process may make decisions that are unpredictable and unforeseeable. Users can decide to cancel a process unexpectedly. WF accommodates such scenario by exposing functionalities to adopt human factor. It is possible to add steps / makes changes to a workflow in execution using the WF features.

Hosting: A workflow system is effective only if it is self sufficient. Since WF is an integral part of the .Net framework, any windows process can be used to host workflows. So, the host for running workflow processes can be a windows service / console application / even a UI program.

Reactive Programs : A key Concept

Before we delve deep into the WF architecture fundamentals, it is necessary to understand the key concept that has made WF feasible. We have already discussed that real life workflows may not be a step of sequencial operations and we have to account for unpredictability especially because of manual intervention. This concept prompted the WF architects to look at program with a different approach.

Think of a situation where you are subscribing to a new website. You will typically go though a number of screens and input a lot of information before the registration is complete. Now, the web site takes you to the next screen only when you submit the information in one screen. So, the registration process comprises of a set of steps, each requiring an action from the user. This simple example explains the reqality of real life workflows, where programs “react” to external events. WF frameworks enables you to design workflow where each individual component can be made to execute upon the occurence of an external event. This event can be a completion of another task, an input from the user, a signal from another system etc.

The other key concept is maintaining the state of a process. Think of the subscription process where you have to go through several pages. What if the website goes down before you are done? Or, what happens if you remain idle for a long time on one specific page? Chances are, you will have to start all over again. This is definitely not an acceptable situation for business critical workflow systems. WF builds in the capability to persist the current state of the workflow. A workflow will resume even after you restart your workflow system.

WF Architecture Overview

Workflow Designer: This is a ui based component that lets you design workflow visually. However, this does not force you to use any specific application or tool. It is possible to embed the design capability to other GUI systems.

WF Base Activity Library: A workflow is a combination of activities in a specific order. The activity library is an out of the box list of activities provided by WF that can be readily used in your workflow.

Custom Activities: WF allows you to extend the existing activities and define your own custom activity that can suit your specific needs.

Workflow: This is what you design using the above 3 components.

.Net Runtime Support: The .Net runtime includes WF specific functionalities that can be used to execute workflows. This has built in capabilities to manage life cycle of the workflows.

Workflow Types

As described earlier, WF supports system as well as human workflows in a unified manner. System workflows execute activities in pre-defined fashion, where as human workflows are unpredictable. To cater to such disparate needs, WF provides two types of workflows: sequential and state machine. Sequential workflows are suited for system workflows where as the state machine workflows are capable of responding to events as and when they occur.

Sequential Workflow:

The example shown above was designed using the visual designer for sequential workflows. This depicts the inventory workflow [I have skipped some steps to keep the example simple here]. The entire workflow is designed using the out of the box activity types provided by the .Net framework. Here are some key items:

Code: This activity type empowers the developer to write custom code that is executed when the workflow reaches this point. In the example I have implemented ReceiveOrder, BlockInventory and ShipInstruction using Code activity types.

IfElse: This activity type executes the activities defined in two or more possible paths based on whether a condition is met. The inventory check is performed using this type of activity and then the control either shifts to VendorPO or BlockInventory depending on the result of the check. The condition can be defined using custom code.

CallExternalMethod: This type of activity is used to call methods in an external component. This is useful when the workflow spans across multiple applications. In the example the VendorPO is implemented using an CallExternalMethod activity. InvokeWebService is another activity type that can be used in a similar situation to call a web service.

HandleExternalEvent: This is a very useful type to handle asynchronous events. In this example, once we place a VendorPO, we do not know when we will receive the inventory. We have already discussed that conventional programming practice cannot be used to effectively implement this type of business process. This is where the HandleExternalEvent type comes into picture. This type can be used to define an external event that will resume the workflow from this point onwards.

State Machine Workflow:

Unlike the sequential workflow, the state machine workflow is event based. This is useful when we are dealing with processes that depend on real life events. Think of a sales process. In simplest of terms, a sales process involves identifying contacts and working with the contacts to close a sale. These are processes where you cannot predict the sequence of events or the duration.

This is where State Machine workflow comes into consideration. The workflow type is built around a set of statuses or checkpoints in the overall process. Consider the diagram below. It is possible for us to identify the different states of the sales process i.e. NewContact, ContactVerified, ContactClosed and ContactLost. Then we need to design the events that move the status of the workflow from one state to the other state.

Here is a summary of the commonly used framework activities used in a state machine workflow.

State: Represents a “Checkpoint” in the business process.

EventDriven: This consists of a set of activities that get executed when an event is received while the workflow is in a specific state.

StateInitialization: Defines a set of activities that get executed when a state is reached in the workflow.

StateFinalization: Defines a set of activities that get executed when a state is exited in the workflow.

SetState: Changes the current state of the workflow.

Summary

In this article I presented a very high level overview of WF. It takes a while to learn the intricate details of this new framework, but once you understand the capabilities, you can design and develop powerful workflow applications with least amount of effort.