五张表,撑起流程、低代码与权限——驰骋 BPM 组织结构设计的工程价值
「一套组织底座,三件事一次做对」——驰骋 BPM 五表模型如何同时驱动工作流、低代码与应用权限
文档版本:2026-06
依据代码:BP.En30/Port、BP.WF/Template/FindWorker、BP.WF/CCBill、Vue3/src/bp/sys/Safe
姊妹文档:组织结构设计技术报告 · 组织结构数据字典
开篇:组织结构的"一鱼三吃"
在企业数字化建设中,组织结构从来不是一张可有可无的通讯录——它是三件事的共同地基:
| 能力域 | 典型诉求 | 若组织模型薄弱,后果是…… |
|---|---|---|
| 工作流 | 费用报销找"申请人部门的财务经理" | 流程卡住、找不到人、审批串岗 |
| 低代码 | 拖拽建表单,按岗位控制谁能新建/删除 | 权限只能靠硬编码,平台失去"低"的意义 |
| 应用权限 | 销售只能看本部门客户,总监能看下属组织 | 数据越权、租户串库、审计不过关 |
驰骋 BPM(CCBPM)用 五张核心表(Port_Dept、Port_Emp、Port_Station、Port_DeptEmp、Port_DeptEmpStation)构建组织底座,使上述三大能力共享同一套组织语义——不必为流程建一套人、为低代码再建一套人、为权限又建第三套人。
这不是理论推演,而是写进引擎源码的工程选择。下文从流程、低代码、应用权限三个维度,说明其可取之处。
一、支撑工作流:让"按部门+角色找人"成为引擎本能
1.1 政企审批的真实语义
真实世界里的审批从来不是"找一个叫经理的人",而是:
在「申请人所在部门」里,找「担任财务经理角色」的人。
同一个人,在 A 部门是经理,在 B 部门是普通员工——角色必须带部门上下文。驰骋用 Port_DeptEmpStation 将 部门 × 角色 × 人员 三维绑定,与编制管理语义一致。
1.2 引擎直接消费,无需应用层翻译
驰骋工作流引擎 FindWorker 内置 20+ 种接收人规则(DeliveryWay 枚举),其中大量规则的核心查询直指五表:
| 接收人规则 | 代码中的组织依赖 |
|---|---|
| 按角色(以部门为纬度) | Port_DeptEmpStation + 当前部门 |
| 按部门与角色交集计算 | Port_DeptEmpStation JOIN WF_NodeStation |
| 按表单部门字段 + 角色计算 | 表单 DeptNo → Port_DeptEmpStation |
| 找部门领导 | Port_Dept.Leader |
| 找直属领导 | Port_Emp.Leader |
核心选人 SQL 简洁到可以背诵:
SELECT FK_Emp FROM Port_DeptEmpStation
WHERE FK_Station = '角色编号' AND FK_Dept = '部门编号'
引擎还实现了智能向上找岗:本部门找不到人时,自动向父部门、同级部门回溯——这一整套逻辑建立在部门树(Port_Dept.ParentNo)与三要素绑定表之上,无需业务系统额外开发。
1.3 对流程实施的可取之处
- 配置即运行:流程设计器选"按角色",底层自动查
Port_DeptEmpStation,实施顾问不必写 SQL。 - 兼职天然支持:一人多部门时,每个部门下的角色独立存储,流程不会"串岗"。
- 多组织零改模:集团/SAAS 模式下查询自动附加
OrgNo条件,流程不因租户增加而重构。 - 可诊断:找不到人时,错误信息直指"某部门某角色下无人员",便于核对组织数据而非猜引擎 Bug。
一句话:五表模型让流程引擎"理解"组织,而不是"绕过"组织。
二、支撑低代码:组织语义贯穿表单与应用全生命周期
低代码平台的承诺是业务人员可配置、少写代码。若组织模型与平台脱节,低代码就退化为"画界面 + 写脚本补权限"——驰骋的做法是:把组织五表变成低代码的运行时上下文。
2.1 登录即携带完整组织身份
用户登录后,WebUser 上下文自动注入:
WebUser.No— 人员编号WebUser.DeptNo— 主部门WebUser.OrgNo— 所属组织(集团/SAAS)- 兼职部门与角色 — 运行时从
Port_DeptEmpStation加载
低代码表单、流程、报表中的表达式(如 @WebUser.DeptNo、@WebUser.OrgNo)直接引用,无需每个应用重复封装用户服务。
2.2 表单控件原生理解组织
前端组件库(GPN_ComponentMapExt 等)内置多种组织感知控件:
- 按部门选人
- 按部门 + 岗位选人
- 组织树选择器
这些控件的数据源统一来自 Port_Dept、Port_Emp、Port_DeptEmpStation,设计器拖拽即可用,不必为每个表单写一套人员接口。
2.3 数据权限可视化配置,不靠写代码
驰骋低代码单据(CCBill)提供 DBSafe 数据安全策略,在低代码界面中配置:
| 策略 | 含义 | 依赖的组织数据 |
|---|---|---|
SelfOnly | 只看自己创建的数据 | Port_Emp.No |
DeptOnly | 本部门可见 | Port_Emp.FK_Dept / Port_DeptEmp |
DeptLeader | 部门负责人可见本部门数据 | Port_Dept.Leader |
ByStations | 指定岗位可操作 | Port_DeptEmpStation |
ByDepts | 指定部门可操作 | Port_Dept |
OrgOnly / POrg / NOrg | 组织级数据隔离与上下级可见 | Port_Org、OrgNo |
运行时,WF_CCBill 在渲染按钮权限前,自动查询当前用户的全部部门与角色:
DataTable mydeptsDT =
DBAccess.RunSQLReturnTable("SELECT FK_Dept,FK_Station FROM Port_DeptEmpStation WHERE FK_Emp='" +
WebUser.UserID + "'");
foreach (DataRow dr in mydeptsDT.Rows)
{
mydepts += dr[0].ToString() + ",";
mystas += dr[1].ToString() + ",";
}
随后据此判断当前用户能否新建、保存、删除、归档——全部在低代码配置层完成,业务开发者不必在每个 CRUD 接口里手写 if。
2.4 对低代码建设的可取之处
- 组织即平台能力:新建一个低代码应用,自动继承部门/角色/组织隔离,而非从零造轮子。
- 配置替代编码:权限策略在
GPN_DBSafe界面点选,实施周期从"周"缩短到"小时"。 - 兼职场景不踩坑:权限计算遍历
Port_DeptEmpStation中全部部门与角色,不会因只认主部门而越权或缺权。 - 集团/SAAS 原生:
OrgOnly、Admin2(二级管理员)等策略与Port_OrgAdminer联动,一套低代码应用从单企业平滑扩展到多租户。
一句话:五表模型让低代码平台"自带组织智商",而不是每个项目重新发明权限。
三、支撑应用系统权限:从菜单到数据行的统一坐标系
驰骋 BPM 的定位不仅是流程引擎,更是可嵌入业务系统的数字化底座。组织五表为应用级权限提供了统一坐标系。
3.1 三个层级的权限,一张组织底图
3.2 数据权限:部门、岗位、组织多维度组合
CheckDBRoleUtil 是应用数据权限的核心工具,支持按优先级叠加过滤:
- 全部(All) — 不限制
- 本部门(Dept) — 基于
DeptNo字段过滤 - 部门领导(DeptLeader) — 查询
Port_Dept.Leader是否为当前用户 - 本组织(OrgOnly) — 基于
OrgNo字段隔离 - 父级组织及下级(NOrg) — 基于
Port_Org.TreeNos层级 - 按表达式(Exp) — 支持
@WebUser.No等组织变量
部门领导判断直接查组织表,而非维护独立"领导角色":
ps.SQL = "SELECT No FROM Port_Dept WHERE Leader=" + CACHED_DB_VAR_STR + "Leader AND No=" + CACHED_DB_VAR_STR + "No";
ps.Add("Leader", WebUser.No);
ps.Add("No", WebUser.DeptNo);
DataTable mydt = DBAccess.RunSQLReturnTable(ps);
3.3 管理权限:组织管理员体系
集团/SAAS 模式下,Port_OrgAdminer 定义二级管理员,可细化到:
- 流程目录权限(
Port_OrgAdminerFlowSort) - 表单目录权限(
Port_OrgAdminerFrmTree)
WebUser.IsAdmin 运行时综合判断:超级管理员、组织主管理员、二级管理员——全部锚定在组织五表及其扩展表上,避免多套账号体系。
3.4 与业务系统集成:一套主数据,多处复用
业务系统通常已有 HR/OA 组织主数据。驰骋提供两种集成路径,均围绕五表展开:
| 模式 | 做法 | 权限收益 |
|---|---|---|
| 视图模式 | 五表改为视图,映射 HR 数据 | 组织变更即时生效,权限零延迟 |
| 接口模式 | OrganizationAPI 同步五表 | Port_Emp_Save 一次写入人员+部门+角色 |
集成后,业务系统与 BPM/低代码/权限共用同一份组织真相,不会出现"HR 已调岗、流程还找旧人"的数据裂缝。
3.5 对应用权限的可取之处
- 统一语义:部门、岗位、组织在流程、表单、报表中含义一致,减少权限漏洞。
- 可审计:权限判断基于结构化组织数据,可追溯"谁在什么部门担任什么角色"。
- 租户硬隔离:
OrgNo贯穿五表,从数据行级别防止跨租户泄露。 - 渐进式增强:简单场景用部门字段即可;复杂场景叠加岗位、组织策略——不必一步到位上完整 IAM。
一句话:五表模型是应用权限的"共同语言",而不是各模块各说各话。
四、三大能力协同:1 + 1 + 1 > 3
五表设计的真正价值,在于三件事共用同一底座时产生的协同效应:
场景示例:费用报销全流程
| 阶段 | 流程 | 低代码 | 权限 |
|---|---|---|---|
| 发起 | 发起人 = 当前 WebUser | 表单记录写入 DeptNo、OrgNo | 只有本部门人员可新建(DeptOnly) |
| 审批 | 找"发起人部门的部门经理"(Port_DeptEmpStation) | 审批意见字段按角色显示/隐藏 | 部门经理可见本部门单据(DeptLeader) |
| 归档 | 流程结束写入业务表 | 低代码单据状态变为已归档 | 财务岗位可查看全部(ByStations) |
| 查询 | — | 报表按部门筛选 | 集团模式下仅本组织可见(OrgOnly) |
若组织模型分裂(流程一套人、权限另一套人),这个场景需要三处对齐、六套测试;驰骋五表模型下,维护一次组织数据,三处同步受益。
五、与替代方案相比,优势在哪里
| 对比维度 | 简易用户-部门模型 | 重度 IAM 模型 | 驰骋五表模型 |
|---|---|---|---|
| 流程按部门+角色找人 | 需大量补偿逻辑 | 概念映射复杂 | 引擎原生支持 |
| 低代码按钮/数据权限 | 靠脚本硬写 | 需桥接 IAM | DBSafe 可视化配置 |
| 兼职与多岗位 | 难以表达 | 可以但集成重 | DeptEmpStation 原生 |
| 多组织/多租户 | 需改造 | 可以但重 | OrgNo 贯通五表 |
| 与 HR 主数据集成 | 简单但不完整 | 映射链路过长 | 五表视图/API 即可 |
| 学习成本 | 低但能力弱 | 高 | 中等,能力完整 |
驰骋五表不是"最简单的设计",而是在流程、低代码、权限三域交叉点上,工程性价比最高的设计。
六、结语:选组织模型,就是选数字化底座
组织结构设计看似底层、枯燥,实则决定了:
- 流程能不能跑通;
- 低代码能不能真低代码;
- 权限能不能管得住。
驰骋 BPM 用五张表回答了一个工程问题:
如何用最小表集,让工作流引擎、低代码平台、应用权限系统共享同一套组织语义?
答案是:Port_Dept + Port_Emp + Port_Station + Port_DeptEmp + Port_DeptEmpStation——部门树、人员主档、角色定义、兼职关系、三要素绑定,缺一不可,亦不过度。
一套组织底座,三件事一次做对。 这是驰骋十余年政企交付经验的沉淀,也是 CCBPM 区别于"只会画流程图"的轻量产品的底层理由之一。
本文档由驰骋 BPM 技术团队基于源码分析编写,转载请注明出处。


192

被折叠的 条评论
为什么被折叠?



