Progettazione delle applicazioni Telemetry

Quando viene creato un flusso per i messaggi provenienti da client Telemetry, è necessario includere almeno un nodo SCADAInput. Configurare le proprietà per definire la porta di ascolto dei nuovi messaggi. Se il flusso di messaggi invia messaggi a client Telemetry, è necessario includere un nodo Publication oppure SCADAOutput (il nodo Publication include un nodo integrato SCADAOutput).

E' necessario distribuire i flussi di messaggi in cui sono contenuti i nodi SCADAInput e SCADAOutput per ogni singolo gruppo di esecuzione all'interno di un broker. Se vengono inviati messaggi a client Telemetry mediante un nodo Publication, è necessario che il flusso di messaggi in cui è contenuto tale nodo sia nello stesso gruppo di esecuzione del nodo SCADAInput, anche se non si dispone di un flusso di messaggi che riceve messaggi da client Telemetry. Ciò si verifica poiché le proprietà del nodo SCADAInput identificano la porta TCP/IP utilizzata per la comunicazione con i client e le caratteristiche di gestione dei messaggi.

Arresto e avvio dei listener

Avviare e arrestare un listener WebSphere MQ Telemetry Transport mediante un messaggio di pubblicazione con l'argomento $SYS/SCADA/MQIsdpListener/<numero porta>. Impostare la parte payload della serie di messaggi su ON oppure su OFF. Sostituire la parte <numero_porta> con la porta singola che si desidera avviare o arrestare oppure con il valore tutte per avviare o arrestare tutte le porte del sistema definite come porte SCADA.

Miglioramento della gestione dei messaggi

Il numero di messaggi gestiti da un flusso di messaggi dipende dalla velocità dei messaggi e dai tempi di risposta. Consultare le istruzioni guida in Ottimizzazione dei tempi di riposta del flusso di messaggi e Ottimizzazione della velocità di trsmissione del flusso di messaggi. Considerare inoltre la qualità del servizio scelta per i messaggi ricevuti da o pubblicati per client Telemetry, disponibile in in Scelta della qualità del servizio.

Scelta della qualità del servizio

La qualità del servizio determina l'affidabilità della consegna del messaggio. Esaminare le circostanze dei messaggi elaborati; in alcune situazioni è accettabile la perdita di messaggi. In altre situazioni è invece necessario che la consegna dei messaggi sia garantita. Le opzioni relative alla qualità del servizio, vale a dire QoS0, QoS1 e QoS2, sono descritte in Flussi e livelli di QoS di WebSphere MQ Telemetry Transport.

Se si sceglie di garantire la consegna dei messaggi, è necessario che il broker esegua operazioni aggiuntive per proteggere il messaggio finché non si è certi che sia stato consegnato. Tale procedura influenza le prestazioni del broker e del client e sarà necessario bilanciare le necessità relative alla velocità di elaborazione del messaggio con le necessità di garantire la consegna dei messaggi.

Se viene scelta l'opzione QoS1 oppure l'opzione QoS2, che indicano che il messaggio venga consegnato almeno o soltanto una volta, è necessario che il broker e il client forniscano un livello determinato di riconoscimento. E' necessario che il broker memorizzi il messaggio in modo da inviarlo nuovamente nel caso in cui non vengano ricevuti riconoscimenti appropriati.

Il broker memorizza i messaggi nel database. E' possibile che tale procedura influenzi la gestione dei messaggi nel caso in cui il broker non sia in grado di completare l'input nel database o la relativa emissione quando necessario; in tal caso, è possibile che il broker arresti l'elaborazione dei messaggi. Se il database del broker è DB2, disattivare il blocco della chiave successiva di DB2 per evitare problemi relativi a blocchi critici (deadlock). Per effettuare tale modifica immettere il seguente comando nell'apposita finestra di DB2:

db2set DB2_RR_TO_RS=YES

Per rendere effettive le modifiche, riavviare il gestore database DB2.

Se viene scelta l'opzione QoS0, la consegna dei messaggi non sarà garantita. Il broker non memorizzerà i messaggi.

Informazioni particolari | Marchi | Download | Libreria | Supporto | Commenti
Copyright IBM Corporation 1999, 2006 Ultimo aggiornamento: ago 17, 2006
ac23510_