1. 名词解释#
1.1. BPM Business Process Management，业务流程管理，“通过建模、自动化、管理和优化流程，打破跨部门跨系统业务过程依赖，提高业务效率和效果”。 1.2. BPMN Business Process Modeling Notation，业务流程建模与标注，包括这些图元如何组合成一个业务流程图（Business Process Diagram）；讨论BPMN的各种的用途，包括以何种精度来影响一个流程图中的模型；BPMN作为一个标准的价值，以及BPMN未来发展的远景。 1.3. BPEL Business Process Execution Language，意为业务过程执行语言，是一种基于XML的，用来描写业务过程的编程语言，被描写的业务过程的每个单一步骤则由Web服务来实现。 1.4. XPDL XML Process Definition Language,是由Workflow Management Coalition（简写为：WfMC）所提出的一个标准化规格，使用XML文件让不同的工作流程软件能够交换商业流程定义。XPDL被设计为图形上和语义上都满足交换用的商业流程定义，是描述BPMN图的最佳文件格式。BPEL也可以描述商业流程。但是XPDL不仅包含流程执行的描述，还包括了元素的图形信息，更适于商业流程建模。 1.5. JPDL JBoss jBPM Process Definition Language，是构建于jBPM框架上的流程语言之一。在jPDL中提供了任务（tasks）、待处理状态 （wait states）、计时器（timers）、自动处理（automated actions）等术语，并通过图型化的流程定义，很直观地描述业务流程。 1.6. PVM Process Virtual Machine，流程虚拟机，他的设计初衷是通过实现接口和定制插件等方式兼容多种流程定义语言和流程活动场景，为所有的业务流程定义提供一套通用API平台。那么，无论是需要对jBPM 原有流程定义语言进行扩展，或者重新实现一套专用的流程定义语言，都可以通过实现 PVM 指定的接口规范完成。 PVM是在JBPM4的时候被纳入的，activiti5沿用，activiti团队在activiti6就已经移除了，ActivitiImpl, ProcessDefinitionImpl, ExecutionImpl, TransitionImpl 都不可用了。所有的流程定义有关的信息都可以通过BpmnModel来获得，通过org.activiti.engine.impl.util.ProcessDefinitionUtil来拿到BpmnModel。 工作流中，由于flowable是基于activiti6开发的，所以代码中也没有PVM，Camunda基于activiti5开发的，所以PVM还在，这个核心引擎没有绝对的好坏之分。 1.7. DMN Decision Model and Notation，DMN的目的是提供一个模型决策结构，从而使组织的策略可以用图形清晰的地描绘出来，通过业务分析准确的定义，使其自动化（可选地）。 1.8. CMMN Case Management Model and Notation，CMMN是一种图形化的符号，用于捕获工作方法，这些工作方法基于处理需要各种活动的情况，这些活动可能以不可预测的顺序执行，以响应不断变化的情况。通过使用以事件为中心的方法和案例文件的概念，CMMN扩展了可以用BPMN建模的边界，包括结构化程度较低的工作和由知识工人驱动的工作。结合使用BPMN和CMMN，用户可以涵盖更广泛的工作方法。 #
- 主流开源工作流程引擎
2.1 Osworkflow
Osworkflow是一个轻量化的流程引擎，基于状态机机制，数据库表很少，Osworkflow提供的工作流构成元素有：步骤（step）、条件（conditions）、循环（loops）、分支（spilts）、合并（joins）等，但不支持会签、跳转、退回、加签等这些操作，需要自己扩展开发，有一定难度，如果流程比较简单，osworkflow是很好的选择，但该开源组件已过时，长时间没有版本升级了。
2.2 JBPM
JBPM由JBoss公司开发，目前最高版本JPBM7，不过从JBPM5开始已经跟之前不是同一个产品了，JBPM5的代码基础不是JBPM4，而是从Drools Flow重新开始，基于Drools Flow技术在国内市场上用的很少，所以不建议选择jBPM5以后版本。 jBPM4诞生的比较早，后来JBPM4创建者Tom Baeyens离开JBoss后，加入Alfresco后很快推出了新的基于jBPM4的开源工作流系统Activiti，另外JBPM以hibernate作为数据持久化ORM也已不是主流技术，现在时间节点选择流程引擎，JBPM不是最佳选择。
2.3 Activiti
activiti由Alfresco软件开发，目前最高版本activiti 7。activiti的版本比较复杂，有activiti5、activiti6、activiti7几个主流版本，选型时让人晕头转向，有必要先了解一下activiti这几个版本的发展历史。
activiti5和activiti6的核心leader是Tijs Rademakers，由于团队内部分歧，在2017年时Tijs Rademakers离开团队，创建了后来的flowable，activiti6以及activiti5代码已经交接给了 Salaboy团队。
activiti6以及activiti5的代码官方已经暂停维护了，Salaboy团队目前在开发activiti7框架，activiti7内核使用的还是activiti6，并没有为引擎注入更多的新特性，只是在activiti之外的上层封装了一些应用。
结论是activiti谨慎选择。
2.4 flowable
flowable基于activiti6衍生出来的版本，flowable目前最新版本是v6.6.0，开发团队是从activiti中分裂出来的，修复了一众activiti6的bug，并在其基础上研发了DMN支持，BPEL支持等等，相对开源版，其商业版的功能会更强大。
以flowable6.4.1版本为分水岭，大力发展其商业版产品，开源版本维护不及时，部分功能已经不再开源版发布，比如表单生成器（表单引擎）、历史数据同步至其他数据源、ES等。
Flowable 是一个使用 Java 编写的轻量级业务流程引擎，使用 Apache V2 license 协议开源。2016 年 10 月，Activiti 工作流引擎的主要开发者离开 Alfresco 公司并在 Activiti 分支基础上开启了 Flowable 开源项目。基于 Activiti v6 beta4 发布的第一个 Flowable release 版本为6.0。
Flowable 项目中包括 BPMN（Business Process Model and Notation）引擎、CMMN（Case Management Model and Notation）引擎、DMN（Decision Model and Notation）引擎、表单引擎（Form Engine）等模块。
2.5 Camunda
Camunda基于activiti5，所以其保留了PVM，最新版本Camunda7.15，保持每年发布2个小版本的节奏，开发团队也是从activiti中分裂出来的，发展轨迹与flowable相似，同时也提供了商业版，不过对于一般企业应用，开源版本也足够了，强烈推荐camunda流程引擎，功能和性能表现稳定。
选择camunda的理由： 1）通过压力测试验证Camunda BPMN引擎性能和稳定性更好。 2）功能比较完善，除了BPMN，Camunda还支持企业和社区版本中的CMMN（案例管理）和DMN（决策自动化）。Camunda不仅带有引擎，还带有非常强大的工具，用于建模，任务管理，操作监控和用户管理，所有这些都是开源的。
2.6 JFlow
前身ccFlow，国产的工作流引擎，由济南驰骋公司开发维护，主打中国式的业务流程，由于是国产的软件，中文化程度比较深，业务开发也对用户比较友好。国产的开源工作流引擎还是挺多的，JFlow是其中功能比较完善的一个，同时对比activiti，流程上更加中国化，支持自定义流程跳转，加签等。其他国产工作流就不列举了。
2.7 其他
还有很多工作流，比如ProcessMaker，SWF，oracle，Bonita，openwebflow，snaker等，不过做BPM的话，相对于上面列举的产品还是有些缺陷，比如流程过于简单，资料过少等。
3.1 对比表格
Camunda、Flowable和Activiti都是开源的工作流引擎，它们在功能方面有许多相似之处，但也有一些差异。以下是它们在功能方面的主要对比：
1、流程设计与建模 l Camunda：提供了独立的Modeler设计器，支持BPMN 2.0、CMMN和DMN标准，用于绘制和编辑流程模型。Camunda的Modeler既面向业务人员又面向开发人员，具有良好的用户体验。 l Flowable：Flowable也提供了基于Eclipse的插件设计器，但相对于Camunda的Modeler来说，其功能和用户界面可能稍显简单。Flowable的设计器主要面向专业开发人员。 l Activiti：同样提供了基于Eclipse的插件设计器，支持BPMN 2.0规范。然而，随着版本的迭代，Activiti的设计器可能在功能和易用性方面与Camunda和Flowable有所差距。 2、流程执行与任务管理 l 这三个引擎都提供了强大的流程执行和任务管理功能，包括流程的启动、挂起、恢复、终止等操作，以及任务的分配、认领、完成等功能。 l Camunda：在流程执行方面，Camunda支持流程实例的迁移，允许将运行中的流程实例从一个版本迁移到另一个版本。此外，Camunda还提供了丰富的API和插件机制，使得开发者可以轻松地扩展和定制流程执行和任务管理功能。 l Flowable：Flowable也对Activiti的代码进行了大量的重构和优化，提供了更高效的流程执行和任务处理性能。Flowable还支持异步执行、多实例任务等特性。 3、事件与监听器 l 这三个引擎都支持事件和监听器机制，允许开发者在流程执行过程中的关键节点上注册自定义的监听器，以处理特定的事件或执行自定义的逻辑。 l Camunda：Camunda提供了丰富的事件类型和监听器接口，使得开发者可以灵活地处理各种流程事件。 l Flowable：Flowable在事件处理方面也进行了优化和改进，提供了更简洁和易用的API。 4、表单与数据管理 l 这三个引擎都支持流程表单的管理，允许用户在流程执行过程中填写和提交表单数据。 l Camunda：Camunda提供了强大的表单管理功能，支持自定义表单和动态表单的渲染和提交。此外，Camunda还支持多租户模式和分布式部署等特性，以满足不同用户的需求。 l Flowable：Flowable也注重表单管理的易用性和灵活性，提供了直观的表单设计器和表单数据绑定机制。 5、历史与数据分析 l 这三个引擎都支持流程历史和数据分析功能，允许用户查询和分析已完成的流程实例和任务的数据。 l Camunda：Camunda提供了丰富的历史数据查询和分析API，以及可视化的流程分析工具和优化建议功能。此外，Camunda还支持复杂事件处理（CEP）和决策自动化等高级特性。 l Flowable：Flowable也提供了强大的历史数据查询和分析功能，支持自定义的查询条件和结果展示方式。 6、外部集成与扩展性 l Camunda：由于其强大的API和插件机制，Camunda能够很好地与外部系统集成，例如与Spring框架集成、REST API集成等。这使得Camunda可以轻松地嵌入到现有的企业应用架构中。 l Flowable：Flowable也提供了良好的扩展性，特别是它基于Activiti的优化和改进使得在集成方面更为顺畅。Flowable同样支持REST API和Spring集成。 l Activiti：虽然Activiti也提供了与外部系统集成的可能性，但随着其核心团队的变动和项目的发展，一些集成可能不如Camunda和Flowable来得直接和高效。 7、 用户界面与操作体验 l Camunda：Camunda提供了Web-based的管理界面，包括Cockpit（用于实时监控）、Tasklist（用于任务管理）和Admin（用于系统配置和管理）。这些界面直观且用户友好。 l Flowable：Flowable同样提供了Web-based的用户界面，包括流程设计器、任务管理和系统配置等功能。不过，在用户体验方面，Flowable可能稍逊于Camunda。 l Activiti：Activiti的用户界面相对基础，主要集中在流程设计和管理上。随着项目的发展，一些用户界面相关的功能可能没有得到及时更新。 l 总的来说，Camunda、Flowable和Activiti在功能方面都有各自的优势和特点。Camunda注重流程的灵活性和可扩展性，提供了丰富的API和插件机制；Flowable注重流程的易用性和性能优化；而Activiti则以其起源早、社区活跃和广泛的应用而知名。在选择时，可以根据项目的具体需求、团队的技术能力和偏好以及商业支持和服务等因素进行综合考虑。
3.2 Flowable 和 Camunda 功能对比
由于Flowable与Camunda都起源于Activit，好多功能都是类似的，因此在这里重点罗列差异化的功能
- camunda支持流程实例的迁移，比如同一个流程有多个实例，多个流程版本，不同流程实例运行在不同的版本中，camunda支持任意版本的实例迁移到指定的流程版本中，并可以在迁移的过程中支持从哪个节点开始。
- camunda基于PVM技术，所以用户从Activit5迁移到camunda基本上毫无差异。flowable没有pvm了，所以迁移工作量更大（实例的迁移，流程定义的迁移、定时器的迁移都非常麻烦）。
- camunda对于每一个CMD命令类都提供了权限校验机制，flowable没有。
- camunda基本每一个API都有批处理的影子，flowable几乎没有。比如批量挂起流程、激活流程等，使用camunda可以直接使用API操作，使用Flowable则只能自己去查询集合，然后循环遍历集合并操作。
- camunda很多API均支持批处理，在批量处理的时候可以指定是异步方式操作或者是同步方式操作。异步的话定时器会去执行。Flowable没有异步批处理的机制。比如批量异步删除所有的历史数据。
- camunda启动实例的时候支持从哪个节点开始，而不是仅仅只能从开始节点运转实例。Flowable仅仅只能从开始节点运转实例。
- camunda支持任意节点的跳转，可以跳转到连线也可以跳转到节点，并且在跳转的过程中支持是否触发目标节点的监听器。flowable没有改原生API需用户去扩展。
- camunda支持双异步机制，第一个异步即节点可以异步执行，第二个异步方式是：完成异步任务后，还可以继续异步去执行任务后面的连线。所以称之为双异步机制，flowable只有第一种异步方式。
- camunda支持多种脚本语言，这些脚本语言可以在连线上进行条件表达式的配置，开箱即用。比如python、ruby、groovy、JUEL。flowable仅仅支持JUEL、groovy。开箱即用的意思就是如果想用python直接引入jython包就可以用了，不需要额外配置。
- camunda支持外部任务，比如我们有时候想在一个节点中执行调用第三方的API或者完成一些特定的逻辑操作，就可以使用外部任务，外部任务有两种表，并支持第三方系统定期来抓取并锁定外部任务，然后执行业务完毕之后，完成外部任务，流程实例继续往下执行。外部任务的好处就是解决了分布式事物的问题。在flowable中我们可以使用httpTask任务，我个人更倾向于camunda外部任务，因为这个外部任务有外部系统决定什么时候完成，httpTask是不等待任务，实例走到这个节点之后，调用一个api就直接往下跑了，外部任务不会继续往下跑，有外部系统去决定啥时候往下跑。
- camunda支持为用户定制一些个性化的偏好查找API，比如张三每次查询任务的时候，一般固定点击某某三个查询条件过滤数据，使用camunda就可以将这三个查询条件进行持久化，下次张三来了，就可以直接根据他的偏好进行数据的过滤，类似机器学习。
- camunda支持历史数据的批量删除或者批量迁移到其他介质，比如批量迁移到es，flowable没有该机制。
- camunda支持在高并发部署流程的时候，是否使用锁机制，flowable没有该机制。
- camunda支持单引擎多组合、多引擎多库。flowable仅仅支持单引擎多组合。
- camunda支持流程实例跨流程定义跳转，flowable没有该机制。
- camunda支持分布式定时器，flowable没有该机制。
- flowable支持nosql，camunda只有nosql的解决方案。
- camunda支持优化流程，以及了解流程引擎的瓶颈所在和每个环节的耗时，flowable没有该机制。
- camunda修改了流程模板xml解析方式，相比flowable性能更好。
- camunda在解析流程模板xml的时候，去除了activiti5的双解析机制，相对而言耗时时间更短。flowable没有了pvm所以规避了双解析机制。
- camunda可以在任意节点添加任意的属性，flowable原生API没有，需要自己扩展。
- camunda框架没有为流程生成图片的API(所有流程图展示以及高亮均在前端动态计算)，activiti5/6/flowable5/flowable6有图片生成以及高亮的API.
- camunda可以在节点中定义定时作业的优先级，也可以在流程中进行全局优先级的定义。当节点没有定义优先级的时候可以使用全局的优先级字段。activiti5/6/flowable5/flowable6没有改功能。
- camunda可以在流程中定义流程的tag标记，activiti5/6/flowable5/flowable6没有该功能。
- camunda/activiti5/6/flowable5/flowable6 均不支持国产数据库，比如人大金仓 和 达梦。
- flowable6支持LDAP，openLDAP,camunda不支持。activiti5不支持。
3.3 Flowable和Camunda 性能
根据一些社区基准测试，可以对它们的性能进行一些定性的评估：
Camunda：Camunda在性能上通常表现出色。它经过优化，可以处理高并发的工作负载，并且具有较低的延迟。Camunda还提供了丰富的功能和工具，如历史数据管理、事件处理、任务管理等，这些功能在复杂流程中可能会增加一些开销，但总体上，Camunda在性能上被认为是相当稳定和高效的。 Flowable：Flowable作为Activiti的分支，在性能上也有所表现。Flowable团队对引擎进行了一些优化，以提高性能和可扩展性。然而，与Camunda相比，Flowable可能在某些方面稍逊一筹，特别是在处理高并发和复杂流程时。但总体而言，Flowable仍然是一个可靠和高效的工作流引擎。
4 总结
Activit、Flowable以及Camunda 均起源于JBoss开发的JBpm4，且Flowable、Cammunda由Activit核心团队分裂而来。 Flowable和Cammunda作为使用率较高的工作流程引擎，二者功能丰富，均满足我们公司开发项目需求的要求，考虑Flowable在推出商业版后对开源版的维护频率大幅降低，很多功能已不再在开源版本中提供，Cammunda开源代码维护更新频率较高，稳定性好于Flowable，所以更倾向于采用Cammunda作为工作流程引擎应用于项目中。