DOSSIER SUR L'INTEGRATION D'APPLICATION EN ENTREPRISE GROUPE E.A.I.

Transcription

1 DOSSIER SUR L'INTEGRATION D'APPLICATION EN ENTREPRISE GROUPE E.A.I. Version Date Foncions et tâches Identité /12/2003 Au 01/02/2004 Rédacteur Benjamin Descamps Sébastien Brunin François-Xavier Salengro /02/2004 Au 03/03/2004 Rédacteur Benjamin Descamps Sébastien Brunin François-Xavier Salengro /03/2004 Au 25/03/2004 Rédacteur Benjamin Descamps Sébastien Brunin François-Xavier Salengro /03/2004 Au 03/04/2004 Rédacteur, intégration des parties 2 et 3 Relectures Benjamin Descamps Sébastien Brunin François-Xavier Salengro /04/2004 Au 25/04/ /04/2004 Au 30/04/2004 Rédacteur, finalisation des parties 2 et 3 Relectures Relectures et validation du dossier dans son ensemble. Benjamin Descamps Sébastien Brunin François-Xavier Salengro Benjamin Descamps Sébastien Brunin François-Xavier Salengro Destinataires : Messieurs Raynal & Morel. Le 26/04/2004 Page 1 sur 95

2 Sommaire : Introduction 3 Partie 1 L intégration 4 Titre 1 Les différents environnements applicatifs 5 Chap. 1 Evolution des technologies des systèmes d information 5 Chap. 2 Les méthodes d analyse et différentes solutions 10 Titre 2 Concepts et importance de l intégration 20 Chap. 1 Naissance du marché et de son évolution 20 Chap. 2 Les indispensables pour mettre en place son intégration 23 Partie 2 Outils et plates-formes d intégration 35 Titre 1 Choisir sa plate-forme d intégration 35 Chap. 1 EAI (Enterprise Application Integration) 36 Chap. 2 ESB (Enterprise Service Bus) 40 Chap. 3 EII (Enterprise Information Integration) 43 Chap. 4 Orchestration de services 44 Chap. 5 Conclusion 46 Titre 2 Panorama des outils d intégration 47 Chap. 1 BizTalk 47 Chap. 2 L offre Tibco 48 Chap. 3 L offre Sybase 50 Titre 3 Le marché de l intégration en France 53 Titre 4 Critères comparatifs sur l EAI 55 Partie 3 Implémentation d un processus avec BizTalk 66 Titre 1 Introduction 66 Chap. 1 Description du scénario 67 Chap. 2 Fonctionnalités mises en oeuvre 67 Chap. 3 Architecture de la solution 68 Titre 2 Implémentation de la solution 70 Chap. 1 Schémas 70 Chap. 2 Orchestration 71 Chap. 3 Publication des Web Services d invocation de l orchestration 79 Titre 3 Formulaire d approbation des articles 80 Titre 4 Formulaire InfoPath d invocation 82 Titre 5 Formulaire Intranet 84 Titre 6 Extensions 85 Chap. 1 Envoi des articles par 85 Chap. 2 Agrégation de contenu en ligne 85 Titre 7 Conclusion 86 Conclusion 87 Glossaire 88 Table des matières 92 Table des schémas 95 26/04/2004 Page 2 sur 95

3 Introduction Ce projet réalisé dans le cadre des travaux dirigés de Méthodologie des Systèmes d Informations au CNAM de LILLE, lors de la session , a pour but de traiter l intégration d applications en entreprise. Les différentes évolutions techniques et architecturales des applications, environnements et systèmes informatiques ; qui ont conduit les entreprises à disposer de systèmes et de plateformes informatiques hétérogènes, posent maintenant le problème de la communication et de l interconnexion entre toutes ces plateformes applicatives. De nos jours, et suite à l accroissement important de la communication entre les différents acteurs du monde économique, industriel, de plus en plus d entreprise souhaitent échanger des informations entre elles. De ce fait, il devient très utile et nécessaire, après avoir traiter le problème à l intérieur même de l entreprise, d élargir cette réflexion pour aborder les principales difficultés qui peuvent exister dans la mise en place d une passerelle communicante entre l entreprise et ses partenaires. Toutes ces informations nous amènent à nous poser, et à essayer de répondre à la problématique suivante : Comment choisir et intégrer, parmi les différentes technologies et architectures disponibles, une solution technique d EAI (Enterprise Application Integration) adaptée au système d information inter et/ou intra entreprise? 26/04/2004 Page 3 sur 95

4 Partie 1 L intégration Il existe dans le jargon informatique quantité de mots dont la définition ne vient pas immédiatement à l esprit. Le terme «intégration» en fait partie. Si on cerne le mot et sa fonction informatique, en fournir une description précise n est pas aussi facile que cela. L intégration cache en effet, une multitude de réalités. On peut penser à trois types d intégrations : logicielles, matérielles ou technologiques. Au niveau de l entreprise et de son environnement applicatif, l intégration n est pas à prendre à la légère. Par exemple, quand on change l outil de bureautique, comment effectuer la migration ou encore récupérer les anciens documents? Une autre façon d interpréter le terme de l intégration est de citer la manière d intégrer entre elles des applications et des données hétérogènes. C est sans doute le défi le plus important de l intégration logicielle. Car aujourd hui l environnement applicatif est souvent diversifié, avec des plates-formes hétérogènes et des types de données parfois incompatibles. Nous verrons dans cette première partie, comment les entreprises au fil des avancées technologiques et des idéologies se sont dotées d une architecture sous forme de «plats de spaghettis», pour ensuite comprendre pourquoi l intégration prend une part de plus en plus importantes dans la définition des priorités des entreprises, en parallèle nous nous intéresserons à certains concepts et architectures d intégrations qui existent. Le 26/04/2004 Page 4 sur 95

5 Titre 1 Les différents environnements applicatifs Afin de connaître et de comprendre toutes les formes d architectures que l on peut être amené à rencontrer dans différentes entreprises, il est primordial de s arrêter un instant sur les évolutions technologiques et les analyses qui ont conduit les mutations des systèmes d information au fil des années. Pour ensuite, en tirer les conséquences directes ou indirectes sur l organisation ou encore l architecture de l environnement applicatif. Chap. 1 Evolution des technologies des systèmes d information Il est possible de décomposer l avancée technologique des architectures informatiques selon 4 phases : - Le maître esclave, - Le client serveur, - Le web - Et le client riche. Chacune de ces phases possède une certaine logique métier plus ou moins adaptée à leurs besoins, avec des méthodes d intégrations plus ou moins performantes. Il n est pas question ici de comparer ces phases, nous nous contenterons de les présenter chacune, afin d en tirer des éléments expliquant les conséquences sur le système d information dans sa généralité. 26/04/2004 Page 5 sur 95

6 1 Le Maître Esclave Schéma 1 : les architectures maître esclave Ces architectures informatiques fortement répandues dans les années 70 et 80 étaient la base des systèmes propriétaires, en effet le système informatique et les solutions informatiques ne formaient qu une seule plate-forme composée de terminaux passifs reliés entre eux et d un serveur applicatif central. La logique métier de cette architecture était linéaire et concentrée sur le serveur, le langage informatique le plus couramment utilisé étant le langage COBOL, et les applicatifs étaient distribués sous forme de RPG. Sous cette architecture, l intégration était représentée par le projet informatique en lui-même. En effet, de part les possibilités technologiques existantes, les budgets informatiques disponibles et les solutions d éditeurs de logiciels, il était logique de réaliser le développement d applications autonomes. On ne peut donc pas utiliser véritablement le terme d intégration pour cette période et ce type d architectures. Mis à part le métier de «chef de projet» que l on trouvera pour toutes les architectures décrites dans cette partie. On trouve pour cette période le métier de «développeur d application». RPG : Report Program Generator 26/04/2004 Page 6 sur 95

7 2 Le Client Serveur Schéma 2 : les architectures client serveur Dans les années 80, et jusqu aux années 2000, l architecture «client - serveur» apporte de nouvelles possibilités en terme d intégration d applications, mais aussi en terme de développement applicatifs partagés. On trouve donc pour ce type d architecture, encore fortement répandu, une logique métier éclatée entre le client et le ou les serveurs. La notion de développement en couches applicatifs voit le jour : la couche traitement qui se situent plutôt sur le poste client utilisant l application, et la couche donnée hébergée quant à elle sur le serveur applicatif. Dans ce mode de développement, l intégration n est pas à négliger, dans le but de ne pas se perdre dans toutes les interconnexions nécessaires et utiles entre les serveurs d applications, et les postes clients utilisant bien souvent plusieurs applications. L utilisation simultanée de plusieurs applications se traduit par la création de connecteurs applicatifs. Ces connecteurs, développés en spécifiques, ont pour but de relier en point à point les différents environnements applicatifs de l entreprise. Etant donné l ouverture technologique qui découle de ces nouvelles possibilités techniques, de nouveaux métiers apparaissent dans le monde professionnel, on parle alors de Développeurs et d Administrateurs de Bases De Données, voir d Experts Réseaux. 26/04/2004 Page 7 sur 95

8 3 Le Web Schéma 3 : les architectures Web Les années 2000 sont fortement influencées par l avancée des technologies en téléphonie, Internet et interconnexion de réseaux. En effet, les entreprises et les particuliers se fournissent en équipements «Internet», une nouvelle vision des architectures applicatives tournée vers le Web voit le jour, et se propage rapidement dans le monde de l entreprise. La logique métier, se trouve concentrée sur les différents serveurs (applicatifs, de communication, de stockage ). Trois couches principales ressortent des nouveaux développements : - Présentation, son rôle est de formater la présentation des données souhaitées. - Traitements, son rôle est de réaliser les traitements relatifs aux actions souhaitées. - Données, son rôle est de stocker les informations nécessaires. Les modes d intégrations reposent sur la rationalisation des échanges inter applicatifs à l aide d une plate-forme nommée «EAI». Les applications sont alors reliées via des connecteurs standards à un bus de messages. L émergence de ces nouvelles architectures voit apparaître les métiers suivants : Développeur, Web Designer, Intégrateur et Administrateur de Bases de Données Web. 26/04/2004 Page 8 sur 95

9 4 Le client riche A l époque où l Internet devient incontournable, et où les communications entre sites distants ne posent plus de problèmes techniques ou économiques, de nouvelles formes de communications et de définitions d applications voient le jour. La logique métier se trouve alors éclatée entre processus et traitements, et est répartie entre le serveur et le client. Certaines entreprises mettent sur le marché des «Web Services» répondant à des besoins définis préalablement pour plusieurs utilisateurs. Les modes d intégration se retrouvent alors bouleversés, le but est désormais d exposer l existant via des standards comme SOAP ou WSDL, afin de raccorder directement l application à une entreprise ou à une application sans passer par des connecteurs spécifiques ou nécessitant des développements complémentaires. Les couches applicatives sont alors démultipliées : - Présentations - Orchestration - Traitements - Intégration - Abstraction - Données - Applications Les métiers nécessaires dans ces nouveaux types de projets sont alors tout aussi démultipliés, on retrouve en effet autant d experts que de couches applicatives. Les Développeurs, Intégrateurs, Administrateurs de Base De Données, GUI Designer, Architectes Fonctionnels et Architectes Techniques sont là pour répondre à ces nouveaux besoins. SOAP : Simple Access Protocol WSDL : Web Services Description Language GUI Designer : Graphics User Interface 26/04/2004 Page 9 sur 95

10 Chap. 2 Les méthodes d analyse et différentes solutions Dans le cadre de ce dossier, il n est aucunement question de définir dans le détail quelles sont les méthodes d analyse, ainsi que les cycles de vie associés à ces méthodes. Nous nous contenterons juste d introduire ces différentes notions, afin d en expliquer pourquoi le système d information de l entreprise peut être aussi complexe de nos jours. 1 La méthodologie, la base La méthode se veut être une démarche ordonnée et raisonnée dans le but d obtenir un résultat conforme aux attentes définies initialement. Il est facile de constater qu il n existe non pas une méthode pour atteindre le résultat, mais bien souvent autant de méthodes que de protagonistes. Toute bonne méthodologie, commence par la définition du champ d action concerné par la démarche, et surtout ce que l on fait et ce que l on ne fait pas. L expérience est un élément important, qui influence souvent le cheminement emprunté afin de résoudre la problématique initiale. Cette expérience associée à une démarche scrupuleuse, et une réflexion de tous les instants, peut mener à la naissance du «génie» d une profession. On parle par exemple de «génie civil», «génie logiciel», «génie industriel» Une bonne méthodologie permet donc de sortir de l empirisme, et d utiliser au mieux les expériences, bonnes ou mauvaises, qui nous ont conduit à faire des choix plus ou moins efficaces. Dans tous les cas, cette méthodologie, ne représente qu une aide, pour être plus efficace, et gagner de l assurance dans le déroulement d une étude. 26/04/2004 Page 10 sur 95

