- SAP Managed Tags:
- Search Paging implementation in S/4HANA Fiori application
- Search Paging implementation in CRM Fiori application
- Search Paging implementation in S/4HANA for Customer Management
In my blog https://blogs.sap.com/2018/03/28/paging-implementation-in-s4hana-for-customer-management/ I introduce the search paging implementation in S/4HANA for Customer Management built by CRM WebClient UI technology.
How about the search paging implemented in S/4HANA native Fiori application?
In this blog, I use Product Master Fiori application in S/4HANA and My Opportunity application in CRM for example.
Search paging implementation in S/4HANA Fiori application
Once search button is pressed, by default the first 25 materials among totally found 140 are displayed in search result.
This is due to the OData request sent with option $skip=0&top=25, so only 25 records are fetched from backend. $inlinecount works like SELECT COUNT(*) in ABAP Open SQL to return the total number of matched records.
We can check from Chrome development tool that there are indeed only 25 records returned for the http request displayed in above screenshot.
When you scroll down the search result view to the bottom,
another http request is sent automatically with option $skip=25&top=25 to retrieve the records starting from index 26 to 50.
In my blog How does UI5 AutoGrowing list work I have explained how this incremental $skip option value 0,25,50,75... is determined in frontend side.
In this blog, I will continue with paging implementation done in ABAP backend.
I repeat to scroll search result list to bottom for three times, and observed product underlying CDS view are selected for three times with 25 hit each time as expected.
Simply click this button to find the ABAP source code where OPEN SQL is performed:
the value of $skip and $top passed from frontend is maintained in importing parameter io_query_option of method CL_SADL_GW_GENERIC_DPC~GET_ENTITYSET:
The starting row index = skip option value + 1.
The actual paging fetch is simply achieved by ABAP keyword OFFSET:
This offset is determined by a very complex table expression in CL_SADL_SQL_STATEMENT~GET_SECTIONS_FOR_SELECT:
First get the value of expression lt_sections[ type = cl_sadl_sql_statement=>co_type-page ]-from as 99.
Then inspect the 99th row of mt_parts and get the final value 75 from field value2.
Search paging implementation in CRM Fiori application
The frontend logic is exactly the same as in S/4HANA: by default the first 20 opportunities are displayed, and I scroll the list to trigger the load of 21st opportunity:
This parameter is passed into is_paging in the backend:
My opportunities Fiori application in CRM does NOT use OFFSET keyword in OPEN SQL. Instead guid of ALL matched opportunities are fetched from One Order database table:
and then the superfluous records which are out of range specified by $skip and $top are discarded:
This implementation might not be so straightforward as the OFFSET solution in S/4HANA, but still without too much overhead since internal table lt_opportunity_ext contains simply opportunity guid.
Further reading
You can also compare this implementation with the one in S/4HANA for Customer Management:
