Ancienne architecture

Une architecture complexe avait été mise en place pour s’adapter à ce fonctionnement. Les 40 bases locales et la base centrale échangeaient des données par le biais d’une application intermédiaire (ERP). Cette base intermédiaire était utilisée pour définir à quelle base locale transmettre les messages issus de la base centrale (routage des messages). Un grand nombre de données issues des bases locales était transmis à la base intermédiaire mais toutes n’étaient pas pertinentes. L’ERP servait donc également à filtrer les informations à mettre à jour si besoin. La base intermédiaire communiquait avec les bases locales et la base centrale via une solution de Message-Oriented Middleware (MOM).

Problématiques

Ces choix d’architecture (en particulier l’utilisation de MOM pour la transmission des messages et d’une base intermédiaire pour le routage et le filtrage) posaient plusieurs problèmes :

• L’utilisation d’un ERP (la base intermédiaire) pour faire transiter les messages n’était pas efficace en matière de performances
• Plusieurs référentiels coexistaient et leur mise à jour n’était pas coordonnée. Aucun référentiel n’étant déclaré maître, il était difficile de déterminer quelle était l’information la plus à jour (par exemple, quelle était l’adresse actuelle d’un abonné)
• Les MOM étaient uniquement utilisés pour assurer le transport des messages Aucune supervision n’était effectuée. Depuis l’interface des MOM, les utilisateurs ne pouvaient donc pas déterminer si un message avait bien été transmis ou non. Ainsi, des messages étaient perdus. Pour pallier ce problème, les collaborateurs procédaient à des vérifications manuelles
• Le centre de services avait besoin de disposer des informations relatives à l’instance locale émettant une demande de prestation avant de pouvoir la traiter et faire part de son retour auprès de la base concernée. Afin de décharger le service central de ce travail d’analyse, une urbanisation de l’architecture du système d’information était à prévoir

Solution mise en place

Afin de parer à ces problèmes, nous avons mis en place une architecture différente. La base intermédiaire utilisée pour filtrer et router les messages ainsi que les MOM ont été supprimés et remplacés par Xbus.

Outre la mise en place de Xbus, nous avons accompagné les équipes du client afin de :

• Définir la nature des messages envoyés par chaque base afin de disposer d’un schéma d’échange clair : dans le cadre des synchronisations Xbus, les 40 bases locales sont à présent maîtresses des données (informations relatives aux clients). Le service central émet uniquement des messages indiquant que tel événement a eu lieu pour tel numéro de contrat (comptes rendus de prestation)
• Filtrer les données envoyées en amont : les équipes du client ont défini pour quelles données locales ils souhaitaient que les changements soient synchronisés avec le service central. Par exemple, lorsqu’un contrat est créé, le numéro est transmis au centre de services, mais pas l’identifiant de la base locale qui le gère. En effet, le rattachement de l’abonné à une base locale peut changer en cas de déménagement, et la correspondance numéro de contrat-base locale est gérée par un tableau de correspondance à part. Un mécanisme de détection des changements a été mis en œuvre au sein des bases locales afin que les modifications soient automatiquement envoyées au centre de services via Xbus. Ainsi, le filtrage des messages réalisé a posteriori au sein de la base intermédiaire n’est plus nécessaire.

Cette solution permet de : 

• Améliorer les performances : Xbus étant par nature une solution destinée à intégrer les données, il est conçu pour supporter la charge d’échanges constants ; les performances en sont ainsi accrues
• Garantir la livraison des messages : Xbus garantit l’acheminement des données, même si l’application réceptrice n’est pas disponible au moment de l’envoi (transmission asynchrone)
• Contrôler l’acheminement des données : contrairement aux MOM précédemment utilisés, le bus sert non seulement à transporter les messages mais également à superviser leur transmission (vérifier si chaque message a été reçu ou non, suivre précisément leur progression, savoir quelles applications sont joignables et accéder à leur historique de connexion, connaître le temps de traitement entre les différents systèmes)
• Assurer le routage des messages : le système utilisé par Xbus pour transmettre les messages (pipelines et nœuds) facilite le développement de routeurs. Un routeur spécifique a été développé pour ce client afin d’envoyer les messages issus du service central vers la base locale concernée. Les structures locales n’étant pas gérées par le même organisme que le service central, il n’aurait pas été pertinent que le routage soit effectué au niveau de celui-ci. Le routeur identifie la structure locale à laquelle transmettre le message grâce à un tableau de correspondance, qui met en regard le numéro de contrat d’abonnement (inclus dans les messages émis par le service central) et la structure locale concernée. Ce tableau est alimenté à chaque création de contrat,
• Urbaniser l’architecture du système d’information : le centre de services peut désormais se concentrer sur la partie métier et n’a plus à endosser le rôle de référentiel commun. En effet, le service central se contente d’envoyer un compte rendu des événements ayant eu lieu sur un contrat et Xbus, à l’aide du tableau de correspondance, se charge du routage vers la base locale concernée.