我們打開 SAP CRM Fiori 應用 My Opportunity 的 list 頁面,首頁預設隻能顯示 20 個 Opportunity:

當我們向下滾動滑鼠中鍵時,觸發一個加載更多 Opportunity 的動作,或者說延遲加載(分頁加載)機制:
lo_provider = lo_processor->read(
io_entity_set = lo_entity_set
is_function_import_info = ls_function_import_info
it_key = io_uri->key_predicates
it_expand = io_uri->expand
it_select = io_uri->select
io_filter = io_uri->filter
io_orderby = io_uri->orderby
iv_skip = io_uri->skip
iv_top = io_uri->top
iv_skiptoken = io_uri->skiptoken
iv_inlinecount = lv_inlinecount
iv_for = lv_operation
iv_format = lv_format ).
下圖是 gateway 處理 OData 請求的入口:
通過
CALL_BACKEND
方法進行 RFC 調用:
進行 RFC 調用,使用的 SM59 Destination 為
ZGM4TOAG3_001
:
直接用 postman,沒有傳回記錄:
CL_CRM_OPPORTUNITY_DPC_EXT~OPPORTUNITIES_GET_ENTITYSET
成功讀出 470 條 Opportunity:
用 Postman 發送的請求,一 delete 就沒了:
UI 上也是 0,這個 growing behavior 在 GM4/AG3 上不能正常工作。
但 task 可以。
在這之前,在 me->select_tasks 裡完成 guid 的讀取。
把所有 guid 都讀取出來了:
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-P7IfPAjq-1659765006868)(https://upload-images.jianshu.io/upload_images/2085791-85e425bd414c0165.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]
分頁邏輯的實作:
IF lv_maxhits > 0.
DELETE lt_sort FROM lv_maxhits + 1.
ENDIF.
IF iv_skip > 0.
DELETE lt_sort FROM 1 TO iv_skip.
ENDIF.
sap.ui.model.odata.ODataMetaModel
是一個OData 元模型的實作,它提供對OData V2中繼資料和V4注釋的統一通路。它使用現有的
sap.ui.model.odata.ODataMetadata
作為基礎,并将現有的sap.ui.model.odata.ODataAnnotations的 V4 直接合并到相應的模型元素。
此模型不準備被進一步繼承。
此外,來自“http://www.sap.com/Protocols/SAPData”名稱空間的注釋從擴充數組中提取出來,并從對象轉換為名稱字首為
sap:
的簡單屬性。注意,這是另外發生的,是以下面的示例顯示了這兩種表示。這樣,這樣的注釋就可以通過簡單的相對路徑來處理,而不是搜尋數組。
{
"name" : "BusinessPartnerID",
"extensions" : [{
"name" : "label",
"value" : "Bus. Part. ID",
"namespace" : "http://www.sap.com/Protocols/SAPData"
}],
"sap:label" : "Bus. Part. ID"
}