Migrazione di un flusso di messaggi

Prima di iniziare:

Leggere l'argomento relativo a condizioni per un broker Versione 5.0 che partecipa ad un dominio del broker Versione 6.0.

E' possibile migrare i flussi di messaggi creati nel prodotto versione 2.1 (WebSphere MQ Event Broker, WebSphere MQ Integrator Broker, o WebSphere MQ Integrator) e utilizzarli in WebSphere Message Broker Versione 6.0.

Se si sta effettuando la migrazione da WebSphere MQ Event Broker Versione 2.1, tutte le informazioni in questo argomento che fanno riferimento a ESQL e plug-in definiti dall'utente non sono valide: tali funzioni non sono disponibili su WebSphere MQ Event Broker Versione 2.1.

Se la migrazione è stata eseguita da WebSphere MQ Integrator Broker Versione 2.1, potrebbero essere stati scritti dei flussi di messaggi che gestiscono i messaggi XML che utilizzano spazi dei nomi XML. Nella Versione 2.1, tali messaggi XML sono analizzati in modo diverso rispetto a quello utilizzato da WebSphere Message Broker Versione 6.0. Sebbene tali flussi di messaggi continuino ad operare correttamente quando vengono trasferiti nella Versione 6.0, è meglio aggiornarli affinché riconoscano lo spazio dei nomi seguendo le istruzioni contenute in Flusso di messaggi che riconosce uno spazio dei nomi.

Si potrebbero modificare i flussi di messaggi da migrare in modo che usufruiscano dei nuovi nodi e funzioni disponibili nella Versione 6.0. Ad esempio, si potrebbe decidere di sostituire un nodo definito dall'utente che riceve richieste di servizi web con il nodo integrato HTTPInput.

Per ulteriori informazioni sulle modifiche in questo rilascio, consultare Nuove funzioni nella Versione 6.0.

E' possibile migrare più di un flusso di messaggi alla volta se si desidera definirli nello stesso progetto del flusso di messaggi. E' necessario migrare i flussi secondari e i nodi definiti dall'utente insieme ai flussi di messaggi nei quali sono inclusi per assicurare dei riferimenti coerenti.

Se è stato definito più di un flusso di messaggi con lo stesso nome o il flusso di messaggi è stato esportato in più di un file di esportazione, l'attività di migrazione sovrascrive qualsiasi flusso di messaggi esistente con il flusso successivo che abbia lo stesso nome senza alcuna avvertenza. Fare quindi attenzione ad evitare i conflitti e assicurare che la versione più recente di un flusso di messaggi a più definizioni sia l'ultima a essere migrata.

Se si hanno più versioni di uno stesso flusso di messaggi, utilizzato come flusso secondario in altri flussi nella stessa directory di migrazione, i risultati dell'importazione sono imprevedibili.

