在 SAP Gateway 的集成场景里，有一类配置很容易被忽略。OData 服务明明已经激活，$metadata也能够正常访问，普通的查询和更新操作看上去都没有问题，但一旦系统进入订阅通知、多个后端系统或者基于请求内容进行路由的场景，仅仅把服务注册到 SAP Gateway Hub 上就不够了。Gateway 还必须知道，一个已经注册的数据模型，在真正执行请求时究竟应该交给哪个 Data Provider。SUBSCRIPTIONMANAGEMENT就属于这种情况。SAP 官方文档对这个服务的定位相当明确。管理员可以代表某个用户或者角色建立订阅，当被订阅的集合发生变化时，通知从 SAP 后端系统推送到 SAP NetWeaver Gateway Hub，Gateway 再按照订阅中保存的 delivery address，通过 HTTP POST 把通知发送给相应订阅者。对于角色订阅，角色还需要通过应用侧实现解析成对应用户。如果只是把这套机制理解成一个普通的 OData CRUD 服务，就很容易漏掉它背后的路由问题。尤其是在经典的 Hub Deployment 中，一个 SAP Gateway 前端服务器可能连接多个 ABAP 后端系统，同一个逻辑上的服务可能对应不同的 system alias。请求来到 Gateway 时，系统不但要知道调用哪个 OData Service，还需要进一步判断请求应该进入哪个后端环境。这正是Assign Data Provider to Data Model这项配置存在的原因。SAP 对这项配置给出了非常严格的版本边界。只有使用原始的SUBSCR
在 SAP Gateway 的集成场景里，有一类配置很容易被忽略。OData 服务明明已经激活，$metadata也能够正常访问，普通的查询和更新操作看上去都没有问题，但一旦系统进入订阅通知、多个后端系统或者基于请求内容进行路由的场景，仅仅把服务注册到 SAP Gateway Hub 上就不够了。Gateway 还必须知道，一个已经注册的数据模型，在真正执行请求时究竟应该交给哪个 Data Provider。SUBSCRIPTIONMANAGEMENT就属于这种情况。SAP 官方文档对这个服务的定位相当明确。管理员可以代表某个用户或者角色建立订阅，当被订阅的集合发生变化时，通知从 SAP 后端系统推送到 SAP NetWeaver Gateway Hub，Gateway 再按照订阅中保存的 delivery address，通过 HTTP POST 把通知发送给相应订阅者。对于角色订阅，角色还需要通过应用侧实现解析成对应用户。如果只是把这套机制理解成一个普通的 OData CRUD 服务，就很容易漏掉它背后的路由问题。尤其是在经典的 Hub Deployment 中，一个 SAP Gateway 前端服务器可能连接多个 ABAP 后端系统，同一个逻辑上的服务可能对应不同的 system alias。请求来到 Gateway 时，系统不但要知道调用哪个 OData Service，还需要进一步判断请求应该进入哪个后端环境。这正是Assign Data Provider to Data Model这项配置存在的原因。SAP 对这项配置给出了非常严格的版本边界。只有使用原始的SUBSCR
