Belegung der Nachrichtenbaumstruktur

Die Nachrichtenbaumstruktur wird anfangs vom Empfangsknoten des Nachrichtenflusses mit Daten gefüllt.

Wenn der Empfangsknoten die Eingangsnachricht empfängt, erstellt er eine Baumstruktur für Eigenschaften ('Properties', die erste untergeordnete Baumstruktur der Nachrichtenbaumstruktur) und füllt diese mit den Knoteneingenschaften, die Sie zuvor im Nachrichtenfluss konfiguriert haben. Anschließend überprüft er den Inhalt des Bitstroms der Eingabenachricht und erstellt den Rest der Nachrichtenbaumstruktur, um diesen Inhalt zu wiederzugeben. Dieser Prozess hängt bis zu einem gewissen Grad vom Empfangsknoten selbst ab, der von dem Transport gesteuert wird, über den die Nachricht empfangen wird:

Protokolle WebSphere MQ Enterprise Transport, und WebSphere MQ Telemetry Transport
Wenn Ihre Anwendung über diese Protokolle mit dem Broker kommuniziert und Ihr Nachrichtenfluss den entsprechenden MQEmpfangs- , oder SCADAEmpfangsknoten enthält, müssen alle empfangenen Nachrichten mit einem MQMD-Header (MQMD = Message Queue Message Descriptor) beginnen. Wenn die Nachricht nicht mit einem gültigen MQMD-Header beginnt, wird sie abgelehnt, und es findet keine weitere Verarbeitung statt.

Der Empfangsknoten ruft zuerst den MQMD-Parser auf und erstellt die untergeordnete Baumstruktur für diesen Header.

Dem MQMD-Header in einer Nachricht können keine oder mehrere zusätzliche Header folgen. Diese werden miteinander verkettet, wobei das Formatfeld des einen Headers das Format des folgenden Headers definiert, bis einschließlich des letzten Headers, der das Format des Nachrichtenhauptteils definiert. Wenn die Kette einen MQRFH- und MQRFH2-Header enthält, können die Namens-/Wertdaten in diesen beiden Headern auch Informationen zum Format der folgenden Daten enthalten. Falls es sich bei dem im Format angegebenen Wert um einen anerkannten Parser handelt, hat dieser immer Vorrang vor den Namens-/Wertdaten.

Der Broker ruft den geeigneten Parser für die Interpretation der einzelnen Header auf, wobei er der Nachrichtenkette folgt. Jeder Header wird unabhängig syntaktisch analysiert. Die Felder in einem einzelnen Header werden in der Reihenfolge syntaktisch analysiert, die vom Parser vorgegeben wird. Die ausgewählte Reihenfolge kann nicht vorhergesagt werden und ist auch nicht verlässlich. Die Reihenfolge, in der die Felder syntaktisch analysiert werden, wirkt sich jedoch nicht auf die Reihenfolge aus, in der die Felder im Header angezeigt werden.

Der Broker stellt sicher, dass die Integrität der Header, die vor dem Hauptteil einer Nachricht stehen, gewahrt bleibt. Das Format der einzelnen Nachrichtenbereiche wird entweder über das Formatfeld im unmittelbar davor stehenden Header (wenn der folgende Bereich ein anerkanntes WebSphere MQ-Format ist) oder über die Werte definiert, die im MQRFH- oder MQRFH2-Header festgelegt sind:

  • Das Format des ersten Headers ist bekannt, da es sich hierbei um einen MQMD-Header handeln muss.
  • Das Format der nachfolgenden Header in der Nachricht wird im Formatfeld des vorhergehenden Headers festgelegt.
  • Das Format des Hauptteils entspricht der Nachrichtendomäne und dem Parser, der für den Nachrichtenhauptteil aufgerufen werden muss (beispielsweise XML). Diese Informationen werden entweder im MQRFH- bzw. MQRFH2-Header oder in der Nachrichtendomänen-Eigenschaft des Empfangsknotens festgelegt, der die Nachricht empfängt.

Die Anzahl der Wiederholungen dieses Prozesses hängt von der Anzahl der Header ab, die dem Hauptteil einer Nachricht vorangehen. Sie müssen diese Felder nicht selbst mit Daten füllen; der Broker handhabt diese Folge für Sie.

Der Broker schließt diesen Prozess ab, um sicherzustellen, dass die Formatfelder in den Headern jeden Nachrichtenbereich korrekt identifizieren. Wenn der Broker dies unterlässt, kann die Nachricht möglicherweise nicht von WebSphere MQ zugestellt werden. Da der Parser des Nachrichtenhauptteils kein anerkanntes WebSphere MQ-Headerformat ist, ersetzt der Broker diesen Wert im Formatfeld des letzten Headers durch den Wert MQFMT_NONE. Der ursprüngliche Wert in diesem Feld wird im Domänenfeld innerhalb des MQRFH- oder MQRFH2-Headers gespeichert, damit die Informationen zum Inhalt des Nachrichtenhauptteils weiterhin vorliegen. Falls es keinen MQRFH- oder MQRFH2-Header gibt, werden die Informationen in der Baumstruktur für Eigenschaften (Properties) gespeichert.

