驰骋BPM四大流程模式与Flowable-Camunda对比选型指南

线性到父子流程：驰骋 BPM 四大流程模式源码解读，及与 Flowable/Camunda 的选型指南

导读

在企业 OA、ERP 审批、项目管理等场景中，线性审批只是起点。真正考验工作流引擎的，是：

• 一笔采购拆成多部门并行处理（分合流）
• 各部门填同一张表还是各自独立表单
• 主流程等待子项目、子合同子流程结束再继续

驰骋 BPM（CCFlow / JFlow）将上述能力抽象为四大流程运行模式，并在 WorkNode.NodeSend() 的 5×5 路由算法中落地。Flowable / Camunda 则用 BPMN 2.0 的 Parallel Gateway、Multi-Instance、Call Activity 等标准元素实现类似能力。

本文从源码出发，对照 Flowable/Camunda 架构，梳理前后端实现、优劣势，并给出倾向选择 CCFlow/JFlow 的选型结论。

一、概念澄清：驰骋的「四大流程模式」是什么？

驰骋在节点级别通过 RunModel（运行模式）和 NodeType（节点类型）描述流程拓扑，面向业务人员的四大模式如下：

说明：引擎内部还有 分流（FL）、合流（HL）、分合流（FHL） 三种路由节点形态（RunModel 1/2/3），它们是实现「分合流」的拓扑基础，与上述四大模式配合使用，而非并列的第四种业务形态。

枚举定义（后端）：

    /// <summary>
    /// 运行模式
    /// </summary>
    public enum RunModel
    {
        Ordinary = 0,          // 普通/线性
        HL = 1,                // 合流
        FL = 2,                // 分流
        FHL = 3,               // 分合流
        SubThreadSameWorkID = 4, // 同表单子线程
        SubThreadUnSameWorkID = 5 // 异表单子线程
    }

    public enum NodeType
    {
        UserNode = 0,
        RouteNode = 1,
        CCNode = 2,
        SubFlowNode = 3,       // 子流程节点
    }

前端流程设计器（FlowDesignerV2）将上述模式映射为可拖拽图元：

二、四大模式技术实现（驰骋源码）

2.1 总体执行架构

驰骋流程发送的核心入口是 WorkNode.NodeSend()，采用三阶段处理：

1. 发送前检查：权限、表单、条件
2. 5×5 路由算法：按源节点 RunModel × 目标节点 RunModel 分支
3. 发送后业务：抄送、子流程、事件、数据汇总

        /// 1，方法体分为三大部分: 发送前检查\5*5算法\发送后的业务处理.

关键实例字段：

2.2 模式一：线性流程（Ordinary）

业务特征

最常见的串行审批：发起 → 部门审批 → 领导审批 → 归档。

后端实现

