流程引擎BPM设计之：流程二开的三种模式

.流程引擎BPM设计之：流程二开的三种模式

摘要

驰骋 BPM 主张：流程可以设计出来，业务却不能写进引擎内核。
流程设计完成后，要用脚本与流程引擎交互，在发送成功、发送前、退回、结束等生命周期点嵌入业务逻辑——这一能力，我们称为流程二开。

CCFlow / JFlow 工作流引擎为此提供了三种编写脚本的模式：前端外挂、后端外挂、事件配置。
团队可按场景复杂度与技术特征选型，三种模式共用同一套事件语义（如SendWhen/SendSuccess），互为补充、互不排斥。

本文说明驰骋 BPM 对「流程二开」的设计思想与主张，重点记录关键设计决策，并以驰骋 BPM（CCFlow / JFlow）为实现对照。

一、什么是流程二开

1.1 定义

流程二开= 流程设计出来之后，用脚本与流程引擎交互，实现相关业务逻辑的过程。

典型场景：在发送成功时做业务同步、在发送前做校验拦截、在流程结束后写台账——不是改引擎源码，而是在固定挂接点嵌入执行一段脚本。

1.2 驰骋的主张

主张一：引擎稳定，业务外挂。
流程引擎只回答「怎么流转」；「流转时业务做什么」交给二开。

主张二：同一套事件时钟，三种写法。
不发明三套事件名；前端外挂、后端外挂、事件配置都认SendWhen、SendSuccess、FlowOverAfter等同一语义。

主张三：按团队选模式，不按产品逼模式。
前端强、后端强、配置优先——三种路径都合法，按场景与团队技术特征选择。

二、三种模式总览

管理端把「前后端外挂」与「事件配置」并置（事件列表工具栏可见「前后端外挂」），产品语义上三者是并列的二开入口，不是互相替代。

运行时分层（设计示意）

用户点击发送 ├─ ① 前端外挂：WGFlow_* / beforeSend ← 可拦截（UI 侧） └─ ② HTTP → 流程引擎发送编排 └─ ExecEvent（统一调度） ├─ OverrideEvent（全局后端拦截） ├─ FlowEventBase（流程级后端外挂） ├─ FrmEvents / GenerDBSrc（事件配置） └─ PushMsgs（消息推送，同事件标记） └─ ③ 前端 SendSuccess / afterSend ← 发送成功后的前端副作用

设计记录 R1：二开挂接点与消息推送共用事件标记，但执行职责分离——消息走PushMsg，业务走外挂/配置，避免「发消息的代码里夹业务」。

三、模式一：前端外挂

3.1 设计意图

前端外挂回答的是：「用户还在页面上时，要不要先校验、先提示、先改交互？」

适合：

• 发送前的表单完整性、金额/天数等即时校验
• 发送成功后的前端提示、局部刷新、调用浏览器侧能力
• 自定义工具栏按钮、打开表单后的 UI 初始化

不适合单独承担：强事务写库、跨系统强一致同步（应交后端外挂或事件配置中的服务端执行体）。

3.2 设计记录

3.3 能力边界（宣传口径）

• 轻量钩子：如beforeSend/afterSend，适合快速嵌入
• 流程外挂类：继承流程外挂基类，按流程号完整覆盖生命周期
• 字段级脚本：经典 JSLib / 表单字段脚本，属于更细粒度的前端扩展，可与流程外挂并存

主张四：前端外挂管「人机交互边界」，不管「系统真相边界」。
交互可拦在浏览器；业务真相以服务端事件为准。

四、模式二：后端外挂

4.1 设计意图

后端外挂回答的是：「引擎已经进入服务端生命周期，业务要以强类型、可调试的方式介入。」

适合：

• 发送前复杂规则、可改跳转节点 / 接收人
• 发送成功后写第三方待办、同步 ERP/主数据
• 需要访问引擎运行时变量（当前节点、WorkID、发送返回对象等）
• 平台级全局拦截（所有流程统一审计、统一组织策略）

4.2 设计记录

源码注释中的产品原话（设计思想直述）：

集成该基类的子类，可以重写事件的方法与基类交互；一个子类必须与一个流程模版绑定；基类里有很多流程运行过程中的变量，可辅助编写复杂业务逻辑。

