@Nicolas Thouvenin Nicolas Thouvenin authored on 29 Nov 2022
apil-dumps refactor: use makefile 1 year ago
bin fix: strict grep 1 year ago
corhal-dumps fix: -f is better 1 year ago
doiwos-dumps docs(doiwos-dumps): Add README 1 year ago
halcnrs-dumps feat: import dumps for hal cnrs 1 year ago
halinria-dumps fix: use var 1 year ago
wos-dumps refactor: use makefile 1 year ago
.gitignore restructuration 1 year ago
Makefile restructuration 1 year ago
README.md docs: Add best practices 1 year ago
apil-dumps-config.json update confs 1 year ago
corhal-dumps-config.json clarification et simplificiation des critères 1 year ago
doiwos-dumps-config.json fix(doiwos): zip URL was wrong 1 year ago
halcnrs-dumps-config.json update confs 1 year ago
README.md

Web-dumps

Le dépôt tdm/web-dumps contient les programmes de plusieurs procédures automatiques de collecte et d'enrichissement de données.

Ces procédures, dont le principe est similaire, sont chacune rangée dans un répertoire de premier niveau.

.
├── apil-dumps
├── apil-dumps-config.json
├── corhal-dumps
├── corhal-dumps-config.json
├── halcnrs-dumps
├── halcnrs-dumps-config.json
├── halinria-dumps
└── wos-dumps

Principe

Chaque répertoire est destiné à être déployé dans une instance de l'application lodex-contab sur ezMaster.

À intervalle régulier, les scripts ezs sont executés. Leur objectif est en général de télécharger des nettoyer, éventuellement de les nettoyer, de les reformater, et de les enrichir.

Ces intervalles sont paramétrables très finement.

Les requêtes exécutées par les scripts peuvent ramener des données différentes à chaque fois (les données les plus récentes) ou bien les mêmes, en fonction d'un fichier de paramétrage dont la nature peut varier selon les procédures.

Il y a deux modes à ces procédures:

  1. exécution d'un script particulier
  2. obtention d'un fichier particulier, en fonction d'une table d'identifiant / d'un fichier contenant une requête / ou autre.

Dans le deuxième cas, on n'exécute la procédure que si le fichier dont elle dépend a changé.

Les procédures étant déployées sur un serveur (avec ezmaster), elles ont l'avantage de pouvoir durer autant que nécessaire, et ne sont pas contraintes par l'extinction ou la mise en veille d'un poste de travail à la fin d'une journée de travail, voire la perte de réseau lors d'un déplacement.

Développement

Chaque nom de répertoire doit être en deux parties, séparées par un tiret.
Ceci pour respecter la nomenclature des instances dans ezmaster.

Créer une version

Afin de faciliter le déploiement (et de le limiter à un répertoire), on peut utiliser les helpers du Makefile (make version-major, make version-minor, make version-patch).

Ils se chargent de mettre un tag git sur un répertoire et de le pousser sur le dépôt. Leur seul paramètre est le nom du répertoire.

Exemple:

$ make version-major giec-wos
Décompte des objets: 1, fait.
Écriture des objets: 100% (1/1), 185 bytes | 185.00 KiB/s, fait.
Total 1 (delta 0), reused 0 (delta 0)
remote: Updating references: 100% (1/1)
To ssh://gitbucket.inist.fr:22222/tdm/web-dumps.git
 * [new tag]         giec-wos@1.0.0 -> giec-wos@1.0.0
Nouvelle version créée: giec-wos@1.0.0
URL à utiliser: https://gitbucket.inist.fr/tdm/web-dumps/archive/giec-wos/giec-wos@1.0.0.zip

L'URL fournie sert à la configuration de l'instance, et permet la mise à jour du programme.

Il suffit de la coller dans la clé files.zip de l'instance de lodex-crontab.

Bonnes pratiques

Mettre un fichier de configuration d'exemple, au même nom que le répertoire + .json pour qu'on puisse le copier et l'adapter dans la configuration de l'instance dans ezMaster.
Cette configuration doit contenir les paquets npm nécessaires à l'exécution des scripts.

Numéroter les fichiers de données produits en fonction des numéros des étapes qui les ont produits.

Numéroter les scripts ezs selon les étapes qu'ils représentent (un nombre à deux chiffres au début du nom du fichier, comme pour les données qu'ils produisent).

Documenter chaque procédure, dans un README à l'intérieur de son répertoire.