消息交互与批量发起
从 UX 发起消息事件
工作流先定义消息及消息参数，在对应节点配置等待或订阅逻辑。UX 的“发起消息事件”动作需要与其配套。
-
在 UX 事件中添加“发起消息事件”动作，选择关联工作流。
-
选择该工作流定义的消息。
-
为消息体参数赋值，类型与消息定义一致。
-
选择接收范围。只通知某一次流程时，明确提供该流程实例 ID。
-
保存后，让测试流程先到达目标等待位置，再发送消息。
-
检查实例是否继续运行、消息参数是否按节点的数据映射传入后续变量。
当前动作支持把单个流程实例 ID 或实例 ID 数组作为指定范围的取值。页面接收单个目标流程 ID 时，先声明外部变量 proc，在来源流程的跳转参数中赋值，再在发送范围选择【UX变量 → proc】。确认传入的是目标流程 ID，而不是任务 ID 或业务编号。向父流程发消息时，应另用外部变量 parent_proc_id 接收 wfp$parent_proc_id，发送范围选择【UX变量 → parent_proc_id】。若目标实例由当前页面的选择控件选定，则选择【控件值】取得实例 ID，无需绕回外部变量。
消息发送成功与业务处理完成是两件事。 接收范围、消息定义或等待位置不匹配时，应检查流程中的接收条件，不能只凭 UX 的发送成功提示认定后续业务已经完成。
操作演示：报销审批后等待线下付款
本例将“等待消息”放在报销审批之后。流程先停在此处；出纳完成线下付款并在 UX 确认后，UX 向选定的实例发送消息，流程继续通知报销人并结束。
- 打开消息交互 UX 配置：元素
send_message_event，切换“使用”可体验。 - 打开“等待消息”工作流配置：元素
catch_message，与上述 UX 配套使用。
Demo 位于 Alpha 环境，需登录并具有应用与元素访问权限。
-
如果页面没有可选实例，点击“发起一个等待消息的流程实例”。
-
从“去处理待办”依次完成提交报销、同意审批，再返回页面刷新流程信息。
-
确认当前实例已到达“等待消息—等待线下打款”。此时暂停推进是预期行为。
-
在页面选择本次实例，填写付款人和付款金额，点击“确认付款完成（给工作流发送消息）”。此按钮模拟付款确认，不会实际转账。
-
查看通知内容和刷新后的流程记录，确认消息携带的付款信息已用于通知，流程继续到结束。
查看配置时，将三处对应起来：工作流定义的消息及参数 → 等待消息节点订阅的消息与数据映射 → UX 动作选择的消息、目标实例范围与参数。付款人和金额等直接取页面输入的值，优先使用【控件值】。
同样的方式可用于等待 Python 处理完成、外部系统回调等场景，但完成处理的一方仍需显式发送对应消息，并定位正确实例；等待消息节点不会自动监测脚本或外部接口是否完成。节点属性见 等待消息。
批量发起流程
单条与批量发起的操作视频、在线 Demo 及测试实例清理步骤，见 发起流程操作演示。
“发起流程”动作选择批量方式后，参数表达式应返回 对象数组，每个对象表示一条流程实例的启动参数。
下面是数据结构示例，不是固定业务数据：
[
{ "contract_id": "HT-2026-001", "amount": 1200.5 },
{ "contract_id": "HT-2026-002", "amount": 3600 }
]
对象的属性名对应工作流启动参数编码。不要使用 wfi$contract_id 作为属性名，也不要返回一段包含上述 JSON 的字符串。
配置步骤
-
确定批量来源，例如业务列表中已选中的、已保存的合同。
-
在事件表达式中取出这些记录，为每条记录构造启动参数对象。
-
对空选择、缺少主键、金额类型错误和重复业务先进行校验。
-
选择批量发起，将对象数组作为批量参数；按需配置备注。
-
使用两条测试数据运行，并在流程监控中逐一核对实例与业务的对应关系。
重试前先核对结果
批量操作发生异常时，先查询哪些业务已经成功发起，再处理失败部分。不要在未核对结果时直接重复提交整批数据；尤其要检查业务键唯一规则和重复记录。
批量发起用于生成多个独立的流程实例；若业务要求父流程等待各部门办理并汇总结果，应阅读 多实例子流程，按父子流程的控制关系设计。
回到顶部
咨询热线
400-821-9199
