在我的博客Paging Implementation in S/4HANA for Customer Management 我介绍了 S/4HANA for Customer Management 里采用 WebClient UI 技术实现的 UI 上的搜索分页实现。

那么 S/4HANA 和 CRM 里原生的 Fiori 应用，其搜索分页又是如何实现的？

这篇博客分别选取 S/4HANA 里的 Product Master，以及 CRM 里的 My Opportunities 这两个应用为例来介绍。

S/4HANA Fiori 应用的搜索分页实现

点击搜索按钮之后，默认返回前 25 个命中的 product，同时显示总共命中的 product 数目：140。

这个分页效果通过 OData 请求的参数skip=0&top=25实现的。而总共命中条数140的显示通过另一个参数inlinecount 来实现，该参数的后台实现原理类似 ABAP Open SQL 里的 SELECT COUNT(*)。

从 Chrome 开发者工具里观察该请求的回应，确实只有 25 条记录返回。

将该搜索结果列表 scroll 至底部，发现有另一个 OData request 自动发出：

该请求的头部参数为 $skip=25&top=25，因此能够从后台只取从第 26 到 50 个 product：

在我博客SAP Fiori里的List是如何做到懒加载Lazy load的 我解释了 $skip 递增的序列值 0,25,50,75...是如何在前台生成的。

而在这篇博客里，我会着重介绍分页搜索的后台实现。

假设我重复将搜索结果 scroll 至底部的动作重复三次，那么能够通过 ST05 观察到有三个数据库的读请求，每个请求返回 25 条记录。

点击该按钮，可以查看到具体是哪一行 ABAP 代码发起的数据库读请求：

$skip和$top 这两个参数的值从前台传入后台，在后台的方法 CL_SADL_GW_GENERIC_DPC~_GET_ENTITYSET 的输入参数 io_query_option 能观察到:

开始行的索引值等于 $skip 参数值加 1。

实际的读取分页在后台的实现：通过 ABAP 关键字 OFFSET 实现。

该 OFFSET 的值通过方法 CL_SADL_SQL_STATEMENT~GET_SECTIONS_FOR_SELECT 内一个较复杂的 table 表达式来决定出来：

首先得出表达式 lt_sections[ type = cl_sadl_sql_statement=>co_type-page ]-from 的值：99.

再从内表 mt_parts 取出第 99 条记录，从其字段 value2 得出最终 offset 值 75。

CRM Fiori 应用的搜索分页实现

前台的逻辑和 S/4HANA 的 Fiori 应用完全一致。

该参数传至后台，存储在参数 is_paging 里:

至于后台的分页搜索，My opportunities 应用并未使用 ABAP OPEN SQL 里的关键字 OFFSET。相反地，所有匹配记录的 GUID 都通过 One Order 的搜索 API 返回：

多余的记录，即那些不在$skip和$top 定义的参数之内的都被 DELETE 丢弃：

该实现或许不如 S/4HANA 采用 OFFSET 方式实现得直接，但是因为从数据库返回的仅仅是命中 opportunity 的 GUID，因此也不会有太多额外的开销。要获取更多 Jerry 的原创技术文章，请关注公众号"汪子熙":