Preparazione del sistema ICS esistente ICS

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".

  1. Passo 1 - Esecuzione backup del sistema di InterChange Server
  2. Passo 2 - Porre il sistema in uno stato di quiete
  3. Passo 3 - Disinstallazione InterChange Server e software di terze parti
  4. Passo 4 - Installazione InterChange Server e software di terze parti
  5. Passo 5 - Aggiornamento di ORB (Object Request Broker)
  6. Passo 6 - Aggiornamento InterChange Server
  7. Passo 7 - Avviare InterChange Server ed il software di terza parte
  8. Passo 8 - Caricare il repository
  9. Passo 9 - Speciali procedure di aggiornamento nella migrazione dalla versione 4.1.1
  10. Passo 10 - Convalida aggiornamento

Passo 1 - Esecuzione backup del sistema di InterChange Server

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:

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
Tipo di dati Metodo di esecuzione backup
Dati statici

Repository
Utilizzare il programma di utilità repos_copy per salvare alcuni o tutti i componenti personalizzati di InterChange Server. Per ulteriori informazioni, consultare la descrizione del modo in cui eseguire il back up dei componenti di InterChange Server nel manuale System Administration Guide.

Personalizzare file di classe Java di collaborazione (.class) e file di messaggio (.msg) Includere la directory secondaria collaborazioni della directory ProductDir nel backup del sistema:
ProductDir\collaborations 
 

Personalizzare i file di classe Java di mappa (.class)
Per includere questi file nel backup del sistema, è necessario che il backup del sistema contenga la seguente directory:
ProductDir\DLMs
 

Personalizzare connettori Includere la directory seguente nel backup del proprio sistema: ProductDir\connectors\connector_name, dove "connector_name" è il nome del connettore di personalizzazione.

Script di avvio personalizzati Se alcuni script di avvio sono stati personalizzati, è necessario includerli nel backup del sistema.

File di configurazione ICS (InterchangeSystem.cfg) Includere nel backup del proprio sistema il file di configurazione ICS, che risiede nella directory ProductDir.
Dati dinamici

Riferimenti incrociati, eventi di errore e tabelle di relazione Utilizzare il programma di utilità di esecuzione backup per il database. Per ulteriori informazioni, consultare la descrizione del modo in cui eseguire il back up dei componenti di InterChange Server nel manuale System Administration Guide.

Tabelle di archivio eventi connettore Utilizzare il programma di utilità di esecuzione backup per il database che contiene queste tabelle.

File di log Includere la directory seguente nel backup del sistema:
ProductDir
 

Passo 2 - Porre il sistema in uno stato di quiete

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:

  1. Inoltrare nuovamente gli eventi non riusciti o eliminarli (questo passaggio è facoltativo). E' possibile decidere di aggiornare gli eventi di errore a livello ICS ed elaborarli dopo l'aggiornamento del sistema.
  2. Arrestare tutti gli adattatori dall'esecuzione del polling delle tabelle eventi impostando la proprietà PollFrequency su No
  3. Consentire l'esecuzione di tutti gli eventi attraverso il sistema, compresi tutti gli eventi in elaborazione. E' necessario che siano risolte tutte le transazioni in dubbio.
  4. Arrestare le collaborazioni. Questa attività garantisce che non vi siano eventi in esecuzione su InterChange Server durante l'aggiornamento.
  5. Aggiornare le code rimuovendo tutti gli eventi obsoleti.
    Nota:
    Eseguire il passaggio 5 solo se non sono in elaborazione gli eventi di errore e scegliere di inoltrare gli eventi nuovamente dall'applicazione. Se si decide di aggiornare gli eventi di errore e si utilizza la funzione di trasporto MQ, NON aggiornare le code. E' necessario eseguire il backup delle code e ripristinarle dopo l'aggiornamento. Consultare la documentazione MQ relativa all'esecuzione del backup delle code.
  6. Chiudere InterChange Server e tutti i componenti relativi.
  7. Chiudere il database.
  8. Chiudere l'ORB (Visibroker) delle versioni di ICS precedenti alla 4.2.2.
  9. Chiudere MQSeries.

Consultare il manuale System Administration Guide per ulteriori informazioni sul modo in cui arrestare un sistema in esecuzione normalmente.

Passo 3 - Disinstallazione InterChange Server e software di terze parti

I passaggi seguenti elencano l'ordine corretto della disinstallazione del software di terza parte.

  1. Disinstallare l'ORB (Visibroker) (per le versioni precedenti alla 4.2.2)
  2. Disinstallare ICS (Uninstall InterChange Server)
  3. Disinstallare JDK
  4. Eliminare le tabelle del repository . Le tabelle verranno create nuovamente come parte dell'aggiornamento di ICS.
    Nota:
    Nell'aggiornamento del database sul posto non eliminare le tabelle del repository poiché il repository verrà utilizzato nuovamente nella nuova installazione.

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.

Passo 4 - Installazione InterChange Server e software di terze parti

I passaggi seguenti elencano l'ordine corretto in cui installare i componenti di InterChange Server.

