Questo argomento si applica solo se il terminale Control del nodo AggregateControl nel flusso fan-out è connesso per emettere messaggi di controllo in una coda. Se non si connette il terminale Control si possono ignorare gli argomenti trattati in questa sezione. Per ulteriori informazioni sulla connessione del terminale Control del nodo AggregateControl, consultare Utilizzo dei messaggi di controllo nei flussi di aggregazione.
Il nodo AggregateReply ha due terminali di input: In e Control. Se si utilizzano entrambi questi terminali, ricordando che l'utilizzo del terminale Control è facoltativo, il modo più efficace per fornire dati al nodo AggregateReply è quello di avere un singolo nodo MQInput per il flusso fan-in seguito da un nodo Filter. Il nodo Filter viene utilizzato per instradare un messaggio in entrata ai terminali In o Control del nodo AggregateReply, come appropriato.
Utilizzare un singolo MQInput seguito da un nodo Filter invece di due nodi MQInput nel flusso di messaggi: uno per il terminale In e uno per il terminale Control. Si consiglia di utilizzare un singolo nodo MQInput poiché non c'è modo di specificare quanti thread aggiuntivi (resi disponibili dall'utilizzo di istanze aggiuntive) andrebbero distribuiti tra i due nodi MQInput. Ci sono buone probabilità che il traffico sul terminale In del nodo AggregateReply sia maggiore, quindi è utile disporre di più thread in esecuzione sul nodo di input e non è possibile attuare questa configurazione utilizzando due nodi MQInput. Può accadere quindi che il nodo si trovi ad essere privo di thread ed esegua il backup dei messaggi di replica e blocchi il meccanismo di aggregazione.
CREATE FILTER MODULE FanIn_Filter CREATE FUNCTION Main() RETURNS BOOLEAN BEGIN IF Root.XML.ComIbmAggregateControlNode IS NULL THEN RETURN TRUE; -- trasmesso via cavo al terminale In ELSE RETURN FALSE; -- trasmesso via cavo al terminale Control END IF; END; END MODULE;