Per migrare un flusso di messaggi:

  1. Prima di disinstallare la Versione 2.1, esportare il flusso o i flussi di messaggi dal Centro di controllo utilizzando gli strumenti della Versione 2.1 (consultare la documentazione relativa alla Versione 2.1 per informazioni dettagliate).

    Il processo di migrazione è più efficace quando tutti i flussi secondari a cui si fa riferimento sono inclusi nello stesso file di esportazione, esportare quindi tutti i flussi di messaggi che si desidera migrare in un singolo progetto del flusso di messaggi all'interno di un singolo file di esportazione.

  2. Trasferire il file o i file di esportazione sul nuovo sistema su cui è in esecuzione il workbench. Verificare che la directory nella quale si memorizzano questi file non contenga altri file. Memorizzare i file che si ha intenzione di importare in un singolo progetto del flusso di messaggi in una directory separata e migrare ogni directory separatamente. Accertarsi di non memorizzare alcun file nelle sottodirectory della directory del progetto, perché questi file vengono ignorati dal comando migrate.
  3. Se una sessione del workbench è attiva, chiuderla. Non è possibile eseguire il comando migrate se è in esecuzione il workbench.
  4. Sul prompt dei comandi, richiamare il comando mqsimigratemsgflows, specificando il nome del nuovo progetto e la directory nella quale sono stati memorizzati i file di esportazione. Una volta che il comando è stato completato:
    • I flussi di messaggi contenuti nei file di esportazione nella directory specificata sono importati nel progetto del flusso di messaggi specificato. Se il progetto già esiste, i flussi di messaggi aggiuntivi sono inclusi con il contenuto corrente, se presente. Se il progetto non esisteva prima di richiamare il comando, viene creato. E' preferibile consentire al comando di creare il progetto del flusso di messaggi.
    • I flussi di messaggi e i flussi secondari vengono creati e le relative definizioni sono memorizzate in file denominati flow_name.msgflow. I nodi definiti dall'utente vengono creati e le relative definizioni sono memorizzate in file denominati node_name.msgnode.

      Se si desidera ridenominare uno qualsiasi di questi flussi di messaggi o nodi dopo l'importazione per conformarsi alle convenzioni di denominazione locali, utilizzare le funzioni fornite dal workbench per mantenere la coerenza e l'integrità di tutti i riferimenti. Non ridenominare alcun i file all'interno del file system.

    • Se uno dei nodi nei flussi di messaggi contiene ESQL, questo viene estratto dal nodo stesso e memorizzato nel file ESQL message_flow_name.esql. L'ESQL per ogni nodo è incluso nelle appropriate istruzioni CREATE e END MODULE (per Compute, Database o Filter). Il comando crea il file ESQL se non esiste già.

      Inizio modificaQuando si aggiunge un flusso di messaggi a un file bar, il codice di runtime ESQL viene generato al livello Versione 6.0. Questo codice è incompatibile con i broker Versione 2.1. Se si desidera che il file bar includa ESQL di runtime versione 2.0, selezionare la casella Compila ESQL per broker versione 2.1. Così facendo, non è possibile includere i miglioramenti della Versione 6.0 nel codice ESQL, ma è possibile distribuire i flussi sia ai broker Versione 2.1 che Versione 6.0.Fine modifica

      Per ulteriori informazioni, consultare l'argomento Aggiunta di file a un archivio broker.

  5. Controllare che il file di prospetto mqsimigratemsgflows.report.txt sia scritto nella directory da cui si richiama il comando. Il comando fornisce le seguenti informazioni:
    • Il nome di ogni flusso di messaggi, flusso secondario e nodo definito dall'utente che sia stato migrato. Se una di queste risorse aveva un nome incompatibile con la Versione 6.0, il comando aggiorna il nome e tutti i riferimenti al nome per garantire la coerenza. (Se si esegue la migrazione di una risorsa con un nome non valido più di una volta, la correzione apportata al nome è sempre la stessa.)
    • L'esito positivo o negativo di ogni risorsa migrata
    • Un'indicazione di un flusso secondario che non può essere individuato (la cui definizione non è contenuta in alcun file di esportazione, ma è inclusa in uno o più flussi di messaggi migrati). Se si verifica ciò, ricercare il flusso secondario mancante e importarlo nel progetto appropriato. Se non è possibile recuperare il flusso secondario mancante per qualche motivo, crearlo nuovamente con il nome originale. Tutti i flussi interessati possono quindi collegarsi correttamente al nuovo flusso secondario.

      Non è necessario ripetere l'intero processo di esportazione e importazione.

    • Un'indicazione che una risorsa che è stata migrata come flusso di messaggi e memorizzata in un file .msgflow potrebbe essere un nodo definito dall'utente. Se si presenta questa avvertenza, controllare se la risorsa specificata è un nodo definito dall'utente o un flusso di messaggi. Se è un flusso di messaggi, la risorsa è stata migrata correttamente. Se è un nodo definito dall'utente, completare le azioni indicate nella fase 11.
  6. Avviare il workbench e passare alla Prospettiva Sviluppo dell'applicazione broker.
  7. Aprire il progetto del flusso di messaggi creato o aggiornato dal comando migrate facendo clic con il tasto destro sul progetto e facendo clic su Apri progetto.

    Se il progetto è già aperto, fare clic con il tasto destro e fare clic su Aggiorna, poi su Compila di nuovo il progetto per assicurare che la vista Navigator rifletta il nuovo contenuto. L'azione di ricompilazione esegue anche una convalida del contenuto del progetto del flusso di messaggi.

    Poiché ESQL e le mappature sono gestiti in modo diverso nella Versione 6.0, il processo di migrazione sostituisce alcuni dei nodi della Versione 2.1 con nodi della Versione 6.0 diversi. La seguente tabella elenca i nodi sostituiti. L'ESQL associato ad ogni nodo viene creato come un modulo con un nome predefinito e la proprietà del nodo è impostata sul nome di quel modulo.

    Nodo Versione 2.1 Nodo Versione 6.0
    Compute Compute
    Filter Filter
    Database Database
    DataDelete Database
    DataInsert Database
    DataUpdate Database
    Extract Compute
    Warehouse Database
  8. Se un flusso di messaggi include uno o più nodi Filter, controllare nel modulo ESQL ogni nodo nel file ESQL per assicurare che l'istruzione RETURN restituisca correttamente un'espressione valida che si risolve in un valore Booleano.
  9. Se un flusso di messaggi include un nodo con ESQL, i campi dei riferimenti ESQL in un messaggio vengono ricavati da un'intestazione C importata e si è creato nuovamente il modello del messaggio importando l'intestazione C nel workbench, controllare le istruzioni ESQL che fanno riferimento a questo messaggio. L'importazione nel workbench Versione 6.0 potrebbe creare un modello con convenzioni di denominazione diverse da quelle create dal programma di importazione Versione 2.1 e si potrebbe avere la necessità di aggiornare uno o più riferimenti del campo.
  10. Se è stata promossa la proprietà ESQL di uno qualsiasi dei nodi Versione 2.1 che includevano la personalizzazione ESQL per riutilizzare ESQL in più nodi, questa non viene conservata nei flussi di messaggi Versione 6.0 migrati, poiché la promozione delle proprietà ESQL correlate non è più supportata. La vista Attività mostra un errore per ogni proprietà ESQL promossa. Per ottenere lo stesso effetto, creare una funzione ESQL e richiamare quella funzione dal modulo ESQL di ogni nodo.
  11. Se è stata eseguita la migrazione di un nodo definito dall'utente, solo il file di definizione dell'interfaccia XML viene migrato in un file .msgnode del nodo (questo definisce solo i terminali e le proprietà del nodo). Completarne la migrazione e definizione manualmente nella Versione 6.0 del prodotto. Le seguenti operazioni forniscono un profilo dell'elaborazione richiesta: per tutti i dettagli, consultare Creazione della rappresentazione dell'interfaccia utente di un nodo definito dall'utente nel workbench.
    1. Creare un progetto del nodo definito dall'utente e spostare il file .msgnode dal progetto del flusso di messaggi al nuovo progetto del nodo definito dall'utente. Così facendo, vengono creati i file delle proprietà associati.
    2. Facoltativo: completare lo sviluppo del nodo definito dall'utente in ambiente Eclipse per creare il plug-in Eclipse del nodo definito dall'utente (la struttura di directory che contiene i file che costituiscono questo nodo). Questa attività include la creazione di risorse del nodo per la guida, le icone, i compilatori e gli editor Proprietà, se richiesto.
    3. Controllare la presenza di errori nell'elenco delle attività. Questi potrebbero essere generati, ad esempio, se il nodo o i nomi dei relativi terminali includono lo spazio (non supportato nella Versione 6.0) o se un flusso integra un altro flusso migrato e il riferimento non è corretto. Risolvere questi errori correggendo i nomi o utilizzando l'opzione di menu Ricerca flusso secondario.
    4. Installare il codice di runtime per il nodo (il file .lil) sui sistemi broker appropriati. Non è necessario ricompilare il codice per il nodo definito dall'utente quando si esegue la sua migrazione.
    5. Arrestare e riavviare il broker per riconoscere i file nuovi o modificati.
Una volta migrate le risorse, consultare Attività da eseguire dopo la migrazione della Versione 2.1 per informazioni sulle attività che si desidera eseguire dopo la migrazione.
Concetti correlati
Panoramica dei flussi di messaggi
Funzioni ESQL
Attività correlate
Flusso di messaggi che riconosce uno spazio dei nomi
Apertura di un flusso di messaggi esistente
Definizione del contenuto del flusso di messaggi
Sviluppo di ESQL
Riferimenti correlati
Prospettiva Sviluppo dell'applicazione broker
Editor ESQL
Nodi integrati
Comando mqsimigratemsgflows
Informazioni particolari | Marchi | Download | Libreria | Supporto | Commenti
Copyright IBM Corporation 1999, 2006 Ultimo aggiornamento: ago 17, 2006
ac02355_