从0到1构建工作流引擎(二)

5 评论 6015 浏览 45 收藏 25 分钟

在构建完整的工作流引擎时,应当遵循哪些功能逻辑和业务逻辑呢?这篇文章里,作者就结合实际工作案例,对功能与逻辑进行了详细拆解,一起来看,或许会对你有所帮助。

最近我做了工作流引擎系统,借鉴了市面上的一些成熟工作流引擎,将其做了一些简化以更适用于实际情况,同时在复盘的时候发现当初踩了一些坑。所以希望以文章的形式写出来构建一个完整的工作流引擎应该有哪些功能模块,哪些功能逻辑,可以抽象哪些业务逻辑,有哪些思考的点。希望对需要的同学有所帮助,也和大家一起讨论改进。

文章分为两篇,由4个板块组成:

  1. 工作流引擎简介;
  2. 从案例出发推演功能;
  3. 功能模块概览;
  4. 功能与逻辑详解。

本文是第二篇,本文包括第四个板块。前三个板块请看《从0到1构建工作流引擎(一)

四、功能与逻辑详解

由上一篇文章中我们知道了一个工作流引擎应该有图中这些功能,本篇文章主要对每个功能进行详解,包括其背后的逻辑、分支情况和思考点。

其中,业务系统管理毕竟维护的频率太低,主要维护哪些字段也需要和开发沟通,组织架构管理也无非是部门信息和人员信息,所以这两块功能就直接跳过。

1. 角色矩阵管理

角色矩阵管理功能主要分为两类,矩阵人员和固定人员,具体解释如下:

  • 矩阵人员:组织架构下会多个部门都会存在的角色,如部门负责人;所以该角色会由多人担任,且对应其所在部门;
  • 固定人员:组织架构下只会固定存在一个的角色,如财务总监,总经理等角色;所以该角色只会由一人担任。

1)矩阵人员操作页面

上图为矩阵人员的列表配置页。通过图中可以看到,左侧功能为矩阵角色的添加维护板块,右侧是角色对应的人员的添加维护板块。

操作逻辑为:

  1. 先添加矩阵人员角色;
  2. 再为角色选择角色变量(数据来源于条件变量管理);
  3. 再选中该角色为其添加人员(人员的数据来源于组织架构管理);
  4. 最后再为人员配置变量值(数据来源于条件变量管理中该条件变量的值)。

这样矩阵人员的数据就配置好了,具体怎么用看后文流程模型管理中描述。但是这里有2个问题:

a. 为什么条件变量是跟着角色走,也就是一个角色一个条件变量,而不是一个人员一个条件变量?

条件变量跟着人员走也可以,但是角色只会存在于一个操作节点中,操作节点的主要目的是对一个变量进行处理,如果有2个及以上变量,为什么不再多设几个操作节点呢。所以这样会增加配置和理解的难度,还不如单纯一点。

还有就是为了防止用户操作过程中选错选漏条件变量等风险,导致流程没有找到对应的审批人。

b. 为什么要有一条默认数据?

比如区域负责人这个角色负责的区域该有东南西北,如果我只配了东南西的3个人员,区域为北的项目走流程时就会因为找不到处理人员而报错。

又比如只有东是一个负责人,南西北是一个负责人,我只需要配东就行了,南西北就直接由默认包含了,因为工作流引擎会优先找非默认的数据,发现找不到就直接找默认那条数据。

所以在变量值很多的情况下,有一条默认数据可以达到2个目的,1是防止漏配,2是简便配置过程和数据。

2)固定人员操作界面

上图是固定人员的列表配置页。通过图中可以看到,左侧功能为固定角色的添加维护板块,右侧同样是角色对应的人员的添加维护板块。

操作逻辑为:

  1. 先添加固定人员角色;
  2. 再选中该角色为其添加人员(人员的数据来源于组织架构管理)就行了,相较于用户矩阵的配置更为简单。

与用户矩阵不同的是,固定人员配置的都是由一个人担任的角色,比如总经理,财务总监此类,不需要由条件变量去判断该由谁去审批。所以一个角色虽然可以为其添加多个人员,但是只能有1个人员的状态开启。

这里有3个思考点:

a. 如果允许多个人员开启会怎么样?

如果直接在固定人员里开启2个及以上人员,流程这个操作节点时,这2个人是会签还是或签呢。

这个思考点可以结合下文流程模型中来看,流程模型中的操作节点是可以添加多个处理人的,所以这是能达到并审目的的。甚至可以用并行网关也是可以达到并审目的。

