关于流程引擎-BPMN引擎
BPM、BPMN、BPMN2.0 概念介绍
基本概念
在介绍流程引擎前，我们需要了解一些基础概念。首先 BPM（业务流程管理），从管理业务流程的角度来说，我们现有的 IT 系统大多数都属于这一类，比如供应链领域的 InStock（WMS），物流管理/提货送货预约（TMS），订单管理 OMS、SRM、CRM等。都可以称之为 BPM 系统。系统存在的意义就是用来管理企业/政府等经营/行政主体管理自身纷繁复杂的业务关系以及业务流程。
正如我们处理现实中的问题的解决思路一样，我们通常对已经存在复杂问题进行模型化的抽象，通过模型来推导解决问题的方案。也就是所谓的建模（这一过程也被称之为 Business Process Modeling 业务流程建模）。BPM 有很多种建模语言，BPMN（Business Process Modeling Notation）就是其中的一种建模语言。
而在 BPMN 发展的过程中，基于 BPMN 的一些特性与业务流程管理中常见的一些情况，总结提炼出了一套标准。这套标准或者也可称之为规范，在2004年5月由 BPMI Notation Working Group 对外发布，这就是 BPMN 1.0 规范。后 BPMI 并入到 OMG 组织，并在 2011年推出 BPMN2.0 标准，对 BPMN 进行了重新定义(Business Process Model and Notation)。这就是我们常说的 BPMN2.0
BPMN 标准是听得比较多的工作流标准，但工作流的规范其实不止一种，还有 XPDL(XML Process Definition Language)，BPML(Business Process Execution Language) 等。甚至他们的出现时间比BPMN 更早，只是因为一些技术和非技术原因，BPMN2.0 被普遍使用了，而非 BMPN2.0 规范的厂商也逐渐转移了。
对象管理组织（英文Object Management Group,缩写为OMG）是一个国际协会，开始的目的是为分布式面向对象系统建立标准，现在致力于建立对程序、系统 和 业务流程建模的标准，以及基于模型的标准。
BPMN 的价值
BPMN 的开发旨在减少众多已存在的业务建模工具和流程记录工具之间的断层。BPMN 的标准化组织通过吸取许多已经存在的专业工具及相关经验，形成了一套标准的标记语言。而一个好的，易用的，标准的建模标记语言，可以减少业务与IT用户之间的混乱。
另一个驱使 BPMN 的开发原动力是，历史上由业务人员做出来的业务流程模型与由 IT 实施人员设计和构建的流程执行模型在很大程度上都是一个不断趋近而又不断交错的，有必要将原有的业务流程模型转换为执行模型，而这个转换对于业务流程拥有者和 IT 实施人员来说，都是容易出错且很艰难的过程。
为了减少业务建模与技术实现的断层，开发 BPMN 的重要目标就是要创建一座桥梁，连接业务流程建模标记到 IT 执行语言。
工作流引擎与 BPMN
什么是工作流引擎
工作流引擎是一个用于管理和调度流程的应用程序，可以集成并作为程序框架使用，包括流程定义的存储，流程的节点与流程条件判断和调度、流向管理、流程实例管理等功能。
工作流引擎与 BPMN 的关系
通过 BPMN（业务流程建模语言）来进行 BPM（业务流程建模）得到的结果就是业务流程的定义，它规定了业务的流转过程由谁参与等等。而协调并执行这个流程，记录流程的执行过程和结果就是工作流引擎的职责范围了。
多款工作流引擎的比较
现在主流的工作流引擎基本都是基于 BPMN2.0 标准了，下面这几种也就是 Java 领域业界相对主流的工作流引擎，我们接下来对其进行简单对比分析
JBPM（Java Business Process Management）
由 JBoss 公司开发，目前最高版本 JPBM7，不过从 JBPM5 开始已经跟之前不是同一个产品了，JBPM5 的代码基础不是 JBPM4，而是从 Drools Flow 重新开始。下面要涉及的很多产品都是以 JBPM4 的代码为起点进行开发的。
Activiti
Alfresco 软件开发，基于 JBPM4，后并入 OMG，目前最高版本 Activiti 8（不过当前主流使用都是 Activiti 7）。Activiti5 版本的时候，核心团队发生了比较大的变动（离职），Activiti6 的开发团队在新版本中去除了 PVM，纳入了 DMN，重构 XML 解析，BUG 较多，目前主要团队致力于 Activiti7,5&6 已经官宣不维护。
Flowable
基于 Activiti6，最新的开源版本是 Flowable7，开发团队是从 Activiti 中分裂出来的，修复了一众Activiti6 的 bug，并在其基础上研发了 DMN 支持，BPEL 支持等等。相对开源版，其商业版的功能会更强大。
Camunda
基于 Activiti5，所以其保留了 PVM，最新版本 Camunda8，开发团队也是从 Activiti 中分裂出来的，发展轨迹与 Flowable 相似，同时也提供了商业版。
JFlow
前身 ccFlow，国产的工作流引擎，由济南驰骋公司开发维护，主打中国式的业务流程，由于是国产的软件，中文化程度比较深，业务开发也对用户比较友好。国产的开源工作流引擎还是挺多的，JFlow 是其中功能比较完善的一个，同时对比 Activiti，流程上更加中国化，支持自定义流程跳转，加签等。其他国产工作流就不列举了。
表格对比
还有很多工作流，比如 Osworkflow、Shark、Apache ODE、ProcessMaker，SWF，Bonita，Openwebflow等，不过做 BPM 的话，相对于上面列举的产品还是有些缺陷，比如流程过于简单，资料过少等所以当前主要从支持的标准和社区活跃度表现比较好的工作流中筛选出几个选项进一步比较，如下表：
| Activiti 7 | Flowable 7 | Camunda8 | JBPM 7 | JFLOW | |
|---|---|---|---|---|---|
| 功能 | |||||
| 会签 | √ | √ | √ | √ | √ |
| 回退 | × | √ | √ | - | √ |
| 驳回 | × | √ | √ | √ | √ |
| 自定义流转 | × | × | √ | - | √ |
| 加签、减签 | × | √ | √ | - | √ |
| 多实例 | √ | √ | √ | √ | √ |
| 事务子流程 | √ | √ | √ | √ | √ |
| 版本迁移 | × | × | √ | × | × |
| 兼容性及二次开发 | |||||
| 支持的流程格式 | BPMN2.0、XPDL、PDL | BPMN2.0、XPDL、XPDL | BPMN2.0、XPDL、XPDL | BPMN2.0 | BPMN2.0 |
| 开源情况 | 开源 | 提供商业和开源版 | 提供商业和开源版 | 开源 | 开源 |
| 开发基础 | jBPM4 | Activiti 5 & 6 | Activiti 5 | 版本5之后Drools Flow | 自开发 |
| 直接支持的脚本 | JUEL、groovy | JUEL、groovy | python、ruby、groovy、JUEL | - | - |
| 引擎核心（跟代码兼容有关） | 去除PVM | 去除PVM | 流程虚拟机（PVM）（迁移上有优势） | Drools | 自研 |
| Spring结合 | √ | √ | √ | √ | √ |
| 二次开发难度 | 一般 | 一般 | 一般 | 较难 | 一般 |
| 未来拓展 | |||||
| CMMN支持 | × | √ | √ | × | × |
| DMN支持 | √ | √（6.4之前不稳定） | √ | √ | × |
| 历史数据处理（NoSql） | × | √ | √（只提供了解决方案） | - | × |
| 支持数据库 | Oracle、SQL Server、MySQL | Oracle、SQL Server、MySQL、postgre | Oracle、SQL Server、MySQL、postgre | Mysql，postgre | oracle,sqlserver,mysql |
| 集群部署 | √ | √（6.5版本支持） | √ | √ | √ |
| 云部署 | √ | - | √ | - | √ |
| 其他特性 | |||||
| 持久化框架 | Mybatis | JPA二次封装 | Hibernate | JPA | - |
| 架构 | spring boot 2 | spring boot 1.5 | spring boot 2 | Kie | spring boot 2(特别版本) |
| 事务管理 | MyBatis机制/Spring事务控制 | hibernate机制/Spring事务控制 | hibernate机制/Spring事务控制 | Bitronix，基于JTA事务管理 | - |
| 分布式事务 | |||||
| MyBatis机制/Spring事务控制 | - | 补偿机制，SAGA 模式 | Bitronix，基于JTA事务管理 | - | |
| 开发手册 | https://activiti.gitbook.io/activiti-7-developers-guide/ | ||||
| 部分网页打不开 | http://www.shareniu.com/flowable6.5_zh_document/bpm/index.html | https://docs.camunda.org/manual/7.13/user-guide/ | https://docs.jboss.org/jbpm/release/7.40.0.Final/jbpm-docs/html_single/ | http://ccbpm.mydoc.io/ | |
| 运行模式 | 独立运行和内嵌 | - | 独立运行和内嵌 | - | 独立运行和内嵌 |
| 源码活跃度 | 相对活跃 | 相对活跃 | 比较活跃 | 相对活跃 | 一般 |
| 源码地址 | https://github.com/Activiti/Activiti | https://github.com/flowable/flowable-engine | https://github.com/camunda/camunda-bpm-platform | https://github.com/kiegroup/jbpm | https://gitee.com/opencc/JFlow |
| 设计器 | 集成idea eclipse，web | 自提供，eclipse | 自提供，eclipse | Eclipse | 自提供，.net开发 |
| 集成接口 | SOAP、Mule、RESTful | SOAP、Mule、RESTful | SOAP、Mule、RESTful | 消息通讯 | SOAP、Mule、RESTful |
| 内部服务通讯 | Service间通过API调用 | Service间通过API调用 | Service间通过API调用 | 基于Apache Mina异步通讯 | |
| - |
特别说明：
- 源码活跃度：从分支数，提交数，参与者，最近提交时间等判断
- Drools Flow (process/workflow)：该工作流引擎是 Drools 下的一个项目，JBPM 的规则引擎正是Drools，由于 Activiti 开发自 JBPM4，所以 Activiti，Flowable 以及 Camunda 都有 Drools 的影子。
- 空白处表示的代表的暂时未查证的内容
- 另外要说明的是，表格中支持的功能需要有不少部分需要认真探讨，比如 Camunda 宣称支持各种功能，以及 Nosql 存储，但实际上，其支持的回退，撤回都是通过一个跳转实现的，要打折扣，NoSql 也只是提供了解决方案，要自己实现。
大致总结起来。Activiti7 相对于 5 和 6 没有太多功能上的变化，主要致力于一些辅助功能，对接一些基础技术。比如云原生、ELK、spring cloud。分布式的应用或许会对性能有一定的提升。
Flowable 的 NoSql 方案和消息队列比较特别，同时对 DMN 和 CMMN 的研究也比较多，是个不错的选择。
JBPM 近年来新的文档少一些，应用和二次开发可能会比较吃力。JFlow 功能比较齐全，而且中文化的设计器对开发人也和业务人也都比较友好，但是他的材料基本限于官网，后期不会保障。
Camunda BPM 支持的功能比较多，对 DMN 和 CMMN 的支持也是推出最早的，性能上看起来也做了比较多的应对，虽然商业版的推出减少了开源版的维护，但仍然是几个竞品中综合看起来比较符合当前需求的，PVM 的保留也会使得迁移比较顺滑，具体使用情况还需要进一步尝试，比较推荐。（如果不是旧产品迁移其实需要更多选择，框架改革的优化是可以考虑在内的，根据需求选择）
工作流引擎的使用场景
方式一
将系统中对于审批/经办等内容交给工作流引擎处理，其他复杂的传统业务由代码处理。
此种方式可以将相对比较固定的审批流转、委托代办、会签或签等功能分离给工作流引擎处理，而相对复杂的各种业务仍然采用代码定制的方式来拟合业务，常见各种 OA 系统
这样做的优点是，对于各种复杂的权限判断，业务上的复杂处理，牢牢掌握在自己手中，对于业务流转、条件判断等直接使用代码解决，理解起来简单，操作上直接。
缺点方面，工作流引擎形同虚设，没有发挥出更大作用。
形象的例子是：你到餐馆去吃饭，想要吃一份儿水煮鱼，你认识会做水煮鱼的厨师，直接来到后厨，找到厨师并且提供给厨师全套厨具以及待烹饪的生鱼让他给你做饭。简单直接，没有中间服务员点菜和传菜的步骤，做菜的指令直接传递给厨师，菜做好了也是直接交给你的。
方式二
作为业务调度中心
业务中的每一个步骤的具体执行由代码完成，而步骤之间的所有衔接全部交由工作流引擎处理。业务发起时，调用方只负责将对应的发起人和要发起的业务代码传递给工作流引擎，其余的事情交给引擎自己去调度。
以仓储业务的入库单的提交为例：
从单据提交，发起审批，保存批次信息，保存单据信息，到根据配置生成仓库作业请求，修改库存，回调修改单据状态等等，各个环节的启动与流转，完全交给工作流引擎调度。发起方只需要去关注整个业务的进展状态即可，不再关注后续执行的细节（如何时生成请求，应该使用什么作业模式等等）
这种做法的优点是，发起方与执行方进行了拆分，引入了调度协调器的角色。业务的执行依赖调度器的串联。发起方不必再关注后续的细节，只需关注业务本身的流转状态。业务流程的编排由事先指定好的 BPMN 模型定义。
缺点方面，引入了更多的复杂度，工作流引擎成为了系统的核心运转依赖组件，需要在数据一致性、并发、与高性能方面做更多的设计与考量。
使用 BPMN 及工作流引擎来处理业务流程的优缺点
优点
业务流程间的可视配置化
开发与业务人员间的交流语言得到了统一
使知识（业务、决策逻辑、具体执行等）可以得到更大范围的沉淀
缺点
性能表现
流程节点（任务）本身在执行过程中经历了更多的步骤以及持久化过程，对于性能上以及优化上引入了更大的复杂度。
既有研发方式的变化
难以在代码层级对跨任务的执行过程进行切面处理。工作流的引入，对于AOP的使用带来了很多困难，例如使用 AOP 实现的日志、特定的验证和数据包装等，原先很简单的一个实现方式，现在变得非常复杂。
单一的应用 BPMN 会存在一些局限，复合使用则略显复杂
结合 CMMN、DMN 进行业务的支持
BPMN 强调的是流程与固定步骤的执行，CMMN 强调的是事件驱动的动态案例执行，DMN 侧重于流程中的决策的汇总与整合。
举例：
家具厂生产家具，生产橱柜和沙发，橱柜和沙发的生产流程都是固定的，使用 BPMN 来解决橱柜生产和沙发生产的流程是合适的。而如果将完成生产订单的业务整体来建模，则生产橱柜和沙发的流程对于一个订单来说，可能不存在严格的先后顺序，更多的是基于事件和决策的执行，比如当订单客户有客制化要求，或者原材料供应商是否能够按时供应等等。使用 BPMN 中的并行网关+事件处理也能完成业务建模，但可能导致模型复杂。
BPMN 的事务处理
与数据库事务的比较
单个任务执行过程是一个传统数据库事务，整个流程是一个长活事务。而且整个流程的事务表现上更具有明显的分布式事务的特征。其中事务失败回滚补偿机制的问题需要进行更多考虑，这也是我们讨论分布式事务时的 Saga 模式：
Saga 模式
1987年普林斯顿大学的 Hector Garcia-Molina 和 Kenneth Salem 发表了一篇 Paper Sagas，讲述的是如何处理 long lived transaction（长活事务）。Saga 是一个长活事务可被分解成可以交错运行的子事务集合。其中每个子事务都是一个保持数据库一致性的真实事务。
Saga 的组成及执行顺序
- 由一系列 sub-transaction Ti 组成
- 每个 Ti 都有对应的补偿动作 Ci，补偿动作用于撤销 Ti 造成的结果
执行顺序为下列两种情况的任意一种，其中
Saga定义的两种恢复策略：
- backward recovery，向后恢复，补偿所有已完成的事务，如果任一子事务失败。即上面提到的第二种执行顺序，其中j是发生错误的 sub-transaction，这种做法的效果是撤销掉之前所有成功的 sub-transation，使得整个 Saga 的执行结果撤销。
- forward recovery，向前恢复，重试失败的事务，假设每个子事务最终都会成功。适用于必须要成功的场景，执行顺序是类似于这样的：T1, T2, ..., Tj(失败), Tj(重试),..., Tn，其中 j 是发生错误的 sub-transaction。该情况下不需要Ci。
总结
- 了解了 BPM 及 BPMN 的概念，并对于BPMN能够做些什么有了一个大致的概念；
- 基于BPMN 标准的流程引擎优缺点分析对比；
- 工作流引擎的使用场景；
- 使用 BPMN 及工作流引擎来处理业务流程的优缺点。