L EAI par la pratique François Rivard Thomas Plantain ISBN : 2-212-11199-1
6 Les connecteurs applicatifs Si le middleware transporte les messages entre applications, les Connecteurs sont les éléments techniquement capables de créer ces messages ou de les collecter, de les exploiter, et de compléter ainsi la réalisation de l infrastructure d intégration.
162 Réalisation PARTIE III Principes À l identique des conclusions tirées au sujet du middleware, les connecteurs applicatifs sont un point particulièrement crucial de l architecture des plates-formes d intégration. La qualité de ces modules pré-packagés et leur diversité sont souvent des éléments déterminants dans le choix d un progiciel EAI. Nombreuses sont les entreprises qui se détournent d une solution si elle ne propose pas en standard un des connecteurs recherchés, sans même en envisager le développement à l aide du SDK fourni. Ce constat est particulièrement vrai dans les premières tranches de la roadmap d intégration, où des résultats concrets sont attendus très rapidement. L existence de connecteurs applicatifs sur les applications à intégrer réduit la complexité du projet d intégration et, par conséquent, les délais nécessaires à sa mise en œuvre. Or, développer un connecteur spécifique constitue un projet dans le projet, mené séparément et en parallèle, et dont la charge n est pas négligeable. Cette couche technologique majeure, avec le courtier de message, a permis l avènement des logiciels et des éditeurs d EAI dans le courant des années 90. C est aussi un élément différenciateur des offres, et c est sur ce terrain que les pure players du domaine se sont longtemps concurrencés, avant de lutter dans le domaine des processus métier. De plus, ces connecteurs représentent un point de convergence avec les technologies des serveurs d application, via l émergence des services Web et de normes comme JCA (J2EE Connector Architecture) dans le paysage. L objectif de ce chapitre est de montrer concrètement la mise en œuvre de ces connecteurs (appelés aussi adaptateurs), dans l optique de bien comprendre le type de travail qu ils impliquent, de bien mettre en évidence les services à valeur ajoutée qu ils procurent toujours par rapport à un développement spécifique. Enfin il s agit de mieux appréhender leur place et la part qu ils tiennent dans le projet et dans la démarche générale d intégration. Leurs points de connexion avec les services Web seront aussi détaillés. Le travail sur les connecteurs intervient lors de la phase de réalisation technique de la plate-forme, pour exploiter les structures de données (les interfaces) mises à disposition des développeurs dans le cahier de spécifications techniques. Détaillons cela en reprenant le diagramme de la démarche EAI. Dans le planning du projet, la partie Connecteurs suit la partie Middleware. En effet, à ce stade, le bus capable de drainer les données émanant des différentes applications a été spécifié et déployé. Les données qui seront ensuite exploitées par le moteur d intégration (processus et mappings), dont le développement s effectue en parallèle, doivent pouvoir être lues puis écrites dans les applications correspondantes. Le chaînon manquant se situe à la jonction des applications et de ce bus middleware : les connecteurs applicatifs. Lorsque ces connecteurs seront paramétrés, toute l infrastructure sera mise en place pour assurer la circulation des données et activer le système nerveux d entreprise. Les premiers tests de flux de données pourront enfin avoir lieu. En effet, il n est pas indispensable de disposer d un processus métier finalisé pour mettre en relation deux applications : deux modèles de connexion peuvent communiquer entre eux. Il est parfaitement envisageable de gérer des processus d intégration simples de cette façon. Dans ce cas, la valeur ajoutée de la structure pivot est négligeable, puisqu en quelque
Les connecteurs applicatifs CHAPITRE 6 163 sorte, on fait du point à point dans le bus EAI. Rappelons que la valeur ajoutée de la structure pivot se situe dans l orchestration complexe (conditions, boucles, intervention humaine ) et dans l application de règles métier spécifiques à des Business Process Objects (BPO). Ce point sera repris et complété dans le chapitre 9. Nous avons vu dans le chapitre précédent que le volet middleware du projet comptait une partie de déploiement et une partie de paramétrage (création des files d attente ou des sessions de publish & subscribe). L aspect connecteur fait le lien entre les applications (où résident les données et les services) et le middleware. La gestion des connecteurs applicatifs L utilisation de connecteurs applicatifs est à l origine de nombreux avantages en terme de développement comme en terme d exploitation. On trouve dans tout bon outil une console dédiée à la gestion des connecteurs applicatifs. Les intérêts sont nombreux : Centralisation des informations : quel que soit le type de connecteur, c est la même console qui est utilisée pour le paramétrage. Il existe ainsi un outil unique de travail, que le développeur soit amené à lire ou écrire des données présentes dans des fichiers plats, dans des fichiers XML, dans une base de données, dans des progiciels qui présentent des API, ou dans tout autre type d application. Paramétrage et administration graphique des connecteurs : la console graphique permet de faciliter la mise en œuvre des connecteurs. Ceci s apparente en réalité davantage à du paramétrage qu à du développement. Ce paramétrage reste graphique : il ne s agit pas de documenter un fichier de propriétés lu par le connecteur au démarrage, mais de fournir des informations dans une interface type Windows ou Swing, qui spécifieront le comportement de ce connecteur. Ce travail fait l objet du cas pratique présenté dans la suite de ce chapitre. Enregistrement des structures de données dans le référentiel : les structures de données gérées par les connecteurs peuvent être générées au moment de la création du connecteur. Elles sont alors ensuite stockées dans le référentiel, pour être utilisées de façon homogène par les autres applications de la suite d intégration. Il n y aura pas de risque de se heurter à des structures de données incohérentes d un module de l offre EAI à l autre. Figure 6-1 Création des structures de données directement depuis les connecteurs
164 Réalisation PARTIE III Cependant, pour s adapter à la démarche que nous nous attachons à suivre, les structures de données peuvent également être créées préalablement dans le référentiel (suite à l importation des schémas UML) et liées à une instance de connecteur lors de la création de celui-ci. C est tout l intérêt du modèle. Cela permet d importer des schémas XML ou des diagrammes de classes UML vers le référentiel EAI, et de garantir à tout moment l intégrité entre les diagrammes de la phase de modélisation et les réalisations de la phase de développement. Figure 6-2 Définition des structures de classes hors de la plate-forme d EAI Les connecteurs dans le projet TTT Le processus de gestion des voyages communique avec différentes applications, selon différents modes de communication et protocoles qui sont décrits dans la vue Technique du modèle de flux. Nous rappelons ci-dessous pour mémoire les différents modes de communication impliqués : Application Mode de communication Connecteur applicatif Logiciel de Comptabilité/Facturation Fichier Fichier Site Web Données Connecteur base de données natif ou universel (ODBC/JDBC) Plate-forme de CRM Progiciel Connecteur CRM (communique avec les API du progiciel) Services Web des fournisseurs B2B XML sur http Connecteur services Web
Les connecteurs applicatifs CHAPITRE 6 165 L événement métier qui lance notre processus est la création par le client d une nouvelle commande depuis le site Web, qui se traduit techniquement par l insertion d une ligne dans la table Commande de la base de données du site. La première étape consistera à construire un modèle de connexion qui exploite un connecteur base de données et remonte l événement et les données jusqu au processus métier. Modèle de connexion base de données Un modèle intrusif? Difficile de prétendre plus longtemps, à la lecture de ce qui va suivre, c est-à-dire qu un connecteur base de données n est pas intrusif. Dans le cas de la collecte d information, la notion d intrusion est même toute relative et tient de la pirouette d interprétation : en fait, un tel connecteur n est pas intrusif au sens où il ne modifie pas le modèle physique existant sur les tables qui y participent. En revanche, il crée une table miroir de la table source, copie quasi conforme de celle-ci, avec un léger delta constitué des colonnes système de la plate-forme d EAI, dans le même schéma de base. De plus, cette création de table s accompagne de la génération d un trigger qui copie les enregistrements de la table source vers la table miroir. Pour toute table sur laquelle on souhaite collecter des données, la plate-forme d EAI crée ainsi deux objets : l un directement lié à la table (le trigger), assurant le lien vers la table miroir, passerelle directement utilisée par le connecteur EAI. D une part, cela n est pas sans impact, et explique notre préférence pour l utilisation d une API dans la connexion aux données car celle-ci sera toujours non intrusive. De plus, une connexion au niveau des données n est pas concevable sur un modèle de données complexes. Imaginez un tel mécanisme appliqué aux milliers de tables que compte SAP par exemple, qui devrait de surcroît tenir compte des dépendances fonctionnelles entre ces tables. Une connectivité de type services est bien plus élégante et facile à gérer qu une connectivité au niveau données, mais elle n est pas possible à chaque fois, car elle n a pas toujours été prévue. Fonctionnement du connecteur DB La séquence des opérations du connecteur base de données est décrite graphiquement dans la figure ci-après. L intérêt majeur du trigger, c est sa personnalisation : il est possible de retoucher le code SQL pour ne publier vers l EAI que les enregistrements vérifiant certaines conditions. C est une façon de limiter le volume de publication, au détriment cependant de la visibilité de la règle de filtrage. En effet cette règle, sortie du cadre technique strict de la console de développement, peut alors s avérer difficile à retrouver. En somme, c est un avantage pour un inconvénient, donc c est à l entreprise d arbitrer. Elle doit surtout spécifier clairement ce choix dans ses méthodes, et le généraliser autant que faire se peut à tous les processus et à tous les projets : pas question de placer des filtres dans les triggers sur un processus, dans le mapper sur un autre, dans le processus sur un troisième, et ainsi de suite.
166 Réalisation PARTIE III Figure 6-3 Séquence des opérations du connecteur base de données L important, lorsqu on utilise une EAI, c est de s orienter facilement entre les nombreuses couches techniques. Sans organisation rigoureuse du framework, le projet devient difficile à maintenir, et on perd une partie du bénéfice de ces plates-formes. Pour notre part, nous préférons nettement implémenter tous les filtres depuis la console graphique de la plate-forme EAI. De plus, il est très clair que si la table concernée utilise déjà un trigger pour d autres besoins, l opération tient de la gymnastique : il faut aménager le code du trigger existant, en admettant que cela soit possible sans trop d efforts Une perspective bien peu encourageante. Pour faciliter l opération, on inclura le code dans une procédure stockée invoquée depuis le trigger, mais cette solution n est pas non plus très alléchante. Il est donc impératif, dans tous les cas de figure, de conserver systématiquement tous les scripts de création de table et de trigger, pour être en mesure de les rejouer si nécessaire ou de les déplacer. Parce qu ils constituent finalement une étape importante de la mise en œuvre, il peut être essentiel de les recréer à l identique lors du déploiement des multiples configurations (du développement à la certification, et à la production).
Les connecteurs applicatifs CHAPITRE 6 167 Les spécifications du modèle de connexion Structures de données Deux types de structures de données sont utilisés dans le modèle décrit : une structure de données locale correspondant aux champs retenus dans la table Commande de la base de données, et la structure de données pivot du référentiel commun. Activités La séquence d opérations ci-dessous explique les opérations que nous utilisons dans nos modèles de connexion. Le modèle décrit ici est un modèle d entrée principal (voir le chapitre 3), initiateur d un processus métier. La séquence des activités est représentée par un diagramme UML : LectureDB : c est la collecte des données. Le stéréotype <<connecteur DB>> indique le sous-système qui effectue cette activité. Le message publié est de type Commande. Sa structure correspond aux champs sélectionnés dans la table de la base où les données ont été recueillies. Nous faisons figurer en annotation les spécifications relatives à l événement et à la condition qui déclenchent le modèle de connexion : ici, c est la mise à jour de la colonne Validee d une ligne de la table Commande, à la valeur O, qui indique que le client vient de valider une commande en préparation. Mise au format pivot : transformation de la structure de données (de la structure initiale collectée en base de données vers le format pivot) et mise au format commun des données non normalisées (dates) dans le but d alimenter le processus métier avec une structure de données propre à son fonctionnement. Le stéréotype <<conversion fonctionnelle>> indique la nature de l activité. Le message reçu est de type Commande et le message publié est de type interfacecommande (format pivot). IDL To XML : transformation de la structure de données, du format natif Vitria (IDL valué, c est-à-dire structurant les valeurs du message) vers XML. Il s agit d une convention technique, spécifiée dans les choix d architecture, dont le but est de favoriser la lisibilité des messages échangés. Le stéréotype <<conversion technique>> indique la nature de l activité. Le message reçu et le message publié sont de type interfacecommande. Init Nouvelle Commande : publication de la structure de données pivot XML sur un canal de communication. Comme le but de cette publication est de lancer un processus métier, le stéréotype utilisé est <<publication BPM>>. Nous faisons figurer en annotation la spécification concernant le nom du canal chargé de véhiculer l information (chncommande). La spécification de la figure 6-4 ci-après représente graphiquement le diagramme d activités UML du modèle de connexion.
168 Réalisation PARTIE III Figure 6-4 Spécifications d un modèle de connexion principal d entrée Création du modèle de connexion Passée la phase de modélisation, logiquement commence le développement. Pour le développeur EAI, le travail consiste à reproduire le modèle de connexion par les objets effectuant chaque activité, à les paramétrer et à les relier entre eux en respectant la séquence spécifiée. Le paramétrage des modèles de connexion sur des points comme l accès à une base de données ou l utilisation du compte utilisateur d un progiciel requiert des spécifications précises. Beaucoup de pertes de temps sont dues à des informations de connexion manquantes ou erronées, qui bloquent le designer EAI dans son travail. La responsabilité du chef de projet EAI est de veiller à la disponibilité et la validité de ces informations. L implémentation du modèle de connexion avec BusinessWare est facilitée par la présence de méta-modèles de connexion, qui accélèrent encore le développement. Au moment de la création d un élément opérationnel dans le référentiel, le produit de Vitria demande le type de modèle de connexion qui doit être créé. Une liste de modèles types est ainsi mise à disposition, comme représentée dans la figure 6-5 ci-après.
Les connecteurs applicatifs CHAPITRE 6 169 Figure 6-5 Création du modèle de connexion suivant un modèle type Le modèle en cours de construction ici est la connexion à la base de données Oracle du logiciel de facturation/comptabilité. Ce choix aboutit à la création du modèle de connexion suivant : Figure 6-6 Modèle de connexion Oracle type
170 Réalisation PARTIE III Ce modèle comprend trois activités types : collecte des informations depuis un canal, transformation des données au format cible, publication dans la base de données via le connecteur placé en fin de modèle. Quel que soit l aspect du modèle de connexion final, il y a ainsi toujours une partie de ce modèle type qui est prête au paramétrage et réutilisée. La partie suivante, consacrée à la construction du modèle de connexion employé pour collecter les données dans le portail Web suite à l émission d une nouvelle commande par un client, montrera comment personnaliser le modèle en fonction des éléments mentionnés dans les spécifications. La construction du modèle de connexion Avec BusinessWare, le modèle de connexion décrit ci-dessus prend l apparence de la figure 6-7. Figure 6-7 Le modèle de connexion Lecture Nouvelle Commande
Les connecteurs applicatifs CHAPITRE 6 171 Le tableau suivant détaille les différentes tâches sélectionnées depuis la palette. Les outils utilisés dans le modèle de connexion RDBMS Source Transformer Simple Data Transformer Channel Target Pour chaque objet BusinessWare, on paramètre trois types d informations : Input, Output et Processing. Les deux premiers éléments concernent le message en entrée et le message en sortie. Le troisième élément décrit le traitement à appliquer au message. Nous préciserons les paramètres de chacune des tâches dans les paragraphes suivants. BusinessWare propose aussi des outils pour tester et déboguer le modèle de connexion : les inspecteurs. Il suffit de les déposer dans le modèle et de les relayer aux tâches pour qu ils interceptent les flux et affichent les informations transportées à cet endroit du modèle. Tâche Description Cet inspecteur affiche la structure et les valeurs des structures de données captées. Cet inspecteur effectue un travail similaire, mais forme un breakpoint : le routage s interrompt au moment où la structure de données est capturée. Nous présentons ci-dessous brièvement le paramétrage de chacun des éléments, pour montrer explicitement les propriétés importantes à fixer pour chacun des objets, et préciser leur mode de fonctionnement, à l exception de la tâche de transformation qui sera présentée plus en détail dans le chapitre suivant.
172 Réalisation PARTIE III Le connecteur base de données Assistant de création du connecteur La création du connecteur s effectue dans BusinessWare à l aide d un assistant qui observe la base de données, génère pour vous le code SQL de la table miroir et du trigger, et enregistre la structure de données dans le référentiel. La première étape consiste à fixer les paramètres de connexion à la base de données. Figure 6-8 DB Wizard (1/4) : paramètres de connexion Le travail du chef de projet EAI ne se limite donc pas à mettre à disposition du développeur les informations de connexion. Une autre de ses responsabilités est de se mettre en relation avec les administrateurs des différentes applications, afin qu ils créent un compte EAI pour chacun des systèmes participant au processus métier. C est vrai pour une base de données, mais aussi pour un progiciel ou pour un système de fichier, par exemple. Créer le bon compte avec les bons privilèges est une procédure dont la spécification et la mise en œuvre peuvent parfois prendre un certain temps. Le chef de projet devra donc veiller à mener ces opérations suffisamment en amont pour ne pas freiner le travail de l équipe de développement EAI. Avec ces informations, l assistant est capable de remonter la liste des tables disponibles pour les informations de connexion considérée : c est la deuxième étape de l assistant (figure 6-9). L assistant détermine alors la liste des champs qui constituent la table et la présente à l utilisateur. C est la troisième étape. Parmi ces champs, l utilisateur laisse ceux qui sont propres au site Web et sont sans utilité pour le modèle commun (figure 6-10). La dernière étape n en est pas réellement une. Il s agit d une information succincte sur la structure de données qui va être créée dans le référentiel (figure 6-11). Cette étape validée, l assistant créé et enregistre tous les objets nécessaires.
Les connecteurs applicatifs CHAPITRE 6 173 Figure 6-9 DB Wizard (2/4) : choix de la table Figure 6-10 DB Wizard (3/4) : choix des champs Figure 6-11 DB Wizard (4/4) : message final
174 Réalisation PARTIE III Impacts sur la base de données La première commande exécutée par le connecteur est de créer une séquence. Les séquences sont souvent utilisées pour déterminer un identifiant de table. Nous verrons comment celle-ci est utilisée en fin d exemple. CREATE SEQUENCE vtpollconnector ORDER La table miroir, nommée COMMANDE_sdw (pour shadow) est ensuite créée : create table VITRIA.COMMANDE_sdw ( cmd VARCHAR2(12), old_commandeid NUMBER, old_reference VARCHAR2(32), old_datecommande DATE, old_montantht NUMBER, old_montanttva NUMBER, old_montantttc NUMBER, old_zone CHAR(3), old_clientid NUMBER, new_commandeid NUMBER, new_reference VARCHAR2(32), new_datecommande DATE, new_montantht NUMBER, new_montanttva NUMBER, new_montantttc NUMBER, new_zone CHAR(3), new_clientid NUMBER, orderid INTEGER ) On note que : L ancienne et la nouvelle valeur de chaque champ sont stockées deux fois. Le premier champ de la table est un champ nommé cmd dont l utilité est de préciser le type d opération entrepris (ajout, modification, suppression ) ; Le dernier champ de la table est un champ nommé orderid utilisé pour déterminer la séquence dans laquelle les opérations sont survenues (lors d une insertion multiple par exemple). Vient ensuite la création du trigger (déclencheur) qui est utilisé pour copier les enregistrements de la table native dans la table miroir. CREATE OR REPLACE TRIGGER "VITRIA"."COMMANDE_SDW_TGR" BEFORE UPDATE OF "VALIDEE" ON "VITRIA"."COMMANDE" FOR EACH ROW DECLARE command VARCHAR2(12);
Les connecteurs applicatifs CHAPITRE 6 175 BEGIN IF INSERTING THEN command := insert ; ELSIF DELETING THEN command := delete ; ELSIF UPDATING THEN command := update ; END IF; insert into VITRIA.COMMANDE_sdw values ( command, :old.commandeid, :old.reference, :old.datecommande, :old.montantht, :old.montanttva, :old.montantttc, :old.zone, :old.clientid, :new.commandeid, :new.reference, :new.datecommande, :new.montantht, :new.montanttva, :new.montantttc, :new.zone, :new.clientid, vtpollconnector.nextval); END; La commande INSERT du trigger nous éclaire sur les remarques faites à la lecture du script de création de la table miroir. D abord, c est le trigger lui-même qui détermine et copie les anciennes et les nouvelles valeurs en exploitant les capacités du SGBD à identifier les deux types de valeurs avant la mise à jour effective des données. Ensuite, le premier champ de la table spécifie l action DB en cours : insertion d un nouvel enregistrement, mise à jour ou supression d un enregistrement existant. Enfin, le dernier champ est l identifiant de l enregistrement, déterminé à partir de la séquence vtpollconnector, créée par la première commande du code SQL ci-dessus. Lorsqu un enregistrement est inséré dans la table commande, le trigger le copie instantanément vers la table miroir commande_sdw. C est cette table qui est lue par le connecteur base de données. Il faut savoir que le connecteur DB de BusinessWare opère une lecture destructrice : les enregistrements sont purgés après leur lecture dans la table miroir. D autres éditeurs utilisent la technique du marquage, en ajoutant une colonne à la table miroir, qui spécifie si l enregistrement a déjà été lu ou non.
176 Réalisation PARTIE III Que faire si un trigger existe déjà sur cette table précédemment au déploiement du connecteur? La première étape consiste à créer le connecteur en spécifiant de ne pas créer le trigger. L option existe généralement. La seconde consiste à placer le code destiné au trigger, soit dans le trigger lui-même, soit dans une procédure stockée. Le code du trigger demande alors réécriture : les objets manipulés par celuici (old et new) ne sont pas disponibles à froid. Reste à définir une procédure d invocation régulière de cette procédure stockée, dont le travail consiste à alimenter la table miroir. Une exécution fréquente permet de conserver l aspect temps réel. Impact sur le référentiel de configuration EAI Suite à l utilisation de l assistant, la structure de données est insérée dans le référentiel et sa définition convertie en IDL est stockée parmi les types de données disponibles. La figure 6-12 ci-dessous montre le stockage de la structure de données dans le référentiel. On constate qu un module TTTWeb, correspondant à l identifiant Oracle du service de base de données, a été créé, contenant lui-même un module Vitria, correspondant au nom du schéma de base de données. Enfin, un objet Data, structure contenant les champs sélectionnés dans la table, est affiché. Figure 6-12 Insertion de la structure de données dans le référentiel
Les connecteurs applicatifs CHAPITRE 6 177 Les éléments créés peuvent être déplacés et renommés afin d être éventuellement standardisés dans un module commun. Test du modèle de connexion La première étape consiste à démarrer le modèle. Si tous les éléments sont dûment paramétrés et référencés, aucun obstacle ne doit s opposer au démarrage du modèle. Dans le cas contraire, on interprète le message d erreur et on avise : il faut se familiariser avec les types d erreurs possibles, mais comme pour tout produit, la pratique des erreurs accélère la compréhension et se montre la meilleure des formations. Pour un test complet, une mise à jour d une ligne de commande dans la base de données est nécessaire. Par la suite, on peut procéder à des tests unitaires sur chacune des tâches du modèle, en insérant à tout endroit du modèle des événements de tests enregistrés préalablement. Après mise en état Validé d une ligne de commande, on peut interroger les inspecteurs du modèle de connexion. Le premier inspecteur affiche le résultat suivant. Figure 6-13 Structure de données Commande à la sortie du connecteur On constate que les valeurs du message ont été reproduites telles quelles dans un message respectant le format du modèle de données local Web.
178 Réalisation PARTIE III Figure 6-14 Structure de données Commande après la mise au format pivot Après mise au format pivot, le message résultant véhicule les mêmes données au sein de la structure pivot identifiée et définie dans le référentiel métier commun. Le message est ensuite envoyé au travers de la tâche de transformation XML. Au sortir de cette tâche, l inspecteur affiche le message suivant : <?xml version="1.0" encoding="utf-8"?> <EVENT spec="idl:ttttransformations/commandeinterface:1.0#commande"> <commande> <Client> <Nom/> <Prenom/> <Facturation> <Adresse/> <CodePostal/> <Region/> <Ville/> <Pays/> </Facturation> <Coordonnees> <Telephone/> <Telecopie/> <email/> <Mobile/> </Coordonnees> <Livraison> <Geo> <Adresse/> <CodePostal/> <Region/>
Les connecteurs applicatifs CHAPITRE 6 179 <Ville/> <Pays/> </Geo> </Livraison> <idweb>54.0</idweb> <idcrm/> <idprod/> <idfacturation/> </Client> <TotalHT>1834.18</TotalHT> <TotalTVA>359.49</TotalTVA> <TotalTTC>2193.67</TotalTTC> <Date>2002-07-06 00:33:27.0</Date> <Reference>LED0001511-FR</Reference> <Zone>EUR</Zone> <Articles> <ReferenceTTT/> <MontantHTAdulte>0.0</MontantHTAdulte> <QteAdulte>0.0</QteAdulte> <MontantHTEnfant>0.0</MontantHTEnfant> <QteEnfant>0.0</QteEnfant> <ReferenceFournisseur/> <Description/> <MontantTVAAdulte>0.0</MontantTVAAdulte> <MontantTVAEnfant>0.0</MontantTVAEnfant> <MontantTTCAdulte>0.0</MontantTTCAdulte> <MontantTTCEnfant>0.0</MontantTTCEnfant> </Articles> </commande> </EVENT> Ce message est transmis à la tâche de publication sur le canal de communication. Vérifier la publication de l événement sur le canal est possible avec deux outils de monitoring d appoint accessibles depuis la console : Le premier affiche les statistiques de tous les événements traités par le canal, en bout de chaîne : Figure 6-15 Statistiques des événements traités par le canal
180 Réalisation PARTIE III Le second affiche les statistiques de traitement de chaque élément du modèle de connexion, à tous les niveaux de la chaîne : Figure 6-16 Statistiques du modèle de connexion On peut ainsi suivre le trajet du message, et comprendre à quel endroit un éventuel blocage est susceptible de survenir. Pour comprendre la nature de l erreur, on peut alors se référer aux fichiers de journalisation spécifiés dans la phase de développement et générés par le moteur à l exécution. Tests unitaires Comme nous l avons mentionné au chapitre 3 au sujet de la démarche projet, il est important de pouvoir procéder à des tests unitaires sur les éléments paramétrés. Il n est parfois ni possible ni facile de procéder à un test grandeur nature en agissant directement sur le contenu d une base de données. Vitria laisse alors la possibilité de tester le modèle de connexion en créant des jeux de tests qui peuvent être lancés régulièrement. Ils vérifient la non-régression du modèle, même si un moteur manque pour lancer une batterie de tests complète et vérifient via un reporting adéquat l état de l ensemble des fonctionnalités. Les ensembles de valeurs des jeux de test peuvent être spécifiés dans les plans de tests conçus en marge des spécifications. Ils sont transmis à partir des inspecteurs de débogage placés entre deux tâches. Tout élément de test précédemment stocké peut être utilisé. Nous allons rapidement montrer comment on crée un jeu de test. Vitria utilise un assistant qui pilote la création du message. Dans un premier temps, nous précisons que le jeu de test est un nouvel ensemble de valeurs (figure 6-17). La deuxième étape consiste à spécifier l événement qui déclenchera le processus. Elle permet aussi, conséquemment, de spécifier la structure du message déclencheur de l événement (figure 6-18).
Les connecteurs applicatifs CHAPITRE 6 181 Figure 6-17 Test Wizard (1/3) : choix du jeu de test Figure 6-18 Test Wizard (2/3) : choix de l événement et de la structure de données test La troisième étape consiste à fixer les valeurs utilisées pour jouer le test, et éventuellement à le sauvegarder pour le rejouer ultérieurement. Nous allons volontairement fixer une date qui ne correspond pas à un réel format de date (figure 6-19).
182 Réalisation PARTIE III Figure 6-19 Test Wizard (3/3) : saisie des valeurs de test Après validation, l événement est envoyé dans le flux de données. Il franchit l étape de transformation. Après contrôle de l inspecteur en aval de cette tâche, on s aperçoit que le format de date n a pas posé problème lors de la transformation. Figure 6-20 Structure du message après son passage par la tâche de transformation En réalité, la tâche de transformation n a pas été finalisée. Nous nous sommes contentés de transférer les données d une structure à l autre, sans contrôle sur le format des valeurs ni sur leur type. Le moteur de transformation effectue pour l instant automatiquement les
Les connecteurs applicatifs CHAPITRE 6 183 opérations de transtypage. Nous verrons dans le prochain chapitre comment réaliser et tester une transformation. Modèle d erreur Bref rappel : les modèles d erreur sont utilisés pour gérer les problèmes de nature technique, alors que les modèles d exception gèrent les aiguillages métier qui sortent de l exécution normale d un processus. Figure 6-21 Gestion d erreur type La gestion du modèle relationnel Lorsque la commande est créée, il faut au plus cinq secondes pour déclencher le processus d orchestration. Ce processus collecte alors les informations concernant la commande (Référence de la commande, Date d émission ). Cependant, pour être en mesure de passer commande auprès des fournisseurs B2B, le processus a aussi besoin des articles demandés par le client. Or, ces articles se trouvent dans une autre table, la table Article. BusinessWare prévoit les mécanismes nécessaires à la gestion du modèle relationnel. Nous devons pour cela utiliser un type particulier d objet Vitria, appelé Aggregator. Cet objet, et le modèle de connexion résultant, sont représentés dans la figure 6-22. Figure 6-22 Modèle de connexion avec Aggregator
184 Réalisation PARTIE III Pour utiliser ce composant, il faut : Utiliser l assistant pour créer une table miroir sur la table Article : la structure de données Article vient d elle-même alimenter le connecteur. Paramétrer le connecteur pour envoyer un événement Epoch. Cet événement signale que le connecteur a collecté les événements fils liés à l enregistrement père. Définir dans le composant Aggregator l emplacement où la structure d agrégation sera générée. Cette structure est créée automatiquement par BusinessWare. Et c est tout! Lançons une procédure de test avec le jeu d essai précédent. En sortie du connecteur DB, l inspecteur donne la liste des événements publiés, comme le montre la figure 6-23. Figure 6-23 Événements produits par le connecteur DB Cinq événements sont transmis à l agrégateur : un événement Commande ; trois événements Article, correspondant aux trois articles commandés ; un événement Epoch, closant la transaction. En sortie de l agrégateur, la structure de consolidation est créée, comme le montre la figure 6-24. Figure 6-24 Structure d agrégation
Les connecteurs applicatifs CHAPITRE 6 185 Le champ de jointure, COMMANDEID, est sortie de la structure. Sa valeur apparaît dans la colonne Value. La commande est placée dans une structure dont dépendent les trois articles, placés eux aussi dans une structure de séquence. Le nombre d occurrences de chaque structure apparaît dans la colonne Value. Cette structure est mise en format pivot comme le montre la figure 6-25. Figure 6-25 Structure pivot La structure en sortie correspond bien à notre classe métier, avec sa structure hiérarchique CommandeClient qui regroupe les informations du client et du voyage. Le voyage est lui-même composé d articles en séquence dans un tableau d articles. Cette classe finit ensuite le parcours comme précédemment pour être publiée sur le canal. Conclusion Cette partie nous a permis de présenter la gestion d un connecteur base de données mais audelà, les facilités que procure BusinessWare pour gérer les modèles de connexion, comme l inspection des données, les statistiques de publication ou la génération de jeux de tests. Nous allons maintenant présenter brièvement deux autres types de modèles de connexion : le connecteur CRM et le connecteur fichier.
186 Réalisation PARTIE III Connecteur CRM Nous allons ici décrire les mécanismes employés par BusinessWare pour communiquer avec l application de CRM utilisée par TTT. Le modèle de connexion est un modèle réel interfacé avec une des applications phares du marché, dont nous n avons pas été autorisés à communiquer le nom. Il est représenté figure 6-26. Ce modèle de connexion comprend quatre étapes : Le canal source (channel source) : réception du message depuis un canal middleware. Le connecteur CRM cible (CRM target connector) : communication avec le serveur Web de l application de CRM, déclenchant un processus interne à cette application. Figure 6-26 Le modèle de connexion CRM La réponse de la plate-forme CRM (Extract CRM Msg) : la communication s établissant de façon synchrone sur HTTP, une réponse est renvoyée par l application pour indiquer le résultat du traitement effectué. Le canal cible (channel target) : cette réponse est publiée sur un canal pour d éventuels traitements ultérieurs. Connecteur fichier Le processus de Nouvelle Vente n utilise pas d échanges impliquant des connecteurs lisant ou écrivant des données depuis des fichiers ASCII. Dans ce but, nous allons brièvement étudier les processus de gestion décisionnelle d activité, via l alimentation du data warehouse.
Les connecteurs applicatifs CHAPITRE 6 187 Le data warehouse de TTT est alimenté grâce à l application d ETL qui recueille les fichiers transmis par la plate-forme de CRM. Ces fichiers sont écrits par un connecteur placé sur le serveur où s exécute le logiciel d ETL, en suivant le modèle de connexion représenté figure 6-27. Figure 6-27 Modèle de connexion Fichier On suppose que la structure transmise depuis le processus correspond à la structure écrite dans le fichier : une structure Vente (modèle local du data warehouse) comprenant notamment la date, le montant de la vente et la zone de destination. Ce modèle de connexion suit alors deux étapes : Init Alimentation DW : initialisation du modèle de connexion via la réception d un message sur le canal écouté ; mise au format natif : traduction du format pivot CommandePivot au format attendu par le connecteur fichier ; Les paramètres du connecteur fichier sont indiqués figure 6-28 : Figure 6-28 Paramétrage du connecteur Fichier
188 Réalisation PARTIE III Append (ajout) spécifie que les enregistrements entrants sont ajoutés au contenu du fichier au fur et à mesure de leur arrivée. Nous rappelons que ce fichier est copié toutes les 24 heures dans le répertoire qui est réellement scruté par l outil d ETL. Append To Default File (ajout au fichier par défaut) spécifie que les enregistrements sont ajoutés au fichier par défaut, déterminé par la propriété Default File. Archive Directory (répertoire d archivage) précise le répertoire d archivage après traitement. Le fichier étant copié par l outil d ETL vers une autre destination, cette propriété n est pas spécifiée. Commit After (validation après écriture) est placée à Faux, le contexte n étant pas transactionnel. Default File : le nom du fichier à écrire. File Encoding (encodage du fichier) : le mode d encodage. Log Level (niveau de journalisation) : placé ici à un niveau moyen. Output directory (répertoire de sortie) : le répertoire dans lequel est écrit le fichier. Overwrite (surcharge du fichier existant) : placé ici à Faux, la surcharge étant de toute façon invalidée du fait de l écriture en mode Append. Paramètres généraux Une fois le développement effectué, certaines propriétés du modèle doivent être fixées pour en assurer un fonctionnement optimal. Ces propriétés sont souvent directement gérées au niveau du processus exécutable. La figure 6-29 montre les paramètres de démarrage et d instance du modèle. Figure 6-29 Paramètres de démarrage du modèle
Les connecteurs applicatifs CHAPITRE 6 189 On y voit clairement que ce processus est un processus Java dont on peut modifier les paramètres de ligne de commande. Host Name permet un déploiement à distance du processus. Unsecurity Mode détermine si les privilèges doivent être vérifiés au lancement. Statistiques et fichiers de journalisation sont aussi fixés depuis l onglet de propriétés du modèle. Ainsi, les statistiques sont publiées par défaut sur un canal dédié, statschannel, comme le montre la figure 6-30. Figure 6-30 Paramètres de statistiques d exploitation technique Le canal de statistiques est un canal présent par défaut à l installation dans le répertoire principal d administration du référentiel, comme le montre la figure 6-31. Figure 6-31 Situation du canal statistique dans le référentiel Les événements enregistrés dans les journaux sont écrits par défaut dans un fichier, comme le montre la figure 6-32. Ces paramètres par défaut (statistiques sur un canal, journaux dans un fichier) peuvent complètement être modifiés, voire inversés. Enfin, la figure 6-33 montre comment gérer le nombre d instances concurrentes d un même modèle de connexion en cours d exécution.
190 Réalisation PARTIE III Figure 6-32 Paramètres de journalisation Figure 6-33 Gestion des instances concurrentes Modèle après module, la granularité de développement, de paramétrage et de déploiement est assez fine. Ceci offre une liberté certaine en terme de définition d architecture, et une souplesse considérable au niveau du tuning et de l optimisation des solutions conçues et déployées. Le point sur JCA JCA est le sigle de J2EE Connector Architecture, une API dont l objectif est de standardiser l accès aux applications d entreprise. On a beaucoup parlé de JCA comme de l équivalent de JDBC : un connecteur universel aux services applicatifs de tout type (transaction CICS, Tuxedo, services Corba ), reposant sur une interface commune de connexion (Common Connection Interface).
Les connecteurs applicatifs CHAPITRE 6 191 Le grand avantage de JCA est ainsi de permettre le développement et/ou l utilisation de connecteurs via ces appels de méthodes uniformisées. Utiliser un serveur d applications J2EE pour l invocation de ces méthodes sur les standards du monde Java est donc tout indiqué, et largement simplifié. Avec JDO (Java Data Objects), API de connexion universelle aux données, relationnelles ou non, et JDBC, le monde Java semble ainsi armé pour couvrir l ensemble du périmètre des connecteurs. Les idées reçues ont la vie dure Tout a été dit ou presque sur JCA, présenté à grands renforts médiatiques comme le facteur condamnant à terme les pure layers de l EAI. En effet, en tant que futur standard de la connectivité logicielle, JCA, en rendant inutiles tous les connecteurs propriétaires grâce auxquels les éditeurs d EAI auraient prospéré, impliquerait de facto l obsolescence de leurs produits. Ce point de vue extrêmement réducteur est une idée fausse qui cumule de nombreux effets pervers, dont le moindre n est pas de faire passer les éditeurs d EAI pour d affreux rentiers heureux de rendre leurs clients captifs par leur technologie propriétaire Or, construire et maintenir des connecteurs pour l ensemble des technologies à intégrer, pour toutes les versions utilisées par les clients, coûte chaque année à ces éditeurs une fortune en développement. Les connecteurs JCA, standardisés, sont appelés à être fournis par les éditeurs de progiciels eux-mêmes, voire des sociétés spécialisées, et non plus par les éditeurs d EAI. Ils n offriront pour leur part que la couche de connexion à leur modèle d intégration. Pour ces derniers, de ce point de vue, JCA est davantage une aubaine qu une malédiction, d autant plus que la grande majorité des offres d EAI aujourd hui repose sur un socle technique J2EE. Il n est dès lors pas étonnant de voir un éditeur comme Tibco participer au groupe de travail des spécifications JCA. État de maturité du standard Actuellement dans sa version 1.0, JCA présente encore de nombreuses limites pour être un des socles d une future architecture standard d intégration. Avant de prétendre à remplacer les connecteurs actuels, même propriétaires, JCA doit encore gagner en maturité. Plusieurs faits s opposent encore à son utilisation à grande échelle dans l entreprise : Pas de transaction asynchrone : JCA n offrant pas de niveau d asynchronisme, il n est pas envisageable de l utiliser sans le recours à un middleware asynchrone. JCA pourrait alors trouver dans JMS son complément idéal. Pour autant, le niveau de compétences et de charge nécessaire au développement d un couple JMS/JCA pour lancer un projet d intégration est tel qu on peut se poser la question d acheter ou pas un logiciel d EAI qui gère déjà tous ces aspects, et qui plus est de façon graphique. Pourquoi alors ne pas vouloir, dans le cadre d un projet, développer aussi une base de données relationnelle?
192 Réalisation PARTIE III API unidirectionnelle : toutes les requêtes doivent être lancéees par le serveur d applications. Dans le contexte d une infrastructure d intégration, les applications doivent pouvoir déclencher ou alimenter l exécution d un processus d orchestration. Dans ce cas, les appels peuvent être dynamiques : en fonction des données transmises à une application, celle-ci doit pouvoir générer des types de messages différents. L aspect unidirectionnel de JCA l empêche de tenir compte de cette génération dynamique. Manque de finesse dans la granularité des appels de fonction : le mieux est l ennemi du bien, et la volonté de créer une API la plus simple possible conduit à négliger la spécificité de chaque application. Le protocole d appel des services applicatifs devient trop grossier pour tenir compte des subtilités propres à chaque produit. Les éditeurs des applications, qui développent leurs propres connecteurs JCA sur leurs produits, sont heureux de pouvoir montrer qu ils respectent les standards, mais contraints de s accomoder d une norme finalement trop restrictive à leur yeux. À l arrivée, les équipes projet doivent produire du code pour «adapter l adaptateur» à leur besoin, ce qui est dommage. API du JDK 1.3 : JCA est une API du JDK (Java Development Kit) 1.3. Or, cette version n est pas encore massivement déployée, et comme une infrastructure d intégration est plutôt une infrastructure d entreprise, elle doit constituer un dénominateur commun à tout l environnement de connexion. Les entreprises doivent donc migrer vers JDK 1.3 avant de pouvoir lancer leur propre projet d intégration, là où les applications d EAI du marché savent s affranchir de cette contrainte. Interface graphique : les connecteurs applicatifs des éditeurs d EAI fournissent des services à valeur ajoutée et s administrent graphiquement depuis des consoles centralisées. La connectivité JCA manque encore d outils pour permettre la centralisation de ces paramétrages. Pour conclure La version 2.0 de JCA est annoncée comme devant remédier à ces lacunes, mais elle est encore principalement en phase de spécifications. De la même façon, les premières implémentations JDO arrivent, mais elles ne se coordonnent pas avec JCA. Or, nous pensons que seule une gestion fédérée du triptyque JCA/JDO/JMS peut aboutir à un socle d infrastructure d intégration intéressant. Cette gestion implique des compétences fortes autour de J2EE et de ces API, et qui ne sont pas toujours faciles à trouver sur le marché aujourd hui. A contrario, les serveurs d intégration sont aujourd hui capables de réaliser sur leur propre infrastructure une connectivité à JCA, ce qui les rend d ores et déjà opérationnels. Services Web et connecteurs On a aussi beaucoup parlé du rôle que peuvent jouer les services Web dans les architectures d intégration. Là aussi, on a entendu dire que les technologies des services Web pouvaient à terme condamner les éditeurs d EAI grâce au niveau d interopérabilité et de réutilisabilité (les services Web sont des composants) offert.
Les connecteurs applicatifs CHAPITRE 6 193 Néanmoins, il est clair, à la lumière de l argumentation précédemment menée sur JCA, que les services Web se situent dans la même logique. Le développement de connecteurs reste une tâche à mener comme un véritable projet, quelle que soit la technologie choisie. D autre part, il manque encore aux services Web une spécification de l interface des connecteurs, similaire à ce que représente JCA dans le monde Java (un WS-Connector, en quelque sorte). L avantage des services Web se situe néanmoins clairement dans leur capacité à fournir un niveau d invocation et d interopérabilité à des technologies qui ne sont pas prises en compte dans toutes les plates-formes d EAI du marché. Trois cas sont ainsi clairement identifiés : La connectivité aux systèmes centraux. La connectivité aux composants pour lesquels la plate-forme d EAI ne propose pas d interconnectivité native. La connectivité aux services distants (périmètre initial des services Web). Dans les deux premiers cas, il s agit de proposer un moyen technique commode pour accéder à des services pour lesquels il n existe peut-être pas de connecteurs probants sur la plate-forme d EAI sélectionnée. En effet, nous le voyons dans la démarche globale d intégration, il serait ennuyeux d exclure une plate-forme qui rendrait par ailleurs les meilleurs services, pour la raison qu elle ne propose pas de connecteur, ou pas de connecteur performant, sur les technologies qu on a besoin d intégrer. Graphiquement, le rôle des services Web peut se représenter de la façon suivante : Figure 6-34 Rôle des services Web dans les architectures EAI
194 Réalisation PARTIE III Un autre domaine d application des services Web dans l EAI est envisageable au niveau des séquences de tâches, dans la possibilité de modéliser des enchaînements de processus (notamment par le biais de langages comme WSFL). La partie gauche de la figure cidessus se retrouve alors modélisée sous la forme d un service Web. Il s agit d un choix d architecture fort qui concerne lui aussi une implémentation spécifique, qu on retrouve dans certaines offres progicielles comme celle de Iona. Cet aspect sera repris dans le chapitre 8, consacré aux processus métier et à leur implémentation au sein d une plateforme d EAI, et surtout dans le chapitre 15. Conclusion Les connecteurs applicatifs sont un des fondements et une des raisons d être des progiciels l EAI. C est bien grâce à eux que la «greffe» d une EAI dans le système d information peut réussir et que celui-ci, grâce à sa capacité à récolter et à injecter des données dans les applications métier, devient un système communicant et fédéré : un système nerveux d entreprise. Grâce à ce chapitre, nous avons pu, au travers d un exemple, mesurer les processus à mettre en œuvre pour déployer ce que nous avons nommé le socle d infrastructure de déploiement. Nous avons vu que cette mise en œuvre se conduit, en ce qui concerne les connecteurs applicatifs, de façon graphique et centralisée au sein d une console de gestion. Le travail de paramétrage effectué réduit à néant la nécessité de développer la moindre ligne de code. Bien sûr, il n en va pas toujours ainsi, et certains cas complexes nécessitent l écriture de quelques lignes de code qui seront invoquées depuis le connecteur.