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
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 🙂
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.
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 😉
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?
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.
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 Marcel,
could you please clarify how and why BAPI, with or without RAP, is coupled with UX?
Customers need different data fields, structures and ux layouts, for their different business scenarios and configuration and extensibility help with that. Why is BAPI "to coarse granular" then? I assume not all fields are presented to end user?
BAPIs are a developed for one-shot-RFC calls. Input is defined, backend-logic is triggered, result is provided to the caller.
This is not the desired behaviour for end-user apps. Here you are in interaction with the backend. End user enters values,
the UI is adapted by applying *feature control* (if this field is entered, then the other one is disabled)
end-user *messages* are shown and the end-user can proceed entering data and solving issues
other *values are derived* by the backend logic and depending on other input field values
And all this is done while the end-user is in interaction with the system and typically exclusive locks are applied.
All this cannot be done by using one-shot-BAPIs for enterprise applications.
If you have a trivial scenario where only two fields have to be entered and need to be provided to the backend and it is sufficient to get the complete result in one step (e.g. leave request application), then a BAPI might be suitable - but not for transactional apps where you typically need feature control, locks, messages and derived values.
You can still use the BAPIs. There was a workaround mentioned on the RAP Round Table.
You call the BAPI creating the object and returning the internal number already in the adjust_numbers( ).
the blog explains very well how BAPIs can be integrated into RAP and how to still follow the RAP contract and especially the rules for transactional consistency.
What you probably may add to the BLOG are things to consider when using BAPIs internally (even independent of RAP) to avoid issues in the implementation or even rethink the BAPI usage. At least some things come to my mind:
BAPIs are intended for external and RFC-usage, so usually the interface already has "external" format by design like standard code lists (e.g. ISO Code for Currencies) or IDs (e.g. GTIN for products). At least if not also the internal representation is part of the signature, this requires to map input and output accordingly.
Special notice is needed for amount fields (data type CURR) that in the related ABAP data type is handled without fixed point (i.e. the decimal point is irrelevant) and the number of decimals is derived from the referenced currency code. In BAPI signatures this is obviously exposed properly with the correct number of decimal places (e.g. domain BAPICUREXT that has data type DEC and not CURR). Here interpreting the value properly is essential and there are related mapping function modules in function group BFCR. As a consequence using a BAPI leads to mapping the amount from internal to external and back from external to internal to use it properly.
All this cannot be done by using one-shot-BAPIs for enterprise applications.
using one-shot BAPI not, but can relevant ABAP logic be exposed by additional RFCs, to provide feature control, locks, messages and derived values for the application?
We are on S/4HANA FOUNDATION 2022 02 (05/2023). I can see the failed as a changing parameter in the SAVE method in CL_ABAP_BEHAVIOR_SAVER. However, when I try to use it in the impl. class, I get an error saying "failed is unknown. Any ideas why this might happen?
PS: It is working with CL_ABAP_BEHAVIOR_SAVER_FAILED. Aplogies. Thank you.
Many thanks for your guidance. I am facing a problem with BAPI call during SAVE_MODIFIED execution (scenario is managed, with unmanaged save and unmanaged lock): as lock is created during draft creation, and works fine, it causes failure during BAPI execution, as entity is locked (by the same user). Is there any way to overcome this? Some method to remove lock at SAVE_MODIFIED beginning?
Many thanks in advance!
Maciej
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
