merci les gars.

Je ne m’occupe pas personnellement du Label, cependant, de souvenir, il y a plusieurs tutoriaux de ODI (ex-Sunopsis depuis son rachat).
Sunopsis => Oracle Data Integrator.

L’homme ennuyant est celui qui ennuie par occasion, cela est accidentel; l’homme ennuyeux est celui qui ennuie toujours, cela est inhérent.

En résumé, ce qui est ennuyant est contrariant et cause un désagrément passager, et ce qui est ennuyeux est assommant et cause un désagrément constant ou très fréquent.

Concernant ton premier retour au sujet du grand compte, j’ai eu exactement la même expérience : modélisation des objets et des flux fastidieuse, adaptation d’anciennes applications coûteuse et « pôle EAI » incontournable. Je dirais qu’il s’agit plus d’un problème d’organisation que d’outil à proprement parler : la constatation qui s’impose c’est que bien souvent la connaissance du métier et des flux d’échange n’a jamais vraiment été considérée dans son ensemble dans la société même où on doit mettre en place l’EAI, chaque intervenant a un peu la connaissance de ce qu’il fait sans vraiment avoir une vision sur ce que fait son voisin. De plus, il n’y a pas de documentation sur les anciennes applications qui ne sont pour certaines plus maintenues. Dans ce contexte, la mise en place d’un EAI ou de tout autre outil (ETL) est ardue. Je dirais qu’il faut arriver à découper le projet en lots (plus facile à dire qu’à faire ;ob) et avoir une approche pragmatique en proposant des objectifs successifs moins ambitieux en termes d’intégration mais atteignables.

Dans une plus petite structure, l’impression de plus de facilité avec l’ETL est un peu faussée. Il est vrai que l’ETL est moins intrusif, c’est un fait, mais sur un grand compte, avec un lourd passif, les problématiques entre l’ETL et l’EAI sont similaires : c’est hallucinant le nombre de sources de données redondantes, non consistantes, très mal modélisées ou tout simplement oubliées… que l’on peut dénicher en entrant un peu dans le SI d’une société. L’agrégation ou l’intégration de toutes ces informations est un vrai casse-tête !

Je pense à mon avis qu’il faut quand même choisir son outil en fonction de son objectif (décisionnel ou opérationnel). « Remplacer » l’EAI par un ETL montrera ses limites assez vite lorsque le SI de la société va s’étoffer :

pas possibilité de gérer des workflow et nous avons quelques redondances de règles de gestion liées au point à point.

J’espère également que la seconde partie va pouvoir bientôt paraître, pas toujours évident de tout concilier et les journées sont si courtes ! ;ob

J’ai ensuite eu à mettre en oeuvre des echanges entre applications dans une plus petite structure mais qui comprtait tout de même un paysage applicatif sufisamment réparti pour justifier l’utilisation dans outil centralisé. Nous avons choisi d’utiliser un ETL pour gérer les échanges entre applications et cela nous a apporté des avantages sans avoir les lourdeurs de l’EAI mentionnées ci-dessus.
Les avantages d’avoir cet outil (par rapport à aucun outil) : des interfaces centralisées dans un seul outil quelque soient les technos : plus facile a exploiter et à maintenir, des API de communication avec notre ERP, une gestion d’un référentiel du paysage applicatif permettant de faciliter les connexions en version de développement, de qualité et de production.
Par contre, avec cette solution, nous n’avons pas possibilité de faire du temps réel (mais du batch rapide), pas possibilité de gérer des workflow et nous avons quelques redondances de règles de gestion liées au point à point.

Au contraire, cette méthode permet d’avoir un interfaçage peu intrusif : quel serait le résultat si l’EAI manipulait directement des informations dans les applications sources ou destinatrices ? En cas de dysfonctionnement fonctionnel au niveau EAI, les conséquences seraient importantes car les informations des applications corrompues directement. De plus, autant les responsables de l’EAI que de l’application peuvent se renvoyer la balle en cas de corruption des données. Le passage par la table d’échange permet un sas qui permet de mettre en place un filtre par l’application au niveau des informations qui lui sont destinées. De plus, le modèle évènementiel de l’EAI permet ainsi de consommer les éléments entrants et sortants une fois ceux-ci pris en compte. La table d’échange de l’application source peut-être alimentée directement par l’application, ou bien par trigger pour une intrusivité moindre (quoique ma préférence va quand même à une alimentation par le code de l’application). Quand je parle de filtre ou de traitement par l’application, ceux-ci peuvent être réalisés par des procédures stockées.

Concernant les ETL, je pense effectivement que les données extraites et mises à disposition dans un DWH (datawarehouse) ou un DM (datamart) ne doivent pas être réinjectées dans les applications opérationnelles (sources des données). En effet, les traitements ETL sont déclenchés par batchs et capturent des données à un instant « t », un snapshot, en quelque sorte, à destination d’applications décisionnelles, tandis que les applications opérationnelles manipulent des données en temps réel. Réinjecter des données d’un DWH ou DM dans une base d’application opérationnelle revient à injecter des données passées.

Les données des DWH et DM influent sur les données opérationnelles indirectement puisqu’elles sont à destination du décisionnel qui effectuera des choix concernant les opérations par rapport aux informations récupérées et pourra constater leur efficacité au fur et à mesure des « snapshot » mis à disposition par l’ETL.

Dans le cadre du Active Datawarehousing, il faut que l’information soit issue d’un modèle plutôt évènementiel ou bien d’une forme de streaming proposant une information quasi temps réel pour être toujours d’actualité, et dans ce cas on se rapproche plus d’un fonctionnement type EAI.

Ce genre de fonctionnement sera à mon avis intégré dans des outils de type ESB… Ce genre d’outil sera présenté justement par Romain dans la seconde partie de ce Webcast qui viendra bientôt.

Deux questions sur cette première partie :
Pour l’EAI tu expliques qu’il faut avoir des tables d’échange. Qui les alimentent ? L’application source ? Dans ce cas l’interfaçage avec l’EAI avec est très intrusif si aucune interface existe au préalable pour un outil, non ?
Pour les ETL : tu dis que l’alimentation est unilatérale et qu’en aucun cas un datamart n’alimente une appli source : Préviens Romain, ça va lui faire un choc pour son Active Datawarehousing ;o)))) => Je sais, c’est un peu tiré par les cheveux, le webcast étant dans un objectif de vulgarisation…

En tout cas, c’est très intéressant et bien fait.

ChrYStophe

Dis moi si ca charge bien.