一文了解工作流引擎

 

1 什么是工作流引擎

工作流最早起源于生产组织和办公自动化领域，它是针对平时工作中的业务流程活动而提出的一个概念，目的是将工作分解成定义好的任务或角色，根据一定的原则和过程来实施这些任务并加以监控，从而达到提高效率、控制过程、提升客户服务、增强有效管理业务流程等目的。为了更好地实现某些业务工作目标，可以利用计算机在很多个参与人之间按某种既定原则自动传递文档、信息内容或者任务。

2 为什么使用工作流引擎

工作流是在整个工作区过程中发生的流转，可能是结构化的，也可能是非结构化的。当数据从一个任务流转到另一个任务时，工作流就存在了。但是，如果数据没有流动，就没有工作流。

主要的工作流包括以下三种：

1. 流程工作流（Process Workflow）：当一组任务具有可预测性和重复性时，就会发生流程工作流。也就是说，在项目开始工作流之前，我们已经明确数据的流转方向。比如请假申请，一旦申请提交，后续的每一步处理过程相对固定，工作流几乎不会有变化。
2. 项目工作流（Project Workflow）：项目具有类似于流程的结构化路径，但在此过程中可能具有更大的灵活性，项目工作流只适用于一个项目。比如发布一个新版本的网站，可以准确预测项目的任务流程，但是这个任务流程不适用于另一个网站的发布。
3. 案例工作流（Case Workflow）：在案例工作流中，对于数据流转的方向是不明确的。只有收集到大量的数据时，数据流转的方向才会比较明显。比如保险索赔案例，一开始索赔请求是不可预测流程流转的，我们并不知道如何处理，只有经过人工干预实施调查才能做出相应的决策。

具体是否需要引入工作流引擎，取决于不同的业务内容是否复杂。如果业务流程相当复杂，或者流程逻辑经常变化，最好是引入工作流，相反业务简单且日后的变化甚小，那就没必要引入工作流了。工作流主要包括节点管理、流向管理、状态控制、流程实例管理等核心功能。

3 常见工作流比较

4 工作流规范

众所周知，市面上存在很多工作流引擎，比如activiti、camunda、flowable等，但其功能基本都是大同小异，除了工作流本身的机制外，也会遵从标准的规范，下面就围绕工作流引擎重要的三大标准规范BPMN、CMMN、DMN展开介绍。

• BPMN（业务流程建模与符号）：比较固化，侧重流程管理。

• CMMN（案例管理建模与符号）：比较动态化，侧重案例管理。

• DMN（决策模型与符号）：偏向计算，侧重决策。

5 业务流程引擎

BPMN（Business Process Model and Notation，业务流程建模与符号）

定义了基于流程图技术的业务流程图，同时减少了业务流程操作的图形化模型。业务流程模型是图形对象的网络图，包括定义操作序列的活动(或工作)和流控制，以便更好地让各部门之间理解业务流程和相互关系

BPMN其实就是我们印象中最常接触的工作流，像我们常用的请假、报销等审批都是基于BPMN2.0设计的，下面就着重介绍一下BPMN2.0提供的4类基础对象，了解了这4类基础对象也就基本掌握了BPMN。

1. 基础对象

BPMN2.0主要提供了四类基础对象：流对象，数据，连接对象，泳道

流对象（Flow Objects）

定义业务流程地主要图形元素，包括：事件、活动、网关

事件（Events）：在业务流程的运行过程中发生的事情

• 开始：表示流程的开始

• 中间：发生的开始和结束事件之间，影响处理的流程；比如消息事件，定时器事件，信号事件等

• 结束：表示流程的结束

活动（Activities）：包括任务和子流程两类；子流程在图形的下方中间外加一个小加号（+）来区分

网关（Gateways）：用于表示流程的分支与合并

• 排他网关：只有一条路径会被选择

• 并行网关：所有路径会被同时选择

• 包容网关：可以同时执行多条线路，也可以在网关上设置条件

• 事件网关：专门为中间捕获事件设置的，允许设置多个输出流指向多个不同的中间捕获事件。当流程执行到事件网关后，流程处于等待状态，需要等待抛出事件才能将等待状态转换为活动状态

