Se si decide di creare il gestore code separatamente, è necessario impostare una DLQ (dead letter queue/coda messaggi non recapitati). La DLQ viene utilizzata da WebSphere Message Broker quando si verificano errori durante l'elaborazione dei messaggi nei flussi di messaggi.
Se non è possibile elaborare un messaggio in un flusso di messaggi definito dall'utente oppure nel modello di pubblicazione/sottoscrizione, il messaggio viene indirizzato a tale DLQ come ultima risorsa. Se si preferisce ripristinare il messaggio allo stato precedente nella coda di input, arrestando effettivamente il flusso di messaggi fino a quando il problema non viene risolto, disabilitare la DLQ.
Il comando mqsideletebroker non elimina tale coda (a meno che il gestore code non venga eliminato).
Se si sta utilizzando un gestore code WebSphere MQ creato in modo indipendente dal comando mqsicreatebroker, è possibile definire dei cluster. Nella maggior parte dei casi, questa operazione semplifica la configurazione.
Se il gestore code è creato da questo comando, non viene avviato come servizio di Windows; per questo motivo, si arresta in caso di scollegamento. Per evitare che questo avvenga, è necessario restare collegati oppure modificare lo stato di avvio del servizio del gestore code. Se si blocca la stazione di lavoro, il gestore code WebSphere MQ non viene arrestato.
In z/OS, se si crea un nome del broker in maiuscolo, è necessario utilizzare tale nome in maiuscolo anche per il broker nel workbench.
Per le limitazioni relative all'insieme di caratteri che può essere utilizzato, consultare Caratteri consentiti nei comandi.Può essere specificato utilizzando qualsiasi sintassi di nome utente valida. Su piattaforme Windows tali sintassi sono:
Su sistemi Linux e UNIX, è valido solo l'ultimo formato, username.
Se si utilizza il formato non qualificato per questo ID utente (username) su piattaforme Windows, il sistema operativo ricerca l'ID utente nel proprio dominio, partendo dal sistema locale. Questa ricerca potrebbe impiegare alcuni minuti per essere completata.
Il ServiceUserID specificato deve essere un membro del gruppo locale mqbrkrs. Su piattaforme Windows, può essere un membro diretto o indiretto del gruppo. Il ServiceUserID, inoltre, deve essere autorizzato ad accedere alla directory home (in cui è stato installato WebSphere Message Broker) ed alla directory di lavoro (se specificata dall'indicatore -w).
Se, su piattaforme Windows, si specifica che il broker deve essere eseguito come applicazione sicura WebSphere MQ (indicatore -t), è necessario aggiungere tale ID utente al gruppo mqm. Su sistemi Linux e UNIX, specificare il ServiceUserID come mqm se si imposta l'indicatore -t.
I requisiti di sicurezza per il ServiceUserID sono illustrati in dettaglio in Requisiti di sicurezza per le piattaforme Windows.
Se si utilizza questo ID utente per l'accesso al database (non viene specificato un ID utente differente mediante l'indicatore -u) e si utilizza SQL Server per il proprio database, è necessario creare tale ID utente come ID di collegamento di SQL Server e fornire ad esso l'accesso corretto prima di creare il broker (consultare Sicurezza relativa ad un broker per ulteriori dettagli). Se il database del broker esiste in DB2 e tale ID utente non è riconosciuto da DB2, DB2 lo crea automaticamente.
Per la compatibilità con i sistemi esistenti, è sempre possibile specificare <password>. Tuttavia, se non si specifica una password mediante questo parametro quando si esegue il comando viene richiesto di immettere una password e di immettere la password una seconda volta per verificare che sia stata immessa correttamente.
Su sistemi Linux e UNIX, l'indicatore -a è richiesto per la compatibilità con le piattaforme Windows, ma non è utilizzato in relazione a ServiceUserID; viene utilizzato come impostazione predefinita solo se non è specificato -p. Per ulteriori dettagli, consultare le note relative al parametro -p.
Ciascun Broker richiede il proprio gestore code. Un broker non può condividere un gestore code con un altro broker.
Se il gestore code non esiste, viene creato da questo comando. Non viene creato però come gestore code predefinito; se si desidera che questo gestore code sia quello predefinito su questo sistema, è necessario o creare prima il gestore code e poi immettere il comando in questione o modificare le impostazioni di questo gestore code per impostarlo come predefinito. Utilizzare WebSphere MQ Explorer oppure lo snap-in dei Servizi WebSphere MQ, a seconda della versione di WebSphere MQ che si sta utilizzando.
L'attributo del gestore code MAXMSGLN (lunghezza massima dei messaggi che possono essere inseriti nelle code) è aggiornato a 100 MB. Questa operazione è eseguita indipendentemente dal fatto che il gestore code sia creato mediante questo comando.
Per le limitazioni relative all'insieme di caratteri che può essere utilizzato, consultare Caratteri consentiti nei comandi.
Tale database deve già esistere. E' necessario creare una connessione ODBC del DSN di sistema per questo DSN, se questa operazione non è già stata effettuata.
Se si dispone di un database DB2 in Linux, immettere il nome alias del database DB appropriato; non è necessario un DSN ODBC.
Tale ID utente deve disporre delle autorizzazioni per la creazione di tabelle all'interno di questo database e per la lettura e la scrittura in tali tabelle.
Su piattaforme Windows, se il database del broker esiste in DB2 e tale ID utente non è riconosciuto da DB2, viene creato automaticamente all'interno di DB2. Su sistemi Linux e UNIX, all'utente del servizio devono essere stati precedentemente concessi i privilegi corretti. Se il database è SQL Server, è necessario creare tale ID utente come ID di collegamento di SQL Server e fornire ad esso l'accesso corretto prima di creare il broker (per ulteriori dettagli, consultare Requisiti di sicurezza per le piattaforme Windows).
Se si dispone di un database dell'applicazione in DB2 creato da questo ID utente oppure per il quale questo ID utente dispone di autorizzazioni di lettura, scrittura o creazione appropriate, i flussi di messaggi in esecuzione in questo broker possono accedere ai dati dell'applicazione contenuti in tale database e e modificarli senza dover specificare i nomi dello schema espliciti.
Tale ID utente deve disporre delle autorizzazioni per la creazione di tabelle all'interno di questo database e per la lettura e la scrittura in tali tabelle.
Se si dispone di un database dell'applicazione in DB2 creato da questo ID utente oppure per il quale questo ID utente dispone di autorizzazioni di lettura, scrittura o creazione appropriate, i flussi di messaggi in esecuzione in questo broker possono accedere ai dati dell'applicazione contenuti in tale database e e modificarli senza dover specificare i nomi dello schema espliciti.
Per la compatibilità con i sistemi esistenti, è sempre possibile specificare <password>. Tuttavia, se non si specifica una password mediante questo parametro quando si esegue il comando viene richiesto di immettere una password e di immettere la password una seconda volta per verificare che sia stata immessa correttamente.
Per DB2 su sistemi Linux e UNIX, è possibile specificare -u e -p come stringhe vuote (due doppi apici ""). In questo caso, DB2 concede a WebSphere Message Broker i privilegi di ServiceUserID ed il risultato è una connessione al database "già verificata". Se si specifica -a come stringa vuota insieme a -u e -p, nessuna password viene memorizzata da WebSphere Message Broker, creando la configurazione più sicura.
Questa directory viene utilizzata anche per la traccia dei record creata quando la funzione di traccia è attiva. Tali record vengono scritti nella directory secondaria log, che deve essere creata prima di avviare il broker.
Le registrazioni degli errori scritte dal broker quando un processo termina in modo anomalo vengono memorizzate in questa directory. Su piattaforme Windows, utilizzare questa opzione per specificare una directory su un'unità diversa da quella in cui è installato il prodotto.
La registrazione degli errori non è limitata e continua ad espandersi. Controllare periodicamente la directory ed eliminare le informazioni di errore obsolete.
Non è possibile modificare questa opzione mediante il comando mqsichangebroker. Se si desidera specificare o modificare il percorso di lavoro, eliminare e creare nuovamente il broker.
Se si specifica questa opzione su piattaforme Windows, aggiungere il ServiceUserID (identificato dall'indicatore -i) al gruppo mqm. Se si specifica questa opzione su HP-UX e Solaris, specificare il ServiceUserID come mqm. Per ulteriori dettagli relativi all'utilizzo delle applicazioni sicure WebSphere MQ, consultare WebSphere MQ Intercommunication.
E' necessario creare la propria directory per la memorizzazione dei propri file .lil o .jar. Non salvarli nella directory di installazione di WebSphere Message Broker.
Se vengono specificate più directory, separarle utilizzando il separatore del percorso predefinito specifico della piattaforma (punto e virgola (;) su piattaforme Windows, due punti (:) su sistemi Linux e UNIX).
In questo percorso non è possibile includere variabili di ambiente: se vengono inserite, verranno ignorate.
Quando un flusso di messaggi elabora un messaggio dell'applicazione, non può rispondere ad una modifica alla configurazione. Se uno dei flussi di messaggi all'interno del gruppo di esecuzione a cui è stato richiesto di modificare la configurazione non termina l'elaborazione di un messaggio dell'applicazione ed applica la modifica alla configurazione entro tale timeout, il gruppo di esecuzione restituisce una risposta negativa al messaggio di configurazione distribuito.
Il valore impostato per questo timeout dipende dal carico del sistema (incluso l'utilizzo della CPU) e dal carico di ciascun gruppo di esecuzione. E' possibile effettuare una stima iniziale distribuendo l'intera configurazione del broker. Il tempo necessario per il completamento di tale operazione fornisce un'indicazione del valore minimo da impostare.
Il valore è specificato in secondi e può essere compreso tra 10 e 3600. Il valore predefinito è 300.
La somma di ConfigurationTimeout e ConfigurationDelayTimeout (descritto di seguito) rappresenta l'intervallo di tempo massimo durante il quale un broker può elaborare un messaggio di configurazione distribuito prima di generare una risposta negativa.
Rappresenta il tempo necessario per l'elaborazione di un messaggio di configurazione minimo distribuito da parte del broker e dai relativi gruppi di esecuzione e dipende dai ritardi della rete del gestore code, dal carico del gestore code del broker e dal carico del sistema.
mqsireporttrace brokerName -e "Execution Group Name" -u
F MQP1BRK,reporttrace u=yes,e='exgrp1'
Il tempo di risposta di ciascun gruppo di esecuzione è diverso in base al carico del sistema ed al carico dei propri processi. Il valore impostato deve riflettere il tempo di risposta più elevato necessario a ciascun gruppo di esecuzione per rispondere. Se il valore impostato è troppo basso, il broker restituisce una risposta negativa e potrebbe inviare messaggi di errore nella registrazione degli errori locale.
Il valore è specificato in secondi e può essere compreso tra 10 e 3600. Il valore predefinito è 60.
Se il broker si trova su un sistema di produzione, aumentare i valori di ConfigurationTimeout e ConfigurationDelayTimeout per consentire ai messaggi delle applicazioni elaborati dai flussi di messaggi di essere completati prima che venga applicata la modifica alla configurazione.
Se il broker si trova su un sistema di test o di sviluppo, è possibile che si desideri ridurre i timeout (in particolare ConfigurationTimeout) per migliorare i tempi di risposta e per forzare una risposta da un broker che non funziona nel modo previsto. Tuttavia, la riduzione dei valori di timeout diminuisce la probabilità di corretta distribuzione di una modifica alla configurazione.
Tale listener viene avviato dal broker quando viene avviato un flusso di messaggi che include il supporto dei servizi Web ed ha il valore predefinito 7080.
Verificare che la porta specificata non sia stata specificata per altri motivi.
Un intervallo di zero minuti indica che la piattaforma dispone di un metodo di notifica esterno e non utilizza un timer all'interno di WebSphere Message Broker.
Su sistemi Windows, l'ID utente utilizzato per richiamare questo comando deve disporre di autorizzazione Administrator sul sistema locale.
Su sistemi UNIX, l'ID utente utilizzato per richiamare questo comando deve essere un membro del gruppo mqbrkrs.
Su sistemi z/OS, l'ID utente utilizzato per richiamare questo comando deve essere un membro di un gruppo con accesso READ e WRITE alla directory del componente.
Utilizzo di LDAP: Verificare che il registro sia protetto in modo appropriato per impedire l'accesso non autorizzato. L'impostazione delle opzioni LdapPrincipal e LdapCredentials in mqsicreatebroker non è richiesta per il corretto funzionamento del broker. La password non è memorizzata in formato di testo leggibile nel file system.
L'autorizzazione di accesso viene concessa per il gruppo WebSphere Message Broker mqbrkrs a tutte le code indicate. Se è abilitata la DLQ, dispone della stessa autorizzazione.
Questo comando restituisce le seguenti risposte:
(51002)[IBM][CLI Driver][DB2/NT]SQL0805N Pacchetto "NULLID.SQLLF000" non trovato. SQLSTATE=51002.
Questo errore si verifica quando il bind al database non è corretto.
Su piattaforme Windows, il binding non è necessario per i database del broker ma è richiesto per i database utente. Se il database è stato creato utilizzando il Centro di controllo DB2, il bind viene completato automaticamente. Se si utilizza l'interfaccia di comandi, non viene completato automaticamente. Per il database MYDB, ad esempio, è possibile creare oppure creare nuovamente un bind immettendo i seguenti comandi da un prompt dei comandi:
db2 connect to MYDB user db2admin using db2admin db2 bind X:\sqllib\bnd\@db2cli.lst grant public db2 connect reset
dove X: è l'unità su cui è installato DB2.
Su piattaforme UNIX, il binding è necessario per tutti i database. Per il database WBRKBKDB, per esempio, è possibile effettuare questa operazione immettendo i seguenti comandi da un prompt dei comandi (dove <user_name> è l'ID utente in base al quale è stata creata l'istanza del database):
db2 connect to WBRKBKDB user db2admin using db2admin
db2 bind ~<user_name>/sqllib/bnd/@db2cli.lst grant public CLIPKG 5
db2 connect reset
Se non si utilizzano l'ID utente e la password DB2 predefiniti (db2admin), è necessario sostituire tali valori nel comando db2 connect con i valori corretti.
Se si esegue una seconda volta il comando mqsicreatebroker a causa di un errore visualizzato alla prima esecuzione, viene visualizzata una serie di messaggi. Tali messaggi indicano gli elementi che non possono essere creati. Come risultato, non dovrebbero verificarsi effetti negativi. Ad esempio, fintantoché la causa del primo errore è stata risolta, il tentativo di creazione di un broker non riuscito la prima volta dovrebbe dare come risultato un broker creato correttamente.
mqsicreatebroker WBRK_BROKER -i wbrkuid -a wbrkpw -q WBRK_QM -s WBRK_UNS_QM -n WBRKBKDB
mqsicreatebroker WBRK_BROKER -i wbrkuid -a wbrkpw -q WBRK_QM -n WBRKBKDB -t
mqsicreatebroker WBRK_BROKER -i wbrkuid -a wbrkpw -q WBRK_QM -n WBRKBKDB -x /opt/3rdparty/wmbexits
mqsicreatebroker CSQ1BRK -q CSQ1 -u BRKUSER -n DBA0
mqsicreatebroker CSQ1BRK -q CSQ1 -u BRKUSER -n DBA0 -2