Die Nachrichtenbaumstruktur wird zum ersten Mal vom Empfangsknoten des Nachrichtenflusses gefüllt.
Wenn der Empfangsknoten die Eingabenachricht empfängt, erstellt er die Baumstruktur 'Properties' (Eigenschaften), die erste untergeordnete Baumstruktur der Nachrichtenbaumstruktur, und füllt diese mit den Knoteneigenschaften, die Sie im Nachrichtenfluss konfiguriert haben. Anschließend wertet er den Inhalt des Bitstroms der Eingabenachricht aus und füllt damit den Rest der Nachrichtenbaumstruktur auf. 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.
Eine Nachricht kann nach dem MQMD mehrere zusätzliche Header enthalten, die miteinander verkettet sind, wobei das Formatfeld eines Headers das Format des folgenden Headers definiert, bis hin zum letzten Header, der das Format des Hauptteils der Nachricht definiert. Wenn sich in der Kette ein MQRFH- und ein MQRFH2-Header befinden, können die Name/Wert-Daten in einem dieser beiden Header auch Informationen zum Format der folgenden Daten enthalten. Falls der im Formatfeld angegebene Wert einen anerkannten Parser angibt, hat dieser immer Vorrang vor den Name/Wert-Daten.
Der Broker ruft nacheinander für jeden in der Nachricht verketteten Header den geeigneten Parser zum Interpretieren auf. Jeder Header wird unabhängig analysiert. Die Analyse der Felder in einem einzelnen Header erfolgt in einer vom Parser festgelegten Reihenfolge. Sie können die ausgewählte Reihenfolge weder vorhersagen noch voraussetzen, allerdings hat die Reihenfolge, in der Felder analysiert werden, keine Auswirkung auf die Reihenfolge, in der die Felder im Header angeordnet sind.
Der Broker stellt sicher, dass die Integrität der Header, die vor dem Hauptteil einer Nachricht stehen, erhalten 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:
Dieser Prozess wird so oft wiederholt, wie es abhängig von der Anzahl der Header, die dem Hauptteil der Nachricht vorausgehen, erforderlich ist. Sie müssen diese Felder nicht selbst füllen, denn diesen Arbeitsschritt übernimmt der Broker automatisch.
Dieser Prozess wird vom Broker ausgeführt, um sicherzustellen, dass die Formatfelder in Headern jeden Teil der Nachricht richtig identifizieren. Falls diese Aufgaben nicht vom Broker erledigt 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. Falls kein MQRFH- oder MQRFH2-Header vorhanden ist, werden die Informationen in der Baumstruktur 'Properties' (Eigenschaften) 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) angeben. Der Empfangsknoten führt die Zuordnung wie folgt durch:
Der SCADAEmpfangsknoten erstellt aus den Eingabenachrichten, die das Empfangsprogramm am TCP/IP-Port empfängt, Nachrichten im WebSphere MQ-Format mit MQRFH2-Headern.
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.
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.
Diese Schnittstelle generiert für eine Nachricht nicht automatisch eine untergeordnete Baumstruktur 'Properties' (eine Beschreibung dieser Baumstruktur finden Sie unter Nachrichtenbaumstruktur). 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.