MSDN Library

migration de solutions EDI BizTalk Server vers BizTalk Services : guide technique

Mis à jour: juillet 2015

Auteur : Tim Wieman et Nitin Mehrotra

Réviseur : Karthik Bharthy

Écrit à l'aide de : Microsoft Azure BizTalk Services - version de février 2014.

L'échange de données informatisé (EDI) est l'une des méthodes les plus utilisées par les entreprises pour échanger des informations par voie électronique. On parle également de transactions interentreprises ou B2B. BizTalk Server prend en charge EDI depuis plus de dix ans, depuis la version initiale de BizTalk Server. Avec BizTalk Services, Microsoft continue de prendre en charge les solutions EDI sur la plateforme Microsoft Azure. Les transactions B2B étant, pour la plupart, externes à une organisation, elles sont plus faciles à réaliser si elles sont mises en œuvre sur une plateforme cloud. Microsoft Azure offre cette possibilité via BizTalk Services.

Si certains clients adoptent BizTalk Services en tant que plateforme « greenfield » pour leurs nouvelles solutions EDI, de nombreux autres disposent déjà de solutions EDI BizTalk Server qu'ils souhaitent peut-être migrer vers Azure. Étant donné que l'EDI BizTalk Services repose sur les mêmes entités clés que l'architecture EDI BizTalk Server (partenaires commerciaux, entités, accords), il est tout à fait possible de migrer des artefacts EDI BizTalk Server sur BizTalk Services.

Ce document décrit certaines différences qu'implique la migration d'artefacts EDI BizTalk Server sur BizTalk Services. Il suppose une connaissance du traitement EDI et des accords de partenariat commercial dans BizTalk Server. Pour plus d'informations sur les solutions EDI BizTalk Server, consultez Gestion des partenaires commerciaux à l'aide de BizTalk Server.

Le module EDI BizTalk Server a été nettement amélioré pour BizTalk Server 2010 et a été remodelé pour inclure partenaires, profils et accords. BizTalk Services utilise le même modèle pour organiser les partenaires commerciaux et leurs divisions. De ce fait, la migration d'artefacts EDI de BizTalk Server 2010 et versions ultérieures sur BizTalk Services est un processus largement plus simple. Pour migrer des artefacts EDI associés à des versions antérieures à BizTalk Server 2010, vous devez au préalable effectuer la mise à niveau vers BizTalk Server 2010, puis migrer vos artefacts EDI sur BizTalk Services.

Comme dans BizTalk Server, le traitement EDI dans BizTalk Services repose sur une solution de gestion des partenaires commerciaux (TPM, Trading Partner Management). La solution TPM comprend les composants clés suivants :

  • les partenaires commerciaux, qui représentent l'organisation dans une transaction B2B ;

  • les profils, qui représentent les divisions d'un partenaire commercial ;

  • les accords de partenariat commercial (ou accords), qui représentent les accords commerciaux entre deux partenaires/profils.

L'illustration suivante indique les similitudes, ainsi que les différences, entre une solution EDI BizTalk Server et la solution EDI BizTalk Services :

Les principales différences, et similitudes, entre une solution EDI dans BizTalk Server et dans BizTalk Services sont les suivantes :

  • De même que BizTalk Server utilise un pipeline EDIReceive pour recevoir un message EDI et un pipeline EDISend pour en envoyer un, BizTalk Services utilise un pont de réception EDI pour la réception et un pont d'envoi EDI pour l'envoi de messages EDI. Dans BizTalk Server, les pipelines sont associés à un accord par l'utilisation de ports d'envoi ou de réception. Dans BizTalk Services, l'accord proprement dit indique le pont d'envoi ou de réception.

  • Dans BizTalk Server, après son traitement par le pipeline EDIReceive, le message EDI est enregistré dans une base de données SQL Server. Le pipeline EdiSend récupère ensuite le message dans la base de données SQL Server, le traite, puis l'envoie au partenaire commercial.

    Dans BizTalk Services, après son traitement par le pont de réception EDI, le message EDI est acheminé vers un processus externe. Le processus externe peut s'exécuter sur Microsoft Azure ou sur site. Le processus externe doit acheminer le message vers le pont d'envoi EDI ; le pont d'envoi n'extrait pas intrinsèquement le message. Après le traitement du message, le pont d'envoi EDI l'achemine au partenaire commercial.

