Weiterleitungs- und Antwortaktionen: Überbrücken von Protokollkonflikten

Letzte Aktualisierung: Juli 2015

Wenn der Absender und der Empfänger einer Nachricht unterschiedliche Nachrichtenprotokolle verwenden, kommt es zu einem Protokollkonflikt. In einem typischen BizTalk Services-Szenario mit Bridges sendet ein Nachrichtenabsender eine Nachricht an die Bridge. Die Bridge verarbeitet die Nachricht und sendet sie dann an den Nachrichtenempfänger. Dies bedeutet, dass der Protokollkonflikt zwei Mal überbrückt werden muss:

  • Zum einen beim Senden der Nachricht an den Nachrichtenempfänger. Dies gilt sowohl für unidirektionale XML-Bridges als auch für XML-Anforderung/Antwort-Bridges, da die Nachricht in beiden Fällen an einen Nachrichtenempfänger gesendet werden muss. Dies wird als Weiterleitungsaktion bezeichnet.

  • Zum anderen, wenn die vom Nachrichtenempfänger empfangene Antwortnachricht an den Nachrichtenabsender zurückgesendet wird. Dies gilt nur für XML-Anforderung/Antwort-Bridges, da nur für diese Bridges eine Antwort an den Nachrichtenabsender zurückgesendet werden muss. Dies wird als Antwortaktion bezeichnet.

Sowohl Weiterleitungs- als auch Antwortaktionen werden auf die Eigenschaften angewendet, die Sie in der Phase Enrich definieren.

Anhand eines Szenarios wollen wir uns ansehen, wie die Weiterleitungsaktion für einen Protokollkonflikt verwendet werden kann. Im Szenario muss eine POX (Plain Old XML)/REST-Nachricht über eine unidirektionale XML-Bridge an einen WCF-Dienst gesendet werden (der eine SOAP-Nachricht erwartet). Die an die Bridge gesendete Nachricht ist eine einfache XML-Nutzlast und hat keine Header. Andererseits müssen für die ausgehende Nachricht an den WCF-Dienst einige SOAP-Header definiert sein. Als Bridge für diesen Protokollkonflikt verwendet die Person, die die Bridge konfiguriert, die Weiterleitungsaktion, um der ausgehenden Nachrichten einige relevante SOAP-Nachrichtenheader zuzuweisen, wie z. B. "Action", "MessageID" usw. Nachdem die Bridge konfiguriert und für Servicebus bereitgestellt wurde, wird eine POX-Nachricht an die Bridge gesendet. Nach der Verarbeitung der Nachricht, aber vor der Weiterleitung der Nachricht an den WCF-Dienst, werden die in der Weiterleitungsaktion der Bridge angegebenen Header als Stempel zur Nachricht hinzugefügt und dann an den WCF-Dienst gesendet, wodurch der Protokollkonflikt überbrückt wird. Informationen zum Konfigurieren einer Weiterleitungsaktion finden Sie unter The Routing Action.

Die Liste in der folgenden Tabelle gibt an, wie Eigenschaftswerte mit Weiterleitungsaktionen zwischen Zwischenphasen (oder dem Ziel) eines BizTalk Service-Projekts übertragen werden können:

 

Von/An An andere Bridges An Warteschlangen und Themen An Relay- oder externe Dienstendpunkte

Von Bridge

Die Eigenschaften können nicht unverändert (als Schlüssel-Wert-Paare) übertragen werden, sondern indem sie als Werte von ausgehenden Nachrichtenheadern (HTTP oder SOAP) zugewiesen werden.

Die Eigenschaften können unverändert (als Schlüssel-Wert-Paare) und auch als Werte von ausgehenden Nachrichtenheadern übertragen werden.

Die Eigenschaften können nicht unverändert (als Schlüssel-Wert-Paare) übertragen werden, sondern indem sie als Werte von ausgehenden Nachrichtenheadern (HTTP oder SOAP) zugewiesen werden. Es ist jedoch die Aufgabe des Bridgedesigners, die Übergabe relevanter Header sicherzustellen, die vom Relay oder externen Endpunkt verbraucht werden können.

Die Antwortaktion ist der Weiterleitungsaktion sehr ähnlich. Der einzige Unterschied besteht darin, dass die Weiterleitungsaktion angewendet wird, wenn die Nachricht an den beabsichtigten Nachrichtenempfänger gesendet wird (entweder über eine unidirektionale XML-Bridge oder eine XML-Anforderung/Antwort-Bridge), während die Antwortaktion angewendet wird, wenn die Antwortnachricht eines Nachrichtenempfängers an den Nachrichtenabsender zurückgeleitet werden muss (nur im Fall einer XML-Anforderung/Antwort-Bridge.)

Zum besseren Verständnis können Sie einfach das zur Erläuterung der Weiterleitungsaktion verwendete Szenario umkehren. Der Nachrichtenabsender muss eine SOAP-Nachricht über eine XML-Anforderung/Antwort-Bridge an den REST-Dienst senden, der eine POX/REST-Nachricht erwartet. An die Bridge wird eine SOAP-Nachricht mit allen relevanten Headern gesendet. Vor der Weiterleitung der Nachricht an den REST-Dienst entfernt die Bridge implizit die Nachrichtenheader und sendet lediglich die XML-Nutzlast an den REST-Dienst. Die Antwort vom REST-Dienst ist ebenfalls eine POX-Nachricht. Bevor die POX-Antwortnachricht an den Nachrichtenabsender zurückgesendet wird, fügt die Antwortaktion der POX-Nachricht die Nachrichtenheader als Stempel hinzu und sendet dann die SOAP-Nachricht an den Nachrichtenabsender. Informationen zum Konfigurieren einer Antwortaktion finden Sie unter Create an XML Request-Reply Bridge.

Die Liste in der folgenden Tabelle gibt an, wie Eigenschaftswerte mit Antwortaktionen von einer Bridge zurück an den Client übertragen werden können, der die Nachricht gesendet hat:

 

Von/An An andere Bridges An Relay- oder externe Dienstendpunkte

Von Bridge

Die Eigenschaften können nicht unverändert (als Schlüssel-Wert-Paare) übertragen werden, sondern indem sie als Werte von ausgehenden Nachrichtenheadern (HTTP oder SOAP) zugewiesen werden.

Die Eigenschaften können nicht unverändert (als Schlüssel-Wert-Paare) übertragen werden, sondern indem sie als Werte von ausgehenden Nachrichtenheadern (HTTP oder SOAP) zugewiesen werden. Es ist jedoch die Aufgabe des Bridgedesigners, die Übergabe relevanter Header sicherzustellen, die vom Relay oder externen Endpunkt verbraucht werden können.

Sie können zwar Eigenschaften von Nachrichtenheadern mit Weiterleitungs- und Antwortaktionen festlegen, müssen dabei jedoch die folgenden Punkte berücksichtigen:

  • Die SOAP-Nachrichtenheader To und ReplyTo sind mit Vorsicht zu verwenden. Grund hierfür ist, dass die zugrunde liegende Bindung, wie z. B. eine WCF-Bindung, diese Nachrichtenheader überschreiben kann. Wenn also die Anwendung, die diese Nachrichten verbraucht, die mit den Weiterleitungs- oder Antwortaktionen festgelegten Nachrichtenheader erwartet, kann es zu unerwarteten Fehlern kommen.

  • Beim Weiterleiten einer Nachricht an Endpunkte, die basicHttpBinding oder basicHttpRelayBinding verwenden, darf der SOAP-Header MessageID nicht festgelegt werden.

Siehe auch

Anzeigen: