Présentation de BizTalk Server 2009

Présentation de BizTalk Server 2009 Mars 2009 David Chappell, Chappell & Associés 2006 Microsoft Corporation. Tous droits réservés.

Sommaire LE DÉFI : AMÉLIORER LES PROCESSUS MÉTIER... 3 RÉSOUDRE LE DÉFI : CE QU APPORTE BIZTALK SERVER 2009... 4 Intégration d applications dans un monde orienté service... 4 Intégration entre entreprises (B2B)... 7 Gestion des processus métier... 7 CONNEXION DE SYSTÈMES... 10 Envoi et réception de messages : les adaptateurs... 10 Traitement des messages : les pipelines... 11 Traduction des messages : mappage de données... 11 MISE EN UVRE DE PROCESSUS MÉTIER... 13 Utilisation des orchestrations... 13 Utilisation du moteur de règles d entreprise... 15 CRÉATION DE CONFIGURATIONS CAPABLES DE MONTER EN CHARGE... 17 CRÉATION ET GESTION DES APPLICATIONS BIZTALK... 18 Création d applications... 18 Gestion des applications... 18 CONTRÔLE BAM (BUSINESS ACTIVITY MONITORING)... 20 UTILISATION D EDI... 22 EXPLOITATION DE RFID... 23 INFRASTRUCTURE POUR DES ARCHITECTURES ORIENTÉES SERVICE (SOA)... 25 AUTHENTIFICATION UNIQUE DE L ENTREPRISE (ENTERPRISE SINGLE SIGN-ON)... 26 2

Vue d ensemble de BizTalk Server 2009 Aucune application n est isolée. Bien au contraire, faire fonctionner ensemble toutes les applications de l entreprise est devenu aujourd hui un objectif pour la plupart des responsables informatiques. Mais connecter des logiciels ne se réduit pas à échanger des octets. Les entreprises évoluant vers un monde orienté services, l objectif réel créer des processus métier efficaces qui réunissent des systèmes disparates et hétérogènes en un tout cohérent est désormais envisageable. BizTalk Server 2009 permet d atteindre cet objectif. Comme ses prédécesseurs, cette sixième version de BizTalk Server permet de connecter diverses applications, puis de créer, d exécuter et de contrôler une logique de processus qui exploite ces applications. L objectif consiste à aider les entreprises à créer des processus métier mieux automatisés. Le défi : Améliorer les processus métier La grande majorité des processus métier modernes repose sur des logiciels. Dans la plupart des entreprises, ces logiciels ont été créés à des époques différentes, avec différentes technologies sur différentes plateformes. Par conséquent, l automatisation des processus métier nécessite de connecter des systèmes hétérogènes. Pour cela, il est nécessaire de résoudre de nombreux problèmes, aucun d eux n étant simple. Une approche efficace consiste à mettre en uvre une plateforme d intégration centrale capable d extraire des informations de tous les systèmes utilisés dans les processus métier. Cette technologie doit être capable de : Se connecter à divers logiciels en mettant en uvre diverses approches. Les services Web peuvent constituer la meilleure solution pour certaines connexions, le partage de fichiers peut être meilleur pour d autres tandis que certaines applications ont besoin d échanger des messages. Se connecter à des applications métier présente souvent des problèmes importants et spécifiques qui doivent être résolus. Prendre en charge l exécution de processus automatisés. Un élément doit héberger la logique qui pilote un processus métier intégré, et une plateforme d intégration représente un choix évident pour jouer ce rôle. Certes, l exécution du processus dans sa globalité est en réalité répartie sur les différents systèmes impliqués, mais une plateforme d intégration met en uvre la logique centrale qui supervise ce processus. Permettre le plus simplement possible des connexions avec des applications situées dans d autres organisations. Cela suppose la prise en charge de standards de communications interentreprises tels que EDI (Electronic Data Interchange), et la fourniture de services qui simplifient la connexion entre partenaires commerciaux. Réaliser un contrôle en temps réel des processus métier. En plus d héberger la logique qui coordonne un processus, une plateforme d intégration doit aussi être l emplacement central pour superviser l état de ce processus. Ce suivi d activité permet aux professionnels de l information ceux qui sont particulièrement concernés par ce processus de suivre exactement ce qui se passe. Gérer des événements en provenance du monde physique, comme ceux générés par des étiquettes d identification par radiofréquence (RFID). Connecter ces événements aux applications existantes est important dans un assez grand nombre de situations. 3

L objectif de BizTalk Server 2009 consiste à aider les entreprises à améliorer leurs processus métier en résolvant ces problèmes, ainsi que d autres. La prochaine section explique dans les grandes lignes son fonctionnement. Résoudre le défi : Ce qu apporte BizTalk Server 2009 Commençons par diviser en trois parties le problème consistant à créer des processus métier mieux automatisés : Connexion des applications au sein d une même entreprise, partie désignée par le terme d EAI (Enterprise Application Integration). Les organisations évoluant de plus en plus vers une architecture orientée service (SOA), l approche de l EAI devient également orientée service. Connexions des applications entre organisations. On parle d intégration B2B (business to business). Prise en charge de l approche globale pour travailler avec des processus métier automatisés, ce qui est défini par la gestion de processus métier (BPM). Comprendre BizTalk Server 2009 revient à comprendre comment ce produit travaille dans chacune de ces parties. Intégration d applications dans un monde orienté service Qu elle soit analysée du point de vue de la SOA ou du point de vue plus traditionnel de l EAI, la prise en charge de processus métier automatisés requiert l intégration d applications. La figure 1 représente les principales technologies de BizTalk Server 2009 qui permettent cela : la messagerie et l orchestration. Figure 1 : BizTalk Server 2009 apporte les services de messagerie et d orchestration, des outils de conception, et d autres éléments. La fonction de messagerie se compose de plusieurs parties, l une d elles étant constituée d un ensemble d adaptateurs. Un adaptateur met en uvre une technologie de communication particulière, par exemple un service Web, ou il est conçu pour interagir avec une application métier spécifique, par exemple l ERP de SAP. Quel que soit l adaptateur utilisé, chaque message transite via un pipeline qui 4

peut le transformer de différentes façons. Pour permettre la traduction entre les différents formats utilisés par les applications, la fonction de messagerie assure le mappage de données. En utilisant divers outils graphiques, un développeur crée des pipelines, définit des mappages et contrôle d autres aspects des échanges de messages. Bien que beaucoup de problèmes puissent être résolus uniquement par la fonction messagerie de BizTalk Server 2009, d autres nécessitent la création d une logique qui pilote un processus métier. Les orchestrations représentent cette logique. Comme le montre la figure 1, les développeurs BizTalk utilisent un outil graphique nommé Concepteur d orchestration pour créer et modifier ces définitions de processus. Les développeurs jouent un rôle important dans BizTalk Server. Mais il est important de comprendre que les analystes métier et les administrateurs jouent aussi des rôles essentiels. Par exemple, un analyste métier devrait définir au départ les règles et les comportements qui définissent un processus métier. Il détermine aussi le workflow des processus métier, en définissant les informations à transmettre à chaque application et comment un document métier est mappé à un autre. Dès lors qu un analyste métier a défini ce processus, un développeur peut créer une application BizTalk pour le mettre en uvre. Cela inclut des tâches comme choisir un ou plusieurs adaptateurs, définir les mappages de données pour les documents qui seront utilisés, et créer les orchestrations nécessaires pour implémenter la logique du processus. Un administrateur déploie ensuite l application BizTalk, établit la communication entre les systèmes et effectue quelques tâches annexes. Ces trois rôles analyste métier, développeur et administrateur sont nécessaires pour créer et assurer la maintenance des solutions BizTalk Server 2009. La figure 2 montre un exemple simple où BizTalk Server 2009 résout un problème d intégration. Dans ce scénario, une application de gestion de stock, fonctionnant sur un ordinateur IBM, détecte que le nombre de pièces en stock pour une référence est trop bas. Elle émet donc une requête pour en commander. Cette requête est envoyée à une orchestration BizTalk Server 2009 (étape 1), qui envoie un message à l application ERP de l entreprise pour demander un bon de commande (étape 2). L application ERP, qui fonctionne sur un système UNIX par exemple, envoie en retour le bon de commande demandé (étape 3). L orchestration informe une application de gestion des commandes, installée sur Windows avec.net Framework, que l élément peut être commandé (étape 4). Figure 2 : BizTalk Server 2009 peut servir à automatiser un processus métier qui met en jeu plusieurs applications sur différentes plateformes. Dans cet exemple, chaque application peut communiquer via un protocole différent. BizTalk Server 2009 est capable de dialoguer avec chacune dans son protocole de communication natif, en utilisant l adaptateur adéquat. Notez aussi qu aucune application ne voit le processus métier dans son 5

