在 SAP S/4HANA 项目里，一个看起来非常普通的 ODataGET请求，有时反而是最容易制造性能问题的地方。我们的接口可能只是读取销售订单、采购订单、Business Partner、物料主数据或者某个 CDS View 暴露出来的 EntitySet。数据量只有几百条时，很难察觉设计上的问题。一旦生产系统运行几年，业务数据累积到几十万甚至几百万条，同样一个集合查询就可能突然变成大响应。ABAP 应用服务器需要构造巨大的结果集，SAP Gateway Runtime 需要完成序列化，ICM 需要传输 HTTP Response，前端还要解析庞大的 JSON。数据库、ABAP 内存、网络带宽和浏览器内存会同时受到压力。OData 为这种问题准备了一套很成熟的机制，Server-Driven Paging，也就是服务端驱动分页。SAP Gateway Foundation 对这套机制提供支持，而$skiptoken正是其中非常关键的一环。SAP 官方文档对这一机制的定义很明确，一个返回集合的 OData 服务可以自行实施 Server-Driven Paging，因此一次响应只返回整个集合的一部分。如果当前响应不是完整结果，必须给出一个能够继续读取下一部分结果的 next link，而最后一页不能再包含 next link。服务可以在生成 next link 时使用保留的系统查询选项$skiptoken。这里最需要建立的认识是，$skiptoken不是简单意义上的页码，也不是$skip的另一个名字。它解决的是另一类问题。设想我们的
在 SAP S/4HANA 项目里，一个看起来非常普通的 ODataGET请求，有时反而是最容易制造性能问题的地方。我们的接口可能只是读取销售订单、采购订单、Business Partner、物料主数据或者某个 CDS View 暴露出来的 EntitySet。数据量只有几百条时，很难察觉设计上的问题。一旦生产系统运行几年，业务数据累积到几十万甚至几百万条，同样一个集合查询就可能突然变成大响应。ABAP 应用服务器需要构造巨大的结果集，SAP Gateway Runtime 需要完成序列化，ICM 需要传输 HTTP Response，前端还要解析庞大的 JSON。数据库、ABAP 内存、网络带宽和浏览器内存会同时受到压力。OData 为这种问题准备了一套很成熟的机制，Server-Driven Paging，也就是服务端驱动分页。SAP Gateway Foundation 对这套机制提供支持，而$skiptoken正是其中非常关键的一环。SAP 官方文档对这一机制的定义很明确，一个返回集合的 OData 服务可以自行实施 Server-Driven Paging，因此一次响应只返回整个集合的一部分。如果当前响应不是完整结果，必须给出一个能够继续读取下一部分结果的 next link，而最后一页不能再包含 next link。服务可以在生成 next link 时使用保留的系统查询选项$skiptoken。这里最需要建立的认识是，$skiptoken不是简单意义上的页码，也不是$skip的另一个名字。它解决的是另一类问题。设想我们的
