在一个运行多年的 SAP 系统里，真正麻烦的往往不是如何创建一个新的 OData Service，而是如何把已经存在于不同技术栈、不同系统甚至不同厂商平台里的服务重新组织起来。一边可能是 SAP Business Suite 中已有的 SPI 或 GenIL 业务模型，一边可能是 SAP BW 的分析数据，还有一些数据直接来自 SAP HANA。更复杂的情况下，业务数据甚至已经被其他系统封装成一个标准 OData Service。此时如果 SAP Fiori、移动应用或者其他企业应用都分别连接这些数据源，前端很快就会面对不同认证方式、不同 URL、不同 Metadata、不同协议细节以及不同生命周期管理方式。SAP Gateway 早期针对这一类问题提供了一套很有意思的能力，也就是 OData Services Consumption and Integration，简称 OSCI。OSCI 的思路并不是继续在 SAP Gateway 中重新实现一遍远程系统的业务逻辑，而是让 SAP Gateway 自己成为一个 OData Consumer。它读取外部 OData Service 的 Metadata，在 SAP Gateway Service Builder 中重新生成一个符合 SAP Gateway 模型和运行时规范的 OData Service，再把这个服务暴露给上层消费者。于是整个调用链可以理解为下面这种结构。SAP Fiori / Browser / Mobile App | v SAP Gateway OData S