De nos jours, les interfaces de programmation d'applications, également connues sous le nom d'API (Application Programming Interface), jouent un rôle essentiel dans la manière dont nous interagissons avec la technologie. Dans cet article, je démystifie ce qu'est une API en utilisant les produits SAP comme exemple.
Qu'est-ce qu'une API ?
Comme mentionné en début d'article, API signifie Application Programming Interface (interface de programmation d'applications), Interface étant le mot clé de cette expression.
Dans le contexte d'un ERP comme SAP, les données sont hiérarchisées et stockées dans une base de données. Ces données sont ensuite isolées et protégées par différentes couches de sécurité, le tout est enveloppé par plusieurs lignes de code garantissant le respect d'un modèle de données particulier.
Pour interagir avec ces données de l'externe, des outils (modules, fonctions, classes) sont programmés pour permettre une action très précise sur ces données, en lecture ou écriture. Ces outils sont communément appelés des APIs. La plupart des applications de nouvelle génération et progiciels de gestion intégrés (ERP) ont des APIs pour faciliter la communication avec des données ou autres modules internes.
Le reste de cet article va se concentrer sur les APIs de SAP. Afin de mieux comprendre le rôle des APIs dans un écosystème informatique, commençons par comprendre d'où elles viennent.
Historique des APIs
RFC (Remote Function Call)
Quiconque connaît bien SAP connait aussi les BAPI, mais peut-être pas leur identité exacte.
Le mot BAPI n'est pas une coïncidence (BAPI = Business API), un terme propre à SAP ayant de particularités bien spéciales :
- Programmation gérée par un module Fonction RFC, un protocole propriétaire SAP permettant d'être appelé de l'externe;
- Une logique qui implémente une action précise d'un Business Object (Objet interne SAP encapsulant un objet réel, ex: Commande d'Achat, Employé);
- Pour une création ou mise-à-jour, le LUW transactionnel (Logical Unit of Work) est conservé; c'est à dire on opère une action à la fois, et pas de mise-à-jour forcée sur la base de données;
- Le module Fonction est approuvé pour utilisation générale, SAP garantie la fonctionnalité et le support de celle-ci lors d'évolutions du système.
SAP offrait à l'époque des librairies (connecteurs) pour différents langages de programmation (VB, Java) permettant à des systèmes maison de se connecter à SAP pour effectuer des opérations diverses. Beaucoup de vieux systèmes maisons utilisent encore ces outils.
Services Web
Avec l'intégration d'un serveur web dans la couche applicative des instances SAP, il est maintenant possible de communiquer par le protocole HTTP(S). Cette méthode de communication va rapidement remplacer RFC comme protocole de choix pour intégrer des systèmes de façon automatisée. À terme, cela permettra l'émergence de services web, protocoles utilisés pour communiquer entre les appareils.
SOAP (Simple Object Access Protocol)
Le format de message SOAP sous HTTP rend relativement simple la communication vers d'autres systèmes, où les données sont transférées et interprétées en format XML.
Nous trouvons alors plusieurs exemples d'interfaces entre les systèmes SAP (ECC ou S/4) et de nombreux partenaires externes pour automatiser des processus critiques d'entreprises (ex: transfert de factures fournisseurs, données d'expédition, étiquettes de livraison, etc.). Ces partenaires offrent ces services (APIs) avec des frais normalement proportionnels au volume de transactions effectuées.
Nous avons par exemple consommé à plusieurs reprises, dans SAP ECC ou SAP S/4HANA, des APIs SOAP produits par Poste Canada pour générer des étiquettes utilisées à la livraison de commandes, ou des numéros de suivi de colis qu'on sauvegarde dans SAP.
Un membre de mon équipe a aussi participé à plusieurs projets récemment où on doit interagir, par appels SOAP, entre SAP S/4 et leur propre produit Concur (ou une alternative TrinDocs) pour transférer des données fournisseurs et leurs factures.
REST (Representational State Transfer)
Quelques années plus tard, un nouveau style fait surface, REST, basé sur un concept de modélisation de données et les méthodes pour interagir avec ces données. On parle ici plutôt d'un style, ou une façon de faire, plutôt qu'un protocole. Il n'y a pas de nouvelle technologie, on utilise les règles déjà existantes du web, mais la charge utile est plus légère et ne nécessite pas de WSDL, comparé à une interface SOAP. Les meilleures pratiques sont normalement de se limiter à des actions très précises sur un objet clairement identifié. Normalement transféré sous HTML, en format JSON (plus compact que XML), ce nouveau style va prendre de plus en plus de popularité avec la communauté web, incluant la plupart des nouvelles applications mobiles.
Selon Google Trends, voici intérêt général sur le sujet de 2004 à 2016 :
Pour de plus amples renseignements sur SOAP vs REST (ou "comment vaincre l'insomnie"), il existe plusieurs sources d'information sur le sujet mais le détail devient rapidement pénible et nécessite beaucoup de connaissances techniques sur le développement web.
OData
En 2007, Microsoft développe un nouveau protocole à format ouvert intitulé OData, rendant plus simple et standard la production et consommation d'APIs REST. Le format partage des similitudes avec les APIs JDBC et ODBC, mais s'applique plutôt à des modèles d'objets plutôt que se limiter à des bases de données relationnelles.
SAP va adopter le protocole OData, qui devient l'outil de choix pour le transfert de données entre son nouveau front end Fiori et la couche applicative.
Pourquoi les APIs sont-elles importantes pour une entreprise ?
Plusieurs entreprises vont se démarquer en mettant le focus sur leur offre d'APIs, qui deviendra plus populaire que leurs produits initiaux. Le trafic web des APIs, maintenant automatisé de machine à machine, devient plus populaire que le trafic des utilisateurs.
Cet engouement va s'étirer jusqu'à l'apparition de plateformes web où les APIs deviennent la vedette (ex: AWS). Ces plateformes, comme Azure de Microsoft, offrent une sorte de page blanche où des développeurs de différentes sources viennent participer en ajoutant et partageant du contenu qui supporte la plateforme.
Nous utilisons des APIs au quotidien sans même le réaliser
Nous avons tous partagés une nouvelle ou un article intéressant sur notre mur Facebook ou profil Instagram. Très récemment, j'étais très agréablement surpris de me connecter à mon compte de "Revenu Canada" (que je ne connais pas) par le biais de mon institution financière (que je connais très bien). Des jeux vidéo vont même utiliser des APIs de stockage de tiers-partie pour sauvegarder le progrès et préférences des joueurs, le tout de manière transparente. Ces interactions se font par le biais d'APIs.
L'interaction humaine est de moins en moins importante, de plus en plus d'applications (incluant mobile) communiquent entre elles par API REST, créant un type de réseau social pour machines.
Les APIs sur SAP Cloud Platform APIs (SCP)
Avec l'apparition des applications cloud de SAP, les développeurs n'ont plus accès à la couche applicative pour manipuler les données ou les processus. SAP a donc mis à la disposition des développeurs une série (grandissante) d'APIs pour accomplir cette interaction.
SAP API Business Hub
Pour regrouper et permettre de retrouver plus facilement toute sorte d'APIs pour différents produits cloud, SAP lance son API Business Hub. Voici un exemple de recherche pour des APIs dans le monde des achats (Purchasing), et leurs différents formats :
Le SAP API Business Hub permet même de générer du code (snippet) dans différents langages pour faciliter la consommation. SAP offre un sandbox avec de vraies données pour tester les APIs facilement et rapidement. La liste, et l'organisation du Hub évolue régulièrement, il faut rester à l’affût!
SAP Cloud Platform API Management
La plateforme cloud de SAP (SCP) met à la disposition des développeurs un service intitulé API Management. On peut ici exposer notre propre API, créer des produits (combinaison d'APIs), ajouter la sécurité ou autre limitation voulue, faire un suivi sur la consommation, évaluer les statistiques et erreurs, etc.
En utilisant l'intégration avec le WebIDE, nous pouvons même créer une application Fiori basé sur un modèle et y intégrer un appel à un de ces APIs.
J’ai personnellement passé bien des heures au fil des ans à rechercher des détails sur différentes actions d’une API, suivant la documentation parfois très mince et dispersée trouvée un peu partout sur Internet. Le format et la qualité de l'information présente aujourd'hui est une nette amélioration.
Avec un tel regroupement et homogénéisation d'information ainsi que la génération automatique de sections de code, il n’a jamais été aussi facile de développer des applications intégrées et professionnelles.
Il est certain que ces outils et leur intégration n'arrêteront pas d'évoluer, alors il est important de demeurer informé. Contactez-nous pour plus d'informations!
Références:
- Historique des APIs chez SAP : https://blogs.sap.com/2016/06/17/part-1-introduction-to-api-management/
- REST et HTTP : https://www.infoq.com/articles/designing-restful-http-apps-roth/
- OData : https://en.wikipedia.org/wiki/Open_Data_Protocol
- Définition des services web : https://www.techopedia.com/definition/25301/web-service
- Évolution des services web : https://www.slideshare.net/APIMeetup/apis-and-beyond-open-distribution-platforms-6815625
- Comment l'internet fonctionne en coulisse : https://hackernoon.com/apis-how-the-internet-works-behind-the-scenes-690288634c32
- Évolution des APIs : https://www.epam.com/insights/blogs/a-look-at-the-evolution-of-apis
