在我的博客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，因而也不会有太多分外的开支。
