企业官网建设流程全解析

这段时间一直在SAP S/4HANA Public Cloud上折腾销售订单相关的增强，最让我觉得值得沉淀的，是用 RAP BO 事件（RAP Business Object 的 Event）把“销售订单待确认数量自动拆分”这件事做成了一套事件驱动的本地消费链路。RAP，也就是 ABAP RESTful Application Programming Model，现在是 S/4HANA Cloud 上开发业务对象的标准方式；BO 事件则是行为定义里显式声明的抽象事件，和传统 ABAP 的 raise event 是两码事。

这个方案解决的是一个很现实的计划问题：销售订单行项目里经常有“客户要 100，系统 ATP 只确认了 30”的缺口，剩下的 70 就是待确认数量。麻烦的是，这 70 后续会随着供应、采购、排产的变化被拆成多条不同交期的承诺。如果不做事件驱动，就只能把“判断缺多少”和“怎么拆、拆给谁”的逻辑死死耦合在一个类里，大家抢着改同一个方法，发布顺序也要跟着排。用了 RAP BO 事件之后，销售订单 BO 只负责发出“这里出现了待确认数量需要拆分”的事件，另一个 BO 在本地订阅这个事件，自己决定怎么拆、什么时候确认。发布方和消费方各自独立演进，耦合点收敛到事件参数这一张“合同”上。

这篇文章我会把业务背景、事件建模、BDEF 配置、行为实现类的关键代码，以及我在 Public Cloud 上踩过的坑完整梳理一遍。适合正在做 RAP 增强、或者想理解 S/4HANA Cloud 里“本地消费”到底是怎么运作的朋友，看完基本可以直接照着自己项目抄作业。

1. 先想清楚：这个方案到底在解什么业务问题

1.1 “待确认数量”和“拆分”在销售订单里是怎么回事

SAP 标准销售订单里，一行项目通常对应多个计划行（Schedule Line）。系统做完 ATP 可用性检查后，计划行上会有确认数量（Confirmed Quantity）和待确认数量。最常见的情况是：客户下了一张 100 件的订单，可用库存和已分配产能只够满足 30 件，也就是说确认数量只有 30，剩余 70 会被挂起，状态可能是“部分交货”“无可用库存”之类。这 70 就是待确认数量，在用户看来，它已经挂在订单上，但并没有真正变成供应承诺。

等采购补货、生产入库或供应分配策略发生变化后，原本那 70 件不太可能一次性全部确认——可能是 30 件可以在两周内出货，20 件要等到下个月，剩下 20 件要到更晚的交期。这时候就需要“拆分”：把一笔待确认数量拆成多条子确认记录，每条记录有独立数量、确认日期、优先级、状态，甚至不同的工厂和库位。这就是标题里说的“自动拆分销售订单待确认数量”。

我在实际项目里的一个简化模型是这样的：

如果你用传统增强，很容易把“拆多少、怎么拆”直接写死在销售订单 BO 的某个 action 里。短期看没问题，一旦确认规则从“按到货日期拆”变成“按客户优先级拆”，或者要在拆分时联动库存预留单、采购申请单，那就会越改越乱，所有逻辑互相引用，谁都不敢动。

1.2 为什么不是直接调用，而是用事件

在 RAP 模型里，当然可以在一个 BO 的 action 里直接调用另一个 BO 的 action，或者用MODIFY ENTITIES直接改别的 BO 数据。问题是这种“直接调用”会让两个业务对象形成编译期依赖：销售订单 BO 要编译通过，就必须先有目标 BO 的行为定义；目标 BO 一改接口，销售订单 BO 也要跟着重新发布。在 S/4HANA Public Cloud 这种交付节奏很快的环境里，这种耦合非常难受。

RAP BO 事件的价值在于：销售订单 BO 不关心“谁”在消费事件，也不关心消费之后做了什么。它只负责在恰当的业务时机，把事件和相关参数抛出来。订阅方在自己的 BO 行为定义里通过on event ... of 某个BO声明我关心这个事件，然后在实现类里写处理逻辑。发布方和订阅方之间唯一的硬依赖，就是事件名和事件参数的字段结构。

还有一个很实际的好处：可扩展性。以后如果不止“待确认数量拆分器”要响应这个事件，还有另一个“订单日志分析器”也要跟随记录，那只需要新增一个 BO 去订阅同一个事件，销售订单 BO 的代码一行都不用改。这在传统 ABAP 里通常要靠 BAdI 或者增强点，在 RAP 里用事件天然就是松耦合的。

