Fonctionnement de l’exemple de chemin d’entrée d’itinéraire

Article
10/14/2023

L’exemple d’application cliente de test D’itinéraire génère un ensemble d’en-têtes SOAP qui contiennent l’itinéraire que vous créez à l’aide des contrôles de la fenêtre de l’application cliente, charge le fichier de message spécifié à partir du disque, ajoute les en-têtes d’itinéraire au message et le soumet à l’ESB par le biais d’une rampe d’accès d’itinéraire pour traitement. Si l’itinéraire génère une réponse, l’application collecte la réponse et l’affiche dans la fenêtre de l’application.

Vous pouvez choisir parmi plusieurs exemples de fichiers de configuration d’itinéraire pour voir les scénarios unidirectionnel et bidirectionnel qui utilisent des orchestrations, des messages ou une combinaison des deux.

Pour vous aider à comprendre comment le service Itinéraire utilise les informations d’itinéraire dans un message, le code XML suivant montre l’exemple de fichier de configuration d’itinéraire nommé TwoWay-OrchTransform-OrchRoutingGroup-OrchTwoWayCustom.xml utilisé dans l’exemple précédent. La première section de cet itinéraire spécifie trois étapes d’appel de service.

<Itinerary xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" uuid="" beginTime="" completeTime="" state="Pending" isRequestResponse="false" servicecount="0" xmlns="http://schemas.microsoft.biztalk.practices.esb.com/itinerary">  
  <BizTalkSegment interchangeId="" epmRRCorrelationToken="" receiveInstanceId="" messageId="" xmlns="" />  
  <ServiceInstance name="Microsoft.Practices.ESB.Services.Transform" type="Orchestration" state="Pending" position="0" isRequestResponse="false" xmlns="" />  
  <Services xmlns="">  
    <Service uuid="92d3b293-e6d4-44a1-b27d-c42b48aec667" beginTime="" completeTime="" name="Microsoft.Practices.ESB.Services.Transform" type="Orchestration" state="Pending" isRequestResponse="false" position="0" serviceInstanceId="" />  
  </Services>  
  <Services xmlns="">  
    <Service uuid="774488bc-e5b9-4a4e-9ae7-d25cdf23fd1c" beginTime="" completeTime="" name="Microsoft.Practices.ESB.Services.Routing" type="Orchestration" state="Pending" isRequestResponse="false" position="1" serviceInstanceId="" />  
  </Services>  
  <Services xmlns="">  
    <Service uuid="" beginTime="" completeTime="" name="ProcessAndRespond" type="Orchestration" state="Pending" isRequestResponse="true" position="2" serviceInstanceId="" />  
  </Services>  
  ...

Après la liste des étapes d’appel de service dans l’itinéraire se trouve la section contenant les détails des résolveurs (représentés par des chaînes de connexion) qui permettent au service d’itinéraire de localiser ou de fournir des informations de résolution pour chaque service défini dans l’itinéraire.

  ...  
