Étendre une API via BTP, ABAP environment – PARTIE I

Traitement en cours…
Terminé ! Vous figurez dans la liste.

Prérequis : Maitrise du Framework ABAP RESTful Application Programming Model.

Dans notre précédent article, nous avions créé un objet RAP en utilisant une API externe.

Pour rappel, nous utilisons l’entité PRODUCT mis a disposition par Northwind. Dans notre cas, nous pouvons récupérer les produits présents dans l’API Northwind en effectuant un GET. Notre objet RAP nous permet d’afficher les produits disponibles dans l’API Northwind au sein d’une application Fiori.

Nous allons désormais étendre cette API.

Pour cela nous allons :

  1. Ajouter un champs « Commentaire » au sein de l’objet RAP qu’il sera possible de modifier
  2. Créer une entité fille « Commandes » qui représentera les commandes associées a ces produits ( Partie II )

Tout le code contenant la Partie I et la Partie II est disponible sur notre GitLab.

L’ensemble des données issues de ces extensions seront sauvegardées au sein de BTP, ABAP Environment. Cela veut dire que les commentaires créés par les utilisateurs seront sauvegardes au sein de notre environnement, ainsi que les commandes. Lors de l’appel a l’API pour retrouver les produits, il y aura également une recherche au sein de notre base de données pour retrouver les commentaires saisis et les commandes créées par rapport a ces produits.

Cette technique convient également très bien aux OData de S/4 Hana ( side-by-side extensibility ). Étendre ces OData dans l’environnement SAP BTP, ABAP est une approche stratégique pour enrichir vos services OData existants sans modifier les systèmes backend ( Ici, S/4 Hana) sous-jacents.
Cette méthode permet une intégration fluide de nouveaux attributs de données, offrant ainsi la possibilité d’étendre les fonctionnalités sans impacter le cœur du backend, ce qui préserve la stabilité du système et garantit la conformité avec les processus existants.

1/ Créer une table de base de données

Le champs product_id permettra de faire le lien avec les données retournées de l’API.
Le champs comment_product stockera les commentaires sur le produit.

2/ Modifier la custom CDS

  • Ajouter le champs « comment_product » dans la CDS.
  • Ajouter les annotations UI qui permettrons de naviguer dans chaque produit et de les afficher dans un Object Page.
  • Modifier la classe ztest_crt_proxy pour sélectionner le commentaire correspondant a la ligne du produit s’il existe
  • Également, ajouter le traitement du filtrage, car lorsqu’on naviguera en cliquant sur un produit en particulier, nous avons besoin d’effectuer un appel api qui filtre sur ce produit en particulier.

3/ Créer un behavior definition

Comme nous sommes dans le cas d’une Custom CDS Entity, alors il faut gérer le behavior de manière « unmanaged ».

Ici on active uniquement le « update » et seulement sur le champs « comment_product » ( les autres champs sont en Read only ) car c’est le seul champs qu’on veut autoriser modifier.

4/ Developper le Behavior Implementation

Le behavior implementation sera développé dans la classe zbp_test_cust_northwind

  • On commence par développer la classe nécessaire au traitement de la phase d’intéraction.

La methode READ ( À implémenter – ici on ne s’en sert pas – , doit vous permettre de venir lire les informations sur les entités qui sont encore dans le buffer – dans la phase d’interaction – et pas encore sauvegardées – pas encore passées par la phase de sauvegarde – )

La methode UPDATE vient créer une entrées dans le buffer ( Ici la variable mt_buffer_upd_prod ) et sera sauvegardées plus tard dans la phase de sauvegarde.

On logue également les données updatées dans le CHANGING PARAMETER mapped.

  • On implémente ensuite la classe nécessaire au traitement de la phase de sauvegarde.

Dans la methode SAVE, on vient traiter les demandes d’UPDATE de notre entité ( donc l’ajout/modification d’un commentaire ).

C’est a ce moment qu’on vient mettre a jour la base de données.

5/ Exposer le business object RAP via une API

Créer le Service Definition et le Service Binding

On pourra ensuite utiliser cette API dans une application Fiori dont voici le résultat :

Note :

Dans notre cas, nous pouvons récupérer les produits présents dans l’API Northwind en effectuant un GET. Mais il n’est pas possible d’effectuer de POST pour créer de nouveaux produit, de PATCH pour mettre a jour un produit ou de DELETE pour supprimer un produit, mais cela pourrait être le cas pour d’autres API.

Si ces méthodes avaient été disponibles il aurait suffit de déclarer et d’implémenter les différentes méthodes nécessaires pour traiter les demandes de création/mise a jour/suppression et d’appeler l’API Northwind dans l’objet RAP avec des POST/PATCH/DELETE.

Conclusion

Nous avons vu comment étendre une API externe en y ajoutons un champs supplementaire qui sera sauvegarde au sein de notre environement.

Dans la Partie 2, nous complexifierons cet objet RAP en y ajoutons une toute nouvelle entité fille qui gerèra les commandes associées aux produits.

Laisser un commentaire