DOSSIER SUR L'INTEGRATION D'APPLICATION EN ENTREPRISE ...caron.nicolas.free.fr/cnam/Projet Methodologie/Dossier_EAI ver 2.02.… · Chap. 2 ’ Tibco _____ 48 Chap. 3 ’ Sybase

Dossier sur l’EAI v2.0

Le 26/04/2004 Page 1 sur 95

DOSSIER SUR

L'INTEGRATION D'APPLICATION EN ENTREPRISE

GROUPE E.A.I.

Version Date Foncions et tâches Identité

0.112/12/2003

Au01/02/2004

Rédacteur Benjamin DescampsSébastien BruninFrançois-Xavier Salengro

0.210/02/2004

Au03/03/2004


1.014/03/2004

Au25/03/2004


1.127/03/2004

Au03/04/2004

Rédacteur, intégration des parties 2 et 3Relectures

Benjamin DescampsSébastien BruninFrançois-Xavier Salengro

1.208/04/2004

Au25/04/2004

Rédacteur, finalisation des parties 2 et 3Relectures


2.026/04/2004

Au30/04/2004

Relectures et validation du dossier dans son ensemble.


Destinataires : Messieurs Raynal & Morel.


26/04/2004 Page 2 sur 95

Sommaire :Introduction______________________________________________________________________3

Partie 1 L’intégration ___________________________________________________________ 4

Titre 1 Les différents environnements applicatifs ___________________________________ 5Chap. 1 Evolution des technologies des systèmes d’information _______________________ 5Chap. 2 Les méthodes d’analyse et différentes solutions ____________________________ 10

Titre 2 Concepts et importance de l’intégration ___________________________________ 20Chap. 1 Naissance du marché et de son évolution _________________________________ 20Chap. 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 ______________________________________ 35Chap. 1 EAI (Enterprise Application Integration)__________________________________ 36Chap. 2 ESB (Enterprise Service Bus) __________________________________________ 40Chap. 3 EII (Enterprise Information Integration) __________________________________ 43Chap. 4 Orchestration de services ______________________________________________ 44Chap. 5 Conclusion _________________________________________________________ 46

Titre 2 Panorama des outils d’intégration________________________________________ 47Chap. 1 BizTalk____________________________________________________________ 47Chap. 2 L’offre Tibco _______________________________________________________ 48Chap. 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 _________________________________________________________ 66Chap. 1 Description du scénario _______________________________________________ 67Chap. 2 Fonctionnalités mises en oeuvre ________________________________________ 67Chap. 3 Architecture de la solution ____________________________________________ 68

Titre 2 Implémentation de la solution ___________________________________________ 70Chap. 1 Schémas ___________________________________________________________ 70Chap. 2 Orchestration _______________________________________________________ 71Chap. 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___________________________________________________________ 85Chap. 1 Envoi des articles par email ____________________________________________ 85Chap. 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 3 sur 95

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 2003 – 2004, 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 ?


Le 26/04/2004 Page 4 sur 95

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.


26/04/2004 Page 5 sur 95

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 6 sur 95

§ 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 7 sur 95

§ 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 relieren 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 8 sur 95

§ 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 9 sur 95

§ 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 ProtocolWSDL : Web Services Description Language GUI Designer : Graphics User Interface


26/04/2004 Page 10 sur 95

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 11 sur 95

§ 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

2« Feed-back » de deuxième ordre associé à une mémoire sélective. Cela tient compte des modifications futures prévisibles. Pas d’apprentissage.

Thermostat programmable

3« 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.

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

NIVEAUX

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 12 sur 95

B Les composantes qui interagissent dans un système

Voici un schéma reprenant un système, son environnement et ses composants :

L’environnement

Ses objectifs

Sa structure

Ses entrées

Ses sorties

Son processus

ENVIRONNEMENT

SYSTEME(OBJECTIFS, PROCESSUS, SCTRUCTURE)

ENTREES SORTIESFEED-BACK

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 sous-systè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 13 sur 95

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

Information

Opération

Système décisionnel

Système d'information

Système opérantflux

entrantsflux

sortants

Schéma 5 : Fonctionnement d’un système dans un environnement


26/04/2004 Page 14 sur 95

§ 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 15 sur 95

§ 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 16 sur 95

§ 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 plusieursfacteurs. 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éagirrapidement.

La difficulté réside dans le fait d'obtenir un système d'information souple et flexibletout 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 17 sur 95

§ 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 connexionpoint à 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'e-business. On retrouve donc l'automatisation de la force de vente (SFA SalesForce Automation), la gestion de la relation client (GRC / CRM), la gestion desachats 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 18 sur 95

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 auxutilisateurs 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écuteautomatiquement 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 19 sur 95

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 20 sur 95

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 1997. 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 2001.

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 21 sur 95

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 2000. 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 %1999 400 millions -2000 920 millions 126.9%2001 2.15 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 2006-2007 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 2007. En effet, l'EAI traditionnel réaliserait 5.87 milliards d’euros.


