How to select a workflow type in Windows Workflow Foundation (WF)

How to select a workflow type in Windows Workflow Foundation (WF)

Windows Workflow Foundation supports three basic workflow modes: sequential workflow and state machine workflow.
Machine and data-driven. Many people ask me how to choose them, so I am willing to share my views on this. Let's start with a simple question. I asked Fred (fled) to check a document,
Let Joe review and finally send it to my customers.

This is an obvious sequential workflow. To achieve our problem, I created an ordered workflow project, added Fred check and Joni review, and finally sent it to the user to complete the sequential activities of the workflow (sequence
Activity ). A sequential workflow is characterized by the fact that "a workflow is always under control. When Fred, Jonny and I were told to do things we had previously defined, we started to do it. We do what we should do. When we have finished, we will notify the workflow, and then the workflow will decide what will happen next.
Of course, a sequential workflow does not mean that all things only occur in a straight line as we described above. We can also have conditional branches, loops, and so on. In other words

A sequential workflow is characterized by the fact that "a workflow is always under control. When Fred, Jonny and I were told to do things we had previously defined, we started to do it. We do what we should do. When we have finished, we will notify the workflow, and then the workflow will decide what will happen next.

Of course, a sequential workflow does not mean that all things only occur in a straight line as we described above. We can also have conditional branches, loops, and so on. In other wordsWorkflow controls "order".
As a classical workflow model, ordered workflow has been supported and based on many workflow products for many years.
In my opinion, a bad name for a workflow also requires considerable attention. I don't mean to tell people what to do with any mistakes (sometimes I also act with my own habits), sometimes it's really impossible to work.
.
Let's look at another example. For example, I am testing a product in the development stage. When I find a problem, I create a new bug, assign it to the corresponding developer, and then
"At ease" waits for programmers to fix it. I will write a workflow to manage this process. Now, everything sounds normal. The procedure should be: the tester creates a bug and the developer fixes it.
The tester closes the bug. This is like the example of the document we just mentioned.
However, this solution is unreliable. What happened in the test example? A tester creates a bug and assigns it to Bill ). But Bill says this is not my problem.
It should be the problem of Clive and re-assigned to him; or Bill said it was not a bug (or similar statement) and marked it as not to be handled; or he asks the tester to give
Even more, he is in a good mood. He fixed the bug and gave it back to the tester. Or the first tester was absent, but only other testers; or the tester revokes this error.
Bug (unsafe ). Each participant can make a set of different choices at a given position.
What will happen if I write this example in sequential workflow mode? It may be like this (if you can forgive me for this pseudocode ):
. As a classical workflow model, ordered workflow has been supported and based on many workflow products for many years.

In my opinion, a bad name for a workflow also requires considerable attention. I don't mean to tell people what to do with any mistakes (sometimes I also act with my own habits), and sometimes it is really impossible to work.

Let's look at another example. For example, I am testing a product in the development stage. When I find a problem, I create a new bug, assign it to the corresponding developer, and then
"At ease" waits for programmers to fix it. I will write a workflow to manage this process. Now, everything sounds normal. The procedure should be: the tester creates a bug and the developer fixes it.
The tester closes the bug. This is like the example of the document we just mentioned.

But this solution is not reliable. What exactly happened? A tester creates a bug and assigns it to Bill ). But Bill says this is not my problem. It should be that it is
(Clive) problem, and re-assigned to him; or Bill said this is not a bug (or similar statement), mark it as not to be handled; or he asks the tester to give a more detailed email.
Even worse, he is in a good mood. He fixed the bug and gave it back to the tester. Or the first tester was absent, but only other testers; or the tester revokes the bug (uneasiness
All ). Each participant can make a set of different choices at a given position.

What will happen if I write this example in sequential workflow mode? It may be like this (if you can forgive me for this pseudocode ):

         Tester T creates instance of bug workflow
T adds bug details
T assigns to developer D
LabelA: Switch
D assigns to developer E
Goto LabelA
D rejects bug to T:
Switch
T accepts rejection:
T updates bug and assigns to developer F:
Goto LabelA
End Switch
D requests info from T:
T submits info
Goto LabelA
D submits solution to T:
T withdraws bug:
End Switch

You have also learned that the cycle and selection within the selection are causing structural problems. (Here I use Goto With my own nose, to maintain the ing between the Code and the settings.
System .) We can make this example more realistic. When many bugs emerge, team leaders will assign tasks to people in the team (or adopt the developer preemption mode ), and added a ticket
Process snapshot and set the bug priority, and so on, things will get worse and worse.

The problem caused by this example is a better way to use the state machine mode. The above pseudo code becomes like this:

State: Initial
Action: T adds bug details
Action: T assigns to developer D; new state = Fixing

State: Fixing
Action: D assigns to developer E
Action: D rejects bug to T; new state = Rejected
Action: D requests info;  new state = Pending Info
Action: D submits solution; new state = Pending Approval
Action: T withdraws bug; new state = Closed

State: Rejected
Action: T accepts rejection; new state = Closed
Action: T updates bug and assigns to developer F; new state = Fixing

State: Pending Info
Action: T submits info; new state = Fixing

State:  Pending Approval
Action: T rejects solution; new state = Fixing
Action: T accepts solution; new state = Closed

State: Closed

This is clearer and easier to understand, and adding more features will not complicate the entire structure-simply adding more state machines and actions.

Implementing this state machine mode is very simple in Windows Workflow Foundation: you only need to create a State Machine workflow project and then define the state machine and the required actions.

What are the criteria for using the state machine model? In short:Is it important to make a choice outside the workflow? (Are the important choices being made outside the workflow ?) Are users under control? (Is the user in control? )If the above answer is "yes", using the idea of sequential workflow mode will put the task into trouble at the beginning. On the other hand, those that are selected outside the workflow are suitable for the state machine workflow mode.

If you do not need to make any choice for a workflow, which mode is more suitable? Well, a state machine workflow controls a set of options. It makes no sense for a tester to receive the solution after the problem is submitted. This becomes effective only when the bug workflow reaches the appropriate state machine activity-by a large number of possible branches.

This is the last point to prove why the state machine workflow is more suitable for this bug. A sequential workflow is born to write all possible sequential behaviors into its internal structure. But here we don't care.
It. We only need to know the current status, and what can be done next is enough, so we spend time modeling the line in the process, even though we don't actually care about them, and those lines are not
There are often as many bugs as in this bug program, so the benefits of sequential workflow mode are inevitably minimal.

In particular, the article is translated into http://blogs.msdn.com/davegreen/
Copyright is owned by the original author. The original Article's description of the data-driven type workflow has been deleted.