Partie 3 : conversion technique Apogée v 2.80

Objectif du séminaire Aborder la méthodologie de conversion recommandée d’un point de vue technique et opérationnel. Prendre connaissance des tables impactées

Le déroulement Pré-requis Diagnostic de l’existant Les outils de la conversion Les domaines concernés La méthodologie proposée Un exemple : INDIVIDU Mise en place Recommandations

Pré-requis Maîtriser l’application précédente Connaître l’outil SQL*LOADER Maîtriser le langage SQL

Diagnostic de l’existant Source(s) de données SCOLAR : COBOL Autres systèmes … Dossier papier Les outils du diagnostic modèles de données locaux modèles de données APOGEE manuels de conversion

Les outils de la conversion Application existante SCOLAR : COBOL Autres systèmes ... La migration SQL*LOADER Base de données Apogée règles de cohérence contraintes Oracle

Les outils de la conversion : SQL*LOADER Fichier DATA (.dat) Enregistrements Enregistrements non sélectionnés Lecture (.ctl) SQL*LOADER Discard File (.dsc) When clause SQL*LOADER Compte rendu (.log) Correction RDBMS Base de tests APOGEE Enregistrements incorrects Bad File (.bad)

Les outils de la conversion : SQL*LOADER Le fichier de contrôle (.ctl) LOAD DATA INFILE ‘ indetu.dat ’ DISCARDMAX 1200 INSERT INTO TABLE individu (cod_ind POSITION(1:8) INTEGER EXTERNAL cod_thp POSITION(10:11) CHAR, cod_fam POSITION(13:13) CHAR, cod_sim POSITION(15:15) CHAR, cod_pay_nat POSITION(17:19) CHAR, cod_thp POSITION(21:27) CHAR, ... )

Les outils de la conversion : SQL*LOADER Le fichier de contrôle (.ctl) - exemples de variantes INSERT INTO TABLE individu REPLACE INTO TABLE individu INTO individu TRUNCATE cod_ind POSITION(1:8) INTEGER EXTERNAL cod_ind POSITION(*) INTEGER EXTERNAL(8) FIELDS TERMINATED BY ‘ | ’

Les outils de la conversion : SQL*LOADER Les fichiers DISCARD et BAD DISCARD file (.dsc) Uniquement alimenté par la clause ‘WHEN’ Indiquer un nombre maxi d’enregistrements Ecrit dans le même format que le fichier DATA BAD file (.bad) Alimenté par SQL*LOADER le moteur de la base Egalement écrit dans le même format que le fichier DATA

Les outils de la conversion : SQL*LOADER Le fichier LOG Une synthèse des opérations Nombre d’enregistrements à insérer Nombre d’enregistrements à ignorer Nombre d’enregistrements en erreurs Nombre d’enregistrements rejetés Des explications sur la nature des problèmes

Les domaines concernés Individu & Etudiants Inscriptions Administratives Inscriptions Pédagogiques Résultats

Les domaines concernés Individu & Etudiants Données personnelles des individus table INDIVIDU Adresses tables ADRESSE, INS_INFO_ANU Baccalauréats table IND_BAC Autres diplômes table IND_DAC

Les domaines concernés Inscriptions administratives Inscriptions administratives annuelles table INS_ADM_ANU Inscriptions administratives aux étapes tables INS_ADM_ETP Inscriptions pédagogiques Pas conseillée

Les domaines concernés Résultats Résultats aux versions de diplômes tables GRP_RESULTAT_VDI et RESULTAT_VDI Résultats aux versions d’étapes table GRP_RESULTAT VET et RESULTAT_VET Résultats aux éléments pédagogiques table GRP_RESULTAT_ELP et RESULTAT_ELP

Inscriptions Administratives La méthodologie Individus & Etudiants Manuel : convinet.doc Inscriptions Administratives Manuel : convia.doc Résultats Manuel : convresu.doc

Semblable pour les trois domaines Pour chaque table à remplir La méthodologie Semblable pour les trois domaines Pour chaque table à remplir Préparer le fichier plat Renseigner les tables connexes Importer par SQL*LOADER Vérifications de cohérence

La méthodologie par l ’exemple Domaine : Individu & Etudiant Méthode Structure de la table Tables connexes Valeurs de conversion Contrôles de cohérence

La méthodologie par l ’exemple Domaine : Individu & Etudiant Méthodes ETAPE 1 : Consulter la structure de la table INDIVIDU et inventorier les données dont dispose l’établissement, ainsi que celles qui lui manquent. Consulter le schéma des tables connexes à INDIVIDU afin de connaître les tables de référence à nourrir. ETAPE 2 : Compléter éventuellement la table ANNEE_UNI avec les nouvelles années présentes dans les données à convertir (COD_ANU). Ceci peut être fait sous Apogée ou en insérant dans la table par SQL*Loader. ETAPE 3 : Compléter éventuellement la table ETABLISSEMENT avec les nouveaux établissements présents dans les données à convertir (COD_ETB). Ceci peut être fait sous Apogée ou en insérant dans la table par SQL*Loader. ETAPE 4 : Compléter éventuellement la table SIT_FAM avec les nouvelles situations de famille présentes dans les données à convertir (COD_FAM). Ceci peut être fait sous Apogée ou en insérant dans la table par SQL*Loader. ETAPE 5 :...

La méthodologie par l ’exemple Domaine : Individu & Etudiant Structure commentée de la table Individu (vue partielle) 1 Ces champs sont Obligatoires ou Facultatifs au sens de la base de données

La méthodologie par l ’exemple Domaine : Individu & Etudiant tables connexes ANNEE_UNI COD_ANU ETABLISSEMENT COD_ETB ACADEMIE COD_ACD INDIVIDU COD_ANU_SRT_IND COD_ETB COD_FAM COD_PAY_NAT COD_SIM COD_THP COD_UTI COD_UTI_MOD COD_UTI_BLO COD_DEP_PAY_NAI SIT_FAM COD_FAM PAYS COD_PAY DEPARTEMENT COD_DEP COD_ACD SIT_MIL COD_SIM PAYS COD_PAY TYP_HANDICAP COD_THP UTILISATEUR COD_UTI

La méthodologie par l ’exemple Domaine : Individu & Etudiant Valeurs de conversion de la table Individu La notion Obligatoire/Facultative des champs décrits ici est la valeur logique et non physique de cet aspect. Certains champs peuvent être physiquement facultatifs en base mais obligatoires dans l'application.

La méthodologie par l ’exemple Domaine : Individu & Etudiant Règles de cohérence sur la table individu Règle n°1 : Le champ COD_UTI de la table INDIVIDU doit contenir le COD_UTI d’un utilisateur défini dans la table UTILISATEUR. Il est conseillé de créer un utilisateur nommé CONVERSION. Règle n°2 : Le champ DAT_NAI_IND doit être renseigné car il est obligatoire pour le client Apogée. Règle n°3 : Si le champ COD_ANU_SRT_IND est renseigné, il doit contenir un COD_ANU existant dans la table ANNEE_UNI. Règle n°4 : Le champ COD_CIV doit être renseigné car il est obligatoire pour le client Apogée. Règle n°5 : Le champ COD_PAY_NAT doit être renseigné car il est obligatoire pour le client Apogée. Règle n°6 : Le champ COD_TYP_DEP_PAY_NAI doit être renseigné car il est obligatoire pour le client Apogée.

Etudier la documentation SQL*LOADER Mise en place - Résumé Bien réfléchir avant de commencer à la démarche de conversion dans l’établissement Formaliser la démarche adoptée (penser aux besoins ultérieurs en matière de pilotage et de statistiques) Etudier la documentation SQL*LOADER Copier la base de production dans la base de test Travailler sur la base de test (voire sur une base spécifique migration) Vérifier qu’on dispose : du temps CPU de la place disque

Recommandations Ne pas chercher à convertir une S.E en entier et automatiquement Bien renseigner le référentiel avant la conversion

Recommandations Créer un utilisateur conversion Attention à la codification (% - _ ,) Attention au minuscule / majuscule Veiller à recréer les index suite à la conversion (notamment si on importe par ordre alphabétique par exemple) Mise à jour des séquences (cod_ind, cod_etu, cod_adr) $APOGEE_HOME/admin/maj_sequence.sh

Recommandations Conversion IA - IP et batch babajou1 - babanui1 La conversion des IA et éventuellement des IP doit se faire alors qu’aucune action d’inscription n’est en cours via Apogée Trav_ini_res doit être vide Arrêter babajou1 et babanui1 (arrêt architecture batch) conversion truncate de trav_ini_res relancer l ’architecture batch

Questions Vos questions ???