Hello Community,
We're currently building a solution based on RAP unmanaged (OData V4 & on-premise 2023 FPS3) + OData V4 + Fiori Elements List Reports with multiple view entityset (for SAP BUILD Workzone) — around 10 tiles depending on user profiles.
With the goal of being cloud compliant (that's why we exluded SEGW).
Our backend scenario doesn’t follow a typical RAP-unmanaged BO:
We don’t have a persistent Z-table representing the main BO. Instead, we expose a merged view of:
- Sales Orders,
- Purchase Orders,
- A custom Z-table that manages additional status, dates on them. And is updated both by UI and interfaces (IDocs, API, etc.).
Each List Report is tied to a projection CDS/behavior with specific actions available (from main behavior): Approve, Reject, Confirm, etc.
Some complex Actions must be executed synchronously to orchestrate multiple steps, (committing or rollback ourselves depending rules between step) and return structured information (e.g., results & messages) to the UI. The frontend expects instant feedback and reacts to message type (S, W, E...) to guide the user. Example sequences :
- Update standard document via BAPI PO/SO
(No use of standard RAP due to doc type not herited from NBF and some fields not managed by current RAP), - Update Ztable via EML (RAP),
- Trigger external APIs.
🚫 Problem with RAP standard actions
We initially built RAP actions (with deep parameter) that return a complex response (deep result), for manage specifically result & messages in Fiori side. However, we quickly hit one RAP limitation :
- You cannot commit or rollback inside an action.
As it breaks RAP’s design principles (LUW control, Clean Core).
So we tried using cl_abap_parallel (released class) or even function modules with DESTINATION 'NONE', which technically allowed us to run parts of the logic in a separate LUW and return structured results synchronously.
And see some others Posts using these kind of workaround solution.
👌 This completely solved our issues at runtime — enabling orchestration, feedback, and proper error control.
However, after discussing with SAP, we were clearly told this is not a long-term solution.
Such techniques are discouraged as they break the RAP LUW model and violate Clean Core principles.
💡 SAP suggested:
Firstly :
"Trigger this logic in SAVE sequence via BGPF"
We did a full POC of this model and found several issues for our case:
- No possibility to simulate during MODIFY runtime (action) before SAVE (to manage deep result at this time)
You can't do a commit entity in simulation mode to know validation problems etc on our ztable rap. And some BAPI like SO can't be executed in simulation mode (due to authority-check triggered that can't be deactivate like PO BAPI) - COMMIT ENTITY (of another BO!) inside BGPF crashes
- The user doesn’t get immediate feedback in UI
- Save have only Reported return. Instead of action that can manage a deep result
- We’d have to rework the entire UX logic (tracking status of BGPF per order to lock user action, error reprocess design, etc.)
- Event RAP Side effects are not available in our current release (2023 FPS03. Available in 2025).
From an API-only scenario, Side effects is not an option
Secondly :
Falling back to OData V2 SEGW (only for the action) and use Function Import POST — which gives us exactly what we need: a self-contained synchronous LUW with a structured response!
But as you know, SEGW is not released, so we aren't totally cloud compliante.
Today, this is the solution implemented. It kind of takes the soul out of our RAP implementation, which is frustrating 😅
👨🔬 Question to the community
We’ve created a SAP Influence post to support this request → https://influence.sap.com/sap/ino/#/idea/351633/?section=sectionDetails
Have a nice day.
Clément
Bluesky
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.