on 09-13-2019 7:12 PM
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.
Regards
Hi Mahesh,
Yes. Hopefully I will do a write up if I complete the UI5 integration successfully.
Function import is a good idea. Thanks for the tip.
Regards,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Cool and You are most welcome. Will be waiting for that blog 🙂 🙂
Tip: You can click on comment and reply to the thread instead of posting a new answer as answers are solutions for the question.
BR,
Mahesh
Hi maheshkumar.palavalli ,
Thanks for letting me know. New SCN is somewhat confusing to me 🙂
Regards,
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.
Regards,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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).
BR,
Mahesh
Hello Prabaharan Asokan
Yeah, Sadly some of the best features are available in the latest versions.
You can also do one thing, inform the UI team about the time limit of the soft state session. So they can show a popup before it gets expired. Else they can resend a dummy request to the backend so the soft state stays active. In case if no action is performed by the user before the timeout, ask them to go back to the initial view automatically(outside of the customer view).
Thanks,
Mahesh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Mahesh,
Thank you for the pointers. We can do so to maintain the session active. Kudos to your thoughts!
Also am trying with the below possibilities.
I think session ID will be identified using the cookie sap-contextid with the HTIP request and looks in the below format when we enable the stateless oData service session into soft state stateful session.
sap-contextid=sid-NEW;
Am trying to rewrite the above Cookie into: sap-contextid=sid-ATT;
Am not sure how to do this in FrontEnd. Do you think it is feasible?
Reason for rewriting the cookie:
The sequence -NEW is an indicator to the ICM layer to place the incoming HTIP request Into an existing session or to create a new session if the old session is not found. This ensures that the HTIP request will be processed always which is what soft state does.
With -ATT the catch is, if the session does not exist any more, the ICM layer will display a session-timeout message, and the HTIP request will never be processed within the ABAP layer.
Regards
Hello Prabaharan Asokan,
That's an interesting way of doing it. You can do it easily in the UI5 using javascirpt code to rewrite cookies. Can you also tell me when you want to rewrite the cookie id in the ui5?(is it after the timeout that you configure in the sicf node?)
You can raise an error from the SICF node class, but I would still suggest you to do it at the ui5 level, It will be very simple. Just ask the ui5 guy to reset the timer(that you provide, which is the soft state seesion timout) whenever a request is sent to the backend. Now the ui5 guy just has to use a setTimeout function and just go back to the initial page once the timelimit is reached.
Or I am missing something here? please let me know If what I am even saying is legit or not as I am kind of cofused in this area.
Thanks,
Mahesh
Hi maheshkumar.palavalli
I'm a bit late to the party here and I'm aware you probably have lots of other things to do nowadays. ^^
I wanted to ask if there is a specific SICF Path / URL / Endpoint required to which a dummy-request would be sent to, in order to keep the session maintained and prevent requiring the user to login again? I'm not particularly talking about a specific odata soft-state here but rather the FLP session / cookie which is maintained in the backend.
Thank you in advance,
Marco
User | Count |
---|---|
101 | |
13 | |
13 | |
11 | |
11 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.