一道请假审批需求看六款 Java 流程引擎：实现路径与成本

请假审批是最常见的流程考题。本文按统一需求拆解六款 Java 引擎的实现路径、场景适配与交付成本，并给出加权评分与选型建议。

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

0.1 本文要比的

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

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

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 流程节点（固定）

说明：需求原文顺序写为「部门领导 → 人力资源 → 总经理」。按转向条件「部门经理审批后：天数 > 5 走总经理，总经理后再人力资源」理解，合理主路径应为： 申请 → 部门领导 →（≤5 天）人力资源备案 → 反馈； 申请 → 部门领导 →（>5 天）总经理 → 人力资源备案 → 反馈。 下文实现均按该语义建模；若贵司制度规定「先 HR 备案再总经理」，只需改网关位置，不改变引擎对比结论。

1.3 表单与规则

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

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

2.1 评分原则

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

2.2 维度与权重

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

2.3 及格线（POC 验收）

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

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

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

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

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

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

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

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

4.2 Camunda

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

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

4.3 Flowable

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

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

4.4 Activiti

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

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

4.5 该引擎

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

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

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

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

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

4.7 OpenWFE

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

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

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

5.1 审批（人机任务语义）

5.2 PC 应用

5.3 移动应用

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

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

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

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

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

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

一句话读表

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

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

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

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

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

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

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

历史引擎：

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

8.2 分场景建议

8.3 若你的「Deployment」其实是 jBPM

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

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

8.4 最终坦诚结论

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

9. 局限性声明

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

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

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

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

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