Muster für Nachrichtenrouting

Nachrichtenroutingmuster definieren bewährte Richtlinien für das Weiterleiten einer Nachricht an ihre Zielendpunkte. Routing kann das Ergebnis einer statischen Konfiguration sein, oder es kann dynamisch basierend auf einer Reihe von Kriterien und mithilfe einer Reihe von Methoden konfiguriert werden.

Nachrichtenrouter

Das Nachrichtenroutermuster bestimmt den Empfänger der Nachricht basierend auf einer Reihe von Bedingungen. Eine ausführliche Beschreibung dieses Musters finden Sie unter Nachrichtenrouter (https://go.microsoft.com/fwlink/?LinkId=186844) auf der Enterprise Integration Patterns-Website.

Die Implementierung dieses Musters im Designer "Itinerary" ist eine Kombination aus dem Routenroutingdienst des Microsoft BizTalk ESB Toolkit und einem einzelnen inhaltsbasierten Resolver. Der Routenroutingdienst ist für das Höherstufen von Nachrichtenroutingeigenschaften im Microsoft BizTalk-Nachrichtenkontext oder für das explizite Routing einer Nachricht zuständig.

Sie können den Routenroutingdienst des Microsoft BizTalk ESB-Toolkits wie folgt auswählen:

  • Definieren Sie den Routingdienst für die Reiseroute mit einem Messaging-Extender, der in einer BizTalk-Pipeline ausgeführt werden soll, indem Sie Designer.

  • Definieren Sie den Routenroutingdienst mit einem Orchestrierungs-Extender, der als Orchestrierung ausgeführt werden soll, mithilfe von Itinerary Designer, der das Routing mithilfe von BizTalk-Sendeports ausführt.

    Der Resolver, der dem Routenroutingdienst zugeordnet ist, bestimmt den Empfänger der Nachricht basierend auf dem Nachrichteninhalt. Sie können aus den Resolvern wählen, die inhaltsbasiertes Routing unterstützen, das vom Microsoft BizTalk ESB Toolkit bereitgestellt wird, oder Sie können Einen eigenen Resolver implementieren.

    Ein Beispiel für die Implementierung dieses Musters im Microsoft BizTalk ESB Toolkit finden Sie in den folgenden Ressourcen:

  • Vorgehensweise: Auflösen eines Dienstendpunkts mithilfe einer UDDI-Bindungsschlüsselsuche

  • Vorgehensweise: Auflösen eines Dienstendpunkts mithilfe einer UDDI-Kategoriensuche

Inhaltsbasierter Router

Das Inhaltsbasierte Routermuster bestimmt den Empfänger einer Nachricht basierend auf dem Nachrichteninhalt. Eine ausführliche Beschreibung dieses Musters finden Sie unter Inhaltsbasierter Router (https://go.microsoft.com/fwlink/?LinkId=186839) auf der Enterprise Integration Patterns-Website.

Die Implementierung dieses Musters in Itinerary Designer ist eine Kombination aus dem Routenroutingdienst des Microsoft BizTalk ESB Toolkit und einem einzelnen inhaltsbasierten Resolver. Der Routenroutingdienst ist für das Höherstufen von Nachrichtenroutingeigenschaften im BizTalk-Nachrichtenkontext oder für das explizite Weiterleiten einer Nachricht verantwortlich.

Sie können den Routenroutingdienst des Microsoft BizTalk ESB-Toolkits wie folgt auswählen:

  • Definieren Sie einen Routenroutingdienst mit einem Messaging-Extender, der in einer BizTalk-Pipeline ausgeführt werden soll, indem Sie Designer .

  • Definieren Sie einen Routenroutingdienst mit einem Orchestrierungs-Extender, der als Orchestrierung ausgeführt werden soll, mithilfe von Itinerary Designer, der das Routing mithilfe von BizTalk-Sendeports ausführt.

  • Definieren Sie einen Reiseplanbrokerdienst mit einem Broker-Messaging-Extender, der in einer BizTalk-Pipeline ausgeführt werden soll, mithilfe von Itinerary Designer.

    Der Konfliktlöser, der dem Routenroutingdienst zugeordnet ist, bestimmt den Empfänger der Nachricht basierend auf dem Nachrichteninhalt. Sie können aus den folgenden Resolvern wählen, die inhaltsbasiertes Routing unterstützen, das vom Microsoft BizTalk ESB Toolkit bereitgestellt wird:

  • XPATH-Resolver. Mithilfe dieses Resolvers können Sie Nachrichteninhalte mithilfe von XPATH-Abfragen weiterleiten.

  • BRE-Resolver. Mithilfe dieses Resolvers können Sie Routinginformationen aus Nachrichteninhalten mithilfe der BizTalk-Regel-Engine abrufen.

  • Konfliktlöser für den Nachrichtenkontext. Mit diesem Resolver können Sie den Inhalt einer Nachricht aus dem BizTalk-Nachrichtenkontext abrufen, wenn sie einem Microsoft BizTalk ESB Toolkit-Reiseplanbrokerdienst zugeordnet ist.

    Hinweis

    Zusätzlich zu den vorherigen Implementierungsszenarien können Sie eine benutzerdefinierte lösungsbasierte Lösung für die Inhalts- und Routenroutinglösung als messagingbasierten oder orchestrierungsbasierten Dienst entwickeln. In diesem Fall müssen Sie möglicherweise Extender für den Microsoft BizTalk ESB-Toolkit-Resolver und den Routenplanungsdienst implementieren, um mit dem Designer "Itinerary" zusammen arbeiten zu können.

    Ein Beispiel für diese Implementierung finden Sie in den folgenden Ressourcen:

  • Installieren und Ausführen des Beispiels „Programmablaufbasierte Eingangscontainer“

  • Vorgehensweise: Implementieren von inhaltsbasiertem Routing mithilfe einer Geschäftsregelrichtlinie für einen bekannten Nachrichtentyp

  • Vorgehensweise: dynamisches Routing einer auf einem Nachrichtenkontext basierenden Nachricht mithilfe einer Geschäftsregelrichtlinie

Verteiler

Das Routing slip-Muster beschreibt ein Szenario, in dem eine Nachricht in einer vordefinierten Reihenfolge durch eine Reihe von Komponenten geleitet werden muss, die zur Entwurfszeit möglicherweise nicht bekannt sind. Eine ausführliche Beschreibung dieses Musters finden Sie unter Routing Slip (https://go.microsoft.com/fwlink/?LinkId=186840) auf der Enterprise Integration Patterns-Website.

Die Implementierung dieses Musters wird vom Microsoft BizTalk ESB Toolkit bereitgestellt. Die Implementierung hängt vom Typ der Clientanwendung ab, die eine Nachricht für die programmablaufbasierte Verarbeitung sendet:

  • Dienstproxy. Konfigurieren Sie bei dieser Art von Anwendung das Microsoft BizTalk ESB Toolkit on-ramp mit der Pipelinekomponente Itinerary Selector, und ordnen Sie einen Routenkonfliktlöser zu, um die entsprechende Microsoft BizTalk ESB Toolkit-Reiseroute auszuwählen. Die Reiserouteneigenschaften können mithilfe des ITINERARY-Resolvers als statische Eigenschaften konfiguriert werden, oder sie können als dynamische Eigenschaften mithilfe der BizTalk-Regel-Engine und des BRI-Resolvers konfiguriert werden.

  • Erweiterter Client. Konfigurieren Sie bei dieser Art von Anwendung das Microsoft BizTalk ESB Toolkit on-ramp mit der Pipelinekomponente Itinerary Selector und dem Resolver ITINERARY-STATIC. Die Clientanwendung sendet eine Nachricht mit einem Referenzheader für die Reiseroute, der den Namen, die Version und den Nachverfolgungsbezeichner enthält.

  • Adaptiver Client. Bei diesem Anwendungstyp ruft die Clientanwendung den Resolverdienst auf, der wiederum den Verweis auf die Reiseroute identifiziert, indem der Clientstatus als Anforderungsmeldung übergeben wird. Wenn die Reiseroute aufgelöst wird, sendet die Clientanwendung eine Nachricht mit Routenreferenzen auf die gleiche Weise wie im vorherigen erweiterten Clientszenario.

    Weitere Informationen zum Implementieren dieses Musters finden Sie in den folgenden Ressourcen:

  • Vorgehensweise: Auswählen eines Programmablaufs mithilfe einer Geschäftsregelrichtlinie

  • Vorgehensweise: Transformieren einer Nachricht und Routing der resultierenden Nachricht an einen Dateispeicherort mithilfe eines programmablaufbasierten Verteilers

    Hinweis

    Zusätzlich zu den vorherigen Szenarien können Sie einen benutzerdefinierten Routenkonfliktlöser und Routenroutingdienste entwickeln. Sie können die Erstellung von Designer-Extendern für benutzerdefinierte Reiseplandienste zur Verwendung im Designer "Itinerary" in Betracht ziehen.

Scatter-Gather

Das Scatter-Gather-Muster ermöglicht es, Nachrichten an mehrere Empfänger zu senden und deren Antworten zu aggregieren. Dies führt zu einer einzelnen Nachricht. Eine ausführliche Beschreibung dieses Musters finden Sie unter Scatter-Gather (https://go.microsoft.com/fwlink/?LinkId=186841) auf der Enterprise Integration Patterns-Website.

Ein Beispiel für die Implementierung dieses Musters finden Sie im Beispiel zum Installieren und Ausführen des Scatter-Gather Beispiels .

Empfängerliste

Das Empfängerlistenmuster adressiert die Szenariolösung, in der eine Nachricht an einen oder mehrere Empfänger weitergeleitet wird. Die Empfängerliste kann entweder statisch (d. h. eine feste Empfängerliste) oder dynamisch definiert werden. Eine ausführliche Beschreibung dieses Musters finden Sie unter Empfängerliste (https://go.microsoft.com/fwlink/?LinkId=186842) auf der Enterprise Integration Patterns-Website.

Die Implementierung dieses Musters in Itinerary Designer ist eine Kombination aus dem Routenroutingdienst des Microsoft BizTalk ESB Toolkit und mehreren Resolvern. Der Routenroutingdienst ist für das Klonen einer Nachricht und dann für die verwendung der Eigenschaften des BizTalk-Nachrichtenkontexts verantwortlich, um eine Nachricht explizit weiterzuleiten.

Sie können den Routenroutingdienst des Microsoft BizTalk ESB-Toolkits wie folgt auswählen:

  • Definieren Sie den Routingdienst für die Reiseroute mit einem Messaging-Extender, der in der BizTalk-Pipeline ausgeführt werden soll, indem Sie Designer .

  • Definieren Sie den Routenroutingdienst mit einem Messaging-Extender, der als Orchestrierung ausgeführt werden soll, mithilfe von Itinerary Designer, die das Routing mithilfe von BizTalk-Sendeports ausführt.

    Der Konfliktlöser, der dem Routenroutingdienst zugeordnet ist, bestimmt den Empfänger der Nachricht basierend auf dem Nachrichteninhalt. Sie können die Vom Microsoft BizTalk ESB Toolkit bereitgestellte Gruppe von Resolvern auswählen, um dieses Szenario zu implementieren. Weitere Informationen zum Implementieren dieses Musters finden Sie in der folgenden Ressource:

  • Vorgehensweise: Routing einer einzelnen Nachricht an mehrere Empfänger mithilfe eines programmablaufbasierten Verteilers

Aufteilung

Das Splittermuster behebt das Problem, wenn eine einzelne Nachricht in mehrere Nachrichten aufgeteilt werden muss. Eine ausführliche Beschreibung dieses Musters finden Sie unter Splitter (https://go.microsoft.com/fwlink/?LinkId=186843) auf der Enterprise Integration Patterns-Website. Weitere Informationen zum Implementieren dieses Musters finden Sie in der folgenden Ressource: