Verwendung und Phasen von Bridges

Letzte Aktualisierung: Juli 2015

BizTalk Services bietet zwei Arten von Bridges – Pass-Through-Bridge und XML-Bridge. Die XML-Bridges beziehen wiederum die unidirektionale XML-Bridge und die XML-Anforderung/Antwort-Bridge ein. In diesem Abschnitt sind Informationen zur Verwendung und zu den Phasen dieser Bridges enthalten.

Die XML-Bridge kann dazu verwendet werden, um bei Konflikten zwischen zwei oder mehr ungleichen Systemen, die über den Austausch von XML-Nachrichten kommunizieren, zu vermitteln und diese zu überbrücken. Die XML-Bridges bieten möglicherweise in Verbindung mit anderen Servicebus-Entitäten in einem Nachrichtenfluss eine Auswahl an Vermittlungsparadigmen und Szenarien wie die Folgenden:

  • Nachrichtenüberprüfung: Die XML-Bridge unterstützt die Überprüfung eingehender XML-Nachrichten anhand eines XSD-Schemas. Nachrichten, bei denen ein Überprüfungsfehler ausgegeben wird, werden abgelehnt.

  • Nachrichtenerweiterung und -extrahierung: Die XML-Bridge unterstützt die Nachrichtenerweiterung über die Datensuche in anderen Datenquellen. Dies ist in der Regel in Szenarien hilfreich, in denen es für Nachrichten möglicherweise erforderlich ist, dass Kontextdaten über die Nachrichtengrenzen hinaus verfügbar sind, normalerweise aus einem Konfigurationsspeicher, einem externen Dienst oder ähnlichem.

    Mithilfe der XML-Bridge können Sie auch Eigenschaften aus einer XML-Nachricht extrahieren, die möglicherweise für die Weiterleitung verwendet werden können. In einer Bestellauftragsnachricht kann z. B. das Element Quantity für die Menge markiert werden. Die Nachricht kann dann auf Basis des Werts für die bestellte Menge weitergeleitet werden.

  • Nachrichtentransformation: Die XML-Bridge unterstützt Nachrichtentexttransformationen aus einer XML-Struktur in eine andere. Diese Funktion einer XML-Bridge kann auch dazu verwendet werden, um eine Nachricht in Szenarien zu "normalisieren", in denen einer einzelnen Nachricht mehrere Nachrichten zugeordnet werden. Eine Bridge muss z. B. Bestellaufträge von verschiedenen Kunden in unterschiedlichen Schemas akzeptieren, die aber schließlich in ein einzelnes Bestellauftragsschema transformiert werden, das für die Organisation erforderlich ist.

  • Speicherortvirtualisierung: Die XML-Bridge bietet eine einfache Speicherortvirtualisierung von Back-End-Diensten. Die Clients senden Nachrichten an den in der Cloud bereitgestellten Endpunkt der XML-Bridge und nicht an den eigentlichen Dienst (der lokal verfügbar oder in der Cloud enthalten sein kann). Die Bridge leitet die Nachrichten dann auf Basis von Weiterleitungsregeln an den Back-End-Dienst weiter.

  • Benutzerdefinierte Verarbeitung: Die Bridges stellen die Optionen zum Einbeziehen von benutzerdefiniertem Code zur Integration von Verarbeitungstasks bereit, die nicht in der fertigen Bridgekonfiguration enthalten sind.

In diesem Abschnitt sind Informationen zu den verschiedenen Phasen einer XML-Bridge enthalten. Beachten Sie, dass die einzelnen Phasen optional sind und aktiviert oder deaktiviert werden können.

Die erste Phase in der XML-Bridge ist die Validate-Phase. In dieser Phase erfolgt die XSD-Überprüfung von XML-Nachrichten anhand angegebener Schemas. Die zur Überprüfung zu verwendenden Schemas werden während der Konfiguration der Bridge angegeben. Eine einzelne XML-Bridge kann XML-Nachrichten mit verschiedenen Schemas empfangen und verarbeiten. Während der Überprüfungsphase wird das entsprechende Thema in Abhängigkeit von der eingehenden Nachricht ausgewählt und für die Überprüfung verwendet. Nachdem die Nachricht anhand des Schemas überprüft wurde, wird die X_PIPELINE_MESSAGETYPE-Eigenschaft für die Nachricht von der Validate-Phase hochgestuft. Der Wert der Eigenschaft ist eine Kombination von Zielnamespace für das Schema und dem Stammknotennamen, z. B. http://IntegrationServices.Schema#RootNode. Wenn für die Nachricht ein Überprüfungsfehler ausgegeben wird, da kein übereinstimmendes oder ein nicht eindeutiges Schema (bzw. mehrere passende Schemas) gefunden wurden, wird eine Ausnahme ausgelöst.

