Nachrichtenbaumstruktur füllen

Die Nachrichtenbaumstruktur wird zum ersten Mal vom Empfangsknoten des Nachrichtenflusses gefüllt.

Wenn der Empfangsknoten die Eingangsnachricht empfängt, erstellt und vervollständigt er eine Baumstruktur für Eigenschaften ('Properties', die erste untergeordnete Baumstruktur der Nachrichtenbaumstruktur). Weitere Informationen hierzu finden Sie unter Nachrichtenbaumstruktur.

Anschließend überprüft er den Inhalt des Bitstroms der Eingabenachricht und erstellt den Rest der Nachrichtenbaumstruktur, um diesen Inhalt zu wiederzugeben. Dieser Prozess ist bis zu einem gewissen Grad vom Empfangsknoten selbst abhängig, der von dem Transportprotokoll, über das die Nachricht empfangen wird, bestimmt wird.

WebSphere MQ Enterprise Transport- undWebSphere MQ Telemetry Transport-Protokolle
Wenn Ihre Anwendung über diese Protokolle mit dem Broker kommuniziert und Ihr Nachrichtenfluss den entsprechenden MQInput- oder SCADAInput-Knoten 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 den 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- und 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- und 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. 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 jedes Teils der Nachricht ist definiert, entweder durch das Formatfeld im unmittelbar vorausgehenden Header (wenn der folgende Teil ein bekanntes WebSphere MQ-Format hat) oder durch die Werte, die im MQRFH- oder MQRFH2-Header festgelegt sind:

  • Das Format des ersten Headers ist bekannt, weil es sich dabei 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 XMLNSC). 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 füllen, denn diesen Arbeitsschritt übernimmt der Broker automatisch.

Der Broker schließt diesen Prozess ab, um sicherzustellen, dass die Formatfelder in den Headern jeden Nachrichtenbereich korrekt identifizieren. Falls dieser Prozess nicht vom Broker vollständig ausgeführt wird, ist WebSphere MQ möglicherweise nicht in der Lage, die Nachricht zuzustellen. Da der Parser für den Hauptteil der Nachricht kein anerkanntes WebSphere MQ-Headerformat hat, ersetzt der Broker diesen Wert im Formatfeld des letzten Headers durch den Wert MQFMT_NONE. Der ursprüngliche Wert in dem Feld wird im Feld für die Domäne im MQRFH- oder MQRFH2-Header gespeichert, um die Informationen über den Inhalt des Hauptteils der Nachricht zu erhalten.

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

Diese Aktionen können dazu führen, dass Informationen, die von einem ESQL- oder Java-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. Geben Sie den Inhalt des Hauptteils in einem Header innerhalb der Nachricht ( z. B. im Ordner <mcd> im MQRFH2-Header) an, oder in den Eigenschaften des Empfangsknotens (wenn die Nachricht keinen Header enthält). Der Empfangsknoten führt die Zuordnung wie in der folgenden Liste beschrieben 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 Namens- und Wertdaten), den Parser, der dieser Nachricht zugeordnet wird.

    Der SCADAInput-Knoten 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, gibt die Eigenschaft Nachrichtendomäne des Empfangsknotens die Domäne der Nachricht und den Parser an, die verwendet werden sollen. Sie können eine benutzerdefinierte Domäne und einen benutzerdefinierten Parser angeben.
  • Wenn die Nachrichtendomäne weder durch Headerwerte noch durch die Eigenschaft Nachrichtendomäne 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 standardmäßig nicht umgehend analysiert. Möglicherweise ist für den Hauptteil der Nachricht keine syntaktische Analyse im Verlauf des Nachrichtenflusses erforderlich. Er wird nur analysiert, wenn ein Verweis auf seinen Inhalt erfolgt.

Beispielsweise wird der Hauptteil einer Nachricht analysiert, wenn Sie beispielsweise auf Root.XMLNSC.MyDoc.MyField im Nachrichtenhauptteil 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 (weitere Informationen finden Sie unter Fehler in Nachrichtenflüssen behandeln).

