Control Flow Patterns in Workflows
There is a lot of potential in Workflow Foundation that is seldom uncovered. Due to the existence of different business processes for different industries, an architect who would prefer to model these processes using workflows will look for more useful control flow patterns (explicitly available or an opportunity to develop one) than the ones that are shipped out-of-box with WF i.e. the Sequential and State Machine Workflow Patterns.
It is very important to understand that WF is a part of the .NET Framework 3.0. It is a “Framework” and not a “Solution” in itself. The onus lies on the developers and designers to put this framework to best use and develop customized solutions according their business needs.
WF provides the flexibility to create customized control flow patterns. So what is a Control Flow Pattern? Let us briefly understand the existing out-of-box patterns:
Sequential Workflow – In this workflow pattern a set of activities are organized in a sequence from top to bottom. When the workflow is executed, the control flows from one activity to the next in sequence.
State Machine Workflow – In this workflow pattern an entity moves from one state to another. Each state is an Activity. The control flows based on the external stimulus received from the client and moves the entity to another state accordingly.
There can be business processes which may require different flow patterns. For example,
- An activity can execute only if a set of activities preceding it have executed successfully.
- The control should move from one activity to another based on the user input i.e. the user explicitly decides which activity to execute next.
- An activity may proceed to one of the next few activities possible based on the input it receives. A small difference from the above case will be that the user cannot explicitly mention the activity that will be executed next.
- If in a sequence, a set of activities may be re-executed before the workflow is completed. The number of activities that will be re-executed and the number of times such a thing should happen may be unknown.
Can we accomplish anything like the above??? Fortunately, the answer is YES! So what does it take to develop such customized control flow patterns?
The first concept to be painted on the wall: “Every Workflow is an Activity; a Composite Activity”. The next step to take will be to understand the root of the execution of activities in a workflow (and the workflow itself) which is the Activity Execution Context (AEC). AEC enables us to interact with the underlying scheduler component of the workflow i.e. it is an abstraction for the scheduler and the work queue components of the WF Runtime. This becomes the ground for developing customized control flow patterns, from the simplest to extremely exotic and complex ones.
A very good resource that WF developers/designers in this regard will be the book:
Essential Windows Workflow Foundation - Dharma Shukla, Bob Schmidt
The book provides an in-depth insight into the details of the AEC and the possible control flow patterns that one can develop. The programmers will have something to cheer about since these flow patterns are explained with code.
I should honestly admit that the effort required to develop such complex patterns will be a little more than usual. But, such an effort is justified if it can solve the most critical business problems. However, it is very important to pay due diligence before a decision is taken to develop such complex patterns right from scratch. If a pattern can be tailored out from the existing patterns (Sequential or State Machine), it will be a good idea to pursue the same.
