Octo.com - Livre Blanc Eai

Le livre blanc de l’EAI Intégration des Applications d’Entreprise

octobre 99

© 1999 O CT O Tech no log y. To us dr oi ts rés er vés Les informations contenues dans ce document représentent le point de vue actuel d’OCTO Technology sur les sujets exposés, à la date de publication. Dans la mesure où les éditeurs cités doivent s’adapter aux conditions changeantes du marché, OCTO ne peut pas garantir l’exactitude des informations présentées après la date de publication. Les noms de produits ou de sociétés dans ce document peuvent être les marques déposées de leurs propriétaires respectifs.

Au te urs :

Les auteurs de ce document sont des consultants d’OCTO Technology, par ordre alphabétique L. Avignon, T. Brethes, C. Devaux, P. Pezziardi. Pour tous renseignements complémentaires, veuillez contacter P. Pezziardi ([email protected]).

Constat d’évolution Un système d’information d’entreprise est constitué de nombreuses applications bâties sur des technologies différentes avec des spécificités propres aux contraintes du moment, et qui de surcroît ont évoluées dans le temps. A présent, lors du développement d’une nouvelle application, une grande partie du travail consiste à développer les interfaces des applications avec lesquelles elle doit échanger des informations. Dans un contexte où la mondialisation est de mise, ces problèmes prennent une dimension encore plus importante, et deviennent la pierre angulaire des échanges intra-entreprises et inter-entreprises. Les nouveaux concepts et produits de l’Enterprise Application Integration (EAI) se proposent de répondre de manière élégante à cette problématique de gestion des flux d’information dans le SI de l’entreprise.

Les enjeux de l’EAI L’EAI, traduit en français par “Intégration des Applications d’Entreprise”, permet de faire communiquer tout type d’applications, que ce soit des développements “maison” ou des progiciels intégrés. Il ne s’agit plus dès lors de développer une nouvelle solution d’interfaçage mais de fournir un cadre d’intégration souple et robuste. Le fait que l’entreprise puisse faire évoluer en douceur son SI en s’appuyant au maximum sur l’existant est une qualité intrinsèque de l’EAI. Le système d’information a ainsi la capacité d’absorber les changements technologiques toujours plus fréquents. L’entreprise peut alors plus facilement réagir aux nouvelles donnes économiques (fusion, acquisition, mondialisation des marchés et élargissement de la concurrence). De ce point de vue, la valeur de l’EAI réside bien dans sa capacité à faire perpétuer le système d’information, tout en minimisant le coût total du changement (TCC). Cependant, la mise à disposition d’information et l’échange de données entre systèmes nécessitent une normalisation de leurs formats. Dans ce domaine, les technologies de l’EDI ont adressé le problème secteur par secteur (automobile, santé, etc.) en définissant les formats et la cinématique des échanges. Trop complexes et coûteuses à mettre en œuvre, particulièrement pour les PME, elles n’ont pas réussi à s’imposer à grande échelle. En outre, les échanges de données informatiques s’effectuaient jusqu’à présent sur un mode point à point. Ce modèle éclate aujourd’hui avec l’arrivée

d’une multitude de partenaires et d’organisations de toute taille. En effet, l’avènement des technologies de l’Internet a considérablement allégé les coûts d’investissement et ont permis l’apparition de nouveaux acteurs. De plus, l’apparition de tiers, assurant des fonctions de “place de marché” (annuaires, catalogues, paiements, commandes, tiers de confiance,...), modifie radicalement la cinématique des échanges. Le format XML, issu du monde du WEB, et les expériences de l’EDI apportent un début de normalisation mais un grand travail reste encore à faire, notamment en corrélation avec les éditeurs de progiciels intégrés, sur lesquels de plus en plus d’entreprises gèrent leur personnel, leur stock ou leur système de facturation. Au delà de ces raisons économiques, deux facteurs technologiques tirent le marché de l’EAI : • le développement massif des technologies Internet et la possibilité d’uti liser ce réseau et ses protocoles pour y créer de la valeur ajoutée, • une adoption généralisée des solutions packagées : Enterprise Ressource Planning (ERP), Customer Relationship Management (CRM), Supply Chain Management (SCM), permettant l’émergence de standards métier.

Acteurs du marché de l’EAI Une solution EAI contient un ensemble d’outils que l’on peut classer dans les catégories suivantes : • Les outils de gestion de processus métier, qui gèrent l’ensemble des données métier et assurent le suivi des étapes et des décisions prises, • Des moteurs de règles pour le routage et la transformation des flux, plus connus sous le nom de Message Broker, • Des connecteurs et adaptateurs de progiciels intégrés permettant une intégration aisée de ces applications dans le système, • Des connecteurs vers des formats d’échange déjà en usage (EDI, réseaux de clearing, etc), • Des passerelles bas-niveau vers les multiples formats de transport (fichier, message, base de données, e-mail, etc.), • Des middlewares de communications (mode message, transfert de fichiers, Web, messageries).

Aujourd’hui, aucun éditeur du monde de l’EAI ne peut se flatter d’offrir l’ensemble de ces outils. Certains ont une approche “bottom up” : ils viennent du monde des middlewares et proposent des solutions de plus haut niveau audessus de leurs technologies existantes. D’autres ont abordé ce marché en partant de leur expertise métier ou de leur connaissance en matière de progiciels spécialisés, et ont une approche “top down” : ils proposent des outils de gestion de processus ou des connecteurs, et peuvent s’appuyer sur des middlewares existants. Le spectre des offres actuelles est en pleine ébullition, mais le marché commence à se structurer. La bataille se joue à coup d’annonces, d’alliances et acquisitions, afin de pouvoir proposer le plus rapidement possible une offre intégrée globale. A ce jeu, le NASDAQ devient rapidement le baromètre des stratégies. Ce livre blanc se propose donc d’éclaircir le lecteur sur le pourquoi et le comment des technologies EAI. Une première partie est consacrée à la description de la problématique, la seconde expose les différentes “briques d’architecture” proposées par les éditeurs, et la dernière présente notre vision du marché… en date de rédaction ! Nous vous souhaitons une excellente lecture, en espérant que vous prendrez autant de plaisir à le lire que nous en avons eu à le rédiger.

Sommaire INTRODUCTION

8

1 .VER S L’INT EGRA TI ON DE S AP PLICA TIONS D’ ENT RE PRI SE

13

2.A RC HI TE CTU RE E AI

16

2. 1.M ÉCA NI SME S D’É CHA NGE

16

2.2 .ECH ANGE EN MODE MESSAG E

19

2. 3. LES SER VICES FO ND AMEN TA UX DE L’ EAI

23

2. 3 .1.Tr an sforma tio ns e t con ne cteu rs

23

2.3 .2.Pa sse rell es tec hn iqu es

27

2. 3. 3. La gestio n d e proce ssu s ou Work flo w

30

2.4 .L’ INTÉGR ATI ON D ES APP LICAT IONS

31

2.4 .1.L es app lic ati ons cl ie nt /ser veu r

31

2.4 .2.Le s ap plic ations 3- ti ers

32

2.4 .3.Le s ER P et autres prog icie ls mét ier

33

2. 5. AD MINI STRA TI ON ET EXPLO I TA TION

34

2. 6. GES TIO N D E LA S ÉCURIT É

36

2.7.CONCLUSION

37

3. ACT EURS D U M AR CH É

39

3. 1. ACTIVE SOFT WAR E

40

3.2 .BEA SYST EMS

42

3.3.CROSSWORLDS

44

3.4.FORTÉ

46

3.5.IBM

48

3.6.MICROSOFT

50

3.7.NEON

52

3. 8. SO FTW AR E TE CHNOL OGIE S CO RPO RATIO N

54

3.9.SOPRA

56

3.10.TEMPLATE

58

3.11.TIBCO

60

3.1 2. TS I SOFT WARE

62

3.13 .VI EWLOC IT Y (E X F RO NT EC)

64

3.14.VITRIA

66

Table des figures Figure 1 : Flux ent ra nts et sorta nts d’une app lication

8

Figu re 2 : Evo lutio n du SI d’u ne entrepr ise à travers le t emps

8

Figure 3 : Cycle d’a cqu isitio n de s technologie s

14

Figu re 4 : Princip e du Hub central

15

Figu re 5 : Ech ang e basé su r le t ra nsf er t de fich ier

16

Figu re 6 : Ech ang e de type “Ex tra ction”

16

Figu re 7 : Méca nism e d e ré plica tion entre SGB DR

17

Figure 8 : Echanges via un MO M

20

Figure 9 : La c ouc he t ransport c om me pre miè re briq ue d e l’EA I

21

Figure 10 : Le Mess age B ro ker com me de uxième b rique de l’EAI

22

Figu re 11 : Exem ple de reformat age d’un flu x d’information

24

Figure 12 : L es co nne cte urs comm e troisiè me brique d e l’EA I

25

Figu re 13 : P asse re lle ave c les SGBDR

27

Figure 14 : Exemple de déclenchement d’une transaction à réception d’un message 2 9 Figu re 15 : E xem ples de pa sser elles ver s et en provena nce de fichie rs

29

Figu re 16 : L es passer elle s comm e quatr ièm e brique de l ’EAI

30

Figu re 17 : E xem ple d e pr oce ssus métier autom atisable par un WorkFlo w

30

Figu re 18 : L e Workflow comme cinq uième br iqu e de l’EAI

31

Figu re 19 : E xem ple de pr ogram matio n visuelle a vec Visual B asic

33

Figu re 20 : Le s ou tils d’e xplo itation c omme s ixième br iqu e de l’EAI

35

Figu re 21 : La sécurit é : septièm e b riq ue de l’EAI ...mais g éné ral ement p as la septième me rv eille !

37

Figu re 22 : L’e nse mbl e des bri ques d’un e offr e d’ EAI

37

Figu re 23 : Po sitionne ment de s principaux acteurs du march é de l’EAI

39

Figu re 24 : A ctiveW or ks Int egrat ion Syste m (so urce Active Sof tw are)

41

Figu re 25 : B EA eL ink So lution (source BEA Systems)

43

Figu re 26 : Arch itec ture Cr os sWorlds (source Cro ssWorlds)

45

Figure 27 : Fo rté Fusio n Enterpri se Ap plication Integratio n (source Fort é)

47

Figure 28 : MQSeries a u cœ ur du Bu sine ss integr at ion (source IBM)

49

Figu re 29 : Micros oft BizTal k (s ource Mic ro sof t)

51

Figu re 30 : NEON Fo rm ater et NEO N Ruler (so ur ce NEON)

53

Figure 31 : e*Gate (ex D ata Gate), la solu tion d’EA I de S TC (source S TC )

55

Figu re 32 : B us Ap plicatif (source Sopra)

57

Figure 33 : EIT (sou rc eT em plate)

59

Figu re 34: Tib/ Act ive Enter pr ise (so urceTibc o)

61

Figure 35: A rchitec tur e Me rcator (source TSI)

63

Figu re 36: Composan ts d e l’offr e A MTrix (sou rce Viewlocity)

65

Figure 37: Comp osants d e l’offre B usine ssWare (sou rc e Vitria)

67

Introduction La problématique d’Intégration des Applications d’Entreprise n’est pas nouvelle. En effet, faire communiquer entre elles les différentes applications qui composent le Système d’Information n’a rien d’exceptionnel. Constat : les applications d’une entreprise sont excessivement liées entre elles.

Pourquoi une communication entre applications ? Tout simplement parce que un Système d’Information n’est pas constitué d’une seule application. Chaque application spécifique ou progiciel répond à un besoin fonctionnel, mais nécessite, d’une part, des informations gérées par d’autres applications (liste des clients, des produits, etc.) et, d’autre part, produit de l’information qui intéresse également d’autres applications (comptabilité, gestion de stock, etc.). Ce principe est simplement figuré par le schéma suivant, où apparaissent les flux en entrée et en sortie d’une application :

Fi gu re 1 : F lu x en tr ant s et sortan ts d’une a ppl icati on

Cette schématisation, un peu banale certes, présente néanmoins l’avantage d’introduire l’exemple d’une entreprise fictive A et son évolution dans le temps : Au cours du temps, le SI de toute entreprise tend vers l’état “spaghetti”

F ig ur e 2: Evo lut ion du S I d’u ne e ntr ep ri se à trav er s le t em ps

La détail de la chronologie de notre exemple est le suivant : Action

Mise en œuvre

Difficultés rencontrées

1980 Mise en œuvre d’une Utilisation d’un Mainframe. Monopole du fournisseur, application centrale coût de maintenance de gestion client/produits. élevé.

Les six questions fondamentales pour évaluer l’agilité d’un SI.

1982 Déploiement d’une nouvelle application de comptabilité.

Ecriture de programmes de synchronisation des bases des deux applications.

1990 Mise en œuvre de quatre nouvelles applications en régions visant la gestion de nouveaux produits.

Mise en place d’un Difficultés en cas de système de réplication changement de SGBDR. entre les SGBDR des nouvelles applications. Ecriture des programmes de synchronisation vers les applications centrales.

1992 Acquisition d’un concurrent.

Ecriture d’un mécanisme de synchronisation des bases clients, avec gestion d’un identifiant unique. Portage de l’ensemble des programmes extrayant des données.

Difficultés rencontrées pour fusionner les applications de gestion de produits qui resteront isolées.

1995 Migration des applications centrales sous un ERP.

Ecriture de divers programmes de synchronisation permettant la coexistence des trois systèmes. Développements réalisés à l’aide des outils fournis par l’éditeur de l’ERP et de compétences externes.

La mise en place de l’ERP est entravée par les nombreuses interfaces existantes à reproduire. Développements lourds autour de l’ERP.

1996 Création d’un Ecriture d’un programme DataWarehouse de suivi d’extraction de données de clientèle. depuis le central et les régions vers la base Infocentre.

Difficultés rencontrées pour homogénéiser les données venant de sources hétérogènes.

1998 Ouverture d’un Web.

Délais de mise en œuvre énormes en regard de la simplicité du service Ajout de nouveaux flux Duplication des données.

Mise en œuvre de nouvelles interfaces vers les systèmes hétérogènes. Développement des interfaces vers l’ERP.

A partir de ces éléments, mettons nous par exemple à la place d’un consultant externe et évaluons par une note de 1 à 10 les six points suivants : • Flexibilité du système Dans quelle mesure peut-on faire évoluer un projet (une application) indépendamment des autres ? Quelle réactivité peut-on espérer pour la mise en œuvre de projets futurs (Time to Market) ? • Capacité d’administration et d’exploitation

Capacité de suivi des flux, maîtrise de l’intégrité transactionnelle de son système: est-on capable de s’assurer que tel achat de produit par le client a bien été comptabilisé, envoyé au datawarehouse, etc. ? • Capacité du système à diminuer les délais d’échange Le système est-il capable simplement d’évoluer vers du Straight Through Processing (STP)1, c’est à dire de propager instantanément les événements se produisant dans l’une des applications vers les cibles ? • Sécurité Quel est le niveau de sécurité de ces échanges : authentification, contrôle d’accès, intégrité, confidentialité ? • Coût de développement et de maintenance Dans le coût global de ces applications (conception, développement, intégration, exploitation), quelle est la part liée aux échanges inter-applicatifs ? • Qualité de service vu du client Est-on capable simplement de fournir au client une vision synthétique de ces avoirs dans l’entreprise fusionnée A+B, quelle est la fraîcheur de ces informations ? Procédons maintenant comme dans certains magazines féminins : faites la somme des notes et reportez vous à la rubrique correspondante. • Vous obtenez un total de plus de 30 (la moyenne) : Vous êtes un grand optimiste, la nature vous a doté de ce regard positif et parfois naïf sur tout ce qui vous entoure... en revanche, nous vous proposons de repasser le test avec les éléments supplémentaires suivants : ■

Modifier une application nécessite-t-il de retoucher l’ensemble de ses interfaces ?

■

L’exploitation des flux est-elle globale ou dispersée dans les différents ordonnanceurs et logs ?

■

Les flux étant ordonnancés la plupart du temps en mode batch avec extraction, transfert de fichier et import, porter un flux en mode fil de l’eau nécessite-t-il une intervention dans les applications ?

■

Certains flux ne sont-ils pas issus de programmes batch sous Unix ou MVS, contenant les mots de passe d’accès aux bases cibles ?

En fait, la part de la mise en œuvre des flux dans le coût global des applications dépasse largement les 25% (Source Gartner), (extractions, transformations, routages, imports). Cette part augmente exponentiellement dès que les spécifications des flux dépassent la simple synchronisation de référentiels pour aller vers des processus métier complexes. • Vous obtenez un total de moins de 30 : Doué d’un sens aigu de l’observation, vous savez déceler les problèmes et y apporter des solutions concrètes. Votre brillant intellect vous pousse ainsi à lire avidement la suite de cet ouvrage. Chaque nouvelle application engendre de nouveaux flux d’information vers ou en provenance de l’existant.

Effectivement, ce qui était acceptable à l’échelle de quelques applications ne l’est plus du tout au niveau des grands Systèmes d’Information : on se trouve confronté au “syndrome Spaghetti”. Chaque nouvelle application nécessite la mise en œuvre de flux d’information depuis et vers elle, l’augmentation de ces flux est exponentielle par rapport au nombre d’applications.

1 La notion de STP vient historiquement du monde de la finance et des réseaux de compensation (comme Swift par exemple). Par exemple, l’achat de titres dans une application bancaire de back-office générait une impression qui était ressaisie dans l’application de clearing, puis envoyé sur le réseau Swift. Aujourd’hui, le processus peut s’automatiser, l’application envoie directement un message formaté au point d’entrée Swift qui le propage.

L’urbanisme De la même manière qu’un architecte conçoit un bâtiment en fonction des besoins exprimés par ses futurs occupants à un instant donné, un urbaniste prend en compte les exigences d’une communauté à faire évoluer dans le temps. A l’origine du concept d’urbanisme, Jacques SASSOON fait l’analogie avec une ville comme Paris et assimile les quartiers aux groupes d’applications qui ont été conçues à peu près au même moment avec une architecture similaire. On trouve alors des groupes pour les applications Mainframe en mode Batch ou interactif, les mini-ordinateurs, le client/serveur, et maintenant les nouvelles applications Web. Les urbanistes n’aspirent pas à démolir les anciens quartiers à l’émergence de chaque nouveau style architectural. Mais, ils s’efforcent de maintenir certains standards d’infrastucture dans tous les quartiers. L’approvisionnement en eau et en électricité est nécessaire quelque soit le quartier. Les nouveaux besoins de la communauté provoquent parfois certains travaux d’aménagements des quartiers existants afin d’y apposer une canalisation plus grosse par exemple. Alors que les modèles d’architecture sont statiques, l’urbanisme doit savoir évoluer à travers le temps et prendre en compte les besoins non seulement du présent, mais également du passé et du futur. De cette analogie avec la gestion de la ville, ressort un ensemble de règles et de principes : • Le processus métier global d’une entreprise est découpé en domaines, contenant chacun des districts, comprenant à leur tour des blocs. • Chaque bloc est autonome et capable d’assurer seul l’accomplissement des fonctions qui lui sont attribuées. • Il ne doit pas y avoir de dépendance temporelle entre les blocs, chacun opérant de manière asynchrone par rapport aux autres. • Chaque bloc encapsule les données dont il a la charge et qui ne peut être directement accédé par un autre bloc (principe de la technologie objet) • Chaque bloc produit des résultats et des rapports avec un format standard sans présumer des destinataires • Chaque bloc doit avoir un gestionnaire d’évènements d’entrée et un générateur d’événements en sortie • Toutes les communications entre les blocs doivent s’effectuer indirectement au travers d’un gestionnaire de flux. Les contraintes d’interactions asynchrones entre les blocs n’interdisent cependant pas d’utiliser des technologies synchrones temps réel pour l’invocation de méthodes distribuées à l’intérieur d’un même bloc. Si l’adjonction d’une application Web à un système existant nécessite un couplage synchrone étroit entre les deux blocs, on assiste alors à une fusion des deux. C’est un peu comme la nouvelle façade d’un bâtiment. On a alors intérêt à ce que les deux blocs s’assemblent parfaitement et que les fenêtres soient bien alignées. Si à l’intérieur d’un même bloc, il existe des fortes contraintes de standardisation d’architecture, une certaine flexibilité entre les blocs est de mise, tant qu’un certain formalisme dans les d’échanges d’information est respecté, par l’utilisation par exemple d’un format fédérateur comme XML.

L’entreprise, pour pallier aux problèmes évoqués plus haut, doit s’équiper d’un système performant pour faire communiquer ces applications. En effet, le SI n’est malheureusement pas quelque chose de monolithique. Il évolue dans le temps, et, comme tout autre objet sur ce bas monde, obéit aux principales lois de la physique. En particulier son entropie ne cesse de croître, i.e. le désordre en son sein augmente : évolution des technologies et coexistence de différents paliers technologiques, choix différents selon les branches de l’entreprise, fusions/acquisitions, ouverture de canaux de distribution vers les partenaires, les clients, etc. L’EAI répond à la problématique d’intégration de hétérogènes au sein du SI mais aussi vers l’extérieur : clients et fournisseurs.

Le décideur est donc confronté à une problématique complexe d’intégration de ces systèmes hétérogènes, cette intégration devant répondre aux cinq critères évoqués plus haut : flexibilité, exploitabilité, capacité de gérer certains flux au fil de l’eau, sécurité et maîtrise des coûts bien entendu. L’objectif principal est de se donner la capacité de fournir au client final un service de meilleure qualité. Le chapitre suivant se proposant de dresser un historique des offres en matière d’EAI, nous commencerons donc par plonger dans le passé de ce marché, pour émerger ensuite dans l’actualité des offres, et tenter d’entrevoir leurs futures évolutions.

1. Vers l’Integration des Applications d’Entreprise Pour résumer le paragraphe précédent, le objectif de l’EAI est d’échanger de manière performante des informations entre applications ou progiciels, sur plates-formes hétérogènes, dans des Systèmes d’Information en constante évolution. Historiquement, l’EAI 2 a été le cheval de bataille d’éditeurs comme Sopra ou IBM depuis les années 80. L’éditeur Français SOPRA a été l’un des précurseurs dans la gestion des flux de l’entreprise.

Sopra avait développé une technologie de gestion de flux (Règle du Jeux) capable de gérer des transferts de fichiers de façon globale : inventaire, contrôle de flux et transformations. Cette initiative innovante, unique sur le marché de l’époque, se positionnait au-dessus du transport des fichiers, pour fournir des services de transformation, de routage et d’exploitation grâce à un dictionnaire des flux.

D’autres acteurs se sont positionnés à différents niveaux : IBM, Tibco, Microsoft...

IBM proposa aussi assez tôt (à partir de 1993) un middleware asynchrone en mode message (MQSeries), c’est à dire de la “tuyauterie3” permettant de développer des applications s’échangeant des informations au fil de l’eau. Cette technologie se positionnait précisément sur l’interopérabilité des applications, centrales dans un premier temps, puis sur l’ensemble des platesformes disponibles sur le marché. D’autres éditeurs ont par la suite proposé des offres comparables à celle d’IBM (DEC, Pipes et plus récemment Microsoft) voire plus évoluées, comme Tibco par exemple.

Certains utilisateurs ont développé leurs propres systèmes de communication interapplicatives.

Enfin, beaucoup de clients ont réalisé eux-mêmes leur propre système de messagerie inter-applicative et de gestion de flux. Ces initiatives, justifiables dans le cadre de projets limités, apparaissent finalement peu rentables à terme par rapport à l’acquisition de produits, notamment sur les aspects support multi-plate-forme, capacité d’administration et d’exploitation, gestion transactionnelle, outils de développement...

Le modèle de communication de type «Publish & Subscribe» est plus attrayant que le modèle «Point à point».

Probablement mal expliqué et mal compris, limité technologiquement et complexe à mettre en œuvre, ces solutions ne se sont pas généralisées et sont restées pour beaucoup des solutions techniques, locales à des besoins particuliers. L’exemple de Tibco est assez révélateur : sa technologie de Publish and Subscribe, déployée à Wall Street en 1980, puis dans les salles de marché du monde entier, n’a pas réussi à s’imposer réellement ailleurs que dans ces niches. Pourtant techniquement, l’offre était très attractive, le principe en est le suivant : • le publisher poste des messages sans en connaître les destinataires, il publie sur un thème, par exemple trading.achat • le susbscriber s’abonne aux messages de trading.* et reçoit ainsi au fil de l’eau ce qui est publié sur les thèmes trading.achat, trading.vente... Ce principe permet un réel découplage entre les applications, beaucoup plus qu’un moniteur de message classique qui effectue ses envois en point à point (directement de l’émetteur vers les N récepteurs finaux, via N files d’attente). Dans ce dernier mode en effet, les applications émettrices doivent connaître parfaitement l’adresse des applications destinatrices. Quel est donc l’événement qui bouleverse aujourd’hui l’état du marché ? Pourquoi donc la presse se fait-elle l’écho de cette problématique aussi ancienne que les Systèmes d’Information ? La réponse tient en deux points : • d’un côté l’offre des éditeurs s’est enrichie de nouvelles fonctionnalités

2 Qui ne portait pas encore à l’époque ce doux acronyme marketing et “Gartnerien” 3 On parlera dans la suite de Message Oriented Middleware (MOM) pour désigner ces technologies

simplifiant la mise en œuvre et autorisant une réelle généralisation : passerelles, connecteurs aux formats standards et pour la plupart des progiciels, offre d’administration, gestion de la sécurité, intégration dans les outils de développement, etc. Les utilisateurs réalisent l’énorme potentiel des solutions d’EAI.

• de l’autre les clients réalisent les coûts et la relative vétusté de leurs infrastructures existantes en la matière4. Une analogie possible se trouve sur le marché des Systèmes de Gestion de Base de Données Relationnelles (SGBDR). Avant l’avènement de la technologie relationnelle, chaque projet réécrivait notamment la gestion transactionnelle, la gestion de lock, la sécurité et l’exploitation de ses fichiers de base de données. Puis un jour, certains ont proposé de factoriser ces briques de bases dans des systèmes intégrés de gestion de base de données. La courbe suivante est assez instructive quant aux différentes étapes du cycle d’acquisition d’une technologie et l’évolution du niveau :

Fi gure 3: Cycle d ’ac qui sition de s te chno logi es

Aujourd’hui, le marché a bénéficié à ces éditeurs bien sûr, mais surtout aux clients : il serait inimaginable de nos jours de se priver de ces systèmes et des outils de conception, de développement et d’administration qui les accompagnent. EAI : de puissants outils d’interconnexion en phase d’acceptation

De la même manière donc, le marché de l’EAI se situe en France dans la phase de “Début d’acceptation” (il est un peu plus avancé aux Etats-Unis). Il est enfin perçu comme un puissant outil d’interconnexion capable de résoudre des problématiques transactionnelles, sécurisées, à caractère critique et d’améliorer la qualité de service des systèmes actuels. Le positionnement est clair : fédérer l’ensemble des technologies qui aujourd’hui tissent des adhérences fortes entre applications et y apporter une valeur ajoutée. Les échanges sont essentiellement de type : • échanges de fichiers, • échanges de messages, • systèmes de réplication SGBDR, • systèmes d’extraction de données orientés DataWarehouse. Le syndrome spaghetti évoqué au paragraphe précédent est constitutif de la superposition des technologies mentionnées. Les travers sont nombreux : interdépendance des applications, codage de la logique de transformation et de routage en L3G (C, Perl, Shell, etc.), réplication sauvage des données dans plusieurs référentiels, difficulté de suivi global, mauvaise sécurisation, difficul-

4 Parfois douloureusement puisque certaines entreprises ont réalisé après coup la nécessaire prise en compte des programmes d’interconnexion dans les projets An 2000...

tés de passage en mode fil de l’eau (STP). La solution EAI : un bus d’échange central fonctionnant en mode « Publish & Subscribe «.

Le stratégie étant précisée, la tactique d’implémentation consiste à fédérer les échanges d’information autour d’un Bus d’Echange. Le Bus (ou Hub) est un élément focal du Système d’Information, il centralise les flux en assurant les transformations et les routages nécessaires. Le système fonctionne par essence en mode “Publish and Subscribe”, c’est à dire que dès qu’une information présente dans une application est susceptible “d’intéresser” d’autres applications, elle est transmise, non pas aux destinataires finaux, mais au bus d’échange. Celui-ci a la charge d’en assurer ensuite le routage vers les applications “intéressées” en y appliquant éventuellement les transformations nécessaires à leur bonne interprétation. Nous détaillerons plus loin les services supplémentaires qui peuvent se greffer au niveau de ce Bus, c’est-à-dire son niveau d’“intelligence”.

F igure 4 : Pr inci pe du Hu b cen tr al

Le gain apparaît clairement : tous les aspects d’extraction, transformation et émission, auparavant gérés programmatiquement, sont désormais déportés dans un outil adapté. Donc, au-delà du simple gain en terme de coûts de développement, c’est la totalité du Système d’Information qui bénéficie : • d’un gain de flexibilité Une modification dans une application n’impacte que sur le Bus et non les N destinataires, • d’un gain de robustesse La centralisation des flux permet un réel suivi, des sauvegardes, des reprises, • d’un gain en fluidité et en sécurité Nous le verrons au paragraphe suivant, les technologies proposées se fondent sur des mécanismes asynchrones fil de l’eau et peuvent proposer une gestion poussée de la sécurité. Un puissant outil de gestion du changement

Ainsi la qualité de service globale s’améliore bien entendu : les temps d’intégration d’une nouvelle application sont réduits, la gestion des flux est sécurisée, la fraîcheur et la sécurité des données augmente. Quelle(s) technologie(s) mettre en œuvre pour implémenter cette fonction ? C’est l’objet du prochain chapitre.

2. Architecture EAI 2.1. Mécanismes d’échange Comme nous l’avons évoqué précédemment, la majorité des mécanismes d’interopérabilité se fondent sur la donnée. On peut en citer trois principaux, par ordre d’importance décroissant dans les systèmes actuels : • les transferts de fichiers, • les systèmes d’extraction orientés DataWarehouse, • les systèmes de réplication SGBDR. Explicitons rapidement le mode de fonctionnement de ces trois mécanismes. Le transfert de fichier est encore aujourd’hui le principal mode d’échange d’information entre applications.

Le transfert de fichier représente l’immense majorité des flux d’information aujourd’hui. Quand deux applications communiquent, le premier mécanisme mis en œuvre consiste à extraire une partie de l’information contenue dans l’application, puis, pour chaque destinataire, la formater et la transmettre. D’une manière générale, les deux premiers points constituent des développements spécifiques (extraction et formatage), le dernier point (transport) étant assuré par des transferts “classiques” (FTP, partage de fichiers) ou plus évolués à base de progiciels spécialisés (Computer Associates XCOM, Sterling Commerce Connect Direct, Sopra CFT et InterPel, etc.).

Fig ure 5: Echa ng e ba sé sur le t ran sfert de fi chie r Les ETL ne se focalisent que sur l’extraction de données.

Les systèmes d’extraction orientés DataWarehouse (Extract-Transform-Load : ETL) constituent une avancée dans le domaine puisqu’ils prennent en charge la gestion d’un dictionnaire mettant en relation les données sources (qui peuvent être sous différentes formes : fichiers, bases relationnelles, etc.) et les données cibles du DataWarehouse. Exemple : pour alimenter la table clients d’un DataWarehouse, on décrira au niveau d’un dictionnaire centralisé où et comment aller chercher cette donnée. En particulier, si celle-ci se trouve dans un fichier, un script automatique sera mis en œuvre grâce au dictionnaire pour transporter le fichier et l’importer dans le DataWarehouse (ETI, Informatica, Ardent, Constellar, etc.), de même si elle vient d’une base relationnelle, d’un annuaire, etc.

Fi gure 6 : Ech ange de type “Extr ac tio n”

Les systèmes de réplication SGBDR sont optimisés pour répliquer en mode fil de l’eau ou en mode batch des données issues de SGBDR. Les produits les plus avancés étendent leur capacité à d’autres sources de données, comme les fichiers VSAM par exemple. Capables de fonctionner en mode événementiel (dès qu’un UPDATE base de données est déclenché par exemple), ces outils s’appliquent très bien à une problématique d’intégration d’applications client/serveur. Comme nous le verrons au paragraphe développement, ils permettent d’intégrer ces applications sans intervention dans le code. Les mécanismes de réplication SGBDR sont trop limités en terme de routage et formatage.

En revanche, ils ne s’appliquent correctement qu’à ce type d’environnement, leur capacité de routage et de formatage d’événements n’étant pas suffisamment évoluée.

Figu re 7 : Mé ca nisme de rép lic ati on en tre S GB DR

