Skip to content

Automatisation Colodus/JavaScript : limites, problèmes et prospectives

08/10/2015

Tous les billets de la série « Automatisation Colodus avec JavaScript »

Problèmes

Nombre de caractères dans l’URL d’un favori sous Firefox : il n’est pas possible de charger toute une bibliothèque via un favori Firefox, même en le laissant tourner  plusieurs jours : le nombre de caractères dans un favori est limité à 65536 caractères. Et quand on y stocke des données d’exemplaires, ça peut aller assez vite

Ralentissements quand un script contient trop d’exemplaires : c’est plus problématique. Au fur et à mesure que les exemplaires défilent, la vitesse d’exécution ralentit (je suppose que c’est dû à une mémoire cache qui s’alourdit peu à peu, ou quelque chose comme ça). Plus le script contient d’exemplaires, plus le temps moyen passé par exemplaire s’allonge (même si en début de script les premiers exemplaires traités sont toujours très rapides).

Nb d’exemplaires à traiter temps (secondes) Temps (secondes) / exemplaire
10 34 3,4
20 105 5,25
30 180 6
40 325 8,125
50 495 9,9

bookmarklet colodus - temps par exemplaire

Zone L035 : la création de données locales génère des pop-ups d’erreurs. Pourtant quand on les ferme ou qu’on les bloque, ça n’empêche manifestement pas la création correcte de la zone locale.

J’ai mis du temps à comprendre d’où vient le problème : les pop-up apparaissent à partir de la 2e création de zone L035 (dans le 2e PPN, donc). Et à chaque nouvelle zone se rajoute une pop-up supplémentaire (lors du 4e PPN, il y aura 3 pop-up).
S’il faut les fermer à la main, ça devient vite désespérant. La solution que nous avons trouvée pour l’instant est d’installer sur les postes qui font tourner ces script une extension Firefox qui bloque très strictement les pop-up de Colodus lors du lancement du script.
Voici comment j’ai cru comprendre la raison du problème : lorsque le script donne pour consigne d’enregistrer la zone de données locales (cliquer sur le bouton « enregistrer les données locales ») il n’imite pas exactement l’action d’un internaute cliquant sur « Enregistrer ». Du coup le code de la page HTML est modifié est garde en mémoire la consigne de créer une zone L035. Lors de la création de la L035 suivante, le code précédent est toujours dans la page, et la validation de la 2e zone envoie au serveur Colodus l’ordre simultané de créer 2 L035… Mais bon, ça n’empêche pas de créer pour autant la bonne zone, alors en attendant mieux on se contente de bloquer l’affichage de la pop-up. Ce n’est pas satisfaisant, mais ça fonctionne..

Pistes d’amélioration

Authentification : nous avions envisagé que l’exécution des scripts soit centralisée (une personne se chargeant de les faire passer pour l’ensemble des RCR). Mais je craignais un peu la confusion dans l’utilisation successive de logins propres à chaque RCR. Du coup le login est mis dans le script, ce qui n’est pas forcément sécurisé. Je suppose qu’il est possible de déporter la gestion des mots de passe sur un serveur, mais je ne sais pas faire !

Contrôles bibliographiques : les rapports Aleph qui génère le code JavaScript contiennent aussi la liste des notices concernées, et pour chaque notice ils effectuent un certain nombre de contrôle qualité sur les notices Sudoc. Du coup nous avons dû réécrire ce qui a déjà été fait par ailleurs pour l’application CheckSudoc. L’idéal serait donc qu’une API soit développée pour CheckSudoc, afin qu’on puisse s’en servir non seulement comme interface web, mais aussi par le biais d’applications de type SIGB, afin de pouvoir exploiter ses contrôles depuis une application de ce genre (et tant qu’à faire avec des options sur le niveau d’exigence que l’on souhaite mettre en place…).

Mutualisation du code : si l’interface Colodus évolue, le code JavaScript qui agit sur ces pages devra évoluer aussi. Donc si une telle solution technique est déployée pour plusieurs types de situations (acquisitions, pilon, recotation) et dans plusieurs établissements, ça veut dire autant de mises à jour à reporter systématiquement. L’idéal serait donc de gérer les fonctions elles-mêmes de manière centralisée, et que le script les invoque au moment de les exécuter, sans qu’il soit nécessaire de les reproduire à l’identique dans chaque bookmarklet (l’appel de l’URL du fichier qui les contient suffirait alors).
Un tel fichier permettrait de mutualiser aisément la mise à jour des fonctions.
Et j’en profite pour glisser que l’idéal serait qu’à terme il ait une URL en http://*.abes.fr, car c’est l’Abes qui est la plus à même de voir arriver des évolutions dans le code des pages de Colodus. Ces fonctions JavaScript pourraient même être nativement intégrées à l’interface (il y a déjà un nombre considérable de fonctions JavaScript qui font tourner Colodus !)

Fonctions avec des paramètres vides : notamment pour la fonction FormExemplaire() qui alimente le formulaire de création d’exemplaire sous Colodus. Le SCD de Nice indique systématiquement, pour chaque exemplaire, 6 informations : Bibliothèque, localisation, cote, n° d’inventaire, code-barres et règle de PEB. De nombreuses bibliothèques ne mettent dans le Sudoc que la mention de site, ou site + localisation, ou site + localisation + cote (+ PEB à chaque fois, bien sûr). La fonction devrait tenir compte de l’hpothèse que certains paramètres attendus (CB et n° d’inventaire notamment) soient vides, et ne générer ces champs dans Colodus que si nécessaire.

