工作流引擎的七项产品化能力：从数据表设计到父子流程编排

原创

驰骋工作流程

发布于 2026-10-05 10:19:46

930

判断一套 BPM 引擎是否“厚”，要看它把多少审批语义做成了可配置项。本文从数据表分工、组织找人、属性产品化、二开模式与父子编排五个角度做工程拆解，并说明适用边界。

阅读说明

「护城河」在本文中指：经过长期交付沉淀、难以用「画布 + 几个钩子」短期补齐的产品能力面。这些能力并非玄学，而是可在表结构、枚举、事件基类与 API 上逐条核对的工程事实。

能力面	一句话	主要代码锚点
流程引擎五表	实例 / 待办 / 业务 / 组织 / 轨迹各安其位	GenerWorkFlow、GenerWorkerList、GERpt、Port_*、Track
组织结构集成	五表组织模型 + 视图/API 对接	BP.Port.*、OrganizationAPI
二开模式	前端外挂 / 后端外挂 / 事件配置	FlowEventBase、ExecEvent、平台系统表
表单引擎	低代码与高代码双轨，节点可绑多方案	FrmType、NodeFormType、FlowDevModel
节点/流程属性	设计器可配的运行语义产品化	NodeAttr、FlowAttr、NodeExt、FlowExt
接收人规则	DeliveryWay 枚举驱动的找人引擎	FindWorker、DeliveryWay
父子流程	手工 / 自动 / 延续三类，实例级关联	SubFlowType、平台配置实体、Dev2Interface

客观边界：BPMN 标准引擎（如 Flowable、Camunda）在标准元素与生态工具链上另有优势；该平台更偏表单驱动 + 中国式审批语义产品化。选型应看场景，而非总分叙事。

一、流程引擎五表：控制与业务分立

1.1 设计主张

西方引擎常见做法是：执行实例、任务、变量高度抽象到统一运行时表（如 ACT_RU_*）。该平台的选择不同：引擎控制表管「跑到哪、谁在办」；业务宽表管「填了什么」；组织表管「人是谁」；轨迹表管「做过什么」——五类表松耦合，用 WorkID / OID 关联。

┌──────────────┬──────────────┬──────────────┬──────────┬─────────┐
│ ① 流程实例    │ ② 工作人员    │ ③ 业务数据    │ ④ 组织身份 │ ⑤ 轨迹  │
│ WF_Gener     │ WF_Gener     │ NDxxRpt      │ Port_*   │ NDxx    │
│ WorkFlow     │ WorkerList   │ (+节点表单)   │          │ Track   │
├──────────────┼──────────────┼──────────────┼──────────┼─────────┤
│ 状态/标题/节点 │ 待办/已办/会签 │ 报表/查询/归档 │ 人/部门/岗 │ 审计回溯 │
└──────────────┴──────────────┴──────────────┴──────────┴─────────┘

注意：仓库文档里还有「组织 Port 五表」说法（人员/部门/岗位/部门人员/部门岗位人员）。本文「流程引擎五表」指运行期控制与业务分立，二者勿混用。

1.2 五表职责（可核验）

#	表	实体	回答的问题
1	平台配置实体	引擎内核命名空间	这条流程实例现在在哪、什么状态、标题是什么
2	平台配置实体	引擎内核命名空间	谁在办、办没办、何时到期
3	ND{FlowNo}Rpt	GERpt	业务字段汇总与流程系统字段镜像，便于报表
4	Port_*	BP.Port.*	选人与权限所依赖的组织身份
5	ND{FlowNo}Track	Track	发送/退回/移交等操作轨迹（按流程分表）

发送路径的大致协作（文档与 WorkNode 发送逻辑一致）：更新工作者 IsPass → 更新实例状态与当前节点 → 写入新待办 → 同步业务报表 → 追加轨迹。

1.3 工程价值与边界