Importante:
Se è necessario aggiornare del software di terze parti, è necessario definire un amministratore di sistema che esegua il backup del software prima dell'aggiornamento.
  1. Installare IBM JDK 1.4.2.
  2. Installare o aggiornare DBMS e rispristinare le tabelle di runtime se si desidera conservare i dati di runtime.

    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.

  3. Installare o aggiornare a WebSphere MQ 5.3.02 (CSD07).
    Importante:
    La necessità di eseguire i passaggi descritti in questa sezione dipende dalla propria versione corrente di InterChange Server:
    • Se si esegue un aggiornamento da una delle versioni 4.2.0, 4.2.1 o 4.2.2 di InterChange Server, non è richiesto l'aggiornamento di WebSphere MQ.
    • Se si esegue un aggiornamento da una versione 4.1.1 di InterChange Server, eseguire i passaggi descritti i questa sezione per migrare WebSphere MQ alla versione nuova.

    Quando si esegue un aggiornamento di MQ, è possibile seguire uno di questi percorsi:

    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.

  4. Installare InterChange Server in una directory diversa da quella in cui risiede la versione precedente di directory ICS.

Passo 5 - Aggiornamento di ORB (Object Request Broker)

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:

Nota:
Per una panoramica generale dell'ORB Java IBM, consultare il manuale System Administration Guide.

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.

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..

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

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.

Passo 6 - Aggiornamento InterChange Server

Fare riferimento a Aggiornamento script server e Completamento aggiornamenti dei componentiper informazioni di aggiornamento aggiuntive.

Note:

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

  2. Quando il programma di installazione richiede il nome dell'istanza ICS, è necessario che tale nome sia lo stesso della versione precedente alla 4.3 per garantire la portabilità degli eventi di errore.

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

Passo 7 - Avviare InterChange Server ed il software di terza parte

  1. Riavviare la macchina di InterChange Server.
  2. Avviare IBM ORB' Persistent Naming Server eseguendo il file batch PersistentNameServer.bat ubicato nella directory ProductDir\bin.
  3. Avviare IBM MQSeries.

    Verificare che sia il gestore code che il listener siano attivi ed in esecuzione.

  4. Avviare il database, se l'esecuzione è in locale.
  5. Se si esegue un aggiornamento dalla versione 4.1.1 copiare i file .class, .java e di messaggio di cui precedentemente era stato eseguito un backup, per DLM e collaborazioni nelle directory appropriate. Per i DLM, copiare i file in ProductDir\DLMs\classes ed in ProductDir\DLMs\messages. Per le collaborazioni, copiare i file in ProductDir\collaborations\classes ed in ProductDir\collaborations\messages.
  6. Per la migrazione database sul posto: è necessario indirizzare ICS al database su cui risiede il repository originale. E' possibile eseguire questa operazione riutilizzando il vecchio file InterchangeSystem.cfg o impostando i parametri database attraverso la procedura guidata di configurazione ICS.
  7. Avviare InterChange Server.

    Per le istruzioni sul modo in cui avviare InterChange Server, fare riferimento a "Impostazione di InterChange Server".

    Nota:
    E' necessario che il nome server sia lo stesso della versione precedente per garantire la portabilità degli eventi di errore.

    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.

Passo 8 - Caricare il repository

Nota:
Questo passaggio non è necessario se si esegue un aggiornamento database sul posto.

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.

Passo 9 - Speciali procedure di aggiornamento nella migrazione dalla versione 4.1.1

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.

  1. Riavviare il server appena installato.
  2. In System Manager, collegarsi al server.
  3. Creare un'ICL (Integration Component Library) temporanea e importare tutti i componenti dal server.
  4. Compilare tutte le maschere delle mappe e delle collaborazioni.
  5. Creare un progetto ed includervi tutti i componenti dell'ICL creata precedentemente.
  6. Cancellare il repository sul server.
  7. Distribuire il progetto sul server.

Per ulteriori informazioni sull'ICL consultare Importazione in un ICL.

Questi passaggi non sono necessari per la versione server 4.2.x.

Passo 10 - Convalida aggiornamento

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:

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

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:

Aggiornamento file di configurazione strumenti

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
 

Verifica variabili di ambiente

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.

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 modificare nè le tabelle eventi né i trigger in alcun modo se lo schema non è stato cambiato.

Aggiornamento 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:

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

Caricamento oggetti di repository preesistenti

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:

  1. Copiare i file di classe Java (.class) esistenti 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 esistenti risiedano nella struttura della nuova directory 4.3.

  2. verificare che tutti i database utilizzati dal sistema ICS per le relazioni e le connessioni database 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à. Per ulteriori informazioni, fare riferimento alla sezione Preparazione file di repository di seguito riportata.
    2. Eliminare dal repository qualsiasi oggetto in esso contenuto.
    3. Caricare gli oggetti preesistenti.

    Ognuno di questi passaggi relativi alla gestione degli oggetti di repository preesistenti è descritto nelle sezioni seguenti.

Preparazione file di repository

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 -pnull -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 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.

Nota:
L'operazione di importazione carica tutti gli oggetti di repository definiti nel file di repository eccetto le definizioni dei progetti. Le definizioni dei progetti non verranno più memorizzate nel repository. Vengono ora definite attraverso le ICL (Integration Component Libraries) ed i progetti utenti. Per ulteriori informazioni, consultare Importazione progetti utente esistenti.

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.

Copyright IBM Corp. 1997, 2004