老板要我开发一个简单的工作流引擎-读后感与补充

概述

最近读了一篇《老板要我开发一个简单的工作流引擎》 幽默风趣,干货较多,作为流程引擎的设计者、开发者、探索者,写的很好,合计自己的理解,对每个功能补充说明,对于流程引擎的应用场景,做出更好的理解与实践。

1 -线性流程

一天,老板找到我,说要做个简单的工作流引擎。

我查了一天啥是工作流,然后做出了如下版本:

老板要我开发一个简单的工作流引擎-读后感与补充_第1张图片

  • 按顺序添加任意个审批人组成一个链表,最后加一个结束节点
  • 记录当前审批人,当审批完后,审批人向后移动一位
  • 当审批人对应结束节点时,流程结束

老板:简陋了点。

RE 这个概念称为线性流程,具体如下。

  1. 每个节点都是按照顺序执行,只有一个节点是活跃的。
  2. 走到最后一个节点,流程自动结束。
  3. 也可以在中间节点满足一定的条件结束。
  4. 线性流程是ccflow流程引擎的概念,可以参考。

2 -会签

老板又来了:要支持会签节点。

我又查了一天啥是会签节点,发现会签节点就是一个大节点,里面有很多审批人,当这个大节点里的所有人都审批通过后,才能进入下一个节点。

我想了一个星期,推翻了原来的链表式设计:

老板要我开发一个简单的工作流引擎-读后感与补充_第2张图片 

结构上我做了如下调整:

  • 把节点分为两大类:简单节点(上图中长方形)和复杂节点(上图中圆形)
  • 用一棵树表示整个流程,其中叶子节点都是简单节点,简单节点都是叶子节点。
  • 每个简单节点里都有且仅有有一个审批人。
  • 复杂节点包含若干个子节点。
  • 加入会签节点: 会签节点激活后,所有的子节点都可以审批,当所有的子节点都审批完毕后,会签节点完成。
  • 加入串行节点:子节点只能从左到右依次进行审批,当最后一个子节点审批完成后,串行节点完成。
  • 所有的工作流最外层都是一个串行节点,该节点完成后代表整个工作流完成。

为了控制审批流程,我设计了一些节点状态:

  • Ready: 可以进行审批操作的简单节点是Ready状态。
  • Complete: 已经审批完成的节点状态。 
  • Future: 现在还没有走到的节点状态。
  • Waiting: 只有复杂节点有该状态,表示在等待子节点审批。

借助上述规则,一次带会签节点的工作流审批过程如下:

老板要我开发一个简单的工作流引擎-读后感与补充_第3张图片老板要我开发一个简单的工作流引擎-读后感与补充_第4张图片

老板:有点意思。

RE: 会签节点上,就是一个节点上多人处理,ccflow的概念是多人处理规则,若一个节点上有1个以上的人员处理,就需要考虑着多个人处理的模式。

    1. 强办模式。
    2. 协作模式
    3. 队列模式
    4. 共享任务模式。

协作模式下,就是会签的场景。

会签

A节点发到B节点,B节点上有3个副局长需要签字,由最后一个人发送到下一个环节上去, 我们把这样的模式称为多人会签.

设置方式:1. 节点属性=》基本设置=》多人处理规则=》设置协作模式. 2. 节点属性=》表单设置=》审核组件=》启用.

加签 - 协作模式

A节点发到B节点,B节点上有n个人需要处理,其中一个人需要参考别人的意见,要把其他人邀请进来进行处理工作,邀请之后他的工作就处理完毕了, 整体工作由最后一个人发送到下一个环节, 我们把这中模式称为协作模式的加签.

设置方式:请参考下一个章节.

加签 - 组长模式

A节点发到B节点,B节点上有n个人需要处理(一般只有1个人),他要把其他人邀请进来进行协同处理工作,被邀请人处理完毕后, 整体工作由他发送到下一个环节, 我们把这中模式称为组长模式的加签.

设置方式:请参考下一个章节.

主持人

在加签-组长模式,模式下. 能够邀请其他人处理工作的人员我们称为主持人(组长).

A发到BB节点的接收人都是主持人(组长,一般情况下只有1个人), 主持人可以邀请其他人处理工作, 被邀请的人称为组员, 组员是不能在邀请其他组员的.

一个注册人(组长)邀请的组员,只能被这个主持人(组长)所管理,比如移除、增加操作。

增加主持人

在一些场景下, 一个主持人可以邀请其他人作为组长,我们把这个模式,称为增加主持人.

比如:一个工作组的组长,可以邀请另外一个工作组的组长进行工作。

多组长处理规则

接上个场景,多组长处理规则, 如何标识当前节点工作已经完成? 这需要设置多组长模式。

任意组长:只要一个组长说完成了,这件工作就发送到下一个环节,对于组员没有完成的自动删除。

所有组长:所有的组长说完成了,该工作就完成了,对于组员没有完成的自动删除。

3抢办模式

老板来了:要支持并行节点。

我查了一下午啥是并行节点,发现并行节点是一个包含很多审批人的大节点,这个大节点里任何一个人审批通过,则该节点就完成。

然后很快就加入了并行节点:

  • 并行节点是一个复杂节点,该节点激活时,任何一个子节点都可以进行审批,且任何一个子节点是完成状态时,该节点完成。

加入新状态 Skip:

  • 当一个并行节点的子节点状态为非(ReadyWaiting)时,其它兄弟节点及其子节点的状态被置为Skip

举个栗子

老板要我开发一个简单的工作流引擎-读后感与补充_第5张图片 

 老板:这个设计添加新节点还挺方便的。

Re: 该模式下,类似于ccflow抢办模式。

    A发送到B B节点上有n个人可以处理。这n个人都可以看到待办,当其中一个人处理后,其他人的待办就消失了。

    这样的工作模式属于抢办,这n个人可以同时打开,当一个人发送后,其他人都不能在发送了。

    通俗的说,也就是谁抢到了这件工作,就是谁处理的。

    抢办模式是一个默认的处理模式。

4 -异表单分合流

老板又来了:节点要支持嵌套,比如会签节点里有个并行节点,并行节点里又有个复杂节点,要可以嵌套任意层的那种。

我:其实已经支持了~

老板要我开发一个简单的工作流引擎-读后感与补充_第6张图片

  •  能无限扩展的树形结构可以支持任意复杂流程。

老板:小伙子有点东西!

RE: 参考ccflow的异表单分合流。

如下图1

老板要我开发一个简单的工作流引擎-读后感与补充_第7张图片

5方向条件

老板又来了:要支持条件节点。

工作流附带一个表单,要根据表单的内容确定下一步进入哪个分支。

经过几天的冥思苦想,我加入了条件节点:

  • 条件节点类似并行节点,只不过只有满足条件的子节点才能进入接下来的审批。

老板要我开发一个简单的工作流引擎-读后感与补充_第8张图片

 老板:已阅。

RE 流程节点在转向的时候有多个节点,有两种模式。

  1. 自动计算,就是按照条件进行转向,这里的条件,有流程参数、表单数据、身份等。
  2. 主管选择:在发送的时候,选择到达的方向。

老板要我开发一个简单的工作流引擎-读后感与补充_第9张图片

 丰富的条件表达式,能让减少开发。

条件表达式老板要我开发一个简单的工作流引擎-读后感与补充_第10张图片

6接受人规则

老板又来了:审批人多加两种类型,比如可以从表单中选择下一个审批人,还有根据发起人不同选择不同的审批人。

经过一番考虑,我把简单节点分成了3类:

  • 第一种:审批人是写死的。
  • 第二种:审批人从表单中读取。
  • 第三种:根据发起人和一个映射函数,算出审批人。比如 get_主管("钱某") 得到钱某的主管 李某。

