Technical Articles
Locking in S4HANA via the Durable Locks & CDS View ObjectModel.Lifecycle annotation
Hello Everyone,
This blog is about the new locking concept in SAP, the Durable Locks and the CDS View Lifecycle annotations which will work for the latest ABAP Programming model for Fiori(Draft).
Note: This is just based on my understanding and the analysis I’ve done on it in the S4 system with ABAP 7.52 as I couldn’t find any detailed documentation about this.
First we will see Why the Durable locks are introduced and How this concept is utilized (along with some interesting stuff 🙂 ) in the latest SAP ABAP programming model for Fiori. I am assuming the same will be there for the Restful application programming model(RAP) as well.
We will not discuss how to create the durable locks(they are not released to the customers) but only to understand how they work and how to override their behavior in a Draft enabled Fiori Application.
“Why the Durable locks” are introduced.
*****If you already have an idea about the locking in Fiori apps via etags & soft state, you can skip this and move to section on “How the durable locks works“*****
I think everyone must be aware about the current SAP strategy for developing the new apps, which uses the UI5/Fiori for the front end and the backed will be CDS, ABAP and they both will communicate using the OData service, which will be a stateless model.
In this scenario, there will be no session maintained as the OData requests from the UI5 app will go, opens the session in the backend, fetches/updates the data and closes the session.
But in normal GUI/WebDynrpo apps, the session will be there till you log off.
So in terms of locking, if we are opening the Webdynpro/GUI app in the Edit mode, usually we will call the lock object to create the locking and so the other users cannot edit the same data till the first user commits the data or leaves the transaction.
Note: For beginners, there are blogs/SAP help out there which explains the locking concept using lock objects
Here comes the issue with the Fiori Apps, which will not persists the locks as the session will be closed after every request.
For example, If we call a OData request to lock the sales order, the request will go to the backend by opening a session, locks the sales order and when the request is completed, the session will be closed and all the locks will be removed 🙁
So how will you handle locks in these apps? (else the data might get corrupted)
For this SAP earlier has given 2 features
- ETag
- Odata soft state
ETag
Using the ETag, we can only achieve the Optimistic based locking.
It is based on a the timestamp or some other external calculation like hash out of the data.
E.g.,
- If the user A edits the sales order 1 and at the same time, user B can also edit the sales order 2.
- When they both click on edit, they will have already read the data of the sales order 1 in the UI5 app. Now assume they both will have the same timestamp(lastchangedon). But when they both saves the data, the first user’s request will go the backend and updates the data along with the timestamp(lastchangedon) in the data. So the timestamp (lastchangeon) is changed in the db.
- Then the user B request will go to the backend and the system will check if the timestamp in the db and timestamp coming from the UI matches and if not it will give error for the user B.
With a little configuration, OData framework automatically takes care of it. This will not be very helpful in all the scenarios as the users might have to enter the whole data and just to see an error message at the time of saving. There are many blogs & sap help to learn more on this topic.
https://blogs.sap.com/2017/06/30/optimistic-locking-etag-in-sapui5/
OData Soft State
By using this a session is maintained and once the configured timeout is reached, the session will be closed. So till the time session is opened, we will have locks, then after the session is closed, locks are removed.
But SAP themselves said in the help to not use this for transactional processing and should be used only to improve performance by buffering the data. But anyways, opening a session will definitely put a toll on the server and performance and we will have to open the session just to persist the lock.
Below are the comments reg. the soft state from Jocelyn Dart and the SAP team
The issue with soft state is that it is not recognized on the UI if it is gone just as a new session is opened (and a new lock acquired). Therefore it is not usable or only in combination with eTag.
So for this reason, the new Durable Locks are introduced.Like the name “Durable” suggests they are “Long Lasting”. So these locks will not be removed even if the session is closed.
Wow right!!, no session required to maintain the locks 🙂 for me it’s an awesome feature and
Kudos to the SAP architects and the team who designed this.
“How the Durable locks” works.
These locks are long lasting because they don’t depend on the session/commit work. They depend on the context and will persist for a long time(based on the expiry time). So what is this new context I just mentioned??
From the SAP Help
A durable lock is requested using a context. A context is a lock phase in which durable locks are assigned to this context. A context belongs to a draft document and is bound to this draft or to a shorter lifespan.
Durable locks are only available for specific SAP applications or frameworks.
So the context is based on the draft document and like sap mentioned, these are only available for few frameworks and one such is ABAP Programming model for Fiori with draft.
So for the people who are not very familiar to this framework, please check my other blog as the below example is based on it and If you try that example once, it will be very easy to understand the below process.
Heads up: I will discuss two types of locking here.
- Enqueue locking -> This is SM12 lock & the Durable Lock (Exclusive)
- Processing locking -> Lock maintained in the Draft Admin table & a Draft Lock (Optimistic)
- This is about overwriting the behavior of the the above two locks, so better check my another blog on how the locking works before coming here 🙂 Link
I am giving this warning because it might be a bit confusing. Hope I will try my best to explain 🙂 I
Let’s check the below video to find out how the locking works when 2 users(DUSER1, DUSER2) opened the same app and tries to edit the same data.
DUSER1 -> Edits the existing data, the framework will create a draft document and locks it by creating an SM12 lock.
DUSER2 -> Edits the same data, the framework will check the lock and throws the error.
DUSER1 -> Closes the app and the browser, without discarding the draft document( didn’t click on cancel button or SAVE button which will discard the draft).
DUSER2 -> Opens the same data and clicks on “Edit” and it will still show the error.
The error is still coming for the DUSER2 because the DUSER1 didn’t click the cancel button and closed the browser and so the framework didn’t remove the lock, which is the reason why the DUSER2 got the error. So how and when the lock will removed now? This will be discussed in the later part of the blog.
For now lets see the SM12 lock that will be created when the DUSER1 clicks on the “Edit” button.
Here you can see the Draft ID- which is nothing but the draft table entry key for the sales order header draft table. You can open the auto generated draft table and compare the data here.s
More technical information below:
When the user clicked on the “Edit” button, a function import call goes to the backend and it will call the below Action(standard auto generated action for the BO)
Class “*LIB_A_EDIT” call will create the draft entry and it will also create the lock using the durable manger class – “*DURABLE_LOCK_MNGR”.
Internally a kernal method is called which takes the draft id and will create the enqueue entry in the SM12.
So let’s get back to our issue where the lock is not removed when the DUSER1 closed the Fiori app without cancelling the created draft.
What happens in this scenario is the lock gets stuck in the SM12. To handle this, In the background SAP internally will call an RFC function module(periodically for every 5 minutes) to delete the locks for the draft entries which are expired.
So how they know that the draft entry is expired?? The expiry time for different CDS Views are defined in a standard table, which the framework uses to check if the draft entries are expired and if they are, it will delete the lock on the draft entry.
(In the server I tested, for every 5 minutes the RFC Function module is called in the background but it is not a background job, I think it is some kernal call) – This is called as “AUTO ABAP”, check Jocelyn Dart comments for more details.
Let’s see where they store the lock expiry timings and how much is the default expiry time.
Table: SDRAFT_LC_CONFIG
You can see the first entry: <DEFAUTL> , which has the expiry_duration for all CDS Views(Transactional Enabled) is 900s, which is 15 minutes. So till 15 minutes, the Draft is locked form SM12 and no one can edit that entry from the Fiori app except the user who created that lock (DUSER1).
There is also another admin table, which has all the admin data related to all the draft entries. Whenever a draft entry is created in any application, it will be stored here. This has very important information related to the locks (ENQUEUE_CONTEXT & IN_PROCESS_BY)
The RFC FM which deletes the locks will take the data from the above table, which has the enqueue context & LAST_CHANGED_AT data. Then the framework will compare the last modification date from the admin table and the expiry time from the config to delete the SM12 lock that is linked to the Enqueue_context field.
So in the system the <DEFAULT> expiry time to clear the locks is 15 minutes and an additional 1-5 minutes because the RFC Fm to delete the locks will be called every 5 minutes.
cl_enq_context_admin=>run_cleanup_task( ).
Method call that cleans up all the locks. You can call that to clean immediately after 15 minutes if you don’t want to wait for that additional 5 minutes when you are testing. Don’t really recommend it though.
So how to override this 15 min locking period?? (if you want to increase or decrease the time).
Go to the root transactional CDS view and add the below annotation:
Now I changed the expiryInterval to 1 minute, BTW you cannot give less than 1 minute.. If you give, it will automatically change to 15 min the backend and it is not showing any error in the eclipse when activating the CDS view. But do not give 1 min also as it is not a realistic time.
you can check the documentation below:
Activate and see the table entry below, for our transactional CDS view, it is showing 60 second(1 min).
Now the enqueue locks will get expired after 1 min.
When the lock gets deleted come back to the Fiori App and refresh it, it will “still show that it is locked”.
This is because of “lifecycle.processing” expiry time (The second Lock)– I will discuss this one later.
If the DUSER2 opens and edits it, it will allow him to edit it even though in the first page it is showing as “Locked by DUSER1”. This is because we missed one annotation in the CDS view.
For SAP: I am not sure if this is a bug or expected behavior as the processing expiry time(2nd type of lock) has not been reached so it should not allow us to edit.. when debugged the code, they are checking if the etag is changed first and then checking the process expiry time(don’t remember now correctly). But Etag code passes because we didn’t mention the above annotation and it allows us to edit.. something in those lines..
Ok let’s add the below annotation and activate the view.
We are mentioning that “changedat” for the ETAG related check, this has a special significance, which i will discuss in an another blog 🙂.
For now to fix this issue, lets activate and test it.
Now as we added the ETAG annotation, when the DUSER2 clicks on edit button, it will give him the error that it is locked by DUSER1.
But if you see the above gif, there are no locks in the SM12 as the 15 min expiry time is passed and the locks are removed by the RFC FM. But still the error is being displayed when you click on the edit button. This is because the “Enqueue lock” is deleted by the framework but the draft entry still have the ‘In Process’ user assigned, which is the “Processing Lock”(2nd type).
You can also observe that the “Enqueue Context” is removed along with the SM12 lock.
Weird right? Why there are two types of locks for a single draft application?
Actually enqueue context locking is used for legacy GUI apps locking like BP Tcode.(I will explain this in an another blog).
Let’s check the draft config table for the Processing Lock
So it says for the “22” – Processing expiry event has the expiry duration of 900 seconds, which is 15 minutes.
This is same as the enequeue lock default setting, so in normal applications, these two locks won’t make any difference as they both will be released at the same time. So the difference when you maintain two different custom expiry intervals for both of them.
So let’s override it by adding the below annotation and activate the program.
If you go back and check the same draft config table after activation, you will see “21” expiry event for our CDS view as 60 seconds.
When the processing lock gets expired after 1 min, the “IN_PROCESS_BY” will be removed. lets see the table entry.
Let’s go back to the Fiori App
- When the DUSER2 opens the fiori application, it will show that there are unsaved changes by the DUSER1 (becuase duser1 created the draft entry).
- If the DURSER2 tries to edit that entry, it shows a warning popup and if the you click on “Edit”, It will delete the existing draft by DUSER1 and creates an another draft for DUSER2.
So for the Fiori app, if the User 1 edits an active entry, the framework creates a draft entry. So if the User 2 wants to edit the same active entry, he needs to wait for the framework to remove the Processing and the Enqueue locks for the DUSER1 draft entry.
BTW if the User 1 saves the data to the DB by clicking on the “Save” button or discards the draft entry by using the “Cancel” button from the Fiori app, then no lock will be applied on the active entry as the locks will be removed by the framework and the draft admin entry will removed from the admin draft table.
So what is the difference between these lifecycle.processing(draft lock) and lifecycle.enqueue(durable lock) expiry times as they are very similar?
I will show with an example about this in an another blog 🙂
Still confused?? Go and check the below comment by Harald Evers, the co-innovator of the Durable locking framework.
Design goals were to preserve the long-standing pessimistic enqueue locking in ABAP based stateful applications and combine it with further lock capabilities in the Fiori programming model. As a consequence of the durable enqueue lock approach, no existing lock coding in those stateful apps, process integration or batch input logic needs to be modified when introducing Durable enqueue locks in draft-based Fiori applications and OData services.
The strict pessimistic lock of session-based enqueues seamlessly work with or better said as durable enqueue locks if created by a framework with the corresponding context. This interoperability is important for scenarios where editing a draft in a Fiori application may get in conflict with concurrent stateful UI usage, process integration or batch input logic. The according interval is dedicated to this scenario and should be the smallest one.
In a pure Fiori world without existence of such stateful apps or enqueue based logic the processing interval may apply as a second approach to pessimistic locking. Since this is a different lock conflict pattern we decided to separate concerns and introduced the processing interval. However, you are right that for a draft exclusive to a single user both intervals should be the same for the sake of simplicity. So typically, if you change one of these intervals you should keep the other in sync. Nonetheless, designing it this way gives us options to further evolve draft handling, in future.
Finally, the optimistic locking applies once the intervals are exceeded and the draft lifecycle handler has run. Still, the user can be informed about former modifications of another user as a usability plus compared to the pure session-based locking. Without concurrent accesses a user may pick up entries made before and resume the draft processing (then entering a new phase of pessimistic locking).
Please leave a comment if you guys have any questions or suggestions.
Thanks & Best Regards,
Mahesh
Thanks, Mahesh.
It is very interesting and usefull topic.
Mahesh,
Nice blog and well articulated. 🙂
Regards,
Dhruv
Mahesh thanks for the detailed explanation. One thing which i am wondering is why is SAP using such a complex logic for locks. One lock is SM12 one which gets removed and another is processing life cycle one. I think the overall idea of moving forward to S4 or Cloud is to make things simple right. Too me I personally feel SAP shall have a look at this durable locks and make them simple to understand for anyone.
I must thank you for taking your time out and documenting this critical behavior plus i ended up ready two more draft capabilities enabled blog while going through the links mentioned by you:)
Thanks for the feedback Nabheet. The more the merrier ?
I found couple of mistakes regarding the processing lock expiry times in the blog and rectified them. I also updated some information as well related to the locks. I will try my best to explain your question below
But if you see, unless if the user overrides the default expiry setting in the CDS view, no one will actually see the difference between those two locks as they both will have the same expiry interval(both locks will be removed at the same time). So for customers it is very simple to lock the GUI and the Draft as they don’t need to write any additional code to lock.
So I am assuming that maybe in some scenarios, to prioritize the locking for the GUI and the Draft, this has been introduced.
For e.g., In a scenario where the active data gets updated from another system via some interfaces. Here we can define the enqueue expiry time(durable locks) a bit less than the draft processing expiry time. So that if any interface calls comes from another system, it don’t need to wait for the sm12 enqueue locks to be removed.. But for the same data, when it comes to the Fiori application, the draft lock will still be exclusive for the created user for some more time.
To be frank, this is all my speculation as there is very less documentation on this topic.
BTW: In the help link, they said that durable lock is applied on the active document but not on the draft, I think they meant the durable locks only for the Active document not for the draft document. Then it will make sense that the processing lock in the admin table is for the draft entry and the durable lock is for active entry. But again they are creating durable locks for both the draft and active entries https://help.sap.com/viewer/cc0c305d2fab47bd808adcad3ca7ee9d/7.5.9/en-US/896496ecfe4f4f8b857c6d93d4489841.html
Hi Mahesh,
thanks for the Kudos - I forwarded them to my co-innovators ?
You have very well analyzed, described and illustrated this rather complex topic. Design goals were to preserve the long-standing pessimistic enqueue locking in ABAP based stateful applications and combine it with further lock capabilities in the Fiori programming model. As a consequence of the durable enqueue lock approach, no existing lock coding in those stateful apps, process integration or batch input logic needs to be modified when introducing Durable enqueue locks in draft-based Fiori applications and OData services.
The strict pessimistic lock of session-based enqueues seamlessly work with or better said as durable enqueue locks if created by a framework with the corresponding context. This interoperability is important for scenarios where editing a draft in a Fiori application may get in conflict with concurrent stateful UI usage, process integration or batch input logic. The according interval is dedicated to this scenario and should be the smallest one.
In a pure Fiori world without existence of such stateful apps or enqueue based logic the processing interval may apply as a second approach to pessimistic locking. Since this is a different lock conflict pattern we decided to separate concerns and introduced the processing interval. However, you are right that for a draft exclusive to a single user both intervals should be the same for the sake of simplicity. So typically, if you change one of these intervals you should keep the other in sync. Nonetheless, designing it this way gives us options to further evolve draft handling, in future.
Finally, the optimistic locking applies once the intervals are exceeded and the draft lifecycle handler has run. Still, the user can be informed about former modifications of another user as a usability plus compared to the pure session-based locking. Without concurrent accesses a user may pick up entries made before and resume the draft processing (then entering a new phase of pessimistic locking).
BR Harry
Thank you so much Harald Evers for the clarification. I am a fan to the Durable locking concept. I always had trouble answering to the customer questions with regards to the the pessimistic locking in the Fiori based apps, but not anymore 🙂 ( Thanks to you guys 🙂 )
I was confused at the beginning whether to post this blog as I might be wrong 😀 . Now I am relieved that my analysis is not completely wrong 🙂
I will mention your comment in the blog so it will be useful for those who are looking for this information.
have a different view here and agree with Nabheet Madan . We need to zoom out and have a outcome specific dive into this.
Primary arguments for digital are around customer experience, data ubiquity and process excellence and in all this users should be oblivious to the technical constraints.
To me all three have been violated here.
Simple use case to refer to would be concurrent editing and merge from confluence and outliers handling for conflict.
The draft could have been handled better and rather than enhancing the locking layers, SAP could have looked at designing a concurrent and merge process to support the true definition of REST.
Surely there would have been challenges( Can think of Audit Trails for conflict scenarios straight away) but surely there are smart people to handle this.
Let me know ur thoughts…
Regards,
Sitakant.
Hi
Thanks for your comment.
You and Nabheet Madan are correct, if only we have to configure those locks by ourselves.
But this blog is to understand what is happening internally and for the customers they don't need to touch this logic. For them locks will be automatically implemented and it works like a charm more simple then the existing enqueue locking which we have to call manually, here it is all automatic.
For example. The application programming model for fiori has so much complex logic both for UI5 and backend. In the UI5 they generate the controls using JS (which is not so recommended by SAP but still sap uses it) and backend it will be even more complex logic that are written to fetch the draft and compare with active and much more..
But for customer?? it is very simple, they create the CDS view and assign the draft table and create the consumption view then bopf will be generated and UI will be generated from the webide effortlessly.
the inside logic is very complex but for customers it is very easy to do. Same way, if you go through the blog, when I overriden the durable locks and processing locks timing then only we will see the differnce else it doesn't matter at all and moreover SAP created the processing locks(optimistic) for some future roadmap as said by harald.
I think I will update this blog mentioning that this to understand internally what is happening and if we override the locking lifecyle then only we will see the difference else it will cause confusion.
Thanks & Best Regards,
Mahesh
Hi Mahesh,
No questions on your findings... they getting brilliant every day :).
The comment was just to stimulate thoughts on whether this is the right way to go or there could be better ways of doing things.
Regards,
Sitakant.
Haha sorry bro if my comment had that vibe 😀 😀 .. infact I was happy to see your comment 🙂
What I was saying is that if we don't see this blog then we will find the locking with SAP draft framework to be the simplest one using the durable locks. To be frank this blog actually make people think it is complex 😀 so that is the reason why I said that I will update this with relavant comments and moreover I want to create another blog which show end to end of locking without complexity, which makes it easily understandable.
Warm Regards,
Mahesh
Hi Mahesh, Interesting blog and well explained. FYI you might want to add tag "SAP Fiori for SAP S/4HANA" to broaden your target audience.
Rgds
Jocelyn
P.s. Official name is always SAP S/4HANA
Thanks Jocelyn Dart , updated the tags accordingly.
Hi Mahesh,
Again thanks for an excellent blog on a very deep topic - really great that you are incorporating Harald's comments. FYI I passed it onto the team as we thought it was so good it definitely deserved getting some feedback from the team themselves!
I've also added it to the Expert Deep Dive section of the Fiori for S/4HANA wiki - this is exactly the kind of stuff you need to know when creating your own custom Fiori apps.
I have a couple of other comments from the experts that would improve this...
Re OData Soft State:
The issue with soft state is that it is not recognized on the UI if it is gone just as a new session is opened (and a new lock acquired). Therefore it is not usable or only in combination with eTag.
Re: In the server I tested, for every 5 minutes the RFC Function module is called in the background but it is not a background job, I think it is some kernal call
This is what is known as AUTO ABAP.
Rgds
Jocelyn
Thank you so much Jocelyn for getting the feedback. It has cleared some confusion on this topic. I’ve included the same in the blog.
Best Regards,
Mahesh
EXCELLENT blog!!! I appreciate the detail and time you put into this. The explanation is easy to follow and thorough! Keep them coming!
Thanks Christopher Solomon for the feedback and the encouragement 🙂
Nice article with good summary !
Thanks aditya 🙂
Hi Mahesh Kumar Palavalli,
thanks for that awesome post and the great introduction into this topic! I tried to build a freestyle app including durable locks and drafts according to your concept. Currently I am facing a problem, when the user stays in the edit mode without changing anything and reaches the optimistic lock phase. When the user now tries to change a value in this phase, I receive a 409 conflict error when saving the draft changes 🙁 Do you have any idea how to solve this so the user gets a pessimistic lock again after changing a value? Is there maybe a special function import to call or did I mess up something with etag handling?
Thank you so much in advance!
Martin
Thanks for the feedback, Martin.
I am not sure about that error, but I would advise you to investigate why the 409 came, it will only come if the data that you have and the data from the backend doesnt match(timestamp). ( anywhere in the backend the data is getting updated?)
I tried standard bp app and saw after 15 min and didn’t get any error in the batch call after updating a field(after 15 min).
ps: I would definitely not call it my concept, i just got lucky to write a blog about it