11 2 L analyse systémique Un système peut se définir comme un ensemble d éléments en relation les uns avec les autres. Selon la fonction associée à chacun de ces éléments, et les interactions qui existent entre ces éléments, on pourra définir plusieurs types de systèmes. C est aussi un ensemble de méthodes, de procédures, de techniques unifiées par un certain nombre de règles pour former un ensemble organisé. L analyse systémique se situe à la base des développements objets ou structurels. A Classification des différents types de systèmes Voici un tableau récapitulatif des différents niveaux systémiques recensés : Définition Exemples 0 Aucun échange d informations avec l environnement - COMPLETEMENT FERME Marteau 1 Doté d un «feed-back» de premier ordre, mais sans mémorisation. Réaction immédiate par acte réflexe. Thermomètre N I V E A U X 2 3 «Feed-back» de deuxième ordre associé à une mémoire sélective. Cela tient compte des modifications futures prévisibles. Pas d apprentissage. «Feed-back» de troisième ordre, ils possèdent en plus d une mémoire sélective et d une capacité d apprentissage. Capacité stratégique. Thermostat programmable Automates. Echecs électriques. 4 Ils possèdent tous les attributs précédents. Avec en plus la volonté et l imagination créatrice. Système humain 5 Ils possèdent tous les attributs précédents. Avec en plus la capacité de modifier leurs propres structures. Système entreprise 26/04/2004 Page 11 sur 95

12 B Les composantes qui interagissent dans un système Voici un schéma reprenant un système, son environnement et ses composants : L environnement ENVIRONNEMENT Ses objectifs Sa structure SYSTEME (OBJECTIFS, PROCESSUS, SCTRUCTURE) Ses entrées Ses sorties ENTREES FEED-BACK SORTIES Son processus Schéma 4 : les composantes interagissant dans un système C Les critères d efficacité d un système Nous pouvons définir au minimum quatre critères permettant de mesurer l efficacité d un système : 1. Assurer la cohérence de l ensemble des objectifs des sous-systèmes avec les objectifs d ensemble du système complet. 2. Disposer des informations nécessaires pour évaluer les performances des soussystèmes et assurer leurs coordinations. 3. Regrouper les activités élémentaires afin de trouver la meilleure synergie et la meilleure productivité possible. 4. Réduire les interactions entre les différents sous-systèmes afin d assurer le minimum de pertes d énergie. 26/04/2004 Page 12 sur 95

13 D Fonctionnement d un système dans son environnement On peut constater que le système est constamment en interaction avec tous les éléments qui le composent, de plus son environnement l influence dans son évolution et dans ses choix. Il est important de préciser que l analyse fonctionnelle et l analyse objet empruntent une part plus ou moins importante à cette théorie des systèmes. La démarche systémique est essentielle pour : - Situer le problème dans un contexte global. - Aborder le système d information à partir des activités et non des besoins. - Prendre en compte l informatique et l organisation dans les projets. Décision Système décisionnel Information Système d'information Opération flux entrants Système opérant flux sortants Schéma 5 : Fonctionnement d un système dans un environnement 26/04/2004 Page 13 sur 95

14 3 Analyse structurée et fonctionnelle L analyse fonctionnelle se veut très concrète dans sa réalisation, de part son orientation reposant sur le fonctionnement et l organisation des activités nécessitant sa mise en place. A Séparation des Données Traitements Communications La séparation entre Communications Données et Traitements permet d atteindre les différents niveaux d abstraction nécessaire à l analyse fonctionnelle. L aspect dynamique des traitements conduit à la transformation de l information manipulée. A l opposé l aspect statique des données offre un stockage et une mémorisation de l information. Les communications ont pour rôle de transmettre l information avec les traitements effectués sur les informations. B L abstraction de l analyse fonctionnelle En plus de la séparation des Données et Traitements, Il existe trois niveaux d abstractions qui correspondent à des choix et directions différentes : - La partie conceptuelle définie les choix de gestion conceptuel par le QUOI? - La partie organisationnelle fixe les choix d organisation par le QUI_OU_QUAND? - La partie opérationnelle explique les choix techniques avec le COMMENT? Il est important de préciser que dans pareil cas, la nature du travail ne change pas, mais la façon de travailler change par l organisation et l automatisation de ce travail. 26/04/2004 Page 14 sur 95

15 4 Analyse objet La taille et la complexité des logiciels n ont cessé de croître en parallèle des évolutions technologiques. Dans le but de gagner en efficacité d analyse, en rapidité de développement, et d offrir des plates-formes applicatives qui se veulent portables, inter opérables et adaptables, l analyse et l approche objet apportent des solutions à la problématique de conduite de projets informatiques. Pour cela, l approche et l analyse objet reposent sur cinq concepts fondamentaux : Les objets : o Se définissent par des informations et un comportement. Les messages : o Ils permettent la manipulation des objets. Les classes et instances : o Elles regroupent des objets ayant les mêmes attributs et comportements. L héritage : o Mécanisme qui permet d assurer une grande variabilité dans la réutilisation des objets. Le polymorphisme : o Mécanisme permettant à une sous-classe de redéfinir une méthode dont elle a hérité. Un objectif prioritaire est de réutiliser ce que l on produit, apportant ainsi une valeur ajoutée non négligeable aux nouveaux développements informatique. «Pourquoi le logiciel n'est-il pas comme le matériel? Pourquoi tout nouveau développement doit-il repartir de zéro? Il devrait y avoir des catalogues de modules logiciels, comme il y a des catalogues de puces de circuits intégrés : pour construire un nouveau système, on devrait commander des composants dans les catalogues et les combiner, plutôt que de réinventer la roue à chaque fois...». Extrait de «Conception et programmation par objet» de Bertrand Meyer. Par conséquent, l approche orientée objet offre une manière claire de concevoir une architecture faite de modules autonomes, facilitant l implémentation multi plate-forme. Elle permet une flexibilité technique accrue et une meilleure ouverture aux nouvelles technologies et modules externes. 26/04/2004 Page 15 sur 95

16 5 Les différents projets L entreprise ne peut pas se permettre de posséder une multitude d applications lourdes et nécessitant une phase projet importante. La phase peut être délimitée dans un premier temps par une phase d analyse pour finir sur une phase d intégration, ou de déploiement. De ce fait, les entreprises développent des petites applications en interne, bien souvent par l intermédiaire de leur service informatique, ou alors dans d autre cas par les «meilleurs informaticiens» de l entreprise dans le cas de PME-PMI ne disposant pas de service informatique. Tous ces «petits outils» qui ont germés dans les entreprises complexifient encore plus la gestion des données dans l entreprise, l intégration de nouvelles applications, mais aussi la volonté de rassembler et de consolider les informations, telles que le fichier client, le listing du personnel L'intégration des toutes ces applications consiste en la combinaison de plusieurs applications métiers, créant ainsi une valeur ajoutée pour les entreprises car cela permet l'échange et le partage des données. C'est pourquoi l'intégration d'application répond à un double objectif. En effet, en plus de satisfaire le besoin de partage de l'information, les logiciels d'eai doivent en assurer la connexion. Il s'agit de relier les applications Front Office aux applications Back Office. Ces connexions forment ainsi une chaîne de processus métiers, reliant toutes applications métiers entre elles. L'idée d'assembler les processus métiers d'une entreprise est née de plusieurs facteurs. En effet, l'accroissement de la net économie et une compétitivité de plus en plus serrée renforcent la notion de «time to market» et pousse les entreprises à réagir rapidement. La difficulté réside dans le fait d'obtenir un système d'information souple et flexible tout en ayant ces applications reliées. L'objectif de la chaîne de processus métiers (vu dans le chapitre 2) est de permettre à l'entreprise d'améliorer sa productivité et son profit. L'intégration des processus métiers a été améliorée dans le courant des années 1990 avec la création d'un nouveau système de processus appelé les BPR (Business Process Reengineering). C'est un système reliant une activité indépendante au processus métier. La création de la chaîne de processus métier devient de plus en plus nécessaire. En effet, à l'heure des partenariats, de la délocalisation et de l'internalisation, voir de la globalisation. L'EAI est un moyen efficace de communiquer et de partager ses informations dans les meilleurs délais. 26/04/2004 Page 16 sur 95

17 6 Progiciels de Gestion Intégré (PGI) PGI dont l'acronyme est «Progiciel de Gestion Intégré», est l'équivalant des ERP, c'est à dire «Enterprise Ressources Planning», en anglais. Ce sont des logiciels centralisant toutes les informations concernant, les ventes, la comptabilité et la production d'une entreprise. Ils s'articulent autour d'une base de données unique, un jeu de code et une interface utilisateur intégrée afin de relier les données à des processus commerciaux. Mais ce modèle est dépassé par les évènements car il ne permet qu'une connexion point à point. C'est pourquoi on assiste aujourd'hui à une réorientation de ce type de logiciels. En effet, les éditeurs d'erp s'associent avec des partenaires leur permettant de faire évoluer leurs progiciels vers les technologies liées à l «e-business». C est par exemple le cas de «SAP. Tandis que d'autres préfèrent re-écrire leurs applications avec un langage ouvert et compatible («PeopleSoft» par exemple). Les éditeurs de PGI, introduisent de nouvelles technologies afin de rester compétitif et d'éviter une catastrophe financière. Les PGI sont donc en perpétuelle évolution. On distingue quatre phases majeures dans le domaine des «Progiciels de Gestion Intégrée»: Optimisation de l'intégration et de la souplesse des logiciels : o Les PGI ont une architecture plus ouverte, capable de s'adapter aux technologies standards du marché. Adaptation à l'e-business : o Extension des applications par des modules e- business. Ces modules correspondent aux applications les plus demandées dans le cadre de l'ebusiness. On retrouve donc l'automatisation de la force de vente (SFA Sales Force Automation), la gestion de la relation client (GRC / CRM), la gestion des achats et des approvisionnements (e-provisionning et e-procurement), la gestion de la chaîne logistique (supply chain management) et la business intelligence. 26/04/2004 Page 17 sur 95

18 Adaptation à une nouvelle cible : o Avant les PGI ne s'adressaient qu'à des applications internes à l'entreprise. Aujourd'hui le partage des informations est essentiel à la croissance de l'entreprise et prend en compte les partenaires. C'est pourquoi, les logiciels s'ouvrent également à des utilisateurs externes (clients ou prestataires) et créent une utilisation mobile et multi-entreprise. Adaptation à Internet : o Internet a un rôle de plate-forme et de canal d'échange. Des interfaces sont annexées aux PGI et s'appuient sur un navigateur. Cela permet aux utilisateurs d'entrer dans le Système d Information d'une entreprise, à partir de n'importe quel poste et endroit. Il suffit d'avoir une connexion Internet. La fonction primaire des PGI est d'assurer l'interface entre les applications entreprises. Or, il existe deux types d'interface : «mode message» et «mode API», chacune ayant sa particularité. Le «mode message» est considéré comme connecteur dit «léger», alors que le «mode API» est considéré comme un connecteur lourd. Les modes messages sont orientés vers les batchs. Un batch consiste à traiter les messages par lots. Une liste des tâches à accomplir est créée, celle-ci s exécute automatiquement par la suite. Ainsi les messages ou fichiers sont envoyés dans le SI, qui en retour donne les informations recherchées. Tandis que le connecteur est dit léger lorsque le cheminement est assuré par un Message Broker. 26/04/2004 Page 18 sur 95

19 Section 2 Conséquences de ces évolutions Si l'on examine le fonctionnement de l'entreprise, on constate que le nombre des interactions entre les différentes applications, internes et externes, ne cesse d'augmenter. En fonction des besoins et des contraintes, les entreprises ont développé leur propre solution d'intégration en rajoutant, brique par brique, de nouvelles applications à celles déjà existantes. Le résultat est malheureusement qu'aujourd'hui beaucoup d'entreprises sont confrontées à des applications "spaghetti", très fortement liées entre-elles, aux bases de données et aux applications externes. Ces applications «spaghetti» sont caractérisées par une dépendance très forte (couplage fort). Chaque intervention sur une application spécifique risque ainsi de provoquer un véritable effet "domino" sur les autres. Le seul moyen d'extraire ou d'ajouter des données dans un tel système est, en général, de développer une procédure spécifique pour un format de fichier bien particulier. Ainsi, la plupart des entreprises ne disposent pas d'une centralisation de leurs applications. De plus, la modification ou la réutilisation de certains composants est difficile, voire impossible. La solution pour éviter le «code spaghetti» est l'utilisation d'un serveur d'intégration qui assure la communication intelligente entre les différentes applications internes et externes en passant d'un couplage très fort à un couplage faible entre ces applications. Nous verrons dans la suite de ce dossier : La naissance et l évolution du marché de l intégration. Les bases nécessaires dans sa mise en place. Les différentes plateformes disponibles. La présentation de quelques acteurs du marché. Et enfin un exemple d intégration de processus de publication dans une agence de presse. 26/04/2004 Page 19 sur 95

