Principe Et Objectif de EAI

EAI
PRINCIPES ET OBJECTIFS
EXTRAIT REFERENCES UNILOG
Identification du document : AQT/EAI/ Principes v1.0 Page 1/32

Ce document est la propriété d’UNILOG et ne peut être reproduit sans son accord écrit
PRINCIPE ET OBJECTIFS DE L’EAI
L’EAI L’EAI (Entreprise Application Integration) est un modèle d’échange entre

applications internes (AtoA) et externes (BtoB) à l’entreprise. Il s’agit de gérer
de véritables processus fonctionnels au niveau du SI, et d’affranchir au
maximum les applications de la problématique des échanges avec N autres
applications.
L’EAI fait intervenir des technologies récentes (XML, JAVA, CORBA, MOM…),
sur un ensemble à la fois technique (connectivité, communication,
transformations de données) et fonctionnel (organisation des processus
métiers).
Contexte A l’heure actuelle, la réussite d’une entreprise dépend de sa capacité à

accroître sa réactivité et son adaptabilité, à gérer au mieux les échanges
internes et inter-entreprises (B2B).
Lorsque les interfaces sont spécifiques à chaque couple d'applications (ou de
bases), leur nombre croît très rapidement avec l'arrivée de nouvelles
applications, à tel point qu'on arrive vite à un "modèle spaghetti" impossible à
maintenir.
Les solutions d’EAI visent à confier à un outil unique correctement paramétré
(ou à un très petit nombre d'outils) la prise en charge des fonctions
d'interfaçage. Leur objectif est d’échanger de manière performante des
informations entre applications ou progiciels, sur plate-formes hétérogènes,
dans des systèmes d’information en constante évolution.
Intégration de données
• Analyse de données
• Data Warehousing
Intégration de Processus • Data Mining
• Intégrité synchrone
• Workflow
• Transactions
• Messaging
Scénarios d’intégration
d’applications
Synchronisation de données
• Réplication
• Consistance de données
• Messaging
Consolidation d’informations
• Vision unifiée de données

Bénéfices En terme d’urbanisme, les bénéfices sont :
• Maîtrise de la taille des applications
• Facilité d’évolution des applications
• Meilleur dialogue ente DSI et MOA
Positionnement
Contrairement aux tendances précédentes qui favorisaient des ruptures entre le
passé et le présent, comme par exemple la mise en place d’un ERP, l’EAI se
positionne comme un vecteur de l’évolution continuelle et maîtrisée du système
d’information dont l’objectif est de valoriser le capital qu’il représente.
L’EAI pris dans son ensemble, outil et démarche, permet de mieux maîtriser
l’urbanisation d’un système d’information, c’est à dire le périmètre fonctionnel
de chaque applications.
Maîtrise de la taille de chaque application

Lorsque il n’y avait pas d’offre progicialisée d’intégration d’application il était
souvent plus facile de faire grossir les applications existantes plutôt que d’en
créer une nouvelle. Cela avait pour conséquence de créer au sein du SI des
applications difficile à maîtriser à cause de leur taille et de leur périmètre
fonctionnelle trop floue. Les équipes chargées de la maintenance de ses
applications devenaient rapidement des goulots d’étranglement pour les projets
d’évolutions du SI. Grâce à l’EAI il est plus facile d’ajouter une nouvelle
application au SI, cela permet donc de limiter l’expansion fonctionnelle de
chaque application et de d’en garder la maîtrise.
Remplacement d’une ancienne application par une nouvelle

L’EAI permet de maîtriser fonctionnellement et techniquement l’ensemble des
flux de données entrant et sortant d’une application. La phase de rétro-
ingénierie habituelle est ainsi évitée, le processus de développement est
accéléré par les possibilité de connectivité offerte par les offres du marché.
Meilleur dialogue entre la DSI et la MOA
L’approche EAI vise non seulement à maîtriser les flux de données, d’une
application A vers une application B, mais aussi à développer la vision
d’ensemble de l’implémentation des processus métier de l’entreprise au travers
des différentes applications de son système d’information. En modélisant un
macro processus sous la forme de flux de données entre applications
l’approche EAI va permettre de donner aux utilisateurs une vision d’ensemble
de leur outil informatique et donner aux direction informatiques une base de
dialogue avec leur maîtrise d’ouvrage.
Applications L’EAI est au cœur de la problématique d’échanges internes et externes

possibles (partenaires, sous traitants, clients…). Tous les SI sont ainsi concernés par
l’EAI, qui se positionne au cœur des échanges :
• CRM (Front Office)
• ERP (Back Office)
• E-business
• legacy

Le modèle EAI Les EAI répondent à une problématique triple :
 Fédérer les sources de données gérées par des applications

d’entreprise qui ont été développées ou installées isolément.
 Unifier ces applications d’entreprise en mettant en place des

processus métiers à l’échelle de l’entreprise, ce qui exigent la
collaboration de plusieurs applications.
 Faciliter l’intégration de nouvelles applications et rendre souple

l’adaptation des processus métiers mis en place.
 Ceci doit être réalisé dans un environnement technique souvent
varié et hétérogène.
Modèle Une architecture d`EAI typique est construite autour d`un moteur central, le
d’architecture message broker, qui exécute des règles de transformation de formats et de
gestion pour recevoir, traduire et envoyer des messages en provenance de ou
vers les applications.
Les middleware, dont les plus utilisés sont les MOM (Middleware orientés
messages), participent de l’amélioration du découplage entre applications.
L’architecture Ce choix pourra influer sur celui du ou des outils qui la constitueront. Il se fera
d’échange entre une topologie bus (publish and suscribe décentralisé) ou une topologie
hub and spoke.(publish and suscribe centralisé). Avec une topologie hub and
spoke, les messages sont envoyés à un hub central. L’application source
envoie un message dans un format ; le hub traduit le message si nécessaire et
le route vers les différentes branches abonnées, ou spokes, du hub.
Le choix portera aussi sur le mode de communication entre les applications à
intégrer : synchrone (ORB, http…) ou asynchrone (middleware message).

Transport et Les services de transport assurent la livraison des données aux applications via
connectivité le moteur d’intégration. Dans la pratique, toutes les solutions d’EAI reposent sur
une couche plate-forme, ou middleware, soit propriétaire, soit fournie par un
éditeur partenaire.
La connectivité est assurée par les adapters ou connecteurs. Les connecteurs
prennent en charge la connexion physique des applications au gestionnaire de
flux. Leur nature est directement liée aux moyens qu'une application fournit
pour communiquer avec elle : APIs, interface avec des middlewares de
communication (MOM), etc.
Adaptation de Les événements produits par les applications d'origine doivent être transformés
l’information pour être compréhensibles par les applications destinataires.
Ce niveau offre les services suivant :
La transformation des flux : le moteur de transformation déclenche, sur
réception d'un ou plusieurs événements, les règles de transformation et
d'enrichissement des données afin que ceux-ci deviennent compréhensibles
par l'application destinataire.
Le routage et le contrôle des flux : le routage consiste en la gestion et
transmission des données. Il permet de distribuer et d'aiguiller les flux vers les
bons destinataires. Les critères de routage peuvent être issus des processus
métiers, des règles de routages, et des informations contenues dans les
messages.
Toutes ces fonctions sont fournies par un moteur d’intégration. Le moteur
d’intégration centralise l’intelligence de la plate-forme d’EAI via son référentiel,
qui contient toutes les règles de routage et de transformation des données. Il
sait à quel événement métier appartient le message recueilli et assure la
continuité de cet événement.
La gestion des Un flux subit une série d'aiguillages et de traitements qui forment un processus
processus métiers métier. Le gestionnaire de processus doit pouvoir :
Dérouler une chaîne de traitements composée de plusieurs étapes
élémentaires (workflow), c'est-à-dire faire de la gestion événementielle
complexe;
Prendre en charge la gestion des rendez-vous (flux n vers 1);
Garantir le suivi et l'intégrité transactionnelle (transaction longue).

GLOSSAIRE
EAI
Enterprise Application Integration : intégration d’application.
L’EAI peut être vu comme l’ensemble des technologies d’intégration, mais
généralement ce terme est restreint aux produits récents (moins de 4 ans
environ), à forte valeur ajoutée (couches transport, routage, transformation,
supervision de processus…).
Le terme EAI restreint souvent implicitement le champ à la sous-catégorie A2A
de l’EAI, c’est à dire les échanges intra-entreprise, par opposition au B2B.
B2B
Business To Business : Ce terme désigne les relations, les services
automatisés mis en œuvre entre entreprises. L’EDI a permis de tisser les
premières relations B2B. Internet, avec les portails, les solutions d’e-
marketplace et les outils d’intégration e-business, donne une nouvelle
dimension à ces échanges.
Le B2B est souvent vu comme une sous-catégorie de l’EAI, correspondant à la
notion d’entreprise étendue. Par exemple dans la suite webMethods, le produit
proposé est Integration Server (ex webMethods B2B).
B2C
Désigne les relations qu’une entreprise peut tisser avec ses clients. Ici le terme
client correspond au consommateur final, pas les entreprises partenaires
intermédiaires.
A2A
Application To Application : sous-catégorie de l’EAI, correspondant à la notion
d’intégration des systèmes internes à l’entreprise, par opposition au B2B. Par
exemple dans la suite webMethods, le produit proposé est webMethods
Enterprise (ex produit de Active Software).
Broker
Ensemble des outils identifiés sous les vocables de Message Broker ou
d'Integration Broker ou Integration Server. Ce sont ces outils qui apportent les
fonctions de base de toute solution d'EAI.
Mode publish -
Ce mode met en œuvre l'échange de messages. L'échange n'est plus 1 à 1
suscribe
mais 1 vers n. Un message est envoyé par un émetteur à plusieurs
(publication /
destinataires sans que celui-ci les connaisse à l'avance. Il ne fait que publier sur
abonnement)
un sujet donné.
MOM Middleware Orienté Message, par exemple MQSeries.

Les MOM désignent les technologies d’échange des messages stockés dans
les files d’attente. Le MOM est un routeur de flux interapplicatifs reposant sur
une logique asynchrone. Les produits comme MQSeries (IBM),
TIB/Rendezvous (Tibco), MessageQ (BEA), MSMQ (Microsoft) incluent cette
technologie.
L’EAI englobe souvent la plupart des fonctionnalités d’un MOM, bien qu’on
puisse aussi intégrer les deux le cas échéant.

MOT
Middleware Orienté Transaction (moniteur transactionnel), par exemple
Tuxedo.
L’EAI peut assumer une partie des fonctionnalités d’un MOT, mais ce n’est pas
sa fonction première. Les deux familles sont donc complémentaires.
MOF
Middleware Orienté Fichier (moniteur de transfert de fichier), par exemple CFT.
L’EAI peut remplacer un MOF pour les échanges dits « au fil de l’eau », par
contre l’EAI n’est pas fait pour les importants transferts de fichiers « batch ».
Workflow
Le workflow est l’automatisation d’un processus – partiel ou complet – au cours
duquel des documents, des informations et des tâches passent d’un participant
à un autre, au sein d’un groupe de travail, en conformité avec un ensemble de
règles prédéfinies. Un système de workflow définit, crée et gère l’exécution de
tels processus.
XML
eXtensible Markup Language : métalangage qui permet, contrairement à HTML,
de décrire la structure des données indépendamment de la présentation des
données. Ce langage est un sous-ensemble de SGML et est évolutif. XML est
la pierre angulaire des applications de commerce électronique.
Objet Pivot ou
Objet métier générique circulant sur le bus EAI.
Canonique
Le format de cet objet est indépendant des applications.
Les applications émettrices plublient des objets de ce type (publish), tandis que
les applications consommatrices s’y abonnent (subscribe) ; ainsi le découplage
des applications est préservé.

Logiciel « Client » On parle souvent d’adapters accédant à l’application désirée via un logiciel
client. Par exemple :
• l’adapter Oracle communique avec la base de données via SQL Net, de
même que l’adapter JDBC communique avec la base de données via un
driver JDBC utilisant TCP/IP
• l’adapter Tuxedo communique avec les services Tuxedo via un client
Tuxedo
• les adapter fichiers (XML ou fichiers plats) peuvent communiquer via
des protocoles tels que http ou bien sockets, (voire FTP).
• des adapters tels que EJB, JMS…
La plupart des adapters autorisent ce mode de fonctionnement qui permet de
distribuer physiquement les composants, sans être forcé d’installer l’adapter sur
la même machine que l’application. Néanmoins pour des raisons de
performances et de sécurité, il vaut mieux installer l’adapter au plus proche,
c’est à dire – si possible – sur la machine applicative.
Certains adapters ne peuvent pas utiliser de logiciel client, car l’application (ou
la technologie) ne le permet pas, par exemple :
• les adapters fichiers, s’il est nécessaire de communiquer via le disque
dur. A l’exception de montages NFS, rarement autorisés par les équipes
système.
• l’adapter ARBOR/BP
• un adapter spécifique « attaquant » directement des fonctions Java, C…
C’est le cas de l’adapter FE développé dans le cadre du démonstrateur
Commande – Facturation, qui enapsule des services C en utilisant JNI
(Java Native Interface)

EXTRAIT DE REFERENCES UNILOG
ORANGE – Projet MNEMO

Période De décembre 2000 à juillet 2001
Durée du projet 8 mois
Taille du projet 690 K€ – (790 jours hommes)
Description Gestion des flux logistiques des cartes SIM.
Mise en œuvre d’un service EAI (projet MNEMO) pour le
traitement des flux de distribution cartes, pour sécuriser les
traitements et améliorer l’adaptabilité de la gestion des échanges,
avec un forte contrainte de performances (pic de charge de
100.000 messages par heure).
Les chantiers :
 Définition de l’architecture technique cible (basée sur SUN
E10000, machine multi-processeurs).
 Réalisation d’un plan de charge, et mise en œuvre d’un
benchmark.
 Réalisation des procédures d’installation et d’exploitation.
 Spécifications et développement des processus métier
dans CROSSWORLDS.
 Réalisation des développements Java complémentaires.
 Spécifications et développement d’un superviseur des flux
(suivi, statistiques, gestion des rejets).
Environnement MQ/Series, CROSSWORLDS, ORACLE, JBUILDER
technique

FRANCE TELECOM SICOR
Période Déc. 2001 à ce jour
Durée du projet
Description Etape 1 :
Prototype de faisabilité technique dans le cadre du projet
ComptaFour.
L’application Comptafour à France Telecom assure la comptabilité
auxiliaire fournisseurs.
Elle permet de traiter toute la gestion des factures fournisseurs de
l’engagement jusqu’à la mise en paiement. Cette application est
actuellement en phase de spécifications générales.
Etape 1 :
Déploiement de la solution.
Environnement WEBMETHODS, SAP, ORACLE APPLICATION, EDI
technique
FRANCE TELECOM SIFAC

Période Mai 2002
Durée du projet En cours
Description L’application FE à France Telecom prend en charge la facturation
d’entreprise.
Dans le cadre de la progicialisation de l’application vers un
environnement Java (IHM) / Tuxedo (services métier) réalisée par
Unilog, une étude d’impacts est menée sur la mise en oeuvre d’un
EAI.
Environnement WEBMETHODS
technique

DGA – Projet SIPROG
Période Déc. 2001 à ce jour
Description Le projet SIPROG (Système d’Information PROGrammes) permet
d’automatiser et d’optimiser la conduite des programmes et
opérations d’armement menés par la DGA auprès des industriels
pour le compte des états-majors.
Il couvre quatre domaines fonctionnels :
 Domaine Programme (Gestion de projet et Gestion des
ressources) instrumenté dans l’outil OPX2 de Planisware
 Domaine Achat instrumenté dans l’outil SIS Marchés de la
société SIS
 Domaine Finance-Comptabilité instrumenté dans
l’application spécifique NABUCCO et Oracle Application
(modules PA, PO, GL, AP, OFA),
 Domaine Ingénierie Système (Windchill, DOORS)
Les processus métiers instrumentés dans différentes applications
partagent de nombreuses données (marchés/contrats,
fournisseurs, factures, commandes, etc…). Le partage des
données est réalisé de façon automatique via des interfaces
implémentées dans un outil EAI.
La maîtrise d’œuvre du projet a été confié à UNILOG
Management. Le chantier Intégration EAI a couvert les phases
suivantes :
 Définition et conception des interfaces à partir des
processus métiers DAG : modélisation des objets métiers
échangés, structure des messages, transformations.
 Définition et conception de l’architecture technique autour
de l’EAI : principes, normes, services techniques,
connecteurs,…
 Mise en œuvre des interfaces : développement et
intégration des connecteurs, routages et transformation des
flux de données.
 Intégration de l’ensemble du système : tests de bout en
bout et déroulement des processus métiers complets.
Le chantier interface (connecteurs et mise en œuvre de l’EAI)
représente 3000 h.j pour une cinquantaine de flux complexes.

Environnement UML, XML, Websphere MQ Intégrator 2.1, Websphere MQSeries,
technique Java, PL/SQL, Transact SQL, Sybase, Oracle 8.1.7, Oracle
Application 11.5, Windows NT, AIX
Connecteurs ORACLE APPLICATION, WINDCHILL, OPX2,
NABUCCO (Sybase), SIS Marchés, SITEA (Weblogic Application
Server)

POST@XESS (GROUPE LA POSTE)
Période D’octobre 2000 à octobre 2001
Taille du projet 300 h.j
Description Assister la maîtrise d’ouvrage POST@XESS pour l’aider à définir
son architecture technique et logicielle, ainsi que les outils
logiciels ou progiciels de type EAI qu'elle doit utiliser pour
développer une offre de type place de marchés.
Première phase : choix d’une architecture cible
 Analyse de la problématique,
 Etude macroscopique des technologies existantes,
 Rédaction du cahier des charges,
 Synthèse des propositions reçues
Deuxième phase : assistance à la maîtrise d’ouvrage pour la
mise en œuvre de l’EAI (CROSSWORLDS) et de l’architecture
préconisée (services métier, serveur d’application, …). Cette
phase a intégré la modélisation des processus métier en UML.
Environnement Technologies EAI, CROSSWORLDS, serveur d’application
technique WebLogic, UML

ALCATEL – PROJET CORPORATE CONCERTO
Période Fin 2001 – Début 2002
Durée du projet Sur 6 mois
Taille du projet 120 jours.hommes, 1 à 2 personnes sur 6 mois
Description Consolidation pour le groupe Alcatel des résultats financiers des
différentes filiales européennes, utilisation de SAP FI et de
WebMethods :
 Conseil en architecture EAI et prototypage.
 Mise en oeuvre de nouveaux flux avec WebMethods entre
le projet Concerto (SAP) et le projet BluePlanet(SAP).
 Technologie de connexion : Adapter WebMethods SAP-
ALE IDOC, Inboud, Outbound.
Environnement Webmethods, SAP, adaptateur IDOC
technique

USINOR PROJET TBO (THALIS BACK OFFICE)
Période Début 2002
Durée du projet
Taille du projet Confidentiel

Description Projet Thalis Back Office.
Mise en place de SAP R/3 et intégration au reste du SI via
WebMethods.
Mise en œuvre fonctionnel de SAP R/3 (module FI,CO,MM, EBP).
Conception et développement de flux SAP avec WebMethods
Environnement WebMethods
technique

AIR LIQUIDE - PROJET OPERA
Période 2002
Durée du projet + de 6 mois
Taille du projet 700 jours.hommes pour la partie EAI, autant pour la partie ABAP
Description Refonte complète de l’ensemble des filiales (60 pays)
Pipeline/Bulk/Cylinder/healthcare/HomeCare.
 Mise en place de SAP R/3 et intégration au reste du SI via
SeeBeyond
 Mise en œuvre fonctionnelle de SAP R/3 (module
FI,CO,MM).
 Conception et développement de flux SAP (ABAP) et
intégration l’ensemble des applications legacy, soit un
minimum de 70 interfaces (plus de 150 à terme)
Environnement SAP R/3 (module FI,CO,MM), ABAP, SeeBeyond, XML
technique

EDF – GDF (GDMI-OP)
Période D’octobre 2001 à février 2002
Durée du projet 3,5 mois
Taille du projet 230 jours.hommes
Description Projet Interface Producteur : mse en place d'un système
d'échanges autour de WebMethods.
Il s’agit de réaliser un prototype industriel gérant divers échanges
entre applications du SI du Producteur pour définir une démarche
de mise en place des échanges qui seront connectés au Service
d’Echange bâti avec le progiciel WebMethods.
 Lot 1 : Réalisation de la Version 1 du prototype mettant en
œuvre des échanges entre deux applications sous MVS et
Oracle.
 Lot 2 : Réalisation de la Version 2 du prototype mettant en
oeuvre des échanges entre trois applications sous MVS,
Lotus Notes et Oracle
 Lot 3 : Industrialisation du prototype et préparation de la
mise en exploitation
 Lot 4 : Description d’une démarche et d’une organisation.
Interconnexion d'applications sous MVS, Oracle, Lotus Notes,
Fichiers XML en environnement NT et AIX. Conception,
réalisation, architecture technique, mise en production, définition
de la méthodologie EAI.
Environnement Webmethods, XML, Java, Oracle, Lotus Notes, applications sous
technique MVS, MEGA, UML

CREDIT LYONNAIS (Direction des marchés Actions)
Période De février à octobre 2001
Taille du projet 250 jours.hommes
Description Assister la maîtrise d’ouvrage du CREDIT LYONNAIS, ainsi que
l’équipe responsable de la phase courante du schéma directeur
dans le processus de choix d’une solution progicielle de type EAI
et d’une architecture technique pour son middleware.
La démarche est la suivante :
 Etude technique du middleware,
 Étude de l’existant,
 Expression des besoins du CREDIT LYONNAIS et
rédaction d’un cahier des charges,
 Formulation puis pondération des critères de choix d’une
solution progicielle pour le middleware,
 Analyse des produits en regard de ces critères,
 Choix d’une solution progicielle pour le middleware,
 Construction d’un prototype,
 Description d’un plan d’action.
Environnement Technologies EAI, prototypes REUTERS et CrossWorlds
technique

DEXIA Banque Internationale du Luxembourg
Période Fin 2001, 2002
Durée du projet Confidentiel
Description DEXIA BIL (Banque Internationale du Luxembourg) est la filiale
luxembourgeoise du groupe DEXIA.
Dans le cadre de la rationalisation de son système de
communication inter-applicative comprenant un legacy MVS, SAP
R/3 et un progiciel de CRM Siebel, DEXIA BIL recherchait la
solution EAI la plus adaptée et la plus pérenne du marché. DEXIA
utilise déjà MQSeries et Mercator dans certaines de ses filiales.
DEXIA BIL a souhaité procéder en plusieurs étapes :
Une première étape pour :
- La définition des besoins
- L'aide au recueil des éléments qui permettront le choix de
(ou des) l’architecture technique cible
- L’évaluation des solutions possibles sous les angles
fonctionnels, technique, organisationnel et économique
- le choix de la meilleure solution
La seconde étape consiste à la mise en œuvre technique et
organisationnelle de la solution cible.
UNILOG vient de réaliser la première étape. DEXIA BIL finalise
actuellement son choix. Le produit CROSSWORLDS a été choisi.
Environnement Technologies EAI, Mercator, CROSSWORLDS, MQSeries
technique

AUREL LEVEN (SOCIETE DE BOURSE)
Période De Avril Juin 2001
Durée du projet

Description Projet Automatisation de la Table de Vente Produits Dérivés :
 Etude préalable à la mise en place d'une plate-forme
intégrée Front- to-Back pour les produits dérivés
 Validation des spécifications fonctionnelles et
techniques,Identification et étude des progiciels du marché
 Participation à la rédaction de l'appel d'offre
Environnement Technologies EAI, XML
technique

SCHNEIDER ELECTRIC
Période 2001 à 2004
Durée du projet Sur 3 ans
Taille du projet 6 000 jours.hommes
Description Partenariat stratégique pour la définition de l’architecture et
l’intégration d’un système d’échange dans le Système
d’Information Schneider.
Conseil, assistance et réalisation sur le produit CROSSWORLDS
choisi par la Direction Générale du groupe SCHNEIDER.
Environnement Technologies EAI, CROSSWORLDS
technique

CAISSE DES DEPOTS ET CONSIGNATIONS
Période De Janvier 2001 à Juin 2002
Taille du projet Equipe de 3 personnes
Description Définition de l’architecture technique pour la mise en place d’un
EAI au sein du SI CDC :
 Définition des besoins
 Etude des solutions du marché
 Dossier de choix de solution
 Etude d’architecture technique
 Mise en place d’un prototype autour de l’EAI MERCATOR
(Développements de 18 messages RGV, Relit+ et Swift)
Environnement Technologies EAI, MERCATOR
technique

GRANDE BANQUE FRANÇAISE
Période Depuis Septembre 2001
Description Projet d’agence OPCVM
Conception et mise en oeuvre de l’interfaçage du système
dépositaire (30 applications) avec un service Internet dédié à la
clientèle :
 Définition de l’architecture fonctionnelle
 Mise en oeuvre de l’EAI MERCATOR
 Mapping des flux
technique

SG ASSET MANAGEMENT
Période Depuis Janvier 2001
Description Management et assistance de l’équipe sur l’envoi et réception de
flux de données de portefeuilles vers partenaires et dépositaires
de la SGAM avec l’EAI Mercator :
 Prototype de flux aller et retour
 Mise en œuvre et déploiement
 Mise en place de la maintenance.
Environnement Technologies EAI, Mercator
technique

EUROCLEAR
Période Depuis Juin 2001
Description Intégration du projet rationalisation des liens au sein de la plate-
forme SICOEXCHANGE, point d’entrée d’Euroclear.
 Validation du dossier d’analyse fonctionnelle
 Adaptation de la PECT (prise en charge technique) – partie
MERCATOR
 Adaptation de la PECF (prise en charge fonctionnelle) –
partie MERCATOR
 Adaptation du routage des données – paramétrage des
tables ORACLE
 Adaptation de la partie concernant la conversion des
données partie MERCATOR
 Adaptation de la partie concernant la MADP (Mise A
Disposition) des données – partie MERCATOR
 Recette
 Livraison des maps Mercator sous UNIX
 Support/Correction à l’intégration
technique

EDF – ICIA
Période Octobre 98 à ce jour
Durée du projet Jusqu'à la mise en production : 1 an
Taille du projet 760 K€
Description Mise En oeuvre d’un système d’échanges inter-applicatifs, dans
un environnement distribué, multi plates-formes (UNIX, NT, MVS),
avec une composante de sécurité et de suivi assez forte.
Cadrage, Spécifications Générales, Prototypage, Spécifications
détaillées, Mise en Œuvre, Recette, site pilote, formation,
assistance au déploiement
Environnement Administration A&P (SOPRA) SYBASE, agent A&P, NT, UNIX,
technique MVS SAP

FRANCE TELECOM - SNPI
Période De 1999 à 2000
Durée du projet 2 ans
Taille du projet 300 K€
Description Mise en Œuvre et déploiement de la solution A&PMise en œuvre
d’un système d’échanges inter-applicatifs, multi-plateformes
(UNIX, NT, MVS, VMS) et qualification d’un plan de migration
global.
Les chantiers :
 Définition de l’architecture technique cible
 Réalisation de packaging d’installation
 Rédaction des procédures d’installation, d’exploitation et
d’administration
 Formation des utilisateurs exploitants et fonctionnels.
 Qualification d’une montée de version des produits A&P et
MQSeries (réalisation d’un plan de tests techniques et
validation)
 Plan de migration
Environnement MQSeries, CFT, A&P.
technique

Générale des eaux - Banlieue de Paris
Période D’ oct. 2001 à ce jour
Durée du projet 3 mois pour le choix du produit EAI, 3 mois pour la mise en œuvre
du prototype
Taille du projet
Description Dans le cadre d’une réorganisation, Banlieue de Paris a décidé de

mettre en œuvre l'application DELIA permettant de centraliser les
demandes d'interventions issues, principalement, de l'application
IDC et de les dispatcher vers les agents via un système
informatique nomade (pocket PC, Portable...).
Le projet EAI a permis de mettre en œuvre les flux de données
concernant les demandes d’interventions issues de IDC qui sont
transmises à DELIA pour y être planifiées et allouées aux
différents inspecteurs susceptibles d’intervenir sur le terrain.
La première étape a consisté dans le choix de l’EAI :
 Définition des besoins
 Etude des solutions du marché
 Prototype technique avec les éditeurs
 Dossier de choix de solution
La seconde étape a permis de mettre en œuvre les flux dans le
système : architecture technique, paramétrage des flux dans le
système.
Environnement EAI VITRIA, VSAM sur MVS, TUXEDO, HP UX, ORACLE, XML
technique

EULER
Période De Juin 2000 à Septembre 2000
Taille du projet 460 K€ – Equipe jusqu’à 13 personnes (1 300 jours hommes)
Description Définition de l’architecture technique pour la mise en place d’un
EAI (Enterprise Integration Application) au sein du Groupe
EULER :
- Définition des besoins
- Etude des solutions du marché - Dossier de choix de solution
- Etude d’architecture technique
- Mise en place d’un prototype.
Environnement
IBM DB2, Windows NT 4.0 Server – IBM AIX, IBM MQSeries
technique
Integrator V2 – MERCATOR – SOPRA Règles du Jeu, MQSeries
- XML

CEGETEL - SGFE
Période De novembre 1999 à septembre 2000
Taille du projet 460 K€ – Equipe jusqu’à 13 personnes (1 300 jours hommes)
Description Le SGFE se positionne dans le SI de CEGETEL comme le point
unique de fédération et de fiabilisation de l’ensemble des flux
métier d’encaissement. Plus aspects supervision.
Environnement MQ Series, CFT, UNIX, ORACLE 8i, SUN SOLARIS, TIVOLI,
technique JAVA OAS Client / Serveur

TIMKEN
Période Confidentiel
Description Définition d’une architecture d’échanges internationale entre le
siège central aux Etats Unis et les filiales Européennes, au niveau
infrastructure télécoms, réseaux et Middleware en mode message
(MQ/SERIES).
Environnement IBM MQ/Series
technique

DEXIA Crédit Local de France
Période Confidentiel
Description
CLF-SI, GIE d'Informatique CDC est le service informatique de
DEXIA Crédit Local de France.
Dans le cadre de la refonte du système de gestion de crédit,
baptisée SIP, CLF-SI s'interroge sur l'architecture technique à
mettre en place afin de supporter et maîtriser les échanges entre
SAB/AS400 (le nouveau progiciel sélectionné) et les autres
applications du SI de DEXIA.
Le CLF-SI a souhaité procéder en deux étapes :
Une Première étape pour :
• la définition des besoins
• l'aide à la constitution des éléments qui permettront le choix de
(ou des) l’architecture technique cible
• Evaluer les solutions possibles sous l’angle « financier » et
l’angle « Organisationnel »
• Le choix des outils adaptés aux solutions proposées.
Une Deuxième étape pour la mise en œuvre technique et
organisationnelle de la solution cible.
DEXIA/CLF a confié à UNILOG la première étape.
Environnement MQ Series, CFT, UNIX, ORACLE 8i, SUN SOLARIS, TIVOLI,

technique JAVA OAS Client / Serveur


Principe Et Objectif de EAI

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Principe Et Objectif de EAI

Uploaded by

Copyright:

Available Formats

EAI

EXTRAIT REFERENCES UNILOG

Identification du document : AQT/EAI/ Principes v1.0 Page 1/32

L’EAI L’EAI (Entreprise Application Integration) est un modèle d’échange entre

Contexte A l’heure actuelle, la réussite d’une entreprise dépend de sa capacité à

Identification du document : AQT/EAI/ Principes v1.0 Page 2/32

Maîtrise de la taille de chaque application

Remplacement d’une ancienne application par une nouvelle

Applications L’EAI est au cœur de la problématique d’échanges internes et externes

Identification du document : AQT/EAI/ Principes v1.0 Page 3/32

 Fédérer les sources de données gérées par des applications

 Unifier ces applications d’entreprise en mettant en place des

 Faciliter l’intégration de nouvelles applications et rendre souple

Identification du document : AQT/EAI/ Principes v1.0 Page 4/32

Identification du document : AQT/EAI/ Principes v1.0 Page 5/32

MOM Middleware Orienté Message, par exemple MQSeries.

Identification du document : AQT/EAI/ Principes v1.0 Page 6/32

Identification du document : AQT/EAI/ Principes v1.0 Page 7/32

Identification du document : AQT/EAI/ Principes v1.0 Page 8/32

ORANGE – Projet MNEMO

Identification du document : AQT/EAI/ Principes v1.0 Page 9/32

FRANCE TELECOM SIFAC

Identification du document : AQT/EAI/ Principes v1.0 Page 10/32

Identification du document : AQT/EAI/ Principes v1.0 Page 11/32

Identification du document : AQT/EAI/ Principes v1.0 Page 12/32

Identification du document : AQT/EAI/ Principes v1.0 Page 13/32

Identification du document : AQT/EAI/ Principes v1.0 Page 14/32

Taille du projet Confidentiel

Identification du document : AQT/EAI/ Principes v1.0 Page 15/32

Identification du document : AQT/EAI/ Principes v1.0 Page 16/32

Identification du document : AQT/EAI/ Principes v1.0 Page 17/32

Identification du document : AQT/EAI/ Principes v1.0 Page 18/32

Identification du document : AQT/EAI/ Principes v1.0 Page 19/32

Taille du projet Confidentiel

Identification du document : AQT/EAI/ Principes v1.0 Page 20/32

Identification du document : AQT/EAI/ Principes v1.0 Page 21/32

Identification du document : AQT/EAI/ Principes v1.0 Page 22/32

Identification du document : AQT/EAI/ Principes v1.0 Page 23/32

Identification du document : AQT/EAI/ Principes v1.0 Page 24/32

Identification du document : AQT/EAI/ Principes v1.0 Page 25/32

Identification du document : AQT/EAI/ Principes v1.0 Page 26/32

Identification du document : AQT/EAI/ Principes v1.0 Page 27/32

Description Dans le cadre d’une réorganisation, Banlieue de Paris a décidé de

Identification du document : AQT/EAI/ Principes v1.0 Page 28/32

Identification du document : AQT/EAI/ Principes v1.0 Page 29/32

Identification du document : AQT/EAI/ Principes v1.0 Page 30/32

Identification du document : AQT/EAI/ Principes v1.0 Page 31/32

DEXIA/CLF a confié à UNILOG la première étape.

Environnement MQ Series, CFT, UNIX, ORACLE 8i, SUN SOLARIS, TIVOLI,

Identification du document : AQT/EAI/ Principes v1.0 Page 32/32

You might also like