老板要我开发一个简单的工作流引擎-读后感与补充
概述
最近读了一篇《老板要我开发一个简单的工作流引擎》 幽默风趣，干货较多，作为流程引擎的设计者、开发者、探索者，写的很好，合计自己的理解，对每个功能补充说明，对于流程引擎的应用场景，做出更好的理解与实践。
第1关 -线性流程
一天，老板找到我，说要做个简单的工作流引擎。
我查了一天啥是工作流，然后做出了如下版本：
- 按顺序添加任意个审批人组成一个链表，最后加一个结束节点
- 记录当前审批人，当审批完后，审批人向后移动一位
- 当审批人对应结束节点时，流程结束
老板：简陋了点。
RE： 这个概念称为线性流程，具体如下。
- 每个节点都是按照顺序执行，只有一个节点是活跃的。
- 走到最后一个节点，流程自动结束。
- 也可以在中间节点满足一定的条件结束。
- 线性流程是ccflow流程引擎的概念，可以参考。
第2关 -会签
老板又来了：要支持会签节点。
我又查了一天啥是会签节点，发现会签节点就是一个大节点，里面有很多审批人，当这个大节点里的所有人都审批通过后，才能进入下一个节点。
我想了一个星期，推翻了原来的链表式设计：
结构上我做了如下调整:
- 把节点分为两大类：简单节点(上图中长方形)和复杂节点(上图中圆形)。
- 用一棵树表示整个流程，其中叶子节点都是简单节点，简单节点都是叶子节点。
- 每个简单节点里都有且仅有有一个审批人。
- 复杂节点包含若干个子节点。
- 加入会签节点: 会签节点激活后，所有的子节点都可以审批，当所有的子节点都审批完毕后，会签节点完成。
- 加入串行节点：子节点只能从左到右依次进行审批，当最后一个子节点审批完成后，串行节点完成。
- 所有的工作流最外层都是一个串行节点，该节点完成后代表整个工作流完成。
为了控制审批流程，我设计了一些节点状态:
- Ready: 可以进行审批操作的简单节点是Ready状态。
- Complete: 已经审批完成的节点状态。
- Future: 现在还没有走到的节点状态。
- Waiting: 只有复杂节点有该状态，表示在等待子节点审批。
借助上述规则，一次带会签节点的工作流审批过程如下：
老板：有点意思。
RE: 会签节点上，就是一个节点上多人处理，ccflow的概念是多人处理规则，若一个节点上有1个以上的人员处理，就需要考虑着多个人处理的模式。
-
- 强办模式。
- 协作模式
- 队列模式
- 共享任务模式。
协作模式下，就是会签的场景。
会签
A节点发到B节点，B节点上有3个副局长需要签字，由最后一个人发送到下一个环节上去， 我们把这样的模式称为多人会签.
设置方式：1. 节点属性=》基本设置=》多人处理规则=》设置协作模式. 2. 节点属性=》表单设置=》审核组件=》启用.
加签 - 协作模式
A节点发到B节点，B节点上有n个人需要处理，其中一个人需要参考别人的意见，要把其他人邀请进来进行处理工作，邀请之后他的工作就处理完毕了, 整体工作由最后一个人发送到下一个环节, 我们把这中模式称为协作模式的加签.
设置方式：请参考下一个章节.
加签 - 组长模式
A节点发到B节点，B节点上有n个人需要处理(一般只有1个人)，他要把其他人邀请进来进行协同处理工作，被邀请人处理完毕后， 整体工作由他发送到下一个环节, 我们把这中模式称为组长模式的加签.
设置方式：请参考下一个章节.
主持人
在加签-组长模式，模式下. 能够邀请其他人处理工作的人员我们称为主持人(组长).
A发到B，B节点的接收人都是主持人(组长，一般情况下只有1个人), 主持人可以邀请其他人处理工作, 被邀请的人称为组员， 组员是不能在邀请其他组员的.
一个注册人(组长)邀请的组员，只能被这个主持人(组长)所管理，比如移除、增加操作。
增加主持人
在一些场景下, 一个主持人可以邀请其他人作为组长，我们把这个模式，称为增加主持人.
比如：一个工作组的组长，可以邀请另外一个工作组的组长进行工作。
多组长处理规则
接上个场景，多组长处理规则, 如何标识当前节点工作已经完成? 这需要设置多组长模式。
任意组长：只要一个组长说完成了，这件工作就发送到下一个环节，对于组员没有完成的自动删除。
所有组长：所有的组长说完成了，该工作就完成了，对于组员没有完成的自动删除。
第3关 – 抢办模式
老板来了：要支持并行节点。
我查了一下午啥是并行节点，发现并行节点是一个包含很多审批人的大节点，这个大节点里任何一个人审批通过，则该节点就完成。
然后很快就加入了并行节点：
- 并行节点是一个复杂节点，该节点激活时，任何一个子节点都可以进行审批，且任何一个子节点是完成状态时，该节点完成。
加入新状态 Skip:
- 当一个并行节点的子节点状态为非(Ready, Waiting)时，其它兄弟节点及其子节点的状态被置为Skip。
举个栗子：
老板：这个设计添加新节点还挺方便的。
Re: 该模式下，类似于ccflow抢办模式。
A发送到B ，B节点上有n个人可以处理。这n个人都可以看到待办，当其中一个人处理后，其他人的待办就消失了。
这样的工作模式属于抢办，这n个人可以同时打开，当一个人发送后，其他人都不能在发送了。
通俗的说，也就是谁抢到了这件工作，就是谁处理的。
抢办模式是一个默认的处理模式。
第4关 -异表单分合流
老板又来了：节点要支持嵌套，比如会签节点里有个并行节点，并行节点里又有个复杂节点，要可以嵌套任意层的那种。
我：其实已经支持了~
- 能无限扩展的树形结构可以支持任意复杂流程。
老板：小伙子有点东西！
RE: 参考ccflow的异表单分合流。
如下图1
第5关 – 方向条件
老板又来了：要支持条件节点。
工作流附带一个表单，要根据表单的内容确定下一步进入哪个分支。
经过几天的冥思苦想，我加入了条件节点：
- 条件节点类似并行节点，只不过只有满足条件的子节点才能进入接下来的审批。
老板：已阅。
RE： 流程节点在转向的时候有多个节点，有两种模式。
- 自动计算，就是按照条件进行转向，这里的条件，有流程参数、表单数据、身份等。
- 主管选择：在发送的时候，选择到达的方向。
丰富的条件表达式，能让减少开发。
条件表达式
第6关 – 接受人规则
老板又来了：审批人多加两种类型，比如可以从表单中选择下一个审批人，还有根据发起人不同选择不同的审批人。
经过一番考虑，我把简单节点分成了3类：
- 第一种：审批人是写死的。
- 第二种：审批人从表单中读取。
- 第三种：根据发起人和一个映射函数，算出审批人。比如 get_主管("钱某") 得到钱某的主管 李某。
老板：嗯。
RE： 在流程引擎里，这属于接受人规则的范畴。A节点运动到目标节点，目标节点必须有人处理工作，我们把这个工作，那些人可以处理工作有一个规则，这个规则大致分为两大类。
-
-
- 自动计算： 按照表单、组织结构、环境变量自动计算接收人。
- 主管选择： 发送给谁，由发送人选择的，类似于发送邮件。
-
参考ccflow的接收人规则、
图1：
图2：
第7关 – 退回.
老板又来了：节点可以从前往后审批，那能不能从后往前驳回？
我: ......
首先实现了驳回到发起人的功能，相当于一切从头开始：
- 只有Ready状态的节点有权利驳回。（就像只有Ready状态的节点有权利审批一样）
老板：你小子偷懒。
RE: 驳回也好，退回也罢，就是当前节点的待办移动到以前的处理人节点上，在ccflow里面称为退回规则。
如下图：
流程的前进与后退，是流程引擎两大基本动作。
第8关 – 退回上一个节点.
老板又来了：先实现驳回到上一个审批人吧。
驳回到上一个审批人其实是个很复杂的逻辑，因为工作流中的节点可以无限嵌套，所以如何确定上一个状态有哪些审批人并不简单。
牺牲了一些头发，我终于实现了驳回上一级的功能：
老板：阅。
RE: 在退回规则里，设置仅退回上一个即可。
第9关 – 退回任意节点
老板又来了：实现一个驳回到任意节点的功能。
我发现这个需求并不难实现：
- 不断的驳回上一级，直到Ready状态的节点包含要驳回到的节点为止。
老板：嗯。
RE: 在ccflow设置可以退回任意节点，这些节点不是模板的节点，而流程实例经过的节点，按照时间的顺序排列起来。
Ccflow的退回节点
第10关 – 时限规则
老板又来了：在普通节点加一个时间限制，要是在规定时间内没完成就显示已超时。
我：还有这种需求?
不过还是实现了。
此时我明白了需求和头发呈负相关，需求越多，头发越少。
RE: 在ccflow里是一个时限规则，包括节点实现，与流程时限。
- 节点时限,用于控制节点的时间长短,在节点属性里设置。
- 流程时限，用于控制整体流程的时间，在流程属性里设置。
图：流程属性控制整体流程时限规则。
第11关 – 加签
老板又来了：加一个代理功能，比如有件事让你审批，但是你拿不准，那就转给拿得准的人审批。
马上我发现这个需求跟以往有本质的不同，以往的工作流的节点关系一开始就是固定的，就是在发起流程之前确定的，
但是现在要在审批过程中更改。
无非是加了一些班，掉了一些头发，最终设计了如下方案：
- 代理操作的本质是，新建一个并行节点作为本节点的父节点，再新建一个兄弟节点放代理人，这样自己和代理人都能审批通过。
- 代理操作可以无限嵌套，即代理人也可以找人代理。
RE: 该场景属于多人处理规则的加签，在ccflow里面有两个场景模式，
文档预览 - Gitee.com
加签 - 协作模式
A节点发到B节点，B节点上有n个人需要处理，其中一个人需要参考别人的意见，要把其他人邀请进来进行处理工作，邀请之后他的工作就处理完毕了, 整体工作由最后一个人发送到下一个环节, 我们把这中模式称为协作模式的加签.
加签 - 组长模式
A节点发到B节点，B节点上有n个人需要处理(一般只有1个人)，他要把其他人邀请进来进行协同处理工作，被邀请人处理完毕后， 整体工作由他发送到下一个环节, 我们把这中模式称为组长模式的加签.
第12关 – 移除加签人
老板又来了：能不能再加一个取消代理的功能？
。。。我已经宠辱不惊了，加就加：
- 取消代理是代理的逆操作
- 如果代理人审批过了那就不能取消代理
RE: 增加了这个处理人，也可以移除这个处理人，参考ccflow的界面。
-
第13关 – 阻塞规则
老板又来了：给每个节点加个前后置条件吧，满足前置条件才能进入该节点，满足后置条件该节点才能审批完成。
我的内心：啊老板再见，啊老板再见吧再见吧再见吧！
我的嘴：好的老板，收到收到。
后来：后来我真的给每个节点加了前后置条件，与此同时审批逻辑的相关代码增加了一倍。
RE： 增加后置条件，这个概念不敢沟通，前置条件，在ccflow里我们称为阻塞规则。
第14关 – 进度图
老板又来了：现在有的工作流已经非常复杂了，审批起来耗时较长，能不能对每个进行中的工作流计算一个指标：直观的显示目前审批进行的百分比。
我：收到。
其实跟之前的需求比起来这个并不复杂，因为不涉及核心逻辑的改动，本质只是输入一棵树形结构然后根据不同节点的状态输出一个整数。
经过测试思考，最终敲定的方案如下：
- 工作流完成的百分比指的是树中最右侧Ready状态的节点到最左侧节点的距离 / 最右侧节点的距离。
RE: 这个概念提的不错，据我们的经验，还没有客户提出这样的要求，暂时贴一个进度图看看吧。
第15关 – 节点事件，流程事件
老板又来了：能不能给每个节点挂两个可以执行的脚本，分别在开始审批该节点和审批完成该节点后执行？
我：收..到。
后来我当然实现了这个功能，同时也发现正值壮年的我已经秃了。
RE: 流程运动过程中，对流程的操作，我们称为事件，发送前、发送后，删除前、删除后，结束前，结束后等等。
在这些事件中，需要与其他系统交互，应该提供多种方式，比如：允许写代码、写js,,写sql，调用api等等。
后记
老板是清华毕业的高才生，不然大概想不出这么多巧夺天工的需求，后来老板把这一套工作流系统卖给了广*证券等公司，我也去别的公司各奔前程，当然那个时候我以为我还有前程。
开始做这个工作流的时候我刚刚本科毕业，后来从这家公司公司离职的时候看镜子已经垂垂老矣。这已经是3年前的事情了，现在回想起那些加班改工作流的日子，仍然心惊。
最后愿天下的同行们都没有bug，身心健康，攒的钱够在一线城市买两套房，在若干年后能无病无灾的过上领养老金的休闲退休生活。
RE:
作者幽默风趣、老板从实际应用提出需求，能够开发出来一款流程引擎实属不易，如果早知道，就用ccflow, 驰骋BPM是开源免费的，免去您开发之辛苦，头发也不会掉了：），感谢作者分享，有空来济南与我们聊聊。
- 致敬作者。