摘要:是一項服務器端渲染的技術,意味著所有頁面對應的源代碼都是在服務器里渲染的,然后直接在瀏覽器顯示。在搜索這個場景里,任意時間段里,后臺只會生成默認條搜索結果的源代碼。當了我點了第二頁的超鏈接時,第條到第條的源代碼相應在后臺生成。
這篇文章的英文版我發在了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_WRAPPERCLASS=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
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/93866.html
摘要:是一項服務器端渲染的技術,意味著所有頁面對應的源代碼都是在服務器里渲染的,然后直接在瀏覽器顯示。在搜索這個場景里,任意時間段里,后臺只會生成默認條搜索結果的源代碼。當了我點了第二頁的超鏈接時,第條到第條的源代碼相應在后臺生成。 這篇文章的英文版我發在了SAP Community上:Paging Implementation in S/4HANA for Customer Managem...
摘要:是一項服務器端渲染的技術,意味著所有頁面對應的源代碼都是在服務器里渲染的,然后直接在瀏覽器顯示。在搜索這個場景里,任意時間段里,后臺只會生成默認條搜索結果的源代碼。當了我點了第二頁的超鏈接時,第條到第條的源代碼相應在后臺生成。 這篇文章的英文版我發在了SAP Community上:Paging Implementation in S/4HANA for Customer Managem...
摘要:在我的博客我介紹了里采用技術實現的上的搜索分頁實現。應用的搜索分頁實現點擊搜索按鈕之后,默認返回前個命中的,同時顯示總共命中的數目。實際的讀取分頁在后臺的實現通過關鍵字實現。應用的搜索分頁實現前臺的邏輯和的應用完全一致。 在我的博客Paging Implementation in S/4HANA for Customer Management 我介紹了S/4HANA for Custo...
摘要:在我的博客我介紹了里采用技術實現的上的搜索分頁實現。應用的搜索分頁實現點擊搜索按鈕之后,默認返回前個命中的,同時顯示總共命中的數目。實際的讀取分頁在后臺的實現通過關鍵字實現。應用的搜索分頁實現前臺的邏輯和的應用完全一致。 在我的博客Paging Implementation in S/4HANA for Customer Management 我介紹了S/4HANA for Custo...
閱讀 1378·2021-09-26 09:55
閱讀 1917·2019-08-30 12:45
閱讀 1055·2019-08-29 11:20
閱讀 3555·2019-08-26 11:33
閱讀 3412·2019-08-26 10:55
閱讀 1685·2019-08-23 17:54
閱讀 2382·2019-08-23 15:55
閱讀 2341·2019-08-23 14:23