Designing a Multi‑Level Workflow Engine: From Simple Chains to Complex Conditional and Parallel Nodes

Level 1

The boss asks for a simple workflow engine. The author first implements a linear chain of approvers represented as a linked list ending with a termination node.

Add any number of approvers in order, forming a chain, with a final end node.

Track the current approver; after approval, move to the next approver.

When the current approver reaches the end node, the workflow finishes.

Boss: "Too simple."

Level 2

The boss now wants a countersign (joint approval) node. The author redesigns the engine using a tree structure.

Two node categories: simple nodes (rectangles) and complex nodes (circles).

The whole process is a tree; leaf nodes are simple nodes.

Each simple node contains exactly one approver.

Complex nodes contain multiple child nodes.

Countersign node activates all its children; the node completes when all children are approved.

Serial node forces children to be approved left‑to‑right; when the last child finishes, the serial node finishes.

The outermost node of any workflow is a serial node; its completion marks the whole workflow as finished.

Node States

Ready – a simple node that can be approved.

Complete – an already approved node.

Future – a node that has not been reached yet.

Waiting – a state only for complex nodes, indicating they are waiting for child approvals.

Example approval process with a countersign node is illustrated with images.

Level 3

The boss now wants parallel nodes where any child approval completes the node.

Parallel node is a complex node; when activated, any child can be approved, and the node finishes as soon as one child reaches the Complete state.

A new state Skip is added: when a parallel node’s child is in a non‑Ready/Waiting state, all its sibling nodes and their descendants are set to Skip.

Level 4

The boss asks for unlimited nesting (e.g., a countersign node containing a parallel node, which in turn contains a complex node). The tree‑based design already supports arbitrary depth.

An infinitely extensible tree can represent any complex process.

Level 5

The boss wants conditional nodes that decide the next branch based on form data.

A conditional node behaves like a parallel node but only children whose conditions evaluate to true become eligible for approval.

Level 6

Two new approver types are added: read from the form, or derived from the initiator via a mapping function (e.g., getSupervisor("Qian") → "Li").

Fixed approver (hard‑coded).

Approver read from the submitted form.

Approver calculated from the initiator using a custom function.

Level 7

The boss asks if a node can be rejected backwards. The author implements a rollback to the initiator, resetting the workflow to the beginning.

Only Ready nodes are allowed to reject, mirroring the approval permission.

Level 8

Rollback to the previous approver is added, which is complex because of unlimited nesting.

Level 9

Rollback to an arbitrary node is implemented by repeatedly rolling back one level until a Ready node that contains the target appears.

Level 10

A time‑limit feature is added: if a node is not completed within the configured period, it is marked as timed‑out.

Level 11

Delegation (proxy) is introduced. When an approver delegates, a new parallel node is created as the parent, and a sibling node holds the delegate, allowing both to approve.

Delegation can be nested indefinitely; a delegate can further delegate.

Level 12

Cancellation of delegation is added as the inverse operation; it is prohibited if the delegate has already approved.

Level 13

Pre‑ and post‑conditions are attached to each node: a node can only be entered when its pre‑condition is satisfied, and it can only be completed when its post‑condition holds.

Level 14

A progress metric is added to show the percentage of the workflow that has been completed. The percentage is calculated as the distance from the leftmost node to the rightmost Ready node divided by the total distance to the rightmost node.

Level 15

Two executable scripts can be attached to each node: one runs when the node starts approval, the other runs after the node is approved.

Postscript

The boss, a Tsinghua graduate, eventually sold the workflow system to several securities firms. The author moved on to other companies, reflecting on the many overtime nights and hair loss caused by endless feature requests.

Thank you for reading, hope it helped :) Source: cnblogs.com/duck-and-duck/p/14436373.html