Incompatible Enhancements  

Purpose

Changes to the contents or functionality of a BAPI often result in the introduction of new parameters without which the interface can no longer function. Often, these changes also cause existing parameters to lose their original meaning. Such modifications are considered to be incompatible enhancements, because they no longer enable the BAPI to be downward compatible.

Syntactically incompatible enhancements are:

The table below lists the incompatible changes to function modules. We cannot guarantee that this list is exhaustive.

Incompatible Changes to Function Modules

In interface

New mandatory parameter

 

Adding new fields between existing fields in the structure

 

Adding new fields between existing fields in the table

 

Adding new mandatory fields to the structure

 

Adding new mandatory fields to the table

 

Incompatible changes to field types (in the ABAP Dictionary)

 

Changing optional fields to mandatory fields

 

Renaming parameters

In program code

New additional source code that involves changes to the interpretation/processing logic

 

Changes to the existing source code that involve changing to the interpretation/processing logic

 

Adding or removing COMMIT WORK commands in the program

Process Flow

In cases of incompatible changes to a BAPI, you should work through the following three steps: Create an additional BAPI, Support and label the expiring BAPI and Delete the replaced BAPI.

Create an Additional BAPI

To ensure that the interface stability of an existing BAPI is not impaired, you must not make any incompatible changes to the existing BAPI. Instead, create one or, if necessary, several additional BAPIs to replace the existing one.

The new BAPI must retain the same name as the BAPI to be replaced. A numeric suffix is simply added to it. This suffix changes if further incompatible changes are made.

 

A number of incompatible changes must be made to the BAPI FixedAsset.Create(). To implement these changes, a new BAPI, FixedAsset.Create1(), is created, in order to maintain the interface integrity of the BAPI FixedAsset.Create().

If further incompatible modifications must be made to the BAPI at a later date, yet another BAPI, FixedAsset.Create2(), must be created.

When creating the additional BAPIs, you must follow the guidelines in the BAPI Programming Guide.

Support and Label the Expiring BAPI

After the BAPI has been superseded by a new BAPI, you should not remove the replaced BAPI from the Business Object Repository (BOR). Instead, you first label this BAPI as expired, and continue its support in the release in which you have introduced the new BAPI as well as in the next functional release. During this time the original BAPI must remain fully functional and executable.

The following tasks are required when a BAPI has expired (become obsolete):

The diagram below illustrates the expiry phase of BAPIs: In this example, the successor BAPI was implemented in Release 4.0. The replaced BAPI will therefore be supported in Release 4.0 (that is, in the correction release in which the successor BAPI was implemented) and in the next functional release, "F1". In the following functional release "F2", this BAPI will no longer be available.

BAPI Expiry Phase

Delete the Replaced BAPI

If the expiry phase of a BAPI set to obsolete has come to an end, you can remove the BAPI from the BOR. You should delete an obsolete BAPI as close to the beginning of a new release as possible, so that developers have time to adjust to its successor.

To delete a BAPI, follow the steps below: