Suppression d'objets sous P5
Rappels d’architecture
L’architecture du progiciel Planisware 5 repose sur une base de données contenant des tables indépendantes (une par classe d’objet). Les relations entre objets sont gérées exclusivement par la couche logicielle (il n’y a pas de relations directement implémentées dans le SGBD).
Lors de la suppression d’un objet complexe (lié à d’autres objets) c’est le noyau logiciel qui va, dans la plupart des cas, vérifier que l’objet que l’on veut supprimer n’est pas encore lié à d’autres objets de l’application. Dans le cas où un autre objet de l’application utilise l’objet à supprimer, P5 remonte en général une erreur ou un avertissement précisant le nom de cet objet.
Par exemple si l’on souhaite supprimer une ressource il faudra au préalable supprimer toutes les affectations de cette ressource.
Limites :
Dans certains cas, P5 ne remonte pas tous les objets en relation avec l’objet à supprimer et la suppression peut engendrer des problèmes. C’est souvent le cas lorsque l’on supprime un utilisateur par exemple.
Au démarrage, lorsque P5 charge les données et les objets d’environnement, ces problèmes de dépendance sont remontés dans les logs ou dans une pop-up d’alerte. P5 gère généralement ces exceptions en recréant de manière temporaire (limité à la session ouverte) les objets manquant sous le libellé « INCONNU-XXXXXXXXXX » avec XXXXXXXXXX l’ONB de l’objet qui a été supprimé.
Exemple d’un objet temporaire créé par P5
Dans de rares cas, P5 ne gère pas ces exceptions. Il génère alors un rapport d’erreur et tente de redémarrer en boucle. Dans ce cas, la seule solution pour débloquer l’application consiste à analyser le log pour identifier l’objet qui pose problème (il possède un lien vers un objet supprimé) et de le supprimer.
Pour prévenir ce genre de problème on peut également rajouter du paramétrage permettant de contrôler les conditions de suppression des objets complexes (alertes, verrous etc.).
Suppression logique / physique
La suppression des objets dans P5 est une suppression logique. Pour rappel chaque objet possède un champ « DATASET » qui correspond à l’ONB (numéro interne unique) de son « Fichier » de rattachement. Le fichier de rattachement peut-être un fichier projet un fichier commun ou un fichier d’environnement. Seuls les objets appartenant à des fichiers chargés au démarrage sont accessibles dans l’interface P5. Ainsi la suppression d’un objet dans P5 revient à passer le champ « DATASET » de l’objet supprimé en négatif pour que l’objet ne soit plus accessible.
Processus de suppression d’objet sous P5
La suppression physique (c’est à dire des objets en BDD) n’est pas automatique. Il est nécessaire de purger régulièrement directement en BDD les objets supprimés logiquement dans P5. Pour cette suppression Planisware met à disposition un script SQL. Ce script est mise en place lors de l’installation du module Connect. Par exemple sous oracle il s’agit du script « generate-delete-negative-dataset.sql ». Celui-ci génère un script de sortie permettant la suppression des objets possédant un dataset négatif pour chaque table de la BDD de P5.
Le script généré contiendra des commandes du type suivant :
…
DELETE FROM TASK where DATASET<
0;
DELETE FROM TASK_ALLOC where DATASET<
0;
DELETE FROM TC_RESOURCE where DATASET<
0;
DELETE FROM TC_WORK_STRUCTURE where DATASET<
0;
DELETE FROM TRACE_MODIF where DATASET<
0;
DELETE FROM TRANSACTION_LOG where DATASET<
0;
DELETE FROM TRANSACTION_READER where DATASET<
0;
…
Ce script ne peut bien évidemment pas être générique car, au modèle de données standard (nécessaire au noyau P5), peut s’ajouter les tables liées à Processes, mais aussi les tables spécifiques mises en place lors du paramétrage du progiciel.
Ce processus de séparation entre les suppressions logique et physique peut sembler contraignant. Il permet cependant de conserver en BDD la trace des objets supprimés dans l’application tant que la purge de ces objets n’a pas été décidée.