在我的博客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請求的參數KaTeX parse error: Expected 'EOF', got '&' at position 7: skip=0&?top=25實現的。而總共命中…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的原創技術文章，請關注公眾號"汪子熙":

總結

以上是生活随笔為你收集整理的S/4HANA和CRM Fiori应用的搜索分页实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。