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去研究?这就得从他和基友老金的故事说起。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180616G0MG0800?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券