Wie kann ich einen Transformationsdienst mit BRE auflösen, der nach einer Orchestrierung in einer Reiseroute auftritt?

Question

Bei dem Versuch, eine einfache Integration zu implementieren Muster Mit BizTalk ESB Toolkit 2.0 habe ich ein Problem, mit dem ich versuche, einen Transformationsrouten -Service zu lösen, der nach einer Orchestrierung auftritt.

Ich verwende den BRE -Resolver, um Regeln auszuführen, die die Eigenschaft des Kontextnachrichten -Typs untersuchen müssen, um die zu verwendende Karte zu bestimmen. Sobald die Nachricht jedoch den Schritt in der mit dem Transformationsdienst zugeordneten Reiseroute erreicht hat, kann die Karte nicht ausgeführt werden.

Aus sorgfältiger Untersuchung scheint der Nachrichtentyp nicht an das "Auflösungsobjekt" geliefert zu werden, das intern vom BRE -Resolver verwendet wird. In der Tat, da die Nachricht, die vorhergehende Orchestrierung hinterlässt, tippt System.Xml.XmlDocument, Die Art der Nachricht wird aus dem Kontext "herabgestuft".

Durch die Verfolgung von Regeln der Engine -Ausführung kann ich feststellen, dass die Art der Nachricht tatsächlich ist verirrt beim Erreichen des Bre -Resolvers. Die Art der Nachricht ist leer, während das stark typische des Dokuments ist Microsoft.XLANGs.BaseTypes.Any.

Der Orchestrierungsdienst, den ich verwende, stammt direkt aus den Proben, die mit ESB Toolkit 2.0 versandt werden.

Gibt es eine Möglichkeit, eine kontextbasierte BRE-Auflösung durchzuführen? nach Eine Orchestrierung in einer Reiseroute?

Answer 1

Beantwortung meiner eigenen Frage ... Kurz gesagt, der Schlüssel besteht darin, den Kontext der ursprünglichen Nachricht zu fördern und die Messagetype -Kontexteigenschaft zu fördern. In den folgenden Absätzen reproduziere ich einen bevorstehenden Beitrag über mein Blog:

Orchestrierungs -Reiseroute -Service 101

Nachdem ich gekämpft hatte, diese Arbeit zu machen und verschiedene Lösungen auszuprobieren, gelang es mir schließlich, dass ich eine Reihe einfacher Regeln befolgt hatte. In diesem Beitrag möchte ich skizzieren, was eine gut erzogene ESB-Toolkit 2.0-freundliche Orchestrierung ausmacht, die als Reiseroutenservice verwendet werden kann und die Business Rules Engine Resolver für dynamische Transformationen basierend auf dem Kontext-Typ einer Nachricht nutzen kann .

Kontextabonnement für einen Reiseroutendienst

Zunächst muss eine Orchestrierung, die als Reiseroutenservice verwendet werden soll, über einen logischen Direktanschluss verfügt, der mit einer Empfangsform verknüpft ist, die ein ESB-freundlicher Abonnement wie SO definiert:

Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == "MyCustomItineraryService" And
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState == "Pending" And
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType == "Orchestration"

In der Dokumentation wird dies nicht erwähnt, aber dies macht deutlich, dass die direkt gebundenen Portoperationen auf Nachrichten vom Typ System.xml.xmldocument zugeordnet werden müssen. In der Tat, wenn dies nicht der Fall ist, wird die Orchestrierung nicht ausgeführt und a Routing -Fehler Die Fehlermeldung wird an die registriert Nachrichtenbox.

Übrigens bedeutet dies, dass das sehr Art einer Nachricht Geben Sie überhaupt keine Rechnung ein. Und dies erklärt weitgehend, warum der Business Rules Engine Resolver nach Ausführung der Orchestrierung die korrekte Transformation nicht bestimmt.

An der Reiseroute kommen

Der folgende Code in einer Ausdrucksform zu Beginn der Orchestrierung hilft dem aktuellen Reiseroutenschritt:

// Retrieve the current itinerary step.
itinerary.Itinerary = Microsoft.Practices.ESB.Itinerary.ItineraryOMFactory.Create(InboundMessage);
itineraryStep.ItineraryStep = itinerary.Itinerary.GetItineraryStep(InboundMessage);

Erhalt des Kontextes der ursprünglichen Nachricht

Als nächstes muss der Kontext der ursprünglichen Nachricht (größtenteils) bei jedem Schritt der Orchestrierung (größtenteils) erhalten bleiben. Dies ist von besonderer Bedeutung, wenn in der Orchestrierung mehrere mittlere Konstruktformen aufgewendet werden, um das spezifische Szenario auszuführen.

OutboundMessage(*) = SourceMessage(*)

Beachten Sie, dass ich im obigen Satz "größtenteils" geschrieben habe. Wie wir in einer Minute sehen werden, muss die Art der resultierenden Nachricht am Ende der Orchestrierung im Kontext vorhanden sein. Höchstwahrscheinlich wird dies ein sein Anderer Typ als die ursprüngliche Inbound -Nachricht. Und seitdem die schreibgeschützte Beauftragte Bts.messagetype Eigentum ist nicht möglich, manchmal kann es ziemlich schwierig sein, es zu erreichen.

Möglicherweise müssen Sie eine benutzerdefinierte Pipeline in der Orchestrierung oder anderen exotischen Techniken ausführen, damit dies der Fall ist. In den meisten Fällen sollte die oben gezeigte Syntax jedoch funktionieren.

Förderung der Reiseroute

Der folgende sehr einfache Code darf am Ende der Orchestrierung nicht vergessen werden:

itinerary.Itinerary.Advance(OutboundMessage, itineraryStep.ItineraryStep);

Förderung von Kontexteigenschaften

Das Dokumentation Verschreibt nicht ganz klar, welche genauen Schritte befolgt werden müssen, oder selbst wenn Eigenschaften aus einer solchen Orchestrierung gefördert werden müssen. Wenn man jedoch die als Quellcode bereitgestellten Stichproben betrachtet, kann man feststellen, dass die folgenden Eigenschaften am Auflösungsmechanismus teilnehmen:

Promoting Properties http://public.blu.livefilestore.com/y1pLURN1zH2vdRuLcF5yyAiHZQQ9rkdlrqG-QH01Nn8hEY5zH1W9TjjtNc0Z9421eFC2gUVG-srs2-NdcliI3XD1w/orchestration_service_promoting_properties.png?psid=1

In dem in diesem Beitrag beschriebenen Szenario reicht dies jedoch definitiv nicht aus.

Damit kontextbasierte Regeln nach der Orchestrierung arbeiten können, müssen auch die Eigenschaft BTS.Messagetype gefördert werden. Dies kann leicht erreicht werden, indem eine Korrelation der Send -Form am Ende der Orchestrierung initialisiert wird.

Nachrichtentyp Korrelation

Und es funktioniert!

Die Förderung des Nachrichtentyps im Kontext der resultierenden Nachricht fehlte in meinem ursprünglichen Versuch. Sobald dies identifiziert wurde, funktionierte die Reiseroute wie ein Zauber!

Regel Feuerprotokoll

Obwohl die Lösung nach der Tatsache offensichtlich erscheint, hätte es mir sicher geholfen, wenn ich das früher gewusst hätte. Ich hoffe, dieser Beitrag hilft denjenigen, die das gleiche Problem treffen.