在我的部落格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代碼發起的資料庫讀請求：
s k i p 和 skip和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傳回：
多餘的記錄，即那些不在s k i p 和 skip和skip和top定義的參數之内的都被DELETE丢棄：
該實作或許不如S/4HANA采用OFFSET方式實作得直接，但是因為從資料庫傳回的僅僅是命中opportunity的GUID，是以也不會有太多額外的開銷。