Anweisungen zum Konfigurieren der Überprüfungsphase finden Sie unter Erstellen einer unidirektionalen XML-Brücke oder Erstellen einer Anforderungs-/Antwort-XML-Bridge.

In der Enrich-Phase können Sie eine Nachricht durch Erstellen von Eigenschaften erweitern, deren Werte vom eingehenden Nachrichtenheader, von einer vom System höher gestuften Eigenschaft, von einem Element oder Attribut im eingehenden Nachrichtentext oder über die Suche in einer externen Datenquelle abgeleitet werden, z. B. in Microsoft Azure SQL-Datenbanktabellen. Mit diesen Eigenschaften können die Nachrichten dann an Zielendpunkte und zur Protokollüberbrückung weitergeleitet werden.

 

Vorgang Beschreibung

Zuweisung von Headern zu Eigenschaften

Bei diesem Vorgang können Sie einen Wert aus dem Nachrichtenheader zu einer Eigenschaft zuweisen. Sie können z. B. die Aktion aus dem SOAP-Header extrahieren, sie einer Eigenschaft zuordnen und diese Eigenschaft dann zur weiteren Verarbeitung und/oder Weiterleitung verwenden. Sie können die Eigenschaften auf Basis des Nachrichtenprotokolls verwenden, mit dem die Nachricht an die Bridge gesendet wird. Die unterstützten Protokolle sind HTTP, SOAP, FTP und SFTP. Folgende Eigenschaften stehen für diese Protokolle zur Verfügung:

  • SOAP

    • Aktion

    • MessageId

    • ReplyTo

    • An

    • Benutzerdefinierte SOAP-Header

  • HTTP – HTTP-Standardheader

  • FTP/SFTP

    • FileName

    • ServerAddress

    • Ordner

Anweisungen zum Konfigurieren der Zuweisung von Headern zu Eigenschaften finden Sie unter Create an XML Bridge oder XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Verwenden von vom System höher gestuften Eigenschaften

Standardmäßig werden einige Eigenschaften von BizTalk Services für die Nachrichten hochgestuft, die von der Bridge verarbeitet werden. Diese Eigenschaften werden auch als vom System höher gestufte Eigenschaften bezeichnet. Die Werte dieser Eigenschaften können auch für verschiedene Verarbeitungstasks verwendet werden, z. B. zum Treffen einer Entscheidung zum Weiterleitungsziel usw. Folgende vom System höher gestufte Eigenschaften sind verfügbar:

  • RequestId: Eine eindeutige Anforderungs-ID, die der Nachricht zugeordnet ist.

  • MessageReceivedTime: Der Zeitstempel, der den Zeitpunkt angibt, an dem die Nachricht am Endpunkt der Bridge empfangen wurde.

  • SourceName: Der Name der Quelle, der in der Bridgekonfigurationsoberfläche definiert ist, über die die Bridge Nachrichten empfängt.

  • SourceType: Der Typ der Quelle, der in der Bridgekonfigurationsoberfläche verwendet wird, über die die Bridge Nachrichten empfängt.

Anweisungen zum Verwenden der vom System höher gestuften Eigenschaften finden Sie unter Create an XML Bridge oder XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Extract

Über den Extract-Vorgang der Enrich-Phase werden die Werte bestimmter Elemente oder Attribute des Nachrichtentexts extrahiert und im Rahmen der Nachrichtenweiterleitung oder weiteren Verarbeitung verwendet.

Anweisungen zum Konfigurieren des Extrahierungsvorgangs finden Sie unter Create an XML Bridge oder XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Lookup

