BPM 平台实体数据处理模式设计：五种配置化交互方式评估

实体是一行数据，实体集合是多行数据，流程对它们的操作方式其实可以穷举。本文从概念划分、配置化程度与实践风险三方面，评估这样一套模式体系的价值与代价。

一、实体概念与本文研究范围

1.1 实体的定义

在该 BPM 平台中，实体 是对现实世界事物的数字化建模，例如：车辆、固定资产、员工、供应商等。

// 前端模块源码目录
// EntityType: @0=独立表单 @1=单据 @2=实体
map.AddTBInt('EntityType', 0, '业务类型', true, true);

打开一条实体记录时，前端由 MyDictFrameWork.vue 加载 卡片页；浏览实体集合时，由 Search 系列页面（如 useSearchNoName.ts）加载 列表页。

1.2 本文研究范围

本文 不讨论 流程引擎内部的节点流转、分合流、父子流程等机制，而聚焦一个问题：

流程如何对单个实体与实体集合进行操作？

该 BPM 平台的答案是：通过五种 MethodModel 模式，在配置层区分「操作对象是一行还是多行」「数据是否回写」「是否与实体长期绑定」，开发人员 按模式选型 + 向导配置 即可完成大部分场景，无需重复编写集成代码。

1.3 五种模式一览

总结：实体与流程的关系，就是通过流程来 操作一行数据、多行数据、修改数据、增加数据。

二、操作维度：单个实体 vs 实体集合

该 BPM 平台在 UI 与配置层将操作入口分为两类，与「一行 / 多行」严格对应：

方法类型常量在 GPN_Method.ts 中统一定义：

// 前端模块源码目录该引擎/CCBill/Method/GPN_Method.ts
export class MethodModel {
  public static readonly FlowBaseData = 'FlowBaseData';
  public static readonly FlowEtc = 'FlowEtc';
  public static readonly FlowNewEntity = 'FlowNewEntity';
  // FlowHostBill、FlowEntityBatchStart 在向导中单独注册
}

三、五种模式详解

3.1 新增模式（FlowNewEntity）

业务定义

走完流程之后，在实体表中 增加一笔新记录。通常在实体 列表（表格） 上增加按钮，例如：「发起车辆采购流程」。流程审批通过后，系统将流程表单数据写入实体表，实体集合 多一行。

操作对象

• 实体集合（列表页），不依赖已选行；从「无记录」到「有新记录」。

典型场景

代码实现

列表页点击后调用后端 CreateWorkID，打开流程页：

// useSearchNoName.ts
const workID = await menu.DoMethodReturnString('CreateWorkID');
baseComp.value?.openIframe({
  src: '/#/WF/MyFlowGener?FlowNo=' + data.FlowNo + '&FrmID=' + data.FrmID + '&WorkID=' + workID + ...
});

后端设计意图（MethodFlowNewEntity.ts 注释）：流程实例标记 FlowNewEntity=1，PWorkID 与实体新行 ID 对齐，流程结束后自动写入 Dict。

配置要点

• 挂载：Collection + IsSearchBar
• DTS：通常 DTSWhenFlowOver = true，流程结束回写
• 开发人员：无需编写 INSERT 逻辑，配置流程与方法即可

3.2 批处理模式（FlowEntityBatchStart）

业务定义

在实体 列表 上勾选 多行 记录，一次性发起 一条 流程，将选中实体的信息批量带入流程。面向 实体集合 的批量操作。

操作对象

• 实体集合（多行选中），合并为一条流程实例处理。

代码实现

handler.AddPara('WorkIDs', tableConfigs.checkedItems.join(','));
const data = await handler.DoMethodReturnString('MyDict_DoFlowBatchBaseData_StartFlow');

与新增、修改模式的边界

3.3 修改模式（FlowBaseData）

业务定义

在 一笔已有记录（单个实体） 上，发起 基础资料变更流程，例如：「车辆基础资料变更」、「纳税人基础资料变更流程」。流程结束后，按配置将变更字段 同步回写 到该实体行。

操作对象

• 单个实体（一行），主键通过 PWorkID 关联。

典型场景

• 法人变更、车牌变更、纳税人识别号变更
• 需留痕、需审批的主数据变更

代码实现

GPN_Method.Docs11 官方说明：

操作当前一行数据；流程结束后，系统就会把这些字段同步到实体中去。

DTS 配置（各 Method 通用）：

配置要点

• 挂载：Method + IsList 或卡片页 IsMyBillToolBar
• 向导一键从实体表单 复制字段 到流程开始节点
• 开发人员：无需编写 UPDATE 回写代码，由 DTS 引擎完成

3.4 多次业务模式（FlowEtc）

业务定义

在 一笔记录（单个实体） 上发起流程，将当前实体信息 传递 到流程开始节点表单。流程发起后，与实体 不再有持续关系，不回写 实体数据。同一实体 可多次 发起，每次产生独立流程实例。

操作对象

• 单个实体（一行），每次发起时 复制 字段快照。

典型场景

代码实现

GPN_Method.Docs12：

启动流程的时候，单据数据 copy 到开始节点上。流程运行完毕后，就作为业务查询数据。

卡片页嵌入流程历史（MyDictFrameWork.vue）：

<!-- methodModal === 'FlowEtc' -->
EnName=GL_FlowEtcList&WorkID=...&FlowNo=...&FrmID=...

与修改模式的本质区别

3.5 宿主流程模式（FlowHostBill）

业务定义

实体上设计一个 状态枚举字段，其取值由流程 运行中、结束后 的事件决定，此类流程称为 宿主流程。

