同一道请假审批，六款 Java 工作流引擎的实现路径与成本对比

差距不在能不能画出流程图，而在表单从哪来、人从哪来、待办页谁提供、移动端谁做。用同一需求基线对比六款引擎的实现路径与相对工作量。

0. 先说清楚：本文比什么、不比什么

0.1 本文要比的

用同一道业务题（请假）回答三件事：

实现方式：引擎侧通常怎么建模、怎么挂表单、怎么写分支、怎么把待办送到人。
场景适配：审批语义、PC、移动、企业应用、集团应用各自差在哪里。
选型建议：什么场景优先谁，什么场景不该硬选谁。

0.2 本文不比的

不比「百万级吞吐压测绝对值」（请假场景通常不是瓶颈）。
不把商业增值版能力算进开源免费版得分。
不因某一产品在本仓库有源码，就默认它「总分第一」------分数按请假交付闭环打，不按品牌亲疏打。

0.3 关于「Deployment」的坦诚说明

公开检索中，没有仍在主流活跃维护、且官方名称就叫 Deployment 的 Java BPM 引擎。

与 OpenWFE 同期、常被学术/早期开源 BPM 评测并列的，多为 jBPM / Enhydra Shark（XPDL、流程定义部署中心化）一类产品。

本文处理口径 ：将「Deployment」按早期「以流程定义部署为中心」的 XPDL / WfMC 路线引擎代表 评估（公开资料最接近的对照物是 Enhydra Shark 一类），并在评分中单独标注资料不确定性惩罚 。若你本意是 jBPM，请以文末「若换成 jBPM」补注为准------结论会明显好于当前「Deployment」栏。

1. 需求基线：这道「简单请假」到底考什么

1.1 业务目标

解决手工纸质请假单繁琐问题：线上发起、逐级审批、按天数分支、人力资源备案、结果反馈申请人。

1.2 流程节点（固定）

序号	节点	角色语义
1	填写申请单	申请人（所有人可发起）
2	部门领导审批	发起人所属部门领导
3	总经理审批	条件节点：请假天数 > 5 才进入
4	人力资源备案	HR
5	反馈给申请人	通知 / 抄送 / 结束知会

说明：需求原文顺序写为「部门领导 → 人力资源 → 总经理」。按转向条件「部门经理审批后：天数 > 5 走总经理，总经理后再人力资源」理解，合理主路径 应为：

申请 → 部门领导 →（≤5 天）人力资源备案 → 反馈 ；

申请 → 部门领导 →（>5 天）总经理 → 人力资源备案 → 反馈 。

下文实现均按该语义建模；若贵司制度规定「先 HR 备案再总经理」，只需改网关位置，不改变引擎对比结论。

1.3 表单与规则

项	要求
字段	请假类型、日期从/到、请假天数、请假原因、附件
类型枚举	病假、婚假、事假
发起范围	所有人
关键规则	`请假天数 > 5` → 总经理审批

1.4 这道题真正拉开差距的，不是画 5 个框

能力点	为什么重要
审批语义	待办、同意/驳回、意见、退回申请人------请假几乎天天发生
表单 + 附件	病假常要证明材料；没有表单引擎就要自研或外接
组织选人	「部门领导」依赖组织树 / 上级字段，不是 BPMN 自带的
PC 办理台	员工与领导日常入口
移动办理	领导出差批假是刚需
企业 / 集团	分公司、多组织、流程模板复用，决定能不能从 Demo 长成平台

2. 打分标准（同一把尺子）

2.1 评分原则

满分 10 分 ；只在 Java 栈内部相对比较。
依据：开源/社区版公开能力 + 把请假跑通所需的额外自研量。
口径：强 = 产品级/配置级可交付；中 = 引擎能做但要大量自建；弱 = 基本不覆盖或项目已停更难落地。
综合分采用加权，权重偏向「请假这类人机审批交付」而非「纯编排炫技」。

2.2 维度与权重

编号	维度	权重	评判要点（对准请假需求）
S1	流程与条件分支	15%	天数网关、节点顺序、发起权限是否好配
S2	表单 / 附件 / 枚举	15%	请假单字段、附件、类型字典开箱程度
S3	审批语义	20%	待办、意见、驳回/退回、知会反馈
S4	PC 应用完备性	15%	设计器、待办门户、查询、办理页
S5	移动应用	15%	官方/生态移动端、H5/APP、待办推送
S6	企业应用	10%	组织岗位、权限、消息、报表、与业务系统集成
S7	集团 / 多组织	10%	多公司、租户/Org 隔离、流程模板共享与分发

