Vous êtes sur la page 1sur 72
Intégration de données opérationnelle
Intégration de données opérationnelle

Intégration de données opérationnelle

Intégration de données opérationnelle
Intégration de données opérationnelle

02

03

INTEGRATION DE DONNEES OPERATIONNELLE

Auteurs

Jean-François Saluden est architecte sI chez logica. Il est spécialisé depuis 1999 dans l’intégration de données et la Business Intelligence. Il a activement participé à la construction de nombreux systèmes BI et à la rationalisation d’architectures. la majorité de ces chantiers ont mis l’accent sur l’intégration de données et l’optimisation globale des systèmes. son expertise l’a naturellement conduit, au travers d’études préliminaires, à la mise en oeuvre du Hub d’Intégration de données. Il est désormais responsable de l’activité BI et Intégration de données au Centre de service de logica France situé à Montpellier, établissement spécialisé dans la BI, l’intégration de données et le CrM.

Cyrille Lintz est architecte Integration de données chez logica depuis 1998. Il a conçu et déployé des projets pour différents secteurs tels que les télécommunications, le luxe, la grande distribution, l’automobile, l’assurance, l’énergie, les médias ainsi que les industries alimentaires. Cyrille a en particulier participé à la mise en œuvre d’un Hub d’intégration de données utilisant la technologie Informatica pour lU France, appartenant anciennement au groupe danone.

Informatica pour lU France, appartenant anciennement au groupe danone. IntégratIon de données opératIonnelle

IntégratIon de données opératIonnelle

04

Sommaire

1. Présentation de l’Intégration de Données Opérationnelle

07

2. Caractéristiques de l’Intégration de Données Opérationnelle

08

2.1 Explication des caractéristiques de l’Intégration de Données

08

3. Projets d’Intégration de Données Opérationnelle étudiés

10

4. Projets d’Intégration de Données Opérationnelle Temps Réel

12

4.1 Comparaison entre l’Intégration de Données et l’Intégration de Processus

12

4.2 Temps Réel ?

14

5. Détail de trois projets d’Intégration de Données Opérationnelle

15

5.1 Réplication de données

15

5.2 Synchronisation de Données

17

5.3 Data Integration Hub

19

6. Mise en œuvre du Data Integration Hub

25

6.1 Organisation des fonctionnalités du Data Integration Hub

25

6.1.1

le noyau du data Integration Hub: mouvement de données entre systèmes

25

6.1.2

Contrôles de qualité et certification des données

29

6.1.3

gestion des données en rejet

32

6.1.4

Fréquence des flux et orchestration

33

6.1.5

paramétrage / configuration

34

6.1.6

traçabilité et audit

36

6.1.7

surveillance - rapports

37

6.1.8

Fiabilité

38

6.2 Architecture du Data Integration Hub

39

6.2.1

La dynamique d’intégration de données

40

6.2.2

les zones de stockage du Hub

40

6.2.3

autres modules importants du data Integration Hub

43

6.3 Conception du Data Integration Hub

47

6.3.1

demi-flux entrant :

48

6.3.1.1 étape 1 : extraction

48

6.3.1.2 étape 2 : Zone de persistance

52

6.3.1.3 étape 3 : Création du pivot

53

6.3.1.4 étape 4 : recyclage des rejets

56

6.3.1.5 Étape 5 : Acquittement vers le système source

56

IntégratIon de données opératIonnelle

05

6.3.2 Demi-flux sortant

57

6.3.2.1 étape 1 : Identification des données pivot à traiter

57

6.3.2.2 étape 2 : traitement du pivot en fonction de la cible

57

6.3.2.3 étape 3 : stockage dans une zone persistante (zone de staging)

58

6.3.2.4 étape 4 : Chargement ou envoi des données dans la cible

58

6.3.2.5 Étape 5 : Acquittement dans le Data Integration Hub

58

6.4 Bonnes pratiques de mise en œuvre du Data Integration Hub

60

6.4.1 1 ère phase : Liste de toutes les fonctionnalités prévues ou requises

60

6.4.2 2 ème phase : Inventaire des flux de données prévus

61

6.4.3 3 ème phase : Configuration de la base de données du data Integration Hub

61

6.4.4 4 ème phase : Conception et déploiement des flux dans le data Integration Hub

63

7.

Annexes

7.1 table des figures

IntégratIon de données opératIonnelle

69

69

06

Préface

Force est de constater que le monde de l’intégration de données a connu de nombreuses évolutions au cours des deux dernières décennies. les entreprises réalisent de plus en plus la valeur stratégique de leurs données pour leur activité tout en étant confrontées à une véritable explosion des volumes manipulés. Le Gartner estime qu’en 2012, les utilisateurs auront besoin de 6,5 fois plus de tetraoctets qu’en 2008. Historiquement, les principales solutions d’intégration de données se sont développées dans le cadre des initiatives de data Warehousing et de Business Intelligence. Ce marché, que certains analystes appellent plus communément l’intégration de données analytiques, continue d’ailleurs à croître aujourd’hui. Cependant, la plus forte croissance s’observe désormais sur l’intégration de données opérationnelle, qui répond aux besoins tactiques immédiats de l’entreprise afin d’assurer son efficacité opérationnelle. Logica intervient sur l’ensemble des problématiques d’intégration de données et a acquis une solide expertise dans ce domaine.

C’est pourquoi nous avons souhaité rédiger ce livre blanc qui présente une approche méthodologique de nos bonnes pratiques de mise en œuvre des projets d’Intégration de Données opérationnelle.

Ce document a été réalisé en étroite collaboration avec les consultants professional services de l’éditeur Informatica, leader mondial des plateformes d’intégration de données et dont les solutions ont fait leurs preuves en termes de valeur ajoutée.

J’espère vivement que ce document vous permettra d’apporter des réponses concrètes aux questions que vous vous posez sur l’intégration de données opérationnelle. Nos experts se tiennent à votre disposition pour vous apporter leurs retours d’expérience en fonction de votre contexte.

en vous souhaitant une bonne lecture,

Frédéric réault Directeur d’Offre Business Intelligence & Data Management logica France

IntégratIon de données opératIonnelle

1. Présentation de l’intégration de données opérationnelle

07

Avant de poursuivre, attardons-nous sur une définition généralement admise pour l’Intégration de données opérationnelle : I’Intégration de données opérationnelle décrit un ensemble de moyens informatiques permettant d’accéder à des données, les nettoyer, les intégrer et les transmettre, avec une certaine latence, en traitant aussi bien des informations actuelles qu’historiques, afin de les utiliser dans les processus d’entreprise liés à l’exécution d’opérations critiques et appelant à des décisions immédiates. Comme cela a été évoqué précédemment, l’Intégration de Données Opérationnelle répond donc aux besoins tactiques immédiats pour assurer l’efficacité opérationnelle d’une entreprise.

L’Intégration de Données Opérationnelle constitue une pratique assez vaste, qui soutient des initiatives stratégiques plus conséquentes et centrées sur l’information, comme l’implémentation d’applications intégrées, l’intégration des données Client, la gestion des informations produit, la mise en place de la gestion des données de référence dans son ensemble (Master data Management), l’informatique décisionnelle (BI) pervasive, la BI opérationnelle, l’intégration d’applications d’entreprise (eaI), l’intégration des données B2B multi-entreprises, le Business activity Monitoring (BAM) ou encore l’Intégration des Processus Métiers, pour n’en nommer que quelques-unes.

l’Intégration de données opérationnelle est susceptible de prendre en charge tous les aspects de manipulation des données de ces projets, qu’il s’agisse de mouvements ou de conversions de données entre applications, quelle qu’en soit la latence, ou bien de certification de la donnée, de normalisation ou de mise en correspondance accessible sous forme de service pour des applications consommatrices au sein d’une architecture orientée service.

L’offre d’Informatica est particulièrement pertinente pour offrir une plate-forme complète, unifiée, ouverte et au meilleur coût pour adresser toutes les facettes de manipulations de données et ce à l’échelle de l’entreprise.

facettes de manipulations de données et ce à l’échelle de l’entreprise. IntégratIon de données opératIonnelle

IntégratIon de données opératIonnelle

08

2.

Caractéristiques de l’intégration de données opérationnelle

Examinons les différentes caractéristiques d’intégration de données nécessaires aux activités opérationnelles de l’entreprise.

Caractéristiques de l’Intégration de Données Latence : Faible Élevée Volume : Faible Élevé Qualité :
Caractéristiques de l’Intégration de Données
Latence : Faible
Élevée
Volume : Faible
Élevé
Qualité : Standard
Avancée
Structure : Simple
Complexe
Transformation : Standard
Avancée
Orchestration: Standard
Avancée

Figure 1 : Comportement type d’un projet d’Intégration de données

Cet exemple graphique représente les six caractéristiques marquantes d’un projet d’Intégration de Données Opérationnelle. Dans cet exemple, nous indiquons les caractéristiques moyennes (bouton vert) d’un projet de synchronisation de données (expliqué plus bas). La zone grise représente l’écart- type des capacités d’intégration de données pour ce type de projet.

par exemple, la latence moyenne d’une synchronisation de données (bouton vert) est généralement assez faible. la latence peut toutefois être plus élevée dans certains cas : dans le cas d’une chaîne de production à quatre cycles par jour, ses données ne seront synchronisées avec le système financier que quatre fois par jour. Ceci est représenté par un décalage vers la droite de la zone grise.

2.1 ExPLICATION DES CARACTéRISTIquES DE L’INTéGRATION DE DONNéES

Latence des données : représente la capacité à gérer différentes fréquences de mouvement de données. elle peut être programmée (une fois par jour, semaine, mois, etc.), déclenchée par la survenance d’un événement (arrivée d’un fichier, appel à une application, scrutation des applications) ou en temps réel (détection des transactions directement dans l’application source, réception d’un message dans une file).

Volume de données : détermine le volume manipulé en moyenne pour un type de projet donné. Il importe de noter que le volume résulte de deux facteurs : le volume de l’élément traité unitairement et le volume global des données sur une période spécifique. En fait, il peut s’agir de plusieurs millions de lignes copiées quotidiennement d’une application à l’autre ; comme de plusieurs millions de lignes capturées et répliquées en temps réel tout au long d’une journée ; ou de centaines d’énormes fichiers de données arrivant au fil de l’eau toute la journée et à traiter dès leur arrivée ; ou encore de centaines de milliers d’e-mails reçus avec pièce jointe, analysés, convertis et intégrés dans le système d’information, jour et nuit.

IntégratIon de données opératIonnelle

09

qualité de données : garantit que les données sont contrôlées au cours des manipulations et des transferts de ces données. La qualité de données garantit que les données de mauvaise qualité ne seront pas propagées entre systèmes. Ou qu’une donnée de mauvaise qualité provenant de l’extérieur ne pénètrera pas dans le système d’information de l’entreprise. La qualité de données garantit la cohérence, l’intégrité, la complétude et l’exactitude des données. Elle vérifie également que toutes les données qui pénètrent dans le système d’information sont valides conformément aux règles de l’entreprise et ne sont pas doublonnées. La qualité des données identifie également les similarités des données entre systèmes pour créer, maintenir ou avertir des relations entre données de différents systèmes.

Structure des données : définit la large gamme de formats et de structures que le projet peut traiter. Il peut s’agir de données très structurées (mainframe ou rdBMs par exemple) ou d’accès et de format hautement propriétaires comme des applications sap ou oracle eBusiness suite. la structure peut par ailleurs être aussi complexe que des messages EDI ou de gros fichiers XML. Les données peuvent être déstructurées et imprévisibles comme les documents bureautiques Excel ou a dobe pd F.

Transformation des données : décrit la manipulation des données qui doit intervenir pendant leur transfert. Ce peuvent être des transformations basiques de manipulations de chaînes ou de nombres ; ou plus complexes, comme la conversion de valeurs d’un système à l’autre, le calcul ou le fractionnement de valeurs. Souvent, la transformation peut être aussi avancée que l’agrégation, la fusion, le routage, la correspondance ou la standardisation, sur une base d’introspection des données et d’exécution de règles.

Orchestration : décrit la capacité à contrôler de bout en bout les processus de transfert des données. Un transfert de données peut être exécuté de bout en bout et gérer automatiquement les étapes de manipulation, traitement des erreurs, persistance et récupération sur erreur. Ce peut aussi être un long processus d’exécution impliquant des décisions humaines, le stockage temporaire et le traitement manuel des données afin de les qualifier et d’en finaliser le transfert.

IntégratIon de données opératIonnelle

10

3.

Projets d’intégration de données opérationnelle étudiés

Ce document traite uniquement de trois types de projets d’Intégration de Données Opérationnelle. Il aborde les types de projet les plus dynamiques en termes de latence des données mais aussi de grands volumes de données. la réplication et la synchronisation de données sont assez représentatives de ces besoins. le troisième type de projet, le Hub d’Intégration de données, constitue certainement l’implémentation d’Intégration de données opérationnelle la plus avancée, où les six caractéristiques de l’Intégration de Données jouent un rôle important pour répondre aux besoins métiers.

Vous pouvez consulter le livre blanc Intégration de données opérationnelle pour l’entreprise temps réel pour vous faire une idée de certains autres types de projets d’Intégration de données opérationnelle.

Cette étude décrit en premier lieu le type de projet de réplication de données.

Réplication de données :

simple propagation des données et synchronisation de systèmes en temps réel sur des données élémentaires. La réplication de données offre uniquement la possibilité de propager les données en elles-mêmes ou leurs changements, avec très peu de transformations ou de vérifications sur les données. les systèmes source et cible concernés sont principalement des bases de données de même structure et souvent du même éditeur. l‘aspect temps réel des traitements est très important dans ce type de projet.

exemples de projet :

capture d’événements pour la détection de fraude, ods (stockage de données opérationnelles pour un système décisionnel) temps réel, récupération de base de données en cas d’incident, synchronisation multi-sites de base de données, reporting opérationnel…

la seconde partie étudie la synchronisation de données.

Synchronisation de données :

Le projet de synchronisation de données est d’une nature plus légère que le Hub d’Intégration de Données, et assure principalement la cohérence des données entre quelques bases de données hétérogènes ou des applications packagées, in situ ou en Cloud 1 , avec validation de quelques règles métiers légères et résolution de conflits. La synchronisation de données est souvent mise en œuvre selon une approche point à point et dans un périmètre correspondant à un service ou un vertical métier, et vérifie les règles métiers associées afin de garantir la bonne marche de l’activité opérationnelle. elle peut aussi inclure une zone de stockage commune pour des composants transverses et la gestion des données de référence. le projet de synchronisation de données constitue très souvent une première implémentation tactique pour résoudre rapidement un besoin métier critique et peut se transformer en un Hub d’Intégration de Données à l’échelle de l’entreprise à mesure que les besoins métiers évoluent.

exemples de projet :

synchronisation des données client entre un erp et un système CrM, synchronisation des données CRM et financières pour une meilleure connaissance et un meilleur ciblage des clients…

le Hub d’Intégration de données est le dernier type de projet étudié.

1 Le Cloud (en français, informatique en nuages) est un concept majeur faisant référence à l’utilisation de la mémoire et des capacités de calcul des ordinateurs et des serveurs répartis dans le monde entier et liés par un réseau, tel Internet (principe de la grille informatique).

IntégratIon de données opératIonnelle

11

Hub d’Intégration de Données :

le Hub d’Intégration de données peut être considéré comme une plate-forme d’intégration de données complète, capable de traiter tout type de données ou applications, au sein d’une entreprise ou en dehors et ce avec un niveau de transformation élevé, de larges capacités de connectivité, tout niveau de latence et des contrôles transversaux de qualité des données pour en assurer la cohérence globale (entre enregistrements ou entre données différentes). Le Hub d’Intégration de données gère les traitements de bout en bout avec certains routages de données et des conversions de format, et assure la certification des données pour garantir que les processus de l’entreprise reposent sur des informations exactes. Il intègre une zone de stockage intermédiaire qui conserve une trace de tous les contrôles et de toutes les transformations, et assure l’acquittement de la bonne transmission des données ; il peut assurer un monitoring transverse et la traçabilité de toutes les données gérées. le Hub d’Intégration de données alerte les utilisateurs et les invite à gérer les problèmes de cohérence des données ou tout événement notable susceptible d’affecter leur métier.

exemple de projet :

synchronisation de données entre plusieurs applications, interfaçages directs et de bout en bout, synchronisation des données de référence entre systèmes, intégration de données multi-entreprises, prise en compte et gouvernance des documents bureautiques, etc.

le type de projet approprié est choisi selon le périmètre et l’étendue des données gérées et son objectif final. Il faut noter qu’une implémentation limitée comme la réplication ou la synchronisation des données peut également produire les résultats souhaités tout en ayant la capacité à évoluer vers un système plus complet.

IntégratIon de données opératIonnelle

12

4.

Projets d’intégration de données opérationnelle Temps Réel

