在构建完整的工作流引擎时，应当遵循哪些功能逻辑和业务逻辑呢？这篇文章里，作者就结合实际工作案例，对功能与逻辑进行了详细拆解，一起来看，或许会对你有所帮助。
最近我做了工作流引擎系统，借鉴了市面上的一些成熟工作流引擎，将其做了一些简化以更适用于实际情况，同时在复盘的时候发现当初踩了一些坑。所以希望以文章的形式写出来构建一个完整的工作流引擎应该有哪些功能模块，哪些功能逻辑，可以抽象哪些业务逻辑，有哪些思考的点。希望对需要的同学有所帮助，也和大家一起讨论改进。
文章分为两篇，由4个板块组成：
本文是第二篇，本文包括第四个板块。前三个板块请看《从0到1构建工作流引擎（一）》
由上一篇文章中我们知道了一个工作流引擎应该有图中这些功能，本篇文章主要对每个功能进行详解，包括其背后的逻辑、分支情况和思考点。
其中，业务系统管理毕竟维护的频率太低，主要维护哪些字段也需要和开发沟通，组织架构管理也无非是部门信息和人员信息，所以这两块功能就直接跳过。
角色矩阵管理功能主要分为两类，矩阵人员和固定人员，具体解释如下：
1）矩阵人员操作页面
上图为矩阵人员的列表配置页。通过图中可以看到，左侧功能为矩阵角色的添加维护板块，右侧是角色对应的人员的添加维护板块。
操作逻辑为：
这样矩阵人员的数据就配置好了，具体怎么用看后文流程模型管理中描述。但是这里有2个问题：
a. 为什么条件变量是跟着角色走，也就是一个角色一个条件变量，而不是一个人员一个条件变量？
条件变量跟着人员走也可以，但是角色只会存在于一个操作节点中，操作节点的主要目的是对一个变量进行处理，如果有2个及以上变量，为什么不再多设几个操作节点呢。所以这样会增加配置和理解的难度，还不如单纯一点。
还有就是为了防止用户操作过程中选错选漏条件变量等风险，导致流程没有找到对应的审批人。
b. 为什么要有一条默认数据？
比如区域负责人这个角色负责的区域该有东南西北，如果我只配了东南西的3个人员，区域为北的项目走流程时就会因为找不到处理人员而报错。
又比如只有东是一个负责人，南西北是一个负责人，我只需要配东就行了，南西北就直接由默认包含了，因为工作流引擎会优先找非默认的数据，发现找不到就直接找默认那条数据。
所以在变量值很多的情况下，有一条默认数据可以达到2个目的，1是防止漏配，2是简便配置过程和数据。
2）固定人员操作界面
上图是固定人员的列表配置页。通过图中可以看到，左侧功能为固定角色的添加维护板块，右侧同样是角色对应的人员的添加维护板块。
操作逻辑为：
与用户矩阵不同的是，固定人员配置的都是由一个人担任的角色，比如总经理，财务总监此类，不需要由条件变量去判断该由谁去审批。所以一个角色虽然可以为其添加多个人员，但是只能有1个人员的状态开启。
这里有3个思考点：
a. 如果允许多个人员开启会怎么样？
如果直接在固定人员里开启2个及以上人员，流程这个操作节点时，这2个人是会签还是或签呢。
这个思考点可以结合下文流程模型中来看，流程模型中的操作节点是可以添加多个处理人的，所以这是能达到并审目的的。甚至可以用并行网关也是可以达到并审目的。
b. 如果没有矩阵人员这个功能，全靠固定人员来配置需要怎么配？
A部门的部门负责人（张三），B部门的部门负责人（李四），C部门的部门负责人（王五）……也就是有多少个人会参与到审批，就需要配多少个固定角色，并且流程中也需要配多少个操作节点。
c. 例如总经理这类角色是否可以用矩阵人员来配置？
也是可以的，但是在配置条件变量、变量值的时候，还有在流程的后端逻辑处理就需要改变一些规则了，变得更复杂了，同时在操作人员的认知上和配置上来说会比较麻烦。
条件变量的数据来源于业务系统，如erp、oa等，它的目的是为了将业务系统中的字段与工作流引擎建立映射对应关系；如项目分一级项目和二级项目，一级由XX审批，二级由XXX审批，所以业务系统在发起流程时会记录该项目是一级还是二级，工作流引擎以此来判断该走哪个审批。
而条件变量从用法上可以分两类：
（但是在系统中并没有强制规定某个条件变量是否只能用于顺序流或者矩阵人员，所以这一点是很灵活的）
注意，具体条件变量需要配置哪些字段需要和开发同学沟通，有没有必要单独做一个前端页面需要看实际情况而定，毕竟开发同学可以直接在数据库维护，因为增减字段可能是一个低频次操作。不过做出来有一个好处就是方便查看有哪些变量和变量值，也可以手动维护。
从图中可以看到条件变量包括编码和数据类型，这个编码是在业务系统的数据库中存储的编码，在工作流引擎的数据库中配置是为建立映射对应关系。数据类型包括字符型、布尔型等。
前面将配置流程所需要用到的元素和数据都已配置好了，接下来就是最重要的流程模型管理了，也就是怎样配置一个完整的流程了。
1）流程模型配置–流转线配置界面
上图是流程模型–流转线的配置页面，流转线也就是图中互斥网关（菱形带×）后的两条线。整个页面主要由三部分组成：
基于上图中的这个操作界面，我们要添加一个完整的流程应该怎么做？
接下来结合图中的操作界面，我来讲一下这4个步骤每一步的详细操作和判断逻辑。而第一步添加/删除操作节点、网关、流转线的交互逻辑这里就没必要展开说了，我们的主要目的是说说功能逻辑和判断逻辑，所以直接从第二步讲起。
通过上图中下方的弹窗，我们可以看到一个流转线的流转条件是由多个条件共同组成规则，并且每个条件由4个元素组成：
然后我们根据几个例子来看一下，具体应该怎么配置：
例1：当项目是海外项目时由分管领导审批，非海外项目由部门负责人审批。
由于只有2个审批人参与，所以我们需要配置2条流转线和其流转条件。
在第一个流转线的流转条件中先选择“是否海外项目”这个条件变量，再选择“包含”这个比较符，最后的变量值选择“是”；在第二个流转线的流转条件中选择“否”就行了。如下图：
例2：当项目是海外项目且是一级项目时由分管领导审批，当项目是海外项目且是二级项目时部门负责人审批，当项目非海外项目时由总经理审批。
可以看出这时是由3个审批人参与了，所以需要配置3条流转线和其流转条件。和例1不同，这时有2个条件变量来参与流程的走向了。所以我们需要配如下3个条件
但问题来了，有2个条件变量，各有2个条件值，实际项目会根据排列组合可以得出4种情况：
我们只配了3种情况，如果出现第4种情况时或者我配漏了，流程由于找不到满足的流转条件，就会直接挂起。
为了不让流程挂起，我们就需要引入默认流转这个功能（在操作页面的流转条件旁边），我们可以将其中一个流转条件设置为默认流转，这样第4种情况找不到满足的条件时，就会默认走入这一条流转条件。
同时默认除了可以实现逻辑更严密的目的，还有一个好处就是让配置过程更简便，我只需要配前两条流转条件就行，第3条直接设置为默认流转，就不用再配什么流转条件了，在条件变量很多的情况下就显得非常好用了。
例3：前面我们看的都是条件之间是并且的关系，接下来我们看一下或者的关系。
当项目是海外项目或者是一级项目时由分管领导审批，非海外项目或者是二级项目时由部门负责人审批。
这个例子很简单，只需要这样配就行了：
同例1一样，同样有2个条件变量，各有2个条件值，实际项目也会根据排列组合可以得出4种情况：
情况1、2、3的项目会走流转线1，情况4的项目会走流转线2。
但仔细想一想，情况2的项目也满足流转线2的条件二，那为什么不走流转线2呢？这里面还有一个隐藏逻辑，当逻辑比较符是或者时，出现两个流转线的流转条件有交集时，系统需要从上往下判断，也就是先判断流转线1内的条件一是否满足，再判断条件二是否满足，然后再判断流转线2的条件一和条件二是否满足。
所以当情况2的项目走到流转线1的条件一时就发现满足了，也就不需要再往下找流转线2的条件二了。
例4：我们来看一个复杂的配置情况，只有2个审批人，但是有3个条件变量，每个条件变量各有2个条件值，但混合并且和或者的情况：
由于有3个条件变量和各有2个条件值，实际项目可得出8种项目：
以上各类情况流转至流转线如下：
2）流程模型配置–操作节点配置界面
操作节点也就是图中“部门负责人审批”、“分管领导审批”等。与上面流转线配置页面大部分相同，不同的地方是最下面排节点属性配置的字段有些差别。
当流程走向正确的流转线之后，就会来到操作节点，所以我们需要为其配置处理人、操作等，才能让流程走向下一个节点。
我们先看处理人配置弹窗。如图所示，我们可以配置多条处理人数据，每条处理人需要先选择角色类型（矩阵人员或者固定人员），再选择对应的角色，下方就会带出可能参与审批的人员。
矩阵人员前面的案例已经讲过，会由条件变量去判断具体的审批人，这里就不多说了；固定人员就是固定的一个人去审批，没有条件变量参与判断。
需要注意的是审批模式的或签和会签。当处理人配置了多个时，如图中，可能参与审批的人有张三、李四、赵六，如果是或签则需要他们3人其中一人审批通过即可，因为流程会同时流转到他们3人处，；如果是会签，则需要他们3人都通过后，流程才会流转到下一节点。
然后自动完成条件可多选也可不选，当前处理人可能在前面的操作节点中已经存在了并且已经通过了，这里可以不用再次审批；如果处理人是发起人时也可自动通过。设置这个条件的目的是为了加快流程的审批，减少一些不必要的操作。
最后是操作设置，在工作流引擎中勾选了当前审批人可以进行哪些操作后，该功能将在业务系统中展示并使用，这一点需要与开发同学沟通清楚。具体操作按钮的逻辑如下：
说完了操作节点属性配置有哪些功能后，我们再来看几个逻辑问题：
1.如果处理人配置的是矩阵人员，而其角色对应条件变量中在实际发生的流程里没有时怎么办？
比如我先设置了一个角色叫项目经理，条件变量选的是项目等级，张三负责一级项目，李四负责二级项目；然后有个操作节点叫项目经理审批，选择了项目经理这个角色，。但是实际提交的立项流程的表单中没有项目等级这个字段，那实际流程都跑到这个节点了但是又找不到条件变量来判断该由谁去处理该怎么办。
这时有2种处理方式，1是直接将流程挂起，2是默认由角色中配置的第一个人员审批，两种处理各有利弊。
2.同一个条件变量，如果在流转条件中设置了，又在矩阵人员中设置并配到了操作节点会怎样？
这种配法倒不会让流程挂起，也没有逻辑性的问题，但是会让流转条件没有存在的意义了，为了更简化直接配一个操作节点就行了。
配置完一个完整的流程模型后，我们需要部署。但是一个模型可能前后会进行多次修改，每次修改就需要部署一次，所以一个模型会有多个版本，我们也就需要一个列表来对这些版本进行查看和管理。
更为重要的问题是，一个流程实例（实际发生的流程）可能会经历较长的时间才能审核完，有多个流程实例都在运行中时，所有完成的时间你没法预估，可能这个流程实例走完了下一个又发生了。但这时你又有修改流程的需求，总不可能把流程暂停了不让大家发起吧。
所以就引入了流程版本的概念，可能多个版本共存。比如现在是版本1有10个流程实例在运行中，你在0点改了流程模型并且部署了版本2，那从0点以后发生的流程都是走的版本2，但不会影响之前运行中的10个流程，那10个流程还是走的版本1。
如果这时你又说那10个流程实例走的是错误的版本，需要走流程2，可以将这10个流程实例直接终止，让他们重新发起流程就行了。
所以我们可以看到每个流程版本都有运行中、挂起中、已完成的数据统计（挂起中的数据怎么处理在后文中讲解）
该列表是所有发生过的和正在发生的流程实例的集合展示，点击列表我们可以进入下一页查看其执行详情：
流程执行详情页主要目的是为查看某一条流程的详细情况，并对其进行相关处理；如因为条件变量、处理人配置等原因未找到正确的处理人，流程将会挂起，此处可选择正确的处理人，以将流程正常运行完结。
本文由 @橘钻 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Pixabay，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。