Avvio del processo di aggiornamento

Una volta che il sistema è in uno stato di quiete ed è stata eseguita la copia di backup, è possibile avviare in modo sicuro la procedura di aggiornamento.

Nota:
Non è richiesta la disinstallazione della versione obsoleta di InterChange Server prima dell'installazione della versione 4.3, ma è possibile eseguire questa operazione tranquillamente a questo punto. Fare riferimento alla sezione Disinstallazione di InterChange Server per i dettagli. Se si decide di non eseguire la disinstallazione in questo momento, è consigliabile rimuovere la versione precedente una volta terminato l'aggiornamento a causa dell'ampia dimensione dei file associati. E' necessario utilizzare una directory diversa per l'installazione della versione 4.3 anche se si decide di eseguire la disinstallazione in questa fase.
L'aggiornamento del sistema implica le seguenti attività:

Impostazione del database

Se il database è stato aggiornato, è necessario definire il DBA per l'importazione delle informazioni database salvate, comprese le informazioni sullo schema e le procedure memorizzate. Consultare la documentazione del server database per le istruzioni relative.

Installazione della versione nuova di InterChange Server

Una volta eseguito il backup della pre-installazione 4.3, si è pronti per installare la versione nuova di InterChange Server. Per installare la versione nuova di InterChange Server, consultare Installazione InterChange Server, gestore dati XML, adattatore e-mail ed altri prodotti di supporto per le istruzioni.

Note:

  1. Durante un aggiornamento, è necessario installare la versione nuova in una ubicazione diversa dell'installazione esistente.

  2. Quando il programma di installazione richiede il nome dell'istanza ICS, è necessario che corrisponda a quello della versione precedente per garantire la portabilità degli eventi di errore. Questo passaggio non è necessario se si sta eseguendo una migrazione del database in attività.

  3. Per ottenere le informazioni di configurazione del proprio InterChange Server originale, è possibile intraprendere una delle azioni seguenti quando il programma di installazione avvia la procedura guidata di configurazione di InterChange Server:

Configurazione ORB (Object Request Broker)

Se si esegue l'aggiornamento da una versione 4.2.2 di InterChange Server, non è necessario configurare ORB (Object Request Broker). Passare alle istruzioni contenute in Aggiornamento script server.

A partire dal rilascio 4.2.2 di InterChange Server, l'ORB VisiBroker è stato sostituito dall'IBM Java ORB. Come descritto in Aggiornamento hardware e software di supporto, il programma di installazione di ICS installa automaticamente l'ORB IBM Java e l'IBM Transient Naming Server come parte del processo di installazione di ICS. Tuttavia, è necessario che l'ORB IBM Java venga configurato correttamente eseguendo queste attività:

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 l'ORB IBM Java. Tabella 32 elenca alcune delle proprietà ORB VisiBroker ed i nomi relativi equivalenti nell'IBM Java ORB.

Se esistono script personalizzati nelle precedenti installazioni 4.2.2 che fanno riferimento alle proprietà ORB VisiBroker, è necessario sostituirli con gli equivalenti ORB IBM di seguito elencati in Tabella 32.

Nota:
Sono state inserite le interruzioni di riga in alcuni dei nomi delle proprietà in Tabella 32 per consentire ai nomi di essere inserito nelle celle delle tabelle. I nomi delle proprietà attuali non includono spazi o interruzioni di riga.

Tabella 32. Proprietà ORB IBM ed equivalenti VisiBroker relativi
Proprietà ORB IBM Proprietà VisiBroker equivalenti Descrizione
org.omg.CORBA.ORBInitialHost vbroker.agent.addr Specifica l'indirizzo IP o il nome della macchina su cui è in esecuzione l'IBM Transient Naming Server (tnameserv). Il valore predefinito di questa proprietà è localhost.
org.omg.CORBA.ORBInitialPort vbroker.agent.port Specifica la porta su cui l'IBM Transient Naming Server è in ascolto.
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. Per la versione 4.3 il nome proprietà VisiBroker OAport sarà ancora 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 allora 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. Per la versione 4.3, il nome proprietà di VisiBroker OAthreadMaxIdle verrà ancora 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 più ampia aumenta le probabilità di lettura del messaggio intero al primo tentativo, il che può migliorare le prestazioni. Il valore predefinito è 2048.

Identificazione componenti ORB ICS registrati