Si les inconvénients d’un système d’échange reposant entièrement sur les transferts de fichiers sont bien connus, les limites d’une interopérabilité uniquement fondée sur la donnée sont en revanche moins évidentes à appréhender. La réplication SGBDR est bien entendu une niche dans laquelle ne rentrent pas aisément les applications centrales, les ERP et les communications hétérogènes au sens large. Ces outils pourront cependant être complémentaires d’une architecture EAI pour adresser des problématiques spécifiques, dans le cas d’applications client/serveur par exemple. Les ETL pourraient en revanche constituer un excellent socle technique d’interopérabilité. Malheureusement, leur objectif est de créer une nouvelle base de données, pas de diriger des événements vers différents systèmes hétérogènes. En somme, c’est une excellente “pompe”, mais un mauvais “routeur”5 : ils mettent en œuvre un référentiel de méta-données décrivant où l’information se trouve et ce qu’elle signifie, mais pas le référentiel de règles métier décrivant les flux voire les processus complexes. Exemple : la fermeture d’un compte déclenche une facturation, le passage d’un ordre boursier déclenche sa comptabilisation, etc. Nous le découvrirons en détail dans la suite, les seuls outils à fournir ces deux fonctionnalités sont les Message Broker. Comme leur nom l’indique assez bien, ces outils s’appuient sur des communications de messages asynchrones. 5 A noter cependant que des acteurs comme Constellar, issus des premières générations d’ETL, ont abordé le problème dans sa globalité et offrent aujourd’hui une intégration poussée avec les outils d’EAI.

Synch rone ou async hrone ? Les architectures distribuées et l’émergence de technologies de communication entre applications imposent des choix de conception architecturale. Une des décisions importantes à prendre reste le mode de communication : synchrone ou asynchrone? Dans un mode synchrone, l’émetteur doit localiser le destinataire sur le réseau, se connecter à l’une de ses instances et attendre la réponse. Dans un tel mode, la requête n’est jamais perdue. En cas d’erreur ou de rejet, l’application émettrice en est directement avertie. Les technologies RPC, HTTP, Corba, COM, etc entrent dans cette catégorie. A l’inverse, dans un mode asynchrone, la disponibilité du destinataire au moment de l’émission n’est plus indispensable. Celui-ci traitera la requête en temps voulu. Charge au middleware utilisé de garantir alors que la requête ne se perde pas. Les technologies de Message Oriented Middleware comme IBM MQSeries, Microsoft MSMQ, Tibco/Rendez-Vous entrent dans cette catégorie. Si l’émetteur de la requête a besoin de la réponse avant de passer à une autre tâche, les technologies synchrones sont à privilégier, ce qui nécessite alors un haut niveau de disponibilité à la fois du réseau et des applications destinatrices. Si une telle disponibilité n’est pas garantie ou si la réponse n’est pas immédiatement nécessaire, il sera alors préférable de mettre en œuvre des communications orientées sans connexion. D’une manière générale, il est fortement conseillé de réduire les besoins de synchronisation entre les applications afin d’améliorer leur disponibilité et leurs performances.

Un mécanisme d’échange avec fort découplage: le message.

L’idée de faire communiquer les applications en mode message est relativement ancienne puisque avant d’apparaître dans les Message Oriented Middleware (MOM) actuels, elle est le fondement de la communication entre objets, distribués ou non. Un message peut contenir plus que de la donnée simple. Il pourra, comme dans le cas des communications entre objets, inclure la méthode, c’est à dire l’action qu’il représente. Exemple : envoi d’un message commander contenant la quantité, le code de l’article ; envoi d’un message règler contenant la devise, le client et le montant, etc. Pour assurer le transport de ces messages, nous avons deux principales technologies à notre disposition : • les Message Oriented Middleware Des produits comme MQSeries (IBM), Tib’Rendez-vous (Tibco), MessageQ (BEA), MSMQ (Microsoft) proposent ce style d’offre. • les Object Request Broker (ORB) Visibroker (Inprise), Orbix (Iona), ou plus récemment les offres d’Application Server (IBM WebSphere, BEA WebLogic, Microsoft MTS, Sun, etc.) qui sont parfois bâties au-dessus d’un ORB. L’interopérabilité soulève cependant une contrainte forte : ne pas lier les systèmes entre eux. En particulier, le fait que, pour échanger, deux applications doivent être simultanément disponibles en permanence n’est clairement pas acceptable.

En ce sens, la vision de l’OMG6 qui propose une communication synchrone d’objets à objets est irréaliste dans le cadre de l’EAI. Les services d’échanges asynchrones du standard CORBA ne satisfont pas aujourd’hui aux besoins complexes de l’EAI.

Les systèmes doivent demeurer le plus indépendants possibles, et les mécanismes qui les lient le plus asynchrone possible. Le système A doit fonctionner même si le système B n’est plus disponible ; à son retour, B récupérera ce qui lui était destiné.

Routage et transformation sont assurés par les Message Broker.

Que le lecteur ne conclue pas trop vite, les éditeurs d’ORB ou de serveurs d’applications commencent à intégrer ce type de technologie dans leurs produits. Voir à ce propos Iona et le projet Warhol, Forté Fusion, BEA et son partenariat avec TSI (l’éditeur du Message Broker Mercator), Jasmine de Computer Associates, IBM avec WebSphere ou Microsoft COM+.

Bien entendu, on rétorquera que les ORB disposent de mécanismes asynchrones que sont les Event Services et autre Notification Services. Cependant, on l’a vu, le simple transport ne suffit pas. La valeur ajoutée d’une architecture EAI se situe au niveau des services de transformation et de contrôle de flux qu’elle met en œuvre, voire au niveau d’autres services que nous détaillerons plus loin. Dans ce domaine, seules les offres se fondant sur des MOM sont aujourd’hui à même de couvrir ce besoin.

Du reste, même si l’asynchrone doit être privilégié dans la mesure du possible, il est des cas où le mode synchrone question/réponse est nécessaire. Par exemple dans le cas d’une consultation de référentiel externe, bloquante pour un processus donné. On verra donc dans l’avenir des produits s’appuyer indifféremment sur du middleware synchrone (HTTP, IIOP, RMI, DCOM, etc.) ou asynchrone (MQSeries, MSMQ, etc.). Bien que le retard de l’offre EAI des éditeurs de serveurs d’applications soit encore important, il est donc probable que les deux approches fusionnent à moyen terme : les communications en entrée et en sortie du serveur d’applications seront pilotées par un moteur d’EAI, fournissant des services de bien plus haut niveau que l’accès à un protocole technique comme HTTP ou IIOP. Pour les entreprises, il n’y a donc pas de choix à proprement parler, pour démarrer un projet d’EAI aujourd’hui, il faut se tourner vers les offres de MOM et de Message Broker. L’important étant de constater qu’il s’agit d’une trajectoire claire du marché, c’est-à-dire dans laquelle s’inscrivent aussi bien les acteurs historiques du monde de l’asynchrone que les ténors du moniteur transactionnel ou du serveur d’applications. Nous vous proposons donc au travers des prochains paragraphes de décrire les briques d’architecture qui incluent le transport et les services à valeur ajoutée d’une architecture EAI : transformations, routages, passerelles, connecteurs, gestion de processus complexes (workflow). Enfin, nous illustrerons les aspects liés au développement d’application et la problématique d’administration et de sécurité.

Message Oriented Middleware : une technologie orienté échange point à point...

2.2. Echange en mode Message Le mode de transport principalement utilisé par les Message Oriented Middleware est du point à point. C’est à dire qu’une application émettrice poste un message dans une file d’attente précise. L’application réceptrice R1, quand elle le décide, consomme les messages postés par le programme émetteur. Les deux applications communiquent donc directement, au travers

6 Object Management Group, groupement d’éditeurs et d’utilisateurs publiant la standard CORBA (Common Object Request Broker Architecture).

d’une file d’attente commue des deux parties. Si l’application émettrice doit fournir l’information à un deuxième programme R2, elle doit poster le message une seconde fois.

Fi gu r e 8: Ec ha nges v i a un MOM La principale fonction d’un MOM est de transmettre des messages de manière sécurisée

Au-delà de la simple gestion de files d’attente, le MOM assure un certain nombre de services pour sécuriser l’architecture : • Garantie de délivrance Un message, une fois soumis par l’application, sera forcément traité par le système : soit l’application réceptrice le consomme (et il y a garantie d’unicité) soit sa durée de vie expire et il est envoyé dans une file d’attente particulière (dead-letter queue) où une action de l’exploitant est requise. • Notification Il est possible de “simuler du synchrone” par l’utilisation de reply queue dans laquelle l’application émettrice attend une réponse en retour de son message. • Priorité, groupage des messages Il est possible de marquer les messages comme ayant une priorité particulière ou comme faisant partie d’un groupe de messages. • Sécurité Il est intéressant de pouvoir restreindre l’accès pour des files d’attente particulières. Par exemple tout le monde ne doit pas pouvoir publier des messages dans une file d’attente “paiement” sans contrôle. Un message peut être authentifié, son contenu rendu intègre ou confidentiel. Nous détaillerons ces points au paragraphe Sécurité. • Triggering Sur l’arrivée d’un message dans une file d’attente, il est possible de déclencher automatiquement un programme. Par exemple, une transaction, une mise à jour de base de données, etc. • Transaction Le MOM peut se comporter comme un Ressource Manager vu d’un moniteur transactionnel ou d’un OTS. Ainsi, il est possible d’écrire des composants s’exécutant dans un Application Server et qui réalisent une mise à jour de base de données et un envoi de message, le tout de manière transactionnelle. Inversement, le MOM peut aussi jouer le rôle du Transaction Manager, c’est le cas par exemple lorsque le MOM synchronise l’envoi d’un message avec des mises à jour de plusieurs SGBDR

Un point sur les modèles de communication L’habitude est de classer les méthodes de communication entre applications en cinq modèles. Chacun de ces modèles repose sur l’un des deux principes de base suivants : • Le mode bidirectionnel souvent orienté connexion, correspond à la plupart des implémentations de communication conversationnelle et question/réponse • Le mode unidirectionnel souvent orienté sans connexion, correspondant généralement aux implémentations par messages. Conversationnel : Dans ce mode, les deux applications communiquent à l’intérieur d’une même connexion, un peu comme une conversation téléphonique entre deux personnes. Il suppose que les deux partenaires soient disponibles au moment de l’échange. L’émetteur initialise la connexion. Un dialogue sous forme de questions/réponses s’instaure. Puis la communication prend fin sur demande explicite d’un des participants. Request/Reply : Ce mode est également synchrone, impliquant par conséquent la disponibilité des deux partenaires. C’est le mode d’implémentation des appels de fonctions distantes (RPC). Une application appelle une fonction qui s’exécute à distance, de manière transparente. L’application appelante reste bloquée le temps d’exécution de la requête. Message Passing : A l’inverse des deux modes précédents, ici l’échange est généralement unidirectionnel et jamais bloquant, elle prend la forme d’un échange de message, de la même manière que l’émission d’une lettre. Ce mode étant sans connexion, la disponibilité du destinataire à l’instant de l’émission n’est pas nécessaire. Message Queuing : Ce mode est très similaire au mode précédent, il en est une implémentation “sécurisée”. Entre l’émission et la réception, le message est stocké sur disque. Comme précédemment, la disponibilité du destinataire au moment de l’émission n’est pas nécessaire puisque le paradigme de base est sans connexion. Publish-and-Subscribe : C’est le troisième mode mettant en œuvre l’échange de messages. Ici l’échange n’est plus 1 à 1 mais 1 vers N. Un message est envoyé par un émetteur à plusieurs destinataires. Ce modèle repose sur un échange de messages et présente donc les avantages liés au modèle sans connexion.

Les applications pevent donc être directement liées à la couche transport (MOM, fichiers, email ORB...). Dans le cas du MOM, les applications utilisent des verbes très simples de type mq_put pour poster des messages et mq_get pour les retirer :

F ig ur e 9: La co uc he tr an sp ort c omm e p re mi èr e br ique d e l’ EA I

Ce type d’architecture a néanmoins un défaut important : il n’enraye pas le syndrome spaghetti puisque finalement les applications dialoguent toujours en point à point. Un réseau de ce type est donc très rapidement complexe (N nœuds donnent N*(N-1) flux possibles !), et s’avère rapidement très difficile à administrer. Les deux modes du modèles Publish & Subscribe : centralisé et décentralisé.

Une solution, tout d’abord introduite par Tibco dans son MOM Tib’RendezVous, consiste à publier des messages en multi-point. C’est la notion de Publish and Subscribe. Les technologies actuelles permettent de réaliser deux modes de Publish and Subscribe : • Mode Décentralisé L’initiative du Publish et du Subscribe revient aux applications. Elles utilisent des verbes de publication de type mq_put(domaine de publication, message). Les applications réceptrices s’abonnent avec des verbes de type mq_subscribe(domaine_de_publication). Tibco, et plus récemment IBM MQSeries 5.1 et MSMQ2000 (COM+) implémentent ces fonctionnalités. Les domaines de publication sont des chaînes de caractères du type domaine.sous-domaine.sous-domaine.etc., il est possible de s’abonner à un domaine précis ou à un ensemble de domaine (domaine.*). • Mode Centralisé Dans ce mode, les applications n’ont pas l’initiative de la publication ou de la souscription. Celle-ci revient à un Hub centralisé par lequel passent tous les messages. Dans ce mode, le Hub est un Message Broker : MQSeries Integrator (IBM), Mercator (TSI), Tib/MessageBroker (Tibco), etc. C’est l’administrateur du Hub qui décrit les règles de routage de chacun des flux. Ces règles peuvent se fonder sur la file d’attente de réception, mais aussi sur le contenu même du message7, on parle alors de content-based routing. Le schéma logique d’utilisation du Publish and Subscribe décentralisé ou centralisé est le suivant :

Fi gu re 1 0: Le Mess age Broke r co mme d eu xièm e b riq ue de l’EA I

La différence fondamentale entre les 2 modes réside dans le fait que, pour le premier mode, les applications embarquent du code pour publier et s’abonner. Dans l’autre mode, les applications publient sur des files d’attente du Hub. Elles utilisent encore l’API mq_put/mq_get du MOM comme dans le cas du point à point, mais uniquement pour communiquer avec le Hub : N applications génèrent N flux possibles (configuration en étoile vers le Hub). 7 Exemple : tous les ordres de paiement de moins de 10 000 F sont routés vers tel réseau de compensation, ceux de plus de 10 000 F vers tel autre : le routage dépend du contenu du message.

Le mode centralisé du modèle Publish & Subscribe est adapté à la problématique d’EAI.

Concrètement, le publish/subscribe décentralisé s’applique à l’échelle d’une application (par exemple une application de Front Office qui “s’abonne” à telle cotation de titres), mais n’est pas adapté à une architecture EAI à l’échelle de l’entreprise étendue. Pour cela, le Publish/Subscribe centralisé, à l’aide d’un Message Broker, va permettre d’assurer au niveau central un certain nombre de services additionnels tels que les transformations de messages, les passerelles vers d’autres systèmes ou middlewares, ainsi que la gestion de processus complexe. Ces services vont permettre de diminuer la part de code nécessaire à la communication dans les applications.

2.3. Les services fondamentaux de l’EAI Dans une architecture EAI centralisée sur un ou plusieurs “Hubs”, il est possible (voire conseillé !) d’implémenter des services à valeur ajoutée pour traiter les messages reçus. Nous allons donc détailler ici les services de formatage, les passerelles et la gestion de processus. ■ 2.3.1. Transformations et connecteurs Comme nous l’avons présenté dans l’analyse de la communication entre deux systèmes, l’une des phases concerne le formatage des données envoyées. Par exemple, si une application A envoie tous les soirs à l’application B la liste des clients qu’elle gère, les deux applications devront s’accorder sur un format. Exemple : un fichier où chaque enregistrement est formaté en “pas fixe” : 0 1 2 3 4 01234567890123456789012345678901234567890 0012670000DUPONT Gérard 0012671000DURANT Gabriel ...

Généralement, pour arriver à ce fichier, il aura fallu extraire la donnée de l’application, puis développer un programme, en Shell, en C, en Perl, etc. générant le fichier au bon format. Indépendamment de cette première extraction, certaines applications destinatrices de cette information pourront l’attendre sous un format différent, par exemple : 0012670000DUPONT Gerard 0012671000DURANT Gabriel ... Les éditeurs de format sont de puissants outils dédiés à la description sémantique des messages.

Dans une architecture à base de Message Broker, il est possible d’externaliser totalement cette étape de transformation au niveau du broker. L’intérêt est multiple : • Le développement est facilité par l’utilisation de l’éditeur de formats, qui est en fait un AGL dédié à la conception de règles de formatage. En particulier, l’outil va permettre de “parser” des messages, de définir des champs, d’appliquer plusieurs règles sur un champ, de réorganiser les champs, etc. pour produire un nouveau message. • Les règles de transformation sont centralisées, les compétences nécessaires minimisées. Le développement de ces modules n’est plus à la charge des projets

applicatifs, mais devient l’affaire d’une équipe dédiée à la gestion des flux. Un référentiel de “méta-données” décrivant les données de l’entreprise est constitué. • Le système, dédié à cette tâche, est beaucoup plus robuste que la somme des interfaces précédemment utilisées.

