Les EAI :

1. Les EAI : Structuration de la communication dans les systèmes d’information Partie 3

2. Sommaire • Point de situation de la plupart des SI • La notion d’urbanisation «naturelle», • Cas réel de cartographie applicative, • Les besoins d’évolution vers les EAI • Définitions et composition d’un EAI • Les principes généraux, • Les solutions techniques et les outils complémentaires, • La sécurité et les EAI, • Revue des différentes architectures EAI possibles, • Projet d’implantation d’un EAI • Structure de projet et points clés • Quelques cas clients • Le marché des EAI • Conclusions • Avantages et inconvénients des EAI, • Quelle(s) relation(s) future(s) entre ERP et EAI ?

3. Sécurité et EAI

4. Fonctions sécurité d’un EAI • EAI = support de suivi et de maîtrise des SI intégrant des fonctions sécurité : • sécurisation des flux, • sécurisation des fonctions d'administration et d'exploitation, • sécurisation de l'utilisation des Web Services.

5. Exemple d’architecture sécurisée

6. Sécurité des fluxProblématique générale • Flux de données échangés entre applications d’un SI reposent encore sur des transferts de fichiers, • Sécurité assurée via login/password, parfois en clair dans des fichiers batch ! • Une infrastructure d’EAI doit offrir les services de sécurité suivants : • authentification (flux ou message), • intégrité, • confidentialité, • garantie de non répudiation des données échangées au sein du SI ou avec l’extérieur, • gestion des habilitations pour répondre à des questions du type : « message émis par X autorisé ? Si oui, valide en terme de format et valeurs des données ? • référentiel des émetteurs et destinataires (machines, personnes), • flux signé ou crypté soit dans sa globalité, soit par message.

