Tables référentielles

Présentation au sujet: "Tables référentielles"— Transcription de la présentation:

1 Interface Infocentre-RH avec TIM et Ldap France  Chargement des employés

2 Tables référentielles
Vue globale des échanges alimentant le LDAP France Acquisition Données CADANA Tables applicatives (DB2) CADANA Tables référentielles (DB2) Proc stock DB2(GFX05) Mise au Format PIVOT LDAP Ecriture MAJ LDAP InfoCentre-RH (Oracle) InfoLDAP Tables fonctions et personnes (Oracle) LDAP EAI/ESB Organisations Loader Oracle Acquisition Données Paie Mise au Format PIVOT LDAP Ecriture MAJ LDAP EAI/ESB Personnes Demi-flux EAI/ESB

3 Données de l’INFOCENTRE-RH
Les données en provenance de l’INFOCENTRE-RH sont sures et considérées comme digne de confiance. L’INFOCENTRE-RH est considéré comme le référentiel des utilisateurs France. Ces données portent l’identifiant de l’utilisateur interne et les informations de lieu, métier et fonction Ces informations de lieu métier et fonction sont la base des systèmes d’habilitation : elles sont indispensables. Les mises à jours des données se font périodiquement : Pour les hypers : toutes les semaines Pour les supers et autres formats : toutes les mois, Au fil de l’eau pour des données traitées par l’Infocentre-RH et en urgence Ces données sont mises à disposition du Ldap France en début de semaine dans une table d’interface appelée INFOLDAP. Le transfert de l’infocentre vers la table d’interface se fait avant 10h00 du matin le lundi pour les hypers Et avant 10h00 le matin le 5 du mois ou le jour suivant si conflit avec le flux précédent pour les autres formats Le transfert des hypers est en mode FULL pour celui intervenant entre le 20 et le 25 du mois (vérifier les dates); sinon en mode PARTIAL. Le LDAP prend ces données (via un échange EAI) et les transfert en mode « doux » vers le LDAP pendant 20 heures au maximum (avant arrêt pour sauvegarde) : En respectant la charge du LDAP soumis aux applications qui sont prioritaires En respectant les contextes utilisateurs dans l’OpenLDAP afin de ne pas perturber l’utilisateur connecté ou non connecté (changement que de ce qui doit l’être par ajout puis suppression des attributs, ….) En contrôlant la cohérence des données avec les lieu/fonctions/métier, … en provenance de CADANA et de l’INFOCENTRE-RH En remontant l’ validé par l’utilisateur …etc…

4 Schéma de transfert des données vers LDAP France
Composition des données d’interface 2 tables sont mises en place : PERSON : il s’agit d’une liste de personnes avec NOM, PRENOM, MATRICULE, PACK-PAIE, BU- AL-DP ( principal, mutés) , DATES (entrée, sortie, mutation), fonction, …, et STATUS AFFECT : il s’agit des affectations de la personne : MATRICULE, PACK-PAIE, BU-AL-DP. Il y a autant de lignes AFFECT pour une personne qu’il y a des affectations 2 autres tables sont mises en place pour les franchisés PERSON_EXT (pas de mutation) AFFECT_EXT D’autres tables sont dans ce schéma et servent à transmettre au Ldap, via un autre échange EAI/ESB, les organisations de type fonctions : ceci n’entre pas dans cette présentation.

5 Echange CADANA vers LDAP Paie EAI/ESB
Schéma de transfert des données vers LDAP France : l’échange Echange CADANA vers LDAP (description dans une autre SFD) Paie EAI/ESB MAJ organisations Thalès Codes Thalès venant de CADANA ou de GSI ou de Thalès InfoCentre RH (Oracle) Chargement de la base infoLdap 1 – chargement des utilisateurs dans la table PERSON 2 – MAJ table REFRESH LDAP Lecture organisations InfoLdap (Oracle) Acquisition Données Mise au Format PIVOT LDAP Ecriture MAJ LDAP Ecriture/MAJ Utilisateurs Dont les « deleted » suivant règle Déclenchement suite MAJ table REFRESH EAI/ESB Périodiquement (24 h) MAJ REFRESH Mise à jour de l’état de chaque personne traitée Sur erreur (pas d’organisation) : l’échange reprendra la personne 24 heures plus tard.

6 OpenLDAP InfoLdap (Oracle) Tables : REFRESH PERSON
Schéma de transfert des données vers LDAP France : l’échange LDAP_INFOCENTRE_INJECT_IN Réveil sur modification de la table REFRESH (eway IN_ORACLE) Prise des Personnes à date, et suivant Status LDAP_LDAP_CHECK_IN Lecture des organisations OpenLDAP InfoLdap (Oracle) Tables : REFRESH PERSON LDAP_LDAP_INJECT_OUT Ecriture/Update/Delete Personne Seulement les personnes Insérées dans le LDAP JCD Lecture InfoLdap JCD Adapt Organi- sation JCD Ecriture LDAP lecture JCD MAJ Status Retry en cas d’erreur Format Pré-Pivot avec organisation donnée par un simple item : celui de CADANA Il y a N personnes dans chaque message : le PAS est donné dans la table REFRESH Format Pivot Ldap Les personnes en erreur sont dans la console EAI. Elles restent dans le status initial et seront « re-prises » lors de la prochaine instanciation de l’échange LDAP_INFOCENTRE_UPDATE_OUT Mise à jour du status de chaque PERSON

7 STATUS des l’interface
La colonne STATUS prend différentes valeurs : UPDATED : l’infocentre à transféré ou mise à jour des données sur la personne INSERED : les données ont bien été insérées dans le LDAP France sans problème. MUT_INSERED : les données ont bien été insérées dans le LDAP France sans problème. Le Ldap France ira vérifier périodiquement les dates de mutation afin de mettre à jour la personne le jour venu (changement de métier, de lieu, de fonction, …) ERROR : une erreur n’a pas permis d’insérer cette personne WARNING : une erreur non bloquante concerne les références aux BU, AL, ou DP. DEL_INSERED : une personne est sortie de l’entreprise ou de son pack paye et pris en compte dans le LDAP France

8 Paie 1 InfoCentre RH (Oracle) LDAP 2 InfoLdap (Oracle) 3 EAI / ESB 4
Schéma de transfert des données vers LDAP France : l’échange 1 – 2 : alimentation INFOCENTRE-RH actuelle 3 – L’EAI met à jour le Ldap France (ETATS : ceux actuels) ; à terme cette étape est supprimée et remplacée par l’étape 5 4 – TIM s’enrichie aussi de ses données 5 – TIM complète avec le code FR, l’ , l’état et met à jour le mot de passe si nécessaire. Paie 1 InfoCentre RH (Oracle) LDAP 2 InfoLdap (Oracle) 3 EAI / ESB Ecriture/MAJ Utilisateurs Dont les « inactive » suivant règle 4 Gestion des identités 5