Über den Lookup-Vorgang der Enrich-Phase wird die Nachricht erweitert, indem Daten in Quellen, die außerhalb der Nachrichtenbegrenzung liegen, gesucht und einbezogen werden. Es könnte z. B. ein Onlinegeschäft geben, in dem Benutzer ihre Bestellungen unter Angabe der eigenen lokalen Währung aufgeben können, während der für die Verarbeitung der Bestellungen zuständige Back-End-Dienst für sämtliche Bestellungsverarbeitungen eine einzelne Währung verwendet, z. B. Dollar. In dieser Situation muss der Wert der Bestellung von der lokalen Währung in Dollar umgewandelt werden, bevor die Nachricht an den Back-End-Dienst gesendet wird. Dies könnte über die Suche nach einem anderen Dienst erfolgen, der aktuelle Wechselkurse bereitstellt.

Bei dieser Version unterstützt die Enrich-Phase nur die Suche von Daten aus der Microsoft Azure SQL-Datenbank. Das bedeutet, dass die Microsoft Azure SQL-Datenbank der einzige "Suchanbieter" ist, der für die aktuelle Version unterstützt wird. Die Informationen zum Suchanbieter werden in der Datei "LookupProviderConfigurations.xml" gespeichert, die zum BizTalk Service-Projekt hinzugefügt wird. Sie können in einer einzelnen XML-Datei mehrere Anbieter festlegen, da Sie im Rahmen einer einzelnen Enrich-Phase auch in mehreren Datenquellen der Microsoft Azure SQL-Datenbank suchen können. Eine typische Anbieterdefinition in der Datei "LookupProviderConfigurations.xml" sieht wie folgt aus:

<ArrayOfLookupProviderConfiguration xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/WindowsAzureServiceBus/Bridge">
  <LookupProviderConfiguration i:type="SqlTableLookupProviderConfiguration">
    <ProviderName>...</ProviderName>
    <ConnectionString>...</ConnectionString>
    <QueryInColumnName>...</QueryInColumnName>
    <QueryOutColumnName>...</QueryOutColumnName>
    <TableName>...</TableName>
  </LookupProviderConfiguration>
</ArrayOfLookupProviderConfiguration>

Beachten Sie im obigen Ausschnitt, dass das type-Attribut für das LookupProviderConfiguration-Element auf SqlTableLookupProviderConfiguration festgelegt ist. Der Grund hierfür ist, dass Sie derzeit nur eine Tabelle in der Microsoft Azure SQL-Datenbank suchen können.

Während der Suche nach Daten aus einer Microsoft Azure SQL-Datenbank müssen auch einige Überlegungen angestellt werden.

  • Sie können nur eine Microsoft Azure SQL-Datenbanktabelle suchen.

  • Die Suche muss mit einem Schlüssel-Wert-Paar ausgeführt werden.

  • Die Suche darf nur einen Wert ergeben, der einer Eigenschaft in der Nachricht zugewiesen wird. Wenn die Suche mehrere Werte ergibt, wird der Eigenschaft der erste Wert zugewiesen.

  • Sie können einen Wert aus mehreren Datenquellen suchen, d. h. Sie können in mehreren Microsoft Azure SQL-Datenbanktabellen oder in mehreren Microsoft Azure SQL-Datenbanken suchen.

Anweisungen zum Konfigurieren des Nachschlagevorgangs finden Sie unter Create an XML Bridge oder XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Obwohl die Informationen zu den Anbietern in der Datei "LookupProviderConfigurations.xml" gespeichert werden, befinden sich die Informationen, welche Werte aus dem Header zu den Nachrichteneigenschaften zugewiesen werden, welche Werte extrahiert und welche gesucht werden müssen, in der Konfigurationsdatei einer Bridge. Wenn Sie ein BizTalk Service-Projekt erstellen, wird für die Datei "LookupProviderConfigurations.xml" auch ein Rollup in die Konfigurationsdatei einer Bridge ausgeführt. Wenn Sie das BizTalk Service-Projekt bereitstellen, wird die Konfigurationsdatei der Bridge für den Servicebus bereitgestellt.

In der Enrich-Phase erstellen Sie Eigenschaften und weisen diesen Eigenschaften Werte zu. Es stellt sich jedoch die Frage, was mit diesen Eigenschaften gemacht werden kann? Wie können diese Eigenschaften meine Aufgabe vereinfachen? Es gibt zwei Möglichkeiten, um diese Eigenschaften zu verwenden:

  • Sie können mit den Eigenschaften Filterbedingungen für die Weiterleitung von Nachrichten an verschiedene Zielen festlegen. Anweisungen hierzu finden Sie unter The Routing Condition.

  • Mit diesen Eigenschaften können Sie den Protokollunterschied zwischen Nachrichtensender und Nachrichtenempfänger in Einklang bringen. Sie erhalten z. B. eine eingehende SOAP-Nachricht, die einen benutzerdefinierten Headerwert enthält. Sie möchten diesen Wert als benutzerdefinierten Header einer HTTP-Nachricht übergeben, da der Nachrichtenempfänger eine REST-Nachricht erwartet und das SOAP-Nachrichtenformat nicht kennt. Sie können hierfür Eigenschaften verwenden. Sie können zunächst den Wert aus dem eingehenden Nachrichtenheader zu einer Eigenschaft zuweisen, z. B. "P1", und dann beim Senden der Nachricht an den Empfänger den Wert von P1 dem Nachrichtenheader der ausgehenden Nachricht zuweisen. Weitere Informationen finden Sie unter Weiterleitungs- und Antwortaktionen: Überbrücken von Protokollkonflikten.

In einer Bridgekonfiguration stehen die von Ihnen im Rahmen der Enrich-Phase definierten Eigenschaften während des gesamten Nachrichtenflusses für jede Phase der Bridgekonfiguration zur Verfügung. Wenn Sie also eine Eigenschaft in der Enrich-Phase definiert haben, können Sie diese Eigenschaft während der Transform-Phase sowie für beliebige Zuordnungsvorgänge verwenden. Die in der Enrich-Phase definierten Eigenschaften können unter Berücksichtigung einiger Faktoren auch außerhalb der Grenzen einer Bridgekonfiguration verwendet werden. Bevor wir dabei ins Detail gehen, muss Ihnen bewusst sein, dass die Eigenschaftswerte als Eigenschaften der Servicebus BrokeredMessage-Klasse gespeichert werden. Nachdem uns diese Information jetzt bekannt ist, betrachten wir nun die Lebensdauer der Eigenschaften außerhalb einer Bridgekonfiguration.

  • Da Nachrichten vom Typ "BrokeredMessage" nur von Servicebus-Warteschlangen oder -Themen verarbeitet werden können, können die Eigenschaften und ihre Werte (als Schlüssel-Wert-Paar) von Warteschlangen und Themen direkt verwendet werden. Danach können die Eigenschaften z. B. von Themen möglicherweise zur weiteren Verarbeitung und Weiterleitung verwendet werden.

  • Die Eigenschaften und ihre Werte können nicht an andere Bridgekonfiguration-Komponenten wie unidirektionale-/bidirektionale Relayendpunkte oder unidirektionale/bidirektionale externe Dienstendpunkte übergeben werden. Wenn Sie die Eigenschaftswerte an diese Entitäten übergeben möchten, müssen Sie die Eigenschaftswerte den Headern der ausgehenden Nachricht zuweisen. Weitere Informationen finden Sie unter Weiterleitungs- und Antwortaktionen: Überbrücken von Protokollkonflikten.

  • In einem Szenario mit "Verkettung", in dem die Nachricht von einer Bridge an eine andere Bridge und abschließend (beispielsweise) an eine Servicebus-Warteschlange weitergeleitet wird, sind nur die Eigenschaften der letzten Bridge in der Kette zur weiteren Weiterleitung oder Verarbeitung verfügbar. Damit Eigenschaftswerte an nachfolgende Briges übergeben werden können, müssen den Headern der ausgehenden Nachricht zudem die Eigenschaftswerte zugewiesen werden. Diese Eigenschaften müssen dann in der zweiten Bridge extrahiert werden.

Wie der Name vermuten lässt, werden in der Transform-Phase die Funktionen zum Ausführen struktureller Transformationen für die Nachrichten bereitgestellt. Wie auch die anderen Phasen in der Pipeline kann die Transform-Phase mit mehreren Nachrichtentypen arbeiten, sodass im Rahmen der Transform-Phase mehrere Transformationen zur Verfügung stehen. Während der Laufzeit wird die auszuführende geeignete Transformation automatisch auf Basis des eingehenden Nachrichtentyps ermittelt, vorausgesetzt, die entsprechenden Transformationen wurden während der Konfiguration der Bridge konfiguriert und hochgeladen. Die Transformationsauflösung erfolgt auf Basis des Nachrichtentyps der eingehenden Nachricht.

  • In der Transform-Phase wird der Nachrichtentyp der Nachricht mit dem Nachrichtentyp des Quellschemas in einer Zuordnung verglichen.

  • Wenn die Überprüfungsphase deaktiviert ist, wird in der Transform-Phase die eingehende Nachricht mit dem Quellnachrichtenschema verglichen. Wenn die Auflösung erfolgt, wird die MessageType-Eigenschaft der Nachricht hochgestuft.

Die aktuelle Version unterstützt ausschließlich Transformationen einzelner Quellen in einzelne Ziele. Weitere Informationen finden Sie unter Erlernen und Erstellen von Nachrichtenzuordnungen und -transformationen. Anweisungen zum Konfigurieren der Transformationsphase finden Sie unter Create an XML Bridge oder XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Die der Transformationsphase nachfolgende Enrich-Phase ähnelt der Enrich-Phase, die vor der Transformation erfolgt. Der einzige Unterschied ist, dass Sie die transformierte Nachricht in der Enrich-Phase, die auf die Transformationsphase folgt, erweitern können. Die Enrich-Phase wird auf dieselbe Weise wie bei der vor der Transformation ausgeführten Enrich-Phase konfiguriert. Anweisungen zum Konfigurieren der Enrich-Phase, die auf die Transformation folgt, finden Sie unter Create an XML Bridge oder XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

noteHinweis
Alle vor den Transform-Phasen extrahierten oder gesuchten Eigenschaften stehen auch für die transformierte Nachricht zur Verfügung. Eine zuvor extrahierte oder erweiterte Eigenschaft wird überschrieben, wenn sie in der Enrich-Phase, die im Anschluss an die Transform-Phase folgt, geändert wird.

Im vorherigen Abschnitt wurde gezeigt, dass die Überprüfung in der Validate-Phase anhand von Schemas vorgenommen wird, während in der Transform-Phase die Nachricht transformiert wird. Somit sind die folgenden Artefakte im Rahmen einer XML-Bridge verfügbar:

  • Schemas: Diese besitzen die XSD-Erweiterung.

  • Transformationen: Diese besitzen die TRFM-Erweiterung und es können sich mehrere Transformationen innerhalb einer Transform-Phase befinden.

  • Assemblys: Diese enthalten die benutzerdefinierte Verarbeitungslogik, die in bestimmten Phasen der Bridge einbezogen werden kann.

  • Zertifikate: Diese werden zur sicheren Nachrichtenübertragung verwendet.

noteHinweis
Eine Bridgekonfigurationsdatei ist kein Artefakt, da sie nicht von verschiedenen Bridges gemeinsam genutzt werden kann. Eine Bridgekonfigurationsdatei ist spezifisch für eine Bridge.

Die BizTalk Service-Anwendung kann mehrere Bridges umfassen und jede Bridge kann wiederum mehrere Transformationen und Schemas verwenden. Daher umfasst eine typische BizTalk Services-Anwendung in der Regel eine große Anzahl an Transformationen und Schemas. Dabei sind jedoch möglicherweise nicht alle Transformationen und Schemas für die einzelnen XML-Bridges erforderlich. Daher muss es eine Möglichkeit geben, um die Transformationen und Schemas zu einer Bridge zuzuordnen. Diese Zuordnung kann während der Konfiguration der Bridge vorgenommen werden.

Informationen zum Zuordnen von Schemas und Transformationen finden Sie unter Erstellen einer unidirektionalen XML-Brücke oder Erstellen einer Anforderungs-/Antwort-XML-Bridge.

Wenn ein beliebiger Nachrichtentyp von der Bridge verarbeitet werden soll, wird eine Pass-Through-Bridge verwendet. Daher umfasst eine Pass-Through-Bridge keine Validate- oder Transform-Phasen, da beide Phasen an Nachrichtentypen gebunden sind. Eine Pass-Through-Bridge umfasst nur die Enrich-Phase, die für dieselben Zwecke wie in einer XML-Bridge verwendet wird. Weitere Informationen zum Konfigurieren einer Pass-Through-Bridge finden Sie unter Erstellen einer Pass-Through-Bridge.

Siehe auch

Anzeigen: