七款 Java 工作流引擎「二开能力」怎么比

七款 Java 工作流引擎「二开能力」怎么比

一句话结论

「二开」不是改引擎源码，而是在不污染内核的前提下，把业务逻辑挂到流程生命周期上。
Activiti 系（Flowable / Camunda 7 / Activiti / Operaton）强在BPMN 标准扩展 + Java 委托/监听器/外部任务；JFlow 强在同一套事件语义下的前端外挂 / 后端外挂 / 事件配置三路并行；FixFlow 曾以微内核 + SPI 插件见长但开源线停滞；OSWorkflow 属于早期 XML + FunctionProvider 范式，已不适合作为新项目主选。

没有「绝对第一」——只有「与团队技能、集成形态、是否要低代码配置」是否匹配。

1. 先确认：流程引擎「二开」的定义与范围

1.1 定义（建议统一口径）

流程引擎二开= 流程（模板）设计完成之后，在不修改引擎内核发送/流转代码的前提下，用脚本、类、配置或 Worker，与引擎在固定生命周期点交互，从而完成业务校验、集成、通知、台账等逻辑的过程。

1.2 本文「二开」包含什么、不包含什么

1.3 为公平对比，统一成「三层挂接模型」

各产品名词不同，但二开诉求可映射为同一三层模型：

下文各引擎对照时，都尽量落到 L1 / L2 / L3，避免「只比 JavaDelegate、不比页面扩展」的偏科。

2. 七款引擎速览（背景，避免误读）

公平提示：Camunda 8 与 Camunda 7 / Operaton 不是同一套二开体验。本文默认对「Java 嵌入式 BPMN 引擎」以Camunda 7 / Operaton为代表；对 Camunda 8 单独注明「外部 Worker 优先」。

3. 总表：二开能力对照（同一维度）

评分说明（避免「营销满分」）：

• ●●● 产品化完整、文档与实践成熟
• ●●○ 可用且常见，但需较多自建或工具链配合
• ●○○ 有机制但弱产品化 / 需改较多外围
• ○○○ 基本不具备该层（或需改核）
• — 不适用或公开资料不足以公允评价

3.1 读表方式（中肯解读）

1. Activiti / Flowable / Camunda 7 / Operaton在 L2 几乎同级：都是「Java 委托 + 监听器」成熟范式，差异主要在工具链、External Task、运维套件与许可证演进。
2. JFlow的差异化不在「能不能写 Java」，而在L1+L3 产品化：同一事件名可前端拦、后端拦、设计器配，且面向中国式审批事件（发送、退回、撤销等）清单化。
3. FixFlow扩展思想先进（SPI、连接器），但开源维护状态拖累「能否作为长期二开底座」。
4. OSWorkflow有历史价值，不宜与现代 BPMN 引擎做「功能多寡」硬比，仅作范式对照。

4. 分引擎：二开机制怎么挂（公开资料口径）

4.1 Activiti / Flowable（同源范式）

公平评价：L2 极强、生态大；L1 通常要自己做任务中心/表单壳；L3 依赖模型里写表达式或上商业建模套件，不像「设计器勾选事件 + 选 SQL/WebApi」那样面向实施人员。

4.2 Camunda 7 / Operaton

Camunda 8 补充（避免混比）：核心是 Zeebe，二开主路径变为Job Worker / 外部客户端，与 7.x「类路径里丢一个 Delegate」体验不同。选 8 是选编排平台，不是简单替换 7 的嵌入式二开习惯。

Operaton 补充：二开能力本身 ≈ Camunda 7；差异在于社区维护连续性与「无开放核心分层」主张，而不是发明第三套委托模型。

4.3 FixFlow

公平评价：扩展点设计对「可升级二开」意识强；但开源停更后，资料陈旧、人才与补丁风险必须写入选型风险表。

4.4 OSWorkflow

公平评价：奠定了「工作流 = 状态机 + 可插拔函数」的早期范式；不应再作为新 Java BPM 项目的主引擎，但理解它有助于读懂后来 Listener/Delegate 的演进。

4.5 JFlow（专节见第 5 章）

三路并列：前端外挂（L1）、后端外挂（L2）、事件配置（L3），共用SendWhen/SendSuccess/FlowOverAfter等事件语义；服务端由ExecEvent统一调度。

