Skip to Content
You might also be interested with this blog Search Paging implementation in S/4HANA and CRM Fiori application.
The search implemented by WebClient UI framework in S/4HANA for Customer Management(called as S4CRM for short) does have paging mechanism with a small difference compared with other SAP products.
Suppose I have specified the following search criteria:
In my test system I prepares lots of Service Request as test data, so 200 Service Requests found as expected. The results are divided into 10 pages with each page displaying 20 rows by default.
Two key points for paging implementation in CRM WebClient UI framework:
1. Business data with number which equals to “max hit” value specified by end user is retrieved from database and held in application memory in ABAP backend server.
In my example above, the number is 200.
2. As WebClient UI is a server-rendering technology, all html source code are prepared in ABAP server. The browser simply displays those html source code assembled in the backend. ABAP backend only renders source code for records which will be visible in current page.
Take my above example for illustration, after I click search button, 200 Service Requests are fetched and held in the given buffer implemented in Agent search application. WebClient UI framework then prepare html source code for first 20 Service Requests. When I click page index “2”, the source code for 21th~ 40th records are generated.
If you woud like to get these two conclusions by yourself, you can following my research steps below.
1. You can use ST05 to find out the exact code where the Service Requests are fetched from new CDS view in S4CRM: CRMS4_SERVHSRCH
Then the last record is discarded:
Set a breakpoint in view ICCMP_INBOX/INBOXRESULTVIEW.HTM, inspect variable “me” in debugger:
And use this reference path to find the 200 records held in BOL collection wrapper:
{O:5768*\CLASS-POOL=CL_BSP_WD_COLLECTION_WRAPPER\CLASS=LCL_COLLECTION_REF}-IF_BSP_WD_COLLECTION_REF~COLLECTION
2. When I click the page index “2”, the second page is displayed:
the assembed html source code for these rows with index from 21 to 40 could be observed in Http response sent from ABAP backend:
How does backend server know it should render rows starting with index 21? This index is passed by frontend via http request parameter ItemTree_visibleFirstRow.
If you still have doubt about the prefix C36_W138_V139_, please refer to my blog WebClient UI element ID generation logic
Just set breakpoint on method CL_THTMLB_CELLERATOR~GET_REQUEST_PARAMETERS to figure out where the backend interprets this visibleFirstRow:
In BSP renderer class CL_THTMLB_CELLERATOR, this gv_visible_first_row is used as the starting index of current page – lv_current_row_index:
Then each rows’ cells are rendered within the loop against 8 columns visible in UI by default:
Table Columns header information are stored in lt_cellerator_cols:
For trouble shooting purpose you can inspect the final rendered html source code for current page in variable GT_TABLE_ENTRIES:
html source code for rows in second page starting from index 21:
and ends with index 40:
why gt_table_entries have 168 records?
20 records are displayed in a page by default plus one row for table column display, and in each row 8 columns are displayed with default configuration, as a result: ( 20 + 1 ) * 8 = 168

Further Reading and update for S4CRM

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply