流程引擎

流程概念

流程的定义

维基百科：对工作流程及其各操作步骤之间业务规则的抽象、概括描述。即将工作流程中的工作如何前后组织在一起的逻辑和规则。

流程就是一组活动按照一定的顺序组成的序列流，其顺序可能是串行的、并行的，或者两者的组合模式

流程一般具备六个要素：输入、活动、活动间的相互作用、输出、流程的服务对象和价值。

  • 输入：是运作流程所必须的资源
  • 输出：流程运作的结果
  • 活动：是流程运作的环节
  • 活动间的相互作用：是环节之间的关系，把流程从头尾串联起来
  • 价值：是流程运作为流程的服务对象带来的好处
  • 流程的服务对象：是流程服务的对象，也叫做流程的下一个环节

为什么要用流程引擎

工作流程常见问题

  1. 做需求时考虑不周全，上线后不断修改流程。

  2. 组织架构调整，产生业务流程变更。

  3. 业务流程比较复杂，使用的状态很多。

  4. 工作流业务耦合度太高，很多场景不适用。

例子

假定我们有一个支付订单状态需要维护，它的状态图如下：

它的状态跃迁自左向右，清晰名了，而且没有处理角色的概念，此时我们使用代码控制好状态流转即可，无需使用框架。

流程1

假设有一天流程变更为下图所示：

流程2

如果是开发人员，看到的则是：

public function doSomething(int case){
   if(case == 0){
       //业务逻辑
       retutn;
   }
    if(case == 1){
       //业务逻辑
       retutn;
   }
    if(case == 2){
       //业务逻辑
       retutn;
   }
   .
   .
   .
}

这个采购订单的状态复杂多变，状态的转换不稳定性很强，随时有可能增加新的状态；而且不同状态的处理人也是不同的，存在权限管理功能，若此时我们仍然使用一个状态字段来维持状态变更，无疑会困难重重。

复杂繁多的业务流程如果采用 if else 实现那将是崩溃的，代码不可维护，业务流程在代码中可读性很差，所以就有了业务流程模型图示 BPMN2.0 规范，我们要做到就是把业务场景抽象为标准流程图，把流程图丢到流程引擎中按流程定义约定逐步流转，很显然扩展性和业务可描述性会好很多，所以工作流引擎主要用于解决复杂的业务。

流程引擎适用场景

  1. 状态的个数及其稳定性，个数多且不稳定，适合使用工作流引擎。

  2. 每个状态的处理人，处理人角色多且不稳定，适合使用工作流引擎。

流程引擎优缺点

优点

- 具有可视化的流程设计工具
- 业务数据和流程数据的分离，可以进行更专注的性能优化，业务划分
- 内置API能很好的完成常见的功能场景
- 具有完善的流程监控体系
- 具备大量的自定义扩展接口

工作流规范简介

20 世纪 70 年代中期，工作流出现并运用于办公自动化领域，使流程管理技术第一次有了系统的技术规范。20 世纪 80 年代 初期，工作流伴随着 OA 系统走向商用，但是应用范围有限。至 80 年代后期，OA 系统的研究被群件和工作流管理系统所代替。20 世纪 90 年代以后，相关技术逐渐成熟，工作流管理联盟(WfMC)成立并发布了工作流参考模型。进入 21 世纪， BPM 更进一步发展。SOA 的出现使得流程管理技术从工作流转向业务流，基于此的一系列规范也相应被推出。

流程管理技术发展时间线

BPMN2.0 规范

业务流程模型和标记法（BPMN, Business Process Model and Notation）是一套图形化表示法，用于以图形的方式详细说明各种业务流程。

它最初由业务流程管理倡议组织（BPMI, Business Process Management Initiative）开发，名称为”Business Process Modeling Notation”，即“业务流程建模标记法”。BPMI 于 2005 年与对象管理组织（OMG, Object Management Group）合并。2011 年 1 月 OMG 发布 2.0 版本（时至今日，没人会用 1.0 版本了），同时改为现在的名称。

BPMN2.0 规范的实现，实质上是一个按照特定规范编写的 XML 文件，使用特定的 BPMN 设计器，即可以图形化的形式查看和编辑该文件。Camunda，Activiti，Flowable 等主流的 java 开源流程引擎，以代码的形式实现了这套图形化表示法，使任务的流转依赖图形，而非具体的实现代码。

BPMN2.0规范图1

开源流程引擎

目前 java 主流的开源流程引擎，有 jBPM，Activiti，Camunda，Flowable 等