BizTalk Services offre une solution de configuration simple pour créer et déployer rapidement un accord B2B entre partenaires commerciaux sans configurer aucune instance Compute Microsoft Azure (rôles Web ou de travail), aucune Base de données base de données SQL Microsoft Azure, ou aucun compte de stockage Microsoft Azure. Les scénarios de déploiement plus complexes nécessiteront l'attachement de flux de travail ou d'autres traitements « en bordure » d'un accord de partenariat commercial, c'est-à-dire, avant ou après le traitement d'un pont EDI d'accord de partenariat commercial. En détail, les séquences d'événements suivantes se produisent pendant le traitement d'un message EDI dans BizTalk Services.

  1. Un message EDI est reçu du partenaire commercial, Fabrikam. Pour recevoir les messages EDI des partenaires commerciaux, BizTalk Services prend en charge des protocoles de transport tels que FTP, SFTP, AS2 et HTTP/S.

  2. Le traitement côté réception de l'accord de partenariat commercial désassemble le message EDI au format XML. Vous pouvez acheminer le message EDI désassemblé (au format XML) aux points de terminaison Service Bus, tels qu'un point de terminaison de relais Service Bus, un sujet Service Bus, une file d'attente Service Bus ou un pont BizTalk Services.

  3. Les messages XML désassemblés peuvent ensuite être reçus à partir du point de terminaison, en vue de leur traitement spécifique. Ces points de terminaison peuvent être traités par un composant sur site ou une instance Compute Microsoft Azure pour un traitement ultérieur du message dans un service Windows Workflow (WF) ou Windows Communication Foundation (WCF), par exemple.

  4. Le « traitement côté envoi » de l'accord de partenariat commercial compile ensuite le message XML dans le format EDI et l'envoie au partenaire commercial, Contoso. Pour envoyer des messages EDI aux partenaires commerciaux, les BizTalk Services prennent en charge les mêmes protocoles que ceux utilisés pour la réception des messages EDI.

Ce document fournit des instructions relatives à la migration de certains des différents artefacts EDI BizTalk Server sur BizTalk Services.

Dans BizTalk Server, vous configurez les emplacements et les ports de réception pour recevoir les messages EDI/XML transmis par les partenaires commerciaux, et vous configurez les ports d'envoi pour envoyer des messages EDI/XML au partenaire commercial. Vous liez ensuite ces ports à un accord de partenariat commercial à l'aide de la console Administration de BizTalk Server. Dans les BizTalk Services, les emplacements de réception des messages transmis par les partenaires commerciaux et d'envoi des messages qui leur sont adressés sont configurés dans l'accord de partenariat commercial proprement dit (dans le cadre des Paramètres de transport) dans le portail de services BizTalk. Par conséquent, les concepts de « ports d'envoi » et d'« emplacements de réception » n'existent pas en tant que tels dans les BizTalk Services. Pour plus d'informations, consultez Création d'accords.

Dans la solution EDI BizTalk Server, les pipelines sont des entités de traitement de messages qui peuvent également inclure une logique personnalisée pour des fonctionnalités de traitement spécifiques, selon les exigences de l'application. Pour BizTalk Services, l'équivalent serait un pont EDI. Toutefois, dans BizTalk Services, les ponts EDI sont, pour l'instant, « fermés ». Vous ne pouvez donc pas ajouter vos activités personnalisées à un pont EDI. Tout traitement personnalisé doit être effectué en dehors du pont EDI de votre application, soit avant, soit après l'entrée du message dans le pont configuré dans le cadre de l'accord de partenariat commercial. Les ponts IAE offrent la possibilité d'effectuer un traitement personnalisé. Si vous souhaitez un traitement personnalisé, vous pouvez utiliser des ponts IAE avant ou après le traitement du message par le pont EDI. Pour plus d'informations, consultez Intégration d'un code personnalisé dans les ponts.

Vous pouvez insérer un flux de publication/abonnement avec du code personnalisé et/ou utiliser les files d'attente et les sujets Service Bus avant que l'accord commercial ne reçoive le message, ou après que l'accord ait traité le message et l'ait acheminé vers un point de terminaison Service Bus.

Consultez Scénarios/Flux de messages pour obtenir un modèle de flux de messages.

Si vous connaissez les accords de partenariat commercial BizTalk Server 2010 utilisés pour le traitement EDI, alors les accords de partenariat commercial BizTalk Services n'ont pour vous aucun secret. La plupart des paramètres des accords sont identiques et utilisent la même terminologie. Dans certains cas, ils sont même beaucoup plus simples que les mêmes paramètres dans BizTalk Server. Microsoft Azure BizTalk Services prend en charge le transport X12, EDIFACT et AS2.

Microsoft Azure BizTalk Services offre également un outil TPM Data Migration pour migrer les partenaires et les accords commerciaux du module BizTalk Server Trading Partner vers le portail de services BizTalk. L'outil TPM Data Migration est disponible dans un package Tools, téléchargeable à partir de http://go.microsoft.com/fwlink/?LinkId=235057. Le package comprend également un fichier d'instructions d'utilisation de l'outil et des informations de dépannage de base pour l'outil.

BizTalk Services propose des schémas EDI qui peuvent être utilisés dans des solutions BizTalk Services. En outre, les schémas EDI BizTalk Server peuvent également être utilisés avec BizTalk Services, étant donné que le nœud racine du schéma EDI est le même pour BizTalk Server que pour BizTalk Services. Par conséquent, vous pouvez utiliser directement vos schémas EDI BizTalk Server dans les solutions EDI que vous développez à l'aide de BizTalk Services. Vous pouvez également télécharger les schémas à partir de http://go.microsoft.com/fwlink/?LinkId=235057.

