从0到1构建工作流引擎（一）

一个完整的工作流引擎，应该具备哪些功能模块？这篇文章里，作者尝试结合实际工作经验和实际案例，对构建工作流引擎这件事儿进行了总结，并对工作流引擎的功能模块进行了大概讲述，一起来看。

(资料图片)

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

文章分为两篇，由4个板块组成：

工作流引擎简介； 从案例出发推演功能； 功能模块概览； 功能与逻辑详解。

本文包括前三个板块。

一、工作流引擎简介 1. 工作流是什么？

为了完成某一项工作，而需要有多个环节、多个人员来分工、配合共同完成；而每个环节和每个人员的处理操作是有先后顺序的，所以有流向性的特征，也就称之为“工作流”。

常见的工作流简单的有如请假流程、离职流程，较为复杂的有采购流程、立项流程等。

大家经历过就会知道一个工作流会有多个操作节点，也就对应多操作人员；比如请假需要部门领导通过、人事经理通过等，比如采购需要领导验收合同、财务付款等（工作流和审批流的概念本文就不展开）。

2. 工作流引擎主要是用来做什么的？

工作流引擎是一个为实现工作流程的定制化，并驱动工作流程完整进行的工具。其特点在于可以实现随着公司实际业务的发展（如组织架构的改动、业务逻辑的改动），而能快速做出灵活响应更改工作流，减少重复性的开发成本。

比如一开始公司只有10个工作流，随着业务发展需要20个，多出来的这10个不用写死在代码里，直接可以在工作流引擎内配置； 比如公司有人事变动，需要更改某些工作的审批人，也可以直接配置； 公司的业务发生了一些改变，原来的审批节点只有5个，现在要增加到10个，等等情况都可配置。 3. 工作流引擎的边界是什么？

工作流引擎主要只配置工作流，所以需要与业务系统如ERP区隔开，并需与业务系统通过接口对接，以此业务系统方可发起流程、审批流程、完成流程。

也就是说工作流引擎和业务系统是相互独立但又通过接口对接的两个系统，一个工作流引擎可以对接多个业务系统，为其配置工作流。

所以操作逻辑应该是：先在业务系统定义有哪些流程，然后在工作流引擎中配置具体流程，再在业务系统中发起/处理流程，并在工作流引擎中可以对已发起流程进行管理；当公司的各类业务系统较多时，不用每个业务系统都去开发自己的工作流管理模块，这样可以较大地也提高了开发和维护效率，减少了开发成本。

二、从案例出发推演功能

了解了工作流引擎是干嘛的，我们就可以来看看其应该包含哪些内容。但是如果我一来直接就从某个功能开始讲，大家肯定是比较抽象的。

所以我们先从一个审批案例着手，从0开始为完成这个案例我们该配置哪些数据？这样更有助于大家能先有一个全局的认识，然后再来讲一个个的功能，这样大家可能更容易接受。

前提条件：

某公司有甲、乙、丙、丁4个部门：

条件1：每个部门各有1个部门负责人a、b、c、d 条件2：甲/乙部门的分管领导是e，丙/丁部门的分管领导是f 条件3：东南区域的总监是g，西南区域的总监是h

假设成立项目也就是立项需要走流程，不同类型的项目走的流程肯定不一样，假设关于项目的维度有项目等级（包括一级、二级），项目区域（包括东南，西南）。通过排列组合，我们可以得到以下4类项目：

项目1：一级项目，东南 项目2：二级项目，东南 项目3：一级项目，西南 项目4：二级项目，西南

有了前提条件，我们再分场景来看，不同部门的人员发起不同类型的项目，流程会怎样走。

场景1

如果一级项目由分管领导审批，二级项目由部门负责人审批，不管哪个区域的项目都要由区域总监审批。根据这个前提我们就可以得到下面这个流程图：

先解释一下流程的构成元素，如上图：

有操作节点，比如提交、分管领导、部门负责人； 有网关，如菱形带×这个是互斥网关； 有流转条件，如图内的一级项目、二级项目，流转条件是和互斥网关是一起使用，通过流转条件来判断不同的工作流数据该流向哪个操作节点。

如果从0开始，这个时候系统里什么数据都没有，那我们是不是要先录入部门、人员等组织架构信息？所以就会得到如下图简化的表单信息：

但是注意，这上图只是组织架构信息，并不是该人员在流程中的实际角色。

再回头看一下流程图，我们在流程中只会有部门负责人、分管领导、区域总监这3个角色，并没有指定这个3个角色具体是谁进行审批？因为a是部门负责人，b也是，g是区域总监，h也是。

所以这个时候我们需要引入用户矩阵这个概念来解决这个问题，也就需要再录入一个表单来记录流程中的实际角色，如下图：

先说为什么要这样一张表来记录这些信息？为什么不直接用组织架构表？这样做主要达到2个目的：

为了解决多个人员担任同一角色，但又存在变量的情况（比如部门、区域不同），这样在流程中只需要配置一个角色就行了，不用每个人员都配置一次（具体后面演示）；比如同样是部门负责人，a管理甲部门，b管理乙部门。 为了将组织结构中的职位与流程中的角色进行解耦；同时调整更灵活，比如在公司中叫部门负责人，在流程中可以叫部门老大，如图3所示。

然后解释一下为什么要条件变量和变量值？是因为不同的项目会流向不同的操作节点，系统就需要通过条件变量来判断，而哪种项目要走哪条流程，是由其变量值来确定的。

根据以上变量值，再结合之前的流程图，我们就可以得到下图：

有了流程的相关数据，我们再来看流程会怎样走。假设张三是丙部门的人员，他来走立项流程，不同的项目属性会经历下列审批人：

流程的配置大概就是这些，但有1个思考的点：如果没有用户矩阵这张表，我们的流程会配置成什么样？

如图所示，我们需要把每个参与到人员都配置到流程中去，也就是一个人员就要占一个审批节点；并且只能通过流转条件来控制该项目需要走到哪个审批节点。这样流程将会非常庞大且臃肿。

场景2

基于场景1，我把这些元素打乱了再重新排一下来设定场景：如果甲/乙部门的项目由分管领导审批（e负责一级项目，f负责二级项目），丙/丁部门的项目由区域总监审批（g负责东南，h负责西南），最后再统一由部门负责人审批。所以得到如下流程图：

组织架构的表单我们已经有了，就不再赘述了。然后第二步我们需要往用户矩阵表里添加信息：

第三步就能得到这个带有用户矩阵的流程图：

所以可以得到以下结论：

假设张三是丙部门员工，发起一个一级、东南区域项目立项，会走g和c的审批； 假设李四是甲部门员工，发起一个一级、东南区域项目立项，会走e和a的审批。

为什么我会举场景2这个例子？

通过场景1和场景2，大家可以看出条件变量有很多，包括人员所属部门、项目所属区域、项目等级，而对比这两个场景大家可以发现，这些条件变量都是可以放到操作节点或流转条件里去配置的。

比如场景1中不同的项目等级走不同的顺序流，场景2中的项目等级是放到操作节点里，不同的等级经过不同的人审批，而这个审批的角色都叫分管领导。

三、功能模块概览

经过上面的例子，我们知道了一个完整的流程应该包含哪些元素：组织架构、用户矩阵、条件变量等，有了这些数据才能配置到流程内。

所以我们就可以看到一个工作流引擎应该由以下功能来组成：

下一篇接着讲工作流引擎具体的功能与逻辑。

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

题图来自 Unsplash，基于 CC0 协议

责任编辑：