Nelle versioni precedenti alla 4.2.2 di InterChange Server, ORB VisiBroker ha fornito lo strumento osfind per identificare tutti gli oggetti ORB registrati con InterChange Server. L'IBM ORB Java fornisce uno strumento denominato CosNameServer_Dump per questo scopo. Questo strumento è ubicato nella directoryProductDir/bin. Per ulteriori informazioni, consultare il manuale System Administration Guide.

Aggiornamento funzioni HA (high-availability)

A partire dal rilascio 4.2.2 di InterChange Server, l' IBM ORB Java ha sostituito l'ORB VisiBroker. Con questa modifica, il Transient Naming Server ha sostituito l'agente smart VisiBroker, precedentemente utilizzato per HA. Per ulteriori informazioni sulla configurazione dell'ORBIBM per l'ambiente HA, consultare Installazione e configurazione di ORB (Object Request Broker).

Aggiornamento script server

Se sono stati creati file personalizzati nel sistema InterChange Server preesistente, è necessario valutare i file seguenti per determinare se richiedono aggiornamenti:

Aggiornamento script di avvio server

A partire dal rilascio 4.2.2 di InterChange Server, tutti gli script di avvio sono stati modificati per conformarsi al passaggio dall'ORB VisiBroker all'IBM Java ORB e per supportare IBM JRE.

Se sono stati personalizzati degli script di avvio server e si esegue un'aggiornamento alla versione 4.3 da un rilascio diverso da 4.2.2, è necessario eseguire le stesse modifiche ai nuovi script. Potrebbe essere necessario eseguire le seguenti personalizzazioni a questi script di avvio:

Nota:
E' ora possibile accedere ad ITE (Integrated Test Environment) con un semplice comando di avvio. Impostare ICS per controllare la modalità aggiungendo l'opzione -test alla riga di avvio nello script di avvio del server. E' possibile trovare informazioni più dettagliate nel manuale Implementation Guide for WebSphere InterChange Server.

Aggiornamento file di configurazione strumenti

Una delle attività del file di configurazione strumenticwtools.cfg , è quella di fornire i file .jar personalizzati da includere al momento della compilazione. Se sono stati creati file personalizzati .jar, è necessario aggiungerli alla sezionecodeGeneration , nella variabile CLASSPATH. Il file cwtools.cfg è ubicato nella seguente directory sulla macchinaWindows su cui sono in esecuzione i propri strumenti:

ProductDir\bin
 

Verifica variabili di ambiente

Tutte le variabili di ambiente del sistema sono impostate in un file CWSharedEnv.sh 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'ORBIBM Java). Come parte del processo di aggiornamento, verificare che le seguenti proprietà dell'intero sistema siano impostate in modo corretto:

Per ulteriori informazioni sul fileCWSharedEnv.sh, consultare il manuale System Administration Guide.

valutazione componenti di personalizzazione

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.

Nota:
Non sarà necessario non modificare né le tabelle eventi nè i trigger in alcun modo se lo schema non è stato cambiato.

Avvio della nuova versione aggiornata

Una volta completata l'installazione, è possibile avviare la nuova versione di InterChange Server utilizzando la versione esistente del repository, fornita, in esecuzione su tutto il software di supporto richiesto. Se è stato eseguito l'aggiornamento con la funzione di aggiornamento in attività del database, è necessario indirizzare ICS al repository originale. Per avviare ICS, seguire le indicazioni:

  1. Si consiglia, ma non è strettamente necessario, di riavviare la macchina.
  2. Se si sta eseguendo un'installazione con il database in attività, riutilizzare il file di configurazione server precedente, InterchangeSystem.cfg. Se non si sta utilizzando l'installazione con il database in attività utilizzare il nuovo file di configurazione creato dal programma di installazione. Se si decide di utilizzare il file di configurazione precedente, copiare quello vecchio nella directory ProductDir della nuova installazione. Se si decide di utilizzare il file di configurazione nuovo, utilizzare la procedura guidata di configurazione del server per modificare correttamente le impostazioni. verificare che il nome server sia lo stesso di quello dell'installazione server precedente se si desidera aggiornare gli eventi di errore dall'ICS precedente.
  3. Verificare che tutto il software di supporto richiesto sia in esecuzione. Il software di supporto include:

    Per le istruzioni relative al modo in cui verificare che il software di supporto sia in esecuzione, fare riferimento alla sezione Avvio software di supporto and Avvio del server IBM ORB Transient Naming.

  4. Avviare InterChange Server.

    Per le istruzioni sul modo in cui avviare InterChange Server, fare riferimento alle sezioni Avvio InterChange Server e Avvio System Manager.

