Quand la base de données d’ITEM a disparu : retour sur l’incident de fin janvier 2024

Date de début de l’incident: 26/01/2024 à 12h20Date de fin de l’incident : 05/02/2024 à 11h04Type d’incident : Critique

Points essentiels à retenir

Précisons tout d’abord qu’une indisponibilité de la base de données d’ITEM ne concerne en rien les exemplaires créés dans le Sudoc ; ces deux processus sont distincts. Ainsi, l’absence de visualisation d’une demande dans le tableau de bord ne reflète pas un problème dans le traitement réel des opérations dans le Sudoc.

De même, il convient de distinguer les fichiers de traitement des informations relatives aux demandes. En cas d’incident sur la base de données, les fichiers de demande sont stockés sur les serveurs de l’Abes et peuvent être retrouvés à partir de leur numéro. Cependant, cela nécessite que l’utilisateur ait mémorisé ce numéro, car il n’est pas possible de retrouver une demande à partir de l’ILN et/ou du RCR. Une réflexion sera menée sur ce point.

Symptômes et impacts de l’incident

Le 26 janvier, un utilisateur constate que ses tableaux de bord sont vides et que le système lui demande de saisir son adresse e-mail après authentification, un comportement anormal puisque cela ne se produit habituellement qu’à la première connexion.

Mesures prises : fermeture de l’application ITEM et envoi d’un mail d’alerte aux professionnels des réseaux.

Le problème identifié révèle un dysfonctionnement de la base de données d’ITEM. Une recherche de solutions de restauration à partir des sauvegardes est entreprise. Cependant, au 29 janvier 2024,  les sauvegardes journalières de la base de donnée s’avèrent vides … depuis le 26 février 2023, un problème dont la source réside dans un désaccord (mismatch) de version entre le serveur PostgreSQL (version 15.1) et l’outil de sauvegarde (version 14.4), qui empêchait  la création de dumps valides. Rappelons qu’un dump représente un instantané de la base de données de l’application contenant toutes les informations relatives aux demandes créées (l’index, le type de demande, etc.).

Mesure prise pour résoudre le problème de compatibilité : mise à jour de l’outil de sauvegarde vers la dernière version (4.0.35)

Le dernier fichier de sauvegarde disponible datant du 26 février 2023, il s’ avère nécessaire de tester la capacité de restauration en environnement de développement. Il a tout d’abord fallu décider quelle base de données utiliser pour la relance d’ITEM : les sauvegardes du 26 février 2023 ou une base vide ?  Ensuite, avant la réouverture en production, il a été nécessaire d’activer les traces SQL de PostgreSQL puis de mettre à jour le dumper vers la dernière version (4.0.35).

Causes et solutions

Du fait du manque de logs, la cause précise de l’incident n’a pas été identifiée avec certitude. Le principal soupçon réside dans un effet de bord d’un paramétrage spring ou d’un batch au sein d’ITEM.

À la suite de l’incident, des mesures ont été prises pour prévenir de futures occurrences similaires. Elles incluent la modification des emplacements de sauvegarde, l’ajout de sondes de surveillance, la notification de l’état des sauvegardes, la réalisation de tests de restauration réguliers, et la réparation du système de logs.

Une certitude : en cas de récidive de l’incident, l’Abes sera en mesure de restaurer plus rapidement – dans la journée en cours – les données relatives aux demandes.

Continuer la lectureQuand la base de données d’ITEM a disparu : retour sur l’incident de fin janvier 2024

Articuler Calames  et Wikimedia Commons : point technique

  • Auteur/autrice de la publication :
  • Post category:Non classé

Ce billet propose un point technique sur la façon d’articuler Calames et Wikimedia Commons. Consulter le billet Fil Abes à ce sujet

Récupérer les données produites dans le cadre du signalement dans Calames afin de les importer sur Wikimedia Commons, plateforme comportant des dizaines de milliers d’utilisateurs dans le monde, semble d’emblée une bonne idée. Pour ce faire, l’Abes se devait de répondre d’un point de vue technique à la question suivante : comment faciliter le liage entre les métadonnées associées aux ressources Calames et Wikimedia Commons ? 

