Creazione del flusso fan-out di aggregazione

Il flusso fan-out di aggregazione riceve il messaggio di input iniziale e lo ristruttura per presentare un certo numero di richieste ad un certo numero di applicazioni di destinazione.

Prima di iniziare:

Per completare questa attività, è necessario completare prima quella che segue:

Si consiglia di leggere anche la panoramica relativa all'Aggregazione del flusso di messaggi, prima di completare questa attività.

E' possibile includere il flusso fan-out e fan-in nello stesso flusso di messaggi. Tuttavia si consiglia di creare due flussi separati. Per ulteriori informazioni sui vantaggi di configurare flussi di messaggi separati, consultare Associazione dei flussi di aggregazione fan-out e fan-in.

Per esaminare un esempio di flusso fan-out, consultare l'Esempio Prenotazioni per compagnie aeree fornito con WebSphere Message Broker.

Per creare il flusso fan-out:

  1. Passare alla Prospettiva Sviluppo dell'applicazione broker.
  2. Creare un nuovo flusso di messaggi per fornire l'elaborazione del fan-out.
  3. Aggiungere i seguenti nodi nella vista dell'editor, quindi configurarli e connetterli come descritto:
    Nodo di input
    Il nodo di input riceve un messaggio di input da cui sono generati più messaggi di richiesta. Questo nodo può essere uno qualsiasi dei nodi integrati o un nodo di input definito dall'utente.
    1. Fare clic con il tasto destro del mouse sul nodo di input e fare clic su Proprietà.
    2. Specificare l'origine dei messaggi di input per questo nodo. Ad esempio, specificare il nome di una coda WebSphere MQ nella proprietà Base Nome coda da cui il nodo MQInput richiama i messaggi.
    3. Facoltativo: specificare i valori per qualsiasi altra proprietà che si desideri configurare per questo nodo. Si consiglia di impostare la proprietà Avanzata Modalità transazione sul valore predefinito, Sì, per assicurarsi che i messaggi di richiesta di aggregazione siano inseriti nel punto di sincronizzazione. Questo eviterà una situazione in cui il nodo AggregateReply riceva messaggi di risposta prima di aver ricevuto il messaggio di controllo che lo informa dell'istanza di aggregazione. Inserendo il flusso fan-out nel controllo transazionale si garantisce che il flusso fan-out sia completato prima che i messaggi di risposta arrivino al nodo AggregateReply.
    4. Connettere il terminale out del nodo di input al terminale di un nodo AggregateControl.

      Questa è la configurazione più semplice; se si ritiene opportuno, è possibile includere altri nodi tra il nodo di input e il nodo AggregateControl. Ad esempio, si potrebbe voler memorizzare la richiesta ai fini della revisione contabile (in un nodo Warehouse) o aggiungere un identificativo univoco al messaggio (in un nodo Compute).

    5. Facoltativo: se i flussi fan-out e fan-in sono combinati in uno stesso flusso di messaggi, è consigliabile modificare la proprietà Modalità ordine nella scheda Avanzate. Selezionare l'opzione Ordine per coda e assicurarsi che sia selezionata anche l'opzione Ordine logico. In questo modo si forza il nodo di input in modo che sia a thread singolo per mantenere l'ordine logico dei messaggi che arrivano nella coda. Questa operazione ha come risultato che tutti i thread delle istanze aggiuntive vengano resi disponibili, siano condivisi solo tra i nodi di input fan-in per migliorare le prestazioni dell'aggregazione. Se i flussi fan-in e fan-out si trovano in flussi di messaggi separati questo passo non è necessario poiché si possono rendere disponibili i thread in modo specifico per il flusso fan-in.
    Nodo AggregateControl
    Il nodo AggregateControl aggiorna la struttura LocalEnvironment associata al messaggio di input con le informazioni richieste dal nodo AggregateRequest.
    1. Fare clic con il tasto destro del mouse sul nodo AggregateControl e fare clic su Proprietà.
    2. Impostare la proprietà Nome aggregazione del nodo AggregateControl per identificare questa particolare aggregazione. Essa verrà utilizzata in seguito per associare questo nodo AggregateControl ad un nodo AggregateReply specifico. Il Nome aggregazione specificato deve essere contestualmente univoco all'interno di un broker.
    3. Facoltativo: impostare la proprietà Timeout per specificare quanto tempo il broker dovrà attendere l'arrivo delle repliche prima di intraprendere qualche azione (descritta in Impostazione dei timeout per l'aggregazione).

      Se il timeout non è impostato su AggregateControlNode allora le richieste di aggregazione conservate all'interno non saranno rimosse fino a che tutti i messaggi di risposta dell'aggregazione non saranno restituiti. Questa situazione può condurre ad un graduale inserimento dei messaggi nelle code interne. Per evitarla, impostare il timeout ad un valore diverso da zero (che significa mai timeout) così quando lo si raggiunge le richieste vengono rimosse e le code non verranno compilate con richieste ridondanti. Anche se i timeout non sono richiesti o previsti, è buona pratica impostare un valore molto ampio (ad esempio: 864000 secondi, ossia 24 ore) in modo che occasionalmente le code siano ripulite da vecchie aggregazioni.

    4. Connettere il terminale out del nodo AggregateControl al terminale in di uno o più nodi Compute responsabili dell'analisi e dell'insuccesso della richiesta nel messaggio di input che è trasmesso a questo terminale.
    Nota: Il terminale control del nodo AggregateControl è stato considerato obsoleto nella Versione 6.0 e, per impostazione predefinita, tutte le connessioni a questo terminale (dirette o indirette), verranno ignorate. Questo serve a rendere massima l'efficienza dei flussi di aggregazione e non compromette l'affidabilità delle aggregazioni. E' la configurazione ottimale.

    Tuttavia, se si desidera che un messaggio di controllo sia inviato dal nodo AggregateControl al nodo AggregateReply, è necessario connettere il terminale control al nodo AggregateReply corrispondente sul flusso fan-in (direttamente o indirettamente, come descritto in Associazione dei flussi di aggregazione fan-out e fan-in). Se lo si connette indirettamente al nodo AggregateReply, ad esempio tramite un nodo MQOutput, è necessario includere un nodo Compute per aggiungere le intestazioni appropriate al messaggio in modo da garantire che sia trasmesso in modo sicuro.

    In aggiunta, perché il terminale Control e le connessioni a partire da esso siano riconosciuti, è necessario abilitare la variabile di ambiente MQSI_AGGR_COMPAT_MODE. Tuttavia, la scelta di questa opzione ha delle implicazioni relative alle prestazioni e al funzionamento delle aggregazioni di messaggi. Per una descrizione completa di queste implicazioni e della variabile di ambiente, consultare Utilizzo dei messaggi di controllo nei flussi di aggregazione.

    Nodo Compute
    Il nodo Compute estrae le informazioni dal messaggio di input e crea un nuovo messaggio di output.

    Se le applicazioni di destinazione che gestiscono le richieste dell'attività secondaria possono estrarre le informazioni necessarie dal singolo messaggio di input, non si dovrà includere un nodo Compute per dividere il messaggio. E' possibile trasmettere l'intero messaggio di input a tutte le applicazioni di destinazione.

    Se le applicazioni di destinazione prevedono di ricevere una singola richiesta, non l'intero messaggio di input, è necessario includere un nodo Compute per creare ogni singolo messaggio di output dell'attività secondaria dal messaggio di input. Configurare ogni nodo Compute nel seguente modo, copiando la serie secondaria appropriata del messaggio di input in ogni messaggio di output.

    1. Fare clic con il tasto destro del mouse sul nodo Compute e fare clic su Proprietà.
    2. Selezionare un valore per la proprietà Base Modalità di calcolo. Questa proprietà specifica quali sezioni della struttura ad albero del messaggio sono modificate dal nodo.

      Il nodo AggregateControl inserisce elementi nella struttura ad albero LocalEnvironment nel messaggio di input che il nodo AggregateRequest legge quando il messaggio lo raggiunge. Assicurarsi che la struttura LocalEnvironment sia copiata dal messaggio di input al messaggio di output nel nodo Compute. Questo avviene automaticamente, a meno che non si specifichi un valore che includa LocalEnvironment (uno tra Tutto, LocalEnvironment, LocalEnvironment e Message o Exception e LocalEnvironment).

      Se si specifica uno di questi valori, il broker presuppone che si stia personalizzando il nodo Compute con ESQL che scrive in LocalEnvironment e che si copieranno tutti gli elementi presenti in quella struttura ad albero, richiesti nel messaggio di output.

      Se si desidera modificare LocalEnvironment, aggiungere la seguente istruzione per copiare le informazioni di aggregazione richieste dal messaggio di input al messaggio di output:

      SET OutputLocalEnvironment.ComIbmAggregateControlNode = 
                  InputLocalEnvironment.ComIbmAggregateControlNode;
    3. Facoltativo: specificare i valori per qualsiasi altra proprietà che si desideri configurare per questo nodo.
    4. Connettere il terminale out di ogni nodo Compute al terminale in del nodo di output che rappresenta la destinazione del messaggio di richiesta di output creato a partire dal messaggio di input in questo nodo.
    Nodo di output
    Includere un nodo di output per ogni messaggio di output che si genera nel flusso fan-out. Configurare ogni nodo come descritto di seguito, con le modifiche appropriate per ogni destinazione.

    Si deve trattare di un nodo di output che supporta il modello richiesta/replica, come ad esempio un nodo MQOutput o una combinazione di questi nodi (a seconda dei requisiti delle applicazioni di destinazione).

    1. Fare clic con il tasto destro del mouse sul nodo di output e fare clic su Proprietà.
    2. Specificare la destinazione per i messaggi di output per questo nodo. Ad esempio, specificare il nome di una coda WebSphere MQ nella proprietà Base Nome coda a cui il nodo MQOutput invia i messaggi. L'applicazione di destinazione deve elaborare la richiesta ed inviare la risposta alla destinazione di replica indicata nel relativo messaggio di input (ad esempio ReplyToQueue a WebSphere MQ).
    3. Fare clic su Richiesta nella vista di sinistra e impostare i valori per queste proprietà per specificare che le repliche siano inviate alla coda di input del flusso fan-in.
    4. Facoltativo: specificare i valori per qualsiasi altra proprietà che si desideri configurare per questo nodo.
    5. Connettere il terminale out del nodo di output al terminale in di un nodo AggregateRequest. Quando il messaggio è trasmesso tramite il terminale out del nodo di output, il nodo di output integrato aggiorna la cartella WrittenDestination nella struttura associata LocalEnvironment con le informazioni aggiuntive richieste dal nodo AggregateRequest.

      Le informazioni scritte dai nodi integrati sono il nome coda, il nome gestore code, l'ID messaggio e l'ID correlazione (da MQMD) e l'identificativo replica del messaggio (impostato sullo stesso valore dell'ID messaggio).

    Nodo AggregateRequest
    Includere un nodo AggregateRequest per ogni messaggio di output che si genera nel flusso fan-out.
    1. Fare clic con il tasto destro del mouse sul nodo di output e fare clic su Proprietà.
    2. Impostare la proprietà Base Nome cartella su un valore che identifichi il tipo di richiesta che è stata inviata. Tale valore è utilizzato dal nodo AggregateReply per la corrispondenza al messaggio di replica quando viene ricevuto nel flusso fan-in. Il nome della cartella specificato per ogni richiesta generata dal flusso fan-out deve essere univoco.

    Il nodo AggregateRequest scrive un record Inizio modificain WebSphere MQFine modifica per ogni messaggio che elabora. Questo fa sì che il nodo AggregateReply individui a quale richiesta è associata ogni risposta. Se i nodi di output sono di tipo non transazionale, il messaggio di risposta potrebbe arrivare al flusso fan-in prima che venga eseguito il commit di questo aggiornamento del database. Fare riferimento ad Impostazione dei timeout per l'aggregazione per dettagli su come utilizzare i timeout per scongiurare questa evenienza.

    Avvertenza:
    sebbene l'utilizzo dei timeout aiuti ad evitare la situazione sopra descritta, è preferibile assicurarsi che per i messaggi di risposta sia impossibile arrivare al flusso fan-in prima che i nodi AggregateRequest corrispondenti abbiano eseguito il commit degli aggiornamenti del database, rendendo i flussi fan-out transazionali.
  4. Premere Ctrl-S per salvare il flusso di messaggi e convalidarne la configurazione.
