工作流引擎的事件体系设计：从节点事件到流程事件

节点事件管动作前后，流程事件管实例全生命周期。本文整理一套事件体系的设计决策、执行链与两大用途。

流程事件体系设计

摘要

该 BPM 平台主张：流程引擎负责“怎么流转”，事件体系负责“流转时业务怎么介入”。 在用户点击发送、退回、移交、结束、删除等操作时，引擎在固定生命周期点抛出事件；事件既可驱动消息推送，也可挂接业务脚本 / 外挂 DLL / WebAPI，实现“配置优先、代码兜底”的二开闭环。

本文说明该 BPM 平台对流程事件的设计思想与主张，重点记录关键设计决策，并以 该引擎（.NET）/ 该引擎（Java） 的实现对齐说明。

一、设计主张：事件是流程与业务的契约

1.1 什么是流程事件

流程事件 = 操作流程时发生的动作节点上的“可挂接点”。 典型操作包括：发送、退回、移交、撤销、结束流程、删除实例等。

该 BPM 平台将事件明确分为两类：

主张一：不要把业务逻辑塞进引擎内核；把业务挂在事件上。引擎保持稳定，业务按事件扩展。

1.2 为什么要定义事件

该 BPM 平台认为事件只有两个核心价值，且必须同时具备：

1. 用于发送消息 把“谁该被通知、何时通知、用什么通道通知”从代码中剥离，配置到事件上（邮件、短信、企业微信、钉钉、站内消息等）。
2. 用于流程二开、运行业务脚本 在发送前校验、发送后同步第三方、结束后写业务库、删除前拦截等，全部通过事件脚本 / 外挂实现，避免改引擎源码。

主张二：消息与业务脚本共用同一套事件时钟。同一时刻既可推消息，也可跑脚本，二者解耦、可独立配置。

1.3 与“硬编码回调”的区别

二、事件分类设计（设计记录）

2.1 节点事件（Node Events）

节点事件回答的是：“这个节点上，某次人机操作前后，要不要做事？”

设计记录（关键决策）

1. 前后对称优先 对会改变流程状态的动作（发送、退回、撤销），默认提供 Before / After。
   • Before：可抛错拦截（“阻止动作”）。
   • After：做通知与副作用（“动作已发生”）。
2. 发送拆成三态 不只“发送后”，而是 SendWhen（前）+ SendSuccess（成功）+ SendError（失败）。 原因：发送是最高频、最易失败、最需消息的动作，必须细粒度可控。
3. 工作打开也是事件 WhenReadWork 把“打开表单”纳入事件时钟，支撑已读、初始化、审计，而不是只在按钮点击时才有扩展点。
4. 产品扩展事件 源码在上述核心集之外，还沉淀了 WorkArrive（工作到达）、催办后、抄送后、加签后、节点预警/逾期等，体现“核心事件稳定、扩展事件可演进”。

说明：移交在引擎中以 移交后（ShitAfter） 为主落地；消息推送与业务同步通常发生在动作完成后。若项目需要移交前校验，可通过接口层或外挂前置逻辑实现，与节点 Before 事件同一思想。

2.2 流程事件（Flow Events）

流程事件回答的是：“这个流程实例从生到灭，关键时刻要不要做事？”

设计记录（关键决策）

1. 实例级与节点级分离 建单、结束、删除是实例生命周期问题，不应绑死在某一个业务节点上，故独立为流程事件。
2. 结束前可拦、结束后必通 FlowOverBefore 允许业务否决结束；FlowOverAfter 侧重归档与通知，异常不回滚已结束事实（与节点 After 同类语义）。
3. 删除必须可拦截 删除是破坏性操作，BeforeFlowDel 被设计为“可抛异常阻止”，避免误删导致业务数据悬空。

三、运行时架构：一条动作如何打到事件

3.1 统一调度入口

该 BPM 平台将事件执行收敛到 ExecEvent：

• 节点动作 → ExecEvent.DoNode(...)
• 流程动作 → ExecEvent.DoFlow(...)

发送路径示例（概念顺序）：

