WP BIancInformatica DB V4 2

Intgration de donnes oprationnelle
02
03
INTEGRATION DE DONNEES OPERATIONNELLE

Auteurs Jean-Franois Saluden est architecte sI chez logica. Il est spcialis depuis 1999 dans lintgration de donnes et la Business Intelligence. Il a activement particip la construction de nombreux systmes BI et la rationalisation darchitectures. la majorit de ces chantiers ont mis laccent sur lintgration de donnes et loptimisation globale des systmes. son expertise la naturellement conduit, au travers dtudes prliminaires, la mise en oeuvre du Hub dIntgration de donnes. Il est dsormais responsable de lactivit BI et Intgration de donnes au Centre de service de logica France situ Montpellier, tablissement spcialis dans la BI, lintgration de donnes et le CrM. Cyrille Lintz est architecte Integration de donnes chez logica depuis 1998. Il a conu et dploy des projets pour diffrents secteurs tels que les tlcommunications, le luxe, la grande distribution, lautomobile, lassurance, lnergie, les mdias ainsi que les industries alimentaires. Cyrille a en particulier particip la mise en uvre dun Hub dintgration de donnes utilisant la technologie Informatica pour lU France, appartenant anciennement au groupe danone.
IntgratIon de donnes opratIonnelle
04
Sommaire
1. 2. 3. 4. Prsentation de lIntgration de Donnes Oprationnelle............................................. 07 Caractristiques de lIntgration de Donnes Oprationnelle..................................... 08
2.1 Explication des caractristiques de lIntgration de Donnes ................................................08
Projets dIntgration de Donnes Oprationnelle tudis ............................................. 10 Projets dIntgration de Donnes Oprationnelle Temps Rel .................................... 12
4.1 Comparaison entre lIntgration de Donnes et lIntgration de Processus ...................12 4.2 Temps Rel ? .....................................................................................................................................................14
5.
Dtail de trois projets dIntgration de Donnes Oprationnelle ............................... 15

5.1 Rplication de donnes ...............................................................................................................................15 5.2 Synchronisation de Donnes ....................................................................................................................17 5.3 Data Integration Hub ....................................................................................................................................19
6.
Mise en uvre du Data Integration Hub................................................................................. 25

6.1 Organisation des fonctionnalits du Data Integration Hub ......................................................25 6.1.1 le noyau du data Integration Hub: mouvement de donnes entre systmes..........25 6.1.2 Contrles de qualit et certification des donnes .........................................................................29 6.1.3 gestion des donnes en rejet .......................................................................................................................32 6.1.4 Frquence des flux et orchestration ........................................................................................................33 6.1.5 paramtrage / configuration .........................................................................................................................34 6.1.6 traabilit 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 dintgration de donnes ..............................................................................................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 : Cration du pivot .........................................................................................................................53 6.3.1.4 tape 4 : recyclage des rejets .................................................................................................................56 6.3.1.5 tape 5 : Acquittement vers le systme source ..........................................................................56
05
6.3.2 Demi-flux sortant.........................................................................................................................................57 6.3.2.1 tape 1 : Identification des donnes 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 donnes 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 1re phase : Liste de toutes les fonctionnalits prvues ou requises.................................60 6.4.2 2me phase : Inventaire des flux de donnes prvus .....................................................................61 6.4.3 3me phase : Configuration de la base de donnes du data Integration Hub .............61 6.4.4 4me phase : Conception et dploiement des flux dans le data Integration Hub ......63
7.
Annexes ................................................................................................................................................... 69
7.1 table des figures ..................................................................................................................................................................69
06
Prface
Force est de constater que le monde de lintgration de donnes a connu de nombreuses volutions au cours des deux dernires dcennies. les entreprises ralisent de plus en plus la valeur stratgique de leurs donnes pour leur activit tout en tant confrontes une vritable explosion des volumes manipuls. Le Gartner estime quen 2012, les utilisateurs auront besoin de 6,5 fois plus de tetraoctets quen 2008. Historiquement, les principales solutions dintgration de donnes se sont dveloppes dans le cadre des initiatives de data Warehousing et de Business Intelligence. Ce march, que certains analystes appellent plus communment lintgration de donnes analytiques, continue dailleurs crotre aujourdhui. Cependant, la plus forte croissance sobserve dsormais sur lintgration de donnes oprationnelle, qui rpond aux besoins tactiques immdiats de lentreprise afin dassurer son efficacit oprationnelle. Logica intervient sur lensemble des problmatiques dintgration de donnes et a acquis une solide expertise dans ce domaine. Cest pourquoi nous avons souhait rdiger ce livre blanc qui prsente une approche mthodologique de nos bonnes pratiques de mise en uvre des projets dIntgration de Donnes oprationnelle. Ce document a t ralis en troite collaboration avec les consultants professional services de lditeur Informatica, leader mondial des plateformes dintgration de donnes et dont les solutions ont fait leurs preuves en termes de valeur ajoute. Jespre vivement que ce document vous permettra dapporter des rponses concrtes aux questions que vous vous posez sur lintgration de donnes oprationnelle. Nos experts se tiennent votre disposition pour vous apporter leurs retours dexprience en fonction de votre contexte. en vous souhaitant une bonne lecture, Frdric rault Directeur dOffre Business Intelligence & Data Management logica France
1.
Prsentation de lintgration de donnes oprationnelle
07
Avant de poursuivre, attardons-nous sur une dfinition gnralement admise pour lIntgration de donnes oprationnelle : IIntgration de donnes oprationnelle dcrit un ensemble de moyens informatiques permettant daccder des donnes, les nettoyer, les intgrer et les transmettre, avec une certaine latence, en traitant aussi bien des informations actuelles quhistoriques, afin de les utiliser dans les processus dentreprise lis lexcution doprations critiques et appelant des dcisions immdiates. Comme cela a t voqu prcdemment, lIntgration de Donnes Oprationnelle rpond donc aux besoins tactiques immdiats pour assurer lefficacit oprationnelle dune entreprise. LIntgration de Donnes Oprationnelle constitue une pratique assez vaste, qui soutient des initiatives stratgiques plus consquentes et centres sur linformation, comme limplmentation dapplications intgres, lintgration des donnes Client, la gestion des informations produit, la mise en place de la gestion des donnes de rfrence dans son ensemble (Master data Management), linformatique dcisionnelle (BI) pervasive, la BI oprationnelle, lintgration dapplications dentreprise (eaI), lintgration des donnes B2B multi-entreprises, le Business activity Monitoring (BAM) ou encore lIntgration des Processus Mtiers, pour nen nommer que quelques-unes. lIntgration de donnes oprationnelle est susceptible de prendre en charge tous les aspects de manipulation des donnes de ces projets, quil sagisse de mouvements ou de conversions de donnes entre applications, quelle quen soit la latence, ou bien de certification de la donne, de normalisation ou de mise en correspondance accessible sous forme de service pour des applications consommatrices au sein dune architecture oriente service. Loffre dInformatica est particulirement pertinente pour offrir une plate-forme complte, unifie, ouverte et au meilleur cot pour adresser toutes les facettes de manipulations de donnes et ce lchelle de lentreprise.
08
2.
Caractristiques de lintgration de donnes oprationnelle
Examinons les diffrentes caractristiques dintgration de donnes ncessaires aux activits oprationnelles de lentreprise.
Caractristiques de lIntgration de Donnes

Latence : Faible Volume : Faible Qualit : Standard Structure : Simple Transformation : Standard Orchestration: Standard
leve lev Avance Complexe Avance Avance
Figure 1 : Comportement type dun projet dIntgration de donnes
Cet exemple graphique reprsente les six caractristiques marquantes dun projet dIntgration de Donnes Oprationnelle. Dans cet exemple, nous indiquons les caractristiques moyennes (bouton vert) dun projet de synchronisation de donnes (expliqu plus bas). La zone grise reprsente lcarttype des capacits dintgration de donnes pour ce type de projet. par exemple, la latence moyenne dune synchronisation de donnes (bouton vert) est gnralement assez faible. la latence peut toutefois tre plus leve dans certains cas : dans le cas dune chane de production quatre cycles par jour, ses donnes ne seront synchronises avec le systme financier que quatre fois par jour. Ceci est reprsent par un dcalage vers la droite de la zone grise.
2.1 ExPLICATION DES CARACTRISTIquES DE LINTGRATION DE DONNES

Latence des donnes : reprsente la capacit grer diffrentes frquences de mouvement de donnes. elle peut tre programme (une fois par jour, semaine, mois, etc.), dclenche par la survenance dun vnement (arrive dun fichier, appel une application, scrutation des applications) ou en temps rel (dtection des transactions directement dans lapplication source, rception dun message dans une file). Volume de donnes : dtermine le volume manipul en moyenne pour un type de projet donn. Il importe de noter que le volume rsulte de deux facteurs : le volume de llment trait unitairement et le volume global des donnes sur une priode spcifique. En fait, il peut sagir de plusieurs millions de lignes copies quotidiennement dune application lautre ; comme de plusieurs millions de lignes captures et rpliques en temps rel tout au long dune journe ; ou de centaines dnormes fichiers de donnes arrivant au fil de leau toute la journe et traiter ds leur arrive ; ou encore de centaines de milliers de-mails reus avec pice jointe, analyss, convertis et intgrs dans le systme dinformation, jour et nuit.
09
qualit de donnes : garantit que les donnes sont contrles au cours des manipulations et des transferts de ces donnes. La qualit de donnes garantit que les donnes de mauvaise qualit ne seront pas propages entre systmes. Ou quune donne de mauvaise qualit provenant de lextrieur ne pntrera pas dans le systme dinformation de lentreprise. La qualit de donnes garantit la cohrence, lintgrit, la compltude et lexactitude des donnes. Elle vrifie galement que toutes les donnes qui pntrent dans le systme dinformation sont valides conformment aux rgles de lentreprise et ne sont pas doublonnes. La qualit des donnes identifie galement les similarits des donnes entre systmes pour crer, maintenir ou avertir des relations entre donnes de diffrents systmes. Structure des donnes : dfinit la large gamme de formats et de structures que le projet peut traiter. Il peut sagir de donnes trs structures (mainframe ou rdBMs par exemple) ou daccs et de format hautement propritaires 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 donnes peuvent tre dstructures et imprvisibles comme les documents bureautiques Excel ou adobe pdF. Transformation des donnes : dcrit la manipulation des donnes qui doit intervenir pendant leur transfert. Ce peuvent tre des transformations basiques de manipulations de chanes ou de nombres ; ou plus complexes, comme la conversion de valeurs dun systme lautre, le calcul ou le fractionnement de valeurs. Souvent, la transformation peut tre aussi avance que lagrgation, la fusion, le routage, la correspondance ou la standardisation, sur une base dintrospection des donnes et dexcution de rgles. Orchestration : dcrit la capacit contrler de bout en bout les processus de transfert des donnes. Un transfert de donnes peut tre excut de bout en bout et grer automatiquement les tapes de manipulation, traitement des erreurs, persistance et rcupration sur erreur. Ce peut aussi tre un long processus dexcution impliquant des dcisions humaines, le stockage temporaire et le traitement manuel des donnes afin de les qualifier et den finaliser le transfert.
10
3.
Projets dintgration de donnes oprationnelle tudis
Ce document traite uniquement de trois types de projets dIntgration de Donnes Oprationnelle. Il aborde les types de projet les plus dynamiques en termes de latence des donnes mais aussi de grands volumes de donnes. la rplication et la synchronisation de donnes sont assez reprsentatives de ces besoins. le troisime type de projet, le Hub dIntgration de donnes, constitue certainement limplmentation dIntgration de donnes oprationnelle la plus avance, o les six caractristiques de lIntgration de Donnes jouent un rle important pour rpondre aux besoins mtiers. Vous pouvez consulter le livre blanc Intgration de donnes oprationnelle pour lentreprise temps rel pour vous faire une ide de certains autres types de projets dIntgration de donnes oprationnelle. Cette tude dcrit en premier lieu le type de projet de rplication de donnes. Rplication de donnes : simple propagation des donnes et synchronisation de systmes en temps rel sur des donnes lmentaires. La rplication de donnes offre uniquement la possibilit de propager les donnes en elles-mmes ou leurs changements, avec trs peu de transformations ou de vrifications sur les donnes. les systmes source et cible concerns sont principalement des bases de donnes de mme structure et souvent du mme diteur. laspect temps rel des traitements est trs important dans ce type de projet. exemples de projet : capture dvnements pour la dtection de fraude, ods (stockage de donnes oprationnelles pour un systme dcisionnel) temps rel, rcupration de base de donnes en cas dincident, synchronisation multi-sites de base de donnes, reporting oprationnel la seconde partie tudie la synchronisation de donnes. Synchronisation de donnes : Le projet de synchronisation de donnes est dune nature plus lgre que le Hub dIntgration de Donnes, et assure principalement la cohrence des donnes entre quelques bases de donnes htrognes ou des applications packages, in situ ou en Cloud1, avec validation de quelques rgles mtiers lgres et rsolution de conflits. La synchronisation de donnes est souvent mise en uvre selon une approche point point et dans un primtre correspondant un service ou un vertical mtier, et vrifie les rgles mtiers associes afin de garantir la bonne marche de lactivit oprationnelle. elle peut aussi inclure une zone de stockage commune pour des composants transverses et la gestion des donnes de rfrence. le projet de synchronisation de donnes constitue trs souvent une premire implmentation tactique pour rsoudre rapidement un besoin mtier critique et peut se transformer en un Hub dIntgration de Donnes lchelle de lentreprise mesure que les besoins mtiers voluent. exemples de projet : synchronisation des donnes client entre un erp et un systme CrM, synchronisation des donnes CRM et financires pour une meilleure connaissance et un meilleur ciblage des clients le Hub dIntgration de donnes est le dernier type de projet tudi.
Le Cloud (en franais, informatique en nuages) est un concept majeur faisant rfrence lutilisation de la mmoire et des capacits de calcul des ordinateurs et des serveurs rpartis dans le monde entier et lis par un rseau, tel Internet (principe de la grille informatique).
11
Hub dIntgration de Donnes : le Hub dIntgration de donnes peut tre considr comme une plate-forme dintgration de donnes complte, capable de traiter tout type de donnes ou applications, au sein dune entreprise ou en dehors et ce avec un niveau de transformation lev, de larges capacits de connectivit, tout niveau de latence et des contrles transversaux de qualit des donnes pour en assurer la cohrence globale (entre enregistrements ou entre donnes diffrentes). Le Hub dIntgration de donnes gre les traitements de bout en bout avec certains routages de donnes et des conversions de format, et assure la certification des donnes pour garantir que les processus de lentreprise reposent sur des informations exactes. Il intgre une zone de stockage intermdiaire qui conserve une trace de tous les contrles et de toutes les transformations, et assure lacquittement de la bonne transmission des donnes ; il peut assurer un monitoring transverse et la traabilit de toutes les donnes gres. le Hub dIntgration de donnes alerte les utilisateurs et les invite grer les problmes de cohrence des donnes ou tout vnement notable susceptible daffecter leur mtier. exemple de projet : synchronisation de donnes entre plusieurs applications, interfaages directs et de bout en bout, synchronisation des donnes de rfrence entre systmes, intgration de donnes multi-entreprises, prise en compte et gouvernance des documents bureautiques, etc. le type de projet appropri est choisi selon le primtre et ltendue des donnes gres et son objectif final. Il faut noter quune implmentation limite comme la rplication ou la synchronisation des donnes peut galement produire les rsultats souhaits tout en ayant la capacit voluer vers un systme plus complet.
12
4.
Projets dintgration de donnes oprationnelle Temps Rel
la besoin lorigine de lIntgration de donnes oprationnelle nat principalement des besoins de cohrence des donnes entre les systmes dinformation ; les donnes doivent tre fiables et cohrentes entre les systmes, et conserver la mme signification, quil sagisse de donnes transactionnelles ou de rfrence. en plus de ce problme de cohrence, lIntgration de donnes permet de grer des volumes variables depuis des transactions unitaires en temps rel, jusqu lintgration de donnes en grands volumes par batchs (de milliers denregistrements plusieurs centaines de millions denregistrements par jour traits massivement). Avant dexaminer en dtail les types de projets, leurs similarits et spcificits, nous expliciterons les concepts dIntgration de Donnes Oprationnelle ainsi que les diffrences entre Intgration de Donnes et Intgration de Processus, car ces deux typologies de projets, pourtant diffrentes, prtent souvent confusion.
4.1 COMPARAISON ENTRE LINTGRATION DE DONNES ET LINTGRATION DE PROCESSuS

Quel que soit le point de vue adopt, lobjectif ultime consiste rsoudre un problme dintgration compliqu pour lentreprise, qui pse sur loptimisation oprationnelle de lactivit. La rsolution de ce problme peut tre aborde du point de vue des processus ou des donnes. les projets dIntgration de processus visent produire des processus mtiers standardiss et en garantir la cohrence en dfinissant leurs diffrentes tapes et en propageant les donnes qui y sont lies ; les donnes en elles-mmes sont propages par les systmes relis entre eux par un processus, mais avec trs peu de transformations et seulement quelques contrles de cohrence ncessaires au bon droulement du processus. LIntgration de Processus ne vise pas contrler ni grer la cohrence ou la qualit des donnes ; elle assure seulement que les donnes entrantes sont correctes pour la bonne continuit du processus. elle assure galement la transmission rapide des donnes entre les systmes, conformment lordonnancement des processus de lentreprise, mais ne concerne gnralement que des transactions unitaires ; ainsi, elle ne vise pas contrler la cohrence globale des donnes entre diffrents systmes sources ou plusieurs enregistrements. les projets dintgration de processus sont principalement construits autour doutils denterprise application Integration (eaI) ou de composants entreprise service Bus (esB) pour lanalyse des transactions et la transmission des donnes, mais ninclut pas en rgle gnrale de composants avancs de Qualit des donnes et ne comble pas totalement les besoins de gouvernance des donnes. lIntgration de processus transfre la plupart du temps des donnes unitaires en quasi temps-rel, mais peut en outre traiter des donnes en masse, en inspecter le contenu ou les transformer. de plus, dans ce type de projet, les processus dirigent les actions dintgration de donnes.
13
Comme nous lavons mentionn en introduction, alors que lobjectif principal de lIntgration de donnes oprationnelle consiste principalement maintenir la cohrence des donnes au sein des systmes dinformation, suivant les besoins mtiers, afin de dlivrer la bonne information au bon moment, les projets dIntgration de donnes sont centrs sur les donnes proprement dites et leur appliquent diffrents types de transformations tout en les transfrant entre applications. Ces transformations comprennent le formatage, les fusions, les agrgations, le routage en fonction du contenu, la validation et mme la compltude des donnes. la capacit traiter tout volume de donnes en masse (un fichier de 10 Go par exemple) ou des transactions unitaires, quelle que soit la latence, constitue un autre aspect de lIntgration de Donnes. Il devient aussi vident que les donnes proprement dites peuvent contenir des informations cls susceptibles daffecter ou mme de diriger lautomatisation de processus. Cette notion est connue sous lappellation data driven process Integration (Intgration de processus pilote par les donnes). dans lIntgration de processus pilote par les donnes, les donnes entrantes vhiculent certaines informations qui dclenchent les processus. Les donnes actionnent des traitements directs qui sont automatiss en fonction du contenu de ces donnes. Il sagit souvent dnormes fichiers traiter, qui gnrent des transactions orchestres dans de multiples applicatifs. Ce contexte cre un besoin crucial de contrle et de certification des donnes pour garantir un droulement correct du processus. Il existe galement un besoin fort en termes de gouvernance des donnes pour comprendre quels processus ont t dclenchs en fonction des donnes traites. Connatre chaque tat des donnes chaque tape du processus ou chaque fois que la donne est manipule est galement un besoin important dans ces contextes. Enfin, le problme nest pas tant dopposer lIntgration de Donnes lIntgration de Processus, toutes deux tant trs complmentaires, mais de mieux comprendre les besoins du projet et dutiliser la meilleure technologie en fonction de lutilisation prvue. Ces deux types dintgration sont trs frquemment ncessaires pour subvenir aux besoins des activits mtiers oprationnelles. Ceci dit, il est intressant de noter quun projet dIntgration 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 rexamines. Par exemple, la modification dun processus SAP ou Oracle ERP nest pas en soi une tche aise, en particulier lorsquelle doit tre excute non seulement au sein dun erp ou dun systme patrimonial existant, mais galement travers de nombreux systmes rpartis dans le monde. Il ne sagit pas seulement dun problme dimplmentation technique dune application ; le problme consiste principalement coordonner plusieurs dpartements mtiers qui doivent travailler ensemble pour affiner les processus afin de grer les transactions mtiers. Un projet dintgration de donnes est plus rapide et plus facile mettre en uvre car, quelle que soit la transaction, elle est toujours initie par une donne et fournit toujours une donne. le projet dIntgration de Donnes est le plus proche de ce patrimoine prcieux quest la donne et, quel que soit le processus mtier, lobjectif ultime consiste obtenir des donnes cohrentes travers lensemble des applications.
14
4.2
TEMPS REL ?
le temps rel est souvent considr comme la capacit dlivrer les informations instantanment. Mais sagit-il bien du besoin rel ? Examinons la dfinition communment admise de linformatique temps rel : les systmes temps rel sont soumis des contraintes de mme nature, cest--dire aux dlais oprationnels entre un vnement et la rponse du systme. les calculs en temps rel sont considrs avoir chou sils ne sont pas termins avant un dlai imparti, dlai qui est li un vnement. En Temps Rel, un dlai limite doit tre respect quelle que soit la charge du systme.
Il nest pas question ici de considration de performance dans labsolu ; la rapidit dune opration, qui est elle-mme une notion somme toute relative, ne doit pas tre confondue avec la capacit fournir linformation sous une contrainte temporelle, quelle quelle soit. le besoin de temps rel dans un contexte dintgration des donnes doit prendre en compte les diffrentes latences exiges pour tous les systmes concerns ; il est inutile dessayer daboutir du temps rel pour toutes les sources et les cibles, mais il convient de se concentrer sur le moment o les donnes doivent tre disponibles pour un systme cible spcifique, en prenant en compte les besoins mtiers et les processus associs. Cest pourquoi il est prfrable de raisonner en termes de Juste Temps (Right Time) plutt que de Temps Rel (Real Time). Cette approche est en outre plus cohrente, car elle respecte les dpendances entre les systmes cibles (donnes devant exister dans un systme donn uniquement lorsque les donnes correspondantes existent dans un autre). Dfinition et critres de Temps Rel dans le contexte dIntgration de Donnes : les jalons oprationnels peuvent tre vus comme des crations/modifications/soumissions de donnes dans un systme et la rponse dun systme la production de donnes finales, conformment lordonnancement des processus mtiers.
Temps
Processus mtier 1
Processus mtier 2
Processus mtier M
Processus mtier N
ERP
Synchronisation des donnes
Application
Juste Temps pour synchroniser lApplication lie au processus mtier M
RDBMS
Juste Temps pour synchroniser le RDBMS li au processus mtier N
Figure 2 : Dfinition du Juste Temps au-del des considrations de latences techniques
5.
Detail de trois projets dintegration de donnees operationnelle
15
5.1
RPLICATION DE DONNES
la rplication est souvent considre comme un simple mcanisme prsent dans les outils des principaux diteurs de base de donnes. dans ce contexte, la rplication est souvent une simple propagation des donnes permettant de synchroniser diffrentes instances de base de donnes utilisant une structure identique ou trs similaire. Ce mcanisme repose sur les fichiers journaux des bases de donnes, qui sont capables de tracer toutes les modifications qui sont intervenues sur une source pour les propager aux cibles . Ces solutions sont gnralement utilises dans des contextes simples pour maintenir la cohrence entre diffrentes instances de base de donnes homognes.

leve leve Avance Complexe Avance Avance
Figure 3 : Comportement type dun projet de rplication de donnes
toutefois, un outil propritaire de rplication de base de donnes atteint ses limites dans de nombreux cas. 1 Limitations techniques pour la rplication htrogne. Ces solutions tant gnralement lies des bases de donnes propritaires, il leur est difficile dagir sur des processus dintgration internes et natifs (comme dans le cas dun erp ou des transactions dApplications, qui comportent souvent un processus dintgration interne pour les donnes entrantes) et elles sont souvent limites au mme type de base de donnes en source et en cible. Cots de mise en uvre et de maintenance lis la ncessit de recourir du scripting (dont la modification ou limplmentation de bases de donnes locales), la rcupration derreur froid (en particulier en cas de rplication multi-site pour garantir un rejeu correct de la transaction), la mise en uvre trs technique exigeant des connaissances approfondies de la base de donnes et limite au niveau de lvolutivit hors solution de lditeur de la base de donnes. Lorsque le nombre dinstances augmente, il devient de plus en plus difficile dassurer une synchronisation correcte sans conflit. mesure que la complexit de larchitecture saccroit et que le nombre de transactions oprationnelles augmente, des dcisions doivent tre prises en cas de collision de donnes : lorsque deux transactions sont gnres sur le mme enregistrement, une stratgie doit tre dfinie pour en dterminer la priorit ; ces
16
solutions sont habituellement bases sur des critres simples (horodatages de transaction par exemple, sil est possible dunifier les horodatages sur des fuseaux horaires diffrents) et, avec une libert de dcision trs troite, peut conduire des choix arbitraires (quels enregistrements conserver, lesquels abandonner). Lintrospection sur les donnes est en outre limite car les rgles de rplication sont gnralement dfinies sur la structure des donnes et non sur leurs valeurs ; dans ce contexte, les dcisions appliquer sont trs limites et peuvent tre soumises caution. 4 non extensible en dehors du systme de bases de donnes relationnelles (synchronisation de donnes dapplications d entreprise comme sap, oracle eBusiness suite, etc.) - une autre solution doit donc tre acquise alors quune solution unique assurant la fois la rplication et la synchronisation des donnes constitue un investissement plus prenne et rutilisable.
les solutions de rplication standard prsentent galement la particularit dliminer les journaux de base de donnes et de les conserver uniquement comme points de restauration en cas de rcupration sur incident. Ils ne peuvent pas tre considrs comme une zone de stockage persistante facile daccs pour suivre individuellement chacune des modifications qui ont eu lieu. Mme si les modifications sont effectivement propages, les dtails sur ces changements et la trace des ventuelles dcisions prises sont perdus... selon le contexte, cette situation peut savrer contraire aux rgles de traabilit et de conformit telles que Sarbanes-Oxley ou Ble II. Un historique complet du suivi des donnes ne peut pas tre assur. Par consquent, le mcanisme de rplication des donnes doit non seulement pouvoir propager les modifications entre plusieurs systmes, mais aussi : propager en fonction de rgles plus complexes, comme le contenu des donnes (valeurs des champs, comparaisons) ventuellement fournir une zone de stockage, qui suit toutes les modifications de journaux phmres de bases de donnes ou capable de stocker des composants communs.
pour ce faire, la rplication de donnes en temps rel propose 2 composants : Un composant de Change Data Capture (CDC), qui est une couche dabstraction permettant daccder aux fichiers journaux. Idalement, ce composant doit galement pouvoir travailler en mode batch de masse pour initialiser la (les) cible(s) lors de la premire excution avant de lancer le mcanisme de CdC proprement dit. Une zone de stockage commun pour stocker des rgles ou des transformations volues, ainsi que pour choisir les modes de propagation des donnes et grer les rsolutions de conflits. Lorsque des rgles trs complexes sont ncessaires pour les contrles ou les transformations des donnes, une implmentation de type synchronisation de donnes doit tre envisage.
avec ces deux composants, il est galement possible dassurer la rplication entre systmes htrognes en utilisant des outils dots de la connectivit adquate et des flux de donnes source et cible distincts.
17
5.2
SyNCHRONISATION DE DONNES
lobjectif de la synchronisation de donnes consiste copier les donnes dune application lautre, avec des niveaux de transformations des plus basiques aux plus avancs. Le champ dapplication dun tel projet se situe principalement au niveau dun service ou dun dpartement de lentreprise, afin de maintenir la synchronisation entre les verticaux pour une meilleure efficacit mtier. la synchronisation permet la propagation dun systme vers un autre, selon une approche point point. Mais elle introduit cependant une notion dindustrialisation car elle est mise en uvre travers une plate-forme centralise et vite ainsi lemploi de plusieurs technologies et de dveloppements unitaires susceptibles de conduire un manque de cohrence globale.

Figure 4: Comportement type dun projet de synchronisation de donnes
la synchronisation de donnes peut saccommoder des contraintes des systmes sources : les latences de synchronisation sont adaptes la nature du systme source (oprationnel ou analytique) et donc la criticit des donnes. la technologie de synchronisation peut prendre en charge une large gamme de connectivits dentreprise.
dautres fonctionnalits apportes par la synchronisation de donnes autorisent lapplication de rgles et de processus plus complexes : les rgles mtiers peuvent tre valides car le systme de synchronisation des donnes est un systme intermdiaire qui peut apporter davantage de fonctionnalits en termes de contrle et de transformation que la rplication. Par exemple, une donne Prospect existe dans un systme, elle est envoye au systme cible pour devenir un Client et recevoir une Identifiant Client unique. Elle est ensuite resynchronise vers le systme source avec cette information. La rsolution des conflits est plus facile traiter, avec des contrles ou des transformations volues.
18
Lintervention humaine peut tre incluse dans ce type de systme en dfinissant des points de validation dans le mcanisme de synchronisation, lorsque les contrles de qualit ou dautres contrles mis sur les donnes peuvent mettre en vidence des problmes. Transcription des donnes de rfrence du systme source (qui ne sont gnralement pas dcrites de la mme manire dans toutes les applications) en valeurs appropries dans le systme cible.
Il est essentiel quun tel projet repose sur la compltude de la vision des donnes traiter et des diffrents systmes concerns. Cela vite la redondance des changes de donnes et garantit la dlivrance des donnes en Juste temps . Le rle du serveur de synchronisation reprsente un autre point critique pour la russite dun projet de synchronisation de donnes. doit-il tre seulement port par un processus etl (extractionTransformation-Chargement) ? Absolument pas ; il doit tre considr comme une application complte, grant non seulement lextraction des donnes, leur transformation et leur transport vers une cible, mais aussi assurant la fois la cohrence unitaire des donnes entrantes et dun point de vue global dans toutes les cibles impliques dans le processus de synchronisation. Cest pourquoi la mise en place dune zone tampon peut galement tre envisage pour limiter les interdpendances entre les systmes dans une approche point point, dans le but dviter les consquences suivantes : Mauvaise gestion des transactions entrantes / sortantes ; les connexions source et cible pouvant interagir dans le cadre dun mouvement de donnes en pipeline, ce qui peut aboutir des temps de connexion plus longs de chaque ct. Les extractions rptes sur une mme source, pour laquelle peuvent correspondre plusieurs cibles, traitant potentiellement les mmes donnes ou des donnes similaires. quipes dexploitation distinctes pour la gestion des applications source et cible, dont les contraintes peuvent tre diffrentes. La zone tampon apporte un dcouplage des systmes et permet de les maintenir sans affecter le systme source ou cible simultanment.
Cette zone persistante intermdiaire est un lment essentiel et obligatoire de larchitecture du data Integration Hub, dtaill dans la section suivante. Lorsque le nombre de systmes sources et cibles augmente, ou si le primtre initial du projet (limit un service ou un dpartement de lentreprise) volue vers un modle multi-mtiers, limplmentation dune synchronisation point point atteint ses limites ; il sera plus difficile de maintenir un tel systme dans loptique dune rationalisation du systme dinformation. En outre, il sera plus difficile dobtenir une vue globale des processus mtiers concerns et dassurer la cohrence des donnes transversalement aux diffrents domaines mtiers. Dans ce cas, un systme dchange de donnes centralis tel que le Data Integration Hub doit tre envisag ; leffort consenti au niveau du systme de synchronisation nest pas perdu car il peut constituer une base solide pour la mise en uvre du data Integration Hub.
19
EXCEL
XML
WORD
PDF
Evolution permanente des interfaces
Codage manual
COBOL ETL b
Consultants C++
Erreur de qualit de donnes
ETL a
Consultants EAI
Rfrentiel produit
CRM
Logistique
Prise de commande
Budget
Facturation
Marketing
Data Warehouse
GED
Figure 5 : la synchronisation point point des donnes 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 Donnes. Il introduit le traitement direct de bout en bout des donnes, dans le cadre duquel les processus mtiers sont ports par les donnes elles-mmes, offrant une vue transverse des donnes gres par une approche de gouvernance des donnes. la diffrence entre le data Integration Hub et la synchronisation de donnes rside dans la prsence de composants applicatifs et la compltude de larchitecture 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 lchange de donnes et dviter des interfaces point point spcifiques. Nous avons dj vu quun certain nombre de ces composants pouvaient tre mis en place dans le cas de la synchronisation de donnes. Une initiative de synchronisation de Donnes peut galement tre la premire brique dun systme plus transverse et plus complet, qui deviendra un data Integration Hub
20

