Nachrichtenflussknoten

Ein Nachrichtenflussknoten ist ein Verarbeitungsschritt in einem Nachrichtenfluss.

Er empfängt eine Nachricht, führt eine Reihe von Aktionen für die Nachricht aus und gibt die Nachricht optional an den nächsten Knoten im Nachrichtenfluss weiter. Bei einem Nachrichtenflussknoten kann es sich im einen integrierten Knoten , einen benutzerdefinierten Knoten oder einen untergeordneten Nachrichtenflussknoten handeln.

Ein Nachrichtenflussknoten verfügt über eine festgelegte Anzahl von Ein- und Ausgabepunkten, die Terminals genannt werden. Sie können zwischen den Terminals Verbindungen herstellen, um die Routen zu definieren, die eine Nachricht im Nachrichtenfluss nehmen kann.

Integrierter Knoten
Ein integrierter Knoten ist ein Nachrichtenflussknoten, der von WebSphere Message Broker zur Verfügung gestellt wird. Die integrierten Knoten bieten Funktionen zur Eingabe und Ausgabe sowie Funktionen für die Bearbeitung und Umwandlung, Entscheidungshilfen, Sortierungsanforderungen, Fehlerbehandlung und Berichtswesen.

Weitere Informationen zu allen von WebSphere Message Broker bereitgestellten integrierten Knoten finden Sie unter Integrierte Knoten.

Benutzerdefinierter Knoten
Ein benutzerdefinierter Knoten ist eine Erweiterung des Brokers, mit der neben den üblichen vom Produkt bereitgestellten Knoten ein neuer Nachrichtenflussknoten zur Verfügung gestellt wird. Der Knoten muss in der API für benutzerdefinierte Knoten geschrieben werden, die von WebSphere Message Broker für die Programmiersprachen C und Java zur bereitgestellt wird. Das Beispielprogramm 'User-defined Extension' veranschaulicht, wie Sie in den Programmiersprachen C und Java eigene Knoten schreiben können.
Untergeordneter Fluss
Ein untergeordneter Fluss ist eine übertragene Grafik, die sich aus Nachrichtenflussknoten und Konnektoren zusammensetzt. Sie wurde für die Einbettung in einen Nachrichtenfluss oder in einen anderen untergeordneten Fluss entwickelt. Ein untergeordneter Fluss muss mindestens einen Empfangsknoten oder einen Sendeknoten enthalten. Ein untergeordneter Fluss kann von einem Broker nur als Teil des Nachrichtenflusses ausgeführt werden, in der er eingebettet ist. Aus diesem Grund kann er nicht unabhängig eingesetzt werden.

Eine Nachricht wird von einem Empfangsknoten empfangen und gemäß der Definition des untergeordneten Flusses verarbeitet. Dies kann beinhalten, dass sie über einen Warehouseknoten gespeichert oder an ein anderes Nachrichtenziel zugestellt wird (beispielsweise über einen MQSendeknoten). Falls erforderlich, kann die Nachricht durch einen Sendeknoten zu weiteren Verarbeitung zurück an den Hauptfluss übergeben werden.

Der untergeordnete Fluss, der in einen Hauptfluss eingebettet ist, wird von einem Knoten des untergeordneten Flusses dargestellt. Diesem ist ein eindeutiges Symbol zugeordnet. Das Symbol wird mit der richtigen Anzahl an Terminal angezeigt, um die Empfangs- und Sendeknoten darzustellen, die Sie in die Definition des untergeordneten Flusses aufgenommen haben.

Die gängigste Verwendung eines untergeordneten Flusses besteht in der Bereitstellung der Verarbeitung, die an vielen Orten im Nachrichtenfluss erforderlich ist. Darüber hinaus kann er von mehreren Nachrichtenflüssen gemeinsam genutzt werden. Sie können beispielsweise eine gewisse Fehlerverarbeitung in einem untergeordneten Fluss codieren oder einen untergeordneten Fluss zur Bereitstellung eines Prüfprotokolls erstellen (dabei wird die gesamte Nachricht gespeichert und ein Trace-Eintrag geschrieben).

Die Verwendung von untergeordneten Flüssen wird im Beispielprogramm 'Error Handler' und im Beispielprogramm 'Coordinated Request Reply' veranschaulicht. Das Fehlerbehandlungsbeispiel verwendet einen untergeordneten Nachrichtenfluss zum Erfassen von Fehlerinformationen und Speichern der Informationen in einer Datenbank. Das Beispielprogramm 'Koordinierte Anforderungsantwort' verwendet einen untergeordneten Nachrichtenfluss zur Einbindung des Speichers der 'ReplyToQ'- und 'ReplyToQMgr'-Werte in einer WebSphere MQ-Nachricht, so dass die Verarbeitungslogik in anderen Nachrichtenflüssen wieder verwendet werden kann und die Substitution alternativer Implentierungen möglich ist.

Ein Knoten generiert nicht immer eine Ausgabenachricht für jedes Ausgabeterminal: Häufig generiert er eine Ausgabe für ein einzelnes Terminal auf Basis der empfangenen Nachricht oder des Ergebnisses der Knotenoperation. Ein Filterknoten sendet beispielsweise für gewöhnlich eine Nachricht am TRUE-Terminal oder am FALSE-Terminal, jedoch nie an beiden Terminals.

Sind mehrere Terminals verbunden, sendet der Knoten die Ausgabenachricht an jedem Terminal. Die Nachricht wird jedoch erst am nächsten Terminal gesendet, wenn die Verarbeitung für das aktuelle Terminal vollständig abgeschlossen ist. Aktualisierungen an einer Nachricht werden niemals an zuvor ausgeführte Knoten weitergegeben, nur an Knoten, dem Knoten folgen, in dem die Aktualisierung vorgenommen wurde. Die Reihenfolge, in der die Nachricht an die verschiedenen Ausgabeterminals weitergegeben wird, wird vom Broker festgelegt; sie kann nicht geändert werden. Die einzige Ausnahme dieser Regel bildet der Knoten 'Nachrichtenflussablauf', in dem die Terminals die Reihenfolge angeben, in der die Nachricht an die einzelnen Terminals weitergegeben wird.

Der Nachrichtenfluss kann eine neue Nachricht zur Verarbeitung erst annehmen, wenn alle Pfade durch den Nachrichtenfluss (d. h. alle verbundenen Knoten aller Ausgabeterminals) vollständig abgeschlossen wurden.

Das Beispielprogramm 'Airline Reservations' verwendet Umgebungsvariablen im Beispiel 'XML_Reservierung', um Informationen aus einer Datenbanktabelle zu speichern und sie an einen nachgeschalteten Knoten im Nachrichtenfluss weiterzuleiten.

Zugehörige Konzepte
Nachrichtenflussprojekte
Nachrichtenflussverbindungen
Nachrichten modellieren
Zugehörige Tasks
Nachrichtenflüsse entwickeln
Zugehörige Verweise
Nachrichtenflussprojekte und Nachrichtenflussdateien
Integrierte Knoten
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 23. Aug. 2006
ac12640_