4.3 与「改引擎」的本质区别

后端外挂写的是业务程序集，不是改NodeSend内核。
引擎升级时，业务 DLL / 包可独立保留——这是驰骋坚持「可二开而不改核」的技术承诺。

五、模式三：事件配置

5.1 设计意图

事件配置回答的是：「没有专职开发时，实施人员能否在设计器里把业务挂上？」

适合：

• SQL 校验 / 存储过程
• WebApi 同步外部系统
• 指向已有事件类、业务单元（BuessUnit）
• 节点事件、流程事件、表单事件的快速挂接

5.2 设计记录

5.3 能力边界

事件配置擅长「标准化连接」：查库、调接口、调过程。
当逻辑需要大量分支、强类型重构、深度使用引擎变量时，应升级到后端外挂；当逻辑主要服务页面交互时，应落到前端外挂。

主张五：低代码不是弱代码，而是把「简单集成」从程序员日程里解放出来。

六、如何选型（场景 × 团队）

设计记录 R2：三种模式允许叠加。
同一SendWhen可以：前端先拦 → 后端再拦 → 配置再执行。顺序固定、语义清晰，叠加不是混乱，而是分层。

七、设计思想小结（宣传要点）

1. 二开是一等公民：流程设计完成不等于项目完成；业务挂接点是产品能力，不是售后补丁。
2. 事件语义统一：前端、后端、配置认同一套时钟，降低培训与协作成本。
3. 核心不可污：升级路径建立在「业务在外、引擎在内」之上。
4. 模式服务团队：不是强迫全员写 DLL，也不是强迫全员只配 SQL。
5. 消息与业务解耦：同一事件点可推消息，也可跑脚本，二者独立配置。

八、以驰骋 BPM（CCFlow / JFlow）为例

以下用驰骋 BPM 开源引擎CCFlow（.NET）与JFlow（Java）说明上述思想如何落地。二者事件模型同源：事件名、二开分层、执行调度思想一致，差异主要在语言与程序集/包机制。

8.1 统一调度：ExecEvent

服务端由ExecEvent统一执行节点/流程/表单事件。节点发送时，大致顺序为：

1. 全局拦截（如OverrideEvent）
2. 流程事件实体（FlowEventBase后端外挂）
3. 配置事件（FrmEvents→ GenerDBSrc）
4. 消息推送（PushMsgs，同事件标记）

这直接对应本文「后端外挂 + 事件配置」的服务端分层。

8.2 前端外挂示例（CCFlow Vue3）

• 基类：WaiGuaBaseFlow（类名必须以WGFlow_开头）
• 约定：WGFlow_064绑定流程064
• 发送链路：工具栏先调SendWhen，服务端成功后再调SendSuccess
• 轻量替代：DataUser/OverrideFiles下的beforeSend/afterSend等钩子

含义：前端外挂不是「随便写个 onClick」，而是与后端同源的事件协议。

8.3 后端外挂示例（CCFlow）

DemoF065 : FlowEventBase：

• FlowMark = ",065,"绑定流程 065
• 重写SendWhen/SendSuccess
• 注释明确标注为「后端外挂」；返回err@...可阻止发送
• 类需进入BP.*.dll才能被反射解析

JFlow 侧以 Java 包 + 同类FlowEventBase思想对应，事件方法与标记保持一致，便于跨语言团队按同一文档实施。

8.4 事件配置示例（设计器）

• 节点属性 →「节点事件」；流程属性 →「流程事件」
• 写入Sys_FrmEvent，执行体走 GenerDBSrc（SQL / WebApi / SFProc / EventBase / BuessUnit 等）
• 事件列表工具栏提供「前后端外挂」帮助入口，产品上承认：配置与代码二开并存

举例：

8.5 一句话对照

结语

驰骋 BPM 对流程二开的态度很明确：

把流程设计好，把业务挂上去；挂的方式可以是前端外挂、后端外挂，或事件配置——按场景选，按团队选，但不要改引擎。

以 CCFlow / JFlow 为证：三种模式不是营销口号，而是源码里可运行、可演示、可交付的工程现实。

附录：关键源码索引（便于二次开发）

本文档属于「.流程引擎BPM设计之」系列，侧重设计思想与主张；具体 API 以当期产品帮助与源码为准。