S/4HANA和CRM Fiori應用的搜索分頁實現

在個人博客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，所以也不會有太多額外的開銷。 要獲取更多Jerry的原創技術文章，請關注公衆號"汪子熙"或者掃描下面二維碼: