Unter diesem Thema wird beschrieben, wie der einfache Aggregationsfluss verschiedenen Anforderungen entsprechend geändert wird. Dies ist auch hilfreich, wenn Sie bestehende Aggregationsflüsse der Version 5 oder früher des Produkts portieren.
Das Steuerterminal des Knotens zur Aggregationssteuerung wird verwendet, um die Steuernachricht, die die Status- und Überwachungsinformationen für eine bestimmte Aggregationsoperation enthält, weiterzugeben. Es kann auf drei Arten verwendet werden:
Sie sollten Folgendes beachten, wenn Sie eine der Optionen auswählen:
In früheren Releases des Produkts war Option 1 nur erlaubt, wenn
die Zeitlimitkonfigurationseinstellung des Knotens zu Aggregationssteuerung
auf null gesetzt wurde, d. h., dass Aggregationsoperationen nie das zulässige Zeitlimit überschritten. In Version 6
des Produkts ist Option 1 immer die optimale Lösung, egal ob Aggregationszeitlimits verwendet werden oder nicht.
Diese Option verwendet die kleinste CPU, um den Aggregationsstatus zu speichern, und vereinfacht den Verteilernachrichtenfluss.
Außerdem wird in Version 6 des Produkts für Nachrichtenflüsse, die die Optionen 2 und 3 verwenden, standardmäßig Option 1 verwendet. Das heißt, das alle Verbindungen zum Steuerterminal des Knotens zur Aggregationssteuerung ignoriert werden. Dadurch wird die Effizienz der Aggregationsflüsse aus vorherigen Versionen des Produkts maximiert, ohne diese Nachrichtenflüsse neu erstellen zu müssen. Dieses Verhalten kann umgekehrt werden, so dass Steuernachrichten an das Steuerterminal gesendet werden, wenn eine Verbindung besteht, indem die folgende Umgebungsvariable in die Startumgebung des Brokers exportiert wird:
MQSI_AGGR_COMPAT_MODE=ON
Hinsichtlich der Zeitlimitverarbeitung funktioniert Option 2 wie Option 1,
es gibt jedoch eine zusätzliche Verarbeitung bei der Nachrichtenweitergabe
vom Steuerterminal und bei der nachfolgenden Verarbeitung im Knoten für Aggregationsantworten.
Dieser Aufwand kann vermieden werden, indem Sie das Steuerterminal des
Knotens zur Aggregationssteuerung, wie in Option 1, nicht verbinden.
Option 3 ist die komplexeste Option, die zur Auswahl steht. Beachten Sie, dass sich die Auswahl dieser Option auf die Leistung und das Verhalten der Nachrichtenaggregation auswirkt. Damit die Verarbeitung im Aggregationsmechanismus höchst effizient ist, sollte der Knoten für Aggregationsantworten im Sammelnachrichtenfluss Informationen vom Knoten zur Aggregationssteuerung im Verteilernachrichtenfluss empfangen haben, bevor er Nachrichten in seinem Eingangsterminal empfängt.
In einigen Situationen ist dies möglicherweise nicht der Fall, z. B., wenn die Verarbeitung auf einer Verteileranforderungsnachricht sehr schnell ist, und
gleichzeitig die Übergabe vom Steuerterminal des Knotens zur Aggregationssteuerung durch
die Verarbeitung im Rechenknoten verzögert wird.
Dies kann zu einem Problem bei der Verarbeitung des Knotens für Aggregationsantworten führen.
Die Aggregation wird jedoch trotzdem korrekt beendet, wenn das Zeitlimit bei
unbekannten Nachrichten auf dem Knoten für Aggregationsantworten ungleich null ist. In diesem
Fall werden unbekannte Antworten gespeichert und dann, sortiert
nach der Anzahl der Zeitlimits, erneut verarbeitet. Hier werden
sie in den Steuerstatusinformationen konsolidiert.
Die Aggregationsoperation wird nach der durch die unbekannte Information
hervorgerufenen Verzögerung immer noch korrekt beendet, wenn das Zeitlimit abläuft.
Wenn Sie das Zeitlimit bei unbekannten Nachrichten auf null setzen, werden Antworten, die vor der Steuernachricht eingehen, direkt an das 'Unknown'-Terminal des Knotens für Aggregationsantworten weitergeleitet und nicht mit den restlichen Aggregationsdaten konsolidiert.
Option 3 sieht ähnlich dem folgenden abgeschnittenen Bild aus:
Der Rechenknoten 'AddMqmd' enthält eine ESQL ähnlich dem nachfolgenden Programmbeispiel, um zu ermöglichen, dass die Steuernachricht in eine Warteschlange geschrieben werden kann:
CREATE COMPUTE MODULE AggregationOut_AddMqmd
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET OutputRoot = InputRoot;
CREATE NEXTSIBLING OF OutputRoot.Properties DOMAIN 'MQMD';
SET OutputRoot.MQMD.StrucId = MQMD_STRUC_ID;
SET OutputRoot.MQMD.Version = MQMD_CURRENT_VERSION;
RETURN TRUE;
END;
END MODULE;
Sie sollten den Transaktionsmodus des MQEmpfangsknotens auf dem Verteilernachrichtenfluss auf Yes (Ja) setzen, um zu verhindern, dass Antwortnachrichten vom Sammelnachrichtenfluss empfangen werden, bevor die Steuerinformationen vom Knoten zur Aggregationssteuerung gespeichert wurden.
Wenn der Verteilernachrichtenfluss nicht unter Transaktionssteuerung durchgeführt wird, kann jede Anforderungsnachricht für Aggregationsausgaben, die von den MQSendeknoten geschrieben wurde, unmittelbar von der aufgerufenen Anwendung zur Verarbeitung aufgerufen werden. Es hängt von der Antwort dieser Anwendung ab, ob diese vom Knoten für Aggregationsantworten empfangen wird, bevor die Steuerinformationen gespeichert wurden.
Dasselbe Problem kann auftreten, wenn das Steuerterminal des Knotens zur Aggregationssteuerung über eine Wire-Verbindung mit dem Rechenknoten und einem MQSendeknoten verbunden ist, was bedeutet, dass die Eingabe- und Ausgabeflüsse aus verschiedenen Nachrichtenflüssen kommen. Selbst wenn die Ausgabe während einer Transaktion vorgenommen wurde, umfasst die Transaktion das Schreiben der Nachricht durch den MQSendeknoten. Antworten können somit weiterhin als unbekannt verarbeitet werden, während der Steuerungsabschnitt des Sammelnachrichtenflusses verarbeitet wird. Dieses Problem wird im obigen Abschnitt zu Option 3 beschrieben.
In beiden Fällen wird die Aggregation weiterhin korrekt beendet, wenn das Zeitlimit bei unbekannten Nachrichten auf dem Knoten für Aggregationsantworten ungleich null ist. Unbekannte Antworten werden gespeichert und dann entsprechend der angegebenen Anzahl an Sekunden erneut verarbeitet. An diesem Punkt werden sie in den Steuerstatusinformationen konsolidiert. Die Aggregationsoperation wird nach der durch die unbekannte Nachricht hervorgerufenen Verzögerung immer noch korrekt beendet, wenn das Zeitlimit abläuft. Wenn Sie das Zeitlimit bei unbekannten Nachrichten auf null setzen, werden Antworten, die vor der Steuernachricht eingehen, direkt an das 'Unknown'-Terminal des Knotens für Aggregationsantworten weitergeleitet und nicht mit den restlichen Aggregationsdaten konsolidiert.
Zusammenfassend sollte für einen effizienten Aufbau eines Aggregationsverteilernachrichtenflusses Folgendes sichergestellt werden:
Wenn Sie diese zwei Empfehlungen zum Aufbau befolgen, wird sichergestellt, dass Zeitlimitprobleme, wie oben beschrieben, nicht auftreten. Wenn es jedoch aus irgendeinem Grund nicht möglich ist, diese Empfehlungen zu befolgen, können Sie auch den Parameter für das Zeitlimit bei unbekannten Nachrichten auf dem Knoten für Aggregationsantworten auf einen Wert ungleich null setzen, damit die Aggregationsoperationen erfolgreich beendet werden.
Der Knoten für Aggregationsantworten besitzt drei fehlerfreie Ausgabeterminals: Out, Unknown und Timeout. Es ist wichtig, zu wissen, wann und warum Nachrichten von diesen Terminals gesendet werden. Dabei muss vor allem der transaktionale Zusammenhang beachtet werden. Der transaktionale Zusammenhang gehört entweder dem MQEmpfangsknoten (dies tritt ein, wenn eine eingehende Antwortnachricht die Ausgabe vom Knoten für Aggregationsantworten auslöst), oder er gehört dem Knoten für Aggregationsantworten selbst.
Wenn er dem Knoten für Aggregationsantworten gehört, hat der transaktionale Kontext die übliche Semantik, die transaktionale Steuerung wird jedoch eher auf dem Knoten für Aggregationsantworten als auf dem MQEmpfangsknoten zentriert. Dies hat zur Folge, dass durch einen Fehler, der später im Nachrichtenfluss auftritt, der Knoten für Aggregationsantworten rückgängig gemacht wird, und eine Nachricht an dessen Catch-Terminal anstatt an den MQEmpfangsknoten weitergegeben wird. Nachrichten, die vom Knoten für Aggregationsantworten im Rahmen seiner eigenen Transaktionen weitergegeben werden, werden nicht direkt vom MQEmpfangsknoten geliefert; der Knoten für Aggregationsantworten ist der Eingabeknoten für diesen Flussaufruf.
Das transaktionale Verhalten des Knotens für Aggregationsantworten wird von seinem Konfigurationsparameter für den Transaktionsmodus kontrolliert. Sie sollten sicherstellen, dass diese Einstellung und die Einstellung auf dem MQEmpfangsknoten gleich sind, damit sich alle Ausgaben des Knotens für Aggregationsantworten auf derselben Ebene der transaktionalen Steuerung befinden.
Folgende Situationen unterliegen der transaktionalen Steuerung des MQEmpfangsknotens:
Folgende Situationen unterliegen der transaktionalen Steuerung des Knotens für Aggregationsantworten:
Der Knoten für Aggregationsantworten hat zwei Eingabeterminals: das Eingangs- und das Steuerungsterminal.
Wenn Sie beide Terminals verwenden, (die Verwendung des Steuerterminals ist bekanntlich optional),
ist es zum Liefern von Daten an den Knoten für Aggregationsantworten am effizientesten, einen einzelnen
MQEmpfangsknoten für den Verteilernachrichtenfluss, gefolgt von einem Filter, zu verwenden.
Der Filterknoten wird verwendet, um eine eingehende Nachricht entsprechend an die Eingangs- oder Steuerterminals
des Knotens für Aggregationsantworten weiterzuleiten. Diese Methode ist besser als die Verwendung von
zwei MQEmpfangsknoten im Nachrichtenfluss, d. h. einen für das Eingangs- und einen
für das Steuerterminal.
Der Sammelnachrichtenfluss sollte wie folgt aussehen:
Der Filterknoten benötigt ein ESQL-Modul ähnlich dem unten dargestellten, um sicherzustellen, dass die Nachrichten an das entsprechende Terminal des Knotens für Aggregationsantworten weitergeleitet werden:
CREATE FILTER MODULE FanIn_Filter
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
IF Root.XML.ComIbmAggregateControlNode IS NULL THEN
RETURN TRUE; -- wired to In
ELSE
RETURN FALSE; -- wired to Control
END IF;
END;
END MODULE;
Sie sollten einen einzelnen MQEmpfangsknoten verwenden, da es nicht möglich ist, festzulegen, wie zusätzliche Threads (durch die Verwendung von zusätzlichen Instanzen verfügbar) zwischen den zwei MQEmpfangsknoten verteilt werden sollen. Der Datenverkehr auf dem Eingangsterminal des Knotens für Aggregationsantworten ist wahrscheinlich stärker. Deshalb ist es am sinnvollsten, wenn mehrere Threads in dessen Empfangsknoten aktiv sind. Dies kann jedoch nicht konfiguriert werden. Es ist daher möglich, dass der Knoten keine Threads mehr enthält und dann Antwortnachrichten sichert und den Aggregationsmechanismus blockiert.
Diese Beschreibung ist nur dann zutreffend, wenn das Steuerterminal des Knotens zur Aggregationssteuerung per Wire-Verbindung so verbunden ist, dass die Ausgabe in eine Warteschlange erfolgt. Wenn das Steuerterminal nicht per Wire-Verbindung verbunden ist, können Sie die in diesem Abschnitt behandelten Probleme übergehen.
Als letzte Maßnahme können Sie, wenn obige Lösung aus irgendeinem Grund nicht durchgeführt werden kann, den MQEmpfangsknoten, der Steuernachrichten liest, zur Einzel-Thread-Ausführung zwingen. Dies kann im Fenster 'Advanced' des MQEmpfangsknotens durchgeführt werden, indem Sie den Modus 'Order' (Reihenfolge) auf By Queue Order (Nach WS-Reihenfolge) setzen und 'Logical Order' (Logische Reihenfolge) auswählen. Dadurch werden alle zusätzlichen konfigurierten Instanzen, die vom anderen MQEmpfangsknoten verwendet werden sollen, freigegeben. Dies sollten Sie erst als letzte Maßnahme durchführen, da die Leistungsfähigkeit des ersten MQEmpfangsknotens dadurch stark eingeschränkt wird.