Wenn Sie möchten, dass ein Nachrichtenfluss Nachrichten von mehreren Nachrichtendomänen akzeptiert, fügen Sie einen MQRFH2-Header in Ihre Nachricht ein, aus dem die Empfangsknoten die Nachrichtendomäne und zugehörige Nachrichtendefinitionsinformationen (Nachrichtengruppe, Nachrichtentyp und Nachrichtenformat) extrahieren.

Wenn Sie die Nachrichtenheader oder Empfangsknoteneigenschaften so konfigurieren, dass ein benutzerspezifischer Parser und eine Domäne 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, , , WebSphere MQ Web Services Transport und WebSphere Broker JMS Transport
Wenn Ihre Anwendung über diese unterstützten Protokolle mit dem Broker kommuniziert und Ihr Nachrichtenfluss die entsprechenden Empfangsknoten enthält, müssen empfangene Nachrichten keinen besonderen Header enthalten. 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 und WebSphere MQ Telemetry Transport), und der Hauptteil der Nachricht wird standardmäßig nicht umgehend analysiert.

Wenn Sie die Nachrichtenheader oder Empfangsknoteneigenschaften so konfigurieren, dass ein benutzerspezifischer Parser und eine Domäne 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 mithilfe der Java- oder der C-Programmierschnittstelle einen neuen, benutzerspezifischen Empfangsknoten.

Diese Schnittstelle generiert für eine Nachricht nicht automatisch eine untergeordnete Baumstruktur 'Properties' (eine Beschreibung dieser Baumstruktur finden Sie unter Nachrichtenbaumstruktur). Es ist nicht 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 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 mithilfe 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.

Gegenüberstellung: Verhalten des Eigenschaftenordners und des MQMD-Ordners für verschiedene Transporte

Es bestehen Unterschiede in der Behandlung des Eigenschaftenordners und des MQMD-Ordners hinsichtlich deren Priorität bei gleichen Feldern. Dieses Verhalten ist durch den von Ihnen verwendeten Transport (z. B. HTTP oder WebSphere MQ) charakterisiert.

Wenn der Nachrichtenfluss von einem MQInput-Knoten stammt, wird ein MQMD syntaktisch analysiert. In diesem Fall wird der Eigenschaftenordner von den MQMD-Werten abgeleitet, sodass der MQMD-Ordner gegenüber dem Eigenschaftenordner bei der Weiterleitung von Werten zwischen den Ordnern Priorität hat. Dieses Szenario bedeutet, dass Sie ESQL (z. B. SET OutputRoot.MQMD.CorrelId) ausführen können und dieser Befehl den Eigenschaftenordnerwert aktualisiert.

Wenn der Nachrichtenfluss von einem anderen Empfangsknoten als dem MQInput-Knoten (z. B. dem HTTPInput-Knoten oder einem benutzerdefinierten Empfangsknoten) stammt, wird kein MQMD syntaktisch analysiert. Dieses Szenario bedeutet, dass der Eigenschaftenordner nicht von einem Eingabe-MQMD abgeleitet wird. Er wird erstellt und mit Transportwerten aus anderen transportspezifischen Headern aufgefüllt. Wenn Sie einen MQMD-Ordner in einem Nachrichtenfluss erstellen, der nicht aus dem WebSphere MQ-Transport stammt, wird der MQMD-Header nicht vorranging vor dem Eigenschaftenordner behandelt, da der WebSphere MQ-Transport den Eigenschaftenordner nicht aufgefüllt hat. In diesem Fall überschreibt der Eigenschaftenordner alle Werte in MQMD.

