在 SAP Gateway Foundation 里开发一个 OData V4 服务时，最容易产生误解的地方，往往不是 Entity Type 怎么定义，也不是READ_ENTITY_LIST怎么实现，而是代码已经写完、类也已经激活之后，这个服务究竟怎样真正进入 SAP Gateway 的运行时体系。不少 ABAP 开发人员第一次接触 OData V4 时，会沿用 OData V2 的经验，脑子里自然形成一种很直接的映射关系，开发一个 Service，注册一个 Service，激活之后通过 URL 调用。但到了 SAP Gateway Foundation 的 OData V4 Runtime，这套思路需要稍微调整一下。对于手工开发，也就是 SAP 官方文档中所说的 Hand-crafted OData V4 Service，真正参与注册的不只是一个 Service ID。SAP Gateway 还需要知道这个服务对应哪个 Model Provider Class，也就是 MPC，以及哪个 Data Provider Class，也就是 DPC。更关键的是，Service 注册完成以后还不够，它还必须成为某个 Service Group 的成员，而客户端真正访问服务时，也是在 Service Group 的上下文中访问。SAP 官方对这一过程的描述非常清楚，OData V4 Provider Application 要经历模型定义、业务数据访问实现、Service 注册、Service Group 分配以及 Service Group 发布几个阶段。单独完成 Service Registration 并不会自动让服务对外可访问。理解了这一点，/IWBEP/ 从 MPC、DPC 到 Service Group，彻底理解 SAP Gateway Foundation OData V4 服务注册机制
在 SAP Gateway Foundation 里开发一个 OData V4 服务时，最容易产生误解的地方，往往不是 Entity Type 怎么定义，也不是READ_ENTITY_LIST怎么实现，而是代码已经写完、类也已经激活之后，这个服务究竟怎样真正进入 SAP Gateway 的运行时体系。不少 ABAP 开发人员第一次接触 OData V4 时，会沿用 OData V2 的经验，脑子里自然形成一种很直接的映射关系，开发一个 Service，注册一个 Service，激活之后通过 URL 调用。但到了 SAP Gateway Foundation 的 OData V4 Runtime，这套思路需要稍微调整一下。对于手工开发，也就是 SAP 官方文档中所说的 Hand-crafted OData V4 Service，真正参与注册的不只是一个 Service ID。SAP Gateway 还需要知道这个服务对应哪个 Model Provider Class，也就是 MPC，以及哪个 Data Provider Class，也就是 DPC。更关键的是，Service 注册完成以后还不够，它还必须成为某个 Service Group 的成员，而客户端真正访问服务时，也是在 Service Group 的上下文中访问。SAP 官方对这一过程的描述非常清楚，OData V4 Provider Application 要经历模型定义、业务数据访问实现、Service 注册、Service Group 分配以及 Service Group 发布几个阶段。单独完成 Service Registration 并不会自动让服务对外可访问。理解了这一点，/IWBEP/ RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
