Statefulness
By default, abap2UI5 runs stateless like any other UI5 freestyle app, with only REST calls to the ABAP backend. Each roundtrip starts a fresh ABAP session, executes the controller, serializes the app state back into the client, and tears the work process down again. Nothing on the server survives between two clicks — and that is exactly what makes the runtime scale.
For the small set of cases where a sticky backend session is needed — classic GUI-style locking, heavy session-bound resources, RFC connections that must stay open — abap2UI5 can also run in stateful mode.
Stateless (default)
| Phase | What happens |
|---|---|
| Request | Browser sends the draft id and the model delta — not the app state, which never leaves the server |
| Process | A free work process picks it up, reads the app instance back from its draft row, runs the controller |
| Response | View, model and a NEW draft id are returned; the app state is written to that new draft and the work process is released |
No work process is pinned, no enqueue is held, no SET/GET parameters survive. This is the recommended default for productive apps.
Stateful Sessions
For private and on-premise systems, you can switch a running app to stateful mode. The same work process then handles every subsequent roundtrip of this user, and ABAP globals, locks, and open RFC connections survive between events:
IF client->check_on_navigated( ).
client->set_session_stateful( ).
ENDIF.Release it explicitly on exit:
client->set_session_stateful( abap_false ).See Z2UI5_CL_SMPS_APP_485 (sticky session with locks) and Z2UI5_CL_SMPS_APP_486 (sticky session) in the samples-stack repository for complete examples.
When to Use It
Stateful sessions are useful when:
- You need a classic SAP-GUI-style enqueue that survives between user interactions — see Locks → Stateful Session.
- You hold a resource that is expensive to set up on every roundtrip (e.g. an open RFC destination, a long-running selection, a cached internal table that cannot be re-derived cheaply).
- You are migrating a legacy dynpro flow one-to-one and want the same session semantics during the transition.
For everything else — and especially anything user-facing on a busy system — stick with the stateless default and use optimistic checks or soft locks instead.
Trade-offs
WARNING
A stateful session pins one work process per active user for the lifetime of the app. On a system with a handful of dialog work processes, a few dozen idle stateful sessions are enough to starve everyone else. Use it sparingly, on internal low-traffic apps, and always pair set_session_stateful( ) with an explicit set_session_stateful( abap_false ) on every exit path — otherwise a leaked enqueue or a pinned work process blocks future users until the session times out.
A few rules of thumb:
- Always release on exit. Wire
set_session_stateful( abap_false )into your back / cancel / save handlers, not just the happy path. - Keep sessions short. A stateful session is a held resource, not a place to park work indefinitely.
- Public cloud is stateless only. S/4 Public Cloud and BTP-hosted scenarios do not support stateful sessions — design for the stateless model from day one if cloud-readiness matters.
Working Samples
Complete apps from the sample catalog
that use what this page describes. Each is a single class in abap2UI5/samples
unless its row names another of the three sample repositories — pull that repository with
abapGit and start the class with ?app_start=<class>.
| Sample | Class |
|---|---|
| Stateful Sessions — Basics — counts up while the session is stateful, starts over once it is not | Z2UI5_CL_SMPS_APP_486 · samples-stack, branch 06-stateful-locks |
| Stateful Sessions — Locks — ENQUEUE_E_TABLE and ENQUEUE_READ, end and restart the session | Z2UI5_CL_SMPS_APP_485 · samples-stack, branch 06-stateful-locks |
| Stateful Sessions — Navigation and Locks — every Next Lock View takes the next VARKEY, going back releases it | Z2UI5_CL_SMPS_APP_490 · samples-stack, branch 06-stateful-locks |