b. 如果没有矩阵人员这个功能,全靠固定人员来配置需要怎么配?

A部门的部门负责人(张三),B部门的部门负责人(李四),C部门的部门负责人(王五)……也就是有多少个人会参与到审批,就需要配多少个固定角色,并且流程中也需要配多少个操作节点。

c. 例如总经理这类角色是否可以用矩阵人员来配置?

也是可以的,但是在配置条件变量、变量值的时候,还有在流程的后端逻辑处理就需要改变一些规则了,变得更复杂了,同时在操作人员的认知上和配置上来说会比较麻烦。

2. 条件变量管理

条件变量的数据来源于业务系统,如erp、oa等,它的目的是为了将业务系统中的字段与工作流引擎建立映射对应关系;如项目分一级项目和二级项目,一级由XX审批,二级由XXX审批,所以业务系统在发起流程时会记录该项目是一级还是二级,工作流引擎以此来判断该走哪个审批。

而条件变量从用法上可以分两类:

  1. 用于流程模型配置中不同的顺序流;
  2. 用于矩阵人员配置中人员与变量建立关系。

(但是在系统中并没有强制规定某个条件变量是否只能用于顺序流或者矩阵人员,所以这一点是很灵活的)

注意,具体条件变量需要配置哪些字段需要和开发同学沟通,有没有必要单独做一个前端页面需要看实际情况而定,毕竟开发同学可以直接在数据库维护,因为增减字段可能是一个低频次操作。不过做出来有一个好处就是方便查看有哪些变量和变量值,也可以手动维护。

从图中可以看到条件变量包括编码和数据类型,这个编码是在业务系统的数据库中存储的编码,在工作流引擎的数据库中配置是为建立映射对应关系。数据类型包括字符型、布尔型等。

3. 流程模型管理

前面将配置流程所需要用到的元素和数据都已配置好了,接下来就是最重要的流程模型管理了,也就是怎样配置一个完整的流程了。

1)流程模型配置–流转线配置界面

上图是流程模型–流转线的配置页面,流转线也就是图中互斥网关(菱形带×)后的两条线。整个页面主要由三部分组成:

  1. 最上面一排左边是对流程的增删改按钮;右边是对模型或页面的操作按钮;
  2. 中间是可视化编辑器,可对模块进行拖拽添加或修改;
  3. 下面是对操作节点和流转线的配置板块。

基于上图中的这个操作界面,我们要添加一个完整的流程应该怎么做?

  • 第一步:先将流程所需的元素添加完整,如操作节点、网关、流转线、结束节点等;
  • 第二步:再将流转线上的流转条件配置完整(如果没有用到互斥网关可以忽略这一步);
  • 第三步:再将操作节点内各维度的属性配置完整,如处理人、抄送人、操作按钮等;
  • 第四步:保存流程,这时候会进行一系列的判断以确保流程无误。

接下来结合图中的操作界面,我来讲一下这4个步骤每一步的详细操作和判断逻辑。而第一步添加/删除操作节点、网关、流转线的交互逻辑这里就没必要展开说了,我们的主要目的是说说功能逻辑和判断逻辑,所以直接从第二步讲起。

通过上图中下方的弹窗,我们可以看到一个流转线的流转条件是由多个条件共同组成规则,并且每个条件由4个元素组成:

  • a. 逻辑符号:包括并且和或者两个选项,并且代表交集,或者代表合集;
  • b. 条件变量:在条件变量管理中配置的数据;
  • c. 比较符:有包含、不包含、等于、不等于、大于、大于等于、小于、小于等于。比较符的使用需要和开发同学沟通;
  • d. 变量值:在条件变量管理中配置的数据。

然后我们根据几个例子来看一下,具体应该怎么配置:

例1:当项目是海外项目时由分管领导审批,非海外项目由部门负责人审批。

由于只有2个审批人参与,所以我们需要配置2条流转线和其流转条件。

在第一个流转线的流转条件中先选择“是否海外项目”这个条件变量,再选择“包含”这个比较符,最后的变量值选择“是”;在第二个流转线的流转条件中选择“否”就行了。如下图:

例2:当项目是海外项目且是一级项目时由分管领导审批,当项目是海外项目且是二级项目时部门负责人审批,当项目非海外项目时由总经理审批。

可以看出这时是由3个审批人参与了,所以需要配置3条流转线和其流转条件。和例1不同,这时有2个条件变量来参与流程的走向了。所以我们需要配如下3个条件

