Eine Aggregation ist die Generierung und Verteilung zusammengehöriger Anforderungen, die von einer einzelnen Eingabenachricht abgeleitet sind, sowie das Sammeln der entsprechenden Antworten, um eine einzelne zusammengefasste Antwortnachricht zu erstellen.
Die ursprüngliche vom Nachrichtenfluss erhaltene Anforderung, die eine Sammlung zusammengehöriger Anforderungselemente darstellt, wird in die entsprechende Anzahl an individuellen Anforderungen aufgeteilt, um den Subtasks der ursprünglichen Anforderung gerecht zu werden. Dieser Prozess wird als Verteilung bezeichnet und von einem Nachrichtenfluss zur Verfügung gestellt, der Aggregationsknoten enthält.
Die Antworten der Subtasks werden kombiniert und zu einer einzelnen Antwort zusammengefügt, die an den ursprünglichen Requester (oder eine andere Zielanwendung) zurückgegeben wird , um den Abschluss der Verarbeitung anzuzeigen. Dieser Prozess wird als Sammlung bezeichnet und ebenfalls von einem Nachrichtenfluss zur Verfügung gestellt, der Aggregationsknoten enthält.
Eine Nachrichtenaggregation wird durch einen Nachrichtenfluss eingeleitet, der den AggregateControl-Knoten gefolgt von einem AggregateRequest-Knoten enthält. Die Antworten werden wieder mithilfe eines Flusses zusammengefasst, der den AggregateReply-Knoten enthält. Die Aggregationsknoten funktionieren nur richtig bei Transportmethoden, in denen ein Anforderungs-/Antwortmodell genutzt wird. Beispiel: WebSphere MQ Enterprise Transport.
Wenn Sie diese Knoten in Ihre Nachrichtenflüsse einfügen, werden parallel innerhalb eines Nachrichtenflusses diese Mehrfach-Verteileranforderungen ausgegeben. Bei der Standardoperation des Nachrichtenflusses führt jeder Knoten nacheinander seine Verarbeitung aus.
Wenn Sie WebSphere MQ Enterprise Transport verwenden, muss es sich bei den vom Sammelnachrichtenfluss empfangenen Antworten um gültige Antwortnachrichten handeln, die die Antwort-ID enthalten. Sie müssen die Antwort-ID auf den Wert der Nachricht im Nachrichtendeskriptor (MQMD) der Anforderungsnachricht setzen und dann die Antwort-ID im Feld für die Korrelations-ID (CorrelId) des MQMD speichern. Wenn die CorrelId auf MQCI_NONE gesetzt wird, gibt der AggregateReply-Knoten einen Fehler aus, da die Antwortnachricht nicht gültig ist und keiner Anforderungsnachricht zugeordnet werden kann.
Mit diesen Aggregationsknoten können Sie auch Anforderungen an Anwendungen außerhalb der Brokerumgebung ausgeben. Nachrichten können asynchron an externe Anwendungen oder Services gesendet; die Antworten von diesen Anwendungen abgerufen und kombiniert werden, um eine einzelne Antwort zur ursprünglichen Anforderungsnachricht bereitzustellen.
Diese Knoten können zu einer Verbesserung der Antwortzeiten beitragen, da langsame Antworten parallel ausgeführt werden können und nicht nacheinander verarbeitet werden müssen. Wenn die Subtasks unabhängig voneinander verarbeitet werden können und nicht als Teil einer einzelnen Arbeitseinheit gehandhabt werden müssen, können sie von individuellen Nachrichtenflüssen verarbeitet werden.
Sie können auch ohne die Verwendung von Aggregationsknoten einen Nachrichtenfluss entwickeln und konfigurieren, der eine ähnliche Funktion bereitstellt, indem Sie die Subtask-Anforderungen an eine andere Anwendung ausgeben (beispielsweise mit dem HTTPRequest-Knoten) und die Ergebnisse der einzelnen Anforderungen in der lokalen Umgebung aufzeichnen. Nach Beendigung jeder Subtask können Sie die Ergebnisse von der lokalen Umgebung in einem Compute-Knoten zusammenführen und die kombinierte Antwortnachricht für die Weitergabe an die Zielanwendung erstellen. Alle Subtasks werden jedoch nacheinander ausgeführt und bieten die Leistungsvorteile der Parallelverarbeitung nicht, die mithilfe der Aggregationsknoten genutzt werden können.
Die Aggregationsknoten speichern den Status für Aggregationen in WebSphere MQ-Warteschlangen. Wenn Sie im AggregateControl-Knoten kein Zeitlimit angeben oder den Wert null übernehmen, werden die von WebSphere MQ intern gespeicherten Aggregationsanforderungen erst bereinigt, wenn alle Antwortnachrichten zurückgegeben wurden. Diese Situation kann nach und nach zu einem Rückstau von Nachrichten in den internen Warteschlangen führen. Legen Sie für das Zeitlimit einen Wert größer als null fest, um sicherzustellen, dass Anforderungen bereinigt werden und die Warteschlangen nicht mit überflüssigen Anforderungen überhäuft werden. Es hat sich bewährt, einen hohen Zeitlimitwert festzulegen, beispielsweise 86400 Sekunden (24 Stunden), damit die Warteschlangen gelegentlich von alten Aggregationen bereinigt werden. Dies wird auch dann empfohlen, wenn keine Zeitlimits erforderlich sind oder erwartet werden.
Die Aggregationsknoten verwenden die Nachrichtenverfallszeit von WebSphere MQ, um Zeitlimits bei Nachrichten zu verwalten. Damit der Verfall von Nachrichten funktioniert, müssen die Nachrichtenwarteschlangen von den Aggregationsknoten durchsucht werden. Die Aggregationsknoten durchsuchen die Warteschlangen automatisch, um sicherzustellen, dass abgelaufene Nachrichten verarbeitet werden.
Unter z/OS können Sie WebSphere MQ für die Ausführung eines Scavenger-Prozesses konfigurieren, der anstelle der Aggregationsknoten die Warteschlangen durchsucht. Um den Scavenger-Prozess zu aktivieren, geben Sie für die Eigenschaft EXPRYINT des Broker-WS-Managers den Wert 5 Sekunden an. Wenn für EXPRYINT entweder kein Wert oder ein höherer Wert als 10 Sekunden angegeben wird, werden die Aggregationsknoten auf die Einstellung zurückgesetzt, bei der sie die Aggregationswarteschlangen automatisch durchsuchen.