Activiti
Activiti 由 Alfresco 公司开发，目前最高版本为 Activiti cloud 7.1.0。其中 activiti5 和 activiti6 的核心 leader 是 Tijs Rademakers，由于团队内部分歧，2017 年 Tijs Rademakers 离开团队，创建了后来的 Flowable。activiti6 以及 activiti5 代码则交接给 Salaboy 团队维护，activiti6 以及 activiti5 的代码官方已经暂停维护。往后 Salaboy 团队开发了 activiti7 框架，activiti7 内核使用的还是 activiti6，并没有为引擎注入更多的新特性，只是在 Activiti 之外的上层封装了一些应用。直到 Activiti cloud 7.1.0 版本，Activiti cloud 将系统拆分为 Runtime Bundle、Audit Service、Query Service、Cloud Connectors、Application Service、Notification Service。这些工作的主要目的其实就是为了上云，减少对 Activiti 依赖的耦合，需要使用 Activiti 的系统只需要通过调用 http 接口的方式来实现工作流能力的整合，将工作流业务托管上云。

Flowable
Flowable 是基于 activiti6 衍生出来的版本，目前最新版本是 v6.7.0。开发团队是从 Activiti 中分裂出来的，修复了一众 activiti6 的 bug，并在其基础上实现了 DMN 支持，BPEL 支持等。相对开源版，其商业版的功能会更强大。Flowable 是一个使用 Java 编写的轻量级业务流程引擎，使用 Apache V2 license 协议开源。2016 年 10 月，Activiti 工作流引擎的主要开发者离开 Alfresco 公司并在 Activiti 分支基础上开启了 Flowable 开源项目。Flowable 项目中包括 BPMN（Business Process Model and Notation）引擎、CMMN（Case Management Model and Notation）引擎、DMN（Decision Model and Notation）引擎和表单引擎（Form Engine）等模块。

Camunda
Camunda 基于 activiti5，所以其保留了 PVM，最新版本 Camunda7.17，开发团队也是从 activiti 中分裂出来的，发展轨迹与 Flowable 相似。通过压力测试验证 Camunda BPMN 引擎性能和稳定性更好。功能比较完善，除了 BPMN，Camunda 还支持 CMMN（案例管理）和 DMN（决策自动化）。Camunda 不仅带有引擎，还带有非常强大的工具，用于建模、任务管理、操作监控和用户管理。

jBPM
jBPM 由 JBoss 公司开发，目前最高版本 7.61.0.Final，不过从 jBPM5 开始已经跟之前不是同一个产品了，jBPM5 的代码基础不是 jBPM4，而是从 Drools Flow 重新开始，基于 Drools Flow 技术在国内市场上用的很少，jBPM4 诞生的比较早，后来 jBPM4 创建者 Tom Baeyens 离开 JBoss 后，加入 Alfresco 后很快推出了新的基于 jBPM4 的开源工作流系统 Activiti，另外 jBPM 以 Hibernate 作为数据持久化 ORM，而 Hibernate 也已不是主流技术。

osworkflow
osworkflow 是一个轻量化的流程引擎，基于状态机机制，数据库表很少，osworkflow 提供的工作流构成元素有：步骤（step）、条件（conditions）、循环（loops）、分支（spilts）、合并（joins）等，但不支持会签、跳转、退回、加签等这些操作，需要自己扩展开发，有一定难度。如果流程比较简单，osworkflow 是很好的选择。

选型建议：

Flowable6 > Activiti7 > Activiti6 > Activiti5 > Camunda > jBPM7

表单引擎

表单引擎，也可以称为表单流程，流程表单和工作流表单，为快速实施项目研发的轻量级表单设计工具,是基于Web界面上可视化编辑的表单设计系统。它可以设置数据库的字段和属性，并设置模块的配置。采用表单引擎工具可在不开发和新增加代码的情况下设计出新表单样式，同比程序开发可省掉程序员差不多70%的开发工作量，并且后期维护相对简单，管理方便。

表单构成

表单内容一般由基本信息、逻辑主体、补充说明三部分构成：

基本信息：基本就是常规信息，差不多每个表单都会用到的，例如：发起人、发起组织、发起时间等身份标识，与业务相关的客户基本信息或者合同基本信息等。

逻辑主体：流程的主要部分，相当于流程的详细描述，涉及逻辑交互、数据交互等，比如合同具体成交的业务类型、费用、数量、付款和回款信息等。

补充说明：作为逻辑主体没有表达清楚的补充说明，例如备注、说明、附件等让相关人员将表单没表达清楚的部分表达清楚。

字段设置

字段设置个性化、灵活性越高，流程引擎能面向的用户则更广，能达到的管理要求也更高。

1）字段排版排序：字段排版、排序要符合用户使用习惯，有逻辑关联的字段要放一起，不要隔开；例如：客户姓名后放了一堆合同信息，最后又放一个客户地址，这样填写和审批都不方便，打乱使用者思维；合理的排序在数据列表展示或导出时都省事不少，表单在使用过程中会不断优化调整，优化后的字段页面上也要及时取消，避免增加页面空值字段。

2）字段查看权限：有的字段比如上传的附件资料，不允许某些节点处理人查阅，则会限制查看。

3）字段编辑权限：不是所有字段在所有节点都允许编辑，所以要根据字段的数据管理要求来设置字段在不同节点的编辑属性。

4）字段留痕：字段修改和留痕关联，重要的字段修改后如果找不到修改人只有系统背锅。有的字段在员工节点填写后，上级节点需要再确认修改；或者流程已结束再修改字段内容的情况就需要将修改痕迹保留下来；留痕就是日志，需要考虑痕迹的重要性，如果重要性不高的字段就不必设置留痕，浪费服务器空间。

5）字段只读：自动填充的关联数据有的能修改，有的不能修改，如果有只读这个控制开关便能更好管理，默认情况应该将自动填充的关联数据都设置只读；设置了只读的字段，一定要关闭必填属性，否则当关联数据空值或者关联失败时，用户是无法提交表单的，设计者应该避免犯这种常规错误。

6）修改字段值：很多流程结束后但需要修改页面内容，需要考虑是否允许不通过节点，直接更改页面表单值，如果允许直接修改已有值，那必须得留痕；但应该尽量避免这种情况，如果直接修改已有值会让流程规范变得更难，使用者对于规范会越来越不重视。

关联数据

1）页面字段数据：表单除了要手动输入的数据外，还有很多数据是由其他表单关联过来的；选择关键字段后会自动带出关联数据，有的表单可能一个字段都不填，打开流程所有数据都自动填充了；有的数据也只需要选择关键字段就自动填充；常规人事、行政审批对数据串联要求不高，但财务或者业务，逻辑关联性较强，涉及数据多，数据串联就变得非常重要。

2）流程相关数据：除了自动填充表单字段数据外，还要将影响审批判断但表单上没有的数据体现出来，便于审批；例如项目请款，同一个合同所有的请款历史、项目信息都应该展示出来，让审批人能快速做审批判断。

表单引擎单优点

1.技术人员在有详细需求文档的情况下，通过表单引擎可快速实现表单功能。

2.轻松维护系统。

3.提高工作效率。即使是个性化的系统定制也可以批量化的实现业务功能。

4.快速更新。您可以随时根据用户要求添加或删除字段和统计信息，摘要以及数据导入和导出，而无需修改任何代码行。可以在半小时内自定义演示，以赢得客户的信任。

5.个性化的DIY系统。使用表单引擎系统快速定义其他系统，例如：行政管理，客户关系，采购管理，请假表单，人事档案等。

表单引擎设计思想

基于文件模式的与基于关系型数据库模式的。

基于文件设计的

基于文件设计的思想是，创建表单的时候，首先创建一个文件比如：xxxx.jsp,xxx.aspx,xxx.php 文件。在这个文件上拖放相关的控件，或者加载相关的通用js代码,或者在对字段Input元素做特殊的标记，让表单引擎解析执行。

表单运行时，运行的界面载体是一个Url文件地址，这个地址引用到相关的菜单上去。

基于文件设计思想的表单引擎系统，需要由软件开发工作者首先设计好项目需要的网页内容，进行封装和部署后，生成使用者可以编辑的表单结构。因为是定制化开发可满足不同的表单样式、表单模板等的设计，能最大程度的符合企业管理者的需求。

弊端一、文件表单布局排版是固定化的，需要改动就需要联系研发人员进行重新设计页面布局，耗时长。

弊端二、该设计模式不能适用于多种行业的表单需求。如现有的系列OA请假报销等表单文件是不能使用项目管理、公文审批等表单引擎需要的。只能是需要开发者根据后者的表单要求重新研发网页功能，从而导致现有表单系统的不可复用性，以及开发多套表单引擎系统投入的大量的人力研发。

基于关系数据库设计

基于关系数据库设计的组成部分是表单设计器、表单解析执行器、表单模板三部分组成。

表单设计器，把表单元素都按照关系表存储到数据库里面，每个表单有一个ID，这个表单ID，挂接到表单的解析执行器上，就可以工作。

表单模板将从表单设计器上设计组件关系存储到数据库中，由各个组件表组成的数据间的关系拼接成表单模板。

表单解析执行器是将表单模板数据进行解析，将解析后的数据形态以网页的形式展现

基于关系数据库的设计模式将表单引擎系统封装为一个设计工具，任何需要的表单只需要在该工具上进行拖拽设计即可，拖拽生成表单数据以数据流的形式存放在数据库中，由系统内置的表单解析器解析和展示填写的内容。该过程无须研发人员改动，表单设计人员可随意使用表单设计工具实现目标表单。

弊端是表单展示为统一风格，较为单调。

表单引擎类型

1. 自由表单
2. 自定义表单
3. 开发者表单
4. Office表单

表单、流程引擎的关系

流程引擎与表单引擎的关系，就是车的制动系统与车厢的关系。

汽车的控制系统控制前进、转向、后退、鸣笛、刹车等，流程引擎控制功能有发送、移交、退回、关注、删除等。

汽车的车厢可以填充货物，流程的表单可以传递数据。汽车的控制系统、车厢、货物与流程引擎、表单引擎、表单数据三者的关系类似。

表单引擎与流程引擎，就类似于汽车的控制系统与汽车的车厢一样。

流程 = 控制系统 表单 = 货物盒子 数据 = 货物

引擎测试

一条小咸鱼