一个外部系统订阅了 SAP Gateway 暴露的某个业务对象集合，后台数据发生变化之后，业务系统已经成功生成 Notification，SAP Gateway 也已经拿到了这条 Notification。到了这里，一个非常现实的问题马上出现，消息究竟由谁送到外部系统，又该按照什么地址发送，认证方式由谁处理，JSON 或 ATOM XML 格式的数据放在哪里，如果标准发送机制无法满足 OAuth 等安全要求，我们还能不能把这段发送逻辑替换掉。这正是 SAP Gateway 的 Notification Content Publisher 要解决的问题。SAP 官方文档把这项能力放在经典 SAP Gateway 的 Subscription and Notification Flow 体系中。SAP Gateway 除了常见的 OData 请求响应模式，本身还提供 Subscription 和 Notification Flow，并同时覆盖 Push Oriented Scenario 与 Pull Oriented Scenario。订阅并不是针对一个抽象事件名称建立，而是针对 Business Object Collection 建立，还可以结合 Filter 限定数据范围。SAP 文档里给过一个非常直观的业务例子，某个使用者订阅所有属于 California 的 Customer。当新的 California Customer 被创建，或者已有 Customer 发生变化时，系统就可以产生 Notification。订阅范围也可以缩小到单独一个业务对象实例，此时 Filter 中只需要包含对应对象的 ID。这种机制和普通 OData 查询最大的区别，是业务消费者不需要持续轮询。