Feb 12

WF4 – Pretty Flowcharts and Visualizing Business Process

When to Flow

During the elaboration phase of a recent project I could feel a disconnect between what the developers where saying and project management wanted. Developers were able to describe a set of high level processes to each other and project management struggled to understand how the system all fit together. In a high level sense the project is an order fulfillment system with a small application used for configuration (not that important in the grand scheme of things). The system will have a series of triggers that aggregate data from various sources to determine if an order can be placed. During these elaboration meetings I kept thinking about how this system fit well into a State Machine, but I didn’t want to go the route of a coded State Machine. I had heard very little about WF4 (Windows Workflow Foundations 4), but it did have the appeal that it could present a visual representation of the main process for order fulfillment. Immediately I began thinking about how easy it would be to convey to new developers here is the process for our system and also how this visual display could be also double up and help project management understand what exactly we are thinking of as developers. I’ll admit a fancy series of Activity diagrams or flowcharts might do the same, but I like the idea that this diagram really represents what the underlying code is intending to execute. Much less smoke and mirrors…

Workflow Overview

To better understand the usefulness of WF4 it is best to get a grounding in what a Workflow is and the related technologies. A workflow is a series of interrelated steps that defines a process that can be thought of as the work of a single entity or a group. In this sense a workflow can be the representation of work (real or abstract) that is achieved by its execution. Businesses have used workflow process modeling to understand system usage of resources including how those resources transition in and out of system. In these transition locations there will always be potential for inefficiencies and evaluation of the system in this manner can provide talking points on where and how to implement improvements.

Simple Order Process
Consider the Simple Order Process workflow shown to the right. It has a discrete amount of steps: Receive Order, Process Order, Charge Customer, and Ship Order. Each time this workflow is run it will flow through these steps and that should cause a few questions to come up. Is it really necessary to execute these steps? What happens if the received order is empty? Should the order ship if charging the customer fails? Is there any feedback that should be transmitted to a customer when an order is shipped or throughout this workflow process? While the previous questions are all fairly simple it does bring to light possible issues in the system by being able to visualize it and understand the logical series of steps.


Workflow Engine and Workflow Patterns

WF4 is Workflow Engine that employs Workflow Patterns. A Workflow Engine is a piece of software that manages and executes modeled processes or Workflows. A Workflow Engine reacts to events in the system, such as receiving an order in the example above, and processes related information, the received order (hidden under the covers of course), producing a result that can be used in subsequent steps if system constraints have been met. Workflow Patterns help define the Workflow into recognizable actions such as do..while, foreach, parallel action, sequences (in the case of the Simple Order Process), flowcharts, and state machines to name just a few. The Simple Order Process example is just a sequence containing 4 activities and it lacks a great deal of functionality because it is setup to follow that flow each and every time. This can be addressed in a number of ways, but I’m most interested in WF4′s State Machine.

Enter the State Machine

State Machines provide the possibility of branching logic for a workflow and help address the previous concerns about the robustness of the Simple Order Process. By translating the previous activities in the previous sequence into states and creating triggers or constraints it will be possible to create the State Machine incarnation of the Simple Order Process. But what exactly is a State Machine in WF4?

Simple Order Process State Machine
Shown above is a simple rendition of what the previous Simple Order Process might look like as a State Machine. From a quick glance it is possible to see the intended progression of states in the system. There is still much that is hidden at this level, but it gives talking points to the business side such as when the system is in the “Charge Customer” state that there will be one of two transitions to either “Shipping the Order” or “Canceling the Order”. It is possible to drive down into individual states to view what exactly is going on, but from a high level view that could be argued away that states would be named in such a way that any user could immediately guess.

State Machine Basics in WF4

State Machines existed in WF3 (previous version), but when WF4 emerged State Machines did not exist “officially” until .NET Platform Update 1. For more details on the progression of WF’s State Machine take a look at The Activity Designer Blog on MSDN. To think in terms of State Machines it is best to understand it as a collection of States that have Transitions between states and there is always a Initial State and Final State. The simple difference between general States and the Initial/Final States are that can be transitioned To and From where as Initial/Final support only To and From respectively. Transitions describe how the system moves between states. It is easy to relate them to events that occur and the system reacts to them triggering a state change.

In WF4 each State is made up of Activities, any class that implements System.Activities.Activity, that control what occurs in the state upon entry and prior to exit. In the Change Customers state above it is possible to see that upon entry into this state a ChargeCustomer activity will be executed and upon exit a sequence of activities will be executed (SendEmail => UpdateCustomer). This is a typical view of a state from the designer and it should be noted that any control flow activities can be embedded into the entry and exit portions of a state. One other piece to notice is that exit state will list what state transitions are available and the triggers that cause the transition.

Transitions between states are the results of Trigger Activities and come in a few flavors: null, shared, and everything else. Trigger activities execute and the result is typically evaluated to determine the next logical state. In the case of the Simple Order Process after Charge Customer there might be an Order Prep finished event that causes a trigger to evaluate and either transition to Order Ship or Cancel Order state.

But that is just a small piece of Workflow as it is neglecting more complex transitions/triggers, Tracking Participants, how to save/resume workflows, hosting a workflow in a WCF service, and many other features.

Where’s the Beef (Code)?

The idea of using WF4 to model the system design and move forward with it would have been too costly for the team to take on for a number of reasons:

  • Nobody at the time was an expert on WF4 or any previous incarnation
  • Shorter time frame did not leave much room to dream big in the design department
  • WF4/StateMachine may not have been the ideal choice
  • The business group may still have been confused after seeing the process visually

Given the time I would have spent a few days mocking up the Order Process that the system was intending to use and provide it as a proof of concept to the group. I think once the design could transition past the state modeling stage breaking up the code into the functional units of state work and transitions would have been fairly straightforward. I do plan on writing up a Simple Order Processor as a post-project proof of concept mostly to satiate that original desire to create a State Machine to handle order processing and better understand how WF4 might fit into my consulting bag of tricks.

Further Reading

29 comments , permalink