Wenn beispielsweise der MQRFH2-Header unmittelbar vor dem Hauptteil einer Nachricht steht und in seinem Formatfeld 'XML' angegeben ist (d. h., der Hauptteil der Nachricht muss vom generischen XML-Parser analysiert werden), wird das MQRFH2-Feld für die Domäne auf XML gesetzt und das Formatfeld erhält den Wert MQFMT_NONE.

Diese Aktionen können dazu führen, dass Informationen, die von einem ESQL-Ausdruck explizit gespeichert wurden, vom Broker durch eine andere Information ersetzt werden.

Nachdem alle Header analysiert und die entsprechenden untergeordneten Baumstrukturen in der Nachrichtenbaumstruktur erstellt wurden, ordnet der Empfangsknoten den angegebenen Parser dem Hauptteil der Nachricht zu. Sie müssen den Parser angeben, der dem Inhalt des Hauptteils der Nachricht zugeordnet werden soll. Dies können Sie entweder in einem Header innerhalb der Nachricht, z. B. im Ordner <mcd> im MQRFH2-Header (allgemein empfohlen), oder in den Eigenschaften des Empfangsknotens (empfohlen, wenn die Nachricht keinen Header enthält). Der Empfangsknoten führt die Zuordnung wie folgt durch:

  • Wenn die Nachricht einen MQRFH- oder MQRFH2-Header enthält, bestimmt die Domäne, die im Header identifiziert wird (entweder im Formatfeld oder in den Name/Wert-Daten), den Parser, der dieser Nachricht zugeordnet wird.

    Der SCADAEmpfangsknoten erstellt WebSphere MQ-Formatnachrichten mit MQRFH2-Headern auf Basis der Eingabenachrichten, die das Empfangsprogramm am TCP/IP-Port empfängt.

  • Wenn die Nachricht keinen MQRFH- oder MQRFH2-Header enthält oder der Header die Domäne nicht identifiziert, aber die in der Baumstruktur 'Properties' gespeicherten Eigenschaften des Empfangsknotens die Domäne der Nachricht angeben, wird der von der Empfangsknoteneigenschaft angegebene Parser verwendet. Sie können einen benutzerdefinierten Parser angeben.
  • Wenn die Nachrichtendomäne weder durch Headerwerte noch durch Eigenschaften des Empfangsknotens identifiziert werden kann, wird die Nachricht wie ein binäres Objekt (BLOB) behandelt. Das heißt, der Nachricht wird der BLOB-Parser zugeordnet. Ein BLOB kann als Zeichenfolge aus hexadezimalen Zeichen interpretiert und im Nachrichtenfluss geändert oder ausgewertet werden, indem die Adresse der Teilmenge der Zeichenfolge angegeben wird.

Der Hauptteil der Nachricht wird aus Leistungsgründen nicht analysiert. Es ist möglich, dass die Konfiguration des Nachrichtenflusses nicht verlangt, dass der Hauptteil einer Nachricht analysiert wird. Er wird nur analysiert, wenn im Verlauf des Nachrichtenflusses ein Verweis auf seinen Inhalt erfolgt.

Beispielsweise wird der Hauptteil einer Nachricht analysiert, wenn Sie auf Root.XML.Field (bzw. InputRoot.XML.Field im Rechenknoten) oder Root.MRM.Field verweisen. Abhängig von den im Nachrichtenfluss eingeschlagenen Pfaden kann diese Analyse an unterschiedlichen Punkten stattfinden. Diese Methode der Analyse (bei der ersten Anforderung) wird auch als Teilanalyse bezeichnet und beeinflusst bei normaler Verarbeitung nicht die Logik eines Nachrichtenflusses. Allerdings gibt es einige Auswirkungen auf die Fehlerbehandlungsszenarios (siehe unter Fehler in Nachrichtenflüssen behandeln).

Wenn Sie möchten, dass ein Nachrichtenfluss Nachrichten von mehreren Nachrichtendomänen akzeptiert, können Sie einen MQRFH2-Header in Ihre Nachricht einfügen, aus dem die Empfangsknoten die Nachrichtendomäne und zugehörige Nachrichtendefinitionsinformationen (Gruppe, Typ und Format) extrahieren.

Wenn Sie die Nachrichtenheader oder Empfangsknoteneigenschaften so konfigurieren, dass ein benutzerspezifischer Parser identifiziert wird, kann sich die Art und Weise, wie die Nachricht interpretiert und die logische Baumstruktur aufgebaut wird, von der hier beschriebenen Vorgehensweise unterscheiden.