综合分 = Σ(维度分 × 权重)。另附「维护活跃度 / 资料可信度」作为一票参考项（不进入加权，但影响选型建议）。

2.3 及格线（POC 验收）

能同时满足以下 6 条，才算「请假流程做完」：

任意登录用户可发起；
表单含类型/日期/天数/原因/附件；
天数 > 5 走总经理，否则跳过；
各部门领导、总经理、HR 能在待办中审批并留意见；
结束后申请人能收到反馈（站内消息 / 邮件 / 抄送至少一种）；
PC 可完整办结；移动端至少可审批（原生或 H5）。

3. 六款引擎定位一览（请假语境）

产品	大致定位	请假实现主路径	更像什么
Camunda	BPMN 编排 + 运维（7 嵌入/平台；8 偏云原生）	BPMN UserTask + Gateway + 外挂表单/Tasklist	国际主流流程中间件
Flowable	Activiti 后继；BPMN/CMMN/DMN 引擎族	同谱系：BPMN + Delegate/Listener + 自建门户	国内普及率很高的嵌入式引擎
Activiti	经典 BPMN 引擎（现多云化叙事）	与上类似，生态与迭代弱于 Flowable/Camunda	历史资产多、新项目谨慎
JFlow	流程 + 表单 + 组织一体化 BPM（Java）	设计器配节点/方向条件 + 内置表单/组织/待办	中国式审批交付平台
Deployment	早期「部署中心化」XPDL/WfMC 路线代表（资料不确定）	流程包部署 + Worklist；表单/移动多自建	历史对照物，不宜作新选型主选
OpenWFE	2000 年代开源套件（Engine + Worklist + Web）	自有流程定义语言 + Worklist；项目已长期不活跃	教学/考古对照，生产新系统不推荐

4. 同一道题：各引擎怎么实现

下列实现描述基于公开机制归纳，用于对比路径差异；不是各厂商官方教程全文照抄。

4.1 共性骨架（所有现代引擎都能表达）

ini 复制代码

开始
  → 用户任务：填写申请单（assignee = 发起人）
  → 用户任务：部门领导审批（候选人 = 部门领导）
  → 排他网关：days > 5 ?
        ├─ 是 → 用户任务：总经理审批 → 汇合
        └─ 否 → 直接汇合
  → 用户任务：人力资源备案
  → 知会/服务任务：反馈申请人
结束

差距不在「能不能画出这张图」，而在：表单从哪来、人从哪来、待办页谁提供、移动谁做、集团怎么隔离。

4.2 Camunda

步骤	典型做法
建模	Camunda Modeler 画 BPMN；Exclusive Gateway 写 `${leaveDays > 5}`
部署	流程定义 Deployment 到引擎（注意：这是引擎概念，不是本文产品名）
表单	Camunda Forms / 外接 Form.io / 自研 Vue；附件走外部对象存储 + 变量存 URL
选人	Identity Service 或自建：部门领导需查组织服务后写入 `candidateUsers/Groups`
审批	Tasklist / 自建工作台；Listener 写审计；反馈用邮件 Connector 或消息服务
扩展	JavaDelegate、Execution/Task Listener、External Task Worker

坦诚短板（请假场景） ：开箱不是「OA 请假系统」。组织上级、附件中心、移动审批、集团多组织，多数要项目自建 。Camunda 8 需额外评估 SSPL 等许可对私有化交付的影响。

适合：已有统一门户与组织中台，引擎只负责标准流转与运维监控。

4.3 Flowable

步骤	典型做法
建模	BPMN 2.0 + Exclusive Gateway；表达式绑定流程变量 `leaveDays`
表单	开源 UI 偏基础；国内常见 = Flowable + 自研/第三方表单
选人	`candidateGroups` + 自建组织；或 TaskListener 动态算领导
审批	Task Service API；退回/驳回常要自研跳转策略
扩展	JavaDelegate、Listener、Spring Boot Starter 嵌入

坦诚短板 ：国内「Flowable 很火」≠「请假两天配完」。火的是引擎内核与资料；表单门户、移动、中国式退回加签，仍是项目工作量。相对 Camunda，中文社区与 Spring 集成案例更密。

适合：Java/Spring 团队、要 BPMN 资产、能接受自建审批壳。

4.4 Activiti

实现路径与 Flowable/Camunda 高度同构（同源思想：BPMN + 委托代码 + 变量网关）。

项	请假语境下的现实
能做完吗	能，机制足够
成本	与 Flowable 类似，但新版本迭代与社区热度偏弱，招人/踩坑资料逐渐转向 Flowable
风险	新项目继续押 Activiti 7/Cloud，要接受生态分流成本

坦诚结论：把它当「经典实现参照」可以；当「2026 年新建请假平台首选」需要非常明确的存量绑定理由。

4.5 JFlow

步骤	典型做法
建模	驰骋流程设计器配置节点与方向；条件如 `@QingJiaTianShu > 5`
表单	内置表单设计器：类型枚举、日期、天数、原因、附件控件直接配
选人	`Port_*` 组织：按部门领导、岗位、HR 角色配置接收人
审批	待办/在途/已完成门户开箱；意见字段可落在表单或审核框
反馈	抄送、消息、结束事件等产品能力，少写胶水代码
扩展	前端外挂 / 后端外挂 / 事件配置（与 CCFlow 同源三层）

本仓库可见请假实体 Demo：JFlow/jflow-core/src/main/java/bp/demo/QingJia.java（字段含请假人、天数、原因及部门/总经理/HR 意见），说明产品叙事就是审批单据 + 流程一体，而不是「纯变量桶」。

坦诚短板：国际社区与 BPMN 工具链弱于 Camunda/Flowable；超高并发分布式编排不是主战场；海外团队接受度有限。

适合：政企/企业 OA、要快速交付完整请假（含 PC 门户），以及后续一堆同类审批。

4.6 Deployment（早期部署型 / XPDL 路线代表）

步骤	历史公开资料中的典型做法
建模	XPDL 或厂商定义语言 + 图形设计器（因具体产品而异）
运行	强调 Process Definition 打包部署到引擎，Worklist 取任务
表单 / 移动 / 集团	普遍薄弱或外置，需大量定制

坦诚短板 ：作为新项目选型对象 资料不足、社区停滞风险高；与当代 BPMN 工具链、Spring Boot、移动推送生态脱节。纳入本文是为对照「引擎史」与用户清单完整，不建议作为新建请假系统的主引擎。

4.7 OpenWFE

项	公开事实
组成	Engine + Worklist + Web 界面（历史架构清晰）
定义语言	类 Scheme/Lisp 风格的 XML 流程定义（学习曲线特殊）
现状	长期不活跃；后续演进更多转向其他技术栈项目
请假	理论上 Worklist 可做人机任务，但表单、组织、移动、集团均需自建，且缺乏现代维护

坦诚结论 ：适合写进「开源工作流发展史」；不适合 2026 年新上线的企业请假/OA。

5. 重点场景对照：审批 · PC · 移动 · 企业 · 集团

评级：强 / 中 / 弱。依据公开产品能力与常见落地形态。

5.1 审批（人机任务语义）

引擎	待办模型	驳回/退回	意见/附件进入审批	一句话
Camunda	强（UserTask 成熟）	中（模式要自建）	中（表单外置时割裂）	引擎审批强，业务审批壳要自己砌
Flowable	强	中	中	同左；国内案例多，壳子方案多
Activiti	强偏中	中偏弱	中	机制有，生态递减
JFlow	强	强（中国式退回等产品化）	强	请假这类审批是主场
Deployment	中偏弱	弱	弱	Worklist 有，语义产品化不足
OpenWFE	中（历史 Worklist）	弱	弱	能演示，难持续

5.2 PC 应用

引擎	设计器	待办/办理门户	查询与监控	请假 PC 交付直觉
Camunda	强（Modeler）	中（Tasklist/Cockpit，偏技术运营）	强（运维监控亮点）	「先有引擎，再造 OA 皮」
Flowable	中偏强	中	中偏强	同上，国内壳更多
Activiti	中	中偏弱	中	可用，体验看发行版
JFlow	强（中文属性面板）	强	中偏强（业务查询友好）	「配完就能给业务用」
Deployment	中（视具体产品）	弱	弱	缺现代 PC 门户
OpenWFE	弱（过时 Web）	弱	弱	不建议

5.3 移动应用

