Créer un Business Object RAP avec une API externe

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

Dans notre dernier article, nous avions vu comment créer un proxy pour consommer une API externe.
En ce basant sur cela, nous allons maintenant l’intégrer a un business object RAP.

Cette pratique peut permettre différentes choses, par exemple :

En créant un objet RAP qui vient consommer cette API externe, alors nous n’avons plus le problème car l’appel se fait directement dans le backend et le résultat de cet appel est rendu disponible via un service OData developpé avec notre BO RAP.

PS : l’autre solution serait de déporter la création et le déploiement de l’application Fiori dans BTP, et de créer une destination pour consommer ce service.
La destination est à considérer comme un proxy internet disponible dans BTP pour permettre des appels avec des URL disposant de la même origine ( l’application Fiori deployée sur BTP appelle la destination vers l’API avec le même domaine => www.mon-domaine-btp.com ).

  • Si nous souhaitons étendre un service OData ou une API, par exemple d’un système S/4 Hana, sans l’étendre directement dans le système source, alors il est possible de consommer cette API dans BTP et de conserver les données supplémentaire dans BTP ( Prochain article a venir ).

Ici nous allons donc consommer l’API Northwind et l’exposer dans un service OData via la création d’un objet RAP. Cet objet RAP nous permettra ensuite de créer une application Fiori pour visualiser ces données.

1/ Creation d’un proxy via Service Consumption Model

Voir https://abapeur.fr/fr/appeler-facilement-des-apis-en-abap/

2/ Creation d’un Custom CDS Entity

  • Créer un custom CDS Entity ( ZTEST_CUST_NORTHWIND ) qui contiendra les données que l’on souhaite exposer dans notre application Fiori.
  • Comme, c’est un custom CDS Entity, alors nous devons implémenter le query de manière unmanaged dans une classe ( ZTEST_CRT_PROXY ). Cette classe aura donc la responsabilité de remplir les données de la CDS.
  • Nous ajoutons également des annotations pour l’affichage dans l’application Fiori ( Les annotations UI peuvent etre déplacée vers un Metadata Extension pour respecter le principe « separation of concerns ». Par simplicité, ici ce n’est pas fait )

3/ Implémenter la classe ZTEST_CRT_PROXY

Pour cela il faut que cette classe implémente la méthode select l’interface if_rap_query_provider.

  • Voici la signature de la classe
  • Voici l’implémentation de la méthode if_rap_query_provider~select

1/ Créer la destination et l’appel a l’API via le proxy.

Ce code permet de récupérer toutes les données de l’entity PRODUCTS.

2/ Remplir les données dans le CDS Custom Entity

IMPORTANT : Si vous voulez également permettre a l’utilisateur de filtrer, trier, limiter le nombre des données, etc… Alors il faut également mettre en place toute la logique nécessaire au sein de la méthode.

1/ Récupérer les actions demandées par l’utilisateur

2/ Une fois que vous disposez de ces élements, il faut adapter l’appel API et le traitement des données reçues en fonction de ces derniers. (Nous verrons un exemple dans mon prochain article).

Code complet

4/ Exposer le service OData

Créer le Service Definition

Et le service binding

Et prévisualiser l’application : nous recevons et exposons dans l’application Fiori les élements de l’API Northwind

Conclusion

Nous avons vu comment consommer une API externe, l’exposer dans un objet RAP, l’utiliser dans une application Fiori ainsi que les problématiques auxquelles cela répond.

Prochainement nous verrons comment étendre une API en se basant sur le meme principe.

Laisser un commentaire