在 RAP 里玩转 Events：从触发到消费的端到端实践

引子：为什么把Excel导入做成事件驱动

在企业应用里，RAP的一个常见场景是：用户在Fiori上点一个动作，把Excel数据导入到业务对象里。导入成功之后，往往还要做一串后续动作：发通知、触发校验、推送到接口、记录审计、启动审批，甚至把结果同步到别的系统。

如果把这些后续逻辑都塞进同一个动作实现里，代码会越来越臃肿，耦合越来越深：导入逻辑稍微改一下，通知逻辑也跟着受影响；想让别的团队订阅这个导入结果，也只能改你的代码。

事件驱动的价值就在这里：导入动作只负责把数据写入业务对象，并“发布一个事件”；后续处理由“事件消费者”完成。消费者可以在同一个系统里本地处理，也可以在未来扩展成跨系统订阅（配合Event Mesh或其它 broker）。事件本身通常包含触发实例的 key，外加少量必要的 payload，例如谁触发的、备注是什么、导入的批次号等。

下面用一个完整思路，把RAP Events从定义、携带参数、触发，到本地消费与事务阶段控制串起来。

---

事件在RAP BO里的基本形态

在RAP里，你可以在行为定义（BDEF）里声明事件，并为事件指定参数结构（通常用 abstract entity 描述）。触发事件时使用RAISE ENTITY EVENT ... FROM VALUE #( ...