Per raccogliere le risposte di aggregazione inizializzate dal flusso fan-out, creare il proprio flusso fan-in, consultando Creazione del flusso fan-in di aggregazione.
Concetti correlati
Panoramica dei flussi di messaggi
Struttura ad albero LocalEnvironment
Aggregazione del flusso di messaggi
Nodi di input definiti dall'utente
Nodi di output definiti dall'utente
Attività correlate
Configurazione dei flussi di aggregazione
Creazione del flusso fan-in di aggregazione
Utilizzo dei messaggi di controllo nei flussi di aggregazione
Associazione dei flussi di aggregazione fan-out e fan-in
Impostazione dei timeout per l'aggregazione
Utilizzo di più nodi AggregateControl
Gestione delle eccezioni nei flussi di aggregazione
Progettazione di un flusso di messaggi
Creazione di un flusso di messaggi
Definizione del contenuto del flusso di messaggi
Creazione di più messaggi di output
Sviluppo di estensioni definite dall'utente
Riferimenti correlati
Nodo AggregateControl
Nodo AggregateReply
Nodo AggregateRequest
Nodo Compute
Nodo MQeInput
Nodo MQeOutput
Nodo MQInput
Nodo MQOutput
Informazioni particolari | Marchi | Download | Libreria | Supporto | Commenti
Copyright IBM Corporation 1999, 2006 Ultimo aggiornamento: ago 17, 2006
ac12290_