流程引擎控制表设计：为什么选择五表分立

本文以一套运行二十年的工作流引擎为样本，分析其五表分立的控制表设计，供做引擎设计的读者参考。

副标题：流程引擎与业务数据各安其位——该引擎 工作流控制表设计揭秘 系列：该平台 BPM 技术白皮书 · 1.6 关键词：五表分立、WF_GenerWorkFlow、待办驱动、业务报表、轨迹审计、中西方设计差异

引言：一张表装不下中国企业的流程

如果你打开 Activiti、Camunda 或 Flowable 的数据库，你会看到 ACT_RU_EXECUTION、ACT_RU_TASK、ACT_RU_VARIABLE 等高度抽象的运行时表——所有流程、所有业务，共用同一套"引擎骨架"。

如果你打开该平台工作流（该引擎）的数据库，你会看到另一幅图景：

• 全局两张"引擎脉搏表"：WF_GenerWorkFlow、WF_GenerWorkerList
• 每个流程一套业务报表表：NDxxRpt
• 每个流程一套轨迹表：NDxxxTrack
• 组织身份独立在 Port_* 体系中

这不是"表多"，而是二十余年中国企业流程交付沉淀出的设计选择：流程引擎管流转，业务数据管业务，组织身份管人，轨迹表管审计——五类表，各安其位。

本文结合 该引擎 源码（该引擎/Components/BP.WF）与前端实现（``），客观解析这套设计为何成立、与西方引擎有何本质差异，以及各自适合什么交付场景。

一、五表分立：该平台工作流的核心数据架构

该平台工作流将运行期数据划分为五个相互独立、通过 WorkID / OID 松耦合关联的层次：

┌─────────────────────────────────────────────────────────────────┐
│                    该平台工作流 · 五表分立模型                      │
├──────────────┬──────────────┬──────────────┬──────────┬─────────┤
│  ① 流程实例   │  ② 工作人员   │  ③ 业务数据   │ ④ 组织身份 │ ⑤ 轨迹  │
│ WF_Gener     │ WF_Gener     │ NDxxRpt      │ Port_*   │ NDxx    │
│ WorkFlow     │ WorkerList   │ (+节点表单)   │          │ Track   │
├──────────────┼──────────────┼──────────────┼──────────┼─────────┤
│ 流程跑到哪了  │ 谁在办、办没办 │ 表单采集了什么 │ 人/部门/岗 │ 历史操作 │
│ 状态/标题/节点│ 待办/已办/会签  │ 报表/查询/归档 │ 选人/权限  │ 审计/回溯 │
└──────────────┴──────────────┴──────────────┴──────────┴─────────┘
                              WorkID / OID 关联

1. WF_GenerWorkFlow —— 流程实例的"驾驶舱"

定位：存储流程引擎级别的运行摘要，一条记录对应一个流程实例（WorkID）。

核心字段（见 GenerWorkFlow.cs）：

设计意图：待办列表、流程监控、催办预警、子流程导航——凡"流程跑到哪了"的问题，查这一张表即可，无需扫描业务宽表。

在 WorkNode.cs 的发送逻辑中，节点流转时首先更新 GenerWorkerList.IsPass，再同步 HisGenerWorkFlow.WFState、FK_Node 等字段——引擎状态与业务表单写入解耦。

2. WF_GenerWorkerList —— 待办驱动的"任务脉搏"

定位：存储"谁在哪个节点办理哪条流程"的工作人员记录，是待办、已办、会签、队列审批的数据源。

核心字段（见 GenerWorkerList.cs）：

设计意图：

• 一人多条：会签、协作、子线程分流时，同一 WorkID 可有多条 GenerWorkerList 记录
• 待办查询极简：SELECT * FROM WF_GenerWorkerList WHERE FK_Emp=@emp AND IsPass=0 —— 无需 JOIN 复杂运行时表
• 与西方 ACT_RU_TASK 对比：该平台将"任务"与"流程实例摘要"物理分离，待办列表不携带流程全量字段，列表查询更轻

前端 TimeBase.vue、CH.vue、Track.vue 均直接消费 WF_GenerWorkerList 数据集，印证其作为待办/轨迹展示的一等公民地位。

3. NDxxRpt* —— 业务数据的"报表视图"

定位：每个流程对应一张（或多张）业务物理表，命名规则 ND{流程编号}Rpt，承载表单采集的业务字段 + 流程系统字段的汇总镜像。

典型字段（见 GERpt.cs / GERptAttr）：

设计意图：

1. 报表友好：国企、政府、制造等场景大量需要"按部门/按月份/按状态查流程业务数据"——直接 SELECT 物理宽表，无需从 ACT_RU_VARIABLE 解析 JSON
2. 节点表单 → 报表自动同步：FlowCheckError.cs 在流程检查时将各节点表单字段合并到 NDxxRpt，保证报表字段与表单一致
3. 与节点表单表（NDxx01、NDxx02…）分工：节点表存各节点填报快照，NDxxRpt 存流程级汇总——适合列表查询与归档