数据（Data）

数据主要通过四种元素表示：数据对象（Data Objects）、数据输入（Data Inputs）、数据输出（Data Outputs）、数据存储（Data Stores）

连接对象（Connecting Objects）

流对象彼此互相连接或者连接到其他信息的方法主要有三种

• 顺序流：用一个带实心箭头的实心线表示，用于指定活动执行的顺序

• 信息流：用一条带箭头的虚线表示，用于描述两个独立的业务参与者（业务实体/业务角色）之间发送和接受的消息流动

• 关联：用一根带有线箭头的点线表示，用于将相关的数据、文本和其他人工信息与流对象联系起来。用于展示活动的输入和输出

泳道（Swimlanes）

通过泳道对主要的建模元素进行分组，将活动划分到不同的可视化类别中来描述由不同的参与者的责任与职责。

2. 流程设计器

对于流程设计器，大家应该并不陌生，用户通过拖、拉、拽来实现流程的建模，使得流程建模变得简单，常用的比如bpmnjs

随着用户审美需求的提高，简易的流程设计已经无法完全满足现代的可视化需求了，因此像钉钉，宜搭等也都构建了符合普通用户审美需求的工作流设计器，不过对于企业级地复杂流程还是建议采用符合BPMN2.0标准的流程设计器以设计更加复杂的流程场景

3.多种审批人选择策略

在云筑网中，我们的统一审批中心为了兼容不同场景下的审批业务，在设计审批流程时可以选择不同的审批人选择策略。审批策略为以下五种：

GIVEN_USER："指定审批人"

GET_BY_FORM_USER："表单控件中选择审批人"

GIVEN_ROLE："拥有角色的人作为审批人"

API："通过api调用获取审批人列表"

TEMPLATE："提供角色和审批人模板实际审批人由前端在发起审批时通过表单传入"

在设定了审批人选择策略后，发起审批时会根据已选择的策略去获取相关的每个节点的审批人，并给相应审批人通过云筑网消息中心来发送审批待办消息。

4.多用户体系接入

目前，在云筑网内部，统一审批中心兼容了用户中心和tower两种用户体系，在创建审批流时，可以根据业务需要选择不同的用户体系，进而覆盖了公司内部和外部的多场景审批需求。在统一审批中心中，可以通过rpc和http等方式来提供审批流基础服务，统一审批中心会在调用的过程中自动根据相应请求标识来区分不同的用户信息，进而实现了用户体系的可插拔。

6 案例模型引擎

CMMN（Case Management Model and Notation，案例管理建模与符号）

用于捕获需要处理各种活动案例的工作方法，这些活动可能以不可预测的顺序执行以响应不断变化的情况。

从上图案例可以看出，CMMN具有与BPMN不同的基本范例，其使用的指标主要包括：

无序性：如果序列无关紧要，并且可以按任何顺序执行任务，则这将在BPMN中产生过多的连接-临时建模。也许使用临时子流程可以避免混乱。

活动取决于条件：定义条件是CMMN的强项。可以定义许多任务，但是它们只能在某些情况下起作用。例如，这种情况可能是订单超过一定数量或客户具有VIP身份；其他已完成的任务也会影响条件。可选因素和数据相关因素的这种组合不能在BPMN中反映出来。

专用计划阶段：由于能够处理任意任务，CMMN可以适应一个计划阶段，在该阶段中，一个工人计划一个案例并启用任务。其他工人将不得不遵守计划。

综上所述，CMMN可以解决无需严格顺序，涉及需要人工决策和不可预测的建模情况，比较适用于特殊的业务场景，比如保险索赔案例，贷款案例计划等，本文就不做过多阐述了，有兴趣的同学可以自行了解。

7 决策引擎

DMN（Decision Model and Notation，决策模型与符号）

定义了业务决策的模型和图形，在BPMN业务活动流程中，可通过业务规则任务调用DMN决策。DMN的目的是想把业务代码和决策进行解耦，使决策分析人员只需关心决策即可。

如上图可以看出，决策引擎其实就是根据预先配置的很多规则条件限制做出的ACCEPT和DECLINE决定，当然也可以有其他不同类型的枚举决策。那决策引擎和规则引擎又有什么区别呢？

