驰骋BPM工作流引擎的护城河

5.2 驰骋 BPM 工作流引擎的护城河出品驰骋低代码 BPM / CCFlow/JFlowCCBPM文档版本2026-07依据代码CCFlow/Components/BP.WF、CCFlow/Components/BP.En30、Vue3/src/WF写作原则技术口径、可对照源码核验写清楚「能做什么、靠什么机制做、边界在哪」不做无法证实的领先声明。阅读说明「护城河」在本文中指经过长期交付沉淀、难以用「画布 几个钩子」短期补齐的产品能力面。这些能力并非玄学而是可在表结构、枚举、事件基类与 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 五表职责可核验#表实体回答的问题1WF_GenerWorkFlowBP.WF.GenerWorkFlow这条流程实例现在在哪、什么状态、标题是什么2WF_GenerWorkerListBP.WF.GenerWorkerList谁在办、办没办、何时到期3ND{FlowNo}RptGERpt业务字段汇总与流程系统字段镜像便于报表4Port_*BP.Port.*选人与权限所依赖的组织身份5ND{FlowNo}TrackTrack发送/退回/移交等操作轨迹按流程分表发送路径的大致协作文档与WorkNode发送逻辑一致更新工作者IsPass→ 更新实例状态与当前节点 → 写入新待办 → 同步业务报表 → 追加轨迹。1.3 工程价值与边界价值说明待办查询轻WF_GenerWorkerList按人 IsPass即可取待办不必扫变量表报表友好政企场景大量「按部门/月份/状态查业务」物理宽表比变量 JSON 更直接组织可替换引擎不把组织硬编码进流转表便于对接 HR边界说明表数量随流程增长每流程有Rpt/Track等运维需接受「按流分表」而非「一张万能表」与 BPMN 运行时模型不同迁移标准引擎项目时要做控制表语义映射而不是字段一一对应二、组织结构集成选人与权限的底座2.1 组织核心五表流程能不能「找对人」取决于组织模型是否稳定、可对接。驰骋组织底座为表类作用Port_EmpEmp人员主部门FK_DeptPort_DeptDept部门树ParentNoPort_StationStation角色/岗位Port_DeptEmpDeptEmp一人多部门Port_DeptEmpStationDeptEmpStation部门 × 岗位 × 人员按「本部门某角色」找人的数据基础扩展还有Port_Org、Port_StationType、Port_Team*等用于集团、岗位分类、用户组等场景。2.2 运行模式与对接方式维度内容部署模式CCBPMRunModelSingle/GroupInc/SAAS等组织类型OSModel一人一部 / 一人多部视图对接用同结构视图替换物理表映射 HR 库接口对接BP.Port.OrganizationAPIPort_Emp_Save、Port_Dept_Save、Port_Station_Save等有则改无则增2.3 为什么算护城河接收人规则、抄送、权限组、待办过滤都建立在同一套Port_*语义上。集成时通常只需对齐五表或调 API而不必为每个流程单独写组织适配层。边界也很清楚组织真相仍在客户侧 HR/AD驰骋提供的是流程可用的组织投影与同步入口不是替代 HR 系统。三、二开模式不改内核也能挂业务3.1 定义流程二开 流程模板设计完成后在不修改引擎发送/退回内核的前提下用脚本、类或配置把业务逻辑挂到固定生命周期点上。典型动作发送前校验、发送后同步第三方、退回拦截、流程结束写台账。3.2 三种写法同一套事件时钟模式载体适合前端外挂Vue 办理页WGFlow_*等交互校验、按钮、提示、字段联动后端外挂FlowEventBase子类按流程标记绑定强事务、改路由/接收人、系统集成事件配置Sys_FrmEvent GenerDBSrcSQL / 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 / WPSOffice 模板与本地能力场景章节表单、实体类表单等长文档、强类型实体等补充路径节点侧还有累加表单、表单树、引用独立表单树等方案NodeFormType用于「一流程多表单」或「节点换皮」类需求。4.3 与流程的关系节点表ND{flow}{node}等存节点填报流程汇总ND{flow}RptFlowAttr.PTable报表与列表常用独立表单元数据Sys_MapData4.4 价值与边界价值边界流程与表单一体交付减少「引擎 自研表单」拼装成本极致自定义 UI 仍可能走嵌入式/开发者表单低代码设计器与高代码实体EnMap可并存「自由表单」多为历史兼容表述当前主推经典/开发者/Office 等路径同一 ORMBP.En30降低范式切换成本表单能力深度依赖设计器与元数据学习曲线真实存在五、丰富的节点属性与流程属性5.1 为什么这是护城河很多引擎「能画节点」但审批语义退回范围、超时怎么处理、无人接收怎么办、是否自动跳过要靠二开补。驰骋把大量语义做成了节点/流程属性在设计器里配置运行期由引擎解释——这是产品化积累不是单次项目脚本。5.2 节点属性大类NodeAttr/NodeExt大类代表能力基本与运行模式节点类型、RunModel线形 / 分流 / 合流 / 分合流 / 同异表单子线程接收人DeliveryWay、参数、无人处理策略、是否排除发送人退回 / 撤销 / 跳转退回角色与范围、撤销规则、跳转方式与目标多人处理会签/协作模式、通过率、组长确认抄送自动抄送规则与写入方式超时与考核期限、预警、超时处理、考核方式阻塞阻塞模式与表达式表单方案表单类型、URL、节点表单绑定父子流程手动/自动/延续子流程配置入口未来处理人是否预计算接收人及提醒5.3 流程属性大类FlowAttr/FlowExt大类代表能力基本与标题分类、标题生成规则、草稿、是否可发起数据与表单业务表、开发模式、批发起、完整性校验等发起限制与前置导航限制角色/参数、引导方式、是否装载历史数据时限流程级期限角色与 SQL抄送与权限组抄送类型、可见范围发起人/参与人/部门等数据同步与业务表同步方式、指定节点事件实体FlowEventEntity/FlowMark绑定后端外挂轨迹展示时间轴、轨迹开关、子流程展示方式5.4 边界属性再全也覆盖不了所有行业特例复杂分支与深度集成仍要落到条件、事件与二开。护城河在于常见审批语义有现成开关而不是每个项目从零发明。六、接收人规则找人引擎产品化6.1 机制节点属性DeliveryWayDeliveryParas由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值枚举含义0HandSubFlow办理人手工启动子流程1AutoSubFlow到达/发送等时机自动触发2YanXuFlow延续子流程业务上接续办理配置落在WF_NodeSubFlowSubFlowHand/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 积木、国际生态工具链优先——应优先评估标准引擎或其衍生方案再决定是否需要驰骋这类表单/审批一体化产品。一句话驰骋的护城河不在口号而在「五表分立 组织找人 属性产品化 三模式二开 表单同栈 父子编排」这组已落地的工程结构用之前请对照源码与演示环境验证当前版本行为。