引擎	官方/产品级移动	常见落地	领导批假体验
Camunda	中（多靠自研/生态）	企业微信/钉钉 + REST 封一层	取决于项目组
Flowable	中	同上，国内钉钉/企微集成案例多	取决于项目组
Activiti	弱偏中	自研为主	成本高
JFlow	中偏强（产品侧移动/H5 叙事完整，视版本）	与待办同一套流程语义	相对少造轮子
Deployment	弱	基本无现代移动方案	差
OpenWFE	弱	无	差

公正提醒：任何引擎的「移动能力」都强依赖消息通道（企微/钉钉/APP 推送）。差别在于------待办语义能否直接复用，还是移动端要再实现一半审批逻辑。

5.4 企业应用（组织、权限、集成、可运营）

引擎	组织岗位	权限门户	业务集成	企业内推请假到「制度系统」
Camunda	中（需 IDM/外部组织）	中	强（Connector/外部任务）	适合已有企业中台
Flowable	中	中	强（Spring 生态）	同上
Activiti	中	中偏弱	中	存量系统续命常见
JFlow	强（Port 体系）	强	中偏强（事件/WebApi/SQL 等）	适合作审批业务底座
Deployment	弱	弱	中偏弱	难
OpenWFE	弱	弱	弱	难

5.5 集团应用（多组织 / 多公司）

引擎	多组织模型	流程模板分发	集团请假制度落地
Camunda	中偏强（Tenant 等，版本与产品线有关）	中（部署与权限要治理）	能做，要平台级治理
Flowable	中（`tenantId` / 企业版更完整）	中	能做，开源版多靠应用层
Activiti	中偏弱	中偏弱	弱于前两者
JFlow	强（集团版 OrgNo 等运行模式，公开资料与同源 CCFlow 一致）	强（组织内复制/共享叙事清晰）	主场之一
Deployment	弱	弱	不建议
OpenWFE	弱	弱	不建议

6. 打分表（请假交付视角）

分数是相对分，服务选型讨论；正式立项仍应 POC。Deployment 因资料不确定，相关维度已保守给分。

维度（权重）	Camunda	Flowable	Activiti	JFlow	Deployment	OpenWFE
S1 流程与分支（15%）	9.0	9.0	8.0	8.5	5.5	5.0
S2 表单附件枚举（15%）	6.5	6.5	6.0	9.0	4.0	3.5
S3 审批语义（20%）	8.0	8.0	7.0	9.2	5.0	4.5
S4 PC 应用（15%）	7.5	7.0	6.0	9.0	4.0	3.0
S5 移动应用（15%）	6.5	7.0	5.5	8.0	2.5	2.0
S6 企业应用（10%）	8.0	8.0	6.5	8.5	3.5	3.0
S7 集团应用（10%）	7.5	7.0	5.5	8.8	2.5	2.0
加权综合	7.6	7.6	6.5	8.8	4.0	3.4

维护与资料可信度（不进加权，但必须看）

产品	活跃度	中文资料	许可提示	选型态度
Camunda	高	中	关注 Camunda 8 协议与商业边界	可进短名单
Flowable	高	高	Apache 2.0，商用友好	可进短名单
Activiti	中偏低	中（存量多）	Apache 2.0	谨慎，优先存量
JFlow	中偏高（国内交付向）	高	以官方开源说明为准	可进短名单
Deployment	低 / 不明	低	---	不建议新选
OpenWFE	停更风险极高	低	历史 BSD 等	不建议新选

一句话读表

只把请假当「流程中间件作业」：Camunda ≈ Flowable，都强。
要把请假当「可上线的审批应用」：JFlow 综合分更高，因为它把表单/组织/门户算进了产品，而不是算进你的项目排期。
Deployment / OpenWFE ：对照历史有价值，对新项目综合分不及格。

7. 实现成本对照（把「简单」说透）

假设团队是 2 名熟悉 Java 的后端 + 1 名前端，从零到「请假可试用」：

引擎	相对工作量（直觉量级）	工作主要花在哪
JFlow	低	设计器配流程/表单/接收人；少量字典与测试
Flowable	中高	BPMN + 变量网关不难；难在表单、组织领导、待办 UI、移动
Camunda	中高	同上；运维监控省心，OA 壳仍要造
Activiti	中高偏上	同谱系，但资料与组件选择更折腾
Deployment	高	缺现代轮子，事事自建 + 资料稀缺
OpenWFE	极高	技术栈过时，招人与维护成本不可接受

