on 2024 Dec 06 10:29 AM
I have a managed (self-built) RAP object, that is working pretty well together with the generated Fiori-Elements-App.
Upon creating/updating/deleting a dataset in that BO I want to update another (SAP-built) BO through EML. But as I can't commit changes within the "save_modified" and without committing them they won't get saved, I am a bit lost. I also tried to raise a custom Business-Event, fetching it in another class, yet still EML-Modify plus EML-Commit are crashing on runtime because in the obviously synchronous Event-Handling (why synchronous?) I am still "not allowed" to Commit things.
Hope someone can help me soon on how to solve this, Google was no help at all.
Request clarification before answering.
Normally you are not allowed to execute COMMIT within the Transactional Processing, since an implicit COMMIT happens at the end of the SAVE sequence of the processing.
You should be able to call through EML external BO MODIFY and should be commited together with your change.
If you want to build around the idea to commit the other BO before your commit happens, you could do it via an async RFC (https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/abapcall_function_starting.htm)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
like yunwu also replied.
The commit should be done by the framework automaticly. I've a similar scenario where I modify entities of a different BO within the RAP LUW. But this is done inside the action implementation ( and not inside the save_modified ) ans this is working well for me
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi
To update another BO through EML in a managed RAP object, avoid committing changes in `save_modified`. Use asynchronous business events to decouple the update and handle the EML operation in a separate transaction. Alternatively, store the required changes in a staging table or buffer and process them later via a background job. This ensures transaction consistency and avoids runtime errors.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
52 | |
8 | |
5 | |
5 | |
5 | |
5 | |
5 | |
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.