Formations techniques Harpège Version 1.11.2 Formations techniques Décembre 2004

Programme TITRE 1

Programme de la deuxième journée Migration DPATE …………………………...9h00 Migration Personnelle GRH, GPU + TP 1 ..9h30 Pause .…………………………….10h30 Mise en œuvre du TP 2 …………………….10h45 Repas …………………………….12h00 Migration mig_test ………………………….13h45 Mise en œuvre du TP 3 ……………………..14h15 Question Réponse …………………………...15h15 Conclusion …………………………………...15h45

La migration informatique

La migration informatique Données perso (GRH, GPU, …) Transfert personnel Schéma MIG_TEST Schéma HARP_ADM Mig_btch.sql (procédures pl/sql) AGORA, POPPEE Dpt_btch.sh (procédure) La migration se déroule en 2 phases bien distinctes Chgt_tab.sh (sqlloader) Schéma DPATE

Plan de l’exposé Pré-requis Les deux phases de la migration Première phase : migration données locales -> MIG_TEST Analyse des données locales Chargements des données dans MIG_TEST avec les données nationales (AGORA, POPPEE …) avec fichiers plats Deuxième phase : migration MIG_TEST -> base Harpège Mise en œuvre de l’outil de migration La migration se déroule en 2 phases bien distinctes

Pré-requis Le site a créé une instance Oracle avec l’utilisateur MIG_TEST, propriétaire des tables temporaires Le site dispose d’une source de données fiable Le site a décidé d’une stratégie de reprise : niveau des données à migrer Le site a effectué des enquêtes pour compléter les informations manquantes La source de donnée locale est fiable et complète. La stratégie de reprise est arrêtée et communiquée à tous les intervenants avec son calendrier de mise en œuvre.

Les deux phases de la migration travail de migration vers MIG_TEST user : MIG_TEST user : HARP_ADM travail de migration vers MIG_TEST tables des données à migrer, tables temporaires, images des tables d’Harpège Source de données existante Outil de migration tables Harpège Les tables MIG_TEST : sont des copies des tables HARP_ADM sur lesquelles on applique uniquement les contraintes d ’intégrité. Les tables HARP_ADM : sont les tables de l ’application Harpège. La première phase et la plus importante en terme de préparation des données. Les données locales sont introduites dans MIG_TEST, un certain nombre de rejet sont générés (contraintes intégrités non respecté, type de données invalides). Lorsque toutes les données sont introduites dans MIG_TEST, la deuxième phase de la migration peut commencer. Avant d ’insérer un enregistrement dans HARP_ADM, la procédure effectue tous les contrôles applicatifs et vérifie toutes les règles de gestion. On verra plus loin le système mis en œuvre pour traiter les rejets. 1ère phase : migration vers MIG_TEST 2ème phase : migration de MIG_TEST vers HARP_ADM

Première phase : migration vers MIG_TEST Chargement de MIG_TEST : fichiers plats à partir d’application(s) locale(s) à partir des données nationales (agora, poppee ==> scripts dpate)

Préparation de la migration vers MIG_TEST Travail d’équipe indispensable entre le gestionnaire et l’informaticien Identification des informations à renseigner Création de tables de correspondance Respect des règles de gestion Remplir les tables temporaires de MIG_TEST avec les informations obligatoires d’Harpège Faciliter au maximum l’étape de migration vers Harpège Quels sont les informations obligatoire ?

Analyse des données locales Etude du modèle de données local quels sont les concepts (objets) modélisés ? quelles sont les nomenclatures utilisées ? quelles sont les clefs, les champs obligatoires ? quelles sont les règles de gestion exprimées dans le modèle : unicité, foreign key, ... vérifiées par l ’application Comparer chacun de ces points avec le modèle de données d’Harpège Bien mettre en parallèle les données locales et les données attendues par Harpège (champ obligatoire et nomenclatures). Prévoir les correspondances données locales - Harpège

