SAP UI 搜索分页技术

搜索分页技术往往和另一个术语Lazy Loading（懒加载）联系起来。今天由Jerry首先介绍S/4HANA，CRM Fiori和S4CRM应用里的UI搜索分页的实现原理。后半部分由SAP成都研究院菜园子小哥王聪向您介绍Twitter的懒加载实现。

关于王聪的背景介绍，您可以参考他的前一篇文章：

SAP成都研究院非典型程序猿，菜园子小哥：当我用UI5诊断工具时我用些什么

。

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

以S/4HANA Product Master Fiori应用为例，如果什么搜索条件都不指定，默认会返回25条数据，并且在UI上显示该系统总的product数量，在Jerry使用的系统里总共存在140个product。

该搜索分页的实现归功于OData请求的参数，$skip=0&top=25，意为从请求命中的第0条记录开始, 总共返回25条记录。而另一个参数$inlinecount，其工作原理可以类比ABAP Open SQL的关键字SELECT COUNT(*)，用于统计数据库表的条目数。

一旦用鼠标滚轮向下移动页面至屏幕底部，会自动触发一个新的OData请求，参数为$skip=25&top=25。 这样，从第26到第50个product也从数据库表中读取出来显示在Fiori UI上。

为什么分页的尺寸为25？在Fiori UI列表实现文件sap.m.ListBase.js里，默认的分页尺寸(GrowingThreshold)为20，这说明一定存在某个配置，或者在Product Master应用某处的JavaScript代码将这个分页尺寸从20改成了25。

如果您想通过自己调试找到这个答案，锻炼自己的分析能力，可以参考我的调试过程：

How does UI5 AutoGrowing list(Lazy Load behavior) work

https://blogs.sap.com/2018/03/29/how-does-ui5-autogrowing-list-work/

以及使用Smart Template开发Fiori应用的介绍：

再来看看搜索分页的后台处理。在Netweaver事务码ST05的数据库跟踪视图里，能清晰观察到这个分页效果：每次到数据库的查询只命中并返回25条记录，如下图三条高亮的跟踪记录所示。

从前台通过UI5库文件发送的带有$skip和$top参数的OData请求，被后台接收并维护于io_query_options参数中：

而最终在数据库查询层面的分页处理，是由ABAP Open SQL的关键字OFFSET实现的。

上图第1674行@lv_offset的值，是基于UI传入的$skip和$top计算而得。

CRM Fiori应用搜索分页实现原理

CRM Fiori应用的前台搜索分页实现原理和S/4HANA Fiori应用类似，只是分页尺寸变成了20。

上图的$skip和$top参数同S/4HANA应用的行为相同，传递到后台并得到处理：

CRM Fiori后台的搜索分页处理和S/4HANA Fiori的区别：并未使用ABAP的OFFSET关键字，而由应用开发人员自行实现。

1. 首先将所有满足搜索条件的记录的GUID全部从数据库取出，从数据库层返回到ABAP层。在我这个测试系统里，总共有21条记录，全部返回到了ABAP层：

2. 由应用开发人员根据$skip和$top值，将多余的记录丢弃掉，保证最后只返回20条记录给UI。

至此S/4HANA和CRM Fiori应用的搜索分页原理介绍完毕。更多细节，请参考我的博客：

Search Paging implementation in S/4HANA and CRM Fiori application

https://blogs.sap.com/2018/03/29/search-paging-implementation-in-s4hana-and-crm-fiori-application/

S4CRM应用的搜索分页实现原理

S4CRM，全称为S/4HANA for Customer Management，UI开发技术仍然采用WebClient UI。和S/4HANA基于UI5的前端技术截然不同，WebClient UI走的是服务器端渲染的BSP路线。严格意义上讲，WebClient UI不存在数据库层面的搜索分页，其分页行为仅仅体现在服务器端渲染上。

下图例子里，我指定Max Number of Results为200，意思是期望满足搜索条件的记录里，显示200条到UI上。

从搜索结果能看出分页效果。全部200条记录已经从数据库查询出来并保存到应用程序的内存里。如下图所示：

WebClient UI仅仅将第一页的HTML源代码在ABAP后台渲染出来然后显示给用户。当用户点了屏幕下方的“2”页码时，不会有任何的数据库查询发生，服务器做的事情仅仅是将第二页对应的HTML源代码渲染出来。

服务器怎么知道应该渲染第二页的源代码呢？这个信息也是点了“2”页码后，从前台传给ABAP服务器的：

ABAP后台拿到这个visibleFirstRow参数后，知道从搜索结果记录里的第21条开始渲染，一直到第40条。

更多渲染细节，请参考我的博客：

Paging Implementation in S/4HANA for Customer Management

https://blogs.sap.com/2018/03/28/paging-implementation-in-s4hana-for-customer-management/

了解了咱们SAP的搜索分页实现原理后，让我们再来看看其他厂商是怎么做的。

像国内的知乎，简书，新浪微博这些网站，其列表显示均实现了懒加载。菜园子小哥王聪对这些实现也很好奇。为什么最后选择了Twitter去研究？这就得从他和基友老金的故事说起。