<ResolverGroups xmlns="">  
    <Resolvers serviceId="Microsoft.Practices.ESB.Services.Transform0"><![CDATA[BRE:\\Policy=ResolveMap;Version=1.0;UseMsg=False;]]></Resolvers>  
    <Resolvers serviceId="Microsoft.Practices.ESB.Services.Routing1"><![CDATA[STATIC:\\TransportType=FILE;TransportLocation=C:\Projects\Microsoft.Practices.ESB\Source\Samples\DynamicResolution\Test\Filedrop\OUt\%MessageID%.xml;Action=;EndpointConfig=;JaxRpcResponse=False;MessageExchangePattern=;TargetNamespace=;TransformType=;]]><![CDATA[UDDI3:\\ServerUrl=http://localhost/uddi;SearchQualifiers=andAllKeys;CategorySearch=;BindingKey=uddi:esb:orderfileservicev3.1;]]></Resolvers>  
    <Resolvers serviceId="ProcessAndRespond2" />  
  </ResolverGroups>  
</Itinerary>

Notes

Le contenu réel de chaque <élément Resolvers ne contient pas les espaces blancs> utilisés pour encapsuler les lignes de la liste précédente.

Voici les trois étapes définies dans l’itinéraire précédent la configuration :

Exécutez l’orchestration Microsoft.Practices.ESB.Services.Transform pour transformer le message avec la stratégie ResolverMap à l’aide du moteur de règles d’entreprise BizTalk (BRE).
Exécutez l’orchestration Microsoft.Practices.ESB.Services.Routing pour acheminer le message transformé vers plusieurs emplacements à l’aide du routage Microsoft.Practices.ESB.Services.Routing1. La <section ResolverGroups> contient un <élément Resolvers> avec cet identificateur, qui définit les chaînes de connexion.
Exécutez l’orchestration ProcessAndRespond fournie avec cet exemple. L’implémentation de cette orchestration envoie comme réponse une copie du message de demande au client de test D’itinéraire.

À l’achèvement de chaque service, le service avance l’itinéraire et promeut le service suivant défini dans l’itinéraire comme étant le service actuel instance, avec son état défini sur En attente.

Notes

L’exemple Itinerary On-Ramp utilise la résolution dynamique pour envoyer des messages au dossier de sortie. C’est pourquoi aucun port d’envoi statique n’est défini pour cet exemple.

Voici la séquence d’événements qui se produisent après que l’application cliente de test a envoyé le message :

Le port de réception OnRamp.Itinerary reçoit le message.
Le pipeline ItineraryReceiveXml extrait l’itinéraire de l’en-tête SOAP, le valide et le pré-traite, écrit l’itinéraire en tant que propriété de contexte de message dans le message entrant et publie le message dans la base de données BizTalk Message Box.
Un abonnement pour l’orchestration du service Microsoft.Practices.ESB.Services.Transform déclenche l’appel de cette orchestration. L’orchestration récupère d’abord l’étape de l’itinéraire en cours en transmettant le message actuel en tant que paramètre, comme indiqué dans le code suivant.
```
itineraryStep =   itinerary.Itinerary.GetItineraryStep(InboundMessage);  
```
L’objet ItineraryStep contient toutes les informations sur le service actuel instance pour l’exécution, ainsi que tous les résolveurs qui lui sont associés.

L’objet Resolver est récupéré à partir du instance ItineraryStep et l’infrastructure de résolution ESB est utilisée pour résoudre le nom complet de la carte de transformation, comme indiqué dans le code suivant.

resolverDictionary =   
   Microsoft.Practices.ESB.Resolver.ResolverMgr.Resolve(InboundMessage,  
                                                        resolver);  

// Set the transform type.  
transformType = resolverDictionary.Item("Resolver.TransformType");

Le programme de résolution et l’infrastructure d’adaptateur microsoft BizTalk ESB Toolkit effectuent cette opération en chargeant le programme de résolution approprié à partir du cache (dans cet exemple, le programme de résolution du moteur de règles d’entreprise BizTalk), qui appelle la stratégie ResolverMap et remplit l’objet ResolverDictionary .

Une fois l’orchestration terminée, le code appelle la méthode AdvanceItinerary , comme indiqué dans le code suivant.

// Call the Itinerary helper to advance to the next step.  
itinerary.Itinerary.Advance(OutboundMessage, itineraryStep.ItineraryStep);

Cela fait avancer l’itinéraire actuel en mettant à jour ses propriétés et en promouvant le service suivant défini dans l’itinéraire comme celui à exécuter ensuite. La méthode copie l’itinéraire dans le message sortant, que le service publie de nouveau dans la base de données Message Box via un port d’envoi direct.

Un abonnement pour l’orchestration du service Microsoft.Practices.ESB.Services.Delivery déclenche l’appel de cette orchestration. Cette orchestration suit un processus similaire à la première, qui permet d’obtenir l’étape actuelle de l’itinéraire. Toutefois, cette orchestration itère via une collection de résolveurs retournés par le instance ItineraryStep. Pour chaque programme de résolution de la collection, l’orchestration de remise utilise microsoft BizTalk ESB Toolkit Resolver and Adapter Framework pour résoudre les emplacements de transport et les promouvoir en tant que propriétés de contexte dans le message sortant, comme illustré dans le code suivant.

// Move to retrieve the first resolver.  
resolver = resolvers.Current;  

// Pass the resolver configuration to the Resolver Manager   
// for resolution.  
resolverDictionary =  
   Microsoft.Practices.ESB.Resolver.ResolverMgr.Resolve(InboundMessage,  
                                                        resolver);  

// Set the transport properties.  
transportLocation =   
   resolverDictionary.Item("Resolver.TransportLocation");  
transportType =   
   resolverDictionary.Item("Resolver.TransportType");  

// Call the Adapter Manager to set all necessary properties.  
Microsoft.Practices.ESB.Adapter.AdapterMgr.SetEndpoint(  
                                resolverDictionary, DeliveryMessage);  

// Set the delivery port address and type.  
DeliveryPort(Microsoft.XLANGs.BaseTypes.Address) = transportLocation;  
DeliveryPort(Microsoft.XLANGs.BaseTypes.TransportType) = transportType;

Un abonnement pour l’orchestration ProcessAndRespond déclenche l’appel de cette orchestration en raison d’une correspondance des propriétés de contexte de message définies pour les propriétés d’expression de filtre.

(Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == :"ProcessAndRespond")   
&& Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState == "Pending")  
&& (Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType == "Orchestration")

L’orchestration ProcessAndRespond avance l’itinéraire et envoie le message de demande d’origine au service de la rampe à l’application client de test d’itinéraire en tant que réponse.

Partager via

Fonctionnement de l’exemple de chemin d’entrée d’itinéraire

Commentaires

Ressources supplémentaires