26/04/2004 Page 22 sur 95

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 1997. 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 2005.

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


26/04/2004 Page 23 sur 95

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 24 sur 95

§ 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 25 sur 95

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'unprogramme.

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 26 sur 95

§ 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 27 sur 95

§ 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 connecteur2. 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 28 sur 95

§ 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 troisniveaux :

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 29 sur 95

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 30 sur 95

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 31 sur 95

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, demanière verticale ou horizontale, permettant aux entreprises de formaliser leurscollaborations commerciales.


26/04/2004 Page 32 sur 95

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 33 sur 95

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 moinsdeux 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 34 sur 95

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 soiteffectuer 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 estcomplètement automatisée et par conséquent beaucoup plus rapide, tandis que le nombred'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.

ConclusionL'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 35 sur 95

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 36 sur 95

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 37 sur 95

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 38 sur 95

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étiersUne 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’entrepriseLa couche « processus » permet aux entreprises de communiquer entre elles.


26/04/2004 Page 39 sur 95

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 40 sur 95

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 41 sur 95

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 42 sur 95

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 43 sur 95

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 44 sur 95

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 45 sur 95

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 46 sur 95

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 100 000 et 250 000 ø25 000 ø pour un connecteur technique supplémentaireEntre 50 000 et 150 000 ø pour un connecteur applicatif

EII :

Entre 10 000 et 75 000 ø selon les éditeurs et un coût moyen de 30 000 ø

Orchestration :

Prix des outils de modélisation entre 3 000 et 30 000 øMoteur d’orchestration entre 10 000 et 50 000 ø


26/04/2004 Page 47 sur 95

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 48 sur 95

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 estl'avenir des entreprises et de l'économie en générale. C'est pourquoi cela représente uninvestissement 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 laprise de décision. La dimension humaine, à l'extérieur de l'entreprise se concrétise par letravail en étroite collaboration avec les différents partenaires en amont et en aval. En ce quiconcerne 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 nombreuxavantages :

Plus grande flexibilité de la chaîne de valeur.Réductions des coûts grâce à des processus métiers bien intégrésMeilleure prise de décisionFavorise l'investissementMeilleure réactivité aux changements du marché.Une infrastructure plus flexible et adaptableMeilleure vision du consommateurMeilleure visibilité sur les opérations menées en interneLancement plus rapide de nouveaux produits sur le marchéAmélioration de la satisfaction et de la fidélisation des clientsOptimisation 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 delogiciels.

L'accroissement des applications B to B, l'accès des partenaires aux systèmesd'information etc…incitent les éditeurs EAI à améliorer sans cesse leurs offres et aller versles 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 lesdifférentes sémantiques (http, SMTP, RosettaNet…). On parle de plus en plus de gestion des processus.


26/04/2004 Page 49 sur 95

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'à lacommunication 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 environnementinformatique 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 dumonde, et jouer sur la concurrence. Une intégration B to B permet une collaborationinteractive grâce à l'automatisation des échanges.


26/04/2004 Page 50 sur 95

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 solutionsdestinées aux marchés verticaux, Sybase se classe parmi les 10 principaux éditeurs delogiciels 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 2001. 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 etcelle de New Era of Networks. Avec cette solution complète, Sybase est en mesured’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 lesentreprises é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 deprocessus métiers reposant sur un serveur d’application ouvert. Celui-ci permet la créationde 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 fournisseursindépendamment de leur source.


26/04/2004 Page 51 sur 95

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 nouvellesapplications aux applications existantes.

Bien qu'utilisant des solutions de différents niveaux, l'intégration d'application (EAI) etl'intégration de processus métiers (BPM) nécessitent une visibilité au niveau métier del'activité. Cela fournit notamment le complément obligatoire de l'automatisation des flux etdes 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éeimmédiatement de ce problème et doit avoir la capacité d'intervenir. De plus, un suivi del'activité globale doit être fourni pour pouvoir attester en temps réel de l'efficacité de tel outel processus, ou le cas échéant le besoin d'une refonte ou d'une modification de ceprocessus.


26/04/2004 Page 52 sur 95

Outre ses fonctionnalités, BPI Suite, offre les outils suivants pour la mise en place desprocessus :

Visualisation

Développement

Conception

Représentation graphique des processus

Tout ceci représente pour l’entreprise, un avantage non négligeable puisque cela luipermet d’analyser et affiner ces processus métiers et d’en assurer l’évolution. L’entreprisebé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 projetsd’intégration en plusieurs phases. Sybase a fixé le prix de sa suite dans cette optique dedéploiement incrémental. Autrement dit, un projet donné n’aura pas à supporter le coûtgé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 53 sur 95

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…