公正补充：若企业已经有统一表单中心、组织中台、移动待办中台，则 Flowable/Camunda 的「自建量」会大幅下降，综合分应上调------这正是它们在大型企业架构里仍然非常合理的原因。

8. 选型建议（按场景，不捧杀）

8.1 决策树（请假及同类审批）

markdown 复制代码

是否必须上线「能直接给员工用的请假」且 2～4 周内可见结果？
 ├─ 是，且缺表单/组织/门户 → 优先 JFlow
 └─ 否，已有门户与组织中台，只要标准 BPMN 引擎
      ├─ 要运维监控/国际化团队/DMN → Camunda（评估协议）
      ├─ Spring 生态 + 国内人才密度 → Flowable
      └─ 仅维护 Activiti 存量 → 继续 Activiti，新流程评估迁 Flowable

历史引擎：

复制代码

是否为教学、考古、论文复现？
 ├─ 是 → OpenWFE / 早期 XPDL（Deployment 对照）可作阅读对象
 └─ 否 → 不要进入生产短名单

8.2 分场景建议

场景	更稳妥的选择	理由（中肯版）
中小企业 / 政企 OA 请假、报销、用章	JFlow	审批+表单+组织闭环，PC/移动交付路径短
大型企业已有中台，流程要进微服务编排	Flowable 或 Camunda	引擎纯粹、标准强；请假只是众多流程之一
强监管、重流程运维与实例迁移	Camunda	Cockpit/运维能力是长板；许可与版本要法务一起看
集团多公司、组织切换频繁的审批平台	JFlow（集团模式）；或 Flowable/Camunda + 自建组织治理	前者产品化；后者灵活但贵在治理
纯移动优先、引擎可有可无	先定移动待办中台，再选引擎	引擎选错不如移动入口选错伤体验
新项目拿 OpenWFE/不明 Deployment 顶上	不建议	活跃度与生态无法支撑企业持续交付

8.3 若你的「Deployment」其实是 jBPM

把 Deployment 换成 jBPM（KIE） 后，请假场景的粗定位是：

审批与 BPMN：中偏强；
表单/PC/移动：仍多依赖周边，综合通常落在 Activiti 与 Flowable 之间或略近 jBPM 商业工具链；
仍不会在「开箱请假 OA」上自动超过 JFlow，也很难在国内普及度上超过 Flowable。

8.4 最终坦诚结论

同一道简单请假题，六款都能「理论上做完」------除 OpenWFE/不明 Deployment 外，现代四款都能工程化做完。
真正的分水岭 ：你是要买（或开源采用）一个流程引擎 ，还是要交付一个审批应用 。
- 前者：Camunda / Flowable 更标准、更国际、更好嵌进中台。
- 后者：JFlow 更像把请假（以及下一打审批）当成产品主路径。
Activiti 值得尊重，但新项目应说清「为什么不是 Flowable」。
OpenWFE、Deployment（按早期部署型理解）：适合对照，不适合当作 2026 年企业/集团请假平台的答案。

9. 局限性声明

本文是公开资料 + 统一需求推演的对比，不是厂商授权测评，也不是性能测试报告。
商业版能力（Flowable/Camunda 企业版等）未计入得分；若采购商业版，PC/移动/低代码短板可能被补齐，需按合同能力重评。
JFlow 章节结合本工作区公开 Demo 与同源产品叙事；其余引擎以公开文档与业界通行落地方式为准，不臆造未公开功能。
「集团应用」在不同厂商中的名词是 Tenant / OrgNo / 多公司，能力边界差异大，上线前必须 POC 多组织隔离与流程模板分发。

附录 A：请假主路径（推荐建模语义）

附录 B：需求→实现检查清单（POC 用）

所有人可发起
表单：类型（病假/婚假/事假）、从/到、天数、原因、附件
部门领导待办可批、可写意见
天数 > 5 出现总经理待办；≤ 5 不出现
HR 备案可办
申请人收到反馈
PC 全流程可办结
移动端至少完成审批动作
（集团场景）组织 A 的单不可被组织 B 越权看到

文档生成说明：基于统一请假需求，对 Camunda、Flowable、Activiti、JFlow、Deployment、OpenWFE 的公开实现路径与场景适配做相对评价。Deployment 名称存疑已在文首披露。选型请以 POC 与法务/安全评估为准。