S/4HANA for Customer Management裏的搜索分頁處理
這篇文章的英文版我發在了SAP Community上：Paging Implementation in S/4HANA for Customer Management
https://blogs.sap.com/2018/03/28/paging-implementation-in-s4hana-for-customer-management/
按照我的公眾號文章裏介紹的，S/4HANA for Customer Management 1.0裏的Service Request UI仍然是采用CRM Webclient UI技術來開發的。
假設我在UI上指定max hit值為200：
每頁默認顯示20條數據，因此這200條搜索結果總共分10頁顯示。
關於CRM WebClient UI的分頁機制，有兩個要點：
1. 搜索按鈕點擊後，會有max hit的值指定條數的記錄從數據庫取出，存儲於WebClient UI的應用的內存區域中。在我的例子裏，我指定的max hit為200，因此有200條Service Request從數據庫裏取出。
2. WebClient UI是一項服務器端渲染的技術，意味著所有WebClient UI頁面對應的html源代碼都是在ABAP服務器裏渲染的，然後直接在瀏覽器顯示。在搜索這個場景裏，任意時間段裏，ABAP後臺只會生成默認20條搜索結果的html源代碼。
例如我點了搜索按鈕之後，只有第1條道第20條記錄的html源代碼在後臺生成，然後返回給瀏覽器由其渲染。當了我點了第二頁的超鏈接"2"時，第21條到第40條的源代碼相應在後臺生成。
下面是一些技術細節。
1. 可以使用事務碼ST05找到S4CRM的Service Request搜索查詢的CDS view的名稱CRMS4_SERVHSRCH
第201條記錄被丟棄：
在視圖ICCMP_INBOX/INBOXRESULTVIEW.HTM裏設置斷點, 在調試器裏檢查變量"me"：
通過這個路徑能找到存儲在內存中的200條搜索結果：
{O:5768*\CLASS-POOL=CL_BSP_WD_COLLECTION_WRAPPER\CLASS=LCL_COLLECTION_REF}-IF_BSP_WD_COLLECTION_REF~COLLECTION
2. 當我點第二頁的超鏈接後：
後臺生成好的針對從第21行到第40行記錄的html源代碼可以在Chrome開發者工具中觀察到，如下圖所示：
那麽後臺如何得知應該從第21行開始準備其html源代碼呢？這個索引信息是從前臺傳到後臺的，通過http請求頭部的字段：ItemTree_visibleFirstRow.
如果您搞不清楚類似下圖這種前綴C36_W138_V139_的生成邏輯，請參考我的博客 WebClient UI element ID generation logic
在方法CL_THTMLB_CELLERATOR~GET_REQUEST_PARAMETERS設置斷點，找到後臺是在何處解析該前臺請求傳入的visibleFirstRow:
在BSP渲染類CL_THTMLB_CELLERATOR裏，這個變量gv_visible_first_row被用於渲染的起始索引：lv_current_row_index:
每一行的每一個單元的源代碼在循環裏依次生成好。循環基於表的列定義，當前我系統裏默認的配置，搜索結果有8列：
出於調試目的，您可以在變量GT_TABLE_ENTRIES裏查看生成好的用於當前頁面顯示的html源代碼:
比如對於第二頁，索引從21開始：
以40結束：
為什麽變量gt_table_entries有168條記錄？
每頁默認顯示20條記錄，加上1行表頭，每條記錄8列，所以最後是( 20 + 1 ) * 8 = 168
要獲取更多Jerry的原創技術文章，請關註公眾號"汪子熙"或者掃描下面二維碼:
S/4HANA for Customer Management裏的搜索分頁處理