Structuration de la communication dans les systèmes d’information Les EAI : Structuration de la communication dans les systèmes d’information

Objectifs du cours Découvrir et comprendre les concepts et les enjeux de l'intégration d'applications via les EAI, Connaître les différentes technologies de mise en œuvre, Balayer les offres d'outils EAI du marché.

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 ?

L’urbanisation «naturelle» Ou Comment en sommes-nous arrivés là ?

L’urbanisation «naturelle» Les SI se sont construits par ajouts successifs d’applications, Les besoins de communications entre applications  développements des interfaces, L’absence de réflexions sur l’ensemble de l’architecture du SI a conduit : AU MODELE SPAGHETTI Urbanisation « naturelle » pour ne pas dire « sauvage ». L’image de l’urbanisation vient à l’esprit car les SI se sont développés comme les bâtiments dans une ville. Au bout d’un moment, les responsables des SI éprouvent le besoin de redessiner l’architecture de leurs applications de façon plus cohérente. A Paris, c’est le baron Haussmann qui a retracé les grandes avenues, les grands axes que l’on connaînt encore aujourd’hui.

Présentation d’un cas réel Reprenons le schéma d’architecture applicative réelle d’un équipementier automobile, déjà vu lors du cours sur les ERP.

Exemple d’un système d’information et ses interfaces Organisation / structure de l’entreprise Divisions / Directions : Divers Unités : Pneu- matique Câblerie Capteurs Électronique (cartes & ordinateurs) Réparation Négoce de pièces Lignes autonomes : Pignons électronique Carters Montage Réparations Sites : Site 1 Site 2 Activité : Série Rechanges Transmissions Division pneumatique Division Électronique Cette structure s’explique par les cessions et rachats successifs de branches d’activité dans une société. L’architecture applicative qui en découle correspond aux différents besoins des différentes unités et aux logiciels correspondant.

Cartographie applicative du site n°1 SGDT Articles Nomenclatures GPAO Macro gammes Commerce Planification Achats Stocks Atelier Articles agréés En cours Commandes Ordre Fabrication Réceptions du jour PIC / PDP Factures fournisseurs Articles Nomenclatures Expéditions OF Mouvements BR Activité Catalogue QUALITE Imputations Prix standards manuel Exped. Prix standards manuel Comptabilité Industrielle Éléments Paie PRESENCE Facture VENTES BR : Bon de réception PAIE Personnel Gestion des Formations Paie CO FI TR Imputations Virements fournisseurs Virements Paie Comptabilité Générale (ERP 4) Contrôle Accès TRESORERIE Banques

Cartographie applicative du Site n°2 SIGA Paye Notes de frais Gestion Réparation Qualité Saisie d’activité MS Project Projets/ressources Pic /Plan dir. de prod. Saisie d’activité E déplacement GPAO Gestion de projet MRP Processus Négoce ? Stocks Achats Prod. Commerce Activité Reporting Prod Manager Gestion de config. Création / Màj Article GENEC CEC E Proc. (TradeXpress) CEC Création d’écritures comptables GENERIC : Génération écritures comptables FISC : Comptabilité industrielle & Génération écritures comptables FISS SIBA Compta (générale, analytique, auxiliaire) Facturation Contrôle facture Controlling Achats divers Module de comptabilité Interface

Traitement “classique” par interfaces spécifiques ou par EDI : Échange de Données Informatisées

Rappels sur l’EDI : l’ancêtre des EAI EDI = Electronic Data Interchange ou Échange de Données Informatisées : Échanges, d’ordinateur à ordinateur, de données concernant des transactions, en utilisant des réseaux et des formats normalisés, Transit des informations de l’émetteur vers le système d’un partenaire (via des réseaux) afin d’y être intégrées automatiquement.

Standards EDI Les standards d’organisations UN/EDIFACT : United Nations / Electronic Data Interchange For Administration, Commerce and Transport ANSI - American National Standards Institute ASC - Accredited Standards Committee X12 - order placement & processing, shipping & receiving information, invoicing, payment & cash application data Certains industriels ont créé leur propres normes : industrie automobile = norme ODETTE, industrie aéronautique : norme AECMA.

Architecture EDI Emetteur Récepteur application application Fichier interne Si même ERP Fichier interne Logiciel de traduction EDI Logiciel de traduction EDI Transferts de fichiers via FTP ou MQSeries Message EDI Message EDI Logiciel de comm. Logiciel de comm. Réseau