Mise à disposition d’un plugin dédié

Le plugin Pattypan s’est vite imposé comme un choix sûr. Développé par la communauté des wikimédiens, régulièrement mis à jour et librement accessible sur GitHub, ce plugin permet de charger des fichiers en masse, ce dans un large choix de formats (jpg, png, pdf, wav, TIFF,…). De plus, il a l’avantage non négligeable de réunir métadonnées et fichiers numériques en un seul import dans Wikimedia Commons, les données étant prises en charge dans un simple tableau Excel. 

Seul inconvénient identifié, le plugin Pattypan nécessite des compétences en Java pour être exécuté sous Windows. Pour remédier à ce problème, l’Abes a donc décidé de financer une prestation de développement. Celle-ci, réalisée par Wikimédia Suède, a abouti à une version du plugin exécutable directement sous Windows, par un simple double-clic sur une icône dédiée présente sur le bureau. Cette version du plugin est librement téléchargeable sur le GitHub dédié.

Mise en place de nouveaux flux de données

Créer les liens entre Pattypan et les métadonnées descriptives présentes dans Calames s’avère relativement simple. Rappelons que Calames proposait déjà des exports d’EAD vers Dublin Core au format csv (à ouvrir avec Excel ou tout autre tableur). Cependant, du fait du format particulier des métadonnées de Wikimedia Commons, il a fallu définir un mapping d’EAD vers ce format spécifique, les modèles de données utilisés dans Wikimedia Commons étant plus simples que le format EAD. Une fois cette opération réalisée,  l’Abes a mis en production deux nouveaux exports Calames, correspondant aux deux modèles de données, complémentaires, proposés par Wikimedia Commons : les modèles «book» et «artwork». 

Ces deux exports ont été pensés afin que les liens avec les composants EAD de Calames – et, le cas échéant, avec les autorités IdRef et les bibliothèques numériques des établissements – soient récupérés directement puis importés dans Wikimedia Commons. 

Il est donc désormais possible – en quelques minutes voire secondes – d’exporter les données Calames puis d’importer dans Wikimedia Commons, d’une part, le tableau des données descriptives, d’autre part, les fichiers numériques des documents.

Le résultat : des fichiers partagés, de multiples rebonds et des perspectives 

Afin de regrouper les fichiers importés selon la personne, l’entité, le lieu, l’époque ou la thématique, il est vivement recommandé d’assigner des catégories Wikimedia Commons aux fichiers à importer. Chaque établissement public est encouragé à créer sa propre catégorie afin de rassembler l’ensemble des fichiers issus de ses collections. Ces catégories particulières peuvent aussi renforcer la visibilité d’un fonds, d’une collection ou d’un ensemble spécifique à l’intérieur des collections.

Du côté du catalogue Calames, il est possible d’établir des liens réciproques vers Wikimedia Commons. Pour réaliser cette opération, il convient d’en faire la demande à l’Abes qui se chargera de la création en masse des liens pointant vers les documents importés dans Wikimedia Commons. 

De même, les établissements qui le souhaitent peuvent s’engager dans des chantiers de création ou d’alignement entre les identifiants IdRef présents dans les données Calames et les identifiants Wikidata utilisés par Wikipédia. Précisons que l’export depuis Calames n’impose pas un tel chantier : il s’agit d’un choix à définir selon l’investissement de l’établissement sur ces plateformes. 

Notons enfin que certains des établissements Calames – La Contemporaine notamment – ont fait le choix d’organiser des événements, des formations ou des ateliers d’édition dans Wikipédia. On peut aussi imaginer des ateliers – organisés potentiellement avec des chercheurs, doctorants, étudiants…- dédiés à la récupération de fichiers importés dans Wikimedia Commons et à leur utilisation pour illustrer des fiches Wikipédia.  Pour cela, il est vivement conseillé de se rapprocher de Wikimédia France. 

