ABAP RESTful Application Programming Model (RAP)

Une application RAP s'assemble à partir de niveaux, chacun étant un objet distinct du référentiel :

1. Modèle de données : des CDS view entities sur les tables de la base de données. Une entité racine et ses entités enfants, reliées par des compositions, forment le business object, par exemple une demande d'achat avec ses postes.
2. Behavior definition (BDEF) : déclare ce que le business object peut faire : création, mise à jour, suppression, actions, validations, déterminations, verrouillage, contrôle de concurrence et draft.
3. Behavior pool : une classe ABAP qui implémente les parties spécifiques déclarées par la behavior definition, comme une validation qui rejette les demandes au-delà d'un plafond.
4. Niveau de projection : des projection views et une projection behavior definition qui n'exposent que ce dont un service donné a besoin.
5. Service definition : liste les entités qu'un service expose.
6. Service binding : choisit le protocole (OData V2, OData V4 ou InA) et la catégorie, UI ou Web API, puis publie le service. Un aperçu affiche le résultat sous forme d'application SAP Fiori elements.

Chaque niveau a une seule fonction : c'est ainsi que RAP sépare modèle de données, comportement et exposition au sein d'un même business object ABAP.

Le type d'implémentation dans la behavior definition détermine qui écrit le code transactionnel :

• Managed : le framework RAP prend en charge les opérations standard de création, de mise à jour et de suppression, le buffer transactionnel et l'enregistrement dans les tables persistantes. Les développeurs n'ajoutent que la logique métier : validations, déterminations et actions.
• Unmanaged : les développeurs implémentent eux-mêmes chaque opération et la séquence d'enregistrement, en général en appelant du code applicatif existant qui gère déjà la persistance.

Une troisième variante existe pour le code plus ancien : les business objects construits avec le modèle précédent, l'ABAP Programming Model for SAP Fiori (BOPF), peuvent être migrés vers des business objects RAP basés sur BOPF. SAP précise qu'il ne s'agit pas de business objects RAP natifs et qu'ils ne sont pas activés pour ABAP Cloud.

Critère de décision : choisissez managed lorsque le business object possède ses propres tables, comme une nouvelle application spécifique chez Alder Manufacturing ; choisissez unmanaged lorsqu'une logique existante éprouvée doit être réutilisée plutôt que réécrite. RAP managed réduit le code ; RAP unmanaged protège les investissements existants.

RAP s'est enrichi release après release : la disponibilité dépend donc de la fonctionnalité, et pas seulement du modèle :

SAP S/4HANA Cloud Public Edition reçoit les fonctionnalités au rythme du cloud, et la Private Edition suit la release on-premise sur laquelle elle s'exécute. SAP ERP (ECC) n'inclut pas RAP : les releases d'ABAP Platform qui le contiennent, à partir de 7.53, ne sont livrées qu'avec SAP S/4HANA. Les tableaux de fonctionnalités RAP BDL de SAP indiquent la release de chaque élément du langage, et les vérifier pour la release cible est la première étape de toute conception RAP.

ABAP Cloud est le modèle de développement de SAP pour un ABAP prêt pour le cloud et stable lors des mises à niveau : uniquement des API libérées, une version de langage restreinte et des outils basés sur Eclipse. RAP est le modèle de programmation qu'ABAP Cloud utilise pour les applications et services transactionnels.

• Dans l'environnement ABAP de SAP BTP et dans l'extensibilité développeur de SAP S/4HANA Cloud Public Edition, RAP est la manière de construire des applications et des API transactionnelles.
• En Private Edition et on-premise, RAP peut être utilisé avec les règles ABAP Cloud, disponibles à partir de SAP S/4HANA 2022 (ABAP 7.57), ou en ABAP classique. Ce choix détermine les objets SAP que le code peut utiliser.
• Le strict mode dans une behavior definition impose les bonnes pratiques actuelles, comme l'utilisation de CDS view entities comme sources de données.

RAP n'est donc pas lié à SAP BTP : le même modèle s'exécute au sein de SAP S/4HANA. ABAP Cloud apporte les règles ; RAP fournit la structure.

Les points forts de RAP sont réels. Un même modèle va de la base de données jusqu'à l'interface SAP Fiori elements ; le verrouillage, le contrôle de concurrence et le draft sont fournis par le framework au lieu d'être codés à la main ; les services restent stables lors des mises à niveau lorsqu'ils reposent sur des API libérées ; et le même business object peut servir une interface et une API.

Ses limites découlent de l'endroit où il s'exécute :

• ABAP uniquement. RAP nécessite des compétences ABAP, ABAP Development Tools et un système ABAP ; les équipes qui n'en disposent pas font face à une réelle courbe d'apprentissage.
• Un seul système. Un business object RAP est transactionnel au sein d'un seul système ABAP. Les processus qui s'étendent sur plusieurs systèmes nécessitent une intégration ou des événements par-dessus.
• Lié à la release. Une fonctionnalité documentée pour le cloud peut n'arriver en on-premise qu'avec une release ultérieure.
• Flexibilité de l'interface via les annotations. Les applications générées avec SAP Fiori elements sont aussi flexibles que les floorplans et leurs points d'extension.

RAP est l'option la plus solide lorsque la logique et les données ont leur place dans le système ABAP ; il n'est pas conçu pour l'orchestration multisystème.

1. Exposer directement le niveau de base. Sans niveau de projection, chaque modification de service touche le business object principal.
2. Choisir unmanaged par habitude. Unmanaged a du sens lorsque de la logique existante est réutilisée ; pour de nouvelles tables, managed épargne l'essentiel du code.
3. Lier une application SAP Fiori à un service Web API. Les bindings Web API ne portent aucune métadonnée d'interface : l'application affiche alors des tableaux vides ou des mises en page par défaut. Utilisez un binding UI.
4. S'appuyer sur des vues CDS DDIC-based. Elles sont obsolètes, et le strict mode attend des view entities.
5. Ignorer les tableaux de fonctionnalités. Du code copié d'un tutoriel cloud peut ne pas s'activer sur une release on-premise plus ancienne.

La plupart des problèmes RAP sont des décisions de structuration en niveaux et de release prises trop tôt, et non des erreurs de codage.