Analyse des données locales Problèmes rencontrés Informations obligatoires différentes, champs manquants. Ex. type d ’accès à un corps ou à un grade Même concept, mais nomenclatures différentes. Ex. les diplômes Le même nom ne signifie pas la même chose dans les deux modèles. Ex. les positions statutaires Utilisation floue ou laxiste des concepts. Ex. positions statutaires,modalités de service, congés, … Pas de distinction entre emploi et postes Séparation pas toujours nette entre les attributs des agents et les attributs des emplois

Chargement de MIG_TEST à partir de la migration DPATE

Chargement de MIG_TEST à partir des données nationales : migration DPATE Outil de migration DPATE AGORA : Aide à la Gestion Optimisée des Ressources Atos POPPEE ITARF POPPEE Bibliothèque POPPEE : Poste Personnel

Migration DPATE : pré-requis Récupérer les fichiers plats auprès du rectorat ou de la DPATE Création d’un nouvel utilisateur DPATE, propriétaire des tables images d’Agora et de Poppee contenant les données à migrer. 1) Pour les données de POPPEE chaque établissement doit faire une demande écrite signée du SG ou du Président, aux 2 bureaux concernés de la DPATE, en indiquant la liste de numéros RNE de l'établissement et une adresse électronique pour réceptionner le fichier d'extraction. Ministère de l'Education Nationale de la Recherche et de la Technologie 142 rue du Bac - 75007 Paris Voici les bureaux concernés * Pour POPPEE ITARF DPATE C2 - bureau des personnels ITARF A l'attention de Mme LUNEAU * Pour POPPEE Bibliothèque DPATE C3 - bureau des personnels des bibliothèques et des musées A l'attention de Mme LAPLANTE 2) Concernant les données ATOS, nous avons sollicité M. ROINEL (chef du bureau DPATE A2) afin qu'il adresse un message aux différentes DPA pour que les services informatiques des rectorats mettent à disposition des établissements concernés les données AGORA. Vous pourrez donc effectuer la demande des données vous concernant directement auprès des services informatiques des Rectorats.

Migration DPATE : principes de base et objectifs Permettre aux gestionnaires de récupérer les informations relatives à la population des agents ATOS, ITARF et Bibliothèque en poste dans l’établissement au moment de la migration. Les IATOS contractuels ne sont pas prévus dans cette migration. Intérêt d’une telle reprise à estimer : rapporter le temps passé consacré à cette reprise à la richesse des informations contenues dans le fichier.

Migration DPATE : données POPPEE Scripts complémentaires pour les données POPPEE Situation de famille Célibataire par défaut Transcodification des grades DPATE …

Migration DPATE : scripts POPPEE

Migration DPATE : traitements Chargement des données DPATE (SQL Loader) Procédures PL/SQL : Lancement de toutes les procédures par un script Les agents IATOS sont comparés aux agents déjà dans la base sur l’homonymie Traitement des rejets Un outil de statistique permet d’éditer le taux de réussite dans le remplissage des informations dans MIG_TEST Suppression de l’utilisateur DPATE

Chargement des données Migration DPATE - Chargement des données Un contrôle d ’homonymie est mis en place pour les agents ATOS déjà présents dans la base Harpège afin de permettre un rapprochement avec les informations venant d’Agora ou de Poppee. Chargement des fichiers plats Agora et Poppee Principe de fonctionnement de SQL*Loader Le script chgt_tab charge les données fournies par le rectorat et le ministère dans les tables de l ’utilisateur DPATE ../MIGRATION/dpate/script/chgt_tab « mot_de_passe_Dpate » « nom_instance» Mettre les fichiers plats (jess.xxx) dans le répertoire ../dpate/script/chrg_ago Après le lancement de chgt_tab, un fichier log est généré « chgt_tab.log.jj.mm » dans le répertoire de lancement (../script)

Migration DPATE - DPATE -> Mig_test Procédures Pour respecter la hiérarchie des composants de la migration, lancer les procédures de migration DPATE avec le script ../MIGRATION/dpate/script/dpt_btch.sql Les rejets sont stockés dans la table REJET avec pour chacun le nom de la table, le rowid, la cause du rejet, le composant Traitement des rejets Ouvrir une session SQL Visualiser les enregistrements rejetés avec la requête suivante Select * from Nom_table where rowid = ‘ ……… ’; sous SQL user dpate/dpate : lancer le script @dpt_btch.sql

