背景
工作流是应用开发平台的重要组成部分，用来实现业务系统的流程处理功能。
一般来说，包括三部分，一是工作流引擎，二是流程建模，三是衍生辅助，包括发起流程、我的待办、我的已办、结束单据等。
2020年技术选型
这是一块需求高度确定的领域，因此有相应的技术组件，在2020年的时候，进行过技术预研，主要是jbpm和activiti以及由activiti分裂产生的flowable和camunda分支，梳理的发展脉络大致如下：
起源：jBPM3是一个完整的工作流系统实现，面向开发人员。
**发展：**jBPM4引入PVM，使其拥有更强大的扩展性，同时增加BPMS特性，这些特性包括了对BPMN的支持、面向业务人员的Web建模器和简单统计分析功能的加入。
分裂：
1.JBPM的主创人员Tom Baeyens与合作伙伴在JBPM的未来架构上产生了重大分歧，于是Tom离开了Jboss并加入了Alfresco公司，沿用jBPM4代码，创立了Activiti5。Activiti5基于jBPM4的开源工作流系统，与Alfresco的集成增加了其流程可视化与管理能力，同时通过创新的Activiti Cycle协作组件支持流程相关人员之间的协调，加强了集成能力。
2.Jboss公司完全抛弃了JBPM4的架构，基于Drools Flow进行彻底重构，推出了JBPM5。支持BPMN，通过与Drools的合并支持BAM，通过内容仓库增加对流程可视化的支持。由于放弃了jBPM4的PVM，引擎的可扩展性受到损害，并且不再支持jPDL。
裂变
- Activiti最大的贡献者之一的公司Camunda表示Activiti可能太拘束于Alfresco对以文档为中心的工作流的需求，而忽视了Activiti起步时的更为普遍的BPM平台。camunda宣布他们正从Activiti 分裂出一个新的开源工程，那就是camunda BPM.
- Activiti的原班核心人马，由于与Alfresco公司在项目的未来发展方向上出现分歧，于是选择集体出走，创建了Flowable。
- activiti自身发展缓慢，Activiti这几年止步不前，开始吃老本。对于新出的CMMN/DMN两个新规范以及BPMN更多的规范，Camunda框架已经率先响应并支持了，而Activiti5还是不能支持这些规范的，导致流失很多用户，很多用户转向了Camunda阵营。activiti6以及activiti5的代码官方已经宣称暂停维护了。activiti7就是噱头 内核使用的还是activiti6，并没有为引擎注入更多的新特性，只是在activiti之外的上层封装了一些应用，往云方向发展。6.0版本据说留了大量框架级bug，而在flowable中进行了修复。
从各方面收集的资料来看
activiti优于jbpm，jbpm首先出局
flowable优于activiti，即activiti也不再考虑
flowable与camunda之间，能查到资料是camunda更好一些，但缺乏多资料交叉印证。
资料1：
从多个维度对比，camunda优于flowable
https://blog.csdn.net/qq_30739519/article/details/86682931
资料2：
flowable以6.4.1版本为分水岭，大力发展其商业版产品。开源版本维护不及时。部分功能已经不再开源版发布，比如表单生成器（表单引擎）、历史数据同步至其他数据源、es等等。dmn目前是个半成品，没有camunda稳定和好用，对于dmn规范支持薄弱。部分商业版的组件被商业化，因此开源版不再维护。Mongdb目前也放到商业产品中了，开源版的几乎不能用。（来源：https://blog.csdn.net/qq_30739519/article/details/
基于上述情况，activiti主分支已落寞，在camunda和flowable这两个分支中选择了前者。集成原生工作流引擎工作量很大，当时投入了几个月，实现了主要功能，效果不是很满意，以下是当时进行集成开发的设计清单。
后端工作流引擎集成，对我而言完全不是问题。最大的问题在于前端基于bpmn2.0的建模，一方面，前端建模组件自身复杂，且资料模糊，很难拿到需要的方法和数据实现功能，反复尝试耗时很长，最终有部分功能采取了后端处理的方式来间接解决；另一方面，activiti（camunda）是一个大而全的组件，定义了流程处理的方方面面，因此流程建模时有大量配置需要设置，包括一些相对晦涩的名称和概念，对建模用户特别是国内用户并不友好。
印象中比较深的是条件边设置，需要流程建模时，选中条件边，然后在表单窗体上，输入表达式，如${contractMoney}>100 0000，友好性差，易出错。
当下技术选型
时隔三年，再次重启工作流的集成工作，首先还是需要技术预研，看看这几年是不是有了新的变化，有了更好的选择。
简单看了下近况，activiti的最新的大版本依旧是7，flowable还是6。
至于camunda，我查了下，之前集成使用的是7.13，现在有了8，但是，8更换了新的流程引擎Zeebe，不再是activiti那一套。市面上最多的依旧是基于comunda7或flowable6进行的二开。
找到一篇今年3月31日发布的文章，《activiti5、activiti6、activiti7、flowable、camunda7、camunda8流程引擎对比分析和选型参考》（https://blog.csdn.net/wxz258/article/details/129884545），
结论如下：
简单总结：国内需要私有化部署流程引擎的用户建议选择camunda7，大部分组件开源，可免费使用，技术生态较好，程序员上手容易。如果对流程自动化和高并发有显著需求的客户，可以考虑选择camunda8，但需要大量扩展定制开发，对技术团队能力要求较高。国内主流的云程低代码平台使用了camunda7作为流程引擎，目前camunda7在国内也逐步流行起来，有超越activiti和flowable的势头。
另一条路子是国产自研，拿出来开源的极少，有家做的年份比较久了，济南驰骋的JFlow（https://gitee.com/opencc/JFlow?_from=gitee_search），遗憾的是vue3的版本使用的是Ant UI库而不是Element Plus，并且还没有开源，H5的版本虽然也能用，但使用的是老的jquery和layui，如果引入到我的平台中，太重了。
另外一家是https://gitee.com/gailunJAVA/dingding-mid-business-java?_from=gitee_search，这位老兄专注于工作流领域，对activiti、camunda、flowerable都比较熟，提供各版本的支撑，主要做后端，前端主要是其他开源项目来支撑。
技术方案选择
在进行技术预研的过程中，技术实现思路得到了启发。主要是找到了仿照钉钉流程建模的开源项目（https://github.com/StavinLi/Workflow-Vue3），技术栈采用的也是vue3+element plus，与当前我的平台一致，实现效果如下：
这种模式，相比于camunda自带的基于bpmn2.0规范的流程建模要简洁直观方便多了。
使用它作为流程建模的替代，面临的主要问题，就是如果把上面这个组件输出的json，解析后转换为bpmn协议约定的数据格式。这块自己来实现，通过调用camunda的API来实现转换。
以上方案选择，是综合考虑了各种因素，基于平台现有的前端技术栈（vue3+Element Plus），以及之前投入几个月的camunda后端集成实现，并提供给流程建模人员友好的UI和体验，最终决定的。
工作流是一个大组件，平台集成涉及到大量的开发，接下来开一个集成的子分类，依旧是每周一篇的节奏，敬请期待。
开发平台资料
平台名称：一二三开发平台
简介： 企业级通用开发平台
设计资料：csdn专栏
开源地址：Gitee
开源协议：MIT
开源不易，欢迎收藏、点赞、评论。