I have posted the English version of this article on SAP Community: Paging Implementation in S/4HANA for Customer Management
Blogs.sap.com/2018/03/28/…
According to the article introduced in my official account, the Service Request UI in S/4HANA for Customer Management 1.0 is still developed by using CRM Webclient UI technology.
Suppose I specify Max hit value 200 on the UI:
By default, each page displays 20 pieces of data, so the 200 search results are divided into 10 pages.
There are two main points about the pagination mechanism of the CRM WebClient UI:
1. After the search button is clicked, records specified by Max hit value will be taken out from the database and stored in the memory area of the application of WebClient UI. In my example, I specified a Max hit of 200, so there are 200 Service Requests fetched from the database.
2. WebClient UI is a server-side rendering technology, which means that the HTML source code corresponding to all WebClient UI pages is rendered in the ABAP server and displayed directly in the browser. In the search scenario, the ABAP background generates only the HTML source code for the default 20 search results at any given time.
For example, after I click the search button, only the HTML source code for track 1 and record 20 is generated in the background and then returned to the browser for rendering. When I clicked the hyperlink “2” on the second page, the source code for items 21 through 40 was generated in the background accordingly.
Here are some technical details.
1. You can use transaction code ST05 to find the CDS view name CRMS4_SERVHSRCH in S4CRM Service Request search
Section 201 Records are discarded:
In the view ICCMP_INBOX/INBOXRESULTVIEW set breakpoints in the HTM, check in the debugger variable “me” :
This is the path to 200 search results stored in memory:
{O:5768*\CLASS-POOL=CL_BSP_WD_COLLECTION_WRAPPER\CLASS=LCL_COLLECTION_REF}-IF_BSP_WD_COLLECTION_REF~COLLECTION
2. When I click on the hyperlink on page 2:
The background generated HTML source code for lines 21 through 40 can be viewed in Chrome Developer Tools, as shown below:
So how does the backend know that it should start preparing its HTML source at line 21? This index information is passed from the foreground to the background via the HTTP request header field: ItemTree_visibleFirstRow.
If you are confused about the generation logic of prefix C36_W138_V139_, please refer to my blog WebClient UI Element ID Generation Logic
Set a breakpoint in the CL_THTMLB_CELLERATOR~GET_REQUEST_PARAMETERS method to find out where the background parsed the visibleFirstRow passed in by the foreground request:
In the BSP rendering class CL_THTMLB_CELLERATOR, this variable gv_visible_first_ROW is used to start the rendering index: lv_current_ROW_index:
The source code for each unit of each line is generated in turn in the loop. The loop is based on the column definition of the table. The current default configuration in my system, the search result has 8 columns:
For debugging purposes, you can view the generated HTML source code for the current page display in the variable GT_TABLE_ENTRIES:
For the second page, for example, the index starts at 21:
End with 40:
Why does the variable gt_table_entries have 168 records?
By default, 20 records are displayed per page, plus 1 row header, and each record has 8 columns, so the final result is (20 + 1) * 8 = 168.