20 Titre 2 Concepts et importance de l intégration Chap. 1 Naissance du marché et de son évolution Le Marché de l EAI prend son essor avec celui de l e-business. La volonté des entreprises d être présentes et performantes dans la nouvelle économie, les pousse à développer de nombreuses offres sur le web. Avec cette augmentation des services online, les entreprises ne cessent d améliorer leurs applications déjà existantes afin de satisfaire toujours plus le client. Les applications e-business suscitent le besoin d intégration afin que toutes les informations restent cohérentes et disponibles. C est notamment le cas pour des applications de CRM (Costumer Relationship Management), de gestion des stocks, de gestion des approvisionnements, etc. Ainsi, au départ les entreprises intègrent leurs applications en achetant «les pièces manquantes» aux éditeurs. Les éditeurs de logiciels voient donc en l EAI, un marché plutôt prometteur. Ceux-ci passent des accords de partenariat avec d autres éditeurs, par exemple Siebel qui a signé un accord d intégration avec IBM. Certains rachètent carrément les éditeurs possédant les applications manquantes, c est notamment le cas pour de nombreuses entreprises : Nortel rachète Clarify, Lucent rachète Mosaix. Ces applications EAI sont ensuite proposées aux entreprises utilisatrices. C est alors que les entreprises éditrices commencent à créer leur propre offre globale, comme par exemple, Sybase Neonsoftare, IBM Crossworlds, Sopra Viewlocity. Un engouement pour le middleware et l EAI apparaît en 1999, bien que la notion d intégration existe depuis Selon une étude menée par la Business Intelligence en 1999, 54% des entreprises estiment qu avec la croissance de l e-business, le manque de communication entre applications leur ferait défaut. De cette effervescence autour de l EAI, apparaissent de nombreux acteurs, tel que SeeBeyond, Tibco,. Cependant, il ne faut pas faire l amalgame entre EAI et Middleware. C est ce que révèle une enquête sur l intégration menée par le Journal du Net, en avril Le Middleware est considéré à 40%, comme une solution de «rafistolage» d applications, tandis que l EAI prend en compte tout le processus de l entreprise, mais n est pas forcement opérationnel à 100% dès le départ. C est pourquoi seulement 15,7% des entreprises considèrent l EAI comme stratégique pour le développement de leurs applications e-business. En fait toutes les entreprises s accordent à dire que l EAI, ne peut qu être bénéfique à leur croissance. Mais le manque de confiance en ce système d intégration rend certaines entreprises utilisatrices réticentes, notamment les entreprises françaises. Cela a pour conséquence un marché EAI moins développé dans certaine partie de l Europe. 26/04/2004 Page 20 sur 95

21 Section 1 Le marché européen On peut dire que celui-ci se porte plutôt bien, en effet l'étude des analystes «Frost & Sullivan» constate une croissance de plus de 220% entre 1992 et Le revenu européen de ce marché est passé de 0.4 à 0.92 milliards d euro, il a été multiplié par vingt-trois en huit ans. L'EAI connaît, en Europe un fort succès depuis 1997 et cela n'est pas prêt de s'essouffler. L'étude de «Frost & Sullivan» annonce les chiffres suivants : Années CA en Taux de croissance en % millions millions 126.9% milliards 135 % Cependant à long terme, même si le revenu de ce marché augmente, la croissance va quant à elle se réduire. Ainsi, le chiffre d'affaires pour 2007 est estimé à 17.5 milliards d euros mais la croissance sera de 6%, ce qui peut être considéré comme faible par rapport à la montée vertigineuse des années précédentes (cf. tableau ci dessus). Cette envolée du marché est à l'heure actuelle due au segment EAI traditionnel, c'est à dire les logiciels «AtoA» (Application To Application). Ils représentent en 2000, un chiffre d'affaire de 760 millions d euros avec une croissance de 116,5%, tandis que le segment «BtoB» (Business To Business) à réalisé 160 millions d euros. Mais, Forest&Sullivan prévoit une inversion des tendances d'ici En effet, l'eai traditionnel réaliserait 5.87 milliards d euros. 26/04/2004 Page 21 sur 95

22 Section 2 Le marché français La France est en retard par rapport aux Pays Anglo-Saxons. L Angleterre et l Allemagne sont matures sur le marché européen depuis le début, c est à dire en Ainsi le cabinet d analyse «Frost & Sullivan» déclare que le marché européen en 2001 est détenu à 29,5% par la Grande Bretagne et à 23% par l Allemagne, tandis que la France possède 15,8% de parts de marché. Cependant, la France devrait rattraper son retard et atteindre 22.5% d ici 2007, alors que les marchés anglais et allemand vont régresser ou stagner. Le marché de l EAI à donc un bel avenir devant lui, surtout en France. Toujours selon le cabinet «Frost & Sullivan», le seul frein à sa croissance serait la confusion provenant de la multiplicité de l offre. Le retard des français, s explique par une toute puissance historique des directions informatiques et techniques au sein des grands comptes. En effet, ces directeurs voient d un mauvais oeil leurs travaux titanesques de développement «homme» se faire supplanter par des solutions «clés en main». Ainsi ce retard, sur le marché de l'eai, à l'avantage de faire de celui-ci le plus porteur dans les années à venir. Le chiffre d'affaires des entreprises présentes sur ce marché est considéré comme faible, exception faite pour la société Sopra, leader de l'eai sur le marché au niveau national. C'est pourquoi les éditeurs affluent, surtout les américains (Seebeyond, Webmethods, Vitria, Tibco...). Selon le cabinet PAC (Pierre Audoin Conseil), le marché devrait être multiplier par sept en Conclusion : Le marché est encore en train de se construire, surtout dans les pays latins. Mais on prévoit l'inversion des tendances sur deux points. En effet, les marchés à fort potentiel deviendront ceux des pays du sud et des logiciels EAI. Cette évolution s'explique par l'ampleur que prennent les applications e-business et Internet au sein de l'entreprise et de l'économie. Toutefois on peut se demander comment évoluera cette tendance après /04/2004 Page 22 sur 95

23 Chap. 2 Les indispensables pour mettre en place son intégration Section 1 Les bases de l intégration 1 Le Middleware Ce sont des logiciels intermédiaires entre le mainframe et les terminaux des utilisateurs. Ces logiciels ont pour fonction de gérer les transactions, le partage des connexions, la mise à jour des serveurs et des bases de données. La communication inter applicative n est que partiellement assurée car les middlewares, ne permettent l échange d information que d un point à un autre. Pour que la communication devienne inter applicative, les entreprises doivent mettre en place un nouveau serveur pour le ralliement de chacune des applications. La mise en place d'un middleware rend le système d information de plus en plus complexe, car chaque application reliée demande une intégration de middleware. En revanche, bien que très lourd en infrastructure, il améliore la communication des principales applications des entreprises, à savoir les E.R.P. (Entreprise Ressource Planning : système informatique prenant en charge la totalité des besoins d automatisation de la gestion d une entreprise) ou P.G.I (Progiciel de Gestion Intégré) en français, la G.E.D. (gestion électronique de données), la logistique ou SCM (Supply Chain Management), l e-business, le CRM (costumer relationship management), le Workflow (gestion des flux). Les middlewares permettent la connectivité entre toutes ses applications. Mais cette amélioration de la communication inter applicative ne suffit plus aux entreprises. Celles-ci souhaitent réduire le nombre de développement que les middlewares impliquent. Toutefois, les middlewares s'appuient sur des plates-formes de développements homogènes. Par exemple celles développées avec l outil java facilitent la communication avec les applications développées avec des langages qui ont pour origine le langage java. Mais, les entreprises se sont rendues compte que la compatibilité des langages ne résolvait qu une partie de leurs problèmes. Car la problématique des entreprises est de faire en sorte que le contenu de leurs applications soit également compatible. C est pourquoi, il faut aussi prendre en compte d autres facteurs tel que le protocole de communication et le «hardware» (exemple : un ordinateur Macintosh et un PC) des entreprises. C est face à la nécessité de simplifier leur système d information et de mieux communiquer au niveau informationnel, qu est né le concept de l EAI. 26/04/2004 Page 23 sur 95

24 2 Le modèle XML A Introduction XML est une technologie incontournable dans l entreprise. On retrouve XML dans des contextes aussi divers que les applications distribuées, la configuration de produits, les annuaires, l édition de documents, la diffusion de contenu sur le web ou la gestion de la connaissance. Tant et si bien qu il est devenu difficile d avoir une vision globale de cette technologie sans passer des heures en veille technologique. B Origine XML (extensible Markup Language) est une recommandation du W3C. C est un langage à balise définissant un format universel de représentation des données. Un document XML contient à la fois des données et les indications sur le rôle que jouent ces données. Ces indications permettent de déterminer la structure du document : ce sont des balises. XML est une sous partie de SGML (Standard Generalized Markup Langage) définit par l ISO (ISO 8879). SGML est un langage international de documentation normalisée, standard de fait dans le milieu de la gestion documentaire. On a souvent coutume de dire que "XML présente 80% des fonctionnalités de SGML pour seulement 20% de sa complexité". C Les règles Tout document XML doit répondre aux exigences suivantes : Il doit être utilisable sur internet. Il doit supporter une grande diversité d applications. Il sera compatible SGML. Il devra être aisé d écrire des programmes qui manipulent le XML. Il devra avoir le minimum de fonctions optionnelles. Il sera lisible par l'homme. Il sera disponible rapidement. La spécification qui le décrira devra être simple et concise. Un document le respectant devra être facile à construire. Il ne pourra ne pas être concis. 26/04/2004 Page 24 sur 95

25 D Exemple Toute personne ayant déjà vu un document HTML sera familiarisée avec les documents XML. Voici un exemple simple de document. Il s agit d un document XML décrivant un annuaire simple : une liste d entrées, chaque entrée étant composée d un nom de personne et d un numéro de téléphone. Le document commence par une entête. Cette entête n est pas obligatoire. Elle contient des informations sur la version de XML et le jeu de caractères utilisé. L entête peut aussi faire référence à une DTD (Déclaration de Type de Document - Document Type Definition). Une DTD est une grammaire qui définit la structure d un document XML. Elle permet de valider que chaque composant d un document XML est à la bonne place. Les DTD sont par exemple utilisées pour valider les flux XML entrants d'un programme. Le document XML suit l'entête. Ce document est composé d un ou plusieurs éléments. Les limites des éléments sont marquées soit par des balises ouvrantes (< >) et fermantes (</ >), soit, pour les éléments vides, par une balise d'élément vide (< />). Chaque élément est identifié par un nom. Il peut contenir des attributs. Exemple d élément vide avec attribut : <expert nom= Improve /> Exemple d élément non vide sans attribut : Exemple d élément non vide avec attribut : 26/04/2004 Page 25 sur 95

26 3 Les échanges de données (ETL) E.T.L. Ses initiales signifient Extraction-Transformation et Loading, et correspondent au chargement. C'est une technologie permettant la transmission des données d'une application à une autre. Elle est utilisée pour le transfert de volume de données importantes, elle doit assurer un rôle d'intégration des données. Nous avons à notre disposition pour intégrer des applications au moyen d un E.T.L. deux méthodes : - Méthode Ascential - Méthode Informatica A Méthode Ascential La méthode développée par Ascential permet l'intégration en centralisant les informations. Ces informations sont extraites de leurs sources par un serveur indépendant. Ensuite, l'etl transforme ces informations et les envoie à son destinataire. B Méthode Informatica Dans la méthode développée par Informatica, l'etl fait office d'un générateur de code (cobol, C, Java, SQL). Les sources et systèmes destinataires servent ensuite de support de déploiement, c'est-à-dire permettent la connexion entre les points. L'information est ensuite répartie selon les points de destination. Ce type d'architecture est dit distribué et s'appuie sur un «batch composant» rattaché aux ETL. Cette technologie liste les actions qui sont à réaliser de manière automatique. C'est le batch qui se charge de l'envoi des fichiers. L'avenir de l'etl en tant qu'outil EAI est plutôt de l'ordre de la complémentarité. Ils s'intègrent dans l'eai car il gère des informations de poids léger et en temps réel, tandis que le deuxième est surtout utilisé pour les gros volumes de données, qu'il traite par lot (technologie du batch). Néanmoins, il serait utile d'accéder aux informations de volume important également en temps réel. Cependant, selon l'étude menée sur l'eai par le cabinet Octo Technology, l'etl ne serait pas le meilleur mécanisme d'échange. En effet celui-ci assure une très bonne compatibilité entre les applications, mais n'est pas efficace pour la répartition des flux, ni pour la gestion des processus complexes. Il en est de même avec les deux autres types de mécanisme. (Cités ci dessus) Dans l'ensemble, les mécanismes d'échange permettent donc de constituer la source (base de données) de façon claire et définie, et d'obtenir facilement le contenu. Toutefois, ils n'ont aucune fonction de gestion des flux, ni des processus. C Conclusion Etant préconisé pour les gros volumes, une entreprise doit d'abord se demander quel est son volume d'échange. Peut-être qu'un outil ETL est plus adéquate pour les grandes entreprises, d'autant plus que cela représente un investissement important. 26/04/2004 Page 26 sur 95

27 4 Le Message Oriented Middleware (M.O.M.) Cet acronyme signifiant «Message Oriented Middleware», est également appelé Middleware asynchrone. En fait, cette technologie permet de transporter et de transformer les messages d'un point à un autre. Le principe d'intégration des applications est simple. Etant asynchrone, les MOM sont composés de plusieurs langages de programmation (C, C++, et Java). Lorsqu'un message est envoyé, il est mis en attente. Le trajet du message varie également si la connexion est interne ou externe. Si la communication est interne alors le message transitera par deux mécanismes, à savoir : un service de «mise en file d'attente» puis la «file d'attente» en elle-même. Si la communication est externe et qu'elle doit entrer en contact avec un autre serveur, alors après avoir été au service de «mise en file d'attente», le message est transféré au «service d'expédition» des messages. A partir d'ici, le message est reçu par le «service d'expédition» de la société externe. Le message effectue donc le parcours inverse, c'est à dire qu'il passe ensuite par le service de «mise en file d'attente» de la société externe, pour arriver à la «file d'attente» et être transmis à l'application souhaitée. Afin d'intégrer son application à une autre, l'entreprise peut donc s'appuyer sur des messages orientés middleware. 5 Le message Broker Le message broker assure le rôle de passerelles techniques ainsi que de connexion. Message broker : c'est un modèle d'échange ayant la mission d'un bus d'échange. Le principe de fonctionnement n'est pas très compliqué : lorsque le bus d'échange reçoit les données, il doit les re-dispatcher à leurs destinataires respectifs. Toutefois cela sous-entend que les applications doivent être abonnées aux informations. C'est à dire que des règles de cheminement ont du être définies afin d'orienter les informations vers les postes correspondants. Grâce à ces règles, le poste expéditeur, n'a pas besoin d'avoir connaissance du destinataire, puisque le «bus» ou le «hub» est un point de passage obligatoire. En fait, qu'il s'agisse de l'application émettrice ou réceptrice, elles ont pour interface le hub, et ne seront jamais connectées entres-elles. Le message broker, assure donc un rôle de passerelle par l'intermédiaire technique qu'est le hub d'échange. Mais afin d'assumer son rôle, le message broker, a deux objectifs à atteindre. Dans un premier temps, la transformation des données. Le message broker assure la comptabilité des formats entre les applications. Et dans un second temps le routage ainsi que le contrôle de ces flux : ici le message broker gère les flux et le routage. Les différentes étapes de l'échange basées sur le message broker : 1. Réception du message en provenance du connecteur 2. Interrogation du référentiel pour connaître la règle de transformation à utiliser. 3. Application de la règle de transformation. 4. Transfert des messages traités et correspondant aux applications destinataires. 5. Formatage des données par les connecteurs des applications réceptrices. 26/04/2004 Page 27 sur 95

