Comprendre les flux applicatifs

Ces flux permettent le bon fonctionnement de tout système informatique, ils se doivent d’être rigoureusement conditionnés afin de garantir une exécution renouvelée des processus qu’ils impliquent.

‍

‍

Sécurité et format de données

‍

Les flux applicatifs permettent donc l’échange de données entre différents lieux, par exemple le catalogue produit d’un site de commerce est géré par un flux qui vient chercher de manière permanente ou programmée dans une base de données les articles qui sont présents dans ce catalogue.

Par convention, les données transférées sont en format JSON, plus rarement on peut utiliser des formats XML, TXT ou CSV.

La sécurité de ces données est conditionnée par la sécurité du flux en lui même, on doit donc veiller à autoriser de manière précises les accès et permissions accordées à un tierce concernant un flux donné. Les mécanismes de sécurisations peuvent être :

• par reconnaissance d’adresse IP : permet d’autoriser seulement l’IP d’un ou plusieurs serveurs à utiliser une API développée.
• par différents mécanismes d’authentification grâce à des “clés” individuelles.
• par des protocoles plus sécurisés permettant de garantir l’authentification d’un utilisateur précis (ex: Oauth 2, JWT)

‍

Lexique utile

‍

Pour vous assurer la bonne compréhension des explications fournies dans cette article, faisons un petit tour des termes inerrants à ce sujet.

• FTP ou SFTP : Il s’agit d’un protocole de transfert de fichiers, ce terme désigne aussi simplement la plateforme utilisée pour gérer les fichiers sur le serveur distant où ils sont stockés.
• S3 : Il s’agit d’un protocole semblable au FTP mais plus moderne car le S3 repose sur le cloud, les données sont donc plus sécurisées car elles sont répliquées en plusieurs zones et non seulement stockées physiquement à un seul endroit comme celles d’un serveur distant classique utilisé par un protocole FTP. Et un SDK est à disposition des développeurs pour interagir facilement avec les fichiers
• CRON : Il s’agit d’un programme permettant de configurer la planification de scripts, donc de tâches automatisées, à exécuter à des heures précises.
• API : Interface de programmations permettant l’échange d’informations entre plusieurs systèmes.
• Front : Interface côté utilisateur d’une application.

‍

Les types de flux et leur fonctionnement

‍

Ces exemples sont basés sur une situation où nous aurions besoin de récupérer une liste d’articles.

Le dépôt de fichier par FTP ou SFTP

Au niveau de l’architecture de base d’un flux, elle est facilement compréhensible : un applicatif vient interroger à intervalle régulier à l’aide d’un CRON le SFTP où sont enregistrées les données afin de détecter des changements dans des données existantes ou bien des nouvelles données. Une fois ces données récupérées, l’API les traite et les stocke dans une base de donnée.

Côté utilisateur, l’internaute va se connecter à un site, par exemple une boutique en ligne, son navigateur va interroger l’API pour récupérer la liste d’articles, l’API vient donc afficher ce qu’elle trouve dans sa BDD.

Ce type d’architecture de flux est la plus simple qui existe. Elle a pour avantage de rendre maître de sa donnée, cependant elle ne permet pas d’avoir des données en temps réel et va venir surcharger le réseau en faisant tourner peut-être inutilement un CRON si de nouvelles données ne sont pas présentes dans le SFTP.

‍

Le dépôt de fichier par S3

‍

Un dépôt de fichier par S3 représente une architecture un petit peu plus avancée. Les données présentes sur le SFTP vont venir se synchroniser dans le cloud, si un changement est constaté dans le cloud, une fonction applicative va créer une route vers l’API qui viendra elle enregistrer ce changement dans sa BDD.

‍

Pour l’utilisateur, aucun changement n’est à constaté, c’est simplement le chemin emprunté par l’information qui change d’une manière plus efficiente.

À l’inverse d’un dépôt par SFTP, le dépôt par S3 permet d’éviter une surcharge réseau, d’avoir une donnée actualisée en temps réel tout en restant maitre de sa data.

‍

L’appel à d’autres API

‍

Dans certains cas où nous ne serions pas maître de la données dont nous avons besoin, nous pouvons concevoir une API qui vient elle demander la récupération de la liste d’articles à des API tierces qui suivraient elles un cheminement classique développé plus haut.

Par exemple, un site E-commerce type “marketplace” qui regroupe les catalogues de différents prestataires aura une API qui ira appeler celles de ses partenaires pour afficher leurs articles dans son catalogue.

Ce système permet d’avoir des données tout le temps à jour et est très orienté micro-services, il est cependant totalement dépendant du fonctionnement des API tierces.

‍

Le message Queuing

‍

Afin de supplanter cette dépendance aux API tierces, nous pouvons faire appel au message Queuing. Cela désigne un canal dans lequel un applicatif vient déposer un “message”, un peu comme une sorte de boîte de réception, lorsqu’elle aurait un nouvel article dans sa BDD. Ce message pouvant être récupéré par un autre système. Ainsi, même si le système tiers ne fonctionne plus, notre API peut tout de même récupérer sa donnée et venir la stocker dans notre BDD.

‍

Cette méthode permet donc d’avoir une donnée toujours à jour, sans surcharger le réseau et sans non plus dépendre du fonctionnement de l’API tierce.

‍

L’orchestration et le suivi des flux

‍

Lorsqu’un système dispose de plusieurs flux qui fonctionnement simultanément, il est nécessaire de programmer leur exécution dans un ordre bien défini pour assurer la cohérence des informations.

Par exemple, dans notre système d’articles, si un deuxième flux existe pour récupérer une “catégorie”, si je veux récupérer un article et le rattacher à une catégorie qui n’existe pas dans mes données, mon système rencontrera un problème.

En cas de problèmes, il faut également toujours s’assurer d’avoir des outils qui tracent les différentes informations sur la bonne ou mauvaise exécution des flux et idéalement avoir des mécaniques simples pour les relancer en cas d’erreurs.