消息交互与批量发起

从 UX 发起消息事件

工作流先定义消息及消息参数，在对应节点配置等待或订阅逻辑。UX 的“发起消息事件”动作需要与其配套。

1. 在 UX 事件中添加“发起消息事件”动作，选择关联工作流。

2. 选择该工作流定义的消息。

3. 为消息体参数赋值，类型与消息定义一致。

4. 选择接收范围。只通知某一次流程时，明确提供该流程实例 ID。

5. 保存后，让测试流程先到达目标等待位置，再发送消息。

6. 检查实例是否继续运行、消息参数是否按节点的数据映射传入后续变量。

当前动作支持把单个流程实例 ID 或实例 ID 数组作为指定范围的取值。若页面传入 $urlQuery.proc，先确认该值确实来自目标流程，而不是任务 ID 或业务编号。

消息发送成功与业务处理完成是两件事。 接收范围、消息定义或等待位置不匹配时，应检查流程中的接收条件，不能只凭 UX 的发送成功提示认定后续业务已经完成。

批量发起流程

“发起流程”动作选择批量方式后，参数表达式应返回 对象数组，每个对象表示一条流程实例的启动参数。

下面是数据结构示例，不是固定业务数据：

[
  { "contract_id": "HT-2026-001", "amount": 1200.5 },
  { "contract_id": "HT-2026-002", "amount": 3600 }
]

对象的属性名对应工作流启动参数编码。不要使用 wfi$contract_id 作为属性名，也不要返回一段包含上述 JSON 的字符串。

重试前先核对结果

批量操作发生异常时，先查询哪些业务已经成功发起，再处理失败部分。不要在未核对结果时直接重复提交整批数据；尤其要检查业务键唯一规则和重复记录。

批量发起用于生成多个独立的流程实例；若业务要求父流程等待各部门办理并汇总结果，应阅读 多实例子流程，按父子流程的控制关系设计。