28 6 La gestion des processus métiers (BPM Business Process Management) Pour cette partie, nous avons découvert et utilisé le logiciel Intalio. A L enjeu des processus métiers L enjeu du BPM est d unifier sous un seul outil toutes ces visions, pour fournir à l entreprise la possibilité de définir ses processus au niveau métier, et de faire intervenir les utilisateurs et les applications de l entreprise en tant que partie prenante à ces processus. L objectif est de permettre aux décideurs, analystes métiers, équipes fonctionnelles et équipes techniques de collaborer pour la définition et l évolutivité des processus métiers via un seul outil agrégeant les différentes visions. Un processus métier est modélisé en plusieurs niveaux, et plus généralement en trois niveaux : Le niveau métier : vue métier haut niveau du processus, définissant ses principales étapes et l impact sur l organisation de l entreprise. Ce niveau est défini par les décideurs, et les équipes méthodes de l entreprise. Le niveau fonctionnel : formalisation des interactions entre les participants fonctionnels du processus, où sont formalisées les règles métiers conditionnant son déroulement. Ce niveau est modélisé par les équipes fonctionnelles. Le niveau technique : lien entre les activités / participants modélisés dans le niveau fonctionnel, et les applications / services du SI, ainsi que les tâches utilisateurs (Workflow). Ce niveau est réalisé par les architectes et les équipes techniques de l entreprise. Un des objectifs du BPM est de capitaliser sur les applications du système d information : le mot d ordre est la réutilisation. Nous verrons dans la suite de ce document que, contrairement aux initiatives précédentes architectures objets, Web Services la réutilisation est rendue effectivement possible, tant au niveau technique (connecteurs, règles techniques, transformation de données) que fonctionnel (réutilisation d un processus de facturation dans un processus de gestion de bons de commande par exemple). 26/04/2004 Page 28 sur 95

29 B Définition Le terme de «processus métier» est souvent utilisé à tort et à travers pour désigner des notions différentes : processus exécutable, processus abstrait, processus collaboratif, etc. Prenons le temps de définir ces différentes notions : Processus métier Un processus métier est une chorégraphie d activités incluant une interaction entre participants, sous la forme d échange d informations. Les participants peuvent être : - Des applications / services du SI - Des acteurs humains - D autres processus métiers Voici par exemple une partie d un processus métier de gestion des bons de commande, modélisé avec Intalio Designer. Cet exemple fait intervenir deux participants : le département marketing de l entreprise, et un processus automatisé de gestion des bons de commande. Schéma 6 : Définition d un processus métier avec Intalio Un processus métier peut être interne à une entreprise (gestion des demandes de congés par exemple), ou mettre en jeu des entreprises partenaires on parle alors de processus collaboratif. 26/04/2004 Page 29 sur 95

30 Processus collaboratif Un processus collaboratif est un processus métier mettant en jeu des entreprises partenaires. Un processus collaboratif incluant n partenaires est composé de deux parties : une interfaces et n implémentations. L interface définit la partie visible du processus, c'est-à-dire le contrat entre les partenaires : définition des documents métiers échangés, du séquencement des activités, des rôles et responsabilités de chaque partenaire. L exécution spécifique de chaque partenaire est abstraite grâce à cette interface. Voici la représentation de l interface d un processus collaboratif de gestion de commande sous Intalio Designer, mettant en jeu trois partenaires un client, un fournisseur et un sous traitant : Schéma 7a : Définition d un processus collaboratif avec Intalio 26/04/2004 Page 30 sur 95

31 Les implémentations une pour chaque partenaire définissent le comportement interne de chaque partenaire pour réaliser le processus, et respecter les contraintes définies dans l interface publique. Voici un exemple d implémentation, pour le partenaire «sous traitant» du processus ci-dessus (les activités en bleu correspondent aux activités présentes dans l interface), modélisé sous Intalio Designer : Schéma 7b : Définition d un processus métier avec Intalio Un processus collaboratif est plus communément appelé «processus métier B2B». Il met en jeu une interface publique et des implémentations privées, qui sont souvent appelées «processus métiers EAI». Un certain nombre d organisations définissent des interfaces publiques standards, de manière verticale ou horizontale, permettant aux entreprises de formaliser leurs collaborations commerciales. 26/04/2004 Page 31 sur 95

32 Processus exécutable Un processus peut être rendu exécutable de trois façons. Il peut orchestrer les applications / services du SI ainsi que des actions utilisateurs pour rendre une tâche automatisée. Par exemple, un processus de gestion de bons de commande va recevoir les bons de commande via des messages XML, les transmettre aux personnes adéquates, se renseigner sur la disponibilité des éléments commandés dans les bases de données de l entreprise, etc. Ceci dit, rendre un processus exécutable ne signifie pas nécessairement l automatiser. Par exemple un processus peut uniquement être l automatisation de la transmission d informations entre acteurs (approche Workflow), les actions étant effectuées manuellement par les utilisateurs. L avantage du BPM est de pouvoir mélanger les concepts : workflow et intégration. Rendre un processus exécutable peut aussi signifier introduire des points de contrôle pour permettre le contrôle de son déroulement. On parle alors de processus de BAM Business Activity Monitoring. Ainsi, les outils de BPM peuvent être utilisés pour construire des dashboards à destination des décideurs leur permettant de suivre les processus et d anticiper les erreurs. C Le workflow Pour le besoin d'intégration d'application workflow, l'entreprise se base sur la technologie Broker et sur des connecteurs intelligents. Ces deux technologies sont indissociables. Le broker est également nommé courtier de message. Le principe de fonctionnement : Le broker via les connecteurs, a un rôle de bus, c'est à dire qu'ils vont faire transiter les flux permettant de relier les applications entre elles et de soulager le système information. Les connecteurs assurent l'interface entre les différentes applications. Il y a donc des connecteurs qui relient l'application au broker et d'autres qui relient le broker aux autres applications. On distingue également les connecteurs intelligents des connecteurs simples : - les connecteurs intelligents font, au préalable, une répartition du traitement des flux afin que la transformation effectuée par le broker soit plus rapide et plus facile à gérer. Tandis que le connecteur assure une simple transition des données. - le broker assure la transformation des informations afin qu'elles soient compatibles avec les applications destinataires. 26/04/2004 Page 32 sur 95

33 Toutefois, plus le besoin de l'entreprise en intégration est complexe et plus celle-ci aura besoin d'outil. C'est à dire que pour la bonne utilisation de son broker, l'entreprise doit aussi intégrer ses outils MOM et / ou ETL. Le chemin parcouru par les flux varie selon les applications et le type de flux. On distingue trois phases d'accès : Phase 1 : message lancé par l'application «x» arrive dans le MOM, selon la compatibilité des applications, soit l'information arrive directement à l'application «y», soit elle est orientée vers le broker qui fait son analyse à partir du référentiel. Phase 2 : le référentiel structure l'information. Ce traitement permet l'exécution de l'application et constitue un cadre commun à plusieurs applications. Phase 3 : les informations repassent par le MOM qui envoie le message à l'application «y». Toutefois, lorsqu'il y a une forte montée en charge des messages, deux solutions peuvent être adoptées : l'entreprise a le choix entre répartir les flux ou les transformer dans les connecteurs intelligents. Pour le besoin d'échange collaboratif sur internet, les moteurs workflow permettent aux entreprises l'intégration des applications B to B. Les outils précédents (MOM, ETL, Broker) sont également indispensables à l'intégration des applications B to B, entre au moins deux entreprises. C'est avec ce type d'outil d'intégration B to B que le partage des données entre entreprises est possible. Pour mettre en place une application B to B l'entreprise doit s'équiper de moteur workflow qui vont exécuter les processus métiers. Une fois exécutées, les informations des applications métiers sont transportées dans le serveur d'intégration B to B. A partir de ce serveur, les applications sont dirigées vers leurs destinataires via des passerelles (MOM, broker, ETL ). Ces passerelles B to B assurent la transformation des données. Peu importe le format puisque s'il est propre à l'entreprise, il est automatiquement transformé sous un format de langage compatible. De manière plus explicite, les informations sont transformées de façon à être comprises de n'importe quelles applications destinataires. La transmission est ensuite assurée par le protocole «SOAP», protocole conçu pour faire passer des documents en XML, sous http. Lorsque l'entreprise destinataire reçoit le message, le même chemin est effectué mais dans le sens inverse. Conclusion : Les entreprises pour pouvoir relier des applications internes ou externes à l'entreprise doivent donc s'équiper techniquement de plusieurs outils. Plus les applications à connecter sont complexes et plus les outils sont nombreux. Cependant, il y a une certaine hiérarchie entre les outils, puisque les applications les plus difficiles, en l'occurrence les applications B to B, ont pour base les outils des applications les plus simples, c'est-à-dire des applications point à point, assurant les transferts. 26/04/2004 Page 33 sur 95

34 D Le Business Process Management Grâce aux outils BPM, l'information prend une valeur plus importante car elle n'est plus transmise d'une application à une autre, mais elle circule dans les processus métiers. Le chemin à suivre est donc prédéfini par un architecte informatique, puis ce chemin ou process sera ensuite analysé en tant que flux techniques. Ces flux techniques sont ensuite paramétrés sur le serveur d'intégration. Ce concept est plus qu'un nouvel outil technique. En effet, les solutions de BPM sont au cœur du système d'information. Leur rôle est d'aider les entreprises dans la gestion quotidienne de leurs relations avec leurs différents partenaires. Par exemple, une solution BPM permet d'assurer le processus d'une prise de commande entre une application ERP avec un site e-business, alors qu'auparavant la saisie des informations entre ces applications s'effectuait à la main. Le concept n'est pas nouveau puisqu'il découle de la gestion des flux, mais aussi de l'augmentation des échanges entres partenaires, entreprises et applications. Par conséquent, les entreprises ont de plus en plus de flux à gérer. Le concept du BPM a été conçu afin d'alléger la gestion. Effectivement, il la rend moins laborieuse car elle nécessite moins d'intervention humaine. En fait, le BPM permet à l'utilisateur de choisir son mode de gestion. Il peut soit effectuer sa requête entièrement de manière automatisée, soit demander un contact humain et cela à n'importe qu'elle étape du processus. En outre, la mise en place d'une telle application nécessite une intervention humaine, et les décisions sont au final prises par des hommes. Cela représente un avantage pour les entreprises, car la gestion des flux est complètement automatisée et par conséquent beaucoup plus rapide, tandis que le nombre d'erreurs est diminué. Toutefois l'automatisation consiste à écrire le rythme à suivre pour le bon déroulement des tâches à accomplir. L'exécution des tâches se déclenche uniquement sous certaine condition. En effet, il doit un y avoir un événement facteur du lancement du processus, comme par exemple la réception d'un bon de commande ou une facture La dispersion des entreprises et la nécessité de les faire communiquer soulèvent d'autres problématiques, notamment la sécurité des informations, la performance, la disponibilité des applications, la compatibilité et la fiabilité des outils utilisés. Conclusion L'EAI permettra à terme de créer des liens de plus en plus étroits entre les différents partenaires. Bientôt les applications EAI permettront la connexion avec des terminaux mobiles tels que les téléphones portables WAP, les assistants personnels, les ordinateurs portables et autres applications «Peer to Peer» et «Wireless». Les entreprises pourront ainsi être en contact permanent avec leurs partenaires, clients, fournisseurs ou employés. Toutefois pour rester performant le système doit être constamment revu et amélioré afin de suivre les évolutions technologiques. 26/04/2004 Page 34 sur 95

35 Partie 2 Outils et plates-formes d intégration Titre 1 Choisir sa plate-forme d intégration Bien qu ils répondent aux mêmes besoins techniques généraux (échanger des données entre deux applications), les EAI, les ESB, Les EII et autres plates-formes d orchestration de services possèdent leur particularité. Les plates-formes EAI sont spécialisées dans l intégration d applications. Les EII dans l intégration de données et les ESB dans le transport de ces données. Les moteurs d orchestration de service chapeautent l ensemble. Plus complémentaires que concurrentes, ces différentes briques dialoguent entre elles, pour peu qu elles supportent des standards tel que SQL, JMS, http ou SOAP. Reste à choisir la brique la mieux adaptée à ses besoins. 26/04/2004 Page 35 sur 95