F igur e 11: E xem pl e de re fo rmata ge d’ un flu x d ’i nf or mation Les connecteurs standards (formats prédéfinis) augmentent fortement la productivité et la maintenabilité d’une solution EAI.

Au-delà de cette possibilité de développement, un des grands intérêts des Message Broker du marché réside dans la disponibilité de connecteurs standards. Un connecteur est un ensemble de règles de formatage destiné à interfacer des messages vers : • des ERP8 : SAP, PeopleSoft, JD-Edwards, Baan, Oracle Applications, etc. • des formats standardisés ■

finance : clearing Swift, Fix, CHAPS, EuroClear, ...

■

industrie, santé : réseaux EDIFACT, X.12 EDI, HL7, ...

■

autres domaines : télécom, transports, énergie, ...

• des progiciels orientés métier : facturation (Kenan, BSCS, etc.), gestion de la relation client (Siebel, Vantive, Clarify, Remedy, etc.), ... • des formats techniques : XML, SGML, copy book COBOL, … Ces connecteurs réduisent considérablement l’effort nécessaire à l’intégration de ces progiciels ou réseaux à valeur ajoutée dans le Système d’Information. Cette économie est d’autant plus intéressante à long terme que la maintenance est garantie par l’éditeur. Celle-ci, à défaut d’être gratuite, permet une réelle maîtrise des coûts d’évolution du SI. Reprenons l’exemple du chapitre 2, et comparons par exemple l’effort initial puis récurrent nécessaire à l’intégration de l’ERP avec le reste du SI : le développement des nombreux scripts d’import/export9, de transformation et de transport est remplacé par la mise en œuvre de produits et leur paramétrage. De plus, la compatibilité de ces produits avec les futures versions des progiciels est garantie par l’éditeur. Ce point est fondamental, car même si les coûts de maintenance du Message Broker ne sont pas négligeables, ils sont connus. Ce qui n’est pas forcément le cas pour des projets de maintenance nécessitant du développement interne. Le schéma suivant positionne le service dans l’architecture, les transformations sont développées au niveau du Message Broker, où des connecteurs 8 Enterprise Resource Planing : progiciel de gestion intégré 9 Notamment écrits avec les langages et interfaces proposés par l’ERP. Les compétences sur ces technologies étant très rares, elles sont forcément coûteuses.

fournis par l’éditeur peuvent cohabiter :

F ig ur e 12: Les co nnec te urs c omme tro isième bri qu e d e l’EA I Point clef de l’étape de formatage : passer par un format pivot .

Pour les nouvelles applications, il est important de ne pas continuer à réinventer différents types de formats pour désigner le même type d’événement. En ce sens, l’introduction d’un format pivot, dont XML pourrait constituer l’implémentation, est fondamentale pour limiter le volume des transformations. Le format pivot va définir de manière unique dans l’entreprise la représentation d’une donnée métier : un client, un paiement, une commande de produit, un achat de titres, une compensation, etc. Certains éditeurs ont bien perçu ce besoin, généralement ceux qui ont une approche “top-down”, c’est à dire avant tout une vision métier, qu’ils implémentent ensuite eux-mêmes. Le principe est beau... mais structurant ! Avant de standardiser toute l’entreprise, une approche incrémentale devra être adoptée.

X ML : la s olutio n de l ’interopérabilité Quand on parle de commerce électronique, l’image qui se dégage est celle d’un site Web où l’on peut acheter des biens et des services. Ce commerce électronique, appelé Business to Consumer (BtoC) ne représente en fait qu’environ 30% du chiffre d’affaire de ce secteur. Où sont donc passés les 70% restants ? Réponse : dans le commerce inter-entrerprises (Business to Business, BtoB)... et encore peu sur Internet. Jusqu’à présent, les entreprises utilisait l’EDI (Electronic Data Interchange) pour se connecter avec leurs fournisseurs et leurs clients. Mettant en œuvre des connexions de type point à point sur des réseaux privés (ou public) de type X.400, ces solutions se sont avérées coûteuses et complexes. Seules de grandes entreprises ont pu investir et proposer (imposer... !) ce type de système à leurs prestataires. Aujourd’hui, les technologies Internet et le standard XML sont des alternatives beaucoup plus simples et économiques, permettant à une multitude de nouveaux acteurs d’y participer. En fait, cette migration du trafic EDI vers des flux XML sur l’Internet va prolonger la vie des systèmes existants et répondre aux besoins d’intégration de tous les partenaires (fournisseurs, clients, tiers,...) de manière beaucoup plus ouverte.

L’exemple suivant donne une idée de la codification XML pour un échange EDI, ici la commande d’un livre: <Title>EDITEUR Lite-EDI Book Ordering 967634 <Message-Date>19990308 <Buyer-EAN>5412345000176 0201403943 Bryan, Martin/SGML and HTML Explained 1 0856674427 Light, Richard/Presenting XML 1 XML représente un élément fédérateur important de l’EEI (Intégration Extra Entreprise). Il permet aux compagnies de définir, pour les messages qui vont constituer les flux entre les systèmes, des dictionnaires standards partagés par les fournisseurs et des tiers tels que les portails ou les systèmes de paiement. Des éditeurs de solutions de commerce électronique intégrent de plus en plus des composants d’accès standards aux catalogues des fournisseurs. Par exemple, le dictionnaire “Common Commerce Library” de CommerceOne définit au format XML des objets et des transactions génériques élémentaires. Ariba annonce Commerce XML (cXML) qui est un ensemble de DTD allégées pour des informations de catalogues et de transactions d’achat. Parmi les initiatives de normalisation en cours, BizTalk de Microsoft offrira des DTD pour tous les types de flux (commandes, personnel, comptabilité,...) entre les principaux ERP (SAP, PeopleSoft). Les éditeurs de progiciels intégrés n’ont pas attendu les organismes de standardisation et proposent déjà des solutions d’interopérabilité inter entreprise basées sur l’emploi du format XML. C’est le cas notamment de SAP dont le dernier module SAP B2B Procurement permet l’intégration dans le SI d’une entreprise des catalogues de ses fournisseurs. Les éditeurs profitent de la flexibilité et de la puissance de cette technologie à l’intérieur même de leurs produits. En outre, la plupart des Message Brokers proposent une intégration forte avec le format XML.

L’int ég r at io n d es tec hn olo gie s Int er ne t d ans SA P En conclusion, XML n’invente rien de nouveau, il démocratise simplement les technologies de l’EDI.

■ 2.3.2. Passerelles techniques La capacité d’une architecture EAI à adresser l’ensemble de la problématique de l’entreprise repose bien entendu sur ses possibilités d’interfaçage avec les systèmes existants. Ceux-ci sont généralement divers et variés, le champ est donc vaste. Les MOM et Message Brokers du marché proposent en standard des interfaces vers : • des SGBDR : Oracle, DB2, SQLServer, Sybase, Informix, etc, • des moniteurs TP : Tuxedo, CICS, IMS, • des serveurs d’applications : WebSphere, Oracle Application Server, WebLogic, MTS, Inprise Application Server, etc, • du transfert de fichiers : avec la notion de conversion message vers fichier et fichier vers message, • d’autres MOM (MQSeries, MSMQ, BEA MessageQ).

l L’accès aux SGBDR Trois interactions possibles avec les SGBDR : en entrée, en sortie, et en lecture.

Se connecter à des sources de données relationnelles est fondamental pour : • Mettre à jour des données sur arrivée de message, Par exemple, à l’arrivée d’un message, une table est mise à jour avec les données contenues dans le message. • Envoyer des messages sur modification de données, Par exemple, sur modification d’un enregistrement dans la base, un message est émis. • Utiliser des données externes au niveau du Message Broker pour réaliser une transformation. On parle alors d’enrichissement par des accès à des tables de références croisées. Par exemple, à l’arrivée d’un message contenant un clientID, celui-ci va être transformé en un autre clientID compatible avec l’application destinatrice, au travers d’une table de translation.

Fi gu re 1 3: P asse relle a ve c les S GBDR

Les deux premiers points vont nécessiter l’utilisation d’une passerelle entre le MOM et le SGBDR. Suivant les technologies, ces passerelles sont fournies par l’un ou l’autre des éditeurs. A titre d’exemple, Oracle propose sa technologie Oracle Gateways pour s’interfacer à MQSeries. Tibco fournit quant à lui sa propre solution d’interfaçage aux dernières versions d’Oracle (Tib/Connect for Oracle). Ces passerelles permettent de déclencher des ordres SQL ou des procédures

stockées sur arrivée de message, et inversement d’émettre ou recevoir des messages depuis le langage de la base de données (PL/SQL, TransacSQL, Java, etc.). Nous aborderons un exemple concret d’un tel développement au paragraphe Développement. Concernant le troisième point, c’est à dire la capacité d’utiliser ou de mettre à jour des données SGBDR dans le Message Broker, le besoin est plus ou moins bien pris en compte selon les produits. L’idée est de créer une règle qui prendrait par exemple un message du type suivant : 0 1 2 3 4 01234567890123456789012345678901234567890 0012670000DUPONT Gérard

et de translater l’ID de M.Dupont à l’aide d’une table externe, de sorte qu’il soit compris par une application ne disposant pas du même référentiel client. Par exemple : 0 1 2 3 4 01234567890123456789012345678901234567890 0000993223DUPONT Gérard

La règle devra donc : • récupérer l’ID d’origine, • sélectionner dans le SGBDR l’ID cible (select IDCIBLE from TRANSLATION where IDSOURCE=0012670000 ) • replacer l’ID cible dans le message. Tous les Message Brokers ne sont pas égaux devant la fonction passerelle avec les SGBDR.

Certains produits (Mercator, Constellar Hub ou CrossWorld) proposent une intégration graphique des sources de données, tandis que d’autres (MQSeries Integrator, etc.) nécessitent encore l’écriture de code C à l’aide d’une API d’accès fournie.

l L’interconnexion avec les moniteurs TP et les Serveurs d’Applications De manière identique à la problématique SGBDR, il devrait être possible dans une architecture EAI de : • envoyer des messages depuis une transaction ou un composant, • déclencher une transaction ou une méthode de composant à l’arrivée d’un message. L’interfaçage avec des moniteurs TP se fait sans gros problème.

Emettre ou recevoir des messages depuis une transaction ou un composant est nativement possible par la disponibilité des librairies du MOM dans l’environnement d’exécution. Par exemple, émettre un message MQSeries depuis une transaction Tuxedo sera réalisé en C à l’aide des API MQSeries ; recevoir un message MSMQ depuis un composant COM sous MTS sera réalisé au travers du composant d’accès COM à MSMQ. Dans tous les cas, ces actions seront exécutées dans un contexte transactionnel. Un exemple sera illustré au paragraphe Développement. Dans l’autre sens, programmer est encore nécessaire : on va positionner un trigger, c’est-à-dire un programme se déclenchant à chaque fois qu’un message arrive. Ce programme va alors “déplier” le message pour en extraire le contenu, puis invoquer une transaction ou une méthode de composant.

F igur e 14: Ex emp le d e décle nche ment d ’un e tr an sac ti on à réc ep tio n d’u n messa ge

Des efforts peuvent encore être réalisés pour traiter correctement ces aspects. En effet, les éditeurs (IBM, Microsoft, etc.) peuvent améliorer l’intégration de ces technologies qui demeurent complexes. On peut imaginer des processus plus simples, qui éviteraient notamment de devoir programmatiquement construire les messages pour les envois, et de les “déplier” à la réception. Ces initiatives verront le jour dans COM+ et probablement dans les prochaines versions d’EJB ou via des implémentations propriétaires (Iona, IBM, etc.).

l Le transfert de fichiers La prise en compte des transferts de fichier au niveau du Hub central permet une migration évolutive vers un mode message.

L’interfaçage de l’architecture EAI aux transferts de fichiers est fondamentale, en particulier pour permettre une reprise de l’existant par étape. Les transferts de fichiers existants seront petit à petit intégrés dans le Bus d’Echange, et éventuellement migreront définitivement pour certains d’entre eux vers un mode fil de l’eau. Pour assurer cette évolution, le système doit offrir la possibilité d’intégrer bien sûr des transferts de fichiers, mais aussi d’offrir la possibilité : • de passer du fichier au message, Un fichier reçu dans le Bus d’Echange peut être séparé en autant d’enregistrements qu’il contient, ces enregistrements étant réémis sous forme de messages pour être traités normalement par le Bus. Exemple de besoin : une application existante ne communique qu’en mode fichier, alors que de nouvelles applications ont déjà été adaptées au mode message. • de passer du message au fichier. Des messages reçus peuvent être stockés par le Bus pour être transmis en batch sous forme de fichier. Exemple de besoin : une application de comptabilité, qui ne fonctionne pas (encore !) au fil de l’eau, reçoit la consolidation des événements de la journée pour les traiter le soir.

Figure 15 : Exemple s de pa sser el les v er s et en pro ven an ce de f ic hi e rs

Cette intégration est généralement assurée au niveau du Message Broker. Des produits comme Bus Applicatif (Sopra), Mercator (TSI) ou Constellar Hub (Constellar) permettent une intégration aisée des transferts en mode fichier vers du message et inversement. Cette intégration est primordiale pour s’insérer dans les systèmes existants, aujourd’hui encore composés en majeure partie de transfert de fichiers.

En terme d’architecture, les connecteurs se positionnent soit au niveau du MOM (moniteurs TP et serveurs d’application, SGBDR), soit au niveau du Message Broker (SGBDR également, et transfert de fichiers) :

Fig ur e 16 : Les pa ssere lle s c omme quat rième briqu e d e l’EA I

l 2.3.3. La gestion de processus ou Workflow Historiquement cantonné aux solutions de Gestion Electronique de Documents (GED) par des éditeurs comme Filenet ou Eastman Software, le Workflow permettait de faire circuler des documents selon des processus complexes mettant en jeu des personnes physiques. Par exemple : une gestion d’actes papiers, scannés, puis transmis à divers acteurs au travers d’un processus de validation, d’enrichissement, etc. Aujourd’hui, on s’aperçoit que ces outils peuvent également adresser des problématiques liées à la communication entre applications. Ils interviennent là où le Message Broker se trouve limité, notamment dans les cas de : • gestion événementielle complexe, • systèmes avec conservation d’état, • flux N vers 1, •… Prenons donc un exemple concret, le cycle de vie d’un prêt bancaire :

Fig ure 17 : Exem pl e d e pr oc ess us méti er a ut om at is ab le pa r un Wo rkFl ow

Pour traiter ce problème (ici extrêmement simplifié), on s’aperçoit de l’utilité d’un moteur capable de gérer des états, ainsi qu’une gestion événementielle complexe : point de rendez-vous des validations, branches conditionnelles, etc. Les outils de Workflow se positionnant au-dessus des Message Brokers10 sont en train d’atteindre la maturité nécessaire pour tenter le transfert du code existant dans les applications d’aujourd’hui, vers un moteur dédié. L’intégration de la brique Workflow reste souvent à faire au niveau technique.

Cependant, aujourd’hui les moteurs de Workflow sont souvent peu intégrés avec les autres briques de l’EAI. Pourtant, ils fournissent le niveau d’intégration le plus élevé entre les applications, car ils expriment les flux en terme de tâches utilisateurs plutôt qu’en terme d’échange d’information.

Fi gur e 18: Le W or kflo w co mme ci nq uiè me b riqu e de l ’EAI

Comme le figure le schéma d’architecture précédent, le moteur de Workflow devra s’appuyer sur le Message Broker et non pas directement sur le MOM. En effet, c’est au niveau du Message Broker que vont être décrits les flux de l’entreprise. Redescendre au niveau de la couche MOM reviendrait à perdre toute modélisation de haut niveau et ne voir que des files d’attentes, objets plus “techniques”. Si c’est déjà le cas de Crossworld, Forté ou Vitria, les acteurs majeurs tels BEA et IBM en sont encore au niveau du concept marketing... Chez Crossworld par exemple, les processus métiers distribués de l’entreprise sont définis dans des collaborations, pouvant être à leur tour réutilisées sous forme de composants dans des groupes de collaborations. Cette organisation modulaire permet d’offrir par secteurs d’activité (Finance, Télécommunication, Industrie, Santé, Administration) un certain nombre des processus standards, tels que l’ouverture d’un compte ou la gestion d’un abonné, qu’il suffira adapter aux contraintes particulières de l’entreprise.

2.4. L’intégration des applications Comme nous avons commencé à l’évoquer au paragraphe concernant les passerelles, il doit être possible de réaliser des applications adaptées au mode message dans tout type d’environnement : applications client/serveur (SGBDR) ou applications 3-tiers (moniteurs TP et serveurs d’applications). Nous montrerons également les mécanismes mis en œuvre pour intégrer un ERP. l 2.4.1. Les applications client/serveur Ici, la problématique est de migrer en mode message une application 10 Voir l’offre e-Link de BEA, ou des outils dédiés comme Crossworld.

