Inhaltliche Änderungen an einem BAPI bedingen zumeist die Einführung neuer Parameter, ohne die die Schnittstelle nicht mehr funktionieren würde. Oftmals verlieren auch existierende Parameter durch inhaltliche Änderungen ihre ursprüngliche Bedeutung. Derartige Änderungen zählen als inkompatible Weiterentwicklungen, durch die eine Abwärtskompatibilität des BAPIs nicht mehr gewährleistet ist.

Syntaktisch inkompatible Weiterentwicklungen sind beispielsweise:

• Änderungen der Feldlänge

• Änderung des Feldtyps

• Umbenennen eines Parameters im Funktionsbaustein oder an der Methode

• Hinzufügen von Feldern inmitten einer Struktur

• Löschen von Parametern oder Feldern

• Hinzufügen neuer obligatorischer Parameter oder Felder
  Im BOR können Parameter als obligatorisch gekennzeichnet werden. Dies ist jedoch für Felder nicht möglich, d.h. Felder können nicht auf technischer, sondern nur auf semantischer Ebene als obligatorisch kategorisiert werden. Deshalb muß in der Dokumentation zu jedem Parameter angegeben werden, welche Felder zu füllen sind.

Folgende Tabelle gibt eine Auflistung von inkompatiblen Änderungen im Funktionsbaustein. Die Vollständigkeit dieser Liste ist nicht garantiert.

Bei inkompatiblen Änderungen an einem BAPI sind die drei Schritte Anlegen eines zusätzlichen BAPIs,Unterstützung und Kennzeichnung des zu ersetzenden BAPIs und Löschen des ersetzten BAPIs zu durchlaufen.

Um die Schnittstellenstabilität eines existierenden BAPIs nicht zu beeinträchtigen, dürfen inkompatible Änderungen nicht an dem existierenden BAPI vorgenommen werden. Stattdessen sind zu diesem BAPI ein - oder bei Bedarf mehrere - zusätzliche BAPIs hinzuzufügen, die das existierende BAPI ersetzen sollen.

Das neue BAPI muß den Namen des zu ersetzenden BAPIs beibehalten, erhält jedoch als Suffix eine Zahl. Diese Zahl kann dann, wenn nötig, bei weiteren inkompatiblen Änderungen hochgezählt werden.

Das zu ersetzende BAPI darf nicht sofort aus dem Business Object Repository (BOR) entfernt werden, sondern es muß zunächst als auslaufend (obsolet) gekennzeichnet werden. Dieses BAPI muß im Änderungsrelease (d.h. in dem Release, in dem das Nachfolge-BAPI eingeführt wird) und in dem darauffolgenden funktionalen Release weiter unterstützt werden und während dieser Zeit in seiner Funktion erhalten und lauffähig bleiben.

Die Kennzeichnung des BAPIs als auslaufend (obsolet) erfolgt folgendermaßen:

• Dokumentieren Sie im BOR die entsprechende alternative Methode bzw. Methoden, die das auslaufende BAPI ersetzen.

• Dokumentieren Sie im Online Service System (OSS) im Hinweis 0107644 "Sammelhinweis für obsolete BAPIs ab Release 4.5A" die BAPIs, die in einem R/3-Release auf "obsolet" gesetzt wurden.

• Unterrichten Sie Ihre Benutzer anhand von Release Notes über die entsprechenden Nachfolge-BAPIs.

Folgende Abbildung beschreibt die Auslaufphase eines BAPIs. In diesem Beispiel wird das Nachfolge-BAPI im Release 4.0 eingeführt. Das zu ersetzende BAPI wird folglich im Release 4.0 (d.h. im Änderungsrelease, in dem das Nachfolge-BAPI eingeführt wurde) und in dem nächsten funktionalen Release "F1" unterstützt. Erst im darauffolgenden funktionalen Release "F2" steht dieses BAPI nicht mehr zur Verfügung.

Ist die Auslaufphase eines auf obsolet gesetzten BAPIs beendet, kann das ersetzte BAPI aus dem BOR entfernt werden. Ein obsoletes BAPI sollte möglichst zu Beginn eines neuen Releases gelöscht werden, um Entwicklern möglichst viel Zeit für die Umstellung auf das Nachfolge-BAPI zu geben.

Um ein BAPI zu löschen, ist wie folgt vorzugehen:

• Löschen Sie den Funktionsbaustein, der das BAPI implementiert
  Geben Sie hierzu im Function Builder den Namen des Funktionsbausteins im Feld Funktionsbaustein ein und wählen Sie anschließend Funktionsbaustein ® Weitere Funkt. ® Löschen.

• Dokumentieren Sie im SAPNet - R/3 Frontend im Hinweis 0107644 "Sammelhinweis für obsolete BAPIs ab Release 4.5A", in welchem Release das BAPI aus dem BOR gelöscht wurde.