很多引擎“能画节点”，但审批语义要靠二开补。本文按七个能力面拆解一套表单与审批一体化引擎的工程结构：能做什么、靠什么机制、边界在哪儿。
阅读说明
「护城河」在本文中指：经过长期交付沉淀、难以用「画布 + 几个钩子」短期补齐的产品能力面。
这些能力并非玄学，而是可在表结构、枚举、事件基类与 API 上逐条核对的工程事实。
| 能力面 | 一句话 | 主要代码锚点 |
|---|---|---|
| 流程引擎五表 | 实例 / 待办 / 业务 / 组织 / 轨迹各安其位 | GenerWorkFlow、GenerWorkerList、GERpt、Port_*、Track |
| 组织结构集成 | 五表组织模型 + 视图/API 对接 | BP.Port.*、OrganizationAPI |
| 二开模式 | 前端外挂 / 后端外挂 / 事件配置 | FlowEventBase、ExecEvent、Sys_FrmEvent |
| 表单引擎 | 低代码与高代码双轨，节点可绑多方案 | FrmType、NodeFormType、FlowDevModel |
| 节点/流程属性 | 设计器可配的运行语义产品化 | NodeAttr、FlowAttr、NodeExt、FlowExt |
| 接收人规则 | DeliveryWay 枚举驱动的找人引擎 | FindWorker、DeliveryWay |
| 父子流程 | 手工 / 自动 / 延续三类，实例级关联 | SubFlowType、WF_NodeSubFlow、Dev2Interface |
客观边界：BPMN 标准引擎（如 Flowable、Camunda）在标准元素与生态工具链上另有优势；驰骋更偏表单驱动 + 中国式审批语义产品化。选型应看场景，而非总分叙事。
一、流程引擎五表：控制与业务分立
1.1 设计主张
西方引擎常见做法是：执行实例、任务、变量高度抽象到统一运行时表（如 ACT_RU_*）。
驰骋的选择不同：引擎控制表管「跑到哪、谁在办」；业务宽表管「填了什么」；组织表管「人是谁」；轨迹表管「做过什么」——五类表松耦合，用 WorkID / OID 关联。
┌──────────────┬──────────────┬──────────────┬──────────┬─────────┐
│ ① 流程实例 │ ② 工作人员 │ ③ 业务数据 │ ④ 组织身份 │ ⑤ 轨迹 │
│ WF_Gener │ WF_Gener │ NDxxRpt │ Port_* │ NDxx │
│ WorkFlow │ WorkerList │ (+节点表单) │ │ Track │
├──────────────┼──────────────┼──────────────┼──────────┼─────────┤
│ 状态/标题/节点 │ 待办/已办/会签 │ 报表/查询/归档 │ 人/部门/岗 │ 审计回溯 │
└──────────────┴──────────────┴──────────────┴──────────┴─────────┘
注意：仓库文档里还有「组织 Port 五表」说法（人员/部门/岗位/部门人员/部门岗位人员）。本文「流程引擎五表」指运行期控制与业务分立，二者勿混用。
1.2 五表职责（可核验）
| # | 表 | 实体 | 回答的问题 |
|---|---|---|---|
| 1 | WF_GenerWorkFlow | BP.WF.GenerWorkFlow | 这条流程实例现在在哪、什么状态、标题是什么 |
| 2 | WF_GenerWorkerList | BP.WF.GenerWorkerList | 谁在办、办没办、何时到期 |
| 3 | ND{FlowNo}Rpt | GERpt | 业务字段汇总与流程系统字段镜像，便于报表 |
| 4 | Port_* | BP.Port.* | 选人与权限所依赖的组织身份 |
| 5 | ND{FlowNo}Track | Track | 发送/退回/移交等操作轨迹（按流程分表） |
发送路径的大致协作（文档与 WorkNode 发送逻辑一致）：更新工作者 IsPass → 更新实例状态与当前节点 → 写入新待办 → 同步业务报表 → 追加轨迹。
1.3 工程价值与边界
| 价值 | 说明 |
|---|---|
| 待办查询轻 | WF_GenerWorkerList 按人 + 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 运行模式与对接方式
| 维度 | 内容 |
|---|---|
| 部署模式 | CCBPMRunModel：Single / GroupInc / SAAS 等 |
| 组织类型 | OSModel：一人一部 / 一人多部 |
| 视图对接 | 用同结构视图替换物理表，映射 HR 库 |
| 接口对接 | BP.Port.OrganizationAPI（Port_Emp_Save、Port_Dept_Save、Port_Station_Save 等，有则改无则增） |
2.3 为什么算护城河
接收人规则、抄送、权限组、待办过滤，都建立在同一套 Port_* 语义上。
集成时通常只需对齐五表或调 API，而不必为每个流程单独写组织适配层。
边界也很清楚：组织真相仍在客户侧 HR/AD；驰骋提供的是流程可用的组织投影与同步入口，不是替代 HR 系统。
三、二开模式：不改内核也能挂业务
3.1 定义
流程二开 = 流程模板设计完成后，在不修改引擎发送/退回内核的前提下，用脚本、类或配置，把业务逻辑挂到固定生命周期点上。
典型动作：发送前校验、发送后同步第三方、退回拦截、流程结束写台账。
3.2 三种写法，同一套事件时钟
| 模式 | 载体 | 适合 |
|---|---|---|
| 前端外挂 | Vue 办理页 WGFlow_* 等 | 交互校验、按钮、提示、字段联动 |
| 后端外挂 | FlowEventBase 子类，按流程标记绑定 | 强事务、改路由/接收人、系统集成 |
| 事件配置 | Sys_FrmEvent + GenerDBSrc（SQL / WebApi / 过程等） | 实施配置、少写代码的标准化连接 |
事件常量产品化（节选）：
- 节点：
SendWhen、SendSuccess、Return*、WorkArrive、超时预警等（EventListNode） - 流程：
FlowOnCreateWorkID、FlowOverBefore/After、删除前后等（EventListFlow） - 表单：加载/保存/从表行/附件等（
EventListFrm）
统一调度入口：BP.WF.ExecEvent；对外门面：BP.WF.Dev2Interface。
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），报表与列表常用 - 独立表单元数据：
Sys_MapData
4.4 价值与边界
| 价值 | 边界 |
|---|---|
| 流程与表单一体交付，减少「引擎 + 自研表单」拼装成本 | 极致自定义 UI 仍可能走嵌入式/开发者表单 |
低代码设计器与高代码实体（EnMap）可并存 | 「自由表单」多为历史兼容表述，当前主推经典/开发者/Office 等路径 |
同一 ORM（BP.En30）降低范式切换成本 | 表单能力深度依赖设计器与元数据，学习曲线真实存在 |
五、丰富的节点属性与流程属性
5.1 为什么这是护城河
很多引擎「能画节点」，但审批语义（退回范围、超时怎么处理、无人接收怎么办、是否自动跳过）要靠二开补。
驰骋把大量语义做成了节点/流程属性，在设计器里配置，运行期由引擎解释——这是产品化积累，不是单次项目脚本。
5.2 节点属性大类（NodeAttr / NodeExt）
| 大类 | 代表能力 |
|---|---|
| 基本与运行模式 | 节点类型、RunModel（线形 / 分流 / 合流 / 分合流 / 同异表单子线程） |
| 接收人 | DeliveryWay、参数、无人处理策略、是否排除发送人 |
| 退回 / 撤销 / 跳转 | 退回角色与范围、撤销规则、跳转方式与目标 |
| 多人处理 | 会签/协作模式、通过率、组长确认 |
| 抄送 | 自动抄送规则与写入方式 |
| 超时与考核 | 期限、预警、超时处理、考核方式 |
| 阻塞 | 阻塞模式与表达式 |
| 表单方案 | 表单类型、URL、节点表单绑定 |
| 父子流程 | 手动/自动/延续子流程配置入口 |
| 未来处理人 | 是否预计算接收人及提醒 |
5.3 流程属性大类（FlowAttr / FlowExt）
| 大类 | 代表能力 |
|---|---|
| 基本与标题 | 分类、标题生成规则、草稿、是否可发起 |
| 数据与表单 | 业务表、开发模式、批发起、完整性校验等 |
| 发起限制与前置导航 | 限制角色/参数、引导方式、是否装载历史数据 |
| 时限 | 流程级期限角色与 SQL |
| 抄送与权限组 | 抄送类型、可见范围（发起人/参与人/部门等） |
| 数据同步 | 与业务表同步方式、指定节点 |
| 事件实体 | FlowEventEntity / FlowMark 绑定后端外挂 |
| 轨迹展示 | 时间轴、轨迹开关、子流程展示方式 |
5.4 边界
属性再全，也覆盖不了所有行业特例；复杂分支与深度集成仍要落到条件、事件与二开。
护城河在于：常见审批语义有现成开关，而不是每个项目从零发明。
六、接收人规则：找人引擎产品化
6.1 机制
节点属性 DeliveryWay + DeliveryParas，由 BP.WF.Template.FindWorker 解释执行。
枚举定义见 BP.WF.EnumLib.DeliveryWay，条目五十余种（随版本增减，以源码为准）。
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 | 跨流程实例的主从编排 |
二者都出现在 WF_GenerWorkFlow 上，但解决的问题不同，实施时不宜混称。
7.2 三类子流程（SubFlowType）
| 值 | 枚举 | 含义 |
|---|---|---|
| 0 | HandSubFlow | 办理人手工启动子流程 |
| 1 | AutoSubFlow | 到达/发送等时机自动触发 |
| 2 | YanXuFlow | 延续子流程（业务上接续办理） |
配置落在 WF_NodeSubFlow（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 积木、国际生态工具链优先——应优先评估标准引擎或其衍生方案，再决定是否需要驰骋这类表单/审批一体化产品。
一句话：驰骋的护城河不在口号，而在「五表分立 + 组织找人 + 属性产品化 + 三模式二开 + 表单同栈 + 父子编排」这组已落地的工程结构；用之前，请对照源码与演示环境验证当前版本行为。
