Exploration de l'architecture du modèle de programmation d'applications ABAP RESTful

Dans cet article de blog, nous détaillerons les principaux concepts liés à l'architecture du modèle de programmation d'applications ABAP RESTful.

Cela comprend les composants techniques dans lesquels un RAP l'application est intégrée au moment de l'exécution.

Modèle de transaction

Le modèle de transaction RAP distingue deux phases dans le traitement des opérations sur les objets métier :

1. Pendant la phase d'interaction, les opérations sont effectuées sur une instance d'objet métier (par exemple, une position est créée ou modifiée). À la suite de ces opérations, les instances des entités CDS respectives sont stockées dans le tampon de transaction.
2. La suite séquence de sauvegarde est déclenché par une validation. L'état du tampon de transaction est écrit de manière persistante dans la base de données. L'état du tampon de transaction n'est pas conservé sur plusieurs requêtes, car cela violerait un principe REST clé. Les instances d'entité CDS qui sont stockées dans le tampon de transaction, qui ont été créées, modifiées ou supprimées (modification), peuvent être considérées comme une unité logique de travail (ULT) au sein du système SAP. Dans le cadre de la séquence de sauvegarde, le LUW est écrit de manière persistante dans la base de données au sein d'un LUW de base de données.

La gestion des projets dans le ABAP Le modèle de programmation d'application RESTful permet de stocker temporairement l'état du tampon de transaction avec des données d'application incohérentes de manière persistante dans la base de données. Cela vous permet de répartir la phase d'interaction sur plusieurs requêtes autonomes ou sessions utilisateur sans violer les principes REST de communication sans état. Les utilisateurs peuvent poursuivre leur travail ultérieurement, quel que soit le terminal. La fonctionnalité de gestion des brouillons est entièrement implémentée par l'environnement d'exécution RAP.

Fondamentalement, le modèle de programmation d'applications ABAP RESTful n'exclut pas la mise en œuvre d'une application avec état. Le modèle de transaction RAP inclut techniquement une zone (le tampon de transaction) où l'état de l'application peut être stocké côté serveur. Cependant, dans ce livre, nous nous concentrerons sur les applications basées sur REST.

Types d'implémentation

Le modèle de programmation d'application ABAP RESTful inclut le concept de type d'implémentation, que vous utilisez pour spécifier qui fournit l'implémentation de la fonctionnalité de lecture (requête) et de la fonctionnalité transactionnelle ou d'écriture (comportement). Il existe deux types d'implémentation : gérée et non gérée. Dans le cas géré, le modèle de programmation fournit la fonctionnalité souhaitée ; dans le cas non géré, l'application doit le faire elle-même.

La mise en œuvre technique de l'accès en lecture et en écriture ou le comportement d'un objet métier est géré par le fournisseur d'objets métier. Lors de la mise en œuvre de l'objet métier, nous distinguons l'utilisation de l' scénario géré et le scénario non géré:

Scénario géré

Dans le scénario géré, vous utilisez une implémentation prête à l'emploi de l'objet métier fourni par le modèle de programmation d'application ABAP RESTful, le fournisseur d'objets métier gérés. Il implémente les opérations CRUD standard de création (create), de lecture (read), de mise à jour (update) et de suppression (delete) des instances de l'entité CDS respective pendant la phase d'interaction et la séquence de sauvegarde. Ceci s'accompagne également de la gestion du tampon de transaction.

Lorsque vous utilisez le scénario géré, un objet métier déjà exécutable qui prend en charge les opérations CRUD est disponible sans aucun effort de programmation de votre part. Vous pouvez éventuellement ajouter davantage de logique à la séquence de sauvegarde (sauvegarde supplémentaire) ou implémentez-le vous-même (sauvegarde non gérée).

Scénario non géré

Dans le scénario non géré, vous pouvez implémenter vous-même les fonctionnalités standard d'un objet métier. Cela implique la phase d'interaction avec le tampon de transaction et la séquence de sauvegarde. Cela vous donne la possibilité d'intégrer l'API d'une application existante et de l'encapsuler avec des ressources RAP. Ce scénario est donc souvent utilisé pour développement de friches industrielles.

