Qu’est-ce que la programmation d’applications RESTful (RAP) ?
Le modèle de programmation d’applications RESTful ABAP, développé par SAP, repose entièrement sur le langage ABAP et suit le cadre REST (Representational State Transfer) pour créer des applications dans une architecture client-serveur avec une interface uniforme pour la manipulation des ressources.
L’objectif principal de RAP est de permettre aux développeurs de créer efficacement des applications d’entreprise prêtes pour le cloud qui gèrent différentes transactions commerciales sous la forme de services OData standard ou de créer des extensions pour des applications existantes sans modifier le code standard existant. Ils prennent en charge le développement de bout en bout, de la modélisation des données à l’exposition des services et à la compatibilité avec SAP Fiori UX.
RAP prend en charge le développement pour diverses plateformes SAP, notamment SAP BTP ABAP pour la création d’applications et d’extensions natives du cloud, ainsi que SAP S/4HANA Cloud (éditions publiques et privées), qui prend en charge les développements personnalisés compatibles avec les innovations continues et les cycles de mise à niveau du cloud. RAP est disponible pour SAP S/4HANA sur site depuis la version 1909, permettant aux clients de créer des applications utilisant des pratiques de développement modernes et de créer des applications pérennes.
RAP joue un rôle central dans le modèle de développement cloud ABAP pour les applications transactionnelles, en utilisant Core Data Services (CDS) pour définir les structures et les vues de données, en fournissant des mécanismes pour implémenter la logique d’entreprise et en assurant l’intégrité des données pendant les transactions.
Pourquoi apprendre la programmation d’applications RESTful ?
Évolution des exigences des applications d’entreprise
RAP n’est pas seulement un nouveau cadre de développement. C’est le modèle de programmation stratégique de SAP pour adopter le paradigme moderne dans la construction d’applications d’entreprise au sein de l’écosystème SAP.
Les applications d’entreprise modernes nécessitent des informations immédiates issues de leurs données opérationnelles pour éclairer la prise de décision. Par conséquent, les capacités analytiques sont intégrées aux applications transactionnelles afin d’obtenir des informations sans changer de contexte. RAP permet une intégration directe des données avec l’entraînement et l’analyse des modèles d’IA, réduisant ainsi le besoin de réplication et de traitement complexes des données.
RAP est optimisé pour la base de données SAP HANA, exploitant pleinement le potentiel de ses capacités de traitement en mémoire et exécutant des opérations telles que les jointures, les agrégations et les calculs complexes à des vitesses plus élevées, qui constituaient autrefois des goulots d’étranglement en termes de performances sur les bases de données traditionnelles.
SAP Fiori a introduit un nouveau langage de conception et un nouveau paradigme d’expérience utilisateur pour les applications SAP, caractérisés par la simplicité, la cohérence et l’accès basé sur les rôles. RAP permet aux développeurs d’exposer des objets d’entreprise sous forme de services OData, permettant une intégration transparente avec les éléments Fiori et une expérience cohérente sur différents appareils.
RAP est conçu en tenant compte des principes du cloud, et les applications sont intrinsèquement optimisées pour l’environnement SAP BTP ABAP, permettant à la fois l’extensibilité au sein de l’application et les extensions côte à côte. Cela le rend idéal pour les déploiements natifs du cloud et hybrides.
Attentes des utilisateurs finaux
Fiori UX utilise directement les services RAP OData, offrant une expérience utilisateur cohérente sur différents appareils tout en conservant le contexte. La conception sous-jacente de RAP favorise l’absence d’état, permettant aux sessions des utilisateurs d’être facilement reprises sur n’importe quel appareil où elles ont été laissées, sur l’appareil suivant.
Qualités du produit (prêt à l’emploi)
Les principes de programmation RAP permettent aux développeurs d’ajouter plusieurs qualités essentielles par défaut, sans nécessiter d’efforts après le développement :
- Évolutivité : L’architecture sans état de RAP et son interaction optimisée avec SAP HANA permettent intrinsèquement une grande évolutivité, permettant ainsi le déploiement distribué des applications et leur mise à l’échelle aisée dans les environnements cloud.
- Testabilité : RAP fournit des outils et des techniques intégrés pour tester la logique des applications et favoriser la séparation des couches logiques, rendant ainsi les tests unitaires et la définition des comportements maintenables.
- Extensibilité : RAP permet aux développeurs de créer des points d’extension bien définis dans leurs applications, permettant des modifications et l’ajout de nouvelles fonctionnalités sans nécessiter de modifications du code source.
- Capacité d’assistance : Les applications développées sont faciles à maintenir grâce à des capacités de diagnostic et de débogage détaillées après déploiement.
- Documentabilité : La nature déclarative de RAP, notamment ses définitions CDS et son modèle de programmation structurée, conduit intrinsèquement à une meilleure documentation.
Bases de RAP
Qu’est-ce qu’un objet d’entreprise ?
Dans RAP, un objet d’entreprise représente une entité ou un concept commercial du monde réel au sein d’un domaine d’activité, tel qu’une commande client, un client, un produit ou un employé. Il englobe toutes ses données, son comportement et ses relations. L’objet d’entreprise est l’unité de contrôle centrale pour une manipulation cohérente des données et une intégrité transactionnelle, définissant la structure des données, les règles régissant leur manipulation et le cycle de vie d’une entité commerciale.
Qu’est-ce qu’une requête ?
Une requête est l’interface en lecture seule qui permet d’accéder aux données à consommer et qui est construite sur les vues Core Data Services (CDS), principalement utilisées pour récupérer et afficher des données d’entreprise. Elles offrent une méthode structurée pour récupérer, filtrer, trier et agréger des données, servant souvent de source de données pour les tableaux de bord analytiques, les fonctionnalités de recherche ou les listes d’objets dans l’interface utilisateur.
Qu’est-ce qu’un service d’entreprise ?
Les services d’entreprise de RAP fournissent une interface externe pour accéder aux fonctionnalités des objets d’entreprise, en lecture et en écriture, qui sont accessibles via l’interface utilisateur de l’application Fiori pour les utilisateurs finaux ou les systèmes externes. Les services d’entreprise sont généralement exposés à l’aide d’une définition de service, qui décrit ce que le service fournit, et d’une liaison de service, qui spécifie comment il est exposé à l’aide d’un protocole particulier, tel que OData v2 ou v4, UI, Web API, etc.
Qu’est-ce qu’un événement d’entreprise ?
Dans RAP, un événement d’entreprise représente un déclencheur ou une notification définie signalant un changement ou une action importante survenant au sein d’un objet d’entreprise, ce qui peut déclencher d’autres événements dans des applications ou des services qui pourraient être liés. Par exemple, une « commande client créée » ou un « prix de produit modifié » est un événement d’entreprise qui peut être utilisé par d’autres applications ou flux de travail pour un traitement ultérieur. Les définitions d’événements et les liaisons d’événements sont définies et utilisées pour l’intégration asynchrone entre les services via SAP Event Mesh ou une logique personnalisée.
Modélisation des données
La modélisation des données dans RAP est réalisée à l’aide de Core Data Services (CDS), qui définit les entités, c’est-à-dire les structures de données, leurs associations, c’est-à-dire les relations avec d’autres entités, et les projections avec des vues personnalisées pour l’exposition. La modélisation des données est le point central pour définir la structure complète de l’application du point de vue du flux de données.
Langage ABAP
Le langage ABAP moderne sert de base à la mise en œuvre de la logique d’entreprise au sein de RAP, en tirant parti de ses fonctionnalités, notamment le langage de manipulation d’entités (EML), les annotations et les concepts orientés objet, ainsi que de ses vastes bibliothèques et de ses capacités de gestion des erreurs.
Outils
Le développement RAP est pris en charge par un ensemble différent d’outils, tels que l’éditeur CDS, les éditeurs de code source ABAP, les assistants ADT et l’éditeur de liaison de services, qui sont principalement intégrés aux outils de développement ABAP (ADT) dans l’IDE Eclipse (une plateforme de développement open source largement utilisée pour le développement de logiciels).
Extensibilité
RAP fournit des mécanismes d’extensibilité intégrés, permettant aux clients et aux partenaires d’améliorer ou d’adapter les objets et services d’entreprise standard sans modifier le code source principal. Fournit un mécanisme précis pour les deux types d’extensibilité : l’extensibilité intégrée, qui permet d’ajouter des champs personnalisés, une logique personnalisée ou des objets d’entreprise personnalisés directement dans les applications existantes, et l’extensibilité parallèle, qui implique la création d’applications ou de services distincts pour consommer et étendre les objets d’entreprise standard.
Architecture à 3 couches du modèle RAP
Le modèle RAP comporte trois couches fondamentales, chacune ayant un rôle spécifique, et fournit une approche structurée pour la création d’applications SAP Fiori de niveau entreprise et l’exposition d’API pour les interactions externes.
Modélisation des données et comportement
La modélisation des données et la définition des comportements constituent la couche fondamentale. Elles définissent les entités qui représentent les objets d’entreprise et les relations entre ces entités.
Les vues des services de données de base servent à définir des modèles de données réutilisables et à définir la structure des entités, y compris leurs attributs et associations, et à appliquer différents filtres et calculs, ainsi que des annotations pour fournir des métadonnées à l’utilisateur.
La définition du comportement est l’étape qui définit les actions possibles avec une structure de données, telles que les opérations de création, de mise à jour et de suppression.
Le modèle de données et les opérations disponibles sont définis dans la base de données. Néanmoins, la logique réelle d’exécution de ces opérations est implémentée dans des classes ABAP qui contiennent la logique d’entreprise pour la création, la mise à jour, la suppression et les opérations personnalisées effectuées sur les objets d’entreprise.
Service d’entreprise
La couche de services d’entreprise est chargée d’exposer la structure de données et le comportement définis dans la première couche sous forme de service consommable. La définition du service est rédigée de manière à spécifier quelles entités CDS et leur comportement seront exposés, contrôlant ainsi la portée du service.
La définition de la liaison de service est la deuxième étape qui spécifie le protocole à utiliser pour la communication avec le service, c’est-à-dire OData v2 ou OData v4.
Consommation de services
La consommation de services désigne la couche où les clients ou les applications utilisent les services exposés. Lorsqu’un service est destiné à une application SAP Fiori Elements, il est appelé service d’interface utilisateur et son but est de fournir des données et des métadonnées que Fiori Elements utilise pour afficher automatiquement les écrans, les tableaux et les formulaires.
Le service peut être exposé sous forme d’API Web pour être consommé par n’importe quel client OData, et ce type de service n’inclut pas de métadonnées spécifiques à l’interface utilisateur. Ces services sont idéaux pour l’intégration avec des systèmes non-SAP, des applications mobiles ou toute application personnalisée nécessitant une interaction avec des données et une logique d’entreprise.
Évolution des modèles de programmation ABAP
La programmation ABAP a évolué, passant d’un codage libre à un modèle de programmation d’applications RESTful, s’adaptant ainsi aux changements technologiques, aux évolutions architecturales et aux besoins de développement, en particulier après l’avènement de SAP Fiori et du développement cloud natif.
Programmation ABAP classique
Dans les modèles classiques, les développeurs écrivaient le code ABAP dans un style procédural et impératif, accédant directement aux bases de données et mélangeant la logique d’entreprise et la logique d’interface utilisateur, ce qui les rendait étroitement couplés et, par conséquent, plus complexes à maintenir.
L’interface utilisateur a été construite à l’aide d’outils tels que SAPscript, Smart Forms et la programmation de dialogues (Dynpro). Création d’écrans avec des éléments d’interface utilisateur et leur liaison avec la logique ABAP, les modules Traitement avant affichage (PBO) et Traitement après saisie (PAI). Dynpro était efficace pour les applications de bureau traditionnelles, mais manquait de capacités de conception réactive modernes.
Modèle de programmation ABAP pour SAP Fiori
Avec l’avènement de SAP Fiori, un nouveau modèle de programmation a émergé pour répondre aux besoins d’une expérience utilisateur moderne et réactive. Ce modèle se concentre sur la création manuelle d’OData avec l’outil SAP Gateway Service Builder (SEGW). Les développeurs définiront manuellement les entités, les propriétés et les associations, et implémenteront les opérations de création, de lecture, de mise à jour et de suppression (CRUD).
À l’aide du mécanisme OData.publish, les services OData ont été enregistrés et publiés pour être utilisés dans SAP Gateway, qui a servi de hub pour exposer et gérer les services OData.
Le service Core Data permettait aux développeurs de définir des modèles de données riches sur le plan sémantique pour la création d’entités, les associations et les calculs au niveau de la base de données. Le cadre de traitement des objets d’entreprise (BOPF) basé sur CDS a été conçu pour simplifier la mise en œuvre des logiques des objets d’entreprise telles que le comportement, les validations et les opérations CRUD.
Modèle de programmation d’applications RESTful ABAP
RAP est la dernière évolution, conçue pour des applications efficaces et prêtes pour le cloud pour SAP S/4HANA et SAP BTP.
Il centralise le concept de service d’entreprise, en encapsulant à la fois les aspects liés aux données et au comportement, tels que les entités et les comportements qui seront exposés pour Fiori ou une application externe, et sur quel protocole.
Le service Core Data reste central dans RAP, permettant la définition de modèles de données réutilisables et d’annotations pour générer automatiquement l’interface utilisateur des éléments Fiori.
RAP sépare la définition du comportement de son implémentation. Une spécification déclarative définit les opérations possibles, tandis que l’implémentation du comportement est l’endroit où réside le code ABAP pour implémenter la logique des comportements définis.
Étapes du processus de développement dans RAP
Le processus de développement des applications dans RAP commence par la définition de la structure de données sous-jacente avec ses relations, son comportement et ses métadonnées afin d’exposer le service qui peut être consommé par Fiori Elements ou une application externe.
1. Fournir les tableaux de la base de données
La première étape consiste à choisir les tableaux qui contiendront les données d’entreprise. Ces tableaux peuvent être des tableaux SAP standard existants ou des tableaux définis sur mesure. Ajoutez des explications sur l’intégration des données héritées et sur les modifications apportées aux tableaux, s’il s’agit de tableaux non basés sur CDS. La création de nouveaux tableaux, avec des attributs personnalisés spécifiques à l’application, est également un choix judicieux pour une implémentation propre et séparée.
2. Définir le modèle de données
L’étape suivante consiste à définir le modèle de données, en créant des vues CDS qui représentent les objets d’entreprise. Ces vues peuvent consister en un seul tableau, comme une simple vue CDS, ou joindre plusieurs tableaux pour créer des vues composites avec des définitions parent-enfant pour des objets d’entreprise complexes.
- Les objets d’entreprise simples représentent intégralement un produit ou un client, avec tous les attributs et comportements pertinents encapsulés dans une seule vue CDS.
- Les objets d’entreprise composites permettent de traiter des scénarios commerciaux complexes impliquant plusieurs entités commerciales, comme une commande client, qui peut ne pas constituer une entité unique et peut être liée à un en-tête et à des articles de commande client.
La relation parent-enfant définit l’association et la composition dans CDS, prend en charge le comportement transactionnel et assure la cohérence.
3. Définir et implémenter le comportement (applications transactionnelles uniquement)
Le modèle de données définit la structure de l’objet d’entreprise. En revanche, la définition et l’implémentation du comportement définissent comment il se comportera de manière transactionnelle, y compris les opérations prises en charge, telles que la création, la mise à jour et la suppression. Les opérations personnalisées sont implémentées ici avec des contrôles de validation avant l’enregistrement des données.
Le Behavior Pool, une classe ABAP globale, est utilisé pour l’implémentation du comportement, où le code ABAP réel est écrit.
Les principales caractéristiques des applications transactionnelles sont les suivantes :
- Activation de projet : Autoriser les utilisateurs finaux à enregistrer des données commerciales incomplètes en tant que brouillon, sans les valider, améliorant ainsi l’expérience utilisateur en leur permettant de mettre en pause et de reprendre leur travail ultérieurement.
- Numérotation automatique : Génération de clés uniques et séquentielles pour les entités nécessitant des identités uniques, telles que les numéros de commande.
- Validations : Il s’agit de contrôles de cohérence des données mis en œuvre pour vérifier que le format des données saisies et les valeurs attendues sont conformes à la logique d’entreprise, c’est-à-dire que les dates de livraison ne peuvent pas être antérieures à la date du jour et que les formats des numéros de téléphone sont corrects.
- Déterminations : Les champs qui sont calculés en fonction des données saisies dans d’autres champs, par exemple le nom complet qui est renseigné à partir du prénom et du nom de famille, ou lorsque le nom d’un produit est saisi, sa description et son prix sont automatiquement renseignés.
L’implémentation du comportement peut être négligée si l’application sert uniquement à afficher des données, comme un rapport de liste ou un rapport analytique, et ne nécessite pas d’opérations de modification.
4. Projetez l’objet d’entreprise RAP
Plutôt que d’exposer tous les champs de la vue CDS sous-jacente, des sous-ensembles de champs sélectionnés sont exposés avec des vues de projection CDS pour un service particulier. Les champs peuvent être renommés ou ajoutés. Des champs précalculés spécifiques à l’interface utilisateur et à la convention de nommage, tels que ZC_,
Similaire à un modèle de projection de données, la projection comportementale permet d’activer ou de désactiver des opérations spécifiques, telles que la création, la suppression et la mise à jour, au niveau du service. Par exemple, au lieu de supprimer l’opération de suppression au niveau du comportement CDS, ce comportement n’est pas exposé au niveau du service.
Des annotations spécifiques à l’interface utilisateur sont ajoutées à la vue de projection pour définir comment les données doivent être affichées dans l’interface utilisateur de Fiori Elements et contrôler des aspects tels que les étiquettes de champ, les capacités de recherche et les fonctionnalités analytiques.
5. Définir le service
La définition de service est un objet de référentiel qui référence une ou plusieurs vues de projection CDS et sert de conteneur pour les entités à exposer en tant que service.
La
6. Lier le service et tester le service
La dernière étape consiste à définir la liaison du service en décrivant les méthodes de consommation, c’est-à-dire l’interface utilisateur Fiori ou les applications externes, et le protocole, tel que OData v2 ou v4.
Pour les services d’interface utilisateur, les développeurs peuvent activer l’aperçu afin de générer automatiquement un aperçu des éléments Fiori, ce qui leur permet de tester rapidement les fonctionnalités sans avoir à créer l’application Fiori complète.
En règle générale, la convention de nommage ZUI_<service_Name>_04 est utilisée pour le service d’interface utilisateur du protocole OData v4.
Implémentation des objectifs d’entreprise
Il existe deux approches principales pour implémenter les types d’objets d’entreprise dans RAP :
- Gérés
- Non gérés
Les deux méthodes reposent sur des modèles de données définis par les entités de vue CDS. La différence réside dans la mise en œuvre du comportement transactionnel de l’objet d’entreprise.
Objectifs d’entreprise gérés
L’implémentation de types gérés est principalement utilisée lorsqu’une application est développée à partir de zéro, mais elle peut également tirer parti de la prise en charge prête à l’emploi du traitement transactionnel. Le cadre de référence fournit des validations et des déterminations standardisées.
Objectifs d’entreprise non gérés
Une approche non gérée est adoptée pour prendre le contrôle total de la logique transactionnelle, des opérations CRUD et de la persistance des données lors de la gestion d’une logique d’entreprise complexe et de l’interaction avec plusieurs systèmes. Les développeurs doivent implémenter les composants essentiels du contrat REST. Le comportement doit être spécifié dans la définition du comportement, mais implémenté manuellement dans les classes ABAP du pool de comportements.
Lorsque la logique d’entreprise est déjà encapsulée dans des modules fonctionnels, une approche non gérée aide les développeurs à réutiliser la logique d’entreprise existante dans les objets d’entreprise. Elle peut tirer profit d’une orchestration d’exécution RAP standardisée pour créer un service RAP.
Réutilisation des services et bibliothèques
ABAP RAP fournit un ensemble de fonctionnalités, d’API et de composants prédéfinis, conçus pour être utilisés dans plusieurs applications ou services. La réutilisation des services et bibliothèques existants permet aux développeurs de gagner du temps et de l’énergie sur des tâches telles que les contrôles d’autorisation standardisés, les déterminations de texte et le code redondant, ce qui leur permet de se concentrer sur la logique d’entreprise unique propre à l’application.
Les bibliothèques et services prédéfinis offrent des fonctionnalités génériques prêtes à l’emploi, applicables à divers domaines d’activité tels que la gestion des brouillons, le contrôle et la validation des champs, la gestion du traitement transactionnel, les utilitaires de date et d’heure, la gestion des étiquettes ETag pour le contrôle de la concurrence des données, la génération de journaux standardisés et le suivi des erreurs ou des événements.
RAP permet de créer une logique personnalisée spécifique au domaine pour ces services ou bibliothèques internes, et ces services personnalisés peuvent être réutilisés partout.
La possibilité de réutiliser des bibliothèques standard ou personnalisées permet aux développeurs de réduire le code standard. Cela accélère non seulement le processus de développement, mais améliore également la maintenabilité. La réutilisation des services et des bibliothèques est conçue pour s’intégrer dans les applications, permettant aux développeurs d’appeler des services externes ou d’invoquer des fonctions de bibliothèque directement à partir de leurs implémentations de comportement et de leurs vues de projection.
Foire aux questions
Le modèle de programmation RESTful ABAP est utilisé pour développer de nouvelles applications Fiori, créer des services OData afin d’exposer la logique d’entreprise, moderniser le code personnalisé existant lors de la mise à niveau vers S/4HANA et développer l’extensibilité sur S/4HANA.
Le modèle RAP est principalement utilisé pour développer des services OData qui exposent des données et des services au sein de l’écosystème SAP, permettant des opérations commerciales dans l’interface utilisateur SAP Fiori ou l’interaction avec des applications tierces. Ces services peuvent prendre la forme de services OData, d’API et de services analytiques offrant des fonctionnalités en lecture seule.
Un objet d’entreprise est un modèle de données logique représentant une opération ou une entité commerciale du monde réel, par exemple une commande, un nom de produit, un employé, et encapsule la structure des données, la logique d’entreprise, les validations et le comportement. Parallèlement, un service d’entreprise est une interface par laquelle les données et le comportement d’un objet d’entreprise sont mis à la disposition d’autres applications pour être consommés et utilisés dans le cadre de l’exécution des opérations d’entreprise.