client/serveur qui utilise par exemple : • Un poste client dialoguant via SQL et des procédures stockées pour la partie interactive, • Des programmes batchs, développés en C, assurant la communication avec le reste du SI. L’intégration d’applications C/S dans une infrastructure EAI repose soit sur l’utilisation d’API d’accès MOM (méthode intrusive), soit sur des outils de réplication de bases (méthode non intrusive).

Des envois et réceptions de messages seront intégrés dans les procédures stockées, supprimant de fait la plupart des programmes batch, ainsi que la logique de transformation. Examinons un exemple de code en environnement Oracle (PL/SQL). Très simplement, le développeur utilisera un package fourni et les procédures MQOPEN/MQCLOSE pour ouvrir et fermer une file d’attente, MQPUT/MQGET pour déposer et retirer des messages : DECLARE queue PGM.MQOD@pg4mq; msgDesc PGM.MQMD@pg4mq; getOptions PGM.MQGMO@pg4mq; objectHandle BINARY_INTEGER; message RAW(32767); BEGIN — Ouvre la file d’attente QUEUE en lecture. queue.OBJECTNAME := ‘QUEUE’; PGM.MQOPEN@pg4mq(queue, PGM_SUP.MQOO_INPUT_AS_Q_DEF, objectHandle); — Recupere un message dans la queue. PGM.MQGET@pg4mq(objectHandle, msgDesc, getOptions, message); — Traitement du message ... ... — Ferme la file d’attente. PGM.MQCLOSE@pg4mq(objectHandle, PGM_SUP.MQCO_NONE); END;

Cet exemple de procédure stockée pourrait bien entendu être invoqué sous forme de trigger et déclenché à chaque mise à jour de table. Une seconde solution, sans impact sur l’application, consiste à utiliser un outil de réplication. L’agent du moteur de réplication “surveille” certaines tables et émet un événement dès qu’une mise à jour se produit. Cet événement peut être utilisé pour propager la mise à jour de la table sur d’autres bases, mais il peut aussi générer un message MOM (MQSeries, MSMQ, etc.), qui pourra être traité dans le cadre de l’architecture. l 2.4.2. Les applications 3-tiers L'intégration d'applications 3-tier peut se faire par API d'accès au MOM (programmation texte), soit à l'aide de composants techniques aux standards COM ou EJB (programmation graphique), soit bientôt sans code du tout !

Le principe de développement a déjà été évoqué, synthétisons ici les technologies disponibles : • les interfaces natives : API propriétaires du type mq_get, mq_put, mq_subscribe, disponibles en C/C++, en Java, Cobol, etc. • les interfaces standardisés en Java : un peu à l’image de ODBC pour l’accès à la donnée, Sun tente de standardiser une interface d’échange Java Message Service (JMS). Au-dessous de cette interface, les éditeurs proposeront leur driver respectif (aucun n’est encore disponible).

• les composants d’accès : développement à base de composants techniques11. Nous ne reviendrons pas sur l’utilisation des API en Java ou en C, dans la mesure où leur utilisation s’apparente à l’exemple précédent en PL/SQL. Effectuons en revanche un zoom sur le développement à base de composant. La copie d’écran ci-dessous montre la différence par rapport à un développement “classique” à base d’API ou de bibliothèque de classes. Ici, la programmation s’effectue par glisser/déplacer du composant. On peut alors naviguer dans les méthodes et propriétés (panneau d’exploration), les fonctionnalités d’“auto-complete” sont activées (fenêtre d’édition de code), enfin, des panneaux de propriétés permettent de remplacer l’écriture de code par du paramétrage.

Figu re 19: Ex emp le de pro gra mmat i on vi sue ll e avec Vi sua l Ba sic

Enfin, comme nous l’indiquions en introduction, il est fort probable que l’intégration avec les serveurs d’applications se fasse encore plus étroite par la suppression de l’étape de codage au profit d’une simple déclaration. Pour qu’un composant émette un appel de méthode en asynchrone au travers du bus de message, il suffira de le lui indiquer par paramétrage. Avec la sortie de COM+ sous Windows2000, Microsoft se lance déjà dans cette direction. l 2.4.3. Les ERP et autres progiciels métier La plupart des ERP et progiciels du marché proposent des interfaces pour lire ou modifier les informations internes. Ces interfaces permettent d’intégrer le progiciel au reste du Système d’Information. On peut classer ces interfaces en deux types : • Mode message : utilisation de connecteurs “légers” • Mode API : utilisation de connecteurs “lourds” En mode message, des formats de fichier spécifiques sont utilisés (par exemple Idoc pour SAP, EDI pour PeopleSoft, etc.). Ces modes sont orientés batch : le fichier est envoyé dans le système, il génère des actions dans le progiciel, et éventuellement un fichier de réponse. 11 Uniquement dans le monde COM avec le composant MSMQ, les Enterprise Java Bean (EJB) MQSeries devraient sortir cette année.

Exemple : création d’un fichier formaté demandant la liste des opérations comptables de tel type, depuis telle date, soumission au progiciel qui renvoie en retour un fichier formaté de réponse. Ces interfaces en mode batch devront ainsi être utilisées en mode fil de l’eau, en entrée du progiciel : l’arrivée d’un message (déjà formaté par le Message Broker) déclenche un programme utilisant les interfaces batch du progiciel pour importer le message. On parle de connecteur léger, car c’est le Message Broker qui se charge de toute la partie formatage, le connecteur sur la machine du progiciel cible ne fait que soumettre un document au travers d’une API technique : submit(Idoc). Une deuxième possibilité souvent employée est l’utilisation d’API publiées par le progiciel : BAPI (SAP), BOI (Baan), Message Agent (PeopleSoft), Kenan, etc. Ces API sont disponibles en C, en Cobol, en Shell, etc., mais aussi aux normes des composants du marché : Corba (puis EJB dans le futur) et COM. Des programmes, déclenchés à l’arrivée de messages spécifiques, pourront utiliser ces API pour mettre à jour des données du progiciel. Dans ce cas, on parle de connecteur lourd, car le programme en question doit disposer de l’intelligence nécessaire au traitement de n’importe quelle requête, ce en utilisant l’API métier du progiciel. Dans le sens progiciel vers l'extérieur, un mécanisme de " trigger " est nécessaire.

Pour intégrer un progiciel en mode fil de l’eau, et surtout pour toute communication en sortie du progiciel, celui-ci doit supporter la notion de “trigger”. C’est à dire la capacité de déclencher un programme sur apparition d’un événement particulier à l’intérieur de l’ERP (création d’un nouveau client par exemple). A l’aide de ces triggers, un événement survenu dans le progiciel pourra aisément déclencher l’émission d’un message. Cependant, tous les ERP ne supportent pas ce type de fonctionnement. Pour SAP, il s’agit par exemple de la technologie Application Linking Enabling (ALE). Il est un des rares à proposer des fonctionnalités de triggering. La méthode plus communément proposée par les éditeurs reste le polling. Les éditeurs de Message Broker supportant des connecteurs vers des progiciels fournissent tous des solutions d’intégration diverses. Un des aspects importants à retenir quant à la qualité de cette intégration est l’exhaustivité des interfaces (des labels de compatibilité peuvent aider le décideur dans son choix) et la capacité de fluidifier la communication (via le support de “triggers”). Le support affiché d’un connecteur particulier ne signifie pas forcément son adéquation dans un autre contexte ... souvent seules quelques fonctionnalités mises en œuvre chez un client suffisent à l’éditeur pour proclamer le support d’un progiciel !

XML se dégage comme le format standard d'échange entre ERP.

Enfin, il est intéressant de noter que les ERP commencent à voir en XML un format capable d’unifier ces différentes technologies d’accès. Une telle standardisation permettrait à terme de bénéficier d’une vision homogène des données et traitements disponibles dans ces systèmes, au travers de flux XML normalisés. La première de ces initiatives est BizTalk de Microsoft ... mais sans offre technique à l’heure actuelle, l’éditeur de Redmond tentant d’occuper le terrain marketing !

2.5. Administration et Exploitation Autre aspect particulièrement important d’une infrastructure EAI : la mise en place d’outils d’administration et d’exploitation. En effet, dans un environnement où les flux vont se multiplier, avec probablement des niveaux de sécurité différents, il est indispensable de se doter des

moyens adaptés à leur administration : Trois fonctions pour l'administration : gestion de configuration, suivi, opérations à dis tance.

• Configuration : mise en œuvre de flux, reroutage, paramétrage, etc. Dans l’idéal, les outils devraient permettre de gérer son réseau au travers d’une carte représentant visuellement tous ses éléments. Malheureusement, l’intégration n’est pas au rendez-vous. L’administration n’est pas une brique commune, mais une fonction à assurer à chaque niveau ! En revanche pour chaque couche, les éditeurs ou tierces parties proposent des outils de qualité12. • Supervision : suivi des flux, de la qualité de service globale, refacturation, alarmes orientées métier, etc. De manière identique, là où les couches basses sont bien outillées, la supervision des flux vus du Message Broker ou du Workflow reste une problématique mal adressée aujourd’hui. Les éditeurs ne proposent que de maigres outils de “message tracking” bien en deça des réels besoins de suivi orientés métier 13, c’est à dire à destination de l’utilisateur final : tous les paiements ont-ils été acquittés ? comment refacturer automatiquement l’utilisateur de mon réseau à valeur ajoutée ? comment recevoir une alarme si une commande est rejetée ? etc. • Opérations à distance : relance de service, sauvegardes, rejeu, etc. Même problématique, ces outils aujourd’hui dispersés dans chaque offre, gagneraient à intégrer une solution globale. • Gestion de la sécurité : voir le prochain chapitre.

Figure 20 : Les outils d’exploitation comme sixièm e brique de l’EAI

Nous l’avons vu, la brique “Administration” relève en fait plus de l’intégration de multiples produits, issus de chaque couche de l’architecture. Or la mise en place d’une solution d’EAI nécessitera à terme des solutions intégrées pour prendre en charge correctement les fonctions décrites plus haut. Ce n’est malheureusement pas le cas actuellement. Une nouvelle fonction: l'IFA pour "Information Flow Administrator".

Enfin, elle aura des répercutions au niveau de l’organisation de l’entreprise. En effet, une nouvelle fonction est identifiée qui sera au flux ce qu’est le DBA (DataBase Administrator) à la donnée : l’“Information Flow Administrator”. Intervenant à la fois en amont dans le développement (assistance aux maîtrises d’œuvre applicatives), mais aussi en aval dans l’exploitation quotidienne des flux, l’IFA sera également l’interlocuteur des utilisateurs, leur fournis-

12 Candle, BMC ou MessageQuest offrent des solutions de qualité pour MQSeries. Microsoft intègre l’administration de MSMQ dans sa console d’administration : la MMC. Pour les couches Message Broker et Workflow, chaque éditeur propose sa propre solution. 13 On peut néanmoins citer les Monitoring Tools de TSI, Neon Track de NEON et saluons l’avance de Sopra en ce domaine, sa solution de gestion de flux A&P étant destinée à cet usage.

sant des indicateurs de haut niveau sur les flux mis en œuvre. L’administration d’un produit est souvent la chose par laquelle l’éditeur finit ... compte tenu de la maturité moyenne du marché, cette fonction n’est pas encore prise en compte dans sa globalité. Au vu des alliances en cours, nul doute en revanche que les quelques acteurs qui vont se dégager proposeront, eux, des solutions performantes dans un cadre intégré.

2.6. Gestion de la sécurité Par quels moyens est gérée la sécurité des échanges entre vos applications aujourd’hui ? Par rien la plupart du temps ! Aussi étonnant que cela puisse paraître, c’est pourtant le constat que l’on fait quand on se penche sur ces échanges, essentiellement réalisés à l’aide de transferts de fichiers. “Rien” est quelque peu exagéré mais reflète le manque de vision à ce niveau, la sécurité n’étant finalement l’affaire que de mots de passe machine, inscrits en clair dans des fichiers batch. Pour les flux inter-entreprises au travers de Réseaux à Valeur Ajoutée (VAN : Value Added Network), par exemple les réseaux de compensation comme Swift, les services sont plus professionnels : authentification de chaque message, intégrité, garantie de non-répudiation sont des fonctions courantes. Mettre en place de nouveaux échanges inter-applicatifs au travers de solutions EAI est très attrayant, cependant prenons garde de ne pas réitérer les faiblesses de nos anciens systèmes. Proposons donc une architecture dans laquelle la sécurité est intégrée comme composante de base, et propose des services compréhensibles par l’utilisateur final : • Authentification L’authentification, forte si possible14, doit avoir lieu au niveau des flux métier, éventuellement au niveau de chaque message du flux. Exemple un flux de synchronisation entre deux progiciels (authentification du flux), un flux de commandes avec un fournisseur (authentification par message). • Gestion des habilitations Ce service répond à la question : le message émis par XX est-il autorisé ? Si oui, est-il conforme en terme de format et de valeurs des paramètres15 ? Là encore, tout l’art de la solution va être de se placer non pas au niveau des messages binaires, mais plutôt au niveau de la description des flux métier. La solution devra gérer un référentiel des émetteurs et destinataires (machines, entités, personnes) et appliquer des Access Control List (ACL) sur les différentes typologies de flux. • Intégrité, Confidentialité et Non-répudiation Ces trois services sont généralement liés, car ils utilisent les mêmes algorithmes cryptographiques. Comme pour l’authentification, il devra être possible selon le besoin de signer ou crypter un flux dans sa globalité, ou de faire de même sur chacun des messages. Au bout du compte, les flux informatiques utilisant ces services pourront être nativement utilisés dans un cadre contractuel. La sécurité est encore de la responsabilité de la couche transport...

Mais arrêtons là notre vision idyllique de la technologie et revenons à la (dure) réalité ! Dans les faits, seule la couche transport MOM propose aujourd’hui des services de sécurité. Cela a pour conséquence que toute la gestion des fonctions décrites plus haut est réalisée au plus bas niveau de l’architecture, s’éloignant de fait d’une gestion de la sécurité orientée métier. Sur ce créneau, des produits existent autour d’IBM MQSeries : Candle MQSecure

14 Les technologies de choix pour ce service et pour les autres sont bien entendues celles de l’Internet, et notamment les certificats X.509 et la cryptographie par clé publique et privée. 15 Exemple : cet ordre d’achat de titres, émis par le courtier XX est valide, mais dépasse le montant des risques alloués pour sa division.

notamment. Ce produit gère l’authentification et l’intégrité/confidentialité des messages et le contrôle d’accès doit être implémenté à la main. Microsoft MSMQ inclut en standard les fonctions d’authentification (mécanisme NT), de contrôle d’accès sur les files d’attente et la confidentialité et l’intégrité des messages.

Figure 21 : La s éc urité : s ep tiè me b riq ue de l’E AI. .. mais gén ér al ement pas la se pti ème merve il le !

Le challenge à relever pour les éditeurs consiste maintenant à “remonter les couches de l’architecture”, pour proposer des solutions simples de sécurité et proches de l’utilisateur : la gestion de la sécurité doit se faire au niveau des flux métier, pas au niveau des transferts de données. Si la simplicité n’est pas là, rien ne sera mis en œuvre. Par expérience, c’est le même constat que l’on fait entre les technologies trop complexes (DCE : sans commentaires..., CORBA : 600 pages de spécifications..., X500...) et celles adoptées par le marché (RACF dans le monde IBM qui a le mérite d’être intégré aux produits de la gamme, SSL pour le Web, S/MIME pour la messagerie, LDAP pour le stockage des certificats X.509 ...)

2.7. Conclusion Il est maintenant possible de représenter l’ensemble des briques techniques d’une offre complète d’EAI :

Fi g ur e 22: L’e nse mble de s briq ues d’ une o ff re d’E AI

Bien entendu, comme les précédents paragraphes l’ont explicité, vous ne trouverez pas sur étagère un produit unique ayant la couverture décrite ici ... il faudra encore vous adresser à plusieurs éditeurs. L'abandon des progiciels de transfert de fichiers au profit des MOM.

Message Broker : un marché parcellaire en cours de maturation.

Cependant, plusieurs grandes tendances se dégagent aujourd’hui : La couche transport migre progressivement d’une solution de transfert de fichiers vers un middleware orienté message. Ces environnements sont les seuls à drainer de l’innovation aujourd’hui, peu d’investissements sont en effet réalisés sur des produits comme CFT et Interpel, Connect Direct ou XCOM. Pour pouvoir conquérir la totalité du marché des échanges asynchrones (ce qui est encore loin d’être le cas), les MOM devront donc combler rapidement la seule lacune qui les différencie de ces progiciels : le transfert de gros volumes16. Parmi ces MOM, le leader incontesté est MQSeries d’IBM (70% de parts de marché). Tibco demeure une offre intéressante, mais c’est surtout du côté de Microsoft que la menace se dessine, dans la mesure où MSMQ est livré de base avec le système d’exploitation Windows2000 ... Au niveau des couches hautes, le marché est bien plus parcellaire. Plusieurs dizaines de produits se positionnent comme des Message Broker (Active Software, Constellar, Level8, IBM/Neon, Software Technologies, Sterling Software, Talarian, Tibco, BEA, TSI, etc.), autant de fournisseurs de connecteurs, et quelques offres de gestion de processus (CrossWorld, Forté, Vitria, etc.). Le marché de l’EAI est encore en pleine construction. Aucune offre ne pouvant tout proposer aujourd’hui, certains acteurs se spécialisent dans des domaines verticaux techniques comme la fourniture de connecteurs progiciels ou par secteur de marché (finance, médical, industrie ou telco). A coup de fusions et d’acquisitions, des leaders commencent néanmoins à se dégager. NEON rachète CAI pour son expertise dans le monde mainframe, ainsi que VIE Systems pour se positionner sur le marché de la santé et de l’industrie. Plus récemment, TSI Software a fusionné avec Braid Systems, un acteur de l’EAI spécialisé sur le marché financier, concurrençant ainsi le fournisseur traditionnel Tibco. Ces alliances sont nombreuses et encore opportunistes. Par exemple, IBM propose à son catalogue Business Integration les produits concurrents de SOPRA et NEON, tout en intégrant Mercator de TSI au niveau de son offre DecisionEdge ! D’autres suivront, et comme nous l’indiquions en début d’ouvrage, les introductions et augmentations de capital au NASDAQ seront les arbitres de ces fusions et rachats. Il est cependant certain qu’un tel regroupement de technologies va dans le sens d’une réponse complète aux besoins clients.

Pour les projets EAI, préférer une approche itérative à l'effet "tunnel".

Les technologies de l’EAI vont permettre aux entreprises de diminuer les coûts d’intégration et d’augmenter considérablement leur capacité de mise en place de nouveaux services. Elles vont donc dans le sens d’une augmentation du Return on Investment (ROI), et de ce que l’on nomme outre-atlantique le Return On Opportunity17 (ROO), à savoir la capacité d’augmenter son volume d’affaires. Cependant, l’EAI est un élément structurant du Système d’Information, il est donc déconseillé de lancer des projets globaux visant à unifier d’une traite l’ensemble des flux de l’entreprise. Ce type de projet se heurtera rapidement à des problèmes de mise en œuvre d’un tel référentiel (qui revient à normer tout ce que manipule le SI...), ou de mise en place d’une nouvelle cellule dans l’organisation (qui revient à transférer des prérogatives d’équipes existantes vers de nouvelles, avec les difficultés que l’on imagine...). Il est souvent préférable d’opter pour une approche opportuniste consistant à relier des groupes d’applications au sein d’un bus puis de l’étendre à de nouvelles applications et à de nouveaux services : gestion de processus, sécurité, reporting avancé, etc.

16 La limitation actuelle tourne autour des 4 Mo pour certains produits (jusqu’à 100 MO pour MQSeries sur certaines plates-formes). Au-delà, des solutions particulières de découpage doivent être mises en œuvre, FTF/MQ de MessageQuest par exemple. 17 C’est ce nouveau critère qui fait que des sociétés fortement déficitaires comme Amazon.com ou Yahoo! sont largement représentées en bourse.

3. Acteurs d u marché Nous proposons dans ce chapitre d’effectuer un tour d’horizon des principaux acteurs du marché de l’EAI. Ce chapitre a été rédigé à partir d’interviews des éditeurs concernés et d’évaluations de leurs produits, soit en interne, soit pour le compte de nos clients. Seuls Active Software et Vitria, qui ne sont pas représentés en France, n’ont pas fait l’objet d’une évaluation détaillée. Avant les synthèses respectives des offres EAI, dressons un diagramme avec : • Sur l’axe des abscisses, le niveau de finition de l’offre. L’éditeur proposet-il un outil intégré, des briques EAI ou un framework sur lequel bâtir des solutions ? • Sur l’axe des ordonnées, le degré de couverture de leur offre EAI actuelle. En outre, des flèches indiquent la trajectoire suivie par l’éditeur et son potentiel d’engagement. Le schéma s’inscrit donc dans le temps et fait notoirement apparaître un regroupement du marché vers des offres globales.

Figure 23 : Positionnement des principaux acteurs du marché de l’EAI

Cette évaluation représente une photo du marché tel qu’OCTO Technology le perçoit en date d’écriture. Elle est donc sujette à certains changements (voire bouleversements !) à moyen terme. Enfin, compte tenu de la fragmentation actuelle du marché, cette liste ne se veut pas exhaustive... l’objectif est avant tout de fournir au lecteur un positionnement relatif des principaux acteurs de ce marché. Pour mieux apprécier cette vision globale, chaque éditeur mentionné fait l’objet d’une fiche descriptive dans les pages qui suivent. Pour chacun d’entre eux, nous structurerons l’exposé en plusieurs points : • Présentation de l’éditeur, analyse financière Chiffre d’Affaire et Résultat Net pour l’année 1998, nombre d’employés, données boursières le cas échéant • Positionnement de l’offre en mettant en évidence les briques supportées dans le schéma général de l’architecture EAI, • Origine du produit et principales caractéristiques, • Perspectives et stratégie de l’éditeur.

3.1. A ctive Software ActiveWorks Integration System www.activesw.com CA / RN : 13,9 M$ / -10,9 M$ Valorisation boursière : 553,7 M$ Références : >80 Employés : 120 Pas présents en France (Allemagne)

Caractéristiques du produit • L’offre ActiveWorks s’articule autour d’un gestionnaire d’évènements, l’Information Broker. Celui-ci réalise le transport et le routage des messages, et supporte le routage sur contenu. Un bon support de la sécurité est offert, au travers de la notion de rôles (client group) et d’autorisation, ainsi que l’utilisation de SSL (utilisation des outils SecureWeb de Terisa Systems). • Le module ActiveWorks Designer autorise le design graphique de processus au standard UML. Ces processus sont modélisés au travers de diagrammes de séquences d’évènements, et de diagrammes d’activité. Il est ensuite possible de les tester directement, avant la phase de génération de code Java à destination de broker. • Ce code Java généré peut être aussi créé à la main par l’utilisation du module Integration Logic Agent, il permettra donc d’étendre les fonctionnalités du broker. Le Business Rule Agent permet d’écrire des règles complexes au travers d’un moteur d’inférence (système expert). Enfin le Data Transformation Agent permet de créer graphiquement des transformations entre évènements de différents formats, c’est lui qui est responsable des transformations EDI ou SAP IDoc par exemple. • L’Event Type Editor permet classiquement des définir graphiquement les formats des évènements, qu’il gère dans un référentiel. A noter la possibilité d’utiliser des plug-in spécifiques pour faciliter l’utilisation de certains adaptateurs. • Ces adaptateurs, les Dynamic Adapters, permettent une connectivité middleware : fichiers, SGBDR, CICS, MQSeries et vers des applicatifs : SAP, Clarify, PeopleSoft, Siebel, Vantive, Pivotal, etc. A noter la forte politique de partenariats d’Active, qui permet d’étoffer rapidement ce catalogue • La configuration du réseau Active et la gestion de la sécurité sont confiés au module ActiveWorks Manager. Bien que le broker soit compatible SNMP (permettant de le connecter à un framework d’administration plus global, rare !), ActiveWorks Monitor propose du tracking d’évènements dans le bus. • Enfin, en plus de ses activité d’éditeurs, Active propose de structurer les projets de mise en œuvre de son produit au travers d’une méthodologie : Active Integration Methodology (AIM)

Forces

Faiblesses

• Forte politique de partenariats (HP, Oracle, Sun/Netscape, Vantive, Clarify, Cisco, intégrateurs, etc.) permettant notamment d’offrir de nombreux adaptateurs

• Pas de modélisation réelle de processus, il faut passer par les différents modules du système : Designer, Broker et Agents (code Java). • Taille de l’éditeur

• Offre autonome, fondée sur bus sécurisé

Positionnement et Stratégie • Projets d’intégration de progiciels (bibliothèques d’adaptateurs) • Optimisation du produit pour une meilleure montée en charge

Fi gu re 24 : Ac tive Wo rks In tegra tio n Syst em (so urce Ac tive So ftwa re)

3.2. BEA Systems elink Family www.beasys.com CA / RN : 351M$ / -16,2 M$ Valorisation boursière : 2 360 M$ Références : 3 aux Etats-Unis et en Afrique du Sud, une vingtaine de projets en cours (2500 pour le reste de l’offre BEA) Employés : 1500 Présence en France : OUI

Caractéristiques du produit • BEA a acquis ses lettres de noblesse grâce au moniteur transactionnel Tuxedo, c’est sur ce produit, et sur son moniteur asynchrone /Q (beaucoup moins répandu ...) que se fonde l’offre eLink Platform. • eLink Platform est l’assemblage de plusieurs technologies, d’origine BEA en couches basse, puis TSI Mercator comme moteur de transformation (Data Integration Option) et Xerox InConcert (Business Process Option) comme gestionnaire de flux, ces offres étant “OEMisées” et packagées comme des modules optionnels. • Le transport de choix est Tuxedo, c’est à dire un mode synchrone. /Q peut être utilisé, mais explicitement par API : TMQFORWARD() depuis la transaction. C’est le cas pour l’adaptateur SAP, qui requiert une garantie de délivraison, et où tous les IDoc transitant par Tuxedo sont sauvegardés dans des queues /Q. • Mercator est un des Message Broker leader du marché. Il propose toutes les fonctions standards attendues dans ce type de produits, y compris la capacité d’enchaîner des traitements (ici, seul le moteur de transformation est utilisé). Les connecteurs de Mercator (ERP, finance et commerce électronique) ne sont pas utilisés, BEA développe ses propres interfaces, aujourd’hui SAP et PeopleSoft ; Vantive, Kenan et Clarify prévus pour la fin de l’année. • Le moteur de workflow, InConcert, permet de modéliser graphiquement des flux complexes, en revanche il n’est pas encore intégré au reste de l’environnement. L’offre pourrait également héberger un second moteur, celui de HP (changeEngine). • Ces différents partenariats ont permis à BEA de se constituer rapidement une offre qui lui permet d’occuper le terrain. • Il peut y avoir nécessité d’effectuer un travail d’intégration des différents modules, notamment en terme d’outillage de développement et de référentiel, puis en aval en ce qui concerne l’administration et la sécurisation de l’ensemble.

Forces

Faiblesses

• Segment stratégique pour BEA qui doit faire face à IBM pour couvrir une gamme qui va du serveur d’application à l’EAI

• Offre récente, susceptible de changements

• Capitalisation sur le moniteur transactionnel Tuxedo

• Offre orientée synchrone, et nécessitant un déploiement lourd de Tuxedo. L’asynchrone à travers /Q peut être utilisé, mais nécessite l'écriture de code.

Positionnement et Stratégie • A l’image du rachat de WebLogic pour asseoir sa présence sur le marché des serveurs d’applications EJB, BEA poursuit une politique de croissance externe... pour l’instant uniquement via des partenariats (TSI, Xerox, HP) • BEA croit au développement d’une offre EAI basée sur des flux importants supportant différents protocoles (synchrone, asynchrone, publish/subscribe, …) nécessitant de réels projets d’intégration. • Le futur de l’offre passera donc par une clarification de la stratégie, ce qui sur ce marché signifie l’acquisition des technologies nécessaires, et leur fusion au sein d’un produit.

Fi gure 25 : B EA e Lin k Sol ut ion (sou rce BEA Sy stems)

3.3. CrossWorlds CrossWorlds www.crossworlds.com CA / RN : 9M$ / NC Références : >30 Employés : >200 Présence en France : antenne commerciale et consultants

Caractéristiques du produit • Crossworlds est né en 1997 de l’idée qu’il y avait autant de valeur ajoutée dans la mise en œuvre de progiciels (ERP et CRM notamment) que dans les flux qu’ils généraient. • La société a donc développé un système de gestion de ces flux, à un niveau très élevé, et fondé sur un standard du monde objet : la méthode de conception UML. • Le produit met en œuvre le concept de collaboration qui définit un flux entre N applications. Un tel flux peut être complexe, le moteur se chargeant de la gestion des transactions longues. • Chaque collaboration manipule des objets métier définis en UML et représentant des données issues des applications cibles. Un objet métier s’instancie sur un connecteur spécifique. Ces connecteurs sont relativement nombreux : ERP, CRM, SCM, etc. bien que l’éditeur ne communique pas précisément leur niveau de support. • Le point intéressant est que les règles de flux sont définies au niveau des objets métier, c’est à dire à un niveau d’abstraction indépendant des applications cibles. Ainsi, ces collaborations sont potentiellement réutilisables dans différents environnements. • D’un point de vue technique, le produit se présente comme l’assemblage de diverses technologies : MQSeries et l’ORB Visibroker en couche basses, TSI Mercator ou Neon Formatter comme moteur de transformation, et enfin Crossworld Interchange Server comme moteur du tout.

Forces

Faiblesses

• “Beauté” du concept

• Difficulté d’implantation, le produit et le type de projet qu’il génère représentent des coûts élevés

• La valeur ajoutée du produit se situe beaucoup dans l’expertise cumulée autour des progiciels (connecteurs) et des différentes collaborations déjà écrites.

• Faible intégration de l’ensemble des technologies mises en œuvre, notamment en termes d’exploitation.

• Partenariat avec IBM.

Positionnement et Stratégie • Tout d’abord, la société Crossworlds devrait s’introduire en bourse cette année. Compte tenu du bon niveau de communication sur le produit et ses dirigeants, cette introduction devrait s’avérer fructueuse, et donc d’une part dégager des liquidités, et d’autre part éloigner (un peu) les menaces de rachat. • Au vu de la taille minimale d’un projet CrossWorlds, et donc du caractère structurant qu’il revêt, la société devra montrer son aptitude à durer, soit à l’aide de partenariats du type IBM, soit par sa capitalisation boursière ... ou soit par un rachat. • Crossworlds devrait par ailleurs poursuivre ses investissements au niveau des couches “hautes” : nouveaux connecteurs, solutions packagées d’intégration, etc.

F ig ur e 26: Archit ec tu re Cr ossW or ld s (so ur ce Cros sWorlds )

3.4. Forté Forté Fusion www.forte.com CA / RN : 83 M$ / (0,5 M$) Valorisation boursière à 567 M$, Rachat récent par Sun Références : 10 environ, aux Etats-Unix (telcos) Employés : 410 Présence en France : antenne commerciale et consultants

Caractéristiques du produit • Depuis 1991, Forté propose des solutions complètes de développement. Fondé sur le langage Tool et un middleware spécifique, l’éditeur fut un des premiers à proposer des solutions en architectures 3-tiers. • Dans la logique de développement autour de ce produit, un premier gestionnaire de Workflow, Forté Conductor, est mis au catalogue en 1997. Ce produit permet de décrire graphiquement un diagramme de séquence, et de générer du Tool intégrant les différents traitements dans un processus. • Fusion est ensuite le packaging de Conductor, avec un moteur de règles, et des adaptateurs vers du middleware (MQSeries, bases de données, Corba, RMI et DCOM) et des applicatifs (SAP, Siebel, Vantive, PeopleSoft et Baan). • Comme le montre le schéma d’architecture fourni par l’éditeur, de nouveaux connecteurs pourront être développés à l’aide d’un kit de développement C++ ou Tool. Ils utilisent HTTP et XML comme unique mode de communication. • XML est le fondement de l’outil. Le moteur de règles utilise des fichiers XSL pour les transformations et le routage. Aujourd’hui l’environnement ne permet pas d’éditer ces règles ni de les intégrer dans le gestionnaire de workflow. Il faudra donc d’une part décrire à la main les règles de routage ou de transformation dans des fichiers XSL, et d’autre part faire manuellement le mapping entre les processus et les objets qu’ils manipulent, et les messages XML qui transitent effectivement. • Par défaut, toute l’interopérabilité se fonde sur du middleware synchrone (HTTP), le moteur ne prend pas à sa charge les éventuelles indisponibilités des applications participantes. Cette gestion d’erreur devra être prise en compte au niveau des processus (retry sur chaque tâche) • Le suivi d’exploitation des flux n’est pas disponible en standard. Cependant Conductor peut externaliser sa trace dans une base de données, consultable ensuite par une application spécifique

Forces

Faiblesses

• L’outil autorise une approche développement (intégration avec le reste de la gamme, Forté et SynerJ) et une approche intégration d’application, ce de manière autonome (middlewares intégrés), et à l’aide d’une gestion de processus.