Outil d’édition de statistiques Migration DPATE - Outil d’édition de statistiques Un outil de statistique permet d’éditer le taux de réussite dans le remplissage des informations dans MIG_TEST Après chaque utilisation du batch de migration lancer : ../MIGRATION/dpate/stat/dpt_btch_stat « mot_passe_DPATE » « nom_instance » Suppression de l’utilisateur DPATE drop user DPATE cascade; drop tablespace -------; Résultat des statistiques dans le fichier dpt_rej.rtf

Chargement de MIG_TEST avec des fichiers plats

Chargement de MIG_TEST avec des fichiers plats Ensemble de fichiers plats user : MIG_TEST 4/ Mises à jour 3/ Analyse des erreurs tables des données à migrer, tables temporaires, images des tables d’Harpège Source de données existante 1/ Extraire 2/ Chargement 6/ Mises à jour 5/ Détermination de l ’erreur 1. Extraction, (re)génération de fichiers plats 2. Chargement de MIG_TEST, avec, par exemple, SQL loader, 3. Analyse des erreurs, détermination de l ’information erronée ou manquante dans les fichiers plats 4. Mise à jour des fichiers plats, transcodage 5. Analyse des erreurs, détermination de l ’information erronée ou manquante dans la base locale 6. Mise à jour de la base locale, entrée d ’informations manquantes ou corrections

Définition des fichiers plats Un fichier plat doit correspondre à : une table de MIG_TEST ou à un sous-ensemble de champs d’une table comprenant des champs obligatoires un ensemble de champs, éventuellement vides, de longueur fixe ou délimités par un séparateur Les fichiers plats sont générés en utilisant la fonction exportation de l’application locale

Préparation des fichiers plats Le formatage des fichiers plats est à la charge des établissements avec l’outil de leur choix Les fichiers plats doivent tenir compte : des champs obligatoires - cf MPD Harpège - du type des données - cf. MPD Harpège - des nomenclatures Harpège - tables de correspondance -

Des fichiers plats vers MIG_TEST : Utilisation de liens ODBC Préparation des fichiers plats (séparateurs) Formatage des fichiers plats avec les outils bureautiques Création du lien ODBC entre Access et MIG_TEST Activation des contraintes d’intégrités Import des données dans MIG_TEST Traitement des anomalies Attention : si les fichiers plats ont des champs de longueur fixe => traiter les blancs en fin de chaine => problème recherche sous Harpege Est que les différences de version SqlNet entre le serveur et le client ne sont pas gênante ?

Chargement direct de MIG_TEST à partir des données locales Source de données existante user : MIG_TEST Mapping entre modèles de données Initialisation des champs obligatoires Transcodages tables des données à migrer, tables temporaires, images des tables d’Harpège SQL Les tables de transcodage peuvent être définie indifféremment soit dans l ’environnement de l ’application locale soit dans l ’environnement ORACLE de MIG_TEST. Tables de transcodage

Présentation du T.P. Schéma général : les 2 phases de la migration 1ère phase : des fichiers plats vers MIG_TEST Utilisation de liaison ODBC Utilisation de SQL Loader 2ème phase : de MIG_TEST vers HARP_ADM Utilisation du batch Analyse des statistiques et des rejets Les données que nous allons migrer sont liées à des domaines ne demandant pas de connaissances fonctionnelles d’Harpège. Le but de ce TP est de vous montrer les principaux outils que vous pouvez utiliser pour effectuer cette migration. 3 TP : * liaison ODBC * sqlloader * mig_test vers harp_adm

Présentation du TP partie 1

1ere phase : Des fichiers plats vers MIG_TEST - Schéma général Activation des contraintes d’intégrités user : MIG_TEST user : HARP_ADM tables des données à migrer, tables temporaires, images des tables d’Harpège Fichiers plats Liaisons ODBC batch tables Harpège SQL*Loader Chargement des fichiers plats et traitements

