Présentation de BizTalk Server 2009

Transcription

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

2 Sommaire LE DÉFI : AMÉLIORER LES PROCESSUS MÉTIER... 3 RÉSOUDRE LE DÉFI : CE QU APPORTE BIZTALK SERVER 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 Envoi et réception de messages : les adaptateurs Traitement des messages : les pipelines Traduction des messages : mappage de données MISE EN UVRE DE PROCESSUS MÉTIER Utilisation des orchestrations Utilisation du moteur de règles d entreprise CRÉATION DE CONFIGURATIONS CAPABLES DE MONTER EN CHARGE CRÉATION ET GESTION DES APPLICATIONS BIZTALK Création d applications Gestion des applications CONTRÔLE BAM (BUSINESS ACTIVITY MONITORING) UTILISATION D EDI EXPLOITATION DE RFID INFRASTRUCTURE POUR DES ARCHITECTURES ORIENTÉES SERVICE (SOA) AUTHENTIFICATION UNIQUE DE L ENTREPRISE (ENTERPRISE SINGLE SIGN-ON)

3 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

4 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

5 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 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

6 ensemble. L intelligence requise pour coordonner tous les logiciels impliqués est mise en uvre dans l orchestration BizTalk Server 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

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

8 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

9 Les fondamentaux de BizTalk Server 2009 Nous venons de décrire les problèmes auxquels s attaque BizTalk Server 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

10 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 à 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 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 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

11 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

12 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

13 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 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

14 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

15 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 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 la semaine dernière, mais elle vient de passer à ; ou la limite crédit d un client vient de baisser de à 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

16 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

17 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

18 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 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

19 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 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 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

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