在 SAP Gateway Foundation 的 OData V4 服务里，一个看上去非常普通的请求就足以把数据提供层的实现复杂度暴露出来。SAP 官方文档给出的请求是下面这样。../PersistenceEntities?$orderby=PERSIS_2_PERSIS/ID,PERSIS_2_PERSIS/CURRENCY desc,ID从 OData 客户端的角度看，这段$orderby很自然。客户端希望按照关联对象PERSIS_2_PERSIS的ID排序，再按照它的CURRENCY倒序排列，最后按照当前实体自身的ID排序。问题到了 ABAP 数据提供层就完全不同了。数据库根本不知道什么叫PERSIS_2_PERSIS/ID。Open SQL 或今天文档里更常使用的 ABAP SQL 看到的是数据库数据源、字段名、Join 和别名。假定当前实体对应数据源别名a，导航目标对应数据源别名b，数据库真正需要的排序表达式可能类似b~ID ASCENDING, a~CURRENCY DESCENDING, a~ID ASCENDING。OData 世界里的 property path 和 ABAP SQL 世界里的 column expression 之间，需要一层可靠的翻译机制。/IWBEP/CL_V4_ORDERBY_BUILDER SAP Gateway OData V4 排序机制拆解，深入理解 /IWBEP/CL_V4_ORDERBY_BUILDER 与 Open SQL ORDER BY
在 SAP Gateway Foundation 的 OData V4 服务里，一个看上去非常普通的请求就足以把数据提供层的实现复杂度暴露出来。SAP 官方文档给出的请求是下面这样。../PersistenceEntities?$orderby=PERSIS_2_PERSIS/ID,PERSIS_2_PERSIS/CURRENCY desc,ID从 OData 客户端的角度看，这段$orderby很自然。客户端希望按照关联对象PERSIS_2_PERSIS的ID排序，再按照它的CURRENCY倒序排列，最后按照当前实体自身的ID排序。问题到了 ABAP 数据提供层就完全不同了。数据库根本不知道什么叫PERSIS_2_PERSIS/ID。Open SQL 或今天文档里更常使用的 ABAP SQL 看到的是数据库数据源、字段名、Join 和别名。假定当前实体对应数据源别名a，导航目标对应数据源别名b，数据库真正需要的排序表达式可能类似b~ID ASCENDING, a~CURRENCY DESCENDING, a~ID ASCENDING。OData 世界里的 property path 和 ABAP SQL 世界里的 column expression 之间，需要一层可靠的翻译机制。/IWBEP/CL_V4_ORDERBY_BUILDER