价值	说明
待办查询轻	平台配置实体按人 + IsPass 即可取待办，不必扫变量表
报表友好	政企场景大量「按部门/月份/状态查业务」，物理宽表比变量 JSON 更直接
组织可替换	引擎不把组织硬编码进流转表，便于对接 HR

边界	说明
表数量随流程增长	每流程有 Rpt / Track 等，运维需接受「按流分表」而非「一张万能表」
与 BPMN 运行时模型不同	迁移标准引擎项目时，要做控制表语义映射，而不是字段一一对应

二、组织结构集成：选人与权限的底座

2.1 组织核心五表

流程能不能「找对人」，取决于组织模型是否稳定、可对接。该平台组织底座为：

表	类	作用
Port_Emp	Emp	人员；主部门 FK_Dept
Port_Dept	Dept	部门树（ParentNo）
Port_Station	Station	角色/岗位
Port_DeptEmp	DeptEmp	一人多部门
Port_DeptEmpStation	DeptEmpStation	部门 × 岗位 × 人员（按「本部门某角色」找人的数据基础）

扩展还有 Port_Org、Port_StationType、Port_Team* 等，用于集团、岗位分类、用户组等场景。

2.2 运行模式与对接方式

维度	内容
部署模式	该 BPM 平台RunModel：Single / GroupInc / SAAS 等
组织类型	OSModel：一人一部 / 一人多部
视图对接	用同结构视图替换物理表，映射 HR 库
接口对接	引擎内核命名空间（Port_Emp_Save、Port_Dept_Save、Port_Station_Save 等，有则改无则增）

2.3 为什么算护城河

接收人规则、抄送、权限组、待办过滤，都建立在同一套 Port_* 语义上。集成时通常只需对齐五表或调 API，而不必为每个流程单独写组织适配层。边界也很清楚：组织真相仍在客户侧 HR/AD；该平台提供的是流程可用的组织投影与同步入口，不是替代 HR 系统。

三、二开模式：不改内核也能挂业务

3.1 定义

流程二开 = 流程模板设计完成后，在不修改引擎发送/退回内核的前提下，用脚本、类或配置，把业务逻辑挂到固定生命周期点上。

典型动作：发送前校验、发送后同步第三方、退回拦截、流程结束写台账。

3.2 三种写法，同一套事件时钟

模式	载体	适合
前端外挂	Vue 办理页 WGFlow_* 等	交互校验、按钮、提示、字段联动
后端外挂	FlowEventBase 子类，按流程标记绑定	强事务、改路由/接收人、系统集成
事件配置	平台系统表 + GenerDBSrc（SQL / WebApi / 过程等）	实施配置、少写代码的标准化连接

事件常量产品化（节选）：

节点：SendWhen、SendSuccess、Return*、WorkArrive、超时预警等（EventListNode）
流程：FlowOnCreateWorkID、FlowOverBefore / After、删除前后等（EventListFlow）
表单：加载/保存/从表行/附件等（EventListFrm）

统一调度入口：引擎内核命名空间；对外门面：引擎内核命名空间。

3.3 价值与边界

价值	边界
业务与内核分离，利于升级与按模板交付	复杂规则仍需代码治理，配置不是银弹
前端/后端/实施可按团队选型叠加	自定义「画布积木式 Activity」不是主叙事；扩展主路径是事件与业务单元
发送前可干预跳转节点、接收人、是否结束	干预点有约定，不是任意改写内核状态机

更完整的分层论述见同系列：《不改内核也能挂业务：工作流引擎的三层挂接模型》。

四、表单引擎：流程绑定的数据入口

4.1 定位

在中国式审批里，表单往往比画布更决定交付成败。该平台把表单引擎与流程引擎同栈交付：节点可绑定不同表单方案，流程可选择不同开发模式（FlowDevModel）。

4.2 主要表单类型（`FrmType` / `NodeFormType`）

类型	说明
经典表单（FoolForm）	设计器配置字段与布局，元数据驱动渲染
开发者表单（Develop）	更偏开发可控的页面形态
嵌入式 / SDK / URL	复用已有页面或第三方表单
Excel / Word / VSTO / WPS	Office 模板与本地能力场景
章节表单、实体类表单等	长文档、强类型实体等补充路径

节点侧还有累加表单、表单树、引用独立表单树等方案（NodeFormType），用于「一流程多表单」或「节点换皮」类需求。

4.3 与流程的关系

节点表：ND{flow}{node} 等，存节点填报
流程汇总：ND{flow}Rpt（FlowAttr.PTable），报表与列表常用
独立表单元数据：平台系统表

4.4 价值与边界

价值	边界
流程与表单一体交付，减少「引擎 + 自研表单」拼装成本	极致自定义 UI 仍可能走嵌入式/开发者表单
低代码设计器与高代码实体（EnMap）可并存	「自由表单」多为历史兼容表述，当前主推经典/开发者/Office 等路径
同一 ORM（引擎内核命名空间）降低范式切换成本	表单能力深度依赖设计器与元数据，学习曲线真实存在

五、丰富的节点属性与流程属性

5.1 为什么这是护城河

很多引擎「能画节点」，但审批语义（退回范围、超时怎么处理、无人接收怎么办、是否自动跳过）要靠二开补。该平台把大量语义做成了节点/流程属性，在设计器里配置，运行期由引擎解释——这是产品化积累，不是单次项目脚本。

5.2 节点属性大类（`NodeAttr` / `NodeExt`）

大类	代表能力
基本与运行模式	节点类型、RunModel（线形 / 分流 / 合流 / 分合流 / 同异表单子线程）
接收人	DeliveryWay、参数、无人处理策略、是否排除发送人
退回 / 撤销 / 跳转	退回角色与范围、撤销规则、跳转方式与目标
多人处理	会签/协作模式、通过率、组长确认
抄送	自动抄送规则与写入方式
超时与考核	期限、预警、超时处理、考核方式
阻塞	阻塞模式与表达式
表单方案	表单类型、URL、节点表单绑定
父子流程	手动/自动/延续子流程配置入口
未来处理人	是否预计算接收人及提醒

5.3 流程属性大类（`FlowAttr` / `FlowExt`）

大类	代表能力
基本与标题	分类、标题生成规则、草稿、是否可发起
数据与表单	业务表、开发模式、批发起、完整性校验等
发起限制与前置导航	限制角色/参数、引导方式、是否装载历史数据
时限	流程级期限角色与 SQL
抄送与权限组	抄送类型、可见范围（发起人/参与人/部门等）
数据同步	与业务表同步方式、指定节点
事件实体	FlowEventEntity / FlowMark 绑定后端外挂
轨迹展示	时间轴、轨迹开关、子流程展示方式

5.4 边界

属性再全，也覆盖不了所有行业特例；复杂分支与深度集成仍要落到条件、事件与二开。护城河在于：常见审批语义有现成开关，而不是每个项目从零发明。

六、接收人规则：找人引擎产品化

6.1 机制

节点属性 DeliveryWay + DeliveryParas，由引擎内核命名空间解释执行。枚举定义见引擎内核命名空间，条目五十余种（随版本增减，以源码为准）。

6.2 规则类别（按源码注释归纳）

类别	示例
组织维度	按角色、按部门、部门∩角色、绑定人员、本部门角色范围内找人
SQL / 数据源	BySQL、SQL 模板、ByGenerDBSrc、FEE 接口
上一步选择	发送人选择、固定范围选择、自研 URL / API 选人
表单字段	主表/从表人员字段、部门字段、岗位字段及组合计算
历史节点人员	与上一节点相同、与发起人相同、与指定节点相同或其岗位
领导/主管	部门负责人、直属领导、多级主管
用户组	按 Team / 组织 / 部门 / 岗位组合
子线程专用	SQL/从表确定子线程接收人与数据行
路由映射	人员/部门/字段映射到目标接收人