标题里特别强调“本地消费”，这里的“本地”指的是同一租户内部、同一个 S/4HANA Cloud 系统环境内的事件消费。与之相对的是通过通信场景（Communication Scenario）加 Event Mesh 之类的远程事件集成。本地消费的好处是：事情发生在同一个事务上下文里，发布方触发事件后，订阅方可以立即在同一业务事务内处理，不需要考虑跨系统消息队列、重试和最终一致性。这段我们是后面要重点实现的。

2. 本地事件消费的技术模型拆解

2.1 RAP BO 事件的完整链路：从 BDEF 到消费者 Handler

RAP BO 事件不是凭空“抛出来”的，它的生命周期可以分为四步：

1. 在发布方 BO 的行为定义（BDEF）中声明事件，比如event OnConfirmSplit parameter ...。
2. 在发布方行为实现类的某个方法（通常是 action 或 determination）中，通过RAISE ENTITY EVENT触发事件。
3. 在订阅方 BO 的 BDEF 中，使用on event OnConfirmSplit of ZI_SalesOrder声明对该事件的兴趣，并绑定到订阅方自己的实现类。
4. 在订阅方实现类中，写一个专门处理该事件的方法，方法签名就是FOR ENTITY EVENT OnConfirmSplit OF ZI_SalesOrder。

这里要注意，BDEF 中的事件定义位于行为定义块内，和 action、determination 在同一个层级。比如：

define behavior for ZI_SalesOrder alias SalesOrder implementation in class zbp_sales_order unique persistent table zsd_so_h lock master authorization master( instance ) etag master lastchangedat { field ( readonly ) OrderUuid; field ( readonly ) CreatedAt; field ( mandatory ) CustomerId; action SplitConfirmation parameter ZSD_SplitConfirmParam result [1] $self; event OnConfirmSplit parameter ZSD_ConfirmSplitEvent; association _item { create; with draft; } }

表面上看，事件定义只有一行，但它背后其实定义了一份“对外合同”。因为事件参数ZSD_ConfirmSplitEvent是标准的 DDIC 结构，订阅方只要依赖这个结构，就能稳定对接，不需要去关心销售订单 BO 内部有哪些节点、哪些字段。

另外补充一点：RAP BO 事件属于业务对象所持有的抽象事件，它的生命周期和 BO 实例相关，和传统的 ABAPRAISE EVENT全局事件完全不同。它只能在中“BO 上下文环境”里触发，建议在 action、determination 这些业务方法内触发，不能在任意类里随手 raise。

2.2 事件参数是硬接口：结构就是合同

在 RAP 里，事件既可以不带参数，也可以带一个结构化参数。我强烈建议你给事件定义一个参数结构，而且这个结构里一定要包含发布方 BO 的根实例键，或者其他能唯一定位业务数据的业务键。

为什么？因为订阅方收到事件后，十有八九要反查发布方订单的数据。如果事件参数里没有OrderUuid、ItemNo这类字段，订阅方就只能拿到一串抽象的事件引用，根本不知道是哪张订单、哪个项目出了问题。实战中这是最容易翻车的地方，很多人把事件定义成无参事件，发出去之后订阅方完全无法处理。

一个可用的参数结构大概长这样：

define structure ZSD_ConfirmSplitEvent { order_uuid : sysuuid_x16; " 发布方根节点键 item_no : abap_int4; " 行项目号 open_qty : abap_quan_13(3); unit : meins; target_date : dats; }

事件参数不要做得太大。有人会习惯把整个订单模型的全部字段都塞进去，觉得反正订阅方需要什么就有什么。但在 RAP 事件里，参数应该是“事件的语义摘要”，而不是“数据快照”。你塞得越多，将来字段一变，订阅方就得跟着升级。我建议只传业务键、数量、日期这几个必要字段，订阅方需要更多数据时通过READ ENTITIES去读发布方 BO。

还要强调事件的一个特性：它是单向通知，不能像 action 那样返回结果给调用方。如果你想在拆分成功后把结果展示到 UI 上，应该把拆分结果写到 BO 的持久化节点里，然后 UI 重新读取数据；事件本身不是为了“返回值”而存在的。这也是很多新手刚接触 BO 事件时觉得别扭的地方。

2.3 本地消费与远程消费的边界