E' possibile verificare il file InterchangeSystem.log nella directory ProductDir per confermarne l'avvio corretto.

Nota:
Se InterChange Server riesce ad essere avviato per avviare il sistema di InterChange Server una volta aggiornato, riesaminare questa procedura di aggiornamento per accertarsi di aver seguito tutte le istruzioni. Se non si riesce a determinare la causa del malfunzionamento, consultare il supporto tecnico IBM per l'assistenza prima di tentare delle modifiche o il ripristino dalla copia di backup.

Aggiornamento repository

Il repository di InterChange Server è un database che contiene metadati relativi ai componenti di InterChange Server. E' possibile eseguire l'aggiornamento con o senza il database in attività. Il programma di installazione di ICS 4.3 non esegue automaticamente l'aggiornamento del contenuto del repository di ICS. Tuttavia, se viene utilizzato l'aggiornamento con il database in attività quando ICS è stato avviato nel passaggio precedente, ICS aggiornerà lo schema nel repository precedente 4.3 con alcune modifiche. A questo punto del processo di aggiornamento, è necessario decidere gli oggetti da caricare nel repository:

Importante:
Se si sta eseguendo l'aggiornamento senza il database in attività caricare il nuovo repository 4.3 con gli oggetti di repository preesistenti. Per ulteriori informazioni, consultare Caricamento oggetti di repository preesistenti.

E' possibile utilizzare la vista di gestione componenti di InterChange Server in System Manager su una macchinaWindows collegata, per sfogliare i componenti caricati nel server.

Caricamento oggetti di repository preesistenti

I passaggi descritti in questa sezione vengono richiesti solo se si esegue l'aggiornamento di InterChange Server senza il database in attività.

Come parte del processo di installazione ICS, i nomi di questi database ICS sono stati specificati nella procedura guidata di configurazione 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:

  1. Copiare i file di classeJava .class) per le mappe e le collaborazioni nella struttura della nuova directory:

    dove ProductDir è la directory del prodotto del nuovo rilascio 4.3. Questo passaggio garantisce che i file.class delle mappe e delle collaborazioni risiedano nella struttura della directory 4.3 nuova.

  2. Verificare che tutti i database utilizzati dal sistema ICS per le connessioni database e le relazioni siano in esecuzione. Verificare inoltre che ICS sia in esecuzione.
  3. Caricare gli oggetti di repository preesistenti seguendo queste indicazioni:
    1. Modificare il file di repository per correggere alcune incompatibilità.
    2. Eliminare dal repository qualsiasi oggetto in esso contenuto.
    3. Caricare gli oggetti preesistenti.

    Ognuno di questi passaggi di caricamento del repository è descritto nelle sezioni di seguito riportate.

Preparazione file di repository

I passaggi descritti in questa sezione vengono richiesti solo se si esegue un aggiornamento dalla versione 4.1.1.

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:

Nota:
Se non si desidera caricaretutti gli oggetti di repository nel file degli oggetti di repository preesistenti, è possibile rimuovere quelli a cui non si è interessati, dal file di repository importato nel repository 4.3.

Aggiornamento del nuovo repository

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 -ppasswd -d 
 

Nel comando precedente repos_copy:

Importazione file di repository

Per caricare il contenuto dei file di repository nel repository, utilizzare il programma di utilità repos_copy. Come descritto nella sezione Esecuzione copia di 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.

Nota:
Nella versione 4.1.1 di InterChange Server le definizioni del progetto sono state memorizzate nel repository. Nella versione 4.3 di InterChange Server, le definizioni dei progetti non vengono più memorizzate nel repository. Vengono ora definite attraverso le ICL (Integration Component Libraries) ed i progetti utenti. L'operazione di importazione carica tutti gli oggetti di repository definiti nel file di repository eccetto le definizioni dei progetti. Per ulteriori informazioni, consultare il manuale System Installation Guide for Windows.

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 nel repository nuovo, è necessario eseguire alcune ulteriori operazioni per completare l'aggiornamento delle mappe e delle maschere delle collaborazioni. Per ulteriori informazioni, consultare Completamento aggiornamenti mappe e maschere di collaborazione.

Copyright IBM Corp. 1997, 2004