En savoir plus

 

Continuer la lectureArticuler Calames  et Wikimedia Commons : point technique

Focus sur les technologies utilisées pour la publication du projet d’établissement 2024-2028 de l’Abes

  • Auteur/autrice de la publication :
  • Post category:Non classé

Au cours de l’année 2023, l’Abes a préparé son projet d’établissement pour la période 2024-2028. Une équipe Scrum, composée de 10 agents issus des 3 départements de l’Abes, a été mise en place pour travailler de manière itérative sur l’analyse des produits et services de l’Abes, le recueil des besoins utilisateurs, des propositions de services et enfin la rédaction du document de projet. 

Pour cette dernière étape, un site web public, doté d’un système permettant aux utilisateurs de déposer des commentaires, a été mis en place : https://projet2024.abes.fr

Cet article a pour objectif de détailler les technologies utilisées pour la conception de ce site web : 

  • Docusaurus, 
  • Hypothes.is, 
  • CI/CD avec GitHub et Docker

Docusaurus 

Le socle du site est le logiciel libre Docusaurus (dans sa version 2) dont la devise est : « Construisez rapidement des sites web optimisés, concentrez-vous sur votre contenu. 

Il s’agit d’un logiciel très populaire – https://docusaurus.io/showcase – dans le monde de l’IT maintenu par les développeurs de Facebook. Son principal cas d’usage est de simplifier la création et la maintenance de documentation en ligne. Il permet de générer des sites web statiques, fluides au niveau de la navigation et optimisés pour le référencement web. 

Le workflow Docusaurus pour la publication du contenu est le suivant : 

  1. L’auteur rédige ou modifie un fichier au format markdown (syntaxe wiki devenue très populaire avec l’arrivée de GitHub). 


      2 – Le système de compilation de Docusaurus va ensuite générer les pages statiques HTML, CSS, JS du site web à partir des fichiers markdown. Cette opération est automatisée à l’aide  des technologies  CI/CD : Github & Docker.

Les fichiers markdown – qui intègrent le contenu du site – sont consignés dans un dépôt GitHub dédié : https://github.com/abes-esr/projet2024. Les contenus peuvent être modifiés à tout moment, que ce soit directement via Git ou via l’interface wysiwyg de GitHub.

Comme pour tous les développements opensource de l’Abes, nous avons suivi le workflow GitFlow pour déployer le site du projet sur les 3 environnements (développement, test, production) en préservant une correspondance entre les branches et tags du GitFlow et l’environnement cible. Voici par exemple ce que cela donne pour l’application « projet2024 » :  

  • Environnement « dev » (développement) : toutes les modifications de contenus (fichiers markdown) et de configuration du site web sont réalisées sur la branche « develop » qui se retrouve alors automatiquement déployée sur l’URL suivante : https://projet2024-dev.abes.fr  (uniquement accessible depuis le réseau interne de l’Abes) 
  • Environnement « test » : une fois les modifications prêtes à être testées, on fusionne la branche « develop » dans la branche « main » et l’ensemble se retrouve alors automatiquement déployé sur l’URL suivante : https://projet2024-test.abes.fr  (uniquement accessible depuis le réseau interne de l’Abes) 
  • Environnement « prod » (production) : une fois les tests validés sur l’environnement précédent, une release (un tag git) est générée qui permet un déploiement sur l’URL de production : https://projet2024.abes.fr   

Ce système, dont les technologies sont détaillées dans le chapitre « CI/CD : Github & Docker », permet d’assurer une autonomie au rédacteur qui, ainsi, ne dépend pas d’un informaticien pour publier les contenus. 

Nous avons également utilisé la technologie Mermaid, disponible par défaut sous forme d’un plugin Docusaurus. Cette fonctionnalité, qui permet de générer des diagrammes au moyen d’une syntaxe textuelle spécifique, a servi pour tracer les diagrammes de Gantt de la partie « calendrier du projet » : https://projet2024.abes.fr/docs/2.4/projet2024-calendrier  