Message EDIFACT Structure UNB UNH I n t e r c h a g BGM M e s a g 1 RFF NAD DTM EDI Enveloppe Détails Article(LIN) Ligne 1 Article 8712345678913 Type EN Quant. 4 ...... ...... LIN LIN UNB et UNZ début et fin de message (enveloppe) UNH : début de message unitaire (Ex. une commande fournisseur ou une facture) BGM, RFF, NAD DTM sont des données dites en tête (Ex. n° client, adresse, référence de commande, …) LIN : une ligne détail de la commande (il peut y en avoir plusieurs), avec réf. Article, Qté, type, etc … UNT clôt cette partie du message UNH redémarre un nouveau message Ex. commande LIN ...... UNT UNH ...... Message 2 UNT UNZ

Exemple de message EDIFACT EDI Message UNB+UNOA:2+5412345678908:140801:1201' UNH+1+ORDERS:2:901:UN:EAN005' BGM+105+112233+950730' RFF+CT+123456+910101' RFF+CR+MR. BLOCK' NAD+DP+8711886500001:14' NAD+IV+8711886599001:14' DTM+002+060120' CUX+DEM:PC' FTX+PUR+1++PLEASE DEL.BEFORE 13.00' TDT++++++EMS' TOD+++FCA' UNS+D' LIN+1++8712345678913:EN++21:4' LIN+2++8710477100104:EN++21:2' IMD+F+++HANDLE THIS ITEM WITH CARE' UNS+S' UNT+16+1' UNZ+1+12345555' Explications Boîte “Enveloppe” émettrice du message. Entête du Message; type de message Message I.D. Programme No & Date etc.. Détails Contrat Détails Acheteur Adresse de livraison Adresse de facturation Date de livraison requise Devise Texte libre Conditions de livraison Détails Article ,, Texte Article Fin d ’ordre Fin du Message Des tables de définitions et des schémas d’échange (de correspondance) définissent quelles parties du message est utilisée pour mettre à jour les fichiers.

Les inconvénients de l’EDI Mise au point longue entre deux partenaires, à répéter à chaque fois Batch (la plupart du temps), Liaison point par point  autant de liens que de partenaires qui conduit : AU MODELE SPAGHETTI

8 applications = 28 interfaces N(N-1)/2 Le syndrome spaghetti Application 1 Application 4 Application 6 Application 5 Application 2 Application 8 Application 3 Application 7 8 applications = 28 interfaces N(N-1)/2

Les raisons d’évolution vers les EAI

L’évolution des SI (1/3) Facteurs de changement : mutation incessante des marchés et des pratiques commerciales exigence de réactivité accrue à tous les niveaux de l’organisation, banalisation des produits - érosion de la fidélité clients besoin de différenciation des marques, croissances externes, fusions, partenariats besoin de flexibilité des S.I., de consolidation des données, de cohérence stratégique.

L’évolution des SI (2/3) Développement historique du parc applicatif des entreprises : budget et conception à un niveau départemental  urbanisation «naturelle», limites technologiques au moment de la conception, succès des technologies Client/Serveur, applications légères centrées sur une base de données dédiée, confort d’exploitation d’un réseau local.

L’évolution des SI (3/3) Besoins d’intégration & avènement de standards autour d’Internet : globaliser de la chaîne de valeur de l’entreprise : ERP, SCM, CRM, BI, PLM, … éviter les coûts d’une refonte de S.I. <-> développer rapidement le e-business, s’appuyer sur l’existant et s’affranchir de son hétérogénéité, disposer, de manière permanente, des ses systèmes de commerce électronique.

Émergence de nouveaux applicatifs «périphériques» : 3 exemples

En synthèse : pourquoi un EAI ? (1/2) Convergence de faits technologiques + évolutions économiques : Spécialisation des applications, Ouverture des ERP, Explosion des intranets et des portails, Applications CRM, SCM et e-business, Refonte des processus métier : réduction de leur durée de vie, souplesse guidée par le besoin de modifier ses règles métiers, recherche d’automatisation de ses processus. Au total, les raisons ne sont pas directement technologiques Spécialisation des applications : spécialisation des métiers et complexité croissante des besoins  multiplication d’applications spécialisées nécessitant intégration et partage de données, Ouverture des ERP : qui ne couvrent pas tous les besoins. Leur ouverture et leur capacité à s’intégrer avec d’autres applications ou autres systèmes est un plus, Explosion des intranets et des portails qui véhiculent volume et qualité d’informations importants, Applications CRM, SCM et e-business qui accroissent leur efficacité par partage de données, intègrent la gestion de la chaîne logistique et tend vers l’e-business avec l’interconnexion des partenaires, Refonte des processus métier : environnement éco., multiplication des concurrents, réduction du cycle de vie des produits  processus métiers marqués par 3 phénomènes convergents : réduction de leur durée de vie, souplesse guidée par le besoin de modifier ses règles métiers, recherche d’automatisation de ses processus.

