Interfaçage

/ by
Reading Time: 6 minutes
Dans ce blog, le directeur technique Richard Develyn dissipe la confusion qui entoure l’importance des différents niveaux d’interfaçage des applications. Il explique que les API et le format des flux de données ne sont pas aussi complexes que beaucoup de gens le pensent. Il affirme que ce sont plutôt la suffisance et le processus d’interfaçage qui sont beaucoup plus importants pour garantir que les applications puissent communiquer avec succès les unes avec les autres.

Nous passons probablement plus de temps à nous préoccuper des choses dont nous ne devrions pas nous soucier et à ne pas nous préoccuper des choses dont nous devrions nous préoccuper tel que l’interfaçage.

L’interfaçage est une chose à plusieurs couches. Certaines couches sont difficiles et d’autres sont faciles. Malheureusement, toutes les couches sont appelées « interfaçage » et c’est là que la confusion apparaît, parce que nous voulons nous assurer que nous avons une réponse claire en tête quant à savoir si l’interfaçage est facile ou difficile et le fait est que c’est à la fois facile et difficile selon la façon dont on voit les choses.

Nous devons donc séparer ces couches afin de mieux le comprendre, notamment en ce qui concerne les défis auxquels nous sommes confrontés ici à CloudTrade lorsque nous essayons de connecter notre service de saisie analytique à d’autres applications et systèmes.

Interfacing diagram

API

C’est la partie la moins importante du défi de l’interfaçage et pourtant c’est souvent celle dont on parle le plus. Bien qu’API signifie interface de programmation d’applications (Application Programming Interface) il s’agit en réalité d’une interface au niveau le plus simple possible dans la communication inter-applications. Les API fournissent le mécanisme permettant aux applications A et B d’échanger des données, mais cela ne va pas plus loin – c’est-à-dire que les API ne garantissent pas que A et B parleront réellement le même langage ou seront capables de donner un sens à ce que chacun d’eux fait.

La raison pour laquelle les API sont très répandues est qu’il existe un grand nombre de A et de B dans ce monde et donc de nombreuses API pour les connecter. Ces API sont parfois normalisées, comme le SFTP et le HTTPS. Parfois, elles ne le sont pas, ce qui peut donner lieu à d’intéressantes guerres d’API, où le fabricant de l’application A publiera une API pour se connecter avec elle, tout comme le fabricant de l’application B ; les API ne seront pas compatibles et aucune des parties ne voudra changer pour accommoder l’autre. Cependant, des entreprises comme la nôtre laissent de côté ces vantardises et essaieront toujours de travailler avec n’importe quelle API, et seront heureuses de mettre en œuvre une API sur mesure à condition qu’elle soit documentée et que le client s’engage à l’aider pour les tests. Le travail de développement d’une API entièrement nouvelle dure généralement une à deux semaines.

L’essentiel est de ne pas s’inquiéter des API. Si nous ne soutenons pas votre API mais que nous allons certainement faire des affaires ensemble, nous réglerons ce problème même s’il implique un petit développement nouveau.

Format

Si l’API établit le fil qui nous relie, le « format » est l’accord sur la signification réelle des données que nous échangeons. Normalement, cela se fait avec des fichiers XML / des flux de données, bien que toutes sortes d’autres formats soient également possibles. XML signifie langage de balisage extensible (Extensible Markup Language), et le mot « balisage » signifie essentiellement qu’il définit la manière dont le sens est attribué aux données. Par exemple, dans la séquence XML :

<nom>Richard</nom>

la donnée « Richard » a le sens de « nom ». Si je développe l’exemple comme ceci :

<client><prénom>Richard</prénom></client>

Ensuite, la signification de « Richard » est qualifiée de prénom du client.

Les formats de fichiers XML ont tendance à être plus standardisés, bien qu’il existe des variations dans l’utilisation de ces normes, ainsi que des extensions de ces normes et la présence de formats de fichiers entièrement personnalisés. En général, cependant, les gens ont moins tendance à s’inquiéter de ce genre d’interfaçage que des API ; je suppose que cela « paraît » plus facile, bien que cela puisse être tout aussi problématique.

En fin de compte, cependant, l’essentiel pour l’interfaçage des formats est le même que pour les API. Si nous n’utilisons pas déjà une interface commune, il se peut que nous devions effectuer un travail de configuration supplémentaire pour régler ce problème, mais tout cela est tout à fait possible.

Suffisance

C’est là que les choses peuvent devenir un peu épineuses. Si nous ne pouvons pas vous fournir tout ce dont vous avez besoin, ou vice versa, alors nous ne pourrons pas travailler ensemble.

