Mustercode 'Aggregation' erweitern

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.

Aggregationsstatussteuerung bei der Ausgabe

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:

  1. Belassen Sie es ohne Wire-Verbindung.
  2. Stellen Sie eine direkte Wire-Verbindung zum Steuerungs-Eingabeterminal des AggregateReply-Knotens her. Eine direkte Verbindung ist nur möglich, wenn sich beide Knoten im selben Nachrichtenfluss befinden.
  3. Verbinden Sie es mit einem MQOutput-Knoten und fügen Sie mithilfe eines Rechenknotens einen MQMD hinzu, der die Steuernachricht in eine benutzerdefinierte Warteschlange schreibt. Der entsprechende AggregateReply-Knoten, der möglicherweise in einem separaten Fluss vorhanden ist, verfügt über einen MQInput-Knoten, der von dieser Warteschlange liest, die über eine Wire-Verbindung mit ihrem Steuerterminal verbunden ist. Vorhandene Aggregationsflüsse der Produktversion 5 und früher funktionieren möglicherweise auf diese Weise.

Sie müssen Folgendes beachten, wenn Sie eine der Optionen auswählen:

Transaktionen bei der Ausgabe verwalten

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.

Transaktionaler Zusammenhang beim Eingang

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:

Threadblockierung bei Ausgang verhindern

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:
Abgeschnittener Sammelnachrichtenfluss mit Filter
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:

  1. Setzen Sie die Option Modus für Reihenfolge im Fenster 'Erweitert' der MQInput-Knotenkonfiguration auf Nach WS-Reihenfolge.
  2. Wählen Sie Logische Reihenfolge aus; dadurch werden alle zusätzlichen konfigurierten Instanzen freigegeben und können vom zweiten MQInput-Knoten verwendet werden.

Allerdings wird die Leistung des ersten MQInput-Knotens durch diese Konfiguration erheblich beeinträchtigt.

Zurück zum Beginn des Mustercodes