六款 .NET 工作流引擎：二开能力怎么比

六款 .NET 工作流引擎：二开能力怎么比

对比对象：Elsa Workflows、Workflow Core、WorkflowEngine.NET、StepWise、CCFlow、Slickflow
资料依据：各产品公开文档 / GitHub / 官方站点，
写作原则：先统一「二开」定义，再按同一维度对照；有优势写优势，有短板写短板；不因场景不同而强行打成「总分第一」

一、先说清楚：什么叫「流程引擎的二开」

1.1 定义（本文口径）

流程二开 = 流程设计（或代码定义）完成后，在不改引擎内核的前提下，用脚本 / 代码 / 配置与引擎交互，把业务逻辑挂到固定生命周期点上的过程。

典型动作：发送前校验、发送后同步第三方、退回拦截、流程结束写台账、自定义活动节点、自定义设计器控件等。

1.2 二开范围（纳入 / 不纳入）

为避免「什么都能叫二开」导致对比失真，本文把二开拆成 6 个可核对能力面：

明确不纳入「二开能力」本身、但会影响选型的因素（文末单独提示）：许可费用、社区活跃度、是否内置表单/组织门户。这些会影响「能不能用二开把项目做完」，但不是二开机制本身的强弱。

1.3 公平原则（阅读说明）

1. 定位不同，不能只比「有没有审批」：Elsa / Workflow Core / StepWise 更偏编排；CCFlow / Slickflow 更偏 BPM；WorkflowEngine.NET 偏可嵌入商业引擎。
2. 「能扩展」≠「开箱就是审批系统」：例如 Elsa 可用 Bookmark 做人工等待，但会签/加签/组织待办通常要自建。
3. CCFlow 章节结合本仓库源码举证；其余产品以公开文档为准，不臆造未公开能力。
4. StepWise 纳入对比是为防误选：它是代码优先的步骤/AI 任务编排框架，不是传统 OA/BPM 引擎。

二、六款产品定位一览（二开语境）

三、二开能力总对照表（同一维度）

评级口径：强 = 产品级、文档/样例完整；中 = 能做但需自建较多；弱 = 基本不覆盖或需从零实现。评级是机制完整性，不是「业务场景总分」。

一句话读表

四、分引擎：二开机制怎么落地（公开资料摘要）

4.1 Elsa Workflows

适合的二开场景：微服务编排、Webhook/长事务、领域自定义活动库。
不太适合指望「只配不写」的：政企审批实施团队纯配置交付。

4.2 Workflow Core

适合：嵌入现有系统做状态机/后台编排。
不适合：指望「设计器 + 事件配置」完成项目交付。

4.3 WorkflowEngine.NET（OptimaJet）

适合：要嵌入高质量设计器 + Action 扩展的商业项目。
选型时必须单独评估：许可成本与锁定风险。

4.4 StepWise

适合：数据分析、批处理、AI Agent 步骤流。
误选风险：名字像工作流，但交付审批系统会从零造轮子。

4.5 Slickflow

适合：要 BPMN + 节点级服务调用、以 API 嵌入业务系统。
相对弱于 CCFlow 的点：前后端统一事件协议、低代码事件配置与表单一体化深度。

4.6 CCFlow（结合本仓库）

五、CCFlow 三种二开方式（结合代码）

驰骋 BPM 的主张可以概括为：

流程可以设计出来，业务却不能写进引擎内核。
同一套事件语义，三种写法：前端外挂、后端外挂、事件配置。

5.1 三种模式总览

运行时分层（示意）：

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

5.2 模式一：前端外挂

意图：人还在页面上时，做校验、提示、按钮与交互定制。

约定：类名必须以 WGFlow_ 开头，并绑定流程号。

  protected constructor(classID: string, flowNo: string) {
    if (classID.includes('WGFlow_') == false) {
      message.warning('外挂类名[' + classID + ']不符合规范,必须是以 WGFlow_ 开头.');
      return;
    }
    super(classID);
    this.FlowNo = flowNo;
  }

Demo（流程 064）：发送前可返回 err@... 阻断发送；发送成功后再做前端副作用。