Figure 6 : Comportement type dun projet de data Integration Hub
Nous devons alors choisir quel type dimplmentation devrait tre mis en place Il dpend pour une grande part des donnes et du primtre mtier : si les donnes proviennent dun seul vertical mtier, avec peu de systmes impliqus et principalement dans un seul processus mtier, la synchronisation de donnes est prfrable. elle peut dans ce cas tre considre comme une plate-forme point point volue, et peut tre mise en place pour un cot raisonnable. les projets de dcommissionnement applicatif forment un sous-ensemble de ce type dimplmentation, avec un primtre plus restreint qui nimplique quun systme source (lancien) et un systme cible (le nouveau) ainsi que des donnes de rfrence cohrentes et des transcodifications. lobjectif du data Integration Hub est de grer et de centraliser intgralement tous les changes de donnes, en assurant la cohrence transversale des donnes, et ce au niveau de lentreprise. Il gre tous les types de donnes et concerne tous les secteurs mtiers de lentreprise. avec le nombre de systmes sources et cibles concerns, sa particularit technique consiste grer diffrentes latences et volumes, du message individuel en Juste Temps jusquaux gros volumes en batch. Le point essentiel sur le plan technique consiste mettre en place loutil dchange de donnes appropri capable de grer cette diversit et sur le plan applicatif, de standardiser le processus dintgration, mme avec de telles diffrences et varits de sources et de formats (fichiers plats, bases de donnes relationnelles, applications, ERP, documents bureautiques, normes et standards comme les formats EDI), et ce quel que soit lemplacement physique de la source (interne ou externe lentreprise). Il est indispensable que larchitecture du Data Integration Hub repose sur une vision et une dfinition communes des donnes mtiers et des donnes de rfrence ; mme si tous les systmes impliqus dans les changes de donnes ne partagent pas le mme langage, le data Integration Hub doit dfinir un langage commun afin de pouvoir tablir des correspondances et constituer lunique passerelle entre ces systmes tout en garantissant une qualit de donnes adquate.
21
pour obtenir cette vision transverse, le data Integration Hub doit assurer la traabilit complte des donnes jusqu leur destination finale. Une zone de stockage temporaire intermdiaire est ncessaire pour ce faire.
EXCEL
XML
WORD
PDF
Business
DIH
Exploitation
Rfrentiel 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 prparation qui permet de conserver les donnes transmises et tracer les informations changes. associe un framework applicatif, cette zone persistante permet de grer dune manire centralise : ladministration fonctionnelle : toutes les informations peuvent tre traces et visualises via une interface de reporting. la gestion des rejets : le stockage et le framework peuvent mettre en vidence les rejets, permettant aux utilisateurs mtiers de corriger des donnes inappropries et de les resoumettre en entre du processus dintgration. pour permettre cette fonctionnalit, le stockage persistant doit conserver les enregistrements entrants tels quels afin de pouvoir les rinjecter comme sil sagissait de donnes standard en entre. Ce stockage des donnes brutes peut tre ralis dans la zone de prparation en utilisant : le stockage binaire du (des) message(s) ou de la (des) transaction(s) : es types de donnes BLOB ou CLOB, qui peuvent stocker nimporte quelle structure de donnes. Une structure de base de donnes XML, qui reflte la structure des donnes entrantes ou un champ XML contenant lensemble du message ou de la transaction.
22
Des tables de rfrence pour les transcodifications. Cette zone de stockage sert galement effectuer les traductions entre les donnes de rfrence, qui ne sont gnralement pas dcrites de la mme faon dans toutes les applications. Ces transcriptions font partie des transformations effectues pendant les processus ETL. Elles peuvent tre ncessaires ds que deux applications peuvent crer les mmes donnes mtiers avec des identifiants techniques diffrents. Ces enregistrements doivent tre relis entre eux dans la zone persistante pour dterminer, laide des champs de rfrence mtiers, les correspondances possibles et la stratgie dfinir pour les unifier. Un composant de qualit des donnes facultatif peut tre utilis pour dterminer les correspondances potentielles et pour dfinir les rgles de priorit de fusion denregistrements lorsque des critres automatiques peuvent tre appliqus (correspondance stricte ou approximative), ou laisser les utilisateurs dterminer manuellement les rgles de priorit / fusion. pour cela, les enregistrements doivent tre rapprochs une premire fois pour dterminer les rgles de fusion, pour ensuite tablir les relations entre les identifiants techniques de lapplication dorigine pour propager les modifications dune application une autre. De la mme manire, des rfrences croises sur les identifiants techniques permettent une synchronisation bidirectionnelle.
En plus de ces fonctionnalits importantes, frquemment mises en uvre pour les projets de Synchronisation de Donnes, le Data Integration Hub se compose de plusieurs briques pour garantir la cohrence du processus dintgration de donnes sur lensemble des systmes : Une premire zone de prparation optionnelle : stocke les donnes en ltat sans aucune modification de structure par rapport au systme source. Les donnes sont persistantes sur un certain laps de temps pour plusieurs raisons : Fonction de traabilit : les administrateurs ou les data stewards peuvent voir les donnes entrantes et identifier les problmes qui trouvent leur origine dans les systmes sources. recyclage des donnes : les administrateurs sont en mesure de corriger et de resoumettre les donnes directement dans cette zone. Identification des changements : lorsque la capture directe des donnes modifies sur les systmes sources est impossible, cette zone offre la possibilit de comparer les donnes afin didentifier toutes les modifications intervenues ; il est galement possible de dterminer les modifications et leurs effets entre plusieurs systmes sources grant le mme type de donnes, ce qui naurait pas t possible directement avec un composant technique de type Change Data Capture.
Une base de donnes pivot: cette zone constitue le cur du data Integration Hub. elle stocke les donnes conformment une dfinition mtier commune et transverse de tous types dobjets. le design du modle de donnes de cette zone est un point crucial dans la conception de lensemble de la plate-forme Data Integration Hub ; il devra prendre en compte le gestion des donnes depuis la zone de prparation jusqu leur livraison dans les systmes cibles. Cette zone pivot devra contenir :
23
La structure pivot de chaque objet mtier gr. eventuellement, une structure additionnelle pour stocker des donnes brutes ou binaires lies ces objets (comme des images, etc.) des tables derreur, traant tous les problmes survenant sur les transformations de donnes (des donnes brutes en entre au format pivot, du format pivot au format de la cible). Une table traant lensemble des intgrations effectues dans les systmes cibles ainsi que lacquittement en provenance de ces systmes.
Une base de rfrences : elle stocke les donnes de rfrence ou toute autre donne utile aux contrles de cohrence ou aux transcodifications.
Un framework applicatif peut assurer un monitoring complet sur tout le processus de synchronisation, grce aux fonctionnalits suivantes : gestion des mtadonnes de lIntgration de donnes et lignage complet depuis les sources jusquaux cibles, en y incluant les contrles et les transformations effectues. traabilit complte et gestion des rejets destination des utilisateurs mtiers grce une interface utilisateur conviviale et simple, masquant toute la complexit de modlisation du framework applicatif. Intgrit des donnes de bout en bout, notamment concernant les dpendances entre systmes cibles, garantissant ainsi que des donnes peuvent bien tre propages vers un systme cible donn car les donnes parentes ont dj t totalement intgres dans un autre systme.
tout ceci fournit un reporting complet et une journalisation des vnements maximale (nombre denregistrements traits, nombre de rejets, acquittement de la cible) et permet de suivre lIntgration de processus par un systme de monitoring dentreprise, conformment une approche Gouvernance des Donnes, et qui se focalise sur la qualit des donnes pour amliorer et protger les informations. tous ces composants permettent aux utilisateurs mtiers de participer au processus dIntgration de Donnes, et leur offre une couche dabstraction simple apprhender, ce qui leur permet de piloter la Synchronisation de Donnes sans avoir comprendre les dtails de limplmentation technique et ainsi de se concentrer sur les enjeux rels : les donnes proprement dites et les processus de lentreprise. la plate-forme dIntgration de donnes peut ensuite tre orchestre par lordonnanceur natif de la plate-forme ou voire son propre module dorchestration pilot par des services Web. elle peut aussi tre facilement couple un esB en utilisant les services Web ou JMs pour devenir le point dentre unique de lentreprise pour tout ce qui touche aux transformations de donnes et pour toute approche dIntgration de processus.
24
Ce dernier point doit tre fortement soulign, en particulier pour les entreprises ayant dfini une stratgie dimplmentation soa. le data Integration Hub est un lment cl dans une stratgie SOA ; lensemble des transformations, mouvements, conversions ou contrles de qualit des donnes peuvent tre exposs comme des services. de plus, comme le data Integration Hub repose sur un format canonique et peut virtuellement accder toutes les sources et cibles de lentreprise, il peut tre un fournisseur de donnes lchelle de lentreprise. Tout type dapplication, quelle soit monolithique, composite, distribue ou mme une application software as a service , peut utiliser ou piloter le data Integration Hub en utilisant des appels de services Web.
6.
Mise en uvre du Data Integration Hub
25
6.1 ORGANISATION DES FONCTIONNALITS Du DATA INTEGRATION HuB

Ce chapitre dtaille les fonctionnalits proposes par le data Integration Hub. Ces fonctionnalits sont classes en plusieurs blocs, chacun mettant en avant une caractristique du Data Integration Hub. Il nest pas ncessaire dimplmenter toutes les fonctionnalits ; tout dpend de leur criticit assurer le niveau de service requis sur un projet.
Intervention humaine
Traabilit Monitoring Fiabilit Qualit de Service
Conguration Gestion derreur Contrle de la latence
Contrle de la qualit des donnes
Fonctionnalits communes dchange

Figure 8 : Fonctionnalits du data Integration Hub
6.1.1 Le noyau du Data Integration Hub : mouvement de donnes entre systmes