En synthèse : pourquoi un EAI ? (2/2) Vitesse d’évolution des entreprises (S.I. pas assez réactifs), Recherche du meilleur logiciel répondant à un besoin donné et au coût moindre (+«clé en main»), Contraintes d’intégration d’applications d’autres sociétés (achats, fusions ou restructurations), … Conclusion : nécessité d’intégrer l’ERP ou l’ensemble des composants du SI (source des données opérationnelles internes à l’entreprise)  avec les autres applications internes et/ou externes à l’entreprise via un EAI. Exemples de solution clé en main + métier : logiciel spécialisé Qualité ou gestion à l’affaire ou encore de planification

Les EAI : Ou … La mort annoncée du concept «Spaghettis» …

Rappel du syndrome «spaghettis» Application 1 Application 4 Application 6 Application 5 Application 2 Application 8 Application 3 Application 7 8 applications = 28 interfaces N(N-1)/2 8 applications donc 8 x 7 = 56 / 2 = 28 interfaces !!!!!!!

EAI Ce que propose l’EAI ? Application 1 Application 8 Application 2

Le déport de l’interfaçage vers l’EAI Application Reste dans Application Logique Applicative Ordonnancement Extraction EAI L’interface est déporté dans Transformation Émission Routage Suivi des flux

EAI : définition L'objet de l'EAI Enterprise Application Integration = intégration des applications de l'entreprise : c’est l'intéropérabilité et l'organisation de la circulation de l'information entre des applications hétérogènes, c'est faire communiquer les différentes applications de l'entreprise, voire même celles des partenaires (clients, fournisseurs, sous-traitants, co-traitants, …) Un projet d'EAI consiste : à mettre en place une architecture de communication entre les différentes applications, à développer des connecteurs (middleware) permettant d'interfacer des applications utilisant des protocoles de communications différents, Au-delà de l'intéropérabilité entre applications, l'EAI peut, aussi, permettre de définir un Workflow entre applications.

Finalité d’un EAI : «fluidifier, simplifier et structurer» les échanges entre applications

Les objectifs d’un EAI Un outil d’EAI n’intervient pas dans le fonctionnement interne des applications maîtrisant les fonctions et règles métier Il permet : de transmettre des données d'une application source vers une application destination (avec transformation éventuelle), de fédérer progressivement les échanges et les flux entre applications, de connecter de nouvelles applications à un «bus» d’échange unique en fonction des besoins d’interfaçage, d'orchestrer le déroulement des processus métier via: l'organisation de l'exécution des composants du SI impliqués dans le processus, la prise en charge des interactions entre ces composants, de mettre en œuvre des règles d’urbanisation d’un SI.

Principes généraux d’un EAI

Principe général d’un EAI Applications existantes et futures pouvant communiquer entre elles et partager des informations de façon simple efficace, Utilisation d'un bus de communication en lieu et place de communications directes d'application à application.

Les périmètres fonctionnels impactés Place de marché Privée - publique Commerce électronique Comparateurs Moteurs de recherche Datawarehouse décisionnel BI Clients CRM - ERP Connaissance KM, archivage EAI Fournisseur SCM - EDI Téléphonie Nomades, PDA Vendeurs SAV Siège ERP Back - office Point de vente Front - office Dépôts - Usines logistique

Les périmètres techniques impactés

Les trois types d'intégration Orchestration d’un ensemble de tâches à effectuer par différentes applications avec ou sans intervention humaine Intégration au niveau des processus métier Orientation métier Intégration au niveau des applications Basée sur des logiciels de messagerie orientés réseau (solution EAI + complète), avec produits de middleware orientés messages (MOM) MOM = Message Oriented Middleware Échange et partage des données applicatives via base de données commune, XML (Extensible Markup Language) particulièrement utile pour l'intégration applicative inter-entreprise, Intégration au niveau des données Complexité technique

Exemple d'intégration au niveau des données EAI propose un point d'intégration unique au travers de son bus de communication

Les outils EAI d’intégration au niveau des données Les outils EAI d’intégration de données proposent : des services de transformation de données, la sécurisation et la fiabilisation des échanges, l’utilisation de connecteurs standard d'accès aux sources de données, Mais ils court-circuitent la couche métier et les règles de gestion ne sont pas vérifiées dans les transferts, Exemple : base de données avec données stockées incluant des règles de gestion (appartenance à un gpe). L’intégration niveau données ne tient pas compte de cette couche et se connecte directement à la base de donnée  atteinte d’intégrité des données (vue métier). Appartenance à un groupe : code client appartenant à un gpe de clients, lui-même permettant la consolidation financière sur un ensemble de comptes client au niveau du plan comptable

Les trois types d'intégration Orchestration d’un ensemble de tâches à effectuer par différentes applications avec ou sans intervention humaine Intégration au niveau des processus métier Orientation métier Intégration au niveau des applications Basée sur des logiciels de messagerie orientés réseau (solution EAI + complète), avec produits de middleware orientés messages (MOM) MOM = Message Oriented Middleware Échange et partage des données applicatives via base de données commune, XML (Extensible Markup Language) particulièrement utile pour l'intégration applicative inter-entreprise, Intégration au niveau des données Complexité technique

Intégration au niveau des applications L’intégration au niveau des applications consiste à utiliser les API métier pour faire communiquer les systèmes. Exemple : appartenance à un groupe : code client appartenant à un gpe de clients, lui-même permettant la consolidation financière sur un ensemble de comptes client au niveau du plan comptable

Exemple d'intégration au niveau applicatif Manipulation des données sécurisée puisque règles métier interposées lors des traitements. Une applet Java = petite application Java. Différents navigateurs Web existent et ils peuvent souvent être installés sur différentes plates-formes. L'architecture Java permet de garantir que les applets Java s'exécutent sur différentes architectures.

Remarques sur l’intégration au niveau applications (1/2) L’intégration au niveau des applications est un bon départ en vue d’une exposition des API métier  Web Services Mais l’intégration de la couche métier n'est pas toujours aisée : toutes les applications ne fournissent pas des API métier, les applications anciennes des environnements centralisés sont souvent des blocs monolithiques sans notion de couche, notamment, leurs seules interfaces sont constituées de grilles d'écran, un important travail de restructuration est souvent nécessaire en préalable à toute intégration d’applications, La couche de présentation gère l’interface utilisateur avec les systèmes, cette couche peut constituer un point d'intégration potentiel (intégration au niveau «écran») = revamping applicatif pour EAI. Revamping : ré habillage applicatif

Remarques sur l’intégration au niveau applications (2/2) Même un API métier disponible n’est pas toujours directement exploitable tel quel : protocoles de communication propriétaires  création d'une sur-couche d'adaptation, Stabilité des API applicatifs dans le temps car : c’est le point d'entrée de l'intégration, une modification interne dans une application ne doit, théoriquement pas, entraîner une modification de l’API métier, si tel est le cas  lourdeur de la gestion de l’intégration au niveau applicatif, Mode synchrone en request/reply, non recommandé plutôt un mode asynchrone court dans lequel l’EAI se charge d’appeler l’API. Revamping : ré habillage applicatif

Intégration au niveau des processus métier Intégrations au niveau données et applications focalisées sur aspects techniques de l'intégration, Intégration au niveau des processus métier = une approche fonctionnelle de l’intégration d’applications, Ce sont les processus métier qui pilotent l’intégration. Rappel : Processus métier = enchaînement de tâches qui ont pour objectif final de fournir un résultat matérialisable au niveau du métier.

Les trois types d'intégration Orchestration d’un ensemble de tâches à effectuer par différentes applications avec ou sans intervention humaine Intégration au niveau des processus métier Orientation métier Intégration au niveau des applications Basée sur des logiciels de messagerie orientés réseau (solution EAI + complète), avec produits de middleware orientés messages (MOM) MOM = Message Oriented Middleware Échange et partage des données applicatives via base de données commune, XML (Extensible Markup Language) particulièrement utile pour l'intégration applicative inter-entreprise, Intégration au niveau des données Complexité technique

Exemple d'intégration au niveau des processus métier Servelt = Programme Java s'exécutant sur un serveur

Intégration au niveau des processus métier BPI (Business Process Integration) BPI = concevoir des processus métier et de les relier aisément aux applications sous-jacentes, Les produits de BPI utilise un moteur d'orchestration connaissant les étapes & données du processus et chargé : de l'aiguillage des flux de données dans le cadre des processus métier, du suivi de l'état d'avancement de chaque processus, d’activer des alertes en cas de déviation du fonctionnement.

Les outils EAI d’intégration au niveau des processus métier Les produits de BPI proposent : un support natif de certains processus classiques (briques élémentaires prédéfinies et configurables), la combinaison de plusieurs briques = un processus métier, un outil de modélisation graphique les agrége, sur cette base, le logiciel de BPI se charge : de générer automatiquement le code nécessaire aux interactions entre les actions élémentaires, et de donner les instructions au moteur pour exécuter les processus définis.

En résumé En complexité croissante, les différents types d’intégration sont : l’intégration au niveau des données (transmission de données avec des transformations éventuelles d’une source à une destination), l’intégration au niveau des applications (utilisation d’API métier pour transférer ou intégrer des flux de données), l’intégration au niveau des processus métier (orchestration d’un ensemble de tâches à effectuer par différentes applications avec ou sans intervention humaine).