Syntaxe spécifique de mermaid pour générer un Gantt 

 

Visuel correspondant à la syntaxe Mermaid

 

Hypothes.is 

La seconde technologie utilisée est le logiciel libre Hypothes.is, dans sa version SaaS, dont la devise est : Collaborer avec n’importe qui, de n’importe où (« Collaborate with anyone, anywhere. ») 

Ce logiciel, au code source ouvert – https://github.com/hypothesispermet de déposer des commentaires partout sur le web. Pour le site du projet de l’Abes, nous avons utilisé la version publique hébergée en SaaS également proposée par lentreprise Hypothes.is.

Pour la publication de commentaires sur le site « projet2024 », le wokflow Hypothes.is est le suivant : 

  • L’utilisateur crée un compte sur la plateforme SaaS Hypothes.is 
  • Il peut alors surligner le texte qu’il souhaite commenter puis rédiger un commentaire qui sera accessible publiquement dans le panneau latéral droit 
  • De la même manière, il peut cliquer sur les commentaires des autres utilisateurs et y répondre 
Exemple de commentaires déposés avec Hypotes.is 

 

Ce système, complètement indépendant de la technologie Docusaurus, est pratique du fait qu’il évite de devoir embarquer dans Docusaurus un système potentiellement complexe pour gérer la création de compte et l’authentification. Il permet de déposer et de répondre à des commentaires de manière très ergonomique. 

Enfin, l’intégration d’Hypothes.is dans le site web « projet2024 » a été simple et rapide : il a suffi d’ajouter un morceau de javascript embed.js dans les pages du site web et de rédiger un tutoriel à destination des utilisateurs. 

CI/CD : GitHub & Docker 

Le système d’intégration et déploiement continus de l’Abes a permis de compiler, intégrer puis déployer automatiquement ce site web. Ainsi, ce site est déployé de la même manière que les applications ITEM (cf dépôt GitHub),  QualiMarc (cf dépôt GitHub) ou theses.fr (cf dépôt GitHub). 

Pour mettre en place cette CI/CD sur l’application « projet2024 », la première étape a consisté à déposer son code en opensource sur le GitHub de l’Abes https://github.com/abes-esr/projet2024 – et la seconde  à ajouter deux GitHub Action dans son code source, ce qui permet de : 

Enfin, la troisième étape a consisté à préparer un dépôt GitHub dédié au déploiement de l’application « projet2024 » dans les 3 environnements (développement, test, production) : https://github.com/abes-esr/projet2024-docker 

Ce dernier dépôt comporte trois fichiers clé : 

  • docker-compose.yml : contient la description et la configuration statique des différents conteneurs de l’application, soit, dans notre cas, les deux conteneurs suivants : 
    • projet2024 : conteneur principal comportant un serveur web nginx légèrement configuré et dont le rôle est d’exposer les sources HTML/JS/CSS statiques générées par le logiciel Docusaurus dans la phase de CI
    • projet2024-watchtower :  conteneur particulier du fait qu’on le retrouve dans toutes les applications Abes déployées avec cette CI/CD (pour rappel : ITEM, QualiMarc, theses.fr …). Il utilise le logiciel Watchtower – https://containrrr.dev/watchtower – qui permet de scanner toutes les n minutes dockerhub pour vérifier si une nouvelle version de l’application est prête à être déployée ou non. C’est ce conteneur qui permet de faire le “CD” de “CI/CD”. 
  • .env-dist : contient les paramètres de l’application pouvant être personnalisés entre les trois environnements de déploiement (dev, test et prod). 
  • README.md :  contient les procédures d’exploitation de l’application (comment l’installer, la démarrer, la stopper, la superviser, la sauvegarder) 

Conclusions

L’utilisation des technologies Docusaurus et Hypothes.is a constitué une première à l’Abes. Nous avons particulièrement apprécié la facilité et la rapidité de production  (mise en œuvre d’environ 4 jours de travail à 3 personnes) d’un site web fonctionnel doté d’une navigation rapide et moderne (et responsive). 