la besoin à l’origine de l’Intégration de données opérationnelle naît principalement des besoins de cohérence des données entre les systèmes d’information ; les données doivent être fiables et cohérentes entre les systèmes, et conserver la même signification, qu’il s’agisse de données transactionnelles ou de référence. en plus de ce problème de cohérence, l’Intégration de données permet de gérer des volumes variables depuis des transactions unitaires en temps réel, jusqu’à l’intégration de données en grands volumes par batchs (de milliers d’enregistrements à plusieurs centaines de millions d’enregistrements par jour traités massivement).

Avant d’examiner en détail les types de projets, leurs similarités et spécificités, nous expliciterons les concepts d’Intégration de Données Opérationnelle ainsi que les différences entre Intégration de Données et Intégration de Processus, car ces deux typologies de projets, pourtant différentes, prêtent souvent à confusion.

4.1 COMPARAISON ENTRE L’INTéGRATION DE DONNéES ET

L’INTéGRATION DE PROCESSuS

Quel que soit le point de vue adopté, l’objectif ultime consiste à résoudre un problème d’intégration compliqué pour l’entreprise, qui pèse sur l’optimisation opérationnelle de l’activité. La résolution de ce problème peut être abordée du point de vue des processus ou des données. les projets d’Intégration de processus visent à produire des processus métiers standardisés et à en garantir la cohérence en définissant leurs différentes étapes et en propageant les données qui y sont liées ; les données en elles-mêmes sont propagées par les systèmes reliés entre eux par un processus, mais avec très peu de transformations et seulement quelques contrôles de cohérence nécessaires au bon déroulement du processus.

L’Intégration de Processus ne vise pas à contrôler ni à gérer la cohérence ou la qualité des données ; elle assure seulement que les données entrantes sont correctes pour la bonne continuité du processus. elle assure également la transmission rapide des données entre les systèmes, conformément à l’ordonnancement des processus de l’entreprise, mais ne concerne généralement que des transactions unitaires ; ainsi, elle ne vise pas à contrôler la cohérence globale des données entre différents systèmes sources ou plusieurs enregistrements.

les projets d’intégration de processus sont principalement construits autour d’outils d’enterprise application Integration (eaI) ou de composants entreprise service Bus (esB) pour l’analyse des transactions et la transmission des données, mais n’inclut pas en règle générale de composants avancés de Qualité des données et ne comble pas totalement les besoins de gouvernance des données. l’Intégration de processus transfère la plupart du temps des données unitaires en quasi temps-réel, mais peut en outre traiter des données en masse, en inspecter le contenu ou les transformer. de plus, dans ce type de projet, les processus dirigent les actions d’intégration de données.

IntégratIon de données opératIonnelle

13

Comme nous l’avons mentionné en introduction, alors que l’objectif principal de l’Intégration de données opérationnelle consiste principalement à maintenir la cohérence des données au sein des systèmes d’information, suivant les besoins métiers, afin de délivrer la bonne information au bon moment, les projets d’Intégration de données sont centrés sur les données proprement dites et leur appliquent différents types de transformations tout en les transférant entre applications. Ces transformations comprennent le formatage, les fusions, les agrégations, le routage en fonction du contenu, la validation et même la complétude des données. la capacité à traiter tout volume de données en masse (un fichier de 10 Go par exemple) ou des transactions unitaires, quelle que soit la latence, constitue un autre aspect de l’Intégration de Données. Il devient aussi évident que les données proprement dites peuvent contenir des informations clés susceptibles d’affecter ou même de diriger l’automatisation de processus. Cette notion est connue sous l’appellation « data driven process Integration » (Intégration de processus pilotée par les données).

dans l’Intégration de processus pilotée par les données, les données entrantes véhiculent certaines informations qui déclenchent les processus. Les données actionnent des traitements directs qui sont automatisés en fonction du contenu de ces données. Il s’agit souvent d’énormes fichiers à traiter, qui génèrent des transactions orchestrées dans de multiples applicatifs. Ce contexte crée un besoin crucial de contrôle et de certification des données pour garantir un déroulement correct du processus. Il existe également un besoin fort en termes de gouvernance des données pour comprendre quels processus ont été déclenchés en fonction des données traitées. Connaître chaque état des données à chaque étape du processus ou à chaque fois que la donnée est manipulée est également un besoin important dans ces contextes.

est également un besoin important dans ces contextes. Enfin, le problème n’est pas tant d’opposer

Enfin, le problème n’est pas tant d’opposer l’Intégration de Données à l’Intégration de Processus, toutes deux étant très complémentaires, mais de mieux comprendre les besoins du projet et d’utiliser la meilleure technologie en fonction de l’utilisation prévue. Ces deux types d’intégration sont très fréquemment nécessaires pour subvenir aux besoins des activités métiers opérationnelles.

Ceci dit, il est intéressant de noter qu’un projet d’Intégration de Processus est souvent beaucoup plus complexe et long à mettre en œuvre, car il touche directement à de nombreux processus applicatifs internes et à des fonctions qui doivent être réexaminées. Par exemple, la modification d’un processus SAP ou Oracle ERP n’est pas en soi une tâche aisée, en particulier lorsqu’elle doit être exécutée non seulement au sein d’un erp ou d’un système patrimonial existant, mais également à travers de nombreux systèmes répartis dans le monde. Il ne s’agit pas seulement d’un problème d’implémentation technique d’une application ; le problème consiste principalement à coordonner plusieurs départements métiers qui doivent travailler ensemble pour affiner les processus afin de gérer les transactions métiers.

Un projet d’intégration de données est plus rapide et plus facile à mettre en œuvre car, quelle que soit la transaction, elle est toujours initiée par une donnée et fournit toujours une donnée. le projet d’Intégration de Données est le plus proche de ce patrimoine précieux qu’est la donnée et, quel que soit le processus métier, l’objectif ultime consiste à obtenir des données cohérentes à travers l’ensemble des applications.

IntégratIon de données opératIonnelle

14

4.2 TEMPS RéEL ?

le temps réel est souvent considéré comme la capacité à délivrer les informations instantanément. Mais s’agit-il bien du besoin réel ? Examinons la définition communément admise de l’informatique temps réel :

les systèmes temps réel sont soumis à des contraintes de même nature, c’est-à-dire aux délais opérationnels entre un événement et la réponse du système.

les calculs en temps réel sont considérés avoir échoué s’ils ne sont pas terminés avant un délai imparti, délai qui est lié à un événement. En Temps Réel, un délai limite doit être respecté quelle que soit la charge du système.

Il n’est pas question ici de considération de performance dans l’absolu ; la rapidité d’une opération, qui est elle-même une notion somme toute relative, ne doit pas être confondue avec la capacité à fournir l’information sous une contrainte temporelle, quelle qu’elle soit.

le besoin de « temps réel » dans un contexte d’intégration des données doit prendre en compte les différentes latences exigées pour tous les systèmes concernés ; il est inutile d’essayer d’aboutir à du temps réel pour toutes les sources et les cibles, mais il convient de se concentrer sur le moment où les données doivent être disponibles pour un système cible spécifique, en prenant en compte les besoins métiers et les processus associés. C’est pourquoi il est préférable de raisonner en termes de « Juste Temps » (Right Time) plutôt que de « Temps Réel » (Real Time). Cette approche est en outre plus cohérente, car elle respecte les dépendances entre les systèmes cibles (données devant exister dans un système donné uniquement lorsque les données correspondantes existent dans un autre).

Définition et critères de « Temps Réel » dans le contexte d’Intégration de Données :
Définition et critères de « Temps Réel » dans le contexte d’Intégration de Données : les jalons
opérationnels peuvent être vus comme des créations/modifications/soumissions de données
dans un système et la réponse d’un système la production de données finales, conformément à
l’ordonnancement des processus métiers.
Temps
Processus
Processus
Processus
Processus
métier 1
métier 2
métier M
métier N
Application
Synchronisation des données
ERP
« Juste Temps » pour synchroniser l’Application liée au
processus métier M
RDBMS
« Juste Temps » pour synchroniser le RDBMS lié au processus
métier N

Figure 2 : Définition du « Juste Temps » au-delà des considérations de latences techniques

IntégratIon de données opératIonnelle

5. Detail de trois projets d’integration de donnees operationnelle

5.1 RéPLICATION DE DONNéES

15

la réplication est souvent considérée comme un simple mécanisme présent dans les outils des principaux éditeurs de base de données. dans ce contexte, la réplication est souvent une simple propagation des données permettant de synchroniser différentes instances de base de données utilisant une structure identique ou très similaire. Ce mécanisme repose sur les fichiers journaux des bases de données, qui sont capables de tracer toutes les modifications qui sont intervenues sur une « source » pour les propager aux « cibles ». Ces solutions sont généralement utilisées dans des contextes simples pour maintenir la cohérence entre différentes instances de base de données homogènes.

Caractéristiques de l’Intégration de Données Latence : Faible Élevée Volume : Faible Élevée Qualité :
Caractéristiques de l’Intégration de Données
Latence : Faible
Élevée
Volume : Faible
Élevée
Qualité : Standard
Avancée
Structure : Simple
Complexe
Transformation : Standard
Avancée
Orchestration: Standard
Avancée

Figure 3 : Comportement type d’un projet de réplication de données

toutefois, un outil propriétaire de réplication de base de données atteint ses limites dans de nombreux cas.

1 Limitations techniques pour la réplication hétérogène. Ces solutions étant généralement liées à des bases de données propriétaires, il leur est difficile d’agir sur des processus d’intégration internes et natifs (comme dans le cas d’un erp ou des transactions d’Applications, qui comportent souvent un processus d’intégration interne pour les données entrantes) et elles sont souvent limitées au même type de base de données en source et en cible.

2 Coûts de mise en œuvre et de maintenance liés à la nécessité de recourir à du scripting (dont la modification ou l’implémentation de bases de données locales), la récupération d’erreur à froid (en particulier en cas de réplication multi-site pour garantir un rejeu correct de la transaction), la mise en œuvre très technique exigeant des connaissances approfondies de la base de données et limitée au niveau de l’évolutivité hors solution de l’éditeur de la base de données.

3 Lorsque le nombre d’instances augmente, il devient de plus en plus difficile d’assurer une synchronisation correcte sans conflit. À mesure que la complexité de l’architecture s’accroit et que le nombre de transactions opérationnelles augmente, des décisions doivent être prises en cas de collision de données : lorsque deux transactions sont générées sur le même enregistrement, une stratégie doit être définie pour en déterminer la priorité ; ces

IntégratIon de données opératIonnelle

16

solutions sont habituellement basées sur des critères simples (horodatages de transaction par exemple, s’il est possible d’unifier les horodatages sur des fuseaux horaires différents…) et, avec une liberté de décision très étroite, peut conduire à des choix arbitraires (quels enregistrements conserver, lesquels abandonner…). L’introspection sur les données est en outre limitée car les règles de réplication sont généralement définies sur la structure des données et non sur leurs valeurs ; dans ce contexte, les décisions à appliquer sont très limitées et peuvent être soumises à caution.

4 non extensible en dehors du système de bases de données relationnelles (synchronisation de données d’applications d’ entreprise comme sap, oracle eBusiness suite, etc.) - une autre solution doit donc être acquise alors qu’une solution unique assurant à la fois la réplication et la synchronisation des données constitue un investissement plus pérenne et réutilisable.

les solutions de réplication standard présentent également la particularité d’éliminer les journaux de base de données et de les conserver uniquement comme points de restauration en cas de récupération sur incident. Ils ne peuvent pas être considérés comme une zone de stockage persistante facile d’accès pour suivre individuellement chacune des modifications qui ont eu lieu. Même si les modifications sont effectivement propagées, les détails sur ces changements et la

trace des éventuelles décisions prises sont perdus

contraire aux règles de traçabilité et de conformité telles que Sarbanes-Oxley ou Bâle II. Un historique complet du suivi des données ne peut pas être assuré.

selon le contexte, cette situation peut s’avérer

Par conséquent, le mécanisme de réplication des données doit non seulement pouvoir propager les modifications entre plusieurs systèmes, mais aussi :

propager en fonction de règles plus complexes, comme le contenu des données (valeurs des champs, comparaisons…)

• Éventuellement fournir une zone de stockage, qui suit toutes les modifications de journaux éphémères de bases de données ou capable de stocker des composants communs.

pour ce faire, la réplication de données en temps réel propose 2 composants :

• Un composant de Change Data Capture (CDC), qui est une couche d’abstraction permettant d’accéder aux fichiers journaux. Idéalement, ce composant doit également pouvoir travailler en mode batch de masse pour initialiser la (les) cible(s) lors de la première exécution avant de lancer le mécanisme de CdC proprement dit.

Une zone de stockage commun pour stocker des règles ou des transformations évoluées, ainsi que pour choisir les modes de propagation des données et gérer les résolutions de conflits. Lorsque des règles très complexes sont nécessaires pour les contrôles ou les transformations des données, une implémentation de type synchronisation de données doit être envisagée.

avec ces deux composants, il est également possible d’assurer la réplication entre systèmes hétérogènes en utilisant des outils dotés de la connectivité adéquate et des flux de données source et cible distincts.

IntégratIon de données opératIonnelle

17

5.2 SyNCHRONISATION DE DONNéES

l’objectif de la synchronisation de données consiste à copier les données d’une application à l’autre, avec des niveaux de transformations des plus basiques aux plus avancés. Le champ d’application d’un tel projet se situe principalement au niveau d’un service ou d’un département de l’entreprise, afin de maintenir la synchronisation entre les verticaux pour une meilleure efficacité métier.

la synchronisation permet la propagation d’un système vers un autre, selon une approche point à point. Mais elle introduit cependant une notion d’industrialisation car elle est mise en œuvre à travers une plate-forme centralisée et évite ainsi l’emploi de plusieurs technologies et de développements unitaires susceptibles de conduire à un manque de cohérence globale.

Caractéristiques de l’Intégration de Données Latence : Faible Élevée Volume : Faible Élevée Qualité :
Caractéristiques de l’Intégration de Données
Latence : Faible
Élevée
Volume : Faible
Élevée
Qualité : Standard
Avancée
Structure : Simple
Complexe
Transformation : Standard
Avancée
Orchestration: Standard
Avancée

Figure 4: Comportement type d’un projet de synchronisation de données

la synchronisation de données peut s’accommoder des contraintes des systèmes sources :

les latences de synchronisation sont adaptées à la nature du système source (opérationnel ou analytique…) et donc à la criticité des données.

la technologie de synchronisation peut prendre en charge une large gamme de connectivités d’entreprise.

d’autres fonctionnalités apportées par la synchronisation de données autorisent l’application de règles et de processus plus complexes :

les règles métiers peuvent être validées car le système de synchronisation des données est un système intermédiaire qui peut apporter davantage de fonctionnalités en termes de contrôle et de transformation que la réplication. Par exemple, une donnée Prospect existe dans un système, elle est envoyée au système cible pour devenir un Client et recevoir une Identifiant Client unique. Elle est ensuite resynchronisée vers le système source avec cette information.

• La résolution des conflits est plus facile à traiter, avec des contrôles ou des transformations évoluées.

IntégratIon de données opératIonnelle

18

• L’intervention humaine peut être incluse dans ce type de système en définissant des points de validation dans le mécanisme de synchronisation, lorsque les contrôles de qualité ou d’autres contrôles émis sur les données peuvent mettre en évidence des problèmes.

• Transcription des données de référence du système source (qui ne sont généralement pas décrites de la même manière dans toutes les applications) en valeurs appropriées dans le système cible.

Il est essentiel qu’un tel projet repose sur la complétude de la vision des données à traiter et des différents systèmes concernés. Cela évite la redondance des échanges de données et garantit la délivrance des données en « Juste temps ».

Le rôle du serveur de synchronisation représente un autre point critique pour la réussite d’un projet de synchronisation de données. doit-il être seulement porté par un processus etl (extraction- Transformation-Chargement) ? Absolument pas ; il doit être considéré comme une application complète, gérant non seulement l’extraction des données, leur transformation et leur transport vers une cible, mais aussi assurant à la fois la cohérence unitaire des données entrantes et d’un point de vue global dans toutes les cibles impliquées dans le processus de synchronisation.

C’est pourquoi la mise en place d’une zone tampon peut également être envisagée pour limiter les interdépendances entre les systèmes dans une approche point à point, dans le but d’éviter les conséquences suivantes :

• Mauvaise gestion des transactions entrantes / sortantes ; les connexions source et cible pouvant interagir dans le cadre d’un mouvement de données en pipeline, ce qui peut aboutir à des temps de connexion plus longs de chaque côté.

• Les extractions répétées sur une même source, pour laquelle peuvent correspondre plusieurs cibles, traitant potentiellement les mêmes données ou des données similaires.

• Équipes d’exploitation distinctes pour la gestion des applications source et cible, dont les contraintes peuvent être différentes. La zone tampon apporte un découplage des systèmes et permet de les maintenir sans affecter le système source ou cible simultanément.

Cette zone persistante intermédiaire est un élément essentiel et obligatoire de l’architecture du data Integration Hub, détaillé dans la section suivante.

Lorsque le nombre de systèmes sources et cibles augmente, ou si le périmètre initial du projet (limité à un service ou un département de l’entreprise) évolue vers un modèle multi-métiers, l’implémentation d’une synchronisation point à point atteint ses limites ; il sera plus difficile de maintenir un tel système dans l’optique d’une rationalisation du système d’information.

