Principe Et Objectif de EAI

EAI

PRINCIPES ET OBJECTIFS

EXTRAIT REFERENCES UNILOG

Identification du document : AQT/EAI/ Principes v1.0 Ce document est la propriété d’UNILOG et ne peut être reproduit sans son accord écrit

Page 1/32

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.


Page 2/32

Intégration de Processus•Intégrité synchrone•Workflow•Transactions•Messaging

Consolidation d’informations•Vision unifiée de données

Synchronisation de données•Réplication•Consistance de données•Messaging

Intégration de données•Analyse de données•Data Warehousing•Data Mining

Scénarios d’intégration d’applications

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

PositionnementContrairement 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 MOAL’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 possibles

L’EAI est au cœur de la problématique d’échanges internes et externes (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


Page 3/32

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 d’architecture

Une architecture d`EAI typique est construite autour d`un moteur central, le 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 d’échange

Ce choix pourra influer sur celui du ou des outils qui la constitueront. Il se fera 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).


Page 4/32

Transport et connectivité

Les services de transport assurent la livraison des données aux applications via 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 l’information

Les événements produits par les applications d'origine doivent être transformés 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 processus métiers

Un flux subit une série d'aiguillages et de traitements qui forment un processus 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).


Page 5/32

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 - suscribe (publication / abonnement)

Ce mode met en œuvre l'échange de messages. L'échange n'est plus 1 à 1 mais 1 vers n. Un message est envoyé par un émetteur à plusieurs destinataires sans que celui-ci les connaisse à l'avance. Il ne fait que publier sur 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.


Page 6/32

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 Canonique

Objet métier générique circulant sur le bus EAI.

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é.


Page 7/32

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)


Page 8/32

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 technique

MQ/Series, CROSSWORLDS, ORACLE, JBUILDER


Page 9/32

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.


WEBMETHODS, SAP, ORACLE APPLICATION, EDI

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.


WEBMETHODS


Page 10/32

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.


Page 11/32


UML, XML, Websphere MQ Intégrator 2.1, Websphere MQSeries, 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)


Page 12/32

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.


Technologies EAI, CROSSWORLDS, serveur d’application WebLogic, UML


Page 13/32

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.


Webmethods, SAP, adaptateur IDOC


Page 14/32

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


WebMethods


Page 15/32

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)


SAP R/3 (module FI,CO,MM), ABAP, SeeBeyond, XML


Page 16/32

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.


Webmethods, XML, Java, Oracle, Lotus Notes, applications sous MVS, MEGA, UML


Page 17/32

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.


Technologies EAI, prototypes REUTERS et CrossWorlds


Page 18/32

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.


Technologies EAI, Mercator, CROSSWORLDS, MQSeries


Page 19/32

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


Technologies EAI, XML


Page 20/32

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.


Technologies EAI, CROSSWORLDS


Page 21/32

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)


Technologies EAI, MERCATOR


Page 22/32

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




Page 23/32

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.


Technologies EAI, Mercator


Page 24/32

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




Page 25/32

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


Administration A&P (SOPRA) SYBASE, agent A&P, NT, UNIX, MVS SAP


Page 26/32

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


MQSeries, CFT, A&P.


Page 27/32

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.


EAI VITRIA, VSAM sur MVS, TUXEDO, HP UX, ORACLE, XML


Page 28/32

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.


IBM DB2, Windows NT 4.0 Server – IBM AIX, IBM MQSeries Integrator V2 – MERCATOR – SOPRA Règles du Jeu, MQSeries - XML


Page 29/32

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.


MQ Series, CFT, UNIX, ORACLE 8i, SUN SOLARIS, TIVOLI, JAVA OAS Client / Serveur


Page 30/32

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).


IBM MQ/Series


Page 31/32

DEXIA Crédit Local de France

Période Confidentiel



DescriptionCLF-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.


MQ Series, CFT, UNIX, ORACLE 8i, SUN SOLARIS, TIVOLI, JAVA OAS Client / Serveur


Page 32/32

Documents

Principe Et Objectif de EAI