海外子公司的订单已经保存成功，总部页面却还看不到最新状态。开发人员打开日志，发现保存程序没有报错，于是又去查接口、消息队列和后台任务。这个场景很适合借用黄药师的碧海潮生曲来理解。琴声从一处发出，沿途传播，进入不同人的感知范围，最终产生的影响又取决于各人的状态。在企业系统里，一笔业务变化也可以从一个确定的发生点出发，经过事件发布、消息传递和后台处理，让多个系统作出各自的反应。但 ABAP 中没有一项叫作碧海潮生曲的技术，也不存在发出一次信号就能自动控制整套系统的神奇语句。这个类比真正有价值的地方，是帮助我们分清四件事，何时发声、声音如何传出去、谁应该听见、听见后能否承受。对应到开发实践，涉及事务提交、业务事件、异步处理、订阅规则、幂等控制和运行监控。少了任何一环，琴声都可能中途断掉，或者在不该响的地方引起混乱。碧海潮生曲给人的印象，并非只靠一记突如其来的重击。它有持续的节奏，也有逐渐增强的影响。放进订单场景，较贴切的对应不是对同一张订单反复发送通知，而是把业务流程中的不同变化表达成清楚的信号。订单创建是一种状态变化，信用检查通过是另一种状态变化，交货完成又是另一种状态变化。接收方可以只关心其中一种，也可以按流程组合处理。每一个信号都要有准确的业务含义，不能把系统里发生的任何技术动作都当成值得向外传播的事件。这就碰到第一个关键问题，琴声究竟从哪里起。订单界面上的保存按钮被点击，并不等于订单已经可靠地保存。程序可能还在校验，后续也可能因为库存、权限或其他业务规则失败而回滚。如果此时先向外部系统报告订单已创建，外部系统开始安排交付，而本地订单最终没有落库，两边看到的事实就冲突了。SAP 的 RAP 事务模型把一致性检查与保存纳入受控的保存序列，业务事件的定义和发出也有相应的行为实现位置。设计事件时，我们应当从已经确认的业务