Intégration d'applications d'entreprise

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

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 dix 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 Objet Métier 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 :

• 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ées 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 : à la suite d'un incident (bug applicatif, erreur d'exploitation, endommagement de disque, ...), ou encore de l'enrichissement des structures de données, il faut resynchroniser les bases où les données sont copiées avec celles 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 quatre heures les données modifiées les cinq derniers jours. La période de cinq 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.

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.

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

• L'EAI en sept questions