在企业系统里，有一类需求看起来很简单，却很容易被传统的请求响应式接口做得又慢又重。销售订单 123 被修改了，移动端希望马上收到提醒。某个客户 456 的地址发生变化，负责该客户的业务人员希望看到通知。一张金额为 1500 美元的差旅申请进入审批流程，审批人希望系统主动推送消息。设备检修系统刚刚把一张新的轨道检查任务分配到工作中心，现场人员也希望尽快知道。如果每个客户端都不断调用 OData Service，反复查询有没有新数据，这当然可以工作，但代价也很明显。大量请求实际上什么变化都查不到，Gateway、应用服务器和数据库却仍然需要处理这些请求。客户端还必须自己维护轮询周期、增量判断、网络异常和状态同步。SAP Gateway Foundation 在传统 OData Channel 架构中提供了一套更有针对性的机制，Subscription and Notification Flow。消费者可以声明自己关心哪个业务对象集合、关注哪些数据、采用什么方式接收通知，SAP Gateway 负责管理订阅，后端业务系统负责发现业务对象变化，再把变化通过 Gateway 送达消费者。SAP 官方文档把它分为 Push Oriented Scenario、Pull Oriented Scenario，以及由管理员代表用户创建订阅的 Subscription Management。这里有一个很关键的概念，Feed。SAP Gateway 语境里的 Feed 并不是 RSS，也不是简单的一张消息表。Feed 是面向某个最终用户的一组 Notification 集合，而这些 Notification 又来自该用户对不同业务对象集合建立的 Subscription。SAP 官方给出的定义正是如此 深入理解 SAP Gateway Feed 订阅与通知机制，从 OData Subscription 到 Push 与 Pull 集成
在企业系统里，有一类需求看起来很简单，却很容易被传统的请求响应式接口做得又慢又重。销售订单 123 被修改了，移动端希望马上收到提醒。某个客户 456 的地址发生变化，负责该客户的业务人员希望看到通知。一张金额为 1500 美元的差旅申请进入审批流程，审批人希望系统主动推送消息。设备检修系统刚刚把一张新的轨道检查任务分配到工作中心，现场人员也希望尽快知道。如果每个客户端都不断调用 OData Service，反复查询有没有新数据，这当然可以工作，但代价也很明显。大量请求实际上什么变化都查不到，Gateway、应用服务器和数据库却仍然需要处理这些请求。客户端还必须自己维护轮询周期、增量判断、网络异常和状态同步。SAP Gateway Foundation 在传统 OData Channel 架构中提供了一套更有针对性的机制，Subscription and Notification Flow。消费者可以声明自己关心哪个业务对象集合、关注哪些数据、采用什么方式接收通知，SAP Gateway 负责管理订阅，后端业务系统负责发现业务对象变化，再把变化通过 Gateway 送达消费者。SAP 官方文档把它分为 Push Oriented Scenario、Pull Oriented Scenario，以及由管理员代表用户创建订阅的 Subscription Management。这里有一个很关键的概念，Feed。SAP Gateway 语境里的 Feed 并不是 RSS，也不是简单的一张消息表。Feed 是面向某个最终用户的一组 Notification 集合，而这些 Notification 又来自该用户对不同业务对象集合建立的 Subscription。SAP 官方给出的定义正是如此