5. JFlow 三种二开：结合代码说明（可核验）

说明：工作区以CCFlow（.NET）+ Vue3为完整可运行实证；JFlow（Java）与之事件名、分层思想同源（公开文档与产品口径长期如此）。下表路径以本仓库为准。

5.1 运行时分层（发送为例）

用户点击发送 ├─ ① L1 前端外挂：WGFlow_* / beforeSend ← UI 侧可拦截 └─ ② HTTP → 流程引擎 └─ ExecEvent（统一调度） ├─ OverrideEvent（全局后端拦截） ├─ FlowEventBase（流程级后端外挂） ├─ FrmEvents / GenerDBSrc（事件配置） └─ PushMsgs（消息推送，同事件标记，职责分离） └─ ③ 前端 SendSuccess / afterSend

5.2 模式对照总表

5.3 前端外挂（L1）

与 Activiti 系公平对比：Activiti/Flowable/Camunda并不缺做前端扩展的能力，但通常要自建 Task UI；JFlow 把「按流程号发现外挂类」做成了产品约定，降低「每个项目重做壳」的成本。代价是需接受产品命名约定与前端技术栈（Vue3）。

5.4 后端外挂（L2）

与 JavaDelegate 公平对比：

两者都是合格 L2；谁更合适取决于你的模型是「国际 BPMN 编排」还是「审批事件驱动」。

5.5 事件配置（L3）

与「BPMN 里写表达式」公平对比：表达式很灵活，但实施友好度通常低于「在属性面板选事件 + 选执行体」。JFlow 的 L3 更像低代码集成；Activiti 系的 L3 更像开发者模型扩展。

5.6 BP.App 里常见业务扩展模式（不止三种）

5.7 JFlow 三种模式怎么选（场景表）

6. 「同一业务需求」七引擎挂法对照（便于评审）

需求示例：节点提交前校验金额；提交成功后调用外部 WebApi；页面上要即时提示。

可以看出：差异往往不在「能不能做」，而在「几层是产品能力、几层要项目自建」。

7. 优劣势清单（刻意写「短板」）

8. 选型建议（按「二开」目标，而非品牌）

9. 资料与局限（公正性声明）

9.1 主要公开依据类型

• 官方用户手册：Camunda Delegation Code、Flowable Service Task / Listener、Operaton 1.0 Release Notes
• 社区对比与演进：Capital One BPM 对比、Camunda 7→8 架构说明、Operaton 对 Camunda 7 CE 的继承说明
• FixFlow / FoxBPM 博客与 GitHub README（SPI、连接器、维护状态）
• OSWorkflow 中文手册（FunctionProvider）
• 本仓库设计文档与源码：doc/BPM-解读/.流程引擎BPM设计之：流程二开的三种模式.md，以及BP.WF/BP.App/Vue3实证路径

9.2 本文不做的事

• 不宣称某一引擎「全面碾压」
• 不把商业版独家能力偷偷算进社区版得分
• 不把「中国式审批好用」偷换成「BPMN 标准更强」
• 不把「BPMN 标准强」偷换成「国内交付一定更快」

9.3 可能的偏差来源

• 各产品版本迭代快，表格是2026-07 公开信息快照
• JFlow 章节有本仓库源码优势，Activiti 系以公开文档为主——已在总表用「同一 L1/L2/L3」约束，降低偏科
• 「社区活跃度」是定性判断，不是星标数排行榜

10. 附录：JFlow/CCFlow 二开源码索引（便于落地）

结语

把「二开」先定义清楚，再比七款引擎，结论会朴素很多：

1. Activiti 家族赢在标准委托模型与国际生态；
2. JFlow赢在审批场景下 L1/L2/L3 三路产品化且事件语义统一；
3. Operaton解决的是 Camunda 7 CE 停更后的「二开资产续命」；
4. FixFlow / OSWorkflow分别代表「国产插件化高峰」与「早期函数扩展」——有学习价值，新项目需谨慎。

好的二开能力 = 挂得上去 + 不改内核 + 团队真的写得动/配得动。
选引擎时，先问自己缺的是 L1、L2 还是 L3，而不是先问品牌。