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