前端 SearchFlow.vue 的流程查询直接调用 WF_Rpt.SearchFlow_Init，以 NDxxRpt 为主数据源；当业务表无 Title 列时，再回查 WF_GenerWorkFlow 补标题——业务查询与引擎摘要按需组合，而非硬绑一张大表。

4. Port_* —— 组织身份的"人员底座"

定位：存储人员、部门、岗位、用户组等组织标识信息，如 Port_Emp、Port_Dept。

设计意图：

• 流程引擎不内嵌组织架构，而是通过 Port_* 引用——组织变更时不必动流程引擎表
• 选人、按部门过滤、拼音检索（WF_WorkOpt.cs 中 Port_Emp + Port_Dept 联查）均依赖此体系
• 与 WF_GenerWorkerList.FK_Emp 形成"身份 → 待办"的清晰链路

5. NDxxxTrack* —— 轨迹审计的"按流分表"

定位：每个流程独立一张轨迹表，命名 ND{流程编号}Track，记录发送、退回、移交、抄送、审核意见等历史操作。

典型操作（WorkNode.AddToTrack / Glo.AddToTrack）：

• ActionType.Forward —— 发送
• ActionType.Return —— 退回
• ActionType.UnSend —— 撤销
• ActionType.WorkCheck —— 审核
• ActionType.CC —— 抄送

设计意图：

• 按流程分表：轨迹数据量随企业运行线性增长，按流程物理隔离便于归档、清理、分区
• 审计合规：政府、金融、能源等行业对"谁在何时做了什么"有强合规要求——轨迹表专表专用，不被业务字段污染
• 前端 Track.vue 读取 NDxxTrack 绘制流程图高亮与时光轴，WorkCheckParseTrack.vue 解析审核轨迹——展示层直接映射物理轨迹表

二、为何这样设计：问题驱动的东方思路

2.1 中西方设计者思维的不同

西方设计深受 BPMN 标准 与 Unix 哲学（做一件事并做好）影响：引擎只负责状态机流转，表单、报表、组织由周边系统提供。这是"集成型工作流"思维。

东方设计深受 OA/ERP 一体化交付 影响：客户采购的不是"流程引擎许可证"，而是"请假能批、采购能查、公文能追溯"的完整系统。这是"交付型工作流"思维。

2.2 交付目的不同

结论并非"谁更好"，而是"为谁交付"。 西方引擎是优秀的流程中间件；该平台是优秀的流程应用平台。

三、与西方工作流引擎的客观对比

3.1 西方引擎典型表结构（以 Activiti/Camunda 为例）

ACT_RE_PROCDEF     — 流程定义
ACT_RU_EXECUTION   — 运行时执行实例
ACT_RU_TASK        — 运行时用户任务
ACT_RU_VARIABLE    — 运行时变量（业务数据常在此）
ACT_HI_PROCINST    — 历史流程实例
ACT_HI_TASKINST    — 历史任务
ACT_HI_VARINST     — 历史变量

设计特征：

1. 统一运行时模型：所有流程实例挤入同一套 ACT_RU_* 表
2. 业务数据变量化：表单字段以 name-value 存入 ACT_RU_VARIABLE，查询报表需解析或同步到外部库
3. 历史与运行分离：RU vs HI 两套表，归档时数据搬迁
4. 任务即待办：ACT_RU_TASK 同时承担"任务分配"职责

3.2 该平台五表分立 vs 西方统一抽象

3.3 代码结构印证：后端分层清晰

该引擎/Components/BP.WF 目录结构体现了"引擎 / 业务 / 组织"的分工：

BP.WF/
├── WF/
│   ├── GenerWorkFlow.cs      ← ① 流程实例
│   ├── GenerWorkerList.cs    ← ② 工作人员/待办
│   ├── GERpt.cs              ← ③ 业务报表实体
│   ├── WorkNode.cs           ← 发送内核（协调五表写入）
│   ├── WorkUnSend.cs         ← 撤销（回滚 WorkerList + Track）
│   └── Flow.cs               ← 流程元数据 + Rpt 同步
├── HttpHandler/
│   ├── WF_MyFlow.cs          ← 发起/办理
│   ├── WF_WorkOpt.cs         ← 发送/退回/轨迹
│   └── WF_Rpt.cs             ← 报表查询
└── Dev2Interface.cs          ← 对外 API 统一入口

WorkNode.cs 的发送方法（约 2700+ 行起）典型执行顺序：

1. 更新当前节点 GenerWorkerList.IsPass = 1
2. 更新 GenerWorkFlow 状态与当前节点
3. 为目标节点插入新 GenerWorkerList 待办
4. 同步 NDxxRpt 流程系统字段
5. 调用 AddToTrack 写入 NDxxTrack

五表在同一事务语义下协作，但物理上互不污染。

