在一个典型的 SAP Gateway 项目里，我们经常会看到这样的技术链路，SEGW 中存在 Data Model，运行时生成 MPC 与 DPC 类，服务在/IWFND/MAINT_SERVICE中注册并绑定 System Alias，SAPUI5 或其他客户端最终通过/sap/opu/odata/...访问业务数据。很多开发工作做久了以后，这套步骤已经相当熟悉，但如果进一步追问一个问题，为什么 SAP Gateway 要设计 MPC、DPC、System Alias、Service Registration 这一整套机制，它们在运行时究竟怎样连接起来，答案就会落到一个非常核心的概念上，OData Channel，也就是经常缩写为 ODC 的 SAP Gateway 编程与运行时通道。
SAP Gateway Foundation 本身提供了开发、生成以及运行 OData 服务所需的基础能力，SAP 官方文档至今仍将 SAP Gateway Foundation 描述为面向不同客户端技术提供 OData 服务开发与生成能力的基础组件。对于传统 SAP Gateway 开发来说，理解 OData Channel，实际上是在理解经典 Gateway 服务为什么能够从一个 ABAP 业务模型一路变成 HTTP 世界里的 OData 资源。
从一次真实的 OData 请求开始理解 OData Channel
假设我们的 SAPUI5 应用正在读取销售订单列表，浏览器发出的请求可能类似下面这样。
/sap/o