Schéma 14 : La croissance du marché français de l’EAI

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 anglo-saxons.


26/04/2004 Page 54 sur 95

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 (avecMQSeries) sont en tête en matière de ventes de services comme de logiciels. .Plusprécisément, ils ont au coude à coude dans l’édition de logiciels EAI.


26/04/2004 Page 55 sur 95

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 www.guidescomparatifs.com).

§ 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 ? Non Oui

Est-ce un middleware du marché ? Non Oui

Si Oui, le(s)quel(s) ?

Le middleware est-il ouvert sur d’autres middlewares ? Non Oui


Le middleware offre-t-il une intégration avec des annuaires LDAP ? Non Oui


Le middleware autorise-t-il des connexions avec des serveurs d’application ? Non Oui



26/04/2004 Page 56 sur 95

B Fiabilité du middleware

Le middleware assure-t-il l’intégrité du contenu des messages ? Non Oui

Si Oui, par quels moyens ? CRC Parité Autres

Le middleware respecte-t-il l’ordre des messages ? Non Oui

C Performances du middleware

Existe-t-il des abaques de benchmarks ? Non Oui

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 ? Non Oui

Le middleware autorise-t-il des échanges asynchrones ? Non Oui

Le middleware fournit-il une API JMS ? Non Oui

Le middleware est-il compatible JMS ? Non Oui

Le middleware autorise-t-il l’implantation de webservices ? Non Oui

Si Oui, comment ?

Le middleware permet-il la mise en œuvre de RPC (Remote Procedure Call) ? Non Oui


26/04/2004 Page 57 sur 95

Le protocole Request/Reply est-il fourni ? Non Oui

Le protocole Publish/Subscribe est-il fourni ? Non Oui

Quels sont les algorithmes de compression des données transportées proposés ?

E API utilisateur

Le middleware est-il facile d’usage ? Non Oui, 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 ? Non Oui

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 58 sur 95

§ 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 ? Non Oui

L’outil propose-t-il la gestion d’un référentiel de règles « métier » ? Non Oui

Est-il possible d’utiliser un format pivot en vue de relâcher le couplage entre les formatsde 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 ?

Non Oui

Utilise-t-on le paradigme objet pour modéliser le référentiel ? Non Oui

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é ? Non Oui

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 59 sur 95

La modélisation des processus (à l’aide de diagrammes d’activité, par exemple UML) peut-elle être effectuée par un outil du marché ?

Non Oui

Si Oui, le(s)quel(s) :

§ 6 Connectivité

A Connecteurs techniques

Connecteurs XML ? Non Oui

Connecteurs EDI ? Non Oui

Si Oui, lesquels ?

Connecteur ODBC ? Non Oui

Connecteur JDBC ? Non Oui

Connecteur OLAP ? Non Oui

Connecteur fichiers ? Non Oui

Connecteur COM ? Non Oui

Connecteur Corba ? Non Oui

Si Oui, quel ORB ?

Connecteur J2EE ? Non Oui

Si Oui, est-ce un connecteur : http Java EJB

Autres connecteurs techniques :


26/04/2004 Page 60 sur 95

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 ? Non Oui

Si Oui, quelles manipulations ?

Manipulation de répertoires ? Non Oui

Si Oui, quelles manipulations ?


26/04/2004 Page 61 sur 95

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 ? Non Oui

Si Oui, lesquelles ?

Existe-t-il une liste de best practices permettant de définir des règles de conception ? Non Oui



26/04/2004 Page 62 sur 95

Existe-t-il une liste de best practices permettant de définir des règles de développement ? Non Oui


Existe-il des métriques d’estimation et de chiffrage des projets ? Non Oui

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

Non Oui, décrire :

Existe-t-il des normes de nommage ? Non Oui

Existe-t-il des normes de développement ? Non Oui

§ 9 Installation & intégration

A Installation

L’environnement de développement offre-t-il une facilité d’installation ? Non Oui, 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 lestransformations ?

L’outil permet-il de tester les connecteurs sans qu’il y ait transfert de données ? Non Oui


26/04/2004 Page 63 sur 95

Dispose-t-on de : Templates Bibliothèques de transformation Palette d’objets graphiques Autres

Peut-on faire des analyses d’impact ? Non Oui

Assure-t-on facilement le suivi des nouvelles versions ? Non Oui

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 ?

Non Oui

Est-il possible d’effectuer des développements concourants en équipe avec gestion multi-postes et multi-utilisateurs (administration des accès…) ?

Non Oui

Sait-on mettre en place un cycle test, validation, mise en production ? Non Oui

C Déploiement

Est-il possibile de répartir les traitements EAI sur plusieurs serveurs ? Non Oui

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 64 sur 95

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 ? Non Oui

Si Oui, lesquels ? Suivi Stockage Archivage Remontée des alertes Autres

Est-il possible de tracer des événements système ? Non Oui

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…) ? Non Oui, comment ?

L’outil permet-il de gérer les rejets fonctionnels (règle métier non respectée…) ? Non Oui, comment ?

Disponibilité d’un outil d’administration (console…) ? Non Oui, détailler :

Disponibilité d’un outil d’administration du référentiel ? Non Oui

Si Oui, pour quelles actions ? Création Dimensionnement Supervision Nettoyage des logs Autres


26/04/2004 Page 65 sur 95

Possibilité d’ordonnancement ? Non Oui

Si Oui, le produit présente t’il graphiquement la logique d’enchaînement des chaînes de traitement et conditions d’enchaînement ?

Non Oui

Possibilité d’intégration d’un outil d’ordonnancement ? Non Oui


Gestion des autorisations d’accès ? Non Oui

Gestion des profils ? Non Oui

Assure-t-on une intégration facile avec les outils d’administration du marché ? Non Oui

Si Oui, lesquels ?


26/04/2004 Page 66 sur 95

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

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 email 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 2004.


26/04/2004 Page 67 sur 95

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 email à [email protected]

Une fois saisis et envoyés, les articles sont soumis au contrôle et à la validation du responsable éditorial de Contoso (par email), 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 68 sur 95

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 69 sur 95

On peut également imaginer qu’il leur soit accordé la possibilité de rédiger leurs articles dans un email et de l’envoyer à [email protected] (5). Ces emails 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 à [email protected], alors que les articles « Technologie » seront transmis à [email protected] (8).

Chaque article traité par BizTalk Server 2004 est donc soumis par email à 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 email 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 70 sur 95

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 71 sur 95

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êteInsertion de l’article dans la baseEnvoie de la réponseCréation d’une règle métierAppel de la règle métierEnvoie 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 72 sur 95

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 73 sur 95

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 74 sur 95

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 Email », de type XML Element (en mode SET) qui va nous permettre de définir l’adresse email de l’approbateur et de la retourner au sein de

l’orchestration. Cette définition pointe sur l’élément « ApprobatorEmail » 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 75 sur 95

§ 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 Email » 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 à [email protected] :

Le principe est le même pour les autres règles « Politiques », « Science », « Sports » et « Technologie ».


26/04/2004 Page 76 sur 95

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 email 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 77 sur 95

Section 6 Envoi de la notification et demande d’approbation

Maintenant que nous avons récupéré l’email de la personne responsable de l’approbation de l’article en cours de traitement, il suffit de créer l’email de notification à envoyer, qui contiendra :

Le titre de l’articleLe corps de l’articleL’auteur de l’article et son emailUn lien vers la fiche d’approbation / déclinaison de l’article

L’email est transmis à l’approbateur via le port « NotificationEmailPort ». 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 emails 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 78 sur 95

Section 7 Schéma d’orchestration


26/04/2004 Page 79 sur 95

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="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<ReceiveArticle xmlns="http://www.contoso.com/webservice">

<SubmissionRequest xmlns="http://ContosoCM.Schemas.SubmissionRequest">

<Category xmlns="">string</Category>

<Title xmlns="">string</Title>

<Body xmlns="">string</Body>

<Author xmlns="">string</Author>

<AuthorEmail xmlns="">string</AuthorEmail>

</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="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<ReceiveArticleResponse xmlns="http://www.contoso.com/webservice">

<SubmissionResponse xmlns="http://ContosoCM.Schemas.SubmissionResponse">

<ArticleId xmlns="">integer</ArticleId>

</SubmissionResponse>

</ReceiveArticleResponse>

</soap:Body>

</soap:Envelope>


26/04/2004 Page 80 sur 95

Titre 3 Formulaire d’approbation des articles

Une notification est envoyée par email aux approbateurs, à chaque fois qu’un nouvel article est soumis. Dans cet email, 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 email à son auteur, lui précisant que son article a été publié ou refusé, avec les commentaires de l’approbateur.


26/04/2004 Page 81 sur 95

Si l’approbateur approuve l’article, ce dernier est alors publié en ligne sur le portal intranet de Contoso :


26/04/2004 Page 82 sur 95

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 83 sur 95

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 84 sur 95

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 85 sur 95

Titre 6 Extensions

Une fois implémenté, ce processus de validation / publication de contenu est devenu un véritable service, auquel on va pouvoir interfacer de nouveaux modules. En effet, il est tout à fait possible d’envisager ce genre d’extensions :

Chap. 1 Envoi des articles par email

Il peut être intéressant d’offrir la possibilité aux rédacteurs de Contoso de saisir et de composer leurs articles dans un email, et de l’envoyer à « [email protected] ».

Pour implémenter cette fonctionnalité, l’idée serait d’avoir un service qui récupère tout email envoyé à « [email protected] », de parser son contenu et de le transformer en un fichier XML sauvé dans un répertoire « Mail_Inbox ». Ensuite, une orchestration BizTalk se chargerait de monitorer et de traiter les fichiers déposés dans ce répertoire, afin de les soumettre au processus de validation en invoquant notre orchestration « ProcessArticle ».

Chap. 2 Agrégation de contenu en ligne

Une autre idée intéressante consisterait à avoir un service d’agrégation de contenu,qui aurait pour rôle de récupérer automatiquement des flux publics d’informations, comme par exemple les dernières news du New York Times ou de Reuters.

Une implémentation possible de cette fonctionnalité consisterait à créer un service s’occupant d’interroger à intervalles réguliers les flux d’informations et de les soumettre à notre orchestration de validation, soit par Web Service, soit par système de fichiers.

Une autre possibilité consisterait à créer un adaptateur personnalisé, de type HTTP GET, et de l’intégrer au sein de BizTalk Server, pour pouvoir l’exploiter et interroger les flux d’informations, directement à partir d’une orchestration.


26/04/2004 Page 86 sur 95

Titre 7 Conclusion

A travers cet exemple de gestion de validation / publication de contenu, nous nous apercevons qu’il peut être très intéressant d’externaliser la gestion des processus métiers au sein d’un outil de Business Process Management comme BizTalk Server 2004.

En effet, en procédant ainsi, on matérialise et consolide de manière unitaire un ensemble d’échanges de flux et de traitements métiers. Cette consolidation donne naissance à un véritable service métier de l’entreprise.

Externaliser la gestion et l’implémentation des processus métiers au sein d’un BPM permet donc de fournir tout un panel de services métiers et d’en faire bénéficier l’ensemble des acteurs du système d’informations, et ce de manière très simple, indépendamment de la complexité des processus métiers invoqués.


26/04/2004 Page 87 sur 95

Conclusion

L'EAI connaît aujourd'hui un engouement fort de la part des entreprises, les outils et techniques d'intégration étant plus performants et permettent aux entreprises d'évoluer sereinement au sein du tissu économique.

Néanmoins, même si le marché de l'EAI est plutôt prometteur, il reste très évolutif. De nombreuses offres apparaissent tous les jours sur le marché. C'est pourquoi il est essentiel pour les entreprises de choisir une application interopérable et évolutive, afin de suivre tous les facteurs et intervenants de son environnement. Aujourd'hui, il devient primordial pour les entreprises d'informatiser au mieux tous ses services (marketing, comptabilité…). Cette informatisation passe par la mise en place de nouvelles applications qu'il faut intégrer, le but des acteurs de l'EAI étant de les aider à cette tâche.

Dans la mise en œuvre d’un projet d’intégration, Il ne faut pas négliger le retour sur investissement. En effet, le budget des projets EAI est fonction du nombre d’échanges à automatiser. Plus le nombre d’applications ou d’entreprises à relier est important, et plus l’intérêt financier est important. Le retour sur investissement est généralement atteint au bout de quatre à six mois pour les projets tactiques (intégration de quelques applications) et de huit à douze mois pour des projets de refonte globale.

La tendance de l'EAI est à la standardisation, à la compatibilité complète avec toutes autres applications l'objectif étant de limiter la complexité des systèmes d'informations. C'est pourquoi le positionnement des applications EAI a tendance à évoluer. En effet, les applications EAI deviennent progressivement un support de l'intégration afin de permettre aux nouvelles technologies, en l'occurrence les Web Services, d'assurer le rôle d'interface et de traducteur entre les applications externes.


26/04/2004 Page 88 sur 95

Glossaire

Adaptateur Permet de se connecter à une ressource spécifiée (SGBD, applicatif…)

Annuaire d’entreprise

Référentiel consacré à l'identification des agents de l'entreprise, et comportant les attributs permettant d'évaluer le profil de chaque agent et de définir ses habilitations.

API Interface publique permettant d’accéder par des mécanismes de requêtes à une fonction d’un progiciel ou à une portion d’application.

Application Web

Logiciel qui utilise le protocole de communication http et qui transmet aux utilisateurs des informations conforme aux standards HTML, DHTML ou XML.

Back Office Ensemble des domaines d’applications qui n’est pas en relation avec les acteurs extérieurs : client, fournisseurs…

BAM [Business Activity Monitoring]Outil d’évaluation et de suivi des performances des processus métiers.