Outre les cas d'utilisation pouvant être implémentés par ces types d'implémentation, il existe toujours des exigences métier très spécifiques (par exemple, la validation d'une certaine constellation de données ou le calcul de certaines valeurs d'une instance d'objet métier). Dans ces cas, le fournisseur d'objet métier ne peut pas fournir d'implémentation. Cependant, dans les scénarios gérés et non gérés, vous pouvez implémenter vous-même la logique métier correspondante.

Les accès en lecture sont appelés requêtes dans le modèle de programmation d'application ABAP RESTful. Ils peuvent être implémentés sans comportement transactionnel ni accès en écriture associés. Une implémentation gérée de ce type d'accès en lecture est appelée requête gérée, et une implémentation non gérée est appelée une requête non gérée. Via la requête gérée, le modèle de programmation fournit les fonctions standard pour la lecture des données métier de la base de données sous-jacente. Cela inclut également, par exemple, des fonctions de tri, de filtrage ou d'agrégation des données lues. Si vous implémentez une requête non gérée, vous pouvez implémenter ces fonctions vous-même et ainsi avoir la possibilité d'inclure n'importe quelle source de données dans le modèle de programmation (par exemple, via un appel à distance d'API) ou de combler les différences entre le modèle de données de la source de données et celui de l'objet métier dans le modèle de programmation d'application ABAP RESTful.

Langage de manipulation d'entités

Le langage de manipulation d'entités (EML) est une API standardisée et sécurisée utilisée pour accéder aux données et aux fonctionnalités d'un objet métier. Elle fait partie intégrante du périmètre du langage ABAP. En utilisant EML, vous pouvez accéder aux instances d'un objet métier en mode écriture (via l'instruction ABAP MODIFY ENTITIES), mais vous pouvez également lire des instances individuelles à partir du tampon de transaction (via READ ENTITIES).

EML joue un rôle majeur dans la programmation d'applications ABAP RESTful Cas d'utilisation modèle dans les cas d'utilisation suivants :

• Implémentation du comportement d'un objet métier : Vous pouvez utiliser des instructions EML pour implémenter le comportement d'un objet métier dans ABAP. Dans ce cas, votre application assume le rôle de fournisseur d'objets métier.
• Effectuer des opérations sur un objet métier : Vous avez besoin d'instructions EML si vous programmez une application ABAP qui accède aux fonctionnalités d'un objet métier en tant que consommateur (c'est-à-dire qui assume le rôle de consommateur d'objet métier). Il est également possible d'utiliser EML dans le cadre de tests unitaires pour vérifier la fonctionnalité d'un objet métier dans votre application.

Lorsque vous utilisez EML dans le fournisseur d'objets métier, par exemple pour lire des données à des fins de validation, vous utilisez également EML dans le rôle de consommateur d'objets métier. Vous l'utilisez pour lire des données sur l'objet métier à partir du tampon de transaction afin de le valider, en contournant les contrôles d'autorisation, par exemple, parce que l'accès est EN MODE LOCAL. Vous consommez ainsi la fonctionnalité de lecture ou d'écriture de votre propre objet métier. Outre les opérations de lecture et d'écriture, vous pouvez également utiliser EML pour définir les limites de transaction (comportement COMMIT et ROLLBACK) et déclencher la séquence de sauvegarde.

Contexte technique des applications et environnement d'exécution

Dans la figure ci-dessous, vous pouvez voir le contexte technique dans lequel une application créée avec le modèle de programmation d'application ABAP RESTful est intégrée. Ici, vous aurez une idée des chemins et protocoles techniques qui peuvent être utilisés pour accéder aux données et aux services d'une application RAP. Une application RAP utilise le SAP HANA base de données pour conserver les données d'application. Les entités personnalisées CDS vous permettent de connecter un système externe ou une autre source de données via une communication synchrone à l'aide d'une requête programmée, spécifiquement en ABAP.