Product Information
Using BAPIs in RAP
Business Application Programming Interfaces (BAPIs) are well-defined APIs exposing data and functionality for remote process integration. This article describes the nature of a BAPI according to the SAP LUW and how it can be integrated into RAP.
What is the nature of a BAPI?
Purpose of POST BAPIs
BAPIs that perform transactional changes (POST) are designed as “one-shot” requests via RFC. The request is either successful or it fails and the call returns success or fail messages. That means one POST API call contains the validation of the input data and the update task.
POST BAPIs in UI scenarios
In UI scenarios, the end-user relevant messages must be returned _before_ the update task is registered. Otherwise, the end-user has no option to correct the issue and every issue leads to a termination of the SAP LUW. Why? Because if the end-user shall correct the issue, then the data to be persisted needs to be changed. An already registered update task can only be invalidated by a ROLLBACK, which destroys the current SAP LUW.
VALIDATE BAPIs
To overcome this, many BAPIs have also a VALIDATE flavor. If VALIDATE returns an end-user error message, the flow can go back to the end-user and he or she might be able to correct this issue. If everything is correct, then the POST can be triggered, and everything goes well. This works then for both – “one-shot” execution and UI scenarios – based on the same implementation.
To sum it up: if a BAPI has a VALIDATE and POST flavor, then it can be used in UI scenarios. If only a POST flavor is available, then it cannot be used in UI scenarios. This is a general consequence and independent of RAP so far.
BAPIs and RAP
Using BAPIs in RAP is possible, but not everywhere since we want to fulfill the SAP LUW rules in the RAP transaction model.
How it works
In RAP we assume that in most cases POST BAPIs have also a VALIDATE flavor. It is then quite easy to integrate VALIDATE in checkBeforeSave and the POST in saveModified in an unmanaged BO. Even in managed this can be done with a save validation and the “unmanaged save” (at the end of the article you find a link with more information about when to use managed and unmanaged).
How it does not work
RAP and its transaction model aim to fulfill the SAP LUW rules. That also means, that the update task can only be called at the end of the SAP LUW. Therefore, RAP does not allow to call the update task earlier. Hence, all BAPIs using the update task cannot be used outside of the late save phase (there is a link at the end of the article with more details about RAP and the SAP LUW).
What if there is no VALIDATE flavor of the POST BAPI
Starting with S/4HANA 2022 oP, REPORTED and FAILED can also be filled in the late save, by using the save handler cl_abap_behavior_saver_failed. This class is not released of ABAP cloud development. Also with RAP the current SAP LUW needs to be rolled back in case of errors at this late point in time.
Further informtion
Examples from SAP
Posting of journal entries was delivered with SAP S/4HANA 2022 and S/4HANA public cloud 2208: BAPI_ACC_DOCUMENT_POST is integrated into the save sequence of the RAP BO R_JournalEntryTP. This journal entry post-processing is not required to be exposed to the end-user UI and therefore, no CRUD support is available. The VALIDATE (BAPI_ACC_DOCUMENT_CHECK) is available and exposed as action “validate”.
The business partner was re-implemented via RAP and the update task function module, lock object, authorization object and other details were reused. The implementation type “managed” was correctly chosen. The BusinessPartner is of course UI relevant and offers also CRUD support and draft functionality.
Links
You can find more details about when to apply managed and when unmanaged here: modernization with rap.
You can find more details about RAP and the SAP LUW
- Renzo Colle‘s blog: the sap luw in abap cloud
- or the second part of the video: https://www.youtube.com/watch?v=ByGpsa7W7Yw
Thanks, Marcel, for the clarification!
In terms of RAP BO R_JournalEntryTP: If there is a CHECK & POST BAPI, why was not a RAP BO with complete CRUD implementation for UI support created? A check within an action sound as a second-best solution.
Hi Stephan, thanks for this excellent question :).
I am not a FIN expert :). But as far as I know: posting journal entries is typically done by other applications. The other (primary) applications can have end-user interaction and store their data. Based on this data the posting is triggered - but only at the end of the LUW (RAP: save). The action and the corresponding save implementation reflect this use case. The primary application can make sure, that the "finalize action" registers the POST for later execution and ensure that no error is to be handled before. Later, when in the late save the data of the primary BO and the posting data are stored together.
If the application developers would decide to provide a BO with "CRUD" functionality and UI then of course the validation needs also to be done earlier. But here the BAPI might not really help, because it is to coarse granular to provide good UX for the end user. This would require to split the big chunk into smaller pieces - in order to provide good and reasonable UX - with and without RAP 🙂
Hi,
great blog, two questions.
Is there also some information/update about numbering & BAPI?
As most BAPIs draw internally a number, if everything checks out - and we can't map a new number with early numbering after save (at least in 2021) & SD has no GUID's.
We didn't manage to use RAP for Sales Dokuments.
BAPI_SALESORDER_CREATEFROMDAT2, BAPI_QUOTATION_CREATEFROMDATA2
Can you provide a linkt to documentation for cl_abap_behavior_saver_failed?
Hi Benedikt, thanks for the questions.
Regarding late numbering: If late numbering is relevant, then the BAPI must also include this aspect. In this case, calling the BAPI is still only reasonable in late save. But the actual save is too late, the number must be returned in adjustNumbers. Otherwise the UI flow does not work (RAP needs to exchange PID by final number and the final number must be returned to UI for later calls) and other BOs do not have a chance to convert the PID to final number for their own reference (e.g. foreign keys). The mitigation is to call the complete BAPI in adjustNumbers. Not nice, but everything else is worse 😉
and the documentation link: https://help.sap.com/doc/abapdocu_latest_index_htm/latest/en-US/index.htm?file=abenabp_cl_abap_beh_saver_failed.htm
Hi Marcel.
This also solved our problems creating OData V4 WebAPIs using RAP facades for BAPIs.
It was just super hard to find.
Thanks a lot
Thanks for the detailed explanation of the usage of BAPI, Marcel!
Are there any ways that we can view the list of RAP BOs released for S4?
You are very welcome, Manoj :).
For S/4HANA pubic cloud you can find the list of the released RAP-based BO interfaces here: https://api.sap.com/products/SAPS4HANACloud/developerextensibility/bointerface
Thanks for this info.
I see, "Develpoer Extensiblity" tab is only available for SAP S/4HANA Cloud in API BH. But not for the On-Prem version. Is it not released?
Hi Marcel Hermanns
Thanks for the blog post on BAPIs...
I am facing issue while calling Standard FM. I have posted my question at below location... Please help...
https://answers.sap.com/questions/13821735/behavior-illegal-statement-in-abap-rap.html
Thanks-
Abhishek
Great blog Marcel.
What if a BAPI has a CALL DIALOG statement in it? Will some of these legacy BAPI's that don't conform to RAP get new versions? Or will new SAP Standard RAP BO's get created for business objects that currently get created or edited with older non-compliant BAPI's?
Hi Theodorus,
thanks for this question. Most BAPIs should be hopefully compliant to at least use within the RAP save phase as described in this blog and not do any commits or dynpro stuff. Definitely there are also such BAPis and as a consequence these cannot be used with the described approach.
If no native RAP behavior definition is in place so far or another usable API this would need to be requested, best via SAP Customer Influence (SAP Innovation Management). The prioritization to provide RAP behavior definitions in S/4HANA is not driven by the availability or state of existing BAPIs, but on the need for features and functions and requirements of customers.
Thanks for the prompt response, Renzo, understood, I don't imagine the turnaround time for this is very speedy and would not be provided within the timeframes of a projects SDLC. So, an interim solution would have to be a Tier 2/3 extension that is created using the older ABAP Programming Model for Fiori (@Odata.publish: true), until such time as a standard RAP BO/usable API is provided by SAP. Usure if a service that uses the ABAP Programming Model for Fiori is considered a tier 2 or tier 3 extension as it uses BOPF. Probably Tier 3.