Partie II : REPRISE DE DONNEES

Partie II : REPRISE DE DONNEES
TITRE 1

LA REPRISE DE DONNEES Présentation rapide des fonctionnalités de la V1.6 Présentation générale de la reprise de données La migration informatique TP de migration

Présentation des fonctionnalités Harpège V1.6

Le champ fonctionnel d’HARPEGE V1.6
S T R U C T U R E S Individu Fonctionnaires et assimilés Contractuels Agent Contrat Listes Electorales Promouvabilités ITARF Carrière I M P L A N T O S Position Modalités Congés Congés Modalités Occupation / Affectation L’enchaînement des fonctions incluses dans la version 1.5: en premier lieu, la gestion des individus (toutes les personnes). une majeure partie de ces individus sont ensuite gérés en tant que : fonctionnaires (carrière, positions, congés, modalités de services...) contractuels (contrats, avenants, congés , modalités de services). en second lieu les emplois et les postes, qui sont enregistrés dans HARPEGE avec la mention de leur financement. Le mode de financement de ces postes est géré (Budget Etat et propre) Enfin, noeud de l'application, l’occupation et l’affectation (quelle personne est sur quel poste et où travaille-t-elle dans l’établissement). Des modules de gestion collective : Listes électorales : la possibilité d ’organiser les élections à partir de l ’application Promouvabilités Itarf : sortir les agents Itarf promouvables par corps et par grade L O C A U X Poste Emploi

Domaine individu L’individu est une personne qui participe ou a participé à l’activité de l’établissement, et sur laquelle il est souhaitable de connaître un minimum d’informations Remarque : les personnes connues uniquement comme individu sont dites «hébergées» Tout personnel de l’établissement est obligatoirement un individu Individus hébergés Agents avec une carrière Agents avec un contrat Exemple d’individus hébergés : chercheur du CNRS, chercheurs de l’INSERM, ... Ensemble des individus 40 20 21 5

De l’individu à l’agent
L’agent (ou personnel) est un individu qui à un instant donné possède une carrière ou un contrat (ou les deux). AGENT est « le passage obligé » pour utiliser et associer les autres constituants de la gestion d’un dossier : carrière, contrat, congés... D’autres concepts sont associés à l’agent : la position (pour les fonctionnaires) l’occupation et l’affectation le bénéfice de modalités de service, de congés et d’absences ... 42

S T R U C T U R E S Individu Fonctionnaires et assimilés Contractuels Agent Contrat Listes Electorales Promouvabilités ITARF 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

Concepts de carrière Définitions
Un type de population est un ensemble de corps formant une grande catégorie d'agents ex : les Enseignants-chercheurs, les ITARF, les ASU, les Hospitalo-universitaires... Une carrière est un ensemble d'éléments de carrière dans un même type de population ex : Une carrière d ’enseignant-chercheur : Assistant--> Maître de conf --> Prof Un élément de carrière est caractérisé par une date d'effet, un corps, un grade et un échelon (le cas échéant, un chevron) ex : au 01/03/1999 : Maître de conf. de 1è cl, 4è échelon A chaque changement de type de population, on enregistre une nouvelle carrière (voir notion de segment de carrière dans le Guide Utilisateur et dans le Glossaire). 45

Position statutaire Ces positions sont :
Tout fonctionnaire est placé dans une des positions définies par le statut général des fonctionnaires. Ces positions sont : Activité, Détachement, Hors cadre, Disponibilité, Service national, Congé parental. Des confusions ou des abus de langage existent parfois sur les situations suivantes : - Le «congé parental» d’un contractuel correspond à un congé spécifique non titulaire, - Un contractuel en service national bénéficie d’un congé, - La «disponibilité pour convenances personnelles» d’un contractuel correspond à un congé spécifique non titulaire (congé pour convenances personnelles). - La «disponibilité pour convenances personnelles» d’un stagiaire correspond à un congé spécifique stagiaire (congé pour convenances personnelles). 49

Domaine Contrat Le contrat traduit l’accord entre un agent et l’établissement, qui s’appuie sur un document descriptif des conditions d’exécution de l’engagement réciproque Distinction entre contrat et carrière : Contractuels Les notions de corps,grades, promotions,... ne s’appliquent pas Fonctionnaires et assimilés (type CNRS, contractuels d'administration) Situation statutaire et réglementaire (corps, grade, promotions,...) Agent Carrière Contrat Position Occupation / Affectation

Contrats et avenants Le contrat initial est enregistré sous l ’avenant n° 0 rattaché au contrat. Règles à retenir : La somme des quotités de recrutement sur une période ne peut pas dépasser 100 % (ou le plafond des 169 h/mois) Les périodes de 2 avenants successifs doivent être contiguës Pour chaque type de contrat existent des règles particulières (durée minimale ou maximale, renouvellement...) A chaque type de rémunération correspond une base spécifique 53

Définitions “Emplois - Postes”
Emploi : ressource mise à la disposition de l’établissement par l’administration centrale, qui lui permet de créer des postes et de rémunérer des personnes. Les emplois sont délégués au travers de “décisions de délégations” soit à l’établissement, soit à une structure de l’établissement (par exception). Poste : unité de gestion des emplois délégués et support de nomination d’une (ou de plusieurs) personne (s). Les postes sont financés soit sur : - le budget de l’état (emplois délégués ou rompus de temps partiel) - le budget propre de l’établissement

Domaine “Emplois - Postes”
BUDGET ÉTAT BUDGET PROPRE Mise à jour du potentiel de l’établissement Enregistrement des délégations Création d’emplois sur rompus Création / Mise à jour des postes Création de postes permanents Création de postes temporaires Création de postes permanents Création de postes temporaires Attribution éventuelle des postes aux structures Différence entre localisation et attribution de poste : la localisation pemet à la structure attributaire de décider de prêter, et donc de localiser un poste pour une période. Localisation des postes dans les structures Occupation / Affectation 55

Le champ fonctionnel d’HARPEGE V1.6 Promouvabilités ITARF

Définition d'occupation/affectation
Établissement UFR A UFR B IUT Sce commun Le couple “poste-agent” est affecté à une (ou plusieurs) structure(s) Département A Département B Service 1 Service 2 Laboratoire X Laboratoire Y x % x % est affecté à Poste Occupation x % occupe Agent 62

Synthèse des liens Occupation est délégué à et donc appartient à
Établissement UFR A UFR B IUT Sce commun Département A Département B Laboratoire X Laboratoire Y Service 1 Service 2 Emploi peut être attribué à finance peut être localisé dans x % x % 1 Affectation Principale pour l'agent Poste est affecté à Occupation x % occupe Agent 67

Modalités de service / Congés
Modalités de service : situation particulière pour l’agent, sur une période définie (date de fin obligatoire) durant laquelle : sa quotité de travail dans l’établissement est inférieure à 100%, son occupation n’est pas modifiée. Ex: Temps partiel, CPA, Mi-temps thérapeutique … Absence/Congé : période définie durant laquelle l’agent n’est pas à son poste de travail pour un motif autorisé pouvant avoir une incidence sur son occupation. Ex : congés sécurité sociale : COM, CLM, CLD, maternité … Ex autres congés : congés formation, CRCT ... Modalités de service : Temps partiel, CPA, MTT, MAD, Délégation (enseignants). Prolongation d ’activité (recul limite d ’âge, surnombre,maintien en fonction) Congés sécu : distinction entre congés titulaires et non titulaires. 69

Congés déconcentrés Gestion dynamique des congés et des éditions d’arrêtés pour les congés maladie et les congés maternité : - Nécessité de paramétrer le niveau de gestion déterminé par les mesures de déconcentration (chacun assorti des entêtes et visas appropriés) - Possibilité de produire différents types d’arrêtés selon le niveau gestion - Requalification automatique des Congés ordinaires par un CLM, - Gestion historique des congés avec reconsidération possible des périodes de rémunération . Les CLM seront livrés en début d ’année 2001

Promouvabilités ITARF
Une aide à la constitution des listes de promouvables ITARF, aux calculs d’anciennetés nécessaires à l’examen de ces promouvabilités, à l’édition des dossiers, etc. Fonctionnalités : La consultation des circulaires ; Le calcul des listes ; Les modifications des listes ; L’édition de diverses listes de travail ; La saisie des propositions, et du classement le cas échéant, formulés par les structures ; La saisie du classement de l’établissement ; L’édition des dossiers des agents promouvables ; L’édition des propositions classées de l’établissement, pour transmission au ministre ; Le verrouillage des listes.

Listes Électorales L’outil Listes électorales permet d’éditer les listes électorales, par collège (et éventuellement par secteur électoral ), par composante élective ou par bureau de vote, pour : 12 types d’instances locales et professionnelles, faisant l’objet d’une réglementation nationale. d’éventuels types d’instances créés sur la base des statuts de l’établissement.

Les éditions Harpège

Les éditions Harpège Principe de fonctionnement Papier ou fichier .PRN
Fichiers plats Exploitation des fichiers .PRN Exploitation des fichiers plats .LIS Les opérateurs Saisie des paramètres Fenêtre d’évaluation Liste des éditions Harpège

Les éditions courantes : papier et/ou PRN
Choix dans un menu de l’item Editions Nom de l’édition Saisie de la liste de paramètres + date d’observation Annuler Editer : Evaluation de la sélection Aperçu (Affichage à l’écran) Impression du document Annuler Fermer Impression du document Impression papier Impression dans un fichier PRN Le processus général des toutes les éditions dans Harpège. Il s’agit d’une procédure standard : toutes les éditions fonctionnent de cette façon. Important : ne faut pas utiliser l’icône «Imprimante»; l’évaluation du nombre de réponses varie d’un domaine à l’autre. + Retour à l’écran de l’évaluation de la sélection Impression dans un fichier PRN Impression papier

Les éditions sur fichiers plats Choix dans un menu de l’item Editions
Nom de l’édition Saisie de la liste de paramètres + date d’observation Annuler Editer : Evaluation de la sélection Aperçu (Affichage à l’écran) Impression du document Annuler Fermer Impression dans un fichier .lis (option pré-cochée)

Exploitation d ’un fichier .PRN
Les fichiers .prn générés ne sont pas exploitables dans Word ou Excel, ces fichiers sont comparables à des fichiers postscript. Cette fonctionnalité est utile dans le cas où vous ne pouvez pas imprimer directement à partir du PC avec lequel l'édition à été lancée (l'imprimante n'est pas en réseau par exemple). Pour imprimer les fichiers .prn : 1/ capturer le port imprimante que vous voulez utiliser : - Choisir "Propriétés" - Dans l'onglet "Détails", cliquez sur le bouton "Capturer le port imprimante" et sélectionner le port et le chemin de votre imprimante. 2/ exécuter la commande suivante sous DOS : copy <nom du fichier> <port de l'imprimante> ou print <nom du fichier> <port de l'imprimante>

Exploitation d ’un fichier plat .LIS
Les fichiers plats .LIS générés sont exploitables avec les outils bureautiques (Word, Excel …). Cette fonctionnalité a été développée pour donner plus de souplesse sur certaines éditions. Chaque établissement peut mettre en forme ces éditions selon les spécificités propres au site. Les fichiers .LIS sont enregistrés dans le répertoire mentionné par l ’utilisateur lors de la demande d ’édition.

Les opérateurs Si le paramètre est une date, la liste des opérateurs est limitée à >= et <=

Saisie de la liste des paramètres
Définition d’un paramètre de sélection : un paramètre de sélection est composé obligatoirement d’un opérateur et d’une valeur Exemple : Liste des opérateurs : =, <, >, <=, >=, not=, absent, =fils, comme. Suivant le type de paramètre (date, structure, numéro de dossier, ...), la liste des opérateurs est réduite. Plusieurs lignes de paramètres de sélection sont autorisées. <= 01/01/1990 Opérateur Valeur Quelques commentaires sur les opérateurs : faire référence au manuel pour détailler la liste des valeurs; en particulier l’opérateur absent : à utiliser par exemple lorsque l’on recherche la liste des agents qui n’ont pas d’affectation.

La ligne de paramètres Définition d’une ligne de paramètres :
un enregistrement est sélectionné s'il satisfait à toutes les conditions et paramètres saisis . Ex : condition 1 et condition 2 et ... Plusieurs lignes de paramètres de sélection sont autorisées. Dans ce cas , chaque enregistrement doit répondre soit aux conditions d'une ligne soit aux conditions d'une autre ligne. Ex : condition(s) ligne 1 ou condition(s) ligne 2 ou ...

Grille de sélection

Fenêtre d ’évaluation

Liste des éditions Domaine Individu - Dossier individu
- Etiquettes administratives (fichier plat) - Etiquettes personnelles (fichier plat) -Liste alphabétique des personnels établissement Domaine Agents - Dossier Agent - Liste des numéros INSEE provisoires - Listes des titulaires (fonctionnaire) par âge - Liste par position : édition des fonctionnaires par position statutaire - Liste par population : édition des fonctionnaires par type de population (Itarf,Atos, Enseignants, etc.) - Historique Carrières et contrats pour un agent -Situation santé-sécu

Liste des éditions (suite)
Domaine Carrière - Bonification indiciaire : édition des bénéficiaires de bonification indiciaire - Etiquettes adresses administratives et personnelles - Edition du traitement de changement de chevron Domaine Contrat - Fin de contrat de travail : édition des agents en fin de contrat - Type de contrat de travail : édition des contrats par type de contrat - Arrêté de fin de contrat (fichier plat) - Etiquettes administratives (fichier plat) - Etiquettes personnelles (fichier plat) Domaine Position - Fichier relance position (fichier plat) - Relance position Domaine Modalités de service Temps partiel : - Liste des agents ATOS - Liste des agents ITARF - Relance temps partiel (fichier plat)

Liste des éditions (suite)
Domaine congés - arrêtés de COM déconcentrés - arrêtés de CMNT déconcentrés Emplois et postes -Etat d ’occupation des postes BE - Nombre d’emplois et postes par enveloppe - Potentiel des postes sur budget Etat - Potentiel des postes sur budget propre - Occupation des postes - Occupation-Affectation des postes - Historique localisation des postes - Historique Occupation-Affectation Pilotage - Consultation sur modalités-congés (choix impression ou fichier plat) - Liste des notes 2nd degré - Liste des notes ATOS - Liste des notes ITARF - Fiche notes ITARF Nomenclatures - Editions des nomenclatures nationales

Liste des éditions (suite et fin)
Listes électorales Edition des nomenclatures (bureaux de vote, collèges, composantes électives, instances, secteurs, sections électives, types d’exclusions) Edition des listes : -Listes de référence, d’affichage, d’émargement -Fichier des électeurs (fichier plat) -Liste des agents exclus (édition et fichier plat) -Liste des électeurs sans bureau de vote -Liste des électeurs à multiple affectation Promouvabilités ITARF -Paramétrage des structures (édition de l ’arborescence des structures) -Liste des agents proposés (liste d’aptitude et tableau d’avancement) -Liste des agents promouvables par structure, par corps de promotion -Liste de tous les agents par corps de promotion. -Dossier agent (liste d’aptitude et tableau d’avancement) Structures -Arborescence structures

Rappel des 7 éléments du paramétrage
(vus lors de la formation paramétrage début décembre) Le paramétrage d ’Harpège est constitué de 7 éléments qui doivent être traités dans l ’ordre suivant : Paramétrage de l ’établissement Création des utilisateurs Saisie des profils d ’habilitations Initialisation des nomenclatures locales Création des implantations / adresse et locaux Saisie des structures Paramétrage des congés et saisie des visas Administration Harpège Base : Connexion à l ’administration Utilisateur : HARP_ADM Harpège

Présentation générale de la reprise des données

Présentation générale de la reprise de données
Objectif Organisation Caractéristiques Pré-requis Diagnostic de l’existant Stratégie de reprise Planification Outils de migration Ordonnancement de la reprise Cf guide de reprise de données

Objectifs Disposer d’une base fiable et complète Pourquoi faire ?
Base complète : elle permet de retracer toute la carrière des agents depuis le début de leur activité. Base fiable : exactitude des données, conformité par rapport à la réglementation. Pourquoi faire ? Assurer la gestion individuelle et collective des agents. Fournir à l’établissement les données individuelles et agrégées nécessaires à sa gestion et à son pilotage.

Organisation Équipe migration : Planning réalisé et communiqué
1 informaticien 1 fonctionnel contact permanent processus itératif Planning réalisé et communiqué

Caractéristiques Il s’agit d’introduire au minimum toutes les données obligatoires dans Harpège avec pertinence et cohérence Données obligatoires : données minimales mais nécessaires pour valider la saisie d’un écran. données minimales et nécessaires pour activer des fonctionnalités transverses Cf doc champs obligatoires distribué lors des visites conduite de projet. (Cf. aussi CD-ROM)

Pré-requis Réfléchir sur l’organisation dans Harpège (structures - implantations géographiques) Pour commencer une reprise des données, aussi bien manuelle qu’automatique, les données minimum à saisir dans la base HARPEGE sont : Les structures, au moins le niveau 1 Les utilisateurs Les habilitations Les nomenclatures locales Les implantations géographiques/locaux, au moins niveau 1 Tout dépendant des objectifs de la migration s ’il a été décidé de : - migrer jusqu’aux occupation/affectation des agents, il faudra alors définir les structures, implantations géographiques et locaux jusqu’au niveau désiré - migrer jusqu’aux emploi/poste il faudra au moins descendre jusqu’aux structures d ’attribution - migrer l ’historique des carrière il n ’est alors pas utile d ’avoir défini les structures jusqu’à un niveau fin (le niveau 1 peut suffire). Attention : s'il n'y à pas de local principal affecté aux structures elles n'ont donc pas d'adresse administrative. De plus suivant le détail de migration (emploi/poste par exemple) il est gênant d'utiliser une structure qui n'a pas tous ses attributs de définis (au moins le local principal). Cf guide de paramétrage

Diagnostic de l ’existant
Les sources de données à partir des applications locales à partir des applications nationales (AGORA, POPPEE, …) Les étapes du diagnostic déterminer les catégories de personnels à migrer vérifier les concepts et nomenclatures locales avec Harpège étudier les modèles de données Les outils du diagnostic modèles de données locaux et Harpège nomenclatures locales et Harpège liste des champs obligatoires Le diagnostic, pourquoi ? Pour faire le bon choix entre reprise automatique, manuelle ou mixte. 1/ La source de données est l ’un des points essentiel du diagnostic. La fiabilité des données est déterminante dans la décision que vous prendrez. 2/ Les étapes : A/ Quels sont les agents concernés par la migration ? Tous ou certains types de population ? Tous les contrats ou juste certains ? Quels supports allez vous utiliser pour faire le diagnostic ? B/ Cette étape est la plus minutieuse, car il faut mettre en parallèle les données de l ’application locale avec celles d’Harpège. C/Cette analyse permet de définir si - les concepts sont globalement les mêmes. - les champs obligatoires d’Harpège pourront être renseignés grâce aux données de l ’application locale. - les nomenclatures utilisées sont transférables. 3/ Les outils : cette liste n ’est pas exhaustive.

Stratégie de reprise Définition des objectifs de reprise à partir :
du diagnostic fait précédemment de choix de gestion et de pilotage de l’établissement de la volonté de mettre en œuvre le domaine gestion collective ... Stratégie et plan d’action définir les données à migrer avec quel détail (historique, en cours) établir un planning avec ses priorités Préparation de la reprise compléter les données dans la base locale établir les correspondances des nomenclatures entre la base locale et Harpège 1/ Quels sont les traitements que l’on souhaite pouvoir réaliser avec Harpège ? La réponse à cette question détermine en partie le détail de la reprise de données. 2/ Pour l ’historique il faut être vigilant sur : - la saisie du type d ’accès aux éléments de carrière qui détermine la prise en compte ou non de l ’élément lors du calcul d ’ancienneté. De plus, la plus part des positions (autres qu’Activité) et des congés (autres que congés parental) sont interruptifs dans le calcul des promouvabilités et ont un caractère exclusif pour les listes électorales. L ’encours : Saisir uniquement l ’élément de carrière courant. Cette stratégie ne permettra pas dans un premier temps d ’utiliser le module promouvable. Définir un planning précis avec les actions et les dates buttoirs, la migration Harpège est un sous projet de l ’implantation d ’Harpège

La reprise de données Facteurs de succès Mises en garde Contraintes
Diagnostiquer précisément l’état de la base Définir clairement les objectifs : que veut-on reprendre, à quel rythme, etc... Mises en garde Sous-estimer la charge de travail - manque de moyens Ne pas se donner de limite dans le temps ou se donner des échéances irréalistes Contraintes Impossibilité de faire évoluer HARPEGE (patch, version supérieure) avant la fin de la migration Pas d’exploitation possible du produit tant que les données ne sont pas insérées 1/ Bien évaluer le rapport reprise automatique/ modification ou reprise manuelle. Par exemple : Suivant l ’état des données, on peut migrer les individus les agents et saisir la partie carrière. Bien planifier toutes les actions avec les responsables et moyens consacrés, organisation du travail (fermeture des services 2 jours par semaine …) 2/ Manque d ’organisation et de communication autour du projet de reprise de données. 3/ La phase de reprise de données doit être bien bornée pour pouvoir rapidement exploiter les données migrées et faire évoluer le produit

La reprise de données (suite)
Recommandations Attention à la codification (% - _ ,) Attention aux minuscules / majuscules

Planification Installation version initiale Migration
installation version initiale serveur installation outils de migration installation partie cliente Migration utilisation des outils de migration liés à la version initiale Passage site en exploitation mise à niveau de la version : passage de tous les patchs correctifs et nomenclatures.

Outils de migration Toute la migration repose sur l ’utilisateur Mig_test schéma identique à harp_adm activation des contraintes Remplir Mig_test procédures personnelles utilisateur DPATE (Agora, Popee Itarf, Popee Bibliothèque) automatisé : sqlloader + procédure Mig_test vers Harp_adm automatisé : livraison de procédure

Outils de migration Données perso (GRH, GPU, …) Transfert personnel
Schéma MIG_TEST Schéma HARP_ADM Mig_btch.sql (procédure) AGORA, POPPEE Dpt_btch.sh (procédure) Dpate : 1°) install_dpate.sh création tablespace création user dpate création schéma dpate 2°) chgt_tab.sh : remplir les tables dpate par sqlloader 3°) dpt_btch.sh : insert into mig_test 4°) destruction user dpate Mig_test : 1°) install_mig.sh création tablespace migration création user mig_test création schéma mig_test 2°) insertion dans mig_test perso dpate 3°) activation / désactivation des contraintes 4°) mig_btch.sh : migration vers harp_adm 5°) mise à jour séquences 6°) destruction user mig_test Chgt_tab.sh (sqlloader) Schéma DPATE