Protokolle WebSphere MQ Multicast Transport, WebSphere MQ Real-time Transport und WebSphere MQ Web Services Transport
Wenn Ihre Anwendung über diese unterstützten Protokolle mit dem Broker kommuniziert und Ihr Nachrichtenfluss die entsprechenden Empfangsknoten für Echtzeiteingabe-, HTTPEmpfangs- oder HTTPAnforderungsknoten enthält, müssen empfangene Nachrichten keinen besonderen Header enthalten. Ihre Anwendungen können den MQRFH2-Header enthalten, um nachrichtenbezogene Informationen, z. B. zu Veröffentlichungen und Subskriptionen, bereitzustellen. Wenn bekannte Header enthalten sind, ruft der Empfangsknoten die geeigneten Parser auf, um die Header zu analysieren und die relevanten Teile der Nachrichtenbaumstruktur aufzubauen, so wie für die anderen unterstützten Protokolle beschrieben.

Falls keine Header vorhanden sind oder die Header den Parser für den Hauptteil einer Nachricht nicht angeben, müssen Sie die Empfangsknoteneigenschaften konfigurieren, um den Parser für den Hauptteil zu definieren. Andernfalls wird die Nachricht wie ein BLOB behandelt. Sie können einen benutzerspezifischen Parser angeben.

Der Empfangsknoten ordnet den angegebenen Parser dem Hauptteil der Nachricht zu (auf dieselbe Weise wie für die Protokolle WebSphere MQ Enterprise Transport, WebSphere MQ Mobile Transport und WebSphere MQ Telemetry Transport), und der Hauptteil der Nachricht wird nicht analysiert.

Wenn Sie die Nachrichtenheader oder Empfangsknoteneigenschaften so konfigurieren, dass ein benutzerspezifischer Parser identifiziert wird, kann sich die Art und Weise, wie die Nachricht interpretiert und die logische Baumstruktur aufgebaut wird, von der hier beschriebenen Vorgehensweise unterscheiden.

Alle anderen Protokolle
Wenn Ihr Nachrichtenfluss Nachrichten von einem Transportprotokoll entgegennehmen soll, für das WebSphere Message Broker keine integrierte Unterstützung zur Verfügung stellt, oder eine spezifische Verarbeitung beim Empfang einer Nachricht bereitstellen soll, erstellen Sie entweder mit Hilfe der Java- oder der C-Programmierschnittstelle einen neuen, benutzerspezifischen Empfangsknoten.

Diese Schnittstellen generieren für eine Nachricht nicht automatisch eine untergeordnete Baumstruktur 'Properties' (siehe Beschreibung dieser Baumstruktur unter Properties-Parser). Es ist nicht zwingend erforderlich, dass für eine Nachricht eine untergeordnete Baumstruktur 'Properties' erstellt wird, kann jedoch hilfreich sein, um unabhängig vom Empfangsknoten über eine konsistente Nachrichtenbaumstruktur zu verfügen. Falls eine untergeordnete Baumstruktur 'Properties' in der Nachrichtenbaumstruktur erstellt werden soll und Sie einen benutzerspezifischen Empfangsknoten verwenden, müssen Sie diese selbst erstellen.

Wenn Sie Nachrichten verarbeiten müssen, die mit keiner der definierten Nachrichtendomänen konform sind, können Sie mit Hilfe der C-Programmierschnittstelle einen neuen, benutzerspezifischen Parser erstellen.

Informieren Sie sich darüber, wie die Knotenschnittstelle Parser verwendet und ob Sie ihr Verhalten durch eine entsprechende Konfiguration ändern können. Wenn der Knoten einen benutzerspezifischen Parser verwendet, unterscheidet sich die für die Nachricht erstellte Baumstruktur geringfügig von der, die für integrierte Parser erstellt wird. Ein benutzerspezifischer Empfangsknoten kann eine Eingabenachricht vollständig analysieren oder sich an einer Teilanalyse beteiligen, bei der der Hauptteil einer Nachricht nur auf Anforderung analysiert wird.

Sie können auch eigene Sende- und Nachrichtenverarbeitungsknoten in C oder Java erstellen.

Zugehörige Konzepte
Logische Baumstruktur
Nachrichtenbaumstruktur (Message)
Umgebungsbaumstruktur (Environment)
LocalEnvironment-Baumstruktur
Ausnahmeliste-Baumstruktur
Properties-Parser
Teilweises Parsing
Korrelationsnamen
Zugehörige Tasks
Fehler in Nachrichtenflüssen behandeln
Nachrichtenflüsse entwickeln
Zugehörige Verweise
Integrierte Knoten
Benutzerdefinierte Knoten
MQRFH2-Header
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2005 Letzte Aktualisierung: Nov 17, 2005
ac18520_