Spring Boot + BPMN流程管理引擎实践
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档
Spring Boot + BPMN流程管理引擎实践
- 前言
- 一、什么是BPMN？
-
- 1. BPMN标准及其核心组件介绍
- 2. 为什么要使用BPMN？
- 二、BPMN框架介绍及对比
- 三、Camunda框架介绍
- 四、Spring Boot + Camunda集成实践
- 五、TODO List
- 六、References
前言
本文首先介绍了BPMN基本概念以及为什么要引入BPMN；接着对实现了BPMN标准的开源框架进行了简单介绍和对比；然后重点介绍了Camunda BPMN框架的核心概念、框架及最佳开发实践，同时基于Spring Boot框架结合实际业务场景对Camunda的应用进行了介绍；最后是对于流程引擎集成到业务系统的一些注意事项说明。
以下是本篇文章正文内容，参考博客都加了引用说明，如有侵权请联系我删除
一、什么是BPMN？
1. BPMN标准及其核心组件介绍
BPMN：Business Process Model and Notation，是国际对象管理组织（OMG）基于BPMI在2011年推出的业务流程建模与标记开放标准。如果对OMG和BPMN的理解还不够直观，另外一个同组织同类型的标准----UML，可能会让你更加清楚OMG及其发布的开放标准是什么。以下是OMG官网关于BPMN介绍的两个截图：
BPMN框架概念介绍：
流对象
它们会展示业务流中的行为，并包含以下内容：
活动：人员或系统执行的工作或任务（显示为圆角矩形）。
事件：流程中发生的事情：开始、中间和终止（以圆圈表示）。
网关：描述流程中的顺序流路径（以菱形表示）。其他细节可以包括决策点。
数据对象
数据对象可以提供流程中数据的信息。数据有四种表现方式：
数据输入是与数据相关的任务（以一个卷角页面和右箭头表示）。只有收集到具体数据才能继续往前推进。
数据输出用于显示流程何时生成数据（以一个卷角的页面和实心右箭头表示）。
数据收集（显示为一个卷角的页面，底部中心带有三条实线）是指流程中所需的任何数据收集行为（例如，调查）。
数据存储（显示为容器），用于存储从流程中收集的任何数据。
连接对象
它们将流对象相互连接，或连接至其他信息，并显示流程：
顺序流（以实心右箭头表示）描述了所执行活动的顺序。
消息流（以左侧带有圆圈的虚线右箭头表示）描述了参与者之间的消息流动和流向。
关联（显示为虚线）可以将文本和人工信息链接到事件。
泳道
这个术语代表“池”和“道”。
池：单个流程的“容器”。
道：将池里面的活动再细分成几个部分，可以是垂直的也可以是水平的，以显示职责和事件的位置。
人工信息
人工信息提供了流程的额外细节。它分为两种类型：
组：以虚线的圆角矩形表示，它们围绕一组元素来显示元素之间的关系。
文本注释：只是简单的备注（前面带有一个左括号），读者无需深入查看就可以轻松了解内容，也称为注解。
2. 为什么要使用BPMN？
在不使用BPMN时，如何实现流程控制：
在业务代码里面加入 Status（状态机） 字段维护流程状态，流程负责的审批人可能也是 Hard Code（硬编码），好处是实现流程刚开始会比较快，但是长远来看会出现几个问题：
- 流程健壮性差，但凡出现人员变动，或者组织结构调整，就需要修改代码，维护成本高
- 定制化开发，流程无法复用，当组织出现新的工作流程，又要重新写一套代码，开发成本非常高
- 流程和业务代码耦合，你中有我，我中有你（并不符合单一职责和解耦的设计原则），业务流程发送变化时，修改成本高
使用BPMN后：
4. 业务逻辑可视化，开发成员内部以及客户沟通无障碍，利于发现流程缺陷、洞察待改善的潜在领域及促进业务理解一致；
5. 同一组织架构或者同类业务模型可高质量复用，提高开发效率同时提升软件质量；
6. 从设计层面对系统架构进行解耦：流程引擎可以和技术栈无关；
7. 有行业规范，遵循行业标准，有较多成熟框架和工具支持，随着项目中使用的工作流越多，集成BPMN的效用和收益会累计越多
比如说一个业务部门，需要做很多子系统，而这些子系统的办事审批流程以及用户组织架构都是一样的，如果在系统开发初期就引入了流程管理引擎，那么后续子系统开发过程中涉及到流程审批的功能开发工作量都将大大减少，同时系统应对审批流程变更需求的能力也会更强，在流程设计得足够完备、流程子节点代码块执行足够原子性的情况下，我们可以做到在不修改代码的情况下适配新的审批需求。
二、BPMN框架介绍及对比
- BPMN引擎框架
基于BPMN开放标准，有较多成熟的开源或商业技术框架。总的来说有如下几类：
基于JBPM4
Jbpm：Jboss开发，基于Drools Flow，技术框架较陈旧（如使用Hibernate进行持久化）国内使用较少；
Activiti：版本分支较多，Activiti 6遗留较多BUG，Activiti 7也是云原生；
Flowable：Activiti 6衍生版本，商业版功能强大，开源版本功能较受限；
Camunda：基于Activiti 5，开源版本的性能、功能与云原生架构，具有很大优势；
Osworkflow：基于状态机机制的流程引擎，适用于简单流程；
下面摘抄一段大牛的总结：
Activiti和Flowable都是来自于一个叫JBPM的开源工作流。在早期Jboss(现已被ReHat收购)发行JBPM4的时候，因为合作伙伴关系闹的不开心。于是其中一个核心人员离职。加入了Alfresco(Activiti所在的公司)。并在同一年发布了Activiti的第一个版本即Activiti5.0.alpha1。这个版本号直接从5.0开始就很有意思了。表示其为携带了JBPM4的所有特性。正式叫板JPBM4。JBPM4也是被使用的最广的一个版本之一其中正有我的老东家(工作流只是个辅助业务的，我老东家在上面自己做了很多东西，故升级版本是不现实的)。也在同一年，Jboss对JBPM4进行了重构，使用了自己公司新研发的一套规则引擎Drools进行重构。将JBPM4升级到了JBPM5。但是那时候国内更多软件基于Tomcat上进行部署，JBoss所用甚少。故JBPM后续版本在国内占据市场远远不如Activiti。Activiti就一直在5.0这个版本一直迭代开发。 国外的开源软件有个好习惯就是：在当前开发的这个版本趋于稳定的时候，会开始陆陆续续构建下一个大版本。Activiti那时候也想的很美好。5.0这个版本这么稳定了，6.0应该没什么问题。但是，天要下雨，娘要嫁人。Activiti的创作者，也因为和合作伙伴关系闹的不开心。又一次上演了离家出走，先后开办了Camunda和Flowable。导致了Activiti最后5.0的问题修复不过来了，官方放弃了这个版本。但是Activiti5可以说的上在工作流的标杆版本之一。至今仍被N多公司进行使用。工作流毕竟只是一个辅助业务的东西，故版本的大升级对于一个公司来说，是代价巨大的。Flowable在开办之初，比Activiti当初直接继承JBPM的版本更为直接。直接继承了他的小版本。直接就从Flowable5.22这个版本开始。和当时的Activiti的小版本一致。
最终：activiti6据说是遗留了很多BUG，然后已经不怎么维护了，团队重点在维护云原生的activiti7的版本，flowable基于activiti6做了很多修复和扩展，所以选择flowable
-
BPMN建模工具介绍
bpmn-js：BPMN 2.0 渲染工具包和 Web 模型。基于web和原生js开发，支持Vue和React集成
mxGraph：强大的JavaScript流程图前端库，可以快速创建交互式图表和图表应用程序，国内外著名的ProcessOne和draw.io都是使用该库创建的强大的在线流程图绘制网站
Activiti-Modeler：Activiti 开源版本中带了web版流程设计器，在Activiti-explorer项目中有Activiti-Modeler，优点是集成简单，开发工作量小，缺点是界面不美观，用户体验差。
flowable-modeler：flowable开源版本中带了web版流程设计器，展示风格和功能基本跟Activiti-Modeler一样，优点是集成简单，开发工作量小，缺点是界面不美观，用户体验差。
easy-flow
Eclipse插件bpmn2-modeler：C/S版本的流程设计器，如果没有强调基于浏览器设计流程图，也可以考虑Eclipse插件版流程设计器bpmn2-modeler。 -
简单BPMN示例
三、Camunda框架介绍
- 核心概念
Process Definition（流程定义）
即通过Camunda Modeler工具建模BPMN（流程）、DMN（决策）、Form（表单）等，可以将设计好的流程等保存成对应格式*.bpmn、*.dmn, 、*form文件，最后需将流程文件部署到对应的工作流平台。
Process Deployment（流程部署）
即将之前流程定义的成果物（.bpmn、.dmn, 、*form）部署到工作流平台，即将流程定义持久化到工作流平台后端的的RMDB中。后续Process Engine即可到RMDB中读取并解析处理相应的流程。
Process Engine（流程引擎）
即Camunda提供的一个Jar包，用于集成到Process Application中，可以理解为Process Engine为一系列与流程处理相关的Service集合，用于解析BPMN、CMMN、DMN并执行相关流程，且Process Engine需要连接指定的流程持久化RMDB。Process Engine封装了流程处理相关的service、dao、db相关实现，使用Process Engine统一了流程处理的相关操作，也可避免开发者再重复定义这些操作。
Process Application（流程应用）
即使用Process Engine的Java应用，这些应用可以内嵌Process engine、集成运行时容器的shared proceess engine。Process Application可以：（1）启动内嵌的Process engine 或 集成运行时容器的shared proceess engine（2）自动部署流程定义（3）通过ProcessEngine解析并执行流程相关操作（4）作为Process Engine的Java代理实现（即流程定义中可以调用本地Java实现）（5）通过resource/META-INF/process.xml定义多个Process Engine、多个自动部署资源
Process Variables（流程变量）
即在启动流程、流程表单中传递（task间传递）的变量及其值
Process（流程）
将流程定义部署后即对应一个流程
Process Instance（流程实例）
启动后（运行）的流程即对应一个流程实例
Task（任务）
流程实例中的某个待执行的任务即task - Camunda 8 VS Camunda 7
- Camunda 8 本地安装
需要适配JDK版本：
如果本地JDK版本不匹配，需要安装JDK18，同时在相应的bat文件中指定jdk环境
set JAVA_HOME=C:\Users\yxiao\Documents\applications\jdk-18.0.1.1
set CLASSPATH=.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOMe%\lib\tools.jar
set Path=%JAVA_HOME%\bin
根据本机配置修改地址和端口配置：Camunda相关组件都是基于Java开发，可以通过修改YML配置文件来修改相关运行参数 - Camunda Modeler
使用Camunda官方的Modeler进行流程建模，建模完成后可以直接部署到zeebe，然后再手动发起一个流程实例，通过operate就可以观察到这个流程实例的执行状态，这样在业务系统不用跑起来的情况下，可以对流程进行调试，非常方便
- Camunda Operate
结合Camunda Modeler，可以方便的发起流程、查看流程状态、修改流程变量，但是Operate不是开源产品，需要商业授权，只能在本地开发调试阶段用用。
四、Spring Boot + Camunda集成实践
Camunda官方文档相当强大，对于流程引擎和业务系统的集成，官方已经给出了几个典型的业务场景和最佳实践，大家可以根据自己的业务场景选择集成架构。
通用架构
标准的业务流程解决方案
最佳实践 - 1
最佳实践 - 2
最佳实践 - 3
最佳实践 - 4
-
业务系统集成流程引擎的基本步骤
-
业务流程建模
-
用户操作与流程状态判断JavaScript代码
使用流程引擎的一大好处就是：不需要将流程状态判断写死到业务代码中，我们可以使用轻量级脚本代码去做状态处理。其好处在于解耦具体业务代码，修改起来非常简单。
-
Spring Boot中引入Camunda依赖及配置
-
Spring Boot中引入BPMN描述文件
-
RestFul接口中发起流程实例
-
业务系统与流程引擎交互 - Service Task保存引擎脚本计算结果
至此，Spring Boot集成Camunda实现BPMN流程管理即集成完毕。总的来说，Camunda的集成过程类似于我们使用Rabbit MQ的过程：提供Camunda Server的配置信息、引入自定义的流程描述文件、业务操作触发一个流程实例、监听流程实例处理状态变更消息（如有必要）对流程实例处理结果进行存储或其他操作。实际流程建模过程会花费较多工作量，至少第一次为组织建模时会多次改版。以下是我建模的结果，实际改了20余版:)
-
基于Spring Boot集成Camunda 8的典型架构
五、TODO List
实际应用过程中，我觉得有以下几个点需要考虑：
- 规划流程：这是集成的开始，如果要在业务系统中集成流程引擎，首先是要对流程进行规划，同时也要随着规划进行不断对流程进行改进。
- 已结束的流程还要唤醒？流程结束点是否定义得不对？
- 如何处理越级审批问题？
- 如何处理重复审批动作
- 批量审批或者误操作时对已审批的流程再次触发了审批操作
- 审批结果异步返回，用户如何实时查看审批结果？
- 如上一步用户重复审批时，接口会返回操作成功，用户界面也提示“审批通过”，但是实际上用户的动作没有对申请的状态产生影响，而这个提示会对用户造成误导，如何处理？
- 流程审批过程中的错误处理：应该回到起点还是回到上一节点？数据状态如何同步？
- 流程审批过程如何结合业务系统的用户权限、数据查看范围等内容？
最后是一点讨论：如果基于Camunda流程引擎，开发一个低代码管理平台，需要做哪些改进？
- 扩展中国特色流程操作功能
开源流程引擎默认就是基于节点连线进行流程流转，没有其它流程操作功能。需要增加中国特色流程操作功能，包括：办理、加签、减签、跳转、退回申请人、退回上一步、任意退回、委托、转办、传阅、催办、收回、撤销等，这些功能配置即生效，无需编码。 - 重新开发组织用户模型
camunda自带的用户组织模型很简单，无法适用中国企业组织架构，需要扩展了多组织用户模型，多组织架构、一人多岗、一人多部门、兼职部门等。 - 重新开发电子表单功能
camunda自带电子表单过于简单，仅仅是一个单表，字段按顺序排列显示，没有布局，没有扩展事件等功能，无法满足企业复杂业务需求，需要扩展了电子表单功能。 - 扩展流程配置选人规则
Camunda自带的流程审批人配置仅仅有user和group，无法满足中国企业复杂的选人需求，需要扩展流程多维度配置选人规则，包括：用户、部门、岗位、角色、关系等多种选人规则，尤其关系动态规则，审批类流程应用最多。 - 重新开发流程门户界面
Camunda自带的流程门户页面，包括发起流程、待办任务，流程审批，流程跟踪等功能，基本上不符合中国人操作习惯，以及对UI界面的审美需求，这部分前端界面均需要重新开发。 - 增加流程监控管理功能
Camunda开源版本功能较为简单，流程监控管理功能在Camunda商业版上才有，我们基于开源版本需要自行扩展流程管理监控的功能，包括：流程实例管理功能，方便管理员后台管理流程：增加办理人、减少办理人、流程删除、流程挂起等；流程分析功能：流程模板统计分析、任务办理统计分析、流程超时统计分析、流程实例统计分析。 - 完善流程设计器配置化功能
优化了流程设计器，camunda大部分手动输入项改成界面配置功能，提升流程设计效率，配置功能包括：流程选人、表单配置、按钮权限、流转规则、字段权限、超时流转、任务提醒、待办标题、启动权限等。 - 增加对国产数据库的适配
Camunda默认支持mysql\oracle\pg等主流的数据库，但对信创国产数据库（达梦、人大金仓、神州通用等）没有支持，我们需要按需求增加对国产数据库的适配，这部分需要修改Camunda进行扩展开发。
六、References
- https://www.bpmnquickguide.com/view-bpmn-quick-guide/
- Spring Boot Integration | docs.camunda.org
- GitHub - camunda-community-hub/zeebe-script-worker: Zeebe worker for script evaluation
- GitHub - camunda-community-hub/spring-zeebe: Easily use the Zeebe Java Client in your Spring or Spring Boot projects
- Local installation | Camunda Platform 8
- Overview | Camunda Platform 8
- 各种开源协议介绍 | 菜鸟教程 (runoob.com)
- flowable与camunda性能对比测试_大龄码农有梦想的博客-CSDN博客_flowable和camunda
- Camunda入门（一） - 选型及核心概念_罗小爬EX的博客-CSDN博客_camunda
- 开源流程引擎该如何选择flowable还是camunda？_大龄码农有梦想的博客-CSDN博客_camunda flowable 对比
- 开源流程引擎camunda需要扩展哪些功能_大龄码农有梦想的博客-CSDN博客_流程引擎功能
- https://zhuanlan.zhihu.com/p/430500045