Liaison ODBC : énoncé Migration des fichiers plats form_individu.txt form_diplome.txt Formatage des fichiers plats (outils bureautiques) Vérification de la structure Formatage des données Gestion des correspondances simples Création du lien ODBC entre Access et MIG_TEST Activation des contraintes d’intégrité (enable.res) Import des données dans MIG_TEST Gestion des tables de correspondances Gestion de la table des erreurs Présentation des possibilités de l’outil liées à Access et première mise en œuvre du processus de migration. 1/ Formatage individu : - Suppression colonne de fin contenant une * - Ajout colonnes : Prénom2, date décès, natural, modif et création, ss_diplôme = ‘ N ’ - Formatage des champs : N° département (000), date (jj/mm/aaaa) Sauvegarde sous excel (.xls) 2/ Création des liens ODBC sur les table MIG_TEST (individu, individu_diplôme, adresse_personnelle) 3/ Laisser les contraintes actives pour travailler avec les liens ODBC. 4/ Import dans Access du fichier individu.xls => rejets sur les civilités (pb nomenclatures) expliquer message access Oui : seule la première erreur est signalée Non : toutes les erreurs sont signalées 5/ Correction dans Excel + Sauvegarde 6/ Import dans Access => rejets homonymie et date naturalisation pour les étrangers. 7/ Corriger sous Excel et Re-importer. B/ Formatage diplômes : ajout des colonnes n°seq_dipl, lieu_dipl, date création et modif 1/ Créer une table vide dans Access (style feuille de données) Coller les enregistrements provenant d ’Excel (Vérifier les types des champs) 2/Créer la table correspondance diplôme : modifier le type et le nom des champs 3/ Faire une requête d ’ajout dans MIG_TEST.INDIVIDU_DIPLOMES avec jointure entre corresp_dipl et diplôme 4/ Rejet d ’un enregistrement car l ’individu n ’existe pas

Liaison ODBC : les outils Le Modèle Logique des Données Harpège Domaine individu - cf Annexes - La description des tables du domaine individu de MIG_TEST et d’HARP_ADM Structure des tables Tables de nomenclature d ’Harpège Correction : Nomenclature Civilité Nés à l ’étrangers => date de naturalisation à renseigner Ville de naissance Département de naissance (blancs) ? A vérifier Homonymie 1/Form_diplomes : Insertion des colonnes n° sequence diplôme, lieu d ’obtention, dates de création et de modification. 2/ Enregistrer sous .xls 3/ Créer la table de correspondance 4/ Diplômes faire une requête : corresp_dip et form_diplômes Requête d ’ajout dans MIG_TEST diplôme Code diplôme sur 7 caractères

Des fichiers plats vers MIG_TEST : Utilisation de SQL*Loader Principe de fonctionnement Mise en œuvre : Préparation des fichiers plats Préparation des fichiers de contrôle Lancement de SQL*Loader Traitement des rejets Rapide présentation de SQL*Loader

SQL Loader - Principe de fonctionnement Fichier de contrôle (.ctl) Fichier plat SQL*Loader Les différents types de fichiers et principe de fonctionnement. Enregistrements erronés (optionnel) Enregistrements rejetés (optionnel) Fichier .log Données chargées

SQL Loader - Préparation des fichiers de contrôle Les fichiers de contrôle définissent la structure des données contenues dans les fichiers plats 2 possibilités pour faire la description des fichiers plats : par position => la longueur des champs est fixe à l’aide d ’un séparateur => la longueur des champs peut-être variable Voir exemple en annexe et documentation SQL Loader - Oracle Server Utilities -

SQL Loader - Lecture des fichiers plats La commande de lancement de SQL Loader permet d ’indiquer le nom et chemin : du fichier de contrôle du fichier log du nombre maximum d ’erreurs … cf doc ORACLE8 - Server Utilities sqlldr user/mot_de_passe control=« nom et chemin du fichier de contrôle » log=«nom et chemin de sauvegarde du fichier log » errors=« nombre maximum d ’erreurs » Cet ordre se lance sous Unix

SQL Loader - Lecture des données Seuls les enregistrements dont l ’intégralité des données est correcte sont importés dans les tables de MIG_TEST SQL Loader rejette les enregistrements qui génèrent une erreur ORA- pour lesquels les données sont incorrectes - formatage - Les enregistrements sont rejetés en totalité dans le fichier .bad - les données le constituant ne sont insérées dans aucune table - La cause du rejet est enregistrée dans le fichier .log

SQL Loader - Traitement des rejets Mettre à jour les enregistrements erronés dans les fichiers plats Relancer SQL Loader, les fichiers .log précédents seront écrasés SQL*Loader fait un truncate de la table avant d ’insérer les nouvelles données. Faire les mises à jour avec vi insérer : esc + i supprimer un car. : esc + x sauvegarde : esc + wq

Présentation du TP partie 2

SQL Loader - Enoncé Migration du fichier plat form_adres_perso.ha Préparation du fichier de contrôle associé form_adres_perso.ctl Lancement de SQL*Loader Traitement des erreurs Demo : sqlldr mig_test/mig_test control = log = errors = 100 0/ désactiver toutes les contraintes disable.res Car truncate sur les tables avant d ’insérer les enregistrements 1/ Créer un répertoire sqlloader sous mig_harpege/ 2/ Placer les fichiers de contrôle et de données dans ce répertoire … /mig_harpege/sqlloader/ 3/ Lancer l ’ordre sqlldr à partir de ce répertoire => les fichiers .bad et .log seront par défaut dans le répertoire de lancement.

SQL Loader - les outils Le Modèle Logique des Données Harpège Domaine individu La description des tables du domaine individu d ’Harpège Structure des tables Tables de nomenclature d ’Harpège Documentation Oracle8 Server Utilities (dont SQL*Loader )

Migration de MIG_TEST vers HARP_ADM

Les deux phases de la migration travail de migration vers MIG_TEST user : MIG_TEST user : HARP_ADM travail de migration vers MIG_TEST tables des données à migrer, tables temporaires, images des tables d’Harpège Source de données existante Outil de migration tables Harpège Les tables MIG_TEST : sont des copies des tables HARP_ADM sur lesquelles on applique uniquement les contraintes d ’intégrité. Les tables HARP_ADM : sont les tables de l ’application Harpège. La première phase et la plus importante en terme de préparation des données. Les données locales sont introduites dans MIG_TEST, un certain nombre de rejet sont générés (contraintes intégrités non respectées, type de données invalides). Lorsque toutes les données sont introduites dans MIG_TEST, la deuxième phase de la migration peut commencer. Avant d ’insérer un enregistrement dans HARP_ADM, la procédure effectue tous les contrôles applicatifs et vérifie toutes les règles de gestion. On verra plus long le système mis en œuvre pour traiter les rejets. 1ère phase : migration vers MIG_TEST 2ème phase : migration de MIG_TEST vers HARP_ADM

2eme phase : de MIG_TEST vers HARP_ADM Pré-requis Principe de fonctionnement Activation et désactivation des contraintes Migration des composants Traitement des rejets - statistiques Vérification de la structure d ’affectation principale Mise à jour des séquences Suppression de Mig_test

De MIG_TEST vers HARP_ADM - Pré-requis Le site a créé une instance Oracle avec 2 utilisateurs : MIG_TEST propriétaire des tables à migrer HARP_ADM propriétaire des tables d’Harpège Le site a inséré dans MIG_TEST les données à migrer avec une méthode qui lui est propre Le paramétrage doit être saisis dans les tables d’HARP_ADM (10 tables concernées : PARAM_ETABLISSEMENT, ORGANISME_RECHERCHE, ORG_MISSION,ANNEE_UNIVERSITAIRE, IMPLANTATION_GEO, TELEPHONE, STRUCTURE, ADRESSE_ADMINISTRAT, LOCALISATION_STRUCTURE, LOCAL)

De MIG_TEST vers HARP_ADM - Principe de fonctionnement batch user : MIG_TEST user : HARP_ADM lecture suppression insertion table des rejets rejet règle de gestion nomenclature contraintes d’intégrités Traitement d’un enregistrement Lecture Contrôle de cohérence si erreur alors traitement rejet sinon insertion dans d’HARP_ADM et suppression de MIG_TEST

