Partager via

Fonctionnement de l’exemple de ventilation-regroupement

  • Article

L’exemple d’application génère un ensemble d’en-têtes SOAP contenant l’itinéraire chargé à partir du fichier d’itinéraire Scatter-Gather, 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 via une rampe d’accès pour traitement. Si l’itinéraire génère une réponse, l’application la collecte et l’affiche dans la fenêtre de l’application.

Pour vous aider à comprendre comment le service Itinéraire utilise les informations d’itinéraire dans un message, la liste suivante montre l’exemple de fichier de configuration d’itinéraire nommé ScatterGatherItinerary.xml. La première section de cet itinéraire spécifie deux é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"   
    xmlns="http://schemas.microsoft.biztalk.practices.esb.com/itinerary">  
  <ServiceInstance uuid="" name="ScatterGather" type="Orchestration"  
                   state="Pending" position="0"   
                   isRequestResponse="false" xmlns="" />  
  <Services xmlns="">  
    <Service uuid="" beginTime="" completeTime="" name="ScatterGather"  
             type="Orchestration" state="Pending" isRequestResponse="false"  
             position="0" serviceInstanceId="" />  
  </Services>  
  <Services xmlns="">  
    <Service uuid="" beginTime="" completeTime="" name="DynamicTest"  
             type="Messaging" state="Pending" isRequestResponse="false"  
             position="1" serviceInstanceId="" />  
  </Services>  
</Itinerary>  
...

Vous trouverez ci-après la liste des étapes d’appel de service de l’itinéraire la section contenant les détails des programmes de résolution et des chaînes de connexion qui permettent au service d’itinéraire de localiser chaque service défini dans l’itinéraire, comme illustré dans le code XML suivant.

<ResolverGroups xmlns="">  
 <Resolvers serviceId="ScatterGather0"><![CDATA[BRE:\\policy=ResolveEndPointScatterGather;version=;useMsg=;]]><![CDATA[UDDI3:\\serverUrl=http://localhost/uddi;bindingKey=uddi:esb:purchaseordersubmitorderservicebinding;credentialType=Ntlm]]></Resolvers>  
<Resolvers serviceId="DynamicTest1"><![CDATA[UDDI3:\\serverUrl=http://localhost/uddi;bindingKey=uddi:esb:orderfileservicebinding;credentialType=Ntlm]]>  
</Resolvers>  
  </ResolverGroups>

Dans cet exemple, l’application exécute le service Web SubmitPOService deux fois, car les chaînes de connexion du programme de résolution sont résolues à l’emplacement de ce service (http://localhost/ESB.CanadianServices/SubmitPOService.asmx). Le contexte de message spécifie l’orchestration Broker comme premier service d’itinéraire à activer, défini dans l’exemple comme suit.

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

L’orchestration Broker analyse les paramètres de son étape d’itinéraire et récupère une collection de résolveurs associés à l’étape d’itinéraire. Pour chacun de ces résolveurs, l’orchestration utilise microsoft BizTalk ESB Toolkit Resolver et Adapter Framework pour résoudre le point de terminaison de service. L’orchestration Broker active ensuite n nombre d’orchestrations ServiceDispatcher de manière asynchrone (où n est le nombre de résolveurs associés au service ScatterGather dans l’itinéraire) pour distribuer le message de demande avec les paramètres suivants :

  • TransportLocation. Le programme de résolution remplit ce paramètre.

  • TransportType. Le programme de résolution remplit ce paramètre.

  • ResolverDictionary. Ce paramètre contient une collection de faits de résolution renseignés par le instance de résolution concret.

  • InboundMessage. Ce paramètre contient le message d’origine qui contient l’itinéraire.

  • ServiceResponsePort. Ce paramètre est le nom du port de réponse auto-corrélatant qui recevra les réponses des instances de l’orchestration ServiceDispatcher.

    Chaque instance de l’orchestration ServiceDispatcher utilise la stratégie ResolveMapScatterGather pour résoudre les types de carte Microsoft BizTalk pour la demande et le message de réponse, en fonction des propriétés TransportType et TransportLocation. Les instances d’orchestration utilisent les mappages résolus pour transformer le message entrant en message de demande pour l’appel de service web.

    Le gestionnaire d’adaptateurs ESB définit les propriétés du contexte de transport sortant sur le message de demande, que BizTalk transfère ensuite vers le port de sollicitation-réponse nommé ServiceRequestPort.

    Lorsqu’elle reçoit un message de réponse d’un service, l’orchestration ServiceDispatcher utilise les informations de carte résolues pour transformer le message de réponse entrant dans un format canonique. Il encapsule ensuite la réponse modifiée dans l’enveloppe ServiceResponse et la transfère à l’orchestration Broker via le port de corrélation automatique. L’orchestration Broker agrège toutes les réponses entrantes et prépare le message de réponse final à l’aide de GlobalBank.ESB.ScatterGather.Processes.AggregatingPipeline, comme indiqué dans le code suivant.

AggregatedResponse.Body = null;  
AggregatedResponse(*) = InboundMessage(*);  
Microsoft.XLANGs.Pipeline.XLANGPipelineManager.ExecuteSendPipeline(  
    typeof(GlobalBank.ESB.ScatterGather.Processes.AggregatingPipeline),  
    messageAggregator,AggregatedResponse);

Ce code encapsule l’ensemble du lot de réponses dans une enveloppe prédéfinie. L’orchestration Broker avance ensuite l’itinéraire à l’étape d’itinéraire DynamicTest , comme indiqué dans le code suivant.

// Copy the context and advance the itinerary.  
OutboundMessage = AggregatedResponse.Body;  
OutboundMessage(*) = AggregatedResponse(*);  
// Advance the Itinerary to the next step.  
itinerary.Itinerary.Advance(OutboundMessage, itineraryStep);

Étant donné que l’attribut de type de service nommé DynamicTest est défini sur Messaging, la classe ItineraryHelper promeut les propriétés du programme de résolution dans le contexte du message nommé OutboundMessage. L’orchestration Broker envoie ce message à un port à liaison directe BizTalk. BizTalk transfère ensuite le message au port d’envoi dynamique représenté par l’abonnement ServiceName , qui est DynamicTest. Ce port d’envoi sérialise la réponse agrégée finale dans le dossier \Source\Samples\DynamicResolution\Test\Filedrop\Out.