ensemble. L intelligence requise pour coordonner tous les logiciels impliqués est mise en uvre dans l orchestration BizTalk Server 2009. Comment cela fonctionne-t-il dans un monde orienté service? Une possibilité est que les applications interagissent de façon plus cohérente en utilisant des services Web standards. Par ailleurs, le rôle du serveur central d intégration peut être considéré sous un autre angle. Généralement, une technologie d intégration dans un environnement orienté service se nomme bus de service d entreprise (ESB) et BizTalk Server 2009 peut fonctionner de cette manière. Pour aider, Microsoft fournit des architectures de référence et des conseils pour ESB. Qu une entreprise suive ou non une approche orientée service, la gestion de la technologie de l intégration est essentielle. Pour la faciliter, BizTalk Server 2009 inclut la console Administration BizTalk qui permet aux développeurs et aux administrateurs de contrôler et de gérer l application. Et pour faciliter la navigation dans la jungle des technologies d ouvertures de session que toutes ces applications utilisent, BizTalk Server 2009 inclut un outil permettant une authentification unique. Cette technologie mappe les informations d authentification entre les systèmes Windows et non-windows. BizTalk Server prend aussi en charge des applications qui exploitent RFID, l identification par radiofréquence. Les étiquettes RFID peuvent être collées sur des palettes dans un entrepôt, sur des produits en étagères, et sur bien d autres choses, puis elles sont utilisées par des applications qui suivent leurs cheminements. Pour faciliter la création de ces applications, BizTalk Server 2009 inclut un serveur RFID. Toutes ces technologies sont utiles pour connecter des applications à l intérieur d une entreprise. La plupart d entre elles s appliquent aussi à la connexion d applications et de processus métier automatisés entre entreprises. La prochaine section examine comment BizTalk Server 2009 gère cet objectif. 6

Intégration interentreprises (B2B) Connecter des applications entre elles au sein d une entreprise constitue une avancée importante, mais connecter des applications entre organisations présente au moins autant de valeur. La figure 3 illustre ce genre d intégration B2B. Le client en haut de la figure exécute une orchestration BizTalk Server 2009 qui contrôle un processus métier. Ce processus permet au client d acheter des produits auprès de deux fournisseurs. Le fournisseur A utilise aussi BizTalk Server 2009 pour permettre un accès indirect à son application ERP. Les deux systèmes utilisent un adaptateur BizTalk approprié pour communiquer via des services Web. Le fournisseur B utilise une plateforme d intégration d un autre fournisseur. La connexion avec l orchestration BizTalk du client s effectue par des services Web ou par un autre mécanisme. Figure 3 : BizTalk Server 2009 peut servir à établir des connexions entre des applications d entreprises différentes. EDI (Electronic Data Interchange) constitue aujourd hui un élément fondamental des communications interentreprises. Dès l origine, BizTalk Server a largement pris en charge EDI via des produits tiers. À partir de la version 2006 R2, Microsoft a inclus la prise en charge directe d EDI dans son produit, ainsi qu un outil facilitant la gestion des relations avec les partenaires EDI. BizTalk Server 2009 fournit aussi des accélérateurs qui aident à mettre en uvre d autres standards largement répandus comme RosettaNet, SWIFT et HL7. Chaque accélérateur inclut des définitions de messages prédéfinies respectant le standard, ainsi que des exemples et des conseils. Gestion des processus métier Intégrer des applications dans un processus métier unique et automatisé est l objectif premier de BizTalk Server 2009. Mais aujourd hui, ce problème est considéré comme faisant partie d un ensemble plus vaste, celui de la gestion des processus métier. Cette dernière approche va au-delà de l intégration. Comme le montre la figure 4, BizTalk Server 2009 prend aussi en charge deux technologies importantes pour la gestion des processus métier : un moteur des règles d entreprise (BRE) et un contrôle d activité métier (BAM). 7

Figure 4 : BizTalk Server 2009 inclut un BRE et prend en charge BAM. Comme tous les moteurs de règles, le moteur de règles BRE de BizTalk Server 2009 permet d évaluer des ensembles de règles. Bien qu il soit tout à fait possible de définir une logique métier en utilisant uniquement le Concepteur d Orchestration BizTalk, certaines applications ont besoin d évaluer un ensemble complexe et changeant de règles. Une souscription d assurance et un dossier de prêt en sont des exemples parmi d autres. L objectif du moteur BRE de BizTalk est de mieux prendre en charge ce genre de processus. Par ailleurs, lorsqu un processus est mis en uvre, les utilisateurs ont souvent besoin de connaître certaines statistiques sur son fonctionnement. Combien de commandes ont été traitées au cours des cinq dernières minutes? Combien de clients n ont pas pu accéder au service au cours de la dernière heure? Ce genre d informations en temps réel peut apporter aux professionnels de l information pas uniquement au personnel informatique une valeur métier importante. C est pour fournir ces renseignements que BizTalk Server 2009 intègre les services BAM. Comme le montre la figure 4, Les informations fournies par BAM sont accessibles via des outils standards comme Microsoft Excel, Office PerformancePoint Server et d autres. BizTalk Server est aussi capable d extraire des données BAM à partir d applications qui exploitent Windows Communication Foundation (WCF) et Windows Workflow Foundation (WF). Comme ses prédécesseurs, BizTalk Server 2009 connecte des applications, il est donc au c ur des workflows. Cependant, un principe fondamental de BPM est que la plupart des processus métier incluent à la fois des workflows humains et des workflows système. BizTalk Server 2009 en tient compte : il peut se connecter à des workflows humains exploitant la dernière version de Windows SharePoint Services. Via un adaptateur SharePoint, cette connexion permet aux entreprises de créer des processus métier automatisés qui incluent à la fois les workflows humains et système. Dans le monde actuel complexe et très diversifié des logiciels d entreprise, la combinaison de ces deux approches est indispensable à beaucoup d organisations. 8

Les fondamentaux de BizTalk Server 2009 Nous venons de décrire les problèmes auxquels s attaque BizTalk Server 2009. Pour aller plus loin, étudions les mécanismes sur lesquels repose cette technologie. Commençons avec les bases de la circulation d un message (figure 5). Figure 5 : Un message est reçu par un port de réception, traité éventuellement par une orchestration et émis par un port d envoi. Comme le montre la figure, un message est reçu par un port de réception. Chaque port de réception a trois composants : Un adaptateur qui sait communiquer d une façon spécifique. Un pipeline de réception capable d effectuer des opérations comme convertir le message de son format natif en document XML, valider la signature numérique du message, etc. Un mappage de données qui transforme le message de façon utile. Le message est ensuite transmis à une base de données SQL Server nommée MessageBox. De là, il peut être lu par une orchestration. Les orchestrations ne sont pas créées en écrivant du code dans un langage comme le C#. Un analyste métier ou (plus souvent) un développeur utilise un outil graphique pour créer un groupe de formes qui définissent des conditions, des boucles et d autres comportements. Bien que cela n apparaisse pas sur la figure 5, les orchestrations peuvent utiliser de façon optionnelle le moteur de règles d entreprise BRE pour évaluer des ensembles de règles complexes. Lorsqu une orchestration a traité un message, elle produit généralement un autre message destiné à d autres applications. Ce message est placé à son tour dans la base de données MessageBox puis pris en charge par un port d envoi. Un port d envoi a les trois mêmes composants qu un port de réception, et ils remplissent les mêmes fonctions : mapper le message avec son format de sortie, 9