Pour sa part, le système d’intégration et déploiement continus (CI/CD), sur lequel repose l’ensemble des nouvelles applications développées à l’Abes, a permis de publier facilement et sereinement les versions successives du projet d’établissement (versionnements Git et Docusaurus). 

En revanche, la fonctionnalité d’édition/publication depuis le format markdown – qui représente pourtant un des points forts de Docusaurus pour gérer collaborativement l’édition et la publication de documentation sur un site web – n’a pas été utilisée : de fait, pour collaborer sur le contenu du document de projet, il a été décidé d’utiliser le logiciel Microsoft Word associé à OneDrive, bien connu des membres de l’équipe du Projet d’établissement. L’intégration des contenus dans le site web final n’a donc pas été aussi fluide et intégrée que cela aurait pu l’être en l’éditant directement à partir du markdown. De fait, pour réaliser la conversion automatique de .docx vers markdown (cf procédure), le logiciel Pandoc a été utilisé.

Le type d’architecture présentée dans cet article nous a donc convaincus. Elle est actuellement utilisée à l’Abes pour la publication de la documentation d’un projet interne et servira également pour la publication d’un site web dédié à la politique de développement informatique de l’Abes, actuellement géré directement en markdown depuis GitHub. 

Continuer la lectureFocus sur les technologies utilisées pour la publication du projet d’établissement 2024-2028 de l’Abes

Abes et Mir@bel : retours sur le chantier d’attribution de n°ISSN pour les revues en accès libre

  • Auteur/autrice de la publication :
  • Post category:Non classé

Visuel Abes Mirabel ISSNDébut 2022,  en s’appuyant sur les données de la base Mir@bel et sur la Base de Connaissance BACON, un corpus d’environ 700 titres étrangers en libre accès ne possédant pas de n°ISSN électronique était identifié. Afin de remédier à ce constat, l’Abes a  lancé, à l’aide de l’application CIDEMIS  (Circuit dématérialisé des Demandes ISSN), un important chantier de demandes d’attribution de n°ISSN auprès du Centre International de l’ISSN et de son réseau, qui gère, au niveau international, l’identification et la description des ressources continues.

Ce chantier, qui vise à améliorer l’identification des ressources en libre accès, et éventuellement de leur généalogie, en demandant leur numérotation ISSN, concerne un large périmètre, soit 88 pays et 75 Centres Nationaux différents. Rappelons par ailleurs que l’inclusion de publications en libre accès dans les principaux répertoires mondiaux – tels que le DOAJ (« Directory of Open Access Journals« ) ou ROAD (répertoire des ressources scientifiques et universitaires en accès libre) – implique l’attribution d’un identifiant ISSN.

Continuer la lectureAbes et Mir@bel : retours sur le chantier d’attribution de n°ISSN pour les revues en accès libre

BACON : évolution des fichiers KBart dédiés aux revues

Pour répondre Logo Bacon carréaux demandes des utilisateurs de la base de connaissances BACON – qui souhaitaient, en particulier pour les fichiers relatifs à la presse,  une évolution de l’affichage du format des dates présentes dans les fichiers KBart des revues, les dates signalées dans les champs « date_first_issue_online » et « date_last_issue_online », jusqu’alors restreintes à l’année, seront désormais exposées au format AAAA-MM-JJ.

Précisons cependant que la présence des dates au format « jour, mois et année » dépendent des données renseignées par les fournisseurs. De fait, si seules les années sont spécifiées, l’équipe en charge de BACON ne complètera pas ces dates. Par défaut, si le jour et le mois ne sont pas indiqués, l’affichage des dates  sera construit sur le modèle : [AAAA]-01-01.

Cette modification sera effective pour les fichiers chargés dans la base à partir du 12 juin 2023. Pour les versions antérieures, les données exactes des jours et des mois ne sont pas récupérables.

Cette évolution est conforme à la recommandation KBart. Consulter :  https://groups.niso.org/higherlogic/ws/public/download/16900/RP-9-2014_KBART.pdf

