Contexte
L’un de nos clients dispose d’une organisation s’appuyant à la fois sur un service central, ou centre de services, chargé de fournir des prestations sur abonnement ainsi que sur des structures locales qui gèrent l’aspect administratif (référentiel des clients, contrats d’abonnement…). Il est donc nécessaire que les données clients, enregistrées au niveau local, soient communiquées au référentiel du service central. En retour, les référentiels locaux doivent recevoir un compte rendu de prestation issu du service central. Le service central et les structures locales détiennent un logiciel différent ; celui des structures locales est décliné en une quarantaine d’instances.
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.
Bénéfices :
Notre client a tiré plusieurs avantages de la nouvelle architecture mise en place :
• Vitesse accrue dans la transmission des informations → davantage de réactivité,
• Fiabilisation des échanges de données → pas de perte de messages aux conséquences critiques (par exemple, réalisation de la prestation à la mauvaise adresse),
• Existence d’un référentiel-maître (le référentiel du service central) distinct de la solution d’acheminement des messages → pas d’erreurs dues aux multiples systèmes de référencement des abonnés et d’affectation du matériel,
• Système d’information urbanisé → visibilité des échanges d’information optimisée ; facilité à faire évoluer le système d’information,
• Centralisation de la gestion des accès, des connexions et des rapports d’erreur → meilleur contrôle des échanges de données.
Convaincu par l’efficacité de Xbus, notre client a imposé la mise en œuvre de cette solution d’interconnexion applicative à l’ensemble de ses partenaires. Ainsi, l’utilisation de Xbus a été étendue à une dizaine d’autres centres de services.