Shulou(Shulou.com)06/03 Report--

This article introduces the knowledge of "how to develop a simple workflow engine". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Level 1

One day, my boss came to me and said he wanted to make a simple workflow engine.

I checked what a workflow is all day, and then made the following version:

Add any approver in order to form a linked list, and finally add an end node

Record the current approver. When the approval is finished, the approver moves back one.

When the approver corresponds to the end node, the process ends

Boss: it's a little humble.

Level 2

Here comes the boss again: support countersigned nodes.

I checked what the signing node is all day, and found that the countersigned node is a large node, in which there are many approvers. Only after everyone in this big node has been approved can we enter the next node.

I thought about it for a week and overturned the original linked list design:

Structurally, I have made the following adjustments:

Nodes are divided into two categories: simple nodes (rectangle in the image above) and complex nodes (circle in the image above).

A tree is used to represent the whole process, in which the leaf nodes are all simple nodes and the simple nodes are all leaf nodes.

There is one and only one approver in each simple node.

A complex node contains several child nodes.

Join the countersigned node: after the countersigned node is activated, all the child nodes can be approved, and when all the child nodes are approved, the countersigned node is completed.

Join a serial node: the child node can only be approved from left to right. When the approval of the last child node is completed, the serial node is completed.

The outermost layer of all workflows is a serial node, which represents the completion of the entire workflow.

In order to control the approval process, I designed some node states:

Ready: the simple node that can perform approval operations is the Ready status.

Complete: the status of the node that has been approved.

Future: the node state that has not been reached yet.

Waiting: only complex nodes have this status, indicating that they are waiting for approval from child nodes.

With the help of the above rules, a workflow approval process with a signature node is as follows: boss: it's interesting.

Level 3

Here comes the boss: support parallel nodes.

I checked what a parallel node is all afternoon and found that a parallel node is a large node with a lot of approvers. If anyone in this large node is approved, the node will be completed.

And then quickly added parallel nodes:

The parallel node is a complex node, when the node is activated, any child node can be approved, and when any child node is in the completion state, the node is completed.

Add the new status Skip:

When the child node state of a parallel node is not (Ready, Waiting), the state of other sibling nodes and their child nodes is set to Skip.

Boss: it's convenient to add new nodes in this design.

Level 4

Here comes the boss again: nodes should support nesting, such as a parallel node in a countersigned node and a complex node in a parallel node that can nest any layer.

Me: actually, I have already supported it.

The tree structure that can expand infinitely can support any complex process.

Boss: the young man has something!

Level 5

Here comes the boss again: support the condition node.

The workflow comes with a form that determines which branch to enter next based on the contents of the form.

After a few days of meditation, I added the condition node:

Conditional nodes are similar to parallel nodes, except that only child nodes that meet the criteria can enter the next approval. Boss: I have read it.

Level 6

Here comes the boss again: there are two more types of approvers, for example, you can select the next approver from the form, and choose different approvers according to the initiator.

After some consideration, I divided simple nodes into three categories:

The first kind: the approver is written dead.

The second: the approver reads from the form.

The third kind: calculate the approver according to the initiator and a mapping function. For example, the supervisor of get_ ("Qian") gets Li, the supervisor of Qian. Boss: mm-hmm.

Level 7

Here comes the boss again: the node can be approved from behind, can it be rejected from back to front?

Me:.

First of all, it realizes the function of rejecting to the initiator, which is equivalent to starting from scratch:

Only the node in Ready status has the right to reject it. (just as only nodes in Ready status have the right to approve) Boss: you are lazy.

Level 8

Here comes the boss again: first realize the rejection to the last approver.

Rejecting to the last approver is actually a very complex logic, because the nodes in the workflow can be infinitely nested, so it is not easy to determine which approvers are in the previous state.

At the expense of some hair, I finally achieved the function of rejecting a higher level: boss: read.

Level 9

Here comes the boss again: implement a function that rejects to any node.

I find this requirement not difficult to achieve:

Keep rejecting the next level until the node in the Ready state contains the node to which you want to reject.

Boss: mm-hmm.

Level 10

Here comes the boss again: add a time limit to the ordinary node, and if it is not finished within the specified time, it will show that it has timed out.

Me: is there still such a need?

But it came true. At this point, I learned that demand is negatively related to hair. The more demand, the less hair.

Level 11

The boss came again: add an agency function, such as something for you to approve, but you are not sure, then transfer it to someone who is sure for approval.

Immediately I found that this requirement was essentially different from the past. The node relationship of the previous workflow was fixed at the beginning, that is, it was determined before the process was initiated.

But now you have to change it during the approval process.

Nothing more than some overtime, lost some hair, and finally designed the following plan:

The essence of agent operation is to create a new parallel node as the parent node of the node, and then create a new sibling node to release the agent, so that both the agent and the agent can be approved.

Agent operations can be infinitely nested, that is, agents can also find agents. Level 12

Here comes the boss again: can you add another function to cancel the agent?

. . . I am already humiliated and humiliated. I will add as much as possible:

Canceling the agent is the reverse operation of the agent.

If the agent has passed the examination and approval, then the 13th hurdle of the agent cannot be cancelled.

The boss came again: add a pre-and post-condition to each node, meet the pre-condition to enter the node, meet the post-condition before the node can be approved and completed.

My heart: goodbye, boss, goodbye, boss!

My mouth: okay boss, copy that.

Later: later, I really added pre-and post-conditions to each node, and at the same time, the code related to the approval logic doubled.

Level 14

Here comes the boss again: some workflows are already very complex, and approval takes a long time. Can you calculate an indicator for each ongoing workflow: intuitively display the current percentage of approval.

Me: copy that.

In fact, compared with the previous requirements, this is not complex, because it does not involve changes to the core logic, the essence is to enter a tree structure and then output an integer according to the state of different nodes.

After testing and thinking, the final plan is as follows:

The percentage of workflow completed refers to the distance from the rightmost node in the tree in the Ready state to the leftmost node / the rightmost node in the tree.

Level 15

Here comes the boss again: can you hang two executable scripts for each node and execute them after the approval of the node and the completion of the approval?

Me: take.. To.

Later, of course, I realized this function, and at the same time, I also found that I was bald in my prime.

This is the end of "how to develop a simple workflow engine". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.