高质量 SAP OData 服务怎么做，从 Metadata 到 Runtime 的工程化设计准则

一个 SAP Fiori List Report 页面打开后，如果出现列标题晦涩、筛选字段混乱、金额没有币种、日期无法解析、错误弹窗只有一串后台技术文本，问题往往并不在 SAPUI5 页面本身，而是更早就埋进了 OData 服务。

这种服务从 ABAP 开发者的角度看，很可能完全正常。$metadata 能返回，GET 请求得到 HTTP 200，DPC_EXT 里的代码也执行成功，数据库查询同样没有 Dump。但站在消费方的角度，它依然可能是一套质量很差的 API。

SAP 对高质量 OData 服务的定义恰恰是从消费端观察服务，而不是只检查后台代码是否能够运行。SAP Gateway 的经典设计指南把问题拆成三个区域，Metadata 是否表达清楚业务语义，Runtime 是否按照协议和业务规则稳定返回数据，以及 OData Channel 本身是否采用了合理的数据绑定和实现方式。

这套思想放到今天依然很有价值。经典 SEGW 服务主要对应 code-based OData Channel，而现在的 ABAP Cloud 和 RAP 已经可以通过 Service Definition 与 Service Binding 暴露 OData V4 服务。实现技术发生了变化，但 API 的名字是不是业务化、类型是不是准确、错误信息是不是能被消费端理解、读取操作有没有副作用、数据模型是不是过度暴露，这些问题没有因为 RAP 出现而消失。SAP 当前的 RAP 文档也明确支持通过 Service Binding 暴露 OData V4 服务。