Adoptez un script !

2 scripts pour le prix d’un. Kitten – photo Viola’s Visions — CC-BY-NC-SA-2.0

Si j’ai mis en ligne tous ces billets, ce n’est pas pour vous dire : regardez comme on est trop forts. L’objectif, c’est évidemment que d’autres établissements puissent s’emparer de cette possibilité, sans y passer tout le temps que j’y ai moi-même consacré, pour l’adapter à leur situation propre (circuits, intervenants, type de données concernées, etc.).

C’est clair qu’il manque un mode d’emploi simple, un how to pour implémenter tout ça chez soi.

Je veux bien bosser avec les établissements intéressés pour les accompagner dans cette mise en oeuvre, à condition qu’ils contribuent à documenter (relativement à leur situation propre et à leur SIGB) la manière dont d’autres bibliothèques pourraient faire comme eux. Les premières expériences d’appropriation du code permettrait justement de rédiger un tel mode d’emploi.

Publicités
3 commentaires
  1. B. Majour permalink
    09/10/2015 18:10

    Bonjour Lully

    Oui, un favori sous Firefox doit bien avoir une limite. (celui d’une taille de chaîne de caractères, soit la limite que tu as trouvée)
    Ce n’est pas non plus fait pour faire tourner un script java volumineux. 🙂

    Si j’ai bien compris l’utilisation du favori, c’est pour être positionné sur la page Colodus avant de le lancer.

    Mais, en javascript, tu peux tout à fait ouvrir une page html à l’intérieur, donc ta page Colodus, et ensuite lancer toute ta procédure… sans restriction de longueur.
    A partir de là, il te suffirait de stocker tout ce qu’il faut dans une page html classique « lancement », d’ouvrir cette page « lancement » qui va ouvrir Colodus, se connecter, lancer les actions.

    De la même façon, on peut appeler un sous-programme installé dans un fichier du disque. Et donc ton favori se résumerait à un javascript qui dirait : « lancer le sous-programme dans le fichier du dossier Abes ».

    Et là, tu pourrais avoir tout ce que tu veux dans ce sous-programme, sans aucune limitation de caractères.

    C’est ce que tu fais quand tu appelles une fonction, exemple Jquery. Tu n’as pas tout le code de la fonction Jquery copié dans le favori.

    Voilà ce que tu devrais regarder : appeler un fichier javascript externe
    http://www.commentquonfait.com/question-27-appeler-un-fichier-javascript-%28-js-%29-externe-.html

    Pour le ralentissement en temps, tu peux aussi avoir un problème d’ajout dans la base de données. Tu as plus de chance de rencontrer du monde aux heures de pointes qu’aux heures creuses.
    Et il faut gérer le passage de tout le monde. A essayer sur un créneau où il y a moins de monde sur Colodus.

    Pareil tu peux avoir un temps de latence du réseau, invisible quand les changements sont courts et peu nombreux, mais qui augmente si le flux des données est important et soudain.
    Un peu comme toi, quand tu emplis ta bouche d’eau avec un verre d’eau. Un peu, c’est avalé en quelques déglutitions, beaucoup ou le verre complet, tu vas déjà essayer de ne pas te noyer.
    Donc tu vas retenir de l’eau en bouche, avant d’avaler. Tu bufferises (tu temporises en stockant).

    Sur un ordinateur, quand ça bufferise trop, ça écrit des fichiers sur le disque ou en mémoire tampon => (avec les fichiers disque on passe de la nano secondes à la milli seconde, facteur énorme de latence : 1 000 000 ! Quand on en veut trop 😉 )

    Et tu as raison, les popups augmentent aussi la consommation de mémoire, en particulier l’affichage. Et comme tu as une limite au nombre de fenêtres ouvertes possibles, ça risque de plouffer !

    Après, tu as raison :tu as le problème lié à tous les automates.
    Si les concepteurs du logiciel changent la place des boutons, change l’ordre de validation, ton script boit le bouillon (private joke ;o))

    Toi, tu sais comment faire pour corriger, mais tes autres collègues seront vite dans la panade.
    Comme tu le sens bien, il faudrait que les concepteurs du logiciel intègrent cette manip dans leur système.

    Récupération d’un fichier géré par une application extérieure, pour intégration directe dans les bases de données.

    Montre-leur ce que tu fais avec ton script, et ils devraient comprendre tes besoins. (vos besoins). D’ailleurs ce genre de besoin me semble évident rien que pour éviter des erreurs de saisies. Je ne comprends même pas que ce ne soit pas déjà implanté et que personne ne l’ait réclamé. C’est peut-être trop évident.

    L’automate, c’est du bricolage… mais du bricolage utile. 🙂
    B. Majour

  2. 13/10/2015 11:50

    Bonjour Étienne,
    question idiote par rapport a tout cela, pourquoi l’utilisation de bookmarklets plutot qu’un script GreaseMonkey par exemple, qui il me semble ferait sauter un certain nombre de limitations des bookmarklets?

  3. 13/10/2015 12:15

    @symac : dans le fonctionnement actuel, les collègues sont autonomes pour récupérer les scripts et les exécuter. D’autres outils plus avancés nécessiteraient, je pense, une centralisation (que ce soit des scripts Python ou l’utilisation de GreaseMonkey) et nous n’étions pas en mesure d’évaluer si c’était pertinent.

Commentaires fermés

%d blogueurs aiment cette page :