但问题来了,有2个条件变量,各有2个条件值,实际项目会根据排列组合可以得出4种情况:

  1. 是海外项目,且一级项目
  2. 是海外项目,且二级项目
  3. 非海外项目,且一级项目
  4. 非海外项目,且二级项目

我们只配了3种情况,如果出现第4种情况时或者我配漏了,流程由于找不到满足的流转条件,就会直接挂起。

为了不让流程挂起,我们就需要引入默认流转这个功能(在操作页面的流转条件旁边),我们可以将其中一个流转条件设置为默认流转,这样第4种情况找不到满足的条件时,就会默认走入这一条流转条件。

同时默认除了可以实现逻辑更严密的目的,还有一个好处就是让配置过程更简便,我只需要配前两条流转条件就行,第3条直接设置为默认流转,就不用再配什么流转条件了,在条件变量很多的情况下就显得非常好用了。

例3:前面我们看的都是条件之间是并且的关系,接下来我们看一下或者的关系。

当项目是海外项目或者是一级项目时由分管领导审批,非海外项目或者是二级项目时由部门负责人审批。

这个例子很简单,只需要这样配就行了:

同例1一样,同样有2个条件变量,各有2个条件值,实际项目也会根据排列组合可以得出4种情况:

  1. 是海外项目,且一级项目
  2. 是海外项目,且二级项目
  3. 非海外项目,且一级项目
  4. 非海外项目,且二级项目

情况1、2、3的项目会走流转线1,情况4的项目会走流转线2。

但仔细想一想,情况2的项目也满足流转线2的条件二,那为什么不走流转线2呢?这里面还有一个隐藏逻辑,当逻辑比较符是或者时,出现两个流转线的流转条件有交集时,系统需要从上往下判断,也就是先判断流转线1内的条件一是否满足,再判断条件二是否满足,然后再判断流转线2的条件一和条件二是否满足。

所以当情况2的项目走到流转线1的条件一时就发现满足了,也就不需要再往下找流转线2的条件二了。

例4:我们来看一个复杂的配置情况,只有2个审批人,但是有3个条件变量,每个条件变量各有2个条件值,但混合并且和或者的情况:

由于有3个条件变量和各有2个条件值,实际项目可得出8种项目:

  1. 是海外项目,且一级项目,且工期大于15天
  2. 是海外项目,且一级项目,且工期小于等于15天
  3. 是海外项目,且二级项目,且工期大于15天
  4. 是海外项目,且二级项目,且工期小于等于15天
  5. 非海外项目,且一级项目,且工期大于15天
  6. 非海外项目,且一级项目,且工期小于等于15天
  7. 非海外项目,且二级项目,且工期大于15天
  8. 非海外项目,且二级项目,且工期小于等于15天

以上各类情况流转至流转线如下:

2)流程模型配置–操作节点配置界面

操作节点也就是图中“部门负责人审批”、“分管领导审批”等。与上面流转线配置页面大部分相同,不同的地方是最下面排节点属性配置的字段有些差别。

当流程走向正确的流转线之后,就会来到操作节点,所以我们需要为其配置处理人、操作等,才能让流程走向下一个节点。

我们先看处理人配置弹窗。如图所示,我们可以配置多条处理人数据,每条处理人需要先选择角色类型(矩阵人员或者固定人员),再选择对应的角色,下方就会带出可能参与审批的人员。

矩阵人员前面的案例已经讲过,会由条件变量去判断具体的审批人,这里就不多说了;固定人员就是固定的一个人去审批,没有条件变量参与判断。

需要注意的是审批模式的或签和会签。当处理人配置了多个时,如图中,可能参与审批的人有张三、李四、赵六,如果是或签则需要他们3人其中一人审批通过即可,因为流程会同时流转到他们3人处,;如果是会签,则需要他们3人都通过后,流程才会流转到下一节点。

然后自动完成条件可多选也可不选,当前处理人可能在前面的操作节点中已经存在了并且已经通过了,这里可以不用再次审批;如果处理人是发起人时也可自动通过。设置这个条件的目的是为了加快流程的审批,减少一些不必要的操作。