• L’intégration de Conductor et Fusion reste à faire entre le gestionnaire de formats et de règles et le workflow

• Le rachat par Sun devrait pérenniser la gamme Fusion, seule brique EAI disponible dans son nouveau catalogue... à suivre !

• L’interopérabilité synchrone nécessite la prise en compte de problématiques techniques dans les processus

• Quelques connecteurs... mais un seul format (Swift), de fait, par l’absence d’un réel moteur de transformation (fichiers XSL à éditer manuellement)

• Pas d’outils d’exploitation

Positionnement et Stratégie • L’offre Fusion ne sera réellement crédible que si elle fait partie des priorités de Sun en termes d’investissements et de marketing. Ces informations seront disponibles d’ici à la fin de l’année. • Développement de l’offre (moteur de transformation, référentiel, intégration du workflow), et intégration avec le reste de la gamme Sun : iPplanet, etc.

F ig ur e 27 : Fo rté Fu sio n En te rpri se App li ca tion Integ rat io n (s ou rce Fo rté )

3.5. IBM MQSeries Family MQSeries, MQSeries Integrator, MQWorkflow www.ibm.com CA / RN : 11 900 M$ (Software) / NC Références : >5000 pour MQSeries, faible encore pour le reste de la gamme Employés : 21 590 (Software) 200 pour MQSeries Présence en France : 340 personnes hors support et services

Caractéristiques du produit • IBM est venu sur le marché de l’EAI à partir de son offre middleware MQSeries, aujourd’hui leader sur le marché du MOM. • Conscient de la nécessité de proposer une offre de plus haut niveau, l’éditeur crée une branche Business Integration, et étoffe sa gamme par de nombreux rachats et alliances technologiques. • C’est ainsi que le Message Broker MQSI provient en fait de la société NEON qui offre maintenant des produits complémentaires autour de ce message broker (NEON Track pour le suivi des flux, Enterprise Adapter pour les connecteurs base de données, fichiers, etc., ainsi que des solutions verticales dans la finance, la santé ou les telcos). MQSI est aujourd’hui propriété d’IBM, qui en délègue à NEON le développement du moteur de règles et de transformation. • En Europe, IBM propose une alternative entre MQSI et l’offre Bus Applicatif de Sopra. Idem pour la gestion des flux métiers, où le client choisira entre le produit maison MQWorkflow (anciennement FlowMark) et le partenariat avec l’éditeur CrossWorld... En outre, A&P de Sopra est la seule offre de suivi de flux au catalogue IBM, en concurrence donc avec NeonTrack. • Le Message Broker repose sur une base de données jouant le rôle de référentiel des données et formats, facilitant ainsi la gestion des règles de transformation. • Le gestionnaire de flux utilise également cette base pour ses règles de routage, qui peuvent être basées sur le contenu. Ce moteur fonctionne en “fire and forget”, c’est à dire par déclenchement de règles sur l’arrivée d’un message. Il adresse donc de manière très performante une logique 1 vers N mais ne permet pas de gérer simplement des flux N vers M. • Les connecteurs sont tous issus des bibliothèques Neon, l’offre est aujourd’hui centrée sur quelques progiciels (SAP, PeopleSoft, Siebel, I2, etc.), la finance (Swift, Oasys et FIX) et l’EDI. • A noter le support de flux de type terminaux interactifs (3270, 5250, VT, etc.) par le produit Neon Adapter for Terminals.

Forces

Faiblesses

• Base installée MQSeries comme levier de l’offre

• Pas de fusion simple multi-source

• Référentiel des formats et règles • Gamme complète, par produits compagnons chez des tiers • Pérennité

• Produits très orientés MQSeries en standard, faible ouverture vers d’autres systèmes • Instabilité potentielle des partenariats à moyen terme.

Positionnement et Stratégie • Offre complète construite à partir de briques d’origines diverses (IBM, Neon, Crossworld, Candle pour l’administration MQSeries, Sopra, etc.) • Axe stratégique chez IBM, garant d’une pérennité de la gamme. En revanche, les nombreux accords qui fondent aujourd’hui l’offre sont susceptibles d’évoluer, impactant de fait la portabilité des produits sur le long terme.

Figu re 2 8: M QS eries a u c œu r d u B usi ness in te gra ti on (so ur c e IBM)

3.6. Microsoft BizTalk Server MSMQ Babylon COM+ www.microsoft.com CA / RN : 19 000 M$ / 7 000 M$ Valorisation boursière 500 000 M$ Références : 0 Employés : 27 000 Présence en France : OUI

Caractéristiques du produit • Biztalk Server est l’héritier de Commerce Server, la plate-forme de commerce électronique de Microsoft. La future offre s’architecture autour du moteur qui s’appuie sur un référentiel et des connecteurs. • Les connecteurs permettent de recevoir et d’envoyer des messages : connecteurs techniques SMTP, HTTP, MSMQ, ADO (SGBDR), etc. A noter également un connecteur pour SAP. • Le référentiel contient : ■

■

■

la description de la structure de l’ensemble des messages (les schémas XML) au format XML. les règles de transformation syntaxiques et sémantiques des schémas entre eux (stockés au format XSL : eXentsible Stylesheet Language). Les règles de routage et de workflow à appliquer lorsqu’un message arrive : c’est le concept de “pipeline”, un ensemble de composants ActiveX qui s’enchaînent de manière séquentielle pour mener à bien l’ensemble des opérations à effectuer sur un message. Ces composants pipeline pourront être développés à l’aide d’add-in (wizard) dans les outils de développement de la gamme Visual Studio.

• L’architecture interne de Biztalk Server repose entièrement sur la plateforme Windows2000 et sur DNA : le serveur d’applications MTS, le serveur Web IIS et le MOM MSMQ. • Biztalk Server permet de gérer le routage en fonction du contenu du message, ainsi que la prioritisation des messages. Ce dernier point permet d’avoir un fonctionnement quasi-synchrone pour les messages les plus importants. • En terme de sécurité, Biztalk Server supporte l’encryption de tous les messages, le support de SSL et les certificats à clé publique intégrés à Windows 2000. La sécurité applicative repose sur la notion de rôle déjà existante dans MTS. • En terme d’outils, BizTalk fournira un éditeur graphique de schémas XML (Biztalk Editor), ainsi qu’un outil de mapping : Biztalk Mapper qui permettra d’éditer les règles de transformation des schémas XML (au format XSL). • Les formats supportés en standard seront XML bien sûr (XML Data et DTD), l’EDI (X.12 et EDIFACT), et SAP Idoc. • L’administration du serveur se fera par l’intermédiaire de la MMC (Microsoft Management Console). • Biztalk Server fournit également des fonctions d’archivage et d’analyse des flux de messages échangés au travers de l’outil DTA (Document Tracking and Activity).

Forces

Faiblesses

• Basé entièrement sur XML et sur les pro- • L’offre n’existe pas encore et a beautocoles Internet (SMTP, HTTP, SSL, etc.) coup de retard sur la concurrence, on ne connaît pas encore la réelle capa• Intégration à la plate-forme Windows cité du moteur de transformation ni de 2000 : sécurité, administration, DNA la gestion de pipeline • Pérennité de l’offre • Pas de réelle gestion de processus • Repose sur des outils et langages de prévue développement très répandus (Script, • Peu de connecteurs prévus Visual Studio)

Positionnement et Stratégie • BizTalk Server est la nouvelle offre Microsoft en terme de Message Broker, avec un positionnement stratégique double : 1) Le commerce Electronique B to B : offrir une solution d’interopérabilité entre entreprises via XML et Internet entre système d’informations hétérogènes 2) Interopérabilité inter-applications au sein d’une même entreprise : intégrer les différentes sources de données, applications et progiciels d’une entreprise via XML. ■

■

• Pour soutenir ce positionnement (et surtout occuper le terrain !), Microsoft a lancé l’initiative BizTalk (www.biztalk.org) qui vise à fusionner l’ensemble des initiatives métiers de Microsoft (DNAfs pour la banque, ObjX pour la santé, ainsi que la communication inter-ERP) en vue de définir un ensemble de schémas XML standardisés et librement accessibles sur Internet. Les définitions de ces schémas s’appuieront en partie sur une simplification de la norme EDI existante et impliquent un nombre important de partenaires (SAP, Baan ou PeopleSoft par exemple) et de clients. Dans ce schéma, les ERP fourniront les connecteurs techniques (AIC : Application Integration Connector), les schémas XML et les règles de mapping (XSL) avec leurs types de données. • Si Microsoft réussi son pari, il aura réussi à modéliser l’équivalent des objets métier ERP présents dans CrossWorlds. • A terme, Biztalk Server devrait servir également de fondation pour MSN, qui est en train de devenir le portail B2B et B2C de Microsoft et de rassembler acheteurs et vendeurs échangeant leurs ordres et commandes. Ce positionnement stratégique s’apparente à l’offre MySAP ...

Fig ure 29 : Micro so ft BizT alk (sour ce M ic ros oft)

3.7. New Era of Networks, NEON MQSeries Integrator Enterprise ProcessExecutive E-Biz Integrator www.neonsoft.com CA / RN : 22,3 M$ / 3,17 M$ Valorisation boursière : 248 M$ Références : >800 Employés : 1000 Présence en France : antenne commerciale et cellule de consultants

Caractéristiques du produit • NEON MQSeries Integrator est l’un des produits principaux de NEON. C’est un Message Broker doté d’un référentiel SGBDR et fonctionnant sur un MOM, MQSeries. NEON propose également son propre transport, NEON EMQ (Extended Messaging and Queuing), et distribue alors son offre sous l’appellation NEONet. • Le module de formatage emploie une technologie brevetée lui permettant de garantir des temps de réponse stables, quelque soit le nombre de règles, de façon similaire à la gestion d’un index dans une base de données. • Le moteur de règles fonctionne en mode “fire and forget” sur des flux de messages de type 1 vers n. Pour la collection de message (n vers 1 et n vers m), NEONadapter for Protocols gère la collecte de messages en amont du broker. • NEON a réussi à soutenir une croissance externe relativement élevée, lui permettant d’acquérir des technologies tierces (CAI, VIE Systems, Convoy, MicroScript, etc.) qu’elle intègre à son catalogue, ainsi que des sociétés d’ingénierie (SLI). • L’offre, initialement issue du monde la finance (Swift, FIX, NEON Trading System, Rapport, etc.), a donc pu se consolider autour de nombreux formats : EDI, XML, SAP, PeopleSoft, Siebel, i2, etc. et de connecteurs de protocoles : NEON Enterprise Adapter pour les modes fichiers et base de données, NEONadapter for Protocols pour les passerelles de transport, NEONadapter for Terminal pour l’intégration “non-intrusive” en mode revamping, etc. • L’exploitation est confiée sur le plan de plan du suivi des messages à NEONtrack qui supporte aussi bien MQSeries que NEON EMQ. • Pour offrir des fonctionnalités évoluées de gestion de flux et une meilleure intégration de l’offre, NEON a annoncé la sortie de E-Biz Integrator, qui consolidera dans un même produit Enterprise Process Executive (le moteur de gestion de processus métier), MQSI, NEON Web (ex produit de CAI, connexion aux serveurs d’application et serveurs Web) et certains formats (XML, EDI). • La prochaine étape consistera à unifier l’ensemble de cette gamme dans un produit unique OpenBroker. Cette version permettra notamment d’intégrer nativement d’autres transports que MQSeries et EMQ (MSMQ et autres middlewares synchrones ou asynchrones).

Forces

Faiblesses

• Offre complète, grâce aux différents produits de la gamme

• OpenBroker permettra une meilleure intégration des flux autres que messages MQSeries et EMQ

• Le broker est bâti sur un référentiel • Dynamique de l’éditeur, malgré les récents incidents du NASDAQ • Références nombreuses dans la finance, dans une moindre mesure chez les telcos et dans l’industrie/distribution

• Jeunesse du produit de gestion de processus (EPE), permettant de créer des flux complexes.

Positionnement et Stratégie • Neon va continuer à revendre son offre soit directement, soit au travers d’accords OEM, comme ceux déjà passés avec IBM ou Crossworlds. • Par ailleurs, l’offre va continuer à évoluer, d’une part sur le plan architectural (OpenBroker, NEON Common Standard Architecture qui intègre NEON Impact et NEONet), et d’autre part avec l’arrivée de solutions adaptées à des environnements métier (finance bien sûr, mais aussi telco, industrie, etc.)

Fi gu re 3 0: NE ON Fo rmat er e t NEON Ru ler (so urc e NEON )

3.8. Softwa re Technologies Corporation e*Gate www.stc.com CA / RN : 37,5 M$ / NC Références : >1000 Employés : 385 Présence en France : filiale commerciale

Caractéristiques du produit • e*Gate est un moteur d’EAI historiquement issu du milieu hospitalier. Doté de très nombreuses références dans ce domaine, l’éditeur s’ouvre aujourd’hui plus largement au monde de l’industrie et de la finance. • L’offre STC s’articule donc autour du moteur de transformation et de routage, incluant son propre transport sécurisé ainsi que des connecteurs de base. • Le moteur de transformation permet de traiter la plupart des cas standards, pour des transformations avancées, un langage interne (le monk) est utilisé, donc sans nécessité de bibliothèques externes en C. • Le moteur se connecte aux différentes cibles du SI au travers de e*Ways, celles-ci sont de différents types : DART pour les bases de données, MQSeries, SAP, PeopleSoft, Siebel, Clarify, Swift, Kondor+, HL7, HTTP, ScreenScripter, X.12, EDIFACT, XML, etc. • Un des aspects particuliers du produit concerne le nombre de ces passerelles : plus de 500 e*Ways ont été mises en œuvre, sur tous types de plates-formes et applicatifs. • Cela ne signifie pas pour autant que STC dispose du plus large catalogue de connecteurs, mais dénote plutôt la simplicité de mise en œuvre de cellesci, une e*Way simple (COM client) pouvant être développée très simplement dans tous types d’environnement (TCP/IP, SNA, IPX, DecNet,etc.) • Le produit Universal Index permet de gérer des tables de cross-références de manière intégrée au moteur. • L’outil de suivi inclus dans e*Gate couplé au produit Alert Notifier, qui permet de diriger des évènements d’exploitation vers une base de données, permettent un suivi d’exploitation global, jusqu’aux e*Ways • Enfin, STC a réalisé pour un de ses clients une solution complète dans le monde dentaire, DataDental : suivi de dossier, paiements, etc. • La nouvelle mouture du produit, e*Gate 4.0, est prévue pour le 1er novembre 1999. Elle inclut notamment un moteur de gestion de flux, un référentiel centralisé autorisant une architecture distribuée s’appuyant sur un transport en mode publish/subscribe, et une intégration plus fine de MQSeries.

Forces

Faiblesses

• Offre pragmatique et autonome

• Cohabitation de plusieurs technolo gies, Java, Windows et X

• Nombreuses références, y compris sur de fortes volumétries • Facilité d’intégration de connecteurs spécifiques • EGate 4 augmente notoirement les capacités de l’outil pour les architectures complexes.

Positionnement et Stratégie • L’offre eGate s’ouvre plus simplement à de nouveaux transports (MQSeries notamment), mais demeurera une offre autonome par essence. • La société STC devrait s’introduire en bourse cette année, ce qui lui procurera une marge de manœuvre intéressante en termes d’investissements. En effet, le produit étant relativement complet aujourd’hui, cette somme pourra financer un meilleur marketing. • L’axe de développement de STC est aujourd’hui de croître en dehors du milieu hospitalier : finance, industrie et opérateurs télécom.

F ig ur e 31 : e *Gate (ex D at aG at e) , l a sol utio n d’E AI de ST C (so ur ce S TC)

3.9. Sopra Bus Applicatif A&P, Règles Du Jeux, XFB www.sopra.com CA / RN : 1 857 MF / 107 MF Références : plusieurs milliers pour RdJ, quelques dizaines pour A&P Employés : 3400 Présence en France : 350 personnes dans la division Progiciels Outils

Caractéristiques du produit • SOPRA est le premier éditeur Français avec un CA de 700 MF (1.800 MF au total pour la société en ajoutant le CA de la division Service) qui a organisé son activité édition en 2 branches : une branche métier qui offre des progiciels verticaux pour différents secteurs d’activité, essentiellement Banque (progiciel de gestion des crédits), RH (logiciel de Paie) et Immobilier une direction Progiciels Outils en charge des progiciels horizontaux qui s’est vu accrédité de la 3ième place mondiale dans le (petit) monde de l’EAI par la dernière étude du GIGA Group, et la première en Europe selon le Gartner. ■

■