De MIG_TEST vers HARP_ADM - Activation - désactivation des contraintes 1°) Activation des contraintes sur MIG_TEST : les données à migrer vérifient bien toutes les contraintes d’intégrité (clé primaire, clé étrangère, clé unique, domaine de valeur) : enable.res 2°) Désactivation des contraintes sur MIG_TEST afin de pouvoir migrer les données : disable.res La migration des données ne sera cohérente que si les 2 étapes d’activation et de désactivation des contraintes dans MIG_TEST se sont déroulées sans problème

De MIG_TEST vers HARP_ADM - Migration des composants La migration peut-être lancée de 2 façons sous l ’utilisateur MIG_TEST : migration des composants un à un -vivement recommandé -. Pour cela exécuter sous SQL : execute « nom_du_composant » Respecter la hiérarchie des composants migration de l ’ensemble des composants exécution du batch : ../MIGRATION/mig_harpege/script/mig_btch.sql Par exemple : execute mig_ind_eat; (état civil des individus)

Le batch de migration : les traitements Ensemble de procédures PL/SQL exécutées dans un ordre précis Ces procédures lisent et contrôlent les données des tables de MIG_TEST puis les déversent dans HARP_ADM Un enregistrement n’est déversé que s’il est entièrement correct, sinon un enregistrement de rejet est généré, avec code et motif du rejet Ce déversement est suivi d’une suppression dans MIG_TEST de l’enregistrement déversé L’objectif est d’obtenir des tables de MIG_TEST vides et leurs correspondantes HARP_ADM remplies

Le batch de migration : les composants et leur ordonnancement Un composant regroupe toutes les informations liées à un domaine précis d’Harpège Ex. : ind_eat correspond à la saisie d'un individu Tables impactées : INDIVIDU, ADRESSE_PERSONNELLE, INDIVIDU_TELEPHONE, INDIVIDU_E_MAIL, INDIVIDU_DIPLOMES

Le batch de migration : les composants et leur ordonnancement Mise en œuvre du batch de migration Composant par composant En une seule fois sur l’ensemble des composants (script non interactif qui se lance sans paramètre) 2 règles à respecter Toutes les tables associées à un composant doivent être remplies La hiérarchie des composants doit être respectée

Batch de migration : ordonnancement S T R U C T U R E S Individu Fonctionnaires et assimilés Contractuels Agent Contrat Carrière I M P L A N T O S Position Modalités Congés Congés Modalités Occupation / Affectation L O C A U X Poste Emploi

