在 SAP Gateway 项目里，很多人第一次接触 Subscription Management 时，很容易把它理解成普通的消息订阅功能。业务用户关注某个对象，对象发生变化，系统发一条通知，看起来似乎就这么简单。真正进入 SAP Gateway Foundation 的实现层之后会发现，这套机制解决的问题要复杂得多。它不仅要知道订阅了什么业务集合，还要知道订阅是为谁建立的、通知应该投递到哪里、管理员有没有资格代替别人建立订阅、一个业务角色究竟对应哪些实际用户，以及同一个 OData 服务分布在多个 SAP Backend System 时，订阅应该落到哪几个后端系统。因此，Subscription Management 更接近一套位于 SAP Gateway Hub 上的订阅控制平面。管理员负责管理订阅关系，SAP Backend System 负责感知业务数据变化，SAP Gateway Hub 负责接收变化事件并根据已经保存的订阅信息寻找接收方，最终通过 HTTP POST 把通知送往订阅记录中的 Delivery Address。管理员可以代表某个用户，也可以代表某个 Role 建立订阅，但真正收到通知的是订阅所代表的用户，而不是执行管理操作的管理员本人。SAP 官方对这一行为有明确说明。这里还有一个很关键的版本边界。SAP 文档明确说明，这项服务创建订阅的能力处于所谓new OData library 1.0的上下文中。这个说法来自 SAP Gateway 较早期的 OData Push 架构，因此在今天阅读这些资料时，不能把这里的 Subscription Management 与当前 SAP Gateway Notification Channel 完
SAP Gateway 集成场景里的订阅管理，管理员如何统一管理用户与角色的 OData 通知
在 SAP Gateway 项目里，很多人第一次接触 Subscription Management 时，很容易把它理解成普通的消息订阅功能。业务用户关注某个对象，对象发生变化，系统发一条通知，看起来似乎就这么简单。真正进入 SAP Gateway Foundation 的实现层之后会发现，这套机制解决的问题要复杂得多。它不仅要知道订阅了什么业务集合，还要知道订阅是为谁建立的、通知应该投递到哪里、管理员有没有资格代替别人建立订阅、一个业务角色究竟对应哪些实际用户，以及同一个 OData 服务分布在多个 SAP Backend System 时，订阅应该落到哪几个后端系统。因此，Subscription Management 更接近一套位于 SAP Gateway Hub 上的订阅控制平面。管理员负责管理订阅关系，SAP Backend System 负责感知业务数据变化，SAP Gateway Hub 负责接收变化事件并根据已经保存的订阅信息寻找接收方，最终通过 HTTP POST 把通知送往订阅记录中的 Delivery Address。管理员可以代表某个用户，也可以代表某个 Role 建立订阅，但真正收到通知的是订阅所代表的用户，而不是执行管理操作的管理员本人。SAP 官方对这一行为有明确说明。这里还有一个很关键的版本边界。SAP 文档明确说明，这项服务创建订阅的能力处于所谓new OData library 1.0的上下文中。这个说法来自 SAP Gateway 较早期的 OData Push 架构，因此在今天阅读这些资料时，不能把这里的 Subscription Management 与当前 SAP Gateway Notification Channel 完