• SOPRA est un acteur historique de la gestion des flux en entreprise. Les rachats des sociétés Credintrans (CFT) et Pelican (InterPel) lui fournissent aujourd’hui environ 80% des parts de marché du transfert de fichier en France, cette offre est regoupée sous le terme eXtended File Broker : XFB. • Pour le formatage, le produit phare Règles du Jeu est disponible depuis plus de 10 ans, et en production dans de très nombreux environnements, notamment en gestion comptable (un module est dédié à cette fonction) • Ce produit est par ailleurs au catalogue d’IBM Europe car il peut exploiter dans sa dernière version le middleware MQSeries. Il est donc en concurrence directe avec le produit MQSI (au catalogue IBM... US). SOPRA a arrêté le développement de son MOM propriétaire, Interset, dont il n’assure plus que la maintenance. • Enfin, SOPRA propose depuis 2 ans une nouvelle brique à son offre d’urbanisation des SI : A&P. Ce produit offre des fonctions de routage simple, de cartographie des flux, et de suivi métier (module A&P Tracker). La fonction de routage est implémentée par des règles qui examinent le type du message comme élément de décision. Les flux sont marqués par les agents A&P, ce n’est donc pas un routage basé sur le contenu du message. Pour cela, il faudra rediriger le flux vers RDJ. Ce suivi métier impose alors l’utilisation des A&P Agents et leur API sur les plates-formes cibles. L’A&P Agent pouvant utiliser indifféremment un transport Transfert de fichiers, un MOM ou une messagerie X.400. ■

■

• Ces solutions sont indépendantes les unes des autres mais peuvent évidemment se combiner pour couvrir l’ensemble des besoins d’échange de l’entreprise : transfert de fichier, outils de translation (formatage) ou Message Broker. L’offre globale est packagée sous l’appellation Bus Applicatif. • Les principales références d’A&P sont PSA, Natexis, UNEDIC, ou EDF. Elles sont nettement plus nombreuses pour RDJ (plus de 500 en Europe) et XFB (4000 dans 80 pays).

Forces

Faiblesses

• Précurseur sur le thème de l’Urbanisation, avec des solutions proches du besoin utilisateur : suivi métier et gestion comptable notamment

• Peu de dynamique sur le produit : pas de formats standards (ERP, CRM, XML, etc.) hormis l’EDI,

• Base RDJ et transferts de fichiers importante en Europe, • Partenariat IBM, mais à l’échelle Européenne uniquement.

• Produit ancien, éloigné des nouvelles technologies : HTTP, XML, MSMQ, etc. • Pas encore de réelle intégration entre A&P et Règle du Jeux

Positionnement et Stratégie • Sopra communique peu sur les évolutions de son produit, qui sont essentiellement liées aux besoins de ses clients. La société doit néanmoins annoncer au plan Europe ses nouvelles offres (dont XML, formats ERP et package A&P + RDJ) début novembre 1999 (IT-Expo du Gartner Group). • Les accords avec IBM peuvent aider à la pénétration de la solution, dans un périmètre Français compte tenu du marketing actuel.

Fi gure 3 2 : B us App lic ati f (sou rce Sopra )

3.10. Template Enterprise Integration Template (EIT) www.template.com CA / RN : 42,6 M$ / NC Références : plus de 300 Employés : 350 (la moitié en Europe) Présence en France : antenne commerciale et une dizaine de consultants

Caractéristiques du produit • Template Software est une société spécialisée dans la réalisation et la commercialisation de composants logiciels réutilisables basés sur une technologie “orientée objet”. • EIT (Enterprise Integration Template) représente l’offre EAI de Template et peut s’utiliser de façon autonome pour satisfaire à des besoins de routage simple des données entre applications et progiciels, ou s’utiliser de manière intégrée avec les autres produits de la gamme (Workflow Template, Business Process Template ou Process Monitor Component). • Bâti sur SNAP, la plate-forme de développement commune à l’ensemble des outils, EIT permet une vue intégrée du SI de l’entreprise par l’utilisation des 3 composants suivants : Le modèle objet opérationnel : ce modèle décrit les objets métiers et les flux d’information décrivant l’organisation d’une entreprise, EIT gère un référentiel de ces données Les services de connexion aux ressources : fournissent à EIT le moyen de se connecter aux sources de données et aux applications pour alimenter le Modèle Objet Opérationnel et gérer la persistance des informations Les services de distributions : ces services prennent en charge la propagation des informations et des événements dans l’entreprise ainsi que de la délivrance des réponses aux requêtes des applications clientes. Cette couche de transport s’apparente à un ORB permettant la communication entre composants, au travers du protocole propriétaire SNAP ou de COM ou CORBA. ■

■

■

• Toute nouvelle application peut ensuite facilement se connecter au serveur EIT et bénéficier des objets déjà modélisés pour échanger de l’information avec le reste du SI. • Template dispose de nombreux connecteurs, techniques : IMS/CICS, MQSeries, Tuxedo, SGBDR, XML, etc. et applicatifs : SAP, PeopleSoft, Siebel, Vantive, Kenan, etc.

Forces

Faiblesses

• Savoir faire technique éprouvé

• Maîtrise nécessaire de la fondation SNAP et des concepts objets

• Modèle unifié des objets de l’entreprise • Offre verticale dans le domaine des télécommunications.

• Positionnement floue de EIT entre une plate-forme de développement (voire une serveur d’application) et un produit d’intégration.

Positionnement et Stratégie • Template offre avec SNAP, EIT et les autres modules (WFT, BPT...) un AGL complet, voire complexe, couvrant des besoins du monde EAI (routage, connexion directe avec les progiciels...). • EIT trouve naturellement sa place dans les projets d’intégration pour lesquels l’effort de modélisation et de développement en environnement objet représente une part importante. • De fournisseur de solution de développement, Template tente de se repositionner, ainsi que quelques-uns de ses concurrents (Forté, Compuware...), comme un fournisseur de solution globale d’interopérabilité.

Fi gu re 33 : E IT (so urc eTemp late)

3.11. Tibco TIB/ActiveEnterprise : TIB/RendezVous, TIB/MessageBroker, TIB/Adapters www.tibco.com CA / RN : 186M$ / NC Références : plusieurs milliers, mais avec des parties de l’offre Employés : >800 Présence en France : antenne commerciale et consultants Caractéristiques du produit • Depuis 1980 et l’informatisation de Wall Street avec la technologie de publish/subscribe TIB/Rendez-vous, Tibco a élargi sa gamme pour couvrir les différentes briques de l’EAI • La gamme TIB/Adapters fournit des passerelles techniques (MQSeries, MSMQ, SGBDR, Web, etc.) et vers des progiciels : SAP, PeopleSoft, Vantive, Siebel et Clarify notamment. • Le gestionnaire de flux et de transformation, TIB/Message Broker, est une brique récente sans référence à l’heure actuelle. • L’administration et l’exploitation d’un réseau Tibco et des adaptateurs est assurée par l’outil TIB/Hawk. • A l’image de NEON, mais ici avec le soutien direct de la maison mère Reuters, Tibco propose des solutions clés en main pour la finance, et notamment les salles de marché au travers de la gamme Financial Enterprise Application Integration • Tibco fournit également des solutions de haut niveau pour la gestion de portails (TIB/Portails, utilisé Yahoo!, Altavista, Netcenter et bientôt mySAP.com par exemple) et réseau d’information à valeur ajoutée (Tibco.net)

Forces

Faiblesses

• Editeur spécialisé sur le secteur depuis 1980,

• Pas de Message Broker réel dans l’offre aujourd’hui

• Son assise garantit une dynamique autour de son offre : passerelles et offres packagées notamment, • Fourniture de solutions clé en main : finance et eBusines

Positionnement et Stratégie • Fourniture de solutions totalement intégrées dans la finance, avec l’appui de la maison mère Reuters, • Fourniture de solutions clés en main pour les grands sites portails, • Tibco devra également se doter d’un réel Message Broker ou afficher un partenariat clair avec un des éditeurs leader sur ce créneau.

F ig ur e 34 : T ib/ Ac tive Ent er pr ise (s ourceT ibc o)

3.12. TSI Software Mercator Suite Mercator Integration Server www.tsisoft.com CA / RN : 67,9 M$ / 0,3 M$ Valorisation boursière 653 M$ Références : plusieurs centaines Employés : >300 Présence en France : antenne commerciale

Caractéristiques du produit • Mercator est le produit phare de la société TSI. Constitué de 4 éditeurs graphiques différents qui permettent respectivement de modéliser les formats (Type Tree Editor) ou de les importer (Idoc, XML), de générer automatiquement des formats à partir de tables ou de procédures stockées (Database Editor), de mettre en correspondance ces flux, après transformation éventuelle, entre différentes sources d’entrée et de sortie (Map Editor), de créer de véritables flux d’information métiers (System Editor), c’est à dire d’enchaîner des maps. ■

■

■

■

• A ces modules GUI, viennent se rajouter le moteur du Message Broker à proprement parlé (Command Engine), associé au Launcher Module qui permettra de déclencher le moteur suite à l’apparition d’un événement (dépôt d’un message, de plusieurs fichiers, timer, etc.). Cette approche est intéressante car elle permet nativement de gérer des flux complexes en entrée. • L’offre ne dispose pas de transport spécifique et peut donc s’appuyer indifféremment sur MQseries, MSMQ, Tuxedo ou /Q, Oracle AQ ou Tibco RendezVous. Des passerelles existent également vers les principaux SGBDR • Des connecteurs applicatifs existent dans trois domaines : les ERP (Mercator for R/3, for PeopleSoft) la finance (Mercator FS), avec les formats FIX, SWIFT/ISITC, ACH, BAI, et ETC. Mercator propose également une solution packagée à l’aide de progiciels de gestion de transactions et de paiements. le commerce électronique (Mercator for EC) avec le support de l’EDI (X.12 et EDIFACT), HL7 et XML ■

■

■

• D’un point de vue exploitation, TSI propose l’outil Monitoring Tool qui offre un suivi temps réel de l’exécution des maps, ainsi que l’affichage de diverses statistiques de base (nombre de maps déclenchées depuis le lancement du moteur, le nombre de maps en erreur, en attente de déclenchement, etc.)

Forces

Faiblesses

• Prise en main aisée

• Pas de référentiel, nécessité de gérer manuellement l’ensemble des fichiers décrivant les méta-données,

• Ouverture : nombreuses passerelles techniques vers les middlewares du marché • Qualité du moteur de routage (gestion du N vers M) et de transformation

• SAP est à la fois une force et une faiblesse, il phagocyte l’image du produit.

• Gestion de processus nativement dans le produit (System Editor) • Nombreuses références en intégration SAP

Positionnement et Stratégie • Mercator se retrouve assez souvent intégré, comme brique de transformation, dans des offres plus globale d’autres éditeurs (E-link de BEA ou Crossworlds par exemple), ce qui prouve la pertinence de son moteur de transformation. • La version 2.0 du produit, disponible en fin d’année, se focalisera sur l’amélioration de l’administration (outils de déploiement pour palier à l’absence de référentiel), diverses optimisations de performance (gros fichiers, gestion de connexions SGBDR, etc.), le support de transactions imbriquées, etc. Pas de refonte du marketing produit, avec toujours les éditions Mercator for SAP ou PeopleSoft, for FS et for EC. • Concernant l’édition Mercator for EC, l’offre va s’agrémenter du récent rachat de la société Novera, qui édite un outil d’intégration d’applications Web multi-canaux. • La 2.1 devrait amener l’année prochaine les adaptateurs HTTP et LDAP, un meilleur support de XML, des interfaces vers les progiciels d’administration du marché, et le support de nouvelles plates-formes et SGBDR. • Le récent rachat de la société BRAID devrait faciliter l’axe finance et concurrencer Tibco ou NEON sur ce créneau (TSI utilisera des applicatifs externes de Braid comme Nimbus ou Gemini) • La force du produit autour de l’intégration SAP devrait également tirer le produit vers un support plus poussé des ERP concurrents.

Figu re 3 5 : Ar chit ectu re Mer cat or (so ur ce TS I)

3.13. Viewlocity (ex Frontec) AMTrix www.viewlocity.com CA / RN : non communiqués Références : >800 Employés : 200 (1000 sur Frontec) Présence en France : 2 personnes

Caractéristiques du produit • Le produit AMTrix est issu de la société Suédoise FrontecAB qui a capitalisé sur des développements spécifiques depuis 1990. Le produit n’est vendu comme tel que depuis 4 ans. • La société Frontec AB a séparé son activité d’ingénierie de celle d’éditeur, en renommant cette dernière Viewlocity, avec l’arrivée de capitaux externes (groupe Battery) • AMTrix est un message broker classique, issu des technologies de l’EDI : X.12 et EDIFACT, X.400 pour le transport • Le Message Broker stocke ses informations dans un référentiel, par défaut sous Informix • Le moteur de transformation utilise le référentiel pour stocker ses formats (Message Builder), un langage de programmation spécifique peut être utilisé pour les cas les plus complexes • En plus du transport propriétaire interne, des passerelles (Communication Server : CSE) existent vers les transferts de fichiers, MQSeries et les bases de données (DataMapper) • Outre l’EDI, il supporte aujourd’hui des connecteurs vers les ERP SAP et JDEdwards, se positionnant de fait sur les créneaux de la gestion logistique (AMTrix est également au cœur du SCM Manugistics)

Forces

Faiblesses

• Capacité d’intégration de flux EDI dans des ERP, fournit une solution viable de SCM (cf. signature récente de Carrefour)

• Pas de gestion de processus complexes

• Référentiel SGBDR • Grosses références dans l’industrie et la distribution : Volvo, Mars, DHL, Castorama

• Produit relativement “ancien” et très marqué EDI • Seulement deux connecteurs applica tifs aujourd’hui (SAP et JDE), bien que d’autres soient planifiés (autres ERP et SCM).

Positionnement et Stratégie • Focalisation sur le marché de la chaîne logistique : industrie, distribution • Accord OEM avec des éditeurs, déjà au cœur de Manugistics

F igur e 36 : Co mposan ts de l ’o ffr e AMTrix (s ou rce V ie wl oc ity )

3.14. Vitria BusinessWare www.vitria.com CA / RN : 7,6 M$ / -9,5 M$ 45 M$ levés lors de l’IPO, +200% le premier jour ! Références : environ 30 Employés : 180 Présence en France : NON (UK)

Caractéristiques du produit • L’offre BusinessWare se compose de plusieurs modules. La définition des processus est réalisée à l’aide du Process Modeler Client. Le Message Broker (Automator) exécute ces processus, qui peuvent être suivis en exploitation par l’outil Analyzer. • Vitria offre une couche de transport spécifique (Communicator), fondée sur une architecture CORBA (IIOP ou IP multicast), mais peut aussi se connecter à d’autres infrastructures à l’aide de Connectors. • Ces connecteurs techniques existent pour MQSeries, MSMQ, Oracle AQ, les SGBDR, les fichiers, les messageries, etc. • Des connecteurs applicatifs, nombreux, sont disponibles pour SAP, Peoplesoft, Vantive, Clarify, Kenan, Remedy, et XML, EDI. Nous ne connaissons pas le niveau de support réel qu’ils offrent. • Le connecteur est responsable de la transformation de ce qu’il émet comme événement métier dans le serveur, ceux-ci sont au format CORBA IDL. A ce titre, le connecteur SAP se chargera de la transformation d’IDoc en IDL par exemple. Le cas échéant, Vitria peut s’ouvrir à des moteurs de transformations externes pour les cas complexes. • Les processus se définissent graphiquement dans le BusinessWare Modeler, ces processus empruntent une syntaxe compatible UML. Un point intéressant est la capacité de passer directement du modèle aux tests dans Automator. • Toutes les interfaces graphiques de développement et d’administration sont des applications Java

Forces

Faiblesses

• Gestion de processus intégrée dès le départ

• Petite société, une trentaine de références

• Catalogue de connecteurs important

• Pas de moteur de transformation

• Offre très “moderne” : UML, IDL/IIOP, Java, SSL,... trop ?

Positionnement et Stratégie • L’introduction en bourse va permettre à la société de développer ses produits et sa stratégie. • Un des axes annoncés est la verticalisation de l’offre, en premier lieu sur le marché des opérateurs télécom (connecteurs aux applicatifs spécifiques, processus prédéfinis, etc.) • Vitria souhaite également ouvrir son moteur de workflow applicatif à des acteurs humains, proposant ainsi une offre unique sur le marché, synthèse des offres EAI les plus à la pointe et des produits de workflow/GED classiques (FileNet,etc.)

Fig ure 37 : C omp osant s d e l’ of fre B usin ess W ar e (source Vi ew locit y)

Filiale du Groupe Aubay

26 - 28 rue Marius Aufan • 92300 Levallois-Perret Tél : (33) 1 41 49 19 41 • Fax : (33) 1 41 49 19 45 • http : //www.octo.fr