36 Chap. 1 EAI (Enterprise Application Integration) L EAI désigne à la fois des progiciels et des processus permettant d automatiser les échanges entre différentes applications d une même entreprise, ou les systèmes d information d entreprises différentes. Les applications peuvent ainsi s échanger des données, des messages et collaborer à l aide de processus partagé via, en général, un bus logiciel commun chargé du transport de données. Traditionnellement, deux facteurs principaux poussent au développement et à la mise en place de l EAI dans les entreprises : Le premier est lié à la nature souvent hétérogène du système d information de l entreprise qui oblige à établir des passerelles entre ses différentes composantes pour en exploiter toute sa richesse. Le second repose sur la flexibilité,qualité obligatoire à tout système d information moderne,qui se doit d être agile et adaptable dans un contexte de «time to market» accéléré. Les besoins d intégration naissent de ces constats et conduisent inévitablement à définir des ponts entre les applications de production (ERP),de logistique (SCM),de relation client (CRM),etc. Maintenant, les solutions d EAI apportent théoriquement une aide non négligeable à toutes les entreprises qui ont une implantation multi sites,des matériels différents, des bases de données multiples, des systèmes multi applicatifs, ou des problématiques B2B,avec une approche plus ou moins impactant sur le Système d Information : L EAI tactique intervient en effet dans un périmètre limité, généralement comme une brique d un projet fonctionnel de l entreprise. C est un composant qui va permettre d automatiser un ensemble de traitements localisés, sans impact sur le système d information global de l entreprise. Par exemple, en consolidant automatiquement tous les soirs les données commerciales issues des succursales d une enseigne de distribution, ou en autorisant l échange automatique des données entre un site WEB marchand et la gestion de la facturation. L EAI d infrastructure,quant à lui,implique une prise en compte et une évolution éventuelle du système d information global de l entreprise et de ses processus (Buisiness Process Management).Ce sont des solutions qui se justifient dans des environnements applicatifs complexes ou des environnements critiques, plutôt dans de grandes entreprises. L EAI devient alors l un des piliers de l architecture du système d information. Relier des applications entre elles est donc l un des rôles majeurs de l EAI (voir schéma). 26/04/2004 Page 36 sur 95

37 Schéma 8 : Exemple de mise en place d un EAI Un certain nombre de spécialistes prennent souvent comme image de l EAI une multiprise, où chaque application vient se brancher, via un connecteur standard relié au bus EAI. Le connecteur est simplement un exécutable, installé sur la machine hôte de l application,qui traduit les données provenant de l application dans un format lisible par un broker de messages et vice-versa. Deux types de connecteurs sont communément utilisés : Les connecteurs techniques reliés aux applications depuis leur base de données, des fichiers plats, etc. Les connecteurs applicatifs qui interfacent directement les API des applications. De fait, les connecteurs se standardisent autour de technologies telles que les services Web ( WSDL, SOAP, HTPP) ou JCA ( J2EE CONNECTOR Architecture).Au cœur de la plate-forme EAI, le bus EAI traditionnel est constitué d un courtier de messages (message broker) et d un MOM asynchrone (Middleware Orienté Messages).Le broker de messages applique des transformations sur les messages entrants, avant de les renvoyer vers les applications. Il est également capable de router une information sur une file d attente particulière du MOM. Ainsi, si une application destinataire n est pas accessible, le MOM stocke les messages entrants et sortants jusqu à ce qu ils soient récupérés par leurs destinataires. On peut donc remarquer que l EAI utilise vraiment des techniques éprouvées depuis de nombreuses années. 26/04/2004 Page 37 sur 95

38 Ainsi, une première génération d EAI comportait quatre briques de base : Le transport de données : par files d attente de messages qui encapsulent l information et la stockent jusqu à son exploitation. L extraction d informations des applications sources et l insertion dans les applications cibles par l utilisation de connecteurs. Les composants métiers sont utilisés pour effectuer des traitements complémentaires sur les données extraites. Ils enrichissent l intelligence de la plate-forme d intégration. Le moteur d intégration administre la transformation et le routage des données. Il fournit aussi des services de surveillance et d analyse de l activité. Cette première génération fut complétée par une offre de seconde génération, fondée sur les processus métiers et les échanges interentreprises, qui prend dorénavant en compte le modèle Internet ( TCP/IP, SMTP, http, FTP et XML) et apporte deux briques supplémentaires : Un moteur Workflow, pour modéliser et mettre en œuvre les processus métier de l entreprise au sein de la plate-forme d intégration, qui complète le travail des composants métiers Une infrastructure d échange B2B qui ouvre la plate-forme vers l extérieur, via les technologies XML Comme on peut le constater, l aspect «polyglotte» du bon progiciel d EAI est poussé à l extrême et en partant du modèle ISO d interconnexion des systèmes ouverts, L Hurwitz Group a d ailleurs défini un modèle de l EAI en 6 couches qui communiquent entre elles par le biais d interfaces (voir schéma) : La couche «brokers & protocoles» est chargée du transport des données. La couche «structures des données» extrait des données des applications et les intégrer à d autres applications. La couche «services et composants» assure des traitements métiers. La couche «applications» applique des règles de transformation et de routage. La couche «partenaire» modélise les processus métiers de l entreprise La couche «processus» permet aux entreprises de communiquer entre elles. 26/04/2004 Page 38 sur 95

39 Schéma 9: Modèle L EAI en 6 couches et le modèle OSI par le Hurwitz Group Une plate-forme d EAI moderne s appuie sur une console d administration (ou BAM pour Buisiness Activity Monitoring) qui facilite l administration de la plate-forme en exploitation, jusqu à la constitution de tableau de bord métier. 26/04/2004 Page 39 sur 95

40 Chap. 2 ESB (Enterprise Service Bus) L EAI traditionnel possède trois principaux défauts reconnus : Son manque de souplesse Sa complexité Son coût élevé XML est à l opposé de L EAI. L Enterprise Service Bus s appuie sur XML et tente de devenir un EAI universel. ESB est une nouvelle architecture s appuyant sur les Web Services et donc XML. Il s agit d un middleware d intégration. ESB tente ainsi de répondre aux problèmes liés aux EAI, en proposant une approche légère, et sur les Web Services. Or la difficulté, c est que l EAI en tant que tel, est loin d être massivement présent en entreprise et l intégration est un très long processus, commençant tout juste à entrer dans les mentalités. Certains se posent des questions sur l intérêt de l ESB et l opportunité de le considérer.le terme ESB a été défini par le Gartner Group. Il s appuie sur les standards Web Services, XML, et les connexions JCA. A cela s ajoutent des fonctions de transformation, de routage et du messaging. Le marché de l ESB est encore très jeune et il est donc difficile de tirer la moindre conclusion sur son avenir et son évolution. Il existe peu de solutions ESB.L un des avantages de l ESB est de proposer une méthode de connexion inter applications universelle s appuyant uniquement sur les standards reconnus des Web Services. XML est au cœur de cette technologie. L avantage de l architecture ESB est que l on peut mettre en place une intégration progressive. XML et les Web services sont très souples à ce niveau là. Mais l ESB nécessite tout de même de générer des fichiers et du code adéquat. Point de vue fonctionnement, le modèle de déploiement ESB est celui d un réseau d intégration basé sur des nœuds de services collaboratifs, et non d un modèle «hub and spoke» centralisé ou «server-centric» décentralisé. Les services sont hébergés à l échelle du réseau dans ce que l on appelle des conteneurs de services. Ces conteneurs de services sont implantés en des points stratégiques du réseau, selon l emplacement des terminaux applicatifs et le placement des services d intégration, tels que la transformation ou le routage intelligent. Il est également possible d ajouter dynamiquement des conteneurs de services sur un bus ESB sans avoir à reconfigurer ses autres composants. 26/04/2004 Page 40 sur 95

41 Schéma 10 : Passage des EAI de la topologie hub & spoke à la topologie Bus *Légende : «app» = application En général pour garantir la fiabilité de communication, dans une topologie de bus logique, les serveurs de communication sont distribués en différents points géographiques de réseau et jouent le rôle de concentrateurs de communication fiables entre les services. L intégration entre les applications se fait au moyen de messages XML. C est par les terminaux que les messages entrent et sortent des conteneurs de services. Les terminaux sont des abstractions logiques qui garantissent la transparence des protocoles et des emplacements. Grâce à cette cartographie du réseau, les services peuvent être mis à niveau, déplacés ou remplacés sans aucune incidence sur les systèmes métier opérationnels et les applications. Par ailleurs, pour anticiper la grande variété des services Web et des applications conçues pour être intégrées, l environnement ESB accepte volontiers l ajout de terminaux basés sur les services Web. L utilisation du langage XML par le bus ESB est le gage d une grande souplesse et rend l infrastructure plus résistante aux changements des applications émettrices, et n ont plus à s assurer que le message est dans le bon format. Il n est plus nécessaire de faire transiter les données par une centrale de transformation. Le bus ESB traite les applications de tous types comme des services, sans tenir compte de la façon dont elles sont connectées au bus. De ce fait, les entreprises passent progressivement à une architecture orientée services, tout en réduisant les risques, en maîtrisant l investissement en informatique. Il est plus simple à présent de créer des 26/04/2004 Page 41 sur 95

42 interfaces de services pour les applications conçues dans les environnements J2EE et.net, à l aide des outils opérationnels. Le bus ESB offre également plusieurs options pour manipuler les applications sous la forme d un jeu d interfaces de services. Les démarches les plus fréquentes consistent à utiliser des adaptateurs «File-Drop» ou spécifiques à chaque application. L adaptateur «File-Drop» interagit avec le bus ESB, via des messages XML (sous la forme d un service approprié basé sur des messages sur le bus), tout en interagissant avec l application cible au moyen du transfert de fichiers à plats. Les adaptateurs d applications sont généralement développés par des éditeurs tiers et font le lien entre l interface de service basée sur le message, telle que requise par le bus ESB, et les interfaces en code natif de l application cible. Quasiment tous les applications packagées, telles que SAP ou Siebel, et quasiment tous les middleware d entreprise, tels que CICS ou Tuxedo, disposent d adaptateurs tiers, garantissant ainsi l accès à la plupart des applications opérationnelles. Chaque service est décrit dans un répertoire commun. Les développeurs connectent les applications en recherchant les services appropriés dans ce répertoire, puis en orchestrant leur interaction. Le bus ESB procède à cette orchestration au moyen d un routage intelligent. L itinéraire XML comporte des ordres d appariement qui décrivent la séquence de services que le message devra respecter pour conclure un processus. Le routage des messages peut varier en fonction d évènements en temps réel et du contenu. L arrivée du bus ESB aura en effet un impact considérable sur le concept de «réseau» et sur la façon dont les entreprises gèrent leurs systèmes d intégration. Schéma 11 : Le middleware ESB dans sa forme aboutie 26/04/2004 Page 42 sur 95

43 Chap. 3 EII (Enterprise Information Integration) L objectif des «Enterprise Information Integration» (EII) est de construire un ou plusieurs référentiels de données à l échelle de l entreprise. Contrairement aux outils EAI, les EII se concentrent uniquement sur l échange de données. Ils permettent de construire une vue métier à partir de sources de données hétérogènes. Ces vues sont ensuite exposées sous la forme de services Web ou d API de différents formats (SQL, XML, JCA, etc..) afin d être consommées par des applications de l entreprise. Schéma 12 : Exemple d architecture EII 26/04/2004 Page 43 sur 95

44 Chap. 4 Orchestration de services Les plates-formes d orchestration de «Services Web» forment un sous ensemble des outils EAI, dans la mesure où elles remplissent le même rôle, mais en se limitant à SOAP. Elles s appuient globalement sur la même architecture que les outils EAI traditionnels (connecteurs, bus, moteur de transformation, etc ) et l on peut s appuyer sur les critères de l EAI pour les évaluer. Cependant, comme les ESB et les EII, les plates-formes d orchestration de services Web ne reposent pas encore sur des standards matures et figés pour l ensemble de leurs couches. L intégration des propositions de standards et leur évolutivité sont donc deux critères essentiels. Schéma 13 : Orchestration de services Malgré leur hétérogénéité, la plupart des outils reposent sur une approche similaire. Le processus métier est d abord formalisé, importé ou ressaisi dans l outil de design du moteur d orchestration. Chaque tâche est ensuite enrichie d informations techniques. La validation d une commande s effectue, par exemple, par un appel à un composant COM ou Java, un connecteur EAI, un sous processus, ou bien encore par la publication d un message dans une file d attente d un MOM. L enrichissement d une tâche consiste donc à indiquer l adresse du composant sous-jacent, puis à lui communiquer les paramètres nécessaires à son exécution. Cet enrichissement s effectue directement dans l outil de design. La plupart propose de découpler ces appels : l adresse du service est stockée dans un référentiel, qui joue le rôle de couche d abstraction. Il est ainsi possible de remplacer un service fourni par un PGI (ERP) par un développement spécifique, sans remettre en cause le scénario. Seule l adresse physique des services devra être modifiée au niveau de l annuaire. 26/04/2004 Page 44 sur 95