Batch de migration : ordonnancement IND_EAT (1,1) EMP_MOY (1,2) PST_IDBP (1,3) IND_STR (2,1) PER_AGT (2,2) PST_IDBE (2,3) CAR_ELEM (3,1) PER_PAS (3,2) PER_CTR (3,3) CAR_BIND (4,2) PER_POS (4,1) CGA_CMNT (4,3) CGA_CGM (4,4 CGA_NTIT (4,5) CGA_ACTR (4,6) CGA_AL3 (4,7) CGA_AL4 (4,8) CGA_AL5 (4,9) CGA_AL6 (4,10) PER_DEPA (5,2) PIL_NOTE (5,3) PER_TPS (5,4) OCAF_PER (5,1) CGA_MAD(6,1 CGA_LIMA (6,2) CGA_SURN (6,3) CGA_MTFC (6,4) CGA_COM (6,5) CGA_ACSE (6,6) CGA_CRCT (6,7) CGA_STAG (6,8) CGA_BONI (6,9) CGA_CPA (6,10) CGA_DELE (6,11) CGA_ADOP (6,12) CGA_FORM (6,13) CGA-MIDE (6,14) CGA_MATE (6,15) CGA_CLM (6,16) CGA_CLD (6,17) CGA_MTTH (6,18) CGA_FACT (6,19) AFF_SSOC (6,20)

De MIG_TEST vers HARP_ADM - Traitement des rejets Tous les rejets se trouvent dans la table REJET de MIG_TEST Un rejet est caractérisé par : le nom de la table concernée par le rejet le rowid de l’enregistrement rejeté la cause du rejet Le nom du composant concerné par le rejet Il s’agit de comprendre les rejets pour les corriger et relancer l’opération jusqu’à l’obtention de résultat jugés satisfaisants Une compétence fonctionnelle est indispensable pour analyser et comprendre les rejets

De MIG_TEST vers HARP_ADM - Traitement des rejets Avant exécution de l’outil de migration, en cas de violation des contraintes d’intégrité des bases de MIG_TEST : clef primaire, clef étrangère, clef unique, domaine de valeur, … Lors de l ’exécution de l’outil, essentiellement pour non respect des règles de gestion. Ex. succession des segments de carrière, règles de changement de corps, grade ou échelon, … Champs obligatoires non renseignés Peuvent aussi révéler des erreurs ou des incohérences dans la base locale

Le batch de migration : outil d’édition des statistiques Taux de réussite de HARP_ADM par table Taux de rejet de MIG_TEST par table Liste des rejets triés par composant Liste des rejets triés par nombre décroissant ../MIGRATION/mig_harpege/stat/mig_btch_stat « mot_passe_MIG_TEST » « nom_instance »

De MIG_TEST vers HARP_ADM - Vérification de la structure d ’affectation principale Sous SQLPLUS, utilisateur MIG_TEST lancer le script : ../MIGRATION/mig_harpege/script/aff_prin.sql Le script établie la liste des dossiers sur lesquels l’utilisateur devra déterminer la structure d’affectation principale. Cette saisie sera effectuée directement via l’application Harpège @aff_prin.sql

Mise à jour des séquences Une fois toutes les données migrées, il faut mettre à jour les séquences ORACLE en fonction des données insérés dans les tables HARP_ADM Maj_seq.ini

Suppression de MIG_TEST Pour commencer la phase d’exploitation, une fois toutes les données migrées, il faut supprimer l’utilisateur MIG_TEST et le tablespace associé Indispensable pour les futures mises à jour Harpège

Présentation du TP partie 3

De MIG_TEST vers HARP_ADM - Enoncé Activer et désactiver les contraintes d ’intégrité Lancement du batch du composant de migration sous SQLPLUS (mig_test) : execute mig_ind_eat Statistiques et traitement des rejets select * from rejet mig_btch_stat.sh mig_test nom_instance Mise à jour des séquences ORACLE sous SQLPLUS (harp_adm) : @maj_seq.ini Vérification structure d’affectation : @aff_prin.sql

Documentation

La documentation Documentation livrée jusqu’à aujourd’hui : Classeur conduite de projet Dossier de paramétrage Guide de reprise de données (méthodologie) CCI Liste des champs obligatoires

La documentation Documentation contenue dans le classeur : Transparents formation installation reprise de données Manuel d’installation de l’application Manuels d’installation outils de reprise

Contenu du CD-ROM Partie serveur : Application en version 1.11.2.0 Nomenclature en version 1.11.2.0 Partie cliente : Application partie cliente en version 1.11.2.0 Documentation technique : 1. Manuel d'installation 2. Manuel d ’exploitation 3. Cahier des charges d ’implantation 4. Champs obligatoires avec copies d'écrans 5. Listes des nomenclatures (.xls) 6. Manuel base de formation Documentation fonctionnelle : 1. Manuel Utilisateur 2. Manuels de formation

Contenu du CD-ROM Modèle de données : 1. MLD 2. MPD Paramétrage : 1. Dossier de paramétrage Reprise de données : 1. Migration Harpège 2. Migration Dpate

Livraisons à venir Base de formation gestion collective

Conclusion Présentation de l’Espace des Produits http://www.amue.fr/ consultation des fiches assistances documentation en ligne ftp.amue.fr (login harpread) Assistance pour un problème : d’installation : support.install@amue.fr de migration : support.migration@amue.fr Harpread / il&-1d6

Merci de votre attention

Solutions

Solution : liaison ODBC Ouvrir les fichiers plats sous Excel Formater les champs dates, les champs numériques Ajouter des colonnes Renseigner les champs obligatoires Préparer la liaison ODBC Création d ’une nouvelle base sous Access Attacher les tables de MIG_TEST par ODBC (voir MLD) Import des données Excel dans Access Activation des contraintes d ’intégrité (enable.res) Import des données dans MIG_TEST Gestion des tables de correspondances Gestion de la table des erreurs Attention : insertion dans individu_diplôme, l ’individu 51 n ’existe pas Création de la table corresp_diplôme : changer le type de données avant d ’insérer les données (les zéro à gauche risqueraient d ’être tronqués)

Formatage Formater les champs dates, les champs numériques Ajouter des colonnes, vérifier les champs nomenclature Renseigner les champs obligatoires Sauvegarder le fichier avec un type de fichier .xls

Préparation de la liaison ODBC Menu Fichier - Données externes - Lier les tables Choisir le type de fichier : Base de données ODBC Sélectionner ou créer la source de données

Création d’une source de données Choisir le pilote Oracle Créer la connexion - Donner le nom de l ’instance - Se connecter avec l ’utilisateur MIG_TEST Attacher les tables de MIG_TEST

Activation des contraintes Ouvrir une connexion sous SQL Plus - User MIG_TEST Exécuter le script ENABLE.RES L ’activation des contraintes permet de déclencher directement les messages d ’erreur lors de l ’ajout des enregistrements dans Access.

Import des données dans MIG_TEST Importer la table Excel précédemment formatée Créer les tables de correspondances et les requêtes de mise à jour Exécuter les requêtes pour mettre à jour les champs de nomenclature Sélectionner les enregistrements de la table Access Copier par ajout dans la table de MIG_TEST correspondante Les enregistrements rejetés sont stockés dans la table des erreurs.

Solution - SQL Loader Migration du fichier plat form_adres_perso.ha vérifier la structure de la table adresse_personnelle d ’HARP_ADM : type de données valeur nomenclatures champs obligatoires

Préparation du fichier de contrôle Préparation du fichier de contrôle associé form_adres_perso.ctl LOAD DATA INFILE FORM_ADRES_PERSO.HA INTO TABLE ADRESSE_PERSONNELLE TRUNCATE ( ID_ADRESSE_PERSO POSITION(*) INTEGER EXTERNAL(7) NULLIF ID_ADRESSE_PERSO = BLANKS , NO_INDIVIDU POSITION(*) INTEGER EXTERNAL(8) NULLIF NO_INDIVIDU = BLANKS , TEM_ADR_PERS_PRINC POSITION(*) CHAR(1) NULLIF TEM_ADR_PERS_PRINC = BLANKS , HABITANT_CHEZ POSITION(*) CHAR(32) NULLIF HABITANT_CHEZ = BLANKS , TELEPHONE_DOMICILE POSITION(*) CHAR(25) NULLIF TELEPHONE_DOMICILE = BLANKS , NO_VOIE POSITION(*) INTEGER EXTERNAL(4) NULLIF NO_VOIE = BLANKS , BIS_TER POSITION(*) CHAR(1) NULLIF BIS_TER = BLANKS , C_VOIE POSITION(*) CHAR(3) NULLIF C_VOIE = BLANKS , NOM_VOIE POSITION(*) CHAR(22) NULLIF NOM_VOIE = BLANKS , LOCALITE POSITION(*) CHAR(26) NULLIF LOCALITE = BLANKS , CODE_POSTAL POSITION(*) INTEGER EXTERNAL(5) NULLIF CODE_POSTAL = BLANKS , VILLE POSITION(*) CHAR(26) NULLIF VILLE = BLANKS , C_PAYS POSITION(*) CHAR(3) NULLIF C_PAYS = BLANKS , D_CREATION POSITION(*) DATE "YYYYMMDD" NULLIF D_CREATION = BLANKS , D_MODIFICATION POSITION(*) DATE "YYYYMMDD" NULLIF D_MODIFICATION = BLANKS )

Lancement de SQL*Loader sqlldr mig_test/mig_test control=FORM_ADRES_PERSO.ctl log= FORM_ADRES_PERSO.log errors=999999 Traitement des erreurs vi FORM_ADRES_PERSO.log vi FORM_ADRES_PERSO.bad .bad : contient les enregistrements en erreur .log : contient les messages d ’erreur (par défaut porte le même nom que le fichier de contrôle) traitement des erreurs sous vi : insérer : esc + i supprimer 1 car. : esc + x enregistrer : esc + wq