Funktionsweise des Beispiels „Programmablaufbasierte Eingangscontainer“

Artikel
07/21/2023

Die Beispielanwendung "Itinerary Test Client" erstellt eine Reihe von SOAP-Headern, die die Reiseroute enthalten, die Sie mithilfe der Steuerelemente im Clientanwendungsfenster erstellen, lädt die angegebene Nachrichtendatei vom Datenträger, fügt die Reiseverlaufsheader an die Nachricht an und übermittelt sie zur Verarbeitung an den ESB. Wenn die Reiseroute eine Antwort generiert, sammelt die Anwendung die Antwort und zeigt sie im Anwendungsfenster an.

Sie können aus mehreren Beispielkonfigurationsdateien für reiserouten auswählen, um unidirektionale und bidirektionale Szenarien anzuzeigen, die Orchestrierungen, Messaging oder eine Kombination aus beidem verwenden.

Damit Sie besser verstehen können, wie der Reiseplandienst die Reiseplaninformationen in einer Nachricht verwendet, zeigt der folgende XML-Code die Beispielkonfigurationsdatei für die Reiseroute namens TwoWay-OrchTransform-OrchRoutingGroup-OrchTwoWayCustom.xml, die im vorherigen Beispiel verwendet wurde. Im ersten Abschnitt dieser Reiseroute werden drei 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" 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>  
  ...

Nach der Liste der Dienstaufrufschritte in der Reiseroute finden Sie den Abschnitt, der Details zu den Resolvern (dargestellt durch Verbindungszeichenfolgen) enthält, die es dem Reiseplandienst ermöglichen, Auflösungsinformationen für jeden in der Reiseroute definierten Dienst zu finden oder bereitzustellen.

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

Hinweis

Der tatsächliche Inhalt jedes <Resolvers-Elements> enthält nicht die Leerzeichen, die zum Umschließen der Zeilen in der vorherigen Auflistung verwendet werden.

Im Folgenden sind die drei Schritte aufgeführt, die in der vorherigen Konfiguration der Reiseroute definiert sind:

Führen Sie die Microsoft.Practices.ESB.Services.Transform-Orchestrierung aus, um die Nachricht mit der ResolverMap-Richtlinie mithilfe der BizTalk Business Rules Engine (BRE) zu transformieren.
Führen Sie die Microsoft.Practices.ESB.Services.Routing-Orchestrierung aus, um die transformierte Nachricht mithilfe des Routings Microsoft.Practices.ESB.Services.Routing1 an mehrere Speicherorte weiterzuleiten. Der <Abschnitt ResolverGroups> enthält ein <Resolvers-Element> mit diesem Bezeichner, der die Verbindungszeichenfolgen definiert.
Führen Sie die in diesem Beispiel bereitgestellte ProcessAndRespond-Orchestrierung aus. Die Implementierung dieser Orchestrierung sendet als Antwort eine Kopie der Anforderungsnachricht zurück an den Programmablauftestclient.

Nach Abschluss jedes Diensts wird die Reiseroute durch den Dienst erweitert und der nächste Dienst, der in der Reiseroute definiert ist, zum aktuellen Dienst instance, wobei der Status auf Ausstehend festgelegt ist.

Hinweis

Im Beispiel "Itinerary On-Ramp" wird die dynamische Auflösung verwendet, um Nachrichten an den Ausgabeordner zu senden. Aus diesem Grund ist für dieses Beispiel kein statischer Sendeport definiert.

Im Folgenden finden Sie die Abfolge von Ereignissen, die auftreten, nachdem die Testclientanwendung die Nachricht gesendet hat:

Der OnRamp.Itinerary-Empfangsport empfängt die Nachricht.
Die ItineraryReceiveXml-Pipeline extrahiert die Reiseroute aus dem SOAP-Header, überprüft und verarbeitet sie vorab, schreibt die Reiseroute als Nachrichtenkontexteigenschaft in die eingehende Nachricht und veröffentlicht die Nachricht in der BizTalk Message Box-Datenbank.
Ein Abonnement für die Microsoft.Practices.ESB.Services.Transform-Dienstorchestrierung löst den Aufruf dieser Orchestrierung aus. Die Orchestrierung ruft zuerst den aktuellen Schritt der Reiseroute ab, indem die aktuelle Nachricht als Parameter übergeben wird, wie im folgenden Code gezeigt.
```
itineraryStep =   itinerary.Itinerary.GetItineraryStep(InboundMessage);  
```
Das ItineraryStep-Objekt enthält alle Informationen über den aktuellen Dienst instance für die Ausführung sowie alle damit verbundenen Resolver.

Das Resolver-Objekt wird aus der ItineraryStep-instance abgerufen, und das ESB Resolver Framework wird verwendet, um den vollständigen Namen der Transformationszuordnung aufzulösen, wie im folgenden Code gezeigt.

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

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

Das Microsoft BizTalk ESB Toolkit Resolver and Adapter Framework erreicht dies, indem der entsprechende Resolver aus dem Cache geladen wird (in diesem Beispiel der BizTalk Business Rules Engine-Resolver), der die ResolverMap-Richtlinie aufruft und das ResolverDictionary-Objekt auffüllt.

Nach Abschluss der Orchestrierung ruft der Code die AdvanceItinerary-Methode auf, wie im folgenden Code gezeigt.

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

Dadurch wird die aktuelle Reiseroute erweitert, indem die Eigenschaften aktualisiert und der nächste Dienst, der in der Reiseroute definiert ist, als nächstes ausgeführt wird. Die -Methode kopiert die Reiseroute in die ausgehende Nachricht, die der Dienst über einen direkt gebundenen Sendeport wieder in die Message Box-Datenbank veröffentlicht.

Ein Abonnement für die Microsoft.Practices.ESB.Services.Delivery-Dienstorchestrierung löst den Aufruf dieser Orchestrierung aus. Diese Orchestrierung folgt einem ähnlichen Prozess wie der erste, wobei der aktuelle Schritt der Reiseroute abgerufen wird. Diese Orchestrierung durchläuft jedoch eine Sammlung von Resolvern, die vom ItineraryStep-instance zurückgegeben werden. Für jeden Konfliktlöser in der Sammlung verwendet die Übermittlungsorchestrierung den Microsoft BizTalk ESB Toolkit Resolver und adapter Framework, um die Transportspeicherorte aufzulösen und sie als Kontexteigenschaften innerhalb der ausgehenden Nachricht heraufzustufen, wie im folgenden Code gezeigt.

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

Ein Abonnement für die ProcessAndRespond-Orchestrierung löst den Aufruf dieser Orchestrierung aufgrund einer Übereinstimmung der Nachrichtenkontexteigenschaften aus, die für die Eigenschaften des Filterausdrucks definiert sind.

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

Die ProcessAndRespond-Orchestrierung setzt die Reiseroute fort und sendet die ursprüngliche Anforderungsnachricht als Antwort zurück an den On-Ramp-Dienst an die Programmablauftestclientanwendung.

Freigeben über

Funktionsweise des Beispiels „Programmablaufbasierte Eingangscontainer“

Feedback

Zusätzliche Ressourcen