6.3 价值与边界

价值	边界
「谁来办」大多可配置，少写找人代码	规则多，实施需选型规范，避免随意堆 SQL
与 Port_*、表单字段、历史办理人贯通	组织数据不准确时，任何找人规则都会失真
支持选人、自动计算、接口回调多种形态	极特殊组织算法仍可能走 BySQL / API / 事件改接收人

七、父子流程：跨流程实例编排

7.1 与分合流的区别

概念	关联键	含义
分合流 / 子线程	FID 等	同一流程模板内的并行拆分与汇合
父子流程	PWorkID / PFlowNo / PNodeID / PEmp / PFID	跨流程实例的主从编排

二者都出现在平台配置实体上，但解决的问题不同，实施时不宜混称。

7.2 三类子流程（`SubFlowType`）

值	枚举	含义
0	HandSubFlow	办理人手工启动子流程
1	AutoSubFlow	到达/发送等时机自动触发
2	YanXuFlow	延续子流程（业务上接续办理）

配置落在平台配置实体（SubFlowHand / SubFlowAuto / SubFlowYanXu 等实体）。还可区分下级/同级（SubFlowModel），以及字段拷贝、回写父流程、父流程是否自动下步/结束、是否仅启动一次等（SubFlowAttr）。

7.3 API 侧能力（`Dev2Interface` 等）

能力	说明
发起时带父信息	Node_StartWork(..., parentWorkID, parentFlowNo)
回写父流程关联	SetParentInfo（可选拷贝数据）
查询与校验	DB_SubFlows、运行中数量、是否全部结束
删除策略	删除主流程时可选择是否级联子流程
自动触发	发送编排中按 InvokeTime 调用自动子流程

节点属性 IsToParentNextNode：子流程到达该节点时，可推动父流程走到下一步——用于「子办完一段，父自动前进」类场景。

7.4 价值与边界

价值	边界
复杂业务可拆成多个流程模板协同，而不是单图画成「巨无霸」	父子状态机与数据拷贝规则需设计清楚，否则难排查
手工/自动/延续覆盖常见交付模式	跨系统「伪父子」（只同步单据号）仍要靠集成事件
实例级关联可查询、可级联删除	与 BPMN CallActivity 概念相近但产品语义不同，迁移时需对照

八、七条能力如何互相咬合

护城河很少来自单一功能，而来自组合：

组织 Port_*  ──►  DeliveryWay 找人  ──►  GenerWorkerList 待办
                      │
表单引擎 ──► 业务字段 ─┴──► NDxxRpt 报表 / 条件 / 字段选人
                      │
节点/流程属性 ─────────┼──► 退回、超时、抄送、阻塞等运行语义
                      │
二开三模式 ────────────┼──► 在 SendWhen / FlowOver 等时钟挂业务
                      │
父子流程 ──────────────┴──► 跨实例编排，仍复用同一套五表与事件

可以这样理解交付分工：

五表决定数据怎么存、怎么查、怎么审计
组织 + 接收人规则决定谁来办
表单 + 节点/流程属性决定怎么配、少写多少代码
二开决定配不了的业务挂在哪、且尽量不改核
父子流程决定复杂业务如何拆模板协同

九、中肯结论（给选型用）

若你的场景是：政企审批、表单密集、组织找人复杂、需要可配置的退回/会签/超时、并且希望业务逻辑外挂可升级——上述七项构成该 BPM 平台较难被「薄引擎」短期追平的能力面。

若你的场景是：强 BPMN 标准、云原生编排、自定义 Activity 积木、国际生态工具链优先——应优先评估标准引擎或其衍生方案，再决定是否需要该平台这类表单/审批一体化产品。

一句话：该平台的护城河不在口号，而在「五表分立 + 组织找人 + 属性产品化 + 三模式二开 + 表单同栈 + 父子编排」这组已落地的工程结构；用之前，请对照源码与演示环境验证当前版本行为。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

bpmn-js