Pour toute question, le guichet ABESstp BACON est à disposition : https://stp.abes.fr/node/3?origine=Bacon

Continuer la lectureBACON : évolution des fichiers KBart dédiés aux revues

IdRef : le projet ArchéoRef Alignements (ArchéoAl) est terminé

Depuis octobre 2020, l’Abes était partenaire du projet ArchéoRef Alignement – ArchéoAl  relatif aux notices d’autorité de sites archéologiques, projet financé par CollEx-Persée et porté par l’Institut français d’archéologie orientale du Caire (Ifao). Formellement terminé depuis fin 2022, le projet a fait l’objet d’un rapport scientifique publié courant mars 2023. Au printemps 2023, l’Abes a procédé au chargement des alignements PACTOLS dans IdRef.

Dans la continuité du projet ArchéoRef …

Entre 2014 et 2016, le réseau des Écoles Françaises à l’Étranger (EFE), l’Institut français d’archéologie orientale du Caire (Ifao), l’École française d’Athènes (EFA), l’École française de Rome (EFR), l’École française d’Extrême-Orient (EFEO) et la Casa de Velázquez (CVZ) ont mené un premier projet ayant abouti à l’enrichissement de 475 notices d’autorité IdRef décrivant des sites archéologiques. Il s’agissait principalement d’ajouter des coordonnées géographiques dans les notices afin de permettre la géolocalisation des sites.

Consulter les deux billets  publiés à ce sujet sur le blog Punktokomo : ici et ici

…en exploitant la méthodologie du projet RefDivinités

En 2019-2020, l’Abes a été sollicitée par la Bibliothèque interuniversitaire de la Sorbonne et FRANTIQ, Fédération et Ressources sur l’Antiquité (GDS 3378), dans le cadre d’un autre projet CollEx-Persée : RefDivinités. Il s’agissait de travailler sur des divinités et héros du monde méditerranéen antique, décrits à la fois dans IdRef et dans PACTOLS, thésaurus de référence pour les Sciences de l’Antiquité et l’Archéologie.  Ce travail d’enrichissement et d’alignement IdRef <-> PACTOLS a porté sur 663 notices de personnes physiques.

Consulter le billet Punktokomo qui retrace les étapes de ce projet

ArchéoAl : partenaires et finalités du projet

En 2020, sous la houlette de l’Ifao, les mêmes acteurs sont lauréats d’un nouvel appel à projet Collex-Persée : ArchéoAl commence. Le projet a été mené en deux phases :

  •  au sein de chaque école, collaboration entre chercheurs et professionnels de l’IST dans l’objectif d’améliorer les notices IdRef
  • recours à un personnel recruté sur financement Collex-Persée et hébergé par Bibracte afin d’aligner IdRef au thésaurus PACTOLS porté par FRANTIQ et, ainsi, l’ouvrir à d’autres référentiels.
Continuer la lectureIdRef : le projet ArchéoRef Alignements (ArchéoAl) est terminé

CERCLES : lancement d’un nouveau chantier sur le corpus Strada lex

image CERCLES
source : DIYCandy

En 2015, naissait le dispositif CERCLES (voir le billet) mis en place par l’Abes pour accompagner, aider et valoriser un établissement souhaitant s’investir sur l’enrichissement des données d’un corpus de documents spécifique. 

En 2023, un nouveau corpus de ressources électroniques va bénéficier de ce dispositif : Strada lex. 

 

Le corpus Strada lex

Bien connue des établissements d’enseignement supérieur et universités à composante juridique, cette base de données donne accès à toute l’information juridique européenne.
Elle constitue un bon outil de veille (des actualités sont disponibles, ainsi que la jurisprudence) et une plateforme d’accès à des revues en texte intégral, aux codes et textes réglementaires ainsi qu’à un très grand nombre de monographies électroniques.
Déjà, en 2019, quatre établissements membres du réseau Sudoc, conscients de la nécessité de signaler finement ce corpus, s’étaient associés, de façon informelle, pour cataloguer un grand nombre d’ebooks. Ainsi, grâce à la volonté des SCD des universités de Rennes I (sa dénomination à l’époque), Lille, Paris II Panthéon Assas et Paris Dauphine, 400 notices d’ebooks avaient été créées dans le Sudoc. 

