Cegid XRP Ultimate  |  I3   Actualisé le 06/10/2022
	Fondations
Superviseur d'environnements : Propagation

Généralités

Prérequis

Compétence

Version

Environnements nécessaires

Schéma de principe

Règles à respecter

Changement de version

Paramétrage multi-lots

Droits nécessaires sur les bases de données

Utilisation

Liste des tables

Consultation des propagations

Création d'une liste de tables

Création des tables de trace

Nombre de lignes modifiées

Détail des modifications

Extraction du paramétrage

Propagation du paramétrage

Epuration des tables de la propagation

Suppression des tables de la propagation

Maintien de la structure des tables de la propagation

Généralités

Le Module "Superviseur d'environnements : Propagation" permet : - de copier du paramétrage d'un environnement modèle vers un autre dans le cadre d'une évolution du paramétrage actuel ou dans le cadre d'un nouveau projet ; - d'aligner le paramétrage entre tous les environnements ; - d'enrichir la solution avec de nouvelles fonctionnalités.    Les grandes étapes se décomposent ainsi : - Identification des tables et du contenu des tables concernées par le nouveau paramétrage ; - Extraction dans un fichier du nouveau paramétrage depuis une date ou jusqu'à une date ; - Importation de ce nouveau paramétrage dans l'environnement de pré-production pour validation, puis dans l'environnement de production.    Techniquement, des triggers sont positionnés, afin de mémoriser toutes les créations, modifications et suppressions issues de l'évolution du paramétrage courant.

Exemple de fonctionnement de la mémorisation du paramétrage de la table OECPT (Comptes comptables)

Chaque modification de la table OECPT est tracée dans la table TRC_OECPT avec les informations suivantes : date, qui, quoi (I/U/D).

Prérequis

Compétence

Pour bien utiliser cet outil, il est nécessaire de connaître le schéma de base de Cegid XRP Ultimate.

Version

Les bases de données concernées par la propagation du paramétrage doivent être dans la même version de release et avec un niveau de patchs identique.

Environnements nécessaires

Quatre environnements avec chacun un rôle précis :      QUATST    Test      QUAREF    Référence      QUAREC   Recette      QUAPRD   Production    Avant de mettre en place les tables/triggers qui vont mémoriser tout le paramétrage, il faut au moins quatre environnements, sachant que l'environnement QUAREF est une copie de la base de données de production QUAPRD. En effet, la base de données de référence QUAREF doit être "iso paramétrage" avec la base de production QUAPRD au moment de la mise en place du Module "Superviseur d'environnements : Propagation".    Descriptif des environnements :    - l'environnement QUATST est la base de données de test pour la saisie du paramétrage ;    - l'environnement QUAREF sert à saisir le paramétrage après l'avoir testé sur la base de données de test. C'est l'environnement qui est tracé avec les tables et les triggers (en insertion/modification/suppression) ;    - l'environnement QUAREC est une copie très récente de l'environnement QUAPRD, cet environnement est utilisé pour valider la propagation du paramétrage autant de fois que cela est nécessaire ;    - une fois que le paramétrage est validé sur l'environnement QUAREF, il peut être propagé sur l'environnement de production QUAPRD.

Schéma de principe

Règles à respecter

Le paramétrage est à proscrire sur les environnements cibles.    Il est nécessaire d'avoir un suivi rigoureux et de régenter des opérations sur l'environnement de référence --> Journal des opérations.    L'environnement de référence est unique.    Les correctifs de paramétrage sont toujours réalisés sur la base de données de référence.    Fonctionnement par jalon (checkpoint) --> production d'exports cumulables.    Jalon obligatoire avant un passage de bundle et si cela est nécessaire juste après.    Les imports doivent obligatoirement se faire en respectant la chronologie des jalons et des passages de bundles.    Il n'est pas possible de passer partiellement le paramétrage. Tout le paramétrage fait sur l'environnement de référence doit être propagé.

Changement de version

Il n'est pas possible de conserver le journal des modifications dans la base de données de référence lors d'une montée de version. Il faut dans ce cas : 1. Effectuer toutes les propagations sur les bases de données cibles avant ; 2. Supprimer le journal des modifications avant la montée de version. Après la mise à jour, il sera possible de réinitialiser l'outil de propagation afin de démarrer un nouveau paramétrage.

Paramétrage multi-lots

Il est possible de démarrer le paramétrage de différents lots sur la base de données de référence unique. Mais, il faut saisir le paramétrage avec des utilisateurs différents.    Il y aura toujours des risques de pertes de paramétrages : - les données communes multi-lots seront créées par le premier utilisateur et ne seront pas transportées par les autres utilisateurs ; - certaines données créées par un utilisateur pourront être modifiées par un autre utilisateur ou par l'outil de patchs.    Dans ce cas, le Module "Superviseur d'environnements : Comparaison" permettra de mesurer la complétude de la propagation et de corriger si nécessaire le paramétrage manquant. En conclusion, il est conseillé d'extraire les données uniquement de façon chronologique.

