工作流平台的消息触达设计：事件时钟、双轨模板与鉴权链接

流程引擎在事件执行后，如何把结果可靠地传递给相关人员？本文介绍一套消息触达设计：按设备划分内容类型、以 Token 保证链接可安全打开，并客观列出该设计的适用边界。

一、什么是流程消息

1.1 定义

流程消息 = 在事件执行过程中，把执行的内容与结果，传递给该流程实例上相关人员的过程。

典型场景：发送成功时，把提醒推给当事人（下一节点接收人）、其他节点人员（如申请人）、以及表单字段上的人员。

1.2 该平台的主张

主张一：消息是事件的一等产出，不是售后补丁。 发送成功、工作到达、退回、移交、流程结束——这些时钟点上，消息与业务脚本并列配置。

主张二：事件管逻辑，消息管触达。 不要在二开里到处 Port_SendMsg 散落；优先用消息模板绑定事件，二开只补例外。

主张三：人、内容、设备三分离。 「发给谁」「说什么」「用哪类设备接」各自可配，组合而不是绑死。

主张四：能打开，才算送达。 消息不是纯文本广播；内容里应有可点开的超链接，且链接必须经 Token 校验合法性。

二、流程消息总览

2.1 与事件对称

2.2 发送成功时的典型触达

用户点击发送 → 引擎流转成功（SendSuccess / WorkArrive）
                    │
                    ├─ 当事人：下一节点接收人（待办提醒）
                    ├─ 相关人：申请人、指定节点处理人、抄送人等
                    └─ 字段人：表单上「经办人」「抄送对象」等字段人员
                              │
                              └─ 按消息设备分发（站内信 / IM / 短信 / 邮件 / 企微 / 钉钉 / 飞书 / App…）

2.3 谁该收到消息

三、消息设备：接受消息的载体

消息设备 = 用于接受消息的载体。

设计要点：设备是通道，不是业务。同一条消息配置，可勾选多种设备；全局开关与节点级勾选可并存，便于「公司默认策略 + 流程个性策略」。

四、事件内容类型：短消息与邮件格式

根据场景不同，内容分为两类：

设计记录 R1：内容类型按「设备消费能力」划分，不按「业务事件」划分。 同一 SendSuccess 事件，可同时启用短消息模板与邮件模板；不是为每个事件发明第三种格式。

五、事件内容定义与打开超链接

5.1 内容定义

事件消息内容需要支持个性化设置，通常包含：

1. 标题（邮件格式必备）——可用 {Title}、@WebUser.Name 等变量
2. 内容——可用流程名、节点名、单号、退回意见等变量
3. 连接——用户点击后打开工作页面

示例（语义示意）：

• 短消息：有新工作{{Title}}需要您处理，发送人:@WebUser.Name，打开{Url}
• 邮件标题：新工作{{Title}}，发送人@WebUser.Name
• 邮件正文：您好，有新工作需要处理，点击这里打开 {Url}

5.2 打开超链接与 Token

打开超链接：消息设备上的链接，必须能安全打开目标页面——需要带 Token（加密字符串），用于身份与合法性校验。

设计要求：

没有 Token 的链接，不应被视为合格的流程消息出口。

六、设计记录（重点）

R1. 消息与事件同时钟、分配置

事件执行完后，按 EventNo 匹配消息条目再推送。 业务二开与消息推送都挂在 SendSuccess 等点上，但存储与配置界面分离，避免「改通知必须改代码」。

R2. 流程消息 / 节点消息对称于流程事件 / 节点事件

• 节点消息：绑定节点，适合「本节点发送成功通知下家」
• 流程消息：绑定流程，适合「流程结束通知发起人」等跨节点语义

同一产品能力，两级挂接，实施时按粒度选型。

R3. 人、文案、设备三轴正交

R4. 短消息与邮件格式双轨，而不是「万能正文」

IM/短信吃不了长 HTML；邮件/站内信又需要标题与主体。 双轨模板是故意的产品决策，降低「一条内容适配所有设备」的失败率。

R5. 默认模板保底，个性化可覆盖

每个事件类型提供默认标题/正文模板；未配置时仍可提醒。 配置了则覆盖默认——保证「开箱能用」，也保证「项目可定制」。

R6. 先入库、再分发；消息可消噪

消息先写入统一消息表（带 MsgFlag / MsgType / WorkID），再按设备发送。 流程结束、删除等节点可清理过期待办提醒，避免「流程已结束，站内信还在催」。

