|
| 1 | +--- |
| 2 | +outline: [2, 4] |
| 3 | +--- |
| 4 | +# Statefulness |
| 5 | + |
| 6 | +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. |
| 7 | + |
| 8 | +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. |
| 9 | + |
| 10 | +#### Stateless (default) |
| 11 | +| Phase | What happens | |
| 12 | +|---|---| |
| 13 | +| **Request** | Browser sends the serialized app state to the backend | |
| 14 | +| **Process** | A free work process picks it up, runs the controller | |
| 15 | +| **Response** | New view + state are returned, the work process is released | |
| 16 | + |
| 17 | +No work process is pinned, no enqueue is held, no `SET/GET` parameters survive. This is the recommended default for productive apps. |
| 18 | + |
| 19 | +#### Stateful Sessions |
| 20 | +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: |
| 21 | + |
| 22 | +```abap |
| 23 | +IF client->check_on_init( ). |
| 24 | + client->set_session_stateful( ). |
| 25 | +ENDIF. |
| 26 | +``` |
| 27 | + |
| 28 | +Release it explicitly on exit: |
| 29 | + |
| 30 | +```abap |
| 31 | +client->set_session_stateful( abap_false ). |
| 32 | +``` |
| 33 | + |
| 34 | +See `Z2UI5_CL_DEMO_APP_135` and `Z2UI5_CL_DEMO_APP_137` for complete examples. |
| 35 | + |
| 36 | +#### When to Use It |
| 37 | +Stateful sessions are useful when: |
| 38 | + |
| 39 | +- You need a **classic SAP-GUI-style enqueue** that survives between user interactions — see [Locks → Stateful Session](./locks.md#stateful-session). |
| 40 | +- 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). |
| 41 | +- You are migrating a legacy dynpro flow one-to-one and want the same session semantics during the transition. |
| 42 | + |
| 43 | +For everything else — and especially anything user-facing on a busy system — stick with the stateless default and use [optimistic checks](./locks.md#optimistic-check) or [soft locks](./locks.md#soft-lock) instead. |
| 44 | + |
| 45 | +#### Trade-offs |
| 46 | +::: warning |
| 47 | +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. |
| 48 | +::: |
| 49 | + |
| 50 | +A few rules of thumb: |
| 51 | + |
| 52 | +- **Always release on exit.** Wire `set_session_stateful( abap_false )` into your back / cancel / save handlers, not just the happy path. |
| 53 | +- **Keep sessions short.** A stateful session is a held resource, not a place to park work indefinitely. |
| 54 | +- **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. |
0 commit comments