前面说了“本地消费”，把它和远程消费放在一起对比会更清楚。SAP 在 S/4HANA Public Cloud 里支持两种事件消费途径。一种是我们这篇博文的主角：同一租户内另一个 RAP BO 通过 BDEF 直接订阅并处理，这就是本地消费。另一种是把 BO 事件封装到通信场景里，事件发布到云集成/事件网格之类，由外部系统或另一个租户消费，那就是远程消费。

两种方式的选择，主要看业务边界。如果拆分逻辑仍然属于销售域，只是分散在不同 BO 里，用本地消费完全够，而且实现成本低，同一个事务完成后数据就是一致的。如果拆分后还要触发下游 ERP 外系统、伙伴系统或者另一个业务线，那才需要远程事件。不要把本地方案硬套成远程架构，否则你要处理的序列化、传输可靠性问题会立刻拉高复杂度。

下表是我常用的判断方式：

3. 从零实现：销售订单待确认数量拆分本地消费

3.1 准备工作：包、底表、CDS 视图

进入实操前，先规划一下开发对象。我在项目里都是按“导出/导入”的思路组织的：干净的包名，比如Z_SD_ORDER_SPLIT，里面放数据库表、CDS 视图、行为定义、行为实现类、服务绑定。S/4HANA Public Cloud 的 ABAP 环境里开发工具是 ADT（ABAP Development Tools），注意别再用传统 SE80 那套思维了，很多事务代码在云里是禁用的。

销售订单 BO 我用最简单但完整的三层结构：订单头、订单项目、订单确认子项。数据库表我用三张，分别是ZSD_ORDER_H、ZSD_ORDER_IT、ZSD_ORDER_CN。订单头表字段不多，几个核心字段加上管理字段：

define table zsd_order_h { key order_uuid : sysuuid_x16; order_no : zorder_no; customer_id : zcustomer_id; total_qty : zqty; created_at : timestampl; last_changed_at : timestampl; }

订单项目表ZSD_ORDER_IT放关键的数量缺口信息，例如需求数量req_qty、已确认数量conf_qty、待确认数量open_qty。这个待确认数量不是静态存储的，理论上可以通过req_qty - conf_qty算出来，但为了界面展示和事件判断方便，我通常会落一个冗余字段，同时通过验证规则保证它总是等于差值。有点冗余，但省掉很多查询时的计算。

订单确认子项表ZSD_ORDER_CN就是拆分产出的结果集，一条记录代表一笔拆分确认：拆分数量split_qty、确认日期confirm_date、状态status。一开始它是空的，只有 ATP 检查不满足事件触发后才会被填充。

CDS 视图方面，我定义了一个根视图一个子视图。根视图ZI_SalesOrder：

define root view entity ZI_SalesOrder as select from zsd_order_h composition [1..*] _item { key order_uuid, order_no, customer_id, total_qty, created_at, last_changed_at }

子视图ZI_SalesOrderItem把项目字段带出来：

define view entity ZI_SalesOrderItem as select from zsd_order_it association to parent ZI_SalesOrder as _parent { key order_uuid, key item_no, req_qty, conf_qty, open_qty, unit }

这里不展开所有 CDS 细节，重点是行为定义和事件。CDS 视图写好后，用 ADT 的快速修复生成行为定义，然后补上事件和 action。

3.2 发布方：在 Action 中发起拆分并触发事件

现在关键来看 BDEF。首先需要补一个订单确认子节点的行为，并给根节点增加一个 action，我命名为SplitConfirmation。它接收的参数传入“要拆多少、目标确认日期”，在行为实现里执行拆分，然后触发OnConfirmSplit事件。

行为定义完整示意：

define behavior for ZI_SalesOrder alias SalesOrder implementation in class zbp_sales_order unique persistent table zsd_order_h lock master authorization master( instance ) etag master lastchangedat { field ( readonly ) OrderUuid; field ( readonly ) CreatedAt; field ( mandatory ) OrderNo, CustomerId; association _item { create; with draft; } action SplitConfirmation parameter ZSD_SplitConfirmParam result [1] $self; event OnConfirmSplit parameter ZSD_ConfirmSplitEvent; } define behavior for ZI_SalesOrderItem alias Item implementation in class zbp_sales_order_item unique persistent table zsd_order_it lock dependent { field ( readonly ) OrderUuid; field ( readonly ) ItemNo; association _confirm { create; with draft; } } define behavior for ZI_SalesOrderConfirm alias Confirm implementation in class zbp_sales_order_confirm unique persistent table zsd_order_cn lock dependent { field ( readonly ) OrderUuid; field ( readonly ) ItemNo; field ( readonly ) SplitNo; field ( mandatory ) SplitQty, ConfirmDate; field ( readonly ) Status; }

