Hier wird beschrieben, wie der bereitgestellte Aggregationsfluss entsprechend verschiedenen Anforderungen geändert wird. Der angegebene Mustercode ist auch hilfreich, wenn Sie vorhandene Aggregationsflüsse der Produktversion 5 oder früher portieren.
Das Steuerterminal des AggregateControl-Knotens wird verwendet, um die Steuernachricht, die die Status- und Überwachungsinformationen für eine bestimmte Aggregationsoperation enthält, weiterzugeben. Es bestehen folgende Optionen zum Herstellen einer Wire-Verbindung für das Steuerterminal:
Sie müssen Folgendes beachten, wenn Sie eine der Optionen auswählen:
In einigen Situationen treffen die für Option 3 genannten Leistungs- und Verhaltenseinschränkungen möglicherweise nicht zu, z. B., wenn die Verarbeitung einer Verteileranforderungsnachricht sehr schnell ist und gleichzeitig die Übergabe vom Steuerterminal des AggregateControl-Knotens durch die Verarbeitung im Rechenknoten verzögert wird. Dies kann zu einem Problem bei der Verarbeitung des AggregateReply-Knotens führen.
Die Aggregation wird jedoch trotzdem korrekt beendet, wenn das Zeitlimit bei unbekannten Nachrichten auf dem AggregateReply-Knoten ungleich null ist. In diesem Fall werden unbekannte Antworten gespeichert, nach Ablauf des Zeitlimits erneut verarbeitet und dann in den Steuerstatusinformationen konsolidiert. Die Aggregationsoperation wird nach Ablauf der durch das Zeitlimit bei unbekannten Nachrichten hervorgerufenen Verzögerung immer noch korrekt beendet.
Wenn Sie das Zeitlimit bei unbekannten Nachrichten auf null setzen, werden Antworten, die vor der Steuernachricht eingehen, direkt an das 'Unknown'-Terminal des AggregateReply-Knotens 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 Beispiel, 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.Version = MQMD_CURRENT_VERSION;
RETURN TRUE;
END;
END MODULE;
Sie müssen den Transaktionsmodus des MQInput-Knotens im Verteilernachrichtenfluss auf Yes (Ja) setzen, um zu verhindern, dass Antwortnachrichten vom Sammelnachrichtenfluss empfangen werden, bevor die Steuerinformationen vom AggregateControl-Knoten gespeichert wurden.
Wird der Verteilernachrichtenfluss nicht transaktionsgesteuert ausgeführt, kann jede vom MQOutput-Knoten geschriebene Anforderungsnachricht für eine Aggregationsverteilung sofort von der Anwendung verarbeitet werden, die aufgerufen wird. Es hängt von der Antwort dieser Anwendung ab, ob diese vom AggregateReply-Knoten empfangen wird, bevor die Steuerinformationen gespeichert wurden.
Dasselbe Problem kann auftreten, wenn das Steuerterminal des AggregateControl-Knotens über eine Wire-Verbindung mit dem Rechenknoten und einem MQOutput-Knoten verbunden ist, was bedeutet, dass die Verteiler- und Sammelnachrichtenflüsse zu verschiedenen Nachrichtenflüssen gehören. Selbst wenn die Verteilung innerhalb einer Transaktion erfolgt, besteht diese Transaktion aus dem Schreiben der Nachricht durch den MQOutput-Knoten; daher können Anworten nach wie vor bei der Verarbeitung des Steuerungszweigs des Verteilernachrichtenflusses als unbekannt verarbeitet werden. Dieses Problem wird im vorhergehenden Abschnitt zu Option 3 beschrieben.
Die Aggregation wird jedoch in beiden Fällen trotzdem korrekt beendet, wenn das Zeitlimit bei unbekannten Nachrichten auf dem AggregateReply-Knoten ungleich null ist. Unbekannte Antworten werden gespeichert, nach Ablauf der angegebenen Anzahl an Sekunden erneut verarbeitet und dann in den Steuerstatusinformationen konsolidiert. Die Aggregationsoperation wird nach Ablauf der durch das Zeitlimit bei unbekannten Nachrichten hervorgerufenen Verzögerung immer noch korrekt beendet. Wenn Sie das Zeitlimit bei unbekannten Nachrichten auf null setzen, werden Antworten, die vor der Steuernachricht eingehen, direkt an das 'Unknown'-Terminal des AggregateReply-Knotens weitergeleitet und nicht mit den restlichen Aggregationsdaten konsolidiert.
Zusammenfassend muss für einen effizienten Aufbau eines Aggregationsverteilernachrichtenflusses Folgendes sichergestellt sein:
Bei Verwendung der effizientesten Lösung wird sichergestellt, dass die oben beschriebenen Zeitlimitprobleme nicht auftreten. Wenn es jedoch nicht möglich ist, diese Optionen zu verwenden, können Sie dennoch den Parameter Zeitlimit bei unbekannten Nachrichten des AggregateReply-Knotens auf einen Wert ungleich null setzen, damit die Aggregationsoperationen erfolgreich beendet werden.
Der AggregateReply-Knoten 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, auch Transaktionskontext genant, gehört entweder dem MQInput-Knoten (wenn eine eingehende Antwortnachricht die Ausgabe vom AggregateReply-Knoten auslöst) oder dem AggregateReply-Knoten selbst.
Wenn er dem AggregateReply-Knoten gehört, hat der Transaktionskontext die übliche Semantik, die transaktionale Steuerung wird jedoch eher auf dem AggregateReply-Knoten als auf dem MQInput-Knoten zentriert. Dies hat zur Folge, dass durch einen Fehler, der später im Nachrichtenfluss auftritt, der AggregateReply-Knoten rückgängig gemacht wird, und eine Nachricht an dessen Catch-Terminal anstatt an den MQInput-Knoten weitergegeben wird. Nachrichten, die vom AggregateReply-Knoten im Rahmen seiner eigenen Transaktionen weitergegeben werden, werden nicht direkt vom MQInput-Knoten geliefert; der AggregateReply-Knoten ist der Empfangsknoten für diesen Flussaufruf.
Das transaktionale Verhalten des AggregateReply-Knotens wird von seinem Konfigurationsparameter Transaktionsmodus kontrolliert. Sie sollten sicherstellen, dass diese Einstellung und die Einstellung auf dem MQInput-Knoten gleich sind, damit sich alle Ausgaben des AggregateReply-Knotens auf derselben Ebene der transaktionalen Steuerung befinden.
Folgende Situationen unterliegen der transaktionalen Steuerung des MQInput-Knotens:
Folgende Situationen unterliegen der transaktionalen Steuerung des AggregateReply-Knotens:
Der AggregateReply-Knoten hat zwei Eingabeterminals: das Eingangs- und das
Steuerterminal.
Wenn Sie beide Terminals verwenden, (die Verwendung des Steuerterminals
ist bekanntlich optional), ist es zum Liefern von Daten an den AggregateReply-Knoten am
effizientesten, einen einzelnen MQInput-Knoten 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 AggregateReply-Knotens
weiterzuleiten. Diese Methode ist besser als die Verwendung von
zwei MQInput-Knoten im Nachrichtenfluss, d. h. einen für das Eingangs- und einen
für das Steuerterminal. Der Sammelnachrichtenfluss sollte wie in folgendem
Diagramm aussehen:
Der Filterknoten benötigt ein ESQL-Modul ähnlich dem im Beispiel dargestellten, um
sicherzustellen, dass die Nachrichten an das entsprechende Terminal des
AggregateReply-Knotens weitergeleitet werden:
CREATE FILTER MODULE FanIn_Filter
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
IF Root.XMLNSC.ComIbmAggregateControlNode IS NULL THEN
RETURN TRUE; -- wired to In
ELSE
RETURN FALSE; -- wired to Control
END IF;
END;
END MODULE;
Sie müssen einen einzigen MQInput-Knoten verwenden, da nicht angegeben werden kann, wie zusätzliche Threads (die durch den Einsatz zusätzlicher Instanzen verfügbar gemacht werden) zwischen den beiden MQInput-Knoten verteilt werden müssen. Das Datenaufkommen im Eingangsterminal des AggregateReply-Knotens ist wahrscheinlich höher, daher ist die Verwendung weiterer Threads im Empfangsknoten dieses Knotens sinnvoll, allerdings ist keine Konfiguration dieses Szenarios möglich. Es ist daher möglich, dass der Knoten keine Threads mehr enthält und dann Antwortnachrichten sichert und den Aggregationsmechanismus blockiert.
Dies trifft nur zu, wenn das Steuerterminal des AggregateControl-Knotens Ausgaben per Wire-Verbindung in eine Warteschlange schreibt. Diese Probleme treten nicht auf, wenn das Steuerterminal nicht per Wire-Verbindung verbunden ist.
Kann die oben angeführte Lösung nicht umgesetzt werden, können Sie erzwingen, dass der MQInput-Knoten, der die Steuernachrichten liest, im Einzel-Thread-Modus aktiv ist:
Allerdings wird die Leistung des ersten MQInput-Knotens durch diese Konfiguration erheblich beeinträchtigt.