資訊專欄INFORMATION COLUMN
摘要：在我的博客我介紹了里采用技術(shù)實(shí)現(xiàn)的上的搜索分頁實(shí)現(xiàn)。應(yīng)用的搜索分頁實(shí)現(xiàn)點(diǎn)擊搜索按鈕之后，默認(rèn)返回前個命中的，同時顯示總共命中的數(shù)目。實(shí)際的讀取分頁在后臺的實(shí)現(xiàn)通過關(guān)鍵字實(shí)現(xiàn)。應(yīng)用的搜索分頁實(shí)現(xiàn)前臺的邏輯和的應(yīng)用完全一致。
在我的博客Paging Implementation in S/4HANA for Customer Management 我介紹了S/4HANA for Customer Management里采用WebClient UI技術(shù)實(shí)現(xiàn)的UI上的搜索分頁實(shí)現(xiàn)。
那么S/4HANA和CRM里原生的Fiori應(yīng)用，其搜索分頁又是如何實(shí)現(xiàn)的？
這篇博客分別選取S/4HANA里的Product Master，以及CRM里的My Opportunities這兩個應(yīng)用為例來介紹。
S/4HANA Fiori應(yīng)用的搜索分頁實(shí)現(xiàn)點(diǎn)擊搜索按鈕之后，默認(rèn)返回前25個命中的product，同時顯示總共命中的product數(shù)目：140。
這個分頁效果通過OData請求的參數(shù)$skip=0&top=25實(shí)現(xiàn)的。而總共命中條數(shù)140的顯示通過另一個參數(shù)$inlinecount來實(shí)現(xiàn)，該參數(shù)的后臺實(shí)現(xiàn)原理類似ABAP Open SQL里的SELECT COUNT(*)。
從Chrome開發(fā)者工具里觀察該請求的回應(yīng)，確實(shí)只有25條記錄返回。
將該搜索結(jié)果列表scroll至底部，發(fā)現(xiàn)有另一個OData request自動發(fā)出：
該請求的頭部參數(shù)為$skip=25&top=25，因此能夠從后臺只取從第26到50個product：
在我博客SAP Fiori里的List是如何做到懶加載Lazy load的 我解釋了$skip遞增的序列值0,25,50,75...是如何在前臺生成的。
而在這篇博客里，我會著重介紹分頁搜索的后臺實(shí)現(xiàn)。
假設(shè)我重復(fù)將搜索結(jié)果scroll至底部的動作重復(fù)三次，那么能夠通過ST05觀察到有三個數(shù)據(jù)庫的讀請求，每個請求返回25條記錄。
點(diǎn)擊該按鈕，可以查看到具體是哪一行ABAP代碼發(fā)起的數(shù)據(jù)庫讀請求：
$skip和$top這兩個參數(shù)的值從前臺傳入后臺，在后臺的方法CL_SADL_GW_GENERIC_DPC~_GET_ENTITYSET的輸入?yún)?shù)io_query_option能觀察到:
開始行的索引值等于$skip參數(shù)值加1。
實(shí)際的讀取分頁在后臺的實(shí)現(xiàn)：通過ABAP關(guān)鍵字OFFSET實(shí)現(xiàn)。
該OFFSET的值通過方法CL_SADL_SQL_STATEMENT~GET_SECTIONS_FOR_SELECT內(nèi)一個較復(fù)雜的table表達(dá)式來決定出來：
首先得出表達(dá)式lt_sections[ type = cl_sadl_sql_statement=>co_type-page ]-from的值：99.
再從內(nèi)表mt_parts取出第99條記錄，從其字段value2得出最終offset值75。
CRM Fiori應(yīng)用的搜索分頁實(shí)現(xiàn)前臺的邏輯和S/4HANA的Fiori應(yīng)用完全一致。
該參數(shù)傳至后臺，存儲在參數(shù)is_paging里:
至于后臺的分頁搜索，My opportunities應(yīng)用并未使用ABAP OPEN SQL里的關(guān)鍵字OFFSET。相反地，所有匹配記錄的GUID都通過One Order的搜索API返回：
多余的記錄，即那些不在$skip和$top定義的參數(shù)之內(nèi)的都被DELETE丟棄：
該實(shí)現(xiàn)或許不如S/4HANA采用OFFSET方式實(shí)現(xiàn)得直接，但是因?yàn)閺臄?shù)據(jù)庫返回的僅僅是命中opportunity的GUID，因此也不會有太多額外的開銷。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/68897.html
摘要：在我的博客我介紹了里采用技術(shù)實(shí)現(xiàn)的上的搜索分頁實(shí)現(xiàn)。應(yīng)用的搜索分頁實(shí)現(xiàn)點(diǎn)擊搜索按鈕之后，默認(rèn)返回前個命中的，同時顯示總共命中的數(shù)目。實(shí)際的讀取分頁在后臺的實(shí)現(xiàn)通過關(guān)鍵字實(shí)現(xiàn)。應(yīng)用的搜索分頁實(shí)現(xiàn)前臺的邏輯和的應(yīng)用完全一致。 在我的博客Paging Implementation in S/4HANA for Customer Management 我介紹了S/4HANA for Custo...
摘要：在我的博客我介紹了里采用技術(shù)實(shí)現(xiàn)的上的搜索分頁實(shí)現(xiàn)。應(yīng)用的搜索分頁實(shí)現(xiàn)點(diǎn)擊搜索按鈕之后，默認(rèn)返回前個命中的，同時顯示總共命中的數(shù)目。實(shí)際的讀取分頁在后臺的實(shí)現(xiàn)通過關(guān)鍵字實(shí)現(xiàn)。應(yīng)用的搜索分頁實(shí)現(xiàn)前臺的邏輯和的應(yīng)用完全一致。 在我的博客Paging Implementation in S/4HANA for Customer Management 我介紹了S/4HANA for Custo...
摘要：搜索分頁技術(shù)往往和另一個術(shù)語懶加載聯(lián)系起來。該搜索分頁的實(shí)現(xiàn)歸功于請求的參數(shù)，，意為從請求命中的第條記錄開始總共返回條記錄。更多細(xì)節(jié)，請參考我的博客應(yīng)用的搜索分頁實(shí)現(xiàn)原理，全稱為，開發(fā)技術(shù)仍然采用。 搜索分頁技術(shù)往往和另一個術(shù)語Lazy Loading（懶加載）聯(lián)系起來。今天由Jerry首先介紹S/4HANA，CRM Fiori和S4CRM應(yīng)用里的UI搜索分頁的實(shí)現(xiàn)原理。后半部分由SA...
閱讀 2035·2021-11-22 19:20
閱讀 2675·2021-11-22 13:54
閱讀 2039·2021-09-04 16:40
閱讀 1861·2021-08-13 11:54
閱讀 2730·2019-08-30 15:55
閱讀 3493·2019-08-29 13:51
閱讀 553·2019-08-29 11:09
閱讀 3034·2019-08-26 14:06
