SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

Search Paging implementation in S/4HANA and CRM Fiori application

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.

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

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.

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

We can check from Chrome development tool that there are indeed only 25 records returned for the http request displayed in above screenshot.

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

When you scroll down the search result view to the bottom,

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

another http request is sent automatically with option $skip=25&top=25 to retrieve the records starting from index 26 to 50.

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

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.

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

Simply click this button to find the ABAP source code where OPEN SQL is performed:

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

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:

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

The starting row index = skip option value + 1.

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

The actual paging fetch is simply achieved by ABAP keyword OFFSET:

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

This offset is determined by a very complex table expression in CL_SADL_SQL_STATEMENT~GET_SECTIONS_FOR_SELECT:

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

First get the value of expression lt_sections[ type = cl_sadl_sql_statement=>co_type-page ]-from as 99.

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

Then inspect the 99th row of mt_parts and get the final value 75 from field value2.

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

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:

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

This parameter is passed into is_paging in the backend:

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

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:

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

and then the superfluous records which are out of range specified by $skip and $top are discarded:

SAPUI5, JavaScript, SAP Fiori, SAP Fiori for SAP CRM, SAP Fiori for SAP S/4HANA, SAP S/4HANA

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.

Leave a Reply

Your email address will not be published.