ABAP Cloud

SAP décrit ABAP Cloud comme une méthodologie de développement constituée d'éléments qui existaient déjà dans la plateforme ABAP, réunis sous un même ensemble de règles :

• ABAP CDS pour les modèles de données et les requêtes analytiques.
• L'ABAP RESTful Application Programming Model (RAP) pour les business objects transactionnels et les services.
• ABAP for Cloud Development, une version restreinte du langage qui n'autorise qu'un sous-ensemble des instructions ABAP ; les écrans dynpro classiques, par exemple, n'en font pas partie.
• Les API et points d'extension SAP libérés comme seul moyen autorisé d'accéder au code et aux données SAP.
• ABAP Development Tools dans Eclipse comme IDE, avec les ABAP development tools pour Visual Studio Code comme option supplémentaire.

En complément, le modèle fournit des services réutilisables tels que les tranches de numéros, les application jobs et un référentiel d'interface pour les applications SAPUI5 et SAP Fiori elements. ABAP Cloud est donc un ensemble de règles pour utiliser l'ABAP moderne, et non un nouveau langage ni un runtime distinct.

L'environnement ABAP de SAP BTP est un service de plateforme pour le développement ABAP side-by-side ; il est souvent désigné par le nom de projet interne de SAP, Steampunk. Dans SAP S/4HANA, le même modèle s'exécute au sein de l'ERP, ce que le glossaire ABAP de SAP appelle embedded Steampunk. En Private Edition et on-premise, chaque objet de développement porte une version de langage, de sorte qu'une équipe peut créer de nouveaux objets avec ABAP Cloud tandis que le code plus ancien reste en ABAP classique.

ABAP Cloud est la seule option ABAP dans les produits de cloud public et l'option recommandée, aux côtés de l'ABAP classique, partout ailleurs.

ABAP Cloud transforme les règles du clean core en contrôles exécutés pendant l'écriture du code :

1. Chaque objet de développement possède une version de langage ABAP. Les objets en ABAP for Cloud Development sont contrôlés par le contrôle de syntaxe et à l'exécution.
2. Le contrôle de syntaxe n'accepte que les objets SAP libérés pour le développement cloud sous le contrat de libération C1, ainsi que les points d'extension libérés sous C0.
3. SAP vérifie ses propres objets libérés par rapport à leur contrat de libération, de sorte qu'aucune modification incompatible n'est attendue lors d'une mise à niveau.
4. En Private Edition et on-premise, lorsqu'une API libérée nécessaire fait défaut, les recommandations de SAP autorisent un wrapper écrit en ABAP classique, libéré par le client avec le contrat C1 et encadré par des contrôles ABAP Test Cockpit.

Chez Alder Manufacturing, une application de validation spécifique pour le référencement des fournisseurs, construite de cette manière, lit les données fournisseurs via des vues CDS libérées, et non via les tables SAP. ABAP Cloud fait de la stabilité aux mises à niveau une propriété du compilateur plutôt qu'une promesse de revue de code.

• Mises à niveau prévisibles. Le code qui compile sous ABAP Cloud ne dépend que d'objets libérés, ce qui réduit le travail de non-régression à chaque changement de release.
• Un seul modèle pour tous les déploiements. Les mêmes compétences et les mêmes patterns s'appliquent dans l'environnement ABAP de SAP BTP, en Public Edition et en Private Edition ou on-premise.
• Compétences ABAP existantes. Les équipes conservent ABAP, les transports et une gestion du cycle de vie familière au lieu de changer de langage.
• Proximité des données. Le code ABAP Cloud on-stack s'exécute à côté des données et des transactions SAP S/4HANA, avec une cohérence transactionnelle qu'une extension distante ne peut pas offrir.
• Chemin SAP Fiori intégré. Les services RAP alimentent directement les applications SAP Fiori elements.

Pour le code ABAP spécifique qui doit survivre aux changements de release, ABAP Cloud est le modèle de développement autour duquel sont conçus les outils, les contrôles et la documentation de SAP.

• Limité par les API libérées. Lorsque SAP n'a pas libéré un objet, le code ABAP Cloud ne peut pas l'utiliser. En Public Edition, le manque persiste jusqu'à ce que SAP libère une API ; ailleurs, il est comblé par des wrappers qui nécessitent un responsable.
• Les patterns hérités sont exclus. Les écrans dynpro classiques et les reports avec sortie SAP GUI ne font pas partie du modèle ; le code existant se porte donc rarement sans refonte.
• Courbe d'apprentissage. CDS, les behavior definitions RAP et les outils basés sur Eclipse sont nouveaux pour beaucoup de développeurs ABAP classiques.
• Pas un processus de gouvernance. ABAP Cloud garantit la manière dont le code dépend de SAP ; il ne décide pas de ce qu'il faut construire, de qui en est responsable ni de son lien avec un processus métier.

ABAP Cloud sécurise la dépendance technique ; le périmètre, la responsabilité et l'adéquation au processus restent des décisions distinctes.

1. Traiter ABAP Cloud comme un produit sous licence. C'est un modèle de développement ; les produits sont l'environnement ABAP de SAP BTP et SAP S/4HANA.
2. Mélanger les versions de langage sans plan. En Private Edition, décidez par composant logiciel quels objets doivent être en ABAP Cloud et imposez-le avec ABAP Test Cockpit.
3. Recourir au wrapper par défaut. Un wrapper C1 est une passerelle pour une API manquante ; cherchez d'abord une API libérée.
4. Choisir le mauvais emplacement. Utilisez ABAP Cloud on-stack lorsque la logique exige une cohérence transactionnelle avec les données SAP S/4HANA ; utilisez l'environnement ABAP de SAP BTP ou d'autres runtimes lorsque l'extension a besoin de son propre cycle de vie.

Le critère de décision est la dépendance : si la logique doit modifier des données SAP dans la même unité de travail, ABAP Cloud on-stack est généralement le bon emplacement.