SAP Cloud Application Programming Model (CAP)

Une application CAP part de déclarations et n'ajoute du code que là où les comportements par défaut du framework ne suffisent pas :

1. Modèle de domaine : les entités, les types et les associations sont écrits dans des fichiers CDS, par exemple les fournisseurs et les créneaux de livraison d'une application logistique d'Alder Manufacturing.
2. Services : les définitions de services exposent des projections de ces entités, conçues pour une interface ou une API.
3. Runtime : le runtime Node.js ou le CAP Java SDK sert les services et traite de manière générique les opérations standard : lecture, écriture, pagination, tri et draft SAP Fiori.
4. Logique spécifique : des event handlers en JavaScript, TypeScript ou Java, enregistrés pour les phases before, on et after d'une requête, ajoutent des validations, des calculs et des appels à d'autres systèmes.
5. Persistance : le même modèle s'exécute sur SQLite ou H2 pendant le développement et sur SAP HANA Cloud ou PostgreSQL en production.
6. Déploiement : l'application est déployée sur SAP BTP, sur le runtime Cloud Foundry ou Kyma.

Les applications SAP Fiori elements consomment les services CAP au moyen d'annotations d'interface écrites dans les mêmes fichiers CDS. Une application CAP est donc avant tout un modèle, le code étant concentré là où la logique métier est spécifique.

Non. Tous deux sont issus du concept Core Data Services de SAP, utilisent une syntaxe déclarative similaire et portent des annotations, mais ce sont des implémentations distinctes :

• ABAP CDS fait partie de la plateforme ABAP. Ses vues sont des objets du référentiel activés comme vues de base de données au sein d'un système ABAP et transportés avec les transports ABAP.
• CAP CDS est le langage de modélisation de CAP. Son compilateur transforme les modèles en une représentation au format JSON appelée Core Schema Notation (CSN), à partir de laquelle CAP génère les artefacts de base de données et les métadonnées de service.

Les annotations illustrent la différence en pratique. Dans CAP, les annotations d'interface utilisent directement les noms de termes OData, tels que UI.LineItem ; dans ABAP CDS, des notations au niveau des éléments comme @UI.lineItem sont traduites dans ces termes lorsque le service est exposé. Un modèle ne peut pas passer de l'un à l'autre sans modification. CAP CDS et ABAP CDS partagent un nom et une philosophie, pas un environnement d'exécution.

Choisissez CAP lorsque :

• l'application a sa place à côté de SAP S/4HANA, et non à l'intérieur, comme extension side-by-side sur SAP BTP ;
• l'application possède ses propres données ou combine des données de plusieurs systèmes, SAP et non SAP ;
• l'équipe travaille en JavaScript, TypeScript ou Java plutôt qu'en ABAP ;
• l'application doit servir plusieurs clients sous forme d'offre SaaS multitenant, ce que CAP prend en charge grâce à l'isolation des tenants et à ses services MTX.

Préférez RAP lorsque la logique doit s'exécuter dans la même transaction que les données SAP S/4HANA, lorsque l'extension modifie un business object standard, ou lorsque l'équipe et le modèle d'exploitation reposent sur ABAP.

De nombreux environnements utilisent les deux : RAP pour la logique proche du cœur, CAP pour les applications qui l'entourent. La question décisive pour CAP est de savoir où se situent les données et la transaction.

Une application CAP ne s'exécute pas dans SAP S/4HANA ; elle accède donc aux données SAP via des API :

1. La définition d'API d'un service OData SAP S/4HANA, par exemple issue du SAP Business Accelerator Hub, est importée dans le projet CAP avec cds import, qui lit les fichiers OData EDMX, OpenAPI et AsyncAPI.
2. Pendant le développement, CAP peut simuler (mock) le service importé en local, ce qui permet aux équipes de travailler avant que la connexion n'existe.
3. En production, les appels passent par la connectivité SAP BTP : des destinations pour le système cible et, pour les systèmes on-premise, le Cloud Connector.
4. Les événements de SAP S/4HANA peuvent déclencher de la logique CAP de manière asynchrone lorsque le scénario le permet, en général via un service SAP de type event broker.

C'est l'API libérée, et non la table de la base de données, qui constitue le contrat entre CAP et SAP S/4HANA. L'extension reste ainsi découplée du cœur, ce qui est l'objectif de l'approche side-by-side que suit CAP.

Les points forts de CAP sont la rapidité et la cohérence. Les handlers génériques suppriment le code répétitif, le développement local fonctionne sans connexion cloud grâce aux mocks et à SQLite, la prise en charge de SAP Fiori et de SAP HANA est intégrée, et le multitenancy fait partie du framework au lieu de constituer un projet à part entière.

Les limites découlent de l'exécution en dehors du système de référence :

• Pas d'accès direct aux mécanismes internes de SAP S/4HANA. Tout passe par des API libérées ; les API manquantes deviennent des points de blocage ou nécessitent un complément côté ABAP.
• Pas de transaction partagée. Une mise à jour CAP et une comptabilisation SAP S/4HANA sont des transactions distinctes ; la gestion des échecs doit être conçue explicitement.
• Davantage à exploiter. Une application CAP ajoute à l'environnement un runtime SAP BTP, une base de données et de la connectivité, chacun avec sa supervision, ses mises à niveau et ses coûts.
• Framework prescriptif. Aller à l'encontre des conventions de CAP coûte plus cher que de les suivre.

CAP est le choix le plus solide pour les applications à côté du cœur ; il ne remplace pas la logique qui doit résider à l'intérieur.