需同时设计：

1. 状态字段（如车辆状态：正常 / 维修中 / 维修完毕 / 报废）
2. WorkIDOf{FlowNo} 字段（如流程编号 001 → 字段名 WorkIDOf001），存储当前绑定流程的 WorkID

约束：同一时间点只能有一个有效 WorkID；该流程 结束 后才可再次发起并覆盖。

典型场景

车辆维修流程：

• 启动 → 车辆状态 = 维修中，WorkIDOf001 = 当前 WorkID
• 流程结束（分支）→ 状态 = 维修完毕 或 报废
• 流程节点/结束 事件 更新实体表状态字段

代码实现

WorkIDOf 自动注册（MapRefMethod.ts）：

const fieldID = 'WorkIDOf' + flowNo;  // 如 WorkIDOf001
if (!this.attrs.find((attr) => attr.Key === fieldID)) {
  this.AddTBInt(fieldID, null, `${title}WorkID`, true, true, false);
}

发起逻辑（En.vue）：WorkIDOf == 0 时创建流程并回写 WorkID；否则打开已有 MyView。

向导创建：FlowDevModel = 3（宿主专用），FlowEtc_Save + FlowModel=FlowHostBill。

Demo 参考：App/Demo/SingleRecord/StudentFlowComponent.ts（WorkIDOf058）、App/Demo/Resume.ts（手工发起示例）。

状态机示意

四、公共机制与接口对照

4.1 实体—流程关联键

4.2 后端接口

4.3 模式选型速查

五、设计评估：合理性、可操作性、可实践性

本节基于该 BPM 平台对实体—流程关系的 概念划分，从架构与落地角度评估其对开发人员的价值。

5.1 合理性（Conceptual Soundness）

5.1.1 划分是否贴合业务本质

5.1.2 概念正交性

五种模式在三个维度上近似 正交：

维度1：操作对象     →  单行 | 多行 | 无行（新增）
维度2：数据回写     →  回写 | 不回写 | 双向（宿主）
维度3：实例约束     →  无约束 | 唯一在途（宿主）

开发人员选型时可按业务问答式决策，降低架构讨论成本。

5.1.3 可改进点

• 用户口述「三种模式」实际为 五种，建议在培训材料中统一口径，避免实施歧义。
• FlowHostBill 在 UI 文案中为「寄宿流程」，与「宿主流程」混用，建议文档与界面术语统一为 宿主流程。
• 批处理与流程属性中的 IsBatchStart（流程级批量）名称相近，实施时需向配置人员说明 实体 Collection 批处理 与 流程设计器批量发起 的差异。

5.2 可操作性（Operability）

5.2.1 配置化程度

5.2.2 实施路径清晰

5.2.3 权限与规则内置

• 各 Method 均挂接 PCenters 权限子表，可按组织/角色控制按钮可见性。
• 宿主模式提供 FrmBillFlowSingleRole（单次流程规则），支持「仅允许一次发起」等约束，减少硬编码校验。

5.2.4 可操作性评分

5.3 可实践性（Practicability）

5.3.1 对开发工作量的节省

结论：对于车辆、资产、员工等 标准主数据 + 周边流程 类项目，实施人员通过 配置五种模式 即可交付，开发人员主要承担：

1. 实体 Map 设计（字段、状态枚举）
2. 非常规逻辑（RefMethod、流程事件、外挂 WaiGuaBaseEntity）
3. 前端个性化 UI（非标准 Search / 卡片）

5.3.2 代码结构对实践的支撑

• MethodModel 常量 贯穿前后端，Search Hook（useSearchNoName.ts、useSearchMethod.ts、useSearchBill.ts）按类型分支，扩展新模式时有明确挂点。
• MapRefMethod 提供 AddRM_StartFlow / AddRM_StartHostFlow / AddRM_SearchFlow，代码级实体与配置级 Method 语义一致，便于从配置迁移到代码或反向。
• 单据需求文档 §九 已维护方法类型清单，利于团队知识传承。

5.3.3 实践风险与规避

5.3.4 可实践性总评

该 BPM 平台将实体—流程交互 产品化为五种 MethodModel，在 合理性 上覆盖了企业主数据管理的主流范式；在 可操作性 上通过向导、DTS、内置列表降低实施门槛；在 可实践性 上显著减少重复集成代码，使 「配置即交付」 成为可达成目标。对开发人员而言，工作重点从「写流程对接胶水代码」转向「选好模式 + 设计实体字段与事件」，整体 人天可节省约 50%～70%（标准 CRUD+流程类需求，视项目复杂度浮动）。

六、总结

实体 = 一行数据，实体集合 = 多行数据。流程对实体的五种处理方式，本质是该 BPM 平台在配置层对「增、改、批量、申请、绑态」的产品化封装，使开发人员 以模式选型 + 向导配置 为主、编码为辅。

七、通用 BPM 平台的同类处理方式

业界 BPM / 工作流产品与该平台五种模式在 语义上高度对应，实现层次与术语各异。下表便于集成设计与技术对标。

7.1 概念对照

7.2 通用集成模式

7.3 主流产品参考

7.4 差异摘要

7.5 对外集成建议

1. 统一 Business Key ↔ PWorkID，实体类型 ↔ PFlowNo。
2. 修改/新增 必须定义回写字段清单与时机（对齐 DTS）。
3. 宿主 场景在外部系统维护 status + activeWorkId，与 WorkIDOf{FlowNo} 对齐。
4. 批处理 约定流程变量名承载多主键列表（对齐 WorkIDs 参数）。