在经典的 SAP Gateway 项目里，我们更熟悉的一种交互方式，是 Consumer 主动向 SAP 发起 OData 请求。页面需要销售订单，就调用 Sales Order EntitySet，需要刷新库存，就再次执行 GET。整个通信过程的主动权一直在 Consumer 一侧。Push Oriented Scenario 走的是另一条路。当 SAP Backend 中的业务数据发生变化后，后端应用可以主动产生 Notification，SAP Gateway 根据已经建立的 Subscription 找到目标 Consumer，再把通知发送到对应的 Notification Endpoint。Consumer 不需要持续轮询 SAP Backend，也不需要每隔几秒重新读取同一批数据。SAP Gateway Foundation 为这种模式准备了一套完整的基础设施，包括 Subscription Metadata、Subscription Registry、Notification Publisher、bgRFC、System Alias 以及 Gateway 到 Consumer 的 HTTP 通信能力。SAP 官方文档给出的核心后端类包括/IWBEP/CL_MGW_PUSH_ABS_MODEL、/IWBEP/CL_MGW_PUSH_ABS_DATA、/IWBEP/CL_MGW_SUB_REGISTRY和/IWBEP/CL_MGW_NOTIF_PUBLISHER。如果把整个过程压缩成一条链路，我们可以理解成这样。SAP Backend 里的业务对象发生变化，应用 SAP Gateway Push 场景实战，打通 Backend 到 Consumer 的订阅与通知链路
在经典的 SAP Gateway 项目里，我们更熟悉的一种交互方式，是 Consumer 主动向 SAP 发起 OData 请求。页面需要销售订单，就调用 Sales Order EntitySet，需要刷新库存，就再次执行 GET。整个通信过程的主动权一直在 Consumer 一侧。Push Oriented Scenario 走的是另一条路。当 SAP Backend 中的业务数据发生变化后，后端应用可以主动产生 Notification，SAP Gateway 根据已经建立的 Subscription 找到目标 Consumer，再把通知发送到对应的 Notification Endpoint。Consumer 不需要持续轮询 SAP Backend，也不需要每隔几秒重新读取同一批数据。SAP Gateway Foundation 为这种模式准备了一套完整的基础设施，包括 Subscription Metadata、Subscription Registry、Notification Publisher、bgRFC、System Alias 以及 Gateway 到 Consumer 的 HTTP 通信能力。SAP 官方文档给出的核心后端类包括/IWBEP/CL_MGW_PUSH_ABS_MODEL、/IWBEP/CL_MGW_PUSH_ABS_DATA、/IWBEP/CL_MGW_SUB_REGISTRY和/IWBEP/CL_MGW_NOTIF_PUBLISHER。如果把整个过程压缩成一条链路，我们可以理解成这样。SAP Backend 里的业务对象发生变化，应用