用户点击发送
  → NodeSendOrchestrator / WorkNode
    → ExecEvent.DoNode(SendWhen)     // 发送前：可拦截
    → 引擎完成路由、写待办、写轨迹
    → ExecEvent.DoNode(SendSuccess)  // 发送成功：脚本 + 消息
  失败时
    → ExecEvent.DoNode(SendError)

退回 / 撤销 / 移交 / 结束 / 删除同理，分别在 WorkReturn、WorkUnSend、ShiftWork、WorkFlow、流程删除链路中调用对应事件标记。

3.2 一次事件的多层执行链（设计记录）

ExecEvent 内部采用分层挂接，而不是单一回调：

一次事件的分层执行链对照：

主张三：同一事件可“叠多层”，但责任清晰——平台层、项目层、配置层、消息层互不替代。

3.3 配置型事件的执行方式

EventDoType 体现“配置优先”：

消息侧：EventList.xml 用 IsHaveMsg 标明哪些事件适合推送（如 SendSuccess、ReturnAfter、FlowOverAfter 为 1；多数 Before 为 0）。 引擎在 ExecEvent 中对可推送事件集合做白名单处理，避免“发送前校验事件”误发业务消息。

四、两大用途深挖

4.1 用途一：发送消息

设计主张：消息不是业务代码的副产品，而是事件的一等公民。

实践要点：

• 在节点/流程上配置 PushMsg，绑定事件号（如 SendSuccess、ReturnAfter、ShitAfter、FlowOverAfter）。
• 发送成功后，引擎根据接收人规则、模板、通道写入 Sys_SMS 并投递。
• 退回、移交、撤销、结束后，会按策略清理或刷新旧消息，避免“已办完仍提醒”。

典型场景：

4.2 用途二：二开运行业务脚本

设计主张：二开应“挂在事件上”，而不是“改在引擎里”。

三种常用二开形态：

1. 配置脚本（最快） 节点属性 / 流程属性 → 事件 → 写 SQL 或 WebAPI。
2. 流程外挂类（最稳） 继承 FlowEventBase，重写 SendWhen、SendSuccess、FlowOverAfter 等，用 FlowMark 绑定流程编号。 演示类：BP.App.Demo.F065。
3. 全局 Override（平台级） OverrideEvent 统一处理所有流程的某类事件（如统一写待办到门户）。

外挂可访问的上下文（设计有意暴露）：当前节点、WorkID、发送返回对象、接收人、可改转向的 JumpToNodeID / JumpToEmps 等——让二开“看得见引擎，但改不动内核”。

五、设计思想总结（该平台主张）

1. 事件是契约，不是补丁 先定义生命周期时钟，再让消息与业务挂接；避免项目各写一套回调。
2. 节点事件管动作，流程事件管全生命周期 发送/退回/移交属节点；建单/结束/删除属流程。边界清晰，配置不混乱。
3. Before 可拦，After 可通 用异常与返回约定表达控制权，减少“事后补偿”成本。
4. 消息与脚本同钟异轨 同一事件时刻，消息走 PushMsg，业务走 FrmEvent / 外挂，互不绑架。
5. 配置优先，代码兜底，全局可覆盖 顾问能配就不写代码；复杂逻辑进外挂；跨流程共性进 OverrideEvent。
6. 双栈同源 该引擎与该引擎共用同一事件语义与标记命名，降低跨语言团队协作成本。

六、以该 BPM 平台（该引擎）为例

6.1 产品定位

该 BPM 平台 提供两套等价实现：

二者在事件名称、触发时机、消息挂接方式上保持一致，企业可按技术栈选型，事件设计思想不变。

6.2 源码锚点（便于对照）

6.3 落地建议（给实施与二开）

1. 先配消息，再写脚本：80% 通知类需求用 PushMsg 完成。
2. 校验类逻辑优先挂 Before：发送前、退回前、结束前、删除前。
3. 同步外部系统挂 Success / After：避免动作未成功却已写外部库。
4. 多流程共性进 Override，单流程个性进 FlowEventBase。
5. 不要改 ExecEvent 内核：扩展应落在外挂与配置表。

6.4 一句话结论

该 BPM 平台（该引擎）用节点事件 + 流程事件把流程操作时刻产品化；用同一事件时钟同时支撑消息推送与业务二开。 这不是附加功能，而是引擎与业务解耦的核心设计主张。