Durante la preparazione del sistema ICS per un aggiornamento, esistono due opzioni tra cui scegliere per la migrazione del database ICS, una migrazione del database sul posto ed una migrazione senza database sul posto. Una migrazione con il database sul posto significa riutilizzare il repository vecchio e consentire a ICS di eseguire l'aggiornamento del repository durante il primo avvio del server ICS. Una migrazione senza il database sul posto significa eseguire l'aggiornamento con un database di repository completamente vuoto e nuovo.
L'aggiornamento del sistema di InterChange Server utilizzando una migrazione senza database sul posto implica i passaggi seguenti. Se si utilizza una migrazione con database sul posto le modifiche contenute nelle istruzioni vengono indicate come "in-place database migration".
L'esecuzione di una copia di backup del sistema di InterChange Server consente di ripristinare qualsiasi file che potrebbe essere stato sovrascritto inavvertitamente durante l'installazione della versione nuova. Prima di eseguire la procedura di aggiornamento, eseguire il backup sia dei dati statici che di quelli dinamici (dati modificabili che vengono copiati su una base regolare, a prescindere dagli aggiornamenti). Per esempi di dati statici e dinamici, consultare la sezioneTabella 15.
Per eseguire la copia di backup del sistema, procedere nel modo seguente:
repos_copy -sWICS -oRepository430.txt -uadmin -pnull
Per 4.1.1 il programma di utilità repos_copy crea una copia di backup degli oggetti di repository in un file *.txt o *.
Per 4.2.2 e le versioni successive il programma di utilità repos_copy crea una copia di backup degli oggetti di repository in un file *.jar.
ProductDir\mqseries\crossworlds_mq.tst
L'IBM raccomanda di eseguire un backup sistematico della intera directory del prodotto InterChange Server.
Tabella 15 riepiloga il modo in cui eseguire la copia di backup dei
diversi componenti ICS.
Tabella 15. Metodi di esecuzione backup per i dati di InterChange Server
Prima di aggiornare il sistema di InterChange Server alla versione 4.3, è necessario verificare che si trovi in uno stato di quiete. Ciò significa che è necessario completare tutti gli eventi in esecuzione e risolvere tutte le transazioni in dubbio prima di eseguire il backup dell'ambiente e dell'esecuzione della procedura di aggiornamento.
I passaggi seguenti descrivono il modo in cui porre il sistema di InterChange Server in uno stato di quiete:
Consultare il manuale System Administration Guide per ulteriori informazioni sul modo in cui arrestare un sistema in esecuzione normalmente.
I passaggi seguenti elencano l'ordine corretto della disinstallazione del software di terza parte.
Se i componenti di InterChange Server sono in esecuzione come servizi, disinstallare questi servizi prima di eseguire l'aggiornamento. Poiché il rilascio nuovo risiederà in un'ubicazione diversa, le definizioni dei servizi non saranno più corrette. Una volta completato l'aggiornamento, consultare "Opzioni di configurazione avanzate" per le istruzioni relative alla configurazione dei componenti di InterChange Server come servizi.
I passaggi seguenti elencano l'ordine corretto in cui installare i componenti di InterChange Server.
Se si esegue una migrazione da ua versione precedente di InterChange Server, è bene verificare se è necessario aggiornare anche il proprio software database. Consultare la sezione relativa ai requisiti software (consultare Software requisiti ) per l'elenco del software database supportato. Confrontare la versione del software database esistente con la versione supportata dalla versione 4.3 del prodotto .
Se è necessario aggiornare il proprio software database, è necessario che il DBA (database administrator) esegua queste operazioni:
Consultare la documentazione server database per le istruzioni sul modo in cui eseguire le copie di backup e l'aggiornamento del software database. Per ulteriori informazioni sul modo in cui eseguire la migrazione del database, passare a Passo 8 - Caricare il repository.
Quando si esegue un aggiornamento di MQ, è possibile seguire uno di questi percorsi:
Quando si esegue l'installazione di WebSphere 5.3, è necessario scegliere l'installazione personalizzata e l'opzione che include la messaggistica Java. Se si sceglie l'installazione tipica, i file di messaggistica Java richiesti non vengono installati. Per istruzioni dettagliate, consultare Installazione WebSphere MQ.
Per istruzioni dettagliate, consultare Aggiornamento WebSphere MQ.
Una volta aggiornato il software di WebSphere MQ, è necessario configurarlo per utilizzarlo con InterChange Server. Per ulteriori informazioni, consultare la descrizione nella sezioneConfigurazione WebSphere MQ.
Il sistema di WebSphere InterChange Server non utilizza più VisiBroker ORB (Object Request Broker) per gestire le comunicazioni tra ICS ed i client relativi (come i connettori, gli strumenti di WebSphere Business Integration, gli agenti SNMP ed i client di accesso). Invece, il sistema di InterChange Server adesso utilizza IBM Java ORB. Il programma di installazione di ICS installa IBM Java ORB automaticamente come parte di JRE (Java Runtime Environment).
InterChange Server utilizza adesso IBM Transient Naming Server invece dell'agente smart VisiBroker per fornire il servizio di denominazione relativo. Per aggiornare il sistema in modo da utilizzare il nuovo server di denominazione,eseguire una di queste operazioni a seconda se l'agente smart VisiBroker sia installato o meno sulla stessa macchina host del IBM Transient Naming Server ed è necessario che rimanga su questa stessa macchina host:
L'utilizzo delle proprietà per impostare IBM Java ORB è stato impostato negli script di avvio forniti dall'installazione. Tuttavia, sa la versione precedente alla 4.3 di InterChange Server ha utilizzato il software Inprise VisiBroker e le proprietà VisiBroker ORB sono state personalizzate, potrebbe essere necessario eseguire le stesse modifiche ai nuovi script per adeguare la migrazione 4.3 all'IBM ORB. Per ulteriori informazioni sulle proprietà IBM ORB e su quelle equivalenti VisiBroker, fare riferimento a Aggiornamento proprietà ORB.
varie proprietà relative a ORB erano presenti nell'ORB VisiBroker per regolare l'ORB. Se queste proprietà sono state utilizzate in software o script personalizzati, è necessario verificare che siano state impostate correttamente per IBM Java ORB. Tabella 16 elenca alcune delle proprietà VisiBroker ORB e i nomi equivalenti relativi nell'IBM Java ORB.
Se esistono script personalizzati delle installazioni precedenti alla 4.3 che fanno riferimento alle proprietà VisiBroker ORB, sostituirli con gli equivalenti IBM ORB di seguito elencati in Tabella 16..
Tabella 16. Proprietà IBM ORB ed equivalenti VisiBroker relative
Proprietà IBM ORB | Proprietà VisiBroker equivalenti | Descrizione |
---|---|---|
org.omg.CORBA.ORBInitialHost | vbroker.agent.addr | Specifica l'indirizzo IP o il nome host della macchina su cui è in esecuzione IBM Transient Naming Server (tnameserv). Il valore predefinito di questa proprietà è localhost. |
org.omg.CORBA.ORBInitialPort | vbroker.agent.port | Specifica la porta su cui è in ascolto IBM Transient Naming Server. |
com.ibm.CORBA.ListenerPort | vbroker.se.iiop_tp.scm.iiop_tp. listener.port | La porta su cui il server ORB sarà in ascolto per le richieste in arrivo. se viene specificata questa proprietà, l'ORB inizierà l'ascolto duranteORB.init(). Per impostazione predefinita, questa porta viene assegnata dinamicamente. Il nome proprietà VisiBroker OAport continuerà ad essere supportato. |
com.ibm.CORBA.LocalHost | vbroker.se.iiop_tp.host | Questa proprietà rappresenta il nome host (o l'indirizzo IP) della
macchina su cui è in esecuzione l'ORB. Il nome host locale viene
utilizzato dall'ORB dal lato server per ubicare il nome host del server
nello IOR di un oggetto remoto. Se questa proprietà non viene
impostata, l'host locale viene recuperato richiamando :
InetAddress.getLocalHost() .getHostAddress();
.
Per 4.3, il nome della proprietà VisiBroker OAipAddr verrà ancora supportato. |
com.ibm.CORBA.ThreadPool. MaximumSize | vbroker.se.iiop_tp.scm.iiop_tp. dispatcher.threadMax | Specifica il numero massimo di thread che il gestore delle connessioni del server è in grado di creare. Il valore predefinito 0 implica che non esistono limitazioni. Per la versione 4.3, il nome proprietà di VisiBroker OAthreadMax verrà ancora supportato. |
com.ibm.CORBA.ThreadPool. InactivityTimeout | vbroker.se.iiop_tp.scm.iiop_tp. dispatcher.threadMaxIdle | Specifica la durata di tempo (in secondi) prima che venga eliminato un thread inattivo. Il nome proprietà VisiBroker OAthreadMaxIdle continuerà ad essere supportato. |
com.ibm.CORBA.BufferSize | vbroker.orb.streamChunkSize | Il numero di byte (come un messaggio GIOP) che verrà letto da un socket al primo tentativo. Una dimensione buffer maggiore aumenta le probabilità di letture dell'intero messaggio al primo tentativo, il che può migliorare le prestazioni. Il valore predefinito è 2048. |
Nelle versioni precedenti alla 4.3 di InterChange Server, il VisiBroker ORB ha fornito lo strumento osfind per identificare tutti gli oggetti ORB registrati con InterChange Server. IBM Java ORB fornisce uno strumento denominato CosNameServer_Dump per questo scopo. Tale strumento viene ubicato nella directoryProductDir\bin. Per ulteriori informazioni, consultare il manuale System Administration Guide.
Fare riferimento a Aggiornamento script server e Completamento aggiornamenti dei componentiper informazioni di aggiornamento aggiuntive.
Note:
Verificare che sia il gestore code che il listener siano attivi ed in esecuzione.
Per le istruzioni sul modo in cui avviare InterChange Server, fare riferimento a "Impostazione di InterChange Server".
E' possibile verificare il file InterchangeSystem.log nella directory ProductDir per confermarne l'avvio corretto.
Caricare il file di repository dalla versione precedente utilizzando il comando repos_copy. Ad esempio, inserire quanto di seguito indicato se il nome ICS è WICS con il nome utente/password admin/null ed il nome file di repository repos_backup.jar ( utilizzare repos_backup.in se si esegue l'aggiornamento dalla versione 4.1.1)
repos_copy -sWICS_NAME -irepos_backup.jar -uadmin - pnull
Consultare Aggiornamento repository per ulteriori informazioni sul repository.
Se si esegue un aggiornamento da ICS 4.1.1 seguire i passi indicati per aggiornare i vecchi DLM e le collaborazioni per gli strumenti.
Per ulteriori informazioni sull'ICL consultare Importazione in un ICL.
Questi passaggi non sono necessari per la versione server 4.2.x.
Per convalidare la riuscita dell'aggiornamento,è necessario verificare che sia stato creato lo schema di repository e che tutti gli oggetti siano stati caricati correttamente. Per procedere in tal modo, convalidare quanto segue:
Se sono stati creati file personalizzati nel sistema InterChange Server preesistente, è necessario valutare i file seguenti per determinare se richiedono aggiornamenti:
Tutti gli script di avvio sono stati modificati per consentire lo spostamento dal VisiBroker ORB all'IBM Java ORB ed al supporto per IBM JRE. Queste modifiche includono:
Se sono stati personalizzati degli script di avvio precedenti alla versione 4.3, è necessario effettuare le stesse modifiche ai nuovi script 4.3. Potrebbe essere necessario eseguire le seguenti personalizzazioni a questi script di avvio:
Ad esempio, se si dispone di gestori dati personalizzati, aggiungere i file.jar relativi alla variabile CLASSPATH.
Una volta completato il processo di aggiornamento e le relative verifiche, è possibile rimuovere l'opzione -design dall'avvio server in modo che InterChange Server venga avviato in modalità di produzione.
Una delle attività del file di configurazione strumenti, cwtools.cfg, è quella di fornire i file.jar di personalizzazione da includere al momento della compilazione. Se sono stati creati file.jar di personalizzazione,è necessario aggiungere tali file alla sezionecodeGeneration , nella variabile classpath. Il file cwtools.cfg è ubicato nella directory seguente:
ProductDir/bin
Tutte le variabili di ambiente di sistema verranno nuovamente impostate in un file CWSharedEnv singolo. Tutti gli script di avvio leggono questo file come parte della procedura di richiamo. E' in questo file che vengono impostate le proprietà dell'intero sistema ICS (come quelle per l'IBM Java ORB). Come parte del processo di aggiornamento, verificare che le seguenti proprietà dell'intero sistema siano impostate in modo corretto:
Per ulteriori informazioni sul file CWSharedEnv, consultare il manuale System Administration Guide.
Se vi sono componenti completamente personalizzati che utilizzano le tabelle di repository (come script, tabelle database o procedure memorizzate), è necessario valutare ogni componente per decidere se è necessario aggiornarlo. Ad esempio, se una procedura memorizzata utilizza una tabella di repository che è stata modificata nel rilascio nuovo, è necessario modificare la procedura memorizzata perchè funzioni con la struttura nuova della tabella di repository.
Il repository di InterChange Server è un database che contiene metadati relativi ai componenti di InterChange Server. Il programma di installazione ICS non aggiornerà automaticamente il contenuto del repository ICS. Tuttavia, una volta avviato ICS nel passaggio precedente, ICS aggiorna lo schema contenuto nel repository precedente alla versione 4.3 con le modifiche necessarie. A questo punto del processo di aggiornamento, è necessario decidere gli oggetti da caricare nel repository:
Per qualsiasi componente particolare ICS che si desidera installare (che non sia installato separatamente), il programma di installazione copierà automaticamente i file di input appropriati nella directory ProductDir\repository. Questi file di input contengono gli oggetti di repository dei nuovi componenti installati come parte del rilascio 4.3.
Se è stata eseguita una copia di backup del repository ICS con repos_copy, uno o più file di repository contengono degli oggetti per i componenti provenienti dal rilascio ICS preesistente.
E' possibile utilizzare la vista gestione componenti di InterChange Server in System Manager per sfogliare i componenti caricati nel server.
Se si esegue un aggiornamento da una versione 4.1.1 di InterChange Server ed è stato necessario aggiornare il sotware database, è necessario che il DBA abbia installato il nuovo server database ed abbia gestito qualsiasi modifica utile per i database ICS, incluso il repository ICS. Come parte del processo di installazione ICS, sono stati specificato i nomi dei database ICS nella procedura guidata di configurazione di ICS. Una volta avviata la nuova versione di ICS, il server avrà aggiornato lo schema contenuto nel database di repository. Per inizializzare questo nuovo repository, è necessario caricare gli oggetti di repository preesistenti.
Per preparare il repository al caricamento, eseguire queste operazioni:
ProductDir\DLMs\classes\NativeMaps
ProductDir\collaborations\classes\UserCollaborations
dove ProductDir è la directory del prodotto del nuovo rilascio 4.3. Questo passaggio garantisce che i file.class delle mappe e delle collaborazioni esistenti risiedano nella struttura della nuova directory 4.3.
Ognuno di questi passaggi relativi alla gestione degli oggetti di repository preesistenti è descritto nelle sezioni seguenti.
Verificare il file di backup repos_copy esistente (denominato file di repository) per accertare che tutti i valori siano relativi al repository nuovo. Creare una copia di backup del file di repository esistente e modificare il file di repository originale per correggere le informazioni seguenti:
Quando si importano delle relazioni, è necessario verificare che gli attributi seguenti di ciascuna di esse siano validi all'interno del file di repository:
se questi attributi identificano un database che è impossibile rilevare durante l'importazione di repos_copy nel repository ICS, InterChange Server ripristina l'intera operazione di importazione. Tuttavia, se gli attributi sopra riportati relativi ad ogni relazione venissero cancellati, InterChange Server utilizzerebbe il repository come database di relazione predefinito.
E' impossibile importare i pool di connessione database nel formato 4.1.1 nel nuovo repository. Perciò, è necessario eliminare qualsiasi pool di connessione dal file di repository. Una volta aggiornata l'istanza ICS, è necessario creare nuovamente questi pool di connessione all'interno di System Manager.
Prima di importare gli oggetti di repository preesistenti è necessario eliminare qualsiasi oggetto duplicato che potrebbe essere già esistente nel repository 4.3. Questo passaggio è necessario in quanto il programma di utilità repos_copy non è in grado di riconoscere le opzioni -ar o -arp (che gestiscono gli oggetti duplicati) quando esegue l'importazione di un vecchio formato nel repository. Se ICS rileva oggetti duplicati nel file di repository, esegue il ripristino dell'intera operazione di importazione.
Per eliminare questi oggetti di repository, utilizzare l'opzione -d del programma di utilità repos_copy. Ad esempio, il comando seguente repos_copy elimina il contenuto del repository:
repos_copy -sNewICSinstance -uadmin -pnull -d
Nel comando precedente repos_copy:
Per caricare il contenuto dei file di repository nel repository, utilizzare il programma di utilità repos_copy. Come descritto nella sezione Passo 1 - Esecuzione backup del sistema di InterChange Server, è necessario aver esportato gli oggetti di repository preesistenti con l'opzione -o del programma di utilità repos_copy per creare uno o più file di repository. Importare ora questi oggetti di repository nel nuovo repository con l'opzione-i del programma di utilità repos_copy.
Ad esempio, si supponga di disporre del file di repositoryRepository411.txt. Il comando seguente repos_copy carica tutti gli oggetti di repository in questo file:
repos_copy -iRepository411.txt -sserverName -uuserName -ppassword -r*
Nel comando precedente repos_copy:
una volta che gli oggetti di repository preesistenti si trovano in un repository nuovo, è ancora necessario eseguire dei passaggi aggiuntivi per completare l'aggiornamento delle mappe e delle maschere di collaborazione. Per ulteriori informazioni, consultare Completamento aggiornamenti mappe e maschere di collaborazione.