7. EAI, VPN au niveau métier ? • L’EAI = tunnel sécurisé déchargeant applications & utilisateurs de tâches de sécurité, • EAI «VPN intelligent» grâce à ses fonctions de sécurité (de plus haut niveau que les VPN classiques), • Implications sur la PKI et les certificats des entités en présence : • EAI intra-organisation : applications / personnes avec certificats relatifs à leur fonctions* • EAI inter-organisations : échanges entre les organisations avec certificats délivrés par une autorité tierce (ou par un échange de certificats racine entre les PKI des # organisations)**

8. EAI, simple outil de routage ou VPN intelligent • Simple outil de routage : • service rendu = garantie de livraison • implication = envoi de message chiffré non connu de l’EAI (récupération de la clé publique du destinataire) •  émetteur effectue une partie du routage avec structure complexe de ses messages (pré-formatage en fonction des destinataires) • VPN intelligent : • utilisation uniquement de la clé publique de l’EAI pour le chiffrement, • intégralité des tâches effectuée par l’EAI (routage, formatages, connexions, horodatage, vérification de validité de certificats, garantie de livraison, confidentialité, intégrité, …).

9. EAI, firewall au niveau métier • En inter-organisations, l’EAI peut être partie intégrante de la politique et de l’architecture de sécurité (contrôle d’accès et d’habilitations de haut niveau), • L’EAI outil de filtrage à orientation métier avec fonction de contrôle d’accès : • En frontal avec l’extérieur: • l’EAI peut refuser l’entrée de flux en fonction de leur signature (certificats non valides, provenance non reconnue, Autorité de Certification douteuse, …), • ET en fonction de la non validité des messages (format incorrect ou obsolète), • Plan technique :possibilité d’architecture basée sur 2 instances EAI: • une en DMZ et en contact avec l’extérieur, • une dans l’Intranet (MZ), • L’instance sécurisée en Intranet ne voit, hors de sa zone, que l’instance en DMZ. L’instance en DMZ ne communique qu’avec l’instance en MZ et effectue tous les filtrages «firewall métier» (avec des filtrages sur l’identité des interlocuteurs, sur le format des messages, sur le contenu des messages, …)

10. Exemple d’EAI firewall sur les flux de données Criticité des informations permettant des contrôles en DMZ doit être estimée avant toute mise en place de filtrages. Exemple : pas de stockage en DMZ d’information à caractère confidentiel.

11. Sécurité de l’administration et de l’exploitation facilités • Le bus de communication EAI donne une vision globale des données échangées entre applications. • Points importants : • représentation graphique du paramétrage et de la configuration des flux de données (certains outils EAI), • supervision (suivi des flux, gestion QoS, gestion des alarmes métier) au niveau des infrastructures techniques d’échanges (équivalent des outils de supervision réseau mais au niveau applicatif) ET au niveau métier (utilisateur final), • Un Information Flow Administrator peut superviser et sécuriser les flux de données du SI (comme un DB Administrator au niveau DB) • Gestion du dialogue applicatif : «qui dit quoi, comment, à qui et quand».

12. Sécurité, EAI et Web Services • Fort potentiel des Web Services pour accroître l’interopérabilité des applications, • Avantages de l’utilisation des Web Services dans une infrastructure EAI : • rapidité de mise en place (exposition ou accès à un service Web) • centralisation des problématiques d’interfaçage, • conservation des aspects métier, dans les applications, • Utilisation du Web Service comme connecteur universel potentiellement.

13. Exemple utilisation des Web Services via une infrastructure EAI

14. Un exemple opérationnel : GROUPAMA (SANS EAI) • GROUPAMA a mis en place une architecture EAI, qui a permis : • d'automatiser et de sécuriser les échanges de données (sinistre d'un assuré), • processus avant mise en place de l'EAI : • appel téléphonique de l'assuré au centre régional, • enregistrement du sinistre dans SI local, • fax d'une mission à un prestataire qui affecte mission à un réparateur, • rappel de l'assuré, • enregistrement de la mission dans SI local, • Retransmission des infos au centre régional (tps de traitement d'une mission imposé au prestataire : maxi 15 mn).

15. Un exemple opérationnel : GROUPAMA (AVEC EAI) • Contraintes : • sécurisation des flux échangés • décentralisation des acteurs inclus du processus, • automatisation des échanges entre centres régionaux et prestataires, • communication asynchrone de faibles volumes de données, • rapidité des flux, • pas d’installation d'application cliente, ni de plate-forme imposée chez le prestataire (utilisation de formulaires Web de saisie de données mission en Extranet) • non-intrusivité de l'EAI dans les applications back-office des centres régionaux, • Processus AVEC mise en place de l'EAI : • envoi automatique d'une mission dans la boîte aux lettres du prestataire dès sa création dans le SI du centre régional, • traitement de la mission par le prestataire (sélection d'un dépanneur) via une IHM permettant validation de l’utilisateur (certificat numérique), • traitement par le prestataire, • retour automatique des informations au centre régional.

16. Normes et standards de lacouche Sécurité (partie réseau)

17. Normes et standards de lacouche Sécurité (partie applicative)

18. Conclusions sur la sécurité • L’EAI vu comme outil de sécurité au niveau métier, • Remonte dans les couches applicatives les fonctions classiques de sécurité (situées dans les couches techniques et réseau), • Centralisation et facilitation de mise en place de la sécurité par : • mutualisation des différents services de sécurité, • services intégrés dans un workflow, • EAI, en tant que bus d’échange du SI = autorité de référence en matière de sécurité.

19. L’architecture en résumé Gestion de processus métier Repor- ting Routage / Mot. Intégr. Administration Sécurité Paramétrage Transformations Develop- pement Connecteurs / Accès aux données Transport des messages Réseau

20. Différentes architectures techniques Revues des architectures possibles

21. Architecture étoile Architecture «Étoile» : • permet le traitement de très gros volumes localement, • des interface directes point à point facile et rapides à mettre en œuvre (si nombre de systèmes limité), • Au delà d’une certaine complexité (une dizaine de sources d’information), mieux vaut opter pour l’architecture «Bus» pour éviter le «spaghetti-ware». Serveur central SGBD ERP Spécifique Stockage Interfaçage direct point à point

22. Architecture client - serveur Architecture «Client-Serveur» : • adaptée aux besoins de la distribution (caisses), • aux automates industriels, de comptage, • aux travailleurs itinérants (forces de ventes, services après vente, courtiers …). Tous les clients dialoguent avec un serveur central qui les administre (scripts, déclenchements) à distance. Serveur central clients Caisse interface spécifique messages normalisés SFA KM SGBD ERP Clients légers «embarquables»

23. Architecture collaborative Architecture «Collaborative» : pour les besoins de type B2B entre entités autonomes d’une même entreprise, ou des fournisseurs, logisticiens et clients externes. Serveur Serveur Place de marché Client ERP SGBD Stockage Spécifique Logistique Fournisseur Serveur Serveur Entités autonomes avec communication au besoin

24. Architecture bus • Architecture «bus» : • Pour un nombre de sources et de destinations d'information très nombreuses, • avec serveur physique ou virtuel partagé en frontal de chaque source d’info., • réalisant la demi-interface entre messages sortants et entrants, • bus normalisé (généralement XML). Architecture conçue pour traiter des messages (en non du batch) et repose sur un principe de publication/abonnement basé sur les MOM MSMQ ou MQ Series (voire même Email). Stockage ERP SGBD Spécifique Superviseur Demi - spécifique interface publieur abonné abonné abonné Messages normalisés XML via : MS MQ, MQ Series, Email, Http, Soap

25. Les standards utilisés dans le monde des EAI

26. Un standard de développement : J2EE

27. Un standard particulier : le standard d’échange XML • XML est un standard de description de documents • normalisé par le W3C début 98, • utilisé au départ au même niveau que l’EDI, • étendu à l’échange de données entre environnements hétérogènes, • soutenu par des acteurs majeurs du marché : Microsoft, IBM, SAP, … • nombreux dérivés métiers (initiatives non standard), • Des ajouts permettent de passer de la description de document à celle d’un flux de données : • XSL (validé) : transformation de documents par application d’un modèle, • XML Schema (validé) : typage de données, • Xpath, XPointer : accès à des parties de documents, • XLink : liens multi-cibles, • XML Query : intégration de SQL dans le document, • XSL FO, SVG : formatage de documents paginés (pdf par exemple), • Domaines d’application : • commerce électronique B2B, EDI - Intégration d’applications hétérogènes - Gestion de contenu de type GED - Interfaces Web.

28. Éditeur Transformation page HTML API Données structurées XSL : feuille de style document XML document papier Règles de structuration déclaration DTD Présentation XML : rappel des composants et mécanisme • Un flux XML sera émis par un programme selon un format et une syntaxe convenus, • A la réception, il sera dépouillé, décodé, contrôlé par un «parser» qui en extraira les données utiles.

29. Quelques cas clients

30. Intégration généralisée PAB Arcelor Construction Portail CRM Habilitation/Produit/Transport J2EE/Websphere Clients, fournisseurs, partenaires factures Application Sofie Négoce/Achat/Vente Spécifique sous AS/400 EDI Fax,FTP, Email, XML EAI Datawarehouse Windows Application table de correspondance Suivi Access/Windows • Inter-applicatifs interne + DWH • 2) Interconnexion Portail CRM • 3) Échange B2B Anael Comptabilité AS/400 Contrôle des factures ERP Intentia Movex Achats/Vente/GPAO AS/400