En outre, il sera plus difficile d’obtenir une vue globale des processus métiers concernés et d’assurer la cohérence des données transversalement aux différents domaines métiers. Dans ce cas, un système d’échange de données centralisé tel que le Data Integration Hub doit être envisagé ; l’effort consenti au niveau du système de synchronisation n’est pas perdu car il peut constituer une base solide pour la mise en œuvre du data Integration Hub.

IntégratIon de données opératIonnelle

19

EXCEL XML WORD PDF Evolution Codage COBOL permanente manual des interfaces Consultants ETL b Erreur
EXCEL
XML
WORD
PDF
Evolution
Codage
COBOL
permanente
manual
des interfaces
Consultants
ETL b
Erreur de
qualité de
C++
données
ETL a
Consultants
EAI
Référentiel
CRM
Logistique
Prise de
Budget
Facturation
Marketing
Data
GED
produit
commande
Warehouse

Figure 5 : la synchronisation point à point des données produit un « plat de spaghetti »

5.3 DATA INTEGRATION HuB

le data Integration Hub peut être vu comme une extension du concept de synchronisation de Données. Il introduit le traitement direct de bout en bout des données, dans le cadre duquel les processus métiers sont portés par les données elles-mêmes, offrant une vue transverse des données gérées par une approche de gouvernance des données. la différence entre le data Integration Hub et la synchronisation de données réside dans la présence de composants applicatifs et la complétude de l’architecture applicative.

en outre, le data Integration Hub introduit le concept de demi-flux (des sources vers le Hub et du Hub vers les cibles) qui permet de centraliser l’échange de données et d’éviter des interfaces point à point spécifiques. Nous avons déjà vu qu’un certain nombre de ces composants pouvaient être mis en place dans le cas de la synchronisation de données. Une initiative de synchronisation de Données peut également être la première brique d’un système plus transverse et plus complet, qui deviendra un data Integration Hub

IntégratIon de données opératIonnelle

20

Caractéristiques de l’Intégration de Données Latence : Faible Élevée Volume : Faible Élevée Qualité :
Caractéristiques de l’Intégration de Données
Latence : Faible
Élevée
Volume : Faible
Élevée
Qualité : Standard
Avancée
Structure : Simple
Complexe
Transformation : Standard
Avancée
Orchestration: Standard
Avancée

Figure 6 : Comportement type d’un projet de data Integration Hub

Nous devons alors choisir quel type d’implémentation devrait être mis en place… Il dépend pour une grande part des données et du périmètre métier : si les données proviennent d’un seul vertical métier, avec peu de systèmes impliqués et principalement dans un seul processus métier, la synchronisation de données est préférable.

elle peut dans ce cas être considérée comme une plate-forme point à point évoluée, et peut être mise en place pour un coût raisonnable. les projets de décommissionnement applicatif forment un sous-ensemble de ce type d’implémentation, avec un périmètre plus restreint qui n’implique qu’un système source (l’ancien) et un système cible (le nouveau) ainsi que des données de référence cohérentes et des transcodifications.

l’objectif du data Integration Hub est de gérer et de centraliser intégralement tous les échanges de données, en assurant la cohérence transversale des données, et ce au niveau de l’entreprise. Il gère tous les types de données et concerne tous les secteurs métiers de l’entreprise. avec le nombre de systèmes sources et cibles concernés, sa particularité technique consiste à gérer différentes latences et volumes, du message individuel en Juste Temps jusqu’aux gros volumes en batch.

Le point essentiel sur le plan technique consiste à mettre en place l’outil d’échange de données approprié capable de gérer cette diversité et sur le plan applicatif, de standardiser le processus d’intégration, même avec de telles différences et variétés de sources et de formats (fichiers plats, bases de données relationnelles, applications, ERP, documents bureautiques, normes et standards comme les formats EDI…), et ce quel que soit l’emplacement physique de la source (interne ou externe à l’entreprise).

Il est indispensable que l’architecture du Data Integration Hub repose sur une vision et une définition communes des données métiers et des données de référence ; même si tous les systèmes impliqués dans les échanges de données ne partagent pas le même langage, le data Integration Hub doit définir un langage commun afin de pouvoir établir des correspondances et constituer l’unique passerelle entre ces systèmes tout en garantissant une qualité de données adéquate.

IntégratIon de données opératIonnelle

21

pour obtenir cette vision transverse, le data Integration Hub doit assurer la traçabilité complète des données jusqu’à leur destination finale. Une zone de stockage temporaire intermédiaire est nécessaire pour ce faire.

EXCEL Business
EXCEL
Business
XML WORD PDF
XML
WORD
PDF

DIH

Exploitation
Exploitation
ce faire. EXCEL Business XML WORD PDF DIH Exploitation Référentiel produit CRM Logistique Prise de commande

Référentiel

produit

CRM

Logistique

Prise de

commande

Budget

Facturation

Marketing

Data

Warehouse

GED

Figure 7 : la synchronisation vue par le data Integration Hub

Le stockage temporaire est une zone de préparation qui permet de conserver les données transmises et tracer les informations échangées. associée à un framework applicatif, cette zone persistante permet de gérer d’une manière centralisée :

l’administration fonctionnelle : toutes les informations peuvent être tracées et visualisées via une interface de reporting.

la gestion des rejets : le stockage et le framework peuvent mettre en évidence les rejets, permettant aux utilisateurs métiers de corriger des données inappropriées et de les resoumettre en entrée du processus d’intégration. pour permettre cette fonctionnalité, le stockage persistant doit conserver les enregistrements entrants tels quels afin de pouvoir les réinjecter comme s’il s’agissait de données standard en entrée. Ce stockage des données brutes peut être réalisé dans la zone de préparation en utilisant :

- le stockage binaire du (des) message(s) ou de la (des) transaction(s) : es types de données BLOB ou CLOB, qui peuvent stocker n’importe quelle structure de données.

- Une structure de base de données XML, qui reflète la structure des données entrantes ou un champ XML contenant l’ensemble du message ou de la transaction.

IntégratIon de données opératIonnelle

22

• Des tables de référence pour les transcodifications. Cette zone de stockage sert également à effectuer les traductions entre les données de référence, qui ne sont généralement pas décrites de la même façon dans toutes les applications. Ces transcriptions font partie des transformations effectuées pendant les processus ETL. Elles peuvent être nécessaires dès que deux applications peuvent créer les mêmes données métiers avec des identifiants techniques différents. Ces enregistrements doivent être reliés entre eux dans la zone persistante pour déterminer, à l’aide des champs de référence métiers, les correspondances possibles et la stratégie à définir pour les unifier.

• Un composant de qualité des données facultatif peut être utilisé pour déterminer les correspondances potentielles et pour définir les règles de priorité de fusion d’enregistrements lorsque des critères automatiques peuvent être appliqués (correspondance stricte ou approximative), ou laisser les utilisateurs déterminer manuellement les règles de priorité / fusion. pour cela, les enregistrements doivent être rapprochés une première fois pour déterminer les règles de fusion, pour ensuite établir les relations entre les identifiants techniques de l’application d’origine pour propager les modifications d’une application à une autre. De la même manière, des références croisées sur les identifiants techniques permettent une synchronisation bidirectionnelle.

En plus de ces fonctionnalités importantes, fréquemment mises en œuvre pour les projets de Synchronisation de Données, le Data Integration Hub se compose de plusieurs briques pour garantir la cohérence du processus d’intégration de données sur l’ensemble des systèmes :

Une première zone de préparation optionnelle : stocke les données « en l’état » sans aucune modification de structure par rapport au système source. Les données sont persistantes sur un certain laps de temps pour plusieurs raisons :

- Fonction de traçabilité : les administrateurs ou les data stewards peuvent voir les données entrantes et identifier les problèmes qui trouvent leur origine dans les systèmes sources.

- recyclage des données : les administrateurs sont en mesure de corriger et de resoumettre les données directement dans cette zone.

- Identification des changements : lorsque la capture directe des données modifiées sur les systèmes sources est impossible, cette zone offre la possibilité de comparer les données afin d’identifier toutes les modifications intervenues ; il est également possible de déterminer les modifications et leurs effets entre plusieurs systèmes sources gérant le même type de données, ce qui n’aurait pas été possible directement avec un composant technique de type Change Data Capture.

Une base de données pivot: cette zone constitue le cœur du data Integration Hub. elle stocke les données conformément à une définition métier commune et transverse de tous types d’objets. le design du modèle de données de cette zone est un point crucial dans la conception de l’ensemble de la plate-forme Data Integration Hub ; il devra prendre en compte le gestion des données depuis la zone de préparation jusqu’à leur livraison dans les systèmes cibles. Cette zone pivot devra contenir :

IntégratIon de données opératIonnelle

23

- La structure pivot de chaque objet métier géré.

- eventuellement, une structure additionnelle pour stocker des données brutes ou binaires liées à ces objets (comme des images, etc.)

- des tables d’erreur, traçant tous les problèmes survenant sur les transformations de données (des données brutes en entrée au format pivot, du format pivot au format de la cible).

- Une table traçant l’ensemble des intégrations effectuées dans les systèmes cibles ainsi que l’acquittement en provenance de ces systèmes.

Une base de références : elle stocke les données de référence ou toute autre donnée utile aux contrôles de cohérence ou aux transcodifications.

Un framework applicatif peut assurer un monitoring complet sur tout le processus de synchronisation, grâce aux fonctionnalités suivantes :

gestion des métadonnées de l’Intégration de données et lignage complet depuis les sources jusqu’aux cibles, en y incluant les contrôles et les transformations effectuées.

traçabilité complète et gestion des rejets à destination des utilisateurs métiers grâce à une interface utilisateur conviviale et simple, masquant toute la complexité de modélisation du framework applicatif.

Intégrité des données de bout en bout, notamment concernant les dépendances entre systèmes cibles, garantissant ainsi que des données peuvent bien être propagées vers un système cible donné car les données parentes ont déjà été totalement intégrées dans un autre système.

tout ceci fournit un reporting complet et une journalisation des événements maximale (nombre d’enregistrements traités, nombre de rejets, acquittement de la cible…) et permet de suivre l’Intégration de processus par un système de monitoring d’entreprise, conformément à une approche Gouvernance des Données, et qui se focalise sur la qualité des données pour améliorer et protéger les informations.

tous ces composants permettent aux utilisateurs métiers de participer au processus d’Intégration de Données, et leur offre une couche d’abstraction simple à appréhender, ce qui leur permet de piloter la Synchronisation de Données sans avoir à comprendre les détails de l’implémentation technique et ainsi de se concentrer sur les enjeux réels : les données proprement dites et les processus de l’entreprise. la plate-forme d’Intégration de données peut ensuite être orchestrée par l’ordonnanceur natif de la plate-forme ou voire son propre module d’orchestration piloté par des services Web.

elle peut aussi être facilement couplée à un esB en utilisant les services Web ou JMs pour devenir le point d’entrée unique de l’entreprise pour tout ce qui touche aux transformations de données et pour toute approche d’Intégration de processus.

IntégratIon de données opératIonnelle

24

Ce dernier point doit être fortement souligné, en particulier pour les entreprises ayant défini une stratégie d’implémentation soa. le data Integration Hub est un élément clé dans une stratégie SOA ; l’ensemble des transformations, mouvements, conversions ou contrôles de qualité des données peuvent être exposés comme des services. de plus, comme le data Integration Hub repose sur un format canonique et peut virtuellement accéder à toutes les sources et cibles de l’entreprise, il peut être un fournisseur de données à l’échelle de l’entreprise.

Tout type d’application, qu’elle soit monolithique, composite, distribuée ou même une application « software as a service », peut utiliser ou piloter le data Integration Hub en utilisant des appels de services Web.

ou piloter le data Integration Hub en utilisant des appels de services Web. IntégratIon de données

IntégratIon de données opératIonnelle

6. Mise en œuvre du Data Integration Hub

25

6.1 ORGANISATION DES FONCTIONNALITéS Du DATA

INTEGRATION HuB

Ce chapitre détaille les fonctionnalités proposées par le data Integration Hub. Ces fonctionnalités sont classées en plusieurs blocs, chacun mettant en avant une caractéristique du Data Integration Hub. Il n’est pas nécessaire d’implémenter toutes les fonctionnalités ; tout dépend de leur criticité à assurer le niveau de service requis sur un projet.

Intervention humaine Traçabilité Monitoring Fiabilité Qualité de Service Configuration Gestion d’erreur
Intervention
humaine
Traçabilité
Monitoring Fiabilité
Qualité de Service
Configuration
Gestion d’erreur
Contrôle de la latence
Contrôle de la qualité des données
Contrôle de la qualité des données

Fonctionnalités communes d’échange

Figure 8 : Fonctionnalités du data Integration Hub

6.1.1 Le noyau du Data Integration Hub : mouvement de données entre systèmes

Voici les principales fonctions que le Data Integration Hub doit prendre en charge pour gérer des mouvements de données entre systèmes.

Pour une meilleure compréhension, chaque explication est basée sur les dénominations « source » et « cible », mais dans le concept de data Integration Hub, un système donné peut être une source, une cible ou les deux à la fois, selon le flux de données considéré.

IntégratIon de données opératIonnelle

26

Message MQ
Message
MQ
Demi-flux entrant
Demi-flux entrant
Demi-flux sortant 1
Demi-flux sortant 1
Demi-flux sortant 2
Demi-flux sortant 2
Demi-flux sortant 3
Demi-flux sortant 3
sortant 1 Demi-flux sortant 2 Demi-flux sortant 3 Data Integration Hub Base de données DB2 Siebel

Data Integration Hub

Base de données DB2
Base de
données
DB2
Siebel Fichier XML
Siebel
Fichier
XML

Figure 9 : Flux dIH type : routage depuis une source vers 3 cibles

a. Routage des données sources vers un ou plusieurs systèmes cibles

Comme illustré dans le diagramme ci-dessus, le data Integration Hub permet de ne solliciter un système source qu’une seule fois pour alimenter plusieurs cibles distinctes. Par exemple, un message MQ Series peut être lu dans une file de messages MQ en entrée, puis délivré à 3 systèmes cibles différents tels qu’une base de données DB2, une instance Siebel et un fichier XML, comme le montre le schéma précédent.

l’avantage de cette solution par rapport à une approche point à point est la mutualisation des processus d’extraction et des contrôles qui leur sont associés : il en découle un gain de performance, une maintenance plus aisée et une moindre sollicitation du système source (ce qui est particulièrement intéressant dans le cas de sources opérationnelles).

le data Integration Hub est capable d’acheminer des données en fonction des informations de leur en-tête, du type d’événement ou du type de source dont elles sont issues, mais plus important encore, le Data Integration Hub est capable d’effectuer une introspection des données elles-mêmes, qu’il s’agisse d’une transaction unique ou de milliers de transactions en masse. Le Data Integration Hub peut suivre des règles de routage basées sur des techniques avancées de traitements des données.

b. Conversion ou propagation de tous les formats de données sources vers un format cible approprié

Le Data Integration Hub est capable de convertir n’importe quel type de format de données dans le format adéquat aux systèmes cibles. Par exemple, un message iDoc SAP peut être facilement converti en structure de données XML, puis au format Excel ; ou un document PDF Adobe peut être analysé afin de charger certaines de ses informations dans une base de données relationnelle. Il peut aussi s’avérer utile de prendre en charge des données image (ou autres formats binaires) dans l’optique de les faire transiter par ce biais : il s’agit par exemple de scans de factures ou de bordereaux de livraison.

IntégratIon de données opératIonnelle

27

c. Prise en charge de différents protocoles de communication et de formats de données

Le Data Integration Hub doit être capable de communiquer, en lecture comme en écriture, avec un large panorama de systèmes qui utilisent des protocoles d’accès différents. Le Data Integration Hub peut, grâce à son architecture, relier des systèmes hétérogènes, même s’ils ne sont pas directement compatibles techniquement.

Un Data Integration Hub peut s’adapter à différentes sources et protocoles, comme :

protocoles natifs de bases de données relationnelles (oracle net, Ms sQl server, UdB…)

odBC

services Web

Ftp / sFtp

tCp/Ip

Http

e-mails

• Fichiers plats (de largeur fixe ou délimités)

• Fichiers XML

• Mainframe (fichiers VSAM, IMS, IDMS, Adabas, DB2, etc.)

• Fichiers non structurés ou semi-structurés (fichiers Microsoft Word, Microsoft Excel, HtMl ou pdF)

Formats industriels standards (edI, sWIFt, HIpaa, aCord, Hl7, etc.)

MoM (JMs, MQ, tIBCo…)

applications (siebel, sap, peoplesoft, salesforce.com…)

ldap

etc.

d. échange de données sécurisé

Les données peuvent être compressées, mais aussi cryptées ou masquées pour garantir la confidentialité. Les échanges peuvent aussi être sécurisés à l’aide de couches standards comme ssl.

e. Gestion de la granularité des unités de travail

Un data Integration Hub peut transférer des données de façon unitaire (une donnée / un enregistrement / un message à la fois) comme il peut le faire par blocs (en masse). les deux modes peuvent satisfaire la fréquence de transfert des données à la fois en temps réel et en batch. Ce choix dépend des exigences de la cible en termes de rafraîchissement des données : pour une application e-commerce, la latence sera beaucoup plus courte que pour un système décisionnel. L’accès direct aux systèmes source ou cible peut s’effectuer en mode connecté (directement à la base de données ou à la couche applicative), ou en mode non connecté (par l’intermédiaire de messages ou de fichiers).

f. Stockage et transmission

les données brutes et les données pivot peuvent être conservées dans une zone de stockage persistante dédiée, en amont de leur propagation aux systèmes cibles, en utilisant des demi- interfaces. Ceci présente de multiples avantages, comme le fait d’assurer un découplage des systèmes et garantir ainsi leur indépendance respective. et cela permet d’auditer ces données et, de les retraiter en cas d’erreur, sans surcharger le système source.

IntégratIon de données opératIonnelle

28

g. Application des règles de transformation entre les systèmes

Il peut exister autant de types de transformations à appliquer entre les sources qu’il existe de systèmes cibles différents. Les transformations comprennent le découpage des données, les concaténations, regroupements, jointures, contrôles, etc. …. le data Integration Hub peut traiter tout type de transformations de données par un design graphique, sans une seule ligne de code, quelle que soit la complexité du traitement.

h. Application de conversions de formats de données entre systèmes

Il ne s’agit pas uniquement de transformer des éléments des données brutes en passant d’un système à un autre ; il faut également convertir le format propre au système source vers un format pivot (souvent du XML) et ensuite dans le format adéquat pour la cible. Par exemple, des données sources issues d’un mainframe, au format VsaM contenant des enregistrements à occurrences multiples et des redéfinitions, peuvent facilement être converties en messages EDI, en un fichier au format personnalisé ou en XML. Elles peuvent aussi être chargées directement dans une base de données relationnelle ou converties en fichier Excel et envoyées par e-mail. les formats susceptibles d’être gérés avec le data Integration Hub sont illimités. et cette conversion intervient au rythme nécessaire aux besoins métiers.

i. Capacité à propager uniquement les données modifiées

pour des raisons de performance, de sollicitations des ressources matérielles (stockage, serveurs, …), et d’impacts sur les systèmes opérationnels, il importe de déplacer et de manipuler uniquement les données nécessaires. Ainsi, l’extraction complète des données sources est inutile dans la plupart des cas : seules les données ayant évolué depuis la dernière extraction devraient être considérées, c’est-à-dire les données créées, modifiées ou supprimées depuis la dernière exécution du processus d’extraction.

Ceci se produit surtout avec les sources de type base de données relationnelle et les applications comme Siebel, SAP, PeopleSoft, … qui n’utilisent pas forcément de messages ou de fichiers pour communiquer vers l’extérieur de l’application elle-même.

Un Data Integration Hub offre plusieurs solutions permettant d’identifier les données différentielles :

• Prise en charge native de la capture des données modifiées (Change data Capture). le data Integration Hub peut écouter directement les journaux de bases de données ou de fichiers (mainframe) et capturer les transactions dès qu’elles sont appliquées. Cette méthode non intrusive n’exige aucun développement et n’a pratiquement aucun impact sur la performance des systèmes sources par rapport aux autres méthodes d’accès.

utilisation d’un champ d’horodatage dans chaque table source : ce champ stocke la date / heure de la dernière mise à jour. le data Integration Hub récupère les données modifiées depuis la dernière extraction en utilisant cet horodatage.

utilisation de tables d’audit dans le système source. Certaines applications packagées utilisent des tables d’audit pour suivre toutes les transactions traitées. le data Integration Hub peut parcourir ces tables d’audit et extraire les données correspondantes aux transactions effectuées depuis la dernière extraction.

IntégratIon de données opératIonnelle

29

Comparaison d’attributs entre deux exécutions. Cette solution consiste à comparer tout ou partie des attributs entre l’exécution précédente et l’exécution en cours. Elle implique de stocker les données relatives à l’exécution précédente dans une zone persistante. Il est également possible de seulement stocker temporairement des sommes de contrôle calculées sur les attributs (avec les algorithmes CrC32 ou sHa1 par exemple) pour comparer ces dernières au lieu d’avoir à le faire sur l’ensemble des attributs, ce qui apporte des gains significatifs en termes de stockage et de performance. La comparaison peut être appliquée à l’ensemble de l’enregistrement ou se limiter à certains champs spécifiques.

Il est toutefois possible d’effectuer une extraction complète des données sources à un moment donné et d’effectuer une comparaison avec le système cible avant de charger les données ; mais dans ce cas, il convient de prêter une attention particulière au volume extrait et à l’impact correspondant sur la performance des systèmes source et cible.

6.1.2 Contrôles de qualité et certification des données

a. Contrôles de qualité basique sur les données

Un Data Integration Hub permet de contrôler que les données transmises sont correctes techniquement et fonctionnellement. Les contrôles sont effectués :

lors de l’extraction depuis la source : ces contrôles sont alors communs à toutes les cibles.

• Lors de l’émission vers les cibles : ces contrôles sont alors spécifiques à chaque cible.

l’objectif consiste alors à ne pas propager de données erronées ou incomplètes dans l’ensemble du système d’information. toute donnée suspecte est rejetée et éventuellement éligible pour le processus de recyclage automatique.

Un Data Integration Hub offre de nombreuses possibilités quant aux contrôles à appliquer :

Contrôles de format : date, numéro, téléphone, dUns, etc.

Contrôles d’intégrité : par exemple, vérification de l’existence, dans le référentiel produits de l’entreprise, d’un produit listé dans une commande.

Contrôles de références croisées : contrôle qu’un code spécifique récupéré, dans une table de références croisées (ou table de transcodification), existe réellement dans la cible.

Contrôles d’attributs obligatoires : par exemple, pour une facture, contrôle que l’adresse d’un client est complètement renseignée.

IntégratIon de données opératIonnelle

30

• Contrôles de cohérence entre différents attributs d’un même flux :

- Contrôle entre différents niveaux hiérarchiques : par exemple, il est possible de vérifier que la somme des montants des lignes d’une commande est effectivement égale au montant indiqué dans l’en-tête de la commande ; ou bien, vérification du statut global de la commande par rapport au statut de chacune de ses lignes de commandes.

- Contrôle au même niveau : par exemple, vérifier que la date de fin de commercialisation est bien renseignée pour un produit qui n’est plus commercialisé ; ou bien que si une facture représente un avoir, son montant est bien négatif.

Contrôle de cohérence inter-applications : par exemple, pour un flux de commandes entrant, vérifier qu’une commande existe bien dans le système cible ; ou bien vérification dans un référentiel Produit que le produit commandé était toujours commercialisable lors de la commande.

b. Contrôles de qualité avancés sur les données

Les contrôles de qualité avancés sur les données vont au-delà de simples contrôles sur des champs ou sur la cohérence d’une valeur de référence ; ils effectuent également des transformations pour renforcer la qualité et la cohérence des données afin d’offrir une meilleure vision des données traitées. Dans cette optique, les données peuvent devenir de véritables informations de valeur pour l’entreprise :

Standardisation : application de règles permettant de contrôler et de corriger le format et la sémantique d’une donnée. La standardisation garantit qu’une donnée respecte des conventions. Les contrôles de sémantique sont basés sur l’analyse et le découpage des champs ainsi que sur des vérifications effectuées dans un dictionnaire de référence contenant les valeurs valides ou des synonymes. la standardisation est généralement réalisée en quatre étapes :

- Analyse syntaxique : les données sont analysées et découpées en mots.

- Analyse lexicale : chaque mot est lu et rattaché à un type lexical correspondant à un certain champ lexical. Cette étape est spécifique aux règles de localisation.

- Analyse sémantique : les mots reconnus sont associés à l’attribut auquel ils correspondent dans un modèle de données. Cette étape est spécifique aux règles de localisation.

- Rectification : les mots clés sont standardisés par rapport à un dictionnaire de correspondances.

Normalisation : une fois les données standardisées et correspondant à une définition, la normalisation devient possible. Cette étape vérifie que la valeur d’une donnée correspond à la réalité, en étant validée par un organisme de certification externe : par exemple, vérification d’une adresse postale via un fichier Hexapost.

IntégratIon de données opératIonnelle

31

• Correspondance floue (« fuzzy matching ») : lorsqu’une correspondance directe est impossible, les données entrantes et de référence peuvent être comparées approximativement, sur la base d’algorithmes de distance linguistique.

Contrôle de doublons : par exemple, vérification qu’un client ou un prospect n’est pas référencé deux fois. les contrôles précédents sont souvent nécessaires, car il est rare qu’une correspondance directe soit applicable pour mettre en évidence de tels doublons.

Enrichissement : fournit des informations complémentaires pour l’enrichissement sémantique.

Il importe de noter que ce type de validations de qualité avancées peut être effectué en quelques secondes sans pénaliser les opérations.

c. Niveau de qualité de données autorisé

Une fois testées, les données sont marquées pour que le Data Integration Hub puisse décider de l’action à entreprendre. Le marquage peut aussi être utile dans le cadre du monitoring d’activité de l’entreprise (BAM). Trois niveaux de qualité de données sont généralement proposés :

Valide : Tous les contrôles effectués sont valides. Les données correspondantes sont propagées vers les cibles.

Rejetée : Au moins un test bloquant n’a pas été concluant. Les données concernées ne sont pas propagées aux cibles pour lesquelles ce contrôle revêt un caractère obligatoire. Un processus de recyclage de ces données peut être déclenché (ce point sera détaillé dans la section suivante).

Avertissement : Tous les contrôles bloquants ont été vérifiés mais au moins un contrôle de criticité mineure a été révélé. les données sont tout de même propagées aux cibles mais les utilisateurs sont avertis via les fonctions d’orchestration du data Integration Hub.

d. Regroupement des erreurs

Pour chacune des données, l’ensemble des contrôles de validité sont effectués afin d’obtenir une vision consolidée de l’exhaustivité des erreurs ou avertissements concernant un enregistrement particulier ou un ensemble d’enregistrements. l’objectif est de ne pas arrêter le traitement dès la première erreur, ce qui conduirait potentiellement à rejeter un enregistrement à de nombreuses reprises avant que toutes les erreurs possibles soient effectivement identifiées et corrigées l’une après l’autre.

Les données du pivot en erreur sont affichées à l’aide d’une interface utilisateur graphique native, indiquant toutes les erreurs associées. Un seul coup d’œil suffit pour prendre connaissance de toutes les erreurs et définir un plan d’action afin de les corriger (corrections à appliquer dans le système source, mise à jour d’une table de transcodification, …). Là encore, grâce à ses capacités d’orchestration, le data Integration Hub permet aux acteurs les plus appropriés, Moe ou Moa, de gérer le problème en fonction de sa nature.

IntégratIon de données opératIonnelle

32

e. Vérification de la livraison des données et de leur prise en compte par la cible

Le but consiste à vérifier, à chaque étape du flux de données, que toutes les données sources ont bien été propagées aux systèmes cibles et correctement intégrées à ces derniers. Un processus d’acquittement en plusieurs phases peut être nécessaire.

Le mécanisme d’acquittement peut suivre les étapes ci-dessous. Il peut être adapté à chaque système cible ou source en fonction de ses contraintes :

1 Une fois les données sources extraites et prises en compte dans le data Integration Hub (c’est-à-dire une fois la donnée pivot créée), elles sont marquées comme transmises avec succès au data Integration Hub.

2 Une fois la donnée pivot propagée vers une cible, l’instance pivot-cible est marquée comme transmise à la cible.

3 Une fois que les données transmises ont été traitées et intégrées par le système cible, la cible renvoie des informations indiquant si les données ont été correctement intégrées à ce système ; la cible peut également être interrogée pour obtenir cette information.

4 Enfin, une fois que tous les systèmes cibles concernés par ce processus d’intégration de données sont pris en compte, le Data Integration Hub peut notifier le système source que la transmission a été validée pour toutes les cibles.

Le Data Integration Hub conserve une trace des différentes étapes et des états associés, et peut également enregistrer les valeurs des données. Ce mécanisme permet de suivre efficacement la propagation des données étape par étape, que la communication soit synchrone ou asynchrone.

f. Vérification de la conversion des valeurs de transcodification

Il s’agit de configurer un mécanisme de transcodifications pour la traduction des données d’une application à une autre (tables de références croisées ou de transcodification). par exemple, pour la civilité « Madame », l’application a peut utiliser le code « Mme », une application cible B le code « 1 », et l’application C le code « Ms ». dans ce cas, le data Integration Hub utilise une table de références croisées qui est capable de déterminer quel code cible correspond à un code source spécifique, en fonction des applications source et cible.

6.1.3 Gestion des données en rejet

a. Recyclage automatique des données en rejet

Selon les contrôles effectués, la donnée peut être rejetée lors du sourcing (i.e. avant la création du pivot) ou lors de l’émission vers les cibles (i.e. après la création du pivot). le recyclage est possible dans ces deux cas :

si cela se produit avant le pivot, la donnée doit être ré-extraite depuis la source ou depuis la zone de staging : le recyclage concerne toutes les cibles car aucune d’elle n’aura reçu la donnée.

IntégratIon de données opératIonnelle

33

si cela se produit après le pivot, le recyclage est réalisé cible par cible : le recyclage concerne uniquement les cibles pour lesquelles le pivot a été rejeté. Le Data Integration Hub lit alors à nouveau le pivot, contrôle à nouveau les données et tente de charger la cible. les rejets à ce niveau doivent essentiellement être causés par des problèmes de transcodification ou d’intégrité par rapport à des référentiels : le pivot est considéré comme valide. la seule intervention à faire consiste à mettre à jour les tables de transcodification ou les référentiels. Le Data Integration Hub permet d’en alerter automatiquement un utilisateur et met à disposition une interface graphique pour effectuer la modification nécessaire.

b. Éviter de recycler indéfiniment des rejets

Il est possible de définir un nombre maximum de tentatives pour le recyclage d’une donnée : si, pour une donnée, le nombre de recyclages excède cette limite, la donnée est marquée comme abandonnée. Cet aspect est important pour éviter de recycler indéfiniment une donnée corrompue qui ne pourra jamais être intégrée. Les utilisateurs peuvent être avertis du rejet et peuvent alors diagnostiquer le problème ou même modifier les données, voire abandonner la donnée qui ne sera ainsi plus recyclée.

6.1.4 Fréquence des flux et orchestration

Le Data Integration Hub comporte une brique ordonnancement.

a. Traitement au fil de l’eau / « temps réel »

Les flux peuvent traiter les données sources au fil de l’eau, en suivant le cycle de vie de la donnée dans son application (capture des transactions) ou si l’application pousse directement la donnée (message dans une file, arrivée d’un fichier, arrivée de courrier électronique, etc.) : dès qu’une donnée est disponible, elle est prise en compte par le Data Integration Hub. Les données sont traitées soit unitairement (faible volumétrie à chaque exécution et ne concernant souvent qu’une transaction) ou massivement (un jeu de données allant de plusieurs milliers à plusieurs millions de transactions).

b. Traitement par lot

Les flux peuvent être exécutés selon des fréquences prédéfinies, par exemple :

Une fois par jour

Une fois par semaine

toutes les 1/4 heures entre 8h et 20h.

Les données sont ensuite traitées par blocs : le volume concerné peut être faible (quelques enregistrements) ou très importante (des millions d’enregistrements). Le mode batch est fréquemment utilisé lorsque les applications ne sont pas en mesure de publier leurs transactions en temps réel, lorsque le processus de synchronisation ne nécessite pas d’être immédiat pour l’activité métier concernée ou lorsque les applications ciblées nécessitent des calculs ou des agrégations mettant en jeu d’importants jeux de données, avant de pouvoir être chargées.

De plus, ces calculs doivent souvent accéder aux données de plusieurs sources pour appliquer les règles requises. Le mode batch est également utilisé pour initialiser une cible en première exécution, lorsque les applications n’ont jamais été synchronisées auparavant.

IntégratIon de données opératIonnelle

34

c. Adaptation de la fréquence en fonction des besoins de chaque cible

Pour un flux donné, la latence exigée peut être différente d’une cible à l’autre. Le Data Integration Hub permet de définir des fréquences d’alimentation propres à chaque cible. Il peut lire la source une seule fois et propager les données vers plusieurs cibles à différentes fréquences en fonction des contraintes de chaque cible. Cela permet également de gérer le cas où les données en zone tampon doivent être complétées par d’autres processus avant de pouvoir les transmettre.

Le système source est ici le facteur limitant : la latence minimale d’un flux correspond à la fréquence maximale possible sur cette source. Plus particulièrement, lorsqu’un système source ne peut fournir les données en temps voulu, il est impossible d’alimenter les cibles en temps voulu.

6.1.5 Paramétrage / configuration

Le Data Integration Hub offre une interface graphique d’administration pour faciliter la configuration et les réglages spécifiques.

a. Pilotage de l’alimentation des cibles

au sein du data Integration Hub, il est possible de désactiver ou réactiver une cible pour un flux. En effet, pour certaines raisons liées au cycle de vie d’une application (phases de maintenance…), il est envisageable qu’une application cible soit momentanément indisponible.

Cette fonction permet de désactiver temporairement l’application concernée, tout en conservant dans un statut en attente les données éligibles pour cette cible : une fois la cible réactivée, les données en attente sont traitées dans leur ordre de création dans le data Integration Hub et envoyées à la cible. toute perte de données est ainsi évitée.

la désactivation ou l’activation d’une cible peut se faire par anticipation en paramétrant la date de début du nouvel état.

b. Paramétrage de la durée de rétention

pour des raisons de performance, et pour éviter toute consommation inutile de stockage, il peut s’avérer utile de supprimer régulièrement les données pivot. De la même manière, les statistiques et les journaux de chaque flux peuvent être conservés pendant un certain temps.

Ces processus de nettoyage peuvent être lancés à intervalles réguliers (chaque mois par exemple) pour supprimer les données pivot, les statistiques et les logs créés sur une période donnée. La fréquence de la purge peut être paramétrée individuellement pour chaque flux. La durée de rétention des statistiques et des données de log peut être supérieure ou égale à celle des données pivot.

c. Gestion des références croisées

Cette fonction consiste à effectuer une mise à jour des tables de référence par l’intermédiaire d’une interface graphique, fournie par le Data Integration Hub.

IntégratIon de données opératIonnelle

35

d. Réglages généraux

L’utilisation d’un framework (maintenu via une IHM) permet de maintenir les paramètres de flux comme :

les paramètres de connexion pour les bases de données

• Les chemins d’accès et noms des fichiers sources et cibles

• Les chemins d’accès et nom des fichiers logs

les paramètres Ftp

les destinataires des mails d’alerte

les valeurs par défaut de certains attributs.

Ce framework permet également de générer automatiquement et de manière centralisée tous paramètres utiles aux flux du Data Integration Hub.

e. Abandon des données corrompues

Le Data Integration Hub permet de modifier le statut de données préalablement rejetées afin qu’elles ne soient pas recyclées. L’état d’une instance {donnée - cible} est passé au statut ‘Abandonné’. Ce réglage peut être appliqué à une cible spécifique ou à toutes les cibles concernées par une donnée abandonnée.

Cette fonction sert à éviter que les rejets ne soient perpétuellement recyclés s’il est avéré qu’ils ne peuvent pas être intégrés à une cible donnée.

f. Rejeu des données

le data Integration Hub permet de renvoyer des données déjà transmises. l’état d’une instance {donnée - cible} est passé au statut ‘A réémettre’.

Cette fonction est intéressante lorsque des données ont été supprimées par erreur dans une cible ou lorsque des erreurs dans l’application cible ont corrompu les données, exigeant qu’elles soient de nouveau récupérées.

g. Réextraction depuis la source

Il est possible de rejouer l’extraction de tout ou partie des données sources :

• Pour les extractions utilisant un intervalle de date, celui-ci peut être modifié dans une table de paramètres.

pour les extractions utilisant la comparaison d’attributs, les enregistrements doivent être supprimés dans la table de pilotage maître.

pour les extractions utilisant la technologie de Change data Capture (CdC), il est possible de les repositionner dans le log du CdC.

• Les messages quant à eux doivent être renvoyés de la zone tampon vers la file de messages, afin d’être à nouveau disponibles en entrée du flux.

IntégratIon de données opératIonnelle

36

6.1.6 Traçabilité et audit

a. Connaissance de l’origine et de la destination des données

Cette fonction repose sur les métadonnées du Data Integration Hub ainsi que sur les métadonnées des différentes sources. Il est toutefois possible de suivre les données en utilisant la zone tampon qui maintient les données au format canonique et éventuellement au format brut s’il a été mis en place.

b. Livraison finale et acquittement de la cible

Consultez la section 6.1.2. Contrôles de qualité et certification des données.

c. Trace des tentatives

le data Integration Hub conserve une trace de toutes les tentatives :

d’extraction d’un système source.

de livraison à un système cible.

de recyclage.

À partir de ces traces, des indicateurs peuvent être calculés pour améliorer la connaissance des mouvements de données entre applications.

d. Surveillance des transformations des données

Pour un flux de données spécifique, il peut s’avérer intéressant de connaître :

• Combien d’objets ont été transférés sur différentes périodes ?

Combien de rejets ont été générés ?

• Quelles sont les erreurs les plus fréquentes ?

• Quelle est la durée moyenne d’un flux de données en fonction du volume source ?

Combien de fois une donnée a été mise à jour pendant une période donnée (par exemple, combien de fois le système de référence produit a envoyé des mises à jour pour un produit donné) ?

Ces indicateurs peuvent être basés sur les métadonnées du data Integration Hub ou sur des traces spécifiques élaborées à chaque exécution. Ces indicateurs offrent une visibilité sur la qualité des transferts et sur la performance des flux. Il est possible de calculer des métriques de Qualité de Service, qui peuvent être exigées par un système cible. Ces indicateurs peuvent aussi servir à l’élaboration de précieux éléments en vue d’établir un Capacity planning, c’est-à-dire une analyse prévisionnelle de la croissance des volumes de données.

IntégratIon de données opératIonnelle

37

e. Récupération sur erreurs techniques

Nous avons déjà présenté les contrôles de validation comme un moyen pour évaluer la qualité des données entrantes. Ici, il s’agit de tracer les éventuels plantages qui peuvent subvenir dans le cycle de vie d’un flux : manque de capacité de stockage sur le disque, connexion indisponible vers un système source ou cible, problème réseau, etc. Ces types d’erreur peuvent être repérés par le Data Integration Hub et conservés dans une table d’erreurs techniques, afin d’élaborer des indicateurs sur la nature et la fréquence de ces erreurs.

f. Zone de stockage des données brutes

pour les besoins de suivi, de recyclage et de diagnostic, il peut s’avérer très utile de conserver les données brutes (sans aucune transformation) pendant un certain temps. toutefois, ce stockage temporaire peut entraîner des coûts de stockage supplémentaires ou rallonger la durée des traitements, en particulier lorsque les cibles subissent des sollicitations poussées en mise à jour de données. la mise en œuvre de ce stockage intermédiaire doit donc être soigneusement étudiée en fonction de la capacité de la source à renvoyer les données en cas de problème.

6.1.7 Surveillance - rapports

le data Integration Hub fournit une IHM pour les rapports.

a. Restitution des statistiques Les différents indicateurs peuvent être regroupés en tableaux de bord permettant le contrôle de qualité dans les flux de données, en rapportant et en signalant les événements importants. Ces rapports peuvent également servir d’outils de communication pour prouver la conformité aux exigences de Qualité de service.

b. Alertes à destination de l’administrateur

En cas d’échec sur l’exécution d’un flux, le Data Integration Hub peut envoyer à une liste d’interlocuteurs une alerte par e-mail indiquant l’erreur et le fichier log correspondant.

D’autres mails d’alerte peuvent aussi être envoyés à une autre liste de diffusion (utilisateurs par exemple) pour indiquer que certaines données ne sont pas disponibles dans telle ou telle cible. Les deux listes de diffusion sont indépendantes l’une de l’autre, sont paramétrables et définies pour chaque flux, voire pour chaque cible au sein d’un même flux.

c. Alerte sur événement

Le Data Integration Hub permet de définir une alerte par e-mail déclenchée et envoyée en fonction de différents critères, par exemple le nombre de rejets pour une cible donnée.

IntégratIon de données opératIonnelle

38

d. Fourniture d’un récapitulatif quotidien

La brique de reporting du Data Integration Hub peut diffuser quotidiennement (fréquence à personnaliser) des rapports de synthèse sur la surveillance des flux. Les rapports peuvent inclure les éléments suivants :

• Le flux a-t-il été exécuté ?

nombre d’exécutions

état des exécutions

Volume traité

durée de traitement

nombre de rejets

etc.

les rapports sont disponibles via une application web ou envoyés par e-mail.

6.1.8

Fiabilité

a. Évaluation de la fiabilité du Data Integration Hub sur la base de statistiques

Les indicateurs et les rapports disponibles permettent d’évaluer aisément, flux par flux, la fiabilité du Data Integration Hub.

b. Garantie d’absence de perte des données

Le mécanisme d’acquittement au niveau de la source et/ou dans le Data Integration Hub permet de vérifier la bonne transmission à une cible et la bonne prise en compte de la donnée. Les données non transférées sont aisément identifiables.

c. Garantie d’absence de duplication des données

les données susceptibles de constituer des doublons (par exemple, des interlocuteurs) peuvent être captées par des outils de Qualité de données ou de résolution d’Identité. Lorsque des doublons sont détectés, deux options sont possibles :

rejeter les deux occurrences pour une analyse plus approfondie et leur correction dans le système source.

envoyer une demande d’arbitrage à un utilisateur par l’intermédiaire de la couche d’orchestration du data Integration Hub.

d. Permettre le rejeu d’un flux après une erreur

Dans le Data Integration Hub, des points de reprise peuvent être définis sur les flux. Suite à un plantage, les traitements peuvent être relancés à partir du dernier point de reprise validé. ainsi, il est inutile de relancer l’intégralité du flux de données.

IntégratIon de données opératIonnelle

39

e. Gestion du bon ordre des messages

Le Data Intégration Hub garantit que les messages sont traités dans l’ordre chronologique correct. Par exemple, pour une commande donnée, il peut arriver que le premier message (création de la commande) soit envoyé à 15h30 et qu’un deuxième message (mise à jour) soit envoyé à

15h35.

Si l’exécution du flux de données est paramétrée pour un lancement tous les quarts d’heure, la file de messages contient deux messages pour la prochaine exécution. Le message envoyé à 15h30 est bien traité par le data Integration Hub avant le message envoyé à 15h35. ainsi, le système cible aura bien la version la plus récente de la commande.

f. Garantie d’une performance optimale Le Data Integration Hub offre des possibilités de partitionnement et de parallélisme ainsi que de grid Computing pour permettre une évolution linéaire de la scalabilité en cas d’augmentation du volume de données.

g. Garantie de haute disponibilité et d’une capacité de reprise d’activité élevée suivant les besoins en termes de disponibilité, l’architecture du data Integration Hub peut être répartie sur plusieurs nœuds : un nœud principal et un ou plusieurs nœuds de sauvegarde peuvent être utilisés au sein du grid pour de meilleures performances ainsi que pour prendre en charge la bascule et la reprise à chaud en cas d’arrêt brutal du nœud principal.

6.2 ARCHITECTuRE Du DATA INTEGRATION HuB

Sources internes

IHM Gestion Référentiel Paramétres des flux Supervision Etc Hub Transformation Orchestration et processus
IHM
Gestion Référentiel
Paramétres des flux
Supervision
Etc
Hub
Transformation
Orchestration et processus manuels
Tables
Référentiel
tampons
Données du Hub
Données
Paramètres
Statistiques
ETL / EAI
Base de données du Hub
--------
------
----
Alimentation
Temps Réel
Lot
unitaire

Importation------ ---- Alimentation Temps Réel Lot unitaire Exportation JMS / MQ JMS / MQ Native /

Exportation---- Alimentation Temps Réel Lot unitaire Importation JMS / MQ JMS / MQ Native / ODBC

Temps Réel Lot unitaire Importation Exportation JMS / MQ JMS / MQ Native / ODBC Native

JMS / MQ

JMS / MQ

Lot unitaire Importation Exportation JMS / MQ JMS / MQ Native / ODBC Native / ODBC

Native / ODBC

Native / ODBC

Exportation JMS / MQ JMS / MQ Native / ODBC Native / ODBC Service Web Acquittement

Service Web

AcquittementJMS / MQ JMS / MQ Native / ODBC Native / ODBC Service Web Service Web

Service Web

/ ODBC Native / ODBC Service Web Acquittement Service Web Acquittement Mail IntégratIon de données opératIonnelle

Acquittement

Mail

IntégratIon de données opératIonnelle

Figure 10: architecture du data Integration Hub

40

le cœur du data Integration Hub est basé sur Informatica power Center real-time edition pour la partie intégration de données, ainsi qu’une base de données relationnelle associée qui constitue le Hub en tant que tel.

6.2.1 La dynamique d’intégration de données

Informatica power Center real-time edition est un moteur de transformation de données guidé par les métadonnées qui met à disposition :

• La création graphique de flux de transformation de données

Un référentiel de métadonnées permettant de stocker tous les développements autour des données et de leur transformation

le traitement des données en temps réel et en masse

• Des capacités de transformation de données, des plus basiques aux plus complexes

• La connectivité avec les fichiers plats, XML et des bases de données relationnelles

la capture de transactions à partir des journaux rdBMs

• La possibilité de consommer et de propager des éléments de files de messages

la fourniture et la consommation de services Web

Une console d’administration Web

• Une interface Web de gestion des tables de référence ou transcodification

l’orchestration des services Web avec BpMl

Un ordonnanceur intégré

le partitionnement et le parallélisme des traitements pour assurer la scalabilité en termes de performance

le traitement à tolérance aux pannes.

6.2.2 Les zones de stockage du Hub

la base de données relationnelle utilisée comme Hub permet de stocker les éléments suivants :

données pivot

Journalisation des tentatives

Journalisation des erreurs

données brutes en entrée

tables de références croisées.

IntégratIon de données opératIonnelle

41

Données de Staging référence Noyau du Hub Statistiques Paramètres Figure 11: stockage au sein du
Données de
Staging
référence
Noyau
du Hub
Statistiques
Paramètres
Figure 11: stockage au sein du data Integration Hub

Le Hub est divisé en quatre domaines logiques, offrant des zones de stockage pour les données persistantes et la gestion du paramétrage et de la configuration du Data Integration Hub :

Zone de staging : ce domaine stocke les données sources non transformées (telles quelles). Il se compose d’une zone permettant de recycler les données en cas de problème pendant la création des données pivot (sans nécessiter une ré-extraction depuis le système source) ou pour identifier les modifications apportées au système source (par comparaison des attributs). Cette zone peut être facultative, en fonction de la stratégie de recyclage ou de la latence souhaitée. Mais, si les données brutes ne sont pas stockées, la source doit pouvoir délivrer à nouveau les mêmes données en cas de reprise afin de les retraiter.

Zone noyau du Hub : ce domaine représente le cœur du système du Data Integration Hub ; quatre tables principales gèrent l’ensemble du Data Integration Hub :

- Table des données pivot (avec un type de champ CLOB ou XML) : stocke les attributs fonctionnels clés des données pivot, permettant d’en tirer des statistiques ; par exemple, pour un flux traitant les commandes : le type de commande, le numéro de référence, les données de commande et le montant global de la commande peuvent être définis en tant qu’attributs clés pour générer des rapports sur ces éléments.

- Table de données binaires (utilisant un champ de type BloB) : par exemple, si l’image scannée d’une facture doit être transmise d’une application vers une autre (par ex. une application de gestion de Contenu d’entreprise ).

IntégratIon de données opératIonnelle

42

- Table d’erreurs : conserve une trace des erreurs fonctionnelles et techniques pendant la création des données pivot (contrôles globaux) ou pendant la diffusion vers les cibles (contrôles spécifiques à chaque cible).

- Table des données pivot sortantes et de recyclage : par exemple, lorsqu’une donnée pivot doit être propagée vers les cibles a, B et C, cette table contient 3 enregistrements pointant vers la donnée pivot : un par cible. Ils représentent une ‘instance de donnée pivot’. Un chargement indépendant entre les 3 cibles est ainsi assuré. En effet, la donnée pivot peut être correctement chargée dans les cibles A et C, mais rejetée par la cible B (en cas de référence croisée manquante, par exemple). dans ce cas, seule l’instance correspondant à la cible B est recyclée. le pivot n’est pas dupliqué ; il s’agit de pointeurs qui référencent une seule instance physique de la donnée pivot pour limiter le stockage.

Zone des données de référence : ce domaine inclut :

- les tables de référence pour les contrôles de validité sur des valeurs de référence ou des codifications.

- Des tables de références croisées (ou tables de transcodifications) destinées à gérer plusieurs traductions de codes en fonction des applications.

Zone de paramétrage : ce domaine est dédié aux paramètres du data Integration Hub et inclut en particulier :

- Un framework de paramétrage des flux (en particulier pour les paramètres de connexions sources et cibles).

- l’administration du chargement de la cible (activation ou désactivation d’une cible).

- Réglage de la durée de rétention des données pour chaque flux.

- Nombre maximal de nouvelles tentatives pour une donnée rejetée pour chaque flux.

- Paramétrage des dates d’extraction des sources, permettant d’identifier les données en différentiel depuis la dernière mise à jour ou une table d’audit.

Zone de statistiques : ce domaine contient des tables de suivi de toutes les tentatives d’exécution (extractions, chargement, recyclage…) à des fins statistiques.

IntégratIon de données opératIonnelle

43

6.2.3 Autres modules importants du Data Integration Hub

Certaines autres fonctionnalités du data Integration Hub sont prises en charge par les outils suivants :

reference table Manager (rtM) RTM est une interface utilisateur graphique, prête à l’emploi, offrant un accès en lecture et écriture à des tables d’une base de données. Il permet de maintenir facilement les tables des domaines Zone de paramétrage et Zone des données de référence.

Cet outil permet de s’affranchir de développer (en java par exemple) une IHM spécifique pour maintenir ces tables.

Cet outil permet également d’importer et exporter les tables via des fichiers plats.

Cet outil permet encore de visualiser et de faire un suivi des modifications (module audit trail).

de faire un suivi des modifications (module audit trail ). Figure 12 : IHM de mise

Figure 12 : IHM de mise à jour des tables de référence

Informatica PowerExchange :

Cette option permet d’étendre le panel de connectivité de powerCenter, mais aussi d’en faciliter l’utilisation.

Il s’agit d’une interface utilisateur unifiée destinée à simplifier la complexité sous-jacente de n’importe quelle source, qu’il s’agisse d’un fichier, d’un RDBMS, d’une application ou de données mainframe. Elle offre une vue tabulaire des données de toute nature. Elle prend également en charge les systèmes de file de messages (WebSphere MQ, JMS,

tibco

Elle intègre en sus une option de Change Data Capture (permettant d’identifier automatiquement les données modifiées dans les sources) et des accès en mode « bulk » (pour les volumes de données importants). powerexchange permet également d’assurer des transferts inter-applications sécurisés (possibilité de configurer des communications SSL ou de crypter les données transférées.)

),

la connectivité avec des services Web, la connectivité Http, Https, Ftp, Ftps, etc.

IntégratIon de données opératIonnelle

44

Data quality :

L’objectif de ce module consiste à évaluer et à améliorer la qualité des données gérées par le data Integration Hub. Il permet :

- de mesurer la qualité des données (par l’intermédiaire de tableaux de bord et de rapports) selon les critères suivants :

Complétude : identification des données incomplètes ou inutilisables.

Conformité : identification des données malformées (de format incorrect).

Cohérence : identification des données contenant des informations conflictuelles.

Exactitude : identification des données inexactes ou périmées.

Doublons : identification des doublons.

Intégrité : identification des données manquantes ou non référencées.

Il est possible de créer n’importe quel autre critère personnalisé.

- de nettoyer, standardiser, améliorer, associer, dé-doublonner et consolider les données.

- de normaliser et valider les adresses : utilisation d’un outil certifié par des fournisseurs de validation d’adresses, livré en version oeM avec Informatica data Quality.

- Contrôle de l’atteinte d’un seuil d’acceptation de la qualité des données.

- Réutilisation et industrialisation des règles de qualité des données.

le module data Quality s’intègre parfaitement à power Center. Cet outil peut donc s’avérer très utile pour mettre en place des contrôles complexes sur les données.

IntégratIon de données opératIonnelle

45

Data Integration b Data Flows (PowerCenter Mappings) a d e B2B Data Transformation Data Quality
Data Integration
b
Data Flows
(PowerCenter Mappings)
a
d
e
B2B
Data Transformation
Data Quality
Data Quality Assistant
X -> Y
? -> Z
Orchestration
2
5
Control Flows
1
4
(BPEL)
3
6
Human Decision
Figure 13: principe de l’orchestration (1/2)
Control Flow (Orchestration) Results Invoke Invoke Invoke Data Flow (PowerCenter Mapping) SQ products (Micros oft
Control Flow
(Orchestration)
Results
Invoke
Invoke
Invoke
Data Flow (PowerCenter Mapping)
SQ
products (Micros
oft SQL Server)
SQ_products
DQ_P_Standardi
f(x)
zelProducts
mpit_MatchPro
Dgi_generateD
duct
QAFields
product_master(
Oracle)

Figure 14: principe de l’orchestration (2/2)

IntégratIon de données opératIonnelle

46

Orchestration :

Ce composant basé sur un standard BPML et offrant une interface BPM autorise tous les ordonnancements de tâches de services Web, d’alertes par e-mail et des interventions humaines dans un flux (par exemple, si un utilisateur doit vérifier ou corriger les valeurs avant le chargement de la cible, ou prendre une décision en cas détection de doublon potentiel).

Data Analyzer :

Il s’agit de l’IHM de reporting du data Integration Hub. Il fournit des rapports prédéfinis basés sur les métadonnées PowerCenter, notamment des rapports sur les traitements, leurs durées, les volumes traités etc.

Il fournit des tableaux de bord pour obtenir une vue globale des indicateurs clés concernant le fonctionnement ou le design des flux du Data Integration Hub, ainsi que certains rapports détaillés (par ex. détails historiques de la durée de traitement et du nombre de lignes traitées pour un flux donné).

data analyzer permet également la gestion des alertes par e-mail, en envoyant un message en cas :

d’échec d’un traitement,

d’atteinte ou dépassement d’un seuil d’anomalie,

• d’absence d’exécution d’un traitement à une date spécifique,

etc.

Data Analyzer peut diffuser les tableaux de bord et les rapports régulièrement ou dès qu’un événement important se produit dans le traitement des données.

Metadata Manager :

Metadata Manager permet un suivi en amont et en aval du Hub, afin de connaître l’origine des données, leur destination et toutes les règles de transformation qui leur ont été appliquées.

Cet outil intègre tous les composants d’un projet d’intégration de données, et donc en particulier du data Integration Hub, à savoir :

Modélisation des données

rapports

transformations

stockage

glossaire métier.

Il sera utile pour réaliser un audit des données basé sur les métadonnées et pour simplifier les études d’analyse d’impact dans le cas d’évolutions des besoins métiers.

IntégratIon de données opératIonnelle

47

6.3 CONCEPTION Du DATA INTEGRATION HuB

Dans le data integration hub, un flux complet depuis la source jusqu’aux cibles est divisé en demi- flux.

• Demi-flux entrant : du système source au format pivot (stocké dans la zone du Hub).

• Demi-flux sortant : du format pivot à une cible (une demi-interface par instance cible).

Source
Source

D e m i - fl u x e n t r a n t Demi-ux entrant

Cible 1 Demi-flux sortant N Cible 2 Demi-flux sortant 2 Data Integration Hub Cible N
Cible 1
Demi-flux sortant N
Cible 2
Demi-flux sortant 2
Data Integration Hub
Cible N
Demi-flux sortant 1

Figure 15: Un flux DIH = 1 demi-flux entrant et N demi-flux sortants

Hub Phase 0 Recyclage Détection d’erreur Phase 1 Cible 1 Source(s) Extraction des données Contrôles
Hub
Phase 0
Recyclage
Détection
d’erreur Phase 1
Cible 1
Source(s)
Extraction des
données
Contrôles d’intégrité
Autres contrôles
Cible 2
Phase 1
Staging
Création de pivot
XML
Pivot XML
Contrôles
Transcriptions
Transformations
Phase 2
Détection
d’erreur Phase 2
Diffusion des
données vers les
cibles
Cible N
Transcriptions
Transformations

Figure 16: Vue globale de toutes les phases d’un flux complet, de la source aux cibles

IntégratIon de données opératIonnelle

48

6.3.1 Demi-flux entrant :

De nombreux scénarios sont possibles en termes de choix d’implémentation pour le demi-flux entrant, en fonction de la nature des données (de référence ou de transaction), de leur volume et de la volatilité des données sources (messages transactionnels ou données batch). Un demi-flux entrant peut contenir les fonctionnalités ou étapes suivantes, qui peuvent s’avérer obligatoires ou non :

   

Facultative /

étape n°

description

obligatoire

1

extraction des données sources (extraction ou directement fournies par la source)

obligatoire

2

stockage dans une zone persistante (zone de staging)

Facultative

3

Création du pivot

obligatoire

4

recyclage des données rejetées (données pour lesquelles la création de pivot est impossible en raison de contrôles non vérifiés).

Facultative

5

Acquittement vers le système source

Facultative

Étape 1 Détection Étape 4 d’erreur Extraction de données Recyclage Source Phase 1 Contrôles d’intégrité
Étape 1
Détection
Étape 4
d’erreur
Extraction de données
Recyclage
Source
Phase 1
Contrôles d’intégrité
Autres contrôles
Étape 3
Étape 2
Stockage en xone
persistante
Staging
Creation du
Pivot XML
Area
pivot XML
Transcriptions
Transformations

Figure 17: Vue détaillée d’un demi-flux entrant type

6.3.1.1 Etape 1 : Extraction

trois cas peuvent être envisagés pour l’extraction des données sources :

Cas 1 : Mises à jour de données envoyées par le système source.

Cas 2 : Mises à jour de données détectées par le data Integration Hub.

Cas 3 : pas de détection de mises à jour de données (mode « full »).

IntégratIon de données opératIonnelle

49

Cas

 

option possible

 

1.1

La source envoie des messages (MQ ou JMS par exemple) à chaque fois qu’un objet est créé, modifié ou validé dans la source.

Cas 1 envoi des données mises à jour

1.2

La source envoie ou fournit un fichier dans un répertoire en entrée du data Integration Hub.

 

la source alimente des tables d’interface (la plupart du temps stockées dans l’application source même) ne contenant que les créations, modifications ou suppressions depuis la dernière exécution.

 

1.3

la purge de ces tables d’interface est gérée par le système source, en fonction de l’acquittement envoyé par le Data Integration Hub une fois toutes les données traitées. les enregistrements ne sont ainsi supprimés que si le Data Integration Hub les a pris en compte correctement.

   

les données source peuvent être extraites avec le mécanisme de

2.1

Change data Capture (CdC) fourni par le data Integration Hub. les transactions de la base de données sont journalisées et le mécanisme CdC capture les transactions dans le journal pour les traiter.

Cas 2

2.2

Chaque table source contient un champ avec l’horodatage des dernières modifications de l’enregistrement. Les données différentielles sont ensuite identifiées par le Data Integration Hub, en comparant cet horodatage avec la dernière date d’extraction stockée dans le data Integration Hub. tous les enregistrements créés ou modifiés après la dernière mise à jour sont éligibles.

extraction des données mises à jour

 

La source contient des tables d’audit qui conservent une trace de tous les événements se produisant sur les données : chaque création, mise à jour ou suppression est suivie de bout en bout dans ces tables d’audit, avec l’horodatage de l’événement.

2.3

Les données différentielles sont ensuite identifiées par le Data Integration Hub, en comparant cet horodatage avec la dernière date d’extraction stockée dans le data Integration Hub : tous les enregistrements créés ou modifiés après cette date sont éligibles (via un rapprochement entre la table d’audit et la table source).

 

la source ne présente aucun des cas précédents, en d’autres termes :

la source est incapable de fournir les données mises à jour.

l’option de Change data Capture n’est pas utilisable avec cette source.

• La source ne possède pas de champ d’horodatage indiquant

2.4

la date de la dernière mise à jour de l’enregistrement, ni de table d’audit.

Même dans ce cas, le data Integration Hub peut détecter les modifications entre deux exécutions. Cette méthode implique d’utiliser une zone persistante (zone de Staging) qui stocke les valeurs des attributs de l’exécution précédente.

IntégratIon de données opératIonnelle

50

Cas

 

option possible

   

principe : Cette solution consiste à identifier les données sources ayant évolué depuis la dernière extraction : pour les données considérées, cette identification est réalisée en comparant les valeurs des attributs entre l’extraction précédente (stockée dans la zone de staging) et l’extraction en cours (stockée dans la source).

Quatre cas sont généralement testés :

les données existent dans la source, mais pas dans la zone de staging : il s’agit alors d’une création.

les données existent dans la zone de staging, mais pas dans la source : il s’agit alors d’une suppression.

les données existent dans la source et dans la zone de Staging et au moins l’un des attributs est différent ; cela signifie que les données ont été modifiées depuis la dernière exécution.

les données existent dans la source et dans la zone de Staging et tous les attributs demeurent inchangés ; cela signifie que les données n’ont pas été modifiées depuis la dernière exécution.

seuls les trois premiers cas sont éligibles pour le déclenchement de l’extraction des données source.

pour optimiser la comparaison des attributs, la solution consiste à calculer une somme de contrôle sur ces attributs (par exemple à l’aide des algorithmes CRC32 ou SHA1) puis à comparer uniquement la valeur de la somme de contrôle des attributs source avec celle stockée dans la zone de staging. Il est inutile de comparer tous les attributs d’une donnée, ceux qui sont significatifs pour les applications cibles suffisent.

la mise en œuvre de cette solution doit être réalisée sur des sources de taille limitée car elle peut s’avérer consommatrice en espace disque et en temps de traitement.

   

Les données sources sont intégralement transférées sans différencier les enregistrements modifiés et inchangés.

Ce cas doit être utilisé avec précaution :

Volume très limité.

Cas 3 pas de détection de mise à jour des données

Implémentation d’un mécanisme de recyclage impossible.

3.1

pas de zone persistante.

• La conservation du pivot est limitée à quelques jours, par rapport à une durée de l’ordre de quelques mois pour les autres types de flux.

 

les données sont chargées en mode truncate / Insert dans chaque cible concernée.

Chargement initial ou sauvegarde complète.

IntégratIon de données opératIonnelle

51

pour des raisons de performance et pour maîtriser la volumétrie globale des données du data Integration Hub, les modes différentiels sont à privilégier (cas 1 et 2).

La description de flux suivante constitue un exemple représentatif d’extraction de message MQ à stocker dans la zone de staging :

Sous-étape 1.1 : extraction du contenu de la file d’attente et enregistrement du message sans transformation.

Cette sauvegarde sert à recycler le message sans avoir à réaliser de nouvelle extraction depuis la source.

Remarque : Un système de file d’attente comporte également un mécanisme de persistance, que nous pourrions être tentés d’utiliser dans ce but. Mais il est préférable de l’éviter. le mécanisme de persistance de la file de messages est principalement utilisé pour garantir la possibilité de récupération lors d’un transfert d’un message sur le réseau, ou dans l’attente de sa consommation par tous ses abonnés. la persistance ne dure pas longtemps. si un trop grand nombre de messages étaient présents dans la file d’attente, cette dernière pourrait littéralement « exploser ». Dès qu’un message de la file d’attente est entièrement consommé, il en est supprimé afin de ne pas le prendre de nouveau en compte lors de l’exécution suivante.

Lecture de la file MQ MQ SQ
Lecture de la
file MQ
MQ
SQ

Stockage du message sans transformationLecture de la file MQ MQ SQ MQ_REF_PRO SQ_MQ_REF_P DIH_STA_MES DUCT (MQSerie RODUCT SAGE_BRUT (O

MQ_REF_PRO

SQ_MQ_REF_P

DIH_STA_MES

DUCT (MQSerie

RODUCT

SAGE_BRUT (O

s)

RACLE)

Figure 18 : Mapping de sauvegarde d’un message depuis une file MQ Series

Sous-étape 1.2 : extraction de la file d’attente et stockage dans la zone de staging :

MQ SQ
MQ
SQ

MQ_REF_PRODUC

T (MQSeries)

MQ SQ MQ_REF_PRODUC T (MQSeries) Découpage du message SQ f(x) SQ_MQ_REF_PRO DUCT MQ_Message_Re ad (Flat File)
Découpage du message SQ f(x)
Découpage du
message
SQ
f(x)
MQ_REF_PRODUC T (MQSeries) Découpage du message SQ f(x) SQ_MQ_REF_PRO DUCT MQ_Message_Re ad (Flat File) Lecture du
MQ_REF_PRODUC T (MQSeries) Découpage du message SQ f(x) SQ_MQ_REF_PRO DUCT MQ_Message_Re ad (Flat File) Lecture du

SQ_MQ_REF_PRO

DUCT

Découpage du message SQ f(x) SQ_MQ_REF_PRO DUCT MQ_Message_Re ad (Flat File) Lecture du message
Découpage du message SQ f(x) SQ_MQ_REF_PRO DUCT MQ_Message_Re ad (Flat File) Lecture du message
Découpage du message SQ f(x) SQ_MQ_REF_PRO DUCT MQ_Message_Re ad (Flat File) Lecture du message
Découpage du message SQ f(x) SQ_MQ_REF_PRO DUCT MQ_Message_Re ad (Flat File) Lecture du message

MQ_Message_Re

ad (Flat File)

Lecture du message
Lecture du
message

SQ_MQ_File_re

EXP_SPLIT

DIH_STA_REF_P

ad

RODUCT (Oracle)

MQ_Message_Re ad (Flat File) Lecture du message SQ_MQ_File_re EXP_SPLIT DIH_STA_REF_P ad RODUCT (Oracle)
MQ_Message_Re ad (Flat File) Lecture du message SQ_MQ_File_re EXP_SPLIT DIH_STA_REF_P ad RODUCT (Oracle)

Figure 19 : Mapping type d’extraction d’un message depuis une file MQ Series

IntégratIon de données opératIonnelle

52

6.3.1.2 étape 2 : Zone de persistance

Cette étape stocke les données extraites dans la zone de Staging qui constitue une zone persistante. Cette zone persistante permet de conserver les données brutes (sans aucune transformation) pendant une durée variable. L’utilisation d’une zone persistante n’est pas systématique, et est même inutile lorsque le mode « full » est employé (cas 3.1).

le stockage des données brutes dans la zone persistante présente les avantages suivants :

diagnostic : facilite le diagnostic en cas de rejet pendant la création des données pivot. En effet, les données étant stockées au format brut (sans aucune transformation), la visualisation des données en cause ne nécessite pas de connexion à l’application source. les données brutes et les erreurs associées peuvent être visualisées avec une IHM centralisée.

recyclage : le recyclage des données rejetées pendant la création des données pivot est facilité. En effet, selon le type d’extraction, la source n’est pas avisée du rejet de données spécifiques dans le Data Integration Hub. Par conséquent, lors de l’exécution suivante, les données précédemment rejetées ne sont pas resoumises à moins d’avoir été modifiées. Ce principe ne concerne pas les cas 1.2, 2.4 et 3.1.

Cas spécial du recyclage pour les files de messages :

le stockage du message brut dans la zone de staging permet d’en visualiser plus facilement le contenu. Il est normalement visible dans la file de messages, mais peut dans certains cas être tronqué s’il est trop long.

Cela permet également de renvoyer directement un message qui aurait été rejeté pendant la création des données pivot en entrée de la file de messages source ; le recyclage devient ainsi automatique et évite que le Data Integration Hub ne sollicite le système source dans le seul but de renvoyer ce message rejeté. Bien entendu la file de messages peut conserver le message après lecture, endossant ainsi le rôle de zone persistante ; il n’existe toutefois aucune méthode pour notifier la file de messages de la lecture d’un message spécifique, ce qui oblige à supprimer explicitement le message après l’avoir lu.

Une file de messages ne peut pas conserver un trop grand nombre de messages pendant longtemps. Par conséquent, une persistance s’appuyant sur une base de données relationnelle, comme la zone de staging, est préférable.

IntégratIon de données opératIonnelle

53

Identification du message rejeté lors de la précédente création de Pivot Mise à jour du
Identification du message
rejeté lors de la précédente
création de Pivot
Mise à jour du statut du
message pour indiquer son
recyclage
DIH_STA_MESSA
GE_BRUT_upd (
ORACLE)
DIH_STA_MESSA
GE_BRUT (Orac
le)
SQ
Marquage du message
comme recyclé
DIH_CORE_INST
SQ_Ident_Fail
_TRT_upd_stat
ed_Message
us (Oracle)
DIH_CORE_INST
_TRT (Oracle)
MQ_REF_PRODUC
T_ins (MQSeri
Renvoi du message
rejeté vers la file
es)
Figure 20 : Mapping type de recyclage d’un message MQ rejeté par le dIH

6.3.1.3 étape 3 : Création du pivot

En fonction du choix d’implémenter ou non une zone de persistance pour le flux, le pivot est créé soit à partir de la zone de persistance, soit à partir de la source elle-même. au cours de cette étape, les actions suivantes sont réalisées :

Contrôles communs à toutes les cibles.

transformations communes à toutes les cibles.

génération des données pivot.

• Instanciation du pivot pour chaque cible.

avant la création des données pivot, une série de contrôles, communs à toutes les cibles, est réalisée pour vérifier la qualité du pivot et sa capacité à alimenter les cibles. selon les résultats de ces contrôles, plusieurs cas peuvent se présenter :

Au moins un des contrôles bloquants a échoué : le pivot n’est pas généré, la donnée d’origine est rejetée et l’ensemble des erreurs expliquant le rejet sont tracées.

• Tous les contrôles bloquants sont vérifiés et au moins un des contrôles non bloquants n’est pas vérifié : le pivot est créé, la donnée n’est pas rejeté et l’ensemble des erreurs constatées sont tracées.

• Tous les contrôles bloquants et non bloquants sont vérifiés : le pivot est créé, la donnée n’est pas rejetée et aucune erreur n’est tracée.

IntégratIon de données opératIonnelle

54

DIH_CORE_INST _TRT (Oracle) Ecriture des messages SQ d’erreur f(x) DIH_STA_REF_P SQ_DIH_STA_RE EXP_CTRL RODUCT
DIH_CORE_INST
_TRT (Oracle)
Ecriture des
messages
SQ
d’erreur
f(x)
DIH_STA_REF_P
SQ_DIH_STA_RE
EXP_CTRL
RODUCT (Oracle)
F_PRODUCT
DIH_CORE_PIVO
T_ko (Oracle)
KO
f(x)
Contrôle des
RTR_CTRL
EXP_ERROR
DIH_CORE_ERRO
données en
OK
NRM_ERROR
entrée
R (Oracle)
<--->
<--->
f(x)
<--->
<--->
DIH_CORE_PIVO
Branchement du flux en
fonction du résultat des
contrôles
EXP_TRANSF
GENE_PIVOT_PR
T_ok (Oracle)
ODUCT
Generation du pivot XML

Figure 21 : Mapping type de création du pivot à partir de la zone de staging

L’instanciation du pivot pour chaque cible consiste à déclarer un pointeur vers l’objet pivot réel pour chaque cible du flux : le pivot devient disponible et indépendant pour chaque cible; cette instanciation est strictement logique ; elle établit une relation entre chaque instance individuelle de la cible et l’instance physique du pivot.

Par exemple, pour un flux de Données de Contact Client comptant 3 cibles A, B et C, le pivot p est déclaré indépendamment pour les cibles A, B et C. Les demi-flux sortants pour ces 3 cibles seront en mesure de traiter le pivot P selon leurs fréquences propres et avec leurs contrôles et protocoles spécifiques.

ainsi, lors de l’exécution suivante, l’instance A du pivot P pourra être chargée correctement dans la cible A ; l’instance B rejetée en raison de l’échec d’un contrôle de validité propre à la cible B ; l’instance C en attente de traitement car la cible C attend les mises à jour à une fréquence hebdomadaire et non quotidienne.

L’exemple qui précède peut être schématisé comme suit : Après le demi-flux entrant: Table pilotage
L’exemple qui précède peut être schématisé comme suit :
Après le demi-flux entrant:
Table pilotage pivot-cible
Pointeur Pivot - Cible A
Stockage des
Pointeur Pivot - Cible B
pivots
Pointeur Pivot - Cible C
Les 3 tuples pivot-cible sont disponibles pour les 3 demi-flux sortants

Figure 22 : Gestion pivot-cible après le demi-flux entrant

IntégratIon de données opératIonnelle

55

Après les demi-flux sortants (run 1): Table pilotage pivot-cible Cible A ok Pointeur Pivot -
Après les demi-flux sortants (run 1):
Table pilotage pivot-cible
Cible A
ok
Pointeur Pivot - Cible A
Stockage des
Pointeur Pivot - Cible B
ko
Cible B
pivots
Pointeur Pivot - Cible C
ok
Cible C
Pour les cibles A et C, les tuples pivot-cible ont été correctement
chargés dans les cibles A et C.
Le tuple de la cible B est en échec et automatiquement recyclé.
Figure 23 : Gestion pivot-cible après le demi-flux sortant (run 1) Après correction de la
Figure 23 : Gestion pivot-cible après le demi-flux sortant (run 1)
Après correction de la cause du
rejet du tuple pivot-cible et après
les demi-flux sortants (run 2):
Table pilotage pivot-cible
Pointeur Pivot - Cible A
Stockage des
Pointeur Pivot - Cible B
ok
Cible B
pivots
Pointeur Pivot - Cible C
Seul le tuple pivot -cible B a été rejoué : toutes les causes de rejet ont
été corrigées. Le tuple pivot-cible B a été correctement traité et la
cible B est alimentée avec le pivot.

Figure 24 : Gestion pivot-cible après correction et réexécution du demi-flux sortant

IntégratIon de données opératIonnelle

56

DIH_PARAM_ROU TING_TARGET ( Oracle) SQ SQ_Ident_Pivo t_Target DIH_CORE_PIVO T (Oracle) f(x) DIH_CORE_INST EXP_STATUS
DIH_PARAM_ROU TING_TARGET ( Oracle) SQ SQ_Ident_Pivo t_Target DIH_CORE_PIVO T (Oracle) f(x) DIH_CORE_INST EXP_STATUS
DIH_PARAM_ROU TING_TARGET ( Oracle) SQ SQ_Ident_Pivo t_Target DIH_CORE_PIVO T (Oracle) f(x) DIH_CORE_INST EXP_STATUS

DIH_PARAM_ROU

DIH_PARAM_ROU TING_TARGET ( Oracle) SQ SQ_Ident_Pivo t_Target DIH_CORE_PIVO T (Oracle) f(x) DIH_CORE_INST EXP_STATUS

TING_TARGET (

Oracle)

SQ
SQ

SQ_Ident_Pivo

t_Target

DIH_PARAM_ROU TING_TARGET ( Oracle) SQ SQ_Ident_Pivo t_Target DIH_CORE_PIVO T (Oracle) f(x) DIH_CORE_INST EXP_STATUS

DIH_CORE_PIVO

T (Oracle)

f(x) DIH_CORE_INST EXP_STATUS _TRT (Oracle) Création de tous les tuples Pivot - Cible
f(x)
DIH_CORE_INST
EXP_STATUS
_TRT (Oracle)
Création de tous les
tuples Pivot - Cible

Figure 25: Mapping type de création des pointeurs liés à un pivot

6.3.1.4 étape 4 : Recyclage des rejets

Pour un demi-flux entrant, le recyclage concerne les données qui n’ont pas pu être transformées en données pivot en raison de contrôles invalidants. Le recyclage est une étape facultative. Lorsqu’il n’est pas mis en œuvre, les données sources doivent être émises à nouveau par le système source. Cela correspond notamment au cas 3.1 des types d’extraction (« full »).

Si le recyclage est mis en œuvre, les données initiales rejetées peuvent avoir été modifiées entre temps au niveau de la source. dans ce cas, les données sources peuvent être extraites à nouveau de la source, ce qui se solde par la présence de deux instances en entrée du demi-flux entrant ; celle qui a été rejetée au cours de l’exécution précédente et celle qui a été modifiée depuis l’exécution précédente. Ce cas particulier doit être traité avec précaution car la cohérence globale des données dans toute l’application peut s’en trouver affectée.

deux options permettent de gérer ce cas :

• Le rejet est supprimé au profit de la nouvelle donnée extraite : cette nouvelle donnée est censée être plus à jour que le rejet et donc plus fiable.

• Le rejet est conservé car les cibles souhaitent tracer toutes les modifications.

6.3.1.5 étape 5 : Acquittement vers le système source

Cette étape est facultative. Elle consiste à notifier à la source que la donnée a correctement été prise en compte par le Data Integration Hub, c’est-à-dire que le pivot a bien été créé. Pour les sources demandant un acquittement, les données non acquittées seront ré-extraites lors du prochain traitement, même si elles n’ont pas été modifiées entre temps. L’acquittement peut être réalisé par un demi-flux sortant dont la cible sera la source elle-même. Dans ce cas, il sera nécessaire d’instancier le pivot pour la source elle-même.

IntégratIon de données opératIonnelle

57

6.3.2 Demi-flux sortant

Un demi-flux sortant est spécifique à une instance de pivot et à une cible.

Les étapes d’un demi-flux sortant sont les suivantes :

   

Facultative /

étape n°

description

obligatoire

1

Identification des données pivot qui n’ont pas encore été prises en compte par une cible donnée ou qui ont été rejetées au cours de l’exécution précédente

obligatoire

2

traitement du pivot en fonction de la cible.

Facultative

3

stockage dans une zone persistante (zone de staging).

Facultative

4

Chargement dans la cible ou mise à disposition des données pour le système cible.

obligatoire

5

Acquittement dans le Data Integration Hub.

Facultative

6.3.2.1

Étape 1 : Identification des données pivot à traiter

 

2 types de pivot doivent être traités :

• Ceux qui viennent d’être créés par le demi-flux entrant.

• Ceux qui ont été rejetés au cours de l’exécution précédente en raison d’une erreur au niveau des contrôles de données.

Seules les instances liées à la cible mise en jeu dans le demi-flux sont concernées.

6.3.2.2 étape 2 : Traitement du pivot en fonction de la cible

Cette étape consiste à :

• Valider les données pivot en effectuant les contrôles spécifiques à la cible.

• Transformer les données pivot en fonction des spécificités de la cible, en particulier des conversions s’appuyant sur des tables de transcodification.

• Formater les données du pivot dans la structure attendue par la cible (iDoc SAP, fichier plat avec séparateur, format edI…)

Avant de charger la cible, une série de contrôles spécifiques à la cible est réalisée pour vérifier que cette dernière ne rejettera pas les données.

IntégratIon de données opératIonnelle

58

selon les résultats de ces contrôles, plusieurs cas peuvent se présenter :

• Au moins un des contrôles bloquants n’est pas vérifié : la cible n’est pas alimentée, la donnée est rejetée et l’ensemble des erreurs expliquant le rejet sont tracées.

• Tous les contrôles bloquants sont vérifiés et au moins un des contrôles non bloquants n’est pas vérifié : la cible est alimentée, la donnée n’est pas rejeté et l’ensemble des erreurs constatées sont tracées.

• Tous les contrôles bloquants et non bloquants sont vérifiés : la cible est alimentée, la donnée n’est pas rejetée et aucune erreur n’est tracée.

6.3.2.3 Étape 3 : Stockage dans une zone persistante (zone de Staging)

dans certains cas, il peut s’avérer utile de sauvegarder les données formatées avant de les transmettre à la cible. Ce stockage a essentiellement vocation de diagnostic en cas de rejet par la cible malgré les contrôles réalisés dans les demi-flux entrants et sortants. Elle peut aussi constituer la preuve que les données ont bien été transmises à la cible.

La durée de rétention dans cette zone persistante est configurable. Les données sont souvent stockées dans un CloB (texte) ou un Blog (binaire), selon le type de cible.

6.3.2.4 étape 4 : Chargement ou envoi des données dans la cible

seuls les pivots validés peuvent être transmis à la cible

dans la plupart des cas, les cibles ne sont pas chargées directement, mais par l’intermédiaire de messages, de fichiers plats, de tables d’interface, d’appels de fonction internes à l’application ou d’appels de services Web. Les différents connecteurs PowerExchange peuvent gérer tous les types de cible et tous les protocoles.

6.3.2.5 étape 5 : Acquittement dans le Data Integration Hub

Pour certaines données sensibles, il peut s’avérer utile de disposer d’un mécanisme d’acquittement dans le data Integration Hub. Une fois les données correctement chargées dans la cible, cette dernière transmet un ordre d’acquittement sur le DIH pour signifier au DIH que la donnée est bien prise en compte. Le modèle de flux suivant peut être utilisé pour charger des données produits dans la cible A (table sQlserver dans le cas présent) :

IntégratIon de données opératIonnelle

59

Indication de l’erreur ou du succès du chargement dans la cible f(x)
Indication de l’erreur ou du
succès du chargement
dans la cible
f(x)

DIH_CORE_INST

_TRT (Oracle)

EXP_CTRL_TARD

ET

RTR_CTRL

Contrôles spécifiques à la cible
Contrôles
spécifiques à la
cible

Modifications des données conformément au format cible ET RTR_CTRL Contrôles spécifiques à la cible Table Produits dans la cible A Lecture du pivot

Table Produits dans la cible A
Table Produits
dans la cible A
Lecture du pivot DIH_CORE_INST _TRT (Oracle) <---> <---> SQ <---> <--->
Lecture du pivot
DIH_CORE_INST
_TRT (Oracle)
<--->
<--->
SQ
<--->
<--->

DIH_CORE_PIVO

SQ_Pivot_Targ

PARSER_PIVOT

T (Oracle)

er_to_Treat

REF_PRODUCT

Identification des pivots concernés par la cible APARSER_PIVOT T (Oracle) er_to_Treat REF_PRODUCT f(x) DIM_PRODUIT ( EXP_FORMAT Microsoft SQL Server) OK

f(x) DIM_PRODUIT ( EXP_FORMAT Microsoft SQL Server) OK KO f(x) EXP_ERROR DIH_CORE_ERRO NRM_ERROR R (Oracle)
f(x)
DIM_PRODUIT (
EXP_FORMAT
Microsoft SQL
Server)
OK
KO
f(x)
EXP_ERROR
DIH_CORE_ERRO
NRM_ERROR
R (Oracle)
Ecriture des
messages
d’erreur

Figure 26 : Mapping type de demi-flux sortant (cible Base de données)

Le modèle de flux ci-dessous peut être utilisé pour charger les mêmes données de produits (issues du même pivot) dans la cible B (via un message MQ) :

Indication de l’erreur ou du succès du chargement dans la cible
Indication de l’erreur ou du
succès du chargement
dans la cible
de l’erreur ou du succès du chargement dans la cible EXP_CTRL_TARD ET Contrôles spécifiques à la

EXP_CTRL_TARD

ET

Contrôles spécifiques à la cible
Contrôles
spécifiques à la
cible

DIH_CORE_INST

_TRT (Oracle)

Lecture du pivot DIH_CORE_INST _TRT (Oracle) <---> <---> SQ f(x) <---> <--->
Lecture du pivot
DIH_CORE_INST
_TRT (Oracle)
<--->
<--->
SQ
f(x)
<--->
<--->

DIH_CORE_PIVO

SQ_Pivot_Targ

PARSER_PIVOT

T (Oracle)

er_to_Treat

REF_PRODUCT

Identification des pivots concernés par la cible BPARSER_PIVOT T (Oracle) er_to_Treat REF_PRODUCT Modifications des données conformément au format cible

Modifications des données conformément au format cible Identification des pivots concernés par la cible B File de messages MQ pour la cible B

File de messages MQ pour la cible B
File de messages
MQ pour la
cible B
f(x) MQ_TargetB_PR EXP_FORMAT ODUCT (MQSeri es) OK RTR_CTRL KO f(x) EXP_ERROR DIH_CORE_ERRO NRM_ERROR R
f(x)
MQ_TargetB_PR
EXP_FORMAT
ODUCT (MQSeri
es)
OK
RTR_CTRL
KO
f(x)
EXP_ERROR
DIH_CORE_ERRO
NRM_ERROR
R (Oracle)
Ecriture des
messages
d’erreur

Figure 27 : Mapping type de demi-flux sortant (cible File MQ Series)

IntégratIon de données opératIonnelle

60

6.4 BONNES PRATIquES DE MISE EN œuVRE Du DATA

INTEGRATION HuB

la mise en place d’un data Integration Hub doit respecter les étapes suivantes :

1 ère phase : liste de toutes les fonctionnalités prévues ou requises.

2 ème phase : inventaire des flux de données prévus.

3 ème phase : configuration de base de données du Data Integration Hub, c’est-à-dire installation et configuration des composants communs nécessaires à son exécution.

4 ème phase : conception et déploiement des flux de données dans le Data Integration Hub.

Installation et configuration de la base du Data Integration Hub Conception et déploiement des flux
Installation et
configuration de la
base du Data
Integration Hub
Conception
et déploiement
des flux de
données
Inventaire des Liste de toutes les fonctions prévues ou requises flux de données prévus
Inventaire des
Liste de toutes les
fonctions prévues
ou requises
flux de
données
prévus

Figure 28: etapes pour la mise en place d’un data Integration Hub

6.4.1 1 ère phase : Liste de toutes les fonctionnalités prévues ou requises

Cette étape est destinée à définir le périmètre d’utilisation du Data Integration Hub au sein de l’entreprise. plus précisément, il convient de savoir si le data Integration Hub sera utilisé pour synchroniser des systèmes de données de référence (en soutien d’un projet de Master data Management), pour automatiser des processus métiers pilotés par les données (intégration de processus pilotés par les données, traitement direct de bout en bout), pour consolider ou regrouper des informations (consolidation de données client, consolidation d’instances applicatives, regroupement de documents bureautiques à des fins opérationnelles ou statistiques, ou pour alimenter un système de Gestion de Contenu d’Entreprise), pour répliquer des données entre systèmes ou pour devenir le composant de services de données de l’entreprise supportant tous les aspects de manipulation des données dans l’optique d’une stratégie SOA.

le data Integration Hub peut exécuter toutes ces tâches. toutefois, selon le comportement envisagé, les différents composants ne sont pas tous installés.

Un type de projet au moins doit être choisi en fonction des priorités des besoins métiers. les autres composants d’intégration de données peuvent être installés ultérieurement en fonction des besoins métiers.

IntégratIon de données opératIonnelle

61

Selon les objectifs définis pour le Data Integration Hub, cette étape consiste à mettre en œuvre les fonctions choisies parmi l’ensemble des fonctionnalités, qui peuvent être classifiées dans les catégories suivantes :

1. transfert de données entre systèmes.

2. Contrôles et certification des données.

3. gestion des rejets

4. Configuration et orchestration des flux.

5. Administration / paramétrage / configuration

6. traçabilité et audit

7. surveillance - rapports

8. Qualité de service

pour des informations plus détaillées, consultez la section traitant des fonctionnalités du data Integration Hub.

6.4.2 2 ème phase : Inventaire des flux de données prévus

Cette étape consiste à établir la topologie de tous les flux et applications concernés par le Data Integration Hub, ainsi que la feuille de route associée au déploiement des flux.

Une estimation des volumes concernés doit être établie au cours de cette étape.

l’objectif principal de cette étape consiste à obtenir une vue globale du data Integration Hub pour identifier aussi rapidement que possible les charges de travail et la planification des phases de déploiement des différents flux.

6.4.3 3 ème phase : Configuration de la base de données du Data Integration Hub

Il s’agit de la phase de mise en œuvre de la base de données du data Integration Hub:

Installation des 5 domaines du data Integration Hub :

- Zone de staging

- Zone du Hub (obligatoire)

- Zone des données de référence

- Zone de paramétrage et de configuration

- Zone de statistiques.

selon les fonctions sélectionnées au cours de la phase 1, certains de ces domaines ne seront pas utilisés (à l’exception de la zone du Hub, qui constitue le composant principal obligatoire du data Integration Hub).

IntégratIon de données opératIonnelle

62

62 • Configuration des traitements récurrents et partagés, en particulier : - Gestion du recyclage des
62 • Configuration des traitements récurrents et partagés, en particulier : - Gestion du recyclage des

• Configuration des traitements récurrents et partagés, en particulier :

- Gestion du recyclage des messages (dans le cas de files de messages comme systèmes sources)

- purge des données

- gestion des cibles

- Contrôles standard : contrôles de format (tels que contrôles de format de date / heure) ou contrôles d’intégrité récurrents (contrôles d’existence de références produit par exemple…)

- etc.

• IHM graphique de configuration pour les options d’administration des données et des flux de données, notamment :

- administration de la gestion des cibles

- Administration des tables de référence (comme les tables de transcodification)

- Administration des données rejetées (avec affichage du détail des données rejetées)

- Paramètres des flux.

• Surveillance / reporting relatif à l’IHM de configuration. Cela consiste à définir les tableaux de bord nécessaires à la surveillance du data Integration Hub :

-

Suivi des flux

-

suivi des volumes

-

alertes par e-mail

-

 

orchestration des tâches et des processus humains pour la prise en charge des résolutions de problème non automatisables

-

Affinage des règles de qualité des données

-

Valeurs de référence manquantes

-

retraitement des données cibles

-

Résolution des problèmes de qualité des données dans le système source

-

 

Ces modules sont configurés en fonction des besoins exprimés au cours de la phase 1.

IntégratIon de données opératIonnelle

63

6.4.4 4 ème phase : Conception et déploiement des flux dans le Data Integration Hub

Cette phase doit être réitérée pour chaque nouveau flux de données à mettre en œuvre.

Identification de la source
Identification
de la source
Modélisation Définition Spécifications Spécifications Dépendances Durées de Identification de la cible
Modélisation
Définition
Spécifications
Spécifications
Dépendances
Durées de
Identification
de la cible
du schéma
des
des demi-flux
des demi-flux
avec les
rétention des
du pivot
statistiques
entrants
sortants
autres flux
données
Identification des données de référence
Identification des
données de
référence

Figure 29: Etapes pour la mise en place d’un nouveau flux dans le DIH

La mise en place d’un flux peut être détaillée à travers les étapes suivantes :

1. Identification des sources : les questions suivantes doivent être adressées au cours de cette étape

• Où se situent les données les plus fiables et les plus fraîches ? Ce point est utile pour déterminer le bon choix du système source.

Quel est le format disponible pour les données et les attributs à extraire ? Ce point est utile pour déterminer les transformations à réaliser.

• Quels contrôles sont effectués dans le système source ? Afin d’éviter de reproduire ces contrôles dans le data Integration Hub.

• Quelle est la fréquence de mise à jour des données sources ? Il est inutile que les cibles soient mises à jour plus souvent que la source ne peut le permettre.

• Les modifications apportées à la source sont-elles identifiables, et comment ? Ce point détermine la conception du demi-flux entrant.

• Quel est le volume de données mises à jour en fonction de la fréquence de mise à jour ? Ce point contribue à dimensionner le serveur du data Integration Hub.

• La source doit-elle obtenir confirmation que les données envoyées ont été prises en compte par une cible spécifique ? La réponse détermine si un mécanisme d’acquittement pour la source est nécessaire.

La source peut ne pas fournir l’ensemble des informations souhaitées pour un flux donné, et certaines données complémentaires peuvent être stockées dans d’autres systèmes sources. Il est alors essentiel de définir la source maîtresse et les sources secondaires. L’utilisation du module de Profiling des données du Data Integration Hub est indispensable pendant cette phase, pour l’accélérer et garantir une vision complète des formats sources et de l’analyse du contenu. Elle contribue aussi à identifier les contrôles de qualité des données qui ont été effectués à la source pour élaborer un pivot valide et aider à sa constitution.

IntégratIon de données opératIonnelle

64

2. Identification des cibles : les questions suivantes doivent être adressées au cours de cette étape

Quelles cibles doivent être chargées ?

• Quelles sont les informations prévues ou requises pour chaque cible, et dans quel format ?

Quelles sont les contraintes d’intégrité ? les réponses déterminent les contrôles nécessaires pour que les données non valides soient rejetées dès leur arrivée dans le Data Integration Hub, au lieu d’attendre qu’elles atteignent la cible, sachant que le data Integration Hub fournit un mécanisme de recyclage des rejets.

• Quelle latence des données pour la mise à disposition dans chaque cible ? Ce point détermine la fréquence d’exécution du demi-flux sortant et assure son adéquation par rapport à la fréquence d’extraction de la source.

• La cible a-t-elle des périodes d’indisponibilité programmées durant lesquelles son alimentation est impossible ? Cette information fait partie de la configuration des cibles.

• Quel est le processus d’acquittement permettant de vérifier que les données ont été correctement intégrées ?

Il importe de s’assurer de la complétude de la détermination des cibles concernées par un flux, même lorsqu’une cible spécifique n’est prévue d’être disponible que plusieurs mois après le déploiement du flux correspondant. Les besoins futurs doivent être anticipés pour définir dès le début de l’étude une structure pivot stable, qui n’évoluera pas à chaque changement mineur ou lorsqu’une nouvelle instance sur les cibles sera ajoutée au flux. Comme pour la phase d’analyse des sources, le Profiling sur les cibles (avec l’option de Profiling du Data Integration Hub) permet d’obtenir une vision complète du format et du contenu des données, et contribue à déterminer le mapping entre les systèmes sources et cibles.

3. Identification des données de référence : certains flux exigent la vérification de l’existence d’un attribut de données dans une application de référence. Par exemple, lorsqu’une entreprise dispose d’un système de Données de Référence Client, un flux traitant les commandes vérifie l’existence du client concerné dans ce système de référence.

Un système de référence peut aussi être employé pour enrichir un flux par des informations absentes du système source. Par exemple, le niveau de risque d’un client peut être extrait d’un système secondaire, son adresse d’un troisième système, etc.

A l’issue des étapes 1, 2 et 3, sont définis :

• Les sources et cibles du flux.

les éventuels référentiels nécessaires.

la liste des informations disponibles dans les sources.

• La liste des informations attendues pour chaque cible.

IntégratIon de données opératIonnelle

65

L’outil de profiling des données permet un diagnostic complet et automatique des sources et des cibles. Il peut notamment répondre aux questions suivantes :

disposons-nous des données nécessaires pour alimenter toutes les cibles ?

• La définition des données correspond-elle aux besoins métiers pour les flux ?

la nature des données, dans leur contenu réel et leur précision, répond-elle aux besoins métiers pour les flux ?

• Les relations entre les éléments de données sont-elles vérifiées pour assurer une intégrité globale au sein d’un flux de données ?

Quelles données doivent être nettoyées ?

Quelles données doivent être transformées ?

• Les données sont-elles fiables en termes d’exactitude, de cohérence et de stabilité ?

Cet outil peut donc s’avérer utile pour :

• Déterminer rapidement la qualité des données sources d’origine et décider ainsi quelle(s) source(s) il convient d’utiliser.

établir le format du pivot.

• Établir les contrôles à mettre en place au sein du flux pour pallier à d’éventuels défauts de contrôle au niveau de la source.

Établir les transformations requises (en particulier les transformations de format et les transcodifications) afin que sources et cibles puissent communiquer. Le profiling devrait être utilisé dès le tout début de la conception des flux ; il permet de gagner un temps considérable dans la spécification des flux et dans l’amélioration de leur fiabilité. Par exemple, en réduisant le nombre de rejets grâce à un choix judicieux de la source de données et des transformations à appliquer.

4. Détermination du schéma du pivot : grâce aux informations récoltées au cours des étapes précédentes, la structure du pivot peut être établie :

En termes de contenu, il s’agira du cumul de toutes les informations nécessaires pour chacune des cibles. Sachant qu’il n’est pas possible de définir un pivot universel, il est nécessaire de connaître au plus tôt l’ensemble des cibles et l’exhaustivité des données attendues par chaque cible.

En termes de structure, il s’agira de la structure de la donnée dans la source : par exemple, pour une commande, un niveau en-tête et un niveau ligne (1 en-tête pour N lignes) ; pour un référentiel fournisseur, un seul niveau.

IntégratIon de données opératIonnelle

66

66 À des fins de cohérence et de maintenance, il importe de définir un glossaire, qui

À des fins de cohérence et de maintenance, il importe de définir un glossaire, qui permettra de créer facilement les balises XML pour le pivot. Informatica fournit un module de glossaire métier pour faciliter cette tâche et garantir que tous les utilisateurs, techniques ou commerciaux, disposent du même niveau de compréhension.

Le schéma du pivot est réellement l’aspect le plus structurant d’un flux ; cette étape est donc primordiale pour la bonne implémentation des flux.

5. Détermination des éléments statistiques : Pour un flux donné, il existe 2 niveaux d’informations statistiques :

Les informations clés : données permettant d’identifier de manière unique le contenu du pivot : par exemple, le numéro de facture pour un flux de factures ; ou le code EAN d’un article pour un flux référentiel produit).

Les attributs importants : attributs permettant de qualifier le contenu du pivot :

par exemple, pour un flux de factures, il pourra s’agir de l’identifiant du client, du montant TTC, de la devise et de la date de la facture ; ou pour un flux référentiel produit, il pourra s’agir du statut du produit et des dates de début et de fin de commercialisation.

6. Spécifications du demi-flux entrant : Lors de cette étape, devront être définis les points suivants :

• Le scénario du demi-flux entrant : voir à privilégier un mode différentiel ou un mode message pour gérer au mieux la volumétrie transférée.

Le type de connexion avec la source

• La fréquence de lancement du demi-flux

La rétention : la mise en place ou non d’un stockage des données brutes dans la staging area.

Le mapping entre la source et le pivot, y compris les éventuelles transformations.

Les contrôles à mettre en œuvre avant la création du pivot : il s’agit des contrôles communs à toutes les cibles. Les contrôles spécifiques à une cible doivent être positionnés dans le demi-flux sortant correspondant. pour les contrôles, il faut déterminer la sévérité (pour savoir si cela déclenche ou non le rejet de la donnée), le message d’erreur et l’éventuelle action associée.

IntégratIon de données opératIonnelle

67

7. Spécifications du demi-flux sortant : lors de cette étape, devront être définis les points suivants :

Le type de connexion avec la cible.

• La fréquence de lancement du demi-flux.

La rétention : la mise en place ou non d’un stockage des données en staging area avant envoi.

Le mapping entre le pivot et la cible, y compris les éventuelles transformations et les transcodifications.

Les contrôles spécifiques à la cible et donc à mettre en œuvre après la création du pivot.

Acquittement : détermine si un système cible doit renvoyer une information sur l’intégration définitive des données.

Compensation : le traitement des données est réparti en plusieurs transactions, qui peuvent être utiles pour maintenir la cohérence globale des données. Par exemple, si les données de commande sont prises en compte, le montant de la commande peut être contrôlé par rapport à la somme de tous les montants des articles de la commande ; ou, si la validation d’un utilisateur est requise au niveau du Data Integration Hub, les transactions en attente peuvent être confirmées ou annulées, reliant ainsi l’intégration des données et l’intégration des processus à un niveau global.

Cette étape est à réaliser pour chacune des cibles.

8. Dépendances avec d’autres flux : cet aspect est surtout impactant pour les cibles ayant des contraintes d’intégrité entre des données mises à jour par des flux distincts : par exemple, une cible de suivi des stocks sera impactée par les 3 flux suivants : flux référentiel produit, flux de commandes et flux de réceptions. Ces 3 flux devront être lancés dans cet ordre sous peine d’occasionner des rejets inutiles. le data Integration Hub, associé à son module de gestion des métadonnées, permet d’obtenir ce type d’informations et de comprendre quels sont les impacts en cas de modification d’un attribut ou d’une règle.

IntégratIon de données opératIonnelle

68

9. Durées de rétention des données : les deux durées de rétention concernent respectivement le pivot et les données statistiques. pour des raisons de volumétrie, le pivot peut être conservé moins longtemps (2 mois par exemple) que les données statistiques (13 mois par exemple).

Pour la mise en œuvre des flux, une bonne approche consiste à fonctionner en 3 temps, selon le principe « commencer petit, voir grand » :

dans un 1 er temps, élaborer un pilote sur un ou deux flux pour bien valider le fonctionnement, les choix des fonctionnalités et les attentes.