Ce billet constitue un post-mortem au sujet de l’incident qui a impacté l’application ITEM – pour la création ou la modification en masse d’exemplaires dans le Sudoc – entre le 14 mars et le 4 avril 2024.
Symptômes et impact de l’incident
Dans un premier temps, l’incident a été signalé via le guichet AbesSTP, plusieurs utilisateurs ayant constaté que leurs demandes déposées via ITEM n’étaient pas traitées intégralement : à partir d’un certain moment dans le traitement du fichier, une erreur était levée, et le reste du fichier n’était pas traité correctement.
Pour contourner ce problème, certains utilisateurs ont tenté de relancer des demandes via ITEM en ne reprenant que les lignes non traitées, mais cette solution, bien que fonctionnelle, n’était pas satisfaisante et demandait, en outre, un certain temps pour reconstituer des fichiers.
Dans la mesure où l’application ITEM « écrit » dans la base Sudoc, afin de limiter les risques de corruption des données d’exemplaires dans le Sudoc, il a donc été décidé de fermer l’accès à l’application, le temps de diagnostiquer l’origine du problème.
Fonctionnement d’ITEM et interactions avec le Sudoc : rappels
Pour fonctionner, l’application ITEM utilise AccesCBS, une librairie Java développée en 2010 par l’Abes : simulant le comportement de WinIBW, ce programme gère la majorité des commandes présentes dans WinIBW, de la même façon que si une personne les activait à partir de son propre poste, mais de façon beaucoup plus rapide, tout en offrant la possibilité de lancer des traitements en masse.
Ainsi, lorsqu’une demande est en attente de traitement dans ITEM, AccesCBS est utilisé pour effectuer une série d’actions dans le Sudoc : authentification, recherche de la notice à modifier, passage de la notice en mode édition, validation de la modification, passage à la notice suivante.
Précisons qu’AccesCBS utilise le protocole réseau TCP/IP et le protocole Pica3 pour communiquer avec CBS, base centrale au coeur du Sudoc, exactement de la même manière que l’outil de catalogage WinIBW.
Analyses des causes de l’incident
Une première étape a consisté à tenter de reproduire le problème pour en déterminer la cause. L’équipe en charge de la maintenance d’ITEM a donc lancé différents traitements sur l’environnement de test, mais sans parvenir à reproduire le problème.
Devant cette impasse, un programme spécifique a été développé : il s’agissait de permettre la lecture d’un fichier et le lancement, sur la base de production du Sudoc, des mêmes commandes que celles d’ITEM, mais sans validation de ces modifications afin de ne pas modifier les notices utilisées pour ces tests. Lancé à de nombreuses reprises avec des jeux de données différents, ce programme a été affiné au fur et à mesure afin d’obtenir un diagnostic le plus précis possible.
La série de tests – effectués tout d’abord à partir d’un poste local, puis à partir d’un serveur de l’Abes- a conduit aux constats suivants :
- Le bug ne se produit pas systématiquement et, qui plus est, pas forcément au même endroit dans un fichier (notion d’occurrence aléatoire).
- Selon les lancements, un même lot de notices peut être soit traité intégralement soit rencontrer un problème, ce qui ne permet pas de déterminer quel critère fait « planter » le programme.
- Le bug a tendance à se produire plutôt le matin entre 7h30 et 10h30.
Ce constat fait, des tests plus poussés ont été réalisés. Les éléments suivants ont été particulièrement surveillés :
- Charge des machines
- Activité sur le réseau
- Activité sur le CBS
- Journaux d’évènements du CBS
- Journaux d’évènements du programme développé en interne
Par ailleurs, AccesCBS utilisant le protocole TCP/IP, il a été décidé de surveiller le dialogue réseau entre le programme et le CBS pour déterminer si la communication était normale. C’est ce critère de surveillance qui a permis de comprendre l’origine du problème.
Le protocole TCP/IP, qui consiste en l’envoi et la réception de trames (petits paquets de données) sur le réseau entre un client et un serveur, comporte un système de confirmation de l’envoi et de la réception des informations (nommé ACK). Or, à un moment donné dans le lancement du programme, il a été constaté que celui-ci, au lieu de confirmer la bonne réception d’une trame en provenance du CBS, déclenchait la fermeture de la connexion. Le tunnel entre le programme et le CBS étant fermé, le traitement de la ligne en cours était interrompu, les lignes suivantes n’étant pas traitées.
Solutions mises en place
Au niveau d’AccesCBS
Au sein de son code, AccesCBS fournit une méthode pour l’envoi et la réception des trames sur le réseau. Utilisée pour envoyer les commandes WinIBW depuis l’application ITEM, il s’agit d’une méthode de très bas niveau (couche réseau). Pour tenter de corriger le problème de réception des trames, le code a été réécrit et optimisé mais, malgré cette réécriture – qui a toutefois permis d’optimiser la communication entre AccesCBS et le CBS, le bug continuait à se produire.
Au niveau d’ITEM
Devant cette impasse, des recherches ont été réalisées pour déterminer s’il était possible, lorsque le bug se produisait, de réinitialiser la connexion entre AccesCBS et le CBS et de relancer le traitement sur la ligne ayant rencontré le problème. Un système a donc été mis en place dans le code d’ITEM afin d’effectuer les opérations suivantes :
- Mise en place d’une remontée d’erreur spécifique lorsque le problème se produit dans AccesCBS pour « informer » ITEM
- Détection de l’erreur dans ITEM
- Déconnexion et reconnexion au CBS lorsque le problème se produit
- Mise en place d’un système permettant de retraiter la ligne en erreur : lorsque le problème est détecté, ITEM tente de traiter la ligne 4 fois. Au-delà de 4 tentatives infructueuses, ITEM renvoie une erreur avec un message explicite dans le fichier résultat de la demande créée par l’utilisateur.
Actions suite à l’incident
Afin d’améliorer le code d’AccesCBS et ainsi se prémunir contre les potentielles erreurs liées au protocole, une prestation informatique va être demandée par l’Abes.
En parallèle, il était nécessaire d’isoler les flux des applications communiquant avec le Sudoc des flux des utilisateurs professionnels dans leur usage quotidien du Sudoc. A cette fin, les applications de l’Abes utiliseront désormais un port spécifique pour se connecter au CBS.
Enfin, ce problème, qui s’est manifesté avec l’application ITEM, pourrait potentiellement se produire sur d’autres applications utilisant AccesCBS. Pour éviter ce risque, un système de détection de l’erreur « déconnexion / reconnexion au Sudoc » a été mis en place sur les autres applications de l’Abes.