In one of my recent project I was asked if it is possible to run OData services stateful.
By default, the OData protocol is stateless.
- Client sends request to backend
- Backend processes request (e.g. reads data from DB or writes data to DB)
- Backend sends response to client
- After the response is sent, the server forgets about the request.
- The server does not know about the previous request when it sends the next request.
The customer told me that they work with Easy-Cost-Planing which is implemented with ABAP OO. They would like to provide the API somehow via OData.
Here are my results of the investigation. Would be great to hear if I missed something or if there are other solutions.
Stateful server applications
Old OO server applications (e.g. Easy-Cost-Planning) often create a complex framework of class instances on the server side. In these class instances the state of the application is kept.
This state is kept in a user session. Thus each user on server side has its own tree of class instances with its own data.
Advantages of stateful applications
Stateful applications enable complex processes, which extend over many input masks and/or a long period of time, to be stored temporarily without delivering the inputs each time to the persistence layer (DB). Only after the user is satisfied with the result of his changes, he saves the data.
Disadvantages of stateful applications
- Stateful applications may require a lot of resources (memory) on the server to store the sessions of all users. With many users, the server quickly reaches its limits.
- Stateful applications may have to manage the locking of data. That is, the stateful application must either set locks in the DB (pessitmistic locking), implement an intelligent merge mechanism for concurrent changes, or lock the DB objects only when the user actually wants to write his data to the DB (optimistic locking).
- Stateful applications often do not release DB locks because the user sessions are not correctly dismantled (deadlocks).
- If Pessimistic Locking is used, DB objects are locked for other users until they are released (Concurrency Problem).
To solve these disadvantages in the web environment, user sessions are usually automatically terminated on the server side if there has been no activity for 30 minutes. However, this often leads to displeasure among users, e.g. when they go to lunch and forget to have saved the data they entered earlier in 3 hours of work.
Stateless applications
As described above, stateless applications do not notice anything on the server side.
But if a process in an application is more complex than just entering address data and saving it, the state has to be managed on client side. I.e. the client stores all data locally until the user clicks on the button "Transfer to server" (usually "Save").
Advantages of stateless applications
- Stateless applications consume significantly less resources on the server.
- Stateless applications can handle much more user requests.
- Stateless applications do not cause deadlocks or concurrency problems (see above).
- Disadvantages of stateless applications
Stateless applications usually work with optimistic locking. It can happen that a user has been working on e.g. a calculation in Easy-Cost-Planning for several hours and cannot save it because a colleague has made a change to one of the DB objects in the meantime. If the client application does not offer the possibility to merge the changes, all changes of the last hours are lost.
Stateful OData applications
OData services are, as described above, normally stateless. But to be able to work stateful there are the following possibilities.
OData-Model manages own state.
The UI5 OData model manages its own client-side state by default. All changes made to model objects in the UI5 application are kept in a client-side cache. Only the call of SubmitChanges() on the OData model transfers all data to the server in an OData batch request.
State management with a state machine
With the UI framework React, the client-side state machine Redux has established itself, with Vue it is Vuex.
For UI5 applications, you can use MobX, for example. At the UICon 2029 (?) there was a session about this.
Stateful Odata services
If it is too expensive or not performant enough (e.g. Easy-Cost-Planning) to use stateless OData services, you can run them stateful.
The use of stateful OData services with SAP Gateway is described on
help.sap.com.
However, this option seems to be available only from OData V4 onwards.
SAP Gateway
apparently supports the creation of V4 services.
However, the support is not yet fully implemented in SAPUI5, especially Fiori Elements is not or only insufficiently supported.
Soft State Support for Odata services
With OData V2 the
Soft State Support can be used. This also offers the possibility to run stateful applications.
But the default timeout is set to 120 seconds. If and how this can be increased is unknown to me. Alternatively, you can send a dummy request from the frontend to the server every <2 minutes to keep the session alive.
Other useful resources
The following resources are useful to understand session handling in SAP Netweaver ABAP.
Any thoughts and/or suggestions? Please comment here.
