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

请假请流程六款.NET工作流引擎实现方式对比对象Elsa Workflows、Workflow Core、WorkflowEngine.NET、CCFlow、StepWise、Slickflow对照需求一份「人人可发起」的简单请假审批含天数分支、表单附件、反馈申请人资料依据各产品公开文档 / GitHub / 官方站点以及本工作区 CCFlow 请假相关能力安装 Demo、AI 流程示例字段如QingJiaTianShu、组织与门户源码原则同一把尺子量实现路径有优势写优势有短板写短板不把「能写出 Step / Activity」等同于「能交付请假系统」0. 先说清楚本文比什么、不比什么0.1 本文要比的用同一道业务题请假回答三件事实现方式引擎侧通常怎么建模、怎么挂表单、怎么写分支、怎么把待办送到人。场景适配审批语义、PC、移动、企业应用、集团应用各自差在哪里。选型建议什么场景优先谁什么场景属于「名字像工作流、交付却要从零造 OA」。0.2 本文不比的不比百万级吞吐压测请假通常不是瓶颈。不把商业增值版未公开能力算进开源/社区版得分WorkflowEngine.NET 许可单独提示。不比「二开机制有多炫」本身——那是另一篇文档的主题本文只问把这道请假题交到业务手上要多久、还要自建多少。0.3 定位不同必须先认账类型产品请假语境下的诚实定位BPM / 审批向CCFlow、Slickflow、部分WorkflowEngine.NET人机任务、待办、退回是主叙事编排 / 库向Elsa、Workflow Core长流程/嵌入编排强审批壳要自建步骤 / AI 向StepWise不是传统 OA 审批引擎纳入对比是为防误选1. 需求基线这道「简单请假」到底考什么1.1 业务目标解决手工纸质请假单繁琐线上发起、逐级审批、按天数分支、人力资源备案、结果反馈申请人。1.2 流程节点序号节点角色语义1填写申请单申请人所有人可发起2部门领导审批发起人所属部门领导3总经理审批条件节点请假天数 5才进入4人力资源备案HR5反馈给申请人通知 / 抄送 / 结束知会需求原文节点顺序写为「部门领导 → 人力资源 → 总经理」。按转向条件「部门经理审批后天数 5 走总经理总经理后再人力资源」理解合理主路径为申请 → 部门领导 →≤5 天人力资源备案 → 反馈申请 → 部门领导 →5 天总经理 → 人力资源备案 → 反馈。下文均按该语义若制度要求「先 HR 再总经理」只改网关位置不改变引擎对比结论。1.3 表单与规则项要求字段请假类型、日期从/到、请假天数、请假原因、附件类型枚举病假、婚假、事假发起范围所有人关键规则请假天数 5→ 总经理审批1.4 真正拉开差距的不是画 5 个框能力点为什么重要审批语义待办、同意/驳回、意见、退回——请假高频表单 附件病假常要证明无表单引擎就要自研组织选人「部门领导」靠组织树/上级不是 Activity 自带的PC 办理台员工与领导日常入口移动办理领导出差批假是刚需企业 / 集团多组织、模板复用决定 Demo 能否长成平台2. 打分标准与 Java 姊妹篇同一把尺子2.1 评分原则满分10 分仅在.NET 栈内部相对比较。依据公开能力 把请假跑通所需的额外自研量。口径强 产品级/配置级可交付中 引擎能做但要大量自建弱 基本不覆盖或模型不对题。权重偏向「人机审批交付」不偏向「编排炫技」。2.2 维度与权重编号维度权重评判要点对准请假S1流程与条件分支15%天数分支、节点顺序、发起范围S2表单 / 附件 / 枚举15%请假单字段、附件、类型字典S3审批语义20%待办、意见、驳回/退回、知会反馈S4PC 应用完备性15%设计器、待办门户、查询、办理页S5移动应用15%移动/H5、待办推送、审批可达S6企业应用10%组织岗位、权限、消息、集成S7集团 / 多组织10%多公司、Org/租户隔离、模板分发综合分 Σ(维度分 × 权重)。另附「维护活跃度 / 许可」作选型参考不进加权。2.3 及格线POC 验收任意登录用户可发起表单含类型/日期/天数/原因/附件天数 5走总经理否则跳过部门领导、总经理、HR 可在待办审批并留意见结束后申请人能收到反馈站内 / 邮件 / 抄送至少一种PC 可办结移动端至少可审批原生或 H5。3. 六款引擎定位一览请假语境产品大致定位请假实现主路径更像什么Elsa.NET 长流程编排 StudioWorkflow Bookmark/人工等待 自建表单与待办开发者编排平台Workflow Core轻量嵌入式流程库StepBody链 自建状态/UI库级编排内核WorkflowEngine.NETOptimaJet 可嵌入引擎设计器方案 Action/Assignment 自建或模板表单商业组件式引擎CCFlow流程 表单 组织一体化 BPM设计器配节点/方向条件 内置表单/组织/待办中国式审批交付平台StepWise代码优先步骤 / AI 编排[Step]方法图无原生审批待办模型开发/AI 任务框架SlickflowBPMN 风格 .NET 引擎BPMN 任务 Gateway API表单/门户视版本标准向嵌入式 BPM4. 同一道题各引擎怎么实现基于公开机制归纳路径差异不是各厂商教程全文。4.1 共性骨架编排能力足够的引擎都能表达开始 → 人工步骤填写申请单 → 人工步骤部门领导审批 → 条件days 5 ? ├─ 是 → 人工步骤总经理审批 → 汇合 └─ 否 → 直接汇合 → 人工步骤人力资源备案 → 通知反馈申请人 结束差距在表单从哪来、人从哪来、待办页谁提供、移动谁做、集团怎么隔离。4.2 Elsa Workflows步骤典型做法建模Elsa Studio / 代码定义 WorkflowIf 活动或流程图分支写leaveDays 5人机Bookmark / Human-in-the-loop领导完成任务后 Resume表单自建ASP.NET / Blazor / 外部表单附件走对象存储变量存 URL选人自建组织服务把 assignee 写入业务表或自定义活动审批壳自建待办列表查询 Bookmark/任务驳回自定义信号或回退活动反馈HTTP/Email 活动或自定义 Activity坦诚短板引擎与 Studio 对开发者很友好但请假 OA 的 80% 工作量在壳上表单、组织、待办、移动。V2→V3 迁移成本需单独评估。适合已有门户要把请假嵌进更大编排同步考勤、写 ERP、发消息一条龙。4.3 Workflow Core步骤典型做法建模C#StepBody或 JSON/YAML 引用步骤类型分支决策步骤 / 条件流出leaveDays 5人机社区 Users 等扩展可做等待完整审批要自建表单 / 门户 / 移动基本都无产品级能力 → 全自建坦诚短板嵌入成本极低但「简单请假」一旦要求附件、部门领导、移动审批就变成自研迷你 OA。适合后台状态机、已有 UI 的系统内嵌流转。不适合实施顾问「只配不写」交付请假。4.4 WorkflowEngine.NETOptimaJet步骤典型做法建模可视化设计器画方案Condition / 分支表达天数表单设计器表单模板 / Vue 等可定制完整附件中心仍常要项目补选人Assignment、角色、命令部门领导规则多要接自有组织审批引擎命令Approve 等 自建或半成品工作台扩展IWorkflowActionProvider、CodeActions、Plugins坦诚短板生产使用通常需商业许可能看源码 ≠ 可免费商用。比 Elsa/Workflow Core 更接近「可嵌入 BPM 组件」但仍不是开箱中国式 OA集团组织、移动待办要自己补齐或买生态。适合愿意为设计器与嵌入质量付许可费、自有门户较强的团队。4.5 CCFlow步骤典型做法建模驰骋流程设计器配置节点与方向条件如QingJiaTianShu 5表单内置表单设计器枚举病假/婚假/事假、日期、天数、原因、附件选人Port_*按部门领导、岗位、HR 角色配置审批待办/在途/已完成门户开箱意见可落表单或审核框反馈抄送、消息、结束事件等少写胶水扩展前端外挂 / 后端外挂 / 事件配置不改发送内核本仓库可见请假作为一等示例叙事安装可加载请假模板QingJiaFlowDemoInit.xml、AI/快速配置示例大量使用QingJiaTianShu、请假类型等字段——说明产品主场就是这类审批单而不是「纯变量桶」。坦诚短板国际社区与「流程即代码 / GitOps」叙事弱于 Elsa超高并发分布式编排不是主战场学习约定节点号、表单 ID、外挂命名需要时间。适合政企/企业要快速交付可上线的请假以及后续一堆同类审批。4.6 StepWise步骤典型做法若硬做请假建模[Step]/[DependsOn]把「申请、审批、备案」写成方法依赖图人机无原生 UserTask/待办要自建「谁点了同意再触发下一步」表单/门户/移动/集团均需从零自带 WebUI 偏调试执行不是审批工作台坦诚结论StepWise 很强但强在代码步骤编排 / AI 流水线。用它做请假等于承认你要自研半个 BPM。纳入本文的目的防止「看见 Workflow 字样就拿来做 OA」。4.7 Slickflow步骤典型做法建模BPMN 风格设计器排他网关天数 5运行WorkflowServiceStart / Run / Sendback / Withdraw 等表单社区版常见「引擎 自建或轻量表单」完整度视版本/商业线选人参与者配置 常接自有组织扩展IExternalService、WebApi、SQL、过程、C# 库坦诚短板在「标准 BPMN 嵌入」上国内口碑好在「表单 组织 移动 集团开箱」上通常仍弱于 CCFlow。请假能较快跑通引擎侧门户与移动仍是项目量。适合要 BPMN 语义、以 API 嵌入已有 .NET 业务系统。5. 重点场景对照审批 · PC · 移动 · 企业 · 集团评级强 / 中 / 弱。依据公开产品能力与常见落地形态。5.1 审批人机任务语义引擎待办模型驳回/退回意见与附件进审批一句话Elsa中Bookmark 可自建中自建中表单外置能等人不等于开箱审批Workflow Core弱偏中弱弱库级等待OA 语义靠你WorkflowEngine.NET中偏强中中偏强组件强OA 壳仍要砌CCFlow强强强请假类审批是主场StepWise弱弱弱模型不对题Slickflow强强API 级退回等中表单深度视版本引擎审批强壳看项目5.2 PC 应用引擎设计器待办/办理门户查询监控请假 PC 交付直觉Elsa强Studio中偏开发/运维业务门户自建中偏强先有编排再造 OA 皮Workflow Core弱弱弱几乎全自建WorkflowEngine.NET强中中设计器亮眼门户要补CCFlow强中文属性强中偏强配完可给业务用StepWise中执行 WebUI弱非审批台中调试友好业务不友好Slickflow强中中设计师可用办理台多自建5.3 移动应用引擎产品级移动常见落地领导批假体验Elsa弱偏中自研 H5 API/Webhook 恢复取决于项目组Workflow Core弱全自建差成本高WorkflowEngine.NET中自研或生态接企微/钉钉取决于项目组CCFlow中偏强与待办同一套流程语义相对少造轮子StepWise弱不适用审批移动差Slickflow中REST 自研移动壳取决于项目组公正提醒移动体验强依赖企微/钉钉/APP 通道。差别在于——待办语义能否直接复用还是移动端再实现一半审批逻辑。5.4 企业应用组织、权限、集成、可运营引擎组织岗位权限门户业务集成把请假做成企业制度系统Elsa弱外接弱偏中强活动/HTTP/消息适合已有企业中台Workflow Core弱弱中代码集成仅适合深嵌现有系统WorkflowEngine.NET中中强Action/插件中台 许可费场景CCFlow强Port强中偏强事件/WebApi/SQL适合作审批底座StepWise弱弱中代码/AI不建议当 OA 底座Slickflow中中强多种执行体嵌入业务系统很合适5.5 集团应用多组织 / 多公司引擎多组织模型流程模板分发集团请假制度落地Elsa中应用层租户自建中能做贵在治理Workflow Core弱弱基本靠自建WorkflowEngine.NET中中能做要自建组织治理CCFlow强集团版 OrgNo 等运行模式强主场之一StepWise弱弱不建议Slickflow中中可做产品化弱于 CCFlow6. 打分表请假交付视角相对分服务选型正式立项仍应 POC。StepWise 按「硬做请假」诚实打低分——不是否定其在 AI/步骤编排上的价值。维度权重ElsaWorkflow CoreWorkflowEngine.NETCCFlowStepWiseSlickflowS1 流程与分支15%8.57.58.58.55.08.5S2 表单附件枚举15%5.03.07.09.02.56.0S3 审批语义20%5.53.57.59.22.08.0S4 PC 应用15%6.02.57.59.03.56.5S5 移动应用15%4.52.05.58.02.05.5S6 企业应用10%6.54.07.08.53.57.0S7 集团应用10%5.02.55.58.82.05.5加权综合5.93.67.18.82.96.9维护、许可与资料不进加权必须看产品活跃度中文资料许可提示选型态度Elsa高中宽松开源常见编排短名单纯请假慎选Workflow Core中中宽松开源仅嵌入轻场景WorkflowEngine.NET中偏高中偏低生产多需商业许可可进短名单先算法务CCFlow中偏高国内交付向高以官方开源说明为准请假/OA 短名单StepWise中较新中以仓库为准不要当 OA 引擎选Slickflow中偏高高社区/商业线需分清BPMN 嵌入短名单一句话读表把请假当「可上线审批应用」CCFlow综合最高——表单/组织/门户算进了产品。把请假当「嵌入已有系统的 BPMN 流」Slickflow与WorkflowEngine.NET更贴后者看许可。把请假当「更大编排里的人工节点」Elsa合理别指望开箱 OA。Workflow Core能做流转做不齐「简单请假」的产品面。StepWise请假题上故意打低——防误选不是黑它做 AI 流水线。7. 实现成本对照把「简单」说透假设 2 名熟悉 .NET 的后端 1 名前端从零到「请假可试用」引擎相对工作量工作主要花在哪CCFlow低设计器配流程/表单/接收人少量测试Slickflow中流程与 API 较快表单门户移动要补WorkflowEngine.NET中设计器省事组织/移动/许可与集成Elsa中高Bookmark 与活动不难难在表单待办移动组织Workflow Core高几乎从零砌审批壳StepWise极高若坚持做 OA先造待办/退回/组织再谈请假公正补充若企业已有统一表单中心、组织中台、移动待办中台则 Elsa / Slickflow / WorkflowEngine.NET 的自建量会下降综合分应上调——这正是它们在「中台齐全」架构里仍然合理的原因。8. 选型建议按场景不捧杀8.1 决策树请假及同类审批是否必须尽快上线「员工能直接用的请假」且缺少表单/组织/门户 ├─ 是 → 优先 CCFlow └─ 否已有门户与组织中台 ├─ 要 BPMN 嵌入现有 .NET 业务 → Slickflow ├─ 要商业级设计器嵌入可接受许可费 → WorkflowEngine.NET ├─ 请假只是长编排中的人工节点 → Elsa ├─ 只要代码里嵌个状态机 → Workflow Core └─ AI/数据步骤流水线不是审批 → StepWise别拿来做请假主引擎8.2 分场景建议场景更稳妥的选择理由中肯版中小企业 / 政企 OA 请假、报销、用章CCFlow审批表单组织闭环PC/移动路径短已有业务系统只需嵌入标准流程引擎SlickflowBPMN API 清晰壳可复用现有 UI要漂亮设计器、插件式 Action预算含许可WorkflowEngine.NET组件质量高先算清授权微服务编排 偶发人工确认Elsa编排长板审批短板用外部待办补纯后台状态/Saga无领导审批 UIWorkflow Core够用就好别过度采购DAG / AI Agent 步骤StepWise对题与请假 OA 不是同一类题集团多公司审批平台CCFlow集团模式或其它引擎 自建组织治理前者产品化后者灵活但贵在治理8.3 与 Java 姊妹篇的对照读法避免误读分数诉求.NET 侧更贴Java 侧更贴姊妹篇开箱审批应用CCFlowJFlow标准引擎 自建壳Slickflow / ElsaFlowable / Camunda千万别误选StepWise 当 OAOpenWFE 等停更引擎当生产8.4 最终坦诚结论同一道简单请假题CCFlow、Slickflow、WorkflowEngine.NET、Elsa加自建都能工程化做完Workflow Core 能做「流转」但难算「交付」StepWise模型不对题。分水岭仍是你要的是流程引擎/编排库还是审批应用平台。前者Elsa / Workflow Core / Slickflow / WorkflowEngine.NET按嵌入深度与许可选。后者CCFlow。Slickflow是「不要 CCFlow 那种一体化、但又要正经审批引擎」时的重要备选——分数低于 CCFlow往往是因为表单/门户/集团开箱而不是引擎不会走网关。WorkflowEngine.NET能力与设计器值得认真评但许可必须进选型会议程否则 POC 通过也可能上不了生产。StepWise打低分是保护项目它很优秀只是不该出现在「请假 OA 短名单」第一页。9. 局限性声明本文是公开资料 统一需求推演不是厂商授权测评也不是性能测试报告。商业版能力未计入开源/社区版得分WorkflowEngine.NET 尤需按合同重评。CCFlow 章节结合本工作区公开示例与源码叙事其余以公开文档与通行落地方式为准。「集团应用」名词各异OrgNo / 租户 / 多公司上线前必须 POC 隔离与模板分发。与 Java 篇分数禁止直接横比——权重相同生态与人才池不同。附录 A请假主路径推荐建模语义是否填写申请单部门领导审批请假天数 5?总经理审批人力资源备案反馈给申请人结束附录 B需求→实现检查清单POC 用所有人可发起表单类型病假/婚假/事假、从/到、天数、原因、附件部门领导待办可批、可写意见天数 5出现总经理待办≤ 5不出现HR 备案可办申请人收到反馈PC 全流程可办结移动端至少完成审批动作集团场景组织 A 的单不可被组织 B 越权看到文档生成说明基于统一请假需求对 Elsa、Workflow Core、WorkflowEngine.NET、CCFlow、StepWise、Slickflow 的公开实现路径与场景适配做相对评价。选型请以 POC、许可与安全评估为准。