Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
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