Action 的输入参数ZSD_SplitConfirmParam是自定义结构，我给它放了四个字段：

define structure ZSD_SplitConfirmParam { order_uuid : sysuuid_x16; item_no : abap_int4; split_qty : zqty; confirm_date : dats; }

然后在行为实现类ZBP_SALES_ORDER里实现这个 action。核心逻辑分为三步：校验并计算缺口、创建确认子项、触发事件。因为事件参数需要根实例键，所以RAISE ENTITY EVENT的FROM部分要传入订单头键，ADD TO部分传入参数结构。示例代码：

METHOD SplitConfirmation. READ ENTITIES OF zi_salesorder IN LOCAL MODE ENTITY SalesOrder FIELDS ( OrderUuid ) WITH VALUE #( FOR key IN keys ( OrderUuid = key-OrderUuid ) ) RESULT DATA(order_list). " 这里的 keys 为事务内触发的参数，实际实现时还需要和行项目数据校验 DATA(split_qty) = keys[ 1 ]-param-split_qty. DATA(item_no) = keys[ 1 ]-param-item_no. DATA(cdate) = keys[ 1 ]-param-confirm_date. " 创建拆分确认子项 MODIFY ENTITIES OF zi_salesorder IN LOCAL MODE ENTITY Confirm CREATE FROM VALUE #( ( OrderUuid = keys[ 1 ]-OrderUuid, ItemNo = item_no, SplitNo = 1, SplitQty = split_qty, ConfirmDate = cdate, Status = 'A' " Active ) ) REPORTED DATA(create_reported). " 触发事件 RAISE ENTITY EVENT OnConfirmSplit FROM VALUE #( ( OrderUuid = keys[ 1 ]-OrderUuid ) ) ADD TO VALUE #( ( OrderUuid = order_list[ 1 ]-OrderUuid, ItemNo = item_no, OpenQty = split_qty, Unit = 'PC', TargetDate = cdate ) ). ENDMETHOD.

代码里有一处需要特别说明：在真实项目中，事件触发前通常先读一次行项目，确认open_qty确实大于等于拆分数量，再创建确认子项。为了控制篇幅，我略去了这部分，但你写生产代码时千万不要跳过校验。如果缺口是 70，你拆了 80 件，业务上是绝对不允许的。

关于RAISE ENTITY EVENT的语法细节，不同 RAP 版本下写法略有差异，特别是FROM和ADD TO的组合方式，这是我看 ADT 版本提示逐步确认的。你如果在 ADT 里遇到语法报错，先检查是不是把参数结构名写错，或者把ADD TO写成了WITH。这类问题在云环境中不像 ABAP 编辑器有完善的快速修复提示，建议多用内置的语法检查。

3.3 订阅方：在另一个 BO 里写 ON EVENT Handler

发布方已经把事情说清楚了，订阅方登场。我设计了一个“可用性计划调度”BO，名字叫ZI_AvailabilityScheduler，它负责接收销售订单发来的待确认拆分事件，并将拆分数量落入自己管辖的供应计划表ZSD_AVA_SCHED。

这个消费者 BO 不需要知道销售订单的内部实现，它只要在 BDEF 里声明“我订阅ZI_SalesOrder的OnConfirmSplit事件”就行。BDEF 的写法：

define behavior for ZI_AvailabilityScheduler alias AvailabilityScheduler implementation in class zbp_availability_scheduler unique persistent table zsd_ava_sched lock master authorization master( instance ) etag master lastchangedat { field ( readonly ) SchedulerUuid; field ( mandatory ) OrderUuid; field ( mandatory ) ItemNo; field ( mandatory ) SplitQty; field ( mandatory ) ConfirmDate; field ( readonly ) Status; on event OnConfirmSplit of ZI_SalesOrder implementation in class zbp_availability_scheduler unique; }

注意 BDEF 里的on event ... of引用，事件源必须写发布方 BO 的根行为实体，不能写子节点或者视图别名。订阅行为实现在ZBP_AVAILABILITY_SCHEDULER类中，处理方法用FOR ENTITY EVENT来声明：