préparer ce message pour sa transmission via un pipeline d envoi, puis le transmettre réellement au destinataire en utilisant un adaptateur d envoi approprié. Tout cela est contrôlé par des abonnements enregistrés dans la base MessageBox. Quand un message est traité par un port de réception, un contexte de message est créé. Il contient diverses propriétés de ce message. Une orchestration ou un port d envoi peuvent s abonner à des messages en fonction de la valeur de ces propriétés. Par exemple, une orchestration peut s abonner à tous les messages de type «Facture», ou à tous les messages de type «Facture» reçus de la banque Qwick, ou à tous les messages de type «Facture» reçus de la banque Qwick dont le montant est supérieur à 10 000. Un abonnement envoie à ses abonnés les seuls messages qui correspondent aux critères qui définissent cet abonnement. Un message reçu peut démarrer une orchestration ou activer une autre étape dans une autre orchestration en cours d exécution. Lorsqu une orchestration envoie un message, ce message est transmis à un port d envoi en fonction d un abonnement établi par ce port. Comme le suggère cette description, une solution complète basée sur BizTalk Server 2009 se compose de plusieurs parties, connues sous le nom d artefacts : orchestrations, pipelines, schémas de messages, etc. Pour plus de commodité, un développeur regroupe tous ces éléments en une application BizTalk. Chaque application BizTalk enveloppe tous les éléments de la solution pour n en faire qu une seule unité logique, cette abstraction simplifiant le déploiement et la gestion de la solution. BizTalk Server 2009 fonctionne sur Windows Server 2008 ou Windows Server 2003. S il fonctionne sur Windows Server 2008, BizTalk Server tire parti des dernières améliorations présentes dans cette version du système d exploitation serveur. Par exemple, la fonctionnalité Hyper-V de Windows Server 2008 permet de faire fonctionner BizTalk Server 2009 dans un système virtuel à quatre processeurs, alors que Windows Server 2003 imposait une limite à deux processeurs. De façon comparable, BizTalk Server 2009 peut utiliser SQL Server 2008 ou SQL Server 2005. En exploitant SQL Server 2008, BizTalk Server 2009 présente de meilleures performances et une meilleure prise en charge des environnements virtuels. Connexion de systèmes Les applications BizTalk utilisent des ports de réception et d envoi pour communiquer avec d autres applications. Cette section précise le fonctionnement des trois composants d un port : adaptateur, pipeline et mappage de données. Envoi et réception de messages : les adaptateurs Pour une intégration réussie, l interopérabilité avec toutes sortes d applications et de systèmes est indispensable. BizTalk Server 2009 assure cette interopérabilité via des adaptateurs. À partir des cibles avec lesquelles BizTalk doit pouvoir communiquer, le créateur d une application BizTalk détermine les adaptateurs nécessaires. Il peut choisir un adaptateur parmi tous ceux fournis avec BizTalk Server 2009, utiliser un adaptateur développé par un autre éditeur, ou créer le sien. Les adaptateurs les plus récents sont conçus comme des canaux WCF. Les adaptateurs de ce type livrés avec BizTalk Server 2009 prennent en charge les technologies SOAP et SOAP avec WS-* (par exemple WS-Security). Un développeur peut créer son propre adaptateur WCF en utilisant soit des canaux WCF existants soit des canaux personnalisés créés pour une utilisation précise. Microsoft fournit aussi un BizTalk Adapter Pack qui inclut des adaptateurs WCF pour SAP, Siebel, Oracle ebusiness Suite, SQL Server et la base de données Oracle. Tous ont été créés en utilisant le WCF Line-of-Business (LOB) Adapter SDK, un cadre généraliste servant à créer des adaptateurs pour des applications métier. En fait, les adaptateurs créés via ce SDK peuvent être utilisés par toute application basée sur.net Framework ; BizTalk Server n est pas nécessaire. 10

BizTalk Server 2009 inclut aussi tout un ensemble d adaptateurs non WCF. Par exemple, l adaptateur MSMQ permet d envoyer et de recevoir des messages via Microsoft Message Queuing (MSMQ) tandis qu un adaptateur WebSphere MQ envoie et reçoit des messages en utilisant WebSphere MQ d IBM. De même, les adaptateurs SMTP et POP3 permettent d envoyer et de recevoir des courriels en utilisant ces protocoles standards. D autres adaptateurs facilitent l interaction avec des mécanismes de stockage répandus. Par exemple, l adaptateur Fichier permet de lire et d écrire des fichiers dans le système de fichiers Windows. Les applications impliquées dans un processus métier pouvant souvent accéder au même système de fichiers, soit en local soit via un réseau, l échange de messages via des fichiers constitue une option très pratique. L adaptateur Windows SharePoint Services permet d accéder à / de publier des documents enregistrés dans des bibliothèques de documents SharePoint. Ce produit inclut aussi un adaptateur pour échanger des informations avec des bases de données DB/2 d IBM. Une autre catégorie d adaptateurs non WCF permet d établir des connexions avec des applications métier largement répandues. BizTalk Server 2009 fournit ce type d adaptateur notamment pour l ERP de SAP, ebusiness Application de Siebel, PeopleSoft, et OneWorld de JD Edwards. BizTalk fournit aussi des adaptateurs pour des systèmes hôtes ; cela permet d établir des connexions avec des applications fonctionnant sur des systèmes zseries ou iseries d IBM. Quel que soit l adaptateur de réception utilisé pour les données entrantes, les messages reçus doivent généralement être traités avant qu ils puissent être exploités par une orchestration. De même, les messages sortants produits par une orchestration ont souvent besoin d être mis en forme avant d être transmis à un adaptateur d envoi. Ces deux types de traitement mettent en uvre des pipelines. Traitement des messages : les pipelines Les applications qui composent un processus métier communiquent en échangeant différentes sortes de documents, comme des bons de commande, des factures et bien d autres éléments. Pour qu une application BizTalk gère ce processus, elle doit être capable de prendre en charge correctement les messages qui contiennent ces documents. Le traitement requis pour cela implique plusieurs étapes ; il est exécuté par un pipeline de message. Les messages entrants sont traités par un pipeline de réception tandis que les messages sortants sont traités par un message d envoi. Par exemple, bien qu il existe de plus en plus d applications qui savent interpréter les documents XML, beaucoup ne le peuvent pas encore. Puisque BizTalk Server 2009 travaille en interne avec des documents XML, il doit fournir un moyen de convertir toutes sortes de formats en XML et réciproquement. D autres services sont aussi nécessaires, comme celui d authentifier l expéditeur d un message. Pour gérer ces tâches et d autres de façon modulaire, un pipeline se compose d un certain nombre d étapes, chacun contenant un ou plusieurs composants. Chaque composant gère une partie du traitement du message et BizTalk Server 2009 fournit des composants standards couvrant déjà de nombreux cas. Si cela ne suffit pas, les développeurs peuvent aussi créer des composants personnalisés pour les pipelines de réception et d envoi. BizTalk Server 2009 définit quelques pipelines par défaut, y compris une paire simple de réception/envoi qui peut servir à gérer des messages déjà exprimés en XML. Un développeur crée des pipelines personnalisés via le Concepteur de pipeline. Cet outil, qui fonctionne dans Visual Studio, fournit une interface graphique qui permet de faire glisser des composants afin de créer des pipelines en fonction du comportement recherché. Traduction des messages : mappage de données Les pipelines convertissent les documents externes en XML ou le XML en documents, lorsque cela est nécessaire. C est au développeur de définir la représentation XML nécessaire, c est-à-dire de définir le schéma qui doit être utilisé. Les schémas sont définis en langage XSD (XML Schema Definition). C est 11

