API libérées et SAP Business Accelerator Hub

Un objet est libéré lorsque son statut de libération est Released au titre d'un contrat de libération précis, qui définit l'usage autorisé et les modifications que SAP s'engage à éviter :

Un objet Deprecated fonctionne toujours mais doit être remplacé par son successeur ; un objet Decommissioned n'est plus pris en charge, un statut que SAP n'applique actuellement qu'aux API distantes. Pour les objets C0 et C1, un paramètre de visibilité détermine si les développeurs ABAP Cloud, les key users ou les deux peuvent utiliser l'objet.

Une API libérée est donc un engagement portant sur un objet et un usage, et non une étiquette générale pour tout ce qui possède une interface.

Le SAP Business Accelerator Hub, anciennement SAP API Business Hub, est une application web hébergée par SAP. Il répertorie les API de SAP et de ses partenaires (OData, SOAP, REST), les business events, les vues CDS, les data products, les flux d'intégration et les process blueprints.

Pour chaque API, le hub affiche la spécification, la documentation et, pour de nombreuses API, une sandbox permettant d'essayer des appels avant de connecter le moindre système. Un développeur d'Alder Manufacturing qui doit créer des factures fournisseurs depuis un portail externe commence ici : trouver l'API, lire son statut et son successeur, la tester dans la sandbox, puis télécharger la spécification.

Deux limites comptent. Le hub documente les API standard de SAP, et non les API propres à un client, et les API sont répertoriées par produit : une API répertoriée pour une édition n'est donc pas automatiquement disponible dans une autre. Le SAP Business Accelerator Hub est le point de départ de la conception d'API distantes, et non la preuve qu'une API existe dans un système donné.

Les API libérées se répartissent en deux groupes pratiques :

• API locales (contrat C1). Vues CDS, classes, behavior definitions et autres objets libérés, utilisés par le code ABAP spécifique dans le même système. Le code ABAP Cloud ne peut appeler que celles-ci. Les développeurs les trouvent dans ABAP Development Tools, où l'onglet API State affiche le statut et le contrat de libération, ainsi que dans la section extensibilité développeur du Business Accelerator Hub.
• API distantes (contrat C2). Services OData, SOAP et autres, appelés via le réseau par des applications SAP BTP, un middleware ou des systèmes tiers. Elles sont documentées sur le Business Accelerator Hub.

Lorsque SAP remplace une API, l'ancienne est dépréciée et un successeur est désigné ; SAP a par exemple déprécié l'API OData Production Order dans SAP S/4HANA Cloud 2008.

Cette distinction détermine l'architecture : les API locales servent les extensions on-stack construites avec ABAP Cloud, tandis que les API distantes servent les extensions side-by-side et les intégrations.

• SAP S/4HANA Cloud Public Edition : les API libérées sont le seul point d'accès. Le code ABAP spécifique n'utilise que des API locales libérées, et les API distantes sont exposées via des communication scenarios qu'un administrateur active avec un communication arrangement.
• Private Edition et on-premise : les API libérées coexistent avec des interfaces classiques telles que les BAPI. Les API OData distantes s'activent comme les autres services OData sur SAP Gateway, par exemple avec /IWFND/MAINT_SERVICE pour OData V2. Lorsqu'aucune API libérée n'existe, les recommandations de SAP autorisent des wrappers spécifiques autour d'API classiques répertoriées, libérés avec le contrat C1.
• Environnement ABAP de SAP BTP : les mêmes contrats de libération s'appliquent, et les objets spécifiques utilisés entre software components sont soit libérés, soit reliés via des relations entre software components.

Les clients ne peuvent libérer leurs propres objets qu'avec les contrats C0 et C1. Le concept d'API libérée est identique dans toutes les éditions ; ce qui diffère, c'est la part d'accès non libéré que chaque édition tolère encore.

• Stabilité lors des mises à niveau garantie par contrat. SAP contrôle les objets livrés au regard de leur contrat de libération : aucune modification incompatible d'une API libérée n'est donc attendue lors d'une mise à niveau.
• Une obligation, pas seulement un conseil. En ABAP Cloud, le compilateur rejette les appels à des objets non libérés pour le développement cloud, ce qui transforme la règle clean core en contrôle de syntaxe.
• Un vocabulaire unique. Les mêmes statuts et contrats s'appliquent dans toutes les éditions de SAP S/4HANA et dans l'environnement ABAP de SAP BTP.
• Des changements planifiés. La dépréciation avec un successeur désigné offre aux équipes un chemin de migration au lieu d'une interface cassée.

Les API libérées constituent la règle de dépendance sur laquelle repose le niveau A de la classification clean core.

• La couverture est inégale. Tous les business objects ou champs ne disposent pas d'une API libérée. Une plainte fréquente dans les communautés de praticiens est de ne trouver l'opération nécessaire que dans une BAPI classique ou une table interne.
• Un contrat n'est pas une conception. Une API libérée garantit la stabilité technique, et non l'adéquation de sa granularité à un processus ; plusieurs appels peuvent être nécessaires pour une seule étape métier.
• Le comportement peut encore changer. Les règles de contrat de SAP autorisent des modifications compatibles des API libérées et ne promettent pas une compatibilité descendante totale : les consommateurs doivent donc refaire leurs tests après les mises à niveau.
• La dépréciation est facile à ignorer. Les API dépréciées continuent de fonctionner pendant un temps, si bien que le passage au successeur a tendance à être repoussé.

Les API libérées suppriment le risque de mise à niveau au niveau de l'interface ; l'adéquation au processus et le cycle de vie de chaque consommateur restent de la responsabilité de l'équipe.

1. Considérer tout service OData comme une API. Un service OData généré pour une application SAP Fiori est un service d'interface. Vérifiez le statut de libération avant qu'une intégration n'en dépende.
2. Concevoir à partir du hub seul. Confirmez que l'API existe et qu'elle est activée dans le système et la release cibles.
3. Ignorer les avis de dépréciation. Suivez les successeurs de chaque API utilisée.
4. Tout encapsuler. Les wrappers C1 spécifiques autour d'API classiques comblent des manques ; chacun nécessite un responsable et une revue lorsque SAP libère un successeur.

Le critère de décision pratique est simple : si l'objet n'a pas de statut de libération pour l'usage prévu, traitez toute dépendance envers lui comme une dette technique et consignez-la.