Les mappages de BizTalk Server sont appelés transformations dans BizTalk Services. La migration des mappages depuis BizTalk Server vers BizTalk Services peut être une des tâches les plus complexes à réaliser (en fonction de la complexité du mappage). L'outil de mappage utilisé pour BizTalk Services est différent du mappeur de BizTalk. Bien que le mappeur ait quasiment le même aspect, le format de mappage sous-jacent est différent. Les functoids (Opérations de mappage dans BizTalk Services) disponibles aux utilisateurs sont également différents. En fait, vous ne pouvez pas utiliser directement un mappage BizTalk dans BizTalk Services. De même, tous les functoids disponibles dans BizTalk Server le sont sous la forme d'opérations de mappage dans BizTalk Services.

Tandis que la liste des opérations de mappage de transformation peut paraître très différente de celle d'un mappeur BizTalk Server, les transformations BizTalk Services proposent de nouvelles méthodes pour effectuer les mêmes tâches. Par exemple, les transformations des BizTalk Services disposent d'opérations de liste. Ce n'est pas le cas dans le mappeur de BizTalk. Les opérations de liste vous permettent de créer et gérer une « liste », soit un ensemble d'éléments (également appelés « lignes ») où chaque élément peut avoir plusieurs membres (également appelés « colonnes »). Vous pouvez trier la liste, sélectionner des éléments en fonction d'une condition, etc.

Un autre exemple de nouvelles fonctionnalités dans les transformations des BizTalk Services sont les opérations de boucle. Il est difficile de créer des boucles imbriquées dans le mappeur BizTalk Server. Par conséquent, les opérations de mappage de boucle ont été ajoutées aux transformations des BizTalk Services.

Un autre exemple est l'opération de mappage If-Then-Else Expression. Une opération if-then-else était possible dans le mappeur BizTalk, mais nécessitait plusieurs functoids pour accomplir une tâche apparemment simple.

Microsoft Azure BizTalk Services offre un outil pour migrer les mappages BizTalk Server vers les transformations BizTalk Services. L'outil BTMMigrationTool est disponible en tant qu'élément du package Tools fourni avec le Kit de développement logiciel (SDK) BizTalk Services. Vous pouvez le télécharger à la page http://go.microsoft.com/fwlink/?LinkId=235057. Pour plus d'informations sur l'outil, consultez Conversion d'un mappage BizTalk en une transformation BizTalk Services.

Vous pouvez également consulter un exemple de Sandro Pereira, MVP BizTalk, sur la migration de mappages BizTalk Server vers des transformations BizTalk Services. L'exemple est disponible ici. Un article basé sur cet exemple est disponible ici.

Si vous devez migrer le traitement d'orchestration de BizTalk Server dans Microsoft Azure, les orchestrations doivent être réécrites car Microsoft Azure ne prend pas en charge les orchestrations BizTalk Server existantes. Vous pouvez réécrire la fonctionnalité d'orchestration dans un service Windows Workflow Foundation 4.0 (WF4). Il s'agit d'une réécriture complète, car il n'existe actuellement aucun mécanisme de migration des orchestrations BizTalk Server vers WF4. Voici quelques ressources pour Windows Workflow :

  • Intégrer un service de flux de travail WCF aux files d'attente et aux sujets Service Bus par Paolo Salvatori. Voir ici (http://go.microsoft.com/fwlink/?LinkId=237313).

  • Génération d'applications avec Windows Workflow Foundation et Azure (session de la conférence Build 2011). Voir ici (http://go.microsoft.com/fwlink/?LinkId=237314).

  • Centre de développement Windows Workflow Foundation sur MSDN. Voir ici (http://go.microsoft.com/fwlink/?LinkId=237315).

  • Documentation de Windows Workflow Foundation 4 (WF4) sur MSDN. Voir ici (http://go.microsoft.com/fwlink/?LinkId=237316).

Voici quelques autres considérations dont vous devez tenir compte lors de l'utilisation de BizTalk Services.

Le traitement EDI de BizTalk Server prévoit le concept d'« accord de secours ». BizTalk Services ne propose pas, à ce jour, le concept d'accord de secours. Consultez les rubriques de la documentation BizTalk Rôle des accords dans le traitement EDI et Configuration des propriétés des accords globaux ou de secours pour plus d'informations sur la façon dont les contrats de secours sont utilisés dans BizTalk Server.

Les ponts BizTalk Services, dans l'état actuel des choses, ne prennent pas en charge l'acheminement de messages vers plusieurs destinations avec un modèle publication/abonnement. Vous pouvez toutefois acheminer les messages d'un pont BizTalk Services à un sujet Service Bus, qui peut ensuite avoir plusieurs abonnements pour recevoir le message au niveau de plusieurs points de terminaison.

Microsoft Azure BizTalk Services est mis à jour sur une base régulière afin d'offrir de nouvelles fonctionnalités et possibilités. À chaque mise à jour, davantage de fonctionnalités seront prises en charge pour faciliter la création de solutions de bout en bout à l'aide de BizTalk Services et d'autres technologies Azure.

Voir aussi

Afficher:
© 2016 Microsoft