Voici les principales fonctions que le Data Integration Hub doit prendre en charge pour grer des mouvements de donnes entre systmes. Pour une meilleure comprhension, chaque explication est base sur les dnominations source et cible , mais dans le concept de data Integration Hub, un systme donn peut tre une source, une cible ou les deux la fois, selon le flux de donnes considr.
26
De
mi-
t sor ux
ant
Base de donnes DB2
Message MQ
Demi-ux entrant
Demi-ux sortant 2
Siebel
Data Integration Hub
De
mi-
xs ort
an
t3
Fichier XML
Figure 9 : Flux dIH type : routage depuis une source vers 3 cibles
a.
Routage des donnes sources vers un ou plusieurs systmes cibles Comme illustr dans le diagramme ci-dessus, le data Integration Hub permet de ne solliciter un systme source quune seule fois pour alimenter plusieurs cibles distinctes. Par exemple, un message MQ Series peut tre lu dans une file de messages MQ en entre, puis dlivr 3 systmes cibles diffrents tels quune base de donnes DB2, une instance Siebel et un fichier XML, comme le montre le schma prcdent. lavantage de cette solution par rapport une approche point point est la mutualisation des processus dextraction et des contrles qui leur sont associs : il en dcoule un gain de performance, une maintenance plus aise et une moindre sollicitation du systme source (ce qui est particulirement intressant dans le cas de sources oprationnelles). le data Integration Hub est capable dacheminer des donnes en fonction des informations de leur en-tte, du type dvnement ou du type de source dont elles sont issues, mais plus important encore, le Data Integration Hub est capable deffectuer une introspection des donnes elles-mmes, quil sagisse dune transaction unique ou de milliers de transactions en masse. Le Data Integration Hub peut suivre des rgles de routage bases sur des techniques avances de traitements des donnes.
b.
Conversion ou propagation de tous les formats de donnes sources vers un format cible appropri Le Data Integration Hub est capable de convertir nimporte quel type de format de donnes dans le format adquat aux systmes cibles. Par exemple, un message iDoc SAP peut tre facilement converti en structure de donnes XML, puis au format Excel ; ou un document PDF Adobe peut tre analys afin de charger certaines de ses informations dans une base de donnes relationnelle. Il peut aussi savrer utile de prendre en charge des donnes image (ou autres formats binaires) dans loptique de les faire transiter par ce biais : il sagit par exemple de scans de factures ou de bordereaux de livraison.
27
c.
Prise en charge de diffrents protocoles de communication et de formats de donnes Le Data Integration Hub doit tre capable de communiquer, en lecture comme en criture, avec un large panorama de systmes qui utilisent des protocoles daccs diffrents. Le Data Integration Hub peut, grce son architecture, relier des systmes htrognes, mme sils ne sont pas directement compatibles techniquement. Un Data Integration Hub peut sadapter diffrentes sources et protocoles, comme : protocoles natifs de bases de donnes relationnelles (oracle net, Ms sQl server, UdB) odBC services Web Ftp / sFtp tCp/Ip Http e-mails Fichiers plats (de largeur fixe ou dlimits) Fichiers XML Mainframe (fichiers VSAM, IMS, IDMS, Adabas, DB2, etc.) Fichiers non structurs ou semi-structurs (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 donnes scuris Les donnes peuvent tre compresses, mais aussi cryptes ou masques pour garantir la confidentialit. Les changes peuvent aussi tre scuriss laide de couches standards comme ssl.
e.
Gestion de la granularit des units de travail Un data Integration Hub peut transfrer des donnes de faon unitaire (une donne / un enregistrement / un message la fois) comme il peut le faire par blocs (en masse). les deux modes peuvent satisfaire la frquence de transfert des donnes la fois en temps rel et en batch. Ce choix dpend des exigences de la cible en termes de rafrachissement des donnes : pour une application e-commerce, la latence sera beaucoup plus courte que pour un systme dcisionnel. Laccs direct aux systmes source ou cible peut seffectuer en mode connect (directement la base de donnes ou la couche applicative), ou en mode non connect (par lintermdiaire de messages ou de fichiers).
f.
Stockage et transmission les donnes brutes et les donnes pivot peuvent tre conserves dans une zone de stockage persistante ddie, en amont de leur propagation aux systmes cibles, en utilisant des demiinterfaces. Ceci prsente de multiples avantages, comme le fait dassurer un dcouplage des systmes et garantir ainsi leur indpendance respective. et cela permet dauditer ces donnes et, de les retraiter en cas derreur, sans surcharger le systme source.
28
g.
Application des rgles de transformation entre les systmes Il peut exister autant de types de transformations appliquer entre les sources quil existe de systmes cibles diffrents. Les transformations comprennent le dcoupage des donnes, les concatnations, regroupements, jointures, contrles, etc. . le data Integration Hub peut traiter tout type de transformations de donnes par un design graphique, sans une seule ligne de code, quelle que soit la complexit du traitement.
h.
Application de conversions de formats de donnes entre systmes Il ne sagit pas uniquement de transformer des lments des donnes brutes en passant dun systme un autre ; il faut galement convertir le format propre au systme source vers un format pivot (souvent du XML) et ensuite dans le format adquat pour la cible. Par exemple, des donnes sources issues dun mainframe, au format VsaM contenant des enregistrements occurrences multiples et des redfinitions, peuvent facilement tre converties en messages EDI, en un fichier au format personnalis ou en XML. Elles peuvent aussi tre charges directement dans une base de donnes relationnelle ou converties en fichier Excel et envoyes par e-mail. les formats susceptibles dtre grs avec le data Integration Hub sont illimits. et cette conversion intervient au rythme ncessaire aux besoins mtiers.
i.
Capacit propager uniquement les donnes modifies pour des raisons de performance, de sollicitations des ressources matrielles (stockage, serveurs, ), et dimpacts sur les systmes oprationnels, il importe de dplacer et de manipuler uniquement les donnes ncessaires. Ainsi, lextraction complte des donnes sources est inutile dans la plupart des cas : seules les donnes ayant volu depuis la dernire extraction devraient tre considres, cest--dire les donnes cres, modifies ou supprimes depuis la dernire excution du processus dextraction. Ceci se produit surtout avec les sources de type base de donnes relationnelle et les applications comme Siebel, SAP, PeopleSoft, qui nutilisent pas forcment de messages ou de fichiers pour communiquer vers lextrieur de lapplication elle-mme.
Un Data Integration Hub offre plusieurs solutions permettant didentifier les donnes diffrentielles : Prise en charge native de la capture des donnes modifies (Change data Capture). le data Integration Hub peut couter directement les journaux de bases de donnes ou de fichiers (mainframe) et capturer les transactions ds quelles sont appliques. Cette mthode non intrusive nexige aucun dveloppement et na pratiquement aucun impact sur la performance des systmes sources par rapport aux autres mthodes daccs. utilisation dun champ dhorodatage dans chaque table source : ce champ stocke la date / heure de la dernire mise jour. le data Integration Hub rcupre les donnes modifies depuis la dernire extraction en utilisant cet horodatage. utilisation de tables daudit dans le systme source. Certaines applications packages utilisent des tables daudit pour suivre toutes les transactions traites. le data Integration Hub peut parcourir ces tables daudit et extraire les donnes correspondantes aux transactions effectues depuis la dernire extraction.
29
Comparaison dattributs entre deux excutions. Cette solution consiste comparer tout ou partie des attributs entre lexcution prcdente et lexcution en cours. Elle implique de stocker les donnes relatives lexcution prcdente dans une zone persistante. Il est galement possible de seulement stocker temporairement des sommes de contrle calcules sur les attributs (avec les algorithmes CrC32 ou sHa1 par exemple) pour comparer ces dernires au lieu davoir le faire sur lensemble des attributs, ce qui apporte des gains significatifs en termes de stockage et de performance. La comparaison peut tre applique lensemble de lenregistrement ou se limiter certains champs spcifiques.
Il est toutefois possible deffectuer une extraction complte des donnes sources un moment donn et deffectuer une comparaison avec le systme cible avant de charger les donnes ; mais dans ce cas, il convient de prter une attention particulire au volume extrait et limpact correspondant sur la performance des systmes source et cible.
6.1.2 Contrles de qualit et certification des donnes

a. Contrles de qualit basique sur les donnes Un Data Integration Hub permet de contrler que les donnes transmises sont correctes techniquement et fonctionnellement. Les contrles sont effectus : lors de lextraction depuis la source : ces contrles sont alors communs toutes les cibles. Lors de lmission vers les cibles : ces contrles sont alors spcifiques chaque cible.
lobjectif consiste alors ne pas propager de donnes errones ou incompltes dans lensemble du systme dinformation. toute donne suspecte est rejete et ventuellement ligible pour le processus de recyclage automatique. Un Data Integration Hub offre de nombreuses possibilits quant aux contrles appliquer : Contrles de format : date, numro, tlphone, dUns, etc. Contrles dintgrit : par exemple, vrification de lexistence, dans le rfrentiel produits de lentreprise, dun produit list dans une commande. Contrles de rfrences croises : contrle quun code spcifique rcupr, dans une table de rfrences croises (ou table de transcodification), existe rellement dans la cible. Contrles dattributs obligatoires : par exemple, pour une facture, contrle que ladresse dun client est compltement renseigne.
30
Contrles de cohrence entre diffrents attributs dun mme flux : Contrle entre diffrents niveaux hirarchiques : par exemple, il est possible de vrifier que la somme des montants des lignes dune commande est effectivement gale au montant indiqu dans len-tte de la commande ; ou bien, vrification du statut global de la commande par rapport au statut de chacune de ses lignes de commandes. Contrle au mme niveau : par exemple, vrifier que la date de fin de commercialisation est bien renseigne pour un produit qui nest plus commercialis ; ou bien que si une facture reprsente un avoir, son montant est bien ngatif.
Contrle de cohrence inter-applications : par exemple, pour un flux de commandes entrant, vrifier quune commande existe bien dans le systme cible ; ou bien vrification dans un rfrentiel Produit que le produit command tait toujours commercialisable lors de la commande.
b.
Contrles de qualit avancs sur les donnes Les contrles de qualit avancs sur les donnes vont au-del de simples contrles sur des champs ou sur la cohrence dune valeur de rfrence ; ils effectuent galement des transformations pour renforcer la qualit et la cohrence des donnes afin doffrir une meilleure vision des donnes traites. Dans cette optique, les donnes peuvent devenir de vritables informations de valeur pour lentreprise : Standardisation : application de rgles permettant de contrler et de corriger le format et la smantique dune donne. La standardisation garantit quune donne respecte des conventions. Les contrles de smantique sont bass sur lanalyse et le dcoupage des champs ainsi que sur des vrifications effectues dans un dictionnaire de rfrence contenant les valeurs valides ou des synonymes. la standardisation est gnralement ralise en quatre tapes : Analyse syntaxique : les donnes sont analyses et dcoupes en mots. Analyse lexicale : chaque mot est lu et rattach un type lexical correspondant un certain champ lexical. Cette tape est spcifique aux rgles de localisation. Analyse smantique : les mots reconnus sont associs lattribut auquel ils correspondent dans un modle de donnes. Cette tape est spcifique aux rgles de localisation. Rectification : les mots cls sont standardiss par rapport un dictionnaire de correspondances.
Normalisation : une fois les donnes standardises et correspondant une dfinition, la normalisation devient possible. Cette tape vrifie que la valeur dune donne correspond la ralit, en tant valide par un organisme de certification externe : par exemple, vrification dune adresse postale via un fichier Hexapost.
31
Correspondance floue ( fuzzy matching ) : lorsquune correspondance directe est impossible, les donnes entrantes et de rfrence peuvent tre compares approximativement, sur la base dalgorithmes de distance linguistique. Contrle de doublons : par exemple, vrification quun client ou un prospect nest pas rfrenc deux fois. les contrles prcdents sont souvent ncessaires, car il est rare quune correspondance directe soit applicable pour mettre en vidence de tels doublons. Enrichissement : fournit des informations complmentaires pour lenrichissement smantique.
Il importe de noter que ce type de validations de qualit avances peut tre effectu en quelques secondes sans pnaliser les oprations. c. Niveau de qualit de donnes autoris Une fois testes, les donnes sont marques pour que le Data Integration Hub puisse dcider de laction entreprendre. Le marquage peut aussi tre utile dans le cadre du monitoring dactivit de lentreprise (BAM). Trois niveaux de qualit de donnes sont gnralement proposs : Valide : Tous les contrles effectus sont valides. Les donnes correspondantes sont propages vers les cibles. Rejete : Au moins un test bloquant na pas t concluant. Les donnes concernes ne sont pas propages aux cibles pour lesquelles ce contrle revt un caractre obligatoire. Un processus de recyclage de ces donnes peut tre dclench (ce point sera dtaill dans la section suivante). Avertissement : Tous les contrles bloquants ont t vrifis mais au moins un contrle de criticit mineure a t rvl. les donnes sont tout de mme propages aux cibles mais les utilisateurs sont avertis via les fonctions dorchestration du data Integration Hub.
d.
Regroupement des erreurs Pour chacune des donnes, lensemble des contrles de validit sont effectus afin dobtenir une vision consolide de lexhaustivit des erreurs ou avertissements concernant un enregistrement particulier ou un ensemble denregistrements. lobjectif est de ne pas arrter le traitement ds la premire erreur, ce qui conduirait potentiellement rejeter un enregistrement de nombreuses reprises avant que toutes les erreurs possibles soient effectivement identifies et corriges lune aprs lautre. Les donnes du pivot en erreur sont affiches laide dune interface utilisateur graphique native, indiquant toutes les erreurs associes. Un seul coup dil suffit pour prendre connaissance de toutes les erreurs et dfinir un plan daction afin de les corriger (corrections appliquer dans le systme source, mise jour dune table de transcodification, ). L encore, grce ses capacits dorchestration, le data Integration Hub permet aux acteurs les plus appropris, Moe ou Moa, de grer le problme en fonction de sa nature.
32
e.
Vrification de la livraison des donnes et de leur prise en compte par la cible Le but consiste vrifier, chaque tape du flux de donnes, que toutes les donnes sources ont bien t propages aux systmes cibles et correctement intgres ces derniers. Un processus dacquittement en plusieurs phases peut tre ncessaire. Le mcanisme dacquittement peut suivre les tapes ci-dessous. Il peut tre adapt chaque systme cible ou source en fonction de ses contraintes : 1 Une fois les donnes sources extraites et prises en compte dans le data Integration Hub (cest--dire une fois la donne pivot cre), elles sont marques comme transmises avec succs au data Integration Hub. 2 Une fois la donne pivot propage vers une cible, linstance pivot-cible est marque comme transmise la cible. 3 Une fois que les donnes transmises ont t traites et intgres par le systme cible, la cible renvoie des informations indiquant si les donnes ont t correctement intgres ce systme ; la cible peut galement tre interroge pour obtenir cette information. 4 Enfin, une fois que tous les systmes cibles concerns par ce processus dintgration de donnes sont pris en compte, le Data Integration Hub peut notifier le systme source que la transmission a t valide pour toutes les cibles. Le Data Integration Hub conserve une trace des diffrentes tapes et des tats associs, et peut galement enregistrer les valeurs des donnes. Ce mcanisme permet de suivre efficacement la propagation des donnes tape par tape, que la communication soit synchrone ou asynchrone.
f.
Vrification de la conversion des valeurs de transcodification Il sagit de configurer un mcanisme de transcodifications pour la traduction des donnes dune application une autre (tables de rfrences croises ou de transcodification). par exemple, pour la civilit Madame , lapplication a peut utiliser le code Mme , une application cible B le code 1 , et lapplication C le code Ms . dans ce cas, le data Integration Hub utilise une table de rfrences croises qui est capable de dterminer quel code cible correspond un code source spcifique, en fonction des applications source et cible.
6.1.3 Gestion des donnes en rejet

a. Recyclage automatique des donnes en rejet Selon les contrles effectus, la donne peut tre rejete lors du sourcing (i.e. avant la cration du pivot) ou lors de lmission vers les cibles (i.e. aprs la cration du pivot). le recyclage est possible dans ces deux cas : si cela se produit avant le pivot, la donne doit tre r-extraite depuis la source ou depuis la zone de staging : le recyclage concerne toutes les cibles car aucune delle naura reu la donne.
33
si cela se produit aprs le pivot, le recyclage est ralis 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, contrle nouveau les donnes et tente de charger la cible. les rejets ce niveau doivent essentiellement tre causs par des problmes de transcodification ou dintgrit par rapport des rfrentiels : le pivot est considr comme valide. la seule intervention faire consiste mettre jour les tables de transcodification ou les rfrentiels. Le Data Integration Hub permet den alerter automatiquement un utilisateur et met disposition une interface graphique pour effectuer la modification ncessaire.
b.
viter de recycler indfiniment des rejets Il est possible de dfinir un nombre maximum de tentatives pour le recyclage dune donne : si, pour une donne, le nombre de recyclages excde cette limite, la donne est marque comme abandonne. Cet aspect est important pour viter de recycler indfiniment une donne corrompue qui ne pourra jamais tre intgre. Les utilisateurs peuvent tre avertis du rejet et peuvent alors diagnostiquer le problme ou mme modifier les donnes, voire abandonner la donne qui ne sera ainsi plus recycle.
6.1.4 Frquence des flux et orchestration

Le Data Integration Hub comporte une brique ordonnancement. a. Traitement au fil de leau / temps rel Les flux peuvent traiter les donnes sources au fil de leau, en suivant le cycle de vie de la donne dans son application (capture des transactions) ou si lapplication pousse directement la donne (message dans une file, arrive dun fichier, arrive de courrier lectronique, etc.) : ds quune donne est disponible, elle est prise en compte par le Data Integration Hub. Les donnes sont traites soit unitairement (faible volumtrie chaque excution et ne concernant souvent quune transaction) ou massivement (un jeu de donnes allant de plusieurs milliers plusieurs millions de transactions). b. Traitement par lot Les flux peuvent tre excuts selon des frquences prdfinies, par exemple : Une fois par jour Une fois par semaine toutes les 1/4 heures entre 8h et 20h.
Les donnes sont ensuite traites par blocs : le volume concern peut tre faible (quelques enregistrements) ou trs importante (des millions denregistrements). Le mode batch est frquemment utilis lorsque les applications ne sont pas en mesure de publier leurs transactions en temps rel, lorsque le processus de synchronisation ne ncessite pas dtre immdiat pour lactivit mtier concerne ou lorsque les applications cibles ncessitent des calculs ou des agrgations mettant en jeu dimportants jeux de donnes, avant de pouvoir tre charges. De plus, ces calculs doivent souvent accder aux donnes de plusieurs sources pour appliquer les rgles requises. Le mode batch est galement utilis pour initialiser une cible en premire excution, lorsque les applications nont jamais t synchronises auparavant.
34
c.
Adaptation de la frquence en fonction des besoins de chaque cible Pour un flux donn, la latence exige peut tre diffrente dune cible lautre. Le Data Integration Hub permet de dfinir des frquences dalimentation propres chaque cible. Il peut lire la source une seule fois et propager les donnes vers plusieurs cibles diffrentes frquences en fonction des contraintes de chaque cible. Cela permet galement de grer le cas o les donnes en zone tampon doivent tre compltes par dautres processus avant de pouvoir les transmettre. Le systme source est ici le facteur limitant : la latence minimale dun flux correspond la frquence maximale possible sur cette source. Plus particulirement, lorsquun systme source ne peut fournir les donnes en temps voulu, il est impossible dalimenter les cibles en temps voulu.
6.1.5 Paramtrage / configuration

Le Data Integration Hub offre une interface graphique dadministration pour faciliter la configuration et les rglages spcifiques. a. Pilotage de lalimentation des cibles au sein du data Integration Hub, il est possible de dsactiver ou ractiver une cible pour un flux. En effet, pour certaines raisons lies au cycle de vie dune application (phases de maintenance), il est envisageable quune application cible soit momentanment indisponible. Cette fonction permet de dsactiver temporairement lapplication concerne, tout en conservant dans un statut en attente les donnes ligibles pour cette cible : une fois la cible ractive, les donnes en attente sont traites dans leur ordre de cration dans le data Integration Hub et envoyes la cible. toute perte de donnes est ainsi vite. la dsactivation ou lactivation dune cible peut se faire par anticipation en paramtrant la date de dbut du nouvel tat. b. Paramtrage de la dure de rtention pour des raisons de performance, et pour viter toute consommation inutile de stockage, il peut savrer utile de supprimer rgulirement les donnes pivot. De la mme manire, les statistiques et les journaux de chaque flux peuvent tre conservs pendant un certain temps. Ces processus de nettoyage peuvent tre lancs intervalles rguliers (chaque mois par exemple) pour supprimer les donnes pivot, les statistiques et les logs crs sur une priode donne. La frquence de la purge peut tre paramtre individuellement pour chaque flux. La dure de rtention des statistiques et des donnes de log peut tre suprieure ou gale celle des donnes pivot. c. Gestion des rfrences croises Cette fonction consiste effectuer une mise jour des tables de rfrence par lintermdiaire dune interface graphique, fournie par le Data Integration Hub.
35
d.
Rglages gnraux Lutilisation dun framework (maintenu via une IHM) permet de maintenir les paramtres de flux comme : les paramtres de connexion pour les bases de donnes Les chemins daccs et noms des fichiers sources et cibles Les chemins daccs et nom des fichiers logs les paramtres Ftp les destinataires des mails dalerte les valeurs par dfaut de certains attributs.
Ce framework permet galement de gnrer automatiquement et de manire centralise tous paramtres utiles aux flux du Data Integration Hub. e. Abandon des donnes corrompues Le Data Integration Hub permet de modifier le statut de donnes pralablement rejetes afin quelles ne soient pas recycles. Ltat dune instance {donne - cible} est pass au statut Abandonn. Ce rglage peut tre appliqu une cible spcifique ou toutes les cibles concernes par une donne abandonne. Cette fonction sert viter que les rejets ne soient perptuellement recycls sil est avr quils ne peuvent pas tre intgrs une cible donne. f. Rejeu des donnes le data Integration Hub permet de renvoyer des donnes dj transmises. ltat dune instance {donne - cible} est pass au statut A rmettre. Cette fonction est intressante lorsque des donnes ont t supprimes par erreur dans une cible ou lorsque des erreurs dans lapplication cible ont corrompu les donnes, exigeant quelles soient de nouveau rcupres. g. Rextraction depuis la source Il est possible de rejouer lextraction de tout ou partie des donnes sources : Pour les extractions utilisant un intervalle de date, celui-ci peut tre modifi dans une table de paramtres. pour les extractions utilisant la comparaison dattributs, les enregistrements doivent tre supprims dans la table de pilotage matre. 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 renvoys de la zone tampon vers la file de messages, afin dtre nouveau disponibles en entre du flux.
36
6.1.6 Traabilit et audit

a. Connaissance de lorigine et de la destination des donnes Cette fonction repose sur les mtadonnes du Data Integration Hub ainsi que sur les mtadonnes des diffrentes sources. Il est toutefois possible de suivre les donnes en utilisant la zone tampon qui maintient les donnes au format canonique et ventuellement au format brut sil a t mis en place. b. Livraison finale et acquittement de la cible Consultez la section 6.1.2. Contrles de qualit et certification des donnes. c. Trace des tentatives le data Integration Hub conserve une trace de toutes les tentatives : dextraction dun systme source. de livraison un systme cible. de recyclage.
partir de ces traces, des indicateurs peuvent tre calculs pour amliorer la connaissance des mouvements de donnes entre applications. d. Surveillance des transformations des donnes Pour un flux de donnes spcifique, il peut savrer intressant de connatre : Combien dobjets ont t transfrs sur diffrentes priodes ? Combien de rejets ont t gnrs ? Quelles sont les erreurs les plus frquentes ? Quelle est la dure moyenne dun flux de donnes en fonction du volume source ? Combien de fois une donne a t mise jour pendant une priode donne (par exemple, combien de fois le systme de rfrence produit a envoy des mises jour pour un produit donn) ?
Ces indicateurs peuvent tre bass sur les mtadonnes du data Integration Hub ou sur des traces spcifiques labores chaque excution. Ces indicateurs offrent une visibilit sur la qualit des transferts et sur la performance des flux. Il est possible de calculer des mtriques de Qualit de Service, qui peuvent tre exiges par un systme cible. Ces indicateurs peuvent aussi servir llaboration de prcieux lments en vue dtablir un Capacity planning, cest--dire une analyse prvisionnelle de la croissance des volumes de donnes.
37
e.
Rcupration sur erreurs techniques Nous avons dj prsent les contrles de validation comme un moyen pour valuer la qualit des donnes entrantes. Ici, il sagit de tracer les ventuels plantages qui peuvent subvenir dans le cycle de vie dun flux : manque de capacit de stockage sur le disque, connexion indisponible vers un systme source ou cible, problme rseau, etc. Ces types derreur peuvent tre reprs par le Data Integration Hub et conservs dans une table derreurs techniques, afin dlaborer des indicateurs sur la nature et la frquence de ces erreurs.
f.
Zone de stockage des donnes brutes pour les besoins de suivi, de recyclage et de diagnostic, il peut savrer trs utile de conserver les donnes brutes (sans aucune transformation) pendant un certain temps. toutefois, ce stockage temporaire peut entraner des cots de stockage supplmentaires ou rallonger la dure des traitements, en particulier lorsque les cibles subissent des sollicitations pousses en mise jour de donnes. la mise en uvre de ce stockage intermdiaire doit donc tre soigneusement tudie en fonction de la capacit de la source renvoyer les donnes en cas de problme.
6.1.7 Surveillance - rapports

le data Integration Hub fournit une IHM pour les rapports. a. Restitution des statistiques Les diffrents indicateurs peuvent tre regroups en tableaux de bord permettant le contrle de qualit dans les flux de donnes, en rapportant et en signalant les vnements importants. Ces rapports peuvent galement servir doutils de communication pour prouver la conformit aux exigences de Qualit de service. Alertes destination de ladministrateur En cas dchec sur lexcution dun flux, le Data Integration Hub peut envoyer une liste dinterlocuteurs une alerte par e-mail indiquant lerreur et le fichier log correspondant. Dautres mails dalerte peuvent aussi tre envoys une autre liste de diffusion (utilisateurs par exemple) pour indiquer que certaines donnes ne sont pas disponibles dans telle ou telle cible. Les deux listes de diffusion sont indpendantes lune de lautre, sont paramtrables et dfinies pour chaque flux, voire pour chaque cible au sein dun mme flux. c. Alerte sur vnement Le Data Integration Hub permet de dfinir une alerte par e-mail dclenche et envoye en fonction de diffrents critres, par exemple le nombre de rejets pour une cible donne.
b.
38
d.
Fourniture dun rcapitulatif quotidien La brique de reporting du Data Integration Hub peut diffuser quotidiennement (frquence personnaliser) des rapports de synthse sur la surveillance des flux. Les rapports peuvent inclure les lments suivants : Le flux a-t-il t excut ? nombre dexcutions tat des excutions Volume trait dure de traitement nombre de rejets etc.
les rapports sont disponibles via une application web ou envoys 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 dvaluer aisment, flux par flux, la fiabilit du Data Integration Hub. b. Garantie dabsence de perte des donnes Le mcanisme dacquittement au niveau de la source et/ou dans le Data Integration Hub permet de vrifier la bonne transmission une cible et la bonne prise en compte de la donne. Les donnes non transfres sont aisment identifiables. c. Garantie dabsence de duplication des donnes les donnes susceptibles de constituer des doublons (par exemple, des interlocuteurs) peuvent tre captes par des outils de Qualit de donnes ou de rsolution dIdentit. Lorsque des doublons sont dtects, deux options sont possibles : rejeter les deux occurrences pour une analyse plus approfondie et leur correction dans le systme source. envoyer une demande darbitrage un utilisateur par lintermdiaire de la couche dorchestration du data Integration Hub.
d.
Permettre le rejeu dun flux aprs une erreur Dans le Data Integration Hub, des points de reprise peuvent tre dfinis sur les flux. Suite un plantage, les traitements peuvent tre relancs partir du dernier point de reprise valid. ainsi, il est inutile de relancer lintgralit du flux de donnes.
39
e.
Gestion du bon ordre des messages Le Data Intgration Hub garantit que les messages sont traits dans lordre chronologique correct. Par exemple, pour une commande donne, il peut arriver que le premier message (cration de la commande) soit envoy 15h30 et quun deuxime message (mise jour) soit envoy 15h35. Si lexcution du flux de donnes est paramtre pour un lancement tous les quarts dheure, la file de messages contient deux messages pour la prochaine excution. Le message envoy 15h30 est bien trait par le data Integration Hub avant le message envoy 15h35. ainsi, le systme cible aura bien la version la plus rcente de la commande.
f.
Garantie dune performance optimale Le Data Integration Hub offre des possibilits de partitionnement et de paralllisme ainsi que de grid Computing pour permettre une volution linaire de la scalabilit en cas daugmentation du volume de donnes. Garantie de haute disponibilit et dune capacit de reprise dactivit leve suivant les besoins en termes de disponibilit, larchitecture du data Integration Hub peut tre rpartie sur plusieurs nuds : un nud principal et un ou plusieurs nuds de sauvegarde peuvent tre utiliss au sein du grid pour de meilleures performances ainsi que pour prendre en charge la bascule et la reprise chaud en cas darrt brutal du nud principal.
g.
6.2 ARCHITECTuRE Du DATA INTEGRATION HuB

Sources internes et/ou externes IHM Cibles internes et / ou externes
Gestion Rfrentiel Paramtres des ux Supervision Etc...
Applications Importation
Hub
Transformation Orchestration et processus manuels Exportation
Applications
Base de donnes
Tables tampons Rfrentiel
Base de donnes
JMS / MQ
Donnes du Hub
JMS / MQ Fichiers plats
Fichiers plats
XML
Native / ODBC ETL / EAI
Donnes Statistiques
Native / ODBC
Paramtres
XML
XML
WORD PDF EXCEL
Base de donnes du Hub ---------------PDF
XML
WORD
Service Web
Donnes non structures Acquittement
Alimentation unitaire
Temps Rel
Lot
Service Web
EXCEL
Donnes non structures Acquittement
Mainframe
Mail
Mainframe
Figure 10: architecture du data Integration Hub IntgratIon de donnes opratIonnelle
40
le cur du data Integration Hub est bas sur Informatica power Center real-time edition pour la partie intgration de donnes, ainsi quune base de donnes relationnelle associe qui constitue le Hub en tant que tel.
6.2.1 La dynamique dintgration de donnes

Informatica power Center real-time edition est un moteur de transformation de donnes guid par les mtadonnes qui met disposition : La cration graphique de flux de transformation de donnes Un rfrentiel de mtadonnes permettant de stocker tous les dveloppements autour des donnes et de leur transformation le traitement des donnes en temps rel et en masse Des capacits de transformation de donnes, des plus basiques aux plus complexes La connectivit avec les fichiers plats, XML et des bases de donnes relationnelles la capture de transactions partir des journaux rdBMs La possibilit de consommer et de propager des lments de files de messages la fourniture et la consommation de services Web Une console dadministration Web Une interface Web de gestion des tables de rfrence ou transcodification lorchestration des services Web avec BpMl Un ordonnanceur intgr le partitionnement et le paralllisme des traitements pour assurer la scalabilit en termes de performance le traitement tolrance aux pannes.
6.2.2 Les zones de stockage du Hub

la base de donnes relationnelle utilise comme Hub permet de stocker les lments suivants : donnes pivot Journalisation des tentatives Journalisation des erreurs donnes brutes en entre tables de rfrences croises.
41
Staging
Donnes de rfrence
Noyau du Hub
Statistiques
Paramtres
Figure 11: stockage au sein du data Integration Hub
Le Hub est divis en quatre domaines logiques, offrant des zones de stockage pour les donnes persistantes et la gestion du paramtrage et de la configuration du Data Integration Hub : Zone de staging : ce domaine stocke les donnes sources non transformes (telles quelles). Il se compose dune zone permettant de recycler les donnes en cas de problme pendant la cration des donnes pivot (sans ncessiter une r-extraction depuis le systme source) ou pour identifier les modifications apportes au systme source (par comparaison des attributs). Cette zone peut tre facultative, en fonction de la stratgie de recyclage ou de la latence souhaite. Mais, si les donnes brutes ne sont pas stockes, la source doit pouvoir dlivrer nouveau les mmes donnes en cas de reprise afin de les retraiter. Zone noyau du Hub : ce domaine reprsente le cur du systme du Data Integration Hub ; quatre tables principales grent lensemble du Data Integration Hub : Table des donnes pivot (avec un type de champ CLOB ou XML) : stocke les attributs fonctionnels cls des donnes pivot, permettant den tirer des statistiques ; par exemple, pour un flux traitant les commandes : le type de commande, le numro de rfrence, les donnes de commande et le montant global de la commande peuvent tre dfinis en tant quattributs cls pour gnrer des rapports sur ces lments. Table de donnes binaires (utilisant un champ de type BloB) : par exemple, si limage scanne dune facture doit tre transmise dune application vers une autre (par ex. une application de gestion de Contenu dentreprise...).
42
Table derreurs : conserve une trace des erreurs fonctionnelles et techniques pendant la cration des donnes pivot (contrles globaux) ou pendant la diffusion vers les cibles (contrles spcifiques chaque cible). Table des donnes pivot sortantes et de recyclage : par exemple, lorsquune donne pivot doit tre propage vers les cibles a, B et C, cette table contient 3 enregistrements pointant vers la donne pivot : un par cible. Ils reprsentent une instance de donne pivot. Un chargement indpendant entre les 3 cibles est ainsi assur. En effet, la donne pivot peut tre correctement charge dans les cibles A et C, mais rejete par la cible B (en cas de rfrence croise manquante, par exemple). dans ce cas, seule linstance correspondant la cible B est recycle. le pivot nest pas dupliqu ; il sagit de pointeurs qui rfrencent une seule instance physique de la donne pivot pour limiter le stockage.
Zone des donnes de rfrence : ce domaine inclut : les tables de rfrence pour les contrles de validit sur des valeurs de rfrence ou des codifications. Des tables de rfrences croises (ou tables de transcodifications) destines grer plusieurs traductions de codes en fonction des applications.
Zone de paramtrage : ce domaine est ddi aux paramtres du data Integration Hub et inclut en particulier : Un framework de paramtrage des flux (en particulier pour les paramtres de connexions sources et cibles). ladministration du chargement de la cible (activation ou dsactivation dune cible). Rglage de la dure de rtention des donnes pour chaque flux. Nombre maximal de nouvelles tentatives pour une donne rejete pour chaque flux. Paramtrage des dates dextraction des sources, permettant didentifier les donnes en diffrentiel depuis la dernire mise jour ou une table daudit.
Zone de statistiques : ce domaine contient des tables de suivi de toutes les tentatives dexcution (extractions, chargement, recyclage) des fins statistiques.
43
6.2.3 Autres modules importants du Data Integration Hub

Certaines autres fonctionnalits du data Integration Hub sont prises en charge par les outils suivants : reference table Manager (rtM) RTM est une interface utilisateur graphique, prte lemploi, offrant un accs en lecture et criture des tables dune base de donnes. Il permet de maintenir facilement les tables des domaines Zone de paramtrage et Zone des donnes de rfrence.
Cet outil permet de saffranchir de dvelopper (en java par exemple) une IHM spcifique pour maintenir ces tables. Cet outil permet galement dimporter et exporter les tables via des fichiers plats. Cet outil permet encore de visualiser et de faire un suivi des modifications (module audit trail).
Figure 12 : IHM de mise jour des tables de rfrence
Informatica PowerExchange : Cette option permet dtendre le panel de connectivit de powerCenter, mais aussi den faciliter lutilisation. Il sagit dune interface utilisateur unifie destine simplifier la complexit sous-jacente de nimporte quelle source, quil sagisse dun fichier, dun RDBMS, dune application ou de donnes mainframe. Elle offre une vue tabulaire des donnes de toute nature. Elle prend galement en charge les systmes de file de messages (WebSphere MQ, JMS, tibco ...), la connectivit avec des services Web, la connectivit Http, Https, Ftp, Ftps, etc. Elle intgre en sus une option de Change Data Capture (permettant didentifier automatiquement les donnes modifies dans les sources) et des accs en mode bulk (pour les volumes de donnes importants). powerexchange permet galement dassurer des transferts inter-applications scuriss (possibilit de configurer des communications SSL ou de crypter les donnes transfres.)
44
Data quality : Lobjectif de ce module consiste valuer et amliorer la qualit des donnes gres par le data Integration Hub. Il permet : de mesurer la qualit des donnes (par lintermdiaire de tableaux de bord et de rapports) selon les critres suivants : Compltude : identification des donnes incompltes ou inutilisables. Conformit : identification des donnes malformes (de format incorrect). Cohrence : identification des donnes contenant des informations conflictuelles. Exactitude : identification des donnes inexactes ou primes. Doublons : identification des doublons. Intgrit : identification des donnes manquantes ou non rfrences. Il est possible de crer nimporte quel autre critre personnalis.
de nettoyer, standardiser, amliorer, associer, d-doublonner et consolider les donnes. de normaliser et valider les adresses : utilisation dun outil certifi par des fournisseurs de validation dadresses, livr en version oeM avec Informatica data Quality. Contrle de latteinte dun seuil dacceptation de la qualit des donnes. Rutilisation et industrialisation des rgles de qualit des donnes.
le module data Quality sintgre parfaitement power Center. Cet outil peut donc savrer trs utile pour mettre en place des contrles complexes sur les donnes.
45
Data Integration
Data Flows (PowerCenter Mappings)
b a d e
B2B Data Transformation

X -> Y
Data Quality
? -> Z
Data Quality Assistant
Orchestration
Control Flows (BPEL)
2 1 3 4 5 6
Human Decision
Figure 13: principe de lorchestration (1/2)
Control Flow (Orchestration)

Invoke
Results
Invoke
Invoke
Data Flow (PowerCenter Mapping)

SQ
products (Micros oft SQL Server) SQ_products DQ_P_Standardi zelProducts mpit_MatchPro duct
f(x)
Dgi_generateD QAFields
product_master( Oracle)
Figure 14: principe de lorchestration (2/2)
46
Orchestration : Ce composant bas sur un standard BPML et offrant une interface BPM autorise tous les ordonnancements de tches de services Web, dalertes par e-mail et des interventions humaines dans un flux (par exemple, si un utilisateur doit vrifier ou corriger les valeurs avant le chargement de la cible, ou prendre une dcision en cas dtection de doublon potentiel).
Data Analyzer : Il sagit de lIHM de reporting du data Integration Hub. Il fournit des rapports prdfinis bass sur les mtadonnes PowerCenter, notamment des rapports sur les traitements, leurs dures, les volumes traits etc. Il fournit des tableaux de bord pour obtenir une vue globale des indicateurs cls concernant le fonctionnement ou le design des flux du Data Integration Hub, ainsi que certains rapports dtaills (par ex. dtails historiques de la dure de traitement et du nombre de lignes traites pour un flux donn). data analyzer permet galement la gestion des alertes par e-mail, en envoyant un message en cas : dchec dun traitement, datteinte ou dpassement dun seuil danomalie, dabsence dexcution dun traitement une date spcifique, etc.
Data Analyzer peut diffuser les tableaux de bord et les rapports rgulirement ou ds quun vnement important se produit dans le traitement des donnes. Metadata Manager : Metadata Manager permet un suivi en amont et en aval du Hub, afin de connatre lorigine des donnes, leur destination et toutes les rgles de transformation qui leur ont t appliques. Cet outil intgre tous les composants dun projet dintgration de donnes, et donc en particulier du data Integration Hub, savoir : Modlisation des donnes rapports transformations stockage glossaire mtier.
Il sera utile pour raliser un audit des donnes bas sur les mtadonnes et pour simplifier les tudes danalyse dimpact dans le cas dvolutions des besoins mtiers.
47
6.3 CONCEPTION Du DATA INTEGRATION HuB

Dans le data integration hub, un flux complet depuis la source jusquaux cibles est divis en demiflux. Demi-flux entrant : du systme source au format pivot (stock dans la zone du Hub). Demi-flux sortant : du format pivot une cible (une demi-interface par instance cible).
Cible 1
t sor ant 1
De
Demi-ux entrant
x i-u
Source
Demi-ux sortant 2
Cible 2
Data Integration Hub
De
mi-
xs ort
an
tN
Cible N
Figure 15: Un flux DIH = 1 demi-flux entrant et N demi-flux sortants
Hub
Phase 0
Recyclage
Source(s)
Extraction des donnes
Dtection derreur Phase 1
Cible 1
Contrles dintgrit
Autres contrles
Cible 2
Phase 1
Staging
Cration de pivot XML
Pivot XML
Contrles Transcriptions Transformations
Phase 2 derreur Phase 2

Dtection
Diusion des donnes vers les cibles
Cible N
Transcriptions
Transformations
Figure 16: Vue globale de toutes les phases dun flux complet, de la source aux cibles
48
6.3.1 Demi-flux entrant :

De nombreux scnarios sont possibles en termes de choix dimplmentation pour le demi-flux entrant, en fonction de la nature des donnes (de rfrence ou de transaction), de leur volume et de la volatilit des donnes sources (messages transactionnels ou donnes batch). Un demi-flux entrant peut contenir les fonctionnalits ou tapes suivantes, qui peuvent savrer obligatoires ou non :
tape n 1 2 3 4
description extraction des donnes sources (extraction ou directement fournies par la source) stockage dans une zone persistante (zone de staging) Cration du pivot recyclage des donnes rejetes (donnes pour lesquelles la cration de pivot est impossible en raison de contrles non vrifis). Acquittement vers le systme source
Facultative / obligatoire obligatoire Facultative obligatoire Facultative
Facultative
tape 1 tape 4 Extraction de donnes Recyclage Dtection derreur Phase 1
Source
Contrles dintgrit
Autres contrles
tape 2 Stockage en xone persistante
tape 3
Staging Area
Creation du pivot XML
Pivot XML
Transcriptions
Transformations
Figure 17: Vue dtaille dun demi-flux entrant type
6.3.1.1 Etape 1 : Extraction trois cas peuvent tre envisags pour lextraction des donnes sources : Cas 1 : Mises jour de donnes envoyes par le systme source. Cas 2 : Mises jour de donnes dtectes par le data Integration Hub. Cas 3 : pas de dtection de mises jour de donnes (mode full ).
49
Cas 1.1 1.2
option possible La source envoie des messages (MQ ou JMS par exemple) chaque fois quun objet est cr, modifi ou valid dans la source. La source envoie ou fournit un fichier dans un rpertoire en entre du data Integration Hub. la source alimente des tables dinterface (la plupart du temps stockes dans lapplication source mme) ne contenant que les crations, modifications ou suppressions depuis la dernire excution. 1.3 la purge de ces tables dinterface est gre par le systme source, en fonction de lacquittement envoy par le Data Integration Hub une fois toutes les donnes traites. les enregistrements ne sont ainsi supprims que si le Data Integration Hub les a pris en compte correctement. les donnes source peuvent tre extraites avec le mcanisme de Change data Capture (CdC) fourni par le data Integration Hub. les transactions de la base de donnes sont journalises et le mcanisme CdC capture les transactions dans le journal pour les traiter. Chaque table source contient un champ avec lhorodatage des dernires modifications de lenregistrement. Les donnes diffrentielles sont ensuite identifies par le Data Integration Hub, en comparant cet horodatage avec la dernire date dextraction stocke dans le data Integration Hub. tous les enregistrements crs ou modifis aprs la dernire mise jour sont ligibles. La source contient des tables daudit qui conservent une trace de tous les vnements se produisant sur les donnes : chaque cration, mise jour ou suppression est suivie de bout en bout dans ces tables daudit, avec lhorodatage de lvnement. Les donnes diffrentielles sont ensuite identifies par le Data Integration Hub, en comparant cet horodatage avec la dernire date dextraction stocke dans le data Integration Hub : tous les enregistrements crs ou modifis aprs cette date sont ligibles (via un rapprochement entre la table daudit et la table source). la source ne prsente aucun des cas prcdents, en dautres termes : la source est incapable de fournir les donnes mises jour. loption de Change data Capture nest pas utilisable avec cette source. La source ne possde pas de champ dhorodatage indiquant la date de la dernire mise jour de lenregistrement, ni de table daudit.
Cas 1 envoi des donnes mises jour
2.1
2.2
Cas 2 extraction des donnes mises jour
2.3
2.4
Mme dans ce cas, le data Integration Hub peut dtecter les modifications entre deux excutions. Cette mthode implique dutiliser une zone persistante (zone de Staging) qui stocke les valeurs des attributs de lexcution prcdente.
50
Cas
option possible principe : Cette solution consiste identifier les donnes sources ayant volu depuis la dernire extraction : pour les donnes considres, cette identification est ralise en comparant les valeurs des attributs entre lextraction prcdente (stocke dans la zone de staging) et lextraction en cours (stocke dans la source). Quatre cas sont gnralement tests : les donnes existent dans la source, mais pas dans la zone de staging : il sagit alors dune cration. les donnes existent dans la zone de staging, mais pas dans la source : il sagit alors dune suppression. les donnes existent dans la source et dans la zone de Staging et au moins lun des attributs est diffrent ; cela signifie que les donnes ont t modifies depuis la dernire excution. les donnes existent dans la source et dans la zone de Staging et tous les attributs demeurent inchangs ; cela signifie que les donnes nont pas t modifies depuis la dernire excution.
seuls les trois premiers cas sont ligibles pour le dclenchement de lextraction des donnes source. pour optimiser la comparaison des attributs, la solution consiste calculer une somme de contrle sur ces attributs (par exemple laide des algorithmes CRC32 ou SHA1) puis comparer uniquement la valeur de la somme de contrle des attributs source avec celle stocke dans la zone de staging. Il est inutile de comparer tous les attributs dune donne, ceux qui sont significatifs pour les applications cibles suffisent. la mise en uvre de cette solution doit tre ralise sur des sources de taille limite car elle peut savrer consommatrice en espace disque et en temps de traitement. Les donnes sources sont intgralement transfres sans diffrencier les enregistrements modifis et inchangs. Ce cas doit tre utilis avec prcaution : Cas 3 pas de dtection de mise jour des donnes 3.1 Volume trs limit. Implmentation dun mcanisme de recyclage impossible. pas de zone persistante. La conservation du pivot est limite quelques jours, par rapport une dure de lordre de quelques mois pour les autres types de flux. les donnes sont charges en mode truncate / Insert dans chaque cible concerne. Chargement initial ou sauvegarde complte.
51
pour des raisons de performance et pour matriser la volumtrie globale des donnes du data Integration Hub, les modes diffrentiels sont privilgier (cas 1 et 2). La description de flux suivante constitue un exemple reprsentatif dextraction de message MQ stocker dans la zone de staging : Sous-tape 1.1 : extraction du contenu de la file dattente et enregistrement du message sans transformation. Cette sauvegarde sert recycler le message sans avoir raliser de nouvelle extraction depuis la source. Remarque : Un systme de file dattente comporte galement un mcanisme de persistance, que nous pourrions tre tents dutiliser dans ce but. Mais il est prfrable de lviter. le mcanisme de persistance de la file de messages est principalement utilis pour garantir la possibilit de rcupration lors dun transfert dun message sur le rseau, ou dans lattente de sa consommation par tous ses abonns. la persistance ne dure pas longtemps. si un trop grand nombre de messages taient prsents dans la file dattente, cette dernire pourrait littralement exploser . Ds quun message de la file dattente est entirement consomm, il en est supprim afin de ne pas le prendre de nouveau en compte lors de lexcution suivante.
Lecture de la le MQ
Stockage du message sans transformation
MQ
MQ_REF_PRO DUCT (MQSerie s)
SQ
DIH_STA_MES SAGE_BRUT (O RACLE)
SQ_MQ_REF_P RODUCT
Figure 18 : Mapping de sauvegarde dun message depuis une file MQ Series
Sous-tape 1.2 : extraction de la file dattente et stockage dans la zone de staging :
MQ
MQ_REF_PRODUC T (MQSeries)
SQ
Dcoupage du message
SQ_MQ_REF_PRO DUCT
SQ
MQ_Message_Re ad (Flat File) SQ_MQ_File_re ad
f(x)
EXP_SPLIT DIH_STA_REF_P RODUCT (Oracle)
Lecture du message
Stockage du message dcoup dans la zone de staging
Figure 19 : Mapping type dextraction dun message depuis une file MQ Series IntgratIon de donnes opratIonnelle
52
6.3.1.2 tape 2 : Zone de persistance Cette tape stocke les donnes extraites dans la zone de Staging qui constitue une zone persistante. Cette zone persistante permet de conserver les donnes brutes (sans aucune transformation) pendant une dure variable. Lutilisation dune zone persistante nest pas systmatique, et est mme inutile lorsque le mode full est employ (cas 3.1). le stockage des donnes brutes dans la zone persistante prsente les avantages suivants : diagnostic : facilite le diagnostic en cas de rejet pendant la cration des donnes pivot. En effet, les donnes tant stockes au format brut (sans aucune transformation), la visualisation des donnes en cause ne ncessite pas de connexion lapplication source. les donnes brutes et les erreurs associes peuvent tre visualises avec une IHM centralise. recyclage : le recyclage des donnes rejetes pendant la cration des donnes pivot est facilit. En effet, selon le type dextraction, la source nest pas avise du rejet de donnes spcifiques dans le Data Integration Hub. Par consquent, lors de lexcution suivante, les donnes prcdemment rejetes ne sont pas resoumises moins davoir t modifies. Ce principe ne concerne pas les cas 1.2, 2.4 et 3.1.
Cas spcial du recyclage pour les files de messages : le stockage du message brut dans la zone de staging permet den visualiser plus facilement le contenu. Il est normalement visible dans la file de messages, mais peut dans certains cas tre tronqu sil est trop long. Cela permet galement de renvoyer directement un message qui aurait t rejet pendant la cration des donnes pivot en entre de la file de messages source ; le recyclage devient ainsi automatique et vite que le Data Integration Hub ne sollicite le systme source dans le seul but de renvoyer ce message rejet. Bien entendu la file de messages peut conserver le message aprs lecture, endossant ainsi le rle de zone persistante ; il nexiste toutefois aucune mthode pour notifier la file de messages de la lecture dun message spcifique, ce qui oblige supprimer explicitement le message aprs lavoir lu. Une file de messages ne peut pas conserver un trop grand nombre de messages pendant longtemps. Par consquent, une persistance sappuyant sur une base de donnes relationnelle, comme la zone de staging, est prfrable.
53
Identication du message rejet lors de la prcdente cration de Pivot

DIH_STA_MESSA GE_BRUT_upd ( ORACLE)
Mise jour du statut du message pour indiquer son recyclage
DIH_STA_MESSA GE_BRUT (Orac le)
SQ
SQ_Ident_Fail ed_Message DIH_CORE_INST _TRT_upd_stat us (Oracle)
Marquage du message comme recycl
DIH_CORE_INST _TRT (Oracle)
MQ_REF_PRODUC T_ins (MQSeri es)
Renvoi du message rejet vers la le
Figure 20 : Mapping type de recyclage dun message MQ rejet par le dIH
6.3.1.3 tape 3 : Cration du pivot En fonction du choix dimplmenter 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-mme. au cours de cette tape, les actions suivantes sont ralises : Contrles communs toutes les cibles. transformations communes toutes les cibles. gnration des donnes pivot. Instanciation du pivot pour chaque cible.
avant la cration des donnes pivot, une srie de contrles, communs toutes les cibles, est ralise pour vrifier la qualit du pivot et sa capacit alimenter les cibles. selon les rsultats de ces contrles, plusieurs cas peuvent se prsenter : Au moins un des contrles bloquants a chou : le pivot nest pas gnr, la donne dorigine est rejete et lensemble des erreurs expliquant le rejet sont traces. Tous les contrles bloquants sont vrifis et au moins un des contrles non bloquants nest pas vrifi : le pivot est cr, la donne nest pas rejet et lensemble des erreurs constates sont traces. Tous les contrles bloquants et non bloquants sont vrifis : le pivot est cr, la donne nest pas rejete et aucune erreur nest trace.
54
Indication du succs ou de lchec de la cration du Pivot
SQ
DIH_STA_REF_P RODUCT (Oracle) SQ_DIH_STA_RE F_PRODUCT
f(x)
EXP_CTRL
Ecriture des messages derreur
DIH_CORE_PIVO T_ko (Oracle)
KO Contrle des donnes en entre

RTR_CTRL
f(x)
EXP_ERROR NRM_ERROR
<---> <---> <---> <--->
OK
DIH_CORE_ERRO R (Oracle)
f(x)
Branchement du ux en fonction du rsultat des contrles
EXP_TRANSF
GENE_PIVOT_PR ODUCT
DIH_CORE_PIVO T_ok (Oracle)
Generation du pivot XML
Figure 21 : Mapping type de cration du pivot partir de la zone de staging
Linstanciation du pivot pour chaque cible consiste dclarer un pointeur vers lobjet pivot rel pour chaque cible du flux : le pivot devient disponible et indpendant pour chaque cible; cette instanciation est strictement logique ; elle tablit une relation entre chaque instance individuelle de la cible et linstance physique du pivot. Par exemple, pour un flux de Donnes de Contact Client comptant 3 cibles A, B et C, le pivot p est dclar indpendamment 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 frquences propres et avec leurs contrles et protocoles spcifiques. ainsi, lors de lexcution suivante, linstance A du pivot P pourra tre charge correctement dans la cible A ; linstance B rejete en raison de lchec dun contrle de validit propre la cible B ; linstance C en attente de traitement car la cible C attend les mises jour une frquence hebdomadaire et non quotidienne. Lexemple qui prcde peut tre schmatis comme suit :
Aprs le demi-ux entrant:
Table pilotage pivot-cible
Pointeur Pivot - Cible A Stockage des pivots Pointeur Pivot - Cible B Pointeur Pivot - Cible C
Les 3 tuples pivot-cible sont disponibles pour les 3 demi-ux sortants
Figure 22 : Gestion pivot-cible aprs le demi-flux entrant
55
Aprs les demi-ux sortants (run 1): Table pilotage pivot-cible

ok
Cible A
ko
Cible B
ok
Cible C
Pour les cibles A et C, les tuples pivot-cible ont t correctement chargs dans les cibles A et C. Le tuple de la cible B est en chec et automatiquement recycl.
Figure 23 : Gestion pivot-cible aprs le demi-flux sortant (run 1)
Aprs correction de la cause du rejet du tuple pivot-cible et aprs les demi-ux sortants (run 2):
Table pilotage pivot-cible
ok
Cible B
Seul le tuple pivot -cible B a t rejou : toutes les causes de rejet ont t corriges. Le tuple pivot-cible B a t correctement trait et la cible B est alimente avec le pivot.
Figure 24 : Gestion pivot-cible aprs correction et rexcution du demi-flux sortant
56
Liste des cibles concernes par le Pivot
DIH_PARAM_ROU TING_TARGET ( Oracle)
SQ
SQ_Ident_Pivo t_Target
f(x)
EXP_STATUS DIH_CORE_INST _TRT (Oracle)
DIH_CORE_PIVO T (Oracle)
Cration de tous les tuples Pivot - Cible
Figure 25: Mapping type de cration des pointeurs lis un pivot
6.3.1.4 tape 4 : Recyclage des rejets Pour un demi-flux entrant, le recyclage concerne les donnes qui nont pas pu tre transformes en donnes pivot en raison de contrles invalidants. Le recyclage est une tape facultative. Lorsquil nest pas mis en uvre, les donnes sources doivent tre mises nouveau par le systme source. Cela correspond notamment au cas 3.1 des types dextraction ( full ). Si le recyclage est mis en uvre, les donnes initiales rejetes peuvent avoir t modifies entre temps au niveau de la source. dans ce cas, les donnes sources peuvent tre extraites nouveau de la source, ce qui se solde par la prsence de deux instances en entre du demi-flux entrant ; celle qui a t rejete au cours de lexcution prcdente et celle qui a t modifie depuis lexcution prcdente. Ce cas particulier doit tre trait avec prcaution car la cohrence globale des donnes dans toute lapplication peut sen trouver affecte. deux options permettent de grer ce cas : Le rejet est supprim au profit de la nouvelle donne extraite : cette nouvelle donne est cense 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 systme source Cette tape est facultative. Elle consiste notifier la source que la donne a correctement t prise en compte par le Data Integration Hub, cest--dire que le pivot a bien t cr. Pour les sources demandant un acquittement, les donnes non acquittes seront r-extraites lors du prochain traitement, mme si elles nont pas t modifies entre temps. Lacquittement peut tre ralis par un demi-flux sortant dont la cible sera la source elle-mme. Dans ce cas, il sera ncessaire dinstancier le pivot pour la source elle-mme.
57
6.3.2 Demi-flux sortant

Un demi-flux sortant est spcifique une instance de pivot et une cible. Les tapes dun demi-flux sortant sont les suivantes : Facultative / obligatoire obligatoire
tape n 1
description Identification des donnes pivot qui nont pas encore t prises en compte par une cible donne ou qui ont t rejetes au cours de lexcution prcdente traitement du pivot en fonction de la cible. stockage dans une zone persistante (zone de staging). Chargement dans la cible ou mise disposition des donnes pour le systme cible. Acquittement dans le Data Integration Hub.
2 3 4 5
Facultative Facultative obligatoire Facultative
6.3.2.1 tape 1 : Identification des donnes pivot traiter 2 types de pivot doivent tre traits : Ceux qui viennent dtre crs par le demi-flux entrant. Ceux qui ont t rejets au cours de lexcution prcdente en raison dune erreur au niveau des contrles de donnes.
Seules les instances lies la cible mise en jeu dans le demi-flux sont concernes. 6.3.2.2 tape 2 : Traitement du pivot en fonction de la cible Cette tape consiste : Valider les donnes pivot en effectuant les contrles spcifiques la cible. Transformer les donnes pivot en fonction des spcificits de la cible, en particulier des conversions sappuyant sur des tables de transcodification. Formater les donnes du pivot dans la structure attendue par la cible (iDoc SAP, fichier plat avec sparateur, format edI)
Avant de charger la cible, une srie de contrles spcifiques la cible est ralise pour vrifier que cette dernire ne rejettera pas les donnes.
58
selon les rsultats de ces contrles, plusieurs cas peuvent se prsenter : Au moins un des contrles bloquants nest pas vrifi : la cible nest pas alimente, la donne est rejete et lensemble des erreurs expliquant le rejet sont traces. Tous les contrles bloquants sont vrifis et au moins un des contrles non bloquants nest pas vrifi : la cible est alimente, la donne nest pas rejet et lensemble des erreurs constates sont traces. Tous les contrles bloquants et non bloquants sont vrifis : la cible est alimente, la donne nest pas rejete et aucune erreur nest trace.
6.3.2.3 tape 3 : Stockage dans une zone persistante (zone de Staging) dans certains cas, il peut savrer utile de sauvegarder les donnes formates avant de les transmettre la cible. Ce stockage a essentiellement vocation de diagnostic en cas de rejet par la cible malgr les contrles raliss dans les demi-flux entrants et sortants. Elle peut aussi constituer la preuve que les donnes ont bien t transmises la cible. La dure de rtention dans cette zone persistante est configurable. Les donnes sont souvent stockes dans un CloB (texte) ou un Blog (binaire), selon le type de cible. 6.3.2.4 tape 4 : Chargement ou envoi des donnes dans la cible seuls les pivots valids peuvent tre transmis la cible dans la plupart des cas, les cibles ne sont pas charges directement, mais par lintermdiaire de messages, de fichiers plats, de tables dinterface, dappels de fonction internes lapplication ou dappels de services Web. Les diffrents connecteurs PowerExchange peuvent grer tous les types de cible et tous les protocoles. 6.3.2.5 tape 5 : Acquittement dans le Data Integration Hub Pour certaines donnes sensibles, il peut savrer utile de disposer dun mcanisme dacquittement dans le data Integration Hub. Une fois les donnes correctement charges dans la cible, cette dernire transmet un ordre dacquittement sur le DIH pour signifier au DIH que la donne est bien prise en compte. Le modle de flux suivant peut tre utilis pour charger des donnes produits dans la cible A (table sQlserver dans le cas prsent) :
59
Indication de lerreur ou du succs du chargement dans la cible
Modications des donnes conformment au format cible
Table Produits dans la cible A
Lecture du pivot
f(x)
EXP_FORMAT
OK
DIM_PRODUIT ( Microsoft SQL Server)
SQ
DIH_CORE_PIVO T (Oracle) SQ_Pivot_Targ er_to_Treat
<---> <---> <---> <--->
f(x)
EXP_CTRL_TARD ET RTR_CTRL
PARSER_PIVOT REF_PRODUCT
KO
f(x)
Identication des pivots concerns par la cible A Contrles spciques la cible
EXP_ERROR NRM_ERROR DIH_CORE_ERRO R (Oracle)
Figure 26 : Mapping type de demi-flux sortant (cible Base de donnes)
Le modle de flux ci-dessous peut tre utilis pour charger les mmes donnes de produits (issues du mme pivot) dans la cible B (via un message MQ) :
Indication de lerreur ou du succs du chargement dans la cible Modications des donnes conformment au format cible
File de messages MQ pour la cible B
Lecture du pivot
SQ
DIH_CORE_PIVO T (Oracle) SQ_Pivot_Targ er_to_Treat
<---> <---> <---> <--->
f(x)
EXP_CTRL_TARD ET
f(x)
EXP_FORMAT
PARSER_PIVOT REF_PRODUCT
OK
MQ_TargetB_PR ODUCT (MQSeri es)
Identication des pivots concerns par la cible B
Contrles spciques la cible
RTR_CTRL
KO
f(x)
EXP_ERROR NRM_ERROR DIH_CORE_ERRO R (Oracle)
Figure 27 : Mapping type de demi-flux sortant (cible File MQ Series)
60
6.4 BONNES PRATIquES DE MISE EN uVRE Du DATA INTEGRATION HuB

la mise en place dun data Integration Hub doit respecter les tapes suivantes : 1re phase : liste de toutes les fonctionnalits prvues ou requises. 2me phase : inventaire des flux de donnes prvus. 3me phase : configuration de base de donnes du Data Integration Hub, cest--dire installation et configuration des composants communs ncessaires son excution. 4me phase : conception et dploiement des flux de donnes dans le Data Integration Hub.
Liste de toutes les fonctions prvues ou requises
Inventaire des ux de donnes prvus
Installation et conguration de la base du Data Integration Hub
Conception et dploiement des ux de donnes
Figure 28: etapes pour la mise en place dun data Integration Hub
6.4.1 1re phase : Liste de toutes les fonctionnalits prvues ou requises

Cette tape est destine dfinir le primtre dutilisation du Data Integration Hub au sein de lentreprise. plus prcisment, il convient de savoir si le data Integration Hub sera utilis pour synchroniser des systmes de donnes de rfrence (en soutien dun projet de Master data Management), pour automatiser des processus mtiers pilots par les donnes (intgration de processus pilots par les donnes, traitement direct de bout en bout), pour consolider ou regrouper des informations (consolidation de donnes client, consolidation dinstances applicatives, regroupement de documents bureautiques des fins oprationnelles ou statistiques, ou pour alimenter un systme de Gestion de Contenu dEntreprise), pour rpliquer des donnes entre systmes ou pour devenir le composant de services de donnes de lentreprise supportant tous les aspects de manipulation des donnes dans loptique dune stratgie SOA. le data Integration Hub peut excuter toutes ces tches. toutefois, selon le comportement envisag, les diffrents composants ne sont pas tous installs. Un type de projet au moins doit tre choisi en fonction des priorits des besoins mtiers. les autres composants dintgration de donnes peuvent tre installs ultrieurement en fonction des besoins mtiers.
61
Selon les objectifs dfinis pour le Data Integration Hub, cette tape consiste mettre en uvre les fonctions choisies parmi lensemble des fonctionnalits, qui peuvent tre classifies dans les catgories suivantes : 1. 2. 3. 4. 5. 6. 7. 8. transfert de donnes entre systmes. Contrles et certification des donnes. gestion des rejets Configuration et orchestration des flux. Administration / paramtrage / configuration traabilit et audit surveillance - rapports Qualit de service
pour des informations plus dtailles, consultez la section traitant des fonctionnalits du data Integration Hub.
6.4.2 2me phase : Inventaire des flux de donnes prvus

Cette tape consiste tablir la topologie de tous les flux et applications concerns par le Data Integration Hub, ainsi que la feuille de route associe au dploiement des flux. Une estimation des volumes concerns doit tre tablie au cours de cette tape. lobjectif 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 dploiement des diffrents flux.
6.4.3 3me phase : Configuration de la base de donnes du Data Integration Hub

Il sagit de la phase de mise en uvre de la base de donnes du data Integration Hub: Installation des 5 domaines du data Integration Hub : Zone de staging Zone du Hub (obligatoire) Zone des donnes de rfrence Zone de paramtrage et de configuration Zone de statistiques.
selon les fonctions slectionnes au cours de la phase 1, certains de ces domaines ne seront pas utiliss ( lexception de la zone du Hub, qui constitue le composant principal obligatoire du data Integration Hub).
62
Configuration des traitements rcurrents et partags, en particulier : Gestion du recyclage des messages (dans le cas de files de messages comme systmes sources) purge des donnes gestion des cibles Contrles standard : contrles de format (tels que contrles de format de date / heure) ou contrles dintgrit rcurrents (contrles dexistence de rfrences produit par exemple) etc.
IHM graphique de configuration pour les options dadministration des donnes et des flux de donnes, notamment : administration de la gestion des cibles Administration des tables de rfrence (comme les tables de transcodification) Administration des donnes rejetes (avec affichage du dtail des donnes rejetes) Paramtres des flux.
Surveillance / reporting relatif lIHM de configuration. Cela consiste dfinir les tableaux de bord ncessaires la surveillance du data Integration Hub : Suivi des flux suivi des volumes alertes par e-mail
orchestration des tches et des processus humains pour la prise en charge des rsolutions de problme non automatisables Affinage des rgles de qualit des donnes Valeurs de rfrence manquantes retraitement des donnes cibles Rsolution des problmes de qualit des donnes dans le systme source
Ces modules sont configurs en fonction des besoins exprims au cours de la phase 1.
63
6.4.4 4me phase : Conception et dploiement des flux dans le Data Integration Hub
Cette phase doit tre ritre pour chaque nouveau flux de donnes mettre en uvre.
Identication de la source
Identication de la cible
Modlisation du schma du pivot
Dnition des statistiques
Spcications des demi-ux entrants
Spcications des demi-ux sortants
Dpendances avec les autres ux
Dures de rtention des donnes
Identication des donnes de rfrence
Figure 29: Etapes pour la mise en place dun nouveau flux dans le DIH
La mise en place dun flux peut tre dtaille travers les tapes suivantes : 1. Identification des sources : les questions suivantes doivent tre adresses au cours de cette tape O se situent les donnes les plus fiables et les plus fraches ? Ce point est utile pour dterminer le bon choix du systme source. Quel est le format disponible pour les donnes et les attributs extraire ? Ce point est utile pour dterminer les transformations raliser. Quels contrles sont effectus dans le systme source ? Afin dviter de reproduire ces contrles dans le data Integration Hub. Quelle est la frquence de mise jour des donnes sources ? Il est inutile que les cibles soient mises jour plus souvent que la source ne peut le permettre. Les modifications apportes la source sont-elles identifiables, et comment ? Ce point dtermine la conception du demi-flux entrant. Quel est le volume de donnes mises jour en fonction de la frquence de mise jour ? Ce point contribue dimensionner le serveur du data Integration Hub. La source doit-elle obtenir confirmation que les donnes envoyes ont t prises en compte par une cible spcifique ? La rponse dtermine si un mcanisme dacquittement pour la source est ncessaire.
La source peut ne pas fournir lensemble des informations souhaites pour un flux donn, et certaines donnes complmentaires peuvent tre stockes dans dautres systmes sources. Il est alors essentiel de dfinir la source matresse et les sources secondaires. Lutilisation du module de Profiling des donnes du Data Integration Hub est indispensable pendant cette phase, pour lacclrer et garantir une vision complte des formats sources et de lanalyse du contenu. Elle contribue aussi identifier les contrles de qualit des donnes qui ont t effectus la source pour laborer un pivot valide et aider sa constitution.
64
2.
Identification des cibles : les questions suivantes doivent tre adresses au cours de cette tape Quelles cibles doivent tre charges ? Quelles sont les informations prvues ou requises pour chaque cible, et dans quel format ? Quelles sont les contraintes dintgrit ? les rponses dterminent les contrles ncessaires pour que les donnes non valides soient rejetes ds leur arrive dans le Data Integration Hub, au lieu dattendre quelles atteignent la cible, sachant que le data Integration Hub fournit un mcanisme de recyclage des rejets. Quelle latence des donnes pour la mise disposition dans chaque cible ? Ce point dtermine la frquence dexcution du demi-flux sortant et assure son adquation par rapport la frquence dextraction de la source. La cible a-t-elle des priodes dindisponibilit programmes durant lesquelles son alimentation est impossible ? Cette information fait partie de la configuration des cibles. Quel est le processus dacquittement permettant de vrifier que les donnes ont t correctement intgres ?
Il importe de sassurer de la compltude de la dtermination des cibles concernes par un flux, mme lorsquune cible spcifique nest prvue dtre disponible que plusieurs mois aprs le dploiement du flux correspondant. Les besoins futurs doivent tre anticips pour dfinir ds le dbut de ltude une structure pivot stable, qui nvoluera pas chaque changement mineur ou lorsquune nouvelle instance sur les cibles sera ajoute au flux. Comme pour la phase danalyse des sources, le Profiling sur les cibles (avec loption de Profiling du Data Integration Hub) permet dobtenir une vision complte du format et du contenu des donnes, et contribue dterminer le mapping entre les systmes sources et cibles. 3. Identification des donnes de rfrence : certains flux exigent la vrification de lexistence dun attribut de donnes dans une application de rfrence. Par exemple, lorsquune entreprise dispose dun systme de Donnes de Rfrence Client, un flux traitant les commandes vrifie lexistence du client concern dans ce systme de rfrence. Un systme de rfrence peut aussi tre employ pour enrichir un flux par des informations absentes du systme source. Par exemple, le niveau de risque dun client peut tre extrait dun systme secondaire, son adresse dun troisime systme, etc. A lissue des tapes 1, 2 et 3, sont dfinis : Les sources et cibles du flux. les ventuels rfrentiels ncessaires. la liste des informations disponibles dans les sources. La liste des informations attendues pour chaque cible.
65
Loutil de profiling des donnes permet un diagnostic complet et automatique des sources et des cibles. Il peut notamment rpondre aux questions suivantes : disposons-nous des donnes ncessaires pour alimenter toutes les cibles ? La dfinition des donnes correspond-elle aux besoins mtiers pour les flux ? la nature des donnes, dans leur contenu rel et leur prcision, rpond-elle aux besoins mtiers pour les flux ? Les relations entre les lments de donnes sont-elles vrifies pour assurer une intgrit globale au sein dun flux de donnes ? Quelles donnes doivent tre nettoyes ? Quelles donnes doivent tre transformes ? Les donnes sont-elles fiables en termes dexactitude, de cohrence et de stabilit ?
Cet outil peut donc savrer utile pour : Dterminer rapidement la qualit des donnes sources dorigine et dcider ainsi quelle(s) source(s) il convient dutiliser. tablir le format du pivot. tablir les contrles mettre en place au sein du flux pour pallier dventuels dfauts de contrle 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 ds le tout dbut de la conception des flux ; il permet de gagner un temps considrable dans la spcification des flux et dans lamlioration de leur fiabilit. Par exemple, en rduisant le nombre de rejets grce un choix judicieux de la source de donnes et des transformations appliquer. 4. Dtermination du schma du pivot : grce aux informations rcoltes au cours des tapes prcdentes, la structure du pivot peut tre tablie : En termes de contenu, il sagira du cumul de toutes les informations ncessaires pour chacune des cibles. Sachant quil nest pas possible de dfinir un pivot universel, il est ncessaire de connatre au plus tt lensemble des cibles et lexhaustivit des donnes attendues par chaque cible. En termes de structure, il sagira de la structure de la donne dans la source : par exemple, pour une commande, un niveau en-tte et un niveau ligne (1 en-tte pour N lignes) ; pour un rfrentiel fournisseur, un seul niveau.
66
des fins de cohrence et de maintenance, il importe de dfinir un glossaire, qui permettra de crer facilement les balises XML pour le pivot. Informatica fournit un module de glossaire mtier pour faciliter cette tche et garantir que tous les utilisateurs, techniques ou commerciaux, disposent du mme niveau de comprhension. Le schma du pivot est rellement laspect le plus structurant dun flux ; cette tape est donc primordiale pour la bonne implmentation des flux. 5. Dtermination des lments statistiques : Pour un flux donn, il existe 2 niveaux dinformations statistiques : Les informations cls : donnes permettant didentifier de manire unique le contenu du pivot : par exemple, le numro de facture pour un flux de factures ; ou le code EAN dun article pour un flux rfrentiel produit). Les attributs importants : attributs permettant de qualifier le contenu du pivot : par exemple, pour un flux de factures, il pourra sagir de lidentifiant du client, du montant TTC, de la devise et de la date de la facture ; ou pour un flux rfrentiel produit, il pourra sagir du statut du produit et des dates de dbut et de fin de commercialisation.
6.
Spcifications du demi-flux entrant : Lors de cette tape, devront tre dfinis les points suivants : Le scnario du demi-flux entrant : voir privilgier un mode diffrentiel ou un mode message pour grer au mieux la volumtrie transfre. Le type de connexion avec la source La frquence de lancement du demi-flux La rtention : la mise en place ou non dun stockage des donnes brutes dans la staging area. Le mapping entre la source et le pivot, y compris les ventuelles transformations. Les contrles mettre en uvre avant la cration du pivot : il sagit des contrles communs toutes les cibles. Les contrles spcifiques une cible doivent tre positionns dans le demi-flux sortant correspondant. pour les contrles, il faut dterminer la svrit (pour savoir si cela dclenche ou non le rejet de la donne), le message derreur et lventuelle action associe.
67
7.
Spcifications du demi-flux sortant : lors de cette tape, devront tre dfinis les points suivants : Le type de connexion avec la cible. La frquence de lancement du demi-flux. La rtention : la mise en place ou non dun stockage des donnes en staging area avant envoi. Le mapping entre le pivot et la cible, y compris les ventuelles transformations et les transcodifications. Les contrles spcifiques la cible et donc mettre en uvre aprs la cration du pivot. Acquittement : dtermine si un systme cible doit renvoyer une information sur lintgration dfinitive des donnes. Compensation : le traitement des donnes est rparti en plusieurs transactions, qui peuvent tre utiles pour maintenir la cohrence globale des donnes. Par exemple, si les donnes de commande sont prises en compte, le montant de la commande peut tre contrl par rapport la somme de tous les montants des articles de la commande ; ou, si la validation dun utilisateur est requise au niveau du Data Integration Hub, les transactions en attente peuvent tre confirmes ou annules, reliant ainsi lintgration des donnes et lintgration des processus un niveau global.
Cette tape est raliser pour chacune des cibles. 8. Dpendances avec dautres flux : cet aspect est surtout impactant pour les cibles ayant des contraintes dintgrit entre des donnes mises jour par des flux distincts : par exemple, une cible de suivi des stocks sera impacte par les 3 flux suivants : flux rfrentiel produit, flux de commandes et flux de rceptions. Ces 3 flux devront tre lancs dans cet ordre sous peine doccasionner des rejets inutiles. le data Integration Hub, associ son module de gestion des mtadonnes, permet dobtenir ce type dinformations et de comprendre quels sont les impacts en cas de modification dun attribut ou dune rgle.
68
9.
Dures de rtention des donnes : les deux dures de rtention concernent respectivement le pivot et les donnes statistiques. pour des raisons de volumtrie, le pivot peut tre conserv moins longtemps (2 mois par exemple) que les donnes 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 1er temps, laborer un pilote sur un ou deux flux pour bien valider le fonctionnement, les choix des fonctionnalits et les attentes. dans un 2nd temps, crer des flux types (cest--dire des templates) permettant de crer terme des traitements homognes et donc plus facilement maintenables. dans un 3me temps, industrialiser le processus de dploiement.
La complexit dun flux dpend principalement des critres suivants : Complexit de modlisation du pivot : nombre de niveaux hirarchiques, nombre dattributs Volume de donnes exigences en termes de performance nombre et complexit des contrles types des sources types des cibles.
7.
Annexes
69
7.1
TABLE DES FIGuRES
Figure 1: Comportement type dun projet dIntgration de donnes ........................................................................ 08 Figure 2: Dfinition du Juste Temps au-del des considrations de latences techniques ................. 14 Figure 3: Comportement type dun projet de rplication de donnes .................................................................... 15 Figure 4: Comportement type dun projet de synchronisation de donnes......................................................... 17 Figure 5: la synchronisation point point des donnes produit un plat de spaghetti ....................... 19 Figure 6: Comportement type dun projet de data Integration Hub .......................................................................... 20 Figure 7: la synchronisation vue par le data Integration Hub ....................................................................................... 21 Figure 8: Fonctionnalits du data Integration Hub ................................................................................................................. 25 Figure 9: Flux dIH type : routage depuis une source vers 3 cibles ............................................................................. 26 Figure 10: architecture du data Integration Hub..................................................................................................................... 39 Figure 11: stockage au sein du data Integration Hub ......................................................................................................... 41 Figure 12: IHM de mise jour des tables de rfrence ....................................................................................................... 43 Figure 13: principe de lorchestration (1/2)................................................................................................................................. 45 Figure 14: principe de lorchestration (2/2)................................................................................................................................. 45 Figure 15: Un flux DIH = 1 demi-flux entrant et N demi-flux sortants........................................................................ 47 Figure 16: Vue globale de toutes les phases dun flux complet, de la source aux cibles ............................. 47 Figure 17: Vue dtaille dun demi-flux entrant type............................................................................................................. 48 Figure 18: Mapping de sauvegarde dun message depuis une file MQ Series ................................................... 51 Figure 19: Mapping type dextraction dun message depuis une file MQ Series .............................................. 51 Figure 20: Mapping type de recyclage dun message MQ rejet par le dIH......................................................... 53 Figure 21: Mapping type de cration du pivot partir de la zone de staging ..................................................... 54 Figure 22: Gestion pivot-cible aprs le demi-flux entrant ................................................................................................... 54 Figure 23: Gestion pivot-cible aprs le demi-flux sortant (run 1) ................................................................................. 55 Figure 24: Gestion pivot-cible aprs correction et rexcution du demi-flux sortant ..................................... 55 Figure 25: Mapping type de cration des pointeurs lis un pivot ............................................................................ 56 Figure 26: Mapping type de demi-flux sortant (cible Base de donnes) ................................................................ 59 Figure 27: Mapping type de demi-flux sortant (cible File MQ Series) ....................................................................... 59 Figure 28: etapes pour la mise en place dun data Integration Hub.......................................................................... 60 Figure 29: Etapes pour la mise en place dun nouveau flux dans le DIH................................................................. 63
70
71
72
A propos de Logica
Logica Immeuble Cb16, 17 Place Des Reflets, 92097 paris la defense Cedex | France
logica est lentreprise du service en business et technologie. elle runit 39 000 collaborateurs. elle propose conseil en management, intgration de technologies et externalisation ses clients du monde entier, dont les plus grandes entreprises en europe. logica cre de la valeur pour ses clients en intgrant avec succs les hommes, les enjeux business et les technologies. elle sengage dans des collaborations long terme et exploite ses savoirs pour rpondre de faon innovante aux besoins de ses clients. logica est cot la Bourse de Londres et dAmsterdam (LSE : LOG ; Euronext : LOG). Pour plus dinformation : www.logica.com
www.logica.com
Code 1511/0810
aUstralIa / BelgIUM / BraZIl / Canada / CZeCH repUBlIC / denMarK / egYpt / estonIa / FInland / FranCe GERMANY / HONG KONG / HUNGARY / INDIA / INDONESIA / KUWAIT / LUXEMBOURG / MALAYSIA / MOROCCO netHerlands / norWaY / pHIlIppInes / poland / portUgal / rUssIa / saUdI araBIa / sIngapore / sloVaKIa spaIn / sWeden / sWItZerland / taIWan / UKraIne / UnIted araB eMIrates / UK / Usa