Cela peut être tellement catastrophique que si nous avons le moindre doute, nous devons examiner la situation très attentivement avant d’aller plus loin. La difficulté est que ces problèmes d’insuffisance se situent parfois dans les détails. Le plus classique pour nous étant que votre système financier ne peut pas traiter les factures sans numéro de ligne de commande au niveau de la ligne d’achat, et que vos fournisseurs ne les fournissent pas dans leurs factures, et que nous n’avons pas d’autre endroit où nous pouvons les obtenir.

Parfois, le problème n’est pas si catastrophique, mais il peut impliquer que nous devons faire du travail important pour obtenir les informations manquantes, ou peut-être même que vous devez ajuster votre système cible afin qu’il n’ait plus besoin de ces informations. Quoi qu’il en soit, cette couche d’interface est importante, donc l’essentiel ici est de s’assurer très tôt que nous n’avons pas un problème insoluble de suffisance.

Application

Notre application fait-elle ce que votre application exige ? Elle doit faire ce qui est requis, sinon nous ne nous parlerions probablement pas au départ.  Vous l’auriez pensé, de toute façon.

Dans le domaine des comptes fournisseurs et des comptes clients, où nous travaillons depuis de nombreuses années, la question ne se pose pas vraiment, mais dans certains des nouveaux domaines dans lesquels nous évoluons, tels que la détection des fraudes et les flux de données RPA, une sorte de vérification des attentes devrait avoir lieu.

Par exemple, si nous détectons une fraude, vous attendez-vous à ce que nous appelions la police ? Probablement pas, mais l’essentiel ici est que nous devons nous rassurer que nous ayons une compréhension commune de la fonctionnalité que nous fournissons et que vous attendez.

Processus

Finalement, celle qui semble nous causer le plus de problèmes.

Les applications ont des cas d’utilisation – un terme emprunté à l’analyse et à la conception de logiciels, mais qui est maintenant utilisé pour cataloguer toutes les différentes façons dont une application peut être utilisée. Lorsque des applications se rejoignent, ces cas d’utilisation doivent s’interfacer entre eux afin de satisfaire les cas d’utilisation globaux de la suite d’applications. Si vous ne prenez pas soin de bien relier ces cas d’utilisation entre eux, des anomalies et des trous peuvent se produire dans lesquels les transactions peuvent tomber et ne plus jamais être vues.

Cela nécessite une analyse minutieuse de la manière dont chaque cas d’utilisation va progresser dans l’ensemble du système. Les cas problématiques sont généralement ceux où une erreur se produit à un moment ou à un autre du processus. Si elle se produit dans l’application « distributeur », qui est généralement la nôtre ici à CloudTrade, alors l’application « destinataire » doit pouvoir recevoir cette erreur de notre part (de la manière qu’elle veut) et en faire quelque chose de raisonnable. Si l’erreur se produit dans l’application « destinataire », peut-être à la suite d’une erreur que nous avons commise mais dont nous n’avions aucune idée lorsque nous avons transmis la transaction, alors l’application « destinataire » doit à nouveau faire quelque chose de raisonnable. Les deux choses qui ne peuvent pas se produire sont que l’application « distributeur » se retrouve avec le bébé sur les bras sans nulle part où le mettre, ou que l’application « destinataire » laisse le bébé tomber dans un trou noir qui est soit littéralement un trou noir, soit un trou dans lequel personne ne regarde jamais.

L’essentiel pour l’interfaçage des processus est que cela doit être réglé avant que nous ne fassions des affaires, sinon nous risquons de mettre en place quelque chose qui finira par échouer.

Conclusion

Nous ne discuterions probablement même pas de la possibilité de travailler ensemble si nos besoins en matière d’interfaçage au niveau des applications n’étaient pas réglés, mais cela vaut la peine de se mettre en contact si nous ne sommes pas dans le monde des comptes fournisseurs ou des comptes clients. Ensuite, nous devrions prendre le temps de nous assurer que nous n’avons pas de problèmes fondamentaux d’interfaçage au niveau de la suffisance ou du processus avant même de commencer à nous inquiéter des API ou des formats de données. Quant aux deux derniers, bien qu’il soit très peu probable que nous développions des API ou des formats de données « sur mesure », car ils sont très nombreux, ils ne constituent pas un obstacle aux affaires tant que nous convenons des coûts de développement, et nous pouvons généralement développer ou modifier ce que nous avons déjà pendant le temps qu’il faut pour déployer un nouveau système.

L’interfaçage est un problème à plusieurs niveaux. L’essentiel, lorsque nous envisageons de travailler ensemble, est de s’assurer que nous nous préoccupons du processus et de la suffisance, plutôt que des API ou du format de données, car les premiers sont ceux qui peuvent causer de problèmes réels, tandis que les seconds sont ceux que nous pouvons régler avec un peu de temps et d’efforts.