export class WGFlow_064 extends WaiGuaBaseFlow {
  constructor() {
    super('WGFlow_064', '064'); //注册到 064模板的流程上.
  }
  // ...
  protected override async SendWhen() {
    if (this.NodeID == 6401) {
      const msg = `
      ##### 提示信息
      1. 成功激活了/src/App/Demo/WGFlow_064.ts 的 SendWhen事件.
      2. 如果return err@xxxxxxx 则流程不向下发送.
      `;
      return msg;
    }
    return '';
  }

工具栏实际调用链见 Vue3/src/WF/ToolBar.vue（先 SendWhen / beforeSend，服务端成功后再 SendSuccess / afterSend）。

5.3 模式二：后端外挂

意图：进入服务端生命周期后，用可调试的强类型代码介入；可改跳转节点/接收人，可同步第三方。

基类约定（源码注释原文要点）：

1. 子类重写事件方法与基类交互
2. 一个子类必须与一个流程模版绑定（FlowMark）
3. 基类暴露运行时变量辅助复杂逻辑
4. 类需进入 BP.*.dll 才能被反射解析

Demo：

    public class F065 : FlowEventBase
    {
        public override string FlowMark
        {
            get { return ",065,"; }
        }
        public override string SendWhen()
        {
            if (1 == 3)
                return "err@不符合流程发起条件，阻止流程发送。";
            if (1 == 1)
                return "后端外挂 /App/Demo/F065 SendWhen 已经执行成功,节点ID:" + this.HisNode.NodeID + ",WorkID:" + this.WorkID;
            // ...
        }

全局级还可改 OverrideEvent（消息通道、统一策略等），属于平台定制层，与流程级 FlowEventBase 分层。

5.4 模式三：事件配置

意图：实施人员在设计器挂 SQL / WebApi / 过程 / 已有事件类 / 业务单元，少写专用 DLL。

业务单元基类说明：

    /// 1. 重写该类为业务单元子类.
    /// 2. 每个业务单元子类可以在流程事件节点时间设置.
    /// 3. 被继承的子类的必须在BP.*.DLL 里面,才能确保设置时候被映射到.
    /// 4. 子类在DoIt方法中根据WorkID 的书写业务逻辑.

配置侧事件实体：BP.En30/Sys/FrmEvent.cs；管理端事件列表：Vue3/src/WF/Admin/FrmLogic/MapData/FrmEvent/。
也可把可复用逻辑写成 EventBase 子类（如 BP.App/Demo/Event/EventDemo.cs），在配置里按事件源分支处理 SendWhen / SendSuccess / FlowOverAfter 等。

5.5 三种模式如何选型（CCFlow 内部）

5.6 CCFlow 二开相关源码索引

六、横向对比：同一业务诉求，各引擎怎么挂

以高频诉求「发送前校验 + 发送后同步外部系统」为例：

再以「自定义一个可复用的流程积木」为例：

七、综合判断（中肯结论）

7.1 不要用一张「总分表」掩盖场景

7.2 二开机制上的「强项地图」（非营销排名）

7.3 对 CCFlow 的公正边界

做得好的：把「流程二开」定义清楚，并用前端外挂、后端外挂、事件配置三条路径落地；事件与消息共用时钟但职责分离；本仓库有可运行 Demo（WGFlow_064、F065、EventDemo）。

需要承认的：若目标是「像 Elsa 一样沉淀跨项目的自定义 Activity NuGet 生态」，CCFlow 不是同一叙事；它赢在审批生命周期上的业务挂接与低代码配置，而不是通用编排积木市场。

7.4 选型前建议自问的三句话

1. 我的「流程」是 审批待办，还是 服务编排/任务图？
2. 二开主力是 前端、后端，还是实施配置？
3. 能否接受 商业许可 或 自建表单/组织/移动？

答完这三句，六款产品的二开对比基本就不会选错赛道。

八、资料来源（便于复核）

附录：与「改引擎」相关的红线（通用建议）

文档定位：二开机制对比与选型辅助，不是性能测试报告，也不是商务招标评分表。具体 API 以各产品当期文档与源码为准。