Continuer la lectureCERCLES : lancement d’un nouveau chantier sur le corpus Strada lex

Quand Oracle ne répond plus – retour sur l’incident de novembre 2022 

  • Auteur/autrice de la publication :
  • Post category:Non classé

En novembre 2022, un incident technique sérieux sur l’infrastructure du SI de l’Abes pénalisait les bibliothèques, les obligeant à reporter toute activité de signalement et à réorganiser les emplois du temps des équipes.
L’Abes se devait de rendre compte de l’évènement aux établissements membres de ses réseaux. Voici donc le déroulé précis de l’incident, ainsi qu’une explication des mesures de correction prises pour l’avenir.

Les faits marquants 

En résumé 

Le week-end du 19 et 20 novembre 2022 était consacré à la maintenance informatique annuelle assurée par l’Abes. Cette intervention importante, planifiée plusieurs semaines à l’avance, est généralement réalisée le week-end afin d’éviter de perturber les services aux établissements, du fait qu’elle nécessite une extinction complète des systèmes de l’Abes.

Pendant ce week-end, l’équipe Infrastructure et Réseau de la DSI de l’Abes a réalisé plusieurs opérations techniques qui se sont déroulées avec succès (mises à jour diverses sur les serveurs, ajouts de nouveaux serveurs, redémarrages d’applications, etc.).

C’est au début de la semaine suivante que des dysfonctionnements sont apparus, deux problèmes indépendants  ayant très fortement dégradé les performances des applications :  

  • Un problème sur un port d’un composant physique de l’architecture réseau, faisant le lien entre les serveur applicatifs (le Sudoc en particulier) et les disques durs contenant les données 
  • Un problème logiciel sur l’architecture Oracle en cluster, suite à la mise à jour des serveurs, qui a nécessité de changer l’architecture pour basculer vers un serveur unique mais mieux dimensionné. 
Continuer la lectureQuand Oracle ne répond plus – retour sur l’incident de novembre 2022 

Les API de l’Abes disponibles au format OpenAPI sur api.gouv.fr

  • Auteur/autrice de la publication :
  • Post category:Non classé

Depuis sa création, l’Abes développe une gamme d’applications destinées à la production, au traitement et à l’administration des données par les réseaux documentaires de l’ESR. Dès 2010, dans le cadre d’une politique volontariste en faveur de l’ouverture et de l’interopérabilité des données, une nouvelle catégorie de services s’est déployée pour une plus large réutilisation des données par les systèmes d’information :  une gamme de web services a ainsi  été mise progressivement à la libre disposition des professionnels de la documentation et des développeurs afin de faciliter l’extraction et la réutilisation des données en provenance des différentes bases gérées par l’Abes : Sudoc, Calames, IdRef, BACON, Theses.fr, STAR, STEP…

Jusqu’à présent, les web services de l’Abes étaient accompagnés de documentation sous forme de pages HTML, comme par exemple : http://documentation.abes.fr/sudoc/manuels/administration/aidewebservices/index.html.

Cependant, avec une quarantaine de web services disponibles aujourd’hui,  il devenait important d’harmoniser leur présentation, d’optimiser leur exposition et d’affiner leur documentation. Pour ce faire, en conformité avec sa politique de développement,  l’Abes a décidé de décrire ses API avec le standard OpenAPI : https://github.com/abes-esr/abes-politique-developpement/blob/main/08-Documentation.md

A noter : Le vocabulaire et les socles informatiques ayant considérablement évolué depuis 2010, on regroupe désormais ces ensembles de web services sous l’appellation générique d’API – Interface de Programmation Applicative, solution informatique permettant à des applications de communiquer entre elles et de s’échanger mutuellement des données.