BusDans un ordinateur ou un réseau, le bus est un support de transmission sur lequel les signaux sont émis ou reçus par chacun des éléments raccordés à l’ordinateur ou au réseau.

BPI[Business Process Integration ou Gestion des processus techniques]Correspond à la couche technique des projets d’intégration qui fournit la connectivité, le transport et le routage des messages. Démarche technique

BPM

[Business Process Management ou Gestion des processus métiers]Intégration pilotée par les flux. Consiste à modéliser un processus puis orchestrer l’ensemble des appels à la couche technique (BPI) via un moteur de workflow. Démarche métier.

Connecteur Permet de se connecter à une ressource spécifiée (SGBD, applicatif…)

CRM [Customer Relationship Management]Méthodes et outils assurant une gestion de la relation client optimale.

Data warehouse

[Entrepôt de Données]Désigne une base d’informations conçue pour aider à la prise de décision.Conçue à partir des bases de production.

EAI

[Enterprise Application Integration ou Intégration d’Application dans l’Entreprise]Plate-forme logicielle qui relie les applications hétérogènes au moyen de connecteurs et d’un middleware plus ou moins intelligent. L’intégration s’effectue au niveau des API des applications.

EDA[Event-Driven Architecture ou Architecture événementielle]Architecture qui relie les applications via un mode de communication synchrone du type publish & subscribe.

EDI

[Electronic Data Interchange ou Echange de Données Informatique]Système de messagerie permettant à deux entreprises de s’échanger des données de commande et de facturation. Le développement du commerce électronique a bouleversé l’EDI, qui évolue vers le concept de Web EDI.


26/04/2004 Page 89 sur 95

EII

[Enterprise Information Integration ou Intégration de Données]Outil d’intégration de données regroupant au sein de vues métiers homogènes (commandes clients par exemple), des informations provenant de nombreuses sources de données hétérogènes (bases de données relationnelles, fichiers, XML…). La liaison se réalise à l’aide connecteurs.

ESB

[Enterprise Service Bus ou Bus de services]Désigne généralement un MOM chargé de router l’ensemble des messages échangés entre les applications de l’entreprise. Les messages sont au format XML ou SOAP.

ETL[Extract, Transform, Load]Système qui assure l’extraction, la transformation et le chargement des données (par exemple dans un Data Warehouse).

Hub and Spoke Les applications se connectent à un hub, qui se connecte à son tour aux autres applications.

IAI[Internet Application Integration]Intégration entre applications et systèmes d’information via des technologies de l’internet.

LDAP

[Lightweight Directory Access Protocol]Protocole standard permettant la gestion d’annuaires, autrement dit, l’accès à des bases d’informations sur les utilisateurs et les ressources d’un réseau d’entreprise.

Message Broker

Permet le routage et la transformation intelligente de messages transitant sur un réseau

Message Passing Communication unidirectionnelle et non bloquante.

Message Queuing

Type de communication basée sur la gestion de messages par boîte aux lettres permettant la lecture à son rythme des messages.

Middleware

Mécanismes logiciel assurant le dialogue entre différentes applications, ou portions d’une même application, réparties sur plusieurs postes, clients ou serveurs. (moniteurs transactionnels, messagerie inter applicatives asynchrones, ORB, appels de procédure à distance et middlewares d’accès aux données).

MOM[Message Oriented Middleware ou Middleware Orienté Message]Logiciel qui transporte une information d’une application à l’autre en utilisant des files de messages (queue en anglais).

SOA

[Service Oriented Architecture ou Architecture Orientée Service]Architecture applicative qui englobe la majorité des nouveaux concepts liés à l’EAI et aux serveurs d’applications dans un modèle cohérent à couches. L’objectif de SOA est le même que celui de l’EAI mais il s’appuie sur un couplage faible entre les couches et sur des standards.

Service WebArchitecture de développement et de déploiement d’applications web fondée sur l’assemblage statique ou dynamique de composants indépendants et inter opérables appelés services.

XML

[eXtensible Markup Language]Métalangage standard du consortium W3C destiné à la manipulation des données. CXML, ebXML, OBI, RosettaNet, xBCL constituent des déclinaisons adaptées à des besoins particuliers.


26/04/2004 Page 90 sur 95

Bibliographie

Ressources Internet :

Systèmes et applications asynchrones Middleware à messageo Janvier 2004o Roland Balter ; [email protected] Société « ScalAgent Distributed Technologies »

Etude Analytique des architectures applicativeso 28 novembre 2002o Synthèse de l’état de l’art des architectures applicatives

Panorama sur les Web Serviceso Didier Donsez, Université Joseph Fourier (Grenoble 1)o [email protected]