Do you know the name of this RFC function ?
Hi Chaouki Akir,
I don't remember the FM.. But inside that, the below method is callled.
-Mahesh
Hello,
thank you. I have done a where used list and the function name calling this method is FM_ENQ_CTX_CLEANUP_TASK.
This function is called by a report RS_ENQ_CTX_CLEANUP_TASK
Report RS_ENQ_CTX_CLEANUP_TASK
==> function RS_ENQ_CTX_CLEANUP_TASK
=====> Method cl_enq_context_admin=>run_cleanup_task( )
=======> Method cleanup_enq_contexts of classes CL_DRAFT_ENQ_CONTEXT_ADMIN, etc...
ohh cool, thanks for sharing.. Last time when I saw this, I don't remember any report calling that FM, maybe it's in the new version..
But it is very interesting to dig up all these and understanding how beautifully SAP has implemented a lot of stuff in new fiori & rap programming models.. Hope you are having fun!!
Hey Mahesh,
Late to the party but I have read the entire blog, initial it was bit confusing but I read multiple times to make sure I understand each concept . You must have spent decent amount of time in debugging and developing the demo app as well.I have to appreciate you for that.
After spending sometime on this, I am left with one question. That is,there are chances the user still be working on the sales order and the locking got expired , Let’s take a below scenario which will lead to details of my question.
I am not sure how to handle this scenario, after thinking for sometime I came with this idea. Why can’t we give control to the User1(who first started editing) in this case while the user2 trying to overwrite.
E.g: when the user2 is trying to edit and chose to overwrite there should be a mechanism to send a notification to user1 saying
“hey one of your colleagues trying to mess with your items, would you like to allow him to overwrite?”( just a funny example)
So that user1 can reject changes and then user2 cannot overwrite. Is it even possible?
I don’t know if this sounds weird, what are your thoughts on this.
Regards,
Nagendra
Thanks for the feedback... I did spend more time on that ? , I was waiting from a long time to see how sap will solve this locking issue in Fiori apps and bam, one day i found this and got obsessed with how they are doing and here I was with this blog ?
I understand what you are trying to say, and I am not sure if any solution exists for the same.
But if we think about it, it’s rare that two users will be accessing the same document at one time and even if the user 1 is processing 100 items, on adding every item, it sends draft request to save that data in the backend, so again the locking time will be extended on ever backend call, so hopefully adding a large no of items won’t cause any issue.
But if a user want’s to hold an item for long period, if there is an option to reserve it for that user and other users get’s an error that it is reserved or being process by original user it would also do, this can be implemented programmatically by us.
Okay, so we can prevent user not to overwrite pragmatically ? within Fiori elements?
We don't need to touch fiori elements, it's just from the backend, we will show that error.. we can create an additional field in our header table which holds the timelimit or some flag and we can reset or check that in the lock class method and throw error..
It's just a rough idea..
Excellent blog! Very helpful! Thank you!
Thanks Uma Naik 🙂
it is very useful blog, thank you Mahesh Kumar for sharing your knowledge. We have similar requirement in our project. I have small question regarding this, is that work on ABAP CDS views instead of S4HANA CDS ? our client system is not S4HANA based.
thank you in advance.
Thanks Shiva Charan Koti 🙂
It's part of ABAP Programming model for Fiori Framework and I don't think it will work outside of it.
So alternatives are ETag or Soft state. Check this presentation i've given.
https://www.youtube.com/watch?v=il_2-LHhik8
Thanks,
Mahesh
Thank you for quick response. I will check the video for sure. once again very good work your side.
Hi Mahesh,
I watched your video completely. I would like to do solution with delayed invocation, I called the method /iwbep/if_mgw_conv_srv_runtime~soft_state_session_start at the time of edit application.
but the session is not getting started, could you please tell me do I need to do more here.the method looks like below.
I have also tried with redefining it but still it doesn't create session. it would be really helpful if you provide details solution with delayed invocation.
Thank you in advance.
Hi Mahesh,
I watched your video completely. I would like to do solution with delayed invocation, I called the method /iwbep/if_mgw_conv_srv_runtime~soft_state_session_start at the time of edit application.
but the session is not getting started, could you please tell me do I need to do more here.the method looks like below.
I have also tried with redefining it but still it doesn’t create session. it would be really helpful if you provide details solution with delayed invocation.
Thank you in advance.
you need to do the following things for the delayed invocation to work.
1. Redefine the "Define" method in mpc_ext class and add the below code:
2. Then redefine the methods from DPC_EXT, OPERATION_END & OPERATION_START
3. Now, when you call this method, /iwbep/if_mgw_conv_srv_runtime~soft_state_session_start( ). soft state will be activate.
If it doesn't work, post a question, so your issue can be analysed by other community members.
Regards,
Mahesh
I worte a blog post as well,
https://blogs.sap.com/2020/11/26/sap-odata-soft-state-with-delayed-invocation-for-locking
Thank you for infromation Mahesh, I tried the solution to open soft state only at the time of update with help of your blog.
its works absolutely fine from gateway but it does not work from the UI5 app because of the soft state is enable with meta data call(it access MPC–>define method) and lock post call is from different batch request. by the time lock post request comes to back end the soft state is not enabled.
When I access start_soft_state_method() with post lock request, I get exception because of soft state is not enabled.
I am trying to find solution for this, if you know any tip or quick solution for please share here.
when soft state with out delayed invocation. the meta data call enables soft state and following lock post call will create lock within soft state.
Did you find a solution for this problem?
One of the best blog , I can find for the locking ..Thanks @Mahesh for awesome blog and work.
Thanks for the feedback Mohit Bansal 🙂
Awesome blog Mahesh!!