Sequential versus State workflows

Windows Workflow Foundation offers two basic types for workflow, the sequential workflow and the state workflow. So when you start building a new workflow which is right one for you? Well it depends! You knew I was going to say that didn’t you?

 

The State Workflow is the more fluid of the two. Basically the workflow is in a given state and waiting for events to move it into another state. This new target state can be every other state in the workflow. Normally this happens because an event is raised and the current state, or one of its parents knows how to handle the event and does so to trigger a state change. The workflow itself actually has another way, the SetStateQueue queue with a SetStateEventArgs argument to indicate the target state, which can be used to activate any other state, even if there is no event that has the new state as target. This makes state workflows very much like real live. After all how often are we not faced with issues that are not supposed to happen in the normal flow of things?

 

The Sequential Workflow on the other hand is much more rigid. Sure it can contain loops and branches with conditions but basically the path through the workflow is deterministic. So this is much more in line with automated processes or very rigid protocols that need to be applied. This doesn’t mean that things cannot go wrong or if that happens we cannot cater for it but there is a clear distinction between the normal execution path and any exceptional deviations.

 

So what to choose?
Well the above basically gave it away already. If you have a rigid protocol, say for example you submit an expense report, you manager has to approve it, then if the amount is larger that a certain predetermined amount a senior manager has to approve it too and finally ou get the result (and with any luck some money) you are probably best of with a sequential workflow.

 

If on the other hand the same process is modeled more in terms of you submit it, your manager reviews it and might ask for clarification on some items. When done it goes to his supervisor, who in turn can send it back to you for more clarifications etc. In a case like this a state workflow seems more appropriate as the state of the expense report moves all over the place from submitted, to waiting for approval to waiting for clarification and back to waiting for approval.

 

Enjoy!
 

Maurice de Beijer
 

2 thoughts on “Sequential versus State workflows

  1. Your two examples could be equivalent. In the first, the manager makes a decision, and could reject the expense report, which could land it back on your desk. This is exactly the same as the second one’s clarification step, where it comes back for clarification.

    So the way I read it, the above article doesn’t say ‘use sequential here and state-based here’, but ‘either will do’. If you’ve got other arguments as to why one should be used in preference to the other I’d like to hear them…

  2. Hi Ian,

    It isn’t so much a case of you needing to use one or the other type. Lots of problems can be solved with both types of workflow.

    For example. In a recent project I created a workflow with two points the work needed to be checked and if the check failed part of the work needed to be redone. Because the whole process was very rigid and government regulated, my first choice was a sequential workflow. But because the two check, where the checked check failing would end up just before the first check, required a number of extra loops the workflow became hard to create but easy to visualize. When I redid it as a state workflow it was much easier to implement because there was no need for a looping construct. But then the drawback was that is was harder to see what was going on in the workflow itself

    Hope this helps.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>