Outils de migration - sqlloader
Enregistrements Fichier DATA (jess.xxx) Enregistrements non sélectionnés SQL*LOADER Lecture (xxx.ctl) Discard file (xxx.dsc) SQL*LOADER When clause Correction Compte rendu (xxx.log) Base de données dpate Enregistrements incorrects Bad file (xxx.bad)

Outils de migration - sqlloader
Le fichier de contrôle (.ctl) LOAD DATA INFILE 'chrg_dpt/jess.aff' BADFILE 'chrg_dpt/aff.bad' DISCARDFILE 'chrg_dpt/aff.dsc' REPLACE INTO TABLE aff FIELDS TERMINATED BY '|' TRAILING NULLCOLS (AFFNUM INTEGER EXTERNAL , NUMIND INTEGER EXTERNAL , UAARNE CHAR , AFMICO CHAR , DATDEB DATE "DD/MM/YYYY" , DATFIN DATE "DD/MM/YYYY" , AFFANC CHAR NULLIF AFFANC=BLANKS, AFFDAN DATE "DD/MM/YYYY" NULLIF AFFDAN=BLANKS, AFFDIN DATE "DD/MM/YYYY" NULLIF AFFDIN=BLANKS, AFFINS CHAR NULLIF AFFINS=BLANKS)

Outils de migration sqlloader
Le fichier DISCARD (.dsc) Uniquement alimenté par la clause when si elle existe Écrit dans le même format que le fichier DATA Le fichier BADFILE (.bad) Enregistrement incorrect au sens base de données Le fichier LOGFILE (.log) Nombre d ’enregistrements insérés Nombre d ’enregistrements ignorés Nombre d ’enregistrement en erreur Explications des erreurs et rejets

Ordonnancement de migration
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

Ordonnancement de migration
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) 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) Migration DPATE

Harpège Formations techniques décembre 2001 Version 1.6.1.
Agence de modernisation des universités et des établissements Harpège Version Formations techniques décembre 2001

Programme TITRE 1

Programme de la deuxième journée
Migration informatique………………….….9h00 Présentation du TP ……………………….….9h45 Pause .…………………………………..10h30 Mise en œuvre du TP ……………………….10h45 Repas …………………………………..12h00 Mise en œuvre du TP (suite) ………………13h45 Conclusion …………………………………...15h30 Fin ……………………………………………..16h00

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édure) 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
Principes de base et les objectifs de la migration Les deux phases de la migration migration données locales -> MIG_TEST migration MIG_TEST -> base Harpège Première phase : migration données locales -> MIG_TEST Analyse des données locales Chargements des données dans MIG_TEST avec fichiers plats chargement direct de MIG_TEST avec les données nationales (AGORA, POPPEE …) 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 principes de base et les objectifs
Appliquer sur les données migrées l’ensemble des règles de gestion d’Harpège Aucune altération du référentiel Harpège ne peut être envisagée, ni acceptée (tables, programmes, nomenclatures) Objectifs : Disposer d’une base Harpège remplie, et en parfaite cohérence avec les règles de gestion de l’application Disposer d’une base Harpège prête à fonctionner en exploitation Appliquer tous les contrôles liés à la structure de la base (contraintes) et toutes les règles de gestion de l ’applicatif (package).

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
Schéma général : les 2 phases de la migration Préparation de la migration vers MIG_TEST Analyse des données locales Chargement de MIG_TEST : fichiers plats à partir d ’application(s) locale(s) à partir des données nationales (agora, poppee ==> 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

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).

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 Prévoir les correspondances données locales - Harpège

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 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 5/ Détermination de l ’erreur

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

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

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 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 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.

Chargement des données DPATE dans MIG_TEST
user : DPATE user : MIG_TEST tables des données à migrer, tables temporaires, images des tables d’Harpège SQL Loader tables images des tables Agora et Poppee batch fichiers plats

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

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

Deuxieme phase : migration de MIG_TEST vers HARP_ADM
Pré-requis Les principes de base et objectifs de la migration vers Harpège Schéma général : les 2 phases de la migration Présentation de l ’outil de migration vers Harpège

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) Tables concernées également : LOC_AGENT : local de travail de l ’agent LOC_CHERCHEUR : local de travail des chercheurs hébergés

Les principes de base et les objectifs
Appliquer sur les données migrées l’ensemble des règles de gestion d’Harpège Aucune altération du référentiel Harpège ne peut être envisagée, ni acceptée (tables, programmes, nomenclatures) Objectifs : Disposer d’une base Harpège remplie, et en parfaite cohérence avec les règles de gestion de l’application Disposer d’une base Harpège prête à fonctionner en exploitation

Présentation de l’outil de migration vers Harpège
Fonctionnalités de l ’outil de migration Activation et désactivation des contraintes Le batch de migration les traitements les rejets les composants et leur ordonnancement l’outil d’édition des statistiques Vérification de la structure d ’affectation principale Mise à jour des séquences Suppression de MIG_TEST

