#23 100 Rows, Four Hours, One Request ​

Three numbers decide whether an abap2UI5 app feels fast, and none of them is in your code. Learn them before you bind your first table — the first one in particular has cost more debugging hours than it has any right to.

100 rows. Every UI5 JSON model exposes at most 100 items to a list binding by default. Bind a table with 300 entries and the first 100 render — the rest are silently dropped, with no error anywhere, in ABAP or in the browser console. It is a UI5 setting, not a framework one, and it is raised per view from ABAP:

    client->follow_up_action( val   = client->cs_event-set_size_limit
                              t_arg = VALUE #( ( `1000` )
                                               ( client->cs_view-main ) ) ).

Raising it is the fix for a table of a thousand rows. It is not the fix for a table of fifty thousand: every bound row travels to the browser with the response, and back to the database with the draft. A screen that needs that many pages in ABAP — a SELECT with UP TO, a growing table, a filter bar — the way a selection screen always did.

Four hours. The serialized instance from #9 lives in z2ui5_t_01 until it expires, four hours by default. A user who comes back after lunch continues where they were; one who comes back tomorrow starts fresh. The number is draft_exp_time_in_hours in the user exit, and this table is the one place in the framework that grows — it is cleaned up on its own schedule, and a system with many users and long-running screens sizes it like any other table.

One request. Every click is one HTTP roundtrip plus one read and one write of the draft. So the cost of a click is the size of the instance plus the size of the model — and, as #9 warned, those are the same attributes. An app that carries a catalog of ten thousand rows in an attribute pays for it on every single click, in either section. An app that re-reads what it needs pays a SELECT, which the database was built for and is extremely good at.

What a click costs: the instance to the database, the model to the browser.

The rule that follows is the same one a dynpro program with global variables lived by: keep in the instance what the screen shows, and nothing that can be read again.

Small instance, bounded model, one request per click. Everything else the system already does well.