BAPI

Une BAPI relie une définition orientée objet à une implémentation classique :

1. Dans le Business Object Repository, un type de business object tel qu'une commande d'achat déclare des méthodes comme create, change ou get detail. Chacune de ces méthodes d'API est une BAPI.
2. Derrière chaque méthode se trouve un module fonction appelable par RFC, de sorte que la BAPI peut être appelée au sein du système ou à distance via RFC.
3. L'appelant transmet des paramètres d'import et des tables ; la BAPI signale la réussite ou les erreurs dans un paramètre de retour typé avec la structure BAPIRET2, au lieu de lever des exceptions.
4. Les BAPI de modification suivent un modèle transactionnel dans lequel la BAPI elle-même n'effectue pas de commit. L'appelant décide quand enregistrer, en général en appelant BAPI_TRANSACTION_COMMIT après un ou plusieurs appels de BAPI, ou son équivalent de rollback après une erreur.

Le BAPI Explorer, lancé avec la transaction BAPI, parcourt les types de business objects et leurs BAPI par composant d'application et affiche les paramètres et la documentation. Une BAPI est donc un contrat de niveau métier posé sur un module fonction, le commit étant laissé à l'appelant.

Les BAPI sont antérieures à SAP Fiori et à OData, mais elles restent présentes dans de nombreux environnements :

• Les intégrations point à point et via middleware qui appellent SAP ERP ou SAP S/4HANA par RFC, par exemple pour créer des commandes clients depuis une boutique en ligne.
• Les programmes de migration de données et de traitement de masse qui comptabilisent des documents en passant par les mêmes contrôles que les transactions de dialogue.
• Les services OData construits sur des BAPI. En on-premise, les projets SAP Gateway associent souvent les opérations d'une entité à des BAPI existantes via l'import RFC/BOR du Service Builder, et SAP documente un modèle RAP qui appelle une BAPI au sein d'un business object RAP au travers d'une classe wrapper.

Chez Alder Manufacturing, un portail fournisseurs qui crée des commandes d'achat pour Cedar Office Supply peut encore comptabiliser via une BAPI de commande d'achat encapsulée dans une API plus récente. Les BAPI survivent souvent comme moteur sous une interface moderne plutôt que comme interface elle-même.

SAP classe les BAPI parmi les API classiques. Ce ne sont pas des API libérées au sens d'ABAP Cloud : le code écrit dans la version de langage ABAP for Cloud Development ne peut donc pas les appeler directement.

SAP publie une liste d'API classiques pour la Private Edition et renvoie les développeurs vers le BAPI Explorer pour les étudier. Le reporting clean core comptabilise les références aux API classiques répertoriées séparément des API libérées. Une BAPI est donc tolérée comme passerelle dans un environnement clean core, mais n'est pas considérée comme l'interface cible.

1. Oublier le commit. L'appel se termine sans erreur mais rien n'est enregistré, car l'appelant n'a jamais déclenché BAPI_TRANSACTION_COMMIT.
2. Ignorer la table de retour. Les BAPI signalent les erreurs sous forme de messages dans le paramètre de retour ; un programme qui ne vérifie que les exceptions ne comptabilise rien et signale une réussite.
3. Confondre les mentions « libéré ». Le BAPI Explorer affiche les BAPI libérées dans le Business Object Repository, ce qui n'est pas la même chose qu'une API libérée au titre d'un contrat de libération ABAP Cloud.
4. Encapsuler sans responsable. Un wrapper C1 autour d'une BAPI nécessite un responsable qui le remplace lorsque SAP libère une API qui lui succède.

La plupart des anomalies liées aux BAPI proviennent du modèle transactionnel et de la gestion des messages, et non de la logique métier contenue dans la BAPI.