Description et annuaire pour les Web Serviceso Didier Donsez, Université Joseph Fourier (Grenoble 1)o [email protected]

Guide comparatif sur l’EAIo Mai 2003o www.guidescomparatifs.com

Implémenter un processus avec BizTalko Société « Business Design Consulting »o

EAI and Web Serviceso Gunjan Samtani and Dimple Sadhwani


26/04/2004 Page 91 sur 95

Articles de presse :

BizTalk 2004 : L’outil EAI de nouvelle générationo 1er décembre 2003o Guy Faureo Revue « Décisions Micro & Réseaux », n°572

Gestion des Processus Métiers : un domaine en constructiono 17 janvier 2003o Renaud Edouardo 01 informatique, n°1706

Le marché français de l’intégrationo 11 juillet 2003o Clarisse Burgero 01 informatique, n°1732

Les livres blancs:

Le livre blanc du « Business Process Managment »o 2003o Tanguy Crusson ; [email protected] Société « Intalio »

Le livre blanc de l’EAIo Société « Médiadev »

Mémoires :

Mémoire « Coordination de Web Services, langage de description »o Septembre 2002o David Levyo « Ingénierie des Médias et Architecture de la Communication » à Paris


26/04/2004 Page 92 sur 95

Table des matières détaillée

Introduction______________________________________________________________________ 3

Partie 1 L’intégration ___________________________________________________________ 4

Titre 1 Les différents environnements applicatifs ___________________________________ 5Chap. 1 Evolution des technologies des systèmes d’information _______________________ 5

§ 1 Le Maître Esclave ____________________________________________________ 6§ 2 Le Client Serveur _____________________________________________________ 7§ 3 Le Web_____________________________________________________________ 8§ 4 Le client riche _______________________________________________________ 9

Chap. 2 Les méthodes d’analyse et différentes solutions ____________________________ 10§ 1 La méthodologie, la base ______________________________________________ 10§ 2 L’analyse systémique_________________________________________________ 11

A Classification des différents types de systèmes _____________________________ 11B Les composantes qui interagissent dans un système _________________________ 12C Les critères d’efficacité d’un système ____________________________________ 12D Fonctionnement d’un système dans son environnement ______________________ 13

§ 3 Analyse structurée et fonctionnelle ______________________________________ 14A Séparation des Données – Traitements – Communications ____________________ 14B L’abstraction de l’analyse fonctionnelle __________________________________ 14

§ 4 Analyse objet _______________________________________________________ 15§ 5 Les différents projets _________________________________________________ 16§ 6 Progiciels de Gestion Intégré (PGI) ______________________________________ 17

Section 2 Conséquences de ces évolutions ______________________________________ 19

Titre 2 Concepts et importance de l’intégration ___________________________________ 20Chap. 1 Naissance du marché et de son évolution _________________________________ 20

Section 1 Le marché européen _______________________________________________ 21Section 2 Le marché français ________________________________________________ 22

Chap. 2 Les indispensables pour mettre en place son intégration ______________________ 23Section 1 Les bases de l’intégration ___________________________________________ 23

§ 1 Le Middleware______________________________________________________ 23§ 2 Le modèle XML_____________________________________________________ 24

A Introduction ________________________________________________________ 24B Origine ____________________________________________________________ 24C Les règles __________________________________________________________ 24D Exemple ___________________________________________________________ 25

§ 3 Les échanges de données (ETL) ________________________________________ 26A Méthode Ascential ___________________________________________________ 26B Méthode Informatica _________________________________________________ 26C Conclusion _________________________________________________________ 26

§ 4 Le Message Oriented Middleware (M.O.M.)_______________________________ 27§ 5 Le message Broker___________________________________________________ 27§ 6 La gestion des processus métiers (BPM Business Process Management) _________ 28

A L’enjeu des processus métiers __________________________________________ 28B Définition __________________________________________________________ 29C Le workflow________________________________________________________ 32D Le Business Process Management _______________________________________ 34

Partie 2 Outils et plates-formes d’intégration_______________________________________ 35


26/04/2004 Page 93 sur 95

Titre 1 Choisir sa plate-forme d’intégration ______________________________________ 35Chap. 1 EAI (Enterprise Application Integration)__________________________________ 36Chap. 2 ESB (Enterprise Service Bus) __________________________________________ 40Chap. 3 EII (Enterprise Information Integration) __________________________________ 43Chap. 4 Orchestration de services ______________________________________________ 44Chap. 5 Conclusion _________________________________________________________ 46

Titre 2 Panorama des outils d’intégration________________________________________ 47Chap. 1 BizTalk____________________________________________________________ 47Chap. 2 L’offre Tibco _______________________________________________________ 48Chap. 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§ 1 Profil & positionnement_______________________________________________ 55§ 2 Transport / MOM____________________________________________________ 55

A Nature du middleware utilisé au niveau de la couche transport_________________ 55B Fiabilité du middleware _______________________________________________ 56C Performances du middleware___________________________________________ 56D Types de protocoles __________________________________________________ 56E API utilisateur ______________________________________________________ 57

§ 3 Flux techniques / Orchestration /Transformation & Routage __________________ 57§ 4 Gestion de référentiel et de formats pivots / méta données ____________________ 58§ 5 Processus métier / Workflow / BPM _____________________________________ 58§ 6 Connectivité ________________________________________________________ 59

A Connecteurs techniques _______________________________________________ 59B Connecteurs applicatifs _______________________________________________ 60C Fonctions supportées _________________________________________________ 60

§ 7 Sécurité ___________________________________________________________ 61A Connexions applicatives ______________________________________________ 61B Couche transport ____________________________________________________ 61

§ 8 Méthodologie supportée_______________________________________________ 61§ 9 Installation & intégration ______________________________________________ 62

A Installation _________________________________________________________ 62B Manipulation IHM ___________________________________________________ 62C Déploiement________________________________________________________ 63D Architecture ciblée ___________________________________________________ 63E Apprentissage_______________________________________________________ 64

§ 10 Administration & Supervision ________________________________________ 64

Partie 3 Implémentation d’un processus avec BizTalk _______________________________ 66

Titre 1 Introduction _________________________________________________________ 66Chap. 1 Description du scénario _______________________________________________ 67Chap. 2 Fonctionnalités mises en oeuvre ________________________________________ 67Chap. 3 Architecture de la solution ____________________________________________ 68

Titre 2 Implémentation de la solution ___________________________________________ 70Chap. 1 Schémas ___________________________________________________________ 70Chap. 2 Orchestration _______________________________________________________ 71

Section 1 Réception de la requête _____________________________________________ 71Section 2 Insertion de l’article dans la base _____________________________________ 72Section 3 Envoi de la réponse ________________________________________________ 73Section 4 Création d’une règle métier avec le « Business Rule Composer » ____________ 74

§ 1 Définition du « Vocabulary »_________________________________________ 74


26/04/2004 Page 94 sur 95

§ 2 Définition de la « Policy » ___________________________________________ 75Section 5 Appel de la règle métier ____________________________________________ 76Section 6 Envoi de la notification et demande d’approbation________________________ 77Section 7 Schéma d’orchestration_____________________________________________ 78

Chap. 3 Publication des Web Services d’invocation de l’orchestration _________________ 79Section 1 Message d’invocation du Web Service _________________________________ 79Section 2 Message de réponse du Web Service __________________________________ 79

Titre 3 Formulaire d’approbation des articles_____________________________________ 80

Titre 4 Formulaire InfoPath d’invocation________________________________________ 82

Titre 5 Formulaire Intranet ___________________________________________________ 84

Titre 6 Extensions___________________________________________________________ 85Chap. 1 Envoi des articles par email ____________________________________________ 85Chap. 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 95 sur 95

Table des schémas

Schéma 1 : les architectures maître esclave ___________________________________________ 6

Schéma 2 : les architectures client serveur ____________________________________________ 7

Schéma 3 : les architectures Web____________________________________________________ 8

Schéma 4 : les composantes interagissant dans un système______________________________ 12

Schéma 5 : Fonctionnement d’un système dans un environnement _______________________ 13

Schéma 6 : Définition d’un processus métier avec Intalio _______________________________ 29

Schéma 7a : Définition d’un processus collaboratif avec Intalio _________________________ 30

Schéma 7b : Définition d’un processus métier avec Intalio______________________________ 31

Schéma 8 : Exemple de mise en place d’un EAI ______________________________________ 37

Schéma 9: Modèle L’EAI en 6 couches et le modèle OSI par le Hurwitz Group ____________ 39

Schéma 10 : Passage des EAI de la topologie hub & spoke à la topologie Bus ______________ 41

Schéma 11 : Le middleware ESB dans sa forme aboutie________________________________ 42

Schéma 12 : Exemple d’architecture EII ____________________________________________ 43

Schéma 13 : Orchestration de services ______________________________________________ 44

Schéma 14 : La croissance du marché français de l’EAI________________________________ 53

Schéma 15 : Les marchés de l’intégration et de l’édition en France_______________________ 54

Schéma 16 : architecture de la solution (exemple Contoso) _____________________________ 68

Documents

DOSSIER SUR L'INTEGRATION D'APPLICATION EN ENTREPRISE ...caron.nicolas.free.fr/cnam/Projet Methodologie/Dossier_EAI ver 2.02.… · Chap. 2 ’ Tibco _____ 48 Chap. 3 ’ Sybase