在我的博客PagingImplementationinS/4HANAforCustomerManagement中介绍了在S/4HANAforCustomerManagement中通过WebClientUI技术实现的UI上搜索分页的实现。那么原生Fiori应用在S/4HANA和CRM中的搜索分页是如何实现的呢？本博客选取了S/4HANA中的ProductMaster和CRM中的MyOpportunities这两个应用作为示例。S/4HANAFiori应用的搜索页面实现点击搜索按钮后，默认返回前25条命中商品，显示总命中商品数：140。这种分页效果是通过参数$skip实现的=0&top=25OData请求。总共140个命中的显示是通过另一个参数$inlinecount来实现的。该参数的后台实现原理类似于ABAPOpenSQL中的SELECTCOUNT(*)。观察Chrome开发者工具对请求的响应，确实只返回了25条记录。将搜索结果列表滚动到底部，发现又自动发出了一个OData请求：请求的header参数为$skip=25&top=25，所以只能从后台抓取第26到第50个产品：在我的博客中SAPFiori中的List是如何实现Lazyload的？我解释了如何在前台生成序列值0、25、50、75...递增$skip。在这篇博客中，我将重点介绍分页搜索的后台实现。假设我重复3次将搜索结果滚动到底部的动作，那么通过ST05可以观察到有3次对数据库的读请求，每次请求返回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方法中比较复杂的表表达式决定：首先获取表达式lt_sections[type=cl_sadl_sql_statement=>co_type-page]-from:99的值，然后从innertablemt_parts在第99条记录中，从它的字段value2中得到最终的偏移值75。CRMFiori应用的搜索分页实现的前端逻辑与S/4HANA的Fiori应用一模一样。该参数传给后台，存储在参数is_paging中：对于后台分页搜索，我的机会应用在ABAPOPENSQL中没有使用关键字OFFSET。而是通过OneOrder的搜索API返回所有匹配记录的GUID：冗余记录，那些不在$skip和$top定义的参数范围内的被DELETE丢弃：这个实现可能不如S/4HANA使用OFFSET的实现很简单，但由于从数据库返回的只是命中机会的GUID，因此没有太多额外开销。