un moyen puissant mais complexe pour décrire la structure d un document XML et les types qu il contient. Pour simplifier la création de schémas en XSD, BizTalk Server 2009 fournit un outil nommé Éditeur BizTalk. Grâce à cet éditeur, au lieu de créer un schéma directement en XSD, le développeur peut construire un schéma en définissant ses éléments dans une hiérarchie graphique. Des schémas existants peuvent aussi être importés depuis des fichiers ou des services Web. Une fois que les messages correspondent à un schéma XML connu, il est possible d effectuer des mappages (des correspondances) entre eux. Par exemple, la plupart des informations contenues dans un document reçu doivent être transférées dans un document envoyé, parfois en subissant quelles transformations. Pour cela, le développeur crée des mappages. Chaque mappage exprime une corrélation entre deux schémas XML et définit une relation entre des éléments de ces schémas. Le Consortium W3C a défini XSLT (Extensible Stylesheet Language Transformation) comme un standard pour exprimer ces transformations entre des schémas XML. Par conséquent, les mappages dans BizTalk Server 2009 sont mis en uvre sous la forme de transformations XSLT. Les mappages sont utilisés de différentes façons. Supposons, par exemple, que les informations contenues dans un bon de commande entrant doivent être mappées avec un bon de commande sortant. Un développeur crée un mappage pour cela, puis invoque ce mappage dans le pipeline d envoi ; aucune orchestration n est requise. Dans un cas plus complexe qui nécessite une logique métier, le mappage peut être appelé par l orchestration. Par exemple, le processus d exécution d une commande peut recevoir un bon de commande pour certains éléments, puis renvoyer un message indiquant que cette commande est refusée pour certaines raisons. Il est possible que certaines informations en provenance du bon de commande entrant, comme le numéro de la commande, une référence d article et une quantité commandée, soient copiées dans certains champs du message de rejet. Un mappage est simplement écrit en XSLT, il est donc possible de l écrire à la main. Mais pour simplifier cette tâche, BizTalk Server 2009 fournit un outil graphique nommé Mappeur BizTalk. La figure 8 montre à quoi ressemble un mappage pour transférer des informations d une base de données de contacts dans une application de gestion de la relation clients. Figure 6 : Le Mappeur BizTalk spécifie comment les informations d un message sont mises en correspondance avec celles d un autre message. La transformation définie dans un mappage peut être simple, comme copier des valeurs d un document dans un autre sans les modifier. Une copie directe de données est exprimée par un lien, ce qui est représenté dans le Mappeur BizTalk par une ligne connectant les éléments appropriés du 12

schéma source avec leurs homologues dans le schéma destination. La plupart des lignes de la figure 8 représentent ces liens. Des transformations plus complexes mettent en uvre des fonctoids. Un fonctoid est un morceau de code exécutable qui sert à définir des mappages complexes entre schémas XML. Dans le haut de la figure 8, le Mappeur BizTalk représente un fonctoid sous la forme d une boîte sur la ligne qui connecte les éléments. Certaines transformations étant assez courantes, BizTalk Server 2009 inclut en standard des fonctoids pour effectuer des conversions, des opérations mathématiques et d autres tâches. Définir le schéma d un document XML est essentiel ; il en est de même pour le mappage des informations entre des schémas différents. L Éditeur BizTalk et le Mappeur BizTalk répondent à ces deux exigences. Mais pour certaines applications, la définition des schémas et des mappages ne suffit pas ; il faut adjoindre à cet ensemble une logique métier. C est l objet de la prochaine section. Mise en uvre de processus métier L envoi de messages entre des systèmes différents est essentiel pour résoudre les problèmes auxquels s attaque BizTalk Server 2009. Bien que de nombreuses applications puissent déjà être construites en utilisant uniquement les capacités de messagerie du produit, d autres nécessitent la définition et l exécution d une logique supplémentaire. Cette section décrit les technologies employées par BizTalk Server 2009 pour permettre cela. Utilisation des orchestrations En général, il est toujours possible de créer un processus automatisé dans un langage comme le C# ou Visual Basic. Toutefois, écrire, maintenir et gérer sur le long terme des processus métier créés dans des langages de programmation conventionnels peut constituer un véritable défi. Comme ses prédécesseurs, BizTalk Server 2009 ne suit pas cette approche. Il permet de créer une logique de façon graphique. Cette façon de faire est plus efficace que programmer de façon conventionnelle, et elle simplifie la compréhension du processus et ses modifications ultérieures. Réussir la création d un processus automatisé nécessite généralement la collaboration entre des développeurs et les utilisateurs du processus. Pour faciliter les choses, BizTalk Server 2009 fournit un outil pour chacun. L outil du développeur fonctionne dans Visual Studio, un environnement familier pour les développeurs professionnels. Pour les utilisateurs du processus, Visual Studio n est pas particulièrement compréhensible ; aussi, BizTalk Server 2009 leur fournit un module additionnel pour Visio, qui représente un sous-ensemble de l outil pour développeur. Une orchestration créée dans l outil Visual Studio peut être importée dans l outil Visio et vice-versa. Ainsi, développeurs et utilisateurs se comprennent mieux. Ramené à l essentiel, chaque processus métier se compose d actions qui répondent ensemble à un besoin métier. Le Concepteur d orchestration de BizTalk Server 2009 permet à un développeur de définir ces actions en connectant ensemble une série de formes de façon logique. Voici quelques exemples de formes disponibles pour un créateur d orchestration : La forme Réception, qui permet à une orchestration de recevoir des messages. La forme Envoi, qui permet à une orchestration d envoyer des messages. La forme Port, qui définit comment les messages sont transmis. Chaque instance d une forme Port est connectée soit à une forme Envoi soit à une forme Réception. Chaque port a aussi un type, qui définit par exemple les genres de messages que ce port peut recevoir, et une liaison, qui détermine comment un message est envoyé ou reçu (en spécifiant par exemple une URL). 13

La forme Décider, qui représente une instruction if-then-else (si-alors-sinon) afin qu une orchestration puisse réaliser des tâches différentes selon des conditions booléennes. Un Éditeur d expression, élément du Concepteur d orchestration, sert à spécifier ces conditions. La forme Boucle, qui permet de réaliser une action de façon répétitive tant qu une condition est vraie. La forme Transformer, qui permet de transférer des informations d un document dans un autre, tout en le transformant au passage via des mappages définis avec le mappeur BizTalk. La forme Actions parallèles, qui permet de spécifier que plusieurs opérations doivent être réalisées en parallèle plutôt qu en séquence. La forme qui la suit ne sera pas exécutée tant que toutes les actions parallèles ne seront pas terminées. La forme Étendue, qui permet de grouper des opérations en transactions et de définir des gestionnaires d exceptions pour le traitement des erreurs. Il existe deux types de transactions : les transactions atomiques et les transactions de longue durée. Contrairement aux transactions atomiques, les transactions de longue durée utilise une logique de compensation plutôt que de restauration pour gérer des événements inattendus. La forme Assignation du message, qui permet d assigner des valeurs à des variables de l orchestration. Ces variables servent à stocker des informations d état utilisées par l orchestration, comme un message ou une chaîne de caractères en cours de création. La figure 9 montre une orchestration, créée dans le Concepteur d orchestration, qui utilise quelquesunes de ces formes. Dans cet exemple simple, un message est reçu, une décision est prise en fonction du contenu du message, et un chemin sur les deux possibles est exécuté. Les orchestrations mises en uvre dans le monde réel sont souvent bien plus complexes que cela. Le Concepteur d orchestration sait gérer cette complexité en proposant des fonctions comme le zoom qui permet à un développeur de ne faire apparaître que les parties de l orchestration sur lesquelles il travaille. Lorsqu un développeur a défini une orchestration, l ensemble des formes et des relations est converti en un assembly standard.net. Il est bien sûr toujours possible d ajouter explicitement du code à une orchestration en invoquant un objet.net à partir d une forme. 14

