Dokumentation zur VorgehensweiseEigene BAPIs implementieren Dieses Dokument in der Navigationsstruktur finden

 

SAP liefert eine große Zahl von BAPIs aus. Wenn Sie eigene BAPIs implementieren möchten, müssen Sie Ihren eigenen Namensraum verwenden.

Vorgehensweise

Sie haben folgende Alternativen:

  • Sie entwickeln ein eigenes BAPI im Kundennamensraum.

  • Sie modifizieren ein BAPI der Standardauslieferung:

    1. Kopieren und modifizieren Sie den zum originalen BAPI gehörenden Funktionsbaustein.

    2. Legen Sie im Business Object Repository zum Objekttyp Ihres BAPIs einen Sub-Objekttyp im Kundennamensraum an   Werkzeuge   Business Framework   BAPI-Entwicklung   Business Object Builder  .

      Beim Anlegen eines Sub-Objektyps werden die Methoden des Business-Objekts an den Subtyp vererbt.

    3. Setzen Sie den Status des Objekttyps auf Implementiert (  Bearbeiten   Freigabestatus ändern   Objekttyp  ).

    4. Sie können die Methoden des Subtyps ändern, löschen oder durch eigene Methoden ergänzen.

Hinweise für asynchrone BAPIs

Wenn Sie mit Ihrem BAPI einen asynchronen ALE-Geschäftsprozess implementieren möchten, müssen Sie aus dem BAPI eine BAPI-ALE-Schnittstelle pflegen.

Beim Implementieren eines BAPIs als asynchrone Schnittstelle sollten Sie neben den allgemeinen Richtlinen für die Programmierung von Methoden auch die folgenden Punkte beachten:

  • Im BAPI darf kein Commit-Work-Kommando abgesetzt werden.

  • Der Return-Parameter des BAPIs muss die Bezugsstruktur BAPIRET2 verwenden.

  • Alle Export-Parameter der Methode mit Ausnahme des Return-Parameters werden ignoriert und nicht in das generierte IDoc aufgenommen.

  • Statussätze protokollieren BAPI-Rückgabewerte

    Nach Aufruf des Funktionsbausteins, der im gerufenen System für die Umsetzung des IDocs in den entsprechenden BAPI-Aufruf zuständig ist, werden für das IDoc Statussätze geschrieben, in denen die vom Return-Parameter zurückgegebenen Meldungen protokolliert werden.

    Wenn in mindestens einem übergebenen Eintrag des Return-Parameters das Feld Type mit A (Abbruch) oder E (Fehler) gefüllt ist, hat dies folgende Auswirkungen:

    1. Type A:

      Es wird für alle Statussätze des IDocs der Status 51 (Fehler, Anwendungsbeleg nicht gebucht) geschrieben, nachdem ein ROLLBACK WORK durchgeführt wurde.

    2. Type E:

      Es wird für alle Statussätze des IDocs der Status 51 (Fehler, Anwendungsbeleg nicht gebucht) geschrieben und ein COMMIT WORK durchgeführt.

    Andernfalls wird der Status 53 (Anwendungsbeleg gebucht) geschrieben und ein COMMIT WORK durchgeführt.