Intégration d'applications d'entreprise

Pour les articles homonymes, voir IAE et EAI.

L'Intégration d'applications d'entreprise ou IAE (en anglais Enterprise Application Integration, EAI) est une architecture intergicielle permettant à des applications hétérogènes de gérer leurs échanges. On la place dans la catégorie des technologies informatiques d'intégration métier (Business Integration) et d'urbanisation. Sa particularité est d'échanger les données en pseudo temps réel.

Par extension, l'acronyme EAI désigne un système informatique permettant de réaliser cette architecture en implémentant les flux interapplicatifs du système d'information.

Composants

Une plate-forme IAE est composée de plusieurs éléments :

• Des connecteurs servent d'interface entre l'IAE et les applications. Ils scrutent les événements de l'application et transmettent les données associées vers l'IAE (ou fournissent à l'application les données provenant de l'IAE). Ces données sont appelées Objets de Métier Spécifiques (OMS; en anglais, Application Specific Business Objects ASBO) car elles reflètent les données de l'application (nom du champ, format...).
• Les OMS en provenance des (ou dirigés vers les) connecteurs passent par une opération de mise en correspondance ou mappage (mapping) pour transformer les données spécifiques aux applications (OMS) en données standards à l'IAE : les OM (Objets de Métier; en anglais, Business Objects BO).
• Les OM reflètent alors le modèle de données global des informations des différents processus de l'entreprise. Ils sont alors transmis à des traitements appelés collaborations qui reflètent la logique de traitement à appliquer sur un OM avant de le transmettre à une application cible (compléter les infos par recherche dans une autre application, vérification de la validité du processus métier...).
• Une couche de transport : il s'agit de la couche qui sert à acheminer les données entre les applications. Cette couche peut être implémentée par échange de fichiers (par exemple en utilisant FTP), par échange de message (par exemple en utilisant un MOM, JMS ou Jabber/XMPP) ou encore par appel de services (par exemple en utilisant SOAP sur HTTP).

Exemple de fonctionnement

Pour comprendre le fonctionnement, on peut présenter l'exemple suivant : Une application A de gestion de commande crée un nouvel article (une pompe) et elle veut le rendre disponible à une application B qui suit les anomalies techniques de cet article et à une application C qui affiche l'article sur un portail Web.

1. L'application A crée un nouvel article dans sa base de données. Un traitement automatique (trigger) capture cet événement et l'archive dans une table d'événement avec la donnée associée (nouvel article).
2. Un connecteur IAE JDBC (Base de données) scrute cette table toutes les 10 secondes et découvre ce nouvel événement. Il récupère alors la donnée associée et la copie dans un OMS en lui associant un verbe (création).
3. L'OMS passe alors dans une phase de mise en correspondance pour convertir les données du nouvel article (spécifiques à l'application A) en un OM générique reflétant toutes les informations nécessaires à l'entreprise pour représenter un article.
4. L'objet métier Article est attendu (enregistré) par deux collaborations (C1 et C2). La première récupère l'OM, analyse le verbe (création) et envoie l'OM en création vers l'application B (Cet OM est remis en correspondance pour obtenir un article OMS destiné à B et est traité par le connecteur de B qui effectue la création). Dans le même temps, la deuxième Collaboration C2 récupère l'OM original et l'envoie en création vers l'application C (mappage, connecteur C).

Avantages/Inconvénients

Avantages :

