Utilisations et étapes des ponts

Mis à jour: juillet 2015

BizTalk Services propose deux types de ponts : un pont intermédiaire et un Pont XML. Un Pont XML, à son tour, inclut un pont unidirectionnel XML et un Pont demande-réponse XML. Cette section fournit des informations sur les utilisations et les étapes de ces pont.

Un Pont XML peut être utilisé pour agir en tant que médiateur et pallier aux incompatibilités existant entre deux ou plusieurs systèmes hétérogènes qui communiquent en échangeant des messages XML. Un Pont XML, utilisé conjointement avec d'autres entités Service Bus dans un flux de messages, fournit divers modèles et scénarios de médiation, par exemple :

  • Validation des messages : le Pont XML prend en charge la validation des messages XML entrants dans un schéma XSD. Les messages dont la validation a échoué sont rejetés.

  • Enrichissement et extraction des messages : le Pont XML prend en charge l'enrichissement des messages via la recherche de données à partir d'autres sources de données. Cette fonctionnalité est généralement utile dans des scénarios où les messages peuvent nécessiter des données contextuelles présentent au-delà des limites des messages, en général à partir d'un magasin de configurations, d'un service externe ou similaire.

    Le Pont XML vous permet également d'extraire des propriétés d'un message XML que vous pouvez utiliser par la suite à des fins de routage. Par exemple, dans un message de bon de commande, l'élément Quantity peut être marqué. Le message peut alors être routé en fonction de la valeur de la quantité commandée.

  • Transformation des messages : Le Pont XML prend en charge les transformations de corps de message d'une structure XML à une autre. Cette fonctionnalité du Pont XML vous permet également de « normaliser » un message dans des scénarios où plusieurs messages sont mappés vers un seul message. Par exemple, il se peut qu'un pont doive accepter des bons de commande dans différents schémas auprès de clients différents, mais ceux-ci sont pour finir transformés en un seul schéma de bon de commande requis par l'organisation.

  • Virtualisation des emplacements : le Pont XML offre une fonctionnalité de virtualisation d'emplacement primitif des services principaux. Les clients envoient des messages au point de terminaison du Pont XML exposé dans le cloud et non pas dans le service à proprement parler (qui peut se trouver dans le cloud ou sur site). Le pont route ensuite les messages vers le service principal sur la base de règles de routage.

  • Traitement personnalisé : un pont fournit les options permettant d'inclure du code personnalisé de manière à incorporer des tâches de traitement qui ne sont pas incluses dans la configuration du pont prête à l'emploi.

Cette section fournit des informations sur les différentes étapes d'un Pont XML. Notez que chaque étape est facultative et peut être activée ou désactivée.

La première étape du Pont XML est celle de la validation. Elle fournit la validation XSD de messages XML dans des schémas spécifiés. Les schémas à utiliser pour la validation sont spécifiés au cours de la configuration du pont. Un seul Pont XML peut recevoir et traiter des messages XML avec différents schémas. Lors de l'étape de validation, d'après le message entrant, le schéma correspondant est choisi et utilisé à des fins de validation. Une fois que le message a été validé dans le schéma, l'étape Validation promeut la propriété X_PIPELINE_MESSAGETYPE sur le message. La valeur de la propriété est une combinaison de l'espace de noms cible associé au schéma et du nom du nœud racine, par exemple, http://IntegrationServices.Schema#RootNode. Si la validation du message échoue soit parce qu'aucun schéma correspondant n'a été trouvé, soit parce qu'une correspondance ambiguë a été détectée (c'est-à-dire, parce que plusieurs schémas correspondants ont été trouvés), une exception est levée.

Pour obtenir des instructions sur la configuration de l'étape de validation, consultez Création d'un pont unidirectionnel XML ou Création de pont demande-réponse XML.

Au cours de l'étape d'enrichissement, vous pouvez enrichir un message en créant des propriétés dont les valeurs peuvent être déduites de l'en-tête du message entrant, d'une propriété promue par le système, d'un élément ou d'un attribut du corps du message entrant, ou d'une recherche sur une source de données externes telle que des tables d'une base de données SQL Microsoft Azure. Ces propriétés peuvent ensuite être utilisées pour router des messages vers des points de terminaison de destination et pour le pontage de protocole.

 

Opération Description

Affectation En-tête vers Propriété