CLASS zbp_availability_scheduler DEFINITION PUBLIC ABSTRACT FINAL FOR BEHAVIOR OF zi_availabilityscheduler. PUBLIC SECTION. METHODS on_confirmsplit FOR ENTITY EVENT OnConfirmSplit OF zi_salesorder IMPORTING keys. PROTECTED SECTION. PRIVATE SECTION. ENDCLASS.

方法实现里，keys的结构和事件参数结构一致，也就是ZSD_ConfirmSplitEvent。拿到参数后直接创建自己的排程记录：

METHOD on_confirmsplit. MODIFY ENTITIES OF zi_availabilityscheduler IN LOCAL MODE ENTITY AvailabilityScheduler CREATE FROM VALUE #( FOR key IN keys ( SchedulerUuid = cl_system_uuid=>create_uuid_x16_static( ), OrderUuid = key-OrderUuid, ItemNo = key-ItemNo, SplitQty = key-OpenQty, ConfirmDate = key-TargetDate, Status = 'P' ) ) REPORTED DATA(reported_data). " 可以在这一步继续调用发布方 BO，更新订单确认状态 ENDMETHOD.

这类“订阅方修改自己 BO 数据”的例子最清晰，消费者只关心自己领域的动作。如果你还想让订阅方把销售订单的确认状态从“待确认”改成“已拆分”，就需要在 handler 里用MODIFY ENTITIES OF zi_salesorder ...去更新发布方节点——这是允许的，因为本地消费在同一个事务上下文里。但我提醒你：处理时要谨慎，不然事件反复触发，容易出现循环更新。后面问题排查里我会说怎么控制。

3.4 服务发布与手动测试步骤

在 S/4HANA Public Cloud 里，RAP 开发完成后要通过服务绑定将 CDS 视图或 BO 暴露给 UI。常用的是 OData UI 服务绑定，发布后生成 Fiori Elements 预览。测试流程我大概是这样的：

1. 把销售订单 BO、可用性计划 BO 都创建服务绑定，类型选OData UI，绑定后激活。
2. 在服务绑定里点预览，用 Fiori 模拟界面创建一张销售订单，订单数量写大一点，保证 ATP 不会全部确认。
3. 在 UI 上调用SplitConfirmationaction，输入拆分数量和目标日期。
4. 检查订单确认子项是否生成，检查可用性计划表是否出现对应记录。
5. 如果 UI 预览不方便，可以直接用 ADT 里的 ABAP Development 调试或写 ABAP Unit，用READ ENTITIES验证。

Public Cloud 没有传统后台调试器那么好用，单步跟踪还是有的，但跨 BO 的本地事件调用链在调试器里的体验不如 on-prem。更多时候，我依赖自定义应用日志表记录事件处理结果。就是在 handler 里把收到的keys转成 JSON 或者结构化文本写进日志表，这样即使事件没生效，也能从日志反推问题。

4. 实际落地中遇到的坑与排查清单

4.1 “事件不更新”的三种常见原因

如果你在网上搜 RAP 事件，很容易看到“事件不更新”这个说法。我在项目里也遇到过，表面现象是：Action 明明执行成功了，界面也提示创建了确认子项，但订阅方 BO 里的数据根本没有产生新记录。这里把可能的原因理成三类。

第一类，事件触发语句放在了未被执行的代码分支里。比如 action 实现用了很多CHECK和IF，其中某个分支RETURN了，RAISE ENTITY EVENT在最后一行根本没有执行。这个问题最隐蔽，因为界面不会报错，你只会发现订阅方静默无响应。建议在触发语句前后各留一条日志，确认执行路径。

第二类，事件名称或者参数类型在 BDEF 和实现类里不一致。比如 BDEF 里写的是OnConfirmSplit，实现类里写的是on_confirmsplit，ABAP 关键字不区分大小写，但事件定义是区分类型的，只要有一点点拼写不一致，订阅方就收不到。

第三类，事务回滚导致事件“看起来”没有更新。RAP 中事件触发和消费者修改都在同一个 LUW，如果后续某个校验失败导致隐式回滚，消费者创建的记录也会一起消失。这不是 RAP 的 bug，而是本地消费的语义。所以排查时先看整个事务是否成功提交，而不是只看事件有没有发出。

4.2 点击 Action 常见错误：按钮报错但事件没发出

在 Fiori 预览里点击按钮调用 Action，如果报了一个泛泛的“行为执行失败”，第一反应别去翻订阅方，先查发布方自己的 Action 实现。事件驱动链路里，发布方永远是第一道关卡。

我遇到最多的是字段授权问题。Public Cloud 里的 RAP BO 支持authorization master( instance )，如果你的测试用户没有对应订单数据的实例授权，MODIFY ENTITIES会返回权限错误，Action 直接fail，事件自然不可能触发。这种问题在本地单元测试里反而不容易出现，因为单元测试往往绕过了授权检查。

还有一种情况是把事件触发放到了MODIFY ENTITIES之前，顺序颠倒了。事件触发的本意是“拆分已经发生”，那么创建确认子项应该在前面，事件抛应在后面。如果先抛出事件再修改，订阅方在同一事务里去读销售订单数据，会发现拆分还不存在，于是按旧数据处理，逻辑就错乱了。所以代码顺序必须是：先写业务结果，再通知世界。

4.3 事件不会“冒泡”到父节点

有人会把前端的事件冒泡概念下意识地带到 RAP BO 里，以为子节点触发了事件，父节点或者其他子树也能自动感知。实际上 RAP BO 事件不存在冒泡机制，你触发了Order根节点的事件，Item节点和Confirm节点都不会自动收到通知。消费者想要哪一层的数据，就要明确监听哪个行为实体的事件，并在事件参数里传递对应层级的主键。

我在这个项目里有个实际教训：一开始把事件定义在项目子节点ZI_SalesOrderItem上，参数里只带了ItemNo，结果订阅方拿不到OrderUuid，只能在处理时通过READ ENTITIES去反查父节点。费了点功夫，但也算是理解了 RAP 事件的粒度问题。更稳的做法是从设计上就把事件挂到根节点上，根节点的事件语义通常更清晰，订阅方也不用做太多层级回溯。

4.4 循环触发与性能问题

本地消费的一个隐含风险，是消费者在 handler 里修改了发布方 BO，而这个修改又触发了同一个事件，变成无限循环。比如可用性计划器把订单状态从 P 改成 C，订单 BO 的某个 determination 检测到状态变化，又RAISE ENTITY EVENT OnConfirmSplit，这就炸了。

我的做法是在事件参数里加一个SourceSystem或者SplitSource字段，消费者处理完数据后带上标记，发布方看到这个标记就不再进一步触发。简单说，事件要设计成有“方向”的，要能区分“首次发起”和“回调处理”。另外，事件参数结构越薄，处理速度就越快，消费者如果需要更深的数据，宁可多一步READ ENTITIES，也别把整个订单视图塞到事件里，否则大订单场景下事件链路性能会明显的差。

4.5 一套快速排查速查表

把实际问题整理成表格，遇到问题可以对着查：

4.6 关于 Public Cloud 测试与日志的补充

本地消费开发完，最费时间的环节其实是验证。S/4HANA Public Cloud 里不能像传统系统那样随便看数据库表数据，我用两个手段搞定验证。一个是在行为实现类里写应用日志，通过cl_message_collector和自定义日志表记录事件前后关键数据；另一个是在 CDS 视图上写只读查询服务，直接暴露给另一个 UI 或集成测试脚本，批量验证数据结果。

这里也提醒一句：Public Cloud 的对象发布有一套严格流程，你开发完的包最终要通过软件集合传输到测试租户和生产租户。本地事件消费的发布方 BO 和订阅方 BO 如果是两个包，发布顺序很重要：先发布事件参数结构，再发布发布方和订阅方，避免订阅方编译时找不到参数类型。我建议把事件参数结构单独放在公共包，两边都依赖它，这样能减少很多传输顺序的头痛问题。

最后补一句我的实际体会

这个方案跑完一遍之后，我最大的感受是：RAP BO 事件在 S/4HANA Public Cloud 里的定位，不是用来救急的“万能回调”，而是长期演进下的领域解耦工具。如果你只是想让两个类互相调用，直接调可能更快；但如果你面对的是销售订单、供应计划这样在未来半年还会持续加需求的业务对象，那花半天把事件边界理清楚，后面能省下大量联调时间。还有一个小技巧，事件参数结构命名时最好加上业务语义的后缀，比如_ConfirmSplitEvent，这样在订阅方代码里看到keys时一眼就知道事件来源，不用每次去翻 BDEF。找时间把 ABAP Unit 的测试也补完整，这个方案的可维护性会更上一层。