BizTalk Server Mise en oeuvre opérationnelle. Résumé. David GROSPELIER. ENI Editions - All rigths reserved - Kaiss Tag 1

Transcription

1

2 BizTalk Server 2009 Mise en oeuvre opérationnelle David GROSPELIER Résumé Préface d'eric ORTIZ Chef Produit Biztalk Server Microsoft France Ce livre sur BizTalk Server 2009 s adresse aux équipes de développement, aux consultants et chefs de projets qui souhaitent mettre en oeuvre un EAI dans leur entreprise. La démarche d apprentissage proposée dans ce livre est progressive et repose sur l implémentation d un scénario métier complet qui s enrichit au fur et à mesure des chapitres. La lecture du livre et la mise en oeuvre des exemples supposent que le lecteur possède des compétences en développement.net, XML et SQL. Fort de ses expériences opérationnelles, l auteur propose au lecteur des retours d expérience et des conseils pour l implémentation de projets BizTalk. Le livre ne se contente pas d aborder le processus de développement mais traite de l ensemble des aspects relatifs à un projet EAI/SOA : le suivi fonctionnel, les statistiques, les outils pour l exploitation, le déploiement et le maintien en conditions opérationnelles. Pour les lecteurs déjà familiers du produit, le livre apporte des réponses concrètes à leurs problématiques terrain et des conseils sur les bonnes pratiques devant être mises en oeuvre. Les exemples du livre sont disponibles en téléchargement sur cette page. Les chapitres du livre : Préface de Eric ORTIZ, Chef Produit Biztalk Server, Microsoft France - Avant-propos - Présentation de BizTalk Server - La messagerie avec BizTalk Server Déploiement de solutions BizTalk - Suivi de l activité et gestion des erreurs - Modélisation de messages - Déploiement et utilisation de schémas - Introduction au BAM - Transformation de messages - Pipelines et composants de pipelines - Implémentation de processus métier - Processus métier avancés - BAM avancé - Architecture de services avec BizTalk - Architecture et haute disponibilité - Administration et exploitation de BizTalk. L'auteur David Grospelier est architecte spécialiste dans l'intégration de systèmes avec les technologies Microsoft. Après une dizaine d'années passées en SSII, il a créé début 2006 le cabinet de conseil NOVELI, spécialiste dans l'accompagnement et l'architecture d'intégration. Fort de ses expériences opérationnelles, il fournit au lecteur un livre d'une grande richesse sur BizTalk Server (conseils, bonnes pratiques, retours d'expérience...). Ce livre numérique a été conçu et est diffusé dans le respect des droits d auteur. Toutes les marques citées ont été déposées par leur éditeur respectif. La loi du 11 Mars 1957 n autorisant aux termes des alinéas 2 et 3 de l article 41, d une part, que les copies ou reproductions strictement réservées à l usage privé du copiste et non destinées à une utilisation collective, et, d autre part, que les analyses et les courtes citations dans un but d exemple et d illustration, toute représentation ou reproduction intégrale, ou partielle, faite sans le consentement de l auteur ou de ses ayants droit ou ayant cause, est illicite (alinéa 1er de l article 40). Cette représentation ou reproduction, par quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles 425 et suivants du Code Pénal. Copyright Editions ENI 1-1 -

3 Préface Bon anniversaire, BizTalk fête ses dix ans! En retraçant la genèse de BizTalk Server 2009, on constate qu au fil des versions le produit a évolué avec pragmatisme, sans succomber de manière systématique aux effets de modes parfois dictés par le marché. La première version fait son apparition en 2000 (BizTalk Server 2000) sur un marché à l offre pléthorique, puisque l on dénombre alors un peu plus d une trentaine de solutions d intégration. Entre temps le marché s est fortement consolidé et aujourd hui bon nombre des acteurs historiques ont simplement disparus ou été absorbés. Si l existence officielle de l EAI (Enterprise Application Integration) date de 1997, elle connaît un véritable engouement au début des années 2000, portée par la vague ERP et les grands projets CRM qui impliquent la réalisation de nombreuses interfaces. Malgré un avenir annoncé comme prometteur, la technologie va commencer à compter ses premiers détracteurs, se révélant au final plus complexe que prévue et ne dégageant pas le ROI tant attendu. L échec de certains projets (parfois peut être trop ambitieux) au sein de grandes organisations et le caractère élitiste des offres proposées auront raison du terme EAI, qui se verra «black listé» au sein de certaines directions informatiques. Un nouveau terme va alors faire son apparition pour définir un concept d EAI léger et s appuyant sur les standards XML celui de «Enterprise Service Bus» dont Gartner donne la définition suivante «An Enterprise Service Bus (ESB) is a new architecture that exploits Web services, messaging middleware, intelligent routing, and transformation. ESBs act as a lightweight, ubiquitous integration backbone through which software services and application components flow» (source: Roy Schulte, Gartner). L ESB cultive une certaine ressemblance avec son cousin germain l EAI, mais revendique un côté plus agile qui rallie à sa cause de nombreux candidats : l EAI est mort vive l ESB! Les web services sont rapidement pressentis comme un excellent moyen pour décrire et consommer une interface. Microsoft va largement contribuer au développement des web services, notamment via la plate forme.net dont BizTalk profite pleinement dès BizTalk Server 2004 constitue un jalon important dans l évolution du produit, car l architecture totalement repensée constituera le modèle de référence pour les versions à venir. Des modifications majeures sont apportées : la réécriture en.net, l emploi de SQL Server au cœur du «broker» de messages, l intégration au sein de l environnement de développement Visual Studio. Désormais la feuille de route BizTalk sera guidée par la notion de plate forme, profitant des dernières évolutions et d un chemin de migration transparent. La généralisation des web services, notamment chez les éditeurs de progiciels qui commencent à exposer des fonctions métiers ou portions de processus, voit émerger le concept d architecture orientée services (SOA) début Une approche visant à séparer les activités métier, sous forme de «services» pouvant être assemblés et composés selon un principe de couplage lâche. Les ambitions vont au delà du simple fait de résoudre le problème de l intégration ; SOA est perçu comme un moyen d assurer la transformation de l entreprise, en apportant suffisamment d agilité au système d information pour permettre l évolution de ses processus métiers. De nombreuses initiatives sont alors lancées dans les entreprises, mais début 2009, Anne Thomas Mannes (viceprésidente du cabinet d analyse Burton Group) dresse un bilan sévère après plusieurs années d expérimentation : «After investing millions, IT systems are no better than before. In many organizations, things are worse: costs are higher, projects take longer, and systems are more fragile than ever». En synthèse, une question demeure : est ce que les vagues technologiques qui se sont succédées ces dix dernières années ont eu raison des problématiques d intégration en Entreprise? À la lecture de ces éléments on pourrait en douter, heureusement on compte de nombreux retours d expériences très positifs et notamment autour de BizTalk Server. BizTalk Server est à ce jour la solution «middleware» d intégration la plus déployée, avec à son actif plus de clients à travers le monde, de toutes tailles et secteurs d activité. Et si le terme «middleware» revêt une connotation très technique, la solution se positionne désormais véritablement au service de l amélioration continue des processus d entreprise. Aujourd hui, le livre de David Grospelier constitue une réponse sérieuse, professionnelle et en français aux questions que les décideurs sont en droit de se poser sur leurs projets autour de BizTalk Server. Il apporte les connaissances nécessaires pour réussir l implémentation du produit en décrivant précisément ses fonctionnalités mais aussi en réussissant à entraîner le lecteur dans une démarche d apprentissage sur sa mise en œuvre. David Grospelier connaît BizTalk Server depuis sa première version. Il a participé et participe toujours activement à de nombreux projets de déploiement qui ont abouti à des solutions solides et pérennes. Cette longue expérience fait de lui un référent sur ce sujet et le contenu du livre qu il a écrit donne de belles clefs pour démarrer et réussir à mettre en place une architecture EAI et SOA autour de BizTalk Server. Il est parsemé de points méthodologiques issus de ses retours d expérience client et de conseils d expert bien sûr judicieux. Eric ORTIZ Chef Produit Biztalk Server Microsoft France 2-1 -

4 Le Système d Information et son évolution Il y a une dizaine d années, il était encore possible de rencontrer un Système d Information monolithique avec une application majeure et sans ramifications avec l extérieur de l entreprise. Cette situation est aujourd hui impensable tellement le paysage informatique a changé. Les Systèmes d Information évoluent souvent selon deux stratégies : La stratégie du tout intégré qui consiste à mettre en place un logiciel couvrant l ensemble du périmètre des besoins de l entreprise. Ce type de logiciel est appelé PGI (Progiciel de Gestion Intégrée) ou ERP en anglais. La stratégie du best of breed qui consiste à choisir les logiciels spécialisés les plus adaptés aux différents métiers de l entreprise. L application de cette stratégie s appuie souvent sur des développements internes réalisés par l équipe informatique de l entreprise. Une même entreprise passe parfois d une stratégie à l autre en l espace de quelques années en fonction des changements de direction ou des tendances du marché. Il en résulte des phases de migration, de cohabitation d applications et donc tout naturellement une complexité grandissante du Système d Information. L ouverture de l entreprise vers l extérieur, vis à vis de ses clients, fournisseurs ou partenaires, est nécessaire pour son business. Cette ouverture du Système d Information vers l écosystème de l entreprise s accompagne de nouvelles contraintes : respect des standards en vigueur, des contraintes de sécurité, engagements de services à respecter Les architectures d intégration : EAI Pour répondre à ces nouveaux enjeux, l architecture du Système d Information doit évoluer et apporter une réponse industrielle. Les équipes informatiques doivent en effet être capables de fournir des applications pouvant dialoguer avec l écosystème de l entreprise, respecter les standards et cohabiter avec l existant ou les applications à venir. Ces échanges inter applicatifs supposent l implémentation d interfaces. Le terme interface est communément utilisé pour évoquer un développement informatique visant à relier une application avec un ensemble d autres applications. Il n est pas rare de rencontrer, dans un Système d Information, des dizaines voire des centaines d interfaces, chacune permettant de répondre à un besoin d intégration particulier. Les outils d EAI (Enterprise Application Integration), comme Microsoft BizTalk Server, ont été conçus pour répondre aux challenges des interfaces. L objectif d un EAI est de fournir des services, des outils et des méthodes pour implémenter des interfaces entre applications. Vous avez certainement déjà vu le schéma qui représente le fameux "plat de spaghettis" obtenu lorsque toutes les applications du Système d Information sont reliées entre elles. Les échanges de données dans le SI se croisent, formant un "plat de spaghettis"

5 L objectif de l EAI est d éviter cet enchevêtrement d interfaces en fournissant un hub de communication et donc un point central pour fédérer les échanges. Les applications dialoguent avec l EAI qui se charge de l acheminement des informations aux applications ou partenaires concernés. L EAI rationalise le format des données échangées en assurant des conversions, des transcodifications et des ruptures de protocoles d échanges. Le schéma ci dessous illustre les mêmes échanges que ceux du schéma précédent, mais avec la présence d un EAI. La mise en œuvre d un EAI ne fait pas disparaître tous les problèmes d interfaces d un coup de baguette magique. Il n est d ailleurs par rare de constater que le fameux "plat de spaghettis", qui devait disparaître, réapparaît mais cette fois ci dans l EAI... La mise en œuvre d un EAI s accompagne forcément d une démarche de mise en œuvre et de la volonté de la direction informatique dans cette stratégie. L EAI peut être mis en place selon deux approches : Une approche stratégique : consiste tout d abord à cartographier le Système d Information pour décider - 2-4

6 ensuite du plan d action et de la stratégie d implémentation. Une approche tactique : consiste à implanter l EAI pour un besoin particulier, par exemple lors de l installation d une nouvelle application. Ensuite, l architecture se développe en généralisant l EAI. Il n y a pas de bonne ou mauvaise méthode car le contexte de l entreprise, l état du Système d Information, le budget, le planning et bien d autres paramètres vont guider le directeur informatique vers le choix de l une des deux approches. Microsoft BizTalk Server est, depuis sa toute première version, un EAI. 2. Les architectures de services : SOA Depuis plusieurs années, l architecture de services (SOA : Service Oriented Architecture) est devenue à la mode et rendrait presque obsolètes les architectures EAI. L informatique étant en général friande de nouveaux concepts et d acronymes, cette architecture a très vite été considérée comme incontournable pour tout Système d Information qui se respecte, à tort ou à raison. L architecture SOA repose sur les concepts suivants : Capitaliser sur l existant du Système d Information pour fournir des services réutilisables. Adhérer aux standards du marché (normes, protocoles, sécurité). Masquer la complexité du Système d Information pour les consommateurs de services. Fournir des services simples à consommer, disponibles, performants et fiables. Les concepts de la SOA sont très proches de ceux mis en avant dans l architecture EAI. En tous cas, ils visent à rationaliser le Système d Information en fournissant une collection de services réutilisables et faciles à consommer. L adhésion aux standards du marché est un élément clé de l architecture SOA. L arrivée de l architecture SOA coïncide avec la montée en puissance de XML et des services Web. C est donc tout naturellement qu une architecture SOA s appuie sur ces standards. Pour autant, il ne suffit pas de développer et d exposer un service Web pour mettre en place une architecture SOA. De nombreux logiciels sont apparus sur le marché pour permettre la mise en œuvre d une architecture de services. Ces logiciels, appelés ESB (Enterprise Service Bus, littéralement bus de services de l entreprise), permettent d exposer, sur un bus, des services pouvant être consommés par des applications. L ESB permet : D exposer des services en respectant les normes et standards du marché. De consommer les services existants dans le SI ou de récupérer les données nécessaires pour créer un nouveau service. De mesurer les services exposés et leur utilisation : performance, qualité de service, disponibilité. De référencer les services : lister les services exposés, les documenter, référencer et connaître les consommateurs. De garantir la compatibilité des services dans le temps. Microsoft répond aujourd hui à ces besoins car BizTalk Server s est doté, au fil des années, des fonctionnalités d un ESB. 3. Microsoft BizTalk Server : EAI ou ESB? Pour une entreprise qui souhaite rationaliser son Système d Information ou tout simplement faire communiquer des applications entre elles ou avec des partenaires, il n est pas utile de choisir entre une architecture EAI ou SOA. Vous l avez compris, ces deux architectures sont très proches sur de nombreux aspects et complémentaires sur 5-3 -

7 d autres. Les outils traditionnellement d EAI sont devenus au fil de leurs évolutions des ESB capables de fournir les fonctionnalités nécessaires. Le challenge n est donc pas de choisir l architecture à implémenter entre EAI et SOA mais bien de réfléchir aux outils et services qui vont faciliter l implémentation et l évolution du SI de l entreprise. Microsoft BizTalk Server est à l origine un EAI qui a évolué, par l ajout de nouvelles fonctionnalités, vers un ESB. Cette évolution, enclenchée depuis plusieurs versions, arrive réellement à maturité dans la version 2009 de l outil. C est cette version que nous illustrons dans cet ouvrage. Les prochaines versions de l outil vont certainement améliorer les services rendus. 4. ETL : Extract Transform Load Avant que les architectures EAI et SOA se généralisent, tout du moins sur le papier, existaient les outils d ETL (Extract Transform Load). Ces outils, qui bien entendu continuent d exister et d évoluer, répondent à un besoin un peu différent. Comme l acronyme ETL l indique, il s agit d outils permettant d extraire (Extract) des données, de les transformer (Transform) et de les charger (Load). Ces outils sont utilisés pour des reprises de données et des transferts de données planifiés entre applications ou partenaires. Où les EAI et ESB travaillent traditionnellement en réaction à un événement (appel d un service exposé par l ESB, réception d un message provenant d un partenaire), les ETL travaillent plutôt en réponse à une planification déterminée à l avance. Cette différence s explique par le fait qu un ETL est pensé à l origine pour traiter des volumes de données très importants, le plus souvent sous forme de lots. Les opérations effectuées par l ETL sont donc longues et coûteuses en terme de ressources et il est préférable de les planifier pour ne pas impacter les applications concernées par les extractions ou chargements de données. Il existe un grand nombre d ETL sur le marché et l avènement des architectures EAI et SOA a parfois modifié le paysage. Les éditeurs d ETL ont souvent orienté leurs outils pour qu ils soient utilisables comme des EAI ou ESB, avec plus ou moins de succès. Bien que techniquement rien ne l en empêche, Microsoft BizTalk Server n est très clairement pas un ETL, vous le découvrirez au fil de cet ouvrage

8 À qui s adresse cet ouvrage? 1. Public visé Nous venons de l évoquer, la complexité du Système d Information est grandissante afin de répondre aux nouveaux challenges de l entreprise et aux évolutions naturelles des usages de l informatique. La mise en œuvre d un outil comme Microsoft BizTalk Server 2009 constitue une réponse sérieuse et professionnelle à ces nouveaux enjeux. BizTalk Server, dans la tradition des outils Microsoft, est un outil packagé et relativement simple d accès. C est toutefois un outil riche en fonctionnalités et sa mise en œuvre suppose une bonne connaissance de ses capacités et de ses limites. Cet ouvrage s adresse aux consultants, développeurs et chefs de projets qui souhaitent acquérir les connaissances et compétences nécessaires à l implémentation de Microsoft BizTalk Server 2009 dans l entreprise. Ce livre propose une démarche d apprentissage permettant de mettre en œuvre progressivement les architectures EAI et SOA. L ouvrage est également conçu pour permettre aux lecteurs avertis de trouver des réponses précises aux questions qu ils se posent au quotidien dans leurs projets. 2. Pragmatisme et réalité du terrain Ce livre a été écrit et pensé pour fournir un retour opérationnel de la mise en œuvre de BizTalk. Fort de mes différentes expériences dans la mise en œuvre d architectures EAI et SOA avec BizTalk Server, je vous guide dans cet ouvrage afin que vous puissiez utiliser BizTalk au maximum de ses capacités. En toute indépendance également, cet ouvrage met en lumière les faiblesses de l outil que j ai pu rencontrer sur le terrain

9 Pré requis La lecture de ce livre et la mise en œuvre des exemples supposent que le lecteur possède des compétences en développement.net, des connaissances de XML et de SQL. Les exercices présentés dans cet ouvrage ont été implémentés et peuvent être exécutés dans l environnement suivant : Microsoft Windows Server 2008 Microsoft SQL Server 2008 Microsoft Visual Studio 2008 Microsoft BizTalk Server

10 Structure du livre Le livre est structuré selon une démarche d apprentissage permettant au lecteur d acquérir les connaissances et compétences nécessaires de manière progressive. Pour le lecteur averti, la lecture d un chapitre en particulier est possible car ne suppose par forcément la lecture des précédents. Voici comment ce livre est structuré : Présentation de BizTalk Server : ce premier chapitre présente BizTalk Server, son historique, son positionnement dans la gamme Microsoft et les services qu il propose. La messagerie avec BizTalk Server 2009 : ce chapitre, fondamental pour le débutant BizTalk, expose l architecture de BizTalk et ses concepts fondateurs, au travers de la mise en œuvre de scénarios d échange de messages. Déploiement de solutions BizTalk : ce chapitre illustre les concepts du déploiement d applications BizTalk. Suivi de l activité et gestion des erreurs : dès ce chapitre, nous évoquons comment utiliser les outils fournis par BizTalk pour suivre l activité, gérer les erreurs et mener des actions correctives. Modélisation de messages : dans ce chapitre le lecteur apprend à modéliser des messages XML et fichiers plats et les bonnes pratiques associées. Déploiement et utilisation de schémas : dans ce chapitre le lecteur apprend à utiliser les schémas dans une application BizTalk afin d appliquer des vérifications ou de promouvoir des données. Introduction au BAM : les concepts du BAM sont exposés très tôt dans le livre et permettent au lecteur d identifier comment il peut fournir une visibilité fonctionnelle sur les processus EAI et SOA implémentés dans BizTalk. Transformation de messages : dans ce chapitre, le lecteur apprend à concevoir des transformations et transcodifications de données. Pipelines et composants de pipelines : ce chapitre illustre le fonctionnement des pipelines et composants de pipelines permettant l implémentation de traitements dans des solutions de messagerie. Implémentation de processus métier : ce chapitre permet au lecteur de comprendre comment utiliser les orchestrations BizTalk pour implémenter des processus métiers. Processus métier avancés : ce chapitre permet au lecteur d implémenter des processus avancés : corrélations, transactions, et convois. Architecture de services avec BizTalk : ce chapitre illustre comment BizTalk peut être mis en œuvre en tant qu ESB. Architecture et haute disponibilité : ce chapitre explique l architecture technique de BizTalk et comment le produit peut s adapter aux contraintes de haute disponibilité et de montée en charge. Administration et exploitation de BizTalk : ce chapitre permet aux exploitants informatiques, mais aussi aux équipes projet, de comprendre comment administrer leur infrastructure BizTalk avec les outils adaptés

11 Téléchargement des exemples Tous les exercices réalisés dans cet ouvrage sont disponibles en téléchargement. Dans chaque chapitre vous trouverez une référence vers les éléments disponibles en téléchargement concernant l exercice en cours. Pour effectuer le téléchargement des éléments : Rendez vous sur le site Internet eni.com. Dans la zone du moteur de recherche, saisissez le numéro ISBN disponible au dos de cet ouvrage. Cliquez sur le bouton OK. Cliquez sur le livre. Lorsque vous êtes sur la page Internet du livre, cliquez sur le lien dans l encadré Téléchargement. Enregistrez le fichier sur votre disque et décompressez le afin d obtenir la liste des éléments référencés dans les différents chapitres

12 Préface Bon anniversaire, BizTalk fête ses dix ans! En retraçant la genèse de BizTalk Server 2009, on constate qu au fil des versions le produit a évolué avec pragmatisme, sans succomber de manière systématique aux effets de modes parfois dictés par le marché. La première version fait son apparition en 2000 (BizTalk Server 2000) sur un marché à l offre pléthorique, puisque l on dénombre alors un peu plus d une trentaine de solutions d intégration. Entre temps le marché s est fortement consolidé et aujourd hui bon nombre des acteurs historiques ont simplement disparus ou été absorbés. Si l existence officielle de l EAI (Enterprise Application Integration) date de 1997, elle connaît un véritable engouement au début des années 2000, portée par la vague ERP et les grands projets CRM qui impliquent la réalisation de nombreuses interfaces. Malgré un avenir annoncé comme prometteur, la technologie va commencer à compter ses premiers détracteurs, se révélant au final plus complexe que prévue et ne dégageant pas le ROI tant attendu. L échec de certains projets (parfois peut être trop ambitieux) au sein de grandes organisations et le caractère élitiste des offres proposées auront raison du terme EAI, qui se verra «black listé» au sein de certaines directions informatiques. Un nouveau terme va alors faire son apparition pour définir un concept d EAI léger et s appuyant sur les standards XML celui de «Enterprise Service Bus» dont Gartner donne la définition suivante «An Enterprise Service Bus (ESB) is a new architecture that exploits Web services, messaging middleware, intelligent routing, and transformation. ESBs act as a lightweight, ubiquitous integration backbone through which software services and application components flow» (source: Roy Schulte, Gartner). L ESB cultive une certaine ressemblance avec son cousin germain l EAI, mais revendique un côté plus agile qui rallie à sa cause de nombreux candidats : l EAI est mort vive l ESB! Les web services sont rapidement pressentis comme un excellent moyen pour décrire et consommer une interface. Microsoft va largement contribuer au développement des web services, notamment via la plate forme.net dont BizTalk profite pleinement dès BizTalk Server 2004 constitue un jalon important dans l évolution du produit, car l architecture totalement repensée constituera le modèle de référence pour les versions à venir. Des modifications majeures sont apportées : la réécriture en.net, l emploi de SQL Server au cœur du «broker» de messages, l intégration au sein de l environnement de développement Visual Studio. Désormais la feuille de route BizTalk sera guidée par la notion de plate forme, profitant des dernières évolutions et d un chemin de migration transparent. La généralisation des web services, notamment chez les éditeurs de progiciels qui commencent à exposer des fonctions métiers ou portions de processus, voit émerger le concept d architecture orientée services (SOA) début Une approche visant à séparer les activités métier, sous forme de «services» pouvant être assemblés et composés selon un principe de couplage lâche. Les ambitions vont au delà du simple fait de résoudre le problème de l intégration ; SOA est perçu comme un moyen d assurer la transformation de l entreprise, en apportant suffisamment d agilité au système d information pour permettre l évolution de ses processus métiers. De nombreuses initiatives sont alors lancées dans les entreprises, mais début 2009, Anne Thomas Mannes (viceprésidente du cabinet d analyse Burton Group) dresse un bilan sévère après plusieurs années d expérimentation : «After investing millions, IT systems are no better than before. In many organizations, things are worse: costs are higher, projects take longer, and systems are more fragile than ever». En synthèse, une question demeure : est ce que les vagues technologiques qui se sont succédées ces dix dernières années ont eu raison des problématiques d intégration en Entreprise? À la lecture de ces éléments on pourrait en douter, heureusement on compte de nombreux retours d expériences très positifs et notamment autour de BizTalk Server. BizTalk Server est à ce jour la solution «middleware» d intégration la plus déployée, avec à son actif plus de clients à travers le monde, de toutes tailles et secteurs d activité. Et si le terme «middleware» revêt une connotation très technique, la solution se positionne désormais véritablement au service de l amélioration continue des processus d entreprise. Aujourd hui, le livre de David Grospelier constitue une réponse sérieuse, professionnelle et en français aux questions que les décideurs sont en droit de se poser sur leurs projets autour de BizTalk Server. Il apporte les connaissances nécessaires pour réussir l implémentation du produit en décrivant précisément ses fonctionnalités mais aussi en réussissant à entraîner le lecteur dans une démarche d apprentissage sur sa mise en œuvre. David Grospelier connaît BizTalk Server depuis sa première version. Il a participé et participe toujours activement à de nombreux projets de déploiement qui ont abouti à des solutions solides et pérennes. Cette longue expérience fait de lui un référent sur ce sujet et le contenu du livre qu il a écrit donne de belles clefs pour démarrer et réussir à mettre en place une architecture EAI et SOA autour de BizTalk Server. Il est parsemé de points méthodologiques issus de ses retours d expérience client et de conseils d expert bien sûr judicieux. Eric ORTIZ Chef Produit Biztalk Server Microsoft France

13 BizTalk Server 2009 Mise en oeuvre opérationnelle David GROSPELIER Résumé Préface d'eric ORTIZ Chef Produit Biztalk Server Microsoft France Ce livre sur BizTalk Server 2009 s adresse aux équipes de développement, aux consultants et chefs de projets qui souhaitent mettre en oeuvre un EAI dans leur entreprise. La démarche d apprentissage proposée dans ce livre est progressive et repose sur l implémentation d un scénario métier complet qui s enrichit au fur et à mesure des chapitres. La lecture du livre et la mise en oeuvre des exemples supposent que le lecteur possède des compétences en développement.net, XML et SQL. Fort de ses expériences opérationnelles, l auteur propose au lecteur des retours d expérience et des conseils pour l implémentation de projets BizTalk. Le livre ne se contente pas d aborder le processus de développement mais traite de l ensemble des aspects relatifs à un projet EAI/SOA : le suivi fonctionnel, les statistiques, les outils pour l exploitation, le déploiement et le maintien en conditions opérationnelles. Pour les lecteurs déjà familiers du produit, le livre apporte des réponses concrètes à leurs problématiques terrain et des conseils sur les bonnes pratiques devant être mises en oeuvre. Les exemples du livre sont disponibles en téléchargement sur cette page. Les chapitres du livre : Préface de Eric ORTIZ, Chef Produit Biztalk Server, Microsoft France - Avant-propos - Présentation de BizTalk Server - La messagerie avec BizTalk Server Déploiement de solutions BizTalk - Suivi de l activité et gestion des erreurs - Modélisation de messages - Déploiement et utilisation de schémas - Introduction au BAM - Transformation de messages - Pipelines et composants de pipelines - Implémentation de processus métier - Processus métier avancés - BAM avancé - Architecture de services avec BizTalk - Architecture et haute disponibilité - Administration et exploitation de BizTalk. L'auteur David Grospelier est architecte spécialiste dans l'intégration de systèmes avec les technologies Microsoft. Après une dizaine d'années passées en SSII, il a créé début 2006 le cabinet de conseil NOVELI, spécialiste dans l'accompagnement et l'architecture d'intégration. Fort de ses expériences opérationnelles, il fournit au lecteur un livre d'une grande richesse sur BizTalk Server (conseils, bonnes pratiques, retours d'expérience...). Ce livre numérique a été conçu et est diffusé dans le respect des droits d auteur. Toutes les marques citées ont été déposées par leur éditeur respectif. La loi du 11 Mars 1957 n autorisant aux termes des alinéas 2 et 3 de l article 41, d une part, que les copies ou reproductions strictement réservées à l usage privé du copiste et non destinées à une utilisation collective, et, d autre part, que les analyses et les courtes citations dans un but d exemple et d illustration, toute représentation ou reproduction intégrale, ou partielle, faite sans le consentement de l auteur ou de ses ayants droit ou ayant cause, est illicite (alinéa 1er de l article 40). Cette représentation ou reproduction, par quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles 425 et suivants du Code Pénal. Copyright Editions ENI

14 Outils et services Microsoft BizTalk Server est un produit Microsoft de la gamme serveur. C est un serveur d intégration d applications et de partenaires. Nous avons évoqué dans le précédent chapitre les positionnements de BizTalk dans les architectures EAI et ESB. Nous allons désormais illustrer le contenu du produit, c est à dire les services et outils qui le composent. 1. Architecture du produit BizTalk Server repose sur une architecture dite de publication souscription. Cette architecture s appuie sur des composants de messagerie qui assurent le transit des messages de l écosystème vers BizTalk et inversement. Les composants de l architecture BizTalk offrent des mécanismes de persistance des messages qui transitent dans le système, assurant ainsi une robustesse et une forte tolérance aux pannes. La persistance systématique des messages permet un suivi à toutes les étapes des processus. Le chapitre La messagerie avec BizTalk Server 2009 traite dans le détail de l architecture de publication souscription et sa mise en œuvre. 2. Orchestration de processus En plus des services de messagerie et de routage de messages, BizTalk permet l implémentation de processus métier, plus précisément d orchestrations. Les orchestrations BizTalk sont des processus métier hébergés dans BizTalk. Ces processus permettent d orchestrer des échanges, parfois très complexes, entre les partenaires et les applications de l entreprise. Les processus métier peuvent être transactionnels et savent nativement monter en charger et tolérer la panne. Les chapitres Implémentation de processus métier et Processus métier avancés décrivent comment un processus métier peut être implémenté avec BizTalk. 3. Suivi technique Tous les messages, tous les échanges et tous les processus qui sont exécutés et hébergés par BizTalk sont mémorisés. Les informations mémorisées peuvent être restituées aux acteurs de l entreprise. Les outils de restitution permettent de prouver qu une transaction avec un partenaire a bien eu lieu ou de comprendre le cheminement d une information dans l entreprise. Le suivi technique est personnalisable en fonction de la granularité des informations devant être restituées et de la durée de rétention des données souhaitée. Le chapitre Suivi de l activité et gestion des erreurs revient dans le détail sur le fonctionnement du suivi technique BizTalk. 4. Suivi fonctionnel Les utilisateurs finaux doivent disposer d une visibilité sur les processus métier hébergés dans BizTalk. Ils souhaitent comprendre les points de blocage dans un processus métier, être alertés en temps réel si une situation critique se produit et disposer de statistiques sur les échanges et les données. Pour satisfaire cette population d utilisateurs, BizTalk propose des services pour collecter des indicateurs métiers au fur et à mesure de l exécution des processus ainsi que des outils pour restituer ces indicateurs aux utilisateurs. Il s agit du BAM (Business Analysis Monitoring). Nous abordons ce sujet dans les chapitres Introduction au BAM et BAM avancé. 5. Moteur de règles métiers Le moteur de règles métiers est un composant BizTalk qui permet l implémentation de règles fonctionnelles. Il s agit d un moteur d inférence permettant la définition de règles métiers parfois très complexes via l utilisation d un langage fonctionnel, très proche du langage Fortran. Le langage utilisé est en tout cas très facile d accès pour un analyste métier car il repose sur un vocabulaire fonctionnel qui est une abstraction des données techniques

15 Les règles métier sont déployées dans le moteur de règle et utilisables par les processus métier. Les analystes fonctionnels de l entreprise peuvent faire évoluer ces règles sans impacter les processus métier et donc sans requérir de nouvelles phases de développement informatiques. 6. Outillage pour le développeur Le développement de projets BizTalk repose sur les technologies de développement Microsoft, assurant ainsi une cohérence avec les différents projets de l entreprise. Le développement de projets BizTalk repose sur l utilisation de Visual Studio 2008 et du Framework.Net. Les outils de développement BizTalk, complémentaires aux outils de développement standards Microsoft, permettent le développement, les tests et le déploiement de solutions BizTalk. Dans les différents chapitres de ce livre, nous illustrons l utilisation de la plate forme de développement Microsoft pour construire des applications BizTalk. 7. Outillage pour l exploitant Les équipes d exploitation, en charge du maintien opérationnel de la plate forme BizTalk et des applications qui sont hébergées ont à leur disposition plusieurs outils : Une console d administration permettant l administration du produit, sa configuration, le suivi technique, mais aussi le déploiement de projets BizTalk. Une collection d outils en ligne de commande permettant l automatisation des tâches de déploiement et de suivi. Les équipes peuvent également intégrer des indicateurs de suivi BizTalk dans leurs outils de monitoring, grâce aux composants WMI (Windows Management Interface). Nous abordons ce sujet dans le chapitre Administration et exploitation de BizTalk. Nous abordons dans le détail l utilisation de la console d administration BizTalk dans le chapitre Suivi de l activité et gestion des erreurs et les outils pour le déploiement dans le chapitre Déploiement de solutions BizTalk. 8. Outillage pour les utilisateurs finaux Pour proposer de la visibilité sur les processus et échanges hébergés par BizTalk, les outils suivants sont proposés aux utilisateurs : Un portail Web (nommé portail BAM) pour le suivi fonctionnel et la consultation de statistiques. Microsoft Excel pour la consultation et la consolidation des indicateurs métiers du BAM. Nous abordons ces outils dans les chapitres Introduction au BAM et BAM avancé. 9. Les services complémentaires de BizTalk Depuis plusieurs versions, BizTalk est complété par des composants connexes, livrés avec le produit, mais installables indépendamment. a. L Adapter Pack v2.0 L Adapter Pack v2.0 est un complément de BizTalk offrant au produit la connectivité vers les applications suivantes : Base de données Oracle, Base de données SQL Server, Progiciel Oracle Applications, Progiciel SAP et Progiciel SIEBEL. Les composants cités ci dessus ont été écrits sur la base du Framework.Net 3.5 et plus particulièrement de WCF (Windows Communication Foundation). Ils sont utilisables en dehors de BizTalk, dans toute application.net comme ASP.Net ou SharePoint Server. Ils peuvent également être achetés directement sans acquérir de licence BizTalk. L objectif de ce kit de composants est de faciliter l interconnexion entre une application de l entreprise et un progiciel

16 ou une source de données tout en masquant la complexité de cette opération. b. Les accélérateurs et adaptateurs Bien que BizTalk dispose nativement d une collection de composants pour une large connectivité avec des applications tierces, des compléments sont disponibles permettant l élargissement de cette connectivité. Ces composants sont appelés accélérateurs ou adaptateurs. Voici une liste, non exhaustive, des composants complémentaires, intégrés à la licence BizTalk et pouvant donc être installés en fonction des besoins de connectivité de l entreprise : Accélérateur A for SWIFT : échanges bancaires internationnaux conformes SWIFT (Society for Worldwide Interbank Financial Telecommunication). Accélérateur HL7 : échanges dans le domaine de la santé et conformes à la norme HL7 (Health Level Seven). Accélérateur HIPAA : échanges dans le domaine de l assurance. Adaptateur EDI : échanges normalisés EDI (EDIFACT, X12). Adaptateurs Host : échanges avec des systèmes mainframe (IBM AS/400, IBM DB2, CICS...). c. Les services RFID Toujours dans l optique de fournir un maximum de connectivité à BizTalk, Microsoft propose en complément des composants RFID (Radio Frequency IDentification). La technologie RFID permet de récupérer et d envoyer des données à distance dans des puces RFID. Les puces RFID, appelées tags en anglais, sont collées ou incorporées dans des objets ou produits voire même implantées dans des organismes vivants. Les puces émettent et peuvent recevoir des données en provenance d un dispositif RFID de communication. Grâce aux composants RFID de BizTalk, des interactions entre des processus métier et des objets peuvent être imaginés. Un mouvement de stock sur un produit peut être détecté par les dispositifs RFID et ce mouvement peut se traduire par un message posté dans BizTalk qui enclenche un processus métier en réaction. BizTalk va ainsi faciliter la communication avec les dispositifs RFID pour la réception ou l envoi de données. Les composants RFID de BizTalk contiennent également une interface de programmation pour faciliter l implémentation d applications mobiles RFID en rendant plus simples les interactions entre un périphérique mobile (Windows Phone, Windows CE...) et un tag RFID. d. L ESB Toolkit v2.0 En 2007 l équipe Patterns & Practices de Microsoft, à l origine d un grand nombre de guides d implémentation et de modèles de programmation, a construit un kit d outils et d exemples visant à démontrer comment, avec BizTalk, il est possible de respecter les concepts d une architecture de services. L ESB Toolkit version 1.0 est né de cette idée. En 2009, à l occasion de la sortie de BizTalk Server 2009, l ESB Toolkit a évolué vers une version 2.0 plus complète mais surtout bien mieux packagée et plus industrielle. Cette nouvelle version est maintenant officiellement supportée par l équipe produit Microsoft. Les fonctionnalités offertes par l ESB Toolkit v2.0 sont les suivantes : Une amélioration de la gestion des erreurs dans BizTalk et un portail Web de centralisation d erreurs avec resoumission des messages. Une gestion d itinéraires permettant de définir graphiquement l itinéraire d un message dans l EAI. Des mécanismes de résolution dynamique de partenaires ou de services. Un portail Web de configuration et de suivi, nommé ESB Portal, fourni comme un exemple de solution pouvant être implémenté sur la base du kit ESB. Des guides, bonnes pratiques et solutions exemples illustrant les patterns SOA et leur implémentation avec le toolkit ESB. Bien que l ESB Toolkit v2.0 soit officiellement supporté par Microsoft, son implémentation reste relativement récente

17 Les perspectives d évolution de ce toolkit ne sont pas encore connues : soit le toolkit sera refondu dans le produit et les fonctions du toolkit deviendront des fonctionnalités natives du produit, soit il continuera son cycle de vie en dehors du produit lui même. e. L annuaire UDDI v3 La mise en place d une architecture de services s accompagne souvent de la mise en œuvre d un référentiel de services. Ce référentiel permet de cartographier l architecture, de répertorier les services offerts et leurs contrats. La spécification UDDI (Universal Description Discovery and Integration) a été mise au point dès l année Elle détermine comment un registre de services doit être modélisé, quelles sont les informations qui caractérisent un service et comment les acteurs externes peuvent interagir avec le registre. Microsoft propose une implémentation de la spécification UDDI v2.0 dans un service de Windows Server 2003 et donc entièrement gratuit pour les possesseurs d une licence Windows. Avec BizTalk Server 2009, Microsoft livre un annuaire de services conforme à la spécification UDDI v3.0. Nous n allons pas disserter sur les différences entre la version 2.0 et 3.0 d UDDI, mais notez que désormais, l annuaire UDDI de Microsoft est disponible avec BizTalk Server. L annuaire est donc devenu payant puisqu il est réservé aux détenteurs de BizTalk. Il faut certainement comprendre dans cette stratégie que l usage commun de BizTalk et de cet annuaire UDDI prend tout son sens et renforce donc le positionnement de BizTalk dans les architectures de services. Quelle que soit la stratégie Microsoft, cela n enlève rien à l usage que l on peut faire un annuaire de services UDDI. Si vous souhaitez utiliser conjointement UDDI et BizTalk, vous pouvez référencer dans l annuaire des services offerts par BizTalk. Le lien entre les deux produits n est cependant pas direct ni automatique sauf en utilisant une partie de l ESB Toolkit (en l occurrence l ESB Portal). Sinon vous pouvez toujours déclarer vos services manuellement ou via le portail Web accompagnant l annuaire UDDI v3. La présence de l annuaire UDDI dans BizTalk est donc, à mon sens et à ce jour en tout cas, une stratégie produit et pas une réelle synergie entre les deux composants. L annuaire UDDI v3 peut tout à fait fonctionner sans BizTalk et l inverse est vrai. Dommage qu il n existe pas de lien plus fort entre les deux produits. Nous abordons l architecture de services avec BizTalk dans le chapitre Architecture de services avec BizTalk. Vous comprendrez donc à la lecture de ce chapitre qu il n y a pas de liens directs entre ces composants

18 BizTalk Server dans la gamme Microsoft Vous le mesurerez en lisant cet ouvrage, BizTalk Server peut être positionné sur de nombreux projets informatiques en tant qu EAI ou ESB. Dans certains scénarios, la concurrence vient de l intérieur puisque certains produits Microsoft peuvent couvrir tout ou partie du périmètre couvert par BizTalk, c est ce que nous allons découvrir dans ce paragraphe. 1. BizTalk Server et SSIS SSIS (SQL Server Integration Services) est un service de SQL Server. Les outils et composants de SSIS permettent l intégration de données entre systèmes. La connectivité fournie par SSIS est moins importante que BizTalk mais étant donné que SSIS peut invoquer des services Web ou des composants.net, il est tout à fait possible de lui adjoindre des points de sortie ou d entrée supplémentaires. SSIS est un ETL et propose donc toutes les fonctionnalités permettant l injection de données ainsi que leur transformation. Les concepts de transformations sont un peu différents de ceux présents dans BizTalk mais le besoin couvert est le même. La différence essentielle entre SSIS et BizTalk se situe certainement au moment de l exécution : BizTalk est conçu pour répondre à des événements (publication de messages) donc adapté aux scénarios "fil de l eau". SSIS est quant à lui pensé pour répondre à des planifications et aux traitements par lots. Les deux produits, bien que parfois concurrents, sont complémentaires dans de nombreux projets et peuvent être interconnectés pour utiliser le meilleur de chacun. 2. BizTalk Server et WCF WCF (Windows Communication Foundation) est une brique du Framework.Net. Ce composant permet de rassembler sous une même technologie toutes les technologies d interconnexion Microsoft qui existaient auparavant. Avant WCF, le développement de services réutilisables et distribués pouvait être effectué avec ASP.Net Web Services,.Net Remoting, MSMQ, COM/COM+... WCF apporte une réponse cohérente et unique à toutes ces problématiques d interconnexion en permettant le développement de services qui sont agnostiques au transport. Ce n est que lors du déploiement que les services sont exposés aux clients qui souhaitent les utiliser et c est donc lors de cette étape que le choix du protocole, de la sécurité ou des comportements est effectué. WCF est concurrent de BizTalk puisqu il peut couvrir des scénarios de virtualisation de services et d interconnectivité. Si vous souhaitez exposer une application de votre Système d Information à différents clients, WCF vous permet de le faire tout comme BizTalk. WCF n apporte cependant pas tous les services de BizTalk : l architecture de publication/souscription, la persistance, les outils d administration et de suivi technique. 3. BizTalk Server et WF WF (Windows Workflow Foundation) est, tout comme WCF, un composant du Framework.Net. Il s agit d un moteur de workflow permettant la mise en place de processus avec interaction humaine. WF est composé d un outil de construction de workflow (intégré à Visual Studio) et d une bibliothèque de classes permettant l implémentation d actions dans les workflows. Les concepts sont très proches de ceux présents dans BizTalk. La différence essentielle entre WF et BizTalk se situe dans le fait que WF propose une boîte à outils et pas toujours les services et outils qui permettent la gestion des workflows et leur hébergement. C est d ailleurs pour cette raison que les workflows développés avec WF sont souvent hébergés dans des outils tiers comme Microsoft SharePoint (quand il s agit de workflows documentaires par exemple) ou dans des applications ad hoc. Il est difficile de clairement positionner ces deux produits tant certains concepts sont proches. Vous pouvez retenir que WF est très adapté aux interactions humaines alors que BizTalk est plutôt adapté aux workflows "machine to machine" avec une interaction humaine limitée. Si vous souhaitez combiner les deux, vous pouvez le faire sans problèmes car les workflows WF peuvent être invoqués depuis BizTalk (comme des services WCF) et les workflows WF peuvent également poster des messages dans BizTalk. Les workflows WF peuvent également participer au BAM BizTalk en enrichissant les indicateurs métiers, idéal pour des scénarios offrant une visibilité du début à la fin d un processus métier. La prochaine version de BizTalk (vnext pour l instant) permettra certainement le développement d orchestrations avec les technologies de WF

19 4. BizTalk Server et Windows Server AppFabric Windows Server AppFabric est le futur serveur applicatif Windows. AppFabric est un service Windows permettant l hébergement de services WCF et de workflows WF. Il s agit du futur serveur applicatif Microsoft, équivalent aux Tomcat et Jboss dans l environnement J2EE. Depuis MTS (Microsoft Transaction Coordinator) et COM+ qui ont quasiment disparu à l arrivée de.net, Microsoft ne proposait pas de réelle alternative pour l hébergement de composants.net. L objectif de AppFabric est d héberger des composants.net et de fournir les fonctionnalités d un serveur d application comme le recyclage d instances, les pools d objets, mais aussi des fonctionnalités de haute disponibilité, de répartition de charges et de gestion de cache. AppFabric va même offrir des fonctions de routage entre composants.net, soit exactement ce que permet de faire BizTalk. Avec AppFabric, vous pouvez donc exposer des services pour des applications clientes et router les messages vers d autres applications de votre Système d Information. La différence essentielle entre BizTalk et AppFabric est la possibilité, dans AppFabric, de désactiver complètement la persistance des données. Il est donc possible de fournir une latence quasiment proche de zéro ce qui n est pas possible avec BizTalk du fait d une persistance systématique des messages échangés. AppFabric n a toutefois pas pour vocation l hébergement de services longue durée et ne propose pas toute la connectivité de BizTalk. Beaucoup s interrogent sur le remplacement de BizTalk par AppFabric mais il y a fort à parier que les deux produits cohabitent. Contrairement à BizTalk, AppFabric est un service Windows donc il n est pas soumis à des coûts de licences supplémentaires pour tout détenteur d une licence Windows Server Pas sûr donc que Microsoft ait intérêt à proposer un équivalent BizTalk gratuit. AppFabric est annoncé pour l année 2010 sans pour l instant de date officielle. AppFabric pourrait bien devenir à terme le serveur d hébergement universel des technologies Microsoft : services WCF, workflows WF et pourquoi pas orchestrations BizTalk

20 BizTalk Server et la concurrence La concurrence dans le domaine de l EAI et de l ESB est rude et très importante. Une grande phase de concentration a été opérée durant ces dernières années réduisant assez drastiquement les réels concurrents de BizTalk. Il est très difficile de cibler précisément les produits les plus représentatifs de cette concurrence tant les solutions sont difficiles à comparer. Les magic quadrants du Gartner permettent d avoir une vision relativement complète du marché de l intégration de systèmes et d applications et de bien comprendre le positionnement de BizTalk. Les concurrents de BizTalk sont : les solutions ad hoc développées par les entreprises ; les solutions Microsoft elles mêmes (nous venons de l évoquer dans le précédent paragraphe) ; les solutions EAI très verticales par exemple dans le domaine de la santé, secteur dans lequel des éditeurs proposent des EAI spécialisés ; les solutions EAI généralistes des éditeurs comme IBM, Oracle ou encore SAP. Le positionnement tarifaire de BizTalk, très agressif par rapport aux EAI généralistes, l a souvent desservi, car recalé au rang de solution pour petite entreprise. Or, la maturité de la solution et son déploiement qui depuis plusieurs années se multiplie en fait une solution tout à fait concurrentielle et adaptée aux problématiques des grands comptes. À ce jour en tout cas BizTalk Server est l EAI le plus déployé dans le monde en nombre de clients. BizTalk Server est de plus l un des rares EAI que vous pouvez tester gratuitement pendant une durée limitée et sans assistance de Microsoft. Vous pouvez ainsi vous faire une idée du produit sans forcément acheter des prestations d un éditeur ou d un intégrateur

21 Licences BizTalk Server 1. Licence par processeur Le programme de licence Microsoft BizTalk Server est traditionnel par rapport aux programmes de licences des produits serveurs Microsoft. BizTalk Server est vendu sous forme d une licence par processeur. Vous devez acquérir autant de licences BizTalk que de processeurs sur lesquels une instance de BizTalk fonctionne. Étant donné que BizTalk repose sur SQL Server (pour le stockage des données) et sur Windows pour son exécution, il convient d acquérir les licences correspondantes. 2. Éditions Il existe plusieurs éditions de BizTalk Server, chaque édition disposant d un ensemble de fonctionnalités que nous détaillons ci après. a. Édition Developer L édition Developer est dédiée au développement et aux tests. Elle est disponible à l achat unitairement ou via l abonnement MSDN Microsoft. Cette édition ne doit absolument pas être implantée en production et doit être achetée pour chaque personne réalisant du développement ou des tests BizTalk. b. Édition Standard L édition Standard est l édition qui permet un déploiement en production d un environnement BizTalk. Cette édition possède les limites suivantes. Elle ne peut pas utiliser plus de deux processeurs. Si vous installez BizTalk sur un serveur quadriprocesseur, seule la puissance de deux processeurs sera utilisée, vous devrez cependant acquérir une licence BizTalk pour les quatre processeurs. Vous ne pouvez pas créer plus de cinq applications BizTalk. Une application BizTalk est un regroupement logique de composants permettant l implémentation d un processus métier particulier. Un processus de gestion de commandes dans votre entreprise est une et une seule application même si vous êtes amenés à dialoguer avec plusieurs applications ou partenaires. La limite la plus importante est certainement l impossibilité de monter une ferme de serveurs BizTalk. Ceci signifie donc que cette édition est limitée à des solutions de petite taille sans réelle possibilité de montée en charge ni tolérance de panne. c. Édition Enterprise L édition Enterprise est la plus complète. C est une édition qui n a pas de limite en nombre d applications et surtout cette édition peut être montée en ferme de serveurs et en cluster. Reportez vous au chapitre Architecture et haute disponibilité pour en savoir plus sur les options d architecture en haute disponibilité. Le prix d une édition Enterprise est environ le double d une édition Standard. d. Édition Branch L édition Branch est particulière car elle s adresse à des scénarios dits "hub and spoke". Les entreprises qui disposent d entités physiques réparties (filiales, bureaux, entrepôts) peuvent installer une édition Branch dans ces entités afin de couvrir les besoins locaux et afin de dialoguer avec le siège de l entreprise. L édition Branch ne peut être achetée que si l entreprise possède déjà un BizTalk Server Enterprise avec lequel les éditions Branch vont dialoguer

22 Historique du produit BizTalk Server n est pas un outil très récent dans la gamme Microsoft. La version actuelle, sur laquelle est basé cet ouvrage, est la 6ème génération de l outil. Une nouvelle version sort tous les deux ans et cette tendance sera suivie pour les prochaines générations de l outil. C est en tout cas ce qui est annoncé par Microsoft. Voici un rapide aperçu des versions de BizTalk Server qui ont été éditées : BizTalk Server 2000 : cette toute première mouture du produit est restée relativement confidentielle. Elle contenait déjà une grande partie des fonctionnalités connues à ce jour comme la modélisation de schémas, les transformations, mais aussi le suivi technique. BizTalk Server 2002 : cette version doit être considérée comme un service pack de la version 2000 car elle ne contient pas de nouveautés très structurantes. BizTalk Server 2004 : cette version initie un tournant important pour le développement BizTalk car il s agit de la première version s appuyant sur le Framework.Net (1.0 à cette époque). Le développement de solutions BizTalk s appuie donc désormais sur le couple Visual Studio/Framework.Net et plus sur Visio et COM+ comme c était le cas dans les précédentes versions. BizTalk Server 2006 : cette version s aligne techniquement avec l évolution de la gamme Microsoft, notamment le Framework.Net et Visual Studio. Côté outillage, cette version apporte une vraie console d administration et une réelle solution pour le déploiement d applications. La sortie de cette version s accompagne également d un nouveau modèle de licences : un grand nombre d adaptateurs auparavant payants sont désormais intégrés nativement. La connectivité de BizTalk est donc très largement augmentée tout en restant dans un budget très agressif. BizTalk Server 2006 R2 : cette version est une évolution de la version précédente et permet le support de WCF. Cette version offre de nouvelles perspectives pour l interconnexion d applications grâce aux connecteurs WCF. Elle améliore également l utilisation des services Web en facilitant leur usage sur des scénarios de messagerie. BizTalk Server 2009 : la version 2009 n est pas une version majeure du produit. Il s agit essentiellement d un alignement technique avec Windows 2008, SQL Server 2008 et Visual Studio Cette version est accompagnée de la sortie du BizTalk Server Adapter Pack v2.0 qui contient de nouveaux adaptateurs WCF (notamment l adaptateur SQL Server réécrit). Cette version sonne le glas de l outil HAT (Health & Activity Tracking) permettant la consultation de l historique des transactions. Les fonctionnalités de cet outil sont réintégrées dans la console d administration de BizTalk

23 Avenir du produit 1. BizTalk Server 2009 R2 Les équipes Microsoft annoncent une version du produit tous les deux ans. À la date d écriture de ces lignes, une version 2009 R2 est annoncée avec un ensemble d améliorations. Elle sera vraisemblablement mise sur le marché avant la fin de l année 2010 avec des programmes bêta possibles avant l été Les nouveautés possibles Les nouveautés présentées dans ce paragraphe sont l unique fruit de mon imagination et ne se basent pas sur des informations provenant de Microsoft. Il s agit d une liste de vœux dans laquelle j ai ajouté les fonctionnalités qui me semblent nécessaires pour augmenter la couverture fonctionnelle du produit. a. EDI Depuis plusieurs versions, BizTalk intègre son propre adaptateur EDI (Electronic Data Exchange). Auparavant cette fonctionnalité était couverte par un adaptateur tiers édité par la société COVAST. Depuis peu, Microsoft a racheté l adaptateur à la société COVAST afin de l intégrer dans BizTalk Server. Il en résultera donc certainement un support plus vaste des normes EDI mais également des outils de définition d interchange entre partenaires plus graphiques et plus puissants. b. Génération des adaptateurs WCF Les adaptateurs présents dans le BizTalk Adapter Pack v2.0 sorti en même temps que BizTalk Server 2009, sont des adaptateurs basés sur WCF. Tous les adaptateurs BizTalk ne sont pas à ce jour construits sur ce modèle et il est donc possible que les prochaines versions de BizTalk s accompagnent de nouveaux adaptateurs WCF. c. Intégration de l ESB Toolkit comme fonctionnalité native L ESB Toolkit v2.0 est un outil développé à l origine par l équipe Pattern & Practices de Microsoft. L outil est supporté officiellement par Microsoft depuis la sortie de BizTalk Server Cet outil contient un ensemble de composants qui pourraient tout à fait faire partie des fonctionnalités de base de BizTalk et donc être intégrés nativement. Je pense notamment aux composants de gestion d erreurs ou à la résolution dynamique des itinéraires. Les dernières déclarations Microsoft au sujet des évolutions de BizTalk ne mentionnent jamais l ESB Toolkit et son avenir est donc incertain. d. Console d administration Web La console d administration BizTalk est une console MMC (Microsoft Management Console), il s agit donc d un client riche Windows devant être déployé localement sur chaque poste. Cette console permet le suivi des processus mais aussi la configuration du serveur et le déploiement de solutions. L absence d une console accessible en mode Web est souvent contraignante, les prochaines versions de BizTalk pourraient donc combler ce vide. e. Amélioration de l outil de transformation Microsoft a annoncé depuis plusieurs mois maintenant des améliorations notables dans l outil de définition de transformations. Ces améliorations visent à faciliter le travail du développeur dans l implémentation de transformations complexes. Il est également prévu que la collection des fonctions de transformations soit enrichie de nouvelles fonctionnalités. Reportez vous au paragraphe Transformation de messages pour plus d informations sur l usage des transformations dans BizTalk

24 f. Augmentation de la collection des composants La collection de composants prêts à l emploi dans BizTalk est relativement limitée. Vous le découvrirez au fur et à mesure de vos projets. Pour cette raison vous serez amenés à implémenter vos propres composants ou à utiliser des composants communautaires ou commerciaux. Il est prévu que cette collection de composants soit plus importante via la mise à disposition d une galerie de composants en ligne et accessible aux détenteurs d une licence BizTalk. La communauté des développeurs BizTalk pourra également enrichir cette galerie en ligne. Un Apple AppStore pour BizTalk en quelque sorte. g. Alignement technique La plate forme Microsoft, système d exploitation, serveur de base de données ou encore outils et frameworks de développement, évolue régulièrement. Les prochaines versions de BizTalk vont donc naturellement suivre ces évolutions pour bénéficier des nouveautés et des améliorations associées. Ce sera notamment le cas de la prochaine version de BizTalk Server 2009 (appelée R2) qui s appuiera sur Visual Studio h. BizTalk et OSLO OSLO est le nom de code d une initiative Microsoft, ce n est pas le nom d un nouveau produit de la gamme de l éditeur. OSLO est une démarche, annoncée fin 2007, et impactant plusieurs produits. OSLO vise à fournir aux équipes projets des outils de modélisation permettant la définition des applications, services, workflows et orchestrations. OSLO consiste en : un outil de modélisation graphique (appelé Quadrant) ; un langage de modélisation (appelé M) permettant la création de DSL (Domain Specific Language) et de modèles de données ; un référentiel permettant le partage des modèles entre les outils et les équipes. L objectif de Microsoft est de permettre le développement d applications en partant de la modélisation. Cette modélisation est partagée par les différentes équipes de l entreprise : les équipes de développement et d étude, mais aussi les exploitants ou les analystes métiers. À la date d écriture de ces lignes, il n y a pas encore de date officielle pour la sortie des différentes briques OSLO. Seules des versions très préliminaires du langage et de l outil de modélisation sont disponibles à ce jour. OSLO aura certainement un impact sur le développement BizTalk même s il est difficile de le mesurer précisément. Les impacts suivants sont envisageables : La possibilité de modéliser des applications BizTalk dans l outil de modélisation OSLO. Indirectement c est la possibilité de fédérer, dans un même outil, les orchestrations BizTalk et les workflows de WF. La possibilité de réutiliser la modélisation des applications BizTalk dans les outils d administration et d exploitation de BizTalk. Pour, par exemple, visualiser graphiquement un processus d échange. La fédération, dans un unique service d hébergement (Oslo Processing Server), des workflows WF et des orchestrations BizTalk. Ce service d hébergement pourrait bien être Windows Server AppFabric. 3. BizTalk et le Cloud Nous ne pouvions pas évoquer l avenir de BizTalk sans parler du Cloud. Le Cloud, littéralement l informatique dans les nuages, ou autrement dit l informatique en mode hébergé est certainement la tendance la plus forte sur le marché informatique en ce moment. Tous les éditeurs annoncent leur stratégie vis à vis du Cloud et Microsoft est sans aucun doute l un des précurseurs dans ce domaine. a. Windows Azure La stratégie de Cloud Microsoft repose sur Windows Azure. Il s agit d un système d exploitation permettant

25 l exécution de services hébergés. Les services hébergés peuvent être des services Web ou des applications Web hébergés dans un centre Microsoft. Vous consommez ensuite des heures d utilisation des services et êtes facturés en conséquence. Surtout vous pouvez bénéficier de la montée de charge du centre d hébergement Microsoft et de la haute disponibilité associée. b. SQL Azure Microsoft propose également un service nommé SQL Azure. Il s agit d un serveur de base de données hébergé et basé sur les technologies SQL Server. Il permet l hébergement et l accès aux données depuis des applications de l entreprise. c..net Services Concernant plus précisément les projets d intégration de systèmes et de partenaires, Microsoft propose.net Services..Net Services propose un bus de services hébergé et facilitant l interconnexion des partenaires de l entreprise..net Services peut être utilisé pour les usages suivants : Faciliter l interconnexion de vos partenaires avec votre entreprise sans devoir vous exposer directement. Vous définissez les points d entrée de vos partenaires dans.net Services, donc sur le Cloud. Vous autorisez ensuite uniquement les communications entre le.net Services et votre entreprise. Lorsqu un nouveau partenaire doit communiquer avec vous, vous n avez pas de chantier particulier côté réseau/système d Information de l entreprise, simplement au niveau de.net Services. Faciliter les échanges entre entités de votre entreprise sans nécessairement mettre en place une infrastructure d échange à maintenir. En hébergeant la logique d échange et d interconnexion dans.net Services, vous pouvez mettre en place des solutions d échange rapides, robustes et performantes. Profiter de la gestion à la demande des capacités de traitement. Si vous savez qu en fin d année vous aurez plus d échanges avec vos partenaires que le reste de l année, vous pouvez demander à profiter d une capacité de traitement plus importante pendant une durée limitée. Vous ne payez donc que l utilisation réelle des services. Retenez que.net Services n est pas un BizTalk hébergé. Les applications BizTalk que vous pourriez développer ne peuvent pas à ce jour être hébergées par.net Services (et inversement). Vous pouvez cependant faire dialoguer BizTalk avec.net Services car les services exposés par.net Services reposent sur des standards du marché et sont donc nativement interopérables. d. Live Mesh Bien que Live Mesh ne soit pas directement associé à la stratégie Windows Azure de Microsoft, il s agit bien d un service en mode SAAS (Software As A Service) dans l esprit du Cloud Microsoft. Live Mesh est un service, à ce jour en version beta publique, permettant la synchronisation de fichiers entre plusieurs périphériques, à travers l Internet. Live Mesh permet de synchroniser des fichiers entre vos différents ordinateurs personnels, avec votre mobile ou avec un portail Web en ligne appelé le Live Desktop. Vous pouvez partager les fichiers synchronisés avec des partenaires à partir du moment où vous leur ouvrez les droits sur vos dossiers synchronisés dans Live Mesh. Live Mesh est un excellent système de synchronisation de données entre plusieurs entités réparties sur l Internet. Surtout, Live Mesh rend complètement transparente l utilisation de l Internet. Supposez que vous deviez échanger des fichiers avec un partenaire et que la seule possibilité technique de ce partenaire soit l utilisation d un partage de fichier. Vous pouvez synchroniser ce partage réseau avec Live Mesh et rendre ainsi les données disponibles pour votre entreprise via l Internet donc sans contrainte de sécurité tout en respectant des droits d accès et de la traçabilité. Live Mesh propose un mécanisme de notifications permettant de savoir qu une nouvelle information vient d être synchronisée ou supprimée. BizTalk peut s abonner à ces notifications et agir en conséquence. Le lien entre BizTalk et Live Mesh est possible via l utilisation d un adaptateur BizTalk Azure Adapter, à ce jour en version préliminaire dans codeplex : Les services Live Mesh sont à l origine pensés pour le grand public mais dès qu ils seront dans leurs versions définitives pourront tout à fait être utilisables dans l entreprise

26 Conclusion Nous avons dans ce chapitre découvert BizTalk Server mais vous devez être impatients d en savoir plus. Je vous invite donc à poursuivre la découverte de BizTalk dans le prochain chapitre qui illustre l utilisation de BizTalk et de son architecture de publication souscription

27 Architecture de publication/souscription Avec BizTalk, la mise en œuvre d un scénario d échange entre plusieurs applications ou partenaires suppose de connaître et comprendre l architecture dite de publication/souscription. Cette architecture est le cœur du produit car c est elle qui va régir les échanges et les règles qui définissent ces échanges. 1. Exemple d échange entre deux applications Afin d illustrer cette architecture, voici un exemple très simple d échange de messages entre deux applications d une entreprise. Cet échange, bien que très simple, permet la mise en œuvre des concepts de l architecture de publication/souscription. L application de gestion commerciale génère, dès qu une commande est saisie par une assistante commerciale, un fichier contenant le détail de la commande. La commande est envoyée à l application de comptabilité afin d être intégrée et afin qu une facture soit préparée. Ce type d échange (point à point) ne nécessite pas la présence de BizTalk mais nous verrons dans la suite de ce chapitre que les services rendus par BizTalk permettent une plus grande flexibilité et une meilleure adaptation aux futures évolutions de l écosystème de l entreprise. 2. Mise en œuvre dans BizTalk de l échange entre les deux applications Le schéma ci dessous illustre la manière dont nous allons procéder pour mettre en œuvre cet échange au sein de BizTalk

28 Dans ce schéma sont symbolisés trois composants de l architecture BizTalk : Le port de réception chargé de réceptionner le message provenant de l application de gestion commerciale. Le port d envoi chargé d envoyer le message vers l application de comptabilité. La règle de routage qui fait le lien entre le message reçu via le port de réception et le port d envoi qui doit être utilisé pour le transmettre à l application de comptabilité. Le cheminement du message dans BizTalk est le suivant : Le message est produit par l application de gestion commerciale et déposé dans un répertoire. Un port de réception prévu à cet effet est configuré dans BizTalk pour écouter le répertoire et consommer le message qui a été déposé. Le message est publié dans BizTalk (nous verrons plus loin ce processus dans le détail). Si la publication du message se déroule correctement, le message est supprimé du répertoire dans lequel il a été récupéré. Dans ce type de scénario, BizTalk doit disposer des droits nécessaires sur le répertoire d écoute à la fois pour lire les fichiers déposés, mais surtout pour les supprimer après les avoir consommés. Après publication dans BizTalk, les différentes règles de routage configurées vont être exécutées afin de déterminer l itinéraire que le message doit suivre dans le système. Dans notre cas, le message doit être délivré à un port d envoi chargé de la transmission à l application de comptabilité

29 Le port d envoi va donc être exécuté. Il récupère le message au sein de BizTalk et le transmet à l application destination. Si le processus de transmission se déroule correctement, l itinéraire du message est terminé et le processus d échange est considéré comme correctement effectué. 3. Les avantages de la publication/souscription Dans le processus que nous venons d illustrer, toute l intelligence de l échange se situe dans ce que nous avons appelé la règle de routage. C est en effet cette règle de routage qui relie le message réceptionné et le processus chargé de le transmettre. Bien que cette règle de routage soit le lien entre le port de réception et le port d envoi, en aucun cas elle ne va créer une dépendance directe entre les deux éléments. C est justement cette absence de dépendance qui constitue le concept fondateur de l architecture de BizTalk. Dans l architecture de publication/souscription, il existe : d une part des producteurs d informations (dans notre exemple il s agit du port de réception) ; d autre part des consommateurs d informations qui sont abonnés aux messages publiés dans BizTalk. Dans notre exemple le consommateur est le port d envoi et l abonnement de ce consommateur est représenté par la règle de routage. La souplesse de cette architecture se situe dans le concept d abonnement. Plusieurs consommateurs (exemple : plusieurs ports d envois) peuvent être abonnés au même message provenant de la même application source. Ceci est possible sans pour autant que l application source, celle qui produit le message ne soit contrainte de produire plusieurs messages. L ajout d un nouveau consommateur effectué au sein de BizTalk n impacte absolument pas le producteur d information qui ne connaît pas directement les consommateurs. Le schéma ci dessous illustre un second abonné une application de gestion de stock. Cette application est elle aussi abonnée aux messages produits par l application de gestion commerciale. L ajout de cet abonné n impacte absolument pas le fonctionnement de la gestion commerciale qui continue de produire un et un seul message à destination de BizTalk, BizTalk se chargeant de le diffuser à l ensemble des abonnés. 4. Les abonnés dans BizTalk a. Scénarios A2A et B2B

30 Dans l exemple que nous avons utilisé pour illustrer le fonctionnement de l architecture de publication/souscription, l abonné au message entrant est une application dans l entreprise. Nous sommes donc dans un scénario de type A2A (Application To Application). BizTalk supporte bien entendu les scénarios B2B (Business To Business) dans lesquels des partenaires externes s échangent des informations. Dans notre scénario fonctionnel, si l abonné est un partenaire externe à l entreprise (un client, un fournisseur), il n y a pas d impact sur le fonctionnement de l échange. b. Qui sont les abonnés dans BizTalk? Au sein de BizTalk, les abonnés sont représentés par : des ports d envois chargés de transmettre des messages à des applications ou partenaires externes ; des orchestrations chargées de consommer les messages et d exécuter un processus métier. Nous revenons en détail sur les abonnés de type orchestration dans les chapitres Implémentation de processus métier et Processus métier avancés. 5. Les filtres et leur utilisation pour le routage Afin d envoyer un message à l extérieur de BizTalk (à une application comme à un partenaire), il faut créer un port d envoi. Il faut surtout indiquer à BizTalk quels sont les messages que ce port d envoi doit transmettre, c est à dire créer un abonnement pour ce port d envoi. Pour créer l abonnement, il faut associer un filtre au port d envoi. Le filtre va contenir un ensemble de conditions qu un message doit respecter pour être traité par le port d envoi. Le filtre associé au port d envoi est lu et étudié par BizTalk lorsqu un nouveau message est réceptionné. Si le message réceptionné satisfait à l ensemble des conditions du filtre associé au port d envoi, le port d envoi le récupère et le traite. À chaque réception de message, BizTalk effectue cette opération de recherche d abonné et étudie donc le filtre de tous les ports d envois présents dans sa configuration. Si plusieurs ports d envois ont le même filtre, le message réceptionné est délivré à tous les ports d envois, chacun pouvant ensuite le traiter indépendamment. Un même message peut ainsi être transmis par plusieurs ports d envois comme nous l avons illustré avec les applications de comptabilité et de gestion de stock. En aucun cas il n est possible qu un message qui satisfait aux conditions de deux ports d envois, soit traité par un port d envoi, ce dernier empêchant donc au second de le traiter. Si deux abonnés sont présents dans la configuration de BizTalk au moment où un message est réceptionné, les deux abonnés seront forcément en mesure de traiter le message. La copie d écran suivante montre comment un filtre est défini sur un port d envoi. Nous revenons en détail sur la configuration des ports d envois et des filtres dans la suite de ce chapitre

31 6. La MessageBox BizTalk La MessageBox est une base de données BizTalk contenant : la liste des abonnés et leurs filtres ; les messages réceptionnés et devant être traités par des abonnés. Cette base de données est fondamentale pour le fonctionnement de BizTalk. Elle peut être comparée à la boîte de réception d un logiciel de messagerie électronique. En effet, lorsqu un message est réceptionné par BizTalk, il est publié dans la MessageBox. Lorsque le message est publié, le moteur BizTalk recherche des abonnés et leur transmet les messages correspondants. C est ainsi tout à fait similaire au fonctionnement d un logiciel de messagerie électronique qui dépose l ensemble des messages dans une boîte de réception. Ces messages peuvent ensuite être déplacés dans des sous répertoires de la boîte de réception grâce à des règles qui s exécutent lorsqu un message est réceptionné. La base de données MessageBox contient uniquement les messages réceptionnés et en cours de traitement. Lorsque ces messages ont correctement été traités, ils disparaissent de la MessageBox et sont transférés dans une base de données de suivi, appelée aussi base de Tracking. Reportez vous au chapitre Suivi de l activité et gestion des erreurs pour de plus amples renseignements. La MessageBox est un point de persistance des messages. En cas d arrêt inopiné de BizTalk, les messages en cours de traitement sont mémorisés dans cette base de données et peuvent donc être repris dès le redémarrage du système. Comme vous pouvez aisément le comprendre, la criticité de cette base de données suppose que vous fassiez le nécessaire pour la sauvegarder très régulièrement. Dans la suite de cet ouvrage, nous parlerons de "publication de messages dans BizTalk" par simplicité. Il faut comprendre "publication dans la MessageBox de BizTalk"

32 - 6-31

33 Réceptionner des messages avec BizTalk Nous venons d évoquer l architecture de publication/souscription et les mécanismes d abonnements et de filtres. Avant qu un message ne soit publié dans la MessageBox de BizTalk et donc traité par les abonnés, le message doit être réceptionné. Nous allons exposer dans ce paragraphe les principes de réception d un message dans BizTalk. 1. Réceptionner un message avec BizTalk a. Les ports de réception et emplacements de réception La réception d un message dans BizTalk suppose la création préalable d un port de réception et d un emplacement de réception. Un port de réception peut contenir plusieurs emplacements de réception. Un emplacement de réception, comme son nom l indique, définit un emplacement dans lequel BizTalk s attend à recevoir un message. Chaque emplacement de réception est associé à un adaptateur (en anglais on parle d adapter). Un adaptateur représente le protocole de transport avec lequel BizTalk va recevoir le message. BizTalk est livré avec de nombreux adapters comme l adapter fichier (FILE), FTP (File Transfer Protocol), HTTP (HyperText Transfer Protocol), SOAP (Simple Object Access Protocol)... BizTalk peut recevoir des messages selon deux modes : soit le message est mis à sa disposition et c est BizTalk qui le récupère (exemple : écoute d un répertoire, d un site FTP...), soit c est l application qui produit le message qui le "pousse" à BizTalk en utilisant par exemple l adaptateur HTTP ou SOAP. b. Créer une application BizTalk Pour illustrer la réception d un message avec BizTalk, nous allons créer une application BizTalk. Une application BizTalk est le regroupement d un ensemble de composants BizTalk permettant l échange de messages. Nous verrons au fur et à mesure des chapitres de cet ouvrage que la notion d application est très utile dans BizTalk, à la fois pour l administration d un système, mais également pour le déploiement. Dans ce premier exemple, nous allons créer une application BizTalk qui va accueillir nos composants. Nous allons nommer cette application ENIEditions et nous l utiliserons tout au long des exercices du livre. Nous utilisons dans la suite de ce chapitre le terme artefact pour désigner les composants BizTalk. C est un terme utilisé pour désigner tous les éléments pouvant être exécutés au sein d un groupe BizTalk. Ouverture de la console d administration de BizTalk Ouvrez la console d administration de BizTalk. Dans le menu Démarrer, ouvrez le groupe d applications Microsoft BizTalk Server 2009, puis sélectionnez le raccourci Administration de BizTalk Server. Création de l application BizTalk Lorsqu un groupe BizTalk Server est configuré, plusieurs applications sont automatiquement créées. Il s agit des applications suivantes : BizTalk.System : cette application contient les composants de base BizTalk ainsi que les différents schémas de propriétés (reportez vous au chapitre Modélisation de messages pour de plus amples renseignements sur les schémas de propriétés). BizTalk EDI Application : cette application est créée si vous avez installé l adaptateur EDI. Elle contient les artefacts pour la mise en œuvre d échanges normalisés EDI. Microsoft.Practices.ESB : cette application est créée lors de l installation du Microsoft BizTalk ESB Toolkit v

34 BizTalk Application 1 : cette application vide est créée lors de l installation de BizTalk. Il s agit de l application par défaut. Afin de créer l application ENIEditions, naviguez dans l arborescence du groupe BizTalk, sélectionnez le nœud Applications. Ouvrez le menu contextuel et sélectionnez l option Nouveau et ensuite Application : Nommez l application ENIEditions et saisissez une description pour celle ci. Cliquez sur le bouton OK pour créer l application et retourner dans la console d administration : c. Créer un port et un emplacement de réception Création d un port et d un emplacement de réception Nous allons maintenant créer un port de réception afin de réceptionner les messages en provenance de l application de gestion commerciale. Dans la console d administration, localisez l application ENIEditions et ouvrez l application à l aide de l icône

35 située à sa gauche. Sélectionnez le nœud Ports de réception. Ouvrez le menu contextuel, sélectionnez l option Nouveau puis Port de réception unidirectionnel : Nommez le port rcvgestioncommerciale : Sélectionnez ensuite l onglet Emplacements de réception situé à gauche de l écran et cliquez sur le bouton Nouveau. Nommez l emplacement de réception rcvgestioncommerciale_file. Sélectionnez le type de transport FILE et cliquez sur le bouton Configurer :

36 Saisissez le chemin que l emplacement de réception va écouter. Dans notre exemple, il s agit du répertoire C:\ENIEditions\Tests\GestionCommerciale. Saisissez ensuite le masque de fichier écouté. Par défaut la valeur du masque est *.xml, remplacez cette valeur par *.* afin de traiter tous types de fichiers. Cliquez sur le bouton OK pour terminer la configuration du chemin d écoute

37 Cliquez sur les boutons OK des différents écrans de création afin de finaliser la création du port de réception et de son emplacement. Activation d un emplacement de réception Le port de réception ainsi que l emplacement de réception sont désormais créés. L emplacement de réception n est pas encore en écoute du répertoire et pour le rendre actif il faut effectuer les manipulations suivantes : Dans l application ENIEditions, sélectionnez le nœud Emplacements de réception. Sélectionnez l emplacement de réception rcvgestioncommerciale_file, ouvrez le menu contextuel et choisissez l option Activer. BizTalk est désormais prêt à réceptionner des messages. Ne déposez pas encore de fichier dans le répertoire car nous allons préalablement configurer un abonné afin que le message réceptionné soit routé dans un répertoire

38 Routage et envoi de messages 1. Les ports d envoi L envoi de messages avec BizTalk est effectué grâce à un port d envoi. À la différence d un port de réception, un port d envoi n est pas composé d emplacements d envois. Un port d envoi se caractérise essentiellement par : un adaptateur (c est à dire le protocole utilisé pour l envoi du message) ; une adresse d envoi ; des propriétés d envoi, plus ou moins nombreuses selon le protocole utilisé. Nous verrons plus loin dans ce chapitre que d autres éléments caractérisent un port d envoi, notamment pour définir la stratégie d envoi en cas d erreur ou encore la gestion des priorités. 2. Créer un port d envoi Afin de faire fonctionner notre exemple de routage simple, nous allons configurer un port d envoi permettant de déposer un message dans un répertoire. Nous allons donc utiliser l adaptateur FILE. Nous abonnerons ensuite ce port d envoi aux messages réceptionnés par le port de réception créé lors de nos précédentes manipulations. Voici les étapes pour la création du port d envoi : Dans l application ENIEditions, localisez le nœud Ports d envoi. Ouvrez le menu contextuel et sélectionnez les options Nouveau puis Port d envoi unidirectionnel statique : Nommez le port sndcomptabilite_file. Sélectionnez le protocole FILE dans la liste déroulante Type de transport et cliquez sur le bouton Configurer :

39 Dans le champ Dossier de destination, saisissez le chemin du répertoire dans lequel sera déposé le fichier envoyé par BizTalk. Dans notre exemple, le chemin est C:\ENIEditions\Tests\Comptabilite. Dans le champ Nom de fichier, saisissez %SourceFileName% afin que BizTalk crée un fichier portant le même nom que le fichier qui est réceptionné. Cliquez sur le bouton OK

40 Cliquez ensuite sur le bouton OK pour terminer la création du port d envoi. Nous venons de créer un port d envoi, mais il n est pas totalement opérationnel car : Il n est pas encore démarré. Il n a pas de filtre et n est donc abonné à aucun message. Nous allons corriger cela dans le paragraphe suivant. 3. Création d une règle de routage Maintenant que les caractéristiques de transport de notre port d envoi sont définies, nous devons configurer les règles de routage qui vont permettre à BizTalk d exécuter le port d envoi à l arrivée d un message. Pour cela, il faut associer un filtre au port d envoi. Un filtre est une expression booléenne qui est interprétée par BizTalk lorsqu un message est publié dans la MessageBox. Cette expression est construite à partir d une collection de propriétés qui caractérisent les messages BizTalk, on parle de propriétés contextuelles. Nous rentrerons dans le détail au sujet des propriétés contextuelles mais à ce stade de notre découverte de BizTalk, il faut simplement retenir que chaque message publié dans BizTalk est caractérisé par une collection de propriétés contextuelles. Cette collection d informations est nourrie par BizTalk au fur et à mesure du cheminement du message dans l infrastructure. Une propriété contextuelle est une clé, un espace de noms et une valeur. Les propriétés contextuelles permettent de caractériser précisément un message. Par exemple, lorsque le message est réceptionné, BizTalk ajoute des propriétés comme la date de réception, le nom de l adaptateur utilisé pour la réception, le nom du port de réception... La copie d écran ci dessous illustre la collection des propriétés contextuelles qu un message peut contenir (ici un message réceptionné avec l adaptateur FILE) :

41 Nous découvrirons au fur et à mesure les différentes propriétés contextuelles qui peuvent caractériser un message et notamment l utilisation que nous pourrons en faire. Dans le contexte d un message, il existe des propriétés promues et d autres non promues. Les propriétés promues sont les seules propriétés utilisées par BizTalk pour chercher un abonné. Dans le chapitre Modélisation de messages, nous revenons sur les concepts de propriétés promues et non promues. Dans notre scénario de routage, nous souhaitons que le port d envoi soit abonné à tous les messages qui sont reçus par le port de réception nommé rcvgestioncommerciale. Pour définir le filtre du port d envoi sndcomptabilite_file, procédez comme suit. Ouvrez les propriétés du port d envoi depuis la liste des ports d envoi de l application ENIEditions. Dans la fenêtre de propriétés du port, sélectionnez l onglet Filtres. Dans la liste déroulante Propriété, sélectionnez la propriété contextuelle nommée BTS.ReceivePortName, l opérateur == et saisissez la valeur rcvgestioncommerciale :

42 Dans ce filtre, nous utilisons la propriété contextuelle nommée BTS.ReceivePortName. Cette propriété contient le nom du port de réception qui a reçu le message. Elle est nourrie par BizTalk lors de la réception du message et avant sa publication dans la MessageBox. Lorsque vous validez la création du port d envoi, le port est créé et sa configuration est stockée dans la base de données de configuration de BizTalk. 4. Démarrer un port d envoi À ce stade, bien que le port d envoi soit créé et configuré correctement, il n a pas encore été déclaré comme un abonné auprès de BizTalk. Nous pouvons le constater en visualisant l état du port d envoi dans la console d administration : le port d envoi est à l état Désinscrit. Afin de devenir un abonné, il doit être Inscrit. Sélectionnez le port d envoi, ouvrez le menu contextuel et sélectionnez l option Inscrire :

43 Le port est maintenant à l état Arrêté ce qui signifie qu il est déclaré comme abonné auprès de BizTalk mais qu il ne fera pas l envoi de messages si BizTalk lui délivre un message. Si un message est publié dans la MessageBox et si le port d envoi est abonné, BizTalk délivrera le message au port d envoi et le message sera mis en file d attente tant que le port n est pas démarré. Dès que le port sera démarré, tous les messages en file d attente seront traités. Pour démarrer le port d envoi et donc permettre à notre solution de fonctionner, il faut choisir l action Démarrer du menu contextuel sur le port d envoi. 5. Faire fonctionner le routage a. Vérifier les droits d accès de BizTalk Notre première application BizTalk est désormais prête à fonctionner, l ensemble des composants étant configuré correctement. Avant de tester notre application, il convient de vérifier les éléments suivants : Vérifier les droits d accès sur le répertoire écouté pour le compte Windows qui exécute BizTalk. Vérifier les droits d accès sur le répertoire dans lequel notre message sera envoyé. Pour procéder à cette vérification, il faut déterminer quel est le compte Windows qui exécute BizTalk. Si votre installation de BizTalk n a pas été personnalisée, un seul service Windows nommé BTNTSVC.exe a été installé sur la machine et est démarré automatiquement au lancement de votre serveur. Ce service est associé à une identité Windows. Il peut s agir d un compte Windows local ou un compte de domaine Windows. C est ce compte Windows qui va effectuer l ensemble des traitements BizTalk. Ce compte Windows doit donc disposer des droits d accès appropriés. Voici comment connaître le compte Windows avec lequel BizTalk s exécute. Dans la console d administration BizTalk, ouvrez le nœud Paramètres de plateforme, sélectionnez le nœud Instances de l hôte :

44 La configuration de base BizTalk (avec un seul service Windows) n est pas celle que vous retrouverez dans un environnement de production car elle n est pas optimale. Nous évoquerons les architectures optimales dans le chapitre Architecture et haute disponibilité. Il y a de fortes chances que BizTalk tourne sur votre machine avec un compte administrateur local, c est très fréquent sur une machine de développement pour éviter justement les problématiques de droits d accès. Ce n est pas une configuration préconisée pour des raisons de sécurité. Quoi qu il en soit, vous devez vous assurer que le compte Windows sous lequel fonctionne BizTalk doit disposer des droits suivants : Droits de lecture et suppression sur le répertoire de réception. Droits de lecture et écriture sur le répertoire d envoi. Nous pouvons désormais tester notre application. b. Tests de l application BizTalk Pour tester notre application, il suffit de déposer dans le répertoire d écoute C:\ENIEditions\Tests\GestionCommerciale, n importe quel fichier (sauf un fichier en lecture seule et un fichier système). Après quelques secondes d attente, le fichier est consommé par BizTalk, publié dans la MessageBox et routé au port d envoi. Vous pouvez le constater en visualisant le contenu du répertoire d envoi dans lequel doit se trouver le fichier :

45 Notre première application BizTalk est désormais opérationnelle. Si vous n arrivez pas au comportement souhaité, et souhaitez comprendre les dysfonctionnements, reportez vous au chapitre Suivi de l activité et gestion des erreurs qui vous indiquera la manière de procéder pour diagnostiquer et corriger vos problèmes. L application que nous venons de construire est disponible en téléchargement, fichier Chapitre3.msi. 6. Créer un nouvel abonné Afin de vous exercer à la création de ports d envoi mais aussi pour que vous compreniez l architecture de publication/souscription, je vous conseille de créer plusieurs nouveaux abonnés eux aussi chargés d envoyer le message reçu vers d autres destinataires. Vous pourrez ainsi vous rendre compte qu il n y a pas de lien entre le producteur de l information et les consommateurs et qu il est possible de créer, supprimer et modifier un abonné sans impacter les applications externes

46 Fonctionnalités de transport BizTalk Dans l exercice que nous venons de réaliser, nous avons simplement récupéré un fichier dans un répertoire et envoyé ce même fichier dans un autre répertoire. Si vous avez suivi mes conseils, vous avez également dû créer plusieurs nouveaux abonnés. Nous n avons pas évoqué pour l instant dans le détail les fonctionnalités de transport. BizTalk propose nativement des fonctions facilitant les opérations de transport et la gestion des erreurs durant le transport des messages. 1. Rappels sur la notion d adaptateurs a. Adaptateurs natifs BizTalk Avant toute chose, il convient de rappeler ce qu est un adaptateur. Un adaptateur est un composant qui fournit de la connectivité à BizTalk. Afin qu un message soit délivré à BizTalk avec un protocole particulier, un adaptateur doit être installé et configuré. Il en est de même pour l envoi de messages. BizTalk est livré avec une collection d adaptateurs, de plus en plus complète. La liste complète des adaptateurs livrés avec BizTalk est consultable sur le site Internet de Microsoft ( included.aspx) ou dans la documentation du produit. b. Adapter pack v2.0 Depuis la version 2006 R2 de BizTalk, un kit complet d adaptateurs est disponible en complément des adaptateurs livrés avec le produit. Ce pack d adaptateurs s appelle le BizTalk Adapter Pack. La version 2.0 de ce kit d adaptateurs a été délivrée en même temps que la version 2009 de BizTalk. Il s agit d un ensemble d adaptateurs facilitant l interopérabilité avec des applications tierces. Les adaptateurs suivants sont contenus dans ce pack : SQL Server Oracle E Business Suite Oracle Database mysap Business Suite Siebel ebusiness Applications Ces adaptateurs ont été construits sur WCF (Windows Communication Foundation) contrairement aux adaptateurs natifs de BizTalk. Il s agit donc d une nouvelle génération d adaptateurs amenés à prendre le relais des adaptateurs plus anciens. Il y a de nombreux avantages liés au fait que ces adaptateurs soient développés sur WCF, comme une meilleure performance ou une plus grande stabilité. Le principal avantage est cependant ailleurs : ces adaptateurs ne sont pas propres à BizTalk mais peuvent être utilisés par d autres applications clientes. Une application.net ou un portail SharePoint peuvent se connecter à des applications tierces en utilisant un modèle de programmation complètement uniformisé. Ceci permet par exemple l implémentation de scénarios de communication point à point entre une application qui souhaite consommer des données provenant d un progiciel de l entreprise (comme SAP par exemple). Les clients possédant une licence BizTalk peuvent librement utiliser les adaptateurs contenus dans ce pack, y compris en dehors de BizTalk. Pour les clients ne souhaitant pas acquérir BizTalk, le pack d adaptateur est disponible sous forme d une licence individuelle. c. Adaptateurs tiers Si la collection des adaptateurs livrés avec BizTalk et les adaptateurs présents dans l adaptateur pack ne vous permettent pas de répondre aux besoins de connectivité de votre application, vous pouvez faire appel à de

47 nombreux tiers qui proposent des adaptateurs BizTalk. Il existe à ce jour de nombreux adaptateurs gratuits, disponibles dans le site communautaire Des packs d adaptateurs sont également proposés à la vente par de nombreux éditeurs parmi lesquels : /n Software ( qui propose un pack très complet d adaptateurs et de composants BizTalk (FTP sécurisé, messagerie instantanée Jaber...). Une partie de ces adaptateurs est même disponible gratuitement. iway Software ( offrant de la connectivité vers une très large palette de bases de données, d applications métiers, de moniteurs transactionnels ou vers des EAI/ESB concurrents de BizTalk. d. Développement d adaptateurs Avec l arrivée de l Adapter Pack v1.0 un SDK (System Development Kit, c est à dire kit de développement) a été mis à disposition par Microsoft. Ce SDK, nommé WCF LOB Adapter SDK, est la souche de l ensemble des adaptateurs présents dans l Adapter Pack. Vous pouvez, grâce à ce SDK, développer vos propres adaptateurs. Le développement d un adaptateur BizTalk était possible avant l arrivée de ce SDK mais désormais les adaptateurs que vous développez avec le SDK peuvent fonctionner en dehors de BizTalk. Le développement d un adaptateur est une tâche qui nécessite une maîtrise de.net et WCF et peut s avérer longue et fastidieuse. Néanmoins, dans certains scénarios, la mise en œuvre d un adaptateur est nécessaire et permet de gagner du temps lors de l interconnexion avec des applications tierces. 2. Réitération des envois de messages et transport secondaire Sans aucun développement complémentaire, et quel que soit l adaptateur associé à un port d envoi, BizTalk propose des fonctions de gestion des erreurs. Le diagramme ci dessous illustre le processus d envoi d un message et les mécanismes fournis nativement par BizTalk en cas d erreur :

48 Comme vous pouvez le constater dans le diagramme, une erreur d envoi ne se traduit pas immédiatement par une erreur au niveau BizTalk. Il y a deux niveaux de gestion des erreurs : Dans un premier temps, BizTalk va tenter d envoyer le message. Il effectue ces tentatives si la configuration du port d envoi lui indique de le faire et si oui combien de fois. Si le nombre de tentatives d envoi est dépassé et si le message n a pas été envoyé au destinataire, un mode de transport secondaire peut être utilisé. Si c est le cas, BizTalk bascule sur ce mode de transport et peut également itérer plusieurs fois pour envoyer le message. Lorsque le nombre de tentatives d envoi est dépassé (sur le transport primaire ou secondaire), l instance du port d envoi est suspendue. Cette instance peut être relancée. Dans ce cas le processus reprend depuis le début, les compteurs de tentatives sont remis à zéro. Reportez vous au chapitre Suivi de l activité et gestion des erreurs pour comprendre les manipulations permettant de relancer une instance de service suspendue. La copie d écran ci dessous illustre la configuration du transport, notamment le nombre de tentatives et la durée d attente entre chacune :

49 Le nombre de tentatives indique combien de tentatives seront effectuées après l échec de l envoi initial. La valeur par défaut est 3 ce qui signifie que BizTalk essaiera en tout 4 fois avant de suspendre l envoi. Si vous saisissez la valeur 0 dans le nombre de tentatives, BizTalk n effectuera pas de nouvelle tentative en cas d échec. L intervalle avant nouvelle tentative permet de préciser le temps d attente avant un nouvel envoi. Ce temps est exprimé en minutes et par défaut, 5 minutes s écoulent entre un échec et une nouvelle tentative. Si vous précisez la valeur 0 dans ce champ, une tentative d envoi sera effectuée immédiatement après un échec, sans délai d attente. L onglet Transport secondaire, illustré ci dessous, permet de spécifier le transport secondaire en cas d échec du transport primaire

50 La présence d un transport secondaire n est pas obligatoire. Si vous choisissez un transport secondaire, vous pouvez tout à fait choisir un autre protocole que celui du transport primaire. Les paramètres Nombre de tentatives et Intervalle avant nouvelle tentative sont également réglables sur le transport secondaire. N utilisez pas le transport secondaire comme un mécanisme d alerte. Ce n est absolument pas son rôle. Malheureusement, il est très souvent utilisé dans ce sens. Si vous souhaitez alerter des utilisateurs en cas de non transmission d un message, je vous conseille : Soit l utilisation du BAM (Business Analysis Monitoring) et des alertes si vous souhaitez générer des alertes fonctionnelles (exemple : informer une assistante commerciale que l acquittement d une commande ne peut pas être envoyée à un client et qu elle doit donc lui confirmer par téléphone). Reportez vous au chapitre Introduction au BAM pour en savoir plus sur les alertes BAM. Soit l utilisation d outils de suivi technique qui permettent d alerter des exploitants informatiques afin qu ils diagnostiquent et corrigent le problème. L interaction entre des outils de suivi technique du marché et BizTalk est abordé dans le chapitre Administration et exploitation de BizTalk. 3. Gestion de la priorité Dans certains scénarios, il est nécessaire que les messages soient traités de manière prioritaire par BizTalk. Un message visant à annuler une demande d approvisionnement auprès d un fournisseur doit être transmis le plus vite possible pour que le fournisseur n impute pas des frais à l entreprise. A contrario, certains messages ne nécessitent pas un envoi au fil de l eau et des envois groupés en fin de journée sont tout à fait acceptables. BizTalk permet de spécifier, sur chaque port d envoi, une priorité entre 1 et 10. La valeur 1 étant le niveau de priorité le plus élevé. La valeur par défaut est 5. Lorsque des messages sont publiés dans la MessageBox, BizTalk recherche les abonnés intéressés et déclenche leur exécution en fonction de leur priorité. Un port d envoi de très basse priorité peut donc être exécuté plusieurs minutes après la réception d un message, car dans l intervalle, des messages prioritaires ont dû être envoyés. La gestion des priorités est intéressante lorsque vous devez respecter des qualités de service avec vos partenaires internes ou externes. Notez que la priorité s applique à la fois au transport primaire et secondaire d un port d envoi. Lorsqu un serveur BizTalk est fortement sollicité, c est à dire qu il est occupé à transmettre un très grand nombre de messages, la gestion des priorités n est pas toujours très efficace. Si un message hautement

51 prioritaire doit être envoyé alors que BizTalk est en cours d envoi de centaines ou milliers de messages non prioritaires, plusieurs minutes sont nécessaires avant que le message prioritaire ne soit traité. Pour éviter cette situation, il convient de travailler sur l architecture des hôtes comme nous l évoquons dans le chapitre Architecture et haute disponibilité. 4. Envoi ordonné et séquencement des messages Un grand nombre de situations nécessitent que les traitements effectués par BizTalk respectent un ordre bien particulier. Cet ordre particulier est guidé par le processus métier ou par des contraintes techniques. BizTalk est mis à contribution dans les scénarios suivants : Des messages reçus doivent être traités par BizTalk dans l ordre dans lequel ils ont été envoyés par les applications productrices. Des messages publiés dans BizTalk dans un ordre particulier doivent être envoyés dans le même ordre vers des applications ou partenaires. Des messages reçus dans un ordre incorrect doivent être réordonnés par BizTalk avant d être traités et/ou envoyés. Ces scénarios trouvent une réponse bien différente en terme d implémentation que nous allons illustrer dans les paragraphes suivants. a. Préserver l ordre des messages reçus Très peu de protocoles de transport garantissent la délivrance ordonnée d un message, c est à dire qu un message envoyé en premier arrive le premier à l autre bout de la chaîne. Le protocole Fichier par exemple, ne peut pas vous assurer qu en envoyant deux fichiers l un après l autre dans un répertoire réseau partagé, ils arrivent dans ce même ordre. Les protocoles MSMQ (Microsoft Message Queuing) ou encore MQ Series (IBM) offrent des fonctionnalités de transmission ordonnée des messages. Ainsi, si vous souhaitez que BizTalk réceptionne les fichiers dans le bon ordre, vous devez utiliser un protocole qui vous le garantit en amont. b. Garantir l ordre des messages envoyés ou traités Cas d usages Si les messages sont publiés dans BizTalk dans un ordre particulier (car réceptionnés via MSMQ par exemple), vous pouvez configurer BizTalk afin qu il traite les messages dans cet ordre. Ce scénario est fréquent lorsqu il s agit de messages de mouvements (de stock par exemple) ou des messages de modifications de données (modifications de fiches clients par exemple). Le traitement non ordonné de ce type de message par une application peut créer des effets indésirables et provoquer des actions non souhaitées (exemple : réapprovisionnements de stocks, perte d une modification dans une fiche client...). Option Livraison chronologique des messages Sur un port d envoi BizTalk, vous pouvez utiliser l option Livraison chronologique des messages. Cette option indique à BizTalk que les messages qui sont traités par ce port d envoi doivent l être dans l ordre de leur publication dans la MessageBox. Nous allons illustrer l impact de cette option par un exemple. BizTalk reçoit 3 messages en provenance de la gestion commerciale : il s agit d une commande, d une confirmation de la commande et enfin de la modification de la commande souhaitée a postériori par le client. BizTalk doit envoyer ces trois messages dans l ordre. Vous cochez donc la case Livraison chronologique des messages sur le port d envoi. Voici comment le processus va se dérouler : Les messages numéro 1, 2 et 3 sont publiés dans la MessageBox dans l ordre. Le message 1 déclenche l exécution du port d envoi

52 Tant que le message 1 n est pas envoyé, les messages 2 et 3 ne sont pas envoyés. Dès que le message 1 est envoyé, le message 2 est pris en compte et est envoyé. Il en est de même pour le message numéro 3. Une seule instance du port d envoi est exécutée par BizTalk, ceci afin de garantir l envoi séquencé. Sans l option Livraison chronologique des messages activée, trois instances de ports d envoi auraient été créées en parallèle, chacune en charge d un message. La copie d écran ci dessous illustre les options de délivrance ordonnées disponibles sur un port d envoi : Cas particulier des erreurs d envoi de messages Supposez maintenant que l envoi du message 1 n aboutisse pas malgré les différentes tentatives d envoi. L instance du port d envoi sera donc suspendue en attente d une action manuelle pour être relancée. Dans ce cas particulier, BizTalk peut se comporter de deux manières : Soit il envoie le message numéro 2 car le message numéro 1 n a pas pu être envoyé. Il s agit du comportement par défaut. Soit il suspend l envoi des messages 2 et 3 tant que le message 1 n est pas réellement envoyé. Surtout il empêche qu une action utilisateur permette d envoyer un message tant que les précédents n ont pas été transmis. Afin que ce comportement soit appliqué par BizTalk, vous devez activer l option Arrêter d envoyer des messages supplémentaires en cas d échec du message actuel. Messages ordonnés vers plusieurs destinataires Les cas que nous venons d illustrer fonctionnent dans la mesure où les messages sont envoyés au même destinataire, c est à dire vers la même adresse donc le même port d envoi. Si vous souhaitez ordonner des envois entre plusieurs destinataires avec BizTalk, vous devez implémenter une orchestration. Nous évoquerons ce sujet dans le chapitre Processus métier avancés. c. Réordonner des messages Le dernier cas dans lequel l ordre des messages doit être pris en compte est le suivant : des applications de l entreprise publient dans BizTalk des messages dans un ordre indéterminé. Pour différentes raisons (fonctionnelles la plupart du temps), BizTalk doit ordonner les messages selon des règles particulières et les transmettre dans cet ordre. Ce scénario fonctionnel correspond à une situation très fréquente. Un modèle d implémentation nommé Resequencer illustre ce cas métier. Vous trouverez la liste exhaustive des modèles d implémentation EAI sur le site Afin que BizTalk sache comment ordonner les messages, des règles d ordonnancement doivent être implémentées. Il peut s agir par exemple d ordonner les messages selon : un numéro de séquence contenu dans les messages reçus ; une séquence fonctionnelle particulière implémentée dans BizTalk et correspondant aux processus de l entreprise. Dans tous les cas, il n y a pas de solution technique native permettant de prendre en compte ces besoins. Il faut implémenter un processus métier permettant de gérer l ordonnancement. Nous évoquons ce type d implémentation dans le chapitre Processus métier avancés

53 Conclusion Nous venons d aborder les concepts fondateurs de l architecture BizTalk et avons réussi à implémenter un premier échange entre deux applications de l entreprise. La problématique du déploiement d applications étant fondamentale, nous allons aborder dès le prochain chapitre comment notre première application BizTalk peut être intégrée à un programme de déploiement

54 Introduction au déploiement Le déploiement d une solution informatique est bien trop souvent le parent pauvre d un projet informatique. C est pourtant un facteur primordial pour la réussite du projet. Même si la solution informatique satisfait aux attentes des utilisateurs, respecte les contraintes techniques et tous les objectifs du cahier des charges initial, si le déploiement est laborieux et complexe le projet sera assez rapidement en péril. Une solution EAI ne déroge pas à la règle et il est fondamental de prendre en compte très tôt les problématiques de déploiement et de les mettre à l épreuve lors des phases de tests. Lors de mes différentes expériences projet, j ai rencontré deux approches du déploiement : L approche artisanale (très répandue malheureusement) qui consiste à déployer manuellement les éléments d une solution EAI et ce, sur chaque environnement de l entreprise (test, recette, production...). Les partisans de cette démarche considèrent, souvent à tort, qu il est bien trop compliqué et consommateur de temps de faire un package de déploiement et qu un déploiement manuel est plus efficace et maîtrisé. L approche puriste qui consiste à créer un package de déploiement "aux petits oignons" dans lequel tout est complètement automatisé. La plupart du temps cette démarche a du mal à aboutir et le package parfait se révèle inadapté aux changements. Une approche hybride entre ces deux démarches est souvent la meilleure car : Une approche artisanale du déploiement n est pas en adéquation avec le caractère industriel d une solution EAI. Cette démarche entraîne des délais et charges de travail importants lors de chaque phase de déploiement. Elle apporte un trop grand nombre de risques et déporte sur l équipe de déploiement les problématiques de configuration, de tests... Une approche de puriste part à l origine d un souhait tout à fait louable mais n aboutit que très rarement à une solution opérationnelle et maintenable. La mise au point du package de déploiement est une tâche très consommatrice en terme de budget. La construction d un package de déploiement est donc un habile mélange entre ces deux approches en tenant compte des contraintes de planning et de budget du projet

55 Objectifs d un package de déploiement Un package de déploiement de qualité doit respecter les objectifs suivants : Être fiable et permettre aux équipes de déploiement de détecter si un problème de configuration ou d installation a été rencontré. Le package doit fournir un journal des actions réalisées et un descriptif détaillé des erreurs rencontrées. Être simple d utilisation et documenté pour être pris en main par une équipe à peine sensibilisée aux aspects techniques. Être suffisamment complet pour ne pas requérir de multiples actions de configuration ou d installation manuelles qui sont autant de sources d erreurs. Être adapté à l ensemble des environnements de l entreprise. Le même package doit être utilisable dans l environnement de tests, de recette et de production. Les éventuelles différences en terme de configuration liées aux environnements doivent être demandées à l utilisateur pendant l installation mais le contenu même du package ne doit pas être différent entre les environnements. Être construit de manière automatisée ou automatisable afin de garantir sa qualité. Sa construction ne doit pas être trop longue ni trop fastidieuse sinon le packaging sera très rapidement abandonné. Pouvant être désinstallé pour restituer l environnement technique dans un état cohérent

56 Le déploiement avec BizTalk Server 1. Les apports des versions récentes de BizTalk Server Dans les premières versions de BizTalk Server (jusqu à la version 2006), le produit ne répondait pas réellement aux problématiques de déploiement et très souvent des solutions tierces devaient être utilisées pour construire un package de déploiement de qualité. La version 2006 de BizTalk a introduit la notion d application BizTalk et la notion de package MSI de déploiement qui apportent toutes deux une réponse de qualité aux problématiques de déploiement. 2. La notion d application BizTalk La notion d application BizTalk permet à un utilisateur d organiser un système BizTalk en répartissant les composants en applications. Les composants BizTalk (communément appelés les artefacts), sont les ports d envoi, les ports de réception, mais également les orchestrations, le BAM et bien d autres éléments que nous étudierons dans les prochains chapitres. a. Démarrage et arrêt d une application Le découpage en application facilite l administration puisque les éléments relatifs à un processus métier peuvent être regroupés au sein d une même application. Ils peuvent ainsi être gérés de manière unitaire. Démarrage d une application L action Démarrer, disponible dans le menu contextuel de chaque application comme l illustre la copie d écran cidessous, permet de démarrer tous les ports d envois, d activer les emplacements et de réception et de démarrer toutes les orchestrations : En sélectionnant l option Démarrer, l écran suivant est affiché et offre un niveau de finesse supplémentaire sur le démarrage des artefacts contenus dans l application

57 Arrêt d une application Les artefacts d une application peuvent également être arrêtés tous en même temps grâce à l action Arrêter disponible dans le menu contextuel de l application. Lorsque cette action est déclenchée, plusieurs types d arrêts sont possibles : Arrêt partiel numéro 1 : seuls les emplacements de réception sont désactivés. Aucun nouveau message ne peut donc entrer dans BizTalk, cependant, les traitements en cours se poursuivent et des messages peuvent être envoyés. Arrêt partiel numéro 2 : les traitements en cours sont suspendus (exemple : les ports d envoi en cours d exécution). Les ports d envoi sont arrêtés et les emplacements de réception sont désactivés. Cet arrêt correspond à une pause de l application puisqu il n y aura plus d activité à l issue de cette action. Lorsqu un démarrage sera demandé, les traitements seront repris où ils ont été suspendus. Arrêt complet : comme son nom l indique, il s agit d un arrêt complet de l application. Les traitements en cours ou déjà suspendus sont terminés manuellement et assez brutalement. Ce type d arrêt est rarement utilisé sur un environnement de production car il revient à tuer tous les processus d exécution. La copie d écran ci dessous illustre les trois types d arrêts possibles :

58 b. Déploiement d une application En plus des fonctions d administration que nous venons d évoquer, une application BizTalk est un élément fondamental pour le déploiement. Une application BizTalk peut en effet être exportée sous forme d un fichier d installation. L export permet de créer un fichier d extension.msi (MicroSoft Installer) qui contient l ensemble des artefacts de l application. Si cette application doit être déployée sur un autre serveur BizTalk, le fichier MSI sera importé puis installé sur le second serveur et l application sera intégralement recréée. Nous allons maintenant détailler le fonctionnement du déploiement d applications BizTalk. 3. Créer un package de déploiement Nous allons créer un package de déploiement pour notre application de routage entre la Gestion Commerciale et la Comptabilité. Dans la console d administration BizTalk, sélectionnez l application que vous souhaitez exporter. Dans notre cas, il s agit de l application ENIEditions. Ouvrez le menu contextuel, choisissez l option Exporter puis Fichier MSI :

59 Cliquez sur Suivant dans l écran de Bienvenue. L écran Sélectionner les ressources permet de sélectionner les éléments devant être intégrés au package de déploiement. Nous n avons pas le choix car les ports d envoi et de réception sont forcément intégrés dans un package de déploiement. Cliquez donc simplement sur le bouton Suivant. L écran Spécifier les hôtes IIS est utile à partir du moment où nous utilisons les adaptateurs HTTP ou WCF. Cliquez sur Suivant car nous n avons pas utilisé ces protocoles. L écran Dépendances liste toutes les dépendances de notre application vis à vis d autres applications BizTalk. Toute application BizTalk dépend forcément de l application BizTalk.System comme l indique cet écran. Si d autres dépendances étaient détectées, elles seraient listées et nous pourrions les sélectionner. Ce n est pas le cas de notre application donc cliquez sur le bouton Suivant. Dans l écran Destination, vous devez préciser le nom de l application de destination. Par défaut le champ est renseigné avec le nom ENIEditions mais vous pouvez choisir un nom différent. Vous devez de plus préciser le chemin du fichier MSI à générer qui est le package de déploiement de l application. Cliquez sur le bouton Exporter pour déclencher le processus : Lorsque l export est terminé, un Résumé est affiché. Vous pouvez, depuis cet écran, consulter un journal détaillé contenant toutes les actions réalisées. Ce fichier journal est utile en cas d erreur lors de l export. Cliquez sur le bouton Terminer. Le fichier MSI généré contient l ensemble des artefacts de notre application BizTalk (port de réception, port d envoi, filtres...). 4. Importer et installer un package de déploiement

60 Nous venons de générer un package de déploiement BizTalk en exportant notre application. Dans ce paragraphe, nous allons illustrer son utilisation pour déployer les artefacts BizTalk. Afin de simuler un serveur BizTalk vierge, supprimez préalablement l application ENIEditions. Pour supprimer l application, arrêtez l application grâce à l option Arrêter et choisissez Arrêt Complet. Supprimez ensuite l application via le menu contextuel et l option Supprimer. a. Rôles respectifs de l import et de l installation Avant d utiliser notre package de déploiement, il est nécessaire de comprendre le processus d installation d une application BizTalk. L utilisation d un package de déploiement se découpe en deux opérations : L import L installation Ces deux actions ont un rôle bien différent. Import L import du package est déclenché depuis la console d administration de BizTalk. Lors du processus d import, BizTalk inspecte le contenu du package MSI et procède à la déclaration dans la base de données de configuration de l ensemble des artefacts. Les ports d envoi et de réception sont créés pendant cette phase. Installation L installation du package est traditionnellement déclenchée après l import. Elle peut être déclenchée directement à la fin de l assistant d import de package MSI mais aussi manuellement en exécutant le fichier MSI (double clic sur le fichier.msi). La phase d installation n est pas toujours nécessaire. Cette phase a du sens à partir du moment où l application contient : des ressources comme des schémas, orchestrations, pipelines, c est à dire des composants BizTalk développés avec Visual Studio ; des ressources complémentaires devant être copiées sur la machine BizTalk. Notre application ENIEditions ne requiert pas d installation car elle ne satisfait pas aux conditions que nous venons de citer. Nous revenons dans les paragraphes Déploiement de ressources complémentaires et Utilisation de scripts de déploiement, sur la phase d installation. Vous mesurerez également l importance de cette phase d installation dans le chapitre Modélisation de messages et les chapitres suivants. b. Processus pour importer un package de déploiement Afin d importer le fichier MSI et donc créer l application ENIEditions dans BizTalk, voici comment vous devez procéder. Dans la console d administration BizTalk, sélectionnez le nœud Applications. Ouvrez le menu contextuel et sélectionnez l option Importer puis Fichier MSI

61 Sélectionnez le fichier MSI à importer et cliquez sur Suivant : Dans l écran Paramètres de l application, la liste déroulante Nom de l application contient ENIEditions. Il s agit du nom de l application destination qui a été saisi lors de l export du package. Dans ce même écran, vous pouvez spécifier des dépendances vis à vis d autres applications, ce qui n est pas notre cas. Laissez donc simplement la dépendance vis à vis de l application BizTalk.System. La case à cocher Remplacer les ressources permet d écraser des ressources qui existent déjà. Étant donné que nous n avons pas de ressources dans notre application, ne cochez pas cette case. Cliquez sur Suivant

62 Dans l écran Paramètres de l application, la liste déroulante Nom de l application contient par défaut le nom de l application destination choisi lors de l export. Vous pouvez cependant choisir une application existante et ainsi ajouter à cette application les artefacts contenus dans le package de déploiement. Dans l écran Paramètres d environnement cible de l application, cliquez sur le bouton Suivant. Vous comprendrez l usage de cet écran dans le paragraphe Gérer différents environnements et fichiers de liaison du présent chapitre. Pour déclencher l import du package MSI, cliquez sur le bouton Importer de l écran Résumé d importation. La phase d import de l application ENIEditions est relativement rapide car l application contient peu d artefacts. L import d une application riche en artefacts peut prendre plusieurs secondes voire même minutes par exemple lorsque des scripts de déploiement sont déclenchés (paragraphe Utilisation de scripts de déploiement de ce chapitre). Lorsque l import est terminé, l écran Résultats s affiche. Il contient un récapitulatif des actions réalisées et un lien vers un fichier journal détaillant toutes les actions effectuées. La case à cocher Exécuter l assistant Installation des applications pour installer l application sur l ordinateur local permet de lancer la phase d installation du package MSI. Cochez cette case et cliquez sur Terminer. Rendez vous dans le paragraphe suivant pour suivre l étape d installation :

63 c. Processus pour installer un package de déploiement La phase d installation, bien qu inutile dans le cas de l application ENIEditions, a été lancée à l issue de la phase d import. Pour rappel, vous pouvez également lancer l installation du package MSI simplement en l exécutant depuis l explorateur de fichiers de Windows, en double cliquant sur le fichier. Le premier écran du processus d installation permet de sélectionner l emplacement dans lequel les ressources de l application seront copiées :

64 De nombreux écrans de l assistant d installation nécessitent simplement un clic sur le bouton Suivant. Il n est donc pas utile que nous détaillions le contenu de ces écrans. Lorsque l installation est terminée, l écran suivant est affiché. À l issue de l installation, si vous visualisez la liste des programmes installés sur la machine BizTalk, vous constaterez que l application ENIEditions figure dans la liste. À partir de cet écran, vous pourrez ainsi réparer l application (c est à dire réinstaller le package) ou désinstaller l application :

65 La phase d installation pour l application ENIEditions n apporte aucune plus value car notre application ne contient pas de ressources nécessitant une installation. Consultez les paragraphes Déploiement de ressources complémentaires et Utilisation de scripts pour le déploiement afin de mettre en pratique l utilisation de l installation et de mieux comprendre son rôle

66 Gérer différents environnements BizTalk 1. Différences entre environnements L un des objectifs d un package de déploiement de qualité est de permettre de déployer sans effort la même application dans différents environnements (développement, test, recette, production...). Les équipes informatiques travaillent pour faire ressembler les environnements techniques en normalisant un maximum d éléments comme les emplacements de stockage, l adresse des ressources bases de données et parfois même les noms de machine et l adressage réseau. La ressemblance parfaite entre deux environnements est pourtant quasiment impossible et le plus souvent des différences, mêmes mineures, persistent entre les environnements. Ces différences doivent être prises en compte par le package de déploiement. BizTalk apporte une solution à ces problématiques. À titre d exemple, le tableau ci dessous indique les différences entre l environnement de développement et l environnement de recette pour notre application de routage : Environnement de développement Environnement de recette Répertoire de réception des messages de la Gestion Commerciale C:\ENIEditions\Tests\ GestionCommerciale C:\ENIEditions\Tests\ Comptabilite\Recette Répertoire d envoi des messages pour la Comptabilité C:\ENIEditions\Tests\ Comptabilite C:\ENIEditions\Tests\ Comptabilite\Recette Dans le tableau ci dessus, les différences entre les environnements sont assez faibles puisque seul un sousrépertoire est présent sur l environnement de recette et absent de l environnement de développement. Bien évidemment, dans la réalité les différences peuvent être plus importantes. Les protocoles utilisés pour transmettre les messages peuvent par exemple être différents. Ces différences, mêmes si elles sont très importantes, sont gérables dans un package de déploiement BizTalk comme vous pourrez le constater. 2. Fichier de liaison a. Qu est ce qu un fichier de liaison? Afin de prendre en compte la différence entre des environnements, nous devons utiliser des fichiers de liaison (en anglais, fichiers de bindings). Ces fichiers de liaison contiennent la configuration de l ensemble des artefacts d une application BizTalk, comme les ports d envoi et les ports de réception. Les fichiers de liaison sont des fichiers XML qui peuvent être exportés depuis une application BizTalk, édités, puis réimportés. Ils sont très souvent utilisés pour des modifications en masse. b. Comment obtenir un fichier de liaison? Voici la démarche pour obtenir le fichier de liaison correspondant à notre application : Dans la console d administration BizTalk, sélectionnez l application ENIEditions. Ouvrez le menu contextuel, choisissez l option Exporter puis Liaisons :

67 Saisissez le chemin complet du fichier de liaison qui sera généré. Nommez le fichier ENIEditions_Developpement.xml. Dans les options d export, sélectionnez le bouton radio Exporter toutes les liaisons de l application active et cliquez sur OK. À partir de l assistant d export, vous pouvez également exporter les liaisons de toutes les applications BizTalk installées. Le fichier de liaison que nous venons d exporter ressemble à la copie d écran ci dessous :

68 À première vue le contenu du fichier peut paraître complexe, mais en réalité il est très simple de modifier un fichier de liaison pour procéder à un changement de configuration ou ajouter un port d envoi. c. Créer un fichier de liaison pour chaque environnement À cette étape du processus, nous disposons donc d une photographie de la configuration de l application BizTalk. Ce fichier de liaison correspond à la configuration de l environnement de développement. Afin de construire un package de déploiement multi environnement, nous devons disposer des fichiers de liaison correspondants à chaque environnement. Nous allons générer un fichier de liaison correspondant à l environnement de recette/test. Nous avons deux alternatives : Soit modifier, via la console d administration BizTalk, l emplacement de réception et le port d envoi afin de les configurer pour l environnement de recette. Ensuite, nous exportons cette configuration sous forme d un nouveau fichier de liaison. Soit nous copions le fichier de liaison de l environnement de développement et le modifions à la main. Nous allons illustrer la seconde alternative. Voici comment il faut procéder : Effectuez une copie du fichier de liaison ENIEditions_Developpement.xml dans un nouveau fichier que vous nommez ENIEditions_Recette.xml. Ouvrez le nouveau fichier de liaison. Recherchez la chaîne de caractère C:\ENIEditions\Tests\Comptabilite\% SourceFileName% et remplacez la par la chaîne C:\ENIEditions\Tests\Comptabilite\Recette\%SourceFileName%

69 En faisant ce remplacement de chaîne, nous venons de changer l adresse du port d envoi vers l application de Comptabilité. Remplacez maintenant la chaîne C:\ENIEditions\Tests\GestionCommerciale\*.* par C:\ENIEditions\Tests\GestionCommerciale\Recette\*.*. Sauvegardez le fichier de liaison. L opération de modification est terminée. d. Ajouter les fichiers de liaison dans les ressources d une application Nous disposons de deux fichiers de liaison, un pour chaque environnement. Les fichiers de liaison doivent maintenant être intégrés au package de déploiement de l application, nous allons les ajouter en tant que ressources de l application. Les ressources d une application BizTalk sont des éléments complémentaires, intégrés dans un package de déploiement et déployés en même temps que l application BizTalk. Ces ressources peuvent être de plusieurs natures, ce que nous illustrons dans le paragraphe Déploiement de ressources complémentaires. Nous allons ajouter nos deux fichiers de liaison dans les ressources de l application : Dans l application ENIEditions, sélectionnez le nœud Ressources. Ouvrez le menu contextuel, sélectionnez l option Ajouter puis Ressources

70 Cliquez sur le bouton Ajouter pour ajouter les deux fichiers de liaison et sélectionnez les fichiers sur votre disque dur. Pour chaque fichier de liaison, saisissez une valeur dans le champ Environnement cible : La valeur du champ Environnement cible est associée à chaque fichier de liaison. Ce nom sera affiché à l utilisateur lors de l import du package et lui permettra de sélectionner l environnement qu il souhaite configurer

71 Cliquez sur OK lorsque vous avez saisi une valeur dans Environnement cible pour chaque fichier de liaison. Les fichiers de liaison font désormais partie des ressources de l application comme l illustre la copie d écran cidessous : e. Usage des fichiers de liaison lors de l import d un package Nous allons maintenant de nouveau exporter l application ENIEditions. Les fichiers de liaison ajoutés dans les ressources de l application vont être intégrés dans le package MSI. Exportez l application ENIEditions sous forme d un fichier MSI. Référez vous au paragraphe Créer un package de déploiement dans le présent chapitre pour le détail des manipulations. Dès la seconde étape de l export, l assistant propose de choisir les ressources à intégrer dans le package. Les deux fichiers de liaison sont listés et sélectionnés dans ces ressources. Le fichier MSI de l application peut être téléchargé. Il s agit du fichier Chapitre4_avecLiaisons.msi. Vous disposez désormais d un package de déploiement MSI intégrant les fichiers de liaison. Afin d être dans une situation de déploiement sur un serveur vierge, supprimez l application ENIEditions

72 Importez le package MSI afin de recréer l application. Dans l écran Paramètres d environnement cible de l application, la liste déroulante Environnement intermédiaire cible contient le nom des environnements associés aux fichiers de liaison. En sélectionnant l un ou l autre des environnements, vous appliquez le fichier de liaison correspondant. Lorsque l import est terminé, vérifiez, dans les adresses des emplacements de réception et des ports d envoi que la bonne configuration a été appliquée. Quand une application BizTalk est complexe, avec de nombreux artefacts, un seul fichier de liaison est trop lourd à gérer. Plusieurs fichiers de liaison peuvent être créés et associés au même nom d environnement dans les ressources de l application. Lors de l import du package de déploiement, tous les fichiers de liaison portant le même nom d environnement cible seront importés séquentiellement

73 Le déploiement de ressources complémentaires Dans le paragraphe précédent, consacré à la gestion des environnements, nous avons ajouté des fichiers de liaison dans les ressources de l application. Ces fichiers ont été intégrés au fichier MSI généré lors de l export puis utilisés lors de l import pour permettre le choix de l environnement à l utilisateur. Nous verrons dans les chapitres consacrés aux schémas, transformations, pipelines ou encore orchestrations, que les assemblies.net contenant les composants développés pour BizTalk seront elles aussi intégrées aux ressources des applications. Les ressources d une application permettent de déployer, en même temps que tous les artefacts BizTalk, des éléments complémentaires nécessaires à l application BizTalk. 1. Les différents types de ressources Différents types de ressources peuvent être ajoutés dans une application. Le tableau ci dessous référence les différents types. Type de ressource Nom de la ressource Description System.BizTalk:BizTalkBinding Fichier de liaison Gestion des différents environnements de configuration. System.BizTalk:Bam Définition BAM Indicateurs de suivi fonctionnels. cf. chapitre Introduction au BAM System.BizTalk:BizTalkAssembly Assembly.Net BizTalk Composants BizTalk : schémas, maps, orchestrations ou pipelines. System.BizTalk:Assembly Assembly.Net Composants.Net : utilitaires, accès aux données... System.BizTalk:Com Composant COM Composants COM (Component Object Model). System.BizTalk:PreProcessingScript Script de prédéploiement Script exécuté avant le déploiement (cf. paragraphe Utilisation de scripts de déploiement). System.BizTalk:PostProcessingScript Script de postdéploiement Script exécuté après le déploiement (cf. Utilisation de scripts de déploiement). System.BizTalk:File Fichier Fichiers non typés. a. Les ressources de développement Lorsque nous aurons abordé le développement BizTalk dans Visual Studio, nous utiliserons les ressources de type System.BizTalk:BizTalkAssembly, System.BizTalk:Assembly et System.BizTalk:Com. Ces trois types de ressources permettent d incorporer, dans un package de déploiement, les composants développés pour BizTalk ou utilisés par BizTalk. Reportez vous aux chapitres concernant le développement et notamment le premier chapitre qui aborde cette thématique : Modélisation de messages. b. Les ressources de suivi fonctionnel Le type de ressource System.BizTalk:Bam permet de déployer, avec une application, l ensemble des indicateurs métiers utiles au suivi fonctionnel

74 Reportez vous au chapitre Introduction au BAM. c. Les ressources de configuration La ressource de type System.BizTalk:BizTalkBinding contient la configuration de chaque environnement. Nous venons de l illustrer dans le paragraphe Gérer différents environnements et fichier de liaison. d. Les ressources d automatisation Les types de ressources System.BizTalk:PreProcessingScript et System.BizTalk:PostProcessingScript permettent l automatisation des procédures d installation. Reportez vous au paragraphe Utilisation des scripts de déploiement. e. Les ressources non typées Le type de ressource System.BizTalk:File permet de déployer des ressources non typées. Il peut s agir de tout type de fichier devant être déployé en même temps que l application. Vous pouvez par exemple déployer des fichiers de configuration nécessaire au fonctionnement de votre application. Vous pouvez également déployer des requêtes de suivi préalablement enregistrées (cf. Suivi de l activité et gestion d erreurs) ou encore des exemples de messages, de la documentation, des fichiers d aide 2. Ajout d une ressource dans une application Afin qu une ressource, quel que soit son type, soit intégrée à un package de déploiement d une application, il faut préalablement l ajouter dans les ressources de l application. Lorsqu une ressource est ajoutée, des actions automatiques sont effectuées par la console d administration et ce, en fonction du type de ressource. Lorsque vous ajoutez une ressource de type System.BizTalk:BizTalkAssembly, le contenu de l assembly est inspecté par la console d administration et déclaré dans la base de configuration du serveur : il s agit par exemple des schémas comme vous l apprendrez dans le chapitre Modélisation de messages. Nous allons illustrer l ajout d une ressource de type System.BizTalk:File. Une ressource de ce type nous permet de déployer des exemples de messages. La mise à disposition d exemples de messages directement dans le package MSI permet aux exploitants de valider le fonctionnement de l application immédiatement après son déploiement. Nous pouvons également déployer une procédure de tests (fichier bureautique) dans laquelle est indiquée la liste des étapes que l exploitant doit suivre pour s assurer que l application est fonctionnelle. Nous allons illustrer ces deux cas et dans un premier temps nous allons ajouter un exemple de message. Dans la console d administration BizTalk, ouvrez l application ENIEditions, sélectionnez le nœud Ressources, ouvrez le menu contextuel et sélectionnez l option Ajouter puis Ressources. Dans l écran Ajouter des ressources, cliquez sur le bouton Ajouter puis sélectionnez sur votre disque dur un fichier permettant de tester l échange entre la gestion commerciale et la comptabilité. Dans la zone Options, sélectionnez la valeur System.BizTalk:File dans la liste déroulante Type de fichier. Dans le champ Emplacement de destination, saisissez la valeur %BTAD_InstallDir%\Exemples\FichierSource.txt. Ce champ indique à quel emplacement sera copié le fichier lors de l installation de l application

75 Si la ressource existe déjà dans l application et si vous souhaitez la remplacer, cochez la case Remplacer tout. Afin d ajouter une procédure de tests dans les ressources, procédez à la même manipulation. Sélectionnez un fichier bureautique (Word par exemple) et précisez %BTAD_InstallDir%\Manuels\ENIEditions - procedure de tests.docx comme Emplacement de destination. Lorsque les deux ressources ont été ajoutées, voici comment se présente la liste des ressources de l application ENIEditions : Vous pouvez exporter l application sous forme d un fichier MSI. Toutes les ressources vont être intégrées dans le package. Procédez maintenant à la suppression de l application ENIEditions afin de repartir d un environnement vierge. Le fichier MSI de l application peut être téléchargé. Il s agit du fichier Chapitre4_avecRessources.msi

76 3. Installation d une ressource Importez le package MSI correspondant à l application ENIEditions. Si vous ne faites que l import du fichier MSI, les ressources de type System.BizTalk:File ne seront pas copiées sur le disque dur de la machine. Si vous installez le fichier MSI, les ressources sont copiées dans les sous répertoires indiqués lors de l ajout (champ Emplacement de destination). La copie d écran ci dessous illustre les sous répertoires Exemples et Manuels créés dans le répertoire d installation de l application : Je vous conseille donc d utiliser le plus possible les ressources des applications BizTalk pour déployer tous les éléments qui peuvent faciliter l usage de votre application et le travail des exploitants

77 Utilisation de scripts de déploiement 1. Usage des scripts de déploiement Afin de construire un package de déploiement qui minimise les actions manuelles, vous pouvez ajouter aux ressources de l application BizTalk des scripts de déploiement. Il s agit des ressources de type System.BizTalk:PreProcessingScript et System.BizTalk:PostProcessingScript. Les scripts de déploiement permettent l automatisation des tâches de déploiement. Ces scripts, qui peuvent s exécuter avant le déploiement (script de PréTraitement : PreProcessingScript) ou après le déploiement (script de PostTraitement : PostProcessingScript) peuvent contenir toutes les tâches que vous jugez utile d automatiser. Il peut s agir par exemple : de scripts mettant à jour une base de données ; de scripts permettant l arrêt/le redémarrage de services Windows de la machine BizTalk. Un script de déploiement peut être un fichier de commande Windows (extension.bat ou.cmd), un exécutable Windows ou.net (fichier.exe) ou tout autre fichier exécutable (PowerShell, Python...). La liste exhaustive des extensions de fichiers supportées est présente dans la variable d environnement PATHEXT du serveur BizTalk. 2. Ordre d exécution des scripts a. Phase d import et d installation Les scripts sont exécutés lors des phases d import, d installation ou de désinstallation d une application BizTalk. Le code contenu dans chaque script doit déterminer la phase de déploiement en cours afin d effectuer les actions correspondantes. Par exemple, ajouter des données dans une base de données lors de l installation et les supprimer lors de la désinstallation. Lors des phases d import et d installation, les scripts de pré traitement s exécutent juste avant l import ou l installation de l application. Les scripts de post traitement s exécutent immédiatement après l import ou l installation et en cas de réussite du déploiement uniquement. b. Phase de désinstallation Lors de la phase de désinstallation, l ordre d exécution est inversé : les scripts de post traitement s exécutent en premier, suivi des scripts de pré traitement. c. Présence de plusieurs scripts Plusieurs scripts de pré ou post traitement peuvent être présents pour la même application. Ils sont exécutés dans l ordre dans lesquels ils ont été ajoutés aux ressources de l application. d. Cas particulier des erreurs pendant le processus Si une erreur survient pendant l import d une application, les actions déjà exécutées sont annulées. Le script de post traitement est donc de nouveau exécuté. Le script peut consulter une variable d environnement, qui indique qu il s agit de l annulation d une phase (rollback). Le script peut ainsi réaliser l action qui correspond. Reportez vous au paragraphe Les variables d environnement utiles pour plus de détail. 3. Développer un script de déploiement Nous allons dans ce paragraphe développer un script de déploiement très simple afin d illustrer les concepts

78 a. Les variables d environnement utiles Avant de démarrer le développement, il faut connaître les variables d environnement mises à notre disposition par BizTalk. Ces variables d environnement peuvent être lues par les scripts pour détecter : la phase en cours (import, installation ) ; l action en cours (mise à jour, création ) ; la typologie d installation (locale ou distante). La liste des variables d environnement à notre disposition est la suivante : Nom de la variable d environnement Usage BTAD_ChangeRequestAction Indique quelle action a été demandée : Create : lors de l import/installation, la case Remplacer les ressources n a pas été cochée. Update : la case Remplacer les ressources a été cochée. Delete : désinstallation en cours. BTAD_HostClass Contient les valeurs suivantes : ConfigurationDb : indique que l opération en cours est effectuée sur la base de configuration du serveur BizTalk. BizTalkHostInstance : indique que l opération en cours est effectuée sur l ordinateur local. BTAD_InstallMode Contient les valeurs suivantes : Install : installation en cours. Import : import en cours. Uninstall : désinstallation en cours. BTAD_InstallDir BTAD_ApplicationName BTAD_SilentMode BTAD_Server BTAD_Database Indique le chemin complet du répertoire d installation sélectionné par l utilisateur. Indique le nom de l application en cours d import, d installation ou de désinstallation. Indique si l installation se déroule de manière silencieuse. Il y a plusieurs niveaux de silence, reportez vous à la documentation BizTalk pour connaître les valeurs correspondantes. Indique le nom de l instance SQL Server qui héberge la base de données de configuration BizTalk. Indique le nom de la base de données BizTalk dans lequel se trouve la configuration (par défaut, BizTalkMgmtDb). b. Implémenter le script

79 Nous allons implémenter un script très simple dont le but est de créer un fichier de trace avec l heure à laquelle les actions d import, installation ou désinstallation ont été effectuées. Voici le code du script off IF "Debut installation" %TIME% >>c:\log.txt IF "Debut import" %TIME% >> c:\log.txt IF "%BTAD_InstallMode%"==cd "Debut désinstallation" %TIME% >> c:\log.txt Le script vérifie l action en cours grâce à la variable d environnement %BTAD_InstallMode%. En fonction de l action en cours, le texte écrit dans le fichier journal est différent. Il est systématiquement concaténé à l heure système en cours (obtenue grâce à la variable système %TIME%). c. Ajouter le script dans les ressources de l application Vous devez maintenant ajouter le script dans les ressources de l application ENIEditions. Sélectionnez le nœud Ressources de l application ENIEditions, ouvrez le menu contextuel. Choisissez l option Ajouter puis Scripts de pré traitement. Dans l écran Ajouter des ressources, sélectionnez le fichier d extension.cmd dans lequel vous avez implémenté le script. Le type de ressource System.BizTalk:PreProcessingScript est automatiquement sélectionné :

80 Le script fait maintenant partie de l application. Le fichier MSI de l application peut être téléchargé. Il s agit du fichier Chapitre4_avecScript.msi. d. Tester le script Effectuez un import puis une installation pour tester le script. À l issue de ces deux actions, vous devez obtenir un fichier nommé Log.txt dans le répertoire à la racine du disque C:\ avec le contenu suivant : e. Perspectives offertes par les scripts Les scripts pré ou post traitements offrent beaucoup de possibilités d automatisation. Vous pouvez par exemple afficher une interface graphique à l utilisateur dans laquelle il doit renseigner des paramètres de votre application. Ces paramètres peuvent être utilisés pour mettre à jour un fichier de configuration utilisé par vos processus métier. Dans ce type de scénario, je vous conseille de procéder à du développement.net

81 au lieu d utiliser du script Windows qui ne permet pas la même souplesse graphique. Bien que les perspectives d automatisation soient importantes, il faut être prudent et mesurer le gain sur la phase d installation par rapport au temps passé à la mise au point des scripts. Comme nous l évoquions en début de chapitre, il faut trouver un juste milieu entre un package de déploiement parfait et un déploiement artisanal

82 Conclusion Nous avons abordé dans ce chapitre les principes du déploiement d applications BizTalk. Au fur et à mesure des chapitres de cet ouvrage, vous découvrirez que ces mécanismes facilitent grandement le déploiement de vos projets

83 Suivi des échanges 1. Particularité des solutions EAI L une des particularités des solutions EAI, si ces solutions devaient être comparées à d autres types de solutions informatiques comme les portails Web ou les applications de gestion, réside dans le fait qu assez peu de choses sont visibles de l extérieur notamment pour l utilisateur final. L essentiel de l implémentation est de la tuyauterie entre applications et donc totalement incompréhensible et invisible pour l utilisateur final. L objectif d une solution EAI est de faire circuler de l information de manière transparente pour les applications sources et destination et donc en quelque sorte d être le moins visible possible de l extérieur. Ce n est que lorsqu une "fuite" est constatée dans la plomberie que les choses deviennent visibles et c est malheureusement le moment le moins opportun. Par expérience, je remarque que la qualité des outils de suivi offerts aux utilisateurs est un élément qui différencie les solutions EAI d éditeurs par rapport aux solutions développées à façon par les entreprises (ce que l on appelle communément les "moulinettes" dans la plupart des entreprises). Lors du développement de solutions ad hoc, l effort de développement n est pas toujours concentré sur le développement d outils puisque l objectif premier est bel et bien de réaliser les échanges d informations. La plupart des solutions développées en interne ne disposent pas d outils pour suivre les échanges ou bien ces outils arrivent tard dans le projet. Mes expériences projet BizTalk me confortent dans l idée que la visibilité sur les échanges est fondamentale à plusieurs titres : Pour tester la solution mise en œuvre et donc s assurer qu elle effectue ce qu elle est censée faire. Pour fournir, dès le début du projet, des outils pour diagnostiquer les erreurs, comprendre les échanges, relancer les messages bloqués... Pour fournir aux utilisateurs, des indicateurs sur les échanges effectués dans l EAI. Ces indicateurs permettent de rendre visible la solution et de la promouvoir en interne en démontrant sa performance, sa robustesse. Pour fournir des indicateurs de fonctionnement afin de démontrer que la solution mise en œuvre respecte les objectifs initiaux du projet et satisfait aux attentes. C est finalement la seule manière de prouver, pour un chef de projet, que la mise en œuvre d une solution basée sur un outil EAI permet de satisfaire aux attentes énoncées dans le cahier des charges. L organisation de la table des matières de cet ouvrage tient compte du caractère fondamental du suivi : vous pouvez constater que dès le chapitre Introduction au BAM, nous évoquons le suivi fonctionnel des échanges et donc la production d indicateurs pour les décideurs, analystes et chefs de projets. 2. Suivi technique et suivi fonctionnel La visibilité donnée sur les échanges d informations effectués au sein de l EAI est fondamentale, à plusieurs étapes du projet, que ce soit pendant la mise au point de la solution ou en phase d exploitation. Cette visibilité sur les processus est censée répondre à deux besoins : Un besoin de suivi technique, la plupart du temps pour les équipes informatiques qui exploitent la solution au quotidien. Un besoin de suivi fonctionnel, pour les équipes projets, les analystes fonctionnels, les décideurs et les utilisateurs finaux. Dans ce paragraphe, nous détaillons les outils de BizTalk qui permettent le suivi technique. Dans les chapitres Introduction au BAM et BAM avancé, nous évoquons le suivi fonctionnel, matérialisé dans BizTalk dans le composant BAM (Business Activity Monitoring)

84 3. Vision globale de l environnement BizTalk BizTalk propose des outils permettant le suivi technique des échanges. Les outils proposés par BizTalk ont été grandement améliorés lors des deux dernières versions (2006/2006 R2 et 2009). On pouvait en effet reprocher à BizTalk Server 2004 d être relativement pauvre en outillage pour le suivi technique. La tendance constatée avec BizTalk 2009 est la centralisation de toutes les fonctionnalités de suivi dans un outil unique qui est la Console d administration BizTalk Server accessible depuis le menu Démarrer, groupe Microsoft BizTalk Server 2009 et Administration de BizTalk Server. Cette console d administration permet de réaliser trois catégories d opérations : L administration et la configuration de BizTalk et des applications implémentées dans BizTalk. Le déploiement des applications BizTalk. Le suivi des processus et des échanges. La console d administration BizTalk offre une vision globale de l environnement via l onglet Hub du groupe (Groupe Hub Page en version anglaise). Cet onglet est accessible lorsque vous cliquez sur le nœud BizTalk Group dans la console d administration. L onglet Hub du groupe donne une vision complète de l environnement comme l indique la copie d écran ci dessous : Dans cet écran, les informations sont regroupées en plusieurs parties que nous allons détailler. Nous parlerons à de nombreuses reprises, dans la suite de ce chapitre, d instances de service. Un service dans BizTalk est par exemple un port d envoi ou un port de réception. On parle d instance de service car le même service (port de réception par exemple), peut être exécuté plusieurs fois en même temps : réception de plusieurs messages en même temps provenant du même emplacement. Dans ce cas, plusieurs instances du port de réception s exécutent en parallèle

85 a. Présentation de la configuration Les informations suivantes sont présentées dans cette section de la page : Les applications avec le nombre d applications. Dans la copie d écran, il y a 8 applications. Le pictogramme bleu indique que toutes les applications ne sont pas démarrées sinon il serait vert. Les instances de l hôte (qui sont les services Windows de BizTalk). Dans cette copie d écran, il y a deux instances arrêtées, car le pictogramme correspondant est rouge. Les gestionnaires d adaptateur (ici au nombre de 31) qui correspondent à la liste des adaptateurs installés sur le système. En cliquant sur l un de ces liens, vous pouvez accéder à des éléments de configurations complémentaires. Si par exemple vous cliquez sur Instances de l hôte, vous serez dirigés vers l écran permettant la gestion des instances d hôtes BizTalk. b. Travaux en cours et suspendus Cette partie permet d obtenir une vision globale des instances en cours d exécution et des instances suspendues (par exemple en cas d erreur). Cette partie se décompose en : Travail en cours : indique le nombre de services en cours d exécution ou prêts à s exécuter. Éléments suspendus : indique le nombre d instances de service qui sont suspendues, qu elles puissent être relancées ou non. Instances de service suspendues groupées : offre une vision groupée des instances de service suspendues : par adresse de destination (URI : Unified Resource Identifier), par code erreur ou encore par application BizTalk. Un clic sur chaque lien permet de lancer une requête permettant d obtenir une vue détaillée de l élément sélectionné. Par exemple, si vous cliquez sur Instances de service suspendues, vous serez dirigés vers l écran cidessous :

86 c. Événements et instances de suivi Dans cette partie de l écran, vous disposez d un ensemble de liens permettant d accéder au suivi post exécution. Contrairement aux éléments que nous avons vus précédemment, ces liens permettent de visualiser les instances de service qui ont été exécutées et qui ont été terminées. En cliquant sur un lien, par exemple instances réussies, vous accédez à un écran de recherche des instances réussies illustré dans la copie d écran ci dessous :

87 Dans l écran ci dessus sont affichées toutes les instances de service qui ont été exécutées par le serveur BizTalk et dont l exécution a été effectuée avec succès. Par opposition aux instances réussies, vous pouvez consulter les instances terminées. Il s agit des instances de service dont l exécution n est pas arrivée à terme correctement. Les informations d historique sont préservées dans une base de données dite de Tracking (ou de Suivi). La durée de vie des données de suivi peut être paramétrée. 4. Suivi d un échange en temps réel a. Utilisation des requêtes Pour suivre l activité d un système BizTalk, le Hub de groupe est un point d entrée possible. Vous pouvez également utiliser l outil de requête proposé par la console d administration BizTalk. Si par exemple, vous cherchez toutes les instances de service de l application ENIEditions en cours d exécution ou suspendues, voici comment vous devez procéder : Dans la console d administration, sélectionnez le nœud BizTalk Group et cliquez sur l onglet Nouvelle requête. Dans le champ Rechercher, sélectionnez la valeur Toutes les instances de service en cours. Ajoutez ensuite un nouveau champ en sélectionnant Nom de l application dans la liste déroulante. Sélectionnez l application ENIEditions dans la liste déroulante. Cliquez sur Exécuter la requête. Remarquez que la console ajoute automatiquement un champ nommé Résultats (nb maximal) d une valeur de 50. Ce champ limite le nombre de résultats pour cette requête à 50. Vous pouvez modifier cette valeur. Dans le champ Rechercher, vous pouvez utiliser les différentes valeurs récapitulées dans la liste ci dessous. Toutes les instances de service en cours : instances de service en cours d exécution, qu elles soient

88 suspendues ou non. Instances de service en cours d exécution : instances de service en cours d exécution et non suspendues. Instances de service suspendues : instances de service suspendues. Messages : messages en cours d exécution, suspendus ou non. Abonnements : abonnés aux messages. Événements des messages suivis : événements des messages dont l exécution est réussie ou terminée. Instances de service suivi : instances de service réussies ou terminées. b. Détail d un service Via la console vous pouvez visualiser le détail d un service : Dans l application ENIEditions, sélectionnez le port d envoi sndcomptabilite_file, ouvrez le menu contextuel et sélectionnez l option Arrêter. Le but de cette opération est de stopper le port d envoi afin que nous ayons le temps de le voir dans les instances en cours d exécution. Déposez ensuite un fichier dans le répertoire d écoute de l emplacement de réception rcvgestioncommerciale_file et attendez que BizTalk réceptionne le fichier. Lancez une requête sur Toutes les instances de service en cours. À partir d une ligne dans les résultats de requête, ouvrez le menu contextuel et l option Détails sur le service (vous pouvez aussi double cliquer sur la ligne). Dans l onglet Général, vous obtenez des informations sur le service, notamment son état (ici, Suspendu (peut être repris)) et l heure de début d exécution

89 Dans l onglet Informations sur l erreur, vous pouvez consulter des informations lorsqu une instance de service est en erreur. Dans notre exemple, le message d erreur nous indique que l instance est suspendue car le service correspondant (le port d envoi) est arrêté

90 Enfin, dans l onglet Messages, vous pouvez consulter la liste des messages qui sont ou seront traités par l instance de service. Dans notre cas, il s agit du message qui sera envoyé par le port d envoi

91 c. Détail d un message Accès au détail d un message depuis le détail d une instance de service Depuis l onglet Messages du détail d un service, l option Détails sur le message permet d atteindre le détail d un message : L onglet Général permet de consulter des informations générales sur le message comme l heure à laquelle il a été créé ou bien le nom de l hôte BizTalk qui l a traité :

92 L onglet Contexte affiche l ensemble du contexte de ce message. Pour rappel, le contexte d un message permet de disposer d un ensemble d informations qui caractérisent le message et certaines informations du contexte permettent de faire le routage. Jusqu ici nous avons par exemple utilisé la propriété ReceivePortName qui contient le nom du port de réception qui a réceptionné le message. L onglet body permet de consulter le corps du message (le body). Vous pouvez le visualiser en version textuelle ou

93 en version binaire : Autres alternatives pour accéder au détail d un message Il existe deux alternatives complémentaires pour visualiser le détail d un message : Soit en lançant une requête de type Messages et en ouvrant le menu contextuel Détails du message dans les résultats de la requête. Soit en utilisant l option Afficher les messages du menu contextuel à partir d une instance de service. Cette option affiche tous les messages traités par l instance de service. À partir de la liste des messages, vous pouvez accéder au détail de chacun. 5. Suivi d un échange après son exécution Nous venons d illustrer les différentes fonctions de la console d administration BizTalk permettant de suivre l activité des applications BizTalk et des messages échangés. Ce que nous venons de voir permet de suivre en temps réel l activité des échanges. La console d administration propose également des fonctionnalités pour consulter les services qui ont été exécutés ainsi que les messages correspondants. Nous parlons de suivi post exécution. Dans les versions précédentes de BizTalk, jusqu à la version 2009, le suivi post exécution était accessible depuis un outil appelé le HAT (Health & Activity Tracking). Cet outil a disparu officiellement mais en cherchant bien on retrouve de temps à autre des écrans du HAT dans la console d administration... Deux fonctions permettent de visualiser les données post exécution : La requête Instances de service suivi pour visualiser l ensemble des instances de service qui ont été exécutés. La requête Événements des messages suivis pour visualiser l ensemble des événements relatifs aux messages exécutés (réceptions, envois, échecs de transmissions...)

94 a. Contenu de la base de données de suivi La base de données de suivi (base de données SQL Server nommée BizTalkDTADb) contient toutes les informations sur les instances de service et les messages dont l exécution est réussie ou terminée. Lorsque l exécution d un service est réussie ou terminée, les informations sur l instance de ce service ainsi que le ou les messages correspondants sont automatiquement copiées de la base de données BizTalkMsgBoxDb (MessageBox de BizTalk) vers la base de données BizTalkDTADb. Ce processus de copie des données est effectué : d une part par l instance de l hôte BizTalk (c est à dire l exécutable de BizTalk) ; d autre part par une tâche planifiée dans SQL Server qui s exécute très régulièrement (chaque minute). Afin de déterminer quels événements de quels services et quels messages doivent être copiés dans la base de suivi, BizTalk s appuie sur un paramétrage effectué lors de la configuration d une application BizTalk. Ce paramétrage permet d indiquer si un service doit être suivi ou si le contenu d un message doit être conservé dans la base de suivi post exécution. Le paramétrage du suivi peut être effectué : Au niveau d un port. Permet de spécifier quelles informations d un message doivent être conservées : le corps du message et/ou les propriétés du contexte. Ce paramétrage indique également à quel moment les données doivent être conservées : avant l exécution du port ou après. La copie d écran ci dessous illustre ce paramétrage accessible via le menu contextuel Suivi sur chaque port d envoi/port de réception : Au niveau d un pipeline. Dans notre première application BizTalk, nous utilisons le pipeline PassThruReceive lors de la réception et le pipeline PassThruTransmit pour l envoi. Via le menu contextuel Suivi sur chaque pipeline, nous pouvons paramétrer le comportement que doit adopter BizTalk lors du suivi

95 Comme vous pouvez le constater dans la copie d écran ci dessus, les options suivantes sont cochées par défaut : Événements de début et de fin de port : indique à BizTalk qu il doit mémoriser le démarrage et la fin d exécution de chaque instance du pipeline utilisé dans un port. Événements de l envoi et de la réception des messages : indique à BizTalk qu il doit mémoriser l envoi et la réception des messages qui transitent par le pipeline. Le pipeline peut également être paramétré pour mémoriser le corps des messages qui sont traités, avant ou après l exécution du pipeline. Dans le cas d un pipeline PassThru (PassThruReceive ou PassThruTransmit), le corps du message n est pas modifié dans le pipeline donc les deux options produisent le même effet. Lorsque nous utiliserons d autres pipelines qui modifient le corps des messages dans les prochains chapitres, ces deux options permettront de comparer le message entrant et le message sortant et parfois de détecter de potentielles erreurs dans le pipeline. Par défaut, le corps des messages traités par les pipelines n est pas préservé dans la base de suivi. Si vous choisissez de mémoriser le corps des messages, la base de données de suivi (BizTalkDTADb) peut devenir très volumineuse. En contrepartie, si vous ne mémorisez pas le corps des messages, vous ne pourrez plus visualiser le contenu des messages postérieurement à leur exécution. b. Utilisation de la requête Événements des messages suivis Cette requête permet de visualiser les événements (réception et envoi) des messages qui ont été traités par BizTalk. L exemple ci dessous illustre l utilisation de cette requête pour visualiser tous les messages traités par le port d envoi sndcomptabilite_file

96 À chaque exécution du port d envoi sndcomptabilite_file correspondent deux lignes : Une ligne pour le message avant son traitement par le port d envoi (ligne dont le type d événement est égal à Recevoir). Une ligne pour le message après son traitement par le port d envoi (ligne dont le type d événement est égal à Envoyer). Sur chaque ligne un menu contextuel permet d accéder aux fonctions suivantes : Détails sur le message Donne accès au contenu du message. Cette option fonctionne uniquement si BizTalk a été configuré pour préserver le corps du message. Flux de messages Donne accès au flux du message, c est à dire au cheminement que le message a parcouru au sein de BizTalk. Afficher les instances de service suivi Lance une requête permettant de visualiser l instance de service qui a traité ce message (exemple : l instance du port d envoi). Afficher le message Live Lance une requête (cette fois ci dans le suivi temps réel) permettant d afficher le message Live. Un message Live est un message qui est encore en cours d exécution. Si par exemple, la réception du message est terminée, l instance du port de réception est donc dans la base de suivi post exécution. Le port d envoi, s il est encore en cours d exécution, est quant à lui disponible dans le suivi temps réel. L option Afficher le message Live vous permet d accéder à l instance de service qui traite encore le message. Enregistrer dans le fichier Cette option permet de sauvegarder sur disque le contenu du message ainsi que son contexte. c. Utilisation de la requête Instances de service suivi La requête Instances de service suivi permet de lister toutes les instances de service dont l exécution est réussie ou terminée

97 Pour bien comprendre la différence entre la requête Événements des messages suivis et Instances de service suivi, rappelez vous : Qu un même message est traité par un ou plusieurs services (séquentiellement ou parallèlement). Qu un service peut traiter plusieurs messages. Nous le verrons dans le prochain chapitre, un message entrant peut, à l issue de l exécution d un port de réception, être découpé en plusieurs messages. Voici une copie d écran de la requête Instances de service suivi : Le menu contextuel sur chaque résultat contient les fonctions suivantes : Flux de message Donne accès au flux du message, c est à dire au cheminement que le message a parcouru au sein de BizTalk. Afficher les événements des messages suivis Donne accès à la requête Événements des messages suivis pour les messages de l instance de service concernée. Afficher l instance de service Live Lance une requête sur la base de suivi temps réel pour obtenir des informations sur l instance de service en cours d exécution. 6. Consultation du registre des abonnés BizTalk Vous l avez compris, l architecture de publication/souscription de BizTalk repose sur la notion d abonné. Il est donc fondamental de disposer d une vue d ensemble de tous les abonnés. La console d administration BizTalk propose une requête permettant de retrouver la liste des abonnés et de rechercher un abonné particulier. Cette fonction est illustrée dans la copie d écran suivante

98 Pour chaque abonné, l option Détails d abonnement permet de visualiser l expression de filtre associée à l abonné comme l illustre la copie d écran ci dessous : Vous pouvez noter qu il existe deux catégories d abonnement : des abonnements d activation et des abonnements d instances. Dans des scénarios de messagerie pure (sans orchestrations) seuls les abonnements d activation existent. L arrivée d un message dans BizTalk qui respecte les conditions de l abonnement provoque l activation d un port, c est à dire la création d une nouvelle instance de ce port et son exécution. Nous rencontrerons des abonnements d instance dans le chapitre Implémentation de processus métier. Dans le chapitre précédent, nous avons évoqué l inscription du port d envoi et son démarrage. Un port d envoi peut tout à fait exister et disposer d un filtre sans pour autant apparaître dans la liste des abonnés

99 Cela signifie qu il n a pas été Inscrit

100 Architecture des bases de données Nous venons d illustrer comment la console d administration de BizTalk peut nous aider dans les différentes tâches de suivi. Les données affichées dans cette console proviennent de différentes bases de données alimentées par BizTalk au fur et à mesure de l exécution des services et du traitement des messages. Nous allons, dans ce paragraphe, apporter quelques précisions concernant les bases de données sous jacentes. 1. MessageBox a. Rappels sur le rôle de la MessageBox La MessageBox est le point de persistance de l ensemble des messages qui transitent par BizTalk. Les messages sont publiés dans la MessageBox puis consommés par des abonnés. Le message persiste dans la MessageBox tant qu il est en cours de traitement ou tant qu il est suspendu. Lorsqu un message a été consommé correctement par l ensemble des abonnés ou terminé prématurément par un utilisateur, il n a plus de raison de rester dans la MessageBox. b. Purge des données de la MessageBox Afin que la MessageBox ne contienne que les instances de service et de messages en cours d exécution, des opérations de purge sont effectuées conjointement par : l hôte BizTalk en charge du suivi ; une collection de tâches planifiées SQL Server (SQL Server jobs) planifiées très régulièrement (certaines chaque minute). Ces traitements permettent : de faire disparaître de la MessageBox les données qui correspondent aux instances complétées et aux instances terminées ; de copier dans la base de données de Suivi (nommée BizTalkDTADb) les données devant être préservées, ceci en fonction du paramétrage de Suivi précisé dans la configuration de chaque service. En rythme de croisière, la base de données BizTalkMsgBoxDB qui héberge la MessageBox est donc de taille très raisonnable (de l ordre de quelques centaines de mégaoctets). Une base de données BizTalkMsgBoxDB de taille importante signifie le plus souvent un grand nombre d instances de service suspendus et/ou un volume important de traitements en cours. 2. Données de suivi a. Base de données BizTalkDTADB La base de données BizTalkDTADb contient les données de suivi. Cette base de données est alimentée par les processus de purge de la MessageBox. Lorsque, dans la console d administration BizTalk, vous utilisez des requêtes sur les instances de service suivi ou les messages suivis, c est cette base de données qui est utilisée. b. Montée en charge de la base de suivi Les données copiées dans la base de suivi (BizTalkDTADb) peuvent, après plusieurs mois, représenter un volume important. Ce volume de données est d autant plus important si le paramétrage du suivi est configuré pour préserver le corps des messages

101 Les mécanismes de suivi proposés par BizTalk constituent la solution la plus adaptée aux besoins de suivi post exécution des projets EAI. La mise en œuvre de mécanismes ad hoc, développés en dessus de BizTalk (ports d archivage, pipeline d archivage...) est à mon sens, très rapidement inadaptée aux volumes de données et aux besoins de suivi. Je vous conseille donc d utiliser les mécanismes standards offerts par BizTalk. c. Définition d une stratégie de suivi Il convient, dans chaque projet et parfois pour chaque processus métier d établir : La stratégie de conservation des données : quelles informations faut il préserver? Faut il préserver le corps des messages? Si oui, à quel moment dans le processus et quel en sera l usage? La durée de conservation en ligne : combien de temps les données de suivi doivent elles être accessibles depuis la console BizTalk? Les procédés de restauration de données archivées : si l information recherchée n est pas disponible en ligne, comment faut il procéder pour la restaurer et la mettre à disposition et comment identifier le bon jeu de sauvegarde? Cette liste non exhaustive de questions que doivent se poser les chefs de projets EAI, trouvent réponses le plus souvent auprès des utilisateurs concernés (soit les utilisateurs finaux soit les exploitants). Lorsque des réponses à ces questions ont été apportées, la configuration BizTalk doit être adaptée pour refléter les choix de l équipe projet, ce que nous illustrons dans les paragraphes suivants. d. Définition des données à préserver Dans BizTalk, la définition des données à préserver est effectuée : au niveau des pipelines, au niveau des ports (réception ou envoi) et au niveau des schémas (nous le verrons dans le chapitre Modélisation de messages). Configuration des pipelines La configuration des pipelines est illustrée dans la copie d écran ci dessous, accessible depuis le menu contextuel et l option Suivi sur chaque pipeline :

102 La configuration du suivi d un pipeline se décompose en deux aspects : Le suivi des événements : Événements de début et de fin de port : un événement sera préservé dans la base de suivi au début d exécution du port qui utilise le pipeline, idem pour la fin d exécution. Événements de l envoi et de la réception des messages : un événement sera préservé lors de la réception d un message, idem pour l envoi. Le suivi du corps des messages : Message antérieur au traitement du pipeline : préserve le corps du message avant qu il ne soit traité par le pipeline. Message postérieur au traitement du pipeline : préserver le corps du message après son traitement par le pipeline. La configuration effectuée sur un pipeline s applique automatiquement à tous les ports qui utilisent le pipeline, sauf si une configuration différente est effectuée sur le port. Configuration des ports La configuration de suivi d un port (de réception ou d envoi) est accessible depuis le menu contextuel et l option Suivi sur le port :

103 Lorsque l on configure le suivi d un port, les options suivantes sont accessibles : Suivre le corps de message : Message de requête avant le traitement de port : stocke le contenu du message avant qu il ne soit traité par le port. Message de requête après le traitement de port : stocke le contenu du message après son traitement par le port. Suivre les propriétés de message : Message de requête avant le traitement de port : stocke le contexte du message avant son traitement par le port. Message de requête après le traitement de port : stocke le contexte du message après son traitement par le port. La configuration que vous sélectionnez au niveau d un port vient surcharger la configuration de suivi associée au pipeline. L intérêt de choisir avant ou après l exécution du port permet de comparer le contenu d un message avant qu il n entre dans BizTalk et son contenu après le traitement par le pipeline. Si le pipeline effectue des traitements sur le port ou si une transformation du message est effectuée par le port, vous pourrez ainsi comparer les deux messages. Attention cependant à la taille nécessaire dans la base de données de suivi pour le stockage des messages. e. Définition de la durée de préservation des données La durée pendant laquelle les données d historique sont conservées dans la base de suivi est paramétrable. Ce paramétrage est possible au niveau d une tâche de l Agent SQL Server

104 Pour accéder à ce paramétrage, ouvrez la console d administration de SQL Server (SQL Server Management Studio). Après connexion à l instance SQL Server qui héberge les bases de données de BizTalk, vous pouvez visualiser une tâche nommée DTA Purge and Archive, comme indiqué dans la copie d écran suivante. Pour paramétrer cette tâche (qui par défaut est inactive), voici comment procéder : Sélectionnez la tâche DTA Purge and Archive puis ouvrez le menu contextuel. Sélectionnez ensuite l option Propriétés. Dans la page Général, vous devez tout d abord activer la tâche afin qu elle s exécute, cochez la case Activé. Dans la page Etapes, sélectionnez la première étape (la seule) et cliquez sur le bouton Modifier. Vous devez maintenant modifier les paramètres passés à la procédure stockée dtasp_backupandpurgetrackingdatabase qui est appelée par ce travail SQL Server

105 Le code d appel à la procédure stockée est représenté ci dessous : exec dtasp_backupandpurgetrackingdatabase 0, --@nlivehours tinyint, --Any completed instance older than the live hours +live days 1, --@nlivedays tinyint = 0, --will be deleted along with all associated data 30, --@nharddeletedays tinyint = 0, --all data older than this will be deleted. null, --@nvcfolder nvarchar(1024) = null, --folder for backup files null, --@nvcvalidatingserver sysname = null, 0 --@fforcebackup int = 0 -- Les paramètres à modifier sont les suivants : fenêtre de temps (en heures) de préservation des données des instances : fenêtre de temps (en jours) de préservation des données des instances : fenêtre de temps (en jours) de préservation des données correspondant aux instances terminées en : chemin du répertoire de sauvegarde

106 Les valeurs par défaut permettent de préserver pendant 1 jour les instances réussies et 30 jours les instances en erreur. Avant chaque exécution, la tâche se charge de sauvegarder ce qui doit être purgé. Les données purgées pourront donc être restaurées. Lorsque vous avez modifié les paramètres d appel, vous pouvez également modifier la planification de ce travail. Par défaut ce travail s exécute chaque minute mais selon la fenêtre de conservation des données paramétrée, vous pouvez l exécuter plus rarement (1 fois par semaine par exemple). f. Restauration de données archivées Lorsque des données doivent être purgées par la tâche planifiée DTA Purge and Archive, une sauvegarde des données est effectuée dans le répertoire paramétré au niveau de la tâche planifiée. Cette sauvegarde contient les données purgées. Le fichier de sauvegarde est déposé dans le répertoire précisé dans le et son nom est automatiquement calculé. Si vous souhaitez restaurer les données archivées, vous pouvez le faire avec les mécanismes classiques de restauration de bases de données de SQL Server. Lorsque la base de données a été restaurée, vous configurez la console d administration de BizTalk pour qu elle pointe sur cette nouvelle base de données, voici comment procéder : Dans la console d administration, sélectionnez le nœud racine nommé Administration de BizTalk Server Ouvrez le menu contextuel et cliquez sur l option Se connecter à une base de données des suivis existante :

107 Sélectionnez la base de données de suivi qui a été restaurée : Dans cet exemple, elle se trouve sur le même serveur que la base de suivi active. Cependant, dans un environnement de production, les données de suivi restaurées peuvent être hébergées dans une autre instance SQL Server. Lorsque la connexion est établie, vous verrez apparaître un nouveau nœud dans la console d administration. En sélectionnant ce nœud, vous pouvez ensuite lancer des requêtes sur le contenu de la base de données : Vous pouvez connecter plusieurs bases de données de suivi existantes à la console d administration, chacune correspondant par exemple à une période bien précise de votre activité. 3. Bases de configuration

108 Les bases de données BizTalkMsgBoxDb et BizTalkDTADb contiennent des données qui évoluent dans le temps. Il s agit en effet des messages et instances de service en cours d exécution ou dont l exécution est réussie et terminée. BizTalk s appuie également sur deux bases de données qui contiennent la configuration du système, il s agit des bases BizTalkMgmtDb et SSODB. a. Base de données BizTalkMgmtDb La base de données BizTalkMgmtDb est la principale base de configuration de BizTalk. Lorsque la configuration d un groupe BizTalk est effectuée, c est la première base de données créée. Cette base de données contient des références vers les autres bases de données utilisées par BizTalk (notamment la base BizTalkMsgBoxDb et BizTalkDTADb). Vous pouvez d ailleurs remarquer que la console d administration BizTalk est directement connectée à cette base de données. En outre, cette base de données contient l ensemble des informations nécessaires au bon fonctionnement d un groupe BizTalk. Lorsque vous créez un port d envoi, sa configuration est stockée dans cette base de données (nom du port d envoi, pipeline associé...). Par contre, deux éléments ne sont pas stockés dans cette base de données : L abonnement : si le port est enregistré comme abonné, l abonnement est stocké dans la MessageBox. L expression de filtre est quant à elle bien stockée dans la base de configuration. Les données confidentielles : comme les mots de passe ou la configuration des emplacements de réception sont stockées dans la base SSODB. b. Base de données SSODB La base de données SSODB est particulière car elle est sécurisée, son contenu est chiffré avec un secret. Le secret (la clé de chiffrement) est généré lors de la configuration de BizTalk et stocké dans le profil du compte qui exécute le service Windows nommé Service de l authentification unique de l entreprise (ENTSSO). Ce secret permet au service ENTSSO de déchiffrer la base de données et de fournir les informations qu elle contient aux composants de BizTalk qui en ont besoin. Lorsque la console d administration BizTalk souhaite récupérer ou mettre à jour une information confidentielle (mot de passe par exemple), elle s adresse au service ENTSSO qui réalise l opération avec la base de données. En cas de changement d identité du service Windows ENTSSO, suivez la procédure qui consiste à sauvegarder le secret pour ensuite le restaurer. L usage de la base SSODB n est pas limité au stockage de données confidentielles de configuration mais peut être étendu : À la mise en place de scénarios de SSO (Single Sign On) : correspondances de comptes internes/externes et stockage de mots de passe. Au stockage d éléments de configuration applicatifs hors BizTalk (via une API proposée par BizTalk). Plusieurs exemples de ce type sont présents dans le SDK BizTalk

109 Gestion des erreurs Lorsqu une erreur se produit dans un processus d échange, cette erreur provoque la plupart du temps la suspension de l instance de service correspondante (instance du port d envoi ou du port de réception dans une solution de messagerie). Nous allons apprendre dans ce paragraphe à utiliser les outils de BizTalk pour la détection des erreurs et la relance de services. 1. Détecter et diagnostiquer une erreur a. L outillage BizTalk Des erreurs diverses et variées peuvent se produire dans une solution BizTalk et la complexité pour les diagnostiquer augmente proportionnellement avec la complexité des processus que vous implémentez. Il convient donc de s armer des meilleurs outils de diagnostic pour résoudre au plus vite les problèmes rencontrés mais aussi pour fournir aux exploitants BizTalk les procédures de résolution les plus performantes possibles. Les outils d administration que nous avons vus précédemment sont des outils fondamentaux à la fois pour détecter une erreur (grâce aux requêtes de recherche) mais aussi pour diagnostiquer le problème (grâce aux détails sur les services, les messages, la visualisation du contenu des messages...). b. Le journal des événements Applications de Windows En plus des outils BizTalk, je vous conseille de consulter le journal Applications de Windows. Ce journal est nourri d avertissements et d erreurs qui correspondent aux événements se produisant dans BizTalk. Lorsqu une instance de service est suspendue dans BizTalk, une erreur est tracée dans le journal Applications. Dans la copie d écran ci dessus, le contenu de l événement donne immédiatement des indications sur le problème rencontré. Dans cet exemple, BizTalk essaie d écrire dans un répertoire qui n existe pas. Si votre entreprise utilise un outil de suivi technique de vos serveurs et applications (MS System Center Operation Manager, MS Operation Manager, NAGIOS, WhatsUp, ou autres), vous pouvez demander à vos exploitants de scruter le contenu des journaux Applications des serveurs BizTalk. En détectant les avertissements et erreurs provenant de la source BizTalk Server 2009, ils pourront déclencher des alertes ciblées. 2. Reprise d une instance de service suspendue En cas d erreur lors de l exécution, l instance de service correspondant au port est suspendue et peut être relancée

110 directement depuis la console BizTalk avec la fonction Reprendre l instance comme l illustre la copie d écran cidessous. Pour reprendre une instance de service, il faut que celle ci soit dans un état Suspendu (peut être repris). La reprise d une instance de service provoque sa réexécution complète, le message qui a transité par le port est de nouveau traité comme lors de la première exécution. Cette fonction permet, par exemple, de relancer un port d envoi qui n a pu atteindre le destinataire et dont le nombre de tentatives d envois a été atteint. 3. Arrêter une instance de service Lorsqu une instance de service est suspendue, vous pouvez choisir de l arrêter avec l option Arrêter l instance. Lorsque vous arrêtez prématurément une instance de service, celle ci est marquée comme Terminée avec comme description d erreur L instance a été interrompue par l utilisateur : Comme l illustre la copie d écran ci dessus, vous pouvez aisément distinguer les instances de service arrêtées manuellement (ici la première de la liste). Elles sont à l état Terminé contrairement aux instances dont l exécution a été menée à terme par BizTalk qui sont à l état Réussi. 4. Limites de la gestion d erreurs dans la console BizTalk a. Cas particuliers où la relance d une instance n est pas suffisante À l usage, vous mesurerez que la console d administration de BizTalk permet le plus souvent de relancer un processus ou un échange grâce aux fonctions qu elle propose nativement. En revanche, vous serez confrontés aux problématiques dans lesquelles la relance d un message ne peut pas résoudre les problèmes rencontrés. Si par exemple un message entrant n est pas conforme à vos attentes et provoque une erreur dans le port de réception, vous pourrez le relancer autant de fois que vous le souhaitez cela ne modifiera pas le comportement du port de réception puisque le problème vient du message lui même. La seule solution est donc la correction du message puis de sa resoumission à BizTalk

111 b. La correction d un message est elle utile? Je m interroge souvent sur l intérêt d une fonctionnalité permettant de corriger et relancer un message dans un environnement de production. Si l on transpose ce besoin à un autre secteur que l informatique, il est facile de se forger une opinion. Supposez par un exemple une scierie qui produit des planches de bois. Cette scierie doit produire des planches de bois peintes en rouge et noir pour un client. Lorsque les planches sont terminées, la scierie demande à un transporteur de charger les produits et les livrer à son client. Lorsque le transporteur livre son chargement au client, ce dernier le refuse car les planches n ont pas été peintes comme convenu, elles sont brutes. Le transporteur doit en toute logique recharger les produits, les retourner à la scierie. Il n est évidemment pas en cause dans le problème. Si le transporteur avait à sa disposition une fonction de correction et resoumission, il pourrait prendre l initiative de repeindre les planches et d essayer de les livrer de nouveau au client. Bien entendu, il ferait cela sans même avertir la scierie... Les conséquences de la correction/resoumission dans ce scénario sont les suivantes : C est au transporteur de corriger le problème alors qu il n a pas la compétence ni le budget pour le faire. La scierie n est pas mise au courant du problème, elle pense donc avoir honoré son contrat. Lors d une prochaine production de planches pour le même client, elle risque de nouveau de livrer des planches non peintes... BizTalk est le transporteur dans ce scénario. Est ce que c est à lui de corriger les problèmes des applications externes? Je ne pense pas. Le seul cas d utilisation d une correction de messages dans BizTalk est la phase de développement et de tests. c. Comment faire pour corriger un message et le relancer? Si vous n avez pas été convaincu par ma démonstration sur le transporteur de planches, vous pouvez tout de même trouver dans BizTalk des fonctionnalités permettant la correction et resoumission. La seule solution offerte nativement dans BizTalk est la sauvegarde du message en erreur puis le dépôt de ce message de nouveau dans l emplacement de réception. Cela est possible via la fonction Enregistrer dans le fichier à partir de la requête Messages. À l issue de l enregistrement du fichier, vous obtiendrez deux fichiers : Un fichier d extension.out qui est le corps du message. Un fichier d extension.xml qui correspond à la liste des propriétés contextuelles du message. Afin de relancer le message, vous devez corriger le contenu du fichier.out pour le déposer de nouveau dans le répertoire d entrée. Vous constatez que cette opération est fastidieuse et un peu artisanale. Si toutefois vous souhaitez utiliser cette fonction de manière plus fréquente, le Microsoft BizTalk ESB Toolkit 2.0 contient des fonctionnalités plus complètes permettant par exemple la publication du message en erreur dans un portail et sa correction/resoumission depuis l interface Web. Le cas d erreur que nous citons dans ce paragraphe (message entrant non conforme devant être corrigé pour être resoumis) est très souvent rencontré dans des solutions BizTalk où la structure des messages est modélisée. C est l objectif du prochain chapitre : Modélisation de messages

112 5. Les erreurs de routage a. Qu est ce qu une erreur de routage? Les fonctions permettant l accès au registre des abonnés sont utiles lorsqu un message, censé être délivré à un abonné, est en erreur de routage (ou routing failure). Lorsqu aucun abonné n existe pour un message publié dans la MessageBox, une erreur de routage se produit. Cette erreur provoque le comportement suivant : L instance du port de réception est suspendue. Un rapport d erreur de routage est créé dans la console d administration BizTalk. Vous rencontrerez très souvent des erreurs de routage lorsque vous débuterez avec BizTalk Server, notamment lors de vos différents tests et utilisations de filtres. b. Comment traiter une erreur de routage? Le rapport d erreur de routage est censé vous aider à résoudre l erreur qui vient de se produire. Ce rapport contient en effet une photographie des données contextuelles du message au moment où l erreur a été générée. En consultant ces éléments, vous pouvez ainsi vous rendre compte des informations qui sont disponibles dans le contexte du message au moment de sa publication, et peut être mesurer qu un filtre que vous pensiez correct ne l est pas : À partir du rapport d erreur de routage, vous pouvez accéder aux fonctions proposées par le menu contextuel associé, option Dépannage de l échec du routage : Rechercher l instance de service ayant échoué Ouvre une nouvelle requête et isole l instance de service qui a échoué (exemple : l instance du port de réception). Afficher tous les abonnements Ouvre une requête pour afficher tous les abonnements. Afficher tous les abonnements d activation Ouvre une requête pour afficher tous les abonnements de type activation. Dépannage des échecs du routage

113 Ouvre l aide en ligne de BizTalk Server. En plus de ces fonctions spécifiques aux rapports d erreur de routage, vous disposez des fonctions classiques permettant par exemple la visualisation des messages (contexte et contenu). Lorsqu une erreur de routage se produit, il n est pas toujours simple de diagnostiquer, même avec le rapport d erreur de routage, pourquoi un message n a pas été correctement routé. Sur ce point, les outils BizTalk ne peuvent pas vous apporter plus d aide, il convient d être très rigoureux dans la définition de vos filtres. Par expérience, une erreur de routage se produit le plus souvent soit à cause d une erreur de saisie d un filtre ou bien lorsqu un port d envoi n est pas Inscrit. Lorsque vous avez compris pourquoi le message n a pas été routé correctement et après avoir réglé le problème (par exemple, après correction du filtre sur un port d envoi), vous pouvez relancer la réception du message. Pour cela, utilisez l option Reprendre l instance sur l instance suspendue du port de réception. Si votre erreur n a pas été corrigée, vous verrez apparaître de nouveau un rapport d erreur de routage et l instance du port de réception sera de nouveau suspendue. Si votre erreur a été corrigée, l instance du port de réception va s exécuter puis disparaître de la liste des instances en cours d exécution. Au lieu de relancer la réception du message en erreur de routage, vous pouvez également décider de terminer le processus de réception soit pour le relancer depuis l application source par exemple, soit parce que ce message n aurait de toute façon pas dû être réceptionné par BizTalk. Dans ce cas, vous utilisez la fonction Terminer l instance que nous avons évoquée précédemment. 6. Gestion automatisée des erreurs a. Principes et fonctionnement Nous venons d exposer dans les paragraphes précédents la manière dont la console d administration BizTalk peut être utilisée pour traiter les différents cas d erreurs et surtout relancer ou terminer des services qui sont en erreur. Toutes les étapes que nous avons exposées sont manuelles et nécessitent donc des interactions humaines. Cela suppose que l acteur censé traiter les cas d erreurs soit consciencieux et vérifie régulièrement, dans la console BizTalk, que des services sont suspendus ou arrêtés et qu il réalise en temps et en heure les actions correctives nécessaires. Afin de le prévenir de la présence d instances de service suspendues, plusieurs approches sont possibles en standard avec BizTalk et notamment : La mise en œuvre d un mécanisme d alerte dès qu un service est suspendu. Nous évoquerons ces mécanismes dans le chapitre Administration de BizTalk en illustrant comment l API WMI de BizTalk peut être utilisée. La publication des messages en erreur dans un outil offrant les services de correction d erreurs nécessaires. Dans BizTalk, lorsqu un message est en erreur (erreur de routage, erreur lors de la réception...), le message est suspendu et l instance du port de réception est également suspendue. C est le comportement par défaut que nous avons évoqué dans les paragraphes précédents. Il existe cependant une alternative évitant de suspendre les services en erreur. Cette alternative s appelle l activation du routage des messages en erreur (enable routing for failed message). Le principe est le suivant : au lieu de suspendre le message, celui est publié de nouveau dans la MessageBox mais son contexte est modifié comme suit : Toutes les propriétés promues deviennent non promues. BizTalk ajoute dans le contexte du message des nouvelles propriétés promues qui qualifient l erreur rencontrée. Étant donné qu il existe dans le contexte du message des informations sur l erreur rencontrée et que ces informations sont promues, il est tout à fait possible de s abonner aux messages en erreur et de les router : il est

114 ainsi possible de créer un port d envoi pour les messages en erreur permettant la publication de tous ces messages dans un répertoire, l envoi par e mail ou encore mieux la publication dans un portail Web de gestion d erreurs. La copie d écran ci dessous illustre le contexte d un message en erreur : De nouvelles propriétés de contexte ont été ajoutées automatiquement au message afin de qualifier l erreur qui a été générée. Il s agit des propriétés de contexte suivantes : Propriété Description Description ErrorType Contient la description de l erreur. Contient toujours la valeur FailedMessage. ProcessingServer SendPortName ReceivePortName FailureAdapter Contient le nom du serveur BizTalk sur lequel l erreur s est produite. Quand vous disposez d une ferme de serveurs, cette information permet de cibler le serveur qui a provoqué l erreur. Nom du port d envoi dans lequel l erreur s est produite. Cette propriété est présente uniquement si l erreur s est produite dans un port d envoi. Nom du port de réception dans lequel l erreur s est produite. Cette propriété est toujours présente. Cependant, elle n est pas promue si l erreur s est produite dans le port d envoi. Nom de l adaptateur associé au port d envoi ou de réception. S il s agit d une erreur de routage, la valeur de cette propriété sera BizTalkMessagingEngine. FailureCategory FailureCode FailureTime Catégorie d erreur. Cette propriété n est pas utilisée mais toujours présente. Code de l erreur. Reportez vous à la documentation pour la liste des codes erreur. Date et heure de l erreur

115 InboundTransportLocation OutboundTransportLocation RoutingFailureReportId FailureInstanceId FailureMessageId MessageType Adresse de réception du message. Adresse d envoi du message (le cas échéant). Identifiant du rapport d échec de routage (en cas d erreur de routage). Identifiant unique l instance de service qui a déclenché l erreur. Identifiant unique du message qui a provoqué l erreur. Type de message en erreur. Renseigné uniquement si le message a été modélisé. (cf. chapitre Modélisation de messages). Ces nouvelles propriétés contextuelles sont utilisables dans le filtre d un port d envoi : b. Exemple d utilisation Afin d illustrer ce fonctionnement, nous allons modifier notre implémentation du routage effectuée au début de ce chapitre pour : introduire une erreur lors de l envoi du message vers l application de comptabilité ; publier les messages en erreur dans un répertoire. Cet exemple est disponible en téléchargement : fichier Chapitre5.msi. Voici comment vous allez procéder. c. Provoquer une erreur d envoi

116 Saisir une adresse de destination erronée Pour provoquer une erreur lors de l envoi du message, nous allons modifier le chemin d envoi du port sndcomptabilite_file en simulant une erreur de saisie dans le répertoire de destination : Dans les propriétés du port d envoi sndcomptabilite_file, modifiez le dossier de destination pour spécifier un chemin qui n existe pas sur votre machine, par exemple c:\enieditions\tests\comptabilite2\. Modifier le comportement par défaut du port d envoi Comme nous l avons vu dans le chapitre La messagerie dans BizTalk, lorsqu une erreur se produit sur un port d envoi, ce dernier va automatiquement réitérer son envoi selon une stratégie que nous pouvons paramétrer. Afin que le port d envoi ne réitère pas l envoi, nous allons modifier ses paramètres : Dans les propriétés du port d envoi sndcomptabilite_file, onglet Options avancées de transport, saisissez la valeur 0 dans le champ Nombre de tentatives. Ainsi le port ne réitérera pas l envoi en cas d erreur : d. Configurer le routage des messages en erreur Si nous gardons ce paramétrage du port d envoi, lorsque l erreur va se produire, l instance du port d envoi va être immédiatement suspendue. C est le comportement par défaut d un port d envoi et nous allons le configurer pour qu il publie un message d erreur à la place de se suspendre : Dans les propriétés du port d envoi sndcomptabilite_file, onglet Options avancées de transport, cochez la case Activer le routage pour les messages ayant échoué :

117 e. Créer un abonné aux messages d erreurs Nous devons maintenant créer un port d envoi qui va publier tous les messages en erreur dans un répertoire : Créez un nouveau port d envoi nommé snderreurs_file. Associez ce port à l adapter FILE que vous configurez afin de déposer les messages dans le répertoire C:\ENIEditions\Tests\Erreurs. Utilisez %MessageId%.xml comme nom de fichier. Tous les messages en erreur seront donc envoyés dans le répertoire C:\ENIEditions\Tests\Erreurs. Pour abonner le port d envoi aux messages d erreur, vous devez saisir le filtre suivant :

118 L expression ErrorReport.FailureCode Existe permet au port d être abonné à tous les messages dans lesquels se trouve la propriété promue FailureCode. Nous savons que tous les messages d erreur possèdent cette propriété donc notre port consommera tous les messages d erreur. Si vous souhaitez publier uniquement les erreurs qui se sont produites dans le port d envoi sndcomptabilite_file, utilisez l expression de filtre ci dessous : ErrorReport.FailureCode Existe Et ErrorReport.SendPortName == sndcomptabilite_file Démarrez le port afin qu il se déclare comme abonné et qu il soit prêt à effectuer les envois de messages. Vous pouvez maintenant tester la publication d un message d erreur. Déposez un fichier dans le répertoire écouté par l emplacement de réception rcvgestioncommerciale_file. Le message va être publié puis délivré au port d envoi sndcomptabilite_file. Le port d envoi ne va pas réussir à envoyer le message et le message va être de nouveau publié dans la MessageBox avec des propriétés de type Erreur. Il va ainsi être consommé par le port snderreurs_file qui va l envoyer dans un répertoire. À l issue de l exécution, consultez le contenu du répertoire Erreurs pour visualiser le message. f. Publication des erreurs dans un portail de gestion Le mécanisme de gestion automatique d erreur que nous venons de mettre en œuvre est satisfaisant d un point de vue technique mais son utilisation dans un projet n est pas forcément facile. Dans notre exemple, les messages en erreur sont publiés dans un répertoire qui permet de les centraliser mais aucune information sur l erreur rencontrée n est présente dans ce répertoire. Seul le contenu du message peut être consulté. Nous ne pouvons donc pas diagnostiquer à partir des messages quelle a été la cause de l erreur. L exploitant peut donc identifier qu un message est en erreur mais il ne sait pas pourquoi, à moins de faire le lien lui même entre la date/heure de création du message dans le répertoire des erreurs et les données du suivi postexécution. Ce fonctionnement est encore une fois relativement artisanal. Pour fournir aux utilisateurs des mécanismes de détection d erreurs et de diagnostic, il serait préférable de publier le message en erreur dans un portail Web et fournir, en complément du contenu du message, toutes les données contextuelles au moment de l erreur et donc les informations sur l erreur qui a été rencontrée ainsi que l étape à laquelle elle a été détectée

119 Le Microsoft BizTalk ESB Toolkit 2.0 contient un exemple d implémentation permettant la publication dans un portail Web (l ESB Portal). Je vous invite donc à vous en inspirer pour votre gestion d erreurs. 7. Archivage de données et ports de sauvegarde a. Plus jamais d erreurs de routage? Nous avons évoqué dans ce chapitre les erreurs de routage qui se produisent lorsqu un message est réceptionné par BizTalk et si aucun abonné n est trouvé. Le message est publié mais suspendu dans la MessageBox, ceci pour nous permettre de comprendre, corriger et relancer le message. Je vais vous exposer un scénario dans lequel aucune erreur de routage ne peut se produire. C est une situation que je rencontre malheureusement extrêmement souvent lors de mes différentes missions de conseil et que je préconise de faire disparaître. Le scénario est le suivant : le client souhaite disposer d une sauvegarde systématique de l ensemble des messages entrants dans son système. Pour cela, il crée un port d envoi BizTalk abonné à tous les messages reçus par BizTalk et les stocke dans un répertoire. Ainsi il peut les retrouver facilement et éventuellement les rejouer. Pour s abonner à tous les messages entrants, il suffit d utiliser le filtre : BTS.ReceivePortName Existe. b. Pourquoi il ne faut jamais créer un port de sauvegarde? Le besoin de sauvegarde des messages n est pas contestable bien au contraire. En revanche, la méthode n est pas correcte. En créant un port d envoi abonné à tous les messages entrants, toutes les erreurs de routage sont de facto supprimées (puisqu il y a toujours un abonné). Il est de ce fait quasi impossible de se rendre compte qu un message devant être envoyé à un destinataire ne l a pas été à cause d une erreur de configuration. Supposez qu un port d envoi existe dans votre système, que ce port d envoi soit censé router tous les messages provenant de l application de Gestion Commerciale vers une application de gestion de stock. S il y a une erreur dans le filtre du port d envoi à l application de gestion de stock, vous n allez pas identifier le problème car aucune erreur de routage ne sera visible dans la console BizTalk. Vous identifierez l erreur quelques jours ou semaines plus tard lorsqu un utilisateur de l application de gestion de stock vous informera que les données de son application ne sont pas à jour. Voici pourquoi je vous déconseille fortement d utiliser ce mécanisme de sauvegarde qui est très dangereux et peut donc masquer des problèmes de configuration de votre application. En contrepartie, je vous conseille d utiliser les fonctions natives de suivi de BizTalk permettant de retrouver un message et de sauvegarder éventuellement son contenu dans le temps. Nous avons évoqué ces notions dans le paragraphe sur le suivi des messages

120 Conclusion Nous avons terminé la découverte des outils BizTalk pour le suivi et la gestion des erreurs. Vous utiliserez très fréquemment ces outils dans vos projets, il est donc primordial que vous sachiez les utiliser correctement. Vous aurez également besoin de ces outils pour les exercices proposés dans les prochains chapitres

121 Rôle et usage du contenu d un message 1. Les scénarios sans utilisation du contenu du message Dans le chapitre La messagerie avec BizTalk, nous avons utilisé BizTalk pour router et transmettre des messages sans exploiter leur contenu. Le contenu des messages transportés a donc été complètement ignoré par BizTalk qui s est contenté de transporter un flux d informations. Pour preuve, notre exemple de routage, illustré par un échange entre l application de gestion commerciale et l application de comptabilité, est en mesure de fonctionner pour transporter des messages XML, des fichiers PDF ou tout autre type de données. Ces scénarios de transport, sans exploitation de contenu, sont fréquents mais ne constituent pas la majeure partie des projets EAI implémentés avec BizTalk. 2. Utilisation du contenu d un message par BizTalk Dans les scénarios d échanges les plus fréquemment mis en œuvre, le contenu d un message joue un rôle central et fondamental. Pour BizTalk, le contenu d un message est utile dans divers scénarios : Pour détecter le type de message : BizTalk peut exploiter le contenu d un message entrant pour déterminer quel est son type (exemple : Commande, Facture...). Pour router le message : le contenu d un message peut permettre à BizTalk de prendre une décision pour le router au(x) destinataire(s) concerné(s). Pour vérifier le message : lors de la réception ou lors de l envoi d un message, BizTalk peut opérer un ensemble de vérifications sur la structure ou sur le contenu fonctionnel. BizTalk peut ainsi interdire à des messages mal formés d être véhiculés dans le Système d Information. Il peut également garantir aux destinataires que les messages qui leur sont transmis ont été vérifiés par rapport à des structures normalisées ou des règles de gestion. Pour transformer ou modifier le message : lors de la réception ou de l envoi, BizTalk peut opérer un ensemble d opérations sur le contenu du message et ce, afin de le transformer ou de le modifier. Ces transformations/modifications, que nous étudierons en détail dans le chapitre Transformation de messages permettent de convertir des formats ou de rendre conforme des messages. Nous allons, dans ce chapitre et dans les suivants, illustrer ces différentes utilisations du contenu d un message

122 Le rôle fondamental de XML dans BizTalk Vous le comprendrez très vite, le rôle de XML (extensible Markup Language) est à plusieurs titres fondamental dans BizTalk. Tous les messages traités par BizTalk sont représentés en interne comme des messages XML. Cela est vrai même si le contenu n a pas été modélisé, dans ce cas, BizTalk va simplement encapsuler le contenu d un message dans un message XML. Le rôle central de XML dans BizTalk entraîne de fait l utilisation d un ensemble de normes, technologies ou standards connexes à XML. C est le cas de XSD (XML Schema Definition) pour la modélisation des messages mais aussi, nous le verrons plus loin, de XPATH pour la recherche de données ou de XSL (XML Stylesheet Language) pour la transformation des données. La bonne compréhension des notions XML en général et des normes ou usages XML est donc fondamentale pour les équipes projets en charge du développement. Cet ouvrage suppose que le lecteur connaisse, même de manière basique, les principales notions XML

123 Notions fondamentales pour la modélisation de schémas 1. Utilisation de XSD Dans la mise en œuvre d un scénario d échange avec prise en compte du contenu du message, l étape primordiale et préliminaire est la définition du contenu. Les messages doivent être modélisés, c est à dire décrits précisément. La description d un message est effectuée dans un schéma. Les concepteurs de BizTalk ont souhaité s appuyer sur un standard pour représenter les schémas BizTalk. Ainsi, depuis la version 2004 de BizTalk, les schémas sont écrits en XSD (Xml Schema Definition, Avant la version 2004 de BizTalk, les schémas étaient écrits en XDR (Xml Data Reduced). Afin de permettre la migration depuis les versions précédentes, BizTalk propose un outil de conversion XDR vers XSD. Le choix de XSD pour modéliser la structure des schémas est en cohérence avec le rôle fondamental de XML dans les Systèmes d Information d aujourd hui et sa prédominance dans les échanges de données. XSD est en effet très largement répandu, documenté et supporté par de nombreux outils et de nombreux éditeurs. BizTalk propose des outils graphiques pour la modélisation de schémas XSD mais vous pouvez tout à fait effectuer la modélisation de vos schémas avec un outil tiers et ensuite les utiliser dans BizTalk. Microsoft a étendu la spécification XSD pour ajouter des éléments complémentaires permettant notamment la modélisation de fichiers plats. Ces extensions ne rompent cependant pas la compatibilité avec le standard XSD puisque ce sont des annotations dans le schéma qui ne sont donc pas obligatoirement interprétées par l outil ou le parseur XML utilisant le schéma. Vous pouvez donc réutiliser des schémas XSD conçus avec BizTalk dans d autres outils. 2. Les outils BizTalk pour la modélisation de schémas Pour modéliser un schéma avec BizTalk, plusieurs outils sont disponibles : Un outil de conception de schéma (Éditeur de schémas BizTalk ou BizTalk Schema Editor). Cet outil permet de modéliser graphiquement des schémas XSD. Des assistants pour faciliter la génération de schémas. Ces assistants permettent de générer un schéma à partir d un exemple de fichier XML ou de migrer des définitions XDR vers XSD. Nous allons illustrer dans un premier temps la modélisation d un schéma avec l éditeur de schémas BizTalk. 3. Visual Studio 2008 comme outil de développement Jusqu à maintenant, nous n avons pas eu recours à des phases de développement BizTalk puisque nous avons travaillé sur de la configuration via la console d administration. À partir du moment où nous devons effectuer du développement, nous devons utiliser Microsoft Visual Studio 2008, l environnement de développement.net de Microsoft. Lors de l installation de BizTalk, vous disposez en effet d une option vous permettant d installer les outils de développement BizTalk qui viennent compléter la panoplie d outils déjà disponible dans Visual Studio. Suite à l installation des outils de développement BizTalk, des compléments sont ajoutés à Visual Studio et permettent la modélisation de schémas, la création de transformations, la création de pipelines ou encore l implémentation d orchestrations. a. Notion de solution Visual Studio La première étape du développement BizTalk est la création d un projet Visual Studio dans une solution Visual Studio. Une solution Visual Studio (fichier d extension.sln) permet de regrouper différents projets.net. Pour le développeur.net ou BizTalk, une solution permet de rassembler dans une même instance de l environnement de développement l ensemble des composants nécessaires pour l implémentation d un projet donné

124 b. Notion de projet Visual Studio Une solution est composée de projets.net. Un projet.net est un ensemble d éléments (classes, composants...) qui, une fois compilé, produit une assembly.net (assemblage en français), c est à dire un exécutable ou une librairie. Il existe plusieurs modèles de projets selon ce que l on souhaite implémenter. Voici quelques exemples : Bibliothèque de classes : permet de générer une librairie.net (une dll) contenant des classes. Utile pour développer des composants utilitaires et réutilisables par exemple. Application Web ASP.Net : permet de créer un site Web dynamique en ASP.Net. Application WPF : permet de créer une application Windows riche déployée sur un poste client. Application console : permet de créer une application sans interface graphique (exemple : un utilitaire en ligne de commande). Il existe un très grand nombre de modèles de projets en fonction des composants installés sur le poste du développeur. Les modèles de projets sont regroupés en types de projets. Par exemple, les projets de développement C# sont regroupés sous le type de projet Visual C#. c. Les modèles de projet BizTalk Le développement BizTalk dans Visual Studio repose sur les notions de solutions et projets que nous venons d évoquer. Lors de l installation des outils de développement BizTalk sur un poste disposant de Visual Studio 2008, un nouveau type de projet est créé (Projets BizTalk) contenant deux nouveaux modèles de projets : Projet BizTalk Server vide : projet BizTalk pour accueillir des schémas, maps, pipelines et orchestrations. Projet d importation BPEL BizTalk Server : migration d un projet BPEL (Business Process Engine Language). Ces deux modèles de projets peuvent accueillir des composants BizTalk que nous étudions dans cet ouvrage : Schémas : modélisation de messages pour les échanges. Mappages : transformations de messages. Pipelines : pipelines de réception ou d envois. Orchestrations : implémentation de processus métier. Le développement BizTalk repose sur les mêmes notions que le développement.net. Ainsi les projets BizTalk créés dans Visual Studio deviennent, après compilation, des assemblies.net (librairies.net). Le résultat de cette compilation (la dll.net générée par Visual Studio) est ensuite déployée au niveau du serveur BizTalk. Nous abordons le déploiement d assemblies BizTalk à la fin de ce chapitre

125 Modélisation de schémas La solution Visual Studio ainsi que l ensemble des schémas modélisés dans ce chapitre sont disponibles en téléchargement. Le fichier à télécharger se nomme Chapitre6.zip. 1. Créer un projet BizTalk Nous allons maintenant créer notre premier projet BizTalk pour ensuite modéliser des schémas d échanges. Pour créer un nouveau projet BizTalk, voici comment il faut procéder : Dans Visual Studio 2008, ouvrez le menu Fichier puis Nouveau et Projet. Dans Types de projets, sélectionnez Projets BizTalk, puis dans Modèles, sélectionnez Projet BizTalk Server vide. Choisissez le nom du projet ainsi que le chemin de stockage. Vous devez également sélectionner le nom de la solution qui sera créée. Lorsque vous cliquez sur le bouton OK, et si vous avez saisi des valeurs identiques à la copie d écran ci dessus ; vous obtenez : un répertoire ENI.BizTalk dans le répertoire c:\enieditions ; un fichier ENI.BizTalk.sln (représentant la solution) ; un sous répertoire ENI.Schemas (pour le projet) ; un fichier ENI.Schemas.btproj (représentant le projet) ; un fichier ENI.Schemas.btproj.user qui contient les préférences de l utilisateur concernant ce projet

126 2. Modéliser un schéma a. Ajouter un nouveau schéma Nous disposons désormais du conteneur (le projet BizTalk) dans lequel nous pouvons ajouter un ou plusieurs schémas. Nous allons ajouter un schéma dans ce projet. Pour illustrer la manipulation, nous allons mettre en place un schéma qui représente une commande passée par un client à son fournisseur. Nous réutiliserons ce schéma dans l ensemble des exemples de cet ouvrage afin d obtenir un processus métier complet implémenté dans BizTalk. Pour ajouter un schéma, voici comment il faut procéder : Ouvrez le menu contextuel sur le projet ENI.Schemas, sélectionnez l option Ajouter puis Nouvel élément. Étant donné qu il s agit d un projet BizTalk, Visual Studio vous propose les différents éléments pouvant être ajoutés à un projet BizTalk. Dans Catégories, sélectionnez Fichiers de schéma, puis dans Modèles, sélectionnez Schéma. Nommez le fichier en Commande.xsd. Cliquez ensuite sur le bouton Ajouter. À l issue de cet ajout, vous obtenez : Un fichier Commande.xsd a été ajouté au projet ENI.Schemas. Lorsque vous ouvrez le fichier.xsd, vous pouvez utiliser le concepteur de schéma. b. Définir l espace de noms du schéma Rôle des espaces de noms XML Tout schéma est associé à un espace de noms (namespace). Un espace de noms permet de qualifier chaque élément décrit dans le schéma et ainsi le rendre unique. La notion d espace de noms n est pas propre à BizTalk mais fait partie des recommandations W3C XML. Cette recommandation est référencée ici : names/

127 Dans notre exemple, nous souhaitons modéliser une commande. Nous allons donc créer un ensemble d éléments dans le schéma pour représenter une commande : code du client, code des produits commandés, quantité commandée... Si vous échangez des commandes avec un partenaire et si ce dernier a de son côté modélisé une commande avec un schéma, il est possible qu il ait utilisé une convention de nommage proche de la vôtre. Par exemple, il a peut être défini dans son schéma Commande un code client sous la forme d un champ nommé CodeClient. Cependant, même si un code client dans votre entreprise et chez votre partenaire désignent la même notion, leur structure est peut être différente. En interne vos codes client sont par exemple des alphanumériques de longueur 10 alors que votre partenaire identifie ses clients avec des valeurs numériques. Lorsque BizTalk (ou tout autre parseur XML) souhaite lire et comprendre un message XML de type Commande, il doit savoir, pour chaque champ qui compose le message, de quelle définition de champ il s agit. S il trouve un code client dans le message, s agit il du code client de votre entreprise ou de votre partenaire? Le rôle d un espace de noms est d apporter des éléments qualificatifs supplémentaires permettant d identifier précisément une définition de schéma ou de champ. Ainsi, on ne parle plus du champ CodeClient mais du champ CodeClient défini dans l espace de noms EntrepriseA. La combinaison des deux (nom du champ et espace de noms) diminue la probabilité d ambiguïté avec un nom existant. Utilisation d URI pour les espaces de noms Le W3C, qui a rédigé la préconisation relative aux espaces de noms XML, propose qu un espace de noms soit formalisé sous la forme d une URI (Uniform Resource Identifier). Une URI est une chaîne de caractère qui identifie une ressource sur un réseau. Sur le Web par exemple, une URI permet d identifier précisément le site Web d une entreprise. Il existe deux manières d écrire une URI : Soit sous la forme d une URL (Uniform Resource Locator). Une URL est une URI qui contient des informations sur la manière d atteindre la ressource identifiée. Par exemple, l URL identifie la ressource et indique que cette ressource est accessible avec le protocole http. Soit sous la forme d une URN (Uniform Resource Name). Une URN permet d identifier une ressource par son nom. Elle se présente sous la forme urn:siret: Dans cet exemple, cette URN identifie une entreprise par son numéro de SIRET. Dans tous les cas une URI est réputée unique dans le temps et dans l espace. Selon les entreprises et les personnes, vous trouverez des URL ou des URN pour définir des espaces de noms. Personnellement je préfère l utilisation d URN. L espace de noms de notre schéma Commande (et ainsi de l ensemble des éléments qui le constituent) sera urn:editionseni:gestioncommandes. Associer l espace de noms au schéma Pour associer l espace de noms au schéma, il faut tout d abord sélectionner le nœud <Schema> du fichier Commande.xsd. Dans la fenêtre de propriétés du schéma, modifiez la valeur de la propriété Target Namespace :

128 Le schéma est désormais qualifié avec l espace de noms urn:editionseni:gestioncommandes. Bien choisir son espace de noms Dans une solution BizTalk qui comporte de nombreux schémas, il n est pas rare de constater un manque de cohérence entre les espaces de noms utilisés. Cette incohérence ne facilite pas la prise en main par une personne extérieure au projet et devient très souvent une source d erreur et de bugs. Je vous conseille : De définir très tôt dans votre projet une convention pour la définition des espaces de noms. Vous devez définir si vous utilisez des URL ou des URN. Vous devez choisir comment une URI est construite (par exemple : urn:<nom de l entreprise>:<nom du département>:<processus métier>). De vous assurer, tout au long du projet, du respect des conventions établies. Changer l espace de noms d un schéma après son déploiement devient très complexe et peut avoir un impact sur l existant mais aussi et surtout sur vos partenaires. De partager les conventions et les rendre accessibles à l équipe projet. La mise en place d un document normatif en début de projet permet de centraliser ces éléments. De tenir à jour les documents normatifs au fur et à mesure du projet. c. Décrire le message et utiliser l outil de conception de schémas Nous avons désormais un schéma associé à un espace de noms. Nous allons maintenant décrire la structure d une commande avec l éditeur de schéma BizTalk. Définition du nœud Racine Le nœud Racine d un message XML est le premier élément du message. Associé à l espace de noms, il permet de qualifier de manière unique un message. Par défaut, lorsqu un schéma XSD est créé dans Visual Studio, le nœud racine se nomme Root. Nous allons renommer cet élément en Commande. Pour cela, sélectionnez le nœud Root, ouvrez le menu contextuel et sélectionnez l option Renommer ou cliquez sur la touche [F2]. Renommez le nœud en Commande. Toutes les données que nous modifions dans le schéma peuvent également être modifiées dans la fenêtre de propriétés

129 Ajout d un élément ou attribut dans le schéma Nous allons maintenant ajouter le code client comme champ de la commande. Deux options sont à notre disposition : soit nous créons un élément ; soit nous créons un attribut. Il y a plusieurs écoles quant au choix entre un attribut ou un élément. Tout dépend de vos habitudes de travail et de la manière dont les messages XML seront utilisés en dehors de BizTalk. Il faut retenir qu un attribut, contrairement à un élément, ne peut pas être présent plusieurs fois dans un message XML. La manière dont un attribut est représenté dans un message XML est également différente d un élément comme le montrent les deux exemples suivants. Dans cet exemple, le code client est un attribut : <ns0:commande CodeClient="Client1" xmlns:ns0="urn:editionseni:gestioncommandes" /> Dans cet exemple, le code client est un élément : <ns0:commande xmlns:ns0="urn:editionseni:gestioncommandes"> <CodeClient>Client1</CodeClient> </ns0:commande> Pour notre schéma, nous allons créer un élément nommé CodeClient. Sélectionnez le nœud Commande, ouvrez le menu contextuel et sélectionnez l option Élément de champ enfant. Nommez cet élément CodeClient. Définir le type de données d un attribut ou d un élément Par défaut, lorsque vous ajoutez un attribut ou un élément dans un schéma, le type de données chaîne de caractères lui est associé. Vous pouvez le voir en sélectionnant l élément (ou l attribut) puis en visualisant la fenêtre de propriétés associée. La propriété Data Type vaut xs:string :

130 Les types de données disponibles lors de la définition d un schéma sont l ensemble des types de données XSD ( 2/). Les types traditionnels sont représentés (chaînes, numériques, dates...). Lorsque vous définissez vos propres types de données, ces types sont également utilisables en lieu et place des types XSD. cf. paragraphe Réutilisez des schémas dans ce chapitre. Pour modifier le type de données d un élément ou attribut, vous devez simplement changer la valeur de la propriété Data Type associée. Dans notre exemple, nous souhaitons indiquer que le code client de notre commande est une chaîne (type xs:string) mais de longueur maximale 10. Si vous parcourez les propriétés disponibles pour indiquer cette longueur maximale, vous pourrez constater que ce n est pas possible. Pour cela, vous devez dériver d un type existant pour le restreindre : Sélectionnez le champ CodeClient, puis dans la fenêtre de propriétés, localisez la propriété Base Data Type, ouvrez la liste déroulante pour sélectionner le type xs:string. Après sélection du type xs:string, la propriété Derived By vaut Restriction. En effet, nous allons dériver du type xs:string en lui ajoutant une restriction (dans notre cas le limiter à 10 de longueur)

131 Pour indiquer la restriction de longueur, localisez la propriété Maximum Length et saisissez la valeur 10. Dans la fenêtre de propriétés, une section complète nommée Restriction, a été ajoutée et permet de restreindre le type de base. Pour le type xs:string, vous pouvez par exemple spécifier une taille minimum (propriété Minimum Length), indiquer une liste de valeurs possibles (propriété Enumeration) ou encore préciser une expression régulière permettant de spécifier le format possible de la chaîne (propriété Pattern). Si vous dérivez d un autre type (par exemple xs:int ou xs:datetime), vous disposerez d autres propriétés de restriction. Plus vous ajoutez des contraintes dans vos schémas et plus vous garantissez la qualité des messages que vous recevez ou envoyez. En contrepartie si vous intégrez trop de restrictions dans vos schémas, vous perdrez en souplesse lors de la modification de ces contraintes. Par exemple, l utilisation de la propriété Enumeration pour spécifier une liste de valeurs est discutable. Si vous l utilisez, votre schéma va contenir une liste de valeurs possibles en dur dans le schéma XSD et si vous souhaitez la modifier vous devrez déployer de nouveau le schéma et le diffuser à vos partenaires. Ajout d un enregistrement Nous venons d ajouter un élément (le code client). Nous allons maintenant ajouter l adresse de livraison du client. Cette adresse est un ensemble d éléments (rue, code postal et ville). C est donc un enregistrement. Un enregistrement contient des attributs et des éléments, permet de regrouper de manière hiérarchique ces éléments et peut apparaître sous forme d une collection (c est à dire plusieurs fois). Pour créer l enregistrement adresse de livraison, ouvrez le menu contextuel sur le nœud Commande du schéma, sélectionnez l option Insérer un nœud de schéma puis l option Enregistrement enfant. Nommez cet enregistrement AdresseLivraison. Cet enregistrement est maintenant prêt à recevoir des attributs/éléments ou même d autres enregistrements. Vous n êtes pas limités par le nombre de niveaux hiérarchiques. Modification des cardinalités des éléments ou enregistrements Les éléments ou enregistrements d un schéma peuvent apparaître plusieurs fois dans un message XML. Dans une commande, la meilleure illustration est la liste des produits. Une commande peut contenir plusieurs produits commandés, chaque produit étant qualifié par un code, une quantité et un prix unitaire. Pour le modéliser, nous allons créer un enregistrement nommé Produits qui lui même sera constitué d un enregistrement nommé Produit. Créez un enregistrement enfant du nœud Commande et nommez le Produits. Créez ensuite un enregistrement enfant du nœud Produits et nommez le Produit. Pour indiquer que l enregistrement Produit peut être présent plusieurs fois, sélectionnez l enregistrement Produit, et dans la page de propriétés, saisissez la valeur unbounded (ou *) dans la propriété Max Occurs. Par défaut, la valeur de la propriété Max Occurs vaut 1, tout comme la valeur de la propriété Min Occurs. Cela signifie qu un enregistrement (ou un élément) défini dans un schéma est obligatoire (Min Occurs=1) et ne peut pas apparaître plus d une fois (Max Occurs=1). En modifiant les valeurs de ces propriétés, vous modifiez donc le comportement des éléments ou enregistrements pour l adapter à vos attentes. La propriété Max Occurs peut également contenir une valeur numérique à la place de unbounded. Si vous indiquez la valeur 4 dans Max Occurs de l enregistrement Produit, vous spécifiez qu une commande ne peut pas contenir plus de 4 produits

132 Schéma commande au complet Nous avons illustré comment créer des éléments, des attributs et des enregistrements et comment procéder pour modifier leurs caractéristiques. Nous disposons de l ensemble des connaissances nécessaires à la modélisation de l ensemble du schéma Commande. Voici ci dessous la description détaillée du schéma commande : Nom Type Type de données Max Occurs Nœud père Commande Nœud racine N/A Défaut Aucun CodeClient Elément xs:string (Max Length=10) Défaut Commande NumeroCommande Attribut xs:int Défaut Commande Produits Enregistrement N/A Défaut Commande Produit Enregistrement N/A unbounded Produits Code Attribut xs:string Défaut Produit Quantite Elément xs:int Défaut Produit PrixUnitaire Elément xs:int Défaut Produit AdresseLivraison Enregistrement N/A Défaut Commande Rue Elément xs:string Défaut AdresseLivraison CodePostal Elément xs:string (Min length=5, Max length=5) Défaut AdresseLivraison Ville Elément xs:string Défaut AdresseLivraison Après modélisation, voici comment est structuré le schéma XSD Commande : J ai par habitude de créer autant de fichiers.xsd que de schémas devant être modélisés, par souci de clarté et de simplicité. Sachez toutefois qu il est possible de modéliser plusieurs messages dans le même fichier.xsd. Il y a dans ce cas plusieurs nœuds racines dans le même schéma. 3. Tester un schéma

133 Comme cela devrait être le cas dans tous les projets informatiques, le développeur doit tester sur son poste de travail l ensemble des composants qu il a implémenté. Il doit s assurer que ces composants respectent la spécification et fonctionnent sans erreurs. Malheureusement, cette démarche de bon sens n est pas toujours respectée. Un schéma est un composant informatique comme un autre et doit donc être testé. J ajouterais même que la place fondamentale d un schéma dans une solution d échange de données lui confère le devoir d être testé avant d être intégré à la solution d échange. Les tests d un schéma permettent de répondre aux deux questions suivantes : Est ce que la structure du schéma est valide par rapport à la spécification XSD? Est ce que le schéma qui a été modélisé est conforme aux exemples de messages que j ai obtenus de mes partenaires? Visual Studio, et les outils de développement BizTalk, permettent de répondre à ces questions. a. Valider un schéma Conformité avec la recommandation XSD Valider un schéma signifie le confronter à la recommandation XSD pour s assurer qu il n y a pas d incohérence (utilisation d un type de données inexistant...). Cette validation est rarement un problème dans un schéma modélisé avec le concepteur de schémas BizTalk puisque l outil s assure, par des règles de gestion, de la conformité avec la recommandation XSD. Par exemple, lorsque vous souhaitez assigner un type de données à un élément d un schéma, vous avez le choix dans une liste déroulante et ne pouvez donc pas sélectionner un type de données inexistant. En revanche, vous pouvez tout à fait ouvrir un fichier XSD en dehors du concepteur de schémas BizTalk (bloc notes Windows ou bien éditeur de texte de Visual Studio) ou encore récupérer des schémas XSD modélisés en dehors de BizTalk (par simple copier/coller comme nous l expliquons dans le paragraphe Utilisation des assistants de génération de schémas). Dans ce cas, la validation d un schéma permet de garantir que son contenu est correct. Validation d un schéma Nous allons valider le schéma Commande.xsd : Dans la fenêtre Explorateur de solutions de Visual Studio, sélectionnez le fichier Commande.xsd. Ouvrez le menu contextuel et sélectionnez l option Valider le schéma. Cas d erreurs de validation Si notre schéma comporte des erreurs, la liste des erreurs est accessible à partir de la fenêtre Sortie comme indiqué ci dessous : Cette même liste d erreurs est également disponible dans la fenêtre Liste d erreurs. b. Générer une instance de message Comment générer une instance de message? La génération d une instance de message à partir d un schéma est l outil indispensable du développeur BizTalk. Cet outil génère un exemple de fichier XML (une instance de message XML) correspondant au schéma XSD

134 Dans l Explorateur de solutions, sélectionnez le fichier Commande.xsd. Dans la page de propriétés, localisez la propriété Nom de fichier d instance de sortie. Saisissez dans cette propriété le chemin d un fichier. C est le fichier qui sera généré par l outil de génération d instance de messages : Dans le menu contextuel sur le fichier Commande.xsd, sélectionnez l option Générer l instance. Pour visualiser le contenu du message généré, cliquez sur le chemin présenté dans la fenêtre Sortie et gardez le bouton [Ctrl] enfoncé :

135 Pour ouvrir le fichier et le personnaliser par exemple, ouvrez le menu contextuel et sélectionnez l option Afficher la source. À chaque fois que vous utilisez l outil Générer l instance, le fichier référencé par l option Nom de fichier d instance de sortie sera écrasé sans vous avertir. Si vous personnalisez ce fichier veillez donc à le sauvegarder sous un autre nom. Vous pouvez également utiliser l outil Générer l instance sans préciser de chemin de fichier. Dans ce cas, un chemin de fichier temporaire sera généré. Bonnes pratiques Les exemples de messages dans une solution d échange de données sont fondamentaux car ils permettent de tester la solution et garantissent sa non régression par rapport aux spécifications originelles. Aussi étrange que cela puisse paraître, les équipes projet ne sont pas toujours en mesure de fournir des exemples de messages. Souvent d ailleurs elles doivent utiliser les outils de suivi de BizTalk pour récupérer un exemple de message (cf. chapitre Suivi de l activité et gestion des erreurs). Vous devez impérativement disposer des exemples de l ensemble des messages échangés dans votre solution BizTalk. C est au développeur de constituer cette collection de messages : soit avec l outil Générer l instance que nous venons d utiliser ; soit en récupérant des exemples de messages qui accompagnent en principe la spécification du projet ou qui proviennent des partenaires. Dans tous les cas, vous pouvez stocker ces exemples de messages directement dans le projet BizTalk qui contient les schémas. Créez un répertoire dans le projet (nommé Exemples) et insérez vos exemples dans ce répertoire. Voici comment procéder : Dans le projet ENI.Schemas, ouvrez le menu contextuel sur le projet et choisissez l option Ajouter puis Nouveau dossier. Nommez le répertoire Exemples. Faites en sorte que vos schémas soient configurés pour générer des instances de messages dans le répertoire Exemples du projet. Pour cela, mettez à jour la propriété Nom de fichier d instance de sortie de chaque schéma. Lorsque vous générez pour la première fois un message, celui ci est créé dans le sous répertoire Exemple du projet mais ne sera pas automatiquement intégré au projet Visual Studio. Pour que ce soit le cas, dans l explorateur de solutions, cliquez sur le bouton Afficher tous les fichiers. Sélectionnez le ou les fichiers contenus dans le sous répertoire Exemples, ouvrez le menu contextuel et sélectionnez l option Inclure dans le projet. Les fichiers qui ne font pas partie du projet sont identifiés par une icône entourée de pointillés. Si vous connectez votre solution Visual Studio à un outil de contrôle de code source (MS Visual SourceSafe ou MS Team System par exemple), les fichiers exemples seront également intégrés au contrôle de code source. c. Valider une instance de message En sus des deux fonctionnalités que nous venons de détailler, Visual Studio offre également la possibilité de valider une instance de message. Cette fonctionnalité est très utile lorsque vous disposez d un ensemble d exemples de messages et si vous souhaitez confronter ces messages à votre schéma. Pour utiliser cette fonctionnalité, voici comment procéder :

136 Tout d abord renseignez la propriété Nom de fichier d instance d entrée avec le chemin d un fichier exemple que vous souhaitez utiliser. Sélectionnez le fichier Commande.xsd dans l explorateur de solutions, ouvrez le menu contextuel et sélectionnez l option Valider l instance. Les résultats de la validation (erreurs, avertissements, informations) sont affichés dans la fenêtre Sortie de Visual Studio comme cela était le cas pour la fonction Valider le schéma. d. Remarques concernant la propriété Groupe Order Type La propriété Groupe Order Type qui est présente sur chaque enregistrement d un schéma XSD est très importante. Elle peut en tout cas influencer très fortement la validation d une instance de message. Cette propriété indique comment les éléments et enregistrements fils doivent être représentés dans un message XML conforme. Par défaut cette propriété vaut Sequence ce qui signifie que les éléments et enregistrements enfants doivent apparaître dans le même ordre que celui dans lequel ils ont été modélisés. Deux autres valeurs sont possibles pour cette propriété : All : indique que les éléments/enregistrements fils peuvent apparaître dans un ordre indéterminé ou même pas du tout. Choice : indique qu un seul des éléments/enregistrements fils ne peut apparaître. e. Tests unitaires Inconvénients des tests manuels Toutes les fonctionnalités de tests que nous venons d illustrer sont des opérations manuelles. Les deux inconvénients majeurs sont : Aucune trace de l opération ne subsiste après son exécution. En effet, vous ne disposez pas d un rapport, solidaire du projet Visual Studio, qui vous indique que tous les schémas ont été testés et validés. Les tests menés sont au bon vouloir du développeur qui, étant donné que ces tests ne sont pas automatisés, n a aucune obligation (à part morale bien sûr) de les jouer. Les tests unitaires BizTalk Dans un souci de qualité mais aussi d industrialisation, ces actions de vérification de schémas et de messages peuvent être automatisées sous forme de tests unitaires. La mise en œuvre de tests unitaires avec BizTalk repose sur les mêmes notions que les tests unitaires avec Visual Studio pour les projets.net classiques. Un projet de tests unitaires doit être créé ainsi que des classes de tests. Chaque classe de tests contient une ou plusieurs méthodes de tests dans lesquelles le test unitaire est implémenté. Visual Studio vous propose ensuite des outils pour lancer une batterie de tests à partir d un projet particulier et génère un rapport. Le rapport est consultable à partir du projet de tests et fait partie intégrante de la solution. Si votre entreprise dispose d une plate forme d intégration continue comme Microsoft Team Fundation Server par exemple, vous pouvez intégrer les tests unitaires dans le processus de génération de version et ainsi vous assurer à chaque compilation du code qu il n y a pas de régressions. Avant la version 2009, BizTalk ne permettait pas la mise en œuvre de tests unitaires compatibles Visual Studio. Des outils tiers permettaient en revanche la mise en place de tests unitaires. C est par exemple le cas de BizUnit qui permet de générer des tests unitaires. À mon sens, il convient de considérer BizUnit non pas comme un outil de tests unitaire mais comme un outil de tests d intégration. Il est donc complémentaire aux outils de tests unitaires proposés nativement dans BizTalk Mise en œuvre des tests unitaires pour le schéma Commande

137 La mise en œuvre des tests unitaires du schéma Commande passe par plusieurs étapes que nous détaillons ciaprès. Vous devez tout d abord modifier un paramètre de configuration du projet ENI.Schemas : Sélectionnez le projet ENI.Schemas dans l explorateur de solutions. Ouvrez le menu Projets puis sélectionnez l option Propriétés de ENI.Schemas. Dans l onglet Déploiement, modifiez la propriété Activer les tests des unités pour que sa valeur devienne True. Parfois les traductions françaises de certains termes sont hasardeuses. Activer les tests des unités doit être compris comme activer les tests unitaires. Pensez à enregistrer vos modifications (menu Fichier puis Enregistrer). À partir du moment où nous activons cette option, les éléments intégrés au projet peuvent être testés unitairement. C est donc le cas pour le schéma Commande.xsd. Nous le verrons plus loin dans ce chapitre, lors de la compilation du projet, le schéma XSD devient une classe.net. Lorsque nous activons les tests unitaires sur le projet, la classe.net générée hérite d une classe mère contenant des fonctionnalités de tests unitaires (classe TestableSchemaBase de l assembly Microsoft.BizTalk.TestTools). C est pour cette raison que nous pouvons ensuite créer un test unitaire pour notre schéma. Créez maintenant un projet pour accueillir les tests unitaires : Dans le menu Fichier sélectionnez l option Ajouter puis Nouveau projet. Dans catégories, sélectionnez Projets de test, puis Documents de tests. Dans Modèles, sélectionnez Projet de test. Nommez le projet ENI.Tests et vérifiez que l emplacement du projet est correct. À l issue de cet assistant d ajout de projet, des nouveaux éléments ont été créés et ajoutés à la solution Visual Studio : Un nouveau projet nommé ENI.Tests contenant :

138 Un fichier AuthoringTests.txt. Ce fichier est l équivalent d un lisezmoi.txt pour vous expliquer comment mettre en place vos premiers tests. Un fichier UnitTest1.cs qui est une classe de tests automatiquement créée que vous pouvez modifier et enrichir. Un fichier ENI.BizTalk.vsmdi. Ce fichier, situé au niveau de la solution globale, permet d avoir accès à l ensemble des tests unitaires des différents projets de la solution. En l ouvrant, vous obtenez une fenêtre qui vous permet de gérer les tests unitaires. Un fichier LocalTestRun.testrunconfig. En ouvrant ce fichier, vous pouvez paramétrer l exécution des tests unitaires. Vous pouvez par exemple régler le délai maximum d exécution d un test ou configurer la convention de nommage du rapport de tests. Pour créer le test unitaire du schéma Commande.xsd, vous devez tout d abord référencer les librairies BizTalk contenant les classes de tests BizTalk. Sélectionnez le projet ENI.Tests, ouvrez le menu contextuel et sélectionnez l option Ajouter une référence. Soyez patient Sélectionnez les références Microsoft XLANG/S Base Types puis Microsoft.BizTalk.TestTools et cliquez sur le bouton OK

139 Ajoutez une classe de tests dédiée aux tests unitaires du schéma Commande.xsd : Vous pouvez supprimer le fichier UnitTest1.cs car nous allons créer un nouveau fichier pour nos tests. Sélectionnez le projet ENI.Tests, ouvrez le menu contextuel puis choisissez l option Ajouter puis Nouveau test. Dans Modèles, sélectionnez Test unitaire. Nommez ensuite le fichier TestSchemaCommande.cs. Un fichier TestSchemaCommande.cs est ajouté au projet ENI.Tests. Ce fichier contient une méthode nommée TestMethod1 qui contient le code source suivant :

140 [TestMethod] public void TestMethod1() { // // TODO : ajoutez ici la logique du test // } Cette méthode est qualifiée avec l attribut [TestMethod]. C est grâce à cet attribut que Visual Studio détecte les différents tests unitaires contenus dans une classe de tests. Nous allons modifier cette méthode tout d abord en la renommant TestCommandeXml. Ajoutez le code suivant au tout début du fichier TestSchemaCommande.cs : using Microsoft.BizTalk.TestTools.Schema; Au niveau du projet ENI.Tests, ajoutez une référence de type projet vers le projet ENI.Schemas qui contient le schéma à tester. Préférez une référence de type projet. Remplacez ensuite les commentaires à l intérieur de la méthode par le code source suivant : TestableSchemaBase testschemacommande = new ENI.Schemas.Commande(); bool testok = testschemacommande.validateinstance(@"c:\enieditions\eni.biztalk\ ENI.Schemas\Exemples\Commande.xml", OutputInstanceType.XML); if (!testok) Assert.Fail("Erreur lors de la validation du message avec le schéma"); Ce code source effectue les actions suivantes : Instancie le schéma à tester. TestableSchemaBase testschemacommande = new ENI.Schemas.Commande(); Demande la validation d une instance de fichier XML. Ce code est équivalent à l action manuelle Valider l instance sur un schéma. À l issue de la validation, la méthode ValidateInstance invoquée retourne une valeur booléenne pour indiquer si la validation est correcte : bool testok = testschemacommande.validateinstance(@"c:\enieditions\eni.biztalk\ ENI.Schemas\Exemples\Commande.xml", OutputInstanceType.XML); Si la validation de l instance n est pas correcte, nous utilisons la classe Assert de.net pour afficher un message dans le rapport de tests. Vous pouvez imaginer des actions bien différentes en cas d erreur ou même en cas de succès de la validation : if (!testok) Assert.Fail("Erreur lors de la validation du message avec le schéma"); Vous pouvez maintenant compiler le projet de tests via le menu Générer et l option Générer ENI.Tests. Pour lancer la campagne de tests, ouvrez le menu Test, sélectionnez l option Exécuter puis Tous les tests de la

141 solution. Pendant l exécution et après l exécution, consultez la fenêtre Résultats des tests. Dans l exemple suivant, le test a été exécuté avec succès. Si le test avait généré une erreur, le message d erreur serait affiché dans la colonne correspondante : Les différents rapports de tests, générés lors de chaque exécution, sont stockés dans le sous répertoire TestResults du répertoire ENI.BizTalk. Vous pouvez ainsi consulter les rapports de tests archivés et mesurer les avancées ou les régressions entre plusieurs versions de vos schémas. Faut il faire systématiquement les tests unitaires des schémas? Oui car vous l avez vu, le temps nécessaire pour mettre en place le test d un schéma est très court. Ce n est donc pas une charge de travail insurmontable pour l équipe dans la mesure où cela est fait en même temps que la modélisation. L avantage des tests unitaires est leur capacité à être rejoués à l infini et de manière automatisée. Si par exemple votre partenaire décide de modifier le format d une commande qu il vous envoie habituellement, avec des tests unitaires vous savez mesurer immédiatement les impacts sur les schémas. De la même manière, si vous décidez de modifier un schéma, pour ajouter un champ, modifier un type de donnée ou ajouter des règles de vérification plus strictes, la présence de tests unitaires va vous permettre de gagner beaucoup de temps sur les tests et vous garantir, avant de passer en production, que les messages que vous recevez habituellement sont compatibles. 4. Réutiliser des schémas a. Factorisation de schémas La modélisation d un schéma peut être rapprochée des autres disciplines de la programmation comme l algorithmie. Quand vous concevez un algorithme, vous réfléchissez tout d abord à la logique métier et ensuite vous débutez son implémentation lorsque vous avez trouvé la solution. Pendant la phase d implémentation, vous effectuez certainement plusieurs refontes de votre code pour isoler des morceaux de code dans des classes, méthodes, propriétés... Cette phase de refonte permet, à l issue de la phase d implémentation, de disposer non seulement de l algorithme mais également d un ensemble de classes utilitaires réutilisables. Le code dupliqué est théoriquement supprimé pour être factorisé. Il en est de même pour la modélisation d un schéma. Au fur et à mesure de la modélisation d un schéma, vous découvrirez peut être des champs de même nature, voire de même nom, ou des structures de champs identiques. Le meilleur exemple est l adresse. Dans un schéma Commande, une adresse peut être utilisée à plusieurs reprises : adresse de livraison et adresse de facturation par exemple. Vous pouvez bien sûr dupliquer dans le schéma Commande les deux définitions d adresses mais BizTalk et la recommandation XSD vous offrent la possibilité de factoriser votre modélisation en réutilisant des schémas XSD existants. L utilisation d une norme avec BizTalk (HL7 dans le domaine de la santé, SWIFT pour le domaine bancaire...) passe très souvent par la réutilisation de schémas XSD existants. Ces schémas fournissent les types de base de la norme et la manière de structurer les informations. La réutilisation de schémas XSD est donc fondamentale. b. Types simples et types complexes Avant de modéliser des types réutilisables, nous devons différencier les types simples des types complexes

142 Un type simple est un dérivé d un type de données de base avec des restrictions. Par exemple, un type code postal est un type simple car c est une chaîne de caractères de taille 5 (en France en tout cas). Un type complexe est un type structuré contenant plusieurs éléments. Une adresse est un type complexe car une adresse est composée d un ensemble d éléments (une rue, un code postal et une ville). c. Modéliser un schéma réutilisable avec des types simples Pour illustrer la réutilisation de schémas de types simples, nous allons créer un nouveau schéma nommé TypesSimples.xsd dans le projet ENI.Schemas. Ce schéma va contenir des types simples qui représentent : un code postal ; un code client. Ajoutez un nouveau schéma nommé TypesSimples.xsd dans le projet ENI.Schemas. Modifiez l espace de noms du schéma pour qu il devienne urn:editionseni:typessimples comme indiqué cidessous : Par défaut lorsque vous créez un nouveau schéma, le schéma contient un nom racine nommé Root. Dans notre cas, étant donné que nous allons modéliser des types simples, nous pouvons supprimer le nœud racine. Créez un Élément de champ enfant que vous nommez CodePostal. Configurez la propriété Base Data Type à xs:string afin de restreindre le code postal. Modifiez ensuite les propriétés Max Length et Min Length pour les positionner à 5. Nous pourrions également utiliser la propriété Pattern pour préciser une expression régulière permettant de contraindre la saisie de codes postaux français. Créez maintenant un nouvel Élément de champ enfant et nommez le CodeClient. Comme nous l avons fait pour le code postal, dérivez du type de base xs:string pour le personnaliser et positionnez la propriété Max Length à 20. Notre schéma de types simples et réutilisables est terminé. d. Modéliser un schéma réutilisable avec des types complexes Nous allons maintenant effectuer la modélisation de types complexes réutilisables. Créez un nouveau schéma nommé TypesComplexes.xsd dans le projet ENI.Schemas. Modifiez l espace de noms de ce schéma pour le positionner à la valeur urn:editionseni:typescomplexes. Renommez le nœud racine en Adresse et sélectionnez ce nœud. Ajoutez le champ Rue de type xs:string

143 Ajoutez le champ CodePostal de type xs:string. Ajoutez le champ Ville de type xs:string. La copie d écran ci dessous illustre le schéma obtenu : e. Réutiliser des schémas Nous disposons désormais de deux schémas définissant des types de base. Un schéma avec des types simples (TypesSimples.xsd) et un schéma avec des types complexes (TypesComplexes.xsd). Nous allons réutiliser ces schémas. Réutiliser un type simple Dans un premier temps, nous allons réutiliser le type de base CodePostal dans la définition d une adresse. Dans la définition d une adresse faite dans TypesComplexes.xsd, un code postal est de type xs:string. Nous allons modifier cette définition. La première étape de l opération consiste à référencer le schéma TypeSimple (dans lequel est défini le type simple CodePostal) dans le schéma TypeComplexe dans lequel est défini le type complexe Adresse. Nous allons Importer le schéma TypeSimple dans le schéma TypeComplexe : Ouvrez le schéma TypesComplexes.xsd. Sélectionnez le nœud <Schema>. Dans la page de propriétés, localisez la propriété Imports. Cliquez sur le bouton... situé à droite de la propriété Imports. Dans la fenêtre Importations, cliquez sur le bouton Ajouter

144 Dans la fenêtre de sélection de schémas, localisez le schéma TypesSimples, sélectionnez le et cliquez sur le bouton OK. Lorsque cette manipulation est effectuée, une nouvelle ligne apparaît dans la fenêtre Importations. Elle indique que le schéma TypesSimples, d espace de noms urn:editionseni:typessimples est référencé et que son préfixe est ns

145 Nous pouvons maintenant utiliser les types définis dans le schéma importé : Dans le schéma TypesComplexes, sélectionnez l élément CodePostal et rendez vous dans la page de propriétés. Ouvrez la liste de valeurs correspondant à la propriété Data Type. Deux nouvelles valeurs ont fait leur apparition : ns0:codeclient et ns0:codepostal. Ces deux éléments sont préfixés par ns0. Dans la fenêtre Importations utilisée pour référencer le schéma TypesSimples, nous pouvons modifier ce préfixe pour lui assigner une valeur différente si besoin

146 Sélectionnez le type ns0:codepostal. Réutiliser un type complexe Nous allons maintenant réutiliser le type complexe Adresse dans le schéma Commande : Ouvrez le schéma Commande et importez le schéma TypesComplexes avec la même manipulation que celle réalisée précédemment. Dans la fenêtre Importations, avant de cliquer sur le bouton OK, modifiez le contenu du champ Préfixe pour le schéma importé en le positionnant à enitypes : Dans le schéma Commande, sélectionnez l élément AdresseLivraison. Dans la page de propriété correspondante, localisez la propriété Data Structure Type et ouvrez la liste déroulante :

147 Le type enitypes:adresse apparaît désormais. Sélectionnez le. Étant donné que l enregistrement AdresseLivraison contient déjà des éléments dans le schéma Commande, l éditeur de schéma BizTalk nous avertit qu en sélectionnant un type complexe, les éléments seront supprimés. Cliquez sur OK pour accepter. Le schéma Commande est illustré dans la copie d écran ci dessous : Vous pouvez remarquer : L enregistrement nommé initialement AdresseLivraison, s appelle maintenant enitypes:adresse. Les éléments Rue, CodePostal et Ville sont grisés, c est à dire qu ils ne sont pas modifiables dans le schéma Commande. Si vous souhaitez modifier l élément Ville, vous devrez le faire dans le schéma TypesComplexes. Nous venons de réutiliser un type complexe avec succès. Notre manipulation n est cependant pas entièrement satisfaisante car nous avons perdu, dans le schéma Commande, la notion d adresse de livraison. Nous savons que c est une adresse certes, mais si nous avons besoin d ajouter une adresse de facturation, nous n avons pour l instant pas les moyens de les différencier. Pour remédier à cela, créez un nouvel enregistrement, appelé AdresseLivraison dans lequel vous déplacez l enregistrement enitypes:adresse : Sélectionnez le nœud Commande et créez un nouvel enregistrement enfant nommé AdresseLivraison. Déplacez ensuite l enregistrement enitypes:adresse en dessous de ce nouvel enregistrement pour obtenir le

148 schéma ci dessous : Sur le schéma Commande, demandez la génération d une instance de message (menu contextuel puis option Générer l instance). Voici la nouvelle représentation XML d une commande : Notre message est sensiblement différent de celui que nous avions généré avant la réutilisation de schémas. Nous avons désormais trois espaces de noms dans le message : urn:editionseni:gestioncommandes (préfixé par ns0) ; urn:editionseni:typescomplexes (préfixé par ns1) ; urn:editionseni:typessimples (préfixé par ns2). L utilisation des préfixes ns* (ns pour namespace) est une convention mais vous pouvez modifier les préfixes pour utiliser des préfixes qui vous semblent plus adaptés. L association entre un préfixe et l espace de noms est effectuée par la ligne : xmlns:ns1="urn:editionseni:typescomplexes" Cette ligne indique que le préfixe ns1 est associé à l espace de noms urn:editionseni:typescomplexes. Elle signifie également que tous les éléments, enregistrements ou types qui seront préfixés par ns1 appartiennent à l espace de noms urn:editionseni:typescomplexes. Un message XML représentant une commande est sensiblement différent avec ou sans réutilisation des schémas. Cette différence impacte directement les partenaires avec lesquels vous dialoguez si vous décidez de mettre en place de la réutilisation de schémas après avoir communiqué vos schémas et vos exemples de messages. Consacrez suffisamment de temps à la modélisation de vos schémas pour décider pendant cette phase des réutilisations possibles et évitez de modifier votre stratégie après avoir diffusé vos schémas aux partenaires. Si toutefois vous devez modifier vos schémas, utilisez une stratégie de gestion de version comme nous l indiquons plus loin dans ce chapitre

149 f. Import, Include et Redefine Vous avez certainement remarqué dans la fenêtre Importations utilisée pour importer nos schémas que l option Import était sélectionnée. Ce n est pas la seule option possible et voici la différence entre les trois options disponibles : Import : l option Import permet d importer un schéma dont l espace de noms n est pas le même que le schéma dans lequel il est importé. Include : l option Include permet d inclure un schéma qui porte le même espace de noms que le schéma dans lequel il est intégré. Redefine : l option Redefine est une nuance de l option Include. Elle permet d inclure un schéma qui porte le même espace de noms dans un autre schéma tout en offrant la possibilité de redéfinir les types qui ont été inclus. g. Réutiliser des schémas issus d autres projets Nous avons réutilisé des schémas modélisés dans le même projet Visual Studio (donc dans la même assembly.net après compilation). C est un cas fréquent certes mais parfois vous ne disposerez pas du code source des schémas XSD que vous souhaitez réutiliser. Si par exemple votre entreprise est structurée en plusieurs équipes dont l une en charge de la modélisation des types réutilisables, cette équipe ne va peut être pas diffuser le code des projets Visual Studio utilisés pour la modélisation (pour diminuer les risques de modifications par erreur par exemple). Vous ne disposerez que de la version compilée des schémas, c est à dire la dll.net correspondante. Si vous souhaitez réutiliser ces types, vous devrez tout simplement : Référencez la dll depuis votre projet. Sélectionnez les schémas via le nœud Références de la fenêtre de sélection comme l illustre la copie d écran cidessous : Cette situation se produit très fréquemment quand vous souhaitez utiliser des schémas issus d entités externes ou de partenaires

150 5. Schéma pivot a. Situations rencontrées Dans la conception d une solution d échanges BizTalk avec des partenaires externes et/ou des applications, vous devez définir, pour chaque message échangé un schéma correspondant. Ainsi, si une commande est reçue de l application de gestion commerciale puis envoyée à l application de comptabilité, et si ces deux applications n acceptent pas les mêmes formats de messages, vous devez définir : un schéma pour la commande issue de la gestion commerciale ; un schéma pour la commande à destination de la comptabilité. Au niveau de BizTalk, afin d opérer la transition entre les deux formats, vous devez implémenter une transformation comme nous l illustrons au chapitre Transformation de messages. La mise en œuvre de deux schémas et d une transformation est donc suffisante pour couvrir le besoin. Qu en est il désormais si des commandes pouvant provenir de la comptabilité doivent être envoyées à l application de gestion commerciale? Très simple, vous implémentez une nouvelle transformation, cette fois ci pour transformer une commande issue de la comptabilité en une commande à destination de la gestion commerciale. Qu en est il maintenant si une commande doit suivre un processus métier un peu plus riche dans BizTalk qu un simple routage. Par exemple, la commande doit être vérifiée en interrogeant une application tierce, le stock doit être vérifié et l application de CRM doit être informée de la prise d une nouvelle commande avant que la commande ne soit transmise à l extérieur de BizTalk. En résumé, un processus métier complet qui orchestre la communication avec plusieurs applications de l entreprise comme nous le verrons dans le chapitre Implémentation des processus métier. Le processus métier s appuie sur des données issues de la commande donc issues d un schéma modélisé dans BizTalk. Si nous savons que le processus métier doit se lancer lorsqu une commande est réceptionnée de la gestion commerciale, nous pouvons nous baser sur le schéma de commande Gestion Commerciale. Si par contre, ce même processus métier doit être identique pour toutes les commandes, quelle que soit leur provenance et leur format, nous devons adapter le processus métier en conséquence. Cette situation n est pas logique car le processus métier doit être global à l entreprise et pas spécifique à une application donnée. b. Le rôle du format pivot Pour éviter ce type de situation et cette dépendance vis à vis des schémas des applications tierces, nous utilisons un schéma pivot. Un schéma pivot est un schéma qui représente un objet métier (une commande par exemple) et est complètement indépendant des formats de messages des applications tierces. Un schéma pivot offre donc de l indépendance et un couplage très faible vis à vis de l extérieur. Si l application de gestion commerciale change le format de ses commandes (nouveaux éléments, nouvelle structure des messages...), le schéma pivot BizTalk n est pas impacté. Idem si c est l application de Comptabilité qui modifie son format d échange. Afin de permettre la transition entre un schéma externe et le schéma pivot (et inversement), nous avons recours à des transformations (cf. chapitre Transformation de messages). Le schéma ci dessous illustre le scénario complet :

151 c. Faut il systématiser les schémas pivots? La modélisation de schémas pivots est une charge de travail non négligeable dans un projet. Les équipes sont donc parfois tentées d éviter des chantiers supplémentaires et cela est d autant plus vrai quand les plannings ou les budgets sont serrés. La mise en œuvre d un format pivot est pourtant fondamentale et constitue un gage de pérennité de la solution. L adaptabilité aux changements est une qualité in fine d une solution EAI et sans la mise en œuvre de formats pivots, tout changement opéré à l extérieur des frontières de l EAI risque d impacter fortement l existant. Dans certains scénarios cependant, je concède que les équipes projets soient réticentes à modéliser des schémas pivot. Je conseille dans ces scénarios de créer le format pivot en recopiant le format externe et en changeant simplement son espace de noms. Ainsi, vous obtenez un schéma pivot qui est une image du format externe mais vu différemment par BizTalk puisque disposant d un espace de noms spécifique. La transformation entre le message externe et le message pivot est très simple car c est une recopie de l ensemble des données. Si quelque temps plus tard, le message externe venait à changer, il suffirait de modifier la transformation sans impacter le schéma pivot. Lorsque nous évoquerons les transformations de messages, nous construirons un schéma pivot pour la commande ainsi que les transformations associées. 6. Gestion des versions dans les schémas a. Les changements de schémas Les schémas peuvent évoluer dans le temps, que ce soient des schémas pivots ou externes. Les acteurs externes à l EAI doivent être préservés de tous changements structurants s ils ne sont pas eux mêmes à l origine du changement. Il est primordial de garantir une compatibilité de vos schémas avec des applications ou partenaires, parfois pendant une phase d adaptation, mais souvent pendant une durée assez longue. b. Stratégies de gestion de version Si vous devez garantir aux applications communiquant avec votre solution EAI qu elles continuent de fonctionner malgré des changements de schémas, vous devez impérativement ajouter une notion de version dans vos schémas. Cette indication de version doit être visible dans le schéma mais aussi et surtout dans les messages produits à partir du schéma. Supposez par exemple que votre entreprise installe une nouvelle application de gestion commerciale. L ancienne application continue de fonctionner et la nouvelle la remplacera progressivement. Lors de la mise en place de la

152 nouvelle version dans votre entreprise, vous vous rendez compte que des informations complémentaires doivent être véhiculées avec une commande dans l EAI. Si vous modifiez le schéma Commande existant pour ajouter les éléments manquants, vous allez certainement rompre la compatibilité avec l application de gestion commerciale ancienne génération. Pour garantir la compatibilité, vous devez disposer de deux schémas externes : Un schéma Commande tel qu il a été modélisé à l origine. Un schéma Commande en version 2 adapté aux besoins de la nouvelle application de gestion commerciale. Pour différencier les deux schémas, modifiez l espace de noms du second schéma en ajoutant un numéro de version. L espace de noms devient donc urn:editionseni:gestioncommandes:2.0. Lorsqu un message est réceptionné par BizTalk, étant donné que l espace de noms est différent entre un message de commande v1.0 et v2.0, BizTalk peut facilement faire la distinction entre les deux. En couplant la notion de version des schémas avec les schémas pivot, vous pouvez faire en sorte que votre processus de gestion de commande ne soit pas impacté même si une nouvelle structure de commande est réceptionnée. Le schéma ci dessous illustre ce scénario : 7. Comment organiser les schémas d une solution BizTalk? Un projet BizTalk (ENI.Schemas dans notre cas), peut contenir un ou plusieurs schémas. Selon le contexte projet, plusieurs approches sont possibles pour stocker les schémas : Soit un projet unique dans lequel se trouvent tous les schémas de l entreprise. Soit un projet par processus (gestion des commandes par exemple) qui contient les schémas de gestion de commande. Soit un ensemble de projets pour un même processus. Le choix de cette organisation de projets Visual Studio aura des conséquences sur le déploiement de la solution BizTalk, il faut donc faire un choix adapté. Je vous conseille, d après mes expériences projets :

153 D isoler les schémas réutilisables (types de base...) dans un projet dédié qui sera référencé par les autres projets (cf. paragraphe Réutiliser les schémas dans ce chapitre). Ces schémas réutilisables peuvent être partagés avec d autres équipes projets, même si elles ne développent pas avec BizTalk. De ne pas construire un projet BizTalk unique avec l ensemble des schémas. Préférez un ou plusieurs projets de schémas par processus métier vous offrant ainsi la possibilité de déployer chaque processus métier indépendamment des autres. 8. Utiliser les assistants de génération de schémas Nous l évoquions en début de ce chapitre, BizTalk nous offre différents outils de modélisation de schémas. Ces outils sont adaptés à diverses situations. Lorsque nous avons modélisé le schéma Commande.xsd, nous avons utilisé l outil de modélisation de schémas de BizTalk intégré à Visual Studio. Cet outil permet de modéliser un message à partir d une feuille blanche. L outil est ainsi parfaitement adapté à une structure de message que vous venez de concevoir et que vous souhaitez implémenter. Il arrive très fréquemment que l on dispose déjà d éléments relatifs aux messages que nous souhaitons modéliser. Il peut s agir : d exemples de messages ; de schémas (XSD ou autres formats). a. Modéliser un schéma à partir d un exemple de message Lorsque deux partenaires souhaitent échanger des informations, ils accompagnent souvent la spécification de l échange avec quelques exemples de messages représentatifs des échanges à réaliser. À partir des exemples de messages, BizTalk vous permet de produire les schémas XSD correspondants. Prenons par exemple le message suivant qui représente une facture que BizTalk doit envoyer à l application de comptabilité : <?xml version="1.0" encoding="utf-8"?> <Facture xmlns="urn:editionseni:gestionfactures"> <CodeClient>43</CodeClient> <DateFacture>13/11/2009</DateFacture> <AdresseFacturation> <Rue>42 Rue de la pelouse</rue> <CodePostal>69000</CodePostal> <Ville>LYON</Ville> </AdresseFacturation> <MontantHT> </MontantHT> <TauxTVA>19.6</TauxTVA> <DateEcheancePaiement>13/12/2009</DateEcheancePaiement> </Facture> Voici comment créer le schéma XSD correspondant : Installez tout d abord l assistant de génération de schémas. Ouvrez l explorateur Windows et naviguez dans le répertoire C:\Program Files\Microsoft BizTalk Server 2009\SDK\Utilities\Schema Generator. Double cliquez sur le fichier InstallWFX.vbs. Dans le projet ENI.Schemas, ouvrez le menu contextuel, sélectionnez l option Ajouter, puis Ajouter les éléments générés. Choisissez Générer les schémas et cliquez sur Ajouter

154 Dans Type de document, sélectionnez Well Formed XML puis dans Fichier d entrée, sélectionnez le fichier exemple. Cliquez sur OK. Si à la place de Well Formed XML vous obtenez XML Bien formé (non chargé), cela signifie que l étape d installation du générateur de schéma n a pas fonctionné correctement. Relancez donc le fichier InstallWFX.vbs. À l issue de cette étape, vous disposez d un fichier.xsd dont le nom est identique au fichier utilisé comme exemple (dans notre cas Facture.xsd). Le générateur de schémas effectue une introspection du fichier exemple pour en déduire la structure et les types de données. Le schéma Facture généré contient un champ CodeClient de type xs:unsignedbyte car dans le fichier exemple le code client est numérique. Le schéma généré à partir de votre exemple de fichier est une base de travail et doit être certainement retouché et personnalisé. Cet assistant de génération de schémas est très utile et fait gagner beaucoup de temps. Lorsque vous

155 spécifiez des échanges avec vos partenaires, ne vous limitez pas à fournir des exemples de messages. Fournissez des schémas XSD accompagnés d exemples de messages. Le schéma XSD contient toutes les informations nécessaires à la construction et la vérification du message. Les exemples de messages permettent quant à eux d illustrer plusieurs cas métiers pour votre partenaire. b. Utiliser des fichiers XSD existants Si vous pouvez récupérer les schémas XSD correspondants aux messages que vous devez échanger soit parce que votre partenaire vous les fourni, soit parce que vous utilisez une norme qui offre une collection de schémas XSD réutilisables vous pouvez très facilement les intégrer dans un projet BizTalk. Supposons que vous disposiez du schéma XSD représentant une facture échangée avec un partenaire. Ce schéma XSD est le fichier Facture.xsd que le partenaire vous a envoyé. Pour intégrer ce schéma au projet ENI.Schemas, voici comment procéder : Sélectionnez le projet ENI.Schemas, ouvrez le menu contextuel et sélectionnez l option Ajouter puis Elément existant. Sélectionnez le fichier XSD à intégrer au projet. Cliquez sur Ajouter et le schéma est intégré au projet. L intégration de schémas XSD existant dans un projet BizTalk est très simple. Attention, dans certains cas, des dépendances existent entre les schémas que vous importez et d autres schémas, assurez vous de disposer de l ensemble des dépendances nécessaires. Lors de la compilation du projet BizTalk, vous serez averti par le compilateur si des dépendances sont manquantes

156 Modélisation de fichiers plats 1. Les différents types de fichiers plats Un fichier plat est un fichier texte contenant des données. On distingue deux types de fichiers plats : Les fichiers plats positionnels : les données sont stockées dans le fichier selon une position de départ et une longueur. Par exemple, le code client est stocké en position 0 sur une longueur de 10 puis le numéro de Commande... L exemple ci dessous est un fichier plat positionnel : CodeClient_0 41, rue du moulin69000lyon Les fichiers plats avec séparateurs : les données sont séparées d un caractère de séparation, permettant ainsi leur distinction. L utilisation de différents séparateurs permet la mise en œuvre d une hiérarchie complexe dans le fichier. L exemple ci dessous est un fichier plat avec séparateur : CodeClient_0 41, rue du moulin Lyon Produit1,10,10 Produit2,15,9 Certains fichiers plats combinent les deux modes, c est à dire que certaines données sont positionnelles, d autres avec séparateurs. 2. Utilisation de XSD pour modéliser un fichier plat La modélisation de fichiers plats avec BizTalk est tout à fait comparable à la modélisation de fichiers XML. Un fichier plat est modélisé dans BizTalk en utilisant les mêmes outils : schémas XSD, outils de tests fournis par Visual Studio... Des extensions (appelées extensions de fichiers plats) ont été ajoutées par Microsoft dans les fichiers XSD. Ces extensions permettent de stocker des informations spécifiques aux fichiers plats. Ces extensions n empêchent pas la réutilisation des schémas XSD puisque ce sont des annotations. Pour modéliser un fichier plat il faut donc créer un schéma XSD correspondant à la structure du fichier plat. BizTalk permet de modéliser des fichiers plats positionnels, délimités ou hybrides, c est à dire un mélange des deux. Avant la version 2006 de BizTalk, la modélisation d un fichier plat avec Visual Studio et l éditeur de schéma XSD était complexe et fastidieuse. Cette phase était la plupart du temps une source d erreur importante dans l implémentation d une solution et provoquait une certaine réticence des équipes projet vis à vis de l utilisation de BizTalk pour traiter des fichiers plats. Depuis BizTalk Server 2006, un assistant de modélisation de fichiers plats est apparu. Cet assistant guide pas à pas le développeur dans le processus de modélisation. C est une avancée très importante qui accélère grandement l implémentation et sécurise cette phase projet. Nous allons utiliser cet assistant dans les paragraphes qui suivent. 3. Modélisation d un fichier plat avec délimiteurs Nous allons tout d abord utiliser l assistant de modélisation pour modéliser un fichier plat avec délimiteurs (fichier appelé CSV pour Comma Separated Value, c est à dire fichier de données avec séparateur virgule). Le fichier suivant qui représente une commande va être modélisé : CodeClient_0 41, rue du moulin Lyon Produit1,10,10 Produit2,15,9 Si vous ne possédez pas ce fichier sur votre disque, créez un fichier texte, avec le bloc notes, copiez/collez le contenu dans le fichier et enregistrez le. Nommez le CommandeSep.txt et ajoutez le dans le répertoire Exemples du projet ENI.Schemas. Nous allons maintenant créer un nouveau schéma XSD dans le projet ENI.Schemas. Ce schéma, que nous allons

157 nommer CommandeSep.xsd contient la modélisation du fichier avec délimiteurs : Ajoutez un nouvel élément au projet ENI.Schemas, sélectionnez le type d élément Assistant Schéma de fichier plat, et nommez le fichier CommandeSep.xsd. Dans l écran d introduction de l assistant, cochez la case Ne plus afficher cette page d introduction, afin que cette page ne s affiche plus lors de vos prochaines utilisations de l assistant, cliquez ensuite sur Suivant. Vous devez fournir à l assistant de modélisation un exemple de message afin qu il vous assiste pendant la modélisation. Sélectionnez l exemple de fichier pour le fournir à l assistant (dans notre cas le fichier CommandeSep.txt). Saisissez le nom de l enregistrement, qui sera le nœud racine du schéma. Nommons ce nœud CommandeSep. Saisissez enfin l espace de noms cible. Pour rester cohérent avec les schémas existants, saisissez l espace de noms urn:editionseni:gestioncommandes. Cliquez ensuite sur Suivant. L assistant vous présente ensuite le contenu du fichier exemple. Par défaut, il considère que vous souhaitez modéliser la totalité de son contenu mais si ce n est pas le cas vous pouvez changer la sélection. Cliquez ensuite sur Suivant

158 La case à cocher Retour longues lignes automatique permet de visualiser les lignes de longue taille en ajoutant un retour chariot automatiquement. Cela n a pas d impact sur la modélisation. Sélectionnez ensuite le type de fichier plat que vous souhaitez modéliser. Dans notre cas, Par symbole délimiteur. Vous devez choisir le premier Délimiteur enfant. Dans notre cas il s agit du retour chariot (caractère {CR}{LF})

159 L assistant détecte qu il existe deux éléments séparés par le caractère retour chariot. Le premier élément constitue dans notre cas les données du client (code du client et adresse de livraison) et la seconde ligne est la liste des produits commandés : Nommez la première ligne Client et indiquez qu il s agit d un enregistrement. Nommez la seconde ligne Produits et indiquez également qu il s agit d un enregistrement : Puisque nous avons indiqué la présence dans le fichier de deux enregistrements (Client et Produits), nous devons modéliser chaque enregistrement. Cliquez sur Suivant pour continuer

160 L assistant sélectionne automatiquement l enregistrement que nous devons modéliser. Dans notre cas, il s agit de la première ligne du fichier. Cliquez sur Suivant pour continuer : Dans l écran suivant, choisissez de nouveau le type de fichier plat Par délimiteurs. Vous devez préciser quel est le délimiteur. Saisissez le caractère dans le champ Délimiteur enfant :

161 Nommez désormais les champs en fonction de leur contenu : CodeClient, RueLivraison, CodePostalLivraison et VilleLivraison : Vous devez maintenant modéliser l enregistrement Produits. L enregistrement Produits est lui même composé de plusieurs enregistrements. Les enregistrements contenus dans Produits sont séparés entre eux par le caractère. Précisez ainsi le caractère comme délimiteur enfant :

162 L enregistrement Produits est composé de plusieurs enregistrements nommés Produit. Chaque Produit est identique, il n est donc pas utile de modéliser chaque ligne puisque toutes sont identiques en termes de structure : Nommez la première ligne Produit, puis indiquez qu il s agit d un Enregistrement répété (il y a en effet plusieurs produits). Indiquez ensuite sur la seconde ligne que le Type d élément est Ignorer. Vous n aurez donc pas à modéliser cette ligne. Les écrans suivants de l assistant vous permettent de modéliser l un des produits de la collection de produits du fichier. Chaque produit est une structure délimitée avec le caractère,. Vous devez donc préciser ce délimiteur enfant dans l écran ci dessous :

163 Nommez les champs d un produit en CodeProduit, Quantite et PrixUnitaire. Notez que les champs Quantite et PrixUnitaire sont typés comme des entiers (type int). À l issue de l exécution de l assistant, vous obtenez un schéma XSD nommé CommandeSep.xsd qui est la modélisation du fichier plat. 4. Modélisation d un fichier plat positionnel Le fonctionnement de l assistant est quasiment identique lorsque vous souhaitez modéliser un fichier plat positionnel. Nous n allons donc pas illustrer dans ce paragraphe toutes les étapes de modélisation d un fichier positionnel mais simplement les différences avec la modélisation de fichiers plats avec délimiteurs

164 Nous allons modéliser le fichier plat représenté ci dessous : CodeClient_0 41, rue du moulin69000lyon Produit Produit La particularité de ce fichier plat est qu il est à la fois avec délimiteurs et positionnel. Il y a trois lignes dans ce fichier, chaque ligne est séparée avec un caractère de retour chariot qui est le délimiteur. Chaque ligne (la première représente le client et les suivantes représentent des produits commandés) est structurée de manière positionnelle. Lancez l assistant et sélectionnez l exemple de fichier que vous souhaitez modéliser. Nommez le nœud racine CommandePos. Saisissez l espace de noms urn:editionseni:gestioncommandes. Étant donné que notre fichier est tout d abord avec délimiteurs, nous devons indiquer à l assistant Par symbole délimiteur, puis sélectionner comme délimiteur enfant le caractère de retour chariot ({CR}{LF}). Afin de modéliser chaque ligne du fichier, voici les indications que vous devez donner à l assistant :

165 Une fois de plus, il n est pas utile de décrire comment est structuré chaque produit puisqu ils respectent tous la même structure. Lorsque l assistant vous demande de modéliser l enregistrement client, sélectionnez Par positions relatives comme type de fichier. Avec la souris, positionnez les délimitations entre chaque champ en fonction de leur taille. Le champ qui accueille le code client a une longueur de 15 caractères, le code postal de 5 caractères

166 Opérez de la même manière pour la ligne correspondant à un produit : La modélisation du fichier plat positionnel est terminé. Vous pouvez consulter le résultat de la modélisation dans le fichier XSD correspondant. 5. Les extensions fichiers plats dans XSD Comme nous l évoquions au début de ce paragraphe, la recommandation XSD a été modifiée (plus précisément annotée) pour permettre la modélisation de fichiers plats. Ces annotations ajoutées par Microsoft, sont interprétées par les composants BizTalk lors du traitement du fichier plat (nous le découvrirons dans le paragraphe Réception de fichiers plats du chapitre Pipelines et composants de pipelines)

167 Ces annotations sont également utilisées par Visual Studio. Si vous sélectionnez le schéma CommandePos.xsd (fichier plat positionnel), vous constatez la présence d un onglet supplémentaire nommé Fichier plat. Cet onglet contient la définition des positions et longueurs des différents champs du schéma. Si vous sélectionnez le champ CodeClient et vous rendez dans la page de propriétés correspondante, vous pouvez consulter des propriétés spécifiques aux fichiers plats positionnels. Il s agit par exemple de la position du champ, de sa longueur ainsi que sa justification : Lorsqu il s agit d un schéma avec délimiteur (comme le schéma CommandeSep), l onglet Fichier plat est également présent comme l illustre la copie d écran suivante

168 Si vous sélectionnez l enregistrement Client dans le schéma CommandeSep, vous pouvez vous rendre compte des propriétés qui qualifient cet enregistrement. Il s agit par exemple du caractère de séparation (délimiteur enfant) et du type de structure (structure) : Grâce à l assistant fichier plat, vous pouvez construire des schémas XSD qui, la plupart du temps, ne nécessitent pas de modifications. Si toutefois vous souhaitez apporter des corrections ou précisions, vous pouvez le faire grâce aux différentes propriétés des schémas générés. À l usage, vous remarquerez qu un grand nombre de propriétés permettent d affiner le comportement du schéma de fichier plat. Lorsque les fichiers plats sont complexes, ces propriétés sont d une aide précieuse. 6. Comment modifier une structure de fichier plat? Nous venons de voir que les schémas de fichiers plats contiennent différentes propriétés qualifiant précisément le schéma et son contenu. En modifiant les valeurs de ses propriétés vous pouvez donc adapter le schéma à votre scénario

169 Lorsque la structure d un fichier plat est modifiée, l utilisation de l éditeur de schéma et des propriétés associées devient trop complexe et trop fastidieuse. Si vous devez simplement modifier une longueur de champ, vous pourrez le faire aisément, si par contre vous devez modifier complètement la structure pour ajouter des champs, modifier des champs existants et en retirer certains, vous risquez de perdre beaucoup de temps et de produire des erreurs dans votre schéma. Vous pouvez, à tout moment depuis le schéma de fichier plat, relancer l assistant de modélisation et ce, sans perdre le contenu de votre fichier XSD. Sélectionnez le nœud de votre schéma que vous souhaitez modifier, ouvrez le menu contextuel et sélectionnez l option Définir l enregistrement à partir d une instance de fichier plat : Effectuez cette action en sélectionnant l enregistrement Client du schéma CommandePos : L assistant vous prévient qu il va supprimer la structure de l actuel enregistrement pour la recréer. Vous devez accepter pour continuer. Lorsque l assistant vous propose le contenu du fichier à modéliser, pensez simplement à sélectionner la partie du message que vous souhaitez modéliser de nouveau comme illustré ci après pour l enregistrement Client. 7. Tester un schéma de fichier plat Vous pouvez tester un schéma de fichier plat comme s il s agissait d un schéma de fichier XML

170 a. Générer l instance d un fichier plat Pour générer une instance de fichier plat, vous utilisez l option Générer l instance sur le fichier XSD. Dans les options du schéma, vous disposez d une propriété nommée Type de sortie de Générer l instance qui peut prendre deux valeurs : XML : si vous générez une instance du schéma, vous obtenez un fichier XML. Natif : si vous générez une instance du schéma, vous obtenez un fichier plat. Faites l exercice et vous constaterez la différence. b. Valider une instance de fichier plat L option Valider l instance disponible au niveau du schéma permet de valider un exemple de fichier. Si vous souhaitez valider une instance de fichier qui est un fichier plat, vous devez vérifier que l option Type d entrée de Valider l instance est bien positionnée à Natif. c. Comment BizTalk gère t il les fichiers plats? Dans BizTalk, tous les messages sont représentés en XML, même les fichiers plats. Lorsqu un fichier plat est réceptionné par BizTalk, il va être désassemblé pour être transformé en XML et ainsi pouvoir être traité. Dès que le fichier plat a été réceptionné et transformé en XML, il peut être utilisé comme un message XML sans qu il n y ait aucune différence avec un message XML classique. La phase dite de désassemblage de fichier plat se déroule dans le pipeline de réception. Elle consiste à désassembler le fichier plat pour assembler un fichier XML conforme au schéma. Lorsque l opération se déroule dans un port d envoi, il s agit du mécanisme inverse, c est à dire qu il y a transformation d un message XML en message fichier plat conforme à un schéma XSD de fichier plat, on parle cette fois ci d assemblage. La nuance, de taille, entre la réception d un message XML et d un fichier plat, réside dans l association avec le schéma XSD correspondant. Lorsque BizTalk réceptionne un fichier XML, le fichier contient des indications pour permettre à BizTalk de trouver le schéma XSD. Il s agit du nœud racine et de l espace de noms. Dans un fichier plat, aucune indication très précise ne permet à BizTalk de savoir de quel fichier il s agit. Il faut donc l indiquer au niveau du pipeline d envoi ou de réception en précisant le schéma de fichier plat pouvant être reçu. Il n existe pas de pipeline standard permettant la réception de fichiers plats, il faut construire son propre pipeline avec un composant particulier en charge du désassemblage des fichiers plats. Idem pour l envoi. Nous abordons le processus de réception et d envoi des fichiers plats dans le chapitre consacré aux pipelines et composants de pipelines

171 Conclusion Nous avons évoqué dans ce chapitre les fonctions permettant la modélisation de messages avec BizTalk, que ce soient des fichiers XML ou plats. Dans le chapitre qui suit, nous allons apprendre à utiliser ces schémas

172 Déploiement de schémas Dans le chapitre précédent, nous avons décrit toutes les opérations devant être réalisées, pendant la phase de développement, pour modéliser les schémas des différents messages. Dans ce nouveau chapitre consacré au déploiement et à l utilisation des schémas, nous allons aborder l utilisation de ces schémas dans une solution BizTalk. La première étape est le déploiement de schémas. Avant de passer à cette étape de déploiement, je vous conseille de mener les tests sur vos schémas sur le poste de développement. Il s agit de l ensemble des tests relatifs aux schémas évoqués dans le chapitre précédent. Le schéma suivant illustre les étapes qui séparent la modélisation d un schéma de son déploiement dans BizTalk. Dans ce paragraphe, nous allons détailler chaque étape. 1. Compilation de projets BizTalk a. Génération de l assembly.net Lorsque nous avons réalisé notre première application BizTalk (cf. chapitre La messagerie avec BizTalk Server 2009), nous n avons pas eu recours à Visual Studio puisque toute notre solution reposait sur des éléments de configuration effectués dans la console d administration BizTalk. Si nous souhaitons utiliser nos schémas dans BizTalk, nous devons les déployer. Nous n allons pas déployer un par

173 un les fichiers XSD dans BizTalk mais nous allons compiler les schémas et produire une assembly.net. Lors de la compilation, les schémas XSD sont convertis en classes.net afin qu ils puissent être intégrés à l assembly.net : Pour lancer la compilation, sélectionnez le projet ENI.Schemas dans l explorateur de solutions, ouvrez le menu contextuel et sélectionnez l option Générer. Lors de la compilation, les schémas du projet sont vérifiés, ce qui équivaut à lancer l action Valider le schéma sur chaque schéma. Si l un des schémas ne peut être vérifié, la compilation échoue. De la même manière, si un schéma référence un autre schéma et si ce schéma référencé est introuvable la compilation sera en échec. Le résultat de la compilation est affiché dans la fenêtre Sortie de Visual Studio comme indiqué ci dessous : Lorsque la compilation est terminée, nous obtenons une assembly.net stockée dans le sous répertoire bin\debug du projet, comme l illustre la copie d écran ci dessous : Avant la version 2009 de BizTalk, les assemblies générées par les projets BizTalk étaient stockées dans le répertoire bin\developement. b. Conversion des schémas en classes.net Pendant la phase de compilation, les schémas XSD ont été convertis en classes.net. Même si vous n avez pas écrit vous même les classes.net correspondant aux schémas XSD, vous pouvez visualiser le code des classes.net générées. Sélectionnez le projet ENI.Schemas. Cliquez sur le bouton Afficher tous les fichiers

174 Vous voyez apparaître un fichier portant le même nom que le schéma mais avec une extension.cs. Ouvrez le fichier Commande.xsd.cs. Le schéma XSD Commande a été converti en une classe.net que BizTalk va utiliser. Cette phase de conversion, totalement transparente pour le développeur, est un passage obligatoire pour permettre aux schémas XSD d être intégrés dans une assembly.net. Dans le cas du schéma Commande, la classe.net générée dérive de la classe de base TestableSchemaBase. Ceci est lié au fait que nous avons préalablement activé l option Activer le test des unités pour autoriser les tests unitaires. Si nous n avions pas activé cette option, la classe.net dériverait de la classe de base SchemaBase. Nous disposons désormais d une assembly.net avec nos schémas et nous allons être en mesure de la déployer dans BizTalk. Ne modifiez pas directement le fichier.cs correspondant au schéma car lors de chaque compilation il sera écrasé et vous perdrez vos modifications. c. Génération et association d un nom fort à l assembly Dans son état actuel, cette assembly ne peut être déployée dans BizTalk car elle ne possède pas de nom fort (en anglais strong name). Le nom d une assembly, sans nom fort, est le nom du fichier d extension.dll qui a été généré lors de la compilation. Dans notre cas, il s agit d ENI.Schemas.dll. Ce nom n est pas fort dans le sens où n importe qui peut produire une assembly portant ce nom. Si nous souhaitons faire cohabiter deux versions de cette assembly (par exemple pour déployer de nouveaux formats pivots), nous ne pouvons pas le faire car la nouvelle version de la dll portera exactement le même nom que la version précédente. BizTalk sera incapable de les distinguer. Pour remédier à cela, nous devons associer un nom fort à nos assemblies en les signant. Le processus de signature affecte un nom fort à l assembly. Le nom fort est composé des éléments suivants : le nom de l assembly (ENI.Schemas.dll) ; le numéro de version ( ) ;

175 la culture de l assembly (neutral dans notre cas) ; un numéro de clé unique que nous sommes seuls à pouvoir produire. La production d un nom fort nécessite un fichier de clé. Ce fichier de clé (par convention, un fichier avec l extension.snk), doit être préservé par votre équipe et ne doit pas être divulgué. Si vous perdez ce fichier, vous ne pourrez plus jamais produire des noms forts identiques aux noms générés avec la clé perdue. Afin d associer un nom fort à notre assembly, voici comment il faut procéder : Nous allons tout d abord générer un fichier de clé. Dans le menu Démarrer, menu Microsoft Visual Studio 2008, sélectionnez le sous menu Visual Studio Tools puis ouvrez l option Invite de commandes de Visual Studio Tapez la ligne suivante : sn -k c:\editionseni\editionseni.snk. Vous obtenez le fichier de clé que je vous conseille de préserver en lieu sûr. Il existe un autre moyen de générer ce fichier de clé, directement depuis les propriétés du projet dans Visual Studio Si vous souhaitez sécuriser l accès à cette clé, vous pouvez associer au fichier.snk un mot de passe. Nous allons signer l assembly ENI.Schemas pour produire un nom fort : Dans Visual Studio, sélectionnez le projet ENI.Schemas et dans le menu Projet, sélectionnez l option Propriétés de ENI.Schemas. Dans l onglet Signature, cochez la case Signer l assembly et sélectionnez le fichier de clé généré à l étape précédente. Enregistrez vos modifications et lancez de nouveau la génération du projet. Nous disposons d une assembly avec un nom fort. À l œil nu, aucune différence n est visible entre l assembly avec nom fort de l assembly sans nom fort. Nous pouvons maintenant déployer cette assembly au sein d un groupe BizTalk

176 2. Déploiement des schémas a. Les étapes du déploiement Le déploiement des schémas au sein d un groupe BizTalk passe par deux étapes : L import L installation L import des schémas L import des schémas consiste à importer dans la base de données de configuration de BizTalk l ensemble des schémas contenus dans une assembly.net. Lors de la phase d import, BizTalk effectue les actions suivantes : Il importe le contenu de l assembly.net dans sa base de données de configuration (BizTalkMgmtDb). Il analyse l assembly et cherche toutes les classes.net correspondant à des schémas. Pour chaque classe de type schéma trouvée dans l assembly, il crée une occurrence dans sa base de données. Cette phase est primordiale car c est à cette étape que BizTalk prend connaissance des schémas contenus dans une assembly. L installation des schémas L installation des schémas est la copie de l assembly.net qui contient les schémas sur le ou les serveurs BizTalk. L assembly doit en effet être présente physiquement sur chaque serveur BizTalk. L assembly.net ainsi copiée sur le ou les serveurs BizTalk est ensuite chargée en mémoire lors de l exécution (réception, traitement ou envoi d un message). Le serveur BizTalk est en mesure, en utilisant la classe.net qui représente le schéma, de vérifier le message par rapport à son schéma. Reportez vous au paragraphe Utilisation de schémas dans BizTalk pour plus de détails sur le fonctionnement lors de l exécution. Afin que le serveur BizTalk puisse charger l assembly, cette dernière doit être copiée dans le GAC (Global Assembly Cache) du serveur. Le GAC est un emplacement unique sur chaque machine disposant du Framework.Net. Cette zone permet le stockage d assemblies.net. Il s agit du répertoire %windir%\assembly. Le GAC offre, contrairement à un répertoire traditionnel, la possibilité de stocker au même endroit plusieurs versions d une même assembly. Ceci est possible grâce au nom fort associé à chaque assembly (le nom fort contient en effet le numéro de version d une assembly). Pour le GAC, deux assemblies qui n ont pas exactement le même nom fort sont deux assemblies différentes. Lorsque nous aurons déployé l assembly des schémas ENI.Schemas.dll, nous visualiserons le contenu du GAC et le nom fort de notre assembly. b. Les différentes méthodes de déploiement de schémas L exécution des étapes de déploiement que nous venons de détailler (import et installation) peut être effectuée selon trois méthodes : directement depuis Visual Studio ; via la console d administration de BizTalk ; en ligne de commande avec l outil BTSTask.exe. Nous allons détailler les deux premières méthodes, l utilisation de l outil BTSTask.exe étant quant à lui détaillée dans la documentation de BizTalk

177 c. Déploiement avec Visual Studio Le déploiement depuis Visual Studio est une fonctionnalité offerte au développeur. Celui ci peut déployer l ensemble des projets BizTalk sur lesquels il travaille sans quitter Visual Studio. Pour que cela fonctionne, il doit avoir accès au serveur SQL Server hébergeant les bases de données de BizTalk. Reportez vous à la documentation de BizTalk pour connaître la configuration à mettre en œuvre pour que cette méthode de déploiement fonctionne. Il convient en effet de configurer correctement le service MSDTC (MicroSoft Data Transaction Coordinator) sur la machine de développement et le serveur SQL Server. Pour déployer depuis Visual Studio, vous devez préalablement renseigner les propriétés de déploiement du projet ENI.Schemas : Dans Visual Studio, sélectionnez le projet ENI.Schemas et dans le menu Projet, sélectionnez l option Propriétés de ENI.Schemas. Sélectionnez l onglet Déploiement. Dans cet onglet se trouvent les propriétés suivantes : Redéployer : cette propriété va guider le comportement de Visual Studio lorsque votre projet est déjà déployé. Si la propriété vaut True, Visual Studio va supprimer l assembly pour la déployer de nouveau. Si cette propriété vaut False, une erreur sera générée lors du déploiement si l assembly est déjà déployée. Base de données de configuration : cette propriété contient le nom de la base de données de configuration BizTalk. La valeur par défaut, BizTalkMgmtDb, est très rarement modifiée. Nom de l application : la valeur de cette propriété est vide par défaut. Lorsque vous déployez votre projet avec Visual Studio, et si cette propriété est vide, vos schémas seront déployés dans l application par défaut du groupe BizTalk. Si vous souhaitez que vos schémas soient déployés dans l application de votre choix, précisez son nom dans cette propriété. Si l application n existe pas lors du déploiement, elle sera créée automatiquement. Serveur : cette propriété contient le nom de l instance SQL Server qui héberge la base de données de configuration BizTalk. Installer dans le Global Assembly Cache : cette propriété indique à Visual Studio si, en plus de la phase d import dans BizTalk, il doit également effectuer la copie dans le GAC de la machine. Attention, si le poste de développement pointe sur un serveur BizTalk distant, Visual Studio n est pas capable de copier l assembly dans le GAC du serveur distant. Cette option n a de sens que lorsque BizTalk est installé sur le poste de développement. Redémarrer les instances d hôte : cette option indique à Visual Studio s il doit ou non redémarrer les instances de services BizTalk. Nous verrons plus loin que cette option est importante pour que BizTalk prenne en compte correctement une assembly redéployée. Afin que nos schémas soient déployés dans l application EditionsENI, nous allons simplement saisir la valeur EditionsENI dans la propriété Nom de l application et enregistrer nos modifications :

178 Dans l explorateur de solutions, sélectionnez le projet ENI.Schemas, ouvrez le menu contextuel et sélectionnez l option Déployer. La progression du déploiement ainsi que son résultat sont affichés dans la fenêtre Sortie de Visual Studio. d. Vérifier si les schémas sont correctement déployés Visualiser les schémas déployés Pour vérifier que les schémas ont été correctement déployés, ouvrez la console d administration de BizTalk. Ouvrez l application EditionsENI et sélectionnez le nœud Schémas : Vous pouvez le constater, la liste des schémas a été enrichie avec l ensemble des schémas contenus dans l assembly déployée. Pour chaque schéma, les données suivantes sont présentes : Nom : nom complet du schéma. Assembly : nom fort de l assembly qui contient les schémas. Nom de la racine : nom du nœud racine du schéma. Espace de noms cible : espace de noms du schéma. Type de schéma : nous avons modélisé des schémas de type Document. Nous verrons qu il existe également des schémas de type Propriétés. Application : nom de l application dans laquelle se trouve le schéma. Le schéma TypesSimples apparaît deux fois dans cette liste, chaque fois avec un nœud racine différent. Ceci

179 est complètement normal car le schéma type simple n a pas un seul nœud racine mais un ensemble d éléments. Si vous double cliquez sur un schéma, par exemple le schéma ENI.Schemas.Commande, vous pouvez visualiser le détail du schéma : Dans l onglet Affichage de schéma, vous pouvez visualiser le contenu du schéma en code XSD :

180 Visualiser l assembly.net déployée Étant donné que les schémas sont intégrés dans l assembly.net ENI.Schemas.dll, cette assembly a été ajoutée au niveau des ressources de l application BizTalk. Pour la visualiser, ouvrez le nœud Ressources de l application EditionsENI : L assembly.net contenant les schémas a été ajoutée automatiquement aux ressources de l application lors du déploiement. Si nous exportons l application sous forme d un fichier MSI, comme nous l avons fait aux chapitres précédents, l assembly sera intégrée au package MSI car elle fait partie des ressources. Les schémas seront ainsi déployés lorsque le fichier MSI sera importé. Visualiser le contenu du GAC Puisque nous avons indiqué à Visual Studio de déployer l assembly dans le GAC lors du déploiement, nous pouvons vérifier que cette assembly a été correctement copiée : Ouvrez le menu Démarrer et l option Exécuter. Tapez la commande assembly, permettant l ouverture du GAC :

181 Localisez l assembly ENI.Schemas dans le GAC : Vous pouvez visualiser le nom fort de l assembly qui est le suivant : ENI.Schemas, Version= , Culture=neutral, PublicKeyToken=bb71f210b1779e11, processorarchitecture=msil Si vous avez généré votre propre fichier de clé (fichier.snk) et l avez utilisé pour compiler l assembly, le nom fort sera différent de celui affiché ci dessous car la valeur de PublicKeyToken sera différente. Il vous est impossible de générer le même nom fort sauf si vous disposez du même fichier de clé. e. Déploiement avec la console d administration de BizTalk Pour déployer avec la console d administration de BizTalk, deux étapes sont nécessaires : l import de l assembly dans les ressources de l application et la copie de l assembly dans le GAC. Pour réaliser cette manipulation, vous devez préalablement supprimer les schémas s ils sont déjà déployés, même s ils ont été déployés dans une autre application. Une assembly.net ne peut pas être déployée plus d une fois dans la même base de données de configuration BizTalk. Ajouter l assembly dans les ressources de l application Sélectionnez l application dans laquelle vous souhaitez déployer les schémas (EditionsENI). Ouvrez le menu contextuel et sélectionnez l option Ajouter puis Assemblys BizTalk :

182 Localisez l assembly à ajouter dans les ressources (ENI.Schemas.dll) et cliquez sur le bouton OK. Vous pouvez ajouter plusieurs assemblies en même temps. Vous disposez de trois options : Ajouter au Global Assembly Cache lors de l ajout de la ressource (gacutil) : l assembly va être copiée dans le GAC lorsque vous cliquerez sur OK. Ajouter au Global Assembly Cache lors de l importation du fichier MSI (gacutil) : l assembly sera copiée dans le GAC lorsque le fichier MSI correspondant à l application sera importé. Ajouter au Global Assembly Cache lors de l installation du fichier MSI (gacutil) : l assembly sera copiée dans le GAC lorsque le fichier MSI correspondant à l application sera installé

183 Je vous conseille de laisser les valeurs par défaut. Installer l assembly dans le GAC Il existe de nombreuses méthodes pour déployer une assembly dans le GAC (assembly.net BizTalk ou non). Ces méthodes sont : Effectuer un glissé/déposé de l assembly dans le répertoire du GAC. Utiliser l outil en ligne de commande gacutil.exe. Utiliser les outils d administration du Framework.Net depuis le Panneau de configuration. La méthode qui consiste à glisser/déposer l assembly directement dans le répertoire du GAC est de loin la plus simple et la plus efficace. Je vous conseille donc de l utiliser. f. Le déploiement industrialisé de schémas Que vous utilisiez le déploiement avec Visual Studio, avec la console d administration ou avec BTSTask.exe, le déploiement d un schéma dans un groupe BizTalk est identique. Comme nous l évoquions dans le chapitre consacré au déploiement avec BizTalk, la mise en œuvre d un package de déploiement d une application BizTalk est un gage de qualité et d industrialisation. La création de ce package est une étape qui doit faire partie du processus de développement. Les étapes de déploiement que nous avons effectué dans ce chapitre ne sont évidemment pas destinées aux exploitants et administrateurs de votre Système d Information. Ce sont des étapes destinées aux équipes de développement et elles sont la plupart du temps réalisées localement sur le poste de chaque développeur ou sur la plate forme de développement de l entreprise. Si vous souhaitez déployer un schéma XSD dans votre environnement de recette ou de production, vous devez générer un package MSI depuis l environnement de développement et utiliser ce package pour déployer le schéma. Vous allez tout simplement exporter l application BizTalk dans laquelle se trouvent les schémas et distribuer le fichier MSI correspondant. Reportez vous au chapitre Déploiement de solutions BizTalk pour connaître les étapes à suivre pour exporter une application. Les phases d import des schémas et de copie dans le GAC seront automatiquement effectuées lorsque les exploitants informatiques utiliseront le package MSI qui leur aura été fourni. g. Déploiement des fichiers plats Le déploiement de schémas de fichiers plats ne diffère pas du déploiement de schémas XSD classiques. Lors de la compilation, les schémas XSD des fichiers plats sont convertis en classes.net pour être déployés ensuite au niveau du groupe BizTalk

184 Utilisation de schémas dans BizTalk Nos schémas sont désormais déployés, nous allons maintenant les utiliser. Pour illustrer l utilisation de schémas, nous allons faire évoluer la solution d échange créée dans les précédents chapitres et lui adjoindre des étapes dans lesquelles les schémas seront utilisés. 1. Réception de messages structurés a. Rappels sur l utilisation du pipeline PassThruReceive Dans nos précédents exercices, lorsque l application de Gestion commerciale envoyait un message à l EAI le contenu du message était complètement ignoré par BizTalk, ceci grâce à l utilisation du pipeline de réception PassThruReceive. Comme nous l avons expliqué, le pipeline PassThruReceive est complètement vide et ainsi il ne fait aucune action sur le message qu il traite. Il n est donc pas en mesure de vérifier la structure du message réceptionné. b. Fonctionnement de la réception d un message structuré La première étape que BizTalk peut effectuer lors de la réception d un message est la détection du type de message reçu. BizTalk peut en effet nous indiquer que le message entrant est une commande ou une facture, ceci en exploitant le contenu du message et en le rapprochant d un schéma modélisé et déployé. Nous devons utiliser un pipeline de réception particulier nommé XMLReceive pour permettre à BizTalk de réaliser cette étape. Comme son nom l indique, ce pipeline permet de recevoir des messages XML et effectue un ensemble de traitements sur les messages pour les vérifier. Le pipeline XMLReceive est livré avec BizTalk tout comme le pipeline PassThruReceive. Si nous associons ce pipeline à un emplacement de réception, les traitements suivants vont être effectués dès la réception d un message et avant que le message ne soit publié dans la MessageBox : Vérification du message XML Le pipeline vérifie que le message entrant est un message au format XML et qu il est bien formé. Un message XML bien formé (Well formed XML) est un message qui respecte les conditions suivantes : Le document dispose d un et d un seul nœud racine. Toutes les balises XML ouvertes sont fermées. Les noms des balises respectent la casse. Les éléments XML sont positionnés correctement et la hiérarchie du document est respectée. Les valeurs des attributs doivent être entre guillemets. Il n y a pas de caractères spéciaux comme "<" et "&" sauf dans la structure même du document. Recherche d un schéma correspondant Si le document XML est bien formé, le pipeline recherche un schéma qui correspond au message entrant. Pour cela, il utilise deux informations trouvées dans le message XML : le nom du nœud racine et l espace de noms du message. Supposons que le message entrant soit le message ci dessous : <ns0:commande xmlns:ns0="urn:editionseni:gestioncommandes" NumeroCommande="1"> <CodeClient>CodeClient_0</CodeClient> <Produits>

185 <Produit Code="Code_0"> <Quantite>10</Quantite> <PrixUnitaire>10</PrixUnitaire> </Produit> </Produits> <AdresseLivraison> <ns1:adresse xmlns:ns1="urn:editionseni:typescomplexes"> <Rue>Rue_0</Rue> <ns2:codepostal xmlns:ns2="urn:editionseni:typessimples">codep</ns2:codepostal> <Ville>Ville_0</Ville> </ns1:adresse> </AdresseLivraison> </ns0:commande> Les deux informations récupérées par le pipeline sont les suivantes : Nom du nœud racine : Commande. Espace de noms : urn:editionseni:gestioncommandes. Avec ces deux informations, le pipeline recherche un schéma correspondant dans la liste des schémas déployés au sein du groupe BizTalk. Rappellez vous que lorsque nous avons déployé les schémas, BizTalk a stocké des informations sur le nœud racine et l espace de noms de chaque schéma, comme le rappelle la copie d écran cidessous : Lors de cette étape de recherche de schémas, plusieurs scénarios peuvent se produire : Soit aucun schéma ne correspond : le message ne peut être publié dans la MessageBox. Le message et l instance de service correspondante (le port de réception en l occurrence) sont suspendus. Soit plusieurs schémas correspondent : cette situation n est pas normale et signifie qu un même schéma a été déployé plusieurs fois. Cette situation ne doit pas se produire. Soit un seul schéma correspond : le pipeline associe le message au schéma en ajoutant dans son contexte deux nouvelles informations : Le type de schéma dans la propriété BTS.MessageType sous la forme espace de nom#nœud racine. Dans notre exemple, la propriété sera égale à urn:editionseni:gestioncommandes#commande. Le nom complet du schéma dans la propriété BTS.SchemaStrongName sous la forme type.net, nom fort de l assembly. Dans notre exemple la propriété sera égale à ENI.Schemas.Commande, ENI.Schemas, Version= , Culture=neutral, PublicKeyToken=bb71f210b1779e11, processorarchitecture=msil. Si la recherche de schéma se déroule correctement, le message porte des informations concernant son type. Ces informations, notamment la propriété BTS.MessageType, peuvent être utilisées pour router le message vers des destinataires. Nous verrons dans le chapitre consacré aux pipelines que la réception d un message non reconnu, c est àdire si aucun schéma correspondant n a été trouvé, est parfois possible et ne provoque pas d erreurs. c. Configurer la réception d un message structuré

186 Nous allons adapter notre solution BizTalk pour qu elle sache réceptionner des messages structurés de type commande. Localisez l emplacement de réception rcvgestioncommerciale_file et ouvrez ses propriétés. Sélectionnez le pipeline XMLReceive à la place du pipeline PassThruReceive. Localisez le port d envoi sndcomptabilite_file et stoppez le, simplement pour nous permettre de visualiser le contexte du message entrant dans la console d administration. Réceptionnez un message de type Commande en déposant un exemple de ce message dans le répertoire d écoute de l emplacement rcvgestioncommerciale_file. Dans la requête Toutes les instances de service en cours, localisez l instance du port d envoi sndcomptabilite_file qui est à l état Suspendu (peut être repris) : Ouvrez le menu contextuel sur l instance suspendue, puis sélectionnez l option Détails sur le service et naviguez

187 dans l onglet Messages. Enfin, ouvrez le détail du message. Dans cet onglet, vous pouvez constater que la valeur de Type de message est renseignée avec urn:editionseni:gestioncommandes#commande. Dans l onglet Contexte, vous pouvez localiser les deux propriétés MessageType et SchemaStrongName pour vérifier qu elles ont été renseignées correctement

188 Pour illustrer les différents cas d erreur exposés dans le paragraphe précédent, je vous invite à tester la réception d un message non XML ou d un message dont le type n est pas connu par BizTalk. d. Rechercher un message avec son type Nous savons maintenant que notre message est associé à un schéma car BizTalk, lors de la réception du message et juste avant sa publication dans la MessageBox, a fait les traitements nécessaires. Nous pouvons désormais exploiter cette information pour rechercher un message. Rechercher une commande en cours de traitement La copie d écran suivante illustre comment rechercher un message de type Commande de l espace de noms urn:editionseni:gestioncommandes dans la liste des messages en cours de traitement dans BizTalk. Rechercher une commande qui a été traitée La copie d écran ci dessous illustre comment chercher une commande dont le traitement a été effectué : Pour l instant, nous ne sommes pas encore en mesure de chercher une commande avec des critères plus précis (code du client par exemple). Nous verrons plus loin dans ce chapitre que ce type de recherche est possible. 2. Routage d un message en fonction de son type Dans l exemple de routage mis en œuvre au chapitre La messagerie avec BizTalk Server 2009, nous avons construit des règles de routage basées sur le nom du port de réception. Pour rappel, le port d envoi sndcomptabilite_file a comme filtre BTS.ReceivePortName=rcvGestionCommerciale. Ce filtre indique que tous les messages réceptionnés par le port de réception rcvgestioncommerciale sont routés à l application de gestion de comptabilité et ce, quel que soit leur type. Maintenant que notre message est typé, nous pouvons utiliser le type d un message pour décider de le router à une

189 application ou un partenaire. Nous pouvons par exemple router à une application ou un partenaire : toutes les commandes en provenance de la gestion commerciale ; toutes les commandes, quelle que soit leur provenance. Je vous propose de modifier le filtre du port d envoi sndcomptabilite_file : Localisez le port d envoi sndcomptabilite_file, ouvrez ses propriétés et rendez vous dans l onglet Filtres. Modifiez le filtre comme indiqué dans la copie d écran ci dessous : Grâce à ce filtre, toutes les commandes seront systématiquement envoyées vers l application de comptabilité. L application BizTalk permettant la réception et l envoi d un message en fonction de son type peut être téléchargée. Il s agit du fichier Chapitre7.msi. 3. Envoi de messages structurés Nous venons de voir que la réception de messages structurés passe par l utilisation d un pipeline spécifique permettant la vérification des messages et l association avec des schémas. L envoi de messages structurés est un peu différent. En effet, est il nécessaire de vérifier qu une commande réceptionnée par BizTalk et sur laquelle aucune opération n a été effectuée est toujours une commande lorsqu elle est envoyée? Autrement dit, si vous avez vérifié que le message entrant est de type commande et qu il est bien formé, est ce qu il est utile de faire la même chose à l envoi alors même que rien n a changé dans le message? Ce n est pas utile, voire même une perte de temps et de performance. Lorsque vous produisez un nouveau message, par exemple dans le cadre d un processus métier implémenté dans BizTalk (cf. chapitre Implémentation de processus métier), vous pouvez utiliser des composants fournis par BizTalk

190 pour produire les nouveaux messages à partir de messages entrants (par exemple un acquittement de commande à partir d un message de type commande). Ces composants vous garantissent que les messages produits sont bien formés et conformes aux schémas déployés dans BizTalk. Dans ces scénarios il n est pas non plus utile de vérifier de nouveau à l envoi que le message est bien formé. Finalement, vous devez vous demander dans quels cas il faut vérifier un message avant qu il ne sorte de BizTalk. Ces vérifications sont nécessaires et vous les découvrirez dans la suite de cet ouvrage. Il s agit par exemple de scénarios dans lesquels vous êtes à l origine d un nouveau message et souhaitez donc vous assurer qu il est correct avant qu il ne sorte de l EAI. Si vous utilisez correctement les outils mis à votre disposition pour créer des messages dans BizTalk, par exemple les transformations, le risque qu un message soit un message XML mal formé est quasiment nul. J ai malheureusement déjà vu des solutions BizTalk qui n utilisaient pas du tout les outils BizTalk pour générer des messages et donc dans ce cas le risque de générer des messages mal formés ou non conformes est très important. Nous étudierons les différentes alternatives de création de messages dans BizTalk dans le chapitre Implémentation de processus métier. Si vous souhaitez vérifier un message avant son envoi, vous pouvez utiliser le pipeline XMLTransmit. Ce pipeline, livré avec BizTalk, effectue des vérifications équivalentes à celles effectuées par le pipeline XMLReceive : message XML bien formé et schéma XSD déployé correctement. En cas d erreur, l instance du port d envoi, auquel le pipeline est associé, est suspendue et peut être reprise. Souvenez vous, dans le chapitre Suivi de l activité et gestion des erreurs, nous évoquions les erreurs pouvant se produire lors de la réception et l envoi de messages. Ces erreurs provoquent la suspension de l instance de service correspondante. C est exactement ce qui se produit si vous tentez l envoi d un message XML mal formé via le pipeline XMLTransmit. Si vous souhaitez relancer l instance de service en ayant préalablement corrigé le message, vous ne disposez pas, dans la console d administration de BizTalk, d outils pour le faire. Le message en erreur n est en effet pas modifiable directement. C est exactement dans ce type de scénario que la publication du message en erreur dans un portail de gestion permettant la correction et la resoumission est utile. 4. Validations de messages a. Processus de détection du type de message Nous avons l impression jusqu à maintenant, que l utilisation des pipelines XMLReceive et XMLTransmit suffit pour garantir que le message entrant ou sortant est de bonne qualité mais aussi et surtout conforme à un schéma modélisé et déployé. Lors de la réception par exemple, le pipeline XMLReceive a détecté que le message est conforme au schéma Commande et il a de ce fait renseigné la propriété de contexte BTS.MessageType avec la valeur urn:editionseni:gestioncommandes#commande. En réalité, le pipeline XMLReceive ne vérifie pas le message entrant. Il détecte simplement le nœud racine Commande et l espace de noms urn:editionseni:gestioncommandes. Ces deux informations lui suffisent pour supposer que le message est une commande. Ce n est cependant qu une supposition. Pour vous en convaincre, produisez le message ci dessous : <ns0:commande xmlns:ns0="urn:editionseni:gestioncommandes"> <NoeudVide/> </ns0:commande> Ce message n est pas conforme au schéma XSD, vous pouvez d ailleurs demander à Visual Studio de valider cette instance de message pour vous en assurer. Déposez ce message dans un répertoire écouté par un emplacement de réception associé au pipeline XMLReceive (par exemple, l emplacement de réception rcvgestioncommerciale_file). À votre grande surprise, vous constatez que le pipeline de réception XMLReceive considère que le message est de type urn:editionseni:gestioncommandes#commande alors qu il n est pas du tout conforme. b. Forcer la validation d un message Le comportement par défaut du pipeline XMLReceive (et également du pipeline XMLTransmit) est de ne vérifier que partiellement le message entrant comme nous venons de le prouver. Ce comportement, qui peut paraître étrange, est celui par défaut car :

191 Il est très performant : BizTalk n est pas contraint de vérifier le contenu de tout le message avant de considérer qu il est d un type particulier. Il est adapté à certains scénarios : parfois, vous souhaitez utiliser l EAI pour corriger un message qui n est pas encore correctement structuré. Votre partenaire vous transmet par exemple des commandes dans lesquelles certains champs obligatoires ne sont pas renseignés. Vous souhaitez dans ce cas utiliser BizTalk pour corriger le message et le rendre conforme. Bien que ce comportement soit celui par défaut, il est bien entendu tout à fait possible de configurer le pipeline (XMLReceive ou XMLTransmit) pour lui demander une validation stricte du message. Nous avons à notre disposition plusieurs solutions : Configurer le pipeline lorsqu il est utilisé dans un emplacement de réception (XMLReceive) ou un port d envoi (XMLTransmit). Créer un nouveau pipeline de réception ou d envoi XML. La seconde solution suppose de connaître l implémentation des pipelines, ce que nous évoquons au chapitre Les pipelines et les composants de pipelines. Nous allons illustrer la première solution en configurant l emplacement de réception rcvgestioncommerciale_file. Localisez l emplacement de réception rcvgestioncommerciale_file dans la console d administration BizTalk et ouvrez ses propriétés. Vérifiez que le pipeline XMLReceive est sélectionné et cliquez sur le bouton... situé à côté du pipeline. Comme vous pouvez le constater, et nous le détaillerons dans le chapitre consacré aux pipelines, le pipeline XMLReceive possède deux étapes. La première étape, appelée Disassemble contient un composant nommé XML disassembler. C est précisément ce composant qui effectue les opérations de vérification sur le message entrant. Afin de configurer la vérification du message, nous allons configurer ce composant pour lui indiquer ce qu il doit faire lors de la réception du message. Plusieurs paramètres sont à notre disposition, nous allons nous intéresser aux

192 paramètres suivants : DocumentSpecNames : cette propriété contient la liste des schémas avec lesquels le composant doit vérifier le message. En remplissant cette liste, nous indiquons au composant que tous les messages entrants doivent être conformes à l un des schémas de la liste. Si ce n est pas le cas, le message sera refusé, même s il est bien formé et conforme à un autre schéma. ValidateDocument : en positionnant cette propriété à True, nous demandons au composant de valider le message avec le schéma auquel il est censé correspondre. Si le message n est pas strictement conforme, il sera refusé et l instance de service sera suspendue. Pour renseigner la propriété DocumentSpecNames, vous devez connaître le nom complet du schéma. Le nom complet d un schéma se décompose comme suit : <nom.net du schéma>, <nom fort de l assembly>. Le nom.net de notre schéma Commande est : ENI.Schemas.Commande et le nom fort de notre assembly est ENI.Schemas, Version= , Culture=neutral, PublicKeyToken=bb71f210b1779e11. La valeur à spécifier dans la propriété DocumentSpecNames est donc : ENI.Schemas.Commande, ENI.Schemas, Version= , Culture=neutral, PublicKeyToken=bb71f210b1779e11 Pour connaître le nom.net de votre schéma et le nom fort de l assembly, localisez le schéma dans la liste des schémas de l application BizTalk et ouvrez ses propriétés. Vous obtenez l écran ci dessous : Attention, si vous avez utilisé votre propre fichier de clé lors de la compilation, le nom fort de votre assembly est certainement différent, notamment la chaîne qui suit la clé PublicKeyToken. Configurez donc le pipeline XMLReceive comme indiqué dans la copie d écran ci dessous (les valeurs modifiées apparaissent en gras) :

193 Déposez maintenant le message XML non conforme que nous avons utilisé précédemment. Vous obtenez l erreur ci dessous : Si vous souhaitez configurer plusieurs schémas dans la propriété DocumentSpecNames, séparez chaque nom de schéma par le caractère

194 5. Utilisation des schémas de fichiers plats L utilisation des schémas de fichiers plats dans BizTalk est très proche de l utilisation de schémas XML. La nuance réside dans le fait qu il n existe pas de pipeline générique et standard permettant l envoi ou la réception de fichiers plats comme les pipelines XMLReceive et XMLTransmit pour XML. Pour envoyer ou recevoir un fichier plat, il faut créer un pipeline et utiliser des composants livrés avec BizTalk. À ce stade de notre découverte de BizTalk, nous n avons pas encore évoqué la construction de pipelines et l utilisation de composants de pipelines. Il est donc prématuré d illustrer l utilisation de fichiers plats dans BizTalk. Reportez vous au chapitre Pipelines et composants de pipelines dans lequel le paragraphe Réceptionner des fichiers plats est consacré à l utilisation des fichiers plats

195 Contexte et propriétés promues 1. Rappels sur le contexte d un message Lorsque nous avons réalisé notre premier exemple de routage, nous avons évoqué le contexte des messages et son rôle fondamental dans l architecture de publication/souscription. Lorsque BizTalk publie un message dans la MessageBox, il associe à ce message un contexte qui est une collection de propriétés qualifiant le message. Ce contexte est ensuite utilisé pour rechercher un ou plusieurs abonnés. À partir du moment où nous réceptionnons des messages structurés, c est à dire associés à des schémas, le contexte est enrichi d informations sur le type de message (propriété BTS.MessageType et BTS.SchemaStrongName). L enrichissement de ces deux propriétés est effectué par le pipeline XMLReceive, plus précisément par le composant XML Disassembler situé à l étape de désassemblage du pipeline XMLReceive. 2. Modéliser le contexte d un message Pour l instant, nous avons utilisé des propriétés du contexte ajoutées par le moteur BizTalk afin de router nos messages : type de message et nom du port de réception par exemple. À aucun moment nous n avons nourri nous même le contexte pour ajouter de nouvelles propriétés. C est ce que nous allons illustrer dans ce paragraphe. L ajout d informations dans le contexte d un message est possible de plusieurs manières, nous allons nous attarder dans ce chapitre à l une des solutions nommée promotion de propriétés. La promotion de propriétés consiste à promouvoir des informations issues du corps du message dans le contexte du message. Ainsi, une information qui se trouve dans le corps d un message, par exemple le code client, se retrouvera également dans son contexte sous forme d une propriété promue. Étant donné que l information est dans le contexte, elle suit le message tout au long de sa vie dans BizTalk mais surtout cette information peut maintenant être utilisée pour router le message. Il est donc possible de router les commandes en fonction du code du client ou d autres informations contenues dans la commande elle même. Avant d être en mesure de nourrir le contexte d un message avec nos propres propriétés, il faut modéliser le contexte. Tout comme nous avons modélisé une commande, nous devons modéliser le contexte de nos messages, c est à dire déclarer les informations qui peuvent être présentes dans le contexte. La modélisation du contexte passe par la création d un schéma XSD d un type particulier, appelé schéma de propriété. a. Création d un schéma de propriété Afin que BizTalk connaisse les propriétés de contexte que nous ajoutons dans nos messages, nous devons créer un schéma de propriété (property schema en anglais). Un schéma de propriété est un schéma XSD particulier. Le but de ce schéma est de lister toutes les propriétés qui peuvent nourrir le contexte de nos messages. Le schéma contient autant d éléments que de propriétés pouvant potentiellement se trouver dans le contexte. Voici comment procéder pour créer un schéma de propriétés : Dans le projet ENI.Schemas, ajoutez un élément de type Schéma de propriétés et nommez le PropertySchema.xsd : Sélectionnez le nœud <Schema> du schéma de propriété, puis modifiez l espace de noms XML (propriété Target Namespace) en urn:editionseni:proprietes

196 L association d un espace de noms au schéma de propriété est primordiale. Cet espace de noms doit être cohérent par rapport au projet, au contexte métier et suffisamment lisible. Je vous conseille fortement de modifier l espace de noms par défaut avant de procéder à la suite des opérations. Le changement a posteriori de l espace de noms est toujours possible mais peut avoir un impact sur toute la solution BizTalk. Lors de la création du schéma de propriété, un élément nommé Property1 a été automatiquement créé. Il est inutile de garder dans ce schéma un élément que nous n utiliserons pas, nous devons donc le supprimer : Pour supprimer l élément Property1 du schéma de propriété, sélectionnez cet élément, ouvrez le menu contextuel et choisissez Supprimer. b. Créer des propriétés dans le schéma de propriétés Pour illustrer l ajout d informations dans le contexte d un message, nous allons utiliser l information CodeClient. Lorsqu une commande est réceptionnée, le contexte du message doit être nourri avec le code du client issu du corps du message et nous utiliserons cette information pour le routage du message. Pour ajouter l élément CodeClient dans le schéma de propriété, sélectionnez le nœud <Schema>, ouvrez le menu contextuel et sélectionnez l option Insérer un nœud de schéma puis Élément de champ enfant. Nommez cet élément CodeClient. Inutile dans notre cas de modifier le type de ce champ car il est par défaut de type xs:string ce qui nous convient très bien puisque nos codes clients sont des chaînes de caractères. Enregistrez le schéma de propriétés. Nous venons de créer le schéma de propriété. La propriété CodeClient, lorsqu elle sera ajoutée au contexte d un message aura pour nom CodeClient dans l espace de noms urn:editionseni:proprietes. c. Déclarer les propriétés promues dans le schéma du message

197 Nous devons désormais indiquer à BizTalk, que la propriété CodeClient du schéma Commande doit nourrir le contexte de chaque message. Nous devons donc lier le schéma d une commande et la liste des propriétés pouvant être promues représentée par le schéma de propriété. Ouvrez le schéma Commande, sélectionnez le champ CodeClient. Ouvrez le menu contextuel, sélectionnez l option Promouvoir et Promotion rapide. Le lien entre le schéma de propriété et le schéma Commande est créé automatiquement étant donné qu il n existe qu un seul schéma de propriété dans le projet ENI.Schemas. Enregistrez vos modifications dans le schéma Commande. La propriété CodeClient, qui est maintenant promue, dispose d une icône particulière, la différenciant ainsi des champs non promus : La liste de toutes les propriétés promues d un schéma est consultable en ouvrant le menu contextuel (sur n importe quel élément) puis en sélectionnant l option Promouvoir puis Afficher les promotions. L écran ci dessous liste toutes les propriétés promues :

198 3. Déployer un schéma de propriétés a. Déploiement d un schéma de propriétés Toutes les tâches de développement nécessaires à l ajout de la propriété CodeClient dans le contexte d un message de type Commande ont été effectuées. Nous devons déployer notre projet afin que ces éléments soient connus du moteur BizTalk. Le déploiement d un schéma de type Propriété est identique au déploiement d un schéma de type Document. Il faut générer l assembly.net correspondante et déployer cette assembly au sein du groupe BizTalk. Référez vous à la section Déploiement de schémas dans le présent chapitre pour connaître la procédure à suivre. N oubliez pas de mettre à jour le GAC de votre machine avec la nouvelle version de l assembly. Selon la méthode de déploiement choisie, cette mise à jour a été effectuée automatiquement ou non. b. Vérifier le déploiement du schéma de propriétés Lorsque l assembly ENI.Schemas.dll a été déployée, deux éléments ont été modifiés : Le schéma de propriété ENI.Schemas.PropertySchema a été déployé. Le schéma Commande a été de nouveau déployé pour refléter nos derniers changements. Si vous naviguez dans la liste des schémas de l application EditionsENI, vous pouvez vous rendre compte que le schéma de propriété a été déployé :

199 c. Redémarrer les services BizTalk Étant donné que nous n avons pas modifié son numéro de version, l assembly ENI.Schemas porte toujours le même nom fort. Lors de son déploiement, l assembly a été remplacée dans la base de configuration BizTalk et dans le GAC. Pour le service BizTalk qui exécute les ports d envoi et de réception, il s agit donc de la même assembly. Si depuis vos précédents tests, le service BizTalk n a pas été redémarré, il y a de fortes chances qu il dispose déjà en mémoire de l assembly portant ce nom fort. Aucun événement n indique à cet exécutable que l assembly a été modifiée et, pour des raisons de performances, il ne rechargera pas l assembly depuis le GAC. Il est primordial de le forcer à recharger cette assembly en mémoire afin qu il dispose de la dernière version issue du GAC. La manière la plus simple et la plus efficace est de redémarrer l instance BizTalk, c est à dire le service Windows. Plusieurs alternatives sont à votre disposition pour redémarrer l instance BizTalk : Redémarrer l instance de l hôte depuis la console d administration comme l indique la copie d écran cidessous : Redémarrer le service BizTalk depuis la console d administration des services Windows : Redémarrer le service depuis une ligne de commande : net stop "Service BizTalk BizTalk Group : BizTalkServerApplication"

200 net start "Service BizTalk BizTalk Group : BizTalkServerApplication" Cette dernière solution est très utile lorsque vous souhaitez scripter le redémarrage d une instance BizTalk ou redémarrer plusieurs instances en même temps. Windows PowerShell est une alternative pour automatiser ce type d actions, nous l étudions dans le chapitre Administration et exploitation de BizTalk Server. 4. Utiliser le schéma de propriété et le contexte a. Tester la création d une propriété promue Pour illustrer l utilisation de notre propriété promue CodeClient, nous devons réceptionner un message de type Commande via un pipeline XMLReceive. Lors de nos précédents tests, nous avons configuré l emplacement de réception rcvgestioncommerciale_file correctement. Si vous n avez pas effectué de changements, nous pouvons donc l utiliser : Avant de réceptionner une commande, stoppez le port d envoi sndcomptabilite_file afin que nous ayons le temps de visualiser le message et son contexte dans la MessageBox. Déposez un fichier XML de type Commande dans le répertoire d écoute. Dans la console d administration BizTalk, après quelques secondes d attente, une instance du port d envoi sndcomptabilite_file va être suspendue (car le port est arrêté) : Ouvrez le menu contextuel sur l instance suspendue, rendez vous dans l onglet Message puis ouvrez le détail du message. Dans l onglet Contexte, visualisez le code client comme l illustre la copie d écran ci dessous : Il existe maintenant dans le contexte du message une propriété nommée CodeClient de l espace de noms urn:editionseni:propertietes et contenant la valeur CodeClient_0 qui est la valeur du code client dans le message XML

201 b. Les étapes de la promotion d une propriété Afin de promouvoir la propriété dans le contexte du message, voici comment BizTalk a procédé : Le message réceptionné est tout d abord associé à un schéma XSD. Ceci grâce à l utilisation du composant XML Désassembleur dans le pipeline de réception (dans notre cas grâce au pipeline de réception XMLReceive qui contient ce composant). Étant donné que le message est associé au schéma Commande, BizTalk lit ce schéma et détecte qu une propriété doit être promue. Le schéma XSD contient en effet des informations sur les propriétés promues comme l illustre l extrait du schéma Commande représenté ci dessous : Dans cet extrait de code XSD, une annotation est présente car a été ajoutée par Visual Studio dans le schéma. Cette annotation contient une référence à la propriété ns1:codeclient. ns1 est le préfixe qui qualifie l espace de noms urn:editionseni:proprietes, c est à dire notre schéma de propriété. Le schéma indique à BizTalk de créer une propriété promue nommée CodeClient dans l espace de noms urn:editionseni:proprietes. Pour associer une valeur à la propriété promue, une requête xpath est précisée au niveau de la propriété promue. Cette requête indique à BizTalk l endroit où se trouve l information qu il doit associer à la propriété ns1:codeclient. En l occurrence, il s agit de l emplacement du code client dans le schéma Commande. La requête xpath correspond au chemin hiérarchique à parcourir pour atteindre le code client dans un message de type Commande. Avec ces deux informations, BizTalk localise dans le message la valeur du code client puis ajoute la propriété dans le contexte. Si aucun code client n est présent dans le message, aucune propriété n est créée. Il n y a pas d erreur générée lors de la réception dans ce cas. Ce comportement permet de nourrir le contexte avec de multiples informations sans pour autant que tous les champs correspondants soient obligatoires dans les messages. c. Router les messages en fonction d une propriété promue Nous savons maintenant que le code client fait partie du contexte des messages de type Commande. Nous allons utiliser cette information pour router nos messages. Nous allons modifier le port d envoi sndcomptabilite_file pour modifier son filtre. Le port est actuellement abonné aux messages de type Commande (rappel du filtre : BTS.MessageType = urn:editionseni:gestioncommandes#commande). Nous souhaitons envoyer à l application de comptabilité uniquement les commandes du client CodeClient_0. Modifions donc le filtre en conséquence : Ouvrez les propriétés du port d envoi sndcomptabilite_file puis naviguez dans l onglet Filtre. Modifiez le filtre en ajoutant le code client comme indiqué dans la copie d écran ci dessous :

202 Une nouvelle propriété est disponible dans la liste déroulante, il s agit de la propriété ENI.Schemas.CodeClient. Vous mesurez maintenant l importance de nommer correctement vos schémas de propriétés afin que vos propriétés contextuelles soient facilement reconnaissables. Vous pouvez tester le fonctionnement. Si vous réceptionnez une commande qui n est pas associée au client CodeClient_0, cette commande sera certainement en erreur de routage car aucun abonné n attend ce message. 5. Les contraintes des propriétés promues dans les schémas XSD En dehors du fait qu un trop grand nombre de propriétés promues peut nuire à la performance globale du système, il existe plusieurs contraintes lors de l utilisation de ces propriétés : La valeur d une propriété promue ne peut pas contenir plus de 256 caractères. Vous ne pouvez pas promouvoir, depuis un schéma XSD, une valeur multi valuée. Supposez par exemple, que vous souhaitez promouvoir le code d un produit commandé, étant donné qu il peut y avoir plusieurs produits dans une commande vous ne pourrez pas le faire. Vous ne pouvez pas utiliser de requêtes Xpath complexes pour promouvoir une propriété. Une requête Xpath complexe est une requête dans laquelle se trouve par exemple un index. Supposez que vous vouliez promouvoir le code du premier produit commandé. Dans ce cas, vous devez utiliser une requête Xpath qui serait sous la forme suivante /Commande/Produits/Produit[0]/CodeProduit. Ce type de requête Xpath n est pas autorisé. 6. Propriétés promues et non promues La méthode que nous venons d illustrer permet d ajouter des propriétés dans le contexte, ces propriétés sont forcément promues. Le contexte d un message contient des propriétés promues et d autres non promues. Seules les propriétés promues

203 sont utilisées pour la recherche d abonnés. Vous devez certainement vous interroger sur l utilité des propriétés non promues étant donné qu elles ne servent pas au processus de routage. a. Données de travail Les propriétés non promues permettent de qualifier un message, avec des informations supplémentaires, techniques ou non, sans pour autant dénaturer le message lui même. Vous pouvez véhiculer des informations techniques, sur l étape en cours d un processus, sur le statut d un message, sans pour autant devoir modéliser ces informations dans le schéma du message lui même. Ces informations de travail n ont en effet pas à être modélisées dans le message et doivent disparaître lorsque le message quitte l EAI. C est exactement l objectif du contexte d un message. Si vous n utilisez pas ces informations pour router le message, vous n avez pas à les promouvoir, vous devez simplement les ajouter au contexte. b. Promouvoir et dé promouvoir En visualisant le contexte des messages réceptionnés ou envoyés par BizTalk, vous remarquerez que de nombreuses propriétés sont non promues. C est un choix effectué par les concepteurs du produit afin de ne pas pénaliser les performances. Par exemple, le nom d un emplacement de réception n est pas promu bien que présent dans le contexte (propriété BTS.ReceiveLocationName). Par défaut, vous ne pouvez donc pas router un message en vous basant sur cette propriété, mais vous pouvez utiliser la propriété promue BTS.ReceivePortName qui contient quant à elle le nom du port de réception. Nous verrons dans le chapitre Les pipelines et composants de pipelines qu une propriété non promue par défaut peut devenir promue et par ainsi le comportement par défaut de BizTalk peut être modifié. Dans des scénarios de routage complexes, vous serez amené à changer la promotion d une propriété à certaines étapes du processus, afin qu elle ne soit plus promue. Avec cette souplesse, vous pourrez décider du chemin suivi par le message dynamiquement en fonction de votre processus. Je vous conseille de limiter les propriétés promues à vos seuls besoins de routage. Si vous créez trop de propriétés promues, les performances globales du système seront impactées. c. Accès simplifié à des informations du contenu d un message Dans notre exemple, nous avons ajouté le code client dans le contexte du message. BizTalk a recherché pour nous le code client dans le corps du message et l a rendu disponible dans le contexte. Nous le verrons dans le chapitre Implémentation des processus métier, l accès à des informations du corps d un message est très souvent nécessaire dans un processus métier. L utilisation du contexte d un message facilite l accès à ces informations car évite l implémentation de requêtes xpath permettant la recherche des données. BizTalk effectue pour vous la recherche de l information et la rend disponible dans le contexte. L accès au contexte d un message est ensuite très simple depuis un processus métier. Je vous conseille d utiliser le contexte afin d accéder facilement à des informations du corps du message depuis un processus métier. Préférez cependant l usage des champs distinctifs. Les champs distinctifs sont une alternative aux propriétés promues car ils permettent de nourrir le contexte d un message avec des informations issues de son corps sans impacter le processus de routage. Nous abordons ce sujet dans le chapitre Implémentation de processus métier. 7. Utilisation des propriétés promues avec les fichiers plats Étant donné que les fichiers plats sont traités par BizTalk comme des messages XML, et étant donné qu ils sont modélisés selon les mêmes méthodes, les fichiers plats peuvent tout à fait contenir des propriétés promues avec un fonctionnement identique aux messages XML. Pour définir une propriété promue dans un fichier plat, vous procédez de la même manière que dans un schéma XSD classique

204 Configuration pour le suivi des schémas 1. Rappels sur le suivi post exécution Dans le chapitre Suivi de l activité et gestion des erreurs, nous avons illustré dans plusieurs situations, l utilisation des outils de suivi BizTalk. Nous avons notamment illustré le suivi de l activité et le suivi post exécution. Le suivi post exécution permet de suivre, après leurs exécutions, les messages et services qui ont participé à un échange ou un processus métier. 2. Paramétrage du suivi post exécution pour les ports Toujours dans le chapitre Suivi de l activité et gestion des erreurs, nous avons illustré comment le suivi post exécution pouvait être paramétré. Pour rappel, nous pouvons configurer chaque port (réception ou envoi) pour qu il préserve le corps des messages après leurs exécutions et également le contexte de ces messages. Nous pouvons également choisir si ces deux éléments (corps et contexte) doivent être préservés avant ou après leur traitement par le pipeline. 3. Suivi du contexte et du corps Si nous souhaitons préserver le corps et le contexte d un message avant son traitement par le port sndcomptabilite_file voici comment nous devons procéder : Dans les propriétés du port sndcomptabilite_file, onglet Suivi, cochez les cases indiquées dans la copie d écran suivante. En effectuant ce paramétrage, nous demandons à BizTalk de mémoriser le corps et tout le contexte des messages qui sont traités par le port d envoi. Le contexte et le corps sont photographiés avant le traitement par le port, c est à

205 dire juste avant que le pipeline d envoi n effectue le traitement. 4. Rendre disponible une donnée du contexte dans la recherche d un message Grâce au paramétrage effectué sur le port d envoi, BizTalk mémorise le contexte des messages traités par ce port. Vous pouvez le vérifier en utilisant la requête Événements des messages suivis pour visualiser le contexte d un message. Si vous souhaitez cependant rechercher toutes les commandes reçues d un client en particulier, vous devez paramétrer votre schéma de propriétés pour qu il rende le code client utilisable dans les recherches de messages. Voici comment procéder : Dans l application EditionsENI, localisez le schéma de propriété PropertySchema et ouvrez ses propriétés. Dans l onglet Suivi, sélectionnez CodeClient comme propriété à suivre : Pour tester ce changement, effectuez de nouveau un traitement en réceptionnant une commande. Attendez quelques instants avant de faire la recherche du message car selon la performance de votre machine et la planification des tâches SQL Server de suivi, la mise à disposition des informations dans le suivi post exécution peut être plus ou moins longue. Ouvrez une requête de type Événements des messages suivi. Dans le critère Nom du schéma, sélectionnez le schéma urn:editionseni:gestioncommandes#commande. Après sélection de ce schéma, le champ CodeClient devient disponible dans la liste des critères utilisables pour la recherche

206 Sélectionnez le champ CodeClient et saisissez la valeur CodeClient_0 afin de ne visualiser que les messages de type Commande du client CodeClient_0 comme l indique la copie d écran ci dessous : Vous constatez dans la copie d écran ci dessus que, grâce au paramétrage, nous pouvons aisément chercher une commande avec un code client particulier. Vous pouvez d ailleurs remarquer: Que nous trouvons avec cette requête à la fois les messages traités par le port d envoi sndcomptabilité_file mais aussi par le port de réception rcvgestioncommerciale. Qu une colonne nommée CodeClient a été ajoutée dans les résultats de requête. Elle contient la valeur de la propriété promue CodeClient. Vous pouvez suivre toutes les propriétés d un schéma de propriété si vous le souhaitez, sachez simplement que cela aura un impact sur le volume de la base de données BizTalkDTADb qui héberge toutes ces informations

207 Conclusion Nous avons terminé avec la modélisation et l utilisation des schémas. Nous terminerons d évoquer les schémas dans le chapitre Pipelines et composants de pipelines afin de comprendre comment les fichiers plats sont réceptionnés et envoyés par BizTalk. Dans le chapitre suivant, nous allons mettre en place des mécanismes de suivi fonctionnel de nos messages. Nous avons pour l instant utilisé les outils techniques pour comprendre le cheminement des messages, nous allons désormais offrir à nos utilisateurs des outils fonctionnels grâce au BAM

208 Fournir de la visibilité fonctionnelle 1. Le rôle de la console d administration Dans les précédents chapitres, nous avons utilisé la console d administration BizTalk pour suivre l activité de notre système. Cette console nous permet de suivre l activité en temps réel ainsi que l historique de l activité, ce que nous avons appelé le suivi post exécution. La console est très complète et adaptée aux administrateurs et exploitants informatiques. Elle a été pensée pour un public technique et n est pas dédiée au suivi de l activité. En effet, elle permet également de configurer et administrer le serveur et les applications BizTalk. Si un utilisateur final (acheteur, assistante commerciale...) souhaite connaître l avancement d un processus ou l historique d exécution de ce processus, il est difficile de lui donner accès à la console d administration car l outil n est pas adapté à cette population. 2. Les besoins des utilisateurs a. Suivre les processus et les données Les utilisateurs finaux, qui ne sont pas la plupart du temps des informaticiens, ont besoin de visibilité sur les processus métier et les échanges réalisés au sein de leur Système d Information. Ils souhaitent des réponses à des questions comme : À quelle étape se trouve la commande nº 12 que je viens de saisir dans mon logiciel de gestion commerciale? Depuis combien de temps avons nous demandé au fournisseur de nous approvisionner en produits? Toutes ces questions fonctionnelles sont primordiales pour le métier de chaque utilisateur et lui permettent d anticiper sur son organisation, de prendre des décisions et de mener des actions préventives ou correctives. Si l utilisateur se rend compte que le délai d expédition de la commande de son client ne sera pas respecté, il peut le prévenir et peut être lui proposer d aménager la commande en plusieurs lots pour livrer les produits urgents. Si vous ne fournissez pas d outils aux utilisateurs pour qu ils puissent trouver des réponses à leurs questions, ils vont solliciter vos équipes informatiques. C est un temps précieux qui sera consommé par vos équipes informatiques et qui se traduira certainement par des retards sur les projets. b. Les besoins en statistiques Outre les besoins en terme de visibilité que nous venons d évoquer, il est très souvent nécessaire de produire des statistiques. Ces statistiques, qui ne sont souvent pas définies en début de projet, se révèlent primordiales après quelques jours ou semaines d activité. Les statistiques donnent elles aussi une visibilité sur les processus. Avec des métriques et dimensions d analyses bien pensées, le chef de projet informatique peut communiquer sur son projet, démontrer l intérêt des solutions mises en œuvre, éventuellement même prouver les gains pour l entreprise depuis la mise en place de la solution. Ces statistiques sont également importantes pour les utilisateurs finaux qui peuvent ainsi disposer à tout moment d indicateurs métiers. Ces indicateurs peuvent être par exemple le nombre de commandes traitées par jour, le chiffre d affaires hebdomadaire par région du monde ou par gamme de produits Comment répondre aux attentes des utilisateurs? Ces besoins des utilisateurs doivent impérativement être pris en compte dès le début du projet BizTalk. C est pour cette raison que cet ouvrage traite du suivi fonctionnel très tôt dans le parcours d apprentissage. Pour répondre aux besoins des utilisateurs, trois étapes sont nécessaires : Définir les besoins des utilisateurs : quelles données doivent être restituées, comment ses données doivent être organisées

209 Collecter les données souhaitées : collecter les informations souhaitées tout au long des processus ou échanges réalisés. Restituer les données aux utilisateurs : proposer aux utilisateurs les moyens d accéder aux informations, peut être de différentes manières selon leurs besoins. Ces trois étapes sont couvertes par les services et outils BizTalk et sont regroupées sous l intitulé BAM (Business Activity Monitoring, littéralement, suivi de l activité métier). Le BAM dans BizTalk facilite la mise en œuvre de ces trois étapes et offre les outils nécessaires à leur implémentation. Nous allons traiter dans ce chapitre comment, progressivement, il est possible de donner de la visibilité sur les processus aux utilisateurs

210 Notions fondamentales du BAM Avant d illustrer le BAM par un exemple concret, nous devons nous attarder sur ses notions fondamentales. 1. La définition BAM La première étape dans la mise en œuvre du suivi fonctionnel BizTalk consiste à définir les données dont les utilisateurs souhaitent disposer. Il faut donc créer une définition BAM. Le schéma ci dessous illustre ce qu est une définition BAM : Une définition BAM contient : une ou plusieurs activités BAM ; une ou plusieurs vues BAM. a. Les activités BAM Une activité BAM est une collection d indicateurs définissant un processus métier. Par exemple, l activité BAM nommée Gestion des commandes représente le processus de gestion de commandes et contient tous les indicateurs relatifs à ce processus. Un même processus métier nécessite parfois la définition de plusieurs activités liées entre elles. Ces activités représentent des sous processus qui s enchaînent pour constituer le processus global. La prise de commande ou l approvisionnement sont des exemples de sous processus, chacun pouvant faire l objet d une activité BAM particulière. Une définition BAM se compose d indicateurs. Ces indicateurs sont : des données du processus : code du client, numéro de commande, montant de la commande... des étapes du processus : prise de commande, expédition, facturation... b. Les vues BAM Une vue BAM est une représentation d une ou de plusieurs activités BAM. Tous les utilisateurs qui participent à un processus métier n ont pas la même vision de ce processus, les mêmes besoins ni les mêmes autorisations sur les données. La vue BAM permet d adapter la vision du processus selon les souhaits ou habitudes de l utilisateur. Une vue BAM permet : de masquer des indicateurs. Des indicateurs sensibles peuvent ainsi être masqués à certains utilisateurs. Le taux de remise commerciale accordée à un client par la force de vente n est, par exemple, pas visible du responsable de l atelier

211 de renommer des indicateurs. Dans les différents départements de l entreprise, le vocabulaire utilisé pour qualifier la même information est parfois différent. Il est ainsi possible de renommer des indicateurs. de calculer des durées entre des étapes. Une vue BAM peut contenir des calculs de durée entre deux étapes d un processus. La durée ainsi calculée est elle même un indicateur sur lequel des statistiques peuvent être produites. de synthétiser un processus. L activité BAM qui représente un processus peut contenir de nombreuses étapes. Une visibilité très fine sur le processus est nécessaire pour certains utilisateurs mais pour d autres, une vision synthétique se limitant à quelques étapes clés est suffisante. La vue BAM permet de regrouper plusieurs étapes dans une étape macroscopique. de produire des métriques. Les métriques sont des mesures sur des indicateurs (nombre de commandes, somme des quantités commandées, somme des montants...). Ces mesures sont effectuées par rapport à des dimensions d analyses qui sont définies elles aussi dans la vue BAM. Il est ainsi possible de calculer le nombre de commandes par jour, par région ou par gamme de produit. Étant donné qu une vue BAM est destinée à une population d utilisateurs, il est très fréquent de définir plusieurs vues pour un même processus. 2. Les profils de suivi BAM La seconde étape dans la mise en œuvre du BAM consiste à définir la manière dont les indicateurs sont nourris par BizTalk. La définition BAM décrit les indicateurs à collecter (c est l activité BAM) et comment les présenter aux utilisateurs finaux (c est la vue BAM). BizTalk doit savoir comment collecter les informations de l activité BAM. Pour lui indiquer comment procéder, il faut définir un suivi de profil BAM (appelé communément Tracking Profile). Un suivi de profil BAM contient des informations permettant à BizTalk de savoir : Où il doit récupérer les informations : dans quels messages? Dans quels champs, dans quelles propriétés de contexte? Quand il doit récupérer les informations : à quelle étape du processus? Lors de l envoi ou lors de la réception du message? Grâce au suivi de profil BAM, BizTalk collecte les informations et les stocke dans les indicateurs. Le suivi de profil BAM n est pas intrusif dans les processus. Si vous décidez de collecter de nouveaux indicateurs, vous pouvez modifier le suivi de profil (et peut être même l activité BAM) mais vous n avez pas de nouveaux développements à réaliser ni de nouveaux déploiements d assemblies BizTalk. A contrario, il est possible d utiliser une API BAM fournie par BizTalk afin de collecter des indicateurs. Avec cette API, vous pouvez nourrir les indicateurs d une activité BAM par du code. Les appels à cette API font partie du code de votre solution BizTalk et en cas de changement du BAM (suppression d un indicateur inutilisé par exemple), vous serez contraint de déployer de nouveau votre solution BizTalk. Dans ce chapitre, nous illustrons l utilisation du suivi de profil BAM pour collecter les indicateurs. L utilisation de l API BAM sera traitée dans le chapitre BAM Avancé. 3. Les outils de restitution du BAM La troisième étape dans une démarche BAM BizTalk est de fournir les outils aux utilisateurs afin qu ils consultent les indicateurs BAM. Il y a de nombreuses alternatives pour restituer les indicateurs aux utilisateurs, parmi elles en voici plusieurs : Le portail BAM : le portail BAM est un site Web, livré avec BizTalk Server, qui permet de naviguer parmi les vues et activités BAM. Microsoft Excel : Excel constitue une alternative très intéressante pour restituer les indicateurs BAM et ce, pour différentes raisons. Les deux raisons principales sont : Les utilisateurs concernés par le BAM disposent quasiment tous d Excel installé sur leur poste de travail et sont familiers de cet outil

212 Excel est déjà utilisé dans la mise en œuvre du BAM. En effet, la définition BAM (activité et vue BAM) est créée et gérée dans Excel. SQL Server : les données du BAM sont stockées dans une base de données SQL Server (ou SQL Server Analysis Services pour les métriques). Les outils de restitution de SQL Server sont donc tout à fait adaptés, notamment SQL Server Reporting Services. Développements ad hoc : les données du BAM sont facilement accessibles depuis des applications développées spécifiquement. Il est donc envisageable de créer ses propres applications de restitution des données BAM. Tout outil en mesure d être connecté à une base de données SQL Server peut être utilisé pour restituer les données du BAM. Pour restituer les agrégations de données, que nous abordons dans le chapitre BAM Avancé, l outil doit être en mesure de se connecter à SQL Server Analysis Services. Dans ce chapitre, nous illustrons l utilisation de SQL Server ainsi que le portail BAM pour restituer des indicateurs. Dans le chapitre BAM avancé, vous découvrirez comment Excel peut être utilisé pour la visualisation du BAM

213 Mise en œuvre du BAM 1. Les étapes de mise en oeuvre Le schéma ci dessous décrit les 3 étapes que nous allons illustrer dans la suite du paragraphe : 2. Le cas métier utilisé pour illustrer le BAM Pour illustrer la mise en œuvre du BAM, nous allons repartir de notre solution d échange de commandes entre l application de Gestion Commerciale et l application de Comptabilité. Cet exemple se prête bien à l illustration car il est relativement simple et va donc vous permettre de comprendre facilement la mise en œuvre du BAM dans BizTalk. Nous allons définir une activité de gestion de commandes dans laquelle nous allons collecter les indicateurs suivants : Le code du client Le numéro de commande L étape de réception de la commande L étape d envoi à la comptabilité Nous allons également créer deux vues de cette activité de gestion de commandes : Une vue nommée Force de vente dédiée aux commerciaux et assistantes commerciales. Une vue nommée Informatique dédiée à l équipe projet. Dans ce chapitre, étant donné que nous débutons avec le BAM, les deux vues sont très similaires. Vous ne mesurerez peut être pas l intérêt d en avoir créées deux mais nous les réutiliserons dans le chapitre BAM avancé afin d ajouter des axes d analyses et des mesures adaptées aux deux populations d utilisateurs

214 Création et déploiement de la définition BAM 1. Utilisation du complément BAM Excel Nous allons définir dans ce paragraphe l activité BAM ainsi que les deux vues BAM. La création d une définition BAM est effectuée dans Microsoft Excel. Un complément Excel est installé avec les outils de développement BizTalk. Ce complément contient des macros vous permettant de définir, via des assistants, les activités et vues BAM. a. Installation du complément BAM dans Excel Le complément Excel du BAM est le fichier Bam.xla situé dans le sous répertoire ExcelDir du répertoire d installation de BizTalk Server. Si ce répertoire n existe pas sur votre machine, vous devez installer les outils de développement de BizTalk. Afin d installer et d enregistrer le complément BAM dans Excel, reportez vous à la documentation d installation de BizTalk Server Lorsque le complément BAM est utilisé dans Excel, un seul classeur ne peut être ouvert à la fois. Cette contrainte est assez gênante pour un utilisateur qui se sert d Excel à d autres fins. b. Intérêts d Excel L utilisation de Microsoft Excel pour définir le BAM permet théoriquement d impliquer les utilisateurs finaux dans la définition des indicateurs. Excel constitue un bon support pour que les utilisateurs vous fassent part de leurs besoins. Vous pouvez également utiliser Excel pour leur demander de valider votre compréhension de leurs attentes. Si nous poussons la réflexion plus loin, il est aussi envisageable que les utilisateurs définissent eux mêmes leurs besoins dans Excel et vous livre le classeur Excel. Ils restent donc maîtres de leurs attentes et l équipe informatique se contente de déployer cette définition BAM dans BizTalk. Cette implication forte des utilisateurs peut fonctionner si : Des utilisateurs clés sont identifiés au sein des populations concernées par le suivi fonctionnel. Les utilisateurs sont un minimum formés à l utilisation du complément BAM de BizTalk. Dans la réalité des projets que je rencontre, c est l équipe informatique qui définit le BAM et le fait valider ensuite aux utilisateurs. 2. Création du fichier de définition BAM Pour créer notre définition BAM, double cliquez sur le fichier Bam.xla ou créez un nouveau classeur vierge et activez le complément BAM. Les démonstrations et copies d écran sont effectuées avec Excel Cependant, le complément BAM fonctionne également avec Excel 2003, les écrans, menus et manipulations sont cependant un peu différents. Avant toute chose, vous devez accepter l exécution des macros. Pour cela, cliquez sur le bouton Activer les macros dans la fenêtre d avertissement Excel. Dans Excel, vous pouvez remarquer que le bandeau (le ribbon) contient un nouvel onglet nommé Complément. Dans cet onglet se trouvent deux éléments relatifs au BAM et notamment un menu nommé BAM. C est avec ce menu que vous pourrez réaliser toutes les opérations de définition que nous allons mener

215 Enregistrez le classeur Excel dans un fichier que vous nommez GestionCommandes.xlsx. 3. Définition d une activité BAM Afin de créer l activité BAM Gestion des commandes, procédez comme suit. Dans l onglet Complément, ouvrez le menu BAM et sélectionnez l option Activité BAM. Cliquez ensuite sur le bouton Nouvelle activité. Nommez l activité Gestion des commandes. Nous allons maintenant ajouter dans l activité Gestion des commandes, les différents indicateurs. Cliquez sur Nouvel élément. Dans Nom de l élément, saisissez CodeClient. Dans Type d élément, sélectionnez Données de l entreprise Texte. Dans Longueur maximale, saisissez 10. Répétez la même manipulation pour créer l indicateur NumeroCommande. Cet indicateur est de type Données de

216 l entreprise Texte, de longueur maximale 20. Nous allons maintenant créer les indicateurs qui correspondent aux étapes de notre processus : Créez un nouvel indicateur que vous nommez CommandeRecue. Dans Type d élément, sélectionnez Étapes majeures commerciales. Créez ensuite un indicateur nommé CommandeEnvoyee de type Étapes majeures commerciales. Lorsque vous avez créé tous les indicateurs de l activité, cliquez sur le bouton OK afin d enregistrer l activité. L activité est maintenant créée et enregistrée. Au moins une vue BAM associée à cette activité doit exister. Pour créer une vue BAM, cliquez sur le bouton OK. 4. Définition d une vue BAM La création d une vue BAM est lancée automatiquement après la création d une activité : Dans le premier écran de l assistant de création de vue BAM, cliquez sur le bouton Suivant. Choisissez l option Créer une vue et cliquez sur le bouton Suivant

217 a. Création de la vue BAM Informatique Nous allons créer la première vue BAM nommée Informatique dédiée à l équipe projet. Cette vue contient tous les indicateurs pour le suivi du processus de gestion de commandes : Dans Nom de la vue, saisissez Informatique. Sélectionnez ensuite l activité Gestion des commandes et cliquez sur Suivant. Dans l écran suivant, vous devez indiquer quels sont les indicateurs présents dans la vue BAM. Si vous souhaitez masquer des informations confidentielles, il suffit de ne pas sélectionner l indicateur. Pour la vue Informatique nous choisissons d afficher toutes les informations : donc vous cochez la case Sélectionner tous les éléments et cliquez sur Suivant

218 Dans l écran suivant, l assistant vous permet : de renommer un champ ou de créer un alias pour un champ ; de calculer une durée entre deux étapes ; de regrouper plusieurs étapes en une seule. Nous allons renommer, l indicateur CodeClient en Code du client et l indicateur NumeroCommande en Numero de commande : Sélectionnez l indicateur CodeClient, cliquez sur le bouton Modifier et indiquez comment renommer le champ :

219 Réitérez cette étape pour renommer l indicateur NumeroCommande en Numero de commande. Nous allons maintenant calculer la durée totale du processus. Cette durée se calcule entre l étape CommandeRecue et CommandeEnvoyee : Cliquez sur le bouton Nouvelle durée. Dans le champ Nom de la durée, saisissez Duree totale. Dans la liste déroulante Démarrer étape majeure commerciale, sélectionnez l étape CommandeRecue. Dans la liste déroulante Terminer étape majeure commerciale, sélectionnez l étape CommandeEnvoyee. Enfin, dans la liste déroulante Résolution temporelle, sélectionnez Seconde. Nous avons choisi de calculer la durée en secondes car notre processus est très simple, la commande provenant de la gestion commerciale étant directement routée à la comptabilité. Le choix d une résolution temporelle adéquate évite de devoir faire des conversions de durée lors de la restitution de l information à l utilisateur final. Lorsque ces manipulations ont été effectuées, cliquez sur Suivant. Dans ce chapitre, nous n allons pas évoquer les agrégations donc cliquez également sur le bouton Suivant dans l écran Dimensions et mesures de l agrégation

220 Dans l écran récapitulatif, cliquez sur Suivant. Cliquez sur Terminer pour quitter l assistant création de vue BAM. La vue Informatique a été créée correctement. b. Création de la vue BAM Force de vente Nous allons maintenant créer la vue Force de vente destinée aux commerciaux de l entreprise. Dans le processus de l entreprise, le commercial rend visite au client et négocie avec lui une vente de produit. Le client doit ensuite passer commande en envoyant un fax au service prise de commande. Il précise sur le fax un numéro de commande correspondant au numéro de devis établi par le commercial. Les commerciaux souhaitent savoir à tout moment si un devis établi pour un client a été transformé en commande. Ils souhaitent, en saisissant le numéro de devis, savoir quand la commande a été passée par le client. Si la commande n a pas encore été passée par le client, ils peuvent ainsi le relancer et débloquer la situation. La seule étape du processus qui intéresse le commercial est l étape CommandeRecue. Le reste du processus n a pas d importance pour le commercial, il n est donc pas utile de le tenir informé. Nous allons créer la vue Force de vente pour répondre aux attentes des commerciaux de l entreprise. Dans le chapitre BAM avancé, nous modifierons cette vue pour fournir aux commerciaux des métriques sur leur activité. Dans le menu BAM du complément, sélectionnez l option Vue BAM. Progressez dans l assistant et dans l écran Création de vue BAM, sélectionnez Créer une vue. Nommez la vue Force de vente et sélectionnez toutes les activités. Les commerciaux ne sont pas intéressés, à ce jour, par l étape CommandeEnvoyee. Il n est donc pas utile de rendre disponible cette information. Sélectionnez les autres indicateurs sauf l étape CommandeEnvoyee. Afin que les commerciaux comprennent les indicateurs restitués par la vue, nous allons renommer les indicateurs comme suit : Renommez l indicateur CodeClient en Code du client. Renommez l indicateur CommandeRecue en Prise de commande effectuée. Renommez l indicateur NumeroCommande en Numéro de devis. Cliquez sur Suivant et terminez la création de la vue Force de vente. Pour chaque vue BAM, un nouvel onglet est créé dans le classeur Excel. Les informations affichées dans chaque onglet concernent une vue BAM. Une vue peut être modifiée à tout moment à partir du menu Vue BAM du complément Excel. La définition BAM est disponible en téléchargement. Il s agit du fichier Chapitre8_GestionCommandes.xslx. 5. Déploiement de la définition BAM a. Actions réalisées lors du déploiement d une définition BAM Tous les indicateurs sont maintenant définis ainsi que la manière dont les utilisateurs pourront les visualiser. Cette définition BAM doit être déployée au niveau du groupe BizTalk

221 Le but du déploiement de la définition BAM est la création des structures de stockage nécessaires aux indicateurs. Lorsqu une définition BAM est déployée, l outil de déploiement se charge de créer des objets SQL Server dans la base de données BAMPrimaryImport. Cette base de données héberge toutes les données du BAM du groupe BizTalk. b. Déploiement de la définition BAM Le déploiement de la définition BAM est effectué avec l outil en ligne de commande bm.exe. Cet utilitaire est l outil de déploiement et d administration du BAM. Le classeur Excel qui contient la définition BAM doit être exporté sous forme d un fichier XML qui sera utilisé pour le déploiement : Pour exporter la définition BAM, sélectionnez l option Exporter du menu BAM. Toutes les opérations que nous venons d effectuer ne nécessitent pas la présence de BizTalk Server sur le poste de travail. Le déploiement, cependant, suppose de disposer d un certain nombre de composants serveurs. Le fichier que nous venons d exporter doit, si votre serveur BizTalk n est pas la machine sur laquelle la définition a été créée, être copié sur le serveur. Ouvrez une fenêtre en ligne de commande et naviguez dans le répertoire d installation de BizTalk, sous répertoire Tracking. Lancez l utilitaire bm.exe en tapant la ligne de commande suivante : bm.exe Deploy-All - DefinitionFile:c:\ENIEditions\bam\GestionCommandes.xml Le fichier XML est disponible en téléchargement. Il s agit du fichier Chapitre8_GestionCommandes.xml. Si vous consultez la documentation de BizTalk Server ou suivez les tutoriaux, vous remarquerez que le classeur Excel peut directement être utilisé pour déployer la définition BAM. En effet, l outil bm.exe peut lire le fichier au format Excel et le convertir en XML pour le déploiement. Cependant, ce fonctionnement requiert l installation d Excel sur le serveur BizTalk ce qui est très rare et parfois même interdit par l équipe informatique. Je vous conseille donc d exporter vos définitions en XML et de les préserver dans votre contrôle de code source. 6. Les objets SQL Server créés pendant le déploiement Lors du déploiement, des objets SQL Server ont été créés dans la base de données BAMPrimaryImport. Ces objets permettent de stocker les indicateurs définis dans la définition BAM. a. Tables SQL Server Des tables SQL Server sont créées pour chaque activité BAM. Dans notre cas, des tables sont créées pour l activité Gestion des commandes. Stockage des indicateurs bam_gestion_des_commandes_active : contient les activités actives, c est à dire en cours d exécution. bam_gestion_des_commandes_completed : contient les activités terminées. Ces deux tables ont la structure suivante (à une nuance près) :

222 Les indicateurs créés dans l activité BAM se matérialisent sous forme de champs afin que les valeurs correspondantes soient stockées. Les étapes du processus, CommandeRecue et CommandeEnvoyee, sont toutes deux stockées comme des champs de type date/heure. La date et l heure à laquelle l étape sera réalisée est stockée de cette manière.dans la table. Le champ ActivityID est la clé primaire de la table. C est l identifiant unique de l activité BAM. Cet identifiant peut être calculé automatiquement par BizTalk ou renseigné lors de la collecte des données du BAM. Vous pouvez par exemple stocker le numéro de commande dans ce champ, si vous considérez qu une seule commande portant ce numéro ne peut être traitée en même temps. La table bam_gestion_des_commandes_completed, qui contient les activités terminées, possède un champ supplémentaire nommé RecordID. Ce champ est la clé primaire en remplacement du champ ActivityID. Cette nouvelle clé primaire permet de stocker des activités BAM ayant eu le même identifiant (numéro de commande par exemple) mais dans des périodes de temps différentes. Des champs supplémentaires sont ajoutés par BizTalk automatiquement. Il s agit de données de travail lui permettant par exemple de savoir si une activité est terminée ou non. Lorsque les données du BAM seront en volume important, après plusieurs semaines ou mois d activité par exemple, BizTalk va automatiquement créer des tables de stockage supplémentaires. Ces tables de stockage s appelleront comme les tables citées précédemment mais seront suffixées d un identifiant unique (un GUID : Globally Unique IDentifier). BizTalk procède ainsi à du partitionnement pour offrir de meilleures performances lors de l accès aux données du BAM. Vous ne devez donc jamais requêter directement les tables du BAM car vous ne verrez pas forcément toutes les données. Reportez vous au paragraphe concernant les vues SQL Server car ce sont avec elles que vous aurez un accès aux données du BAM. Continuations Une activité BAM se déroule, dans BizTalk, en plusieurs étapes. C est le cas de notre activité de gestion de commandes qui démarre lors de la réception d une commande en provenance de la gestion commerciale et se termine lorsque BizTalk a envoyé cette commande à l application de comptabilité. La collecte des données est donc effectuée à plusieurs moments et il n est pas possible de prévoir combien de temps va séparer ces différentes étapes. Les données de l activité BAM récoltées lors de la réception de la commande vont être stockées dans les tables SQL Server vues précédemment. L activité ne va cependant pas être marquée comme terminée tant que toutes les étapes de ne seront pas effectuées. BizTalk va mémoriser le chemin qu il reste à parcourir avant que l activité se termine. Cette information s appelle une continuation. Les continuations de l activité Gestion des commandes sont stockées dans la table bam_gestion_des_commandes_continuations. Tant que cette table contient des lignes, cela signifie que des activités ne sont pas terminées et attendent de nouvelles étapes. La structure de cette table est la suivante : Il est prématuré d expliquer le contenu de cette table, vous le comprendrez lorsque nous aurons terminé ce chapitre. Relations entre les activités

223 Dans notre définition BAM nous avons une seule activité. Il arrive très souvent qu une activité BAM soit en relation avec une ou plusieurs autres activités BAM. Supposez par exemple que le processus de commande soit lié au processus d approvisionnement. Ce sont deux processus bien différents qui ont certainement été modélisés sous forme de deux activités BAM distinctes. Pour autant, ces deux processus sont liés : une commande engendre un ou plusieurs approvisionnements. Un même approvisionnement peut concerner plusieurs commandes. Les relations sont donc bidirectionnelles et avec des cardinalités inconnues à l avance qui dépendent du chemin d exécution. Pour stocker ces liens, BizTalk crée deux tables : bam_gestion_des_commandes_activerelationships : relations avec des activités tant que l activité est active. bam_gestion_des_commandes_completedrelationships : relations avec des activités lorsque l activité est terminée. La structure de ces deux tables est la suivante : Nous reparlerons du contenu de ces tables dans le chapitre BAM avancé lorsque nous aborderons la notion de relation. b. Vues SQL Server Comme nous l indiquons dans le paragraphe précédent, il ne faut pas directement accéder aux données du BAM via les tables SQL Server. Ces tables peuvent être partitionnées et ne peuvent vous donner qu une vision partielle du BAM. Pour vous permettre un accès aux données, BizTalk crée des vues SQL Server. Ces vues reflètent le contenu des tables citées précédemment mais tiennent compte du partitionnement éventuellement fait par BizTalk. Vues sur les données d une activité BAM Les vues suivantes permettent de requêter une activité BAM : bam_gestion_des_commandes_activeinstances : liste les activités actives. Correspond au contenu de la table bam_gestion_des_commandes_active. bam_gestion_des_commandes_allinstances : liste toutes les activités, complètes ou actives. C est une union des données des tables bam_gestion_des_commandes_active et bam_gestion_des_commandes_completed. bam_gestion_des_commandes_completedinstances : liste les activités terminées. Correspond au contenu de la table bam_gestion_des_commandes_completed. bam_gestion_des_commandes_allrelationships : liste les relations entre activités, qu elles soient complètes ou non. Correspond au contenu des tables bam_gestion_des_commandes_activerelationships et bam_gestion_des_commandes_completedrelationships. En plus de ces quatre vues, deux vues supplémentaires sont disponibles et permettent à BizTalk de savoir si des données BAM doivent être archivées. Ces vues se nomment : bam_gestion_des_commandes_instancesforarchive et bam_gestion_des_commandes_relationshipsforarchive. Nous découvrirons dans le chapitre BAM avancé le fonctionnement de l archivage des données du BAM. Accès aux données des vues BAM

224 Lorsque nous avons créé la définition BAM, nous avons créé deux vues BAM destinées à deux populations d utilisateurs. Dans ces vues nous avons renommé des champs, ajouté des calculs de durée et masqué certaines informations. À chaque vue BAM correspond une collection de vues SQL permettant la visualisation des informations correspondantes. Si nous prenons comme exemple la vue BAM Informatique, voici les principales vues SQL créées par BizTalk : bam_informatique_viewgestion des commandes_activeview : instances actives. bam_informatique_viewgestion des commandes_completedview : instances complétées. bam_informatique_viewgestion des commandes_view : toutes les instances. Dans la copie d écran ci dessous vous pouvez mesurer que ces vues contiennent les champs que nous avons renommés, ou ajoutés : Le champ CodeClient a disparu au profit du champ Code du client. Il en est de même pour le champ NumeroCommande qui est devenu Numero de commande. Le champ DureeTotale a été ajouté et contient la durée du processus de gestion de commandes (temps écoulé en secondes entre la réception d une commande et son envoi à la comptabilité). c. Le stockage des données calculées Vous l avez compris, les données que nous avons personnalisées dans les vues BAM sont présentées dans des vues SQL. Ce sont les vues SQL correspondantes aux vues BAM qui contiennent les mécanismes permettant de renommer des indicateurs. Ces vues savent également masquer des indicateurs, regrouper des étapes ou calculer des durées. À titre d exemple, dans la vue BAM Informatique, nous demandons qu une durée totale du processus soit calculée et présentée dans le champ DureeTotale. Nous souhaitons également renommer les champs CodeClient en Code du client et NumeroCommande en Numero de commande. Toute l intelligence souhaitée se situe dans la vue bam_informatique_gestioncommandes_activealiasview dont le code est présenté ci après. SELECT RecordID, ActivityID, LastModified, CodeClient AS [Code du client], CommandeEnvoyee, CommandeRecue, NumeroCommande AS [Numero de commande], (CAST(CommandeEnvoyee AS FLOAT) - CAST(CommandeRecue AS FLOAT)) * AS DureeTotale FROM dbo.[bam_gestion des commandes_activeinstances] Vous pouvez constater dans l instruction SELECT de la vue : Le renommage des indicateurs (avec le mot clé SQL as). Le calcul de la durée entre les deux étapes (mots clés CAST et soustraction SQL). Les données calculées d une vue BAM ne sont pas stockées. La durée entre deux étapes est bien calculée à la demande. Si vous souhaitez ajouter dans la vue BAM un nouveau calcul de durée, vous pouvez le faire et ne risquez pas de

225 perdre les données qui ont déjà été collectées si, bien entendu, les données utilisées sont déjà présentes dans l activité BAM. d. Procédures stockées SQL Server En sus des tables et vues SQL, BizTalk crée également plusieurs procédures stockées associées à chaque activité BAM. BizTalk utilise lui même ces procédures stockées pour créer des occurrences dans les tables SQL ou pour mettre à jour des occurrences existantes. Nous ne détaillons pas les différentes procédures stockées dans ce chapitre mais illustrons l utilisation de l une d entre elles dans le chapitre BAM avancé

226 Définition de la collecte des données Les structures de stockage sont maintenant opérationnelles pour accueillir les données du BAM. La phase de déploiement est donc terminée en ce qui concerne la définition du BAM. Nous allons maintenant évoquer les mécanismes qui permettent à BizTalk de collecter les données et nous allons mettre en place la configuration nécessaire pour notre activité de gestion des commandes. Il existe plusieurs alternatives pour collecter les données comme nous l avons précédemment évoqué. Nous allons dans ce paragraphe mettre en œuvre un suivi de profil BAM. 1. Rappels sur ce qu est un suivi de profil BAM? Un suivi de profil BAM est un ensemble d indications, données à BizTalk, lui permettant de collecter des données. Ce profil indique : Quand est ce qu il faut collecter les données. Quelles données il faut collecter et où les trouver. Dans notre exemple BAM, nous devons indiquer à BizTalk plusieurs éléments : a. Les sources de données des indicateurs Rappelez vous les étapes de création des indicateurs BAM dans l activité Gestion des commandes. Nous avons créé deux types d indicateurs : Des données de l entreprise : c est à dire des informations métiers comme le code client ou le numéro de commande. Des étapes principales : comme la réception d une commande ou son envoi. Source des données des indicateurs "données de l entreprise" Pour collecter les indicateurs code client et numéro de commande, BizTalk nous propose d utiliser trois sources de données : le corps du message ; le contexte du message ; des propriétés de messagerie. Ces données sont des informations techniques sur le message comme sa taille, la date à laquelle il a été réceptionné... Nous allons utiliser deux sources de données : le corps du message pour récupérer le numéro de commande et le contexte du message pour récupérer le code client. Le code client se trouve également dans le corps du message donc nous pourrions aussi le récupérer dans la source de données correspondante. Source des données des indicateurs "étapes principales" Les étapes principales de l activité BAM peuvent être collectées dans quatre sources de données différentes : le corps du message ; le contexte du message ;

227 les propriétés de messagerie ; les orchestrations. Nous étudierons cette source de données dans le chapitre Implémentation de processus métier. Dans notre exemple, nous allons considérer : Que l étape de réception de la commande (étape CommandeRecue) se situe dès la réception de la commande provenant de la gestion commerciale. Que l étape d envoi de la commande (étape CommandeEnvoyee) se situe dès l envoi de la commande à l application de Comptabilité. Ces deux informations sont récupérées dans la source de données propriétés de message BizTalk. b. Les étapes de collecte Nous venons de lister les sources de données que BizTalk sait utiliser pour collecter les données. Afin de lui permettre de réaliser cette collecte, nous devons également lui indiquer quand il doit effectuer la collecte. Étant donné qu un message entrant dans BizTalk peut être transformé pour ensuite être envoyé, si nous récupérons le code d un client à l entrée ou à la sortie de BizTalk, l information n est peut être pas la même ou n a pas le même format. BizTalk peut collecter des données aux moments suivants : Dès la fin de réception d un message : c est à dire dès qu un message a été traité correctement par un port de réception et dès qu il est publié dans la MessageBox. Dès la fin de l envoi d un message : c est à dire dès qu un message a été correctement traité par un port d envoi. À certaines étapes d un processus métier implémenté sous forme d une orchestration. Nous abordons le BAM dans les orchestrations au chapitre Implémentation de processus métier. Dans notre cas, nous allons collecter les données suivantes : Le code client, le numéro de commande et l étape Commande reçue dès que le port de réception rcvgestioncommerciale aura traité le message et l aura publié dans la MessageBox. L étape Commande envoyée dès que le port d envoi sndcomptabilite_file aura envoyé le message à l application de comptabilité. 2. Création d un profil de suivi BAM a. Définition du suivi de profil BAM avec l éditeur de modèle de suivi Pour définir le suivi de profil BAM, nous utilisons l Éditeur de modèle de suivi (le terme anglais plus largement utilisé est Tracking Profile Editor ou TPE). Par simplicité, nous utiliserons le terme TPE pour représenter l éditeur de modèle de suivi : Lancez le TPE en cliquant sur le lien Éditeur de modèle de suivi dans le menu Démarrer, groupe Microsoft BizTalk Server b. Import d une définition BAM La première action à réaliser dans le TPE est l import d une définition BAM préalablement déployée

228 Avant de définir un suivi de profil BAM, la définition de l activité BAM doit être déployée, comme nous l avons fait dans le paragraphe Déploiement de la définition BAM de ce chapitre. Dans l écran principal du TPE, cliquez sur le lien Cliquez ici pour importer une définition BAM. Vous devez ensuite sélectionner l activité BAM pour laquelle vous souhaitez créer un suivi de profil. Si un grand nombre d activités est déployé dans votre groupe BizTalk, utilisez le champ de recherche à votre disposition. Dans ce champ de recherche, l outil ajoute automatiquement des caractères jokers : Saisissez le mot commande, et cliquez sur le bouton Rechercher, vous obtenez toutes les activités BAM qui contiennent le mot commande. Sélectionnez l activité Gestion des commandes et cliquez sur le bouton OK. Si un précédent modèle de suivi BAM a été défini pour cette activité, veillez à cocher la case Extraire les paramètres de suivi actuels pour cette définition d activité. Ainsi le précédent modèle de suivi sera chargé dans l éditeur et vous pourrez le modifier. Si vous ne cochez pas cette case, vous construirez un tout nouveau suivi BAM et écraserez l actuel dès le déploiement. c. Sélection de la source de données pour les champs CodeClient et NumeroCommande Vous devez désormais sélectionner la source de données dans laquelle le modèle de suivi BAM va se nourrir. Afin de remplir les données Code client, NumeroCommande, nous allons nous sourcer dans le schéma Commande.xsd puisque ce schéma contient toutes les informations nécessaires. Afin de récupérer des informations du schéma Commande.xsd, nous devons utiliser la source de donnée nommée charge de messagerie. La traduction est assez lointaine de la signification réelle dans BizTalk, le terme anglais est messaging payload, ce qui pourrait finalement se traduire par contenu des messages

229 Cliquez sur le bouton Sélectionner une source d événement et sélectionnez l option Sélectionner la charge de messagerie. L écran liste toutes les assemblies BizTalk qui contiennent des schémas. Sélectionnez l assembly ENI.Schemas dans laquelle se trouve le schéma Commande.xsd et cliquez sur Suivant : L écran liste tous les schémas contenus dans l assembly. Sélectionnez le schéma Commande et cliquez sur OK :

230 Comme l indique la copie d écran ci dessous, vous disposez désormais dans le TPE : en partie gauche de la définition de l activité BAM Gestion des commandes ; en partie droite de la définition du schéma Commande. d. Association des données du schéma Commande et des indicateurs BAM Voici comment associer l indicateur CodeClient de la définition BAM (à gauche de l écran) et le champ CodeClient du schéma Commande (à droite de l écran). Sélectionnez le champ CodeClient dans la partie droite de l écran (dans le schéma Commande). Faites glisser le champ sur l indicateur CodeClient situé à gauche de l écran (dans la définition BAM). À l issue de cette manipulation, vous obtenez le résultat illustré ci dessous :

231 Le modèle de suivi BAM indique maintenant où récupérer les données mais pas encore quand il faut les récupérer. Pour préciser quand il faut collecter l indicateur CodeClient : Sélectionnez l indicateur CodeClient dans la définition BAM et ouvrez le menu contextuel. Sélectionnez l option Définir les mappages de port. Recherchez le port de réception nommé rcvgestioncommerciale et faites le glisser dans la liste de sélection disposée à droite de l écran. Cliquez ensuite sur le bouton OK : En effectuant cette manipulation, nous précisons que l indicateur CodeClient doit être récupéré dans le champ CodeClient d une commande à la fin de l exécution du port de réception rcvgestioncommerciale. Procédez aux mêmes manipulations pour le champ NumeroCommande. e. Définition de la collecte pour l étape CommandeRecue Nous considérons que l étape CommandeRecue est le moment où le port de réception rcvgestioncommerciale a été correctement exécuté. D un point de vue fonctionnel, il s agit en effet de la réception effective d une commande par l EAI. Pour préciser cela dans le modèle de suivi BAM, nous utilisons la source de données propriété de messagerie : Cliquez sur le bouton Sélectionner une source d événement et sélectionnez l option Sélectionner la propriété de messagerie. Localisez ensuite la propriété ServiceEndTime et faites la glisser vers l indicateur CommandeRecue dans la

232 définition BAM. Vous obtenez l équivalent de la copie d écran ci dessous : La propriété PortEndTime correspond à la date/heure de fin d exécution d un port (de réception ou d envoi). La propriété PortStartTime correspond au début d exécution d un port. Si le traitement effectué par le port (temps de réception du message, validation du message, analyse du message...) n est pas très long, les valeurs de ces deux propriétés sont sensiblement identiques. D un point de vue fonctionnel, cela n a pas réellement d importance, il est en effet très rare que les étapes fonctionnelles soient comptabilisées de manière si précise. Nous utilisons la propriété PortEndTime pour symboliser l étape de réception d une commande (CommandeRecue). Nous devons cependant indiquer l exécution de quel port il s agit. Dans notre cas, il s agit du port de réception rcvgestioncommerciale. Sélectionnez le champ PortEndTime situé en dessous de l indicateur CommandeRecue dans la partie gauche de l écran, ouvrez le menu contextuel et sélectionnez l option Définir les mappages de port. Sélectionnez ensuite le port de réception rcvgestioncommerciale et cliquez sur OK :

233 f. Définition de la collecte pour l étape CommandeEnvoyee L étape CommandeEnvoyee de notre processus se situe lorsque la commande a été envoyée à l application de Comptabilité. Techniquement, il s agit de la fin d exécution du port SndComptabilite_FILE : Afin de collecter cette information, sélectionnez le champ PortEndTime dans la source de données propriétés de messagerie. Faites la glisser sur l indicateur CommandeEnvoyee : Sélectionnez le champ PortEndTime situé en dessous de l indicateur CommandeEnvoyee, ouvrez le menu contextuel et sélectionnez l option Définir les mappages de port. Cette fois ci, vous devez sélectionner le port d envoi sndcomptabilité_file. La manière dont nous avons défini la collecte pour l étape CommandeEnvoyee fonctionne mais n est pas entièrement satisfaisante, vous comprendrez pourquoi plus loin dans ce chapitre. Nous modifierons le suivi de profil BAM pour l adapter à nos besoins et collecter correctement l étape CommandeEnvoyee dans le paragraphe Continuation dans le BAM. g. Enregistrement du suivi de profil BAM Lorsque vous avez terminé la définition du suivi de profil BAM, sauvegardez le (option Fichier Enregistrer du TPE). Le fichier sauvegardé porte l extension.btt (pour BizTalk Tracking). Il s agit d un fichier XML que vous pouvez modifier manuellement si besoin. Une modification directement en XML est intéressante lorsque des changements en masse doivent être appliqués. Voici le contenu de ce fichier pour la collecte de l indicateur CodeClient : <Dimension Name="CodeClient" DataType="NVARCHAR"> <DataLevel Name="CodeClient" SourceTypeSelected="Messaging Payload" TargetAssemblyName="ENI.Schemas, Version= , Culture=neutral, PublicKeyToken=bb71f210b1779e11" SchemaName="ENI.Schemas.Commande,ENI.Schemas, Version= , Culture=neutral, PublicKeyToken=bb71f210b1779e11" SomXPath="/*[local-name()= <Schema> and namespaceuri()= urn:editionseni:gestioncommandes ]/*[localname()= Commande and namespaceuri()= urn:editionseni:gestioncommandes ]/*[localname()= CodeClient and namespace-uri()= ]" Xpath="/*[localname()= Commande and namespaceuri()= urn:editionseni:gestioncommandes ]/*[localname()= CodeClient and namespace-uri()= ]"> <Port Name="rcvGestionCommerciale" Direction="Receive" /> </DataLevel> </Dimension> Voici ce qu il faut comprendre de cet extrait de code : Un nœud Dimension est présent pour chaque indicateur collecté. Un nœud fils DataLevel indique où les données sont collectées (ici, dans le schéma Commande). Une requête Xpath permet de spécifier précisément le champ à récupérer dans le message. Un nœud fils Port indique quand les données doivent être collectées. Ici, il s agit du port de réception (Direction= Receive ) nommé rcvgestioncommerciale. Supposons par exemple que vous changiez le nom du port rcvgestioncommerciale en rcvgestco. En éditant le fichier XML et en utilisant un remplacement de chaîne, vous gagnerez beaucoup de temps par rapport à des modifications manuelles dans le TPE

234 3. Déploiement du suivi de profil BAM Lorsque la définition du suivi de profil BAM est terminée, il doit être déployé pour que BizTalk commence à collecter les données souhaitées. Tant que le suivi de profil n est pas déployé, aucune collecte de donnée n est effectuée. Il existe deux alternatives pour déployer un suivi de profil BAM : Utiliser le TPE. Utiliser l outil en ligne de commande bttdeploy.exe. a. Déploiement avec le TPE Ouvrez le TPE. Dans le menu Fichier, sélectionnez l option Ouvrir et localisez votre fichier d extension.btt dans lequel votre profil a été enregistré. Dans le menu Outils, sélectionnez l option Appliquer le modèle de suivi pour déployer le profil. Si un profil est déjà appliqué, l éditeur vous avertira et vous demandera de confirmer le déploiement. Lorsque le déploiement est effectué sans erreur, vous obtenez un message d information vous indiquant que le déploiement est effectué. b. Déploiement en ligne de commande Traditionnellement, le déploiement d un suivi de profil BAM est effectué avec le TPE pendant la phase de développement. Lorsque le profil doit être déployé en production, il est conseillé d utiliser les outils en ligne de commande car ils peuvent être intégrés à un package de déploiement automatisé. Voici comment déployer un suivi de profil BAM en ligne de commande : Ouvrez une ligne de commande et naviguez dans le sous répertoire Tracking du répertoire d installation de BizTalk. Lancez la commande suivante : bttdeploy.exe c:\enieditions\bam\gestioncommandes.btt c. Suppression d un suivi de profil déjà déployé La suppression d un suivi de profil BAM déjà déployé est possible soit avec le TPE, soit en ligne de commande avec le programme bttdeploy.exe. Il faut comprendre les deux scénarios suivants : Si vous disposez du fichier.btt contenant votre suivi de profil, vous pouvez utiliser indépendamment l une ou l autre des deux méthodes. Si par contre, vous ne possédez pas le fichier.btt, vous ne pouvez pas utiliser l outil en ligne de commande car celui ci requiert la fourniture du fichier d extension.btt. Par contre, le TPE vous permet de récupérer un suivi de profil déjà déployé. Pour cela, importez une définition BAM et cochez la case Extraire les paramètres de suivi actuels pour cette définition d activité. d. Profils de suivi BAM orphelins Si par malheur vous supprimez une définition BAM sans supprimer le suivi de profil BAM correspondant, le suivi de

235 profil sera orphelin. BizTalk continue de collecter les données car le suivi de profil est déployé mais ne sait pas comment les stocker puisque les objets SQL Server n existent plus pour la définition BAM. Pour supprimer un suivi de profil BAM orphelin, vous devez déployer de nouveau la définition BAM, supprimer le suivi de profil et enfin supprimer la définition BAM. Si par contre, vous n avez pas la possibilité de déployer de nouveau la définition BAM (vous n avez pas conservé le fichier XML de définition BAM par exemple ou n avez pas la même version), vous ne pouvez pas procéder à la suppression du suivi de profil. La seule solution possible mais non supportée suppose de supprimer directement des données dans la base de données BizTalk. 4. Notion de continuation a. Anomalies constatées lors des collectes du BAM Après avoir déployé le suivi de profil BAM, procédez à la réception d une commande afin qu elle soit traitée par BizTalk et envoyée à l application de Comptabilité. Lorsque ce traitement est terminé, vous pouvez consulter des données dans le BAM. Pour l instant, ne réceptionnez qu une seule commande afin que nous puissions facilement comprendre l anomalie. Afin de visualiser les données du BAM, ouvrez SQL Server Management Studio, connectez vous à l instance SQL Server qui héberge la base de données BAMPrimaryImport. Exécutez la requête ci dessous : SELECT * FROM [BAMPrimaryImport].[dbo].[bam_Informatique_ViewGestion des commandes_view] Vous obtenez le résultat suivant : Il y a plusieurs anomalies que vous pouvez remarquer dans les résultats obtenus : Il y a deux lignes alors que nous n avons réceptionné qu une seule commande. Sur la première ligne, la plupart des indicateurs ont été renseignés et la durée totale n a pas été calculée. L indicateur CommandeEnvoyee n a pas été collecté. Sur la seconde ligne, seul l indicateur CommandeEnvoyee a été collecté. Toutes ces anomalies sont liées à la manière dont nous avons collecté l indicateur CommandeEnvoyee. Avant de corriger le suivi de profil, il faut comprendre la notion de Continuation que nous allons expliquer. b. Notion de continuation Pourquoi avons nous des anomalies? Notre processus de gestion de commandes débute lorsqu un port de réception s exécute (rcvgestioncommerciale) et se termine lorsqu un port d envoi a été correctement exécuté (sndcomptabilite_file). Nous collectons 90% des données lors de la réception et l indicateur CommandeEnvoyee lors de l envoi de la commande. Ces deux artefacts BizTalk s exécutent à deux instants bien différents, nécessairement l un après l autre, le port d envoi ne pouvant pas s exécuter tant qu une commande n a pas été réceptionnée. Le temps qui sépare ces deux exécutions n est pas connu ni maîtrisé. Lorsque BizTalk collecte les données lors de l exécution du port de réception, il renseigne les indicateurs que nous souhaitons collecter sur le port rcvgestioncommerciale. Lorsqu il a terminé la collecte, il considère que l activité en

236 cours est terminée. Il marque l activité comme complétée (champ IsActive=false dans la base de données). Dans notre exemple, cette collecte correspond à la création de la première ligne dans la base de données. Lorsque le port d envoi termine son exécution, BizTalk collecte les indicateurs précisés dans le suivi de profil et associés au port d envoi. En l occurrence, il s agit uniquement de l indicateur CommandeEnvoyee. BizTalk crée donc une seconde ligne dans la base de données pour l activité et la marque terminée. Il n y a pas de lien entre les deux lignes dans la base de données alors que, fonctionnellement, il s agit de la même commande. Idéalement, nous aimerions n avoir qu une seule ligne avec tous les indicateurs renseignés et la durée totale calculée. Comment corriger les anomalies? Afin de n obtenir qu une seule ligne dans la base de données pour chaque commande, il faut indiquer à BizTalk que l exécution du port de réception est liée à l exécution du port d envoi. Nous devons indiquer à BizTalk que le processus qui débute par le port de réception rcvgestioncommerciale se termine par le port d envoi sndcomptabilite_file. Pour cela, nous créons une continuation et indiquons à BizTalk quelle information permet de relier le message reçu et le message envoyé. Une continuation est composée de deux éléments : Le début de la continuation, c est à dire le moment dans le processus à partir duquel une suite est attendue. Dans notre cas, il s agit de la réception d une commande. Nous savons qu à partir du moment où nous réceptionnons une commande, il y aura un envoi. Nous allons donc débuter la continuation lors de la réception. La fin de la continuation, c est à dire l étape du processus qui, lorsqu elle est atteinte, indique que la continuation est terminée. Dans notre cas, il s agit de l exécution du port d envoi. Une même activité BAM peut contenir plusieurs continuations. C est le cas si de multiples artefacts prennent part au processus. Par exemple, si nous devons attendre la confirmation d une commande avant de l envoyer à la comptabilité, il y aura plusieurs continuations. Une entre la commande reçue et la confirmation et une entre la commande reçue et la commande envoyée. À partir du moment où nous définissons une continuation dans le suivi de profil BAM d une activité, l activité ne sera pas considérée comme complète tant que la continuation ne sera pas suivie. Si l étape qui est censée terminer la continuation n arrive jamais, l activité BAM restera toujours active. Dans notre cas, si l exécution du port d envoi vers la Comptabilité est terminée prématurément par un administrateur, l activité BAM de gestion de commandes correspondant ne sera jamais marquée terminée. Les continuations doivent être utilisées en connaissant leurs inconvénients et les effets de bords qu elles peuvent engendrer. Dans des processus métier plus complexes, nous utilisons très souvent les relations en complément ou remplacement des continuations. Nous expliquons et illustrons cette notion dans le chapitre BAM avancé. Création d une continuation Nous allons créer une continuation qui est initialisée lors de la réception d une commande sur le port rcvgestioncommerciale : Ouvrez le suivi de profil BAM dans le TPE. Dans la partie gauche de l écran (définition BAM), sélectionnez le nœud racine nommé Gestion des commandes et ouvrez le menu contextuel. Sélectionnez l option Nouvelle Continuation. Un nœud fils est créé en dessous du nœud Gestion des commandes. Nommez le contenvoicommande (ou tout

237 autre terme qui vous semble adapté). Il s agit du nom de la continuation que nous réutilisons plus tard. Nous devons maintenant indiquer quelle information permet à BizTalk de lier une commande reçue à une commande envoyée. Nous allons utiliser le numéro de commande car il ne varie pas entre la réception de la commande et son envoi : Ouvrez la source de données charge de messagerie, sélectionnez l assembly ENI.Schemas et ensuite le schéma Commande. Faites glisser le champ NumeroCommande sur la continuation contenvoicommande : Nous venons d indiquer sur quelle information sera faite la continuation. Nous devons maintenant indiquer quand cette information sera collectée : Sélectionnez le champ NumeroCommande situé en dessous du nœud contenvoicommande, ouvrez le menu contextuel Définir les mappages de ports et sélectionnez le port de réception rcvgestioncommerciale. Paramétrer la suite de la continuation Nous venons de réaliser une partie de la continuation. Si nous déployons le suivi de profil BAM dans son état actuel, BizTalk va détecter qu il y a une continuation et va donc attendre qu une suite soit donnée au processus de réception de commande. Nous devons lui indiquer où se trouve la fin de la continuation. Dans notre cas, la fin de la continuation se trouve dans le même suivi de profil. Ce n est cependant pas toujours le cas lorsque deux activités métiers sont liées (exemple : gestion des commandes et gestion des livraisons). Sélectionnez le nœud racine Gestion des commandes, ouvrez le menu contextuel et sélectionnez l option Nouveau ContinuationID. Vous devez maintenant renommer le nœud fils comme la continuation précédemment créée (dans mon exemple, il s agit du nom contenvoicommande) comme indiqué ci dessous : Indiquez quelle est l information qui lie la commande envoyée de la commande reçue et quand cette information doit être collectée. Sélectionnez la source de commande charge de messagerie, l assembly ENI.Schemas puis le schéma Commande. Faites glisser le champ NumeroCommande sur le nœud ContinuationID. Vous devez obtenir le résultat suivant : Pour terminer, sélectionnez le champ NumeroCommande situé sous le nœud de type ContinuationID, ouvrez le menu contextuel et sélectionnez l option Définir les mappages de ports. Sélectionnez le port d envoi sndcompatibilite_file

238 Nous avons désormais effectué les actions nécessaires pour indiquer à BizTalk : Qu une continuation nommée contenvoicommande, basée sur le champ NumeroCommande débute lors de l exécution du port rcvgestioncommerciale. Que la continuation se termine lors de l exécution du port d envoi sndcompatibilite_file, là aussi en utilisant le champ NumeroCommande comme lien. c. Résultats après correction des anomalies Nous pouvons déployer le suivi de profil BAM et tester de nouveau en réceptionnant une nouvelle commande. En lançant la requête SQL sur le BAM, nous obtenons cette fois ci les résultats ci après. Ces résultats font apparaître trois lignes. Les deux premières lignes correspondent aux anomalies déjà présentes dans les données du BAM et que nous venons de corriger. La troisième ligne correspond à la commande que nous venons de réceptionner. Cette fois ci tous les indicateurs sont collectés, il n y a qu une seule ligne et la durée totale a été calculée (exprimée en secondes). Le suivi de profil BAM est disponible en téléchargement. Il s agit du fichier Chapitre8_GestionCommandes.btt

239 Restitution des données aux utilisateurs À cette étape de notre projet, nous avons défini les indicateurs et BizTalk est en mesure de les collecter. Tous les messages de type Commande qui proviennent de la gestion commerciale et transitent vers la Comptabilité sont suivis et les indicateurs sont collectés. Nous allons étudier comment ces indicateurs peuvent être restitués aux utilisateurs. 1. Utilisation des objets SQL Server Nous l avons vu, lors du déploiement de la définition BAM, BizTalk crée des tables et vues SQL Server. Ces objets SQL Server offrent un accès aux données du BAM et peuvent donc servir pour restituer des informations aux utilisateurs. Vous pouvez donc, à l aide de n importe quel outil sachant produire des clauses SQL et se connecter à SQL Server, restituer les informations issues du BAM. Nous illustrons trois exemples de requêtes SQL pour le suivi. Afin de jouer les exemples ci dessous, vous pouvez utiliser l outil SQL Server Management Studio en vous connectant à l instance SQL Server qui héberge la base de données BAMPrimaryImport. Pour obtenir des données dans les requêtes de visualisation ci dessous, procédez à plusieurs réceptions de commandes. a. Lister toutes les commandes reçues La requête permettant d obtenir cette information est la suivante : SELECT * FROM [BAMPrimaryImport].[dbo].[bam_Informatique_ViewGestion des commandes_view] b. Lister les commandes reçues mais non envoyées Pour simuler une commande reçue mais non envoyée, stoppez le port d envoi sndcomptabilite_file. Réceptionnez une commande et lancez la requête ci dessous : SELECT * FROM [BAMPrimaryImport].[dbo].[bam_Informatique_ViewGestion des commandes_activeview] Nous utilisons la vue bam_informatique_viewgestion des commandes_activeview qui n affiche que les activités non terminées. Vous obtiendrez un résultat équivalent à celui ci : Remarquez que les champs RecordID, CommandeEnvoyee et DureeTotale ne sont pas encore renseignés. Ils le seront lorsque le port d envoi sera exécuté. Démarrez le port d envoi sndcomptabilite_file pour terminer l activité et vous verrez qu il n y a plus d activité Gestion de commandes en cours d exécution. Si vous utilisez la requête illustrée au paragraphe Lister toutes les commandes reçues, vous constaterez que la durée totale est cette fois ci sensiblement plus importante. c. Rechercher une commande par son numéro de devis pour un commercial Pour un commercial de notre entreprise, une commande est toujours recherchée en utilisant le numéro de devis que le commercial a rédigé pour le client. Il peut ainsi lier son action d avant vente avec le processus de commande du client

240 Pour qu un commercial retrouve une commande en utilisant un numéro de devis, la requête suivante peut être utilisée. Dans cet exemple, nous recherchons une commande avec un numéro de devis égal à 2. SELECT * FROM [BAMPrimaryImport].[dbo].[bam_Force de vente_viewgestion des commandes_view] where [Numéro de devis]= 2 Nous utilisons cette fois ci les vues SQL Server spécifiques à la force de vente. Ces vues présentent le numéro de devis au lieu du numéro de commande et n affichent pas la durée totale du processus : 2. Utilisation du portail BAM a. Accès au portail BAM La solution basée uniquement sur SQL Server, exposée ci avant, n est évidemment pas destinée au grand public car des notions SQL sont nécessaires. Le portail BAM livré avec BizTalk est un site Web offrant une vision graphique et conviviale sur les données du BAM. Il est accessible après authentification des utilisateurs. Le look et l ergonomie du portail sont discutables mais l outil a l avantage d exister et vous évite un développement ad hoc d une interface Web. C est un point de départ intéressant et je conseille souvent à mes clients de l utiliser au démarrage du projet avant d initier le développement d un outil plus évolué. Le portail BAM est accessible en http ou https selon la configuration du serveur IIS (Internet Information Server) à l url suivante : BizTalk>/bam Si vous disposez d une ferme de serveurs BizTalk, le portail BAM est vraisemblablement installé sur chaque machine. Reportez vous au chapitre Architecture et haute disponibilité pour connaître les options de configuration dans cette architecture. La page principale du portail BAM est illustrée ci dessous : La partie droite de l écran contient une zone appelée Mes Vues. Cette zone permet l accès aux vues BAM déployées au niveau du groupe BizTalk

241 Toutes les vues BAM ne sont pas visibles pour tous les utilisateurs. Des droits d accès peuvent être positionnés sur les vues. Nous aborderons ce sujet dans le chapitre BAM avancé. b. Utilisation du portail BAM Nous allons illustrer l utilisation du portail BAM comme si nous étions un commercial cherchant si une commande existe pour le devis numéro 2 et quand cette commande a été passée par le client : Dans le menu arborescent à gauche de l écran, cliquez sur la vue Force de vente, sur le lien Recherche d activité puis sur Gestion des commandes. Dans la zone Requête de la page, sélectionnez le champ Numéro de devis, l opérateur Égal à et saisissez la valeur 2 : Dans la zone Sélecteur de colonne, sélectionnez les trois champs afin qu ils soient affichés dans les résultats de la requête : Cliquez sur le bouton Exécuter la requête située en haut de la page pour obtenir les résultats ci dessous : À cette étape de la recherche, le commercial peut se rendre compte qu une commande a été passée pour le devis numéro 2. Il peut également obtenir de plus amples informations sur cette commande en cliquant sur la ligne de résultat correspondante

242 Dans notre cas, cet écran n a pas beaucoup de plus value car 90 % des informations étaient déjà affichées dans la liste des résultats. Dans le cas de processus plus complexe, cet écran permet de naviguer dans les activités associées (exemple : visualiser l état de la livraison correspondant à la commande). Ceci est possible dans la zone Activités associées. Dans le chapitre BAM avancé, nous utiliserons plus de fonctionnalités du portail BAM. Nous illustrerons notamment l usage du bouton Assistance. c. Alertes BAM Dans les étapes que nous venons d illustrer, le commercial a réussi à trouver une commande correspondant au devis numéro 2. Supposons maintenant qu il recherche une commande associée au numéro de devis nº3. Cette commande n a pas encore été saisie ni traitée par BizTalk, donc la recherche dans le portail BAM est vaine comme l indique la copie d écran ci dessous : Pour éviter au commercial de se connecter chaque matin pour lancer cette requête, le BAM de BizTalk propose un mécanisme d alerte, appelé alertes BAM. Grâce aux alertes BAM, le commercial peut demander à BizTalk de l avertir lorsqu une commande sera traitée pour le devis numéro 3. Voici comment il va procéder : Lancez la requête qui permet de rechercher la commande dont le numéro de devis est égal à 3. Cette requête ne devrait pas retourner de résultats. Cliquez sur le bouton Définir l alerte situé en haut de la page. Dans les détails de l alerte, saisissez un nom ainsi qu un message pour cette alerte. Vous pouvez également choisir la priorité de cette alerte :

243 Lorsque vous définissez une alerte, vous pouvez préciser la visibilité de cette alerte avec la case à cocher Autoriser des tiers à voir cette alerte et à s y abonner. En cochant cette case vous permettez à d autres utilisateurs de s abonner, dans le cas contraire, l alerte est privée et vous êtes le seul à pouvoir vous abonner. Cliquez maintenant sur Enregistrer l alerte. À cette étape, l alerte existe mais vous n êtes pas encore abonné. Ainsi, si la requête à laquelle l alerte est associée retourne des données, vous ne serez pas notifié. Voici comment s abonner à l alerte : Lorsque vous avez cliqué sur Enregistrer l alerte, une nouvelle zone a été ajoutée dans l écran. Il s agit de la zone Abonnements. Cliquez sur le bouton Ajouter l abonné situé dans cette zone. Vous devez indiquer le transport qui sera utilisé pour notifier l abonné. Deux transports sont disponibles : Adresse de messagerie : ce transport permet de spécifier une adresse e mail à laquelle sera envoyé un message de notification. Fichier : si vous sélectionnez ce transport, un fichier d alerte sera produit par BizTalk et déposé dans un emplacement qui a été configuré lors de l installation. Afin que vous puissiez facilement reproduire cette démonstration sur votre serveur, nous choisissons d utiliser le transport Fichier. Ceci vous évite en effet de devoir configurer ou disposer d un serveur SMTP. Sélectionnez le transport. Cliquez sur Enregistrer

244 Pour connaître le répertoire dans lequel le fichier d alerte sera créé, ouvrez l outil de configuration de BizTalk (Configuration de BizTalk Server dans le menu Démarrer, groupe Microsoft BizTalk Server 2009). Sélectionnez la section Alertes BAM. Le chemin correspondant est indiqué dans le champ nommé Emplacement du fichier Alertes BAM comme l illustre la copie d écran suivante. Nous avons terminé la création d une alerte et d un abonné à cette alerte. Pour s assurer de son fonctionnement, nous allons réceptionner la commande correspondant au devis numéro 3 et vérifier qu un fichier d alerte est créé. Lorsque l alerte se déclenche, un fichier nommé BAMAlerts.xml est créé dans le répertoire des alertes (en l occurrence dans le partage de fichier nommé alerts). Si le fichier BAMAlerts.xml existe déjà dans le répertoire, les informations sur l alerte sont ajoutées à la fin du fichier. Le fichier peut donc contenir plusieurs alertes. Le fichier BAMAlerts.xml contient les données suivantes : Notification Id: 1 Notification Class Name: FileNotification Subscriber Id: BTS2009FR\Administrateur Device Address:

245 Protocol Fields: Body: <?xml version="1.0" encoding="utf-16"?><alert xmlns:msxsl="urn:schemas-microsoftcom:xslt"><username>bts2009fr\administrateur</username><viewname> Force de vente</viewname><name>saisie de la commande relative au devis numéro 3</Name><Message>La commande relative au devis numéro 3 a été reçue du client.</message><webpage> aspx?viewname=force+de+vente&activityname=gestion+des+commandes &AlertName=Saisie+de+la+commande+relative+au+devis+num%c3%a 9ro+3</WebPage><Time>02/09/ :05:38</Time></Alert> Les données XML contenues dans le champ Body sont différentes selon le paramétrage de l alerte (notamment le sujet et le message). L utilisation du transport Fichier pour délivrer des alertes est intéressante car, couplé à BizTalk, il permet de récupérer une alerte, de la transformer sous forme d un document structuré pour le publier dans le portail Intranet de la société. La publication de ce document dans le portail Intranet de l entreprise enclenche par exemple des processus métier particuliers ou la notification d une population d utilisateurs. Les possibilités offertes par les alertes BAM sont donc très importantes. Lorsque nous évoquerons les agrégations dans le chapitre BAM avancé, vous pourrez identifier de nouveaux usages des alertes BAM. d. Réutilisation de requêtes BAM Lorsque nous définissons une requête BAM depuis le portail BAM, nous pouvons enregistrer cette requête et la réutiliser. Afin d enregistrer une requête, utilisez le bouton Enregistrer la requête disponible en haut de l écran de requête BAM. Lorsque vous cliquez sur ce bouton, vous téléchargez sur votre poste client un fichier XML nommé BAMQuery.xml. Enregistrez ce fichier sur votre disque dur en le renommant comme vous le souhaitez. Afin de réutiliser la requête, utilisez le bouton Parcourir et sélectionnez le fichier XML contenant votre requête enregistrée

246 Intégration du BAM dans un package de déploiement Jusqu à maintenant, nous avons utilisé les outils en ligne de commande pour déployer nos artefacts BAM (définition BAM et suivi de profil BAM). Pour faciliter le déploiement de notre projet BizTalk par des équipes qui n ont pas de compétences BizTalk, nous devons minimiser le recours à des tâches manuelles. Nous allons donc étudier et illustrer les procédés nous permettant de déployer le BAM d une application BizTalk en même temps que tous les éléments de cette application. BizTalk nous permet d intégrer dans les ressources d une application BizTalk des artefacts BAM et donc de les inclure dans un package de déploiement (fichier MSI). 1. Déployer une définition BAM via un package MSI Afin de déployer une définition BAM via un package MSI, il convient simplement d ajouter le fichier de définition BAM (le fichier XML exporté depuis Excel) dans les ressources de l application. Lors de l export de l application BizTalk en MSI, cette définition BAM sera intégrée dans le package et sera donc déployée lors de l import du MSI dans un groupe BizTalk. Voici comment nous pouvons procéder pour déployer la définition BAM de notre processus de gestion de commandes : Dans l application BizTalk ENIEditions, sélectionnez le nœud Ressources. Ouvrez le menu contextuel, sélectionnez l option Ajouter puis Ressources. Cliquez sur le bouton Ajouter puis localisez le fichier XML contenant votre définition BAM. Dans la liste déroulante Type de fichier, sélectionnez l option System:BizTalk:Bam

247 Cliquez sur le bouton OK pour terminer l ajout de la ressource. Exportez maintenant votre application sous forme d un fichier MSI et importez le fichier MSI. La définition BAM sera déployée lors de l import du fichier MSI. 2. Déployer un suivi de profil BAM via un package MSI Il n est malheureusement pas possible, nativement en tout cas, de déployer un suivi de profil BAM dans un package MSI comme nous venons de le faire pour une définition BAM. Si vous ajoutez le suivi de profil BAM (fichier d extension.btt) dans les ressources d une application, le fichier sera associé au type de fichier System:BizTalk:File, c est à dire à un fichier non typé. Lors du déploiement du package MSI de l application, le fichier.btt sera simplement copié sur le serveur mais aucune action de déploiement particulière ne sera effectuée. Afin d automatiser cette action de déploiement du suivi de profil BAM, il est nécessaire d implémenter un script de déploiement. Reportez vous au chapitre Déploiement de solutions BizTalk pour plus d informations sur les scripts de déploiement. Pour implémenter le script de suivi de profil BAM, vous devez interagir avec l outil en ligne de commande bttdeploy.exe qui permet le déploiement et la suppression de profils de suivi BAM

248 Conclusion Nous avons terminé au sujet des notions de base pour la mise en œuvre du suivi fonctionnel dans BizTalk. Nous irons plus loin dans les concepts du BAM dans le chapitre BAM avancé. Nous étudions également le BAM dans les processus métier dans le chapitre Implémentation de processus métier

249 Introduction aux transformations 1. Qu est ce qu une transformation? Lorsque nous avons implémenté le processus de gestion de commandes dans les précédents chapitres, nous avons considéré que toutes les applications participant aux échanges utilisaient le même format de messages. Le format d une commande envoyée par l application de Gestion commerciale est partagé avec l application de Comptabilité. Sur le terrain, cette situation est très rare, sauf peut être lorsque vous développez en interne les deux applications et faites donc en sorte qu elles parlent le même langage. Quoi qu il en soit, les évolutions du Système d Information de l entreprise sont telles que cette situation risque de ne pas durer. L un des rôles de l EAI, et donc de BizTalk, est, outre le transport des messages, de transformer le format des données échangées afin qu elles deviennent compréhensibles par l ensemble des acteurs. Dans BizTalk, la transformation entre un format source et un format destination s appelle un mappage. Le terme français n est pas très fréquemment utilisé et le terme anglais map est bien plus répandu. Nous utiliserons ce terme pour parler des transformations. Une map contient toutes les opérations qui permettent de transformer un message source en un message destination. Afin de définir une map, vous devez disposer des schémas qui modélisent les messages source et destination. 2. Les caractéristiques d une map BizTalk Une map BizTalk se caractérise par les éléments suivants : Un nom : chaque map porte un nom qui permet de la différencier des autres maps. Un type de message source : il s agit du type de message que la map utilise comme source pour la transformation. Un type de message destination : il s agit du type de message que la map va produire à l issue de la transformation. Lorsqu une map est déployée, ces différentes caractéristiques sont déclarées dans la base de données de configuration de BizTalk afin d être utilisées. 3. Technologies derrière la scène a. Éditeur de maps Une map est définie dans un outil de conception intégré à Visual Studio : il s agit du BizTalk Map Editor (ou Éditeur de mappages BizTalk en français). Cet outil permet de créer graphiquement la map et toutes les étapes qui permettent la transformation. b. XSLT Derrière la scène, BizTalk crée une feuille de style XSLT (Extensible StyleSheet Language Transformations). La recommandation XSLT est, tout comme la recommandation XSD, un standard très répandu permettant la définition de transformations entre messages. XSLT est utilisé pour la transformation de messages XML en HTML par exemple ou dans bien d autres contextes. L éditeur de map BizTalk est un facilitateur pour manipuler des transformations graphiquement, vous pouvez toujours écrire vous même le code XSLT si vous le souhaitez. L un de mes clients, qui se reconnaîtra certainement s il lit ces lignes, a pendant très longtemps écrit ses maps directement en XSLT sans utiliser l outil graphique de BizTalk. Cette approche lui a permis de maîtriser le langage XSLT mais l a aussi éloigné des standards BizTalk et parfois des outils qui peuvent faciliter certaines transformations. À l occasion d une migration BizTalk, ce client est revenu à une approche standard des maps. La

250 complexité de certaines des transformations qu il effectue nécessitent toujours des appels à du code XSLT embarqué dans la map. Nous évoquons ce sujet dans la suite de ce chapitre

251 Usage des maps Lorsqu on crée une map, celle ci n est pas de réception ou d envoi. Une map peut être utilisée indifféremment lors de la réception ou lors de l envoi d un message. 1. Réception de messages a. Rappel sur le processus de réception d un message Dans les précédents chapitres, BizTalk a publié le message en provenance de l application source, sans changer son format. Dans le schéma ci dessous, nous illustrons comment une transformation peut agir lors de la réception d un message : Dans le schéma ci dessus, un message de type Commande au format de l application de Gestion Commerciale est réceptionné par BizTalk. BizTalk transforme ce message en un message de type Commande au format pivot. Le format pivot est ensuite publié et véhiculé dans la MessageBox afin de déclencher les échanges et processus métier associés. Lors de la réception, les étapes suivantes sont suivies par le message : Il est tout d abord transporté par l adaptateur jusqu à BizTalk. Le message transite ensuite par un pipeline de réception. Le pipeline, et les composants qui le composent, agissent sur le message, par exemple pour vérifier qu il s agit d un message au format XML. La dernière étape du processus de réception est la transformation. C est à cette étape qu une map peut être exécutée afin de produire un nouveau format de message

252 b. Messages typés et maps L étape de transformation n est évidemment pas obligatoire. Une transformation s applique uniquement si le type du message est connu. Si vous réceptionnez des messages non typés (c est à dire non associés à des schémas XSD), aucune transformation ne peut être appliquée. BizTalk sait qu un message est typé lorsque la propriété contextuelle BTS.MessageType est renseignée (par exemple avec la valeur urn:editionseni:gestioncommande#commande pour nos messages de type Commande). Souvenez vous que le pipeline de réception XMLReceive a notamment pour rôle de détecter si un message est typé et de remplir la propriété BTS.MessageType avec la valeur appropriée. c. Sélection et exécution d une map Si vous souhaitez qu une transformation soit appliquée à la réception d un message, vous devez associer une ou plusieurs maps au port de réception. Lorsqu un message typé est réceptionné, BizTalk recherche, dans la liste des maps du port de réception, si une map doit être appliquée. BizTalk compare le type du message réceptionné (valeur de la propriété BTS.MessageType) et le type de message source de chaque map. Plusieurs scénarios sont possibles : Une map a été trouvée : dans ce cas, elle est exécutée. Plusieurs maps ont été trouvées : seule la première map trouvée est exécutée. Aucune map n a été trouvée : dans ce cas aucune transformation du message n est appliquée et le message est publié dans son format d origine. d. Publication du message transformé Si l exécution de la map ne produit pas d erreur, le message transformé est publié dans la MessageBox. Si le format du message a changé (par exemple, passage d une commande au format Gestion commerciale à une commande au format Pivot), la propriété BTS.MessageType est modifiée par la map pour refléter le format du message obtenu. e. Propriétés promues et maps Souvenez vous de l importance des propriétés promues évoquées au chapitre Modélisation de messages. Ces propriétés nourrissent le contexte d un message avec des informations issues du corps du message. La phase de promotion des propriétés se déroule lors de l exécution du pipeline de réception (plus précisément lors de l exécution du composant XMLDésassembleur qui est contenu dans le pipeline XMLReceive). Lorsque le message sort du pipeline de réception, les propriétés sont déjà promues. Si le message est transformé dans un nouveau format, dans lequel des propriétés promues ont été définies, voici comment BizTalk va se comporter : Les propriétés promues dans le schéma source sont préservées. Si le schéma destination effectue la promotion des mêmes propriétés que le schéma source, les valeurs déjà associées aux propriétés sont écrasées par les valeurs issues du message transformé. Les propriétés promues dans le schéma destination et non promues dans le schéma source sont ajoutées au contexte du message. À l issue de la transformation, le contexte du message publié est nourri : des propriétés promues du schéma source ; des propriétés promues du schéma destination

253 2. Envoi de messages a. Rappel sur le processus d envoi d un message Une transformation peut être également appliquée avant l envoi vers une application ou un partenaire. Le schéma ci dessous illustre le processus d envoi : b. Processus d envoi et transformation La première étape de l envoi est l application de la transformation quand il y a une map associée au port d envoi et si cette map permet de convertir le type de message envoyé. À l issue de la transformation, le message transformé transite par le pipeline d envoi puis est traité par l adaptateur qui se charge du transport. Plusieurs maps peuvent être associées au port d envoi. La sélection de la map à appliquer suit les mêmes règles que celles exposées dans le paragraphe Sélection et exécution d une map. 3. Processus métier Une transformation peut également être appliquée dans un processus métier, c est à dire dans une orchestration BizTalk. L usage des maps dans les processus métier apporte plusieurs avantages que nous évoquons dans le chapitre Implémentation de processus métier. 4. Transformations et format pivot

254 a. Le rôle du format pivot L usage de formats pivots (appelés aussi formats canoniques) est une bonne pratique comme nous l avons mentionné dans les précédents chapitres. Dans notre scénario d échange gestion commerciale et comptabilité, l usage d un format pivot de type Commande évite toute dépendance vis à vis de ces deux applications. Le schéma ci dessous illustre comment nous devons utiliser les formats pivots dans notre scénario d échange de commandes entre la gestion commerciale et la comptabilité : b. Adaptabilité en cas de changement de format Si vous changez d application de comptabilité et donc de format d échange avec cette application, la seule modification que vous devez opérer se situe dans la transformation entre le format pivot Commande et le format attendu par l application de Comptabilité. Si vous implémentez des processus métier basés sur le format pivot dans BizTalk, ils ne sont pas impactés par les changements du monde extérieur. L intérêt du découplage entre format interne et externe se vérifie également lorsque le format pivot évolue pour les besoins des processus ou pour prendre en compte un nouveau format qui nécessite de véhiculer de nouvelles informations. Attention tout de même, le format pivot n est pas magique. Si le format externe change de manière très structurante, nécessitant par exemple la fourniture de données que vous ne possédez pas, l impact pour prendre en compte ce nouveau format ne se limitera pas à la modification de la transformation. Malgré tout, vous pourrez isoler les modifications apportées et ne pas impacter tous vos partenaires

255 Implémentation d une transformation Nous allons faire évoluer notre solution d échange entre la gestion commerciale et la comptabilité en considérant que les formats de commandes échangées ne sont pas les mêmes. Nous allons avoir recourt à un format pivot afin de respecter les bonnes pratiques. Nous disposerons de trois schémas différents : Une commande au format Gestion commerciale que nous allons modéliser. Une commande au format Comptabilité que nous allons modéliser. Une commande au format "pivot" qui est notre actuel schéma Commande.xsd du projet ENI.Schemas. 1. Création des nouveaux schémas a. Structuration des projets BizTalk L un des challenges dans le développement de solutions BizTalk, et ce n est pas le seul, est de structurer correctement les projets Visual Studio afin que les dépendances entre ces projets ne soient pas problématiques lors du déploiement et lorsque l un des éléments vient à changer. Pour l instant, nous avons un seul projet dans notre solution Visual Studio, ce projet contient tous nos schémas. La mise en œuvre des transformations est l occasion de structurer différemment notre projet Visual Studio, afin que l adhérence entre les projets soit la plus logique possible. Nous allons créer deux nouveaux projets et réutiliser le projet ENI.Schemas existant. Le schéma ci dessous illustre la répartition des composants entre les projets et leurs dépendances : Voici la liste des projets et leur rôle récapitulé dans le tableau ci dessous :

256 Nom du projet ENI.Schemas ENI.GestCo.Schemas ENI.GestCo.Maps ENI.Compta.Schemas ENI.Compta.Maps Description Schémas des messages pivots et schéma des propriétés promues. Schémas des messages échangés avec la gestion commerciale. Transformations entre les schémas de la gestion commerciale et les schémas pivots. Schémas des messages échangés avec la comptabilité. Transformations entre les schémas de la comptabilité et les schémas pivots. Ce découpage en plusieurs projets offre les avantages suivants : Chaque élément peut être déployé et modifié sans impacter les autres. Les schémas d échange avec l extérieur (comptabilité ou gestion commerciale) peuvent être réutilisés dans d autres solutions BizTalk. Procédez à la création des différents projets listés dans le tableau. Ajoutez ces projets à votre solution Visual Studio nommée ENI.BizTalk. Assignez à chaque projet le fichier de clé (fichier.snk) comme nous l avons fait dans les chapitres précédents. Référencez les projets entre eux selon les dépendances illustrées dans le schéma présenté précédemment. Dans les propriétés de déploiement de chaque projet, renseignez la valeur du champ Nom de l application afin que tous les artefacts soient déployés dans l application ENIEditions. b. Création du schéma Commande gestion commerciale Dans le projet ENI.GestCo.Schemas, créez un schéma nommé Commande.xsd. Le nœud racine se nomme Commande et l espace de noms cible est urn:editionseni:gestco. Pour gagner du temps, voici le contenu du fichier XSD. Recopiez ce code dans votre fichier schéma via un éditeur de texte : <?xml version="1.0" encoding="utf-16"?> <xs:schema xmlns:b=" xmlns="urn:editionseni:gestco" targetnamespace="urn:editionseni:gestco" xmlns:xs=" <xs:element name="commande"> <xs:complextype> <xs:sequence> <xs:element name="client"> <xs:complextype> <xs:sequence> <xs:element name="numero" type="xs:string" /> <xs:element name="codepostallivraison" type="xs:string" /> <xs:element name="villelivraison" type="xs:string" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="produit"> <xs:complextype> <xs:sequence> <xs:element name="reference" type="xs:string" /> <xs:element name="quantite" type="xs:int" /> <xs:element name="prixunitaire" type="xs:int" /> <xs:element name="remiseclient" type="xs:int" />

257 </xs:sequence> </xs:complextype> </xs:element> <xs:element name="datecommande" type="xs:string" /> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Visuellement, le schéma d une commande issue de la gestion commerciale est le suivant : Les particularités de ce schéma, que nous devrons prendre en compte dans nos transformations, sont les suivantes : Il n y a pas de numéro de commande. Un seul produit peut être commandé à la fois. Le calcul du prix unitaire appliqué au client doit être effectué en tenant compte du rabais accordé au client. c. Création du schéma Commande comptabilité Dans le projet ENI.Compta.Schemas, créez un nouveau schéma nommé Commande.xsd. Le nœud racine est Commande et l espace de noms cible est urn:editionseni:compta. Copiez le code ci dessous dans le fichier XSD : <?xml version="1.0" encoding="utf-16"?> <xs:schema xmlns:b=" xmlns="urn:editionseni:compta" targetnamespace="urn:editionseni:compta" xmlns:xs=" <xs:element name="commande"> <xs:complextype> <xs:sequence> <xs:element name="numerocommande" type="xs:string" /> <xs:element name="comptetiers" type="xs:string" /> <xs:element name="montanthtcommande" type="xs:string" /> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Ce schéma est fondamentalement différent du message reçu par la gestion commerciale. L application de comptabilité ne souhaite pas obtenir la liste des produits commandés, elle souhaite simplement obtenir des éléments afin d établir la facturation des clients. Elle a donc besoin du numéro de commande, du montant HT commandé ainsi que d un code comptable correspondant au client à facturer. Ces exemples de schémas sont fictifs et pensés uniquement pour illustrer les transformations et leur usage. D un point de vue purement fonctionnel, ils ne sont pas toujours le reflet de situations que vous pourrez rencontrer

258 d. Génération d exemple de messages Afin de constituer une collection de messages exemple, profitons de cette phase de modélisation pour générer un exemple de commande au format gestion commerciale. Utilisez la fonction Générer une instance et stockez le fichier XML généré dans un sous répertoire Exemples de votre projet ENI.GestCo.Schemas (comme nous l avions fait dans le chapitre Modélisation de messages). 2. Création des transformations Nous disposons maintenant de l ensemble des schémas représentant une commande vue par la gestion commerciale, la comptabilité et le format pivot correspondant. Nous allons créer les maps permettant les transformations nécessaires. a. Map depuis la gestion commerciale Cette première map permet de transformer une commande provenant de la gestion commerciale en une commande pivot : Sélectionnez tout d abord le projet ENI.GestCo.Maps dans Visual Studio. Ajoutez un nouvel élément de type Mappage. Nommez la map CommandeToPivot.btm. La map s affiche dans l éditeur de transformations. Cliquez sur le lien Ouvrir le schéma source et sélectionnez le schéma source. En l occurrence, il s agit du schéma Commande du projet ENI.GestCo.Schemas. Vous ne pouvez sélectionner ce schéma que si vous avez effectué correctement la référence entre le projet ENI.GestCo.Maps et ENI.GestCo.Schemas. Cliquez sur le lien Ouvrir le schéma cible. Sélectionnez le schéma Commande du projet ENI.Schemas (c est àdire le schéma de commande pivot)

259 Une fois de plus, vous ne pourrez pas sélectionner le schéma ENI.Schemas.Commande si vous n avez pas référencé le projet ENI.Schemas depuis le projet ENI.GestCo.Maps. Utilisez le glissé/déposé pour faire correspondre les champs du format source avec ceux du schéma destination. Nous allons pour l instant relier les données qui doivent être recopiées d un message à l autre : Lorsque cette transformation sera exécutée, les données du message source seront recopiées dans le message destination en suivant les liens que nous avons positionnés. b. Map vers la comptabilité Nous allons maintenant créer une map permettant le passage du format pivot au format de commande pour la comptabilité. Nous n aurons jamais de transformation directe entre la gestion commerciale et la comptabilité puisque nous considérons le format pivot comme étape obligatoire. Créez une map nommée PivotToCommande.btm dans le projet ENI.Compta.Maps. Le schéma source de cette map est ENI.Schémas.Commande et le schéma cible est ENI.Compta.Schemas.Commande. Dans cette map, reliez pour l instant uniquement le champ NumeroCommande et CodeClient puisque le champ MontantHTCommande nécessite l utilisation de fonctions avancées que nous étudions dans la suite de ce chapitre. La map de transformation est illustrée dans la copie d écran ci dessous : 3. Valider les maps

260 a. Objectifs de la validation d une map Nous venons de créer deux transformations, dans deux projets différents. Avant de procéder au test de chaque transformation avec des exemples de messages, nous pouvons demander la validation de ces transformations. L objectif de cette étape est la détection d éventuels problèmes qui pourraient se produire lors de l exécution. Si par exemple, la map produit un message dont un champ obligatoire n est pas renseigné, la validation nous l indiquera. b. Procéder à la validation Sélectionnez la map CommandeToPivot.btm dans le projet ENI.GestCo.Maps, ouvrez le menu contextuel et sélectionnez l option Valider le mappage : Dans la fenêtre Sortie de Visual Studio vous obtenez les lignes suivantes : Appel d un component... C:\ENIEditions\ENI.BizTalk\ENI.GestCo.Maps\CommandeToPivot.btm: warning btm1028: Le champ obligatoire "CodeClient" ne comporte pas de liaison entrante, ni de valeur de constante ni de valeur par défaut. C:\ENIEditions\ENI.BizTalk\ENI.GestCo.Maps\CommandeToPivot.btm: warning btm1028: Le champ obligatoire "PrixUnitaire" ne comporte pas de liaison entrante, ni de valeur de constante ni de valeur par défaut. C:\ENIEditions\ENI.BizTalk\ENI.GestCo.Maps\CommandeToPivot.btm: warning btm1028: Le champ obligatoire "Rue" ne comporte pas de liaison entrante, ni de valeur de constante ni de valeur par défaut. C:\ENIEditions\ENI.BizTalk\ENI.GestCo.Maps\CommandeToPivot.btm: La sortie XSLT est stockée dans le fichier suivant : <file:///c:\users\administrateur\appdata\local\temp\1\_mapdata\eni.gestco.maps\commandetopivot.xsl> C:\ENIEditions\ENI.BizTalk\ENI.GestCo.Maps\CommandeToPivot.btm: L élément XML de l objet d extension est stocké dans le fichier suivant : <file:///c:\users\administrateur\appdata\local\temp\1\_mapdata\eni.gestco.maps\commandetopivot_extxml.xml> L appel de composant a réussi. Par exemple, la ligne C:\ENIEditions\ENI.BizTalk\ENI.GestCo.Maps\CommandeToPivot.btm: warning btm1028: Le champ obligatoire "CodeClient" ne comporte pas de liaison entrante, ni de valeur de constante ni de valeur par défaut indique que le champ CodeClient du message destination n est pas renseigné, ni par un lien depuis un champ source ni avec une valeur constante. Étant donné que ce champ est obligatoire dans le schéma destination, le message produit ne sera pas conforme au schéma de commande cible. Lorsque la validation produit uniquement des avertissements (warning), la map peut tout de même être déployée et utilisée et la compilation du projet sera possible. Bien entendu, la présence de ces avertissements doit être étudiée pour comprendre leur cause et aussi leurs conséquences. 4. Tester une map Il est possible de tester un schéma avec Visual Studio, il est également possible de tester une map pour vérifier qu elle produit le résultat attendu. Tester une map consiste à fournir à la map un exemple de fichier en entrée (fichier qui correspond au schéma source de la map) et à produire un fichier en sortie de cette map. a. Les propriétés pour le test d une map Plusieurs options permettent d indiquer à Visual Studio comment le test doit se comporter. Ces options sont réunies dans la section Tester le mappage dans les propriétés de la map. Vous pouvez accéder à ces propriétés lorsque le

261 fichier de la map (fichier d extension.btm) est sélectionné dans l explorateur de solutions Visual Studio. Voici la signification de ces propriétés : Propriété Description Entrée TestMap Trois valeurs possibles : Générer l instance : lors du test, c est Visual Studio qui génère un exemple de fichier d entrée en se basant sur le schéma source. XML : vous indiquez une instance de message en entrée de la map et le message est au format XML. Natif : idem XML mais pour les fichiers plats ou EDI. Instance de sortie TestMap Instance d entrée TestMap Vous précisez le chemin d un fichier qui va contenir les résultats de la transformation. Si vous ne renseignez pas cette propriété, un fichier sera généré dans un emplacement temporaire. Vous précisez le chemin d un fichier en entrée. Si vous ne précisez pas de fichier en entrée, la propriété Entrée TestMap est automatiquement positionnée à Générer l instance. Sortie TestMap Deux valeurs possibles : XML : indique que le fichier généré après la transformation sera au format XML. Natif : indique que le fichier généré après la transformation sera au format natif du schéma destination, la plupart du temps fichier plat ou EDI. Valider la sortie TestMap Deux valeurs possibles : True : le fichier généré par la map sera validé par rapport au schéma destination. Si la validation n est pas possible, la map produira une erreur pendant le test. False : le fichier généré par la map n est pas vérifié par rapport au schéma. Valider l entrée TestMap Deux valeurs possibles : True : le fichier en entrée de la map est préalablement validé par rapport au schéma source. Si la validation n est pas possible, la map n est pas exécutée et vous obtenez une erreur de validation. False : aucune vérification n est faite sur le fichier en entrée si bien que l exécution de la map peut avoir un résultat inattendu. Ces différentes options sont utilisées par la map uniquement lorsque celle ci est testée dans Visual Studio. Lorsque la map est déployée dans BizTalk et exécutée pour les transformations, ces options ne seront pas prises en compte. b. Tests d une map Afin de tester la map ENI.GestCo.Maps.CommandeToPivot, je vous propose de renseigner les propriétés comme le présente la copie d écran ci dessous :

262 Pour lancer le test, ouvrez le menu contextuel sur le fichier CommandeToPivot.btm et sélectionnez l option Tester le mappage. Les résultats du test sont affichés dans la fenêtre Sortie de Visual Studio : Appel d un component... C:\ENIEditions\ENI.BizTalk\ENI.GestCo.Maps\CommandeToPivot.btm: warning btm1028: Le champ obligatoire "CodeClient" ne comporte pas de liaison entrante, ni de valeur de constante ni de valeur par défaut. C:\ENIEditions\ENI.BizTalk\ENI.GestCo.Maps\CommandeToPivot.btm: warning btm1028: Le champ obligatoire "PrixUnitaire" ne comporte pas de liaison entrante, ni de valeur de constante ni de valeur par défaut. C:\ENIEditions\ENI.BizTalk\ENI.GestCo.Maps\CommandeToPivot.btm: warning btm1028: Le champ obligatoire "Rue" ne comporte pas de liaison entrante, ni de valeur de constante ni de valeur par défaut. Test Map a utilisé le fichier <file:///c:\enieditions\eni.biztalk\eni.gestco.schemas\exemples\commande. xml> en tant qu entrée pour le mappage. C:\Users\Administrateur\AppData\Local\Temp\1\_MapData\ENI.GestCo.Maps\Com mandetopivot_output.xml: error btm1046: Erreur de validation de la sortie : L élément Commande dans l espace de noms urn:editionseni:gestioncommandes a un élément enfant non valide Produits. Liste d éléments possibles attendue : CodeClient. Échec de Test Map pour le fichier de mappage <file:///c:\enieditions\eni.biztalk\eni.gestco.maps\commandetopivot.btm>. La sortie est stockée dans le fichier suivant : <file:///c:\users\administrateur\appdata\local\temp\1\_mapdata\eni.gestco.maps\commandetopivot_output.xml> L appel de composant a réussi. La map a été exécutée mais une erreur se produit comme l indique la ligne error btm1046: Erreur de validation de la sortie. Cette erreur est normale à ce stade de notre implémentation puisque le fichier généré par la map n est pas valide par rapport au schéma pivot. En effet, nous ne remplissons pas le code client alors que ce champ est obligatoire dans le format pivot. Nous allons le faire dans les paragraphes suivants. Les avertissements et

263 erreurs sont également affichés dans la fenêtre Liste d erreurs de Visual Studio : Malgré les erreurs, le fichier généré par la map est consultable : le chemin de ce fichier est indiqué sur la ligne La sortie est stockée dans le fichier suivant. Dans mon cas, voici le fichier généré : <ns0:commande xmlns:ns2="urn:editionseni:typessimples" xmlns:ns0="urn:editionseni:gestioncommandes" xmlns:enitypes="urn:editionseni:typescomplexes"> <Produits> <Produit Code="Reference_0"> <Quantite>10</Quantite> </Produit> </Produits> <AdresseLivraison> <enitypes:adresse> <ns2:codepostal>codepostallivraison_0</ns2:codepostal> <Ville>VilleLivraison_0</Ville> </enitypes:adresse> </AdresseLivraison> </ns0:commande> c. Utilisation des propriétés Valider la sortie et l entrée TestMap La map produit une erreur car le fichier généré n est pas conforme au schéma destination (schéma pivot en l occurrence). Nous savons qu une correction sera apportée prochainement à la map pour corriger cette erreur. À l issue de cette correction, la map ne devrait plus produire d erreur. Vous pouvez cependant rencontrer des scénarios particuliers dans lesquels les fichiers entrée ou sortie ne sont pas valides. Voici plusieurs exemples. Messages invalides à l entrée Votre client, ne sait pas renseigner un champ obligatoire dans un message qu il vous transmet. Vous ne pouvez décemment pas refuser de traiter ses messages, vous devez donc procéder aux corrections nécessaires pour que le message soit complet. C est typiquement le rôle d une map. Dans ce cas, le message en entrée n est pas conforme au schéma source mais la map va le rendre conforme. Pour tester cette map dans Visual Studio avec un exemple de message de votre client, positionnez la propriété Valider l entée TestMap à False. Messages invalides à la sortie Parfois la production d un message (pivot ou externe) suppose l application successive de plusieurs transformations. C est un scénario qui sera typiquement implémenté dans des orchestrations. L application de la première map a de fortes chances de produire un message invalide car c est après l application des maps successives que le message sera conforme. Afin de tester une map intermédiaire, il convient donc de positionner la propriété Valider la sortie TestMap à False

264 Déboguer une map 1. Débogage de maps avec Visual Studio Les nouvelles fonctionnalités de Visual Studio 2008 permettent désormais le débogage des maps. Dans la version 2005 de Visual Studio (utilisable pour le développement BizTalk Server 2006 et 2006 R2), le débogage de maps était possible mais par un chemin détourné. Désormais le débogage pas à pas de maps est proposé de manière native. Le débogage de maps repose en réalité sur les fonctionnalités de débogage XSL de Visual Studio car, souvenezvous, une map est un fichier XSL. 2. Comment déboguer une map? Afin de déboguer une map, ouvrez le menu contextuel sur la map et sélectionnez l option Carte de débogage. La traduction de cette option n est pas correcte, en anglais l option se nomme Debug map. Lorsque vous lancez le débogage de la map, les fenêtres de Visual Studio s organisent et vous permettent d obtenir le résultat illustré dans la copie d écran ci dessous : Dans cette copie d écran, vous retrouvez les fenêtres suivantes : À gauche, la feuille de style XSL correspondant à la map (CommandeToPivot.xsl). Vous pouvez positionner des points d arrêt dans cette feuille de style et l exécuter pas à pas avec les fonctions du menu Déboguer de Visual Studio. Au centre, le fichier Commande.xml est présenté, il s agit du fichier source. À droite, le fichier CommandeToPivot_output.xml est présenté, il s agit du fichier destination. Le contenu de ce fichier se renseigne au fur et à mesure de l exécution de la map. En bas à droite, la fenêtre Variables locales vous permet de consulter les différentes variables utilisées dans le fichier XSL de la map. Lorsque vous utiliserez les fonctoids dans les prochains paragraphes, cette fenêtre vous permettra de comprendre l exécution de ceux ci

265 Tests unitaires des maps 1. Activer les tests unitaires La mise en œuvre des tests unitaires pour les maps suit la même philosophie que les tests unitaires mis en œuvre sur les schémas (cf. chapitre Modélisation de messages, paragraphe Tests unitaires). Indiquez dans les propriétés du projet contenant les maps à tester que vous souhaitez activer les tests unitaires. Positionnez la propriété Activer le test des unités à True. Enregistrez vos modifications (menu Fichier puis Enregistrer). Toutes les maps du projet peuvent maintenant faire l objet de tests unitaires. Effectuez cette opération sur tous les projets contenant des maps. 2. Implémenter un test unitaire Si vous avez suivi le chapitre Modélisation de messages et les exercices, vous disposez déjà d un projet de type test unitaire dans lequel nous pouvons ajouter un nouveau test pour notre map. Il s agit du projet ENI.Tests. Dans le projet ENI.Tests, ajoutez une référence vers le projet ENI.GestCo.Maps qui contient les maps à tester. Dans le menu contextuel du projet ENI.Tests, sélectionnez l option Ajouter puis Nouveau Test. Choisissez le modèle Test unitaire et nommez le fichier TestMapGestCoCommandeToPivot.cs. Dans le fichier TestMapGestCoCommandeToPivot.cs, modifiez la méthode de tests nommée TestMethod1() en la renommant en TestMap(). Voici le code permettant de tester notre map CommandeToPivot.btm : [TestMethod] public void TestMap() { TestableMapBase mapcommandeverpivot = new ENI.GestCo.Maps.CommandeToPivot(); mapcommandeverpivot.validateinput = true; mapcommandeverpivot.validateoutput = true; mapcommandeverpivot.testmap(@"c:\enieditions\eni.biztalk\eni.gest Co.Schemas\Exemples\Commande.xml", Pivot.xml", OutputInstanceType.XML); } Dans ce code, nous créons tout d abord une instance de la map à tester (via la classe TestableMapBase). Nous positionnons ensuite les propriétés ValidateInput et ValidateOutput à True, ce qui correspond aux propriétés Valider la sortie TestMap et Valider l entrée TestMap. Si vous n avez apporté aucune correction à la map, ce test unitaire ne va pas réussir puisque la validation du message produit va échouer. Vous obtiendrez le message d erreur suivant lors de l exécution du test : La méthode de test ENI.Tests.TestMapGestCoCommandeToPivot.TestMap a levé une exception : Microsoft.BizTalk.TestTools.BizTalkTestAssertFailException: Compilateur du mappeur : échec de validation de sortie de mappage. Si vous souhaitez masquer cette erreur, vous pouvez entourer le code de tests d un bloc try/catch afin de capturer l exception BizTalkTestAssertFailException qui se produit

266 3. Exemple de code Si vous souhaitez récupérer l ensemble du code source de la solution Visual Studio, vous pouvez télécharger le fichier Chapitre9_codeSource.zip

267 Déploiement des maps Nous venons, dans les paragraphes précédents, d implémenter les maps. Nous disposons donc de l ensemble des éléments pour construire notre application BizTalk. 1. Compilation des maps Tout comme les schémas, les maps deviennent des classes.net lors de la compilation. Les classes.net sont stockées dans une assembly.net (une classe.net pour chaque map) et lors du déploiement elles sont référencées dans la base de configuration de BizTalk. L assembly correspondante est quant à elle copiée dans le GAC de la machine BizTalk pour être utilisée lors de l exécution. 2. Déploiement des maps La méthode de déploiement d une map et d un schéma est strictement identique. Les différentes alternatives pour le déploiement de schémas s appliquent aux maps : Déploiement depuis Visual Studio (pendant la phase de développement). Déploiement via l ajout de l assembly dans les ressources de l application BizTalk. Déploiement avec les outils en ligne de commande. Pour faciliter notre exercice et étant donné que nous avons désormais plusieurs assemblies à déployer, je vous propose d utiliser Visual Studio pour déployer. Étant donné que nous avons configuré correctement les propriétés de déploiement de tous les projets de notre solution, nous pouvons choisir l option Déployer la solution (menu contextuel sur la solution Visual Studio). Tous les projets BizTalk contenus dans la solution seront déployés. Vérifiez que tous vos projets BizTalk sont associés à l application BizTalk ENIEditions (propriété Nom de l application dans les options de déploiement) : sinon certaines assemblies pourraient être déployées dans la mauvaise application, en l occurrence l application par défaut. Si vous ne souhaitez pas déployer tous les projets de la solution Visual Studio, vous pouvez configurer la solution pour choisir les projets à déployer. Ouvrez le menu contextuel de la solution puis sélectionnez l option Gestionnaire de configurations. Vous obtenez l écran suivant dans lequel vous pouvez cocher/décocher la case déployer pour chaque projet BizTalk

268 3. Vérification du déploiement des maps Lorsque les maps ont été déployées, vérifiez qu elles apparaissent dans l application BizTalk ENIEditions. Dans la console d administration Biztalk, sélectionnez le nœud Mappages dans l application ENIEditions. Vous obtenez la liste des maps déployées : Dans cette copie d écran, vous constatez que BizTalk connaît des détails sur nos maps et notamment : le schéma source ; le schéma destination. Grâce à ces informations, il sera en mesure de choisir la map à appliquer à l arrivée d un message

269 Utilisation des maps Les maps sont correctement déployées, nous pouvons maintenant les utiliser dans notre application BizTalk. Le schéma ci dessous rappelle la solution que nous souhaitons mettre en place : 1. Utilisation d une map à la réception d un message

270 a. Modifier le message produit par la gestion commerciale Nous devons modifier le comportement du port de réception rcvgestioncommerciale. Pour l instant le port réceptionne une commande en provenance de l application de gestion commerciale et publie le message dans la MessageBox. Avant ce chapitre, nous avons considéré que la gestion commerciale nous envoyait des messages au format urn:editionseni:gestioncommandes#commande. Ce format est maintenant notre format pivot. Nous allons faire en sorte que la gestion commerciale produise un message au format urn:editionseni:gestco#commande. Il s agit donc d un message conforme au schéma Commande implémenté dans le projet ENI.GestCo.Schemas. Aucun changement n est nécessaire au niveau du port de réception rcvgestioncommerciale ni au niveau de l emplacement rcvgestioncommerciale_file car nous n avons pas configuré de validation forte vis à vis d un schéma en particulier. Vérifiez cela en copiant dans le répertoire d entrée un message de type Commande conforme au schéma ENI.GestCo.Schemas.Commande. Si vous avez suivi les manipulations de ce chapitre, vous disposez d un exemple de message dans le répertoire Exemples du projet ENI.GestCo.Schemas. Le message publié est en erreur de routage car, souvenez vous, le seul abonné connu, le port d envoi sndcomptabilite_file, est abonné aux messages de type urn:editionseni:gestioncommandes#commande. Étant donné que nous publions maintenant un message de type urn:editionseni:gestco#commande, aucun abonné n est déclaré donc le message est en erreur. Ne terminez pas l instance de service pour l instant car nous allons corriger cette situation. b. Association d une map au port de réception Pour publier un message au format pivot, nous allons associer la map CommandeToPivot du projet ENI.GestCo.Maps au port de réception rcvgestioncommerciale : Ouvrez les propriétés du port de réception rcvgestioncommerciale. Dans l onglet Mappages entrants, sélectionnez la map à appliquer : Pour sélectionner une map, vous pouvez rechercher à partir :

271 du schéma source ; du nom de la map ; du schéma destination. Ces mécanismes de recherche sont très utiles lorsque vous avez de nombreuses maps déployées au sein d une application BizTalk. Relancez maintenant l instance du port rcvgestioncommerciale qui est suspendue à cause d une erreur de routage. Le message transite de nouveau dans le port de réception mais cette fois ci une transformation est appliquée avant la publication du message. Si vous consultez le contexte du message publié dans la MessageBox après l exécution du port rcvgestioncommerciale, vous remarquez que le message est maintenant de type urn:editionseni:gestioncommandes#commande, c est à dire au format pivot. 2. Utilisation d une map à l envoi d un message Nous devons maintenant transformer le message avant qu il ne soit envoyé à l application de comptabilité. Associons donc la map PivotToCommande du projet ENI.Compta.Maps au port d envoi sndcomptabilite_file : Ouvrez le port d envoi sndcomptabilite_file et localisez l onglet Mappages sortants. Sélectionnez la map et appliquez vos modifications : Si vous exécutez l ensemble du processus, vous remarquez que le message déposé dans le répertoire Comptabilite est au format attendu par la comptabilité :

272 <ns0:commande xmlns:ns0="urn:editionseni:compta"> <CompteTiers>CodeDuClient</CompteTiers> </ns0:commande> Étant donné que nos différentes maps ne sont pas encore totalement implémentées, les messages produits à l issue de leurs exécutions respectives ne sont pas valides par rapport aux schémas. Si vous essayez de valider le message produit pour la comptabilité avec le schéma correspondant vous obtiendrez une erreur. Ceci prouve que la map, bien qu elle ne génère pas un message conforme au schéma destination, ne produit pas d erreurs. 3. Utilisation dans un processus métier Nous étudierons l utilisation des maps dans les processus métier dans le chapitre Implémentation de processus métier. En attendant ce chapitre, sachez simplement que les maps que nous venons d implémenter sont réutilisables en l état dans les processus métier

273 Rôle et utilisation des fonctoids 1. Rôle d un fonctoid Dans les précédents exercices, les maps mises en œuvre étaient relativement simples puisqu il s agissait essentiellement de recopies de données entre un message source et un message destination. Bien entendu, les transformations dans BizTalk ne se limitent pas à ces scénarios très simples. Des transformations plus complexes sont possibles grâce à l utilisation de fonctoids. Un fonctoid est un composant, utilisable dans une map, permettant de procéder à des traitements sur les données. Les fonctoids encapsulent du code qui est exécuté dans la map afin de faciliter les opérations de transformations. Les fonctoids sont accessibles dans la boîte à outils Visual Studio lorsque vous utilisez l éditeur de maps BizTalk : 2. Les principaux fonctoids BizTalk est livré avec une collection conséquente de fonctoids. Ils sont classés en catégories : Catégorie de fonctoids Fonctoids de chaîne Fonctoids mathématiques Fonctoids logiques Rôle Manipulations de chaînes de caractères : extraction de chaînes, concaténation... Calculs mathématiques : sommes, multiplications... Opérations logiques : décision, contrôles d égalité

274 Fonctoids Date/Heure Fonctoids de conversion Fonctoids scientifiques Fonctoids cumulés Fonctoids de base de données Fonctoids avancés Opérations de dates : calcul de date du jour, ajout de dates... Conversions : hexadécimal, ASCII... Calculs scientifiques : logarithmes, sinus... Opérations de cumuls de données : sommes, moyennes... Opérations d accès aux bases de données et de transcodage. Traitements avancés comme le script en ligne par exemple. Cette collection de fonctoids peut être complétée : par vos propres fonctoids : il est assez simple de développer ses propres fonctoids. par des fonctoids tiers : vous trouverez, notamment sur des boîtes à outils de fonctoids. Je pense par exemple à la collection de fonctoids disponibles dans le projet créé et géré par Jan Eliasen. Vous pouvez participer à leur amélioration ou compléter la collection des fonctoids. 3. Utiliser un fonctoid dans une map L utilisation d un fonctoid dans une map est très simple. Il faut déposer le fonctoid sur la grille, c est à dire entre le schéma source et le schéma destination. Ensuite, si le fonctoid requiert des données en entrée, il faut lui fournir : soit sous forme de valeurs saisies directement dans sa configuration ; soit sous forme d un lien depuis un champ du message. 4. Exemple d utilisation avec les fonctoids manipulation de chaînes Nous allons illustrer l usage d un fonctoid dans une map en procédant à une manipulation de chaîne dans la map CommandeToPivot du projet ENI.GestCo.Maps. Dans cette map, déjà implémentée, nous ne pouvons pas remplir le champ NumeroCommande du format pivot. Nous allons le faire en considérant que le numéro de la commande est la concaténation du champ CodeClient et du champ DateCommande du message en provenance de la gestion commerciale. a. Organiser les maps en pages Pour clarifier la représentation graphique de la map, nous allons tout d abord créer une nouvelle page. Une page dans une map permet d organiser la map en plusieurs modules. Dans des maps complexes, l usage de plusieurs pages est très utile. Ouvrez la map CommandeToPivot.btm. Au niveau de l onglet Page 1 de la map, ouvrez le menu contextuel et sélectionnez l option Ajouter une page. Renommez la page en Numéro commande. Nous allons dédier cette page à la génération du numéro de commande. b. Utiliser le fonctoid Concaténation de chaînes Positionnez vous dans la page Numéro commande et ouvrez la boîte à outils Visual Studio. Localisez la catégorie Fonctoids de chaîne et faites glisser le fonctoid nommé Concaténation de chaînes dans la page Numéro commande

275 Lorsque le fonctoid se trouve dans la page Numéro commande, faites glisser le champ CodeClient du message source sur le fonctoid. Procédez à la même opération avec le champ DateCommande. Sélectionnez ensuite le fonctoid et faites glisser la souris sur le champ NumeroCommande du message destination. Vous obtenez le résultat suivant : Le fonctoid Concaténation de chaînes va récupérer le numéro de client issu du message source et le concaténer avec la date de commande, elle aussi issue du message source. Le résultat de la concaténation est envoyé dans le champ NumeroCommande du message destination. Testez le comportement de cette map et vérifiez que le résultat produit est celui attendu. c. Modifier l ordre des paramètres d entrée Si vous souhaitez modifier l ordre de la concaténation, par exemple en concaténant tout d abord la date de commande puis le numéro de client, voici comment procéder. Sélectionnez le fonctoid et ouvrez la page de propriété correspondante. Localisez la propriété Paramètres d entrée et cliquez sur le bouton... situé à droite de la propriété. Dans l écran Configurer les entrées de fonctoid, vous retrouvez l ensemble des paramètres en entrée du fonctoid et vous pouvez modifier l ordre grâce aux boutons représentant des flèches :

276 d. Étiqueter les liens d une map Si Xpath est votre langue maternelle, vous n aurez pas de problème pour savoir que le premier paramètre listé dans cet écran est bien le numéro de commande et pas la date de livraison. Si comme moi vous n avez pas eu la chance d apprendre Xpath dans votre enfance, vous préférerez avoir une liste de paramètres qui ressemblent à celle ci après

277 Pour nommer les paramètres d entrée d un fonctoid, vous pouvez tout simplement associer un nom aux connecteurs entrants dans le fonctoid : Dans la page Numéro commande, sélectionnez le lien qui relie le numéro de client au fonctoid de concaténation de chaînes. Saisissez une valeur dans la propriété Etiquette pour nommer ce lien. Réitérez cette opération pour le champ Date de commande. Je vous conseille de procédez à cette opération pour les liens que vous utilisez en entrée des fonctoids. La lecture de la map et de la configuration des fonctoids sera plus claire. e. Utilisation de valeurs constantes Supposons maintenant que le résultat de la concaténation du numéro de client et de la date de commande fonctionne correctement mais que le format de la chaîne obtenue ne convienne pas. Il faut séparer le numéro de client et la date du caractère " ". Nous allons utiliser une constante saisie directement dans les paramètres du fonctoid de concaténation de chaîne : Sélectionnez le fonctoid et ouvrez les paramètres d entrée. Cliquez sur le second bouton de la barre d outils (qui représente une étoile sur un carré) pour créer une nouvelle constante et saisissez la valeur de cette constante :

278 Implémenter de la logique dans une map 1. Les règles à respecter Une transformation n est pas toujours simple et il est souvent nécessaire d implémenter de la logique pour procéder aux opérations adaptées. Le travers que je rencontre très fréquemment sur des projets BizTalk est d intégrer dans les maps de la logique métier. Une map ne doit pas porter de la logique métier puisque son rôle est de transformer et transcodifier. Il n est pas bienvenu d intégrer dans une map la logique qui permet le calcul du rabais accordé à un client en fonction des règles métiers de l entreprise. Pourquoi? La réponse tient en plusieurs remarques : Si vous implémentez plusieurs maps de transformation vous devez dupliquer cette logique dans chaque map. La complexité des règles métier de l entreprise peut être telle que l usage d une map rendrait bien trop complexe leur implémentation. La complexité pour mettre au point la map malgré la présence d outils de débogage ou de tests. L implémentation d une algorithmie complexe dans une map n est pas simple et vous pouvez donc consommer beaucoup d énergie à la faire fonctionner. Vous apprendrez dans le chapitre Implémentation des processus métier que des solutions bien plus adaptées existent dans BizTalk pour l implémentation des règles métier. Je vous invite également à consulter la documentation BizTalk pour comprendre le fonctionnement du moteur de règles métier. 2. Fonctoids logiques et clause IF Bien qu il ne soit pas souhaitable d implémenter des règles métiers dans les maps, certaines transformations nécessitent la mise en œuvre d une logique particulière. Nous allons illustrer cela en modifiant le comportement de la map CommandeToPivot. Nous souhaitons concaténer le code du client et la date de commande mais uniquement si la date de commande n est pas vide. Si la date est vide, nous calculons la date du jour et la concaténons avec le code client. Le numéro de commande obtenu sera : soit la concaténation du code client et de la date de commande ; soit la concaténation du code client avec la date du jour. La copie d écran ci dessous illustre cette transformation qui utilise un fonctoid de calcul de date, des fonctoids logiques et des fonctoids avancés. Je vous invite à consulter le code source de la map pour comprendre la logique. Consulter le fichier

279 Chapitre9_CommandeToPivotAvecFonctoidLogique.btm disponible en téléchargement. a. Alternatives aux fonctoids logiques Dans l exemple précédent, nous avons utilisé les fonctoids logiques afin d implémenter l équivalent d une clause If / Then / Else, sans pour autant écrire de lignes de code. Nous avons utilisé 7 fonctoids différents pour mettre en œuvre cette logique. Imaginez si vous deviez implémenter une dizaine d opérations logiques de ce type dans la même map... Heureusement, il existe d autres alternatives permettant la mise en œuvre de logiques dans une map : l utilisation du fonctoid Script ; l utilisation d un fonctoid ad hoc. 3. Fonctoid Script a. Rôle du fonctoid Script Le fonctoid Script est un fonctoid qui permet : l implémentation de code en ligne (C#, VB.Net, Jscript ou XSLT) ; l appel de composants.net externes. Vous pouvez utiliser des classes du Framework.Net directement depuis une map ou utiliser du code XSLT. b. Implémentation d une logique avec le fonctoid Script Nous allons illustrer dans ce paragraphe l utilisation du fonctoid Script. Nous allons remplacer les fonctoids logiques utilisés pour la génération du numéro de commande : Dans la map, page Numéro de commande, supprimez tout d abord tous les fonctoids utilisés. Déposez le fonctoid Script, reliez les champs DateCommande et Numero de client au fonctoid Script. En sortie, reliez le fonctoid Script au champ Numero Commande du message destination : Ouvrez les propriétés du fonctoid Script. Sélectionnez l option Inline C# et saisissez le code suivant :

280 Le code C# du script est repris ci dessous : public string CalculeNumeroCommande(string codeclient, string datecommande) { if (datecommande==system.string.empty) return codeclient + "_" + System.DateTime.Now.ToString("s"); else return codeclient + "_" + datecommande; } Lorsque vous déboguez la map, vous pouvez également déboguer le code C# du fonctoid. Testez la map depuis Visual Studio et déployez la dans BizTalk afin de mesurer qu elle fonctionne correctement. Si vous êtes fan de VB.Net, vous pouvez coder avec ce langage. C est l un des rares instants dans un projet BizTalk où vous pourrez vous passer de C#, profitez en. c. Limites du fonctoid Script Bien que le fonctoid Script offre des fonctionnalités très pratiques pour l implémentation de logiques dans une map, il a certaines limites. Je vous conseille donc de prendre en compte ces limites lorsque vous choisissez ce fonctoid : Aucune aide à la saisie de code : lorsque vous codez dans le fonctoid Script (Inline C# par exemple), vous n avez pas les traditionnelles fonctions d aide à la saisie présentes dans Visual Studio (Intelisense). Aucune coloration de code : le code saisi dans le fonctoid Script n est pas coloré comme c est le cas dans du code Visual Studio. Fenêtre de saisie de code limitée : la taille de la fenêtre de saisie de code est limitée ce qui ne facilite pas la

281 saisie d un gros volume de code. Si les limites de ce fonctoid handicapent l implémentation de votre map, c est certainement qu il n est pas adapté à votre besoin. Utilisez donc une autre solution. 4. Créer son propre fonctoid Lorsque l implémentation est complexe avec les fonctoids logiques, et lorsque le fonctoid Script n est pas adapté, vous pouvez créer votre propre fonctoid. La création de ses propres fonctoids a du sens à partir du moment où vous réutilisez le fonctoid dans la même map ou dans d autres maps. La création d un fonctoid est simple. Il faut implémenter une classe qui dérive de la classe mère Microsoft.BizTalk.BaseFunctoids.BaseFunctoid. La classe que vous implémentez contient l algorithme du fonctoid, plus ou moins complexe. Vous pouvez même faire appel à des ressources tierces (bases de données, fichiers de configuration, classes du Framework.Net...). Afin d utiliser un fonctoid, il faut le déployer sur le poste de développement mais également dans le GAC du serveur BizTalk. Pensez donc à intégrer les assemblies qui renferment vos fonctoids dans les ressources de vos applications BizTalk. Le projet codeplex de Jan Eliasen ( contient un fonctoid If-Then-Else qui encapsule une logique équivalente à celle que nous avons mise en place avec les deux méthodes illustrées dans les précédents paragraphes. Les exemples de code livrés avec BizTalk Server contiennent un exemple nommé CustomFunctoid qui illustre la création d un fonctoid. Je vous conseille de consulter cet exemple si vous souhaitez créer votre propre fonctoid

282 Effectuer des calculs dans une map 1. Calculs simples Dans la map permettant de passer d une commande au format pivot, nous n avons pas encore renseigné les données relatives aux produits. Les trois informations suivantes doivent être renseignées dans le message destination : Le code du produit que nous renseignerons dans le paragraphe Transcoder des données dans une map. La quantité que nous pouvons renseigner par simple recopie de la quantité du message source. Le prix unitaire que nous devons calculer à partir du prix unitaire du produit et du rabais accordé au client. Pour calculer le prix unitaire et le stocker dans le message destination, nous utilisons le fonctoid Soustraction. Comme son nom l indique, il permet de soustraire des valeurs entre elles : Déposez le fonctoid Soustraction puis faites glisser les champs PrixUnitaire et RemiseClient en entrée du fonctoid. Reliez le fonctoid sur le champ destination nommé PrixUnitaire. Par souci de clarté, j ai créé une page nommée Calcul du prix. Voici pourquoi dans cette copie d écran vous n avez pas d autres liens que ceux relatifs aux produits. Avec ce type de fonctoid, nous pouvons effectuer de simples calculs sur les données. 2. Calculs cumulatifs Il est parfois nécessaire d effectuer des calculs cumulatifs comme : le prix moyen des produits commandés par un client ; la somme des montants des produits commandés. Nous allons illustrer ce scénario grâce à la map PivotToCommande.btm du projet ENI.Compta.Maps. Souvenez vous, cette map doit produire un message de type Commande destiné à l application de Comptabilité à partir d une commande pivot. Dans le message attendu par la comptabilité, seul le montant total hors taxes de la commande est nécessaire, le détail des produits commandés n est pas nécessaire. Nous allons demander à la map de calculer le montant commandé pour chaque produit (c est à dire la quantité multipliée par le prix unitaire) puis faire la somme de ces montants pour obtenir le montant total

283 Nous allons utiliser deux fonctoids différents : Le fonctoid Multiplication pour obtenir le montant de chaque produit. Le fonctoid Somme cumulée pour sommer tous les montants. Ouvrez la map PivotToCommande.btm du projet ENI.Compta.Maps. Déposez le fonctoid Multiplication et reliez en entrée les champs Quantite et PrixUnitaire du message source : Dans le message pivot, le nœud Produit peut apparaître un nombre illimité de fois ce qui signifie qu une commande peut contenir de 1 à N produits. Nous allons utiliser le fonctoid Somme cumulée. Ce fonctoid prend deux paramètres en entrée : L information qu il faut sommer (dans notre cas le résultat de la multiplication). L étendue sur laquelle il faut itérer pour effectuer la somme. Il s agit du nœud Produit. Étant donné que ce nœud apparaît plusieurs fois, le cumul va s effectuer autant de fois qu il y aura de produits. Déposez le fonctoid Somme cumulée. En entrée, reliez tout d abord la sortie du fonctoid Multiplication puis reliez le nœud Produit du message source. En sortie, reliez le fonctoid au champ MontantHTCommande du message destination. L ordre des paramètres en entrée du fonctoid Somme cumulée est important : en premier les données à cumuler puis l étendue du cumul. Testez la map avec en entrée un message comportant de multiples produits

284 Transcoder des données dans une map Nous venons de voir comment les maps peuvent transformer les données ou appliquer des algorithmes sur les données pour les calculer ou les sommer. Nous allons nous intéresser maintenant au transcodage des données. Lorsque vous dialoguez avec des partenaires externes à votre entreprise, vous serez confronté très fréquemment à des situations où la manière d identifier une information est différente. Votre client dispose de codes produits qui lui sont propres et lorsqu il vous transmet une commande vous devez rapprocher les codes produits avec vos références produits. Vous transcodez les données d une nomenclature source vers une nomenclature destination. La map est le composant le plus approprié dans BizTalk pour réaliser ce type d opération et plusieurs approches sont possibles en termes d implémentation. Nous allons évoquer plusieurs alternatives dans ce paragraphe. 1. Utilisation des fonctoids base de données a. Principes et rôles des fonctoids Les fonctoids base de données permettent, comme leur nom l indique, de se connecter à une base de données et de requêter celle ci pour récupérer des informations. Ces fonctoids sont adaptés à la récupération d informations pour le transcodage. Nous disposons, dans une base de données, des codes produits des clients et leurs correspondances en codes produits internes. Ces données de transcodage (que l on appelle le plus souvent tables de mappings) vont être utilisées par BizTalk et peuvent être même partagées avec d autres applications de votre Système d Information. Voici comment fonctionnent les fonctoids base de données : Le fonctoid Rechercher dans la base de données (Database Lookup) se connecte à la base de données avec une chaîne de connexion qui lui est fournie. La configuration de ce fonctoid précise également la table ou vue SQL dans laquelle il faut effectuer la clause SQL SELECT, la colonne dans laquelle il faut rechercher une valeur ainsi que la valeur à rechercher. Ce fonctoid retourne un jeu d enregistrements contenant de 0 à N lignes. Le fonctoid Extracteur de valeurs (Value Extractor) récupère le jeu d enregistrement produit par le fonctoid Rechercher dans la base de données et extrait la valeur d une colonne particulière du premier enregistrement de données. La sortie de ce fonctoid est ensuite connectée au champ destination ou à un autre fonctoid. Le fonctoid Retour d erreur (Error Return) est connecté au fonctoid Rechercher dans la base de données et retourne le message d erreur correspondant à une éventuelle erreur d exécution lors de la requête à la base de données. b. Implémentation Voici comment utiliser ces fonctoids pour transcoder le code produit. Afin de réaliser l exercice, vous pouvez récupérer les scripts SQL permettant de créer une base de données avec des données de transcodage. Récupérez le fichier nommé Chapitre9_BaseDeDonnees.sql. La table SQL Server sur laquelle nous allons nous baser pour le transcodage contient les données suivantes : CodeProduitExt CodeProduitInt CocotteMinute C10 Fritteuse F10 GrillePain G13 (3 ligne(s) affectée(s)) Avant de mettre en place les fonctoids, nous devons récupérer la chaîne de connexion à la base de données car c est un paramètre que nous devons fournir au fonctoid Rechercher dans la base de données :

285 Si vous ne connaissez pas cette chaîne de connexion, créez un fichier texte avec l extension.udl (nommez le par exemple ENIEditions.udl). Ne saisissez rien dans le fichier. Double cliquez dessus et suivez l assistant de connexion pour remplir les paramètres de connexion à votre serveur SQL Server

286 Lorsque vous avez terminé et testé la connexion, ouvrez le fichier ENIEditions.udl avec le bloc notes et récupérez la chaîne de connexion. Vous pouvez également utiliser le site qui contient des centaines d exemples de chaînes de connexion aux bases de données. Nous allons maintenant modifier la map CommandeToPivot.btm du projet ENI.GestCo.Maps : Ouvrez la map. Déposez le fonctoid Rechercher dans la base de données et reliez le champ Reference du produit du message source sur ce fonctoid. Ouvrez les propriétés du fonctoid et renseignez dans l ordre, la chaîne de connexion, le nom de la table (CodeProduit) et le nom du champ dans lequel il faut rechercher la valeur (CodeProduitExt) : Lorsque ce fonctoid va s exécuter, la clause SQL suivante sera exécutée : SELECT * FROM CodeProduit WHERE CodeProduitExt=<Reference>. <Reference> sera remplacé par la valeur du code produit issue du message source. Si plusieurs produits sont présents dans le message source, la requête sera exécutée autant de fois qu il y a de produits. Déposez ensuite le fonctoid Extraire les valeurs. Reliez la sortie du fonctoid Rechercher dans la base de données à ce fonctoid. Dans ses propriétés saisissez le nom de colonne dans lequel il faut récupérer le code produit transcodé. Il s agit de la colonne CodeProduitInt :

287 Voici la map que vous devez obtenir à l issue des manipulations. Vous pouvez tester son comportement. c. Paramétrage de la chaîne de connexion à la base de données Dans l exemple ci dessus, la chaîne de connexion à la base de données a été saisie en dur dans le fonctoid Rechercher la base de données. La chaîne de connexion est ainsi stockée directement dans la map et si cette chaîne varie entre les environnements de développement, recette et production, la map ne fonctionnera pas. Pour être plus précis, ce scénario pourrait fonctionner si vous créez un alias vers l instance SQL Server et si cet alias est le même sur chaque environnement. La création d un alias SQL est possible via l outil de configuration client de SQL Server. Il faut donc sortir la chaîne de connexion de la map en permettant de la paramétrer en dehors. Il y a plusieurs approches pour gérer la configuration dans BizTalk. L une des approches possibles est le stockage de paramètres de configuration dans le fichier app.config de BizTalk. Il s agit du fichier BTSNTSvc.exe.config situé dans le répertoire d installation de BizTalk. Il s agit d un fichier de configuration.net traditionnel que vous pouvez enrichir avec vos propres paramètres comme l extrait de fichier suivant l illustre :

288 <?xml version="1.0"?> <configuration> [... <appsettings> <add key="enieditionssqlconnectionstring" value="provider=sqloledb.1;integrated Security=SSPI;Persist Security Info=False;Initial Catalog=ENIEditions;Data Source=BTS2009FR"/> </appsettings> </configuration> Afin de récupérer, depuis la map, la valeur d un paramètre de ce fichier de configuration, vous pouvez utiliser un fonctoid Script avec du code.net en utilisant la classe ConfigurationManager du framework.net. Vous pouvez également utiliser le fonctoid Read Application Config de la bibliothèque de fonctoids de Jan Eliasen ( qui facilite l accès aux paramètres de configuration. d. Transcodage avec le fonctoid Script Le fonctoid Script peut également être utilisé pour le transcodage. Je vous conseille de l utiliser afin d invoquer du code.net externe. Si vous disposez de classes.net qui implémentent déjà l accès aux données de votre base de transcodage, vous pouvez les réutiliser avec ce fonctoid ou bien créer ces classes utilitaires spécifiques. Je vous déconseille fortement d implémenter directement en Inline C# le code d accès aux données. e. Les fonctoids Cross Referencing BizTalk est livré avec un ensemble de services et de composants permettant le stockage de données de transcodage et leur utilisation. Ces fonctionnalités nommées Cross Referencing sont très peu documentées. Les fonctionnalités Cross Referencing de BizTalk reposent sur trois composants : Des tables SQL Server permettant le stockage des données à transcoder. Un outil pour injecter les données dans les tables de stockage. Des fonctoids pour utiliser facilement ces données depuis des maps. Tables SQL Server Les tables pour stocker les données à transcoder se situent dans la base de données BizTalkMgmtDb (c est à dire la base de configuration de BizTalk). Ces données sont donc sauvegardées en même temps que la configuration de BizTalk et ne sont pas stockées à l extérieur du système. C est un gage de cohérence et de consistance du système. Outil d injection de données L outil permettant de nourrir les tables SQL Server se nomme BizTalk Server Cross Reference Import Tool. Il s agit d un utilitaire en ligne de commande nommé btxrefimport.exe situé dans le répertoire d installation de BizTalk Server. Cet outil se nourrit d une collection de fichiers XML normalisés (dont la structure est documentée) et injecte les données dans SQL Server. Fonctoids de transcodification Plusieurs fonctoids permettent d utiliser les données stockées dans les tables SQL Server. Il s agit des fonctoids suivants : Obtenir la valeur courante Obtenir l ID courant Obtenir la valeur de l application

289 Obtenir l ID de l application Supprimer l identificateur de l application Définir l ID courant Ces fonctoids sont disponibles dans la catégorie Fonctoids de base de données dans la boîte à outils de l éditeur de map. Il faut l avouer, l utilisation de cette fonctionnalité de transcodification n est pas, au début, très naturelle ni très facile d accès. Elle est surtout si peu connue qu il n existe quasiment pas de retour d expérience sur son utilisation ni même d exemples. Les fonctionnalités de Cross Referencing BizTalk sont intéressantes et peuvent vous permettre d accélérer votre implémentation tout en s appuyant sur infrastructure de stockage solide (puisqu il s agit de la base de données de configuration BizTalk). En revanche, si vous disposez déjà de tables de transcodifications dans vos applications, vous préférerez les réutiliser et ne pas avoir à maintenir deux sources de données différentes. L outil d injection de données dans les tables de stockage est relativement rudimentaire et si vous souhaitez offrir une interface graphique aux utilisateurs de votre système, vous devez l implémenter vous même. Enfin, les fonctionnalités de Cross Referencing n offrent pas de mécanismes de cache permettant par exemple la prise en compte de scénarios dans lesquels des milliers de transcodifications s exécutent en même temps

290 Conlusion Les maps permettent de résoudre des problèmes complexes de transformations, transcodifications et fournissent donc des outils (les fonctoids) permettant de simplifier ces opérations. Nous avons traité dans ce chapitre un périmètre très restreint des possibilités offertes par les fonctoids. Je vous invite à parcourir les fonctoids de la boîte à outils BizTalk pour les découvrir et les mettre en œuvre. Certains, comme le Bouclage de table, nécessitent un peu de pratique mais s avèrent des outils très performants et très puissants. Dans certains cas, vous devrez utiliser directement du code XSLT dans vos maps. Je vous conseille de ne pas généraliser cette approche, même si vous maîtrisez ce langage, car vous pouvez rendre les maps très complexes à maintenir. Essayez donc de mixer les fonctoids standards disponibles dans BizTalk ou dans des boîtes à outils tierces et du code XSLT quand cela est nécessaire ou plus performant

291 Introduction aux pipelines Dans les précédents chapitres, nous avons utilisé les pipelines sans rentrer dans le détail de leur fonctionnement. Nous avons notamment utilisé le pipeline XMLReceive pour réceptionner des messages XML, pour les vérifier et promouvoir des données dans le contexte. Dans ce chapitre nous allons mieux comprendre le fonctionnement d un pipeline et des composants de pipelines qui le composent. 1. Rôle de pipelines Que ce soit lors de la réception de messages ou lors d envoi, la présence d un pipeline est obligatoire. Les pipelines sont en quelque sorte le sas entre le monde extérieur et BizTalk. Les pipelines constituent donc le meilleur endroit pour effectuer des traitements avant que le message ne soit publié dans la MessageBox ou avant qu il soit transporté vers un destinataire. Il existe deux catégories de pipelines, les pipelines de réception et les pipelines d envoi. Leurs noms sont suffisamment clairs pour que vous compreniez leur rôle respectif. 2. Pipeline de réception a. Exécution d un pipeline de réception Le schéma ci dessous illustre le processus de réception d un message : Le pipeline de réception se positionne entre l adaptateur et la map de transformation, il s exécute donc immédiatement après le traitement par l adaptateur et juste avant l application de la transformation. En cas d erreur lors de l exécution du pipeline, le message est suspendu et la transformation n est pas exécutée. Si vous relancez le message suspendu, le pipeline est de nouveau exécuté comme si le message entrait de nouveau dans BizTalk. b. Architecture d un pipeline de réception Les étapes d un pipeline de réception Un pipeline de réception est composé d étapes (le terme anglais est stage) :

292 Le message qui entre dans le pipeline passe par l ensemble des étapes de celui ci. Chaque étape peut contenir de 0 à N composants de pipelines. Ces composants de pipelines (livrés avec BizTalk ou développés spécifiquement) appliquent des traitements sur le message. Le rôle de chaque étape est le suivant : Décoder : cette étape sert en principe à décoder le message, c est à dire à le décrypter. Si cela est nécessaire, cette étape contient un composant de décodage PGP (Pretty Good Privacy) ou SMIME (Secure Multipurpose Mail Extension) par exemple. Désassembler : cette étape permet de vérifier le format du message (XML bien formé par exemple), de le désassembler, c est à dire de le transformer au format XML (quand il s agit d un fichier plat ou EDI). Le message peut également être découpé à cette étape lorsqu il s agit d un batch. Reportez vous au paragraphe Découpage de messages lors de la réception pour en savoir plus. À l issue de cette étape, si un découpage a eu lieu, plusieurs messages sont produits. Les étapes qui suivent peuvent donc s exécuter autant de fois qu il y a de messages. Valider : l étape de validation est normalement utilisée pour valider qu un message est strictement conforme par rapport à une spécification de message. La plupart du temps, cette étape est faite en même temps, que le désassemblage. Résoudre tiers : cette dernière étape, juste avant l éventuelle transformation du message par une map permet de vérifier si le tiers, qui transmet le message, est connu de BizTalk. Cela suppose de déclarer les tiers, appelés partenaires dans BizTalk. Si le tiers est résolu, des informations à son sujet sont ajoutées dans le contexte du message. Le comportement des composants dans les différentes étapes Les étapes ne fonctionnent pas toutes selon le même mode : Les étapes Décoder, Valider et Résoudre tiers peuvent avoir plusieurs composants. Chaque composant est exécuté séquentiellement. Ces étapes peuvent contenir jusqu à 255 composants. L étape Désassembler peut également contenir plusieurs composants mais un seul ne peut être exécuté. Lorsqu un message passe par cette étape, le premier composant est exécuté. Si son exécution est réussie, le message passe à l étape Valider, sinon le composant suivant est exécuté. Si aucun composant ne peut être exécuté sans erreur, le pipeline tout entier est en erreur et le message est suspendu. On parle alors d erreur de désassemblage. c. Les pipelines de réception standards de BizTalk BizTalk est livré avec plusieurs pipelines de réception : PassThruReceive : ne contient aucun composant à aucune étape. Il n opère donc aucun traitement sur le message. XMLReceive : contient le composant Désassembleur XML à l étape Désassembler et le composant Résolution de tiers à l étape Résoudre tiers. Ces pipelines sont contenus dans l assembly Microsoft.BizTalk.DefaultPipelines.dll déployée dans l application BizTalk.System. 3. Pipeline d envoi a. Exécution d un pipeline d envoi

293 Le schéma ci dessous est l illustration du processus d envoi. Le pipeline d envoi s exécute immédiatement après la transformation et juste avant le transport du message par l adaptateur : b. Architecture d un pipeline d envoi Un pipeline d envoi est composé d étapes illustrées dans le schéma ci dessous : Le rôle de chaque étape est le suivant : Préassembler : réalise des opérations sur le message avant qu il ne soit transmis à l étape d assemblage. Assembler : permet de formater le message en XML ou au contraire au format EDI ou Fichier plat. Coder : permet par exemple de changer l encodage du message (UTF 8, ANSI...) ou bien de chiffrer le message. Tout comme le pipeline de réception, les étapes peuvent contenir jusqu à 255 composants. L étape de désassemblage n exécute qu un seul composant alors que les autres étapes exécutent les composants séquentiellement. c. Les pipelines d envoi standards de BizTalk BizTalk est livré avec les deux pipelines d envoi suivants : PassThruTransmit : ne contient aucun composant donc n agit pas sur le message. XMLTransmit : contient le composant d assemblage XML qui vérifie que le message est XML et conforme à des schémas déployés. 4. Que faut il faire dans un pipeline? La frontière entre ce que doit faire un pipeline et ce que fait une map est parfois très étroite. Si l on devait fixer une règle pour répartir correctement les rôles, voici ce que nous pourrions dire :

294 Une map effectue des opérations fonctionnelles sur les données : des traductions, transcodages et transformations. Une map ne décrypte pas un message ou ne transforme pas un fichier plat en un fichier XML ou inversement. Un pipeline effectue des opérations techniques, plutôt bas niveau. Le pipeline n agit pas réellement sur les données fonctionnelles mais produit des messages compréhensibles, d un point de vue technique, pour le reste de la chaîne d exécution. Il s agit d opérations techniques comme l encodage, le déchiffrage, le découpage de messages... Bien entendu aucune contrainte technique ne vous empêche d appliquer une feuille XSLT dans un pipeline et donc d implémenter l équivalent d une map. Je ne donne pas cet exemple par hasard car je l ai déjà rencontré chez un client. Certes, ce fonctionnement est pratique, par exemple pour appliquer deux maps successivement : ce que ne permet pas BizTalk nativement, mais je pense que l utilisation des fonctionnalités standards de BizTalk reste la meilleure approche pour construire des solutions pérennes, solides et sachant suivre les évolutions du produit. 5. Le mode d exécution d un pipeline Les pipelines, d envoi ou de réception, sont conçus pour traiter des messages volumineux, faisant plusieurs centaines de mégaoctets. Lorsqu un message transite par les composants d un pipeline, le contenu du message n est jamais entièrement chargé en mémoire par chaque composant. Ceci permet de réceptionner des messages volumineux, mais aussi de gérer la réception de plusieurs centaines de messages en même temps par plusieurs instances du pipeline. Les messages sont traités par les pipelines en streaming. Quand j ai indiqué plus haut dans le chapitre qu un pipeline de réception s exécutait immédiatement après l adaptateur, il faut nuancer par rapport à ce fonctionnement en streaming. Le pipeline commence en réalité son exécution dès qu une partie du message a été traitée par l adaptateur. Ce fonctionnement garantit une consommation constante de la mémoire tout au long du pipeline. Le volume de mémoire utilisé par le pipeline est constant puisqu à un instant T, une seule partie du message est chargée en mémoire. Afin que ce modèle d exécution soit respecté, les composants de pipelines doivent être développés en utilisant des streams. Les composants livrés avec BizTalk respectent cette règle mais c est très rarement le cas des composants de pipelines développés spécifiquement ou intégrés aux boîtes à outils commerciales. Soyez donc vigilants avec les composants de pipelines tiers et menez des tests de performance sur la réception et l envoi de messages volumineux. 6. Les pipelines standards EDI Lorsque vous utilisez l adaptateur EDI de BizTalk, permettant l envoi et la réception de messages EDIFACT, X12 par exemple, différents pipelines de réception et d envoi sont installés. Contrairement aux pipelines standards BizTalk, ils sont déployés dans l application BizTalk EDI Application et contenus dans différentes assemblies dont Microsoft.BizTalk.Edi.EdiPipelines.dll

295 Utilisation des pipelines Avant d étudier l implémentation de nos propres pipelines (cf. paragraphe Créer ses propres pipelines), nous allons utiliser et configurer des pipelines standards de BizTalk. Nous avons déjà utilisé les pipelines pour la réception de messages XML, nous allons revenir très rapidement sur quelques notions. Pour plus de détail, lisez le chapitre Déploiement et utilisation de schémas. 1. Associer un pipeline à un port ou un emplacement L association d un pipeline à un port d envoi ou à un emplacement de réception est obligatoire. C est d ailleurs pour cette raison qu il existe deux pipelines complètement vides (PassThruReceive et PassThruTransmit). Pour être associable à un port via la console d administration, un pipeline doit : faire partie de la même application que le port/emplacement ; faire partie d une application qui est référencée par l application du port/emplacement. Toutes les applications du groupe BizTalk référencent automatiquement l application BizTalk.System dans laquelle se trouvent les pipelines standards. C est pour cette raison qu ils sont utilisables depuis n importe quelle application. 2. Configurer les pipelines Un pipeline contient plus ou moins de composants, 2 pour le pipeline de réception XMLReceive. Ces composants de pipeline, réutilisables dans d autres pipelines, sont parfois configurables. C est le cas du Désassembleur XML sur lequel nous pouvons préciser un ensemble de paramètres et modifier son comportement. La configuration d un pipeline revient à faire la configuration de ses différents composants. Deux approches sont possibles pour configurer un pipeline. a. Configuration par instance La configuration d un pipeline par instance, consiste à configurer le pipeline lorsqu il est lié à un port ou un emplacement. La configuration n est donc pas pour le pipeline dans l absolu mais pour son utilisation dans un contexte en particulier. La configuration par instance d un pipeline s opère dans la configuration du port ou de l emplacement de réception. Pour configurer le pipeline XMLReceive utilisé dans l emplacement de réception rcvgestioncommerciale_file, vous ouvrez les propriétés de l emplacement puis cliquez sur le bouton "..." en face du pipeline. Vous obtenez une fenêtre de configuration dans laquelle se trouvent tous les composants configurables :

296 Dans l exemple ci dessus, les deux composants (Désassembleur XML et Résolution de tiers) peuvent être configurés. Si vous modifiez les paramètres de ces composants, cette configuration est associée à l emplacement de réception et stockée dans les paramètres de l application. Lorsque vous exportez l application sous forme d un fichier de liaisons ou d un package MSI, la configuration du pipeline est également exportée. Si vous associez le pipeline XMLReceive à un autre emplacement de réception, une nouvelle configuration de ce pipeline doit être effectuée. C est pour cette raison que l on parle de configuration par instance. La configuration par instance est devenue bien plus simple et plus accessible avec la version 2006 de BizTalk. Dans les versions précédentes, le recours à des outils tiers était nécessaire, notamment l outil PipelineViewer.exe. b. Configuration statique À l inverse de la configuration par instance, la configuration statique d un pipeline s applique à toutes les instances de pipeline utilisées dans toutes les applications BizTalk. Cette configuration des composants du pipeline fait partie de l assembly qui contient le pipeline. Lorsque vous utilisez le pipeline, la configuration statique du pipeline est automatiquement appliquée. Toutefois, vous pouvez modifier cette configuration lorsque vous utilisez le pipeline dans un port ou un emplacement. Vous effectuez dans ce cas une configuration par instance qui vient remplacer ou compléter la configuration statique du pipeline. Afin de configurer un pipeline de manière statique, il est nécessaire de passer par une phase de développement. Cette opération de configuration s opère en effet dans Visual Studio avant la compilation du pipeline. Étant donné que vous n avez pas le code source des composants de pipelines standards BizTalk, vous ne pouvez pas modifier leur configuration statique. Nous allons illustrer la configuration statique dans la suite de ce chapitre lors de la création de notre propre pipeline. Étant donné que la configuration par instance était très peu accessible dans les précédentes versions de BizTalk, un très grand nombre de pipelines spécifiques a été implémenté dans les projets de développement. Au lieu de configurer spécifiquement le pipeline XMLReceive dans un emplacement de réception, les équipes ont créé un clone du pipeline XMLReceive avec une configuration statique. À l issue du

297 développement, il n est pas rare d avoir autant de pipelines que d emplacements de réception. C est une situation à éviter car elle alourdit énormément le développement. 3. Découpage de messages lors de la réception Nous allons mettre en pratique l utilisation des pipelines standards avec un scénario que vous rencontrerez fréquemment dans vos projets. a. Processus de réception de messages "batchs" Dans les chapitres précédents, nous avons reçu des commandes en provenance de la gestion commerciale. Chaque message reçu contenait une et une seule commande. Nous allons faire évoluer ce scénario en considérant que l application de gestion commerciale nous transmet désormais une liste de commandes chaque soir au lieu de le faire au fil de la journée. BizTalk doit recevoir ce lot de commandes et traiter chaque commande unitairement pour les envoyer, une par une, à l application de Comptabilité. Nous l allons pas remettre en cause tous nos développements, nous allons simplement modifier la manière dont les messages sont reçus par BizTalk. Au lieu de publier dans la MessageBox un message contenant de multiples commandes, nous allons découper le message pour produire autant de messages que de commandes et ainsi publier chaque commande unitairement dans la MessageBox. Le schéma ci dessous illustre le fonctionnement de la réception : b. Rôle du pipeline de réception Le découpage des messages (appelé debatching), se déroule dans le pipeline de réception. Cette opération est effectuée par le composant de Désassemblage XML comme l indique le schéma ci dessous :

298 Le message est découpé à l étape Désassembler du pipeline de réception. À l issue de cette étape, plusieurs messages sont produits et chaque message est traité par l étape Valider et l étape Résoudre tiers du pipeline de réception. Si une map de transformation est associée au port de réception, elle sera exécutée autant de fois qu il y a de messages issus du découpage. c. Création d un schéma d enveloppe Pour que le composant de Désassemblage XML opère le découpage, il s appuie sur un schéma XSD particulier dit d Enveloppe. Ce schéma XSD contient des indications sur la manière de découper le message. Cette indication sur le découpage à effectuer est contenue dans la propriété BodyXPath du schéma. Nous allons donc créer un schéma XSD d enveloppe afin de représenter un message pouvant contenir de multiples commandes. Le nœud racine se nomme Commandes. Nous créons le schéma dans le projet ENI.GestCo.Schemas car il s agit d un format de commande propre à la gestion commerciale. Ouvrez le projet ENI.GestCo.Schemas et créez un nouveau schéma XSD. Nommez le Commandes.xsd. Renommez le nœud racine en Commandes. En sélectionnant le nœud <Schema>, associez l espace de noms urn:editionseni:gestco. Positionnez également la propriété Enveloppe à Oui. Le message Commandes étant une collection de messages de type Commande, nous devons inclure le schéma XSD correspondant à une commande afin de le réutiliser. Faites donc l inclusion du schéma Commande.xsd dans le schéma Commandes.xsd :

299 Étant donné que nous avons effectué une inclusion de schéma (et pas un import), nous avons plusieurs nœuds racine dans le même fichier XSD. Nous devons indiquer à BizTalk quel est le nœud racine à utiliser lors du déploiement du schéma. En sélectionnant le nœud <Schema>, positionnez la propriété Référence de racine à Commandes. Ajoutez un Enregistrement enfant que vous nommez Commande et associez à la propriété Data Structure Type la valeur Commande (Reference). Voici ce que vous devez obtenir : Modifiez la propriété Max Occurs du nœud Commande pour indiquer que plusieurs enregistrements de type Commande sont présents dans le message. Associez la valeur unbounded (ou *) à cette propriété. En positionnant la propriété Enveloppe à Oui, nous indiquons au schéma qu il peut être découpé. Nous devons préciser à quel endroit le découpage peut être opéré. Nous renseignons la propriété Xpath de corps (BodyXPath en anglais) accessible lorsque vous sélectionnez le nœud racine du schéma. Vous devez spécifier dans cette propriété une requête Xpath qui indique à BizTalk où se trouve le corps du message (le body). Un assistant vous accompagne dans la définition de cette propriété comme l indique la copie d écran ci dessous :

300 Dans notre cas, la requête Xpath associée à cette propriété est la suivante : /*[local-name()= Commandes and namespace-uri()= urn:editionseni:gestco ]. Nous avons terminé la définition d un schéma d enveloppe. Demandez à Visual Studio de générer un exemple de message. Complétez cet exemple en ajoutant plusieurs commandes à l intérieur. Dans l exemple ci dessous, nous avons trois commandes : <ns0:commandes xmlns:ns0="urn:editionseni:gestco"> <ns0:commande> <Client> <Numero>ENIEditions</Numero> <CodePostalLivraison>69000</CodePostalLivraison> <VilleLivraison>LYON</VilleLivraison> </Client> <Produit> <Reference>CocotteMinute</Reference> <Quantite>10</Quantite> <PrixUnitaire>10</PrixUnitaire> <RemiseClient>0</RemiseClient> </Produit> <DateCommande>19/02/2010</DateCommande> </ns0:commande> <ns0:commande> <Client> <Numero>ENIEditions</Numero> <CodePostalLivraison>39360</CodePostalLivraison> <VilleLivraison>VIRY</VilleLivraison> </Client> <Produit> <Reference>Fritteuse</Reference> <Quantite>10</Quantite> <PrixUnitaire>5</PrixUnitaire> <RemiseClient>0</RemiseClient> </Produit> <DateCommande>12/03/2010</DateCommande> </ns0:commande> <ns0:commande> <Client> <Numero>ENIEditions</Numero> <CodePostalLivraison>01510</CodePostalLivraison> <VilleLivraison>ARTEMARE</VilleLivraison> </Client> <Produit> <Reference>CocotteMinute</Reference> <Quantite>10</Quantite> <PrixUnitaire>10</PrixUnitaire>

301 <RemiseClient>0</RemiseClient> </Produit> <DateCommande>13/11/2009</DateCommande> </ns0:commande> </ns0:commandes> d. Déploiement et fonctionnement Vous pouvez déployer le projet ENI.GestCo.Schemas qui contient le schéma d enveloppe. Ne modifiez pas le port de réception rcvgestioncommerciale ni l emplacement de réception rcvgestioncommerciale_file. Vous allez vous rendre compte qu il n est pas utile de procéder à une configuration particulière pour que le découpage fonctionne. Procédez aux deux tests suivants : Déposez un message de type urn:editionseni:gestco#commande dans le répertoire d écoute. Déposez maintenant un message de type urn:editionseni:gestco#commandes dans le répertoire d écoute. Assurez vous de disposer dans le message de plusieurs commandes différentes. Lors des deux tests, les messages transitent dans BizTalk, sont transformés en messages pivots Commande puis sont de nouveau transformés au format attendu par l application de comptabilité. Le découpage opéré à la réception n a donc pas d effet sur la configuration de l application. Notre application peut recevoir des messages unitaires ou des messages avec un lot de commandes. Bien que BizTalk consomme un message de type urn:editionseni:gestco#commandes seuls les messages de type urn:editionseni:gestco#commande sont publiés dans la MessageBox puisqu il s agit des messages obtenus après le découpage. Nous ne traitons pas des paramètres avancés du debatching BizTalk dans cet ouvrage mais sachez qu il est possible de positionner des propriétés de configuration indiquant à BizTalk comment il doit se comporter en cas d erreur lors du découpage. Si l un des messages découpés provoque une erreur dans la map appliquée sur le port de réception, deux comportements peuvent être paramétrés dans BizTalk : Traiter les commandes comme un ensemble indivisible. Si l un des messages est en erreur, le lot complet est en erreur et aucun message n est publié dans la MessageBox. Traiter chaque commande du message d origine comme un message unitaire. En cas d erreur sur un message après découpage, le message est suspendu mais les autres messages sont publiés correctement. Cette configuration s opère sur le composant de désassemblage XML dans la propriété RecoverableInterchangeProcess. Par défaut cette propriété est positionnée à False, ce qui indique que tous les messages sont traités comme un lot indivisible

302 Créer ses propres pipelines Nous avons illustré l usage d un pipeline par défaut et comment ce type de pipeline peut nous offrir des services à forte valeur ajoutée. Il n est donc pas toujours nécessaire de créer ses propres pipelines. La création d un pipeline spécifique est nécessaire dans les cas suivants : Lorsque vous souhaitez ajouter un traitement particulier à un pipeline par défaut. Étant donné que vous ne pouvez pas modifier les pipelines par défaut, vous devez en créer un nouveau. Lorsque vous ne trouvez pas dans les pipelines par défaut les comportements que vous souhaitez implémenter. C est le cas de l envoi ou de la réception de fichiers plats que nous allons évoquer. Ne créez pas systématiquement des pipelines car cela n a pas d intérêt particulier en dehors des deux cas cités précédemment. La création d un pipeline suppose des tâches de développement et de déploiement que je vous conseille d éviter quand cela est possible. 1. Implémenter et configurer un pipeline a. Processus d implémentation L implémentation d un pipeline est effectuée dans Visual Studio. Un éditeur de pipeline (Pipeline Designer) permet de réaliser cette phase de développement. Un pipeline est stocké dans un fichier d extension.btp (pour BizTalk Pipeline). Comme les schémas ou les maps, les pipelines sont compilés dans une assembly BizTalk et lors du déploiement, sont détectés pour être déclarés dans la base de configuration de BizTalk. b. Contenu d un pipeline Un pipeline est composé de composants de pipelines issus d une boîte à outils de composants. Cette boîte à outil contient des composants génériques fournis par BizTalk et des composants que vous pouvez développer vousmême (cf. paragraphe Implémenter un composant de pipeline). La surface de dessin d un pipeline se présente comme suit (pour un pipeline de réception) :

303 Dans chaque étape du pipeline, vous déposez des composants issus de la boîte à outils : Après avoir déposé un composant dans une étape du pipeline, vous avez accès à ses propriétés et pouvez donc le configurer. La configuration du composant est enregistrée dans le pipeline : il s agit d une configuration statique du

304 pipeline que nous avons évoqué dans le paragraphe Configurer les pipelines de ce chapitre. 2. Réceptionner des fichiers plats Dans le chapitre Modélisation de messages, nous avons modélisé un schéma XSD pour gérer une commande fichier plat. Nous n avons cependant pas été en mesure de tester la réception d une commande dans ce format justement parce que la création d un pipeline spécifique est nécessaire. Nous allons créer notre propre pipeline pour réceptionner des fichiers plats. a. Création d un pipeline de réception Préparation des schémas de fichiers plats Pour ce nouvel exercice, nous allons réutiliser les schémas de fichiers plats modélisés dans le chapitre Modélisation de messages. Nous disposons de deux schémas, CommandePos.xsd et CommandeSep.xsd correspondant respectivement à un fichier plat positionnel et un fichier plat avec séparateur. Ces deux schémas correspondent à des messages pouvant être envoyés par la gestion commerciale. Pour être cohérent avec les conventions de nommage et le découpage des projets, procédez aux manipulations suivantes sur les deux schémas : Déplacez les fichiers.xsd dans le projet ENI.GestCo.Schemas. Modifiez l espace de noms XML de chaque schéma. Remplacez l espace de noms actuel qui est urn:editionseni:gestioncommandes par urn:editionseni:gestco. Supprimez les propriétés promues des deux schémas ainsi que les références vers le schéma de propriété. Création du pipeline de réception Créez un nouveau projet dans la solution ENI.BizTalk. Nommez ce projet ENI.GestCo.Pipelines. Positionnez les propriétés habituelles de signature et de déploiement sur le projet, afin que l assembly générée puisse être déployée dans l application ENIEditions. Ajoutez un nouvel élément de type Pipeline de réception dans le projet et nommez le rpicommandepos.btp. Il s agit du pipeline de réception des commandes au format fichier plat positionnel. Pour permettre la réception d un fichier plat et sa transformation en XML, nous allons utiliser un désassembleur de fichiers plats. Sélectionnez le composant Désassembleur de fichier plat dans la boîte à outils et déposez le à l étape Désassembler du pipeline : Afin que le désassembleur de fichier plat fonctionne correctement, nous devons lui indiquer le schéma XSD du fichier plat à réceptionner : Étant donné que le schéma de fichier plat n est pas dans le même projet Visual Studio, référencez le projet ENI.GestCo.Schemas dans le projet ENI.GestCo.Pipelines. Sélectionnez le composant et ouvrez la page de propriétés. Dans la propriété Schéma de document, sélectionnez le schéma ENI.GestCo.Schemas.CommandePos

305 Avec ces manipulations, nous indiquons au composant qu il doit désassembler des messages au format CommandePos.xsd. Le développement du pipeline est terminé, nous pouvons maintenant le tester. b. Découpage de fichiers plats Le composant de désassemblage XML peut découper des messages XML, le désassembleur de fichiers plats peut lui aussi procéder à ce type d opération. Il y a quelques nuances dans la définition du schéma XSD pour découpage dans le cas d un fichier plat mais le principe reste le même. Vous pouvez donc réceptionner des fichiers plats en mode batch et les découper avant leur publication dans la MessageBox

306 Tester un pipeline Quand nous avons modélisé des schémas ou implémentés des maps, j ai insisté sur l intérêt des tests locaux (sur le poste de développement) avant le déploiement de la solution sur un serveur BizTalk. Il en est de même pour un pipeline. C est d ailleurs le dernier chapitre de cet ouvrage dans lequel nous aurons la possibilité de tester localement puisque dès le prochain chapitre, consacré aux orchestrations, nous devrons déployer pour tester. Profitons donc de ce chapitre pour garder de bonnes habitudes. 1. Tests unitaires Les pipelines peuvent être testés via des tests unitaires. Avant de pouvoir tester les pipelines d un projet, il faut positionner la propriété Activer le tests des unités dans l onglet Déploiement du projet ENI.GestCo.Pipelines. Nous ne détaillons pas dans cet ouvrage les tests unitaires des pipelines mais inspirez vous des tests unitaires des schémas et maps effectués dans les précédents chapitres, les principes sont en effet identiques. 2. Utilisation de Pipeline.exe L exécutable pipeline.exe est un outil livré avec le SDK de BizTalk et installé en même temps que les outils de développement. Il est accessible dans le répertoire d installation de BizTalk, sous répertoire SDK\Utilities\Pipeline. Il permet d exécuter un pipeline en lui fournissant un message en entrée. Le message est délivré au pipeline qui s exécute. L outil permet de visualiser les étapes suivies par le message, le ou les messages obtenus à l issue de l exécution ainsi que les propriétés promues créées. Pour tester notre pipeline avec cet outil, exécutez la ligne de commande ci dessous : pipeline.exe rpicommandepos.btp -d ExempleCommandePos.txt -c Reportez vous à la documentation BizTalk pour connaître toutes les options en ligne de commande de cet outil. 3. Tests des composants de désassemblage Le SDK contient d autres outils permettant de tester de manière unitaire les composants d assemblage ou de désassemblage (XML ou fichier plat). Il s agit des outils suivants : FFDasm.exe : test du désassembleur de fichier plat. XMLDasm.exe : test du désassembleur de fichier XML. FFAsm.exe : test de l assembleur de fichier plat. XMLAsm.exe : test de l assembleur de fichier XML. Ces outils sont complémentaires aux tests des schémas XSD. Ils permettent de reproduire des comportements proches de la réalité sans pour autant devoir créer des pipelines ou déployer toute la solution dans BizTalk. Ils permettent également de tester des comportements qui ne peuvent pas être produits par les simples tests des fichiers XSD comme : découpage des messages (debatching) ; promotion de propriétés. Systématisez ces tests si vous utilisez des fichiers plats car de nombreux problèmes sont détectés avec ces outils et vous évitent donc des déploiements inutiles et des soirées de débogage

307 4. Déployer un pipeline Le déploiement d un pipeline se déroule comme le déploiement de n importe quel composant BizTalk (schéma et map). L assembly dans laquelle est compilé le pipeline est déployée dans une application BizTalk. Dès qu elle est déployée, la liste des pipelines de l application est enrichie par les pipelines qu elle contient. 5. Utiliser un pipeline Nous allons maintenant illustrer comment utiliser notre nouveau pipeline de réception pour la réception de fichiers plats provenant de la gestion commerciale. a. Association avec un emplacement de réception Créez un nouvel emplacement de réception dans le port de réception rcvgestioncommerciale. Nommez cet emplacement rcvgestioncommerciale_fp (FP pour Fichier Plat). Faites écouter le répertoire de réception de la gestion commerciale avec un masque de fichier *.txt. Associez cet emplacement de réception au pipeline de réception rpicommandepos. Nous sommes prêts à recevoir un fichier plat dans ce répertoire. Le fichier va être désassemblé et transformé en XML. Il sera publié dans la MessageBox comme un message de type urn:editionseni:gestco#commandepos. Sauf si vous avez créé un abonné à ce type de message, le message sera en erreur de routage. Dans les exemples que vous pourrez télécharger, vous trouverez dans le projet ENI.GestCo.Maps une map permettant de transformer un message de type CommandePos en un message de commande pivot. Ainsi, l envoi vers l application de comptabilité pourra être effectué au même titre qu une réception de message XML. b. Configuration par instance du pipeline Lors de l association de notre pipeline à l emplacement de réception nous n avons pas configuré le pipeline pour qu il se comporte d une manière ou d une autre. Le comportement du pipeline, plus précisément du composant de désassemblage fichier plat, a été indiqué de manière statique dans le pipeline. Si vous souhaitez modifier un comportement du pipeline pour l emplacement de réception en particulier, vous pouvez modifier les propriétés de configuration du pipeline associé à l emplacement. Vous opérerez ainsi une configuration par instance de votre pipeline :

308

309 Introduction aux composants de pipelines 1. Les composants standards de BizTalk Dans la construction du pipeline de réception rpicommandepos, nous avons utilisé un composant de pipeline standard, proposé dans la boîte à outils BizTalk. BizTalk est livré avec une collection de composants de pipelines réutilisables et configurables. Ces composants satisfont un grand nombre de besoins comme le désassemblage, l assemblage ou bien encore le chiffrement ou le déchiffrement. Selon les accélérateurs ou adaptateurs BizTalk que vous avez installés, vous disposez d une collection plus ou moins importante. 2. Les composants tiers La collection de composants de pipelines tiers, communautaires ou commerciaux est très importante. Ces composants tiers sont intéressants puisqu ils peuvent améliorer les composants standards ou apporter de nouvelles fonctionnalités. Visitez régulièrement le site pour vous tenir au courant des nouveaux composants disponibles. Si vous êtes amenés à utiliser des composants de pipelines tiers, validez préalablement leur performance et leur stabilité. Vous allez le découvrir dans le paragraphe suivant, le développement d un composant de pipeline est simple mais peut devenir relativement complexe selon le type de composant développé. Cette complexité est liée au fait qu il est impératif de respecter le modèle de streaming de BizTalk (cf. Le mode d exécution d un pipeline dans ce chapitre). Toutes les bibliothèques de composants de pipelines, y compris celles qui sont commercialisées, ne respectent pas ces principes et peuvent donc entraîner des problèmes de performances ou de stabilité des solutions BizTalk

310 Implémenter un composant de pipeline 1. Pourquoi faut il créer ses propres composants? Les outils de développements BizTalk permettent le développement de vos propres composants de pipeline. Il n est pas rare de devoir implémenter ses propres composants quand ils n existent pas en standard. Il n est pas toujours facile de choisir, dans un projet BizTalk, s il faut par exemple implémenter un composant de pipeline ou une orchestration. Si vous ne connaissez pas les orchestrations que nous abordons dans le prochain chapitre vous ne pouvez évidemment pas répondre à cette question. Un même besoin peut souvent être couvert par un composant de pipeline ou par une orchestration, le choix n est donc pas trivial. Si je devais énoncer une règle pour vous permettre de choisir, il s agirait de celle ci : si votre besoin est technique, c est à dire relatif au transport d un message, relatif à la sécurité du message ou encore à son format, je vous conseille d implémenter un composant de pipeline. Au contraire si votre besoin est fonctionnel, métier, une orchestration est bien plus adaptée. Nous allons maintenant illustrer un scénario qui pourrait tout à fait être implémenté sous forme d une orchestration. Cependant, étant donné qu il s agit d un besoin technique, le choix d un composant de pipeline est naturel. 2. Le besoin : baptiser un fichier en sortie de BizTalk Le besoin que nous souhaitons couvrir avec notre composant de pipeline est le suivant. Pour l instant, lorsque nous envoyons un message vers l application de comptabilité, nous utilisons une macro BizTalk pour nommer le fichier. Cette macro, %MessageId%, produit un fichier avec un nom unique. La valeur %MessageId% est remplacée par le numéro unique du message dans BizTalk, ce numéro étant un GUID (Globally Unique IDentifier). Supposons maintenant que l éditeur du logiciel de comptabilité a omis de nous indiquer que les fichiers déposés dans le répertoire devaient être nommés selon une convention bien particulière sans quoi ils ne pourraient pas être intégrés. Nous devons déposer les fichiers dans le répertoire destination mais en respectant la convention ci dessous : <CodeClient>_<DateProductionMessage>_<NuméroUnique>.xml Par exemple, lorsque nous envoyons une commande pour le client ENIEditions, nous devons produire un fichier nommé ENIEditions_ _123.xml. Il n existe pas une macro native BizTalk pour renommer le fichier en respectant cette norme. Nous devons donc implémenter un composant qui sache faire cela, de la manière la plus efficace possible. La solution à ce problème se trouve dans l implémentation d un composant de pipeline, nous allons l illustrer dans la suite de ce chapitre. 3. Développement d un composant de pipeline a. Fonctionnement de notre composant de pipeline Voici comment doit fonctionner le composant de pipeline que nous allons implémenter. Il se nomme Baptiseur puisqu il doit baptiser un fichier en le nommant correctement. Il est positionné à l étape Coder d un pipeline d envoi. Le schéma ci dessous illustre son rôle et son fonctionnement : Voici la séquence d exécution :

311 Un message est délivré au port d envoi en provenance de la MessageBox. Le message est transformé au format attendu par l application de comptabilité. Après transformation, le message est traité par le pipeline d envoi (pipeline spécifique que nous nommons spicomptabilite). Il n y a pas de composants dans ce pipeline autre que notre Baptiseur. Le composant Baptiseur, situé à l étape Coder, récupère le message. Il lit les propriétés promues du message pour récupérer le code du client. Il produit les autres informations nécessaires pour respecter la convention de nommage (date du jour et numéro unique). Le composant récupère ensuite l adresse associée au port d envoi. Il obtient une adresse sous la forme c:\enieditions\tests\comptabilite\%messageid%.xml. Il remplace le nom du fichier par le nom normalisé qu il vient de calculer. Il produit ainsi la chaîne suivante c:\enieditions\tests\comptabilite\enieditions_ _123.xml. Afin que l adaptateur FILE situé immédiatement après le pipeline d envoi utilise cette nouvelle adresse au lieu de celle positionnée dans la configuration du port, le composant met à jour une donnée du contexte du message. Cette donnée (nommée OutboundTransportLocation) est lue par l adaptateur FILE pour connaître l adresse d envoi. Il utilisera cette information pour transporter le message. Nous utilisons la propriété OutboundTransportLocation qui est une donnée contextuelle créée automatiquement dès le début de l exécution du port d envoi et renseignée avec l adresse paramétrée sur le port d envoi. En modifiant cette propriété, nous pouvons ainsi modifier l adresse de destination sans pour autant devoir toucher à l adresse paramétrée au niveau du port. b. Création du projet.net de composants Le développement d un composant de pipeline est du développement.net. Un composant de pipeline est une classe.net qui implémente des interfaces particulières. La liste des interfaces à implémenter est plus ou moins importante selon le type de composant implémenté. La création d un composant de pipeline passe donc par la création d un projet.net (C# ou tout autre langage sachant produire une assembly.net). Dans ce projet se trouvent des classes.net correspondant aux composants de pipelines. Bien que la création d un composant de pipeline ne soit pas complexe, plusieurs tâches fastidieuses et non assistées sont nécessaires. Il s agit par exemple de décorer la classe avec des attributs pour spécifier l identifiant unique du composant, le type de composant... Installation de l assistant création de composants de pipeline Pour gagner du temps, nous allons utiliser un assistant de génération de composant de pipeline nommé BizTalk Server Pipeline Component Wizard. Téléchargez ce composant sur le site Il s agit d un projet communautaire très largement utilisé. Décompressez le code source téléchargé, compilez la solution et localisez le fichier PipelineComponentWizardSetup.msi. Lancez l installeur pour que l assistant soit référencé auprès de Visual Studio. Création du composant de pipeline Créez un nouveau projet dans la solution ENI.BizTalk avec l assistant de création de composants de pipeline. Ajoutez un nouveau projet. Choisissez le type de projet Projets BizTalk, puis le modèle BizTalk Server Pipeline Component. Nommez le projet ENI.Compta.ComposantsPipeline :

312 c. Implémentation du composant L assistant nous guide pour créer le composant de pipeline dans le projet : Nommez le composant Baptiseur. Associez lui l espace de noms.net ENI.Compta.ComposantsPipeline. Indiquez qu il s agit d un composant utilisable dans un pipeline d envoi et précisez qu il pourra être ajouté à l étape Encoder (Coder en français). Terminez en sélectionnant le langage de développement que vous souhaitez. Indiquez ensuite les propriétés relatives à l affichage du composant dans la boîte à outils Visual Studio :

313 Dans la fenêtre Design time variables, cliquez simplement sur le bouton Suivant. Cette fenêtre permet de préciser des paramètres de configuration du composant de pipeline. Lorsque vous terminez l assistant, un projet.net est créé et une classe.net a été ajoutée au projet. Elle se nomme Baptiseur et est hébergée dans le fichier Baptiseur.cs. L assembly qui contient les composants de pipeline ne sera pas déployée dans le GAC, si bien qu il n est pas nécessaire de lui associer un fichier de clé. Modifiez les options du projet nouvellement créé pour que l assembly générée se nomme comme le projet. Si vous ne faites pas cette configuration, l assembly se nommera Baptiseur.dll. Ouvrez le fichier Baptiseur.cs. Vous remarquez que l assistant a créé une classe et l a décorée avec les attributs suivants : [ComponentCategory(CategoryTypes.CATID_PipelineComponent)] : indique qu il s agit d un composant de pipeline. [System.Runtime.InteropServices.Guid("c9e9e6d b79b-52ab21561dbf")] : indique l identifiant unique du composant. [ComponentCategory(CategoryTypes.CATID_Encoder)] : indique que le composant peut être positionné à l étape Coder d un pipeline. La classe implémente les interfaces suivantes : IBaseComponent : cette interface fournit à l éditeur de pipeline Visual Studio des informations sur le composant (nom et version notamment), lorsque le composant est utilisé pour construire un pipeline. IPersistPropertyBag : cette interface permet la prise en charge des données de configuration du composant, c est à dire la récupération des paramètres et leur stockage. IComponentUI : cette interface contient deux méthodes. Une méthode Validate qui est exécutée avant le dépôt du composant dans le pipeline. Cette méthode vous permet de valider la configuration du pipeline et le contexte dans lequel il est utilisé pour éventuellement lever une exception en cas d erreur. Cette interface fournit également un icône pour la représentation graphique du composant dans la boîte à outils

314 BizTalk. IComponent : cette interface est la plus importante. Elle ne contient qu une seule méthode nommée Execute. Cette méthode est invoquée par le pipeline dans lequel se trouve le composant lorsqu un message transite. Elle prend en paramètre le message ainsi que le contexte d exécution du pipeline et retourne un ou plusieurs messages. Nous allons implémenter la logique de notre composant dans cette méthode. Voici le code source de la méthode Execute du composant : public Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(Microsoft.BizTalk.Component.Interop.IPipelineContext pc, Microsoft.BizTalk.Message.Interop.IBaseMessage inmsg) { // Lecture de l adresse du port d envoi string adresseenvoi = (string)inmsg.context.read("outboundtransportlocation", " // Lecture du code client dans les propriétés promues du message string codeclient = (string)inmsg.context.read("codeclient", "urn:editionseni:proprietes"); // Génération du nom de fichier string nomfichier = codeclient + "_" + DateTime.Now.ToString("yyyyMMdd") + "_" + Guid.NewGuid().ToString() + ".xml"; // Modification adresse d origine pour changer le nom du fichier string cheminsansfichier = Path.GetDirectoryName(adresseEnvoi); string nouvelleadresseenvoi = Path.Combine(cheminSansFichier, nomfichier); // Mise à jour du contexte pour indiquer la nouvelle adresse à l adapter inmsg.context.write("outboundtransportlocation", " nouvelleadresseenvoi); } return inmsg; Voici ce qu il faut comprendre dans le code source : Nous récupérons tout d abord l adresse d envoi du port d envoi en lisant la propriété OutboundTransportLocation de l espace de noms Nous lisons cette information dans le contexte du message entrant. Le message entrant est passé dans le paramètre inmsg de la méthode et son contexte est accessible via la méthode Read de l objet Context. Nous récupérons ensuite le code client de la commande. Nous aurions pu lire le contenu du message mais le plus simple est d accéder à la propriété promue CodeClient de l espace de noms urn:editionseni:proprietes. Nous pouvons désormais composer le nom du fichier selon la convention souhaitée. Nous procédons à la concaténation du code client, de la date courante ainsi que d un numéro unique. Nous choisissons d utiliser un GUID comme numéro unique. Nous combinons le nouveau nom de fichier avec le chemin du répertoire de destination pour former la nouvelle adresse d envoi. Nous mettons à jour la propriété OutboundTransportLocation du contexte du message. L adaptateur FILE qui traite le message utilise cette nouvelle adresse au lieu de l adresse paramétrée sur le port d envoi

315 Pour terminer, nous retournons le message avec la clause return inmsg. Le message est mis à disposition pour les composants suivants du pipeline et finalement à l adaptateur FILE, dernier maillon de la chaîne d exécution. Gestion d erreurs Par souci de simplicité, nous n avons pas implémenté de gestion d erreurs dans la méthode Execute. Si une erreur se produit, elle sera donc directement remontée au pipeline qui la propagera au moteur d exécution BizTalk. L instance du pipeline sera suspendue et le message d erreur sera consultable dans la console d administration de BizTalk. En théorie, nous devrions gérer de manière plus sérieuse les erreurs en les captant au niveau de notre code pour les envelopper dans des exceptions typées. Nous pouvons ainsi faire remonter des erreurs plus faciles à analyser tout en fournissant, dans l InnerException, le détail de l exception sous jacente que nous avons intercepté. Instrumentation du code Étant donné qu un composant de pipeline est une classe.net, nous pouvons tout à fait le déboguer, c est d ailleurs ce que nous allons faire dans le paragraphe Deboguer le composant ci après. Le débogage permet de comprendre un dysfonctionnement, mais uniquement dans un environnement de développement. Si une erreur se produit dans notre composant sur un serveur en production, nous devons avoir des outils pour comprendre le problème et donc le diagnostiquer. Il faut impérativement instrumenter le code, c est à dire ajouter des traces permettant de comprendre le chemin d exécution, la valeur des variables, des messages... Je vous conseille de le faire dès le développement initial et ne pas attendre de rencontrer un bug pour ajouter des traces. Vous pouvez utiliser le Framework.Net pour instrumenter (classes Debug ou Trace) ou des composants tiers comme l Enterprise Library ou log4net. d. Ajout du composant dans un pipeline Afin que notre composant s exécute, nous devons l ajouter dans un pipeline, en l occurrence un pipeline d envoi puisqu il a été conçu pour cela. Déploiement du composant de pipeline Pour que le composant de pipeline soit disponible dans la boîte à outil de Visual Studio et ainsi utilisable dans un pipeline, nous devons le déployer. Il faut simplement copier l assembly ENI.Compta.Composants.Pipeline.dll dans le sous répertoire Pipeline Components situé dans le répertoire d installation de BizTalk. Ajout du composant dans la boîte à outils Dans le menu Outils de Visual Studio, choisissez l option Choisir des éléments de boîte à outils. Après quelques secondes, parfois quelques minutes, vous obtenez l écran de sélection des composants de la boîte à outils. Naviguez dans l onglet Composants de pipeline. Cliquez sur Parcourir pour sélectionner l assembly ENI.Compta.Composants.Pipeline.dll et cochez la case correspondant au composant Baptiseur :

316 Création du pipeline d envoi Créons maintenant un pipeline et déposons notre composant de pipeline à l étape Coder. Le pipeline qui va héberger notre composant est un pipeline d envoi destiné à l application Comptabilité, en toute logique nous devons donc créer un projet ENI.Compta.Pipelines spécifiquement pour ce pipeline : Dans ce nouveau projet, que vous devez configurer correctement (signature et déploiement), ajoutez une référence vers le projet de composants de pipelines ENI.Compta.ComposantsPipeline. Ajoutez un nouveau pipeline d envoi et nommez le spicomptabilitebaptiseur. Depuis la boîte à outils, faites glisser le composant Baptiseur à l étape Coder : e. Déboguer le composant Nous avons la possibilité de déboguer le composant avant de le déployer. Voici la procédure qu il faut suivre : Dans les propriétés du projet ENI.Compta.ComposantsPipeline, modifiez le Chemin de sortie afin de le faire pointer dans le sous répertoire Pipeline Components du répertoire d installation de BizTalk. Dans l onglet Déboguer, sélectionnez l option Démarrer le programme externe et parcourez le disque dur vers

317 le programme Pipeline.exe situé dans le sous répertoire SDK\Utilitities\Pipeline d installation de BizTalk. Tools du répertoire Dans les Options de démarrage, Arguments de la ligne de commande saisissez la ligne de code suivante : C:\ENIEditions\ENI.BizTalk\ENI.Compta.Pipelines\spiComptabiliteBa ptiseur.btp -d C:\ENIEditions\ENI.BizTalk\ENI.Schemas\Exemples\Commande.xml -c - v Lorsque nous allons démarrer l exécution du projet ENI.Compta.ComposantsPipeline, l outil Pipeline.exe va être exécuté avec les arguments de ligne de commande que nous venons de préciser. Déposez un point d arrêt dans le composant de pipeline Baptiseur : Lancez le débogage en ouvrant le menu contextuel sur le projet ENI.Compta.ComposantsPipeline et en choisissant l option Déboguer puis Démarrer une nouvelle instance. Dans notre scénario, le composant produira une erreur sur la ligne string nouvelleadresseenvoi = Path.Combine(cheminSansFichier, nomfichier). En effet, quand nous testons le composant en dehors de BizTalk, le message qui entre dans le pipeline n a pas de contexte. Donc quand nous récupérons les propriétés OutboundTransportLocation et CodeClient, elles sont vides. La méthode Path.Combine qui permet de combiner un chemin et un nom de fichier n accepte pas de valeurs nulles, elle va donc produire une erreur avec le message pointeur invalide. Nous sommes dans un cas particulier où les tests du composant ne peuvent pas réellement être effectués en dehors de BizTalk. Dans cet exemple de débogage de composant de pipeline, nous utilisons l outil pipeline.exe. Il est également possible de déboguer un composant de pipeline lorsque celui ci s exécute dans BizTalk, c est à dire dans le processus BTSNTSVC.exe. Cela est possible bien entendu si vous disposez de BizTalk sur votre poste de développement. Dans ce cas, vous devez simplement attacher le projet de composant de pipeline à l exécutable BizTalk et lancer le débogage. f. Déployer le composant Nous allons maintenant déployer le pipeline spicomptabilitebaptiseur ainsi que le composant de pipeline Baptiseur. Déploiement du composant de pipeline L assembly qui contient le composant de pipeline (ENI.Compta.ComposantsPipeline.dll) doit être déployée. Étant donné qu il ne s agit pas d une assembly BizTalk mais d une assembly.net traditionnelle, il n y a pas à déclarer le composant de pipeline dans la base de configuration BizTalk. Vous pouvez d ailleurs noter que la console

318 d administration de BizTalk ne propose pas de dossier Composants de pipeline dans les applications. Pour déployer le composant de pipeline, copiez l assembly dans le répertoire Pipeline Components du répertoire d installation de BizTalk. Lorsqu un pipeline contenant le composant sera exécuté par BizTalk, le service de BizTalk chargera l assembly du composant à partir de cet emplacement. Afin d intégrer l assembly du composant de pipeline à une application et donc l exporter dans le package de déploiement correspondant, vous devez l ajouter aux ressources. Lors de l ajout de la ressource, précisez le répertoire de déploiement en procédant comme indiqué ci dessous : Ne cochez pas la case Ajouter au Global Assembly Cache lors de l installation du fichier MSI puisque l assembly n a pas de nom fort et ne pourra donc pas être publiée dans le GAC. Déploiement du pipeline Pour déployer l assembly qui contient le pipeline, faites un déploiement traditionnel BizTalk, soit via Visual Studio, soit en ajoutant l assembly dans les ressources de l application. Le pipeline est déclaré dans la base de configuration de BizTalk et l assembly est copiée dans le GAC. g. Tester le composant Nous avons déployé tous les composants nécessaires au fonctionnement de l application. Nous allons modifier la configuration du port d envoi sndcomptabilite_file pour lui associer le nouveau pipeline spicomptabilitebaptiseur qui contient notre composant de pipeline :

319 Ouvrez la configuration du port d envoi sndcomptabilite_file et associez lui le pipeline spicomptabilitebaptiseur. Si vous cliquez sur le bouton... situé à côté du pipeline, vous pouvez visualiser la liste des composants contenus dans le pipeline. Notez qu il y a un composant à l étape Coder (notre composant Baptiseur) mais que ce composant n est pas configurable. Déposez maintenant une commande en provenance de la gestion commerciale. La commande est consommée par BizTalk, transformée en format pivot. Le code client est promu lors de la transformation en format pivot. Le message est transformé au format attendu par la comptabilité et envoyé via le port d envoi. Vous obtenez un fichier baptisé dans le répertoire de dépôt de la comptabilité. Pour vous exercer au fonctionnement des composants de pipelines, faites évoluer le composant, en rendant configurable le format de la date présente dans le nom du fichier. Pour cela, modifiez les méthodes et propriétés de l interface IPersistPropertyBag. 4. Développement d un désassembleur Vous serez confrontés à des scénarios dans lesquels les messages que vous réceptionnez sont dans un format tellement exotique qu aucun désassembleur standard ne sera en mesure de les traiter. Dans ces scénarios, vous serez tenté de développer un composant, en amont de BizTalk, pour rendre ces fichiers plus standards et ensuite les envoyer à BizTalk. Ce travail pour rendre les fichiers plus standard aux yeux de BizTalk est en réalité exactement ce que doit faire un composant de désassemblage. Si vous implémentez ce désassemblage en dehors de BizTalk, vous ne pourrez pas utiliser les fonctions natives du produit comme le suivi de l exécution, la reprise en cas d erreur et la montée en charge. Je vous conseille donc très fortement de développer votre propre désassembleur de fichier exotique et de l intégrer à vos pipelines de réception. Il y a de fortes chances que ce désassembleur ne soit pas réutilisable en dehors de votre projet, tellement le format de message est exotique, mais vous pourrez être serein sur la robustesse de votre solution et sa cohérence. Si vous développez un désassembleur, vous devez implémenter l interface IdisassemblerComponent en plus des interfaces traditionnellement implémentées pour un composant de pipeline. Si vous implémentez un assembleur, il s agit de l interface IAssemblerComponent

320

321 Téléchargement des exemples Les exercices de ce chapitre sont disponibles en téléchargement dans le fichier Chapitre10_CodeSource.zip

322 Conclusion Nous venons d explorer les pipelines et composants de pipelines. Vous pouvez donc maintenant mesurer la puissance et les possibilités qui s offrent à vous pour implémenter vos projets. Depuis le chapitre sur la messagerie BizTalk dans lequel nous avons transporté un message d un répertoire à un autre sans utiliser le contenu, notre application a été enrichie de fonctionnalités : Nos messages n ont plus le même format en entrée ou en sortie. Nous avons transcodé des données à partir d une base de données. Nous savons maintenant réceptionner des messages contenant plusieurs commandes. Nous savons même réceptionner des fichiers plats. Et enfin, nous venons d ajouter dans ce chapitre des fonctionnalités permettant de baptiser des fichiers en sortie. Nous sommes pourtant toujours dans des scénarios de messagerie pure, les messages entrent dans BizTalk, sont publiés dans la MessageBox et ressortent immédiatement par des ports d envoi. Cette solution de pure messagerie est très performante et sait monter en charge sans effort dans le développement. Pour réaliser toute cette implémentation, nous n avons pas beaucoup eu recours à du code spécifique, sauf pour le composant de pipeline. Si l écosystème de l entreprise évolue, notre application BizTalk sait évoluer en conséquence sans être totalement remise en cause. Nous pouvons même faire cohabiter deux versions différentes de l application de gestion commerciale ou de comptabilité. Dans le chapitre suivant, nous allons aborder la notion d orchestration et vous comprendrez comment BizTalk nous permet d implémenter des processus métier

323 Les orchestrations BizTalk 1. Introduction aux orchestrations Nous avons jusqu à maintenant réussi à implémenter des solutions BizTalk en utilisant uniquement les fonctions de messagerie BizTalk et l architecture de publication/souscription. Ces composants de messagerie nous ont permis de satisfaire un grand nombre de besoins. Nous allons voir dans ce chapitre qu il existe des scénarios métiers dans lesquels nous ne pourrons pas nous contenter des composants de messagerie. Nous devrons mettre en œuvre des orchestrations BizTalk. Une orchestration BizTalk est l implémentation d un processus métier qui orchestre des échanges de messages et de données entre plusieurs systèmes. Contrairement aux composants de messagerie BizTalk (ports et emplacements) qui sont créés par configuration dans la console d administration, les orchestrations nécessitent une phase de développement dans Visual Studio. Une orchestration modélise le cheminement d un message au sein d un processus métier. Au fur et à mesure de ce cheminement, des actions particulières sont menées avec des systèmes externes (envois et réceptions de messages), des opérations spécifiques sont effectuées (appels de code spécifique, transformations) et de nouveaux messages sont éventuellement produits. Lorsque le processus est simple, il n est pas utile de construire une orchestration et les fonctionnalités de messagerie BizTalk suffisent amplement. Lorsque le cheminement du message est plus tortueux ou bien lorsque plusieurs partenaires doivent interagir pour produire un message final, le recours à une orchestration est nécessaire. Vous comprendrez mieux, à la lecture de ce chapitre, les cas d usage d une orchestration et apprendrez à choisir entre orchestration et messagerie pure. 2. Implémentation d une orchestration L implémentation d une orchestration est effectuée dans Visual Studio, via l éditeur d orchestrations (Orchestration Designer en anglais). Cet éditeur permet de construire graphiquement toutes les étapes du processus et leur enchaînement. La boîte à outils de l éditeur d orchestrations contient des formes (appelées shapes en anglais). Elles offrent les fonctionnalités pour l implémentation de l orchestration : réception et envoi de messages, transformations, boucles, décisions, appel de code externe... À l issue de l implémentation et de la compilation, l orchestration est traduite en classe.net et hébergée dans une assembly. L assembly est ensuite déployée au sein de BizTalk. Après configuration, l orchestration participe à un échange au sein de BizTalk. Nous verrons comment une orchestration s insère dans l architecture de publication/souscription BizTalk. 3. Les fonctionnalités des orchestrations Pour choisir entre messagerie pure et orchestration, il faut comprendre la plus value d une orchestration. Voici plusieurs fonctionnalités offertes par les orchestrations qui peuvent vous guider dans votre choix. a. Persistances et reprises de processus Nous l avons vu dans les précédents chapitres, les messages qui transitent par BizTalk sont stockés dans la MessageBox tout au long de leur traitement. Ils basculent ensuite automatiquement dans la base de données de suivi. Les messages traités par une orchestration sont également stockés en base de données. Étant donné qu une orchestration peut manipuler des données autres que des messages (des variables par exemple), ces données sont également stockées. À chaque étape de persistance décidée par le moteur BizTalk, c est tout l état de l orchestration qui est enregistré dans la base de données. Lorsque l orchestration reprend son exécution, cet état est restauré et le processus peut continuer. La persistance d une orchestration est décidée par BizTalk en fonction d un ensemble de paramètres. Nous revenons sur ce sujet dans le paragraphe La persistance des données d une orchestration. L intérêt de la persistance est de permettre à des processus longs de ne pas perdre leur état même s ils sont inactifs pendant plusieurs semaines ou mois. La persistance est également une fonctionnalité qui permet de parer aux plantages d un serveur et de reprendre

324 l instance d un processus sur un autre serveur, au dernier point de persistance de l orchestration. Les données d état stockées dans la base de données ne sont pas affiliées à un serveur BizTalk particulier si bien que l orchestration peut être reprise sur n importe quel serveur BizTalk du groupe. Nous évoquons les architectures de haute disponibilité dans le chapitre Architecture et haute disponibilité. b. Transactions et compensations Une orchestration offre des mécanismes transactionnels. La possibilité de construire un processus transactionnel permet de maintenir un état consistant des différents systèmes engagés dans le processus. Si vous construisez une orchestration BizTalk pour gérer des virements bancaires, vous devez garantir qu un débit effectué sur un compte correspond au crédit effectué sur un autre compte. Lorsque les deux comptes sont gérés dans la même base de données SQL, l utilisation d une transaction SQL suffit. Lorsque les deux comptes bancaires sont gérés dans deux systèmes différents, il faut créer une transaction distribuée. Les orchestrations BizTalk vont vous permettre de mettre en place ces scénarios avec les adaptateurs transactionnels comme SQL Server, Oracle ou SAP. Lorsque les protocoles de transport ou les systèmes tiers ne savent pas participer à des transactions distribuées, les orchestrations peuvent compenser des transactions. Si le processus a envoyé un e mail au détenteur du compte qui a été débité, mais si le crédit du compte correspondant ne fonctionne pas, la compensation de cette action suppose d annuler le débit effectué et d envoyer un e mail d annulation. Les mécanismes de compensation permettent aux processus longs d êtres transactionnels sans toutefois verrouiller des ressources pendant trop longtemps. c. Processus long Une orchestration qui représente un processus métier peut s exécuter sur une très longue période de temps selon la complexité du processus sous jacent. Si l orchestration gère le cycle de vie d une commande dans l entreprise, de la prise de commande au règlement de la facture par le client, le processus peut s étaler sur plusieurs mois selon les conditions de règlement du client. Pendant toute cette durée, BizTalk garantit que l état du processus est consistant grâce aux mécanismes de persistance et va éventuellement vous permettre de compenser des actions en cas d erreur, grâce à la gestion des transactions. Bien que le processus dure longtemps, il ne va pas consommer des ressources pendant tout le cycle de vie car BizTalk va l endormir et le réveiller lorsque cela sera utile, par exemple dès l arrivée d un message attendu. Ces mécanismes sont natifs et il n est pas utile de s en soucier pendant la phase de développement d une orchestration. d. Impatience Un processus long ne signifie pas un processus qui ne se termine jamais. Dans l entreprise un processus métier qui ne se termine pas n est pas normal. Il est souvent très intéressant de savoir qu un processus n a pas eu d activité depuis un certain laps de temps et d agir en conséquence. Si le processus de commande réserve du stock dès l arrivée d une commande client et ensuite attend une confirmation ou une annulation de commande pour défalquer ou libérer le stock, il faut qu un de ces deux événements se produise sinon le stock est réservé à l infini. Bien entendu, cela a une conséquence directe sur le business de l entreprise, pas seulement sur les ressources informatiques. Les processus doivent s impatienter et se rendre compte qu une période d inactivité trop longue a été rencontrée. Les orchestrations BizTalk savent le faire nativement. e. Modèles d implémentation : patterns EAI Les problématiques rencontrées dans l intégration d applications sont bien connues, depuis plusieurs années, et surtout très largement partagées par les entreprises. Chaque entreprise, malgré le fait que son activité soit très spécifique ou que son Système d Information soit très particulier, rencontre les mêmes problèmes d intégration. Lorsqu une entreprise souhaite résoudre ces problématiques d intégration, elle peut s appuyer sur des modèles d implémentation qui recensent les bonnes pratiques en matière d implémentation mais aussi les limites et les contraintes associées. Ces bonnes pratiques sont rassemblées dans des patterns EAI. Ces modèles se sont construits suite aux expériences rencontrées dans différents projets par de nombreux contributeurs. Ils ont été formalisés de manière très précise dans le très connu Enterprise Integration Patterns écrit par Grégor Hohpe et Bobby Woolf aux éditions Addison Wesley Professional. Certains patterns EAI peuvent être implémentés dans BizTalk sous forme de solutions de pure messagerie, d autres

325 nécessitent la mise en œuvre d orchestrations. Nous évoquons des exemples de patterns EAI à la fin du chapitre Processus métier avancés. Les différents noms de patterns cités dans cet ouvrage sont déposés sous licence Creative Commons et sont issus de l ouvrage Enterprise Integration Patterns de Grégor Hohpe et Bobby Woolf. Consultez le site Internet 4. Les orchestrations et l architecture de publication/souscription Nous avons très longuement parlé depuis le début de cet ouvrage de l architecture de publication/souscription et de son importance dans BizTalk. Les orchestrations s insèrent parfaitement dans cette architecture et sont des abonnés comme les autres. Toute orchestration déployée dans un groupe BizTalk est déclarée comme un abonné et consomme donc les messages qui respectent les filtres de son abonnement. Contrairement aux ports d envoi, la déclaration d une orchestration en tant qu abonné est faite indirectement et de manière quasi transparente

326 Implémenter une orchestration Nous allons maintenant illustrer l implémentation des orchestrations et évoquer les notions fondamentales par exemple pour l envoi ou la réception de messages. 1. Orchestrations : ne pas mélanger le métier et la technique Lorsque vous implémentez une orchestration, vous devez décorréler le processus que vous modélisez (la gestion de commande par exemple) de l ensemble détails techniques relatifs à l exécution de ce processus dans l environnement de l entreprise. Lorsque le processus contient une étape de réception de commande ou d envoi d un acquittement au client, il faut bien à un moment où un autre spécifier comment les messages sont transportés du client vers l orchestration et inversement. Le moment de la définition de ces détails techniques est repoussé le plus longtemps possible et ne doit interférer avec la modélisation et l implémentation du processus métier. Finalement, peu importe si la commande reçue de la gestion commerciale provient d un répertoire ou d un e mail, cela n a pas d incidence sur le processus lui même. Surtout, vous ne devez pas être dépendant du transport du message sinon vous devrez faire évoluer ce processus lorsque l application partenaire modifie son mode de communication. Ce découplage entre le métier et la technique est fondamental dans l implémentation d orchestrations et vous devez le garder à l esprit. Les orchestrations BizTalk vous permettent de décorréler le métier de la technique, tirez donc pleinement partie de ces fonctionnalités. 2. Le cas d utilisation : routage simple a. L exemple parfait de ce qu il ne faut pas faire Notre première orchestration est l exemple parfait de ce qu il ne faut pas faire. Il s agit d une orchestration qui route un message entre la gestion commerciale et la comptabilité. C est l exacte implémentation de ce que nous avons fait jusqu à maintenant en messagerie pure, mais cette fois ci avec une orchestration. Grâce à cette orchestration inutile, nous allons : Évoquer les notions fondamentales des orchestrations comme l envoi et la réception de messages. Mesurer la différence d approche entre de la messagerie pure et l implémentation d orchestrations. Vous comprendrez ainsi pourquoi il ne faut pas systématiser l implémentation d orchestrations quand cela n est pas nécessaire. b. Le scénario implémenté Pour ce premier exemple, nous allons simplement ajouter une orchestration au milieu de nos deux partenaires, c est à dire entre l application de gestion commerciale et l application de comptabilité. Cette orchestration va recevoir le message provenant de la gestion commerciale et le router à la comptabilité. 3. Construction de l orchestration Nous devons tout d abord créer un nouveau projet dans notre solution ENI.BizTalk : Ajoutez un nouveau projet BizTalk à la solution ENI.BizTalk et nommez le projet ENI.Orchestrations. Configurez les options de signature du projet et les options de déploiement. Faites en sorte que le projet soit déployé dans l application ENIEditions de BizTalk, comme c est le cas de l ensemble de nos projets. Nous allons maintenant ajouter une orchestration dans ce projet. Ajoutez un nouvel élément au projet, sélectionnez Orchestration BizTalk et nommez l orchestration GererCommande.odx :

327 Lorsque l orchestration est créée, elle s affiche dans l éditeur d orchestrations : L orchestration est pour l instant complètement vide. Nous avons à notre disposition une boîte à outils pour ajouter les étapes du processus :

328 Nous aborderons progressivement les différents composants présents dans cette boîte à outils. 4. La réception de messages Notre orchestration, très basique, doit recevoir un message (une commande provenant de la gestion commerciale) pour l envoyer à l application de comptabilité. Nous devons ajouter deux actions à notre orchestration : une action pour recevoir ; une action pour envoyer. a. Utilisation de la forme Recevoir Afin de recevoir un message, déposez la forme Recevoir au tout début de l orchestration en la faisant glisser depuis la boîte à outil. Dans la page de propriété, nommez cette forme rcvcommande :

329 Prenez l habitude, lors de l implémentation de vos orchestrations, de nommer vos formes. C est un peu comme nommer des variables dans du code traditionnel. Il n est pas possible d ajouter du commentaire dans une orchestration donc en nommant correctement les formes, vous ajoutez de la clarté et facilitez la compréhension du processus. La seule chose que nous venons d indiquer à l orchestration, c est qu elle doit recevoir un message : elle ne sait pas, en revanche, quel type de message ni d où provient le message. b. Identification du type de message reçu Nous souhaitons que l orchestration reçoive un message de type urn:editionseni:gestioncommandes#commande, c est à dire un message au format pivot. Nous considérons que le message provenant de la gestion commerciale est d abord transformé en message pivot avant d être publié dans BizTalk. Étant donné que l orchestration est un abonné comme un autre, les messages qu elle peut consommer sont les messages publiés dans la MessageBox. Il est tout à fait logique de construire les processus métier en utilisant des formats pivots. Les processus sont de ce fait indépendants des partenaires externes. Nous devons créer un nouveau message. Dans la fenêtre Vue orchestration, localisez le répertoire Messages. Ouvrez le menu contextuel et sélectionnez l option Nouveau message. Nommez le message msgcommande : Le message msgcommande est comme une variable qui contient, lors de l exécution de l orchestration, le message reçu (c est à dire la commande). Il faut simplement préciser qu il s agit d un message de type ENI.Schemas.Commande (autrement dit, il s agit d un message XML de type urn:editionseni:gestioncommandes#commande) : Ajoutez une référence au projet ENI.Schemas depuis le projet ENI.Orchestrations. Dans la Vue Orchestration, sélectionnez le message msgcommande. Ouvrez la page de propriétés. Localisez la propriété Type de message. Déroulez la liste et sélectionnez Schémas puis <Sélectionner dans l assembly référencé> :

330 Sélectionnez ensuite le schéma Commande hébergé dans l assembly ENI.Schemas : Dans cette copie d écran, vous manipulez des objets.net (namespaces.net et classes.net) et non des notions XML. Cette manipulation n est possible qu après la compilation des schémas. c. Association du type de message à la forme Recevoir Nous devons associer la forme Recevoir et le message msgcommande : Sélectionnez la forme rcvcommande et ouvrez la page de propriétés. Localisez la propriété Message, déroulez la liste et sélectionnez le message msgcommande

331 d. Création d un port logique de réception Nous allons maintenant indiquer à l orchestration la provenance de la commande. Nous devons créer un port de réception dans l orchestration pour faire le lien entre l orchestration et le monde extérieur. Une orchestration n est pas censée connaître les détails techniques du transport des messages donc ce qui compte à cette étape n est pas d indiquer comment le message est reçu, mais simplement qu il provient de l extérieur de l orchestration. En créant un port logique, nous créons un point d entrée pour l orchestration. Lors du déploiement, ce point d entrée sera associé à un emplacement physique. Voici pourquoi, dans une orchestration, nous parlons de port logique pour le différencier d un port physique. Pour créer un port logique, ouvrez le menu contextuel sur la surface de dessin nommée Surface du port. Sélectionnez l option Nouveau port configuré : Suivez maintenant les différentes étapes de l assistant qui permet la création d un nouveau port. Nommez le port rplcommande :

332 Sélectionnez Créer un type de port. Nommez le type de port ptymessageunidirectionnel. Sélectionnez le modèle de communication Unidirectionnel et la restriction d accès Interne : Dans cette étape de configuration du port nous précisons plusieurs éléments. Nous créons un nouveau type de port nommé ptymessageunidirectionnel :

333 Il s agit d un type de port unidirectionnel, c est à dire que la communication ne se déroule que dans un sens. Nous allons en effet recevoir un message provenant de l extérieur mais n allons pas envoyer de message en retour, l émetteur de ce message n attend rien de notre part. Le modèle de communication Requête réponse, par opposition, permet de répondre à un message entrant. Nous utiliserons le modèle Requête réponse pour la communication avec des services Web par exemple. Le type de port est à visibilité interne, c est à dire que n importe quelle orchestration implémentée dans le même projet Visual Studio pourra le réutiliser. Si au contraire nous choisissons Privé, le type de port ne sera pas visible en dehors de l orchestration. Enfin, l option Public permet de réutiliser ce type de port dans tous les projets qui référencent le projet contenant l orchestration. Dans la dernière étape de l assistant, nous devons choisir une direction de communication parmi deux options possibles : Toujours recevoir les messages sur ce port ou Toujours envoyer les messages sur ce port. Étant donné qu il s agit de la réception d une commande provenant de l extérieur, sélectionnez l option Toujours recevoir les messages sur ce port. Nous devons choisir une liaison de port. La liaison de port relie le port logique (que nous sommes en train de définir) et un emplacement physique, c est à dire un port physique. Nous avons plusieurs options, mais la plus fréquemment utilisée est Spécifier plus tard. En choisissant cette option, nous reportons l association du port logique au port physique à la phase de déploiement de l orchestration. C est exactement ce que nous souhaitons pour décorréler le métier de la technique : Dans les options possibles pour la liaison de port, il existe l option Spécifier maintenant. Cette option permet d indiquer directement dans l orchestration la configuration du transport à utiliser, c est à dire l adaptateur, le chemin ainsi que le pipeline de réception. En utilisant cette option nous faisons adhérer notre processus métier à des éléments techniques. La liaison Spécifier maintenant est très utilisée pour des démonstrations ou pour vos prototypes, mais ne l utilisez pas dans vos projets opérationnels. Lorsque vous terminez l assistant, un port logique est créé dans la Surface de port :

334 Un port logique possède toujours une opération. Une opération est composée d une Requête quand il s agit d un port unidirectionnel et d une Requête et d une Réponse quand il s agit d un port Requête réponse. La pointe verte située à droite de la Requête permet d établir le lien entre le port logique et une forme de type Recevoir située dans l orchestration. Ce lien signifie : le message réceptionné par le port logique rplcommande déclenche l exécution de la forme Recevoir nommée rcvcommande. Étant donné que le message msgcommande est associé à la forme rcvcommande, c est lui qui contiendra le message reçu. Faites le lien avec votre souris entre le port logique rplcommande et la forme rcvcommande : La pastille rouge avec un point d exclamation, présente sur la forme rcvcommande a disparu. Cela signifie que cette forme est bien configurée et qu aucune erreur ne se produira à la compilation. 5. L envoi de messages : utilisation de la forme Envoyer Nous avons réceptionné une commande dans l orchestration, nous devons maintenant l envoyer. Pour l instant, nous n effectuons pas d opération particulière sur le message. Nous allons simplement prendre le message reçu et l envoyer à l extérieur. Pour l envoi, déposez une forme Envoyer juste après la forme Recevoir. Nommez cette forme sndcommande. Associez le message msgcommande à la forme Envoyer. Inutile de créer un nouveau message puisque nous ne faisons aucune opération particulière et nous contentons d envoyer le même message. Il est nécessaire de créer un port logique pour les messages sortants : Lancez de nouveau l assistant Nouveau port configuré pour créer le port logique. Nommez le splcommande. Cette fois ci, ne créez pas un nouveau type de port mais réutilisez le type de port ptymessageunidirectionnel créé préalablement :

335 À la dernière étape de l assistant choisissez la direction de communication Toujours envoyer les messages sur ce port : il s agit cette fois ci d un port de sortie

336 6. Lisibilité des orchestrations a. Rendu final de l orchestration Notre orchestration est maintenant terminée. Si vous avez suivi les étapes indiquées, voici l orchestration obtenue : b. Positionnement des ports logiques Le positionnement des ports logiques n est pas contraint par leur direction : les ports entrants ne sont pas forcément à gauche et les ports sortants à droite. Lorsque vous implémentez des orchestrations complexes avec de nombreux messages entrants ou sortants, vous pouvez organiser les ports de l orchestration comme vous le souhaitez pour plus de lisibilité. c. Réduction des surfaces de ports Vous pouvez également réduire la taille des surfaces de port en cliquant sur le bouton << ou >> situé en haut de chaque surface. Vous réduisez la place tenue par ces surfaces et les connecteurs entre les ports logiques et les formes Envoyer ou Recevoir disparaissent. Il s agit là aussi de faciliter la lecture de l orchestration à l écran. d. Zoom Vous pouvez utiliser la fonction de Zoom de Visual Studio pour agrandir ou diminuer la taille de l orchestration à l écran. Pour l utiliser, cliquez dans une zone vide de l orchestration et ouvrez le menu contextuel. Vous pouvez également utiliser le bouton [Ctrl] et la molette de votre souris. e. Utilisation de la forme Groupe La forme Groupe, disponible dans la boîte à outils, rassemble plusieurs formes entre elles. Dans des orchestrations complexes, cette forme permet de grouper des parties d un processus et de simplifier la lecture. Cette forme n a aucune incidence sur le processus lui même. 7. Compilation de l orchestration Notre orchestration est terminée, nous pouvons lancer sa compilation et obtenir l assembly pour la déployer dans BizTalk. Vous pensez certainement que la compilation va fonctionner, et vu la simplicité de notre processus ce serait bien mérité. Lancez la génération du projet ENI.Orchestrations et observez l erreur que le compilateur BizTalk va produire : C:\ENIEditions\ENI.BizTalk\ENI.Orchestrations\GererCommande.odx(1 21,13): error X2214: vous devez indiquer au moins un ensemble de corrélations déjà initialisé pour une réception sans activation située sur un port autre qu un port d autocorrélation : par exemple, marquez la propriété Activer de réception comme True : ou marquez la propriété Liaison de port comme Directe et le

337 port d orchestration des partenaires comme Autocorrélation : ou vérifiez une corrélation sur la propriété de réception Ensembles de corrélations suivants Le message d erreur est assez mystérieux si vous n avez pas encore entendu parler des corrélations. Ne soyez pas inquiets, nous abordons ce sujet dans le détail dès le prochain chapitre. Cette erreur signifie tout simplement que BizTalk est incapable de savoir où commence le processus. Nous pensions que le simple fait de déposer une forme Recevoir au début du processus suffirait, ce n est pas le cas. Il faut explicitement indiquer à BizTalk que cette forme Recevoir active le processus. Dans l orchestration, sélectionnez la forme rcvcommande puis dans la page de propriétés, localisez la propriété Activer et changer la valeur à True. Générez de nouveau le projet et l erreur disparaît

338 Le déploiement d orchestrations Nous avons maintenant une orchestration prête à fonctionner, nous devons la déployer dans l infrastructure BizTalk et la configurer pour qu elle fonctionne. 1. Déploiement dans une application BizTalk Le déploiement d une orchestration ne diffère pas du déploiement de tout autre composant de développement BizTalk. Il suffit de lancer le déploiement depuis Visual Studio ou bien d ajouter l assembly dans les ressources de l application BizTalk : Procédez au déploiement de l assembly ENI.Orchestrations.dll dans l application BizTalk ENIEditions. 2. Liaison des ports logiques et physiques a. États de l orchestration après le déploiement L étape primordiale dans la configuration d une orchestration est la liaison entre les ports logiques et les ports physiques. Étant donné que nous avons utilisé le type de liaison Spécifier plus tard nous devons procéder à la configuration si nous voulons que l orchestration soit opérationnelle : Dans la console d administration BizTalk, ouvrez l application ENIEditions et sélectionnez le nœud Orchestrations. Vous pouvez visualiser l orchestration déployée. Elle est pour l instant à l état Désinscrit (non lié) : L état Désinscrit (non lié) signifie deux choses : L orchestration n est pas déclarée comme abonnée à des messages, c est à dire qu elle n est pas inscrite. L orchestration n est pas liée c est à dire que ses ports logiques ne sont pas associés à des ports physiques. b. Liaison entre ports logiques et physiques Afin que l orchestration soit opérationnelle nous devons lier les ports logiques aux ports physiques : Sélectionnez l orchestration dans la console d administration BizTalk, ouvrez le menu contextuel et choisissez l option Propriétés. Rendez vous dans l onglet Liaisons. Choisissez tout d abord l hôte BizTalk sur lequel l orchestration va s exécuter (BizTalkServerApplication par défaut). Nous évoquons la notion d hôte dans le chapitre Architecture et haute disponibilité. Pour chaque port logique de l orchestration (rcvcommande et sndcommande) sélectionnez respectivement un port de réception et un port d envoi. Si les ports n existent pas, vous pouvez les créer directement depuis cet écran. Sélectionnez le port rcvgestioncommerciale pour l associer au port logique rcvcommande puis le port sndcomptabilite_file pour le port logique sndcommande :

339 Les listes déroulantes qui présentent les différents ports de réception ou d envoi utilisables contiennent les ports déclarés dans l application BizTalk de l orchestration. Il s agit, dans notre cas, des ports de l application ENIEditions. Si vous souhaitez utiliser un port situé dans une autre application BizTalk, faites une référence entre l application BizTalk de l orchestration et l application BizTalk dans laquelle se trouve le port. Après validation, l orchestration change d état. Elle est maintenant à l état Désinscrit, sous entendu Désinscrit (lié). c. À quoi servent les liaisons ports logiques/ports physiques? Nous avons effectué le lien entre les ports physiques et les ports logiques car l orchestration nous demandait de le faire. Nous ne savons cependant pas ce que cela a réellement eu comme effet au niveau de BizTalk. Avons nous dit à BizTalk : Tous les messages entrant par le port rcvgestioncommerciale doivent être routés à l orchestration GererCommande? Tous les messages sortant de l orchestration GererCommande doivent être envoyés par le port d envoi sndcommande? Pour l instant, l orchestration n est pas inscrite comme abonnée. Nous ne pouvons pas encore répondre à ces deux questions, mais nous allons le faire dans le paragraphe suivant. 3. Déclaration de l orchestration comme abonné BizTalk a. Inscription de l orchestration Nous devons déclarer l orchestration comme abonné BizTalk. Cette étape a été préparée par l étape de liaison entre

340 les ports logiques et physiques, nous allons le comprendre maintenant : Souvenez vous, pour déclarer un artefact BizTalk comme abonné, il faut l inscrire. Il en est de même pour une orchestration. Sélectionnez l orchestration, ouvrez le menu contextuel et sélectionnez l option Inscrire. L orchestration est maintenant à l état Arrêté. b. Abonnement de l orchestration pour la réception de messages Lorsque l inscription de l orchestration est effectuée, un abonnement est automatiquement créé par BizTalk. L abonnement se résume dans la phrase suivante : l orchestration GererCommande consomme tous les messages de type urn:editionseni:gestioncommandes#commande réceptionnés par le port rcvgestioncommerciale. En termes de filtre, cela peut se traduire par l expression suivante : BTS.MessageType= urn:enieditions:gestioncommandes#commande AND BTS.ReceivePortName= rcvgestioncommerciale BizTalk a défini à notre place ce filtre pour l orchestration car il dispose de tous les éléments pour le faire : Il sait que l orchestration reçoit des messages de type Commande car la forme rcvcommande marquée comme Activer=True est associée à un message de type Commande. Il sait que le port logique de l orchestration par lequel entre la commande est lié au port physique rcvcommande. Si vous souhaitez vérifier que ce filtre existe dans la base de données, vous pouvez consulter la liste des abonnés avec la requête correspondante dans la console d administration. Vous pourrez vous rendre compte qu il y a une petite nuance sur le filtre puisqu au lieu d utiliser la propriété BTS.ReceivePortName, le filtre repose sur la propriété BTS.ReceivePortID qui est l identifiant unique d un port. Le port physique peut ainsi changer de nom sans que le filtre ne soit remis en cause. c. Abonnement pour l envoi de messages Nous savons maintenant comment les messages vont être délivrés à l orchestration, nous ne savons cependant pas comment les messages vont sortir de l orchestration en direction de la Comptabilité via le port d envoi sndcomptabilite_file. BizTalk a peut être modifié le filtre du port d envoi sndcomptabilite_file pour lui ajouter des nouvelles conditions et lui permettre ainsi de consommer tous les messages qui sortent de l orchestration GererCommande. Un filtre qui pourrait par exemple être BTS.OrchestrationName= GererCommande? BizTalk n a en fait pas du tout modifié le port d envoi sndcomptabilite_file, celui ci était prédisposé dès sa création pour consommer des messages provenant des orchestrations. Comment est ce possible puisque nous ne savions pas, lorsque nous avons créé ce port, qu il serait lié à une orchestration? Voici l explication. Chaque port d envoi a un filtre, non modifiable et créé automatiquement sous la forme : BTS.SPTransportID == {88204DAA E-93B3-761F4B1AAA8F} Chaque port BizTalk dispose d un identifiant unique (un GUID) calculé lors de la création du port. Un port d envoi est automatiquement abonné à tous les messages qui disposent, dans leur contexte, de la propriété promue BTS.SPTransportID contenant leur identifiant. En faisant le lien entre le port logique sortant de l orchestration et le port d envoi sndcomptabilite_file, BizTalk a simplement mémorisé cette information, il n a pas modifié le filtre du port d envoi. Lorsque l orchestration envoi un message, elle le dépose dans la MessageBox avec, dans son contexte, la propriété promue BTS.SPTransportId contenant l identifiant du port d envoi sndcomptabilite_file. 4. Schéma récapitulatif du fonctionnement

341 Le schéma ci dessous récapitule le cheminement des messages via l orchestration : Tous les messages, entrants ou sortants de l orchestration, transitent systématiquement par la MessageBox

342 Tests et débogage d orchestrations 1. Tests locaux et test unitaires Il n est malheureusement pas possible de tester localement une orchestration ni de même de créer des tests unitaires. C est assez paradoxal, puisque c est certainement le composant BizTalk sur lequel la présence de tests avant le déploiement est le plus important. Il est toutefois compréhensible que les tests locaux d orchestrations ne soient pas simples à mettre en oeuvre étant donné toute la tuyauterie mise en œuvre pour qu un message soit délivré à l orchestration. Plusieurs mois avant la sortie de BizTalk Server 2009, des rumeurs annonçaient la présence des tests unitaires pour les orchestrations. Cela n a finalement pas été le cas. Espérons que la prochaine version offre cette nouvelle fonctionnalité. Contrairement à ce que j ai répété depuis le début de cet ouvrage (tester avant de déployer), je me vois contraint de vous dire exactement l inverse, c est à dire déployez avant de tester. 2. Test de fonctionnement Nous allons donc tester l orchestration qui a été déployée. L orchestration est inscrite auprès de BizTalk, il faut simplement la démarrer. Sélectionnez l orchestration dans la console d administration BizTalk, ouvrez le menu contextuel et sélectionnez l option Démarrer. Pour que l orchestration s exécute, un message de type Commande (pivot) doit être publié dans la MessageBox par le port de réception rcvgestioncommerciale. Si vous n avez pas modifié la configuration de ce port, tout devrait fonctionner puisqu il réceptionne des commandes au format Gestion Commerciale et applique une map pour en faire des formats pivots. Déposez une commande dans le répertoire écouté par l emplacement de réception et suivez l exécution depuis la console d administration BizTalk (avec la requête Instances en cours d exécution par exemple). Lorsque l exécution est terminée, vous obtenez une commande au format Comptabilité dans le répertoire de dépôt. En observant le contenu du répertoire de dépôt, vous constatez qu il existe deux commandes. Cette situation s explique facilement : Une commande au format gestion commerciale a été réceptionnée et transformée en pivot puis publiée dans la MessageBox. BizTalk a recherché les abonnés et a trouvé 2 abonnés : l orchestration GererCommande ; le port d envoi sndcomptabilite_file. Le port d envoi sndcomptabilite_file a en effet toujours son filtre BTS.MessageType == urn:editionseni:gestioncommandes#commande. Lorsqu une commande est publiée dans la MessageBox, il consomme donc cette commande en même temps que l orchestration GererCommande. Pour éviter cette situation, vous pouvez simplement retirer le filtre du port d envoi. Ne désinscrivez pas le port d envoi sinon l orchestration ne fonctionnera plus, elle est en effet liée à ce port d envoi. 3. Débogage d une orchestration après déploiement

343 La complexité de notre orchestration ne justifie pas vraiment de devoir faire du débogage, mais nous allons tout de même illustrer comment procéder en cas de besoin. a. Mode replay Le mode que j ai nommé replay permet de visualiser graphiquement l exécution terminée d une orchestration. Vous devez tout d abord retrouver la trace de l exécution de l orchestration dans la base de données de suivi postexécution : Lancez une requête de type Instances de service suivis. Vous retrouvez l instance d orchestration qui vient de s exécuter. Sur cette instance, ouvrez le menu contextuel et cliquez sur Débogueur d orchestration : Dans la fenêtre du débogueur d orchestration, vous pouvez visualiser : Sur la partie gauche une représentation tabulaire des étapes d exécution, c est à dire des différentes formes. Chaque forme est représentée par deux lignes, une ligne pour le début et une pour la fin. La colonne type d action vous indique le type de forme. Sur la partie droite, vous pouvez visualiser la représentation graphique de l exécution. Pour comprendre le cheminement de l exécution, sélectionnez une ligne du tableau de gauche et la partie graphique de droite se mettra à jour. Dans notre exemple, la représentation graphique n apporte pas grand chose, mais lorsque vous implémentez des orchestrations complexes avec une logique de traitement plus conséquente, cela peut vous permettre de comprendre par quel chemin le message est passé dans votre processus. b. Débogage Nous voulons maintenant suivre pas à pas l exécution de l orchestration. Pour prendre la main lors de l exécution de cette orchestration, nous positionnons un point d arrêt : Entrez dans le mode replay d une instance d orchestration déjà exécutée. Dans la représentation graphique de l orchestration, sélectionnez l étape sur laquelle vous souhaitez positionner le point d arrêt. Ouvrez le menu contextuel et choisissez l option Définir le point d arrêt sur la classe :

344 Fermez la fenêtre du mode replay. Relancez maintenant un message afin de provoquer l exécution d une nouvelle instance de l orchestration. Lancez une requête du type Toutes les instances en cours d exécution. Vous retrouvez une instance de l orchestration à l état Point d arrêt (actif). Ceci indique que l orchestration est arrêtée sur votre point d arrêt. Pour ouvrir le débogueur et procéder à une exécution pas à pas, ouvrez le menu contextuel sur l instance d orchestration et sélectionnez Débogueur d orchestration. Dans l écran du débogueur d orchestration, ouvrez le menu Débogage et cliquez sur Joindre. Par cette action, vous attachez le débogueur d orchestration à l instance de votre orchestration. Dans l écran du débogueur, vous pouvez visualiser en partie basse de l écran deux nouvelles fenêtres : La liste des variables de l orchestration. Nous avons deux variables qui représentent les ports logiques et une variable qui stocke le message. Une page de propriété affichant les caractéristiques de la variable sélectionnée. Si vous sélectionnez la variable msgcommande par exemple, vous pouvez visualiser le contenu du message ou son contexte. Afin de poursuivre l exécution de l orchestration, utilisez le menu Débogage et l option Continuer. Attention, il n existe pas d option permettant de faire un pas à pas dans l orchestration. Si vous cliquez sur Continuer, l exécution se poursuit jusqu au prochain point d arrêt. S il n y a pas de point d arrêt, l orchestration se termine et le débogueur d orchestration se détache automatiquement de l instance d orchestration

345 Pour procéder à une exécution pas à pas, déposez des points d arrêt d instance et cliquez sur Continuer. À la différence d un point d arrêt de classe, un point d arrêt d instance ne s applique qu à l instance en cours d exécution. Lorsque vous utilisez des points d arrêts de classe pour entrer en débogage, pensez à les supprimer lorsque vous avez terminé le débogage. Utilisez le menu Débogage et l option Supprimer tous les points d arrêt de la classe. Si vous oubliez des points d arrêts de classes, la conséquence peut être importante. Supposez par exemple qu après une session de débogage, tout semble correct et vous décidez de déclencher l envoi d un gros volume de messages à BizTalk, par exemple messages instances d orchestrations à l état Point d arrêt (actif) se trouveront dans la MessageBox. Seule solution pour débloquer la situation : ouvrir chaque orchestration dans le débogueur d orchestration, cliquer sur Joindre puis Continuer... En principe vous rencontrez cette erreur une seule fois dans votre vie Débogage à distance d une orchestration En plus du débogueur d orchestration, utilisable directement depuis le serveur BizTalk, vous pouvez lancer une session de débogage à distance depuis le poste de travail du développeur, c est à dire via Visual Studio. Vous pouvez ainsi naviguer, étape par étape, dans le code de votre orchestration. Cette approche est intéressante car elle permet de déboguer le contenu des formes Expression ou Assignation de messages que nous utilisons plus loin dans ce chapitre. Dans le débogueur d orchestration que nous venons d utiliser, nous ne pouvons pas entrer dans le détail du code de ces formes. Avec le débogage à distance, cela est possible. Cette méthode était possible avec les versions précédentes de BizTalk Server, mais n est désormais plus documentée. Lors de l annonce de la version 2009, le débogage d orchestrations depuis Visual Studio faisait partie des nouveautés promises mais cette fonctionnalité n a finalement pas été implémentée. Espérons que cette fonctionnalité soit présente dans la prochaine version du produit ou dans un service pack. 5. Instrumentation d une orchestration Une orchestration ne peut pas être testée sans être déployée dans BizTalk sauf en utilisant le débogage à distance. Dans un environnement de production, il est rarement possible d utiliser le débogueur à distance car l équipe de développement n a pas accès à l environnement ou n a pas les droits suffisants. En utilisant le débogueur d orchestration, vous pourrez facilement comprendre le problème qui se produit en détectant quelle forme de l orchestration provoque l erreur. S il s agit d une forme Expression, dans laquelle du code.net peut être saisi, vous ne pourrez pas savoir quelle est la ligne de code qui pose problème. Il est donc nécessaire, une fois de plus, d instrumenter votre code, c est à dire d ajouter des traces que vous pourrez consulter dans l environnement de production, en demandant par exemple à l équipe d exploitation de vous fournir le fichier de log correspondant. Il y a plusieurs alternatives techniques pour mettre en place des traces, je vous conseille d utiliser un framework du marché, comme log4net ou Enterprise Library. Vous pouvez également utiliser les classes Debug et Trace contenues dans l espace de noms System.Diagnostics du framework.net. Dans les exemples de code téléchargeables, vous constaterez que j utilise la classe System.Diagnostics.Debug pour écrire des traces. Pour visualiser ces traces, utilisez l outil DebugView, disponible en téléchargement sur le site

346 Implémentation d un scénario complet Nous allons ajouter un peu d intelligence à l orchestration afin de satisfaire un besoin qu une solution de pure messagerie ne pourrait pas couvrir. Nous allons en profiter pour découvrir les différents composants offerts par la boîte à outils et étudier comment nous pouvons manipuler des messages dans les orchestrations. 1. Le scénario implémenté Nous allons faire évoluer l orchestration GererCommande et le processus global de gestion des commandes. Dans cette nouvelle version du processus, nous continuons d envoyer à l application de Comptabilité une commande au format attendu par celle ci. Nous laissons le port d envoi sndcomptabilite_file faire ce travail car nous n avons pas de plus value de le faire dans l orchestration. Nous considérons désormais que l application de gestion commerciale peut nous envoyer des commandes contenant plusieurs produits et pas un seul comme c était le cas auparavant. Nous allons gérer les mouvements de stock pour tous les produits commandés par nos clients. Lorsqu une commande est reçue par BizTalk, nous générons un message de mouvement de stock pour chaque produit de la commande et envoyons ce message à l application de gestion du stock. a. Modification du schéma Commande Pour permettre la réception de plusieurs produits dans la même commande, modifiez le schéma Commande.xsd du projet ENI.GestCo.Schemas : Ouvrez le schéma, sélectionnez le nœud Produit. Dans les propriétés, saisissez la valeur * dans la propriété MaxOccurs. Le nœud Produit peut ainsi apparaître un nombre illimité de fois. Générez un exemple de message Commande contenant plusieurs produits, nous utiliserons cet exemple pour tester notre nouveau processus de gestion de commande. Il n est pas utile de modifier la map qui permet de passer d une commande Gestion Commerciale à une commande pivot car la commande au format pivot accueille déjà plusieurs produits. b. Création du schéma MouvementStock Pour dialoguer avec le système de gestion de stock de l entreprise, nous élaborons un nouveau schéma. Pour simplifier, nous créons un format pivot MouvementStock dans le projet ENI.Schemas. Dans la réalité, nous devrions créer un schéma externe correspondant au format attendu par le système de stock puis un format pivot utilisé par BizTalk. Dans le projet ENI.Schemas, créez le schéma MouvementStock.xsd dans l espace de noms urn:enieditions:gestionstock. Modélisez le schéma comme représenté dans la copie d écran ci dessous : Copier/coller le code XSD ci dessous dans votre fichier.xsd pour obtenir le même schéma :

347 <?xml version="1.0" encoding="utf-16"?> <xs:schema xmlns:ns0="urn:editionseni:proprietes" xmlns:b=" xmlns="urn:editionseni:gestionstock" targetnamespace="urn:editionseni:gestionstock" xmlns:xs=" <xs:annotation> <xs:appinfo> <b:imports> <b:namespace prefix="ns0" uri="urn:editionseni:proprietes" location=".\propertyschema.xsd" /> </b:imports> </xs:appinfo> </xs:annotation> <xs:element name="mouvementstock"> <xs:annotation> <xs:appinfo> <b:properties> <b:property name="ns0:identifiantmouvement" xpath="/*[local-name()= MouvementStock and namespaceuri()= urn:editionseni:gestionstock IdentifiantMouvement and namespace-uri()= ]" /> <b:property distinguished="true" xpath="/*[localname()= MouvementStock and namespaceuri()= urn:editionseni:gestionstock ]/*[localname()= DateHeureMouvement and namespace-uri()= ]" /> <b:property distinguished="true" xpath="/*[localname()= MouvementStock and namespaceuri()= urn:editionseni:gestionstock ]/*[localname()= ReferenceProduit and namespace-uri()= ]" /> <b:property distinguished="true" xpath="/*[localname()= MouvementStock and namespaceuri()= urn:editionseni:gestionstock ]/*[local-name()= Quantite and namespace-uri()= ]" /> </b:properties> </xs:appinfo> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="dateheuremouvement" type="xs:datetime" /> <xs:element name="referenceproduit" type="xs:string" /> <xs:element name="quantite" type="xs:int" /> </xs:sequence> <xs:attribute name="identifiantmouvement" type="xs:string" /> </xs:complextype> </xs:element> </xs:schema> Dans ce schéma nous avons : promu la propriété IdentifiantMouvement ; créé des champs distinctifs pour les champs DateHeureMouvement, ReferenceProduit et Quantite. Vous comprendrez leur utilité dans les paragraphes suivants. c. Suppression de l envoi vers la comptabilité Dans l orchestration GererCommande, supprimez tout d abord la forme sndcommande puisque nous avons décidé de ne plus dialoguer avec l application de comptabilité, cette communication étant déjà opérationnelle via le port d envoi sndcomptabilite_file. Supprimez également le port logique sndcommande qui n est plus utilisé

348 À ce stade, l orchestration ne fait que recevoir une commande, elle ne procède à aucun traitement. Si vous déployez cette orchestration, elle consommera le message de commande et n en fera rien. 2. Accès aux données des messages dans une orchestration La première étape du processus consiste à connaître le nombre de produits reçus dans la commande. Nous avons besoin de cette information pour ensuite boucler sur chaque produit et générer un mouvement de stock correspondant. Pour compter le produit, nous devons accéder aux données du message. L accès aux données d un message dans une orchestration est possible de plusieurs manières. a. Lecture des propriétés promues d un message Dans le message de commande reçu par l orchestration, le code du client est une propriété promue. Pour accéder à cette information depuis l orchestration, nous devons écrire la ligne de code ci dessous : msgcommande(eni.schemas.codeclient) Cette ligne de code permet de récupérer la valeur de la propriété promue, mais permet également de modifier cette valeur. Cette ligne de code doit être saisie dans une forme Expression. Ce type de forme permet la saisie de code.net. Créez une variable dans l orchestration (via la Vue Orchestration). Nommez la variable codeclient et affectez la au type string. Déposez une forme Expression, lisez le contenu du code client issu de la propriété promue et stockez cette valeur dans la variable. Même si le code.net que vous pouvez saisir dans une forme Expression est très proche de la syntaxe C#, il s agit de code XLANG/S. Les deux langages sont très proches mais XLANG/S est plus restrictif. Pour modifier la valeur d une propriété promue, vous pouvez saisir la ligne de code suivante : msgcommande(eni.schemas.codeclient)="nouveau code"; Attention, cette ligne de code ne modifie que le contexte du message pas son contenu. Le code client de la commande dans le corps du message n est pas modifié via cette ligne de code. Si vous compilez l orchestration, vous obtenez des erreurs sur cette ligne de code. Reportez vous au paragraphe Construction de messages pour en savoir plus. b. Utilisation des champs distinctifs Bien que le contenu d une propriété promue soit facilement lisible depuis une orchestration, il n est pas conseillé de créer spécialement une propriété promue pour cet usage. Les propriétés promues doivent être créées uniquement lorsque vous en avez besoin pour le routage du message. Les champs distinctifs (distinguished fields en anglais) sont une alternative aux propriétés promues car ils facilitent l accès aux informations dans un message depuis une orchestration mais ne sont pas utilisés pour du routage. Les champs distinctifs sont des raccourcis vers les données d un message. En lisant le contenu d un champ distinctif, vous obtenez exactement les valeurs issues du corps message, en le modifiant, vous modifiez également le contenu du message. Créer un champ distinctif Pour créer un champ distinctif dans un schéma, par exemple le schéma ENI.Schemas.Commande, sélectionnez le champ, ouvrez le menu contextuel, sélectionnez Promouvoir puis Afficher les promotions. Dans l onglet Champs distinctifs, utilisez le bouton Ajouter>> pour créer un champ distinctif :

349 Vous ne pouvez pas créer un champ distinctif sur un champ multivalué, ce qui est également le cas pour une propriété promue. Dans la copie d écran ci dessus, nous avons créé un champ distinctif pour chaque donnée de l adresse de livraison. Lire la valeur d un champ distinctif dans une orchestration Pour lire la valeur d un champ distinctif, vous utilisez une forme Expression. La syntaxe pour lire le code postal de l adresse de livraison est la suivante : msgcommande.adresselivraison.adresse.codepostal Modifier la valeur d un champ distinctif dans une orchestration Tout comme il est possible de lire le contenu d un champ distinctif, il est possible d en modifier le contenu avec la syntaxe suivante : msgcommande.adresselivraison.adresse.codepostal ="39360"; En modifiant la valeur d un champ distinctif, vous modifiez également le contenu du message, pas seulement son contexte. Si vous copiez cette ligne de code en l état dans une forme Expression de l orchestration, vous obtenez une erreur lors de la compilation. Reportez vous au paragraphe Construction et modification de messages de ce chapitre. c. Utilisation de requêtes XPath La dernière possibilité pour lire le contenu d un message dans une orchestration est l utilisation d une requête XPath. Choisissez les requêtes XPath lorsque les deux précédentes solutions ne conviennent pas, ce n est donc pas la solution à choisir par défaut. L inconvénient majeur des requêtes XPath se situe au niveau leur élaboration. Une requête XPath est parfois complexe et difficile à mettre au point. Pour récupérer le code client de la commande, voici la syntaxe utilisée : xpath(msgcommande," /*[local-name()= Commande and namespaceuri()= urn:editionseni:gestioncommandes ]/*[localname()= CodeClient and namespace-uri()= ]");

350 Vous pouvez également modifier le contenu du message avec la ligne de code ci dessous : xpath(msgcommande," /*[local-name()= Commande and namespaceuri()= urn:editionseni:gestioncommandes ]/*[localname()= CodeClient and namespace-uri()= ]")="nouveau code"; Pour mettre au point la requête XPath, je vous conseille deux approches : Utilisez le schéma XSD de votre message pour récupérer la requête XPath. Lorsque vous sélectionnez un champ dans un schéma XSD, la propriété Instance XPath associée contient la requête permettant l accès à la valeur du champ. Utilisez des outils pour tester vos requêtes XPath avant de rencontrer des problèmes à l exécution de l orchestration. Utilisez par exemple l outil gratuit Visual XPath ( En lisant ces lignes, vous devez vous demander pourquoi cette méthode d accès aux données existe alors qu elle ne semble pas apporter d avantages par rapport aux deux autres alternatives. Le recours à des requêtes XPath est nécessaire lorsque vous souhaitez accéder à des données multi valuées dans un message. Pour récupérer la référence du premier produit d une collection de produits, vous n avez pas d autres choix que d écrire une requête XPath. L exemple ci dessous illustre cette requête : /*[local-name()= Commande and namespaceuri()= urn:editionseni:gestioncommandes ]/*[localname()= Produits and namespace-uri()= ]/*[localname()= Produit and namespace-uri()= ][0]/@*[localname()= Code and namespace-uri()= ]/text() Les requêtes XPath offrent deux autres avantages : Une requête XPath peut être très complexe. Par exemple récupérer la référence d un produit uniquement si ce produit a été commandé en quantité supérieure à 10 unités. Nous sommes ici très proches des possibilités offertes par des requêtes SQL sur une base relationnelle. Une requête XPath peut faire des calculs sur les données du message : additionner des montants, compter des nœuds dans un message... Dans notre processus nous allons justement utiliser une requête XPath pour compter le nombre de produits de la commande et récupérer les données de chaque produit. 3. Récupération du nombre de produits d une commande Ouvrez l orchestration GererCommande dans Visual Studio afin d effectuer les manipulations illustrées ci après. a. Création d une variable d orchestration Nous allons créer une variable pour stocker le nombre de produits de la commande : Dans la fenêtre Vue Orchestration, ouvrez le menu contextuel sur le nœud Variables et sélectionnez Nouvelle variable :

351 Dans les propriétés de la variable, modifiez la valeur de la propriété Indicateur afin de nommer la variable nbproduits. Associez le type System.Int32 : b. Calcul du nombre de produits commandés Pour calculer le nombre de produits commandés, ajoutez une forme Expression immédiatement après la forme rcvcommande. Nommez cette forme Compter nb produits : Dans la forme Expression, saisissez la ligne de code ci dessous permettant de compter le nombre de produits et de stocker le résultat dans la variable nbproduits : nbproduits = xpath(msgcommande,"count(/*[local-name()= Commande and namespace-uri()= urn:editionseni:gestioncommandes ]/*[local

352 name()= Produits and namespace-uri()= ]/*[localname()= Produit and namespace-uri()= ]/*)"); 4. Itérations dans une orchestration Pour parcourir la collection de produits contenus dans la commande, nous utilisons la forme Boucle. Cette forme fonctionne exactement comme une clause While dans un langage traditionnel. Vous définissez une condition qui est vérifiée dès l entrée dans la boucle et lors de chaque itération. Si la condition est vraie, la boucle continue, sinon la boucle se termine. Nous utilisons une boucle pour itérer sur les différents produits. Nous devons donc disposer d un compteur pour savoir sur quelle itération nous nous trouvons. a. Déclaration de variables Déclarons tout d abord une variable nommée numproduit qui contient le numéro d index du produit en cours dans la boucle. Cette variable est incrémentée à chaque itération de la boucle : Déclarez la variable numproduit de type System.Int32. Affectez la valeur initiale 1 à cette variable (dans la page de propriétés). b. Utilisation de la forme Boucle Déposez la forme Boucle immédiatement après la forme Expression. Saisissez la condition de boucle en double cliquant sur la forme. Saisissez : numproduit <= nbproduits Nommez la boucle Pour chaque produit afin de documenter le processus. c. Concaténation de compteurs Ajoutons également une forme Expression dans la boucle afin d incrémenter le compteur. Si vous oubliez cette étape, la boucle sera infinie. Déposez une forme Expression à l intérieur de la boucle. Nommez cette forme numproduit++. Saisissez l expression suivante à l intérieur de la forme : numproduit=numproduit+1; Le langage XLANG/S ne permet pas d écrire numproduit Prise de décision Pour illustrer la forme Décider, nous ajoutons une vérification supplémentaire dans l orchestration. Étant donné que notre entreprise ne vend que des produits en grande quantité, notre gestion de stock n est pas très précise et nous avons souvent des écarts. Il n est donc pas utile de générer un mouvement de stock si un produit est commandé à moins de 2 unités, ceci afin de ne pas surcharger le système avec des mouvements inutiles. Nous allons donc tester la quantité commandée et décider d envoyer ou non le mouvement de stock. a. Récupération de la quantité commandée

353 Pour tester la quantité commandée du produit, nous récupérons cette quantité lors du parcours de la collection de produits du message en cours de traitement : Créez une variable nommée qteproduit de type System.Int32. Créez également une variable getquantitexpath de type System.String. Cette variable est utilisée pour stocker temporairement la requête Xpath. Déposez une forme Expression au tout début de la boucle des produits. Nommez cette forme Récup. quantité. Saisissez la ligne de code suivante : getquantitexpath = System.String.Format("string(/*[localname()= Commande and namespaceuri()= urn:editionseni:gestioncommandes ]/*[localname()= Produits and namespace-uri()= ]/*[localname()= Produit and namespace-uri()= ][{0}]/*[localname()= Quantite and namespace-uri()= ])",numproduit); qteproduit = xpath(msgcommande,getquantitexpath); Dans ce code, nous procédons : À la création de la requête XPath de récupération de la quantité. Nous concaténons une requête XPath et l index du produit en cours dans la boucle des produits. En exécutant la requête Xpath, nous récupérons la quantité de produit dans le message msgcommande et stockons la valeur dans la variable qteproduit. Le stockage dans une variable n est pas obligatoire, cette ligne de code peut tout à fait être utilisée directement dans la forme Décider. Nous aurons besoin, plus loin dans le processus, de la référence produit, stockons donc la valeur dans une variable de l orchestration : getproduitxpath = System.String.Format("string(/*[localname()= Commande and namespaceuri()= urn:editionseni:gestioncommandes ]/*[localname()= Produits and namespace-uri()= ]/*[localname()= Produit and namespace-uri()= ][{0}]/@*[localname()= Code and namespace-uri()= ]),numproduit); referenceproduit = xpath(msgcommande,getproduitxpath); b. Utilisation de la forme Décider Déposez la forme Décider à l intérieur de la boucle, nommez la forme Petite quantité?. La première branche de la forme Décider se nomme par défaut Règle_1. Sélectionnez cette branche et renommez la en Oui. Double cliquez pour saisir la condition suivante sur cette branche : QteProduit < 2 Ne modifiez pas la seconde branche qui correspond au Else du If. La forme Décider s apparente plus à Switch qu à une clause If car plusieurs conditions peuvent être spécifiées au même niveau sans nécessairement procéder à des imbrications

354 6. Construction et modification de messages À l intérieur de l itération, si un mouvement de stock doit être envoyé, c est à dire dans la branche Sinon de la forme Décider, nous devons construire un message pour l envoyer au système de gestion de stock. Il y a plusieurs alternatives pour construire un message dans une orchestration. a. Forme Construction Dans une orchestration, les messages sont immuables, c est à dire qu ils ne peuvent pas être modifiés. Si vous souhaitez par exemple modifier une valeur d un message avant de le renvoyer, vous devez créer une copie du message et modifier la copie. Pour indiquer au compilateur BizTalk que vous allez effectuer une création de message, vous utilisez la forme Construction. Cette forme est un conteneur et peut accueillir deux autres formes : soit une forme Transformation permettant l application d une map ; soit une forme Assignation de message. Nous détaillons l usage de ces deux formes ci dessous. b. Utilisation d une transformation Le plus simple, et souvent d ailleurs le plus efficace est l utilisation d une map dans l orchestration. Le principe est identique à l utilisation d une map dans un scénario de messagerie. Un message est fourni en entrée de la map, transformé puis restitué en fin d exécution. Création d un message de type mouvement de stock dans l orchestration Dans notre scénario, il s agit de la manière la plus simple de produire un mouvement de stock à partir d une commande : Créez préalablement un message nommé msgmouvementstock dans la Vue Orchestration. Ce message est de type ENI.Schemas.MouvementStock. Déposez une forme Transformation dans la branche Sinon de la forme Décider. Vous remarquez que la forme est automatiquement entourée d une forme Construction. Sélectionnez la forme Construction puis nommez la Construct. Mvmt Stock. Dans la page de propriétés, localisez la propriété Messages construits et sélectionnez le message msgmouvementstock. Nous indiquons à BizTalk qu à l issue de l exécution de la construction, nous obtiendrons le message msgmouvementstock. Si vous ne construisez pas le message dans la forme Construction, l orchestration ne pourra pas être compilée. Vous pouvez construire plusieurs messages dans la même forme Construction, mais chaque message doit impérativement être construit à la sortie de la forme. Création d une nouvelle map Nous indiquons maintenant quelle map doit être appliquée dans l orchestration. Cette map, si elle n existe pas encore, peut directement être créée depuis l éditeur d orchestrations. Elle sera directement ajoutée au projet ENI.Orchestrations ce qui n est pas en cohérence avec l organisation de nos projets BizTalk : Nous allons créer un nouveau projet, ENI.Maps, pour héberger cette nouvelle map

355 Dans ce nouveau projet, référencez le projet ENI.Schemas dans lequel sont définis les schémas pivots. Créez une map nommée CommandeToMouvementStock qui prend en entrée une commande au format ENI.Schemas.Commande et produit un message au format ENI.Schemas.MouvementStock. Voici la map que vous devez construire : Particularités de la map La map utilise deux fonctoids : Le fonctoid Script pour créer un identifiant unique et le stocker dans le message IdentifiantMouvement. Le code ci dessous illustre le contenu du code du fonctoid : public string NewGUID() { return System.Guid.NewGuid().ToString(); } Le fonctoid DateTime pour stocker la date et heure courante dans le champ DateHeureMouvement. Cette map permet également d associer des valeurs par défaut aux champs : ReferenceProduit : une chaîne vide est associée à ce champ. Quantite : une valeur égale à 0 est associée à ce champ. Lorsque la map est appliquée, voici le message qu elle produit : <ns0:mouvementstock IdentifiantMouvement="bdd91ca0-c3e2-4b41-82d7-a5012b22b262" xmlns:ns0="urn:editionseni:gestionstock"> <DateHeureMouvement> T07:15:10</DateHeureMouvement> <ReferenceProduit> </ReferenceProduit> <Quantite>0</Quantite> </ns0:mouvementstock> Nous avons associé des valeurs par défaut aux champs afin qu ils existent dans le message destination, nous verrons que grâce à cela, l utilisation de ces champs est plus simple dans l orchestration. Pourquoi nous avons utilisé une map? Vous devez vous demander pourquoi nous avons créé une map puisque nous n utilisons même pas les données du message Commande qui est le message source de la map. Vous avez totalement raison. Cependant, l utilisation d une map pour construire un message apporte plusieurs avantages : La simplicité : la création d une map est simple par rapport aux autres méthodes de création de messages. La performance : même si les messages sont volumineux (en entrée comme en sortie), BizTalk utilise les mécanismes de streaming pour charger et créer les messages

356 L adaptabilité : si le message sortant (ici notre message de mouvement de stock) venait à changer (par exemple d espace de noms), il n y a pas d impact pour la map qui continue de fonctionner. Ce n est pas forcément le cas pour les autres méthodes de création de messages. D autres approches sont possibles pour créer le mouvement de stock, nous en parlons dans les paragraphes suivants. Utilisation de la map dans l orchestration Pour utiliser la map dans l orchestration, ajoutez une référence entre le projet ENI.Orchestrations et le projet ENI.Maps. Dans l orchestration GererCommande, double cliquez sur la forme Transformation et sélectionnez la map de transformation. Associez le message source et le message destination respectivement aux messages entrants et sortants de la map : c. Assignation de messages Lorsque la map est exécutée dans l orchestration, le message msgmouvementstock existe et peut donc être complété. Dans la map, nous avons assigné des valeurs aux champs IdentifiantMouvement et DateHeureMouvement. Nous devons maintenant renseigner les champs ReferenceProduit et Quantite avec les valeurs issues du produit concerné par le mouvement de stock. Nous utilisons la forme Assignation de message. Cette forme s insère elle aussi dans une forme Construction et permet, par assignation de valeurs, de construire des messages ou de les compléter. Dans notre cas, il s agit de compléter un message en cours de construction : Déposez une forme Assignation de message immédiatement après la forme Transformation. Nommez la forme Assign. Produit. Saisissez le code suivant dans cette nouvelle forme :

357 msgmouvementstock.quantite = qteproduit; msgmouvementstock.referenceproduit = referenceproduit; Si nous n avions pas associé des valeurs par défaut aux champs Quantite et ReferenceProduit, nous aurions obtenu une erreur lors de l exécution car les champs n existerait pas dans le message msgmouvementstock. La modification des valeurs de ces deux champs est possible car des champs distinctifs ont été créés dans le schéma XSD du mouvement de stock. Nous avons terminé la création du message, nous pouvons l envoyer au système de gestion de stock : Créez une forme Envoyer associée au message msgmouvementstock. Créez ensuite un port logique d envoi que vous nommez sndstock et qui sera associé à un port physique d envoi au stock. La copie d écran ci dessous représente l orchestration complète : d. Assignation de contenu XML

358 Il est également possible de créer des messages dans une orchestration uniquement via des formes d assignation de messages. Le principe est tout simple : il faut produire un message XML (avec l API System.Xml par exemple) et l assigner au message. Voici un exemple de code pour produire un mouvement de stock : xmldoc = new System.Xml.XmlDocument(); xmldoc.load("<ns0:mouvementstock IdentifiantMouvement=\"" + idmouvement + "\" xmlns:ns0="urn:editionseni:gestionstock"><dateheuremouvement>" + DateMouvement + "</DateHeureMouvement><ReferenceProduit>" + referenceproduit + "</ReferenceProduit><Quantite>" + qteproduit + "</Quantite></ns0:MouvementStock>"); msgmouvementstock = xmldoc; e. Utilisation d un utilitaire externe Il est également possible d invoquer des composants.net externes afin de produire un message. C est un dérivé de la méthode précédente puisque le code.net qui permet la création d un message est relativement proche. Par contre, si le code permettant de produire le message est complexe, il est plus aisé de l implémenter dans une assembly.net externe. Ce code peut également être réutilisé dans d autres orchestrations pour produire le même message. Nous allons illustrer le fonctionnement de cette méthode, toujours pour produire notre message de mouvement de stock. Voici le code de la classe.net permettant la création d un message de type MouvementDeStock : public class MouvementStockHelper { public static XmlDocument CreateMouvementStock(string codeproduit, int quantiteproduit) { Guid idmouvement = Guid.NewGuid(); string messagemouvementstock ="<ns0:mouvementstock IdentifiantMouvement=\"{0}\" xmlns:ns0=\"urn:editionseni:gestionstock\">" + "<DateHeureMouvement>{1}</DateHeureMouvement><ReferenceProduit>{2 }</ReferenceProduit><Quantite>{3}</Quantite></ns0:MouvementStock> "; XmlDocument doc = new XmlDocument(); doc.loadxml(string.format(messagemouvementstock,idmouvement.tostr ing(),datetime.now.tostring("s"), codeproduit,quantiteproduit)); return doc; } } Cette classe.net, hébergée dans une assembly, peut ensuite simplement être utilisée dans une orchestration en procédant comme suit : Référencez l assembly qui contient la classe.net depuis le projet contenant l orchestration. Utilisez une forme Assignation de message et saisissez la ligne de code ci dessous : msgmouvementstock = ENI.Helpers.MouvementStockHelper.CreateMouvementStock(referencePr oduit,qteproduitint); La méthode de création de message de la classe.net est statique. Il n est donc pas nécessaire d instancier la classe.net préalablement. Je vous conseille d utiliser des méthodes statiques le plus souvent possible lorsque vous

359 n avez pas besoin de préserver un état des données. Cela vous évite d être confronté aux problèmes de sérialisation que nous évoquons dans le paragraphe La persistance des données dans les orchestrations. 7. Particularité des maps dans les orchestrations L utilisation de maps dans les orchestrations offre des fonctionnalités complémentaires par rapport à l usage dans un scénario de pure messagerie. Il y a deux particularités principales. a. Application dynamique de maps Pour appliquer une map, nous utilisons normalement la forme Transformation. Grâce à la forme Assignation de message, positionnée dans une forme Construction, vous pouvez appliquer dynamiquement une map en la choisissant parmi une liste de map et selon certaines conditions. Par exemple, vous pouvez appliquer une map en fonction d une donnée du message entrant. Voici ci dessous un exemple de code qui applique la map CommandeToMouvementStock au message msgcommande : mapmouvementstock = typeof(eni.maps.commandetomouvementstock); transform(msgmouvementstock)=mapmouvementstock(msgcommande); b. Map à plusieurs entrées Une map dans une orchestration peut avoir plusieurs entrées, c est à dire qu elle peut être alimentée par plusieurs messages entrants. Vous pouvez par exemple combiner une Commande et une Confirmation de commande pour produire un mouvement de stock. Ceci sans appliquer successivement deux maps. Les maps à plusieurs entrées sont utilisables uniquement dans les orchestrations. Lorsque vous utilisez une map à simple entrée, BizTalk met en œuvre des mécanismes de streaming garantissant la performance et une consommation mémoire stable. Lorsque vous utilisez une map à plusieurs entrées, BizTalk est contraint de charger en mémoire la totalité des messages avec un impact mémoire non négligeable. Utilisez donc les maps à double entrée dans des scénarios où les messages ne sont pas volumineux. c. Recopie du contexte des messages Lorsque vous appliquez une map dans un port d envoi ou de réception, le contexte du message source est recopié automatiquement dans le contexte du message destination. Lorsque vous appliquez une map dans une orchestration, le contexte du message d origine n est pas recopié dans le message destination. Le message produit par la map dispose d un contexte quasiment vierge. Si vous souhaitez recopier le contexte du message source dans le message destination, vous devez utiliser une forme Assignation de messages après l application de la map dans laquelle vous saisissez : msgdestination(*)=msgsource(*); Cette ligne de code recopie la totalité du contexte. Pour recopier une propriété particulière du contexte, voici la ligne de code à utiliser : msgdestination(bts.receiveportname)=msgsource(bts.receiveportname); 8. Déployer et tester le nouveau processus L orchestration peut maintenant être déployée et testée. Pour exécuter notre nouveau processus, assurez vous de démarrer l orchestration et ensuite déposez un message de commande dans le répertoire d écoute du port rcvgestioncommerciale. Utilisez un message de commande avec plusieurs produits pour valider que la production d un mouvement de stock est effectuée sur chaque produit commandé en plus de 2 exemplaires

360 La persistance des données d une orchestration 1. Rôle de la persistance Lorsqu une orchestration s exécute, BizTalk procède régulièrement et à certaines étapes, à la persistance de l état de l orchestration. Cette persistance est opérée dans la base de données MessageBox de BizTalk. Grâce aux données sauvegardées régulièrement, il est possible de reprendre une orchestration à partir de son dernier état sauvegardé. C est utile dans les cas suivants : Arrêt prématuré de la machine BizTalk et redémarrage. Le moteur BizTalk peut reprendre l exécution de l orchestration depuis le dernier point de persistance. Erreur non gérée dans l orchestration. L erreur est remontée au moteur BizTalk qui suspend l instance de l orchestration. L exécution peut reprendre à partir du dernier point de persistance. Mise en sommeil de l orchestration pendant l attente d un message. Nous évoquons ce cas particulier dans le chapitre Processus métier avancés, quand nous parlerons des corrélations. Étant donné que la persistance a lieu dans la base de données MessageBox, il est tout à fait possible que l instance de l orchestration se relance sur un autre serveur du groupe BizTalk. Ces mécanismes offrent une tolérance à la panne, Nous l évoquons dans le chapitre Architecture et haute disponibilité. 2. Fonctionnement de la persistance a. Points de persistance Lorsque les événements suivants se produisent, l état de l orchestration est sauvegardé : Point d arrêt de debug. Envoi d un message. Appel d une autre orchestration de manière asynchrone (utilisation de la forme Démarrer Orchestration). Suspension de l orchestration : soit par une action utilisateur, soit en cas d erreur. Arrêt du service d exécution BizTalk. Déshydratation de l orchestration : référez vous au chapitre suivant dans lequel nous exposons le principe de déshydratation. Début et fin d une étendue transactionnelle. Référez vous au chapitre suivant pour comprendre les transactions. Fin de l exécution de l orchestration. b. Données sauvegardées Afin de sauvegarder l état d une instance d orchestration, BizTalk procède aux actions suivantes : Sauvegarde de l état de tous les composants.net instanciés par l orchestration. Sauvegarde de la valeur de toutes les variables de l orchestration

361 Sauvegarde de tous les messages de l orchestration. Sauvegarde de l état d exécution : forme en cours d exécution. c. Classes sérialisables Afin que la persistance des données fonctionne, les variables, messages et instances de classes doivent être sérialisables. Une classe sérialisable est une classe dont tous les membres (variables scalaires ou instances d autres classes) peuvent être sauvegardés et restaurés en mémoire. La sérialisation des données est une fonctionnalité fournie par le framework.net, il en est de même pour la phase inverse dite de désérialisation. Afin d être sérialisable, une classe doit être déclarée comme telle, par défaut le Framework.Net la considère comme non sérialisable. Pour déclarer une classe sérialisable, vous utilisez l attribut [Serializable]. d. Vérifications faites lors de la compilation d une orchestration Lors de la compilation d une orchestration, BizTalk vérifie que toutes les variables sont sérialisables. Si ce n est pas le cas, le compilateur BizTalk vous l indique sous forme d une erreur : error X2141: un type d objet System.Xml.XmlNode xmlnode non sérialisable peut uniquement être déclaré au sein d un service ou d une étendue atomique Dans cet exemple, une variable de type XmlNode a été déclarée dans l orchestration. Le type XmlNode n est pas sérialisable, voici pourquoi le compilateur refuse la compilation. Cette vérification n est pas toujours possible lors de la compilation car Visual Studio ne peut pas vérifier tous les membres de toutes les classes directement et indirectement utilisées par l orchestration. Seules les classes référencées directement par des variables sont vérifiées par le compilateur. e. Sauvegarde de l état et données non sérialisables Au moment où le moteur BizTalk souhaite enregistrer l état de l orchestration, une exception de type PersistenceException peut être générée si une variable ou une instance d objet n est pas sérialisable. L orchestration est suspendue et ne peut être reprise. f. Cas particulier de la classe XmlDocument Si vous observez la classe XmlDocument de l espace de noms System.Xml du Framework.Net, vous pouvez vous rendre compte qu elle n est pas sérialisable. Pourtant vous pouvez sans problèmes l utiliser dans une orchestration BizTalk. En réalité, lorsque vous utilisez la classe XmlDocument, celle ci est gérée de manière particulière par le moteur BizTalk. Lors de la compilation, la variable de type XmlDocument est transformée en une variable de type Microsoft.XLANGs.RuntimeTypes.XmlDocumentSerializationProxy permettant ainsi sa sérialisation. g. Utiliser temporairement des types non sérialisables Dans certains cas, vous serez contraints d utiliser des variables non sérialisables dans vos orchestrations. Par exemple la classe XmlNode permettant la construction de messages dans une orchestration ou le cumul de données XML. Le type XmlNode n est pas sérialisable donc vous ne pouvez pas compiler l orchestration. La plupart du temps, une variable de type XmlNode est utilisée temporairement dans l orchestration et la sauvegarde de son état n est pas souhaitée. Il faut donc indiquer à BizTalk que certaines étapes de l orchestration ne doivent pas être persistées. Plus exactement, il s agit d indiquer à BizTalk qu un bloc de code doit être totalement exécuté ou pas du tout. Pour cela, nous utilisons la forme Etendue. La forme Etendue est un conteneur de formes. Dans les propriétés de cette forme, nous indiquons qu il s agit d une transaction de type Atomique. En précisant cela au compilateur BizTalk, nous lui indiquons :

362 de sauvegarder l état immédiatement avant l exécution de l étendue ; de sauvegarder l état immédiatement après l exécution de l étendue si et seulement si les actions de l étendue ont été effectuées sans erreurs. En cas d erreur dans l exécution de l étendue, l état sauvegardé de l orchestration est celui immédiatement avant l étendue. En utilisant cette technique, nous sommes sûrs que les variables instanciées dans l étendue ne seront jamais persistées. Vous pouvez donc déclarer les variables non sérialisables au niveau de l étendue et elles seront automatiquement désinstanciées dès la fin de ce bloc de code

363 Téléchargement du code source Le code source de l ensemble des éléments de ce chapitre est disponible sous forme de deux archives : Chapitre11_CodeSource.zip qui contient le code source des projets BizTalk et Chapitre11_Bam.zip qui contient la définition du BAM et le profil de suivi BAM

364 BAM et orchestrations Le processus de commande est désormais plus complet. Il permet d informer l application de gestion de stock des mouvements de stocks correspondants aux produits commandés. Nous devons tenir compte de cette évolution du processus dans le suivi fonctionnel fourni aux utilisateurs et ainsi leur permettre de savoir qu un mouvement de stock a été envoyé à la gestion de stock. Nous allons faire évoluer le BAM mis en place dans les précédents chapitres. C est l occasion d illustrer comment le BAM peut être nourri par les orchestrations. Nous avons jusqu à maintenant collecté des données BAM dans des scénarios de pure messagerie. Nous avons utilisé un profil de suivi BAM dans lequel nous avons indiqué quelles données doivent être collectées et à quel moment. Nous allons procéder de la même manière pour l orchestration. 1. Ajout d une nouvelle activité de gestion de stock a. Création d une nouvelle activité Ajoutons tout d abord une nouvelle activité BAM de gestion de stock permettant le suivi de tous les échanges effectués avec la gestion de stock : Ouvrez le classeur Excel dans lequel nous avons défini le BAM des précédents chapitres. Créez une nouvelle activité que vous nommez Gestion du stock. Créez les indicateurs présentés dans la copie d écran ci dessous : b. Création d une nouvelle vue BAM Créez également une nouvelle vue BAM dédiée aux gestionnaires de stock. Nommez cette vue GestionnaireStock. Sélectionnez pour cette vue tous les indicateurs de l activité Gestion de stock

365 c. Déploiement de l activité et de la vue Exportez la définition BAM sous forme d un fichier XML pour effectuer le déploiement. Déployez la définition BAM en utilisant l outil bm.exe en ligne de commande : bm.exe update-all -DefinitionFile:<fichierXML> Nous utilisons l option update all au lieu de l option deploy all car l activité Gestion de commande ainsi que les vues associées ont déjà été déployées. 2. Collecter les données BAM dans une orchestration a. Création d un nouveau modèle de suivi BAM Nous allons créer un modèle de suivi BAM pour l activité Gestion du stock : Ouvrez l éditeur de modèle de suivi BAM. Importez la définition de l activité BAM Gestion de stock. Nous devons collecter les données de l activité (IdentifiantMouvementStock, ReferenceProduit et QuantiteMouvement) à partir du message de mouvement de stock créé dans l orchestration : Dans l éditeur de modèle de suivi BAM, sélectionnez la source d événement Sélectionner une planification d orchestration

366 Sélectionnez l assembly ENI.Orchestrations qui contient l orchestration de gestion de commande. Sélectionnez ensuite l orchestration ENI.Orchestrations.GererCommande. Lorsque vous avez effectué ces manipulations, l éditeur de modèle de suivi BAM affiche l orchestration en parallèle de la définition de l activité comme l illustre la copie d écran ci dessous : Faites défiler l orchestration pour visualiser la forme sndmouvementstock (qui correspond à l étape d envoi du message mouvement de stock). Sélectionnez cette forme et ouvrez le menu contextuel. Sélectionnez l option Schéma de charge du message (comprendre schéma du message en français). En sélectionnant cette option, vous faites apparaître le schéma XSD du message de mouvement de stock. Naviguez dans ce schéma pour trouver les données à collecter. Faites ensuite glisser les champs souhaités vers les indicateurs de l activité BAM. Pour collecter l étape MouvementEffectue de l activité BAM, revenez à l orchestration en utilisant le bouton [Retour arrière]. Dans l orchestration, sélectionnez la forme sndmouvementstock et faites la glisser sur l indicateur MouvementEffectue de l activité BAM. À l issue de ces différentes manipulations, vous obtenez le modèle de suivi BAM ci dessous :

367 Nous avons volontairement mis en œuvre le suivi de profil BAM en nous basant sur l orchestration afin d illustrer le fonctionnement de la collecte dans les orchestrations. Sachez que tout ce que nous collectons dans l orchestration aurait tout à fait pu être collecté directement au niveau du port d envoi vers le stock. b. Déploiement du modèle de suivi BAM Nous allons déployer le modèle de suivi BAM et le tester. Enregistrez le modèle de suivi BAM. Déployez le en utilisant le menu Outils puis Appliquer le modèle de suivi. 3. Suivi des mouvements de stock Faites entrer plusieurs messages de commande permettant la génération de mouvements de stocks. Cela aura pour effet d alimenter l activité BAM Gestion du stock. Connectez vous ensuite au portail BAM et visualisez les indicateurs métiers collectés :

368 Nous n avons pas encore relié l activité Gestion de commande à l activité Gestion du stock si bien que le portail BAM ne vous permet pas de naviguer entre ces deux activités. Nous ajoutons la notion de relation entre activités dans le chapitre BAM avancé

369 Téléchargement du code source Le code source de l ensemble des éléments de ce chapitre est disponible sous forme de deux archives : Chapitre11_CodeSource.zip qui contient le code source des projets BizTalk et Chapitre11_Bam.zip qui contient la définition du BAM et le profil de suivi BAM

370 Conclusion Voici quelques conseils sommaires que vous devez prendre en compte lorsque vous décidez d implémenter des orchestrations : Ne systématisez pas l implémentation d orchestrations quand cela n est pas nécessaire. Ne vous interdisez pas non plus à tout prix l implémentation d orchestrations. Dans certains scénarios, l implémentation sous forme de messagerie pure est extrêmement complexe et l implémentation d une simple orchestration est souvent plus rapide. Pensez à réutiliser : si vous le pouvez, pensez à développer des orchestrations génériques et réutilisables. Ne créez pas des orchestrations trop volumineuses. J ai déjà vu chez des clients, certains se reconnaissent en lisant ces lignes, des orchestrations tellement volumineuses que Visual Studio n arrive plus à les ouvrir! Très clairement dans ce type de situation, cela signifie qu il faut découper les orchestrations en plusieurs sous orchestrations comme on le ferait avec du code traditionnel. Même si cela ne paraît pas naturel au premier abord, c est une bonne pratique de procéder à ce découpage. Les orchestrations permettent, comme leur nom l indique d orchestrer. Il ne s agit donc pas d implémenter toute la logique métier de vos processus métier dans les orchestrations, mais bien de faire dialoguer les applications de votre Système d Information entre elles pour en faire un processus global. Bien qu il existe une forme Expression permettant la saisie de code.net, je vous conseille de limiter le volume de code que vous intégrez dans cette forme. Préférez l implémentation d utilitaires externes que vous invoquez depuis les orchestrations et qui sont réutilisables. Créez des orchestrations qui se terminent. N implémentez pas des processus infinis et prévoyez des points de sortie possibles suite à des actions externes ou des délais d attente. Ne faites pas de workflows humains dans les orchestrations. Les workflows humains sont plutôt réservés à Windows Workflow Fundation (WF) qui fait partie du framework.net. Si vous avez de nombreuses interactions humaines dans votre processus métier combinez un workflow implémenté dans WF et interconnectez votre orchestration avec le workflow. Vous pouvez ainsi bénéficier de la connectivité de BizTalk avec le système d information et des fonctionnalités de workflow humain de WF. Dans le prochain chapitre, nous évoquons des concepts avancés permettant l orchestration de processus métier plus complets et plus complexes

371 Introduction Dans le précédent chapitre, nous avons découvert les orchestrations et implémenté un scénario basé sur la gestion des commandes dans l entreprise. Nous allons étendre ce scénario en ajoutant différentes fonctionnalités. C est réellement dans ce chapitre que vous mesurerez l apport des orchestrations par rapport aux scénarios de pure messagerie

372 Les corrélations 1. Extension du processus de gestion de commande Nous allons débuter l extension du processus en modifiant le comportement du système de gestion de stock. Actuellement, nous envoyons des mouvements à la gestion de stock sans attendre de réponse en retour. Dans la réalité, le système de stock va certainement nous indiquer si le produit est disponible et si nous pouvons satisfaire la commande de notre client. Si ce n est pas le cas, nous allons tenir notre client informé et lui indiquer que sa commande ne peut pas être totalement servie. Voici un schéma qui illustre le nouveau processus de gestion de commande : La mise en œuvre de ce processus suppose : De produire un acquittement de commande pour la gestion commerciale. Cet acquittement indiquera si la commande peut être servie en fonction de l état du stock. Le personnel commercial de l entreprise pourra ainsi contacter directement le client pour l informer que certains produits sont en rupture de stock. De réceptionner et interpréter un message d acquittement reçu de la gestion de stock indiquant la quantité de stock disponible. 2. Échanges asynchrones avec la gestion de stock Lorsque nous allons envoyer un message de mouvement de stock, nous devons attendre en retour un acquittement correspondant dans lequel nous trouverons la quantité de stock disponible. Le système de gestion de stock est en cours de migration mais dans sa version actuelle il ne peut pas répondre de manière synchrone à nos messages. Les mouvements de stock sont envoyés au gestionnaire de stock par e mail. Il se déplace ensuite physiquement dans l entrepôt pour vérifier si le produit est disponible en quantité suffisante. Si c est le cas, il réserve la quantité souhaitée en étiquetant les produits. Ensuite, il répond à l e mail qui lui a été envoyé pour indiquer la quantité de produit réservée pour la commande. Pas soucis de simplicité, nous allons simuler l envoi d e mails sous forme de fichiers. Sachez en tout cas que l intégration avec un système de messagerie électronique pour recevoir ou envoyer des messages supposerait des changements très mineurs qui n impacteraient pas le processus métier lui même, mais uniquement la configuration des ports de réception et d envoi

373 3. Notion de corrélation a. Les problématiques à prendre en compte Le fait que les échanges soient asynchrones entre BizTalk et la gestion de stock suppose de tenir compte des problématiques suivantes. Multiplicité des mouvements de stocks Plusieurs commandes peuvent potentiellement être en cours de traitement dans le système, donc plusieurs instances de l orchestration de gestion de commande s exécutent en parallèle. Chaque instance de l orchestration produit un message de mouvement de stock et l envoie à la gestion de stock. La gestion de stock reçoit ainsi de nombreux messages de mouvements de stock et doit répondre à chaque message. Toutes ces réponses sont postées à BizTalk. BizTalk doit être en mesure d identifier quelle instance d orchestration est intéressée par la réponse et lui délivrer pour qu elle continue son traitement. Temps d attente Étant donné qu une partie du processus est manuelle (le gestionnaire de stock se déplace dans l entrepôt pour vérifier le stock), le temps d attente entre l envoi d un mouvement de stock et la réception de l acquittement peut être long. Si le mouvement de stock est envoyé en dehors des heures de travail du gestionnaire de stock, la réponse n arrivera que le lendemain matin par exemple. Les instances du processus de gestion de commande doivent patienter et se réveiller lorsqu une réponse est apportée par la gestion de stock. Le simple fait qu il existe un grand nombre d instances d orchestrations en sommeil ne doit pas pénaliser les performances globales du système. b. La réponse apportée par BizTalk BizTalk peut répondre à ces deux problématiques. Déshydratation et réhydratation Les fonctionnalités de persistance que nous avons détaillées dans le précédent chapitre permettent à BizTalk d endormir des instances d orchestration (on parle de déshydratation) pendant le temps d attente. Si BizTalk considère que le temps d attente peut être long entre l envoi du mouvement de stock et l arrivée de la réponse, il stocke l état de l orchestration en base de données. Lorsqu une réponse arrive pour l instance de l orchestration il réhydrate l orchestration, c est à dire la recharge en mémoire et reprend son exécution. Même si un très grand nombre d instances d orchestrations sont en sommeil et en attente d une réponse, les performances du système ne sont pas altérées. Si toutes les réponses du stock arrivent en même temps, BizTalk gère cette montée en charge subite et régule la délivrance des messages afin de ne pas mettre le système en péril. Pour réguler l activité du système, BizTalk s appuie sur des mécanismes de throttling. Nous abordons cette notion dans le chapitre Administration de BizTalk Server. Corrélations La notion de corrélation est la réponse apportée par BizTalk pour relier un message publié dans BizTalk à une instance spécifique d une orchestration en cours d exécution. Nous allons détailler comment les corrélations fonctionnent et les mettre en œuvre dans notre scénario. 4. Fonctionnement des corrélations a. Qu est ce qu une corrélation?

374 Le schéma ci dessus illustre le fonctionnement d une corrélation lorsqu un message est envoyé par une instance d orchestration puis lorsqu un message en réponse est réceptionné par la même instance d orchestration. Une corrélation représente le lien entre plusieurs messages. Ce lien est effectué sur la base d informations se trouvant dans le contexte BizTalk de chaque message (le message envoyé et le message reçu). La corrélation est définie lors du développement de l orchestration en précisant les propriétés promues reliant les messages. Dans notre scénario métier, le lien entre un mouvement de stock et un acquittement provenant du stock est effectué sur la base d un identifiant unique de mouvement de stock. Cet identifiant est généré avant l envoi au système de stock. L acquittement reçu contient un rappel de cet identifiant. Lors de l exécution de l instance d orchestration, deux étapes relatives à la corrélation se suivent : Tout d abord l initialisation de la corrélation. Cette étape s exécute lorsque le message de mouvement de stock est publié dans la MessageBox. Puis la suite de la corrélation. Une corrélation qui a été initialisée doit forcément être suivie. Lorsque le message de réponse est publié dans la MessageBox et délivré à l instance de l orchestration, on dit qu il y a suite de la corrélation (en anglais follow correlation). b. Corrélations et abonnements d instances Nous allons maintenant comprendre comment BizTalk identifie l instance d orchestration en attente du message de réponse. Pour rappel, plusieurs instances de la même orchestration (gestion de commandes) peuvent être actives au moment de la publication d un acquittement de stock et toutes ces instances sont peut être en attente de ce type de message. Comme nous l avons vu, une corrélation qui a été initialisée doit être suivie. Lorsque BizTalk détecte la présence d une corrélation, il crée à la volée un abonnement dans la MessageBox, spécifiquement pour l instance d orchestration concernée. On parle d abonnement d instance. Contrairement à un abonnement d activation, qui permet, à la réception d un message dans la MessageBox, d instancier une nouvelle orchestration, un abonnement d instance permet de router un message vers une instance d orchestration active. Si plusieurs instances d orchestrations sont en attente de messages provenant du stock, il existe plusieurs abonnements d instances, un par orchestration. L abonnement automatique créé par BizTalk pour chaque instance d orchestration est illustré par le filtre cidessous : BTS.MessageType="urn:EditionsENI:GestionStock:AckMouvementStock" AND ENI.Schemas.IdentifiantMouvement="{identifiant mouvement stock}". Lorsqu un message est publié dans la MessageBox, BizTalk détermine s il correspond au filtre et, si c est le cas, le délivre à l instance d orchestration concernée. L abonnement disparaît ensuite automatiquement. 5. Mise en œuvre des corrélations a. Création de nouveaux schémas

375 Pour faire évoluer notre scénario, nous devons créer deux nouveaux schémas : Un schéma relatif aux acquittements reçus de la gestion de stock. Nous appelons ce schéma AckMouvementStock.xsd et l ajoutons au projet ENI.Schemas. Un schéma permettant de produire un acquittement pour la gestion commerciale. Nous appelons ce schéma AckCommande.xsd dans le projet ENI.Schemas. Voici ci dessous le code XSD que vous pouvez copier et coller dans les fichiers XSD correspondants. Schéma AckMouvementStock <?xml version="1.0" encoding="utf-16"?> <xs:schema xmlns:ns0="urn:editionseni:proprietes" xmlns:b=" xmlns="urn:editionseni:gestionstock" targetnamespace="urn:editionseni:gestionstock" xmlns:xs=" <xs:element name="ackmouvementstock"> <xs:annotation> <xs:appinfo> <b:properties> <b:property distinguished="true" xpath="/*[localname()= AckMouvementStock and namespaceuri()= urn:editionseni:gestionstock ]/*[localname()= QuantiteDisponible and namespace-uri()= ]" /> <b:property distinguished="true" xpath="/*[localname()= AckMouvementStock and namespaceuri()= urn:editionseni:gestionstock ]/*[localname()= ReferenceProduit and namespace-uri()= ]" /> </b:properties> </xs:appinfo> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="identifiantmouvementacquitte" type="xs:string" /> <xs:element name="referenceproduit" type="xs:string" /> <xs:element name="quantitedisponible" type="xs:int" /> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Schéma AckCommande <?xml version="1.0" encoding="utf-16"?> <xs:schema xmlns:b=" xmlns="urn:enieditions:gestioncommande" targetnamespace="urn:enieditions:gestioncommande" xmlns:xs=" <xs:element name="ackcommande"> <xs:complextype> <xs:sequence> <xs:element name="numerocommande" type="xs:string" /> <xs:element name="etatcommande" type="xs:string" /> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> b. Promotion de nouvelles propriétés Pour que BizTalk établisse la corrélation entre les messages de mouvement de stock et d acquittement, nous devons promouvoir une nouvelle propriété. Nous appelons cette propriété IdentifiantMouvement :

376 Ouvrez le schéma MouvementStock et faites la promotion du champ IdentifiantMouvement. Une propriété nommée IdentifiantMouvement sera automatiquement créée dans le schéma de propriété du projet ENI.Schemas. Nous devons également promouvoir le champ IdentifiantMouvementAcquitte du schéma AckMouvementStock dans la propriété promue IdentifiantMouvement. Si vous utilisez l assistant Promotion rapide, une nouvelle propriété promue sera créée : ce n est pas ce que nous souhaitons. Suivez donc la procédure ci dessous : Ouvrez le schéma AckMouvementStock. Sélectionnez le champ IdentifiantMouvementAcquitte, ouvrez le menu contextuel et sélectionnez Promouvoir puis Afficher les promotions. Dans l onglet Champs de propriété, cliquez sur l icône qui représente un classeur et localisez le schéma de propriété ENI.Schemas.PropertySchema. Sélectionnez le champ IdentifiantMouvementAcquitte et cliquez sur le bouton Ajouter>>. Dans la colonne Propriété, sélectionnez la propriété IdentifiantMouvement et cliquez sur OK pour terminer

377 La propriété ENI.Schemas.IdentifiantMouvement sera renseignée par la valeur du champ IdentifiantMouvement quand un mouvement de stock sera publié et par la valeur du champ IdentifiantMouvementAcquitte lorsqu un acquittement de stock sera publié. c. Réception de la réponse en provenance du stock Dans l orchestration GererCommande nous ajoutons une forme permettant de recevoir l acquittement de stock : Ouvrez l orchestration GererCommande. Créez un message nommé msgackmouvementstock de type ENI.Schemas.AckMouvementStock. Ajoutez une forme Étendue nommée EchangeStock. Dans les propriétés de cette forme, sélectionnez le Type de transaction à Aucun. Nous expliquons à la fin des manipulations pourquoi nous devons créer une étendue. Ajoutez une forme Recevoir immédiatement après la forme Envoyer nommée sndmouvementstock. Nommez cette forme rcvackmouvementstock et associez la au message msgackmouvementstock. Créez un nouveau port configuré que vous nommez rcvstock. Associez ce port au type de port ptymessageunidirectionnel existant. Indiquez que vous allez recevoir des messages. Créez maintenant une nouvelle opération sur le port. Nommez cette opération AckMouvementStock. Reliez la forme rcvackmouvementstock à cette opération :

378 d. Création de la corrélation Nous allons créer la corrélation qui relie le message envoyé (msgmouvementstock) et le message attendu en retour (msgackmouvementstock). Dans la Vue Orchestration, déroulez le nœud correspondant à l étendue que nous avons nommée EchangeStock. Sélectionnez le nœud Ensembles de corrélations, ouvrez le menu contextuel et choisissez l option Nouvel ensemble de corrélations : Nommez l ensemble de corrélation corstock. Dans la page de propriétés correspondante, ouvrez la liste déroulante située en face de la propriété Type de corrélation et choisissez Créer un type de corrélation. Un type de corrélation est ajouté à la vue orchestration. Renommez le tcoidentifiantmouvement. Dans la page de propriétés correspondant à ce type, sélectionnez la propriété Propriétés de corrélation. Cliquez sur le bouton... À gauche de l écran, sélectionnez la propriété ENI.Schemas.IdentifiantMouvement et cliquez sur le bouton Ajouter >>

379 Nous venons de créer un ensemble de corrélations puis un type de corrélation. Le type de corrélation indique les propriétés promues qui sont utilisées pour faire le lien entre les messages, voici pourquoi chaque message doit disposer de la même propriété promue contenant la valeur de rapprochement. Un type de corrélation peut contenir jusqu à six propriétés. Il n est en effet pas toujours possible de trouver une seule propriété pour distinguer un message. e. Association de la corrélation aux formes d envoi et réception Nous devons tout d abord indiquer à BizTalk à partir de quelle étape de l orchestration la corrélation est initialisée. Il s agit dans notre cas, de la forme sndmouvementstock : Sélectionnez la forme sndmouvementstock. Dans la page de propriétés, ouvrez la liste déroulante située en face de la propriété Initialisation des ensembles de corrélations et sélectionnez l ensemble de corrélation corstock

380 Nous devons maintenant préciser à quelle étape la corrélation se poursuit : Sélectionnez la forme rcvackmouvementstock. Dans la page de propriétés ouvrez la liste déroulante située en face de la propriété Ensembles de corrélations suivants pour sélectionner l ensemble de corrélation corstock. Nous avons terminé la mise en place du processus d envoi/réception avec le système de stock. f. Ensembles de corrélations dans une boucle Au tout début des manipulations, nous avons créé une Étendue non transactionnelle (propriété Type de transaction égale à Aucun). Une étendue fonctionne comme un bloc de code dans lequel peuvent être déclarés des messages, des variables et des ensembles de corrélations. Les éléments déclarés dans une étendue sortent de portée dès la fin de l étendue. Étant donné que nous utilisons l ensemble de corrélation dans une boucle, pour chaque produit commandé, nous ne pouvons pas l initialiser plusieurs fois. En créant une étendue, nous déclarons localement l ensemble de corrélation qui, de ce fait, sort de portée dès la fin de l étendue, c est à dire dès que la réponse a été obtenue du stock. Si un nouveau mouvement de stock doit être envoyé, l ensemble de corrélations est créé de nouveau et nous pourrons ainsi l initialiser

381 g. Envoi de l acquittement de commande L envoi d acquittement à la gestion commerciale est simple. Il faut produire un message de type acquittement et indiquer à la gestion commerciale si la commande peut être honorée. Voici quelques éléments permettant l implémentation de cette partie du processus. Exploiter la réponse provenant du stock Lorsque la réponse du stock est réceptionnée par l orchestration, il faut l interpréter et déterminer si suffisamment de produits sont disponibles. Le stock informe de la quantité qui reste en stock. Si la quantité disponible est inférieure à la quantité souhaitée, il y a rupture de stock : if (msgackmouvementstock.quantitedisponible < qteproduitint) { EtatCommande = EtatCommande + System.String.Format("{0] produits de référence {1} sont disponibles en stock à ce jour."); } Dans cet exemple de code, situé dans une forme Expression juste après la réception de la réponse du stock, la variable EtatCommande est alimentée avec un message informant du produit en rupture. Étant donné que cette opération est effectuée pour chaque produit, la variable contient, à la fin du processus, un récapitulatif de tous les problèmes rencontrés. Cette information est envoyée à la gestion commerciale. Envoyer l acquittement Pour envoyer l acquittement, un composant.net externe est implémenté et permet de produire, à partir d un numéro de commande et d un message, un acquittement de commande. Voici le code de la classe.net : public static XmlDocument GenererAckCommande(string numerocommande, string etatcommande) { string ackcommande = "<ns0:ackcommande xmlns:ns0=\"urn:enieditions:gestioncommande\"><numerocommande>{0} </NumeroCommande>" + "<EtatCommande>{1}</EtatCommande></ns0:AckCommande>"; XmlDocument doc = new XmlDocument(); doc.loadxml(string.format(ackcommande, numerocommande, etatcommande)); return doc; } Cette classe.net est utilisée dans une forme Assignation de message en toute fin d orchestration afin de produire le message et juste avant de l envoyer. Pour obtenir le code source complet de la solution, téléchargez le fichier Chapitre12_CodeSourceCorrelations.zip. h. Déployer le nouveau processus Nous allons tester le fonctionnement du processus. Déployez l orchestration dans sa nouvelle version. Pour simplifier le processus de déploiement, désinstallez préalablement la version précédente de l assembly et procédez à sa réinstallation. Dans un environnement de production, la nouvelle version du processus peut être déployée en parallèle de la version existante. Le numéro de version de l assembly doit être modifié afin d obtenir un nom fort différent et de permettre le déploiement en parallèle. Il faut ensuite désinscrire l ancienne version d orchestration et inscrire la nouvelle version. Pour tester le processus, créez deux nouveaux artefacts de messagerie dans l application ENIEditions : Un port de réception des messages en provenance du stock. Nommez ce port rcvstock. Associez le au pipeline de réception XMLReceive et faites le écouter dans un répertoire de dépôt de fichier (c:\enieditions\tests\retourstock\*.xml)

382 Un port d envoi d acquittement pour la gestion commerciale. Nommez le sndgestioncommerciale_file et faites le pointer sur un répertoire de dépôt de messages pour la gestion commerciale (c:\enieditions\tests\envoigestioncommerciale\ack_%messageid%.xml). Avant de démarrer l orchestration, effectuez les liaisons avec les nouveaux artefacts de messagerie : i. Tester le processus et observer le comportement Testez le processus en déposant une commande provenant de la gestion commerciale. Si la quantité commandée est suffisante, un mouvement de stock est envoyé au système de stock. Visualisez ce mouvement de stock dans le répertoire de dépôt du port sndstock. Tant que vous ne déposez pas un acquittement dans le répertoire de retour du stock (écouté par le port de réception rcvstock), l instance de l orchestration est à l état En attente (ou Déshydratée selon l occupation du système). Avant de déposer une réponse en provenance du stock, visualisez les abonnements d instance. Sélectionnez l orchestration dans la liste des instances en cours d exécution, ouvrez le menu contextuel et choisissez l option Afficher les abonnements d instance

383 Dans les détails de l abonnement d instance, vous pouvez consulter l expression de filtre qui est automatiquement générée grâce à la corrélation : Cet abonnement d instance va disparaître dès que vous publiez un message de type urn:editionseni:gestionstock#ackmouvementstock avec l identifiant de mouvement correspondant et provenant du port lié à l orchestration. Tant que vous ne publiez pas un message avec ces caractéristiques, l abonnement reste actif. L instance d orchestration attend indéfiniment le message, sauf si vous terminez l instance manuellement. Dans ce cas l abonnement d instance sera supprimé automatiquement. Si vous testez le processus correctement, voici un exemple d acquittement de commande produit par le processus et envoyé à la gestion commerciale : <ns0:ackcommande xmlns:ns0="urn:enieditions:gestioncommande"> <NumeroCommande>ENI_ T05:18:11</NumeroCommande> <EtatCommande>Seuls 2 produits de code CocotteMinute sont disponibles en stock à ce jour.</etatcommande> </ns0:ackcommande> Cet acquittement indique que le produit CocotteMinute n est pas disponible en plus de deux exemplaires. L assistante commerciale peut contacter le client et lui demander s il veut annuler la commande, supprimer le produit en rupture ou commander une quantité plus petite de ce produit. 6. Le processus doit savoir s impatienter a. L impact d un processus bloqué La gestion de stock est manuelle dans notre entreprise, il est donc tout à fait possible que le gestionnaire de stock oublie de répondre à un mouvement que nous lui avons envoyé. Cette situation va changer quand nous mettrons en place la nouvelle version du système de gestion de stock comme vous pourrez le constater dans le chapitre consacré aux services Web avec BizTalk

384 Le processus de gestion de commande peut attendre indéfiniment une réponse du stock qui n arrivera jamais. Ce blocage aura une incidence sur toute la chaîne puisque la gestion commerciale n obtiendra pas d acquittement. L équipe commerciale ne pourra pas tenir le client au courant de la disponibilité des produits. L onde de choc est donc importante. Pour éviter cette situation, le processus de gestion de commande doit détecter les blocages potentiels et agir en conséquence. L orchestration doit savoir s impatienter. b. Utilisation des formes Écouter et Délai Pour que le processus se débloque après un laps de temps d attente, nous utilisons conjointement deux formes : La forme Écouter La forme Délai Comme l illustre la copie d écran ci dessus, la forme Écouter, que nous avons nommée Attente réponse stock, attend : soit l arrivée d un message provenant du stock ; soit le dépassement d un délai d attente. Lorsque l un des deux événements survient, la ou les formes se trouvant en dessous sont exécutées et l attente d événement se termine. La forme Délai nommée Pas de réponse dans la copie d écran contient le code suivant : new System.TimeSpan(0,2,0) Si le gestionnaire de stock met plus de deux minutes à nous répondre, nous n attendons pas plus longtemps sa réponse et la forme Expression nommée Ack "pas de réponse" est exécutée. Elle contient le code ci dessous : EtatCommande = EtatCommande + System.String.Format("Impossible de déterminer le stock du produit de code {0}.",referenceProduit); L exécution de l orchestration se poursuit ensuite normalement. La forme Écouter peut contenir plus de deux événements. Les deux seules formes pouvant être utilisées conjointement avec la forme Écouter sont les formes Recevoir et Délai

385 c. Utilisation d un message de déblocage Il est parfois difficile de déterminer un délai d attente tant le processus métier est complexe et tant il concerne de nombreux partenaires. Nous avons considéré dans le cas précédent que le gestionnaire de stock était aidé par du personnel capable de répondre en moins de deux minutes. Si pendant certaines périodes de l année ce temps de réponse est tout à fait possible, il n en est peut être pas de même lors des périodes de congés où l effectif de l entrepôt est sérieusement diminué. Dans ce cas, comment pouvons nous procéder? Devons nous gérer des calendriers de congés dans l orchestration et en fonction du nombre de personnes présentes mettre en œuvre un temps d attente plus ou moins important? Certainement pas. Nous devons réagir à d autres événements que des temps d attente. Il est ainsi préférable de combiner un délai d attente plutôt long (de l ordre de plusieurs semaines par exemple selon le processus) et un déclencheur externe. Ce déclencheur externe, qui est vu par l orchestration comme un message entrant, permet de débloquer la situation. Le processus est ainsi débloqué par l arrivée d un message permettant : soit de relancer un mouvement pour la gestion de stock ; soit d annuler le processus de commande et d en informer la gestion commerciale. L envoi de ce message à l instance d orchestration est effectué directement depuis la gestion commerciale ou bien depuis une console de suivi fonctionnelle offerte aux utilisateurs. Dans un scénario métier complet, nous pouvons imaginer que le responsable commercial de l entreprise est alerté par le BAM BizTalk lorsqu une commande passée il y a deux jours par un client n a toujours pas été acquittée. En détectant ce cas, il peut investiguer et rechercher la cause du blocage. S il détecte que le processus est coincé au niveau du stock il peut relancer le processus en postant un message dans BizTalk. L action permettant de poster ce message peut être un envoi d e mail à BizTalk avec la référence de la commande ou bien une action depuis un portail Web de suivi. Voici par exemple comment ce processus de déblocage pourrait être modélisé dans l orchestration :

386 Convois Nous allons maintenant traiter d une notion très importante lorsque l on implémente des processus métier. Il s agit de la notion de convoi (convoy en anglais). 1. Les convois dans notre processus de gestion de commande Dans BizTalk un convoi est une collection de messages qui convoient vers la même destination, c est à dire vers le même processus métier. Ces messages sont attendus par une même instance d un processus métier. Nous allons faire évoluer notre scénario afin d ajouter une étape de confirmation de commande. Suite à de nombreuses annulations de commande, le service commercial demande désormais aux clients de confirmer leur commande sous 48 heures sinon la commande n est pas prise en compte. Notre processus va donc évoluer comme suit : Le convoi, dans notre processus, se situe entre la réception de la commande et la réception de la confirmation. On parle de convoi car le message de confirmation de commande doit être convoyé vers le processus de gestion de commande correspondant. Étant donné qu il y a plusieurs instances de processus de commande, BizTalk doit diriger le message de confirmation vers une instance d orchestration spécifique. Nous allons de nouveau utiliser la notion d ensembles de corrélations. Afin de rapprocher la confirmation de commande et la commande, nous allons utiliser le code client. Nous considérons qu un même client ne peut pas passer une nouvelle commande tant qu il n a pas confirmé la précédente ou tant que la précédente n a pas été automatiquement annulée. Dans un processus opérationnel, il est préférable de trouver des informations plus discriminantes que le code client, par exemple en utilisant un numéro de commande client ou un numéro de commande fourni au client avant sa confirmation. 2. Mise en œuvre d un convoi a. Créer le schéma de la confirmation de commande Nous devons tout d abord créer le schéma de confirmation de commande dans le schéma ENI.Schemas. Pour simplifier l exercice, considérons que la gestion commerciale sait produire des messages au format pivot. Nous évitons ainsi de créer un schéma de confirmation de commande dans le projet ENI.GestCo.Schemas et une map de transformation. Dans un vrai projet, je vous conseille de systématiser l approche par format pivot même si cela peut vous sembler fastidieux, c est un gage de pérennité et d évolutivité. Créez un nouveau schéma nommé ConfirmationCommande dans le projet ENI.Schemas. Recopiez le code XSD cidessous :

387 <?xml version="1.0" encoding="utf-16"?> <xs:schema xmlns:ns0="urn:editionseni:proprietes" xmlns:b=" xmlns="urn:enieditions:gestioncommande" targetnamespace="urn:enieditions:gestioncommande" xmlns:xs=" <xs:annotation> <xs:appinfo> <b:imports> <b:namespace prefix="ns0" uri="urn:editionseni:proprietes" location=".\propertyschema.xsd"/> </b:imports> </xs:appinfo> </xs:annotation> <xs:element name="confirmationcommande"> <xs:annotation> <xs:appinfo> <b:properties> <b:property name="ns0:codeclient" xpath="/*[localname()= ConfirmationCommande and namespaceuri()= urn:enieditions:gestioncommande ]/*[localname()= CodeClient and namespace-uri()= ]" /> </b:properties> </xs:appinfo> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="codeclient" type="xs:string" /> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Le schéma contient une propriété promue : le code client. Nous sommes maintenant prêts pour mettre en place l ensemble de corrélations nécessaire au convoi. b. Ajout de l étape de réception de la confirmation de commande Dans l orchestration GererCommande, ajoutez les formes illustrées dans la copie d écran ci dessous :

388 Les nouvelles étapes du processus, immédiatement après la réception de la commande sont les suivantes : Une forme Écouter nommée Attente confirmation. Une forme Recevoir nommée rcvconfirmation associé à un message msgconfirmationcommande de type ENI.Schemas.ConfirmationCommande. Une forme Délai nommée 48 heures dans laquelle le code suivant est saisi : new System.TimeSpan(0,5,0). Nous avons réduit le temps d attente à 5 minutes pour les tests. Une forme Terminer nommée Fin du processus. Cette forme permet d arrêter prématurément une orchestration et de spécifier un message qui sera consultable dans le suivi post exécution. L utilisation d une forme Terminer n est pas très fréquente car il s agit d une fin brutale du processus. L instance de l orchestration est marquée comme Terminée et non comme Réussie. Nous l utilisons ici simplement pour l exemple mais préférez une fin normale de processus. Le code de la forme Terminer est le suivant : "Le client " + msgcommande(eni.schemas.codeclient) + " n a pas confirmé sa commande". En amont, nous avons ajouté une nouvelle opération au port rplcommande. Cette opération nommée ConfirmationCommande est reliée à la forme rcvconfirmationcommande. c. Création de l ensemble de corrélations Créons maintenant l ensemble de corrélations qui va relier la commande et la confirmation de commande : Créez un ensemble de corrélations nommé corconfirmation. Créez également un nouveau type de corrélation nommé tcocodeclient. Associez la propriété promue ENI.Schemas.CodeClient à ce type de corrélation. Nous devons maintenant associer cet ensemble de corrélations avec les deux formes de réception de message : rcvcommande et rcvconfirmationcommande : Sélectionnez la forme rcvcommande et sélectionnez l ensemble de corrélations corconfirmation dans Initialisation des ensembles de corrélations

389 Sélectionnez la forme rcvconfirmationcommande et sélectionnez l ensemble de corrélations corcommande cette fois ci dans Ensemble de corrélations suivants. d. Transmission ordonnée des messages Nous venons de créer un convoi dit séquentiel et non uniforme. Séquentiel car nous connaissons à l avance l ordre d arrivée des messages (la commande arrive toujours avant la confirmation). Non uniforme car les messages reçus dans le convoi ne sont pas tous de même type. Pour rappel, rien n empêche un message envoyé en dernier d arriver le premier dans BizTalk, sauf en utilisant un transport qui garanti la délivrance ordonnée des messages comme MSMQ (MicroSoft Message Queuing). Supposons que les messages soient publiés dans le bon ordre dans la MessageBox. Malgré cela, nous n avons aucune garantie qu ils soient traités exactement dans cet ordre. Étant donné que des opérations sur les messages peuvent être menées en parallèle, tout va dépendre du volume d opérations à réaliser et du temps pour réaliser ces opérations. Nous devons donc indiquer à BizTalk que notre processus doit impérativement recevoir les messages dans l ordre de leur publication dans la MessageBox : la commande en premier, ensuite la confirmation. Si nous ne faisons pas cela, nous obtiendrons le message d erreur ci dessous lors de la compilation : error X2260: dans un convoi séquentiel, les messagetypes doivent être identiques, à moins que le port ne soit défini en vue d une livraison chronologique des messages Sélectionnez le port logique rplcommande par lequel les commandes et confirmations de commande arrivent dans l orchestration. Dans la page de propriétés du port logique, modifiez la propriété Livraison chronologique des messages pour la positionner à True : e. Déploiement et tests du nouveau processus Testez maintenant le processus en déployant l orchestration ainsi que les schémas associés. Si vous publiez une confirmation de commande avant la commande, vous obtiendrez une erreur de routage. Il n y a en effet pas d abonné aux confirmations de commande dans l absolu, seulement des abonnés à des confirmations de commande dans le cadre d un processus de commande existant

390 Si vous attendez plus de 5 minutes avant d envoyer la confirmation d une commande, vous pourrez visualiser, dans le suivi post exécution, le message qui a été spécifié dans la forme Terminer de l orchestration. Dans l exemple cidessous, une orchestration a été terminée sans erreur (état Réussi) et l autre a été terminée prématurément (état Terminé). Le message d erreur est affiché dans le champ Description de l erreur. Il est préservé dans l historique : f. Téléchargement du code source Le code source de la solution complète est disponible dans le fichier Chapitre12_CodeSourceConvoi.zip. Le package d installation de l application BizTalk est disponible dans le fichier Chapitre12_Convoi.msi. 3. Différents types de convois Il existe plusieurs types de convois. Voici quelques informations sur ces convois. a. Convoi séquentiel uniforme Un convoi séquentiel uniforme est un convoi dans lequel l ordre d arrivée des messages est connu. Un premier message déclenche le processus et des messages qui arrivent dans un ordre connu poursuivent ce processus. On dit que ce type de convoi est uniforme car tous les messages sont de même type. La copie d écran ci dessous est un exemple de ce type de convoi : Dans cet exemple, toutes les commandes d un même client sont dirigées dans la même instance d orchestration. Un nombre inconnu de commandes peut être reçu et lorsqu un délai d attente est dépassé, on considère que toutes les commandes ont été réceptionnées

391 Ce type de convoi est utilisé pour implémenter un agrégateur par exemple : agrégation de messages envoyés à un même client pour produire un seul message en fin de journée. b. Convoi séquentiel non uniforme Nous avons illustré ce type de convoi dans notre processus de gestion de commande. Il s agit d un convoi permettant de recevoir, dans un ordre connu à l avance, un ensemble de messages de types différents. Dans notre exemple, nous recevons deux messages différents (une commande et sa confirmation). c. Convoi parallèle Un convoi parallèle est un convoi qui permet de réceptionner plusieurs messages dans un ordre inconnu à l avance, cet ordre pouvant évoluer dans le temps. Vous utilisez ce type de convoi lorsque vous attendez un nombre fini de messages de types différents. En termes de processus métier, imaginez l accueil d un patient dans un hôpital. Afin de que le dossier du patient soit complet, des informations provenant de sa mutuelle, de la sécurité sociale et de la gestion administrative du patient de l hôpital sont nécessaires. Cependant, vous ne savez absolument pas dans quel ordre ces informations vont arriver. Vous savez juste que vous avez besoin de ces trois informations pour continuer le processus. Voici l illustration de ce convoi :

392 Réutilisation d orchestrations L orchestration de gestion de commandes que nous venons d implémenter est monolithique. Si nous souhaitons réutiliser une partie du processus, comme la gestion des échanges avec le stock, nous ne pouvons pas le faire sans réécrire et dupliquer cette partie du processus. Nous allons étudier dans ce paragraphe comment nous pourrions isoler certaines parties du processus et faciliter leur réutilisation. 1. Imbrication d orchestrations Les orchestrations peuvent être imbriquées et une orchestration peut appeler une autre orchestration en lui passant éventuellement des paramètres. Afin qu une orchestration soit appelée par une autre orchestration, elle doit être conçue dans ce sens, c est à dire qu à partir du moment où elle peut être imbriquée, elle ne peut pas être instanciée directement par BizTalk. Des paramètres peuvent être passés en entrée d une orchestration et des paramètres de sortie peuvent être récupérés par l orchestration appelante. Nous verrons que selon le procédé utilisé pour l imbrication cela n est pas toujours possible. Il y a deux procédés permettant l imbrication d orchestrations : l appel d une orchestration et le démarrage d une orchestration. a. Appeler une orchestration L appel d une orchestration est identique à un appel de procédure dans du code traditionnel. L orchestration appelante appelle l orchestration fille et attend la fin de son exécution. Tant que l orchestration fille n a pas terminé son exécution, l orchestration mère est en attente. L appel d orchestrations est possible grâce à la forme Appeler orchestration disponible dans la boîte à outils de l éditeur d orchestrations. b. Démarrer une orchestration Le démarrage d une orchestration permet de lancer l exécution d une orchestration fille de manière asynchrone, c est à dire que l orchestration mère n attend pas la fin de l exécution de l orchestration fille. Le démarrage d orchestrations est possible grâce à la forme Démarrer orchestration. c. Passage de paramètres Des paramètres peuvent être passés entre une orchestration mère et des orchestrations filles. Les types de paramètres suivants peuvent être échangés : des messages ; des variables ; des ensembles de corrélations ; des ports ; des liens de rôles. Ces paramètres peuvent être passés par valeur ou par référence. Si un paramètre est passé par valeur, une copie de la valeur est effectuée dans l orchestration fille. Lorsqu une variable est passée par référence et si l orchestration fille modifie cette variable, sa valeur dans l orchestration mère est également modifiée. Les paramètres peuvent être définis en entrée ou en sortie. En revanche, lorsque vous utilisez l appel asynchrone, via la forme Démarrer orchestration, vous ne pouvez pas passer de paramètres par référence ni utiliser des paramètres de sortie. Ceci est logique puisque l orchestration mère n attend pas la fin de l exécution de l orchestration fille, elle ne peut donc pas récupérer des paramètres en

393 sortie. 2. Isolation de la gestion de stock Nous pouvons tout à fait isoler la partie de notre processus permettant la gestion des échanges avec le stock. En procédant de telle sorte, nous pourrons ainsi réutiliser ce processus de gestion de stock dans d autres contextes métiers. Surtout, nous pourrons le faire évoluer sans toucher au processus de gestion de commandes si ce dernier n est pas impacté. a. Création d une orchestration fille Afin d isoler le processus de gestion de stock, nous créons une nouvelle orchestration nommée GestionStock située dans le projet ENI.Orchestrations. Cette orchestration est modélisée selon la copie d écran ci dessous : Comme vous pouvez le constater, cette orchestration ne débute pas par une forme Recevoir. Elle ne peut donc pas être instanciée par l arrivée d un nouveau message mais doit être appelée par une orchestration mère. Dans la vue Orchestration de Visual Studio, nous avons créé différents paramètres devant être fournis à l orchestration afin de permettre son exécution. Il s agit des paramètres suivants :

394 Les paramètres qtemouvement et referenceproduit sont des paramètres d entrée. Le paramètre QuantiteDisponible est un paramètre de sortie. Il s agit de la quantité de produits disponible dans le stock retournée par le système de gestion de stock. b. Appel de l orchestration fille et passage de paramètres Afin que l orchestration mère invoque l orchestration fille, la forme Appeler orchestration est utilisée : Elle est configurée comme suit :

395 À chaque paramètre (d entrée ou de sortie), une variable de l orchestration mère est associée. La variable qtedisponible de l orchestration mère va par exemple contenir la valeur retournée par l orchestration appelée. La valeur de la colonne direction pour cette variable vaut arrière (il faut comprendre paramètre de sortie). c. Activité BAM Gestion de stock La collecte des données pour la définition BAM Gestion de stock mise au point au chapitre précédent ne fonctionne plus correctement si vous opérez l isolation des échanges avec le stock dans une orchestration imbriquée. Pensez à modifier le modèle de suivi BAM correspondant pour demander la collecte des données au niveau de l orchestration GestionStock et plus au niveau de l orchestration GererCommande. d. Téléchargement du code source Téléchargez le code source de cet exemple d imbrication d orchestration. Il s agit du fichier Chapitre12_CodeSourceImbrications.zip et de l application BizTalk Chapitre12_Imbrications.msi. 3. Tâches en parallèles Outre la réutilisation possible de portions de processus, l imbrication d orchestrations permet également la mise en œuvre de tâches en parallèle. Ceci s applique d ailleurs très bien pour la gestion de notre stock. Dans notre processus, nous demandons au gestionnaire de stock de vérifier la quantité de produits disponible en stock. Si notre commande contient 10 produits, nous allons lui demander 10 fois mais, malheureusement pour lui, nous attendons la réponse à la précédente demande pour lui envoyer la suivante. Évidemment, il serait préférable de lui envoyer en même temps toutes les demandes et d attendre ensuite toutes les réponses. Le gestionnaire de stock pourrait donc, en un seul voyage dans l entrepôt, vérifier la quantité des produits disponibles dans le stock. Grâce à l imbrication de processus, nous pouvons déclencher parallèlement toutes les demandes de stock puis attendre toutes les réponses. Pour implémenter l envoi en parallèle au stock, vous devez utiliser la forme Démarrer orchestration. Rappelez vous que l utilisation de la forme Démarrer orchestration vous interdit l utilisation de paramètres en sortie ou par référence. Pour récupérer les réponses du stock, vous devez relier l orchestration GestionStock et GererCommande par un port en liaison Directe

396

397 Gestion des erreurs dans les orchestrations La gestion des erreurs dans les orchestrations est importante et doit être prise en compte pendant la phase de développement. 1. Comportements par défaut des orchestrations Dans le processus actuel, si une erreur se produit, elle est remontée au moteur BizTalk. Le moteur BizTalk mémorise l état de l orchestration au dernier point de persistance avant l erreur puis suspend l instance de l orchestration. En relançant l orchestration, le processus reprend juste avant l erreur. Ce mécanisme standard peut être satisfaisant pour des erreurs purement techniques (problèmes de connexion à une base de données, erreur dans le code...) car les erreurs sont consultables dans la console d administration et disponible pour l équipe d exploitation informatique. Si cette équipe utilise un outil de supervision (cf. chapitre Administration et exploitation de BizTalk), des alertes peuvent même être directement remontées aux personnes en charge de l exploitation. Même s il s agit d erreurs techniques, les processus métier doivent souvent agir en conséquence d une erreur et mener des actions particulières. Si nous n arrivons pas à envoyer un message au gestionnaire de stock à cause d un problème réseau, nous devons peut être, après plusieurs tentatives, annuler la commande et tenir l équipe commerciale au courant. 2. Gestion des erreurs dans les orchestrations Les orchestrations fournissent des mécanismes permettant : de déclencher des erreurs ; de capter des erreurs et d agir en conséquence. a. Déclencher des erreurs Le déclenchement d erreurs est équivalent à la clause throw de C#. La forme permettant de déclencher une exception s appelle Lever exception. Cette forme permet de lever deux types d exception : Des exceptions génériques non typées. Il s agit de l équivalent de la clause throw new Exception() de C#. Des exceptions typées. Il faut préalablement disposer d une classe d exception dérivant indirectement ou non de la classe de base Exception. L utilisation d exceptions typées est préférable, car, nous le verrons dans le paragraphe suivant, la détection du type d erreur sera facilitée. Nous allons modifier le processus de gestion de stock afin qu une erreur soit déclenchée si le gestionnaire de stock ne répond pas. Cette erreur sera de type NonReponseStockException. Créez une nouvelle classe dans le projet ENI.Helpers que vous nommez NonReponseStockException. Le code de cette classe est le suivant : /// <summary> /// Cas de non-réponse du gestionnaire de stock /// </summary> [Serializable] public class NonReponseStockException : Exception { public NonReponseStockException() : base() {} public NonReponseStockException(string message) : base(message) {} public NonReponseStockException(string message,system.exception inner) : base(message,inner) {} protected

398 NonReponseStockException(System.Runtime.Serialization.Serializati oninfo info, System.Runtime.Serialization.StreamingContext context) { } } La classe d exception doit être sérialisable (d où la présence de l attribut [Serializable]). Elle doit également implémenter les 4 constructeurs ci dessus, simplement en appelant les constructeurs de la classe mère sauf si vous souhaitez ajouter des traitements comme de la trace par exemple. Dans l orchestration GestionStock, créez une variable de type NonReponseStockException. Nommez cette variable errnonreponsestock. Déposez la forme Lever exception immédiatement en dessous de la forme Délai. Nommez cette forme err Stock. Cette forme sera exécutée en cas d attente de plus de 2 minutes sur la réponse du gestionnaire de stock : Dans les propriétés de la forme Lever exception, associez la propriété Objet d exception à la variable errnonreponsestock : Nous venons de déclencher des exceptions. Pour l instant, l orchestration GererCommande ne capte pas les erreurs. Notre erreur va donc se propager au niveau du moteur BizTalk et provoquera la suspension de l instance d orchestration GererCommande avec l erreur suivante. Type de l événement : Erreur Source de l événement : XLANG/s Catégorie de l événement : Aucun ID de l événement : Date : 27/10/2009 Heure : 17:00:27 Utilisateur : N/A Ordinateur : BTS2009FR Description : xlang/s engine event log entry: Une exception inattendue (voir exception interne ci-après) a provoqué l arrêt d une instance du

399 service ENI.Orchestrations.GererCommande(61e04ba3-a50c-daf0-440b-e a677). L instance du service reste interrompue tant qu elle n est pas administrativement reprise ou terminée. Si elle est reprise, l instance continuera à partir de son dernier état persistant et peut lever de nouveau la même exception. InstanceId : 2d3eaa57-8b7f-463e-a0c8-03a46bf2ee5f Nom de la forme : ShapeId: 0956d8e9-4fda cc5dcb74 Exception levée de : segment 1, avancement 49 Exception interne : Une exception de type ENI.Helpers.NonReponseStockException a été levée. Type d exception : NonReponseStockException Source : ENI.Orchestrations Site cible : Microsoft.XLANGs.Core.StopConditions segment1(microsoft.xlangs.core.stopconditions) Voici une trace de la pile qui identifie l emplacement où s est produite l exception à ENI.Orchestrations.GestionStock.segment1(StopConditions stopon) à Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopcond, Exception& exp) Pour plus d informations, consultez le centre Aide et support à l adresse b. Capter des erreurs Le principe pour capter des erreurs est équivalent au try - catch de C#. Il se matérialise dans une orchestration par l utilisation de la forme Étendue (qui est l équivalent du try) agrémentée d un ou de plusieurs gestionnaires d exceptions (qui sont les catch). Nous allons illustrer son utilisation dans le processus de gestion de commande pour capter l erreur déclenchée par l orchestration de gestion de stock (erreur de type NonReponseStockException). Déposez une forme Étendue et déplacez dans cette étendue la partie du processus dans laquelle une erreur peut se produire. Dans notre cas, nous allons entourer la forme Appeler orchestration. Nommez l étendue Echange stock puis ouvrez le menu contextuel et sélectionnez l option Nouveau gestionnaire d exceptions : Sélectionnez le gestionnaire d exceptions qui vient d être créé et modifiez ses propriétés pour qu elles soient équivalentes à celles ci dessous :

400 Nous précisons dans les propriétés du gestionnaire d exception qu il doit capter une exception de type ENI.Helpers.NonReponseStockException et stocker cette instance d exception dans la variable errnonreponsestock créée pour l occasion. Si nous devions traduire ce gestionnaire d exception en code C# cela donne : catch (ENI.Helpers.NonReponseStockException errnonreponsestock) Vous pouvez ajouter plusieurs gestionnaires d exception, autant que de types d exceptions. c. Téléchargement du code source Le code source de la solution avec gestion d erreur est disponible en téléchargement : fichier Chapitre12_CodeSourceExceptions.zip et l application BizTalk correspondante peut être installée via le fichier Chapitre12_Exceptions.msi

401 Les transactions 1. BizTalk et les transactions Depuis le début de cet ouvrage, nous avons mis en œuvre des processus transactionnels. Un grand nombre d opérations réalisées par BizTalk sont nativement transactionnelles. Citons par exemple les opérations suivantes : La réception d un message : tant qu un message n est pas correctement publié dans la MessageBox, il n est pas considéré comme réceptionné. Le processus de réception est donc transactionnel. Si vous relancez un port de réception en erreur, le message va de nouveau être traité par le port de réception. L envoi d un message : tant que BizTalk n arrive pas à envoyer un message à un destinataire, le message n est pas retiré de la MessageBox. Nous n avons pas eu d actions particulières à mener pour que ces processus soient transactionnels. 2. Gestion des transactions dans les orchestrations La gestion des transactions est tout naturellement possible dans les orchestrations BizTalk : Lorsque BizTalk met à disposition un message pour une orchestration, ce message n est pas retiré de la MessageBox tant que l exécution de l orchestration n est pas terminée. Il y a donc une transaction entre la MessageBox et l orchestration. Cette transaction est implicite, nous n avons pas à implémenter quoi que ce soit dans l orchestration. À l intérieur de l orchestration, tout ou partie du processus métier peut être déclaré comme transactionnel. 3. Les différents types de transactions On distingue deux types de transactions dans une orchestration BizTalk : les transactions atomiques et les transactions à long terme (en anglais long running). a. Transactions atomiques Une transaction atomique respecte les caractéristiques ACID : Atomicité : soit la transaction est complètement validée soit elle est annulée. Cohérence : à l issue de la transaction (qu elle soit annulée ou validée), les données manipulées se trouvent dans un état cohérent. Isolation : les données modifiées dans le cadre de la transaction ne peuvent pas être manipulées par d autres transactions. Durabilité : lorsque la transaction est validée, les données modifiées sont persistantes. Ces 4 caractéristiques sont les caractéristiques des transactions de tout système de gestion de base de données. Dans une orchestration, l implémentation d une transaction atomique respecte toutes ces caractéristiques. Les actions réalisées dans le cadre de la transaction sont soit totalement validées, soit annulées. Une transaction atomique dans une orchestration se matérialise par l utilisation de la forme Étendue. Dans les propriétés de la forme Étendue, il suffit de positionner la propriété Type de transaction à Atomique. Pour que les mécanismes d annulation fonctionnent, les ressources affectées par la transaction doivent elles mêmes être transactionnelles. Supposez par exemple que vous écrivez dans un fichier sur le disque dur depuis l orchestration. La ressource fichier sur disque n est pas transactionnelle (en tout cas pas avec tous les systèmes de fichiers). Les données écrites dans

402 le fichier sont donc visibles par d autres transactions et si la transaction est annulée le fichier n est pas restitué à son état d origine. Si par contre vous utilisez une ressource base de données, étant donné que cette ressource est transactionnelle, l annulation de la transaction de l orchestration provoquera l annulation des opérations effectuées dans la base de données. L utilisation d une étendue atomique a une incidence directe sur la manière dont le moteur BizTalk gère la persistance de l orchestration. Une transaction atomique est soit entièrement complétée, soit annulée. Le moteur mémorise donc l état de l orchestration juste avant l entrée dans l étendue atomique et juste après, mais jamais pendant. Si BizTalk redémarre pendant l exécution de l étendue atomique, la transaction est annulée. En cas de relance de l orchestration, l exécution démarre au début de l étendue et la transaction est exécutée de nouveau. b. Transactions à long terme Une transaction atomique n est pas toujours adaptée ni souhaitée. Étant donné que les ressources utilisées par une transaction atomique doivent être isolées, elles restent verrouillées pendant toute la durée de la transaction. Ces verrouillages peuvent créer des dysfonctionnements et provoquer des situations de blocage global. BizTalk propose un autre type de transaction adapté aux processus longs. Il s agit du type de transaction à long terme. Une transaction à long terme ne respecte pas les caractéristiques ACID et ne permet donc pas d isoler les données modifiées ou de restituer l état cohérent à la fin de la transaction. Par contre, ce type de transaction offre la possibilité d implémenter des compensations aux opérations réalisées pour fournir un mécanisme d annulation spécifique. Dans l exemple que nous avons pris précédemment, nous avons parlé de l écriture dans un fichier sur disque. Pour annuler l écriture dans le fichier en cas d annulation de la transaction, la compensation permet de supprimer une ligne dans le fichier. Les transactions à long terme sont implémentées grâce à la forme Étendue, cette fois ci qualifiée avec le type de transaction À long terme. La présence d un code de compensation n est pas obligatoire. Contrairement à une étendue atomique, une étendue à long terme peut tout à fait être persistée pendant son exécution. L exécution de l orchestration reprend au dernier point de persistance y compris s il se trouve au milieu de l étendue. 4. Dans quels cas faut il utiliser les transactions? a. Application au processus de gestion de commande Dans notre processus de gestion de commande, nous pourrions tout à fait ajouter une gestion des transactions afin d accélérer le processus métier. Le schéma ci dessous l illustre :

403 Dans la version actuelle du processus, nous ne lançons pas d action vis à vis du stock tant que la confirmation de commande n est pas arrivée. Nous pourrions cependant l anticiper et demander la réservation du stock dès l arrivée de la commande tout en continuant d attendre la confirmation. Si la confirmation de commande arrive, le stock est réservé et tout est correct. Si la confirmation de commande n arrive pas dans le temps imparti, nous devons annuler les mouvements de stock pour restituer le stock dans son état précédent. Avec une transaction à long terme, il suffit d implémenter un bloc de compensation pour annuler les mouvements de stock si la transaction long terme n est pas confirmée. Pour annuler les mouvements, il faut envoyer des mouvements contraires et donc, en quelque sorte, demander la remise en stock des produits réservés. b. Compensations parfois complexes et impossibles La mise en œuvre de compensations n est pas toujours simple. Dans notre cas, nous compensons les mouvements de stock par des mouvements de stock inverses. Ce que nous ne savons pas dans notre processus, c est que les opérations de stock envoyées pour gagner du temps ont entraîné des actions de réapprovisionnement auprès des fournisseurs. Si nous annulons ces mouvements de stock, nous devrions donc en toute logique annuler le réapprovisionnement du stock auprès des fournisseurs. Et peut être une somme d autres actions qui en découlent directement ou indirectement. Retenez donc que la mise en œuvre de compensations nécessite une étude d impact fonctionnel et n est pas simplement l action inverse d une transaction

404 Test d intégration et couverture de code 1. Tests d intégration Dans le précédent chapitre, nous avons illustré comment utiliser le débogueur d orchestrations afin de tester un processus métier. Dans cette version de BizTalk, il n est pas possible de tester localement une orchestration, il est nécessaire de la déployer. Les tests de processus métier complexes, avec beaucoup d interactions, sont souvent fastidieux. Très souvent d ailleurs, ils sont tellement longs à jouer qu ils sont complètement mis de côté, au détriment bien sûr de la qualité du livrable. Le temps gagné sur les tests sera certainement perdu plus tard lorsqu une erreur se produira en production. Pour éviter de vous retrouver dans ces situations, je vous conseille d instrumenter les tests d intégration et des les automatiser. Un projet communautaire CodePlex est assez largement adopté par les équipes projets, il s agit de BizUnit ( BizUnit permet de définir, en XML, les différentes étapes d un processus métier et grâce à des steps prédéfinis peut produire des messages selon des modèles déterminés, publier ces messages dans BizTalk et attendre des messages en retour. BizUnit offre également des actions permettant de valider les messages produits par rapport à des schémas ou bien encore de chercher dans le message récupéré de BizTalk une valeur d une donnée particulière. 2. Couverture de code En complément des tests d intégration, je vous conseille d utiliser l outil Orchestration Profiler, lui aussi disponible sous forme d un projet communautaire CodePlex ( Cet outil scrute la base de données de suivi BizTalk et détermine le taux de couverture de vos tests. Si vous jouez cet outil après vos tests d intégration, vous pourrez identifier des portions de code qui n ont pas été couvertes par vos tests. 3. Tests de charge et de performance Les tests de charge et de performances sont certainement les tests les plus complexes à mettre en œuvre dans des solutions EAI. Étant donné qu un EAI est amené à dialoguer avec des applications et partenaires, les tests de charge et de performances impliquent tous les systèmes environnants. En testant la performance de l EAI, vous testez indirectement la performance des systèmes sous jacents et les résultats de ces tests ne sont pas toujours très probants ou représentatifs. Pour tester la performance de l EAI luimême, vous pouvez "bouchonner" les systèmes connexes en simulant la réponse à des stimulis. Toutefois, le simple fait de bouchonner un partenaire ou une application peut produire de la charge de travail supplémentaire dans l EAI et donc fausser les mesures. Si vous souhaitez mesurer la performance de l EAI ainsi que sa tenue en charge, vous pouvez combiner BizUnit, que je vous conseille pour les tests d intégration, et Microsoft BizTalk LoadGen. LoadGen est un outil gratuit édité par Microsoft. Il permet la mise au point de "tirs" de charge, c est à dire la production en masse de messages, conformes à des modèles et construits de manière aléatoire ou guidés par des listes de valeurs. L intérêt de combiner LoadGen et BizUnit est de permettre la réutilisation des tests d intégration qui sont représentatifs des processus métier

405 Implémentation de patterns EAI Comme nous l avons évoqué dans le chapitre précédent, il existe un grand nombre de modèles d implémentation EAI. Ces modèles recensent les implémentations possibles et recommandées des scénarios traditionnels de l intégration d applications. Les modèles EAI (patterns EAI) cités dans ce paragraphe sont issus de l ouvrage Enterprise Integration Patterns écrit par Grégor Hohpe et Bobby Woolf aux éditions Addison Wesley Professional. Je vous invite également à consulter le site Internet pour comprendre les patterns cités. 1. Les patterns EAI natifs BizTalk La déclinaison de ces modèles dans chaque EAI du marché suppose plus ou moins de développement. Certains modèles EAI sont automatiquement intégrés dans l architecture de BizTalk par exemple. La liste suivante, non exhaustive, est un exemple des modèles EAI ne nécessitant pas d implémentation particulière car pris en compte nativement par BizTalk : Pipes and Filters : implémenté dans les pipelines BizTalk. Durable Subscriber : fondement de l architecture BizTalk permettant à un abonné, s il n est pas en cours d exécution, de consommer les messages dès son réveil. Message Translator : implémenté dans les maps BizTalk. Il y a plus d une vingtaine de modèles présents nativement dans BizTalk et ne nécessitant pas d implémentation particulière. Certains patterns EAI nécessitent cependant une implémentation sous forme d orchestration. Nous allons illustrer deux de ces patterns. 2. Pattern Aggregator a. Principe du pattern Aggregator Le pattern Aggregator est l inverse du pattern Splitter. Son objectif est d agréger dans un message unique un ensemble de messages ayant le même objectif. Si nous appliquons ce pattern à notre processus de gestion de commandes, nous pourrions par exemple agréger les mouvements de stock envoyés à la gestion de stock pour n envoyer qu un seul message contenant tous les mouvements. L implémentation de ce pattern dans BizTalk ne nécessite pas toujours l usage d orchestrations. Trois implémentations de ce pattern sont envisageables. b. Implémentation sur la couche transport L agrégation de données se limite parfois à concaténer des informations dans un fichier en sortie de BizTalk. Si vous utilisez le protocole FILE pour transporter l information, vous devez simplement régler la propriété Mode de copie du port d envoi sur Ajouter. Si vous utilisez d autres protocoles de transport, vous trouverez des équivalents à cette propriété quand cela a du sens. Si ce type d agrégation satisfait vos besoins, préférez la aux autres solutions car elle est très performante, très souple et surtout ne nécessite aucune implémentation. c. Implémentation sur la couche messagerie Tout comme le découpage de messages peut être effectué dans un pipeline de réception, via le composant de désassemblage XML, l agrégation de messages peut être effectuée par un pipeline d envoi grâce au composant d assemblage XML

406 Vous pouvez demander à un pipeline d envoi d assembler des messages entre eux pour construire un message agrégé. Contrairement à la solution basée sur le transport que nous venons d évoquer, l agrégation via l assemblage XML n est pas une simple concaténation de données. Il s agit bien d un assemblage de plusieurs messages dans une enveloppe. Il est donc nécessaire d utiliser les notions d enveloppe que nous avons abordées dans les chapitres relatifs aux messages et aux pipelines. Il n est pas possible de demander à une seule instance d un port d envoi de traiter plusieurs messages, sous forme d un singleton. Afin d utiliser le mécanisme d agrégation du composant d assemblage XML, il est donc utile de créer une orchestration dans laquelle vous invoquez, dans une boucle, un pipeline de réception contenant le composant. À l issue de la boucle d exécution, vous obtenez le message agrégé. Utilisez cette solution technique en lieu et place d une agrégation manuelle dans une orchestration car elle est extrêmement plus performante. d. Implémentation avec une orchestration La troisième solution pour l implémentation d une agrégation de données est l utilisation d une logique métier hébergée dans une orchestration. Utilisez cette solution lorsque l agrégation est régie par des règles métiers. Imaginons par exemple l agrégation des mouvements de stocks. Si votre gestionnaire de stock vous demande un seul message par jour dans lequel les mouvements de stocks de tous les produits de toutes les commandes sont présents. Si un produit est souhaité par deux clients, ce mouvement de stock ne doit pas apparaître deux fois dans le fichier des mouvements mais une seule fois pour la quantité cumulée des deux commandes. Ce type d agrégation nécessite un traitement métier pour cumuler des données par produit. C est donc un scénario nécessitant l implémentation d une orchestration basée sur un convoi. L orchestration se déclenche dès qu un mouvement doit être envoyé au stock et ensuite tous les mouvements de stock sont dirigés vers cette orchestration. En fin de journée, le message agrégé est produit et envoyé au système de stock. Si vous devez implémenter ce type d orchestration pensez à le faire de manière générique quand cela est possible et ainsi permettre la réutilisation pour différents domaines métiers. 3. Pattern Resequencer Le pattern Resequencer est très souvent nécessaire. L idée générale est de permettre l ordonnancement de messages selon des règles métiers ou techniques particulières. L objectif de ce pattern est de garantir que les messages sont traités dans le bon ordre. Il y a deux approches pour l implémentation de ce pattern. a. Implémentation native BizTalk Nativement BizTalk permet de gérer l ordonnancement des messages d un point de vue technique. Si vous souhaitez garantir l ordre des messages de bout en bout, c est à dire depuis l application émettrice jusqu à l application destination, vous devez utiliser un protocole de transport en mesure de préserver l ordre (MSMQ par exemple). En interne dans BizTalk, l utilisation de l option Livraison chronologique des messages sur les ports d envoi indique à BizTalk de préserver l ordre d envoi des messages par rapport à leur ordre d arrivée dans la MessageBox. Sans aucune implémentation, vous pouvez donc préserver l ordre des messages. b. Implémentation basée sur une orchestration L ordonnancement de messages dans l EAI peut être lié non pas à leur ordre d arrivée, mais à leur position dans un processus métier. Il n est pas toujours possible d utiliser un transport qui fournisse une garantie de délivrance ordonnée des messages. L envoi des mouvements de stock au système de gestion de stock doit par exemple être effectué dans l ordre. Un mouvement déclenché dans un mauvais ordre peut avoir un impact sur le processus de réapprovisionnement ou produire une réponse négative sur la disponibilité d un produit. Pour éviter cela, le séquencement doit être basé sur des informations fonctionnelles contenues dans le message luimême. Il peut s agir d un numéro chronologique de mouvement fourni par le système initiateur ou bien d un horodatage du mouvement. Sans l implémentation d une orchestration, ce type de scénarios ne peut pas être géré par BizTalk. En implémentant

407 une orchestration et un convoi permettant de faire converger tous les mouvements de stock vers la même instance, vous pouvez gérer cette séquence et faire patienter des messages qui ne doivent pas encore être envoyés. Encore une fois, préférez le développement d un mécanisme générique pour le séquencement quand cela est possible

408 Modélisation de processus métier Dans les deux chapitres consacrés aux orchestrations, nous avons utilisé l éditeur d orchestrations de Visual Studio pour dessiner les processus métier. Les orchestrations peuvent également être modélisées en dehors de Visual Studio puis importées. 1. Visio ODBA Vous pouvez par exemple utiliser MS Visio ODBA (Orchestration Designer for Business Analysts). Il s agit d une palette de dessin intégré à Microsoft Visio permettant de modéliser des orchestrations. L outil est destiné aux analystes métiers. Les orchestrations modélisées dans Visio sont ensuite importées dans Visual Studio. Le processus peut également être effectué dans le sens inverse, c est à dire qu une orchestration Visual Studio peut être importée dans Visio. 2. Outils de modélisation du marché Si vos analystes ou vos équipes projet utilisent déjà des outils de modélisation du marché, vous pouvez tout à fait continuer de les utiliser pour créer vos orchestrations. La plupart des outils du marché offrent un connecteur BizTalk pour l export des modélisations sous forme d orchestrations ou l export en BPEL (Business Process Engine Language). BizTalk sait nativement importer un projet BPEL et le transformer en orchestration. 3. OSLO et DSL L initiative OSLO de Microsoft vise à généraliser les phases de modélisation, dans tous les domaines du développement informatique. Les orchestrations BizTalk pourraient donc être modélisées dans des DSL OSLO. Pour l instant rien n a filtré, mais la tendance pourrait se confirmer assez rapidement

409 Conclusion Nous venons d aborder un certain nombre de concepts avancés pour l implémentation de processus métier dans BizTalk. En pratiquant les notions de convois et de corrélations, vous découvrirez les possibilités offertes par les orchestrations. Si vous implémentez des processus métier complexes, votre équipe de développement aura peut être le sentiment qu il aurait été plus simple de le faire sans BizTalk. C est un sentiment souvent partagé par les équipes et parfois à juste titre. L outil de développement d orchestration BizTalk n a pas évolué depuis plusieurs versions et comparé à ce qu il est possible de faire en pur.net ou avec les Workflow Fundation, il est très peu flexible, peu pratique et parfois un peu buggé. Sur ce point, les équipes peuvent se plaindre à juste titre. Comparés à du développement.net traditionnel, les orchestrations et les services BizTalk associés offrent des fonctionnalités qu il est très difficile de bénéficier dans des développements à façon. La montée en charge, la persistance, la gestion des transactions, les convois et corrélations sont autant de fonctions natives des orchestrations qu il serait bien dommage de réimplémenter. Utilisez les orchestrations dans des scénarios adaptés sans les surcharger de code.net complexe. Utilisez à bon escient les possibilités offertes pour l appel de code externe et l imbrication d orchestrations. Vous gagnerez en productivité

410 Introduction Nous allons évoquer dans ce chapitre la construction d une architecture de services avec BizTalk. Nous pourrions parler de SOA (Service Oriented Architecture). La démarche SOA est bien plus qu une architecture technique, il s agit d une approche projet et d une démarche complète. Bien qu une architecture de services ne suppose pas forcément la mise en œuvre de services Web, elle suppose le respect des standards du marché pour offrir un maximum d interopérabilité. En utilisant les services Web, nous respectons donc ce principe. Nous allons, dans ce chapitre, illustrer comment construire une architecture de services avec BizTalk, dans un premier temps pour consommer des services et dans un second temps pour exposer des services

411 Rappels sur les services Web La lecture et la compréhension de ce chapitre supposent la connaissance des concepts des services Web et si possible leur pratique. Avant toute chose, nous allons rappeler quelques principes fondateurs des services Web et quelques notions de base. 1. Principes Au début des années 2000, IBM et Microsoft ont été les premiers à définir une spécification pour structurer les appels de procédures entre systèmes, ce que l on appelle communément les RPC (Remote Procedure Call). Cette spécification nommée SOAP a été depuis reprise sous forme d une recommandation du W3C et donc très largement adoptée par le marché. SOAP définit la structure des messages échangés entre deux systèmes qui souhaitent communiquer. Cette spécification est particulièrement bien adaptée aux échanges de type requête/réponse. Un échange de ce type est synchrone c est à dire qu un appel de procédure (la requête) effectué par un client vers un objet distant se traduit par une réponse de ce dernier. SOAP fonctionne également dans des échanges de type requête uniquement. L intérêt de SOAP réside dans son indépendance vis à vis d une technologie particulière ou d un système d exploitation. En théorie tous les systèmes sont interopérables s ils respectent la recommandation. SOAP s appuie sur l utilisation de messages XML qui représentent les requêtes et les réponses échangées entre les systèmes. Le transport de ces messages est la plupart du temps effectué grâce au protocole HTTP mais la recommandation SOAP ne l impose absolument pas. 2. Anatomie d un échange SOAP Le schéma ci dessous illustre l architecture logique d un échange basé sur SOAP : Cette architecture s applique si le client et le service sont sur la même machine physique ou si les composants sont déployés sur différents serveurs. Le protocole de transport des messages SOAP est choisi en fonction des besoins du projet : HTTP, HTTPS par exemple. Quelles que soient les technologies côté client ou côté service, cette architecture est identique : un proxy SOAP et un listener SOAP dialoguent en SOAP et masquent les détails techniques aux clients et services. a. Proxy SOAP Le proxy SOAP est un composant logiciel qui fait l intermédiaire entre une application cliente et un service appelable via SOAP. Le proxy est la plupart du temps généré automatiquement par les outils de développement (Visual Studio par exemple) à partir de la description du service exposé en SOAP (cf. paragraphe Contrat de service WSDL). Lorsque l application cliente invoque une méthode du service distant, elle n a pas à produire un message SOAP. Elle invoque une méthode du proxy SOAP et ce dernier se charge de produire le message SOAP et de l envoyer au

412 service distant. b. Listener SOAP De l autre côté de la chaîne, les messages SOAP en provenance des clients sont réceptionnés par un listener SOAP. Selon les technologies il peut s agir d une extension CGI, de code ASP.Net ou d extensions ISAPI. Le principe est toujours le même : le listener réceptionne des messages au format SOAP. Il interprète ces messages et invoque la méthode du service en lui passant les paramètres récupérés du message SOAP. Les données produites en retour par le service sont réceptionnées par le listener qui produit le message de réponse au format SOAP et le retourne au client. c. Contrat de service WSDL Afin que le proxy et le listener sachent interpréter les messages SOAP, le service doit définir les méthodes qu il expose et les données échangées. On parle de contrat de service. Le contrat de service est défini au format WSDL (Web Service Description Language). Il s agit d un message XML qui décrit, pour chaque méthode exposée, les paramètres en entrée, leur type et les paramètres en sortie. Voici ci dessous un exemple de contrat de service pour un service Web qui expose une méthode nommée EnregistrerMouvement : <?xml version="1.0" encoding="utf-8"?><wsdl:definitions name="gestionstockservice" targetnamespace=" xmlns:wsdl=" xmlns:soap=" xmlns:wsu=" wss-wssecurity-utility-1.0.xsd" xmlns:soapenc=" xmlns:wsam=" xmlns:tns=" xmlns:wsa=" xmlns:wsp=" xmlns:i0="urn:enieditions:gestionstock:1.0" xmlns:wsap=" cy" xmlns:xsd=" xmlns:msc=" xmlns:wsaw=" xmlns:soap12=" xmlns:wsa10=" xmlns:wsx=" <wsdl:import namespace="urn:enieditions:gestionstock:1.0" location=" <wsdl:types/> <wsdl:binding name="basichttpbinding_igestionstockservice" type="i0:igestionstockservice"> <soap:binding transport=" <wsdl:operation name="enregistrermouvement"> <soap:operation soapaction="urn:enieditions:gestionstock:1.0/igestionstockservice /EnregistrerMouvement" style="document"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="gestionstockservice"> <wsdl:port name="basichttpbinding_igestionstockservice" binding="tns:basichttpbinding_igestionstockservice"> <soap:address location=" "/>

413 </wsdl:port> </wsdl:service> </wsdl:definitions> Nous verrons dans ce chapitre comment le contrat de service est défini. d. Structure d un message SOAP Un message SOAP est structuré en plusieurs parties comme l illustre le schéma ci dessous : Les parties suivantes composent le message SOAP : L enveloppe SOAP qui englobe l en tête SOAP et le corps SOAP. L en tête SOAP est optionnel. Lorsqu il est présent, il offre des mécanismes d extensions permettant à des données complémentaires d être véhiculées au service appelé ou dans la réponse fournie au client appelant. Lorsqu un message SOAP transite par plusieurs intermédiaires avant d arriver au service final, ces intermédiaires peuvent agir sur les données sans perturber le fonctionnement du service final. Le corps SOAP est obligatoire. Il s agit de l information principale qui est véhiculée entre un client et un service final. Il contient les informations permettant le passage de paramètres à une méthode du service ou les informations obtenues suite à l exécution d une procédure sur le service final. e. Exemples de message SOAP Voici ci dessous deux exemples de messages au format SOAP. Tout d abord une requête SOAP qui permet d invoquer la méthode EnregistrerMouvement : <s:envelope xmlns:s=" <s:body> <EnregistrerMouvement xmlns="urn:enieditions:gestionstock:1.0"> <referenceproduit>cocotteminute</referenceproduit> <quantiteproduit>10</quantiteproduit> </EnregistrerMouvement> </s:body> </s:envelope> Voici ensuite la réponse à l appel de la méthode EnregistrerMouvement : <s:envelope xmlns:s=" <s:body> <EnregistrerMouvementResponse xmlns="urn:enieditions:gestionstock:1.0"> <EnregistrerMouvementResult>5</EnregistrerMouvementResult> </EnregistrerMouvementResponse> </s:body> </s:envelope>

414 3. Extensions des services Web L utilisation de plus en plus massive de SOAP dans les systèmes d informations a fait évoluer la recommandation SOAP d origine. Des extensions à cette recommandation ont été ajoutées pour couvrir de nouveaux besoins : sécurité, transactions, adressage dynamique... Ces nouvelles recommandations sont plus ou moins bien respectées dans les différentes technologies du marché car elles sont pour certaines assez récentes. L interopérabilité des systèmes qui utilisent ces nouvelles recommandations est parfois entravée par des incompatibilités liées à différents niveaux de respect des normes. Les extensions des services Web sont rassemblées sous l acronyme WS_* (prononcez WS Star). Il s agit par exemple des recommandations suivantes : WS_Security : sécurité des services Web. WS_Federation : fédération d identité lors des appels de services. WS_Reliable Messaging : garantie de transport lors des appels de services. Ces extensions apportées aux services Web se traduisent le plus souvent par l ajout d informations complémentaires dans les en têtes SOAP des messages échangés. 4. Technologies de services Web Microsoft Dans l environnement technique Microsoft, l implémentation de services Web est possible via plusieurs technologies. Ces technologies permettent l implémentation de services Web ou de clients. a. ASP.Net Web Services ASP.Net Web Services est la première alternative, apparue avec le Framework.Net et reposant sur les technologies ASP.Net. Les services Web développés dans cette technologie sont hébergés dans le serveur Web Internet Information Server (IIS) et peuvent être invoqués via le protocole HTTP. L implémentation des extensions de services Web (WS_*) est possible via le composant supplémentaire Microsoft WSE (Web Service Extensions). Cette technologie est désormais remplacée par WCF. Néanmoins, les outils de développement dans leurs versions actuelles permettent encore de développer des services Web ASP.Net. b. WCF WCF (Windows Communication Foundation) est une brique du Framework.Net 3.0 et supérieur. Il s agit d un ensemble de classes et de services permettant le développement de services Web mais pas uniquement. L approche de développement dans WCF est bien différente de l approche de développement avec ASP.Net puisque le développement d un service est décorrélé de son exposition et donc des choix de déploiement. Un service WCF peut ainsi être exposé de manière non sécurisée en HTTP aux applications de l entreprise mais peut, sans impact sur le service lui même, être exposé de manière sécurisée en HTTPS aux partenaires externes. L exposition du service se fait par simple configuration. Le développeur n a pas à connaître les détails de l infrastructure lorsqu il implémente le service. WCF fédère également toutes les technologies d interopérabilité auparavant dispersées dans différents composants Microsoft comme.net Remoting par exemple. WCF supporte nativement les recommandations WS_*

415 Technologies de services Web dans BizTalk 1. L histoire des services Web dans BizTalk Le support des services Web dans BizTalk est une histoire que l on peut résumer en deux épisodes : Le premier épisode qui débute avec BizTalk Server 2004 et l arrivée de l adaptateur SOAP. L adaptateur SOAP permet de consommer des services et de les exposer. Les services exposés sont implémentés via les ASP.Net Web Services. Le second épisode débute avec BizTalk Server 2006 R2 et l arrivée des adaptateurs WCF. Le support des services Web passe désormais par l usage de WCF et l adaptateur SOAP est déprécié depuis cette version. Le passage de l adaptateur SOAP à WCF offre un meilleur support des spécifications WS_* et plus de souplesse dans l implémentation d applications BizTalk reposant sur des services Web. Avec l adaptateur SOAP, les scénarios de pure messagerie basés sur des services Web n étaient pas possibles, le recours à des orchestrations était nécessaire. Cette limite est levée grâce aux adaptateurs WCF. Étant donné que l adaptateur SOAP est déprécié depuis BizTalk Server 2006 R2, nous n allons pas aborder son utilisation et allons concentrer nos efforts autour des adaptateurs WCF. 2. Répartition des rôles entre WCF et BizTalk L apport technique de WCF pour BizTalk est indéniable. La répartition des rôles entre WCF et BizTalk ainsi que l explication des frontières entre ces deux mondes ne sont pas particulièrement aisés. Dans ce chapitre nous n abordons pas l implémentation de services WCF, mais uniquement l usage de WCF dans un contexte BizTalk. Si vous connaissez déjà WCF, vous pourrez vous rendre compte que certaines implémentations faites avec BizTalk pourraient tout à fait être effectuées en WCF pur

416 Consommer un service Web avec BizTalk Nous allons dans un premier temps consommer un service Web depuis BizTalk. 1. Service Web de gestion de stock Pour l illustrer, nous allons interagir avec le nouveau système de gestion de stock qui vient d être implanté dans l entreprise. Cette nouvelle version propose un service Web permettant d enregistrer des mouvements de stock. Nous ne détaillons pas dans ce chapitre le développement du service Web de gestion de stock. Il est disponible en téléchargement : Chapitre14_ServiceWebGestionStock.zip. Le fichier téléchargé contient à la fois le code source du service et du projet de déploiement du service. Pour déployer le service Web dans votre environnement, téléchargez le fichier Chapitre14_ServiceWebGestionStock.msi. Il ne s agit pas d une application BizTalk donc n essayez pas d importer le package dans la console d administration. Ce package doit simplement être lancé et il crée un répertoire virtuel nommé SWGestionStock. Le service contient une méthode nommée EnregistrerMouvement. Cette méthode prend en paramètre : une référence produit ; une quantité. La méthode retourne la quantité de produit en stock. Dans un premier temps, nous allons invoquer ce service Web dans un scénario de pure messagerie puis modifierons l orchestration de gestion de stock pour qu elle fonctionne avec ce service Web. 2. Étapes pour consommer un service Web avec BizTalk L invocation d un service Web avec BizTalk est ni plus ni moins que l envoi d un message XML à un destinataire avec un protocole donné. BizTalk doit donc produire un message correspondant au format attendu par le service Web et lui envoyer. a. Produire un message SOAP avec BizTalk Vous ne manipulez jamais des messages au format SOAP directement dans BizTalk, sauf cas exceptionnels. BizTalk manipule des messages XML et ces messages sont encapsulés en SOAP avant d être envoyés aux services Web par l adaptateur WCF. Le schéma ci dessous illustre le fonctionnement : Dans l implémentation BizTalk, vous devez produire un message au format EnregistrerMouvement. Ce message est ensuite encapsulé dans un message SOAP grâce à l adaptateur WCF. Voici un exemple de message EnregistrerMouvement qu il faut produire : <EnregistrerMouvement xmlns="urn:enieditions:gestionstock:1.0"> <referenceproduit>cocotteminute</referenceproduit> <quantiteproduit>10</quantiteproduit> </EnregistrerMouvement>

417 b. Obtenir les schémas XSD du service Web Rien de plus simple avec BizTalk pour produire un message à partir du moment où vous disposez du schéma XSD correspondant. Grâce à un assistant, BizTalk vous permet d obtenir le schéma XSD qui correspond au service Web. L assistant, appelé Utiliser le service WCF, s exécute depuis Visual Studio et crée ainsi les fichiers XSD dans le projet BizTalk en cours. Ouvrez la solution ENI.BizTalk et ajoutez un nouveau projet BizTalk vide nommé ENI.GestionStock.Schemas. Configurez le projet avec la clé de signature ainsi que le nom d application BizTalk pour le déploiement. Ce projet accueille les schémas XSD qui représentent les messages échangés avec le service Web de gestion de stock. Pour générer les schémas XSD, lancez l assistant en procédant comme suit : Dans le projet ENI.GestionStock.Schemas, ouvrez le menu contextuel et choisissez Ajouter puis Ajouter les éléments générés. Sélectionnez Utiliser le service WCF pour lancer l assistant : L assistant s appuie sur le contenu d un contrat de service (WSDL) pour produire les schémas correspondants. Vous devez donc fournir ce contrat à l assistant : Soit en précisant une URL qui publie le contrat (on parle alors de Point de terminaison MEX pour Metadata EXchange). Notre service de gestion de stock publie par exemple son contrat à l adresse Soit en fournissant directement un fichier WSDL. Choisissez l option Point de terminaison MEX dans l écran ci dessous :

418 Saisissez l adresse du point de terminaison MEX pour obtenir le contrat et cliquez sur Obtenir : Saisissez l espace de noms dans lequel les schémas XSD vont être créés. Par défaut il s agit de l espace de noms du projet en cours. Cliquez sur le bouton Importer pour générer les schémas :

419 Lorsque l assistant a terminé l import du contrat de service et la génération des schémas, plusieurs éléments sont ajoutés au projet. Fichiers de liaison Deux fichiers de liaison sont ajoutés au projet. Ces deux fichiers contiennent la description de ports d envois WCF permettant l invocation du service. Nous utiliserons ces fichiers pour créer les ports d envoi dans l application BizTalk. Nous expliquons dans le paragraphe Bindings WCF et BizTalk pourquoi deux fichiers de liaison sont créés. Fichiers XSD Selon la complexité du contrat de service, plusieurs schémas XSD peuvent être créés dans le projet. Dans notre cas, deux fichiers ont été créés. Le fichier nommé GestionStockService_schemas_microsoft_com_2003_10_Serialization.xsd contient la définition de types de données de base. Il n est pas du tout spécifique à notre service Web. Le fichier GestionStockService_ENIEditions_GestionStock_1_0.xsd contient la définition des messages échangés avec le service. Si vous ouvrez le schéma vous pouvez consulter la définition du message de requête (EnregistrerMouvement) et du message de réponse (EnregistrerMouvementResponse) : L espace de noms du schéma est le même que l espace de noms du service Web (urn:enieditions:gestionstock:1.0 dans notre cas). Orchestration Le dernier élément généré par l assistant est une orchestration nommée GestionStockService.odx. L orchestration est complètement vide mais contient déjà la définition d un type de port (requête/réponse) permettant l invocation du service Web ainsi que la définition de messages. La génération automatique de cette orchestration ne doit pas vous induire en erreur : l invocation d un service Web avec BizTalk ne requiert pas l utilisation d une orchestration. Vous pouvez sans problème supprimer cette orchestration que nous n allons pas utiliser

420 c. Configurer le port d envoi WCF Pour que BizTalk adresse des messages au service Web, nous devons créer un port d envoi. Nous créons un port de type Sollicitation/Réponse (ou Requête/Réponse, les deux termes sont identiques) pour récupérer les données retournées par la méthode EnregistrerMouvement. Les fichiers de liaison générés par l assistant dans le projet ENI.GestionStock.Schemas vont faciliter notre tâche. Ils contiennent, l un comme l autre, la définition d un port d envoi préconfiguré pour invoquer le service de gestion de stock : Dans la console d administration BizTalk, sélectionnez l application ENIEditions et importez le fichier de liaison GestionStockService_BindingInfo.xml. Lorsque l import est terminé, un port d envoi nommé WcfSendPort_GestionStockService_BasicHttpBinding_IgestionStockService est créé. Il est associé à l adaptateur WCF BasicHttp. Cet adaptateur WCF permet l invocation de services Web en SOAP sans aucune sécurité. Il s agit du binding WCF le plus simple. Reportez vous au paragraphe Binging WCF et BizTalk pour plus d informations. Je vous conseille de renommer le port d envoi pour faciliter la lecture dans la console d administration. Renommez le sndservicewebgestionstock. Démarrez le port d envoi depuis la console d administration. d. Tester le fonctionnement dans une solution de pure messagerie Préparer un exemple de message Pour tester le service Web dans BizTalk, générez un exemple de message de type EnregistrerMouvement. Utilisez l option Générer l instance sur le schéma XSD GestionStockService_ENIEditions_GestionStock_1_0.xsd. Déployer les schémas Déployez le projet ENI.GestionStock.Schemas dans l application ENIEditions. Utilisez la méthode que vous souhaitez pour effectuer le déploiement, pensez également à installer l assembly dans le GAC. Configurer la solution de messagerie pour les tests Le schéma ci dessous illustre la solution de messagerie pour tester le service Web : Le schéma précédent ne représente pas la MessageBox mais les messages utilisés dans le processus passent bien évidemment par celle ci. Le principe est relativement simple : Un port de réception (rcvenregistrermouvement) de type FILE récupère dans un répertoire un message de type urn:enieditions:gestionstock:1.0#enregistrermouvement

421 Le message est publié dans la MessageBox. Le port d envoi WCF (sndservicewebgestionstock) est abonné au message et se déclenche. Il invoque le service Web de gestion de stock et attend la réponse. La réponse reçue du service Web est publiée dans la MessageBox. Il s agit d un message de type urn:enieditions:gestionstock:1.0#enregistrermouvementresponse. Le port d envoi (sndenregistrermouvementresponse) est abonné à ce type de message et se déclenche. La réponse obtenue est ainsi déposée dans un répertoire. Cette solution de messagerie démontre comment une application incapable d appeler des services Web peut tout de même bénéficier des services rendus, par dépôt de fichier par exemple. Créez et démarrez les différents artefacts dans l application ENIEditions. Le filtre du port d envoi sndservicewebgestionstock est le suivant : BTS.MessageType == urn:enieditions:gestionstock:1.0#enregistrermouvement Le filtre du port d envoi sndenregistrermouvementresponse est le suivant : BTS.MessageType == urn:enieditions:gestionstock:1.0#enregistrermouvementresponse Testez le fonctionnement de l application. e. Fonctionnement de la SOAP Action Notre solution fonctionne correctement, mais c est un hasard en réalité. Elle fonctionne car le service Web de gestion de stock ne possède qu une méthode (EnregistrerMouvement). Nous allons expliquer pourquoi. Quand un service Web réceptionne une requête SOAP, il l étudie et détermine quelle méthode du service doit être invoquée. Lorsque le service Web ne possède qu une méthode, c est très simple. Lorsque le service Web expose plusieurs méthodes, le message SOAP doit porter des informations pour lui permettre de déterminer quelle méthode est concernée. Deux informations reçues dans la requête SOAP permettent de le déterminer : Le nœud racine et l espace de noms du corps SOAP (dans notre cas EnregistrerMessage dans l espace de noms urn:enieditions:gestionstock:1.0). L action SOAP (SOAPAction) présente dans la requête HTTP POST. Ci dessous, voici un exemple de requête HTTP POST pour l appel du service Web de gestion de stock : POST /SWGestionStock/GestionStockService.svc HTTP/1.1 Content-Type: text/xml; charset=utf-8 SOAPAction: "urn:enieditions:gestionstock:1.0/igestionstockservice/enregistre rmouvement" Host: bts2009fr Content-Length: 302 Expect: 100-continue Connection: Keep-Alive <s:envelope xmlns:s=" EnregistrerMouvement xmlns:ns0="urn:enieditions:gestionstock:1.0"> <ns0:referenceproduit>cocotteminute</ns0:referenceproduit>

422 <ns0:quantiteproduit>10</ns0:quantiteproduit> </ns0:enregistrermouvement></s:body></s:envelope> Étant donné que l action SOAP ne fait pas partie du message lui même (mais de la requête HTTP), elle peut être lue par les différents intermédiaires entre le client et le service. Ceci est bien évidemment possible si la communication n est pas sécurisée avec HTTPS. Les dispositifs de sécurité peuvent par exemple filtrer les messages basés sur certaines actions SOAP. Côté service Web, l usage de l action SOAP diverge selon la technologie sous jacente. Certaines technologies requièrent sa présence, d autres sont plus laxistes ou bien ignorent complètement son contenu. Les services Web développés avec WCF requièrent la présence d une action SOAP valide et correspondant à une méthode du service Web. Si vous souhaitez que BizTalk ajoute cette information dans la requête HTTP, vous devez indiquer au port d envoi de quelle action il s agit. Plusieurs alternatives sont possibles. Association d une SOAPAction à un port d envoi Si le port d envoi ne concerne qu une seule méthode de service Web (comme c est notre cas) : vous précisez cette action SOAP dans la configuration du port comme l indique la copie d écran suivante, zone de saisie En tête d action SOAP. Si vous souhaitez invoquer une seconde méthode du même service Web, vous devez créer un second port d envoi WCF avec sa propre SOAPAction. Plusieurs SOAPAction pour le même port d envoi Si le même port d envoi permet l invocation de plusieurs méthodes du même service Web (donc plusieurs SOAPAction), vous pouvez utiliser la syntaxe suivante dans la zone Action du port d envoi :

423 <BtsActionMapping xmlns:xsi=" xmlns:xsd=" <Operation Name="EnregistrerMouvement" Action="urn:ENIEditions:GestionStock:1.0/IGestionStockService/Enr egistrermouvement" /> <Operation Name="SupprimerMouvement" Action="urn:ENIEditions:GestionStock:1.0/IGestionStockService/Sup primermouvement" /> </BtsActionMapping> Dans cet exemple, deux SOAPAction sont précisées, chacune correspondant à une méthode particulière du service Web. BizTalk sélectionne la SOAPAction correspondant en lisant dans le message entrant une propriété nommée BTS.Operation et devant donc être présente. Lorsqu un message provient d une orchestration, la propriété BTS.Operation est renseignée avec le nom de l opération dans l orchestration. Lorsqu il n y a pas d orchestration, un composant de pipeline doit enrichir le contexte du message pour ajouter la propriété BTS.Operation. f. Formats pivots La solution que nous venons de modéliser fonctionne bien, mais elle est très dépendante du service Web de gestion de stock. Supposez que ce service vienne à changer. Les schémas XSD seront impactés et l application cliente de BizTalk le sera aussi. Pour éviter cet impact massif en cas de changement d un contrat de service, utilisez des formats pivots. Certes cela ajoute des phases dans l implémentation et peut créer un peu plus de latence au niveau BizTalk mais c est un gage de pérennité. g. Téléchargement des exemples La solution complète (le code source ainsi que l application BizTalk) est disponible dans les fichiers Chapitre14_ServiceWebMessagerieCodeSource.zip et Chapitre14_ServiceWebMessagerie.msi. 3. Bindings WCF et BizTalk a. Bindings WCF La notion de binding WCF n est pas liée à BizTalk mais à WCF. Lorsque vous exposez un service WCF pour qu il soit appelé par un client, vous sélectionnez le binding avec lequel les deux acteurs doivent communiquer. De cette manière, vous établissez les règles de communication : sécurité, transactions, authentification... Pour éviter de définir tous les paramètres de communication à chaque fois, WCF livre des bindings correspondant à la plupart des situations. Il s agit des principaux bindings suivants : BasicHttpBinding : appel de services Web SOAP sans sécurité ni authentification. WSHttpBinding : appel de services Web avec envoi fiable, ordonné, sécurisé et authentification. Ce binding permet d appeler des services qui respectent les recommandations WS_*. NetTcpBinding : correspond au binding WSHttpBinding mais sans utiliser le protocole http. Très utile pour des communications sur le réseau local de l entreprise. NetNamedPipeBinding : permet la communication entre un client et un service situés sur la même machine. Ce binding est une déclinaison du binding NetTcpBinding. NetMsmqBinding : permet l invocation de services Web au travers de MSMQ (Microsoft Message Queuing). Les services peuvent ainsi être invoqués avec garantie de délivrance des messages, d ordre des messages mais peuvent aussi être appelés en mode déconnecté. Il existe d autres bindings, en fonction des composants installés et des versions du Framework.Net. Certains permettent par exemple la mise en œuvre d appels basés sur des callbacks (WSDualHttpBinding) ou la prise en compte de fédération d identités (WS2007FederationHttpBinding)

424 Le modèle d extensibilité de WCF est très puissant notamment grâce à cette notion de bindings (mais pas seulement). Vous pouvez ainsi créer vos propres bindings pour étendre ou restreindre le fonctionnement d un binding WCF. b. Binding WCF et BizTalk Dans BizTalk les différents bindings WCF se traduisent en autant d adaptateurs utilisables pour la réception ou l envoi de messages. Selon le binding que vous sélectionnez dans BizTalk, une collection plus ou moins importante de paramètres est proposée pour personnaliser le port d envoi ou de réception. Un port d envoi de type WCF BasicHttp est très peu personnalisable par exemple. Si les bindings standards ne couvrent pas vos besoins, vous pouvez utiliser le binding WCF Custom (ou WCF CustomIsolated). Ce binding est entièrement configurable en dérivant d un binding existant. 4. Configurer l appel au service Web a. Propriétés de transport avancées Le port d envoi WCF qui permet d invoquer un service Web bénéficie de toutes les fonctionnalités de transport des ports d envoi dans BizTalk : réitération en cas d erreur, transport secondaire. Lorsqu il s agit d un scénario synchrone sur toute la ligne (c est à dire que l application cliente de BizTalk est elle aussi en attente d une réponse synchrone), soyez vigilant sur les paramètres utilisés. Évitez par exemple d attendre 5 minutes entre chaque tentative d envoi. b. Configuration WCF Selon le binding WCF utilisé, la configuration possible est plus ou moins importante. Le binding basichttpbinding que nous utilisons est relativement pauvre en configuration. Cependant, les paramètres suivants peuvent être modifiés : Délais d attente : pour l appel au service Web mais aussi pour la réponse ou l ouverture de la communication. Taille maximum des messages échangés. Encodage des messages. Sécurité et authentification. Utilisation d un proxy HTTP. 5. Consommer un service Web depuis une orchestration Pour consommer un service Web depuis une orchestration, il y a deux approches. Nous allons détailler ces deux approches et expérimenter celle qui me semble la plus standard et la plus adaptée. a. Association entre port logique et port d envoi WCF La première approche, toujours dans la lignée de ce que nous venons de faire, consiste à créer dans l orchestration un port d envoi Sollicitation/Réponse et le relier au port d envoi WCF d appel du service Web. L orchestration produit un message au format EnregistrerMouvement et reçoit en retour un message EnregistrerMouvementResponse. Mettons en pratique cette méthode : Ouvrez l orchestration GestionStock. Nous allons modifier cette orchestration pour dialoguer avec le service Web de gestion de stock. Supprimez les ports logiques sndstock et rcvstock

425 Ajoutez une référence au projet ENI.GestionStock.Schemas (pour récupérer les schémas XSD correspondant au service Web). Créez un message nommé msgenregistrermouvement de type : ENI.GestionStock.Schemas.GestionStockService_ENIEditions_GestionStock_1_0.EnregistrerMouvement. Créez un message nommé msgenregistrermouvementresponse de type : ENI.GestionStock.Schemas.GestionStockService_ENIEditions_GestionStock_1_0.EnregistrerMouvementResponse. Créez un nouveau port nommé sndrcvstock. Associez le port à un nouveau type de port nommé ptyrequetereponse. Ce nouveau type est associé au modèle de communication Requête Réponse. Précisez que la direction de communication du port est Envoyer une requête et recevoir une réponse. Sélectionnez le port créé et renommez l opération en EnregistrerMouvement. Modifiez la forme sndstock pour l associer au message msgenregistrementstock et la forme rcvstock pour l associer au message msgenregistrementstockresponse. Au lieu de construire un message de type msgmouvemenentstock, construisez un message de type msgenregistrementstock. Le contenu de la forme Assignation de message est le suivant : msgenregistrermouvement = ENI.Helpers.MouvementStockHelper.CreateEnregistrementMouvement(re ferenceproduit,qtemouvement); La classe MouvementStockHelper a été enrichie d une nouvelle méthode permettant, à partir d une référence produit et d une quantité de produit, de générer un message EnregistrementMouvement. Voici le code de cette

426 méthode : public static XmlDocument CreateEnregistrementMouvement(string codeproduit, int quantiteproduit) { string messagemouvementstock = "<ns0:enregistrermouvement xmlns:ns0=\"urn:enieditions:gestionstock:1.0\"><ns0:referenceprod uit>{0}</ns0:referenceproduit>" + "<ns0:quantiteproduit>{1}</ns0:quantiteproduit></ns0:enregistrerm ouvement>"; XmlDocument doc = new XmlDocument(); doc.loadxml(string.format(messagemouvementstock,codeproduit,quant iteproduit)); return doc; } Vous pouvez grandement alléger l orchestration en supprimant par exemple les formes Écouter et Délai inutiles désormais. Le contenu de la forme Expression qui permet de retourner la quantité disponible doit être modifié. Voici le code de cette forme : QuantiteDisponible = xpath(msgenregistrermouvementresponse,"string(/*[localname()= EnregistrerMouvementResponse and namespaceuri()= urn:enieditions:gestionstock:1.0 ]/*[localname()= EnregistrerMouvementResult and namespaceuri()= urn:enieditions:gestionstock:1.0 ])"); Voici comment est désormais structurée l orchestration : Nous n avons plus besoin de corrélation entre le message de mouvement de stock et le message retour car nous utilisons un port de requête/réponse. La corrélation est faite automatiquement par BizTalk

427 Nous n avons pas respecté les bonnes pratiques en termes de développement. Au lieu de produire directement un message de type urn:enieditions:gestionstock:1.0#enregistrermouvement, nous aurions du produire un message au format pivot et appliquer une transformation sur le port d envoi WCF. Nous aurions ainsi découplé l orchestration de gestion de stock du contrat du service Web. Procédez au déploiement de l orchestration et effectuez la liaison entre le port logique sndrcvstock et le port d envoi WCF sndservicewebgestionstock. Testez le processus complet en réceptionnant une commande. L orchestration de gestion de stock est liée à un port d envoi WCF donc elle permet d invoquer un service Web. Si vous modifiez l architecture de votre système d information et décidez d écrire directement dans la base de données SQL Server ou Oracle du système de stock, vous modifiez simplement le port d envoi. L orchestration n est pas impactée à partir du moment où le port d envoi reste de type Requête/Réponse. Le code source de la solution est disponible en téléchargement dans le fichier Chapitre14_AppelServiceWebOrchestration.zip. b. Utilisation de messages à parties multiples dans les orchestrations La seconde méthode, que personnellement je déconseille fortement, consiste à utiliser des messages à parties multiples dans les orchestrations. Cette alternative est héritée des versions précédentes de BizTalk dans lesquelles la production de messages SOAP n était pas possible autrement. En procédant avec cette méthode, vous associez fortement l orchestration aux services Web. Si votre système de gestion de stock est accessible en SQL et plus en service Web, contrairement à la précédente méthode, vous êtes contraints de réimplémenter l orchestration. Je vous déconseille cette solution et c est pour cette raison que je vous invite, après utilisation de l assistant consommation de services Web à supprimer l orchestration qui est générée automatiquement et préférer la solution que nous venons de mettre en pratique. 6. Gestion des erreurs a. Messages Fault Quand une erreur se produit lors de l invocation du service Web, cette erreur se traduit dans BizTalk par la publication d un message de type Il s agit d un type de message normalisé SOAP qui permet de véhiculer des exceptions entre les systèmes. Voici ci dessous un exemple de message Fault : <s:fault xmlns:s=" <faultcode xmlns:a=" ationfoundation/dispatcher">a:internalservicefault</faultcode> <faultstring xml:lang="fr-fr">le serveur n a pas pu traiter la demande en raison d une erreur interne. Pour plus d informations sur l erreur, activez IncludeExceptionDetailInFaults (depuis ServiceBehaviorAttribute ou depuis le comportement de configuration <servicedebug>) sur le client pour renvoyer les informations de l exception au client, ou activez le suivi conformément à la documentation du SDK de Microsoft.NET Framework 3.0 et examinez les journaux de suivi du serveur.</faultstring> </s:fault> Selon la configuration du service Web dans lequel l exception a été générée, plus ou moins de détails sont présents dans le message d erreur réceptionné par BizTalk. Dans l exemple ci dessus, il n y a aucun détail d erreur car le service WCF sous jacent est configuré pour masquer les erreurs. Le fichier web.config d un service WCF permet de spécifier si le détail des erreurs doit être remonté : <servicedebug includeexceptiondetailinfaults="true"/>

428 Lorsque c est le cas, voici comment est structuré un message Fault : <s:fault xmlns:s=" xmlns:a=" ationfoundation/dispatcher">a:internalservicefault</faultcode> <faultstring xml:lang="fr-fr">ce produit n est plus vendu</faultstring> <detail> <ExceptionDetail xmlns=" l" xmlns:i=" <HelpLink i:nil="true" /> <InnerException i:nil="true" /><Message>Ce produit n est plus vendu</message> <StackTrace> à GestionStockService.EnregistrerMouvement(String referenceproduit, Int32 quantiteproduit) à SyncInvokeEnregistrerMouvement(Object, Object[], Object[] ) à System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs) à System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBeg in(messagerpc& rpc) à System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMe ssage5(messagerpc& rpc) à System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMe ssage4(messagerpc& rpc) à System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMe ssage3(messagerpc& rpc) à System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMe ssage2(messagerpc& rpc) à System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMe ssage1(messagerpc& rpc) à System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isoperationcontextset) </StackTrace> <Type>System.Exception</Type> </ExceptionDetail> </detail> </s:fault> Le message d erreur est contenu dans la balise faultstring : <faultstring xml:lang="fr-fr">ce produit n est plus vendu</faultstring> Dans cet exemple, l exception générée dans le service Web n est pas typée, il s agit d une exception de type System.Exception. En typant correctement les erreurs côté service Web, le message Fault est plus précis et peut donc être correctement exploité. Au lieu d analyser le message d erreur contenu dans la balise faultstring, il faut analyser le contenu de la balise Type qui contient le type d exception. b. Gestion d erreurs dans les scénarios de messagerie Dans la solution de pure messagerie, si une erreur se produit elle provoque une erreur de routage dans la MessageBox (cf. chapitre La Messagerie avec BizTalk Server 2009 pour comprendre les erreurs de routage) : en effet, le message de type Fault retourné par le port d envoi WCF n est attendu par aucun abonné. Si les applications clientes invoquent BizTalk de manière synchrone, par exemple via des ports de réception WCF Requête/Réponse, le message Fault est automatiquement propagé aux clients sans qu aucune implémentation ne soit nécessaire. Nous le verrons dans le paragraphe consacré à l exposition de services Web via BizTalk. Si par contre, comme c est le cas de notre solution de messagerie, nos clients ne sont pas synchrones, le message Fault n est pas automatiquement propagé. Pour le propager aux clients, modifiez le filtre du port d envoi sndenregistrementmouvementresponse pour qu il soit le suivant : BTS.MessageType == urn:enieditions:gestionstock:1.0#enregistrermouvementresponse

429 Ou BTS.MessageType == Si vous procédez ainsi, l application cliente reçoit le message Fault au lieu d une réponse à la demande d enregistrement de stock. L application doit ainsi savoir exploiter ce nouveau type de message ce qui la rend dépendante du fait que derrière la scène vous utilisiez un service Web. La méthode correcte, pour des clients non synchrones, serait de créer une map qui permet de convertir un message Fault en un message EnregistrementMouvementResponse dans lequel la quantité est positionnée à une valeur négative par exemple pour illustrer qu une erreur est survenue. c. Gestion d erreurs dans les orchestrations Les erreurs qui se produisent dans un service Web appelé par une orchestration sont automatiquement traduites en erreur dans l orchestration. Un bloc de type Gestionnaire d erreurs permet de détecter ces erreurs et d agir en conséquence

430 Exposer BizTalk comme un service Web Nous savons maintenant comment consommer des services Web à partir d applications BizTalk. Nous allons désormais exposer les applications BizTalk sous forme de services Web. 1. Les besoins couverts L exposition de services Web avec BizTalk permet de couvrir plusieurs scénarios. Nous décrivons les trois principaux scénarios pouvant être rencontrés dans une architecture de services BizTalk. a. Modernisation des applications La consommation de services Web par des applications du système d information est chose courante, mais toutes les applications de l entreprise ne savent pas exposer leurs données ou services en SOAP. BizTalk peut résoudre cette problématique car il sait se positionner comme hub entre des consommateurs de services SOAP et des applications incapables de s exposer sous forme de services Web. Supposez que l entreprise dispose de deux entrepôts de stock et qu un seul d entre eux ait été équipé du nouveau système informatique (dans lequel un service Web est présent). Le second entrepôt est accessible par dépôt d un message dans un répertoire et il produit une réponse en retour dans un autre répertoire. Le schéma ci dessous illustre ce scénario : Pour les applications du système d information, l entrepôt peut être interrogé en SOAP car BizTalk fait l intermédiaire et masque le système informatique de l entrepôt. Bien entendu ce scénario fonctionne si les temps de réponse du système de stock sous jacent sont corrects. b. Composition de services L architecture de services vise à simplifier l accès aux services et aux données de l entreprise. La complexité du système d information et son hétérogénéité ne doivent pas être ressenties par les applications qui consomment les services. Supposez que de nombreuses applications de votre entreprise aient besoin de récupérer des informations sur les salariés (état civil, position hiérarchique, projets ). Si vous avez de la chance toutes ces informations se trouvent dans un gisement unique. La plupart du temps ce n est pas le cas et il est nécessaire de consolider des données issues de plusieurs silos de données. Le schéma ci dessus illustre la consolidation de deux sources de données :

431 L une accessible via des requêtes SQL et permettant de récupérer l état civil du salarié. La seconde accessible sous forme de service Web et permettant de connaître la position hiérarchique du salarié. On parle de composition de service car un seul service est exposé par BizTalk et derrière la scène ce service masque différentes applications et consolide les données. La composition de services peut poser des problèmes de performances dans certains scénarios, lorsque le nombre de sources de données est important ou lorsqu il faut solliciter plusieurs fois les sources de données lors d une même exécution. Faites l effort, lors de l implémentation du scénario, pour identifier les points de ralentissement et parallélisez les actions qui peuvent l être. c. Virtualisation des services La virtualisation de services consiste à exposer un service du système d information via un frontal qui masque son implémentation ou sa localisation. BizTalk peut être ce frontal d accès. Le service sous jacent, masqué par le frontal, peut évoluer sans impacter tous ses clients. Le schéma ci dessus illustre la virtualisation d un service et sa montée en version. BizTalk masque cette montée de version aux clients qui ne sont pas compatibles avec la version 2.0. Grâce à des transformations appliquées au sein du bus de services, les clients version 1 continuent de fonctionner tout en permettant à des clients d utiliser la version 2. La virtualisation de services est un scénario qui est couvert par d autres produits que BizTalk : directement WCF sans BizTalk, et surtout Microsoft Windows Server AppFabric (ex "Dublin"). 2. Principe de fonctionnement a. Mode d hébergement des services Web BizTalk Pour exposer des services Web, BizTalk propose deux alternatives : soit exposer lui même les services Web et les héberger ; soit utiliser IIS pour héberger les services Web. Hébergement des services Web par BizTalk L hébergement de services Web directement par BizTalk ne requiert pas la présence de IIS, ce qui peut être vu comme un avantage. En réalité ce n est pas toujours une alternative adaptée aux environnements de production : vous ne pouvez pas bénéficier de toutes les fonctionnalités de sécurité comme l authentification, le chiffrement des données avec SSL

432 Le principe de fonctionnement est le suivant : Un emplacement de réception associé à un adaptateur WCF est créé dans BizTalk. Il écoute une URL particulière et reçoit toutes les requêtes SOAP. Lorsqu une requête SOAP est réceptionnée, le message est transformé en message BizTalk et, après traitement par l emplacement de réception, est publié dans la MessageBox. Référez vous au paragraphe Processus de réception de messages SOAP pour comprendre le processus de réception des messages SOAP dans BizTalk. Hébergement des services Web par IIS L hébergement des services Web dans IIS est la solution "officielle" pour exposer des services Web BizTalk. Le principe est le suivant : Un service WCF est hébergé dans IIS (dans un répertoire virtuel particulier). Ce service Web est généré par un assistant BizTalk (Assistant Publication de service WCF BizTalk). Lorsqu il est généré, le service WCF est associé à un emplacement de réception d une application BizTalk. Le service Web écoute toutes les requêtes SOAP provenant des clients. Lorsqu un message SOAP est réceptionné par le service WCF hébergé dans IIS, il est transmis à l emplacement de réception. Le message est traité comme nous l indiquons dans le paragraphe suivant. Ce mode d hébergement des services Web BizTalk a un inconvénient majeur : il faut générer un service WCF ce qui n est pas nécessaire dans le mode d hébergement sans IIS. Nous allons illustrer ces deux modes d hébergement afin que vous compreniez bien leur fonctionnement. b. Processus de réception de messages SOAP Que le message SOAP soit reçu directement par BizTalk (cf. paragraphe Hébergement des services Web par BizTalk) ou via le service WCF hébergé dans IIS (cf. paragraphe Hébergement des services Web par IIS), le message SOAP est transmis à un emplacement de réception associé à l adaptateur WCF. Le schéma ci dessous illustre la réception d un message SOAP de type Requête/Réponse : c. Réception du message SOAP et transformation en message BizTalk Le message SOAP est réceptionné par l adaptateur WCF qui le traduit en message BizTalk. La traduction en message BizTalk consiste à extraire du message SOAP la partie qui est nécessaire au processus BizTalk, il s agit la plupart du temps du contenu du corps SOAP. Le message entrant est ainsi dépouillé de tous les aspects techniques relatifs à SOAP (enveloppe, en tête...). d. Traitement par le pipeline de réception et publication Le message obtenu après l exécution de l adaptateur WCF est traité par le pipeline de réception comme tout autre message et il est finalement publié dans la MessageBox. En cas d erreur dans le pipeline de réception, l erreur est traduite en une erreur SOAP (SOAP Fault) et elle est

433 remontée au client. Par défaut, l erreur récupérée par le client ne contient pas le détail de l erreur rencontrée afin de ne pas dévoiler des détails de l implémentation. Toutefois, l option Inclure le détail des exceptions dans les messages d erreur sur l emplacement de réception permet de retourner des erreurs détaillées quand cela est nécessaire. e. Abonnement d instance du port de réception Quand il s agit d un port de type Requête/Réponse, l instance du port de réception est active tant qu une réponse n a pas été apportée au client. Cette instance active attend qu un message de réponse soit publié dans la MessageBox. Le lien entre le message de requête et le message de réponse est effectué grâce à deux propriétés contextuelles : BTS.EpmRRCorrelationToken : contient un identifiant unique permettant de relier la requête du client à la réponse à lui apporter. Cet identifiant se compose du nom du serveur BizTalk, de l identifiant du processus et d un GUID. BTS.RouteDirectToTP : contient la valeur True quand le message de réponse peut être récupéré par le port de réception en attente. L instance du port de réception possède un abonnement d instance présenté dans l expression de filtre ci dessous : == Svr:BTS2009FR;PID:1008;RRUid:{716319C5-F112-40CC-93B0- CE66676B659B} Et == True Lorsque la réponse est récupérée dans la MessageBox et transmise au client, l abonnement d instance disparaît automatiquement. L abonnement d instance créé automatiquement par BizTalk pour l instance du port de réception ne contraint pas les messages de réponse à être d un type particulier. C est pour cette raison qu un message de type Fault est automatiquement propagé à l application cliente (cf. paragraphe Gestion des erreurs dans les scénarios de messagerie). Les services Web ne sont pas toujours Requête/Réponse. Lorsqu ils sont One Way, l instance du port de réception n est plus active dès que le message entrant est publié dans la MessageBox. 3. Virtualiser le service Web de gestion de stock Nous allons illustrer un scénario de virtualisation de service. Un grand nombre d applications de l entreprise souhaitent disposer en temps réel des disponibilités en stock. Nous savons que l application de gestion de stock qui expose un service Web pouvant couvrir ce besoin n est pas stable et va évoluer. Les applications ne doivent donc pas invoquer directement le service Web. a. Création d un emplacement de réception WCF Nous allons ainsi exposer un service Web dans BizTalk qui fera le relai avec le service Web de la gestion de stock. Dans un premier temps, il respectera exactement le même contrat de service. Pour ce premier service Web exposé par BizTalk nous allons héberger le service Web directement dans BizTalk sans utiliser IIS (cf. paragraphe Mode d hébergement des services Web BizTalk). Dans la console d administration de BizTalk, créez un nouveau port de réception statique de Requête/Réponse. Nommez le rcvservicewebgestionstock. Dans ce port de réception, créez un emplacement de réception nommé rcvservicewebgestionstock_http et associez le à l adaptateur WCF Custom

434 Sélectionnez le pipeline XMLReceive comme pipeline de réception et le pipeline PassThruTransmit comme pipeline d envoi. Ouvrez la configuration de l adaptateur WCF Custom. Saisissez l URL d exposition du service ( : Dans l onglet Liaison, sélectionnez basichttpbinding dans la liste déroulante Type de liaison :

435 Validez la création de l emplacement et de réception ainsi que du port de réception. Activez l emplacement de réception. L emplacement de réception que nous venons de créer utilise l adaptateur WCF Custom qui offre un haut niveau de personnalisation. En sélectionnant le binding basichttpbinding dans l onglet Liaison, nous dérivons de ce binding et le personnalisons. Nous aurions pu sélectionner l adaptateur WCF basichttp car nous n avons fait aucune personnalisation. Cependant, le binding WCF Custom est le seul binding qui permet à BizTalk d écouter en HTTP sans passer par IIS. L emplacement de réception est prêt à recevoir des messages SOAP en provenance des clients. Pour tester le fonctionnement de l emplacement de réception, ouvrez un navigateur Internet et tapez l URL Vous obtenez l écran ci dessous :

436 Le contrat de service (WSDL) du service Web n est pas exposé donc ce comportement est normal. Si vous n obtenez pas la page Web ci dessus, une erreur est tracée dans le journal d événements Application de Windows pour vous aider à diagnostiquer. Le type d erreur ci dessous peut se produire : Le moteur de messagerie n a pas pu ajouter l emplacement de réception "rcvservicewebgestionstock_http" avec l URL " à l adaptateur "WCF-Custom". Raison : "System.ServiceModel.AddressAccessDeniedException: HTTP n a pas pu inscrire l URL Le processus n a pas de droits d accès à cet espace de noms (pour plus d informations, voir Cette erreur indique que le compte sous lequel fonctionne BizTalk n a pas le droit d écouter sur l URL Pour lui donner le droit d écouter, lancez la ligne de commande ci dessous (avec Windows 2008) : netsh http add urlacl url= user=<comptebiztalk> Remplacez <comptebiztalk> par le compte Windows sous lequel fonctionne BizTalk. Avant de tester de nouveau, pensez à réactiver l emplacement de réception car il a été désactivé automatiquement en cas d erreur. b. Invocation du service Web exposé par BizTalk Pour tester le fonctionnement du service Web exposé par BizTalk, créez un client de test. Pour créer le client de tests, vous avez besoin d un fichier WSDL qui décrit le service Web à utiliser. BizTalk n expose pas de contrat de service mais comme le service exposé par BizTalk a la même signature que le service Web exposé par la gestion de stock, utilisez le WSDL du service Web de gestion de stock. Le contrat de service du service de gestion de stock est exposé à l adresse Téléchargez le client de tests disponible dans l archive Chapitre14_ClientTestServiceWeb.zip. Modifiez le

437 contenu du fichier app.config pour le faire pointer sur l URL qui correspond à votre service. Si vous envoyez un message SOAP à BizTalk (pour invoquer la méthode EnregistrerMouvement), voici ce qui se produit : Le message est réceptionné par l emplacement de réception (en http). L adaptateur WCF extrait le corps SOAP et le transmet au pipeline de réception. Le pipeline de réception XMLReceive traite le message. Le composant de désassemblage XML du pipeline détecte qu il s agit d un message de type EnregistrerMouvement. La propriété BTS.MessageType est donc renseignée avec la valeur urn:enieditions:gestionstock:1.0#enregistrermouvement. Le message est publié dans la MessageBox. Il réveille le port d envoi sndservicewebgestionstock qui est abonné à tous les messages de type urn:enieditions:gestionstock:1.0#enregistrermouvement. Le port d envoi invoque le service Web de gestion de stock et attend la réponse. La réponse reçue de la gestion de stock est publiée dans la MessageBox. Elle est récupérée par l instance du port de réception rcvservicewebgestionstock qui l attendait. Le message est transmis au client de tests en retour. c. Propagation des erreurs En cas d erreur dans le service Web sous jacent, elle est automatiquement propagée au client, et ce, sans aucun effort de développement. Testez ce comportement en produisant une erreur dans le service Web de gestion de stock. Si vous utilisez le service Web exemple de ce livre, demandez un mouvement de stock pour le produit Expresso. Cela provoquera une exception qui sera remontée à BizTalk et propagée au client. d. Service web non typé Vous l avez remarqué, le service Web exposé par BizTalk n est pas fortement typé : il peut recevoir n importe quel message SOAP à partir du moment où le corps SOAP a été modélisé et déployé comme schéma dans BizTalk. Le même emplacement de réception peut ainsi être utilisé pour tous les services Web exposés par BizTalk. La seule manière de typer fortement un service Web dans BizTalk est de contraindre les messages vis à vis de schémas XSD au niveau de la configuration du composant de désassemblage XML. 4. Exposer de services Web en utilisant IIS Nous venons d illustrer l exposition d un service Web dans BizTalk sans IIS. Nous allons maintenant illustrer comment exposer un service Web grâce à IIS. Nous profitons de cet exercice pour exposer un nouveau service Web avec un contrat de service différent. Supposez que le service Web de gestion de stock soit complexe à invoquer et que votre volonté soit de simplifier son appel en l exposant dans BizTalk. Le contrat du service exposé par BizTalk doit dans ce cas être différent et proposer des méthodes plus simples d accès. Les nouveaux messages SOAP ainsi reçus par BizTalk sont transformés en messages compréhensibles par le service Web de gestion de stock, idem pour les messages de réponse. BizTalk joue pleinement son rôle de médiateur entre des clients et des services. Le service Web exposé par BizTalk contient une méthode nommée CreerMouvement. Elle prend en paramètre un code produit mais pas de quantité. La quantité est implicite et vaut toujours 1. Pour effectuer un mouvement de stock de 10 produits, il faut par exemple invoquer 10 fois le service Web. a. Modéliser le contrat de service La première étape est la modélisation du contrat de service. Nous allons créer un schéma XSD correspondant à la

438 méthode du service Web : Créez un nouveau schéma dans le projet ENI.Schemas. Nommez le ServiceWebGestionStock.xsd. Voici le code de ce schéma XSD : <?xml version="1.0" encoding="utf-16"?> <xs:schema xmlns:b=" xmlns="urn:editionseni:gestioncommandes" targetnamespace="urn:editionseni:gestioncommandes" xmlns:xs=" <xs:element name="creermouvement"> <xs:complextype> <xs:sequence> <xs:element name="codeproduit" type="xs:string" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="creermouvementresponse"> <xs:complextype> <xs:sequence> <xs:element name="quantitestock" type="xs:int" /> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> L espace de noms de ce schéma est urn:editionseni:gestioncommandes. b. Implémenter les transformations Nous devons maintenant modéliser les transformations permettant de passer d un message de type urn:editionseni:gestioncommandes#creermouvement à un type urn:enieditions:gestionstock:1.0#enregistrermouvement et d un message de type urn:enieditions:gestionstock:1.0#enregistrermouvementresponse à un message de type urn:editionseni:gestioncommandes#creermouvementresponse. Les transformations sont simples puisqu il s agit de copie de données entre les messages. Créez ces deux transformations dans le projet ENI.Maps et nommez les respectivement CreerMouvement_TO_EnregistrerMouvement.btm et EnregistrerMouvementResponse_TO_CreerMouvementResponse.btm. c. Déployer les schémas et les maps Déployez les schémas (ENI.Schemas.dll) et les maps (ENI.Maps.dll) dans l application ENIEditions. d. Générer le service WCF pour IIS L assistant de publication de service Web, nommé Assistant Publication du service WCF BizTalk, permet, à partir de schémas XSD de créer un service Web BizTalk et son contrat de service. Nous allons l utiliser pour : générer le service WCF pour IIS ; créer l emplacement de réception BizTalk correspondant ; générer le contrat de service BizTalk et l exposer aux applications clientes. L assistant Publication du service WCF BizTalk remplace l assistant Publication des Services Web

439 BizTalk utilisé avec l adaptateur SOAP. L adaptateur SOAP étant déprécié, je vous conseille d utiliser exclusivement la version WCF de l assistant. Lancez l Assistant Publication du service WCF BizTalk. Cliquez sur Suivant dans l écran d accueil de l assistant. Dans l écran Type de service WCF, sélectionnez Point de terminaison de service. Sélectionnez l adaptateur WCF basichttpbinding. Cochez la case Activer le point de terminaison des métadonnées afin que le contrat de service WSDL soit publié et accessible aux clients. Cochez la case Créer des emplacements de réception BizTalk dans l application suivante et sélectionnez l application ENIEditions. Cliquez ensuite sur Suivant. Dans l écran Créer le service WCF, sélectionnez l option Publier des schémas en tant que services WCF et cliquez sur Suivant

440 L assistant vous propose maintenant de modéliser le service Web exposé par BizTalk. Utilisez le menu contextuel sur chaque élément de l arborescence du service pour obtenir l équivalent de la copie d écran ci dessous : En renommant les différents éléments, nous indiquons à l assistant que nous souhaitons : créer une description de service nommée ServicesBizTalk ; exposer un service Web nommé ServiceBizTalk ; exposer une méthode nommée CreerMouvement

441 Nous devons maintenant indiquer que le paramètre en entrée de la méthode est de type urn:editionseni:gestioncommandes#creermouvement : Sélectionnez le nœud Request situé en dessous de la méthode CreerMouvement. Ouvrez le menu contextuel et cliquez sur l option Sélectionner un type de schéma. Parcourez le disque dur pour sélectionner l assembly ENI.Schemas.dll qui contient la définition du schéma de notre service Web. Sélectionnez le Type de message urn:editionseni:gestioncommandes#creermouvement : Procédez à la même manipulation pour le nœud Response en sélectionnant cette fois ci le type de message urn:editionseni:gestioncommandes#creermouvementresponse. À l issue de ces manipulations, vous obtenez la définition de service ci dessous. Cliquez sur Suivant pour continuer

442 Affectez l espace de noms urn:editionseni:gestioncommandes au service Web. Cliquez sur Suivant : Sélectionnez l URL du service Web et cochez la case Autoriser l accès anonyme au service WCF

443 Cliquez enfin sur Créer pour générer le service Web et l emplacement de réception. Vous pouvez effectuer cette opération sur un poste de développement car BizTalk n a pas besoin d être installé en local pour utiliser l assistant. La plupart du temps d ailleurs, vous ne pourrez pas utiliser l assistant directement sur le serveur BizTalk car il ne sera pas installé. Lorsque l assistant est terminé, les éléments suivants sont générés : Un répertoire virtuel nommé ServicesBizTalk est créé dans IIS. Il contient les éléments suivants : Un fichier ServiceBizTalk.svc qui représente le service WCF généré. Un fichier web.config qui contient la configuration du service WCF et le lien avec l emplacement de réception BizTalk. Un répertoire nommé App_Data qui contient des éléments complémentaires sur le service notamment les différents schémas XSD correspondants au service. Reportez vous au paragraphe Modifier un service Web déjà exposé pour utiliser le contenu de ce répertoire. Un port de réception nommé WcfReceivePort_ServicesBizTalk/ServiceBizTalk est créé dans l application ENIEditions. Le port de réception contient un emplacement de réception nommé WcfService_ServicesBizTalk/ServiceBizTalk : associé à l adaptateur WCF basichttp ; configuré pour écouter l URL /ServicesBizTalk/ServiceBizTalk.svc ; associé au pipeline de réception XMLReceive et au pipeline d envoi PassThruTransmit. Contrairement à l emplacement de réception que nous avons créé pour héberger un service Web directement dans BizTalk, vous pouvez remarquer que l URL est relative au serveur et n est pas précisée au format L adaptateur WCF basichttp n accepte que des adresses relatives voici pourquoi nous avons sélectionné l adaptateur WCF Custom dans le paragraphe Virtualiser le service Web de gestion de stock

444 e. Configurer IIS et le pool d application Le répertoire virtuel créé dans IIS pour exposer le service WCF est par défaut associé au Pool d applications DefaultAppPool. Un pool d application IIS représente une instance de l exécutable w3wp.exe qui s exécute sous une identité spécifique et avec une configuration spécifique. Pour que le service Web communique avec BizTalk, il doit être associé à un pool d applications qui s exécute sous une identité Windows particulière. Le compte Windows doit faire partie des deux groupes suivants : Utilisateurs d hôtes BizTalk isolés ; IIS_USRS du serveur Windows (ou IIS_WPG sous Windows 2003 Server). Je vous conseille de créer un pool d applications spécifique pour héberger tous les services Web BizTalk. Utilisez la console d administration de IIS pour créer un nouveau pool d applications associé à une identité Windows qui respecte les contraintes que nous venons de citer. Associez ensuite le pool d applications à l emplacement de réception. Dans la copie d écran ci dessous, le pool d applications se nomme WCFAppPool : f. Configurer l application BizTalk et le routage Nous allons maintenant configurer l application ENIEditions afin qu elle procède aux transformations et routages nécessaires entre le port de réception WcfService_ServicesBizTalk/ServiceBizTalk et le port d envoi sndservicewebgestionstock : Ouvrez la configuration du port de réception WcfService_ServicesBizTalk/ServiceBizTalk. Ouvrez l onglet Mappages entrants et sélectionnez la map CreerMouvement_TO_EnregistrerMouvement :

445 Cette map transforme le message entrant en message de type urn:enieditions:gestionstock:1.0#enregistrermouvement. Le message ainsi publié dans la MessageBox réveille le port d envoi sndservicewebgestionstock pour produire l appel au service Web de gestion de stock. Dans l onglet Mappages sortants sélectionnez la map EnregistrerMouvementResponse_TO_CreerMouvementResponse. Cette map transforme la réponse obtenue du service Web de gestion de stock au format de réponse exposé par le service Web BizTalk. Nous n avons pas besoin de modifier les filtres du port d envoi sndservicewebgestionstock. Le port est abonné aux messages de type urn:enieditions:gestionstock:1.0#enregistrermouvement et sera donc réveillé dès l arrivée d un message. g. Accéder au contrat de service Consulter le contrat de service WSDL Consultons le contrat du service Web au format WSDL : Activez l emplacement de réception WcfService_ServicesBizTalk/ServiceBizTalk. Ouvrez un navigateur Internet et naviguez vers l URL : <?xml version="1.0" encoding="utf-8"?><wsdl:definitions name="biztalkserviceinstance" targetnamespace="urn:editionseni:gestioncommandes" xmlns:wsdl=" xmlns:soap=" xmlns:wsu="

446 wss-wssecurity-utility-1.0.xsd" xmlns:soapenc=" xmlns:wsam=" xmlns:tns="urn:editionseni:gestioncommandes" xmlns:wsa=" xmlns:wsp=" xmlns:wsap=" cy" xmlns:xsd=" xmlns:msc=" xmlns:wsaw=" xmlns:soap12=" xmlns:wsa10=" xmlns:wsx=" entation><creationinfo Created=" :37:46Z"/></wsdl:documentation><wsdl:types><xsd:schema targetnamespace="urn:editionseni:gestioncommandes/imports"><xsd:i mport schemalocation=" k.svc?xsd=xsd2" namespace="urn:editionseni:gestioncommandes"/></xsd:schema></wsdl :types><wsdl:message name="servicebiztalk_creermouvement_inputmessage"><wsdl:part name="part" element="tns:creermouvement"/></wsdl:message><wsdl:message name="servicebiztalk_creermouvement_outputmessage"><wsdl:part name="part" element="tns:creermouvementresponse"/></wsdl:message><wsdl:portty pe name="servicebiztalk"><wsdl:documentation/><wsdl:operation name="creermouvement"><wsdl:documentation/><wsdl:input message="tns:servicebiztalk_creermouvement_inputmessage"/><wsdl:o utput message="tns:servicebiztalk_creermouvement_outputmessage"/></wsdl :operation></wsdl:porttype><wsdl:binding name="basichttpbinding_itwowayasync" type="tns:servicebiztalk"><soap:binding transport=" name="creermouvement"><wsdl:documentation/><soap:operation soapaction="creermouvement" style="document"/><wsdl:input><soap:body use="literal"/></wsdl:input><wsdl:output><soap:body use="literal"/></wsdl:output></wsdl:operation></wsdl:binding><wsd l:service name="biztalkserviceinstance"><wsdl:port name="basichttpbinding_itwowayasync" binding="tns:basichttpbinding_itwowayasync"><soap:address location=" /wsdl:port></wsdl:service></wsdl:definitions> Vous pouvez constater que le WSDL exposé par BizTalk est relativement complexe. Surtout, vous n avez pas la main sur son contenu hormis lors de l exécution de l assistant de publication de service WCF BizTalk. Veillez donc à renommer correctement les différents éléments pouvant l être lors de l utilisation de l assistant. Contrats WSDL faiblement typés Les contrats de services exposés par WCF (donc par BizTalk puisque ce dernier repose sur WCF) sont faiblement typés (weakly typed en anglais). La définition des méthodes des services Web n est pas fortement typée mais référence des données qui elles sont définies dans des schémas importés dans le WSDL. La définition des données échangées est accessible via différentes URL qui publient les schémas XSD correspondants comme le précise le code ci dessous extrait du WSDL : <wsdl:types><xsd:schema targetnamespace="urn:editionseni:gestioncommandes/imports"><xsd:i mport schemalocation=" k.svc?xsd=xsd2" namespace="urn:editionseni:gestioncommandes"/></xsd:schema></wsdl :types> Faites l essai et naviguez vers l URL avec un navigateur Internet. En retour, vous obtiendrez le schéma XSD qui contient la définition des données échangées. Il s agit du schéma XSD modélisé au début de l exercice

447 Selon la technologie que vous utilisez pour consommer le service Web, vous pourrez rencontrer des problèmes d interprétation du WSDL pour générer un proxy SOAP. Des mécanismes permettent, en développant des comportements WCF (WCF behaviors) de mettre à plat le WSDL (flattening WCF). h. Consommer le service Web Pour consommer le service Web exposé par BizTalk, ajoutez une référence de service au client de tests en procédant comme suit : Dans le projet ENI.ServiceWeb.Test (client de tests du service Web), ouvrez le menu contextuel et sélectionnez l option Ajouter une référence de service. Saisissez l adresse du WSDL, cliquez sur Aller à et saisissez l espace de noms ENIEditions. Cliquez sur OK pour générer le proxy SOAP : Le code ci dessous permet de consommer le service Web et de récupérer la quantité disponible en stock après un mouvement : ENIEditions.ServiceBizTalkClient swbts = new ENI.ServiceWeb.Test.ENIEditions.ServiceBizTalkClient(); ENIEditions.CreerMouvementResponse repbts = swbts.creermouvement(new ENI.ServiceWeb.Test.ENIEditions.CreerMouvement(){codeProduit=refe renceproduit}); Console.WriteLine("Quantite en stock :" + repbts.quantitestock.tostring()); i. Modifier un service Web déjà exposé Il n est pas rare de devoir revenir en arrière pour modifier la signature des méthodes d un service Web ou tout simplement ajouter de nouvelles méthodes à un service Web déjà exposé. Pour éviter de relancer l assistant de publication de services WCF BizTalk à vide, vous pouvez passer en paramètre à cet assistant la description du service Web existant. Voici la ligne de commande à utiliser (depuis le répertoire d installation de BizTalk) :