31. Balance âgée Crystal Report Datawarehouse, Business Intelligence et diffusion • Renault Crédit Suisse Extraction des sept tables nécessaires à la balance âgée Serveur HP 9000 Progiciel «CREDX» Unix - Sybase Server Enterprise Crystal Report Datawarehouse PC Exploitation Windows 95 EAI Recopie de la table de balance âgée Envoi via Email de l’état Excel généré par Crystal Report à cinq destinataires de la société. Extraction des données via ODBC pour Sybase (100.000 lignes) Réseau local TCP/IP à 10 Mb/s

32. E-business Intégration serveurs Web, BackOffice, Logistique (logique de flux) • Télémarket (supermarché en ligne) AS400 ERP - Production Server Enterprise Serveur d’exploitation Windows 2000 Réseau local TCP/IP à 100 Mb/s Windows NT Serveur Web EAI Serveurs de production Accès Internet via ligne spécialisée AIX RS6000 Logistique Internet Commandes des clients sur le Web Base de traçabilité des flux et de Roll Back au besoin Alertes par GSM, E-Mails, Imprimante

33. Sommaire • Point de situation de la plupart des SI • La notion d’urbanisation «naturelle», • Cas réel de cartographie applicative, • Les besoins d’évolution vers les EAI • Définitions et composition d’un EAI • Les principes généraux, • Les solutions techniques et les outils complémentaires, • La sécurité et les EAI, • Revue des différentes architectures EAI possibles, • Projet d’implantation d’un EAI • Structure de projet et points clés • Quelques cas clients • Le marché des EAI • Conclusions • Avantages et inconvénients des EAI, • Quelle(s) relation(s) future(s) entre ERP et EAI ?