Figure 7 : Le Concepteur d orchestration permet à un développeur de créer une logique métier par simple glisser-déposer de formes à partir de la boîte à outils. Les services Web basés sur SOAP ont eu un grand impact sur le développement d applications. Pour accéder à un service Web externe, le créateur d une orchestration peut utiliser l option Ajouter une référence Web dans Visual Studio, avec l adaptateur SOAP. BizTalk Server 2009 inclut aussi un Assistant Utilisation de service WCF, pour créer des orchestrations qui utilisent des services exposés via SOAP ou via tout autre mécanisme pris en charge par WCF. BizTalk propose aussi un Assistant Publication de service WCF, qui aide le développeur dans les étapes requises pour exposer une ou plusieurs opérations d une orchestration en tant que services WCF. Les orchestrations constituent le mécanisme fondamental pour créer des processus métier dans BizTalk Server 2009. Mais il est nécessaire de pouvoir facilement définir et modifier les règles métier contenues dans une orchestration. C est le rôle du moteur de règles d entreprise (BRE Business Rule Engine) décrit dans la prochaine section. Utilisation du moteur de règles d entreprise Le Concepteur d orchestration est un outil puissant pour définir un processus métier. Toutefois, certains aspects d une orchestration changent plus souvent que d autres. En particulier, les décisions incluses dans un processus les règles métier ont souvent un aspect volatil. Par exemple, la limite des dépenses autorisées pour un responsable était de 100 000 la semaine dernière, mais elle vient de passer à 500 000 ; ou la limite crédit d un client vient de baisser de 10 000 à 1 000. Nous avons besoin d un moyen simple pour changer ces règles. Ce moyen, c est le moteur de règles d entreprise (BRE) inclus dans BizTalk Server 2009. 15

Le moteur BRE est très utile lorsqu un ensemble complexe de règles métier doit être évalué. Par exemple, accorder un prêt peut entraîner un gros travail sur un vaste ensemble de règles qui tiennent compte de l historique du client, de ses revenus et de nombreux autres paramètres. De même, déterminer le tarif d une assurance décès dépend de l âge, du sexe et de nombreux éléments sur la santé du client. Exprimer toutes ces règles en tant qu expressions conditionnelles dans des formes Décider au sein d une orchestration serait possible mais complexe. Pour des processus mettant en uvre de nombreuses règles comme celles-ci, le moteur BRE simplifie le travail du développeur. Le moteur des règles d entreprise permet aussi de modifier ces règles de façon rapide et simple. Pour bien comprendre, étudions d abord ce que nous devons faire pour modifier une règle métier incorporée dans une orchestration. Le développeur doit ouvrir l orchestration dans Visual Studio, modifier toutes les formes concernées (et peut-être les objets.net qu elles invoquent), puis reconstruire l assembly et le déployer. Cela nécessite d arrêter et de redémarrer l application BizTalk qui inclut cette orchestration. Au lieu de cela, si la règle est définie via le moteur BRE, elle peut être modifiée sans avoir à recompiler l assembly ou à redémarrer l application. Il suffit de modifier la règle concernée et de redéployer le nouvel ensemble de règles. Ce changement prend effet immédiatement. De plus, les orchestrations sont créées et gérées par les développeurs tandis que les règles métier sont suffisamment lisibles pour être comprises et modifiées par les analystes métier, sans nécessiter l intervention du personnel technique. Le créateur d un ensemble de règles d entreprise utilise d abord l Éditeur des règles d entreprise pour définir un vocabulaire qui servira à spécifier ces règles. Chaque terme du vocabulaire nomme de façon facilement compréhensible une information. Par exemple, un vocabulaire définit des termes comme Quantité livrée, Quantité maximale, Limite autorisée, etc. Chacun de ces termes peut être : une constante ; un mappage à un élément particulier ou à un attribut dans un schéma XML (et donc à un message entrant) ; le résultat d une requête SQL sur une base de données ; ou même une valeur dans un objet.net. Lorsqu un vocabulaire a été défini, l Éditeur de règles entre en scène pour créer des stratégies d entreprise qui exploitent ce vocabulaire. Chaque stratégie contient une ou plusieurs règles. Une règle utilise les termes d un vocabulaire et des opérateurs logiques comme Supérieur à, Inférieur à, Est égal à. Une règle peut définir comment des valeurs contenues dans un document XML reçu peuvent affecter les valeurs créées dans un document XML à envoyer, ou le contenu d une base de données ou d autres éléments. Par exemple, imaginons un vocabulaire simple qui définisse les termes Quantité maximale commandée autorisée, avec une valeur à 100, et Quantité demandée, avec une valeur obtenue à partir d un élément XML dans les documents reçus. Un analyste peut créer une règle qui spécifie que si la Quantité demandée d une commande reçue est supérieure à la Quantité maximale commandée autorisée, la commande doit être refusée. Cela peut entraîner l envoi d un document XML spécifique en fonction du demandeur à l origine de cette commande. Pour exécuter une stratégie d entreprise, une orchestration utilise une forme RèglesAppel. Cette forme crée une instance du BRE, spécifie quelle stratégie doit être exécutée, puis fournit les informations dont cette stratégie a besoin, par exemple un document XML reçu. Le moteur de règles peut aussi être utilisé par programmation via un modèle objet.net qui permet de l invoquer à partir d applications qui n utilisent pas BizTalk Server 2009 (bien qu une licence BizTalk Server soit requise pour utiliser le moteur de règles). Les vocabulaires et les règles d entreprise peuvent être beaucoup plus complexes et puissantes que les simples exemples décrits ici. L idée centrale reste de définir un vocabulaire, puis des règles qui utilisent ce vocabulaire via le moteur de règles d entreprise. Ainsi, les utilisateurs de BizTalk Server 2009 peuvent facilement créer des règles et les exploiter au c ur des processus métier. 16

Création de configurations capables de monter en charge Il est possible d installer chaque composant de BizTalk Server 2009 sur une seule machine. Mais on comprend facilement que ce n est pas la solution idéale. Le nombre de messages à traiter risque d être trop important pour un seul système, et la redondance peut être indispensable pour des raisons de fiabilité. Pour ces raisons, plusieurs solutions de déploiement existent. Dans le déploiement de BizTalk Server, un concept fondamental est celui d hôte. Un hôte contient différents éléments comme des orchestrations, des adaptateurs et des pipelines. Mais c est uniquement une construction logique. Pour exploiter des hôtes, un administrateur BizTalk doit créer des instances d hôte. Chaque instance d hôte est un processus Windows et, comme le montre la figure 10, une instance contient différents éléments. Dans notre exemple, le système A accueille deux instances. L un contient un port de réception, l autre contient les orchestrations P et Q. Le système B exécute une seule instance d hôte, contenant aussi les orchestrations P et Q. Le système C, comme le système A, héberge deux instances mais aucune d elles ne contient d orchestration. Elles contiennent chacune un port d envoi différent. Pour terminer, le système D héberge la base de données MessageBox utilisée par toutes les instances d hôtes dans cette configuration. Figure 8 : Une installation de BizTalk Server peut être répartie sur plusieurs hôtes et sur plusieurs systèmes physiques. Cet exemple illustre plusieurs façons d utiliser les hôtes. Par exemple, puisque les deux systèmes A et B hébergent les orchestrations P et Q, BizTalk Server 2009 peut automatiquement équilibrer la charge des requêtes entre elles, en fonction de la disponibilité et de la charge de chaque système. Cela permet à une application BizTalk d évoluer en fonction des besoins vers des gros volumes de traitement. Notez aussi que le système C contient deux ports d envoi des messages, chacun exploitant un adaptateur différent. Chaque instance d hôte étant isolée des autres instances (il s agit de processus Windows distincts), il est plus sûr d exécuter un code incertain (comme un nouvel adaptateur personnalisé) dans une instance séparée. Cet exemple ne contient qu une seule instance 17