Fonctionnalités de l ’outil
de migration user : MIG_TEST user : HARP_ADM contraintes d’intégrité nomenclature lecture Outil de Migration insertion suppression rejet table des rejets règles de gestion

Activation et 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) 2°) Désactivation des contraintes sur MIG_TEST afin de pouvoir migrer les données 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

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 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

Les 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, … Peuvent aussi révéler des erreurs ou des incohérences dans la base locale

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

Mise en œuvre du batch de migration composant par composant en une seule fois sur l ’ensemble des composants 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

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

Vérification de la structure d ’affectation principale
Le script dresse la liste des dossiers pour lesquels il existe une ambiguïté pour déterminer la structure d ’affectation principale de l ’agent.

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

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 Indispensable pour les futures mises à jour Harpège

Présentation du TP

Présentation du T.P. Schéma général : les 2 phases de la migration
1ere phase : des fichiers plats vers MIG_TEST Utilisation de liaison ODBC Utilisation de SQL Loader La migration des données nationales (DPATE) 2eme 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

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 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

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

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 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 : é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. 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

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

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 Exercice Enoncé Outils Solution 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 - 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 - 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 ORACLE7 - 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

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

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 Oracle7 Server Utilities (dont SQL*Loader )

Des fichiers plats vers MIG_TEST : Migration des données nationales DPATE
Pré-requis Schéma général Traitements Pour effectuer le transfert des fichiers plats vers MIG_TEST lancement d ’une procédure => procédure très simple