R7. 超链接必须可鉴权

打开 URL 携带 Token（或等价安全串）。 从消息点进系统 = 受控登录/打开工作，而不是裸露 WorkID 的公开地址。

R8. 机器节点默认可不推人

纯机器执行的节点（无人待办）在到达/发送成功时，可不推送人工消息——消息是给人的，不是给自动机的。

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

1. 流程消息是正式产品能力：事件发生后，相关人必须被系统化触达。
2. 与事件对称分类：流程消息 / 节点消息，跟流程事件 / 节点事件同构。
3. 设备可插拔：站内信、短信、邮件、企微、钉钉、飞书、App 都是消息设备。
4. 内容分型：短消息一段话；邮件格式要标题 + 主体。
5. 内容可个性化：变量替换 + 超链接，点开即办。
6. 链接必鉴权：Token 校验合法性，安全与体验一体设计。
7. 消息与二开解耦：同一事件点，脚本跑业务，消息做通知。

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

以下用该 BPM 平台开源引擎 该引擎（.NET） 与 该引擎（Java） 说明上述思想如何落地。二者消息模型同源：事件名、PushMsg 配置、平台系统表 落库、设备分发思想一致，差异主要在语言与宿主集成。

8.1 统一调度：事件之后推消息

服务端 ExecEvent 在执行节点/流程事件后，进入「处理消息推送」：

1. 仅对有消息意义的事件放行（如 WorkArrive、SendSuccess、ReturnAfter、ShitAfter、FlowOverAfter 等）
2. 读取节点的 HisPushMsgs（或流程的 PushMsgs）
3. 按 EventNo == doType 匹配条目
4. 调用 PushMsg.DoSendMessage(...) 生成文案并分发

这直接对应本文「事件与消息同时钟、分配置」。

8.2 配置实体：平台配置实体 / PushMsg

管理端：

• 节点属性 → 节点消息（NodeExt → PushMsgs）
• 流程属性 → 流程消息（FlowExt → PushMsgs）
• 编辑界面可见「短消息推送」「邮件」分组（如 NMGener）

8.3 内容模板：默认值 + 变量该引擎中 PushMsg.MailTitle / MailDoc / SMSDoc 在空配置时按事件给出默认模板，例如发送成功：

• 短消息：有新工作{{Title}}需要您处理, 发送人:@WebUser.No, @WebUser.Name,打开{Url}
• 邮件标题：新工作{{Title}},发送人@WebUser.No,@WebUser.Name
• 邮件正文：含标题、单号、{Url} 等

运行时替换 {Title}、{FlowName}、{NodeName}、@WebUser.*，并支持表单字段表达式继续替换。

8.4 消息落库与设备发送：平台系统表 / SMS

Dev2Interface.Port_SendMessage 写入 SMS 实体：

• 邮件侧：Title、DocOfEmail
• 短消息侧：MobileInfo
• 扩展：OpenUrl、PushModel、提醒规则等

实际发往邮件 / 钉钉 / 企业微信等时，由 SMS.SendMessage 结合全局开关与消息上的 PushType 决定走哪些设备；亦可经 OverrideEvent.SendToEmail / SendToDingDing / SendToWeiXin 做企业定制。

8.5 超链接与 Token

PushMsg.DoSendMessage 生成打开地址（示意）：

HostVue3URL + "#/WF/Port?DoWhat=OF&Token=" + GUID_WorkID_{EmpStr}_NodeID

要点：

• Token（此处为安全串 sid）绑定工作与接收人占位
• 按接收人替换 {EmpStr}，一人一链
• 消息设备上点击后走统一 Port 打开协议，再校验合法性

这对应本文主张四：「能打开，且打开可鉴权」。

8.6 一句话对照

8.7 与「流程二开」的关系

同一事件点上：

二者并列，不互相替代。需要个性化通知时优先配 PushMsg；只有通道或文案规则引擎覆盖不了时，再在二开里调用 Port_SendMsg / Port_SendMessage。

结语

该 BPM 平台对流程消息的态度很明确：

事件发生了，相关人就该被通知到；通知要分人、分文案、分设备，并且点开链接必须能安全打开工作——消息不是日志，而是流程体验的一部分。

以该引擎为证：流程消息与节点消息、短消息与邮件格式、多消息设备、Token 打开链路，都是源码里可配置、可运行、可交付的工程现实。