最后是操作设置,在工作流引擎中勾选了当前审批人可以进行哪些操作后,该功能将在业务系统中展示并使用,这一点需要与开发同学沟通清楚。具体操作按钮的逻辑如下:

  • 提交:该按钮在提交节点中默认选中;提交后则开始审批流,并流转到下一个节点
  • 通过:点击后当前节点通过,并流转到下一个节点
  • 驳回:当前节点不通过,点击后流转到提交人处,需重新提交流程
  • 退回:当前节点不通过,但不是流转到提交人处,而是退回到上一个节点
  • 如果上一个节点是并审,则需要所有人再次通过;如果该节点是并审,退回后再次流转则不需要其他人通过
  • 撤回:如果当前节点通过,流转到下一节点且未通过时,可撤回后重新处理
  • 转办:将流程转给指定人选来处理(前提是该指定人有功能权限)
  • 终止:可直接将当前流程终止,如需操作则要再次提交

说完了操作节点属性配置有哪些功能后,我们再来看几个逻辑问题:

1.如果处理人配置的是矩阵人员,而其角色对应条件变量中在实际发生的流程里没有时怎么办?

比如我先设置了一个角色叫项目经理,条件变量选的是项目等级,张三负责一级项目,李四负责二级项目;然后有个操作节点叫项目经理审批,选择了项目经理这个角色,。但是实际提交的立项流程的表单中没有项目等级这个字段,那实际流程都跑到这个节点了但是又找不到条件变量来判断该由谁去处理该怎么办。

这时有2种处理方式,1是直接将流程挂起,2是默认由角色中配置的第一个人员审批,两种处理各有利弊。

2.同一个条件变量,如果在流转条件中设置了,又在矩阵人员中设置并配到了操作节点会怎样?

这种配法倒不会让流程挂起,也没有逻辑性的问题,但是会让流转条件没有存在的意义了,为了更简化直接配一个操作节点就行了。

4. 流程版本管理

配置完一个完整的流程模型后,我们需要部署。但是一个模型可能前后会进行多次修改,每次修改就需要部署一次,所以一个模型会有多个版本,我们也就需要一个列表来对这些版本进行查看和管理。

更为重要的问题是,一个流程实例(实际发生的流程)可能会经历较长的时间才能审核完,有多个流程实例都在运行中时,所有完成的时间你没法预估,可能这个流程实例走完了下一个又发生了。但这时你又有修改流程的需求,总不可能把流程暂停了不让大家发起吧。

所以就引入了流程版本的概念,可能多个版本共存。比如现在是版本1有10个流程实例在运行中,你在0点改了流程模型并且部署了版本2,那从0点以后发生的流程都是走的版本2,但不会影响之前运行中的10个流程,那10个流程还是走的版本1。

如果这时你又说那10个流程实例走的是错误的版本,需要走流程2,可以将这10个流程实例直接终止,让他们重新发起流程就行了。

所以我们可以看到每个流程版本都有运行中、挂起中、已完成的数据统计(挂起中的数据怎么处理在后文中讲解)

5. 流程监控管理

该列表是所有发生过的和正在发生的流程实例的集合展示,点击列表我们可以进入下一页查看其执行详情:

流程执行详情页主要目的是为查看某一条流程的详细情况,并对其进行相关处理;如因为条件变量、处理人配置等原因未找到正确的处理人,流程将会挂起,此处可选择正确的处理人,以将流程正常运行完结。

本文由 @橘钻 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Pixabay,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 写的超级好!!!

    来自上海 回复
  2. 文章写的很用心,不过针对角色的处理有点复杂。角色管理应该纳入到组织管理里,和流程引擎完全解耦,对角色的设置不用考虑流程引擎的因素。流程引擎里节点处理人的设置应该分为组织架构节点、角色、制定人员即可,另外节点审批需要考虑百分比会签的情况。

    来自上海 回复
    1. 放到组织管理里的也有一个角色,但是和流程引擎里用到的那个角色是两个独立的角色,你可以看一下我的第一篇文章中的场景一和场景二写了这两个角色的区别用途;
      百分比这个功能做细了确实可以有,比如SaaS一类的,不过我们公司当时还没有业务需求。

      来自重庆 回复
    2. 我看了,我的意思是标准BPM的做法要保留,依然要去关联组织/角色/人员(会有按照角色去审批的场景),如果有其他需求在现有标准NPM的基础上拓展就行。
      你这个角色相当于是为了维护提交人所属部门的所属区域/事业部总监、分管VP,同时也维护了每个部门的负责人。但是你这种设计无疑就造成了数据冗余和极高的数据维护成本。首页部门负责人直接获取组织架构的就可以,不需要额外维护一个表。针对分管VP,是需要维护一个表,不过VP一般都是条线分管,在vp分管的顶级部门节点维护就行,查询部门所属分管VP时支持向上查询就可以满足需求,区域/事业部总监同理。

      来自上海 回复
  3. 很专业了

    来自中国 回复