34. Projet d’implantationd’un EAI Urbanisationdes SI

35. Initialisation d’un projet EAI • L’intégration d’applications hétérogènes est une opération complexe, • Les solutions d’EAI facilitent la mise en oeuvre d’un projet d’intégration, • mais … • une réflexion préalable est nécessaire pour : • EAI vraiment nécessaire, • identifier les candidats (applications, processus), • qualifier le type d’intégration voulue, • analyser les autres critères (hommes du métier définissant les priorités d'intégration et décidant de ce qui est à intégrer.

36. EAI ? Pour quels projets ? Identifier et qualifier Avant d’être un concept, l’«EAI», est surtout une réponse opérationnelle à un projet/besoin • Interface : ERP, CRM, bases de données, applications spécifiques, fichiers, front office-back office … ou mise en place d’un ERP, migration, • ETL / Datawarehouse / Réplication / Référentiel, • Transfert et intégration multi-sites : plate-forme d’échange multi-formats (EDI spécifique, XML, fichiers propriétaires, …), • Échanges B2B (EDI spécifique, messages TCP, fichiers FTP…), • Automatisation des échanges : robot d’exploitation • Publication de l’information : Alimentation de portail / Diffusion multi-canaux, • Personnel itinérant : synchronisation des laptops, • Supervision et monitoring des échanges entre machines.

37. Outils ETL versus outils EAI EAI généralement moins adaptés à l’alimentation des bases de donnéesdécisionnelles que les ETL (Extract, Transform and Load) Comparaison des points techniques entre ETL et EAI.

38. Positionnement de l’EAI au sein du SI • Urbanisation = démarche globale, transverse à tout le SI, • Cible visée : un système réorganisé autour de ses fonctions et de ses référentiels partagés, • Transition vers une architecture fonctionnelle = plan d'urbanisation : • étapes du chantier, • structuration du SI en blocs fonctionnels (zones, quartiers et îlots) faiblement couplés, • échanges d’informations par voies de communication.

39. EAI et urbanisation du SI NOUVEAUX PROJETS E A I RÉFÉRENTIELS SYSTÈMES EXISTANTS URBANISATION Dans la terminologie d’urbanisation, les applications contenues dans un «quartier fonctionnel» communiquent avec des applications d’un autre quartier en passant par des voies de communication fournies par l’infrastructure EAI.

40. Quel projet pour quel EAI ?

41. L’ EAI tactique

42. Typologie détaillée des projets d’intégration EAI • Projets d’intégration de l’informatique existante : • environnements propriétaires, applicatifs spécifiques et bases de données non standards, • Projets d’intégration de progiciels ERP et CRM : • l’EAI intervient comme accélérateur dans la mise en place et la maintenance de ces nouvelles solutions, • Projets d’intégration de progiciels e-business pour ouvrir les SI vers l’extérieur: e-procurement, places de marché: • choix des produits utilisés faisant intervenir la qualité des parseurs XML. On parle alors «véritable» EAI, • Projets d’urbanisation passant par l’examen de la gestion des échanges inter-applicatifs au sein du SI d’entreprise mais aussi des échanges inter-applicatifs partenaires : • choix de la solution faisant intervenir les capacités B2B et la gestion des processus métiers. • Intégration par le haut «top down» projets structurants pour les entreprises s’inscrivant dans une réorganisation des processus métiers.

43. Choix d’un EAI :Critères comparatifs (1/2) • Flux techniques / Transformation & Routage • Gestion de référentiel et de formats pivots / méta données • Processus métier / Workflow / BPM • Administration & Supervision • Connectivité • Connecteurs techniques • Connecteurs applicatifs • Web Services • Kit de développement de connecteurs • Fonctions supportées

44. Choix d’un EAI :Critères comparatifs (2/2) • Transport / MOM • Nature de middleware utilisé au niveau de la couche transport, • Fiabilité du middleware, • Performances du middleware, • Types de protocoles, • API utilisateur, • Sécurité • Connexions applicatives, • Couche transport, • Méthodologie supportée • Installation & intégration • Installation, • Déploiement, • Architecture ciblée, • Apprentissage.

45. Autres paramètres techniques (1/2) • Volume  moyen de données à transférer dans chaque message, • Types de transfert à privilégier (batch ou temps réel, mode synchrone ou asynchrone), • Éventail de connecteurs proposés par l’outil : • disponibilité des connecteurs correspondants aux applications à intégrer, • connecteurs compris dans l’offre de base ou à acquérir en plus, • existence d’un outil de développement de nouveaux connecteurs si l’on souhaite intégrer des applications spécifiques, • Possibilités offertes par l’outil de BPM (niveau de modélisation, prise en compte des interventions humaines (workflows), …), •  Ergonomie de l’outil.

46. Autres paramètres techniques (2/2) • Standards supportés (XML, SOAP, JAVA, JCA, …) et degré d’indépendance de l’outil par rapport à la gamme de produits d’un éditeur particulier, • Performances nbre de message traités/s, temps moyen de transfert des messages, capacité de montée en charge, …, • Facilités d’installation, de test, de déploiement, d’administration et d’exploitation offertes (EAI ne proposent pas souvent d’outils de supervision, autres que le simple «fichier de log»), • Plates-formes serveur et clientes nécessaires pour pouvoir mettre en œuvre l’outil (systèmes d’exploitation supportés, espaces mémoire et disque nécessaires, …).

47. Une structure de projet EAI :un exemple d’instances de projet Comité de Pilotage Comité d’urbanisation Comité de Projet(s) Équipes MOE Équipes MOE Projet Référentiels Équipes projet(s) EAI Selon complexité du projet

48. Les acteurs d’un projet EAI (1/2) • Comité de pilotage : • Direction(s), DSI, chef(s) de projet(s) qui : • définit les objectifs, • veille à impliquer les acteurs identifiés, • s'assure du respect des objectifs, • Comité d’urbanisation : • élaboration de la cartographie, urbanisée du SI, • architecture fonctionnelle cible  cadre de référence • formalisation de règles de construction et d’évolution des services applicatifs indépendamment des briques techniques,

49. Les acteurs d’un projet EAI (2/2) • Comité de projet Référentiels : • identifier et définir les référentiels partagés du SI, • identifier et définir les formats pivots • Équipe(s) de projet EAI : • Compétences métier et technique pour : • établit des normes de construction du socle d'intégration, • concevoir l'architecture, • Mettre en place (réalisation) • Préparer l’exploitation.

50. Points clés d’un projet EAI (1/2) • Stratégie informatique établie en fonction de la stratégie et des objectifs de la société • Compréhension approfondie : • des processus métier, • des modèles de données, • des systèmes et applications en place, • Planification de l’ensemble du processus projet : • identification des besoins, • sélection des éditeurs en fct de la mise en oeuvre et des besoins à venir) • Architecture EAI (modèles de processus et besoins d’intégration) formulée à partir de la stratégie informatique et d’urbanisation établie et contrôlée : • outils d’EAI et éditeurs évalués (maquettages), • responsabilités et les priorités établies, • solutions et étendue de l’intégration prise en charge par la technologie prises en compte et évaluées.