• 节点 HisRunModel = Ordinary，HisNodeWorkType = Work（或 StartWork）
• 发送时走 NodeSend_11()：计算下一节点 → FindWorker 找人 → 写 GenerWorkerList 待办

            switch (this.HisNode.HisRunModel)
            {
                case RunModel.Ordinary:
                    Node toND = this.NodeSend_GenerNextStepNode();
                    ...
                    switch (toND.HisRunModel)
                    {
                        case RunModel.Ordinary:
                            this.NodeSend_11(toND);
                            break;

对比 Flowable / Camunda

两者在线性场景能力相当；Flowable 以 BPMN 图表达，驰骋以 WF_Node + WF_Direction 关系表表达。

2.3 模式二：同表单分合流（SubThreadSameWorkID）

业务特征

一张主表（如采购申请单），按明细行或按部门拆成多条并行子线程，各线程处理人不同，但共享同一份主表数据，合流后继续主流程。

典型场景：采购明细按供应商分给不同采购员并行询价，合流后统一审批。

后端实现

拓扑要求：分流点（FL/FHL）→ 同表单子线程节点 → 合流点（HL/FHL）

FID 机制：子线程 Work.FID = 干流程 WorkID，多个子线程共享数据上下文。

        /// 处理分流点向下发送 to 同表单.
        private void NodeSend_24_SameSheet(Node toNode)
        {
            Work wk = toNode.HisWork;
            wk.Copy(this.rptGe);
            wk.Copy(this.HisWork);
            wk.FID = this.WorkID; // 把该工作FID设置成干流程上的工作ID
            town = new WorkNode(wk, toNode);
            current_gwls = this.Func_GenerWorkerLists(town);

找人策略（DeliveryWay）支持：

• ByDtlAsSubThreadEmps：按上一节点明细表字段确定子线程接收人
• BySQLAsSubThreadEmpsAndData：按 SQL 确定接收人与子线程数据

前端配置入口：Vue3/src/WF/Admin/AttrNode/AccepterRole/GPE_AccepterRole.ts

对比 Flowable / Camunda

差异：驰骋将「同表单 + FID」作为一等公民，表单引擎 Sys_MapData 原生识别 FID 字段；Flowable 需自行设计流程变量与表单绑定，明细表驱动多实例需额外开发。

2.4 模式三：异表单分合流（SubThreadUnSameWorkID）

业务特征

分流后各子线程使用不同表单（甚至不同 WorkID），并行处理后合流。例如：项目立项后，技术、财务、法务各自填独立审批表。

后端实现

核心方法 NodeSend_24_UnSameSheet(Nodes toNDs)：

• 为每个子线程节点创建独立 GenerWorkFlow 实例
• USSWorkIDRole 控制 WorkID 生成规则：
  • 0：同一节点仅生成一个 WorkID（多人共享）
  • 1：按接收人各生成一个 WorkID
• 子线程通过 FID 关联干流程

        /// 处理分流点向下发送 to 异表单.
        private void NodeSend_24_UnSameSheet(Nodes toNDs)
        {
            GenerWorkFlows gwfThreads = new GenerWorkFlows();
            gwfThreads.Retrieve(GenerWorkFlowAttr.FID, this.WorkID);
            ...
                if (nd.USSWorkIDRole == 0)
                {
                    ...
                    if (workIDSubThread == 0)
                        workIDSubThread = DBAccess.GenerOID("WorkID");

发送时 FID/WorkID 切换逻辑（子线程 ↔ 合流点）：

            // 是否是分流到子线程
            if (this.HisNode.ItIsFLHL == true && town.HisNode.ItIsSubThread == true)
            {
                nextUsersWorkID = 0;
                nextUsersFID = this.WorkID;
            }
            // 子线程到合流点
            if (this.HisNode.ItIsSubThread == true && town.HisNode.ItIsFLHL == true)
            {
                nextUsersWorkID = this.HisWork.FID;
                nextUsersFID = 0;
            }

对比 Flowable / Camunda

差异：驰骋在合流点内置异表单向合流节点明细表的数据汇总（CheckFrmHuiZongToDtl）；Flowable/Camunda 无内置表单汇总，需自定义 Listener 或外部服务。

2.5 模式四：父子流程（SubFlowNode）

业务特征

主流程某一节点触发完整子流程，子流程结束后父流程才继续。支持：

    public enum SubFlowModel
    {
        SubLevel,   // 下级
        SameLevel,  // 同级
    }

后端实现

子流程启动（WF_WorkOpt.SubFlowGuid_Send）：

        public void SendSingleSubFlow(SubFlowHand subFlowH, Hashtable ht, GenerWorkFlow gwf)
        {
            if (subFlowH.SubFlowModel == SubFlowModel.SubLevel)
                workidSubFlow = BP.WF.Dev2Interface.Node_CreateBlankWork(..., this.WorkID, this.FID, ...);
            if (subFlowH.SubFlowModel == SubFlowModel.SameLevel)
                workidSubFlow = BP.WF.Dev2Interface.Node_CreateBlankWork(..., gwf.PWorkID, gwf.PFID, ...);
            BP.WF.Dev2Interface.SetParentInfo(subFlowH.SubFlowNo, workidSubFlow, ...);
            BP.WF.Dev2Interface.Node_SendWork(subFlowH.SubFlowNo, workidSubFlow);

父流程等待规则（SubFlowRunModel）：子流程全部结束 / 到达指定节点后，父流程才发送。

子流程启动后，父流程当前待办可设为不可见（IsPass=80），用户从在途查看进度。

对比 Flowable / Camunda

差异：驰骋父子流程与表单数据反填规则（BackCopyRole：自动字段匹配、按格式匹配、混合模式）深度集成；Flowable Call Activity 只做流程层面嵌套，业务数据回填需额外开发。

三、四大模式与 Flowable/Camunda 对照总表

四、前端代码结构梳理

4.1 技术栈

Vue 3 + Vite + TypeScript + Ant Design Vue + AntV X6（流程设计器）

4.2 与四大模式相关的前端模块

4.3 设计器如何落地 RunModel

设计器保存节点时写入 RunModel 字段，与后端 WF_Node.RunModel 一致：

// FlowDesignerV2/shapes/index.ts
{ label: '线性', attrs: { typeInfo: { mode: 0 } } }
{ label: '分流', attrs: { typeInfo: { mode: 2 } } }
{ label: '合流', attrs: { typeInfo: { mode: 1 } } }
{ label: '同表单', attrs: { typeInfo: { mode: 4 } } }
{ label: '异表单', attrs: { typeInfo: { mode: 5 } } }

4.4 办理页 FID 传递

分流场景下，前端需正确传递 FID（干流程）与 WorkID（子线程）：

            if ((currND.HisRunModel == RunModel.FL || currND.HisRunModel == RunModel.FHL) && this.FID != 0)
                urlExt += "WorkID=" + this.FID + "&SubWorkID=" + this.WorkID;

审核轨迹前端区分动作类型：

• ActionType.ForwardFL — 分流前进
• ActionType.ForwardHL — 合流前进
• ActionType.SubThreadForward — 子线程前进

4.5 前后端通信

统一通过 HttpHandler 调用后端 Handler：

const handler = new HttpHandler('BP.WF.HttpHandler.WF_MyFlow');
handler.AddPara('WorkID', workID);
handler.AddPara('FID', fid);
const data = await handler.DoMethod('MyFlow_Init');

五、后端代码结构梳理

5.1 项目分层

CCFlow/CCFlow/                          → Web 宿主、API Controller
CCFlow/Components/BP.WF/                → 流程引擎核心
  ├── WF/WorkNode.cs                    → 发送引擎（5×5 算法）
  ├── WF/GenerWorkFlow.cs               → 流程实例
  ├── WF/GenerWorkerList.cs             → 待办任务
  ├── WF/WorkUnSend.cs                  → 撤销/退回
  ├── Template/FindWorker.cs            → 找人（含子线程策略）
  ├── Template/SFlow/                   → 子流程配置
  ├── Dev2Interface.cs                  → 对外 SDK
  └── HttpHandler/WF_MyFlow.cs          → 办理页接口
CCFlow/Components/BP.En30/              → 实体框架、表单引擎

5.2 四大模式关键类与方法

5.3 对外集成 API

JFlow 侧与 CCFlow 同源设计（类名、方法名、表结构一致），Java 团队可无缝使用相同模式语义。

六、优势与不足

6.1 驰骋 BPM（CCFlow/JFlow）优势

6.2 驰骋 BPM 不足

6.3 Flowable/Camunda 优势

6.4 Flowable/Camunda 不足（相对驰骋四大模式场景）

七、如何选择工作流引擎？

7.1 决策矩阵（围绕四大模式）

7.2 决策树

您的流程是否涉及「分流 + 多表单 + 合流汇总」或「父子流程数据反填」？
├── 是 → 强烈推荐 CCFlow / JFlow
│   ├── .NET 技术栈 → CCFlow
│   └── Java 技术栈  → JFlow
└── 否 → 是否以 BPMN 标准 / 微服务编排为核心？
    ├── 是 → Flowable 或 Camunda
    └── 否 → 是否需要完整 OA（表单+组织+权限）？
        ├── 是 → CCFlow / JFlow（BPM 模式）
        └── 否 → 按团队技术栈在 Flowable 与 CCFlow 间选择

7.3 倾向选择 CCFlow / JFlow 的结论

综合源码分析与四大模式对照，在中文企业审批、OA、项目协同场景下，应优先选择 CCFlow / JFlow，理由如下：

1. 四大模式是引擎内核，不是扩展包
   线性、同表单分合流、异表单分合流、父子流程均有专属发送路径（NodeSend_11 / _24_SameSheet / _24_UnSameSheet / SendSingleSubFlow），落地成本远低于在 Flowable 中拼装 Gateway + Multi-Instance + Call Activity + 自定义 Listener。

2. 表单是分合流的灵魂
   驰骋 Sys_MapData 与 FID、PWorkID 原生配合，明细表驱线程、合流汇总、子流程反填均为配置级能力；Flowable/Camunda 无表单引擎，四大模式落地周期通常延长 2~5 倍。

3. JFlow 与 CCFlow 同源，投资可迁移
   类名、表结构、模式语义一致，.NET 与 Java 项目可共享流程设计经验与实施方法论。

4. Flowable/Camunda 的适合边界清晰
   当核心诉求是纯 BPMN 编排、微服务 Choreography、超高吞吐、DMN 决策时，选择 Flowable/Camunda；当核心诉求是复杂审批 + 表单 + 中国特色分合流/子流程时，选择驰骋。

5. 中间件模式降低嵌入门槛
   若只需四大模式中的线性 + 简单并行，可通过 Toolkit SDK 嵌入现有 ERP，无需全盘替换。

一句话结论：
「分合流 + 多表单 + 子流程」是中国 OA 的刚需，这是 CCFlow/JFlow 的设计原点，也是 Flowable/Camunda 需要大量定制才能补齐的短板。

八、附录：关键代码索引

九、参考文献

• 驰骋 BPM 官网：https://ccbpm.cn/
• Flowable 用户手册：https://www.flowable.com/open-source/docs/
• Camunda BPMN 参考：https://docs.camunda.io/
• BPMN 2.0 规范（并行网关 / 多实例 / 调用活动）：https://www.omg.org/spec/BPMN/

本文基于 CCFlowWorkSpace 仓库静态分析生成。JFlow 与 CCFlow 在四大流程模式上保持架构同源，具体 API 以各平台官方文档为准。