#22Where the LUW Ends

A dynpro developer carries a model of the LUW around without thinking about it. Every dialog step ends with an implicit database commit, so an UPDATE in a PAI module is on the database by the next screen. What was registered IN UPDATE TASK waits for COMMIT WORK. A MESSAGE TYPE 'E' or a short dump rolls back what the step had done.

In abap2UI5 the roundtrip is the dialog step (#7), so the first guess is that the model carries over unchanged. It does — with one difference, and it is the one that costs an afternoon: nothing the app writes is committed unless the app commits it.

Here is what happens around main( ) on every roundtrip, in this order:

1. ROLLBACK WORK — the app starts with an empty LUW.
2. main( ) runs.
3. ROLLBACK WORK — whatever the app left uncommitted is undone.
4. The framework writes its draft row to z2ui5_t_01 and runs COMMIT WORK AND WAIT.

The framework’s commit carries its own draft and nothing of the app’s.

The third step is the deliberate one. Without it, the framework’s commit in the fourth step — or the implicit commit at the end of the HTTP request — would carry along whatever the app happened to leave open, and an UPDATE would land or not depending on whether the code path that followed it raised, returned early, or simply forgot. So the rule is simple enough to keep in your head: if it was not committed in main( ), it did not happen.

  METHOD on_save.

    UPDATE zorder SET status = @status WHERE id = @order_id.

    " without this line the UPDATE is rolled back when main( ) returns
    COMMIT WORK.
    client->message_toast_display( `Saved` ).

  ENDMETHOD.

The same holds for every other way of writing, each with the commit it has always needed. CALL FUNCTION ... IN UPDATE TASK registers and COMMIT WORK runs the update. A BAPI writes and BAPI_TRANSACTION_COMMIT commits, as in #3. EML modifies and COMMIT ENTITIES saves: an abap2UI5 app is a consumer outside a RAP transaction, so the business object’s save sequence starts on the app’s command and not on its own (#36).

A failed roundtrip is rolled back too. An exception that leaves main( ) is caught once, in the framework’s handler, and the LUW is rolled back before the HTTP 500 goes out — the same outcome a short dump had, and the overlay the user sees is the one from #21. That rollback matters: the end of the HTTP request commits implicitly, and without it a write made just before the raise would land after all.

Every roundtrip is its own LUW. Nothing written in one click is still open in the next, so a change that spans two screens — a header on the first, items on the second — is either collected in attributes and written in one go, or written per screen with a status that says it is not finished. That is the same decision a stateless web application makes everywhere, and the same one #23 makes for locks.

A stateful app keeps its LUW. After client->set_session_stateful( ) the framework stops rolling back around main( ): the work process is the app’s, and so is the LUW across clicks. The draft is still written, and committed, whenever the app navigates or keeps an app state in the URL — so uncommitted work in a stateful app is committed at the next nav_app_call( ) at the latest. Which is one more reason the stateful session is the exception it is in #40.

The examples with every write path are on ABAP SQL and EML.

PAI wrote, the dialog step committed. Here the app writes, and the app commits.