老板要我开发一个简单的工作流引擎-读后感与补充_第11张图片 

 老板:嗯。

RE 在流程引擎里,这属于接受人规则的范畴。A节点运动到目标节点,目标节点必须有人处理工作,我们把这个工作,那些人可以处理工作有一个规则,这个规则大致分为两大类。

      1. 自动计算: 按照表单、组织结构、环境变量自动计算接收人。
      2. 主管选择: 发送给谁,由发送人选择的,类似于发送邮件。

参考ccflow的接收人规则、

1

老板要我开发一个简单的工作流引擎-读后感与补充_第12张图片

2
老板要我开发一个简单的工作流引擎-读后感与补充_第13张图片

7退回.

老板又来了:节点可以从前往后审批,那能不能从后往前驳回?

: ......

首先实现了驳回到发起人的功能,相当于一切从头开始:

  • 只有Ready状态的节点有权利驳回。(就像只有Ready状态的节点有权利审批一样)

老板要我开发一个简单的工作流引擎-读后感与补充_第14张图片

 老板:你小子偷懒。

RE: 驳回也好,退回也罢,就是当前节点的待办移动到以前的处理人节点上,在ccflow里面称为退回规则。

如下图:

老板要我开发一个简单的工作流引擎-读后感与补充_第15张图片

流程的前进与后退,是流程引擎两大基本动作。

8退回上一个节点.

老板又来了:先实现驳回到上一个审批人吧。

驳回到上一个审批人其实是个很复杂的逻辑,因为工作流中的节点可以无限嵌套,所以如何确定上一个状态有哪些审批人并不简单。

牺牲了一些头发,我终于实现了驳回上一级的功能:

老板要我开发一个简单的工作流引擎-读后感与补充_第16张图片

 老板:阅。

RE: 在退回规则里,设置仅退回上一个即可。

老板要我开发一个简单的工作流引擎-读后感与补充_第17张图片

9退回任意节点

老板又来了:实现一个驳回到任意节点的功能。

我发现这个需求并不难实现:

  • 不断的驳回上一级,直到Ready状态的节点包含要驳回到的节点为止。

老板:嗯。

RE: ccflow设置可以退回任意节点,这些节点不是模板的节点,而流程实例经过的节点,按照时间的顺序排列起来。

老板要我开发一个简单的工作流引擎-读后感与补充_第18张图片

Ccflow的退回节点

10时限规则

老板又来了:在普通节点加一个时间限制,要是在规定时间内没完成就显示已超时。

我:还有这种需求?

不过还是实现了。

老板要我开发一个简单的工作流引擎-读后感与补充_第19张图片

此时我明白了需求和头发呈负相关,需求越多,头发越少。

RE: ccflow里是一个时限规则,包括节点实现,与流程时限。

  1. 节点时限,用于控制节点的时间长短,在节点属性里设置。
  2. 流程时限,用于控制整体流程的时间,在流程属性里设置。

老板要我开发一个简单的工作流引擎-读后感与补充_第20张图片

图:流程属性控制整体流程时限规则。

老板要我开发一个简单的工作流引擎-读后感与补充_第21张图片

11加签

老板又来了:加一个代理功能,比如有件事让你审批,但是你拿不准,那就转给拿得准的人审批。

马上我发现这个需求跟以往有本质的不同,以往的工作流的节点关系一开始就是固定的,就是在发起流程之前确定的,

但是现在要在审批过程中更改。

无非是加了一些班,掉了一些头发,最终设计了如下方案:

  • 代理操作的本质是,新建一个并行节点作为本节点的父节点,再新建一个兄弟节点放代理人,这样自己和代理人都能审批通过。
  • 代理操作可以无限嵌套,即代理人也可以找人代理。

老板要我开发一个简单的工作流引擎-读后感与补充_第22张图片

RE: 该场景属于多人处理规则的加签,在ccflow里面有两个场景模式,