Au cours de cette opération, vous pouvez utiliser une valeur de l'en-tête du message et l'affecter à une propriété. Par exemple, vous pouvez extraire l'action de l'en-tête SOAP, l'affecter à une propriété, puis utiliser cette propriété à des fins de traitement ultérieur et/ou de routage. Vous pouvez utiliser les propriétés sur la base du protocole du message utilisé pour envoyer le message au pont. Les protocoles pris en charge sont les suivants : HTTP, SOAP, FTP et SFTP. Les propriétés suivantes sont disponibles pour ces protocoles.

  • SOAP

    • Action

    • MessageId

    • ReplyTo

    • À

    • En-têtes SOAP personnalisés

  • HTTP – En-têtes HTTP standard

  • FTP/SFTP

    • FileName

    • ServerAddress

    • Dossier

Pour obtenir des instructions sur la configuration de l'affectation En-tête vers Propriété, consultez Create an XML Bridge ou XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Utilisation de propriétés promues par le système

Par défaut, BizTalk Services promeut certaines propriétés sur les messages traités par le pont. Ces propriétés sont également appelées propriétés promues par le système. Les valeurs de ces propriétés peuvent également être utilisées pour diverses tâches de traitement, comme par exemple pour élire la destination de routage, etc. Les propriétés promues par le système sont :

  • RequestId : un ID de demande unique attribué au message.

  • MessageReceivedTime : l'horodatage indiquant l'heure de réception du message sur le point de terminaison du pont.

  • SourceName : le nom de la source, comme défini dans la surface de configuration du pont, à partir de laquelle le pont reçoit le message.

  • SourceType : le type de la source, comme utilisé dans la surface de configuration du pont, à partir de laquelle le pont reçoit le message.

Pour obtenir des instructions sur l'utilisation des propriétés promues par le système, consultez Create an XML Bridge ou XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Extraction

L'opération d'extraction de l'étape d'enrichissement permet d'extraire les valeurs d'éléments ou d'attributs spécifiques du corps du message lui-même à des fins d'utilisation lors du routage du message ou de traitement ultérieur.

Pour obtenir des instructions sur la configuration de l'opération d'extraction, consultez Create an XML Bridge ou XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Recherche

L'opération de recherche de l'étape d'enrichissement permet d'enrichir le message en recherchant et en incluant des données provenant de sources situées hors des limites d'un message. Par exemple, prenez un magasin de vente au détail en ligne qui permet aux utilisateurs de passer leurs commandes en utilisant leur devise locale tandis que le service principal chargé du traitement des commandes utilise une seule devise, le dollar, pour chaque traitement de commande. Si tel est le cas, le montant de la commande doit être converti de la devise locale en dollars avant l'envoi du message au service principal. Cette opération peut être effectuée via une recherche des taux de change les plus récents dans un autre service.

Pour cette version, l'étape d'enrichissement prend uniquement en charge la recherche de données à partir d'une base de données SQL Microsoft Azure. En d'autres termes, une base de données SQL Microsoft Azure est le seul « fournisseur » de recherche pris en charge dans la version actuelle. Les informations concernant le fournisseur de recherche sont stockées dans un fichier LookupProviderConfigurations.xml qui est ajouté à un projet de service BizTalk. En partant du principe que vous pouvez rechercher dans plusieurs sources de données d'une base de données SQL Microsoft Azure au cours d'une seule étape d'enrichissement, vous pouvez disposer de plusieurs fournisseurs définis dans un seul fichier .xml. Une définition de fournisseur classique dans un fichier LookupProviderConfigurations.xml ressemble à ce qui suit :

<ArrayOfLookupProviderConfiguration xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/WindowsAzureServiceBus/Bridge">
  <LookupProviderConfiguration i:type="SqlTableLookupProviderConfiguration">
    <ProviderName>...</ProviderName>
    <ConnectionString>...</ConnectionString>
    <QueryInColumnName>...</QueryInColumnName>
    <QueryOutColumnName>...</QueryOutColumnName>
    <TableName>...</TableName>
  </LookupProviderConfiguration>
</ArrayOfLookupProviderConfiguration>

Dans l'extrait ci-dessus, notez que l'attribut type pour l'élément LookupProviderConfiguration est remplacé par SqlTableLookupProviderConfiguration. Cela est dû au fait que vous ne pouvez actuellement effectuer une recherche que dans une base de données SQL Microsoft Azure.

