Official account: Java Xiaokaxiu, website: Javaxks.com

Author: MCTW, link: cnblogs.com/duck-and-du…

One day, my boss came to me with a simple workflow engine. I spent the day looking up what workflow was, and made the following version: add any approvers in order to form a linked list, add an end node to record the current approver, and when the approver is finished, move the approver one step back

1 shut

One day, my boss came to me with a simple workflow engine.

I looked up what workflow was all day and made the following version:

  • Add any approver in order to form a linked list, and add an end node at the end
  • 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 rough.

2 close

Here comes the boss again: support countersigned nodes.

I checked what the countersignature node was for another day, and found that the countersignature node was just a big node with a lot of examiners in it. After all the examiners in this big node had passed the examination and approval, the next node could be entered.

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

I made the following structural adjustments:

  • Nodes are divided into two main categories: simple nodes (rectangles in the figure above) and complex nodes (circles in the figure above).
  • The entire process is represented by a tree, where 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.
  • Add countersigned nodes: After the countersigned node is activated, all child nodes can be approved. After all child nodes are approved, the countersigned node is complete.
  • Adding serial nodes: Child nodes 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 workflow is a serial node, which represents the completion of the entire workflow.

To control the approval process, I designed some node states:

  • Ready: A simple node that can be approved is Ready.
  • Complete: Indicates the approved node status.
  • Future: Node state that has not yet been reached.
  • Waiting: Only the complex node has this state, indicating that the child node is Waiting for approval.

With the help of the above rules, a workflow approval process with countersigned nodes is as follows:

Boss: That’s interesting.

3 shut

Here comes the boss: support parallel nodes.

I looked up what is parallel node all afternoon and found that parallel node is a big node with many approvers. If any one of the approvers in this big node passes the approval, the node is completed.

Parallel nodes are soon added:

  • A 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 completed state, the node is completed.

Add new state Skip:

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

For example 🌰 :

Boss: This design is quite convenient to add new nodes.

4 close

Nodes should support nesting, such as a parallel node in a countercheck node, and a complex node in a parallel node, which can nest any layer.

Me: Actually already support ~

  • An infinitely scalable tree structure can support arbitrarily complex processes.

Boss: Young man has something!

5 off

The boss is at it again: conditional nodes to support.

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

After a few days of thinking, I added the conditional node:

  • Conditional nodes are similar to parallel nodes, except that only child nodes that meet the conditions can enter the subsequent approval.

Boss: Yes.

6 close

Here comes the boss again: there are two more types of approvers, such as the option to select the next approver from a list, and different approvers depending on the sponsor.

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

  • The first: the examiners are written dead.
  • Second: the approver reads from the form.
  • Third: according to the initiator and a mapping function, calculate the approver. For example, get_ supervisor (” Qian “) gets Qian’s supervisor li.

Boss: HMM.

7 off

The boss came again: node can examine and approve in the past, that can reject from after forward?

I:…

First implemented to reject to the sponsor function, equivalent to everything from scratch:

  • Only nodes in the Ready state have the right to reject. (Just as only nodes in the Ready state have the right to approve)

Boss: You’re lazy.

8 close

The boss came again: the first implementation of the rejection to the last approver it.

The logic of rejecting to the last approver is complicated because nodes in the workflow can be nested indefinitely, so it is not easy to determine which approvers are in the last state.

With some hair sacrifice, I finally managed to override the previous level:

Boss: Yes.

9 off

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

I found this requirement easy to implement:

  • Keep rejecting the previous level until the Ready node contains the node to be rejected.

Boss: HMM.

Add a time limit to the normal node, if the achievement is not completed within the specified time, it will be displayed as timeout.

Me: And this need?

But it did happen.

At this point I understand that needs and hair are negatively correlated, the more needs, the less hair.

11 pass

Here comes the boss again: add an agent function, for example, if there is something for you to approve, but you are not sure, it will be transferred to the right person for approval.

Immediately, I found that this requirement was fundamentally different from the past. In the past, the node relationship of workflow was fixed at the beginning, which was determined before the process was initiated.

But now it has to be changed during the approval process.

It just took a few extra shifts, lost some hair, and came up with the following solution:

  • The essence of the agent operation is to create a parallel node as the parent node of this node, and then create a sibling node to put the agent, so that both the agent and itself can approve.
  • Proxy operations can be nested indefinitely, that is, agents can also have proxies.

12 close

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

. I have accepted the insult and added:

  • Canceling the agent is the inverse of the agent
  • If the agent has approved it, the agent cannot be cancelled

13 clearance

The boss comes again: add a condition before and after each node, meet the pre-condition to enter the node, meet the post-condition to complete the approval of the node.

My heart: boss, goodbye, goodbye goodbye goodbye boss!

My mouth: ok boss, Roger, Roger.

Later: I did add a pre – and post-condition to each node and doubled the code for the approval logic at the same time.

14 closing

Here comes the boss again: some workflows are already very complicated and take a long time to approve. Can we calculate an indicator for each workflow in progress: intuitively show the percentage of approvals that have been made so far?

Me: Got it.

In fact, compared to the previous requirements, this is not complicated, because there is no change in the core logic, essentially just input a tree structure and output an integer according to the state of the different nodes.

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

  • The percentage of workflow completed refers to the distance from the right-most Ready node in the tree to the left-most node/the distance from the right-most node.

15 off

Here comes the boss again: can we attach two executable scripts to each node, one after the node is approved and the other after the node is approved?

I: closed.. To the.

I did, of course, and found myself bald in the prime of my life.

Afterword.

The boss is tsinghua graduates of the high talent, otherwise probably can not think of so many wonderful work demand, later the boss sold this workflow system to the company such as the broad * securities, I also go to other companies each rush the future, of course, at that time I think I still have the future.

I had just graduated from college when I started working on this workflow, and by the time I left the company, I was looking in the mirror like an old man. This was three years ago. I still feel frightened when I recall the days when I worked overtime and changed the work flow.

Finally, I wish the world’s peers have no bugs, physical and mental health, enough money saved in first-tier cities to buy two suites, in a few years can be disease-free on the pension of leisure retirement life.