Intégration d'applications d'entreprise - Définition

Introduction

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

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