Showing results for 
Search instead for 
Did you mean: 

Stateful Fiori / Custom UI5 apps


Dear Experts,

Hope you are doing great.

Our UI5 applications are launched from SAP CRM Web UI when the agent answer the Telephone call via CTI integration. We are looking to implement stateful Fiori application mainly for lock mechanism in my customer landscape.

Is it feasible to implement stateful Fiori apps in projects where interoperability b/w Fiori apps & GUI is required. Just to give a quick background, we wanted to have locking functionality in custom Fiori applications and we are facing challenges since sessions are stateless in oData services and locks are lost moment request is completed. We tried using soft state with the time out mentioned in SICF but the downside of this is, UI5 front-end is not kept informed when the session got timed out in the backend.

May be from oData stateless context it is perfectly fine but from business use case standpoint they expect Fiori & GUI to be interoperable. We are having possible scenarios where different customer care agents or the back office managers could operate / edit on the same Business Partner / customer from GUI & Fiori simultaneously.

I also understand SAP recommends using Draft documents/Durable locks but again the downside is, those are available for customers running >=7.51 only and not all customers are up to it yet i believe.

My Customer is using hub deployment with both hub and backend running on NW 7.50 SP14 using Oracle DB.

Side note:

Does this mean for complex business transactions where stateful session and tight coupling is required with the backend is required, we should use WD ABAP framework which serves the purpose ? I believe am not sailing in the boat alone and many of you folks might be facing this problem in your customer implementation projects.

Please feel to reply here with your thoughts if you have experienced issues.


View Entire Topic

Hi maheshkumar.palavalli ,

Just completed some tests in the system (NW 7.50 hub setup). Results are looking good and the database locks are getting maintained in the same session.

The idea is to reuse the same session after the first request. NW 7.50 supports soft state by request header(instead of cookies since it has some limitations) as mentioned here . So after the request receiving the session id from the first request under response header 'sap-context-id' then replace the header value from sid-NEW to sid-ATT and then reuse this modified header value further requests, thereby maintaining the session and the locks associated to it.

From UI5 make the dummy request to backend as long as the user is active in the application by adding request header into oData model instance. Even this modified header can be used for all the calls made to backend during the change mode and until the user ends with the modifications. So that all the processing happen in the same stateful session and keeps the session active as well. Key thing to not here is, oData service triggered here is the same every time.

Regarding with the timer, the timer in UI5 is set to soft state session time out minus one minute. Ex: If soft state session time out in the backend is 3 minutes then dummy request will be triggered every 2 minutes.

Side note:

1.If the user is not active in the application, find the right idle timer events in UI5.

2. If the user remains inactive in the application, optionally prompt with the warning dialog before the timeout and give the opportunity to preserver the session and reset the time out error.

3. If the user close the application / window then terminate the session by sap-terminate: session using the HEAD request as mentioned here.

Hope this helps.


Active Contributor
0 Kudos

Cool, did not know that you could manipulate the softstate session with request headers. You could write a blog about this 🙂 which will be helpful to a lot of people who are looking at scenarios like that.

One more thing, you could create a function import and call that function import from the ui5 and inside that you can call the method soft_state_session_end to end the session as well (Correct me if I am wrong).



0 Kudos


I tried to follow what you have mentioned and it was working fine until I hit one issue with SoftState.

I have implemented SoftState for locking the object in the backend while object is being edited in the SAPUI5 screen.

In general, everything works fine and below are the high level steps.

1. I make get Entity call to retrieve the data of a particular object.
2. In this get Entity Call in the backend, I call ENQUEUE function module to lock the object.

3. On the screen, when user cancel and go out of this edit screen, I call function import to release the object in backend by calling DEQUEUE FM.


When we execute above steps very first time in the UI5 application, I observed that ODATA call is being made to backend with different 'sap-context-id' for Get Entity Call and Function Import calls. I believe, that is the culprit to identify the lock part of the same session in the backend and it does not release the lock.

Subsequently, if I edit another object and then come out of the edit screen, both Get Entity call and Function Import call happens with the same 'sap-context-id' and thus releases the lock on the object correctly.

So, now my question is, how can I make sure first call happening for Get Entity and Function Import goes through the same 'sap-context-id' so that ENQUEUE & DEQUEUE happens for the object in the same session recognizing the own lock and not the foreign lock?

 I had followed below blog to implement softstate successfully in my ODATA and SAPUI5 application except above issue.

@maheshpalavalli & @former_member184739 : Please provide your valuable inputs in this regard.

Thank you,