规则引擎与决策引擎的区别

（1）运行方式不同

 规则引擎：需要BM根据实际业务进行相关的调整和设置；

 决策引擎：虽然能够根据实际业务进行人工干预，但其实现是由系统自动化做出决定。

（2）用户不同

 规则引擎：针对某一个或者多个群体；

 决策引擎：精准定位到单个用户的偏好。

（3）意义不同

 规则引擎：本身是不带规则的，规则需要人为输入，可单独将规则从系统剥离出来放到规则引擎单独进行执行管理，可以按照需求进行规则的配置、执行、管理，不同行业都可以配置出属于自己的规则平台；

 决策引擎：包含规则和决策条件，具备了对规则的决策能力。

DMN的作用

• 在业务流程过程中，通过定义特别的任务或活动描述决策是如何协作的

• 决策逻辑可以用来做单个决策的具体逻辑定义，例如业务规则，决策表或可执行的分析模型

• 决策需求图形成业务流程模型和决策逻辑模型之间的桥梁

– 业务流程模型将在业务流程中定义决策发生所需的任务

– 决策需求图将定义决策逻辑中的任务、相互关系、以及前提条件

– 决策逻辑将定义足够详细和必要的策略，以允许验证和自动化

8. 表单引擎

表单引擎，也可以称为表单流程，流程表单和工作流表单，是基于Web界面上可视化编辑的表单设计系统。它可以设置数据库的字段和属性，并设置模块的配置。当前市场上的低代码表单引擎，它可以为企业信息管理人员或软件开发人员提供简单，快速和高效的Web表单设计和开发工具。它可以轻松绑定到数据，并且无需编辑任何程序代码即可实现。

与传统的开发方法相比，每个系统都是通过编写代码来实现的，例如行政管理，人力资源，资产管理，招投标审批等。尽管有固定的开发模型，但是开发是相对基于模板的，但是重复编写代码也需要熟悉系统的开发人员，并且表单的开发也与业务方强关联。因此表单引擎诞生的目的不仅仅可以减少大量重复的业务表单开发工作，更深层次的意义是做到了工作流表单与业务解耦，使得业务在使用工作流的时候，减少甚至完全不需要业务方做任何改造。

作用和意义

1. 工作流与业务方实现解耦，以零侵入地方式使业务接入工作流。
2. 业务工作流表单更好地管理，更轻便地维护。
3. 提高工作效率。即使是个性化的系统定制也可以批量化的实现业务功能。
4. 快速更新。可以随时根据用户要求添加或删除字段和统计信息，摘要以及数据导入和导出，而无需修改任何代码行。
5. 个性化的DIY系统。使用表单引擎可以快速定义其他系统，例如：行政管理，客户关系，采购管理，请假表单，人事档案等。

缺陷与不足

尽管目前市面上存在很多开源的表单设计器，并且很多大公司都在建设低代码平台，但目前表单引擎还是有一些不足的地方。

1. UI相对简陋。目前市面上开源的表单设计器，整体UI表现能力不足，用户感官不太理想，需要自定义样式。
2. 定制化组件要求较多。对于公司的一些特殊需求，传统的表单能力，如文本，下拉框，日期选择器等显然不足以满足业务需求，因此还是需要根据业务需求定制化开发组件。
3. 无法完全表达前端布局。比如弹性布局，响应式等，兼容能力都不太理想，需要定制化开发实现。

总体而言，低代码平台也算是革命性地创新了，虽然还存在些许不足之处，但其设计的初衷是减少业务耦合，避免重复劳动，提高工作效率。相信在不久的将来表单引擎会越来越常态化。

9.总结

工作流引擎主要应用于办公自动化和业务流程自动化，比如OA审批、业务审批、服务编排等，它将独立、零散的物料进行编排集成。能够改进和优化业务流程，提高业务工作效率；实现业务过程控制，提高业务柔性；降低业务耦合，提升业务性能。在微服务的时代，一切讲究小而精的工作效率，告别大而杂的设计理念。当我们遇到需要编排设计、状态流转等需求时，可以尝试考虑使用工作流引擎来完成。