Diagnostique et réparation d’un projet associé à Epicraft
À quoi sert l’outil?
Certains projets ont plusieurs années et des divergences de comportements ont pû survenir entre plusieurs versions.
Il peut également arrivé que parfois, un accident puisse se produire sur une installation.
Cela peux venir d’un bug du logiciel, d’un incident serveur, d’une erreur humaine, etc… mais dans tous les cas, ce sont des choses qui arrivent et parfois, une restauration de la base de donnée n’est pas suffisante (ou n’est pas adapté au problème rencontré).
Le but de cet outil est de faciliter l’identification des problèmes et la réparation des projets endommagés (ou de confirmer son bon fonctionnement).
Pour cela, il va recréer tous les XML d’un projet depuis sa création jusqu’à la dernière action jouée sur l’environnement.
Ces XML sont ensuite stockés dans un dossier pour permettre une analyse plus poussée.
L’outil va:
- générer tous les XML d’un projet.
- stocker ses XML dans un dossier à disposition des développeurs.
- comparer ses XML avec ceux trouvables dans les ressources du projet.
- donner la possibilité de corriger directement les formulaires qui auraient besoin d’être retouchés.
L’outil ne va pas:
- faire de modifications de lui-même, chaque retouche doit d’abord être validée par l’utilisateur.
- agir sur les XML des varsets.
Pour éviter tout problème avec les données, c’est au développeur d’analyser les différences trouvées et d’effectuer les corrections nécessaires. - agir sur les dictionnaires.
Utilisation
Dans un premier temps, il faut configurer le projet pour que l’outil puisse communiquer avec le serveur d’Epicraft.
Pour cela, il faut que le mode “pull” soit correctement configuré dans les paramètres généraux du projet.
Une fois la configuration faite, l’outil peux être lancé en ligne de commande.
# remplacer le chemin vers voo4_cli.php selon l'installation du serveur
php /var/www/app/resources/cron/voo4_cli.php mtd=repair project_name=sandbox
www-data ait accès en écriture à cet endroit.Le paramètre project_name correspond au nom du projet que l’on souhaite réparer.
Pour ne pas se tromper, le plus simple est de vérifier le nom dans la table sys_project de l’application.
Resultat
Après que la regénération des XML est faite, chacun va être comparé avec ceux trouvables et utilisés par le projet et un rapport complet est fournit.
Tout est en règle
Des différences sont identifiables
Analyse des cas d’anomalies possibles
Pour effectuer les opérations de réparation, l’outil utilise les fonctions du noyau Voozanoo4.
Tout est monitoré et les ressources supprimées sont retrouvables dans la table {pj}_resource_deleted.
Varset
Toute modification est à faire manuellement par le développeur, en toute connaissance des conséquences (risque d’impacter les données).
Pour l’aider dans sa tâche, un diff est généré, ligne par ligne, entre le XML trouvable en bdd et celui généré par l’outil.
Voici un exemple simple de ce que donne le diff:
Ici, l’attribut default_label est différent sur la variable champ_h9a5.
Le formulaire est manquant
Lorsqu’un formulaire n’est pas trouvable dans la base de donnée par son identifiant, l’outil va proposer de l’ajouter directement.
Le formulaire est différent de celui regénéré
Une analyse est faite, ligne par ligne, du XML et un diff est mis à disposition dans le dossier généré.
L’outil va proposer de remplacer le XML par sa version “propre”.
Un formulaire est en “trop”
Une analyse des ressources de la base de donnée est faite pour en extraire des possibles doublons, ou une suppression de formulaire qui ne se serait pas produite.
L’outil va proposer de supprimer les XML en trop.