文档预览 - Gitee.com

加签 - 协作模式

A节点发到B节点,B节点上有n个人需要处理,其中一个人需要参考别人的意见,要把其他人邀请进来进行处理工作,邀请之后他的工作就处理完毕了, 整体工作由最后一个人发送到下一个环节, 我们把这中模式称为协作模式的加签.

加签 - 组长模式

    A节点发到B节点,B节点上有n个人需要处理(一般只有1个人),他要把其他人邀请进来进行协同处理工作,被邀请人处理完毕后, 整体工作由他发送到下一个环节, 我们把这中模式称为组长模式的加签.

12移除加签人

老板又来了:能不能再加一个取消代理的功能?

。。。我已经宠辱不惊了,加就加:

  • 取消代理是代理的逆操作
  • 如果代理人审批过了那就不能取消代理

老板要我开发一个简单的工作流引擎-读后感与补充_第23张图片

RE: 增加了这个处理人,也可以移除这个处理人,参考ccflow的界面。

老板要我开发一个简单的工作流引擎-读后感与补充_第24张图片

-

 13 –  阻塞规则

老板又来了:给每个节点加个前后置条件吧,满足前置条件才能进入该节点,满足后置条件该节点才能审批完成。

我的内心:啊老板再见,啊老板再见吧再见吧再见吧!

我的嘴:好的老板,收到收到。

后来:后来我真的给每个节点加了前后置条件,与此同时审批逻辑的相关代码增加了一倍。

RE 增加后置条件,这个概念不敢沟通,前置条件,在ccflow里我们称为阻塞规则。

老板要我开发一个简单的工作流引擎-读后感与补充_第25张图片

14进度图

老板又来了:现在有的工作流已经非常复杂了,审批起来耗时较长,能不能对每个进行中的工作流计算一个指标:直观的显示目前审批进行的百分比。

我:收到。

其实跟之前的需求比起来这个并不复杂,因为不涉及核心逻辑的改动,本质只是输入一棵树形结构然后根据不同节点的状态输出一个整数。

经过测试思考,最终敲定的方案如下:

  • 工作流完成的百分比指的是树中最右侧Ready状态的节点到最左侧节点的距离 / 最右侧节点的距离。

RE: 这个概念提的不错,据我们的经验,还没有客户提出这样的要求,暂时贴一个进度图看看吧。

15节点事件,流程事件

老板又来了:能不能给每个节点挂两个可以执行的脚本,分别在开始审批该节点和审批完成该节点后执行?

我:收..到。

后来我当然实现了这个功能,同时也发现正值壮年的我已经秃了。

RE: 流程运动过程中,对流程的操作,我们称为事件,发送前、发送后,删除前、删除后,结束前,结束后等等。

在这些事件中,需要与其他系统交互,应该提供多种方式,比如:允许写代码、写js,,sql,调用api等等。

老板要我开发一个简单的工作流引擎-读后感与补充_第26张图片

后记

老板是清华毕业的高才生,不然大概想不出这么多巧夺天工的需求,后来老板把这一套工作流系统卖给了广*证券等公司,我也去别的公司各奔前程,当然那个时候我以为我还有前程。

开始做这个工作流的时候我刚刚本科毕业,后来从这家公司公司离职的时候看镜子已经垂垂老矣。这已经是3年前的事情了,现在回想起那些加班改工作流的日子,仍然心惊。

最后愿天下的同行们都没有bug,身心健康,攒的钱够在一线城市买两套房,在若干年后能无病无灾的过上领养老金的休闲退休生活。

RE:

作者幽默风趣、老板从实际应用提出需求,能够开发出来一款流程引擎实属不易,如果早知道,就用ccflow, 驰骋BPM是开源免费的,免去您开发之辛苦,头发也不会掉了:),感谢作者分享,有空来济南与我们聊聊。

  1. 致敬作者。

你可能感兴趣的:(算法,前端,javascript)