45 L exécution du processus est déclenchée par l arrivée d un message dans une file d attente ou par un fichier dans un répertoire. Le moteur d orchestration interprète alors le scénario stocké dans un fichier au format XML (BPEL4WS,XLang, etc.). Son moteur de règle évalue les données en entrée et appelle le service adapté. Ce dernier renvoie son résultat au moteur d orchestration, et le processus se poursuit ainsi jusqu à son terme. La majorité des moteurs d orchestration savent paralléliser les plates-formes d orchestration de processus intègrent toutes leur propre outil de design, lequel sert à fragmenter la modélisation métier en sous processus techniques. Les outils les plus avancés découplent la logique métier de la technique au travers d un référentiel qui joue le rôle de couche d abstraction. L hétérogénéité de l offre devrait, peu à peu, être masquée par l émergence de standards tels BPML ou BPEL4WS, qui obligeront les éditeurs à clarifier leur offre. 26/04/2004 Page 45 sur 95

46 Chap. 5 Conclusion Comme nous l avons indiqué en introduction de ce chapitre, ces solutions ne sont pas forcements concurrentes et peuvent être complémentaires. De plus, s ajoutent des solutions «Open Source» dédiées à l intégration de données et d applications. Encore en phase de développement ou de maturation pour la plupart d entre eux,ces outils se caractérisent par un manque flagrant de packaging. Il faut donc commencer par intégrer ces briques techniques les unes aux autres pour disposer d une solution d intégration complète. Autre point faible : le manque de connecteurs, surtout applicatifs. En revanche, la qualité des implémentations d outils tels que Joram, OpenMS ou jbossmq n est plus à démontrer. Et comme plus de 75% des projets d intégration passent actuellement par les couches basses (connecteurs fichiers, SQL, FTP, etc ) l absence de connecteurs applicatifs n est pas gênante pour la plupart des projets tactiques. Voici un récapitulatif des coûts approximatifs constatés pour ces différentes technologies : Plate forme EAI traditionnelle : Entre et ø ø pour un connecteur technique supplémentaire Entre et ø pour un connecteur applicatif EII : Entre et ø selon les éditeurs et un coût moyen de ø Orchestration : Prix des outils de modélisation entre et ø Moteur d orchestration entre et ø 26/04/2004 Page 46 sur 95

47 Titre 2 Panorama des outils d intégration Nous présentons ici les trois outils d intégration les plus courant du marchés pour les petits et moyens projet d intégration. Chap. 1 BizTalk BizTalk Server 2004 est une solution serveur permettant de connecter des applications d entreprise, des utilisateurs et des partenaires externes, à travers des processus métiers configurables. Il simplifie la tâche des développeurs dans l'écriture de ces processus métiers, il simplifie la liaison avec d'autres systèmes hétérogènes et présente sous une vue standard les données et processus métiers. BizTalk Server repose en grande partie sur les Web Services en communiquant avec des messages XML (au format SOAP). Cette communication est standardisée et permet d'appeler des composants écrits dans n'importe quel langage, tournant sur n'importe quel système d'exploitation et qui peut se trouver n'importe où sur la planète ; difficile de faire mieux au niveau interopérabilité. C'est pourquoi BizTalk Server, qui permet de faire communiquer des systèmes hétérogènes entre eux, utilise ces Web Services. L'autre standard utilisé par BizTalk est BPEL (Business Process Execution Language), une spécification concernant les processus métiers qui permet d'échanger ces processus entre différents systèmes. 2 BizTalk : un serveur d EAI et de B2B Les processus de B2B (Business To Business) permettent aux sociétés d'automatiser le traitement des commandes et de gérer la chaîne logistique allant du fournisseur au client (SCM, Supply Chain Management). Pour augmenter l'efficacité opérationnelle de votre société, vous pouvez utiliser BizTalk Server pour permettre à des systèmes hétérogènes distribués dans le monde entier de communiquer entre eux..net est la nouvelle plate-forme de développement de Microsoft qui remplace les technologies COM et ASP existantes. Cette plate-forme permet de développer tout aussi bien des applications client lourd (WinForms) que des applications web (WebForms) ou des web services. Le modèle de développement est très homogène et la bibliothèque de classes est accessible de la même manière, quelque soit le type d'application. Le développement est donc grandement simplifié (même s'il faut un certain temps pour s'habituer à la richesse de la bibliothèque de classes), tout en sachant que vous pouvez utiliser votre langage préféré (Visual Basic, C#, Perl, Python, Cobol, plus d'une trentaine de langages sont supportés). De plus,.net est multi plateformes : les applications.net que vous écrirez tourneront sans problème sur toutes les versions de Windows. Un exemple d intégration avec BizTalk est fournit plus loin dans notre document (Partie 3). 26/04/2004 Page 47 sur 95

48 Chap. 2 L offre Tibco La vision générale de Tibco rejoint cette idée. Aujourd'hui les entreprises s'orientent vers l'intégration d'applications ebusiness. On peut considérer que ce type d'applications est l'avenir des entreprises et de l'économie en générale. C'est pourquoi cela représente un investissement colossal pour toute entreprise et cela dans n'importe quel secteur d'activité. Cette vision globale de L'EAI intègre de plus en plus des dimensions humaines au sein de l'entreprise mais aussi à l'extérieur. En effet, cela favorise l'implication des employés, le travail collaboratif, l inter et l intra- communication, la créativité, de nouvelles idées et la prise de décision. La dimension humaine, à l'extérieur de l'entreprise se concrétise par le travail en étroite collaboration avec les différents partenaires en amont et en aval. En ce qui concerne les fournisseurs, cela permet d'augmenter son pouvoir de négociation et d'obtenir des tarifs plus intéressants, d'offrir aux clients un meilleur service, de répondre plus rapidement à leurs besoins. La combinaison de la dimension humaine à la dimension technique de l' EAI, permet aux entreprises d'aller vers leurs objectifs de maximisation des profits grâce à de nombreux avantages : Plus grande flexibilité de la chaîne de valeur. Réductions des coûts grâce à des processus métiers bien intégrés Meilleure prise de décision Favorise l'investissement Meilleure réactivité aux changements du marché. Une infrastructure plus flexible et adaptable Meilleure vision du consommateur Meilleure visibilité sur les opérations menées en interne Lancement plus rapide de nouveaux produits sur le marché Amélioration de la satisfaction et de la fidélisation des clients Optimisation des relations avec les clients et partenaires Un autre élément essentiel pour réussir son intégration d'application, consiste à s'entourer des bons partenaires de développement. Ils apportent également une plus value aux applications. En effet, la plupart des logiciels vendus sur le marché sont compatibles avec les applications EAI. Les entreprises peuvent ainsi bénéficier du support des éditeurs de logiciels. L'accroissement des applications B to B, l'accès des partenaires aux systèmes d'information etc incitent les éditeurs EAI à améliorer sans cesse leurs offres et aller vers les entreprises, favorisant ainsi le développement d'applications B to B. C'est pourquoi, les éditeurs sont de plus en plus nombreux à rendre, leur plate-forme compatible avec les différentes sémantiques (http, SMTP, RosettaNet ). On parle de plus en plus de gestion des processus. 26/04/2004 Page 48 sur 95

49 Tibco s'inscrit dans cette stratégie de développement et offre une solution globale allant de l'intégration d'application, c'est à dire une solution EAI basique, jusqu'à la communication des infrastructures inter et intra entreprises. L'offre de Tibco est ainsi construite : L'intégration d'applications permet aux entreprises de faire face à un environnement informatique de plus en plus complexe, incluant différentes bases de données, applications en tout genre, ainsi que la multiplicité des partenaires. C'est pourquoi, Tibco, comme d'autres éditeurs de logiciels, mettent au point des solutions permettant l'interopérabilité entre les applications et les partenaires. La finalité du concept EAI ou des processus d'intégration est de faire en sorte que les entreprises améliorent leur business et leur profitabilité. En effet toutes ces applications visent à resserrer les liens avec les partenaires stratégiques (clients, financiers, fournisseurs ). Conclusion Grâce à Internet, les entreprises peuvent s'allier avec des partenaires à l'autre bout du monde, et jouer sur la concurrence. Une intégration B to B permet une collaboration interactive grâce à l'automatisation des échanges. 26/04/2004 Page 49 sur 95

50 Chap. 3 L offre Sybase Sybase offre aux entreprises une infrastructure e-business complète pour intégrer, gérer et distribuer des applications, des données et du contenu partout où ils sont nécessaires. Avec son offre Entreprise Portal, ses solutions mobiles et sans fil et ses solutions destinées aux marchés verticaux, Sybase se classe parmi les 10 principaux éditeurs de logiciels dans le monde. En tant qu éditeur d infrastructure, Sybase s est positionné sur le marché de l intégration depuis le rachat de New Era of Networks en juillet L actualité Sybase est marquée par le lancement de sa nouvelle «Business Process Integrator Suite». BPI Suite permet de développer, de déployer et d optimiser les processus métiers tout au long de la chaîne de valeur de l entreprise et démontre l intégration réussie entre l offre de Sybase et celle de New Era of Networks. Avec cette solution complète, Sybase est en mesure d adresser les problématiques complexes d échanges intra et interentreprises et de gestion des processus, problématiques qui vont bien au-delà de la simple intégration d applications. En effet, Sybase BPI Suite est une solution complète permettant un développement et un déploiement de l ensemble des processus métiers de l entreprise. Parce que les entreprises étendent aujourd hui leurs processus au delà de leurs frontières physiques, BPI Suite fournit les outils nécessaires pour intégrer et automatiser les interactions et les flux d information sur l ensemble de la chaîne de valeur étendue. BPI Suite supporte la majorité des standards de gestion et d intégration des processus B2B, notamment les Web services (WSDL, UDDI et SOAP), RosettaNet et ebxml. BPI Suite est une solution complète de développement, de gestion et d intégration de processus métiers reposant sur un serveur d application ouvert. Celui-ci permet la création de nouvelles applications tandis que le serveur de processus adresse le développement de processus complexes pour lier les nouvelles applications à celles déjà en place. BPI Suite offre des fonctionnalités de visualisation, de développement et de déploiement des processus automatisés ainsi que des outils de conception et de représentation graphique de ces processus, qui peuvent être ensuite rapidement déployés sur le terrain. Résultat : les entreprises peuvent facilement contrôler, analyser et affiner leurs processus en fonction de l évolution de leur environnement. C est un gage de qualité de service rendu à leurs clients et à leurs partenaires. La suite assure l intégration et l optimisation des processus sur l ensemble des systèmes de l entreprise pour garantir un accès unique à toutes les informations pertinentes sur ses clients, partenaires et fournisseurs indépendamment de leur source. 26/04/2004 Page 50 sur 95

51 BPI Suite est donc une offre complète d intégration (interne et externe de l entreprise) s appuyant sur une architecture ouverte. C est-à-dire qu elle n est pas figée et qu elle permet par la suite l évolution des applications mises en place. Le serveur de processus, lui, intègre le développement de processus complexes afin de relier les nouvelles applications aux applications existantes. Bien qu'utilisant des solutions de différents niveaux, l'intégration d'application (EAI) et l'intégration de processus métiers (BPM) nécessitent une visibilité au niveau métier de l'activité. Cela fournit notamment le complément obligatoire de l'automatisation des flux et des processus qu'est la gestion d'exception. Si pour une raison ou une autre, un message ou un processus ne pourrait être traité convenablement, l'entreprise doit être informée immédiatement de ce problème et doit avoir la capacité d'intervenir. De plus, un suivi de l'activité globale doit être fourni pour pouvoir attester en temps réel de l'efficacité de tel ou tel processus, ou le cas échéant le besoin d'une refonte ou d'une modification de ce processus. 26/04/2004 Page 51 sur 95

52 Outre ses fonctionnalités, BPI Suite, offre les outils suivants pour la mise en place des processus : Visualisation Développement Conception Représentation graphique des processus Tout ceci représente pour l entreprise, un avantage non négligeable puisque cela lui permet d analyser et affiner ces processus métiers et d en assurer l évolution. L entreprise bénéficie ainsi d informations pertinentes sur ses partenaires au moment opportun. De plus, le développement se faisant plus rapidement, cela représente un retour sur investissement plus rapide. BPI Suite permet aux responsables informatiques de déployer rapidement des projets d intégration en plusieurs phases. Sybase a fixé le prix de sa suite dans cette optique de déploiement incrémental. Autrement dit, un projet donné n aura pas à supporter le coût généralement associé au déploiement d une solution couvrant toute l entreprise. Le service informatique peut désormais développer et déployer une solution complète d intégration et d optimisation des processus de l entreprise en respectant le budget alloué et en ayant l assurance d un retour sur investissement rapide. 26/04/2004 Page 52 sur 95

53 Titre 3 Le marché de l intégration en France Le marché français de l intégration d applications ou EAI reste quasi indemne. Même s il ne connaît plus de croissance exponentielle. Alors que le contexte économique est incertain, les demandes de mise en place de projets EAI continuent de croître dans l hexagone. Et les SSII et les intégrateurs,qui représentent la majorité de ce secteur (65 % pour les services,contre 35% pour les produits en 2003),devraient pouvoir maintenir leur part de marché. Les principales causes de cette montée en puissance des solutions EAI dans les entreprises sont l augmentation de la complexité applicative du front office et la nécessité d intégrer les applications stratégiques gestion de la relation client, gestion des processus, gestion collaborative, décisionnel, mesure et contrôle d activité, e-buisiness Selon les cabinets d études, les principaux relais de croissance de ce marché dans les prochaines années seront les projets d optimisation des infrastructures logicielles, les refontes de systèmes d information,les mises en place de standards communs, et les projets d intégration des processus métiers. D autant plus que les entreprises françaises ont un léger retard en matière de projets d EAI techniques et fonctionnels par rapport à leurs homologues anglosaxons. Schéma 14 : La croissance du marché français de l EAI 26/04/2004 Page 53 sur 95

54 Les SSII, comme les éditeurs, devraient aussi développer leurs revenus en raison d une demande en conseil plus poussée. Les prestataires ne vont plus seulement travailler sur des études de cadrage de projet d EAI et d aide au choix, mais aussi sur l amélioration des processus métier de l entreprise. Aussi d autres futurs projets, comme l intégration étendue des architectures orientées services et la mise en place de solutions, pourraient-ils relancer la progression du marché des solutions EAI en France? Schéma 15 : Les marchés de l intégration et de l édition en France Si l on prend en compte la couche transport, Sopra/axway (avec XFB) et IBM (avec MQSeries) sont en tête en matière de ventes de services comme de logiciels..plus précisément, ils ont au coude à coude dans l édition de logiciels EAI. 26/04/2004 Page 54 sur 95

55 Titre 4 Critères comparatifs sur l EAI Dans le but de faciliter la mise en place d une plate-forme d EAI dans l entreprise, voici un extrait du guide comparatif sur l intégration d application offrant un questionnaire comparatif dans l étude préliminaire dans la mise en place d une solution EAI (source 1 Profil & positionnement Le produit a-t-il un positionnement : EAI : Mode batch transformations lourdes et Mode «fil de l eau» - transformations légères ETL : Mode batch transformations lourdes EII (Enterprise Information Integration) : Dispatch de requêtes, gestion de contenu 2 Transport / MOM A Nature du middleware utilisé au niveau de la couche transport Le middleware est-il intégré à la solution? Est-ce un middleware du marché? Si Oui, le(s)quel(s)? Le middleware est-il ouvert sur d autres middlewares? Si Oui, le(s)quel(s)? Le middleware offre-t-il une intégration avec des annuaires LDAP? Si Oui, le(s)quel(s)? Le middleware autorise-t-il des connexions avec des serveurs d application? Si Oui, le(s)quel(s)? 26/04/2004 Page 55 sur 95

56 B Fiabilité du middleware Le middleware assure-t-il l intégrité du contenu des messages? Si Oui, par quels moyens? CRC Parité Autres Le middleware respecte-t-il l ordre des messages? C Performances du middleware Existe-t-il des abaques de benchmarks? Si Oui, lesquels? Préciser les résultats : Selon les axes taille des messages Nombre de messages par seconde Autres Comment sont implémentées les files d attentes? D Types de protocoles Le middleware autorise-t-il des échanges synchrones? Le middleware autorise-t-il des échanges asynchrones? Le middleware fournit-il une API JMS? Le middleware est-il compatible JMS? Le middleware autorise-t-il l implantation de webservices? Si Oui, comment? Le middleware permet-il la mise en œuvre de RPC (Remote Procedure Call)? 26/04/2004 Page 56 sur 95

57 Le protocole Request/Reply est-il fourni? Le protocole Publish/Subscribe est-il fourni? Quels sont les algorithmes de compression des données transportées proposés? E API utilisateur Le middleware est-il facile d usage?, justifier : Le middleware est-il riche en terme de fonctionnalités? Paramétrage des fonctionnalités de transport Paramétrage des files d attente Définition des protocoles Autres 3 Flux techniques / Orchestration /Transformation & Routage L EAI autorise-t-il la détection des doublons avant transformation? Si Oui, par quel algorithme? Quelles sont les manipulations de données offertes : Opération de duplication Aiguillage regroupement de messages Autres Quelle est la complexité des algorithmes (traduisant des besoins métier) implantables par le biais de l IHM? Est-il possible d intégrer des programmes externes de transformations? Dans quel contexte est-on obligé d intégrer des programmes externes? Flux Orchestration Transformation Autres 26/04/2004 Page 57 sur 95

58 4 Gestion de référentiel et de formats pivots / méta données L outil propose-t-il un moyen pour modéliser le référentiel de données? L outil propose-t-il la gestion d un référentiel de règles «métier»? Est-il possible d utiliser un format pivot en vue de relâcher le couplage entre les formats de données source et les formats de données cible? L outil propose t-il un mécanisme d introspection pour récupérer les structures de données de SGBDR? Utilise-t-on le paradigme objet pour modéliser le référentiel? Comment s effectue la gestion du référentiel? Centralisée Décentralisée La modélisation du référentiel peut-elle être effectuée par un outil du marché? Si Oui, lequel : ERStudio Oracle Designer Rational Rose SilverRun Autres 5 Processus métier / Workflow / BPM Quel type de cadencement peut-on assurer aux processus? Quelle est la nature du moteur de règles? Déclenchements sur états Déclenchements sur évènements Déclenchements sur données Autres Comment sont gérées les transactions? CICS MTS Tuxedo Autres Comment sont gérés les processus et leurs instances? Quelles sont les facilités de description des dépendances tâches/événements? 26/04/2004 Page 58 sur 95

59 La modélisation des processus (à l aide de diagrammes d activité, par exemple UML) peutelle être effectuée par un outil du marché? Si Oui, le(s)quel(s) : 6 Connectivité A Connecteurs techniques Connecteurs XML? Connecteurs EDI? Si Oui, lesquels? Connecteur ODBC? Connecteur JDBC? Connecteur OLAP? Connecteur fichiers? Connecteur COM? Connecteur Corba? Si Oui, quel ORB? Connecteur J2EE? Si Oui, est-ce un connecteur : http Java EJB Autres connecteurs techniques : 26/04/2004 Page 59 sur 95

60 B Connecteurs applicatifs Connecteurs applicatifs ERP? SAP : BAPI IDOC Oracle Application : Hiérarchies Accès direct Peoplesoft : Hiérarchies Accès direct Navision Baan JD. Edwards Autres Connecteurs applicatifs CRM? Siebel EIM BusinessComponents Hiérarchies Accès direct Pivotal Autres Connecteurs applicatifs GPAO? Lesquels? Connecteurs applicatifs e-commerce? Lesquels? Connecteurs applicatifs Business Intelligence? Lesquels? Autres connecteurs applicatifs? C Fonctions supportées Manipulation de données relationnelles : Clés discontinues Jointures externes Autres : Manipulation de fichiers? Si Oui, quelles manipulations? Manipulation de répertoires? Si Oui, quelles manipulations? 26/04/2004 Page 60 sur 95

61 Les échanges pour chacun des connecteurs sont-ils? Unidirectionnels Bidirectionnels 7 Sécurité A Connexions applicatives Quels sont les protocoles supportés? Quels sont les algorithmes de cryptage? Quels autres mécanismes de sécurité sont intégrés dans le produit? PKI Signature électronique SSL Autres B Couche transport Quels sont les protocoles supportés? Quels sont les algorithmes de cryptage? Quels autres mécanismes de sécurité sont intégrés dans le produit? PKI Signature électronique SSL Autres 8 Méthodologie supportée Existe-t-il une liste de best practices permettant de définir des règles de spécification? Si Oui, lesquelles? Existe-t-il une liste de best practices permettant de définir des règles de conception? Si Oui, lesquelles? 26/04/2004 Page 61 sur 95

62 Existe-t-il une liste de best practices permettant de définir des règles de développement? Si Oui, lesquelles? Existe-il des métriques d estimation et de chiffrage des projets? Si Oui, combien de retours d expérience? Existe-t-il une démarche méthodologique assurant la maîtrise du cycle de développement (incluant la maintenance et la gestion d impact lors des évolutions)?, décrire : Existe-t-il des normes de nommage? Existe-t-il des normes de développement? 9 Installation & intégration A Installation L environnement de développement offre-t-il une facilité d installation?, justifier : Quelles sont les plates-formes disponibles? Windows NT, et versions? Unix, et versions? Autres systèmes d exploitation et versions? B Manipulation IHM Quelle est la facilité de manipulation de l IHM en vue de la création, modification, mise en œuvre des flux? Quelle est la facilité de manipulation de l IHM en vue de la définition des données pivots? Quelle est la facilité de manipulation de l IHM en vue de la définition des transformations? Quelle est la facilité de manipulation de l IHM en vue de la mise en œuvre des tests pour les transformations? L outil permet-il de tester les connecteurs sans qu il y ait transfert de données? 26/04/2004 Page 62 sur 95

63 Dispose-t-on de : Templates Bibliothèques de transformation Palette d objets graphiques Autres Peut-on faire des analyses d impact? Assure-t-on facilement le suivi des nouvelles versions? Si Oui, comment? Dispose-t-on de générateur automatique ou assisté de documentation? Dispose-t-on de générateur automatique ou assisté de documentation des phases de traitement sur le graphe des flux de l interface? Est-il possible d effectuer des développements concourants en équipe avec gestion multipostes et multi-utilisateurs (administration des accès )? Sait-on mettre en place un cycle test, validation, mise en production? C Déploiement Est-il possibile de répartir les traitements EAI sur plusieurs serveurs? Comment gère-t-on le load balancing? Comment gère-t-on la scalabilité? Où sont positionnés les fichiers système? D Architecture ciblée Quel est le type d architecture ciblée? NetworkCentric ESB Hub & Spoke 26/04/2004 Page 63 sur 95

64 E Apprentissage Comment peut-on qualifier la facilité d apprentissage ou de prise en main du produit? Quelle est la qualité de la documentation? La documentation est-elle disponible en langue française? 10 Administration & Supervision Est-il possible de tracer des événements applicatifs? Si Oui, lesquels? Suivi Stockage Archivage Remontée des alertes Autres Est-il possible de tracer des événements système? Si Oui, lesquels? Y a-t-il journalisation des événements? Journalisation des échanges Journalisation des process Autres L outil permet-il de gérer les rejets techniques (intégrité bases de données )?, comment? L outil permet-il de gérer les rejets fonctionnels (règle métier non respectée )?, comment? Disponibilité d un outil d administration (console )?, détailler : Disponibilité d un outil d administration du référentiel? Si Oui, pour quelles actions? Création Dimensionnement Supervision Nettoyage des logs Autres 26/04/2004 Page 64 sur 95

65 Possibilité d ordonnancement? Si Oui, le produit présente t il graphiquement la logique d enchaînement des chaînes de traitement et conditions d enchaînement? Possibilité d intégration d un outil d ordonnancement? Si Oui, le(s)quel(s)? Gestion des autorisations d accès? Gestion des profils? Assure-t-on une intégration facile avec les outils d administration du marché? Si Oui, lesquels? 26/04/2004 Page 65 sur 95

66 Partie 3 Implémentation d un processus avec BizTalk Titre 1 Introduction Ce document a pour but d analyser et d apporter une réponse à une problématique concrète, la gestion du processus de publication d informations et de contenu, à l aide d un outil de Business Process Management (BPM), Microsoft BizTalk Server Il est en effet très fréquent d avoir à gérer une problématique comme celle-ci, et dans un monde où, de plus en plus, les informations affluent de sources disparates, il peut être intéressant de se pencher sur la manière de gérer le processus de publication d informations. Ce processus s étend de la récupération et de l agrégation des informations jusqu à sa publication finale sur un portail ou un site web, en passant par les différentes étapes intermédiaires de confirmation et de validation. Les solutions mises en œuvres pour gérer ce processus consistent généralement en un applicatif métier, permettant la saisie des articles qui, pour pouvoir être publiés, sont soumis à un contrôle et validation d un tiers. Si ce type d application permet d apporter une réponse et une solution à un besoin bien précis, on se retrouve rapidement limité par leurs capacités à gérer des informations issues d autres référentiels que ceux prévus par l application. En effet, est-ce que ces applications permettent de récupérer et d agréger des informations sur Internet (via Web Services ou flux RSS Real Simple Syndication), telles que les derniers articles Reuters ou les dernières cotations boursières? Ces applications permettent elles de gérer des articles postés par ou par Web Services? C est cette multitude de référentiels d informations qui fait apparaître le besoin d externalisation du processus de gestion de contenu (agrégation, validation, publication) au sein d un BPM tel que BizTalk Server /04/2004 Page 66 sur 95

67 Chap. 1 Description du scénario La société Contoso dispose d un site intranet réalisé avec SharePoint, sur lequel est publié du contenu provenant des rédacteurs de Contoso, mais aussi de sources d informations publiques, comme les flux RSS du New York Times. Pour pouvoir saisir et publier de nouveaux articles sur leur intranet, les employés de Contoso ont plusieurs possibilités : Une application web de saisie spécifique, alimentant une base de données Un formulaire de saisie InfoPath qui soumet les articles via Web Service L envoi d articles par à submitpost@contoso.com Une fois saisis et envoyés, les articles sont soumis au contrôle et à la validation du responsable éditorial de Contoso (par ), qui décide alors d approuver ou non la publication de l article sur le site intranet. Le responsable éditorial se verra également soumettre l ensemble des articles nouvellement publiés sur le flux RSS du New York Times. C est pour pouvoir gérer l ensemble des canaux d informations et de contenu alimentant le site intranet, que le besoin d externalisation de ce processus se fait ressentir. En effet, l intérêt de décrire et d implémenter les règles métiers composant le processus au sein de BizTalk Server 2004, est de pouvoir être capable d exposer un service unique et générique de validation et de publication, totalement découplé et indépendant des applications de saisies et de récupération de contenu. Chap. 2 Fonctionnalités mises en oeuvre Voici la liste des principales fonctionnalités de BizTalk Server 2004 qui seront mises en oeuvre : Orchestrations Schémas & Maps Publication de Web Services d invocation d une orchestration Invocation de Web Services en back-end Invocation via InfoPath des Web Services publiés par BizTalk Server 2004 Définition de règles métiers au sein du «Business Rules Engine» Publication et intégration d un formulaire InfoPath dans Sharepoint 26/04/2004 Page 67 sur 95

68 Chap. 3 Architecture de la solution Le schéma ci-dessous représente l architecture globale de la solution et permet de visualiser la cinématique métier du processus : Schéma 16 : architecture de la solution (exemple Contoso) Les employés de Contoso rédigent leurs articles sur l application web dédiée à leur saisie, puis soumettent leurs articles (1). Ces derniers sont alors soumis à l orchestration BizTalk par Web Service (2). D autres possibilités sont offertes aux rédacteurs de Contoso pour soumettre leurs articles. Ils peuvent en effet utiliser et remplir un formulaire InfoPath (3), qui une fois soumis, transmet l article à BizTalk Server 2004 via Web Service (4). 26/04/2004 Page 68 sur 95

69 On peut également imaginer qu il leur soit accordé la possibilité de rédiger leurs articles dans un et de l envoyer à submitpost@contoso.com (5). Ces s seront automatiquement interceptés et traités par BizTalk Server 2004 (6). Les flux RSS du New York Times seront également interrogés automatiquement par BizTalk Server 2004 (7) et les différents articles ainsi récupérés seront soumis au même traitement et processus de validation que les articles des rédacteurs de Contoso. En fonction de la catégorie de l article («Business», «Politiques», «Science», «Sports», «Technologie», etc.), une règle métier définie au sein du «BizTalk Rules Engine» permet de choisir la personne à qui il faut transmettre l article. Ainsi, les articles «Business» seront envoyés à business@contoso.com, alors que les articles «Technologie» seront transmis à tech@contoso.com (8). Chaque article traité par BizTalk Server 2004 est donc soumis par à l approbateur correspondant à la catégorie de l article (9), qui peut alors choisir d approuver ou non la publication finale de l article (10). Si l article est approuvé, alors il est publié sur l intranet de Contoso (11). Enfin, un est envoyé à l auteur de l article pour lui notifier que son article a été publié ou refusé, accompagné d un commentaire de l approbateur (12). 26/04/2004 Page 69 sur 95

70 Titre 2 Implémentation de la solution Chap. 1 Schémas La première des choses à faire lors de la configuration d un nouveau processus métier, est de créer les schémas XSD décrivant la structure et la grammaire des messages échangés tout au long de l orchestration. En effet, BizTalk Server 2004 fonctionne essentiellement à base de messages XML afin de communiquer et transmettre les données entre les différents acteurs intervenants dans l orchestration. Dans notre cas, les schémas permettent de définir la structure du message SOAP reçu pour activer une instance de l orchestration, mais aussi la structure du message de la réponse à retourner. Nos schémas sont définis et regroupés dans une «assembly» «ContosoCM.Schemas» qui sera référencée et exploitée par d autres projets BizTalk de notre solution «ContosoCM». Voici les schémas définis dans notre projet : 1. SubmissionRequest : Ce schéma définit les différents éléments à envoyer pour soumettre un article par Web Service. 2. SubmissionResponse : Une fois soumis, est associé à l article un identifiant «ArticleId» qui est retourné dans la réponse du Web Service. 3. ArticleApprobator : Ce schéma permet de définir le message qui sera exploité par le moteur de «Business Rule» de BizTalk, afin de déterminer la personne à qui il faut envoyer l article pour approbation. 26/04/2004 Page 70 sur 95

71 Chap. 2 Orchestration Passons maintenant à la description même de notre processus métier, c'est-à-dire à la création de notre schéma d orchestration. Pour cela, nous avons un second projet BizTalk intégré à notre solution, qui se nomme «ContosoCM.Orchestration». Voici les étapes clés de la cinématique de notre processus métier : Réception de la requête Insertion de l article dans la base Envoie de la réponse Création d une règle métier Appel de la règle métier Envoie de la notification et demande d approbation Section 1 Réception de la requête Une instance de notre orchestration est activée dés qu un nouveau message de type «SubmissionRequest» est soumis à BizTalk Server 2004 par l intermédiaire du port «ArticleSubmissionPort». Ce port permet de recevoir les requêtes SOAP envoyées par nos utilisateurs (à l application Web Services «ContosoCMWS») et de les soumettre au traitement de notre orchestration. 26/04/2004 Page 71 sur 95

72 Section 2 Insertion de l article dans la base Une fois la requête reçue, la première étape de son traitement consiste à insérer l article dans la base de données de l intranet. L article n est pas publié, il est uniquement stocké. Pour cela, nous invoquons le Web Service «ArticleService.InsertArticle», grâce au port de communication «InsertArticlePort». Un assistant nous a permis de générer automatiquement ce port «InsertArticlePort» à partir du WSDL du Web Service. Nous avons juste eu à créer les messages à envoyer (InsertArticleRequestMsg) et à réceptionner (InsertArticleResponseMsg) de la part du Web Service. Consommer un Web Service avec BizTalk Server 2004 est donc d une extrême simplicité, car aucune ligne de code n est nécessaire ; tout le côté technique d invocation d un Web Service est entièrement pris en charge par BizTalk Server 2004 et totalement transparent à ses utilisateurs. 26/04/2004 Page 72 sur 95

73 Section 3 Envoi de la réponse Une fois l article inséré dans la base de données de l intranet, la valeur «ArticleId» de l article nouvellement créé est retournée à l utilisateur, par Web Service, en réponse à sa requête initiale de traitement de son article. Le port utilisé pour renvoyer la réponse est donc le même que celui pour recevoir les requêtes des utilisateurs ; il s agit du port «ArticleSubmissionPort». 26/04/2004 Page 73 sur 95

74 Section 4 Création d une règle métier avec le «Business Rule Composer» Il faut ensuite déterminer la personne responsable de l approbation de l article, et ce, en fonction de sa catégorie. Pour cela, nous devons créer une «Business Rule» (règle métier) à l aide du «Business Rule Composer», qui va permettre de définir les personnes à qui il faut envoyer les articles, en fonction des catégories. L intérêt de définir et d externaliser cette logique métier au sein du «Business Rule Engine», en dehors de l orchestration, est de pouvoir être capable d effectuer des modifications beaucoup plus facilement, sans avoir à éditer, recompiler et redéployer notre orchestration. 1 Définition du «Vocabulary» Pour créer une règle métier, il faut tout d abord définir ce que l on appelle un «Vocabulary». Il s agit d un groupe de «Definitions», qui correspondent en quelque sorte aux entités et variables que l on utilisera dans notre «Policy» (règle métier). Dans notre cas, nous avons créé une définition «Category», de type XML Element (en mode GET), qui permettra d aller récupérer la valeur de l élément «Category» du message XML soumis. Nous avons également une définition «Approbator », de type XML Element (en mode SET) qui va nous permettre de définir l adresse de l approbateur et de la retourner au sein de l orchestration. Cette définition pointe sur l élément «Approbator » du message XML soumis. Enfin, nous avons une troisième définition «Category Values», de type «Set of values» qui permet d énumérer les différentes catégories possibles. 26/04/2004 Page 74 sur 95

75 2 Définition de la «Policy» Maintenant que notre «Vocabulary» a été définit, nous pouvons créer notre «Policy». Pour chacune des catégories possibles, nous définissions une «Rule» (règle), qui va évaluer la valeur de la définition «Category», et mettre à jour la définition «Approbator » en conséquences. Par exemple, la règle «Business» définit que si la catégorie est égale à «Business», alors, il faudra envoyer la notification et la demande d approbation à business@contoso.com : Le principe est le même pour les autres règles «Politiques», «Science», «Sports» et «Technologie». 26/04/2004 Page 75 sur 95

76 Section 5 Appel de la règle métier Notre règle métier déployée, nous pouvons désormais l invoquer au sein de notre orchestration. Pour cela, il faut préparer le message XML «ArticleApprobator», puis invoquer la règle métier «ApprobationConfig» en passant le message «ArticleApprobator» en tant que paramètre. C est grâce à l appel de cette règle métier, que nous allons pouvoir récupérer l adresse de la personne à qui il faut transmettre l article. L appel à la règle métier est effectuée au sein d un «Scope», configuré en mode de transaction «Atomic», afin de s assurer que les changements d état, comme la modification de variables ou de messages, ne soient visibles en dehors du scope que lorsque la transaction atomique est correctement validée et terminée. 26/04/2004 Page 76 sur 95

77 Section 6 Envoi de la notification et demande d approbation Maintenant que nous avons récupéré l de la personne responsable de l approbation de l article en cours de traitement, il suffit de créer l de notification à envoyer, qui contiendra : Le titre de l article Le corps de l article L auteur de l article et son Un lien vers la fiche d approbation / déclinaison de l article L est transmis à l approbateur via le port «Notification Port». La propriété «Port Binding» de ce port a pour valeur «Dynamic». Cela signifie que c est un port dynamique, c'est-à-dire qu il n est pas configuré au design-time mais au run-time. En effet, la destination pour envoyer les s de notifications varie en fonction de la catégorie de l article en cours de traitement, et de ce fait, le port sera dynamiquement configuré. 26/04/2004 Page 77 sur 95

78 Section 7 Schéma d orchestration 26/04/2004 Page 78 sur 95

79 Chap. 3 Publication des Web Services d invocation de l orchestration Grâce à l utilitaire «BizTalk Web Services Publishing Wizard», il est possible de publier les Web Services d invocation d une orchestration. Cet assistant permet de créer une application ASP.NET Web Service, dont le rôle est de servir de façade d invocation à notre processus métier de gestion de publication de contenu. C est cette application ASP.NET Web Service «ContosoCMWS» publiée par l assistant, qui sera exploitée par notre formulaire InfoPath de saisie des nouveaux articles. Section 1 Message d invocation du Web Service <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap=" <soap:body> <ReceiveArticle xmlns=" <SubmissionRequest xmlns=" <Category xmlns="">string</category> <Title xmlns="">string</title> <Body xmlns="">string</body> <Author xmlns="">string</author> <Author xmlns="">string</author > </SubmissionRequest> </ReceiveArticle> </soap:body> </soap:envelope> Section 2 Message de réponse du Web Service <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap=" <soap:body> <ReceiveArticleResponse xmlns=" <SubmissionResponse xmlns=" <ArticleId xmlns="">integer</articleid> </SubmissionResponse> </ReceiveArticleResponse> </soap:body> </soap:envelope> 26/04/2004 Page 79 sur 95

80 Titre 3 Formulaire d approbation des articles Une notification est envoyée par aux approbateurs, à chaque fois qu un nouvel article est soumis. Dans cet , figure un lien pointant vers un formulaire de l intranet, leur permettant d approuver ou de refuser la publication en ligne de l article. Il leur est également possible de saisir quelques lignes de commentaires à envoyer à l auteur de l article pour justifier sa décision : Que l article soit approuvé ou non, une notification est envoyée par à son auteur, lui précisant que son article a été publié ou refusé, avec les commentaires de l approbateur. 26/04/2004 Page 80 sur 95

81 Si l approbateur approuve l article, ce dernier est alors publié en ligne sur le portal intranet de Contoso : 26/04/2004 Page 81 sur 95

82 Titre 4 Formulaire InfoPath d invocation Une fois le Web Service de notre orchestration publié, il nous est désormais possible de l invoquer et de commencer à soumettre des articles. Pour cela, il nous faut une interface permettant la saisie et l envoi des articles par Web Service. InfoPath, le nouveau né de la suite Office System, offre une réponse correspondant tout à fait à ce type de besoin. En effet, on peut dire qu InfoPath est à BizTalk Server 2004 ce qu Outlook est à Exchange. Ensembles, InfoPath et BizTalk Server 2004 permettent d apporter une réponse aux différents problèmes et besoins qu ont les entreprises concernant la récolte des données, comme par exemple : Récupération et récolte des données inefficaces, impliquant généralement des re-saisies et des risques d entrée d erreur. Des formulaires généralement trop complexes d utilisation engendrant une capacité limitée à fournir les informations requises. Des solutions de récolte de données sur mesure sont trop coûteuses Difficulté à réutiliser les données au sein des différents processus métiers de l entreprise InfoPath permet de créer rapidement et très facilement des formulaires de saisies, offrant une interface de saisie des données très simple d accès et d utilisation (environnement «user friendly»). Bâti entièrement sur XML, InfoPath récolte les données saisies qui peuvent alors être écrites dans un fichier XML, transmises à des Web Services ou à une base de données, à un collaborateur, etc. 26/04/2004 Page 82 sur 95

83 Grâce aux assistants, la création des formulaires avec InfoPath est d une extrême simplicité, et en plus de cela, ces derniers bénéficient d une interface simple, soignée et élégante : Quelques minutes seulement auront été nécessaires à la génération de ce formulaire, sans qu aucune ligne de code ne soit tapée. Une fois le formulaire rempli et validé, InfoPath soumet les données du formulaire à notre Web Service d invocation de l orchestration du processus de validation de contenu. L utilisateur n a plus qu à attendre une réponse de la part de l approbateur. 26/04/2004 Page 83 sur 95

84 Titre 5 Formulaire Intranet Les rédacteurs de Contoso peuvent également utiliser l écran de soumission d un nouvel article de leur intranet. A l instar du formulaire InfoPath, ce formulaire soumet les données via Web Service à notre orchestration : 26/04/2004 Page 84 sur 95