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.
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 Feld Format 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 unter 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 Feld Format 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:
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 Feld Format des letzten Headers durch den Wert MQFMT_NONE. Der ursprüngliche Wert dieses Felds wird im Feld Domain (Domäne) des MQRFH- oder MQRFH2-Headers 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-Domänenfeld 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.
Die Felder CodedCharSetId und Encoding werden nicht auf dieselbe Weise gefüllt wie das Feld Format. Zur Ermittlung der Werte für die Felder CodedCharSetId und Encoding wird insbesondere nicht der Nachrichtenhauptteil verwendet. Vielmehr beeinflussen diese Werte, wie der Nachrichtenhauptteil geschrieben wird. Dies kann zu nicht erwarteten Ergebnissen führen, wenn ein zwischengelagerter Broker (z. B. MQRFH2) entfernt wird, ohne den in der Kette vorangehenden Header mit den entfernten Headerwerten zu aktualisieren.
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:
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 dies an unterschiedlichen Punkten erfolgen. Diese Methode der Analyse (bei der ersten Anforderung) wird auch als Teilanalyse oder als bedarfsgerechte Analyse 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.
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 das WebSphere MQ Enterprise Transport-Protokoll ) und der Hauptteil der Nachricht wird standardmäßig nicht sofort 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.
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.
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. In diesem Szenario wird der Eigenschaftenordner nicht von einem Eingabe-MQMD abgeleitet. 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.
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: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