Il existe également des éléments dont vous devez tenir compte en recherchant des données à partir d'une base de données SQL Microsoft Azure.

  • Vous ne pouvez effectuer une recherche que dans une table d'une base de données SQL Microsoft Azure.

  • La recherche doit être effectuée à l'aide d'une paire clé-valeur.

  • La recherche ne doit renvoyer qu'une seule valeur, qui est attribuée à une propriété dans le message. Si la recherche renvoie plusieurs valeurs, la première est attribuée à la propriété.

  • Vous pouvez rechercher une valeur dans plusieurs sources de données, ce qui signifie que vous pouvez effectuer la recherche dans plusieurs tables d'une base de données SQL Microsoft Azure ou dans plus d'une base de données SQL Microsoft Azure.

Pour obtenir des instructions sur la configuration de l'opération de recherche, consultez Create an XML Bridge ou XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Tandis que les informations concernant les fournisseurs sont stockées dans le fichier LookupProviderConfigurations.xml, les informations concernant les valeurs de l'en-tête à affecter aux propriétés de message, les valeurs à extraire et les valeurs à rechercher sont stockées dans un fichier de configuration de pont. Lorsque vous créez un projet de service BizTalk, le fichier LookupProviderConfigurations.xml est également déployé dans un fichier de configuration de pont. Lorsque vous déployez le projet de service BizTalk, c'est ce fichier de configuration de pont qui est déployé dans Service Bus.

À l'étape d'enrichissement, vous créez des propriétés et attribuez des valeurs à ces propriétés. La question qui vous vient alors à l'esprit est qu'est-ce que vous pouvez faire avec ces propriétés ? Comment ces propriétés peuvent-elles simplifier ma tâche ? Vous pouvez utiliser les propriétés de deux manières :

  • Vous pouvez utiliser les propriétés pour définir des conditions de filtrage afin de router des messages vers différentes destinations. Pour obtenir des instructions sur la manière de procéder, consultez The Routing Condition.

  • Vous pouvez utiliser les propriétés pour pallier aux incompatibilités de protocoles entre l'expéditeur et le récepteur du message. Par exemple, un message SOAP entrant possède une valeur d'en-tête personnalisée. Vous souhaitez transmettre cette valeur en tant qu'en-tête personnalisé d'un message HTTP, car le récepteur du message souhaite recevoir un message REST et ne comprend pas le format de message SOAP. Pour ce faire, vous pouvez utiliser les propriétés. Vous pouvez tout d'abord affecter la valeur de l'en-tête de message entrant à une propriété, par exemple, P1, puis, lors de l'envoi du message au récepteur, attribuer la valeur de P1 à l'en-tête du message sortant. Pour plus d'informations, consultez Actions de routage et de réponse : pallier aux incompatibilités de protocoles.

