Condividi tramite

Funzionamento del campione non sequenziale

  • Articolo

L'applicazione di esempio compila un set di intestazioni SOAP contenenti l'itinerario caricato dal file di itinerario Scatter-Gather, carica il file di messaggio specificato dal disco, aggiunge le intestazioni di itinerario al messaggio e lo invia a ESB tramite una rampa per l'elaborazione. Se l'itinerario genera una risposta, l'applicazione raccoglie questa operazione e la visualizza nella finestra dell'applicazione.

Per informazioni su come il servizio Itinerario usa le informazioni sull'itinerario in un messaggio, l'elenco seguente mostra il file di configurazione dell'itinerario di esempio denominato ScatterGatherItinerary.xml. La prima sezione di questo itinerario specifica due passaggi di chiamata al servizio.

<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>  
...

Seguendo l'elenco dei passaggi di chiamata del servizio nell'itinerario è la sezione contenente i dettagli dei resolver e delle stringhe di connessione che consentono al servizio Itinerario di individuare ogni servizio definito nell'itinerario, come illustrato nel codice XML seguente.

<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>

In questo esempio l'applicazione esegue il servizio Web SubmitPOService due volte perché entrambe le stringhe di connessione del resolver vengono risolte nella posizione di questo servizio (http://localhost/ESB.CanadianServices/SubmitPOService.asmx). Il contesto del messaggio specifica l'orchestrazione broker come primo servizio di itinerario da attivare, definito nell'esempio come indicato di seguito.

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

L'orchestrazione broker analizza le impostazioni per il passaggio dell'itinerario e recupera una raccolta di resolver associati al passaggio di itinerario. Per ognuno di questi resolver, l'orchestrazione usa Microsoft BizTalk ESB Toolkit Resolver e Adapter Framework per risolvere l'endpoint del servizio. L'orchestrazione broker attiva quindi n numero di orchestrazioni ServiceDispatcher in modo asincrono (dove n è il numero di resolver associati al servizio ScatterGather nell'itinerario) per inviare il messaggio di richiesta con i parametri seguenti:

  • TransportLocation. Il resolver popola questo parametro.

  • TransportType. Il resolver popola questo parametro.

  • ResolverDictionary. Questo parametro contiene una raccolta di fatti del resolver popolati dall'istanza del resolver concreto.

  • InboundMessage. Questo parametro contiene il messaggio originale contenente l'itinerario.

  • ServiceResponsePort. Questo parametro è il nome della porta di risposta self-cor correlate che riceverà risposte dalle istanze dell'orchestrazione serviceDispatcher.

    Ogni istanza dell'orchestrazione ServiceDispatcher usa i criteri ResolveMapScatterGather per risolvere i tipi di mappa Microsoft BizTalk per il messaggio di richiesta e risposta, in base alle proprietà TransportType e TransportLocation . Le istanze di orchestrazione usano le mappe risolte per trasformare il messaggio in ingresso nel messaggio di richiesta per la chiamata al servizio Web.

    Gestione adapter ESB imposta le proprietà del contesto di trasporto in uscita nel messaggio di richiesta, che BizTalk inoltra quindi alla porta di richiesta denominata ServiceRequestPort.

    Quando riceve un messaggio di risposta da un servizio, l'orchestrazione serviceDispatcher usa le informazioni sulla mappa risolte per trasformare il messaggio di risposta in ingresso in un formato canonico. Esegue quindi il wrapping della risposta modificata all'interno della busta ServiceResponse e lo inoltra all'orchestrazione broker tramite la porta auto-correlazione. L'orchestrazione broker aggrega tutte le risposte in ingresso e prepara il messaggio di risposta finale usando GlobalBank.ESB.ScatterGather.Processes.AggregatingPipeline, come illustrato nel codice seguente.

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

Questo codice esegue il wrapping dell'intero batch di risposte all'interno di una busta predefinita. L'orchestrazione broker avanza quindi l'itinerario al passaggio di itinerario DynamicTest , come illustrato nel codice seguente.

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

Poiché l'attributo del tipo di servizio denominato DynamicTest è impostato su Messaging, la classe RouteyHelper promuove le proprietà del resolver nel contesto del messaggio denominato OutboundMessage. L'orchestrazione broker invia questo messaggio a una porta con associazione diretta BizTalk. BizTalk inoltra quindi il messaggio alla porta di trasmissione dinamica rappresentata dalla sottoscrizione ServiceName , ovvero DynamicTest. Questa porta di invio serializza la risposta aggregata finale alla cartella \Source\Samples\DynamicResolution\Test\Filedrop\Out.