Der Eigenschaftenordner wird erstellt und stellt eine Nachricht dar, die mit dem Transport empfangen wurde. In diesem Szenario werden zwei völlig verschiedene Transportmethoden verwendet, die unterschiedliche Bedeutungen haben und deshalb unterschiedliche Anforderungen an den Eigenschaftenordner stellen. Ist ein HTTPInput-Knoten die Quelle, steuern die HTTP-Header die LIKE-Felder im Eigenschaftenordner. Ist ein MQInput-Knoten die Quelle, werden die LIKE-Felder im Eigenschaftenordner von MQMD gesteuert.

Wenn Sie also einen MQMD-Ordner zu einer Baumstruktur hinzufügen, die vom HTTP-Transport erstellt wurde, wird der Eigenschaftenordner nicht vom MQMD-Ordner gesteuert, und die Werte werden nicht von MQMD nach Properties weitergeleitet, sondern von Properties nach MQMD. Sie sollten hier das Feld 'replyIdentifier' im Eigenschaftenordner setzen und zum Auffüllen des MQMD verwenden.
 SET OutputRoot.Properties.ReplyIdentifier = X' ..... '; 
Das Verhalten ist nicht nur den Feldern 'CorrelId' bis 'ReplyIdentifier' vorbehalten. Es gilt für alle like-Felder zwischen dem MQMD und dem Eigenschaftenordner:
  • CorrelId
  • ENCODING
  • CodedCharSetId
  • Persistence
  • Verfall
  • Priority
Zusammenfassung:
  1. Wenn Ihr Nachrichtenfluss von einem MQInput-Knoten stammt, hat MQMD Priorität gegenüber dem Eigenschaftenordner bei der Weiterleitung von Werten zwischen den Ordnern.
  2. Wenn Ihr Nachrichtenfluss von einem anderen Empfangsknoten als dem MQInput-Knoten (z. B. dem HTTPInput-Knoten oder einem benutzerdefinierten Empfangsknoten) stammt, hat der MQMD-Header keine Priorität gegenüber dem Eigenschaftenordner.
  3. Wenn ein MQMD-Ordner zu einer Baumstruktur hinzugefügt wird, die vom HTTP-Transport erstellt wurde, wird der Eigenschaftenordner nicht von diesem MQMD-Ordner gesteuert, und die Werte werden nicht von MQMD nach Properties weitergeleitet, sondern von Properties nach MQMD.

Beispiel

SET OutputRoot.Properties = InputRoot.Properties;
SET OutputRoot.MQMD.Version = 2;
SET OutputRoot.MQMD.CorrelId = X'4d454e53414a453320202020202020202020202020202020';
SET OutputRoot.MQMD.Encoding = 785;
SET OutputRoot.MQMD.CodedCharSetId = 500;
SET OutputRoot.MQMD.Persistence = 1;
SET OutputRoot.MQMD.Expiry = 10000;
SET OutputRoot.MQMD.Priority = 9;
SET OutputRoot.BLOB.BLOB = X'01';
Wenn die Ableitung von einem HTTPInput-Knoten erfolgt, wird keine dieser Änderungen wirksam, und die MQMD-Ausgabe aus dem Compute-Knoten lautet wie folgt:
(0x01000000):MQMD       = (
    (0x03000000):Version        = 2
    (0x03000000):CorrelId       = X'000000000000000000000000000000000000000000000000'
    (0x03000000):Encoding       = 546
    (0x03000000):CodedCharSetId = 1208
    (0x03000000):Persistence    = FALSE
    (0x03000000):Expiry         = -1
    (0x03000000):Priority       = 0
Zugehörige Konzepte
Logische Baumstruktur
Nachrichtenbaumstruktur
Umgebungsbaumstruktur
Baumstruktur für die lokale Umgebung
Baumstruktur für Ausnahmeliste
Korrelationsnamen
Zugehörige Tasks
Fehler in Nachrichtenflüssen behandeln
Nachrichtenflüsse entwickeln
Zugehörige Verweise
Integrierte Knoten
Benutzerdefinierte Knoten
MQRFH2-Header
Bedarfsgerechte Syntaxanalyse
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Letzte Aktualisierung : 2009-02-17 15:28:21

ac18520_