• Flux centralisés : Avant l'arrivée de l'IAE, les entreprises devaient développer des interfaces spécifiques à chaque application et les connecter point à point. Il en résultait un réseau complexe (plat de spaghetti) de flux, difficile à maintenir et à faire évoluer. Maintenant, toutes les interfaces IAE convergent vers un serveur central (concentrateur ; en anglais, hub) qui traite et redistribue les flux vers les applications enregistrées.
• Flux traités "au fil de l'eau" : Les mises à jour des données sont effectuées au fil de l'eau, c'est-à-dire au fur et à mesure des événements des applications sources. Cela réduit les flots de donnée lors des transferts et propose une donnée "à jour" peu de temps après son éventuelle modification. Cela réduit aussi la perte de performance des applications due à l'extraction ou la mise à jour des données car on ne traite que des flots de petite taille et répartis dans le temps.
• Flux réutilisable : Si une nouvelle application veut accéder aux OM déjà présents dans l'IAE, toute la logique de récupération n'est plus à développer. En théorie elle n'a besoin d'ajouter au concentrateur IAE que sa collaboration (si elle a besoin d'un traitement spécifique), ses OMS, ses mappings et son connecteur.
• Coût de migration des interfaces : Lors du changement d'une des applications interfacées (migration, changement de produit), peu de modifications sont nécessaires. Seuls le connecteur, le mappage ou la collaboration spécifique à l'application doivent être modifiés.

Inconvénients :

• Flux massif : Pour les flux massifs (par exemple : mise à jour de 10 000 articles en même temps), la logique du traitement unitaire de l'information est très lente. On préfèrera plutôt une solution ETL.
• Coût initial : Le coût de mise en place de l'infrastructure est assez élevé. Mais il se réduit grandement au fur et à mesure de l'ajout de nouveaux flux.
• Resynchronisation des bases : Suite à un incident (bug applicatif, erreur d'exploitation, endommagement de disque, ...), ou encore à l'enrichissement des structures de données, il faut resynchroniser les bases où les données sont copiées avec celle où les données sont en référence. Ce phénomène est malheureusement quasi certain, et même assez fréquent. Une procédure spéciale de resynchronisation est généralement nécessaire. Elle travaille sur des données statiques pouvant être volumineuses et non plus sur des événements. Une étude fonctionnelle est impérative. Il faut souvent ajouter des données de resynchronisation dans les bases (identifiant de rapprochement, date-heure de dernière mise à jour, ...). De fait, il faut doubler l'IAE de fonctionnalités plus proches de celles d'un ETL. Avant de proposer une mise à jour au fil de l'eau, il convient de commencer par étudier la procédure de resynchronisation. Il est fréquent qu'elle suffise à répondre au besoin. Sinon le génie de l'architecte doit s'exprimer pour trouver une solution modulaire et éviter la redondance des règles métier entre les deux outils. Il est souvent suffisant de répliquer par exemple toutes les 4h les données modifiées les 5 derniers jours. La période de 5 jours limite le volume. Le recouvrement de période permet, lorsque la procédure tombe en erreur ou lorsque la base source est restaurée ou réparée, de rétablir automatiquement la cohérence lors du passage suivant. La même procédure est utilisée pour réaligner l'intégralité des données en jouant sur la période. Ainsi, les règles de réplication sont toutes dans le même outil.

L'IAE dans l'entreprise

La mise en place d'un IAE nécessite une volonté d'unification de l'intégration des systèmes d'information de l'entreprise. Une phase d'étude d'urbanisation va permettre de :

• identifier la plupart des données métier de l'entreprise.

Par exemple : articles, commandes, fournisseurs, clients...

• définir les applications qui en seront maîtres.

Par exemple :

• L'application de gestion des fournisseurs sera maître des données fournisseur.
• Elle pourra les diffuser via l'IAE aux autres applications, qui pourront s'en servir comme données fournisseur de référence.

Ses données seront représentées dans l'IAE sous forme d'objet métier (OM).

On pourra alors construire des flux d'information métiers unifiés par lesquels chaque application spécifique peut partager ses informations avec les autres au sein d'une étape de l'organisation de l'entreprise.

Par exemple :

• Le service des achats a créé les fournisseurs qui permettront d'identifier les articles utilisés par le service de production.
• Ce service de production construira les produits vendus aux clients par le service des ventes.
• Lesdits clients seront suivis par le service après vente...

L'IAE n'apparaît comme une solution d'intégration pertinente qu'au sein d'une infrastructure complexe d'échange de données. Utiliser l'IAE pour connecter deux systèmes extrêmement simples serait aussi pertinent que manipuler une enclume pour extraire une noix de sa coquille.

On note qu'une nouvelle technologie semble se mettre en place face à l'IAE : l'Enterprise Service Bus (ESB).

Produits Commerciaux

Les principaux produits proposés sont :

• Antares de Enovacom
• BizTalk de Microsoft
• BlueWay SOA/EAI tactique de BlueWay
• Business Integration Server SEEBURGER
• Business Works de Tibco Software
• Cloverleaf, édité par la société HealthVision et distribué par E.Novation
• DataEXchanger de DataEXchanger
• Email2DB Intégration de flux Email.
• exteNd Composer de Novell
• iBOLT de Magic Software Enterprises
• JCAPS de Sun (ex. Seebeyond)
• InterSystems ENSEMBLE Universal Integration Platform de InterSystems
• iWay SOA Middleware de iWay Software, une société de Information Builders
• JEEBOP (ancien APILINK) de Wraptor
• Oracle SOA Suite de Oracle
• SAP eXchange Infrastructure de SAP
• Synchrony de Axway / Sopra Group
• TradeXpress de Generix Group (Generix Group)
• WebLogic Integration de BEA Systems
• webMethods de webMethods
• Websphere Process server succédant à WBI (ancien Crossworlds) d'IBM
• Websphere ESB d'IBM
• [1] de Fiorano
• BusinessWare de Vitria

Produits Libres

• Openadaptor iae compatible java/tomcat/jdbc
• OpenSyncro iae compatible java
• Mule iae compatible java
• Proteus iae compatible java/xalan/jdbc/jms/ftp/tibco
• xBus iae compatible java/tomcat/jdbc/message (jms)
• xmlBlaster serveur MOM sécurisé (LDAP crypt password) java compatible multilangage et multiprotocole (Corba, rmi, meail) et les requêtes (Xpath ,SQL-,JMS)
• J-EAI de Process One
• OpenEAI
• XAware
• FuseSource, ServiceMix, Camel

Autres projets

• Guaraná DSL -- Indépendant de la langue des solutions technologiques EAI au modèle

Liens externes

• L'EAI en sept questions

• Portail des entreprises
• Portail de l’informatique