abap2UI5

Appearance

Performance ​

Almost all processing of an abap2UI5 app runs in ABAP; the browser renders what the backend sends. A roundtrip is one POST that occupies one dialog work process for three phases: reading the app draft, your main( ), building the response. The app can make three things expensive: the size of its instance, the size of its bound data and the number of times it rebuilds the view. This page is about the three; what a roundtrip costs the system and how the draft table grows is on Sizing.

Call view_display( ) once ​

The biggest optimization is not rebuilding the view on every event:

  • client->view_display( ) — sends a new XML view and model to the frontend. UI5 destroys the current view and creates a new one from scratch. Use this on initialization, and when the view structure changes.
  • Change your bound attribute and return. The framework compares the model before and after the roundtrip and pushes what changed by itself. UI5 refreshes the existing view via data binding, re-rendering only the affected controls, and the UI keeps its state — scroll position, focus, everything.
abap
METHOD z2ui5_if_app~main.

  IF client->check_on_navigated( ).
    DATA(view) = z2ui5_cl_ui5_view_builder=>factory(
        )->ele( n = `View` ns = `mvc`
            )->a( n = `xmlns`     v = `sap.m`
            )->a( n = `xmlns:mvc` v = `sap.ui.core.mvc`

            )->ele( `Page`
                )->a( n = `title` v = `My App`

                )->tag( `Text`
                    )->a( n = `text` v = client->_bind( mv_text )
                )->tag( `Button`
                    )->a( n = `text`  v = `update`
                    )->a( n = `press` v = client->_event( `UPDATE` ) ).

    client->view_display( view->stringify( ) ).
  ELSEIF client->check_on_event( `UPDATE` ).
    " no view_display( ), and nothing else either - the changed value is
    " pushed with the response
    mv_text = `new value`.
  ENDIF.

ENDMETHOD.

Keep the Model and the Instance Small ​

  • Bind data with client->_bind — the framework sends only the paths the user actually edited back to ABAP (a delta), so read-only and untouched fields cost nothing on the return trip.
  • Declare public attributes in your app class only for variables shown on the frontend. _bind( ) needs an attribute to be public, and only what is bound becomes part of the model sent to the browser. Every attribute of the instance, whatever its visibility, is serialized into the draft: it is read on every click and written on every click. So keep large data out of the instance; making it private is not enough. What a draft row holds and how big the table gets is on Sizing.
  • Follow standard ABAP best practices, like cutting loops and choosing sorted tables, just like in any other ABAP project.

Measuring It ​

To see where the time goes in production, log the roundtrips. The roundtrip monitor reports every roundtrip's duration in three phases: reading the draft, your app's main( ), building the response. It also reports the model and response sizes and the browser's own measure. The Admin Cockpit add-on turns that into p95 times per app and hints such as a model that has grown too large. From abap2UI5 1.147.0 on.

Still Slow? ​

Build a small sample that shows the problem and send it as a pull request to the samples repository. The maintainers analyze it and check whether the framework can be made faster.