Droits nécessaires sur les bases de données

L'outil de propagation crée des tables, des index, des triggers et une séquence. Ces objets ne sont pas créés sous le schéma ADMIN de Cegid XRP Ultimate. Donc pour commencer, il faut choisir un utilisateur sous lequel tous ces objets seront créés. Il s'agit de l'utilisateur connecté à l'interface utilisateur précédé du radical "TRT$". Une fois l'utilisateur choisi, l'outil de propagation devra toujours être lancé avec le même utilisateur.    Voici les droits à positionner avant l'initialisation de l'outil. Ces droits sont positionnés sur le compte SGBD TRT$<UTILISATEUR>.    Avec ORACLE :    - sur la base de données de référence :       grant unlimited tablespace to TRT$<UTILISATEUR>      grant create table to TRT$<UTILISATEUR>      grant create any trigger to TRT$<UTILISATEUR>      grant create sequence to TRT$<UTILISATEUR>      grant select on dba_objects to TRT$<UTILISATEUR>    - sur la base de données cible :       grant IACALL to TRT$<UTILISATEUR>      grant ALTER ANY TRIGGER to TRT$<UTILISATEUR>    Avec SQLSERVER :    - sur la base de données de référence :       CREATE SCHEMA TRT$<UTILISATEUR> AUTHORIZATION TRT$<UTILISATEUR>      EXEC sp_addrolemember 'db_ddladmin', N'TRT$<UTILISATEUR>'    - sur la base de données cible :       sp_addrolemember IACALL, TRT$<UTILISATEUR>

Utilisation

Liste des tables

Les requêtes qui constituent les listes des tables à propager s'appuient sur le contenu de la table technique GTTRC (consultation CTTRC). Cette table contient tous les objets compilés dans la base de données et en particulier les tables (Type : U). La consultation CTTRC permet ainsi d'identifier toutes les tables liées à une application, à une catégorie ou à une nature. Le libellé des tables permet également de faire le lien entre une fonctionnalité et les tables impactées par un paramétrage.

Consultation des propagations

Avec la transaction CMIOPE, il est possible de consulter toutes les extractions déjà effectuées sur la base de données de paramétrage.    Il est également possible de consulter toutes les propagations de paramétrage déjà effectuées sur les bases de données cibles.    Le type "E" correspond aux extractions. Le type "P" correspond aux propagations.

Création d'une liste de tables

La création d'une liste de tables à propager se fait à l'aide des transactions GMIELT et GMILST.    Création d'une liste de tables avec GMIELT après avoir saisi le nom de la liste et son commentaire : - ne pas cocher la case "STR/PAR" ; - utiliser % pour toutes les tables dans le radical ; - puis cliquer sur "Générer".    Remarques importantes :    Comme il est très difficile de connaître avec exactitude toutes les tables impactées par un nouveau paramétrage, il est préférable, afin de ne rien oublier, de tracer toutes les modifications de toutes les tables.    Les tables contenues dans la liste "PROPAG_EXCLUDE" sont exclues. Cette liste est créée et maintenue uniquement par Cegid. C'est une liste de tables qu'il faut exclure dans tous les cas de la propagation. Si cette liste de tables n'existe pas, vous pouvez la générer en compilant le fichier "mir_ins_milst.obj" sur le serveur de traitements (pln mir/maj/mir_ins_milst.obj).    Il est possible à partir de la transaction GMIELT de manipuler des listes de tables en création, suppression ou duplication.    Il est conseillé de créer deux listes de tables :      - Liste ALL : contient toutes les tables tracées ;      - Liste EXTRACT : dupliquée à partir de la liste ALL. C'est cette liste qui est utilisée pour extraire le paramétrage. Les tables qui ne doivent pas être exportées sont éliminées de cette liste.

Création des tables de trace

Dans GENVP, l'action "Installation" crée pour la liste ALL saisie dans GMIELT toutes les tables, index, triggers qui permettront de mémoriser les modifications.

Nombre de lignes modifiées

Dans GENVP, pour la liste EXTRACT saisie dans GMIELT, l'action : - "Nbe d'enreg. tracés" recense toutes les modifications de la base de données ; - "Nbe d'enreg. non exportés" recense toutes les modifications de la base de données qui n'ont pas encore été extraites.    Il est également possible : - d'identifier les modifications à une date donnée ; - de les identifier pour une liste de tables ou pour une seule table ; - de les identifier pour un utilisateur.    Extrait du compte rendu

Détail des modifications

