Skip to Content
Product Information
Author's profile photo Marcel Hermanns

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.  


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. 


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 


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Stephan Heinberg
      Stephan Heinberg

      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.

      Author's profile photo Marcel Hermanns
      Marcel Hermanns
      Blog Post Author

      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 🙂


      Author's profile photo Benedikt Kromer
      Benedikt Kromer


      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.


      Can you provide a linkt to documentation for cl_abap_behavior_saver_failed?

      Author's profile photo Marcel Hermanns
      Marcel Hermanns
      Blog Post Author

      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 😉

      Author's profile photo Marcel Hermanns
      Marcel Hermanns
      Blog Post Author

      and the documentation link:

      Author's profile photo Marcel Wahl
      Marcel Wahl

      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

      Author's profile photo Manoj Mohanty
      Manoj Mohanty

      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?

      Author's profile photo Marcel Hermanns
      Marcel Hermanns
      Blog Post Author

      You are very welcome, Manoj :).

      For S/4HANA pubic cloud you can find the list of the released RAP-based BO interfaces here:

      Author's profile photo Manoj Mohanty
      Manoj Mohanty

      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?

      Author's profile photo Abhishek Sharma
      Abhishek Sharma

      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...






      Author's profile photo Theodorus van Wyk
      Theodorus van Wyk

      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?

      Author's profile photo Renzo Colle
      Renzo Colle

      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.

      Author's profile photo Theodorus van Wyk
      Theodorus van Wyk

      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.