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.
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.
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:
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à:
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.
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. |
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.
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).
Se sono stati creati file personalizzati nel sistema InterChange Server preesistente, è necessario valutare i file seguenti per determinare se richiedono aggiornamenti:
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:
Ad esempio, se si dispone di gestori dati personalizzati, aggiungere i file.jar relativi nella variabile CLASSPATH.
Una volta completato il processo di aggiornamento e la relativa verifica, è possibile rimuovere l'opzione -design dall'avvio del server in modo che ICS (InterChange Server) venga avviato in modalità di produzione.
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
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.
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.
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:
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.
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.
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:
Il programma di installazione copia automaticamente i file di input dei vari componenti di ICS in ProductDir ed in varie directory secondarie di ProductDir, che includono /repository (dove ProductDir è la directory del prodotto per il nuovo rilascio 4.3). Questi file di input contengono i nuovo componenti per il rilascio di ICS 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 di gestione componenti di InterChange Server in System Manager su una macchinaWindows collegata, per sfogliare i componenti caricati nel server.
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:
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 risiedano nella struttura della directory 4.3 nuova.
Ognuno di questi passaggi di caricamento del repository è descritto nelle sezioni di seguito riportate.
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:
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 questi attributi vengono eliminati per ciascuna relazione, InterChange Server utilizza 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 su una macchinaWindows collegata.
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:
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.
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.