de la base de données MessageBox mais il est bien sûr possible de répliquer cette base de données afin de permettre une meilleure montée en charge ou d éviter un point unique de panne en installant un cluster. Création et gestion des applications BizTalk Comme tout autre logiciel, une application BizTalk est créée via des outils de développement. Une fois créée, l application doit être déployée et administrée. Cette section montre comment réaliser ces tâches pour BizTalk Server 2009. Création d applications La plupart des logiciels sont créés par des équipes de développeurs. Pour cette raison, Microsoft propose Visual Studio Team System pour faciliter le travail en équipe. Au c ur de Team System se trouve TFS, Team Foundation Server, qui regroupe en un seul emplacement le code source, les tests et d autres artefacts de développement. À l origine, il n était pas possible de développer des applications BizTalk dans Visual Studio Team System. BizTalk Server 2009 change la donne et apporte toute la puissance de Visual Studio Team System aux développeurs BizTalk. Plutôt qu utiliser une approche spécifique et particulière, les développeurs BizTalk s appuient désormais sur TFS pour le contrôle des sources, utilisent le moteur de Visual Studio pour compiler leurs applications, créer des tests unitaires et les exécuter sur les artefacts BizTalk. Les gestionnaires de projets peuvent aussi exploiter Visual Studio Team System pour suivre la progression des réalisations, comme pour n importe quel autre projet de développement. Gestion des applications La console Administration de BizTalk est l outil principal pour administrer ce produit. Il s agit d un composant logiciel enfichable MMC (Microsoft Management Console) qui présente une interface utilisateur standard aux administrateurs BizTalk. Cet outil offre de nombreuses fonctionnalités dont les plus importantes sont : Le déploiement d applications BizTalk. En utilisant la console Administration de BizTalk, un administrateur peut spécifier les composants d une application BizTalk, déployer l application sur un ou plusieurs serveurs, et effectuer d autres opérations. La configuration des applications BizTalk. Lorsqu un développeur crée une orchestration, il travaille essentiellement en termes de logique. Par exemple, pour définir comment BizTalk Server 2009 communiquera avec une application particulière, le développeur sélectionne un adaptateur SOAP WCF sans s inquiéter de l URL spécifique qui sera utilisée. De même, il peut inclure dans un pipeline d envoi un composant qui ajoute une signature numérique aux messages sortants, sans savoir exactement quelle clé sera employée pour créer la signature. Mais pour que l application fonctionne réellement, ces détails doivent être précisés. La console Administration de BizTalk permet à un administrateur de créer et de modifier des détails de ce type. Le contrôle et la gestion des applications BizTalk. En utilisant la Page du groupe de la console Administration, un administrateur supervise le fonctionnement des applications BizTalk. Comme le montre la figure 11, il est possible d examiner de différentes façons l état de ces applications. Un administrateur peut examiner les applications en cours d exécution, les suspendre et les redémarrer si nécessaire. Il est aussi possible d analyser plus finement chaque application, chaque message, ou d autres détails. La Page du groupe utilise des indicateurs de couleur pour faire ressortir les problèmes potentiels. Ainsi, l administrateur peut anticiper et résoudre un problème avant qu il ne devienne bloquant. 18

Figure 9 : La Page du groupe de la console Administration de BizTalk permet à un administrateur de contrôler et de gérer les applications BizTalk. La console Administration de BizTalk propose aussi d autres services. Un administrateur peut ajouter dynamiquement d autres systèmes et associer les hôtes aux systèmes pendant qu une application BizTalk fonctionne, sans avoir à l arrêter. Les fonctions de la console Administration sont exploitables par programmation via WMI (Windows Management Instrumentation) ; un administrateur peut créer des scripts pour automatiser certaines tâches de gestion. Comme pour d autres produits serveurs Microsoft, un pack d administration BizTalk Server 2009 est disponible. Il permet le contrôle et la supervision de BizTalk via Microsoft Operations Manager 2005 ou System Center Operations Manager 2007. La console Administration de BizTalk sert à suivre les applications en cours d exécution ; mais elle permet aussi d examiner des informations d historique sur des groupes d applications. C est d ailleurs l objectif principal du composant Suivi des activités et du fonctionnement (HAT Health and Activity Tracking) de BizTalk Server 2009. Cet outil HAT donne accès à des informations consolidées sur l historique des applications BizTalk s exécutant sur un système. Les informations fournies sont, par exemple, les heures de démarrage et d arrêt des orchestrations, les exécutions de chaque forme, les envois et les réceptions de messages, les contenus des messages, etc. L outil HAT sert à examiner les données archivées, à la recherche de tendances dans l exécution d un processus. Toutes ces informations sont utiles pour le débogage, répondre à des questions métier (par exemple, vérifier qu un message a été réellement envoyé à un client), et pour l amélioration des performances. 19

Autres technologies BizTalk Server 2009 Le c ur d une application BizTalk est composé de messages et d orchestrations. Mais le produit permet d aller plus loin, en contrôlant l activité métier, en prenant en charge RFID, etc. Cette section décrit succinctement chacune de ces technologies. Contrôle BAM (Business Activity Monitoring) BizTalk Server 2009 est capable de prendre en charge des processus métier automatisés répartis sur plusieurs applications. Une fois que ces processus ont été créés, les professionnels de l information qui les exploitent (pas les développeurs) ont besoin de contrôler certains aspects métier qui dépendent de ces processus. Pour répondre à ce besoin, BizTalk Server 2009 fournit BAM (Business Activity Monitoring). Il existe différentes façons d examiner l activité d un processus métier. Par exemple, un responsable des achats pourrait rechercher combien de bons de commande sont approuvés ou refusés chaque jour tandis qu un responsable des ventes aimerait savoir à chaque heure les produits qui ont été commandés. Pour répondre à ces différents besoins, il nous faut un cadre général pour suivre ce qui se passe sur un processus métier particulier. C est exactement le rôle de BAM. Comme le suggère la figure 12, BAM peut être considéré comme composé de deux parties distinctes : Une infrastructure pour collecter des informations sur les processus métier en cours d exécution. Ces processus dépendant d autres applications et d orchestrations BizTalk, cette infrastructure doit prendre en considération tout l environnement, pas simplement BizTalk Server 2009. Des outils qui permettent aux utilisateurs d accéder à ces informations. Des employés d horizons différents souhaiteront voir les données BAM sous des angles différents et les outils qu ils utilisent peuvent être très variés. Par exemple, certains utiliseront des tableaux de bord pour afficher en temps réel des données critiques, d autres auront besoin de rapports qui affichent des tendances en fonction de l historique, et tous exploiteront des outils largement répandus comme des tableurs. 20

Figure 10 : Les données BAM sont générées par des orchestrations et d autres applications.net, et utilisées de diverses façons. La première de ces deux parties, l infrastructure qui collecte des informations sur les processus en cours d exécution, est fournie par BizTalk Server 2009. Comme le montre la figure 12, les orchestrations BizTalk génèrent directement des données BAM, stockées dans une base de données BAM. Via un outil nommé Éditeur de modèle de suivi, un développeur peut configurer une orchestration pour qu elle envoie les informations nécessaires dans cette base de données. Via une API BAM, cette infrastructure est aussi exploitable par n importe quelle application construite sur.net Framework. En plus de cette API Générale, BizTalk Server 2009 fournit des intercepteurs BAM spécifiquement conçus pour des applications qui exploitent WCF (Windows Communication Foundation) et WF (Windows Workflow Foundation). Lorsqu elles parviennent à la base de données BAM, les données sont stockées sous forme de tables et de cubes. Elles sont alors accessibles via un ensemble de services Web BAM (figure 12) et les différents clients sont libres d exploiter ces informations pour leurs besoins. Par exemple, un utilisateur d Excel les intégrera dans un tableau croisé dynamique, puis créera une vue graphique de tous les aspects du processus qu il souhaite voir. (BizTalk Server 2009 fournit un composant Excel qui facilite ce travail.) La vue pourra être mise à jour aussi souvent que nécessaire, ce qui autorisera un suivi en temps réel des processus métier. D autres outils afficheront les mêmes données de façon différente. Par exemple, Office PerformancePoint Server 2007 affichera dans un tableau de bord les données BAM générées par un ou plusieurs processus métier. La capture d écran ci-dessous donne un exemple de tableau de bord avec Business Scorecard Manager de PerformancePoint. 21

Figure 11 : Les informations affichées par Office PerformancePoint Server 2007 peuvent provenir de la base de données BAM. Par ailleurs, un employé peut exploiter le portail BAM de BizTalk Server pour sélectionner une instance particulière d un processus métier, puis choisir une vue BAM sur ce processus. Chacune des vues proposées montre un aspect différent, comme des tendances de ventes ou des niveaux de stock par produit sous forme graphique. Les informations de ces vues sont mises à jour régulièrement, chaque jour, chaque heure ou à la fréquence que vous souhaitez. Via le portail BAM, un employé définit des agrégations de données, comme le nombre de commandes passées, annulées ou en cours de traitement sur la dernière heure. Présenté sous la forme de pages ASP.NET, le portail BAM peut aussi être hébergé comme un composant WebPart dans Windows SharePoint Services. Utilisation d EDI L intégration B2B interentreprises est une part importante des possibilités de BizTalk Server 2009. Une large part des connexions B2B, environ 80 % du total, s appuie sur les standards EDI (Electronic Data Interchange). EDI n est pas à la pointe de la technologies car ce mécanisme existe depuis longtemps. EDI échange des données sous forme de caractères, pas sous forme de documents XML, mais c est un élément incontournable de l intégration interentreprises. Pour cette raison, BizTalk Server 2009 prend largement en compte EDI. Chaque version de BizTalk Server a tenu compte d EDI, notamment grâce à l appui de partenaires Microsoft. Avec BizTalk Server 2006 R2, la version précédente de BizTalk, Microsoft a complètement 22

