Moss multi-level approval workflow [statemachine] V1.1

Last year, I published a moss multi-level approval workflow, which was developed in a sequential workflow mode. Later, I made some improvements. conditionedactivitygroupactivity replaces the complex nested whileactivity + ifelseactivity, but it is still a sequential workflow.

At the end of the second article, I wrote: "approval is not suitable for sequential workflows. It would be better to use another Workflow of WF-state machine workflow ", why?

We already know that the execution process of a sequential workflow is a continuous step, from the beginning to the end, although we can use the loop activity like while to make the workflow seem to have executed several steps back, however, the consequence is an obscure flowchart and complicated execution logic.

In the real world, workflows are flexible. They are often not a single line. They may include many of these decisions, and each decision can make the process move in another direction. Therefore, a workflow that includes human participation is actually a decision-driven process. abstracting it into a workflow becomes an "event-driven Workflow", that is, a state machine workflow (statemachine workflow ).

A state machine workflow consists of a series of States. Each State can contain a series of event handlers. The state machine workflow always stays in a State, waiting for the necessary events to be triggered, and then jump to the new State.

Now let's take a look at the original flowchart of this multi-level approval workflow:

 

The following is a flowchart after the state machine is implemented:

 

You will find that the flowchart of the state machine workflow is quite similar to our original flowchart, whether it is a process block or a line between them. If you compare it with the flow chart after implementing the sequence workflow, you will not consider implementing the sequence workflow in the future when you encounter a workflow involving humans.

The following briefly describes the key points of state machine workflow development:

1. How do I plan the status?

In the moss state machine workflow, we generally plan a state as follows:

Create a task (createtaskactivity) at the initial state (stateinitializationactivity) and delete the task (deletetaskactivity) at the end of the State (statefinalizationactivity ). In the process of initialization and termination, we can add multiple event drivers. eventdrivenactivity is used to receive and process events (such as the modified event of a task, ontaskchangedactivity ), then, you can jump to another State (setstateactivity) based on the event processing result. You can understand setstateactivity as a connection line between States.

2. How to Implement the concurrency of task3 and task4?

Note that in the initial flowchart, Task 3 and Task 4 are two parallel tasks. In the sequence implementation of this approval process, we certainly choose parallelactivity to implement concurrency, we can still do this in statemachine, but if we want to arrange Task 3 and Task 4 in two states, we have to add a setstateactivity in the two branches of parallelactivity and point it to the corresponding state.

However, you will be surprised to find that although each branch is executed, only setstateactivity In the last branch correctly performs the jump.

Because an eventdrivenactivity can only jump to one stateactivity, we need other methods to achieve the concurrency of task3 and task4.

My method is to integrate task3 and task4 into a state, first create two tasks at the initial state, and then add two eventdrivenactivities that are almost identical to each other to process the modified events of the two tasks, below is the composition of the eventdrivenactivity sub-activity:

After processing the task modified event, I will mark the task as "completed" and record its approval results. Then, ifelseactivity is used to determine whether both tasks are marked as "completed". If other tasks are not completed, no operation is performed. If both tasks are completed, then, based on their approval results, determine the status to jump.

3. Why should I add the activity of the deletion task to eventdrivenactivity instead of statefinalizationactivity?

This is because I want to delete a task immediately after it is processed, but stateactivity will always be executed to statefinalizationactivity only when setstateactivity is executed, in the preceding steps, the jump occurs only after both tasks are completed. Therefore, if deletetaskactivity is added to statefinalizationactivity, the task cannot be deleted in real time.

4. Why should I add ifelseactivity in eventdrivenactivity?

The answer is to achieve the jump only after both tasks are completed.

However, the consequence of this operation is that I have to add this ifelseactivity after each task is processed. Fortunately, our process has only two concurrent tasks, what if there are three, five, or more? This judgment method is very troublesome and will make the process structure bloated. Isn't there a better way? I hope to discuss this issue with you. In the next article, I will introduce a method to replace this frequent use of ifelseactivity for judgment.

OK. The above are the implementation points of this multi-level approval workflow (statemachine version). You are welcome to discuss it together.

Download source code: Click to download (Visual Studio 2008)

 

Source: http://coding.windstyle.cn/2008/07/15/moss-multi-level-approval-workflow-statemachine-edition/