Freigeben über

Funktionsweise des Beispiels „Scatter-Gather“

  • Artikel

Die Beispielanwendung erstellt eine Reihe von SOAP-Headern, die die aus der Scatter-Gather-Reiseverlaufsdatei geladene Reiseroute enthalten, lädt die angegebene Nachrichtendatei vom Datenträger, fügt die Routingheader an die Nachricht an und übermittelt sie zur Verarbeitung an den ESB. Wenn die Reiseroute eine Antwort generiert, erfasst die Anwendung diese und zeigt sie im Anwendungsfenster an.

Damit Sie besser verstehen können, wie der Reiseplandienst die Informationen zur Reiseroute in einer Nachricht verwendet, zeigt die folgende Auflistung die Beispielkonfigurationsdatei für die Reiseroute namens ScatterGatherItinerary.xml. Im ersten Abschnitt dieser Reiseroute werden zwei Dienstaufrufschritte angegeben.

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

Im Anschluss an die Liste der Dienstaufrufschritte in der Reiseroute finden Sie den Abschnitt mit Details zu den Resolvern und Verbindungszeichenfolgen, die es dem Reiseplandienst ermöglichen, jeden in der Reiseroute definierten Dienst zu finden, wie in der folgenden XML gezeigt.

<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 diesem Beispiel führt die Anwendung den SubmitPOService-Webdienst zweimal aus, da beide Resolver-Verbindungszeichenfolgen an den Speicherort dieses Diensts aufgelöst werden (http://localhost/ESB.CanadianServices/SubmitPOService.asmx). Der Nachrichtenkontext gibt die Brokerorchestrierung als ersten zu aktivierenden Reiseplandienst an, der im Beispiel wie folgt definiert ist.

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

Die Brokerorchestrierung analysiert die Einstellungen für den zugehörigen Reiseroutenschritt und ruft eine Sammlung von Resolvern ab, die dem Reiseplanschritt zugeordnet sind. Für jeden dieser Resolver verwendet die Orchestrierung den Microsoft BizTalk ESB Toolkit Resolver und adapter Framework, um den Dienstendpunkt aufzulösen. Die Brokerorchestrierung aktiviert dann asynchron n Anzahl von ServiceDispatcher-Orchestrierungen (wobei n die Anzahl der Resolver ist, die dem ScatterGather-Dienst in der Reiseroute zugeordnet sind), um die Anforderungsnachricht mit den folgenden Parametern zu senden:

  • TransportLocation. Der Resolver füllt diesen Parameter auf.

  • TransportType. Der Resolver füllt diesen Parameter auf.

  • ResolverDictionary. Dieser Parameter enthält eine Auflistung von Resolver-Fakten, die vom konkreten Resolver instance aufgefüllt werden.

  • InboundMessage. Dieser Parameter enthält die ursprüngliche Nachricht, die die Reiseroute enthält.

  • ServiceResponsePort. Dieser Parameter ist der Name des sich selbst korrelierenden Antwortports, der Antworten von den Instanzen der ServiceDispatcher-Orchestrierung empfängt.

    Jeder instance der ServiceDispatcher-Orchestrierung verwendet die ResolveMapScatterGather-Richtlinie, um die Microsoft BizTalk-Zuordnungstypen für die Anforderungs- und Antwortnachricht basierend auf den Eigenschaften TransportType und TransportLocation aufzulösen. Die Orchestrierungsinstanzen verwenden die aufgelösten Zuordnungen, um die eingehende Nachricht in die Anforderungsnachricht für den Webdienstaufruf zu transformieren.

    Der ESB-Adapter-Manager legt die Eigenschaften des ausgehenden Transportkontexts für die Anforderungsnachricht fest, die BizTalk dann an den Solicit-Response-Port namens ServiceRequestPort weiterleitet.

    Wenn eine Antwortnachricht von einem Dienst empfangen wird, verwendet die ServiceDispatcher-Orchestrierung die aufgelösten Zuordnungsinformationen, um die eingehende Antwortnachricht in ein kanonisches Format zu transformieren. Anschließend wird die geänderte Antwort innerhalb des ServiceResponse-Umschlags umgebrochen und über den sich selbst korrelierenden Port an die Brokerorchestrierung weitergeleitet. Die Brokerorchestrierung aggregiert alle eingehenden Antworten und bereitet die endgültige Antwortnachricht mithilfe von GlobalBank.ESB.ScatterGather.Processes.AggregatingPipeline vor, wie im folgenden Code gezeigt.

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

Dieser Code umschließt den gesamten Batch von Antworten in einem vordefinierten Umschlag. Die Brokerorchestrierung führt dann die Reiseroute mit dem Schritt DynamicTest-Reiseroute fort, wie im folgenden Code gezeigt.

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

Da das Diensttyp-Attribut DynamicTest auf Messaging festgelegt ist, werden die Resolvereigenschaften von der ItineraryHelper-Klasse in den Kontext der Nachricht mit dem Namen OutboundMessage heraufgesetzt. Die Brokerorchestrierung sendet diese Nachricht an einen direkt gebundenen BizTalk-Port. BizTalk leitet die Nachricht dann an den dynamischen Sendeport weiter, der durch das ServiceName-Abonnement dargestellt wird, d. h. DynamicTest. Dieser Sendeport serialisiert die endgültige aggregierte Antwort an den Ordner \Source\Samples\DynamicResolution\Test\Filedrop\Out.