Migration DPATE : pré-requis
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. Création d’un nouvel utilisateur DPATE, propriétaire des tables images d’Agora et de Poppee contenant les données à migrer

Migration DPATE : le schéma général
user : DPATE user : MIG_TEST user : HARP_ADM tables des données à migrer, tables temporaires, images des tables d’Harpège SQL Loader tables images des tables Agora et Poppee batch batch tables Harpège fichiers plats 1ère phase : migration vers MIG_TEST 2ème phase : migration de MIG_TEST vers HARP_ADM

Migration DPATE : traitements
Chargement des fichiers plats Agora et Poppee (fichiers plats vers les tables du user DPATE) Procédures PL/SQL Un outil de statistique Suppression de l’utilisateur DPATE

Chargement des données
Migration DPATE - Chargement des données Chargement des fichiers plats Agora et Poppee Principe de fonctionnement de SQL*Loader - cf. Utilisation 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

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

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

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 Les données à migrer sont dans MIG_TEST (SQL*Loader, ODBC ou données nationales -AGORA, POPPEE, …- ) Le paramétrage est saisi dans les tables d’HARP_ADM (9 tables concernées : PARAM_ETABLISSEMENT, ORGANISME_RECHERCHE, ORG_MISSION,ANNEE_UNIVERSITAIRE, IMPLANTATION_GEO, TELEPHONE, STRUCTURE, ADRESSE_ADMINISTRAT, ADRESSE_ADMIN_STRUCT)

De MIG_TEST vers HARP_ADM - Principe de fonctionnement
batch user : MIG_TEST tables des données à migrer, tables temporaires, images des tables d’Harpège user : HARP_ADM tables Harpège Ce sont les même package qui sont utilisés que lors de la saisie via l’application Harpège. Appliquer sur les données migrées dans MIG_TEST l’ensemble des règles de gestion d’Harpège Contraintes fonctionnelles : idem saisie

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 : ../MIGRATION/mig_harpege/script/enable.res 2°) Désactivation des contraintes sur MIG_TEST afin de pouvoir supprimer les données migrées : ../MIGRATION/mig_harpege/script/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 Faire un fichier spool Lancer les commandes enable.res et disable.res sous SQL+ user mig_test Vérifier le fichier spool sous vi : recherche /ORA CTRL + F : Défil 1 page vers le bas CTRL + U : Défil 1 page vers le haut

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 - cf. page suivante - 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)

De MIG_TEST vers HARP_ADM - Migration des composants

De MIG_TEST vers HARP_ADM - Traitement des rejets - statistiques
Les rejets sont dans la table REJET de MIG_TEST, caractéristiques 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 Traitement des rejets cf. migration Dpate Outils statistiques ../MIGRATION/mig_harpege/stat/mig_btch_stat « mot_passe_MIG_TEST » « nom_instance » SOUS UNIX 1/ Génération d ’un fichier log dans le répertoire Contenu difficilement exploitable : Faire une recherche sur NOMBRE pour les erreurs de type ORA- 2/ fichiers mig_rej.lst (texte) et mig_rej.rtf (word) Fichiers contenant le résultat formaté des statistiques (à partir du fichier log)

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

De MIG_TEST vers HARP_ADM - Mise à jour des séquences
Une fois la migration terminée. Sous SQLPLUS, utilisateur HARP_ADM lancer le script : ../MIGRATION/mig_harpege/script/maj_seq.ini qui met à jour les séquences Oracle : SQ_ADRESSE_PERS SQ_ADRESSE_ADM SQ_AFFECTATION SQ_DEPART SQ_INDIVIDU SQ_INDIVIDU_DIPLÔMES SQ_MAINTIEN_FONCTION SQ_OCCUPATION … 1/ Faire un spool 3/ Visualiser le spool

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 mig_btch_stat mig_test nom_instance Mise à jour des séquences ORACLE sous SQLPLUS (harp_adm) : @maj_seq.ini

Documentation

La documentation Documentation livrée jusqu’à aujourd’hui :
Classeur conduite de projet Dossier de paramétrage Guide de reprise de données CCI

La documentation Documentation contenue dans le classeur :
Transparents formation installation reprise de données Manuel d ’installation Notes d ’accompagnement de la version Procédure de commandes Oracle

Contenu du CD-ROM Partie serveur : Application en version V Nomenclature en version V Partie cliente : Application partie cliente en version V Documentation technique : 1. Manuel d'installation 2. Manuel d ’exploitation 3. Cahier des charges d ’implantation 4. Dossier de paramétrage 5. Champs obligatoires avec copies d'écrans 6. Listes des nomenclatures (.xls) 7. Manuel Utilisateur 8. Manuel base de formation Modèle de données : 1. MLD 2. MPD

Livraisons à venir Migration MIG_TEST Migration DPATE
outil de migration MIG_TEST manuel de migration harpège Migration DPATE outil de migration DPATE manuel de migration DPATE

Conclusion Présentation du ftp de Montpellier
ftp.montpellier.cpu.fr (login harpread) Arborescence Assistance pour un problème : d ’installation : de migration : Présentation de la base assistance WEB http// consultation des fiches assistances 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 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

Partie II : REPRISE DE DONNEES

Présentations similaires

Présentation au sujet: "Partie II : REPRISE DE DONNEES"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Partie II : REPRISE DE DONNEES

Présentations similaires

Présentation au sujet: "Partie II : REPRISE DE DONNEES"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back