Due to SAP’s release strategy and the strict rules for enhancing existing BAPIs, application developers can rely on the stability of BAPI interfaces.
Each enhancement to a released BAPI is downwardly compatible in terms of syntax and content. Downward compatibility means that applications that were programmed with BAPIs from a specific R/3 Release will not be affected in later R/3 Releases if the syntax or the content of this BAPI changes.
If it is necessary to make changes to an existing BAPI which cannot be made downwardly compatible by SAP, a new interface that is a new additional BAPI is created. This BAPI has the same name as the existing BAPI it is replacing, with a number as a suffix, for example: CustomerCode.GetDetail1().
The replaced BAPI is marked as expired (obsolete) in the correction release in which the new BAPI is introduced. It is supported in this correction release and in the next functional release.
Note 0107644 ‘Composite note for obsolete BAPIs after Release 4.5A’ identifies all the BAPIs in one R/3 Release which have been set to ‘obsolete’, or which were deleted from the BOR at the end of the expiry phase.
The graphic below illustrates the expiry phase of a BAPI. In this example the new BAPI is introduced into Release 4.0. The replaced BAPI is supported in Release 4.0 (the correction release in which the new BAPI was introduced) and in the next functional Release ‘F1’. The BAPI can then no longer be used in the following functional Release ‘F2’.
BAPI Expiry Phase
For further information on this subject, see Enhancing existing BAPIs in the BAPI Programming Guide.