Dans GENVP, pour la liste EXTRACT saisie dans GMIELT, l'action : - "Liste des enreg. tracés" détaille toutes les modifications table par table ; - "Liste des enreg. non exportés" détaille toutes les modifications table par table qui n'ont pas encore été extraites ; - "Liste des extractions" donne la liste des extractions déjà effectuées dans l'ordre chronologique ; - "Liste des extractions détaillées" donne la liste des extractions déjà effectuées avec leur contenu table par table.    Il est également possible : - d'identifier les modifications à une date donnée ; - de les identifier pour une liste de tables ou pour une seule table ; - de les identifier pour un utilisateur.    Extrait du compte rendu

Extraction du paramétrage

Dans GENVP, pour la liste EXTRACT saisie dans GMIELT, l'action "Extraction" extrait sur le serveur de traitements tout le paramétrage dans le fichier $IAC_HOME/qenvironnements/propagation/qen_YYYYMMDDhhmmss.txt.    Il est possible d'extraire uniquement le paramétrage manquant avec l'action "Extraction enreg. non exportés".    Il est également possible : - d'identifier les modifications à une date donnée ; - de les identifier pour une liste de tables ou pour une seule table ; - de les identifier pour un utilisateur.    Attention :    Avant d'extraire le paramétrage de la base de données de référence, il est conseillé de vérifier par le moyen de l'action "Nbe d'enreg. tracés" les tables à propager. En général, il faudra enlever certaines tables de l'extraction, parce qu'elles correspondront par exemple à un jeu de test, qui n'est pas du paramétrage. Pour cela, il faudra dans GMIELT, dupliquer la liste de tables qui a servi à initialiser le Module "Superviseur d'environnements : Propagation" et créer une liste qui correspondra aux tables à extraire (Exemple : Liste EXTRACT). Dans cette liste, il sera possible ainsi de supprimer les tables qui ne correspondent pas au paramétrage à propager.    Il ne faut extraire que le paramétrage. Il ne faut donc pas extraire des données d'exploitation et du référentiel qui altèreraient considérablement les données de production. Pour cela, il sera nécessaire de modifier au fur et à mesure la liste des tables.    Il est possible d'extraire le paramétrage d'un seul utilisateur (champ "Utilisateur"). Mais il faut que seul cet utilisateur travaille sur un même type de paramétrage, et il faut également que cet utilisateur ne travaille pas sur des données communes avec un autre utilisateur, sinon il est fort probable que des portions de paramétrage ne soient pas extraites.    Il est possible d'extraire des portions de paramétrage par date, mais là encore il faut faire très attention à ne pas faire des "trous" dans le paramétrage, sinon la base de données où sera propagé le paramétrage sera incohérente.    Extrait du compte rendu

Propagation du paramétrage

Dans GENVP, l'action "Propagation" ou "Simulation de la propagation" propage, ou simule, le paramétrage contenu dans le fichier passé en paramètre dans la base de données de destination.    Le format à respecter pour la base de données de destination afin de propager le paramétrage est le suivant : Sur Oracle : ORA://<MAC>:<PORT>/<BASE> Sur SQLServer : MSQ://<MAC>:<PORT>/<BASE>    Remarque :    Il est possible de marquer les données insérées ou modifiées dans la base de données de destination, en renseignant le champ "Utilisateur". Lorsque l'utilisateur est renseigné, les lignes de données créées auront les champs :      ucr<table>=<La valeur du champ "Utilisateur">      dcr<table>=<date du jour>      udm<table>=null      ddm<table>=null Lorsque l'utilisateur est renseigné, les lignes de données modifiées auront les champs :      udm<table>=<La valeur du champ "Utilisateur">      ddm<table>=<date du jour>    Si le champ "Utilisateur" n'est pas renseigné dans GENVP, on conserve les valeurs d'origines.    Une extraction est faite pour une version majeure et pour une version de patch. Un contrôle est donc fait lors de la propagation du paramétrage afin de vérifier que le paramétrage exporté est compatible pour la base de données cible.    Extrait du compte rendu

Epuration des tables de la propagation

Dans GENVP, l'action "Suppression" permet d'épurer les tables de paramétrage de la propagation à partir d'une liste et éventuellement d'une date de début ou de fin. Cette action est soumise à confirmation parce qu'elle est à manipuler avec précaution.

Suppression des tables de la propagation

Dans GENVP, l'action "Désinstallation" permet de supprimer les tables de paramétrage de la propagation à partir d'une liste. Cette action est soumise à confirmation parce qu'elle est à manipuler avec précaution.

Maintien de la structure des tables de la propagation

Dans GENVP, l'action "Révision" permet de maintenir la structure des tables après la livraison d'un bundle. Dans ce cas la structure de la table de trace est remise en phase avec la table origine. Cette action est à lancer après chaque bundle appliqué sur la base de données de référence.