Les API de l’Abes en OpenAPI

En 2010, la startup Swagger initiait un projet, devenu populaire au fil des années, qui permettait aux développeurs de définir et documenter des API en y incluant le code source. En 2016, des géants du secteur (Google, Microsoft, etc.) rejoignent l’initiative pour la faire évoluer. La spécification Swagger, alors renommée Spécification  OpenAPI définit, pour les API les plus courantes (de type REST / HTTP), un standard utilisé par les humains comme par les machines.

Lors du développement d’une nouvelle application, il est assez simple de produire la documentation de son API en OpenAPI, à l’aide de librairies logicielles, telles que SpringDoc. En effet, il suffit d’inclure ce type de librairie dans les dépendances de la nouvelle application, et d’utiliser les annotations adéquates, pour que la documentation soit automatiquement générée. Ainsi, les nouveaux web services développés par l’Abes – et bientôt utilisés par l’outil de curation paprika.idref.fr, intègrent une documentation OpenAPI :

En revanche,  cette transformation s’avère plus compliquée pour les API plus anciennes : celles-ci n’utilisant pas forcément de framework  (de type Spring), il n’y a pas de moyen automatique et simple pour produire la documentation OpenAPI. L’effort de rédaction étant plus conséquent, il a été décidé de documenter en priorité les web services les plus utilisés.  Cette démarche s’appuie sur l’éditeur d’OpenAPI, Stoplight, outil gratuit pour la conception de documentation OpenAPI « à la main », via des formulaires qui aident et contrôlent la saisie. Ces documentations sont ensuite versionnées sur un espace Github dédié : https://github.com/abes-esr/openapi

Publication des OpenAPI de l’Abes sur api.gouv.fr

Pour publier les OpenAPI, le choix du site api.gouv.fr  s’est naturellement imposé, le site référençant les API du service public (collectivités, ministères, entreprises…) pour construire des services informatiques pour tous. De plus, les fonctionnalités disponibles facilitent largement l’usage et l’accès aux web services concernés.

Lors du chargement des OpenAPI sur api.gouv.fr,  un formulaire interactif est généré. Celui-ci liste les web services composant l’API et fournit, lorsque c’est pertinent, les liens vers la documentation HTML. Il est facile de saisir rapidement la structure et le fonctionnement de chacune des API, chaque paramètre possédant également sa description et une valeur exemple. Lorsque c’est nécessaire, une expression régulière donne le format attendu. A l’aide de ce formulaire, il est même possible de tester directement un appel au web service.

Retrouver les API mises à disposition sur api.gouv.fr :

 

Continuer la lectureLes API de l’Abes disponibles au format OpenAPI sur api.gouv.fr

« Épatant : ça nous bouge ! » : les ressources continues, en direct de la BnF et d’ISSN France

  • Auteur/autrice de la publication :
  • Post category:Non classé

Épatant : ça nous bouge !

Tel est le titre de la première notice en provenance d’ISSN France importée directement dans le Sudoc (PPN 260627062 ; ISSN 2804-715X). En l’occurrence, il s’agit d’un site web, occasion de rappeler que les ressources continues ne se limitent pas aux publications en série et aux collections, mais incluent aussi les « ressources intégratrices », c’est-à-dire des ressources dont le contenu peut être augmenté ou modifié par des mises à jour.

Cette intégration directe constitue une évolution fondamentale, la première de cette importance depuis la mise en place du Catalogue collectif national des publications en série (CCN-PS), ancêtre du Sudoc en matière de signalement et de localisation des ressources continues dans les bibliothèques françaises.

copie de la notice dans winibwi
Copie de la notice dans WinIBW : on remarque le lien vers le site, mais aussi vers sa version archivée via Internet Archive. A noter : la notice ne sera disponible dans le Sudoc public qu’une fois « localisée ».

Continuer la lecture« Épatant : ça nous bouge ! » : les ressources continues, en direct de la BnF et d’ISSN France
Aller au contenu principal