做 SAP Gateway 集成时，我们很容易形成一种固定印象，前端或者外围系统发起一个 OData 请求，SAP Gateway 接住请求，调用后端业务逻辑，再把业务数据返回给消费端。整个过程由 Consumer 主动发起，SAP 系统处在响应请求的位置。
这种模式非常适合查询客户、读取销售订单、创建采购申请、更新业务伙伴之类的常规业务场景。不过一旦业务需求变成了「SAP 后端发生变化时，外部系统需要尽快知道」，单纯依靠传统的 OData Request Response 模式就开始显得笨重。
假设移动端关心销售订单状态，如果移动端每隔 10 秒调用一次 OData Service 查询订单是否已经审批完成，大部分请求最终得到的结果都是「没有变化」。请求仍然需要经过网络、SAP Gateway、OData Runtime、Authorization Check、Backend Provider 和数据库。系统承担了大量没有实际业务价值的调用。
SAP Gateway 为此提供了 Subscription and Notification Flow，也就是订阅与通知流。
它给传统 OData Channel 补上了另外一条数据流。Consumer 不再只负责不断询问 SAP 后端有没有变化，而是可以提前登记自己关心的数据范围。SAP Backend 检测到相关业务对象发生变化后，再通过 SAP Gateway 产生 Notification。
SAP 官方文档把这套能力明确划分为 Push Oriented Scenario、Pull Oriented Scenario，以及由管理员代表用户创建订阅的 Subscription Management。
理解这套机制的关键并不
