SAP Gateway Pull Oriented 集成场景深度解析，从订阅模型到后端通知链路

在 SAP Gateway 的很多集成项目里，我们很容易把 OData 理解成一套典型的 Request Response 接口。前端或者外围系统发起一个 HTTP 请求，SAP 后端执行查询、创建、修改或者删除，再把结果返回给调用方。这套模型很适合查询销售订单、创建采购申请、读取 Business Partner，也正是大多数 SAP Fiori 和外围系统集成场景最熟悉的模式。可一旦业务需求变成了「SAP 后端的数据发生变化以后，外围消费者希望感知这些变化」，问题就不再只是普通的 OData CRUD。SAP Gateway Foundation 为此提供了一套 Subscription 和 Notification 机制。消费者可以针对某个业务对象集合建立订阅，SAP 后端负责识别业务变化并生成 Notification，SAP Gateway 则承担订阅管理、通知传输或者通知持久化等职责。SAP 官方文档把它分成 Push Oriented 和 Pull Oriented 两类运行方式。本文讨论的是 Pull Oriented，也就是通知仍然从 SAP Backend 产生，但消费者可以在需要的时候从 SAP Gateway 拉取已经保存的通知。这一点很重要，因为 Pull Oriented 并不等同于传统意义上不断轮询业务表。如果一个移动应用每隔一分钟调用一次 SalesOrderSet，重新读取成千上万条销售订单，再比较哪些订单发生变化，这属于业务数据轮询。Subscription 和 Notification 的设计思路完全不同。消费者先告诉 SAP Gateway 我关注哪一个 Collection、什么样的 Filter、什么类型的变化，后端只针对这些订阅产生通知。消费者读取的是