Dans une Configuration de pont, les propriétés que vous définissez dans le cadre de l'étape d'enrichissement sont disponibles dans le flux du message à chaque étape dans la Configuration de pont. En d'autres termes, si vous avez défini une propriété à l'étape d'enrichissement, vous pouvez utiliser cette propriété lors de l'étape de transformation ainsi que pour toute opération de mappage. Les propriétés définies lors de l'étape d'enrichissement peuvent également être utilisées hors de la limite d'une Configuration de pont, avec certaines précautions. Avant de rentrer dans les détails, vous devez comprendre que les valeurs de propriété sont stockées en tant que propriétés de la classe Service Bus BrokeredMessage. Maintenant que vous connaissez cet aspect, il est temps d'aborder le sujet de la durée de vie des propriétés hors d'une Configuration de pont.

  • Étant donné que seule une file d'attente ou une rubrique Service Bus peut consommer des messages du type BrokeredMessage, les propriétés et leur valeur (sous forme de paire clé-valeur), peuvent être directement consommées par des files d'attente et des rubriques. Après ça, les rubriques pour l'instance peuvent potentiellement utiliser les propriétés à des fins de traitement ultérieur et de routage.

  • Vous ne pouvez pas transmettre les propriétés et leur valeur à d'autres composants de la Configuration de pont tels que des points de terminaison de relais unidirectionnels/bidirectionnels ou des points de terminaison de service externes unidirectionnels/bidirectionnels. Si vous souhaitez vraiment transmettre les valeurs de propriété à ces entités, vous devez attribuer les valeurs de propriété aux en-têtes du message sortant. Pour plus d'informations, consultez Actions de routage et de réponse : pallier aux incompatibilités de protocoles.

  • Dans un scénario de « chaînage » où le message en provenance d'un pont est routé vers un autre pont puis vers une file d'attente Service Bus pour terminer (à titre d'exemple), seules les propriétés en provenance du dernier pont dans la chaîne sont disponibles à des fins de routage ou de traitement ultérieur. Par ailleurs, pour transmettre des valeurs de propriété aux ponts suivants, celles-ci doivent être attribuées aux en-têtes du message sortant. Ces propriétés doivent ensuite être extraites dans le deuxième pont.

L'étape de transformation, comme son nom l'indique, offre la possibilité de réaliser des transformations structurelles sur les messages. Comme les autres étapes du pipeline, l'étape de transformation peut fonctionner avec plusieurs message-type. Par conséquent, plusieurs transformations peuvent être disponibles dans le cadre de l'étape de transformation. La transformation adéquate à réaliser est automatiquement recherchée au moment de l'exécution en fonction du type de message entrant, à condition que les transformations correspondantes aient été configurées et téléchargées lors de la configuration du pont. La résolution de la transformation se produit en fonction du type du message entrant.

  • L'étape de transformation met en correspondance le type de message du message avec le type de message du schéma source dans un mappage.

  • Si l'étape de validation est désactivée, l'étape de transformation met en correspondance le message entrant avec le schéma de message source. Si la résolution se produit, elle promeut alors la propriété MessageType sur le message.

La version actuelle prend uniquement en charge les transformations d'une source unique vers une destination unique. Pour plus d'informations, consultez Apprentissage de la création de tables et de transformations des messages. Pour obtenir des instructions sur la configuration de l'étape de transformation, consultez Create an XML Bridge ou XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

L'étape d'enrichissement posttransformation est identique à l'étape d'enrichissement avant transformation. La seule différence réside dans le fait qu'à l'étape d'enrichissement posttransformation, vous pouvez enrichir le message transformé. La manière dont vous configurez l'étape d'enrichissement est similaire au cours de ces deux étapes. Pour obtenir des instructions sur la configuration de l'étape d'enrichissement posttransformation, consultez Create an XML Bridge ou XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

noteRemarque
Toutes les propriétés extraites ou recherchées avant les étapes de transformation sont également disponibles sur le message transformé. Une propriété préalablement extraite ou enrichie sera remplacée si vous la modifiez au cours de l'étape d'enrichissement posttransformation.

Dans la section précédente, vous avez découvert qu'au cours de l'étape de validation, la validation se produisait dans des schémas et que dans l'étape de transformation, le message était transformé à l'aide d'une transformation. Par conséquent, les artefacts disponibles pour un Pont XML sont :

  • Schémas : avec l'extension .XSD.

  • Transformations : avec l'extension .TRFM, il peut y avoir plusieurs transformations au cours d'une étape de transformation.

  • Assemblys : ils incluent la logique de traitement personnalisé qui peut être incorporée à plusieurs étapes du pont.

  • Certificats : ils permettent de sécuriser le transfert des messages.

noteRemarque
Un fichier de configuration de pont n'est pas un artefact, car il ne peut pas être partagé entre plusieurs ponts. Un fichier de configuration de pont est spécifique à un pont.

L'application de service BizTalk peut avoir plusieurs ponts et chaque pont peut utiliser plusieurs transformations et schémas. Par conséquent, vous en déduisez qu'une application BizTalk Services classique peut avoir un grand nombre de transformations et de schémas. En même temps, chaque transformation et chaque schéma n'est pas forcément requis pour chaque Pont XML. Aussi, vous devez mettre en place une méthode permettant d'associer les transformations et les schémas au pont. Vous pouvez réaliser cette association lors de la configuration du pont.

Pour associer des schémas et des transformations, consultez Création d'un pont unidirectionnel XML ou Création de pont demande-réponse XML.

Un pont intermédiaire est utilisé lorsque vous souhaitez que tout type de message soit traité par le pont. Par conséquent, un pont intermédiaire n'inclut pas d'étape de validation ou de transformation, car ces deux étapes sont liées aux types de messages. Un pont intermédiaire inclut uniquement l'étape d'enrichissement, qui est utilisée aux mêmes fins que dans un Pont XML. Pour plus d'informations sur la configuration d'un pont intermédiaire, consultez Créer un pont intermédiaire.

Voir aussi

Afficher: