Il est aujourd’hui très courant d’interfacer des applications entre elles, pour échanger des données ou mettre à jour des éléments de l’une avec des données de l’autre.
Partons du principe que vous avez choisi votre mode de dialogue, API REST ou SOAP, API spécifique Open Graph Facebook ou MS-Graph Microsoft, ou bien encore un accès direct à la base distante.
Une fois cela fait, il faut décider quelle application accède à l’autre. Cela peut être contraint par l’architecture (une application SAAS ne peut en général pas accéder à une application ON-PREMISE) ou tout simplement par l’absence de description du modèle de données, d’API documentée ou de compétences de développement pour l’une des applications ou des éditeurs concernés.
Une fois toutes les cartes en main on peut se lancer, mais pour que tout se passe bien, il y a un certain nombre de règles à respecter, et des risques à prendre en compte.
La clé d’interface
Dès lors que l’on met face à face deux ensembles de données, la première préoccupation est de définir la ou les clés de correspondance. Cela signifie mettre en face d’un objet d’une application son équivalent dans la seconde, de telle manière à ne créer que ce qui est réellement absent et à mettre à jour le reste.
Ce qui est sûr, c’est que chaque objet présent d’un côté va devoir n’avoir qu’une et une seule correspondance de l’autre.
C’est simple quand on parle d’un bien qui aura son identifiant, code interne, code-barres ou numéro de série unique. Cela se gâte un peu quand on parle d’annuaire. Le nom d’une personne peut changer, son matricule peut être recréé et cela devient encore plus complexe quand un numéro de commande ou d’engagement se transforme en un ou plusieurs numéros d’immobilisations.
Le maître d’une propriété
Dans le cas où les propriétés sont présentes dans les deux applications, il faut s’assurer que les modifications soient répliquées dès que possible afin d’éviter tout conflit ou qu’elles soient distinctes et interprétées par l’application.
Prenons quelques exemples concrets pour comprendre le problème :
L’objectif est souvent de prendre des données et de les compléter avec d’autres éléments. C’est ainsi que j’ai eu l’occasion de mettre en place pour le compte d’un groupe de plusieurs dizaines de milliers de d’employés et de centaines de sociétés, un outil permettant aux collaborateurs, sur la base d’un annuaire Active Directory global, de compléter leur fiche personnelle avec leur photo mais surtout d’indiquer la société pour laquelle ils travaillaient et le nom de leur manager. Cela dans le but de mettre à jour en retour l’annuaire central Active Directory.
Dans ce cadre, l’AD est le maître et les modifications faites par l’utilisateur doivent être propagées dès que possible afin de ne pas rentrer en conflit avec d’éventuelles modifications faites dans le maître.
Même si la lecture de l’AD peut se faire régulièrement et de façon programmée, il faut donc que dès que l’utilisateur modifie les données, celles-ci soient immédiatement réécrites dans l’AD en lieu et place des précédentes.
Sur le même principe, dans un autre cas, l’objectif consistait à lire les commandes et à les compléter avec les informations de réceptions des biens ou des prestations, afin d’être en mesure de décider de la bonne fin de l’opération et du paiement du fournisseur.
Ici il faut distinguer la propriété « quantité attendue » et celle « constatée ». En effet, rien ne garantit que la réception est intégrale, ni d’ailleurs qu’elle a été saisie en une fois. Cependant il n’est pas nécessaire de la reporter immédiatement, cela peut être fait de façon programmée uniquement. C’est donc l’application d’interface qui va devoir gérer la réconciliation des données et présenter le solde. les données ne peuvent pas être en conflit mais il faut gérer la réconciliation.
La meilleure solution
Dans tous les cas de figure, une bonne solution est de toujours distinguer les données issues des deux applications et de laisser l’interface piloter l’éventuel écrasement des données, en prenant évidemment soin d’historiser les changements.
En revanche, il restera à traiter les suppressions et être en mesure de fournir un bon suivi des opérations, mais cela fera l’objet d’un prochain article.
Ces articles pourrait vous intéresser :
Olivier Piochaud, PDG d’Apsynet
