请假流程：六款.NET工作流引擎实现方式对比

请假请流程：六款.NET工作流引擎实现方式

对比对象：Elsa Workflows、Workflow Core、WorkflowEngine.NET、CCFlow、StepWise、Slickflow
对照需求：一份「人人可发起」的简单请假审批（含天数分支、表单附件、反馈申请人）
资料依据：各产品公开文档 / GitHub / 官方站点，以及本工作区 CCFlow 请假相关能力（安装 Demo、AI 流程示例字段如QingJiaTianShu、组织与门户源码）
原则：同一把尺子量实现路径；有优势写优势，有短板写短板；不把「能写出 Step / Activity」等同于「能交付请假系统」；

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

0.1 本文要比的

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

1. 实现方式：引擎侧通常怎么建模、怎么挂表单、怎么写分支、怎么把待办送到人。
2. 场景适配：审批语义、PC、移动、企业应用、集团应用各自差在哪里。
3. 选型建议：什么场景优先谁，什么场景属于「名字像工作流、交付却要从零造 OA」。

0.2 本文不比的

• 不比百万级吞吐压测（请假通常不是瓶颈）。
• 不把商业增值版未公开能力算进开源/社区版得分（WorkflowEngine.NET 许可单独提示）。
• 不比「二开机制有多炫」本身——那是另一篇文档的主题；本文只问：把这道请假题交到业务手上，要多久、还要自建多少。

0.3 定位不同，必须先认账

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

1.1 业务目标

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

1.2 流程节点

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

1.3 表单与规则

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

2. 打分标准（与 Java 姊妹篇同一把尺子）

2.1 评分原则

• 满分10 分；仅在.NET 栈内部相对比较。
• 依据：公开能力+ 把请假跑通所需的额外自研量。
• 口径：强 = 产品级/配置级可交付；中 = 引擎能做但要大量自建；弱 = 基本不覆盖或模型不对题。
• 权重偏向「人机审批交付」，不偏向「编排炫技」。

2.2 维度与权重

综合分= Σ(维度分 × 权重)。另附「维护活跃度 / 许可」作选型参考（不进加权）。

2.3 及格线（POC 验收）

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

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

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

基于公开机制归纳路径差异；不是各厂商教程全文。

4.1 共性骨架（编排能力足够的引擎都能表达）

开始 → 人工步骤：填写申请单 → 人工步骤：部门领导审批 → 条件：days > 5 ? ├─ 是 → 人工步骤：总经理审批 → 汇合 └─ 否 → 直接汇合 → 人工步骤：人力资源备案 → 通知：反馈申请人 结束

差距在：表单从哪来、人从哪来、待办页谁提供、移动谁做、集团怎么隔离。

4.2 Elsa Workflows

坦诚短板：引擎与 Studio 对开发者很友好，但请假 OA 的 80% 工作量在壳上（表单、组织、待办、移动）。V2→V3 迁移成本需单独评估。

适合：已有门户，要把请假嵌进更大编排（同步考勤、写 ERP、发消息一条龙）。

4.3 Workflow Core

坦诚短板：嵌入成本极低，但「简单请假」一旦要求附件、部门领导、移动审批，就变成自研迷你 OA。
适合：后台状态机、已有 UI 的系统内嵌流转。
不适合：实施顾问「只配不写」交付请假。

4.4 WorkflowEngine.NET（OptimaJet）

坦诚短板：

1. 生产使用通常需商业许可（能看源码 ≠ 可免费商用）。
2. 比 Elsa/Workflow Core 更接近「可嵌入 BPM 组件」，但仍不是开箱中国式 OA；集团组织、移动待办要自己补齐或买生态。

适合：愿意为设计器与嵌入质量付许可费、自有门户较强的团队。

4.5 CCFlow

本仓库可见请假作为一等示例叙事：安装可加载请假模板（QingJiaFlowDemoInit.xml）、AI/快速配置示例大量使用QingJiaTianShu、请假类型等字段——说明产品主场就是这类审批单，而不是「纯变量桶」。

坦诚短板：国际社区与「流程即代码 / GitOps」叙事弱于 Elsa；超高并发分布式编排不是主战场；学习约定（节点号、表单 ID、外挂命名）需要时间。

适合：政企/企业要快速交付可上线的请假，以及后续一堆同类审批。

4.6 StepWise

坦诚结论：StepWise 很强，但强在代码步骤编排 / AI 流水线。用它做请假，等于承认你要自研半个 BPM。
纳入本文的目的：防止「看见 Workflow 字样就拿来做 OA」。

4.7 Slickflow

坦诚短板：在「标准 BPMN 嵌入」上国内口碑好；在「表单 + 组织 + 移动 + 集团开箱」上通常仍弱于 CCFlow。请假能较快跑通引擎侧，门户与移动仍是项目量。

适合：要 BPMN 语义、以 API 嵌入已有 .NET 业务系统。

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

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

5.1 审批（人机任务语义）

5.2 PC 应用

5.3 移动应用

公正提醒：移动体验强依赖企微/钉钉/APP 通道。差别在于——待办语义能否直接复用，还是移动端再实现一半审批逻辑。

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

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

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

相对分，服务选型；正式立项仍应 POC。StepWise 按「硬做请假」诚实打低分——不是否定其在 AI/步骤编排上的价值。

维护、许可与资料（不进加权，必须看）

一句话读表

• 把请假当「可上线审批应用」：CCFlow综合最高——表单/组织/门户算进了产品。
• 把请假当「嵌入已有系统的 BPMN 流」：Slickflow与WorkflowEngine.NET更贴（后者看许可）。
• 把请假当「更大编排里的人工节点」：Elsa合理；别指望开箱 OA。
• Workflow Core：能做流转，做不齐「简单请假」的产品面。
• StepWise：请假题上故意打低——防误选，不是黑它做 AI 流水线。

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

假设 2 名熟悉 .NET 的后端 + 1 名前端，从零到「请假可试用」：

公正补充：若企业已有统一表单中心、组织中台、移动待办中台，则 Elsa / Slickflow / WorkflowEngine.NET 的自建量会下降，综合分应上调——这正是它们在「中台齐全」架构里仍然合理的原因。

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

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

是否必须尽快上线「员工能直接用的请假」且缺少表单/组织/门户？ ├─ 是 → 优先 CCFlow └─ 否，已有门户与组织中台 ├─ 要 BPMN 嵌入现有 .NET 业务 → Slickflow ├─ 要商业级设计器嵌入，可接受许可费 → WorkflowEngine.NET ├─ 请假只是长编排中的人工节点 → Elsa ├─ 只要代码里嵌个状态机 → Workflow Core └─ AI/数据步骤流水线，不是审批 → StepWise（别拿来做请假主引擎）

8.2 分场景建议

8.3 与 Java 姊妹篇的对照读法（避免误读分数）

8.4 最终坦诚结论

1. 同一道简单请假题：CCFlow、Slickflow、WorkflowEngine.NET、Elsa（加自建）都能工程化做完；Workflow Core 能做「流转」但难算「交付」；StepWise模型不对题。
2. 分水岭仍是：你要的是流程引擎/编排库，还是审批应用平台。
   • 前者：Elsa / Workflow Core / Slickflow / WorkflowEngine.NET（按嵌入深度与许可选）。
   • 后者：CCFlow。
3. Slickflow是「不要 CCFlow 那种一体化、但又要正经审批引擎」时的重要备选——分数低于 CCFlow，往往是因为表单/门户/集团开箱，而不是引擎不会走网关。
4. WorkflowEngine.NET能力与设计器值得认真评，但许可必须进选型会议程，否则 POC 通过也可能上不了生产。
5. StepWise打低分是保护项目：它很优秀，只是不该出现在「请假 OA 短名单」第一页。

9. 局限性声明

1. 本文是公开资料 + 统一需求推演，不是厂商授权测评，也不是性能测试报告。
2. 商业版能力未计入开源/社区版得分；WorkflowEngine.NET 尤需按合同重评。
3. CCFlow 章节结合本工作区公开示例与源码叙事；其余以公开文档与通行落地方式为准。
4. 「集团应用」名词各异（OrgNo / 租户 / 多公司），上线前必须 POC 隔离与模板分发。
5. 与 Java 篇分数禁止直接横比——权重相同，生态与人才池不同。

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

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

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

文档生成说明：基于统一请假需求，对 Elsa、Workflow Core、WorkflowEngine.NET、CCFlow、StepWise、Slickflow 的公开实现路径与场景适配做相对评价。选型请以 POC、许可与安全评估为准。