WP BIancInformatica DB V4 2

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

WP BIancInformatica DB V4 2

Загружено:

Авторское право:

Доступные форматы

Intgration de donnes oprationnelle

INTEGRATION DE DONNEES OPERATIONNELLE

IntgratIon de donnes opratIonnelle

Dtail de trois projets dIntgration de Donnes Oprationnelle ............................... 15

Mise en uvre du Data Integration Hub................................................................................. 25

IntgratIon de donnes opratIonnelle

IntgratIon de donnes opratIonnelle

IntgratIon de donnes opratIonnelle

Prsentation de lintgration de donnes oprationnelle

IntgratIon de donnes opratIonnelle

Caractristiques de lintgration de donnes oprationnelle

Caractristiques de lIntgration de Donnes

leve lev Avance Complexe Avance Avance

Figure 1 : Comportement type dun projet dIntgration de donnes

2.1 ExPLICATION DES CARACTRISTIquES DE LINTGRATION DE DONNES

IntgratIon de donnes opratIonnelle

IntgratIon de donnes opratIonnelle

Projets dintgration de donnes oprationnelle tudis

IntgratIon de donnes opratIonnelle

IntgratIon de donnes opratIonnelle

Projets dintgration de donnes oprationnelle Temps Rel

4.1 COMPARAISON ENTRE LINTGRATION DE DONNES ET LINTGRATION DE PROCESSuS

IntgratIon de donnes opratIonnelle

IntgratIon de donnes opratIonnelle

Synchronisation des donnes

Juste Temps pour synchroniser lApplication lie au processus mtier M

Juste Temps pour synchroniser le RDBMS li au processus mtier N

Figure 2 : Dfinition du Juste Temps au-del des considrations de latences techniques

IntgratIon de donnes opratIonnelle

Detail de trois projets dintegration de donnees operationnelle

Caractristiques de lIntgration de Donnes

leve leve Avance Complexe Avance Avance

Figure 3 : Comportement type dun projet de rplication de donnes

IntgratIon de donnes opratIonnelle

IntgratIon de donnes opratIonnelle

Caractristiques de lIntgration de Donnes

leve leve Avance Complexe Avance Avance

Figure 4: Comportement type dun projet de synchronisation de donnes

IntgratIon de donnes opratIonnelle

IntgratIon de donnes opratIonnelle

Evolution permanente des interfaces

Erreur de qualit de donnes

Figure 5 : la synchronisation point point des donnes produit un plat de spaghetti

DATA INTEGRATION HuB

IntgratIon de donnes opratIonnelle

Caractristiques de lIntgration de Donnes

leve leve Avance Complexe Avance Avance

Figure 6 : Comportement type dun projet de data Integration Hub

IntgratIon de donnes opratIonnelle

Figure 7 : la synchronisation vue par le data Integration Hub

IntgratIon de donnes opratIonnelle

IntgratIon de donnes opratIonnelle

IntgratIon de donnes opratIonnelle

IntgratIon de donnes opratIonnelle

Mise en uvre du Data Integration Hub

6.1 ORGANISATION DES FONCTIONNALITS Du DATA INTEGRATION HuB

Traabilit Monitoring Fiabilit Qualit de Service

Conguration Gestion derreur Contrle de la latence

Contrle de la qualit des donnes

Fonctionnalits communes dchange

6.1.1 Le noyau du Data Integration Hub : mouvement de donnes entre systmes

IntgratIon de donnes opratIonnelle

Base de donnes DB2

Data Integration Hub