intégré EDI dans son produit. Les partenaires Microsoft ont bien sûr toujours un rôle important à jouer, notamment en offrant des solutions pour des marchés verticaux spécifiques. La prise en charge d EDI inclut différents éléments. Tout d abord, différentes parties du monde suivent des normes différentes : alors que X12 est utilisé aux États-Unis, EDIFACT est largement employé en Europe et ailleurs dans le monde. BizTalk Server 2009 reconnaît donc les deux standards. Le produit prend aussi en compte le standard AS/2, plus récent, qui permet d échanger des informations EDI via Internet. BizTalk Server 2009 propose aussi des milliers de schémas EDI qui correspondent à de nombreux formats d échanges standardisés dans certains secteurs d activité, comme HIPAA. Les entreprises peuvent les personnaliser via Visual Studio. Les standards EDI définissant des formats de messages plutôt que la manière de transporter ces messages, BizTalk Server 2009 implémente EDI dans des composants pipelines. Cela permet à tout adaptateur BizTalk d envoyer des messages EDI, en laissant le soin aux entreprises de choisir le moyen de communication le mieux approprié. Un autre défi dans une intégration B2B consiste à gérer des interactions avec des partenaires commerciaux. Pour simplifier les connexions EDI, BizTalk Server 2009 inclut un Partner Agreement Manager (PAM). Le PAM permet à un administrateur BizTalk de configurer de nombreux paramètres pour chaque partenaire commercial. Par exemple, des entreprises différentes peuvent encapsuler des transactions EDI selon des manières différentes, utiliser des options différentes pour accuser réception de ces transactions, et les traiter par lots de façons différentes. Le PAM permet d adapter ces options à chaque partenaire. BizTalk Server 2009 inclut aussi une prise en charge spécialisée de BAM qui simplifie la production de données BAM pour des applications EDI. Et pour aider les administrateurs à suivre ce qui se passe, le produit propose un ensemble de rapports orientés EDI, accessibles via la Page du groupe. Des experts ont prédit depuis longtemps la fin d EDI. Mais ce mécanisme est très largement répandu dans le monde entier, sa popularité s étend toujours et il apporte une réelle valeur ajoutée. L intégration et la multiplicité des fonctionnalités EDI dans BizTalk Server 2009 illustrent cette réalité. Exploitation de RFID La technologie d identification par radiofréquence (RFID) montre déjà un potentiel énorme. Une étiquette RFID est un minuscule équipement qui peut être collé sur pratiquement n importe quel support : des palettes dans un entrepôt, des produits dans un magasin, des animaux d élevage dans une ferme, sur des passeports, etc. Une étiquette RFID contient des informations qui peuvent être lues par un lecteur RFID à proximité. Des applications exploitent ensuite ces informations de toutes sortes de manières. Microsoft fournit pour cela un serveur RFID BizTalk. Les applications développées sur cette plateforme peuvent exploiter d autres technologies de BizTalk Server mais le serveur RFID BizTalk peut être installé et utilisé de façon totalement indépendante des autres parties du produit. La figure 14 décrit une telle topologie. 23

Figure 12 : Le serveur RFID BizTalk fournit une plateforme commune aux applications RFID qui interagissent avec des périphériques RFID comme des lecteurs et des imprimantes. Les éléments ayant reçu des étiquettes RFID (palettes, passeports, etc.) apparaissent comme des carrés rouges dans le bas de la figure 14. L identificateur unique de chaque étiquette peut être lu par un lecteur portatif ou par des équipements fixes, comme un lecteur installé sur la porte d un entrepôt. Ces étiquettes peuvent être créées par des imprimantes RFID capables de produire des étiquettes papier enveloppant les étiquettes RFID. D autres moyens existent aussi. Aujourd hui, de nombreux constructeurs proposent des lecteurs RFID et des imprimantes RFID. Les matériels utilisés changent grandement d un constructeur à l autre. Le serveur RFID BizTalk fournit une interface standard DSPI (Device Service Provider Interface) qui permet aux applications de travailler d une façon transparente avec ces périphériques hétérogènes. Les constructeurs de matériels RFID ont à leur disposition un SDK DSPI pour créer des fournisseurs DSPI pour leurs produits. Comparable à un pilote de périphérique dans un système d exploitation (bien qu il ne contienne que du code en mode utilisateur, pas en mode noyau), un fournisseur interagit avec une type particulier d équipement, puis expose ses services de façon standard via DSPI. La lecture d une étiquette RFID reflète un événement du monde réel. Par exemple, le déplacement d une palette de l intérieur de l entrepôt vers le quai d embarquement peut provoquer la lecture de l étiquette de la palette au moment du passage de la porte. Quel que soit le périphérique à l origine de l événement, le serveur RFID BizTalk place ces événements dans une file d événements. Un développeur crée un processus métier RFID, structuré comme un gestionnaire d un ou de plusieurs événements, pour traiter ces événements. Pour faciliter la création de tels processus, BizTalk Server 2009 fournit un type de projet pour Visual Studio consacré aux processus RFID. Le processus peut faire ce qu il veut de chaque événement. Il est généralement écrit dans un langage comme le C# ou Visual Basic. Il peut ignorer certains événements, les enregistrer dans un récepteur d événements, et ne répondre qu à certains. Lorsqu un processus RFID répond à un événement, cette 24

réponse prend souvent la forme d une règle : si cet événement se produit, alors faire telle chose. Pour simplifier la création de cette logique, des développeurs peuvent utiliser le moteur de règles d entreprise BRE de BizTalk Server. Le serveur RFID BizTalk fournit des vocabulaires spécialisés pour aider les développeurs à créer ces règles pour RFID. Comme le montre la figure 14, BizTalk Server 2009 inclut aussi une version du serveur RFID pour les équipements et terminaux Windows Mobile et Windows CE. Nommé BizTalk RFID Mobile, ce nouveau composant offre aux développeurs un environnement de développement plus cohérent pour les applications RFID entre les serveurs et les équipements mobiles. Un logiciel fonctionnant sur BizTalk RFID Mobile s exécute de façon autonome sur un terminal portatif. Il met périodiquement à jour un serveur RFID BizTalk central. Aucune connexion permanente n est requise. Qu il utilise ou non des terminaux mobiles, un processus RFID devra communiquer avec d autres applications. (En fait, ce besoin d intégration constitue la principale raison pour laquelle la prise en charge par Microsoft de RFID est sous licence BizTalk Server.) Une application de gestion de stock peut ainsi être informée en temps réel des mouvements de stocks ; ou une application de gestion de cheptel assure le suivi de chaque animal. Comme le montre la figure 14, le processus RFID communique directement avec d autres applications via des services Web ; il peut aussi communiquer avec BizTalk Server 2009. Pour cela, une application BizTalk pourrait employer un adaptateur basé sur WCF, puisque le serveur RFID exploite WCF, mais d autres approches restent possibles. Dans tous les cas, l objectif est de fournir un moyen efficace pour transformer des événements à bas niveau (lecture d étiquettes RFID) en connaissances métier exploitables. Finalement, comme le montre la figure, le serveur RFID BizTalk a son propre gestionnaire RFID. Avec cet outil, un administrateur peut déterminer les périphériques RFID en fonctionnement, examiner et modifier leurs paramètres (par exemple les antennes actives sur un lecteur RFID ou le protocole utilisé pour lire des étiquettes), et réaliser d autres opérations. Microsoft fournit aussi un pack d administration pour Microsoft Operations Manager 2005 et son successeur System Center Operations Manager 2007, afin qu un serveur RFID BizTalk puisse être contrôlé et géré à distance. Infrastructure pour des architectures orientées service (SOA) Bien qu il soit difficile de définir avec précision ce qu est une architecture orientée service (SOA), le concept est clair et déjà largement répandu. Et pour que SOA fonctionne dans une entreprise, il faut mettre en place une infrastructure adaptée. BizTalk Server 2009 inclut une technologie spécifiquement conçue pour cela. Par exemple, de nombreuses personnes considèrent un ESB (bus de services d entreprise) comme un aspect fondamental d une architecture SOA. Un ESB peut être considéré comme un groupe de modèles architecturaux, centré sur des applications de connexion dans un style orienté service. Pour faciliter la réalisation de ces modèles avec BizTalk Server, Microsoft fournit ESB Guidance. Apparu avec BizTalk Server 2006 R2, ESB Guidance est fourni avec BizTalk Server 2009 dans sa version 2.0. ESB Guidance propose des modèles et des pratiques recommandées, ainsi que du code, pour étendre BizTalk Server et d autres parties de l environnement Microsoft afin de prendre en charge des scénarios courants ESB. Ce logiciel est disponible via Codeplex, le site Web hébergeant le projet open source de Microsoft. Il ne fait pas partie de BizTalk Server. Les extensions fournies par ESB Guidance incluent des on-ramps et des off-ramps qui utilisent des pipelines personnalisés afin de prendre en charge davantage de styles de messages dynamiques, un cadre de travail pour gérer les exceptions, un portail de gestion ESB, et d autres choses encore. Un autre aspect d une infrastructure SOA est sa façon de découvrir des services disponibles. UDDI (Universal Description, Discovery, and Integration) est une technologie standard conçue à cet effet. La version 2 d UDDI est incluse dans Windows Server mais Microsoft intègre UDDI version 3 dans 25

