Urbanisation et évolutivité du système d’information

L’utilisation d’une solution tierce pour assurer la transmission d’informations entre les diverses applications du système d’information (SI) permet d’urbaniser celui-ci. Bien souvent, les évolutions des entreprises les amènent à cumuler au fil du temps des applications qui communiquent entre elles de façon non homogène et non harmonisée au niveau global (syndrome du plat de spaghetti). Cette situation rend difficile toute évolution, qu’elle soit technique ou applicative.

En réponse à cette problématique, l’urbanisation du SI, à l’image de la démarche d’urbanisme pour une ville, consiste à mettre en place un système qui puisse évoluer facilement afin d’accompagner les divers changements pouvant survenir dans une entreprise (rachat, fusion, partenariats, création d’une nouvelle branche d’activité…). À cette fin, le SI doit mettre en œuvre le principe de cohérence forte, couplage faible : chaque composant doit pouvoir communiquer facilement avec les autres sans qu’une forte dépendance technique ne les lie. Un rôle défini doit être assigné aux applications, associé à un comportement normalisé en entrée et en sortie. Elles doivent pouvoir être supprimées ou remplacées sans que le reste du SI n’en pâtisse sur le plan technique. Le fait que les applications passent par la solution tierce pour échanger des informations a ainsi pour avantage de leur éviter de prendre en charge des API ou des formats de fichier spécifiques aux autres participants du SI, ce qui créerait un couplage technique. L’utilisation d’une solution dédiée pour faire communiquer les diverses applications du SI s’impose donc.

L’urbanisation du SI favorise notamment sa mise à l’échelle scalability. Un schéma d’échanges inter-applicatifs bien maîtrisé, sans couplage, facilite l’ajout de nouvelles applications. Le respect des principes de l’urbanisation, notamment via l’usage d’une solution d’interconnexion applicative, contribue ainsi à la construction d’un SI agile, modulaire et évolutif.

Gestion des échanges asynchrones

Développer une interface point-à-point entre deux ou quelques applications peut sembler simple. Toutefois, la question de la disponibilité des applications réceptrices entraîne la nécessité de gérer l’asynchronisme. L’un des avantages de recourir à une solution tierce est en effet sa disponibilité, indépendamment des applications. Même si les applications réceptrices ne sont pas connectées à Xbus au moment où un message leur parvient, celui-ci ne sera pas perdu. Stocké dans la base de données du bus, il sera envoyé à l’application dès qu’elle se connectera à celui-ci. Xbus fournit ainsi une garantie de transmission asynchrone des messages qui transitent par lui.

En outre, la ou les application(s) réceptrice(s) ne consomment pas nécessairement les données qui leur sont envoyées au rythme où elles leur parviennent. Intégrer un système de file d’attente (queue) associé à une base de données pour stocker les messages au niveau des applications réceptrices serait inutile étant donné qu’un tel système serait dépendant de leur disponibilité. Il faudrait donc intégrer le système au niveau des applications émettrices. Or cela impliquerait que l’émetteur ait à se soucier du mode de consommation du ou des récepteur(s), ce qui ne cadre pas avec les principes de l’urbanisation, selon lesquels un composant ne doit pas être trop étroitement lié à un autre. Intercaler un système tiers semble donc constituer la meilleure option si l’on veut assurer la gestion de l’asynchronisme. Xbus dispose d’un système de queue, basé sur NATS, ainsi que d’une base de données capable de « faire le tampon » en stockant les messages qui ne sont pas consommés assez rapidement par les applications réceptrices. Pour chacune d’elles, il est possible de paramétrer le rythme d’arrivée des données.

Supervision des communications

Une solution d’interconnexion applicative permet généralement de superviser les échanges inter-applicatifs en suivant diverses métriques. Dans Xbus, il est possible de :

• Vérifier si chaque message a été reçu ou non
• Suivre la progression des messages, notamment connaître la position exacte de chaque enveloppe contenant des données dans son parcours
• Savoir quelles applications sont joignables et accéder à l’historique des connexions et déconnexions des applications interfacées avec le bus
• Connaître le temps de traitement entre les différents systèmes
• Accéder aux messages d’erreur des récepteurs : savoir quand une enveloppe reçue n’a pas pu être consommée et pourquoi (mauvais format, incohérence des données…)

Le fait que l’ensemble des informations (logs) soit enregistré dans un système central évite aux équipes de production d’avoir à vérifier au sein de chaque application ce qui a été envoyé ou reçu. La supervision en est simplifiée. Pour faciliter encore le suivi, il est possible de connecter à Xbus un outil spécifique de type Prometheus afin de recevoir des alertes.

Généralement, une solution d’interconnexion applicative prend aussi en charge le routage des messages, ce qui favorise l’urbanisation du système, les applications émettrices étant ainsi moins couplées aux consommatrices.

À noter également que recourir à une solution dédiée pour interfacer ses applications permet d’éviter de gérer soi-même la sécurisation des accès.