3.4 前端印证：按数据职责分模块

`` 前端结构同样映射五表分工：

WF/
├── MyFlow*.vue           ← 办理页（读 GenerWorkFlow + 节点表单）
├── WorkOpt/
│   ├── Send.ts           ← 发送（写 WorkerList + Track）
│   ├── OneWork/
│   │   ├── Track.vue     ← 轨迹图（读 NDxxTrack + GenerWorkerList）
│   │   └── TimeBase.vue  ← 时光轴（读 Track + GenerWorkFlow）
│   └── WorkCheck*.vue    ← 审核意见（写 Track）
├── Rpt/
│   └── SearchFlow.vue    ← 流程报表（读 NDxxRpt，按需补 GenerWorkFlow）
└── CCForm/               ← 表单引擎（读写节点业务表 NDxx01…）

前端从不假设"一张大对象包含所有数据"，而是按场景组装不同表的数据集——这与五表分立架构高度一致。

四、该平台设计的核心优点

4.1 性能：该快的查询真的快

• 待办列表：GenerWorkerList 单表索引查询，不 JOIN 业务宽表
• 轨迹归档：NDxxTrack 按流程分表，历史数据可按流程整体迁移
• 报表统计：NDxxRpt 直接 SQL 聚合，无需从变量表反序列化

4.2 可维护：职责边界清晰

• 业务顾问改表单字段 → 影响 NDxx01 / NDxxRpt，不动引擎表
• 流程顾问改节点路由 → 影响 WF_Node 模板，不动业务数据
• 组织管理员改部门 → 影响 Port_*，不动流程实例

4.3 可交付：二十年场景沉淀

会签、加签、队列、子线程、分流合流、父子流程、抄送、移交、催办、挂起——这些中国企业高频场景，在 GenerWorkerList 的 IsHuiQian、Idx、FID 及 WorkNode 发送逻辑中都有直接映射，而非靠 BPMN 扩展硬拗。

4.4 可审计：轨迹专表专用

NDxxTrack 记录完整操作链，前端 Track.vue 支持退回记录、撤销记录独立展示——满足政务、国企审计要求。

4.5 可扩展：松耦合关联

五表通过 WorkID / OID 关联，而非外键强绑——第三方系统可通过 Dev2Interface.cs 只读写所需表，实现渐进式集成。

五、客观结论：没有银弹，只有匹配场景的选择

5.1 该平台五表分立更适合

• 以项目交付为主的乙方实施团队
• 需要表单 + 流程 + 报表一体化落地的甲方信息中心
• 复杂中国特色审批场景（会签、多级分流、公文流转）
• 私有化部署、信创数据库、数据归档合规要求高的行业
• 业务人员需要自主配置而非依赖研发排期

5.2 西方统一抽象更适合

• 已有成熟业务系统，仅需嵌入"流程编排"能力
• 云原生微服务架构，流程引擎作为独立中间件
• 强依赖 BPMN 2.0 标准与跨引擎迁移
• 研发团队主导，业务人员不参与配置

5.3 一句话总结

西方引擎用"统一的抽象"换"集成的自由"；该平台用"五表的分立"换"交付的效率"。

二十余年、数千家企业、政府与大型集团的运行验证，证明这套设计在中国企业的土壤中是经过实战检验的。它不是学术上的最优解，而是交付上的最优解。

六、附录：五表关键 SQL 场景速查

-- ① 我的待办
SELECT gwl.*, gwf.Title, gwf.StarterName
FROM WF_GenerWorkerList gwl
JOIN WF_GenerWorkFlow gwf ON gwl.WorkID = gwf.WorkID
WHERE gwl.FK_Emp = @EmpNo AND gwl.IsPass = 0 AND gwl.IsEnable = 1;

-- ② 流程监控（运行中）
SELECT * FROM WF_GenerWorkFlow
WHERE FK_Flow = @FlowNo AND WFState = 2;

-- ③ 业务报表（以流程 001 为例）
SELECT * FROM ND001Rpt
WHERE WFState = 3 AND FK_Dept = @DeptNo;

-- ④ 轨迹回溯（以流程 001 为例）
SELECT * FROM ND001Track
WHERE WorkID = @WorkID
ORDER BY RDT;

-- ⑤ 组织选人
SELECT e.No, e.Name, d.Name AS DeptName
FROM Port_Emp e
JOIN Port_Dept d ON e.FK_Dept = d.No
WHERE e.Name LIKE '%' + @Keyword + '%';

推荐阅读

• 该平台工作流官网：https://该引擎.cn
• 源码仓库：该引擎/Components/BP.WF — 工作流引擎核心
• 前端实现：`` — 流程办理与报表
• 系列上一篇：流程设计器与表单设计器一体化交付实践

本文基于 该引擎 开源代码客观分析撰写，旨在帮助架构师与实施顾问理解该平台工作流的数据设计哲学，做出匹配自身场景的技术选型。