BizTalk Server 2009. Bien que la fonction traditionnelle d UDDI consiste à fournir un annuaire des services, UDDI v3 y ajoute les capacités de partager des informations entre registres affiliés, d empêcher de modifier des données UDDI en les signant de façon numérique, de créer des abonnements afin d être au courant des modifications apportées aux données UDDI, etc. Authentification unique de l entreprise (Enterprise Single Sign-On) Un processus métier qui interagit avec différentes applications doit s adapter à différents mécanismes de sécurité. L accès à une application sur un système Windows peut nécessiter des identifications de sécurité qui seront différentes de celles employées sur un système IBM. Cette multiplication d informations d identification complique le travail des utilisateurs et des processus automatisés. Pour répondre à ce problème, BizTalk Server 2009 inclut une authentification unique de l entreprise. Attention, il ne s agit pas d un mécanisme qui permet à un employé d avoir une seule ouverture de session pour toutes les applications. L authentification unique est un mappage entre l identifiant de l utilisateur Windows et les informations d identification de l utilisateur sur les systèmes non-windows. Il ne résout pas tous les problèmes d identification en entreprise mais il simplifie le travail des processus qui utilisent des applications sur différents systèmes. Pour utiliser l authentification unique de l entreprise, un administrateur définit des applications associées, chacune d elles représentant une application ou un système non-windows. Par exemple, une application associée peut être une application CICS fonctionnant sur un système IBM ou un ERP SAP sur UNIX. Chacune de ces applications a son propre mécanisme d authentification, et chacune requiert ses propres informations d authentification. L authentification unique de l entreprise stocke dans une base de données spécifique, un mappage chiffré entre l identificateur Windows d un utilisateur et ses informations d authentification pour une ou plusieurs applications associées. Lorsqu un utilisateur a besoin d accéder à une application associée, ses informations d authentification sont automatiquement extraites de la base de données par un serveur de l authentification unique de l entreprise. La figure 15 illustre ce fonctionnement. 26

Figure 13 : L authentification unique de l entreprise permet un mappage entre les informations d authentification Windows d un utilisateur et celles requises par d autres systèmes. Dans cet exemple, un message envoyé à une application BizTalk est traité par une orchestration, puis envoyé à une application associée, s exécutant sur un système IBM. La tâche de l authentification unique de l entreprise consiste à envoyer les informations d authentification adéquates (par exemple nom d utilisateur et mot de passe) avec le message lorsqu il est envoyé à l application associée. Comme le montre le diagramme, lorsqu un adaptateur de réception reçoit un message, l adaptateur demande un ticket d authentification unique (SSO) au serveur A de l authentification unique de l entreprise (étape 1). Ce ticket chiffré contient l identité Windows de l utilisateur qui émet la requête, et un délai. (Ne confondez pas cela avec un ticket Kerberos, ce n est pas la même chose.) Puis le ticket SSO est ajouté en tant que propriété au message entrant. Le message suit le chemin normal dans BizTalk Server 2009 ; dans notre exemple, il est traité par une orchestration. Lorsque cette orchestration génère un message sortant, ce message contient donc le ticket SSO. Le nouveau message est destiné à une application fonctionnant sur un système IBM ; il doit contenir les informations d authentification appropriées pour que cet utilisateur puisse accéder à cette application. Pour obtenir ces informations, l adaptateur d envoi contacte le serveur B de l authentification unique (étape 2), et lui fournit le message (qui contient le ticket SSO) et le nom de l application associée pour laquelle il souhaite obtenir les informations d authentification. Lors de cette opération nommée récupération, le serveur B vérifie le ticket SSO puis recherche les informations d authentification de l utilisateur pour cette application (étape 3). Le serveur B renvoie ces informations à l adaptateur d envoi (étape 4), qui les utilisent pour transmettre un message contenant les informations d authentification appropriées à l application associée (étape 5). Des outils d administration sont fournis pour effectuer diverses opérations. Toutes les opérations concernant la base de données des informations d authentification sont auditées. Avec les outils 27

fournis, un administrateur peut surveiller ces opérations et analyser le journal d audit. D autres outils permettent à un administrateur de désactiver une application associée, d activer ou non un mappage pour un utilisateur en particulier, et d effectuer d autres fonctions. Un utilitaire permet aussi à un utilisateur de configurer lui-même ses informations d authentification et ses mappages. Comme les autres composants de BizTalk Server 2009, l authentification unique SSO expose ses services via une API. Les créateurs d adaptateurs BizTalk peuvent utiliser cette API pour accéder aux services de l authentification unique, et les administrateurs l exploitent pour créer des scripts afin d automatiser des tâches courantes. L exemple que nous venons de décrire montre une utilisation typique de l authentification unique SSO mais d autres options existent. Par exemple, une petite configuration BizTalk Server 2009 peut ne posséder qu un seul serveur d authentification SSO et il est possible d utiliser l authentification unique indépendamment de BizTalk Server. Par essence, les applications BizTalk ayant besoin d interagir avec d autres applications sur des systèmes différents, il est logique d inclure ce composant dans le produit. Conclusion L objectif de BizTalk Server 2009 consiste à aider les organisations à créer des processus métier automatisés qui englobent diverses applications et plateformes. En plus de ses capacités fondamentales de messagerie et d orchestration, le produit inclut un moteur de règles d entreprise (BRE) pour travailler avec des règles métier complexes, et BAM pour que chaque utilisateur puisse suivre l avancement des processus. Des composants additionnels, comme la prise en charge d EDI, le serveur RFID, la prise en charge de l infrastructure SOA et l authentification unique répondent à d autres exigences. Plongeant ses racines dans l intégration EAI et B2B, BizTalk Server a grandi pour devenir une fondation pour la gestion des processus métier (BPM). L informatique évoluant vers un monde orienté services, BizTalk Server 2009 jouera un rôle de plus en plus important dans l automatisation des processus métier. L'auteur David Chappell est l actionnaire majoritaire de Chappell & Associates (www.davidchappell.com), situé à San Francisco, dans l État de la Californie aux États-Unis. Par le biais de ses conférences, de ses ouvrages et de ses services de conseil, David Chappell aide de nombreuses personnes dans le monde à comprendre, utiliser et prendre de meilleures décisions sur les nouvelles technologies. 28