Determinati componenti di InterChange Server richiedono delle attività
aggiuntive per completare gli aggiornamenti relativi. Le sezioni
seguenti descrivono il modo in cui completare tali aggiornamenti:
- 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 versione 4.1.1 di
InterChange Server, eseguire i passaggi contenuti in questa sezione per
importare i componenti ICS preesistenti in una ICL (Integration Component
Library).
- Se si esegue un aggiornamento da una delle versioni 4.2.0,
4.2.1 o 4.2.2 di InterChange Server,
non è necessario importare i componenti ICS in una ICL poichè le
ICL sono già esistenti. Passare alle istruzioni contenute in Completamento aggiornamenti mappe e maschere di collaborazione.
Avviando la versione 4.2.0, lo sviluppo dei componenti ICS
verrà eseguito localmente invece di essere eseguito nell'istanza ICS
(come in 4.1.1). Perciò, se si esegue un aggiornamento da
una versione 4.1.1, è necessario creare una ICL (Integrated
Component Library) all'interno di System Manager sulla macchinaWindows su
cui sono in esecuzione i propri strumenti. L'ICL contiene i
componenti InterChange Server. Fare riferimento al manuale System
Integration Guide per le informazioni relative alla creazione di
ICL. Dopo aver creato l'ICL (o le ICL), si è in grado di importare
i componenti dal repository di InterChange Server sulla macchinaUNIX.
- Nota:
- Si raccomanda di importare i componenti ICS suddivisi in varie parti, poichè
importare un'ampia quantità di dati potrebbe rallentare l'esecuzione
e provocare errori di memorizzazione su System Manager. Se si dispone
di una inusuale quantità di componenti, si potrebbe desiderare di interrompere
il processo di importazione anche se in fase avanzata. L'ordine
consigliato di importazione dei componenti è illustrato in Tabella 33.
Tabella 33. Ordine di importazione componenti ICS
Ordine
| Componente ICS
| Azioni di importazione
|
1
| Oggetti business
|
Importare le definizioni degli oggetti business preesistenti dal repository
ICS in una ICL all'interno di System Manager. Consultare il
manuale the Implementation Guide for WebSphere InterChange Server
per i dettagli sul modo in cui importare i componenti utilizzando la procedura
guidata di importazione componenti di System Manager.
|
2
| mappe
| Completamento aggiornamenti mappe e maschere di collaborazione
|
3
| Modelli ed oggetti di collaborazione
| Completamento aggiornamenti mappe e maschere di collaborazione
|
4
| Connettori
| Completamento aggiornamenti connettore
|
5
| Relazioni
|
Importare le definizioni di relazione preesistenti dal repository ICS in
una ICL all'interno di System Manager. Consultare il manuale the
Implementation Guide for WebSphere InterChange Server per i
dettagli sul modo in cui importare i componenti utilizzando la procedura
guidata di importazione componenti di System Manager.
|
Queste istruzioni sono necessarie solo se si esegue un aggiornamento dalla
versione 4.1.1.
Una volta aggiornato il repository ICS, è possibile completare
l'aggiornamento di qualsiasi mappa e maschera di collaborazione
preesistente. Questo aggiornamento implica i passaggi seguenti:
E' importante verificare i file di classe Java preesistenti
(.class) delle mappe e delle maschere di collaborazione per
accertarsi che il codice sia compatibile con la versione nuova.
- Nota:
- Verificare che i file di classe risiedano nella directory corretta della
versione nuova versione, come segue:
Verificare l'esistenza del codice seguente nei file di classeJava
preesistenti:
- Se un qualsiasi codice personalizzato nelle mappe e nelle collaborazioni
utilizza estensioni CORBA specifiche di VisiBroker, tale codice non funzionerà
nell'IBM ORBJava. E' necessario modificare quel codice in un
codiceJava neutrale per il fornitore. Se una collaborazione o una mappa
utilizzano IDL personalizzati con gli stub corrispondenti, utilizzare il
programma di compilazioneidlj per ricompilare tali stub. Per
tutte le piattaforme, il programma di compilazione idlj viene
fornito con JDK e si trova sul CD JDK.
- Nota:
- Il programma di compilazione idlj scaricato con JDK da Sun o HP
potrebbe non essere compatibile con IBM ORB. Utilizzare lo strumento
fornito sul CD JDK.
- JDK IBM è certificato per essere compatibileJava e per non implicare alcun
problema con l'esecuzione di classi di mappe e collaborazioni
precedentemente compilate. Tuttavia, se qualche collaborazione o
qualche mappa contengono un codice personalizzato specifico di Sun JDK, è
necessario modificarlo con un codice Java neutro per il fornitore.
Se viene modificato qualche file di classe Java è necessario compilare
nuovamente il codice e ridistribuire il componente associato al repository
ICS. Per informazioni sul modo in cui compilare le mappe, consultare il
manualeMap Development Guide. Per informazioni sul modo in
cui compilare le maschere di collaborazione consultare il manuale
Collaboration Development Guide. Per ulteriori informazioni
sul modo in cui ridistribuire, consultare la sezione Distribuzione su ICS.
- 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 versione 4.1.1
InterChange Server, eseguire le indicazioni contenute in questa sezione per
convertire il formato delle maschere e delle mappe di collaborazione
preesistenti.
- Se si esegue un aggiornamento da una delle versioni 4.2.0,
4.2.1 o 4.2.2 di InterChange Server,
non è necessario convertire il formato delle mappe e delle maschere
di collaborazione. Passare alle istruzioni contenute in Completamento aggiornamenti connettore.
E' necessario che le mappe e le maschere di collaborazione create con
le versioni del software di InterChange Server precedenti al rilascio
4.2.0 vengano convertite in un formato nuovo compatibile con il
software corrente. Nel nuovo formato, tutte le informazioni relative
alle mappe ed alle collaborazioni vengono memorizzate come parte delle
definizioni delle mappe e delle maschere di collaborazione nel
repository.
- Nota:
- Le mappe e le maschere di collaborazione create con le versioni del software
di InterChange Server precedenti al rilascio 4.0.0 utilizzano
file di modelli di collaborazione
(CollaborationName.clm) e file di progettazione
delle mappe(MapName.dlm), che non sono
più richiesti. Contattare il supporto tecnico IBM per
l'assistenza.
Per convertire le mappe e le maschere di collaborazione nel nuovo
formato:
- Importare le maschere e e mappe preesistenti dal repository di ICS in una
ICL (integration component library) all'interno di System Manager in
esecuzione su una macchinaWindows collegata. Consultare il manuale the
Implementation Guide for WebSphere InterChange Server per i
dettagli sul modo in cui importare i componenti utilizzando la procedura
guidata di importazione componenti di System Manager.
- Nota:
- La procedura guidata Importa componenti rileva qualsiasi associazione o
maschera di collaborazione in un formato precedente al 4.2. In
questo caso, chiede conferma per la conversione. Per disporre di mappe
e maschere di collaborazione convertite nel formato 4.3, verificare che
siano abilitate le caselle di controllo relative.
- Se le mappe e le maschere di collaborazione non sono state ancora
compilate ed importate a causa degli aggiornamenti dei file di
classe,(consultare Aggiornamento file di classe componenti), eseguire ora l'operazione. Per il modo in cui
compilare le mappe, consultare il manuale Map Development
Guide. Per il modo in cui compilare le maschere di
collaborazione, consultare il manuale Collaboration Development
Guide.
- Distribuire le maschere e le mappe di collaborazione aggiornate al
repository ICS sulla macchina UNIX utilizzando l'opzione di
sovrascrittura. Per ulteriori informazioni, consultare Distribuzione su ICS.
Questa sezione fornisce informazioni relative alle azioni da
intraprendere per aggiornare un connettore alla versione 4.3 di
InterChange Server:
- Installare gli adattatori relativi.
- Aggiornare il connettore al brocker di integrazione:
- Se sono stati personalizzati degli script di avvio del connettore,
potrebbe essere necessario aggiornarli. Per ulteriori informazioni,
consultare Aggiornamento script di avvio connettore.
- Verificare l'aggiornamento del connettore. Per ulteriori
informazioni, consultare Verifica configurazione connettore.
Per ottenere cheWebSphere Business Integration Adapter funzioni con
l'InterChange Server, è necessario installare la versione 2.6 di
un WebSphere Business Integration Adapter. Tuttavia, per una nuova
installazione, è impossibile copiare semplicemente le directory degli
adattatori esistenti(quelle contenute nelle directory secondarie della
directory ProductDir/connectors),poichè vi sono dei
componenti condivisi forniti dal programma di installazione diWebSphere
Business Integration Adapters. Non viene più utilizzato un singolo
programma di installazione per tutti gli adattatori è perciò necessario
installareogni adattatore relativo utilizzando il proprio programma
di installazione.
- Nota:
- Quando InterChange Server è il broker d'integrazione, non è necessario
installare il prodotto Adapter Framework separatamente. Adapter
Framework è incluso come parte dell'installazione di InterChange
Server.
Per ulteriori istruzioni più dettagliate sul modo in cui installare gli
adattatori, fare riferimento ai manuali relativi agli adattatori
singoli.
Se il file di configurazione ICS (InterchangeSystem.cfg)
contiene informazioni relative all'agente connettore verrà creato un file
di configurazione per ogni connettore elencato.
- Il percorso per il file di configurazione è stato modificato perciò è
necessario specificare il percorso completamente qualificato per questo file
sulla riga all'intero dello script di avvio connettore di
personalizzazione che richiama lo script
start_adapter.sh. Eseguire queste operazioni
utilizzando l'opzione -c , nel modo seguente:
start_adapter.sh -dconnector_name -nconnector_name
-cfully_qualified_name_of_new_config_file
- Per incorporare una definizione connettore aggiornata nel repository,
utilizzare il programma di configurazione connettore(sulla macchina Windows
collegata su cui sono in esecuzione i propri strumenti) per aprire il nuovo
file delle definizioni connettore fornito con il connettore(normalmente, il
nome del file fornito è
connectorName.txt).
Con il file aperto nel programma di configurazione connettore, impostare le
proprietà relative quindi scegliere Salva come progetto per salvare la
configurazione in System Manager. Da System Manager è possibile
distribuire la configurazione nel nuovo connettore su InterChange Server, come
descritto nel manuale Implementation Guide for WebSphere InterChange
Server.
- Nota:
- Per essere certi di disporre delle proprietà più recenti per il connettore
aggiornato, fare riferimento al manuale dell'adattatore
appropriato.
Per migrare i connettori da un broker messaggiWebSphere ( MQ
Integrator, MQ Integrator Broker o Business Integration Message Broker) al
sistema di InterChange Server rilascio 4.3, seguire questi
passaggi. E' necessario che alcuni di questi passaggi vengano
completati su una macchina Windows collegata, su cui sono in esecuzione i
propri strumenti.
- Utilizzare lo strumento System Manager per creare una nuova ICL
(Integration Component Library).
- Utilizzare il programma di configurazione connettore per confermare che
tutte le code specificate nella configurazione locale siano valide per
InterChange Server.
- Per ogni file di definizione connettore, utilizzare il programma di
configurazione connettore procedendo nel modo seguente:
- Modificare la proprietà connettore DeliveryTransport
daWebSphere Message Broker-JMS in JMS.
- Modificare la proprietà RepositoryDirectory in
REMOTE.
- Aggiornare le proprietà connettore, nel modo seguente:
- Aggiungere o eliminare le proprietà specifiche connettore. Per
essere certi di disporre delle proprietà specifiche connettore più recenti per
il connettore aggiornato, fare riferimento al manuale dell'adattatore
associato.
- E' necessario che tutte le proprietà standard appropriate dispongano
di un valore. Per essere certi di disporre delle proprietà standard più
recenti per il connettore aggiornato, fare riferimento all'appendice
delle proprietà standard nel manuale dell'adattatore associato.
- Utilizzare l'opzione Salva nel progetto in Connector Configurator per
salvare la definizione connettore nella ICL (Integration Component
Library).
- Utilizzare lo strumento Business Object Designer per aggiornare i file di
definizione oggetto business (.xsd) in modo da contenere le
informazioni sulla locale.
- Utilizzare l'opzione Salva nel progetto in Business Object Designer
per salvare la definizione di oggetto business nella ICL (Integration
Component Library).
- Da System Manager, distribuire la configurazione connettore aggiornata e
le definizioni oggetto business su InterChange Server, come descritto nel
manuale Implementation Guide for WebSphere InterChange
Server.
Tutti gli script di avvio di InterChange Server sono stati modificati per
consentire la migrazione dall'ORB VisiBroker all'IBM ORB
Java. Se gli script di avvio connettore della versione precedente a
4.2.2 sono stati modificati, è necessario eseguire le stesse
modifiche ai nuovi script di startup.
Il rilascio 4.2.2 ha introdotto una nuova struttura
script di avvio con le seguenti modifiche principali:
- Tutte le variabili di ambiente del sistema sono nuove e vengono 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). Per ulteriori
informazioni su questo fileCWSharedEnv.sh, consultare il
manuale System Administration Guide.
- Per avviare un connettore, utilizzare lo script di
avviostart_connName.sh, che contiene le
informazioni specifiche del connettore. Questo script
start_connName.sh richiama a sua volta il file
start_adapter.sh, che contiene le impostazioni generali di
tutti i connettori. Questo file imposta l'ambiente
dell'adattatore e richiama il connettore.
- Nota:
- La maggior parte degli adattatori distribuiti dall'IBM esistenti, non
utilizza ancora queste nuova struttura per gli script di avvio
relativi. Non è necessario modificare gli script di avvio di tali
adattatori distribuiti dall'IBM. Sarà necessario modificare solo
gli script di avvio degli adattatori di personalizzazione.
Se alcuni script di avvio connettore sono stati personalizzati in un
rilascio precedente al 4.2.2, sarà necessario riesaminarli per
verificare che le personalizzazioni vengano visualizzate nel file corretto
nella struttura di questo nuovo script di avvio utilizzato anche dalla
versione 4.3.
- Nota:
- Negli script di avvio connettore, è necessario includere i
file.jar nella variabile CLASSPATH (o JCLASSES) per i
gestori dati personalizzati utilizzati dal connettore. In particolare,
è bene verificare l'ordina in cui i gestori dei dati sono elencati nel
CLASSPATH. Ad esempio, se si utilizza il gestore dati XML, è necessario
che il file CwXMLDataHandler.jar sia ubicato davanti al file
CwDataHandler.jar. Un file
xml.class esiste in entrambi i file .jar
ed è necessario verificare che uno dei due sia il
fileCwXMLDataHandler.jar richiamato.
Una volta completato ogni aggiornamento connettore o ogni modifica,
verificare che il connettore sia configurato correttamente per il nuovo
ambiente. Procedere nel modo seguente:
- Verificare che il connettore disponga della password e del nome utente
corretti (se modificati) e che sia indirizzato al sistema corretto.
- Verificare che ogni connettore sia indirizzato all'applicazione
appropriata e utilizzi le impostazioni corrette eseguendo un controllo con lo
strumento di gestione database o con l'applicazione.
E' necessario aggiornare il client di accesso in modo che funzioni con
IBM Java ORB o se si preferisce, con un'altra implementazione ORB che sia
compatibile con CORBA 2.3. Contattare il proprio fornitore ORB
per verificare che il proprio ORB sia compatibile con CORBA 2.3.
La parte rimanente di questa sezione presume che si stia operando con IBM Java
ORB.
Per aggiornare un client di accesso che utilizza correntemente ORB
VisiBroker all'uso di IBM Java ORB, procedere nel modo seguente:
- La versione precedente del file IOR (Interoperability Object Reference)
(.ior), generata con l'ORB VisiBroker e copiata sulla
macchina che contiene il client di accesso, è necessario che venga sostituita
con un file .ior che l'IBM ORBJava genera dopo
l'avvio di InterChange Server.
- E' necessario che il file AccessInterfaces.idl
venga ricompilato con il programma di compilazione idlj.
Utilizzare il programma di compilazione idlj fornito con il CD
JDK.
- Nota:
- Se JDK è stato scaricato da Sun o HP, il programma di compilazione idlj
incluso potrebbe non essere compatibile con l'ORB IBM.
Utilizzare il programma di compilazione idlj compiler provided on
the JDK CD.
- E' necessario che il codice contenuto nel client di accesso
inizializzi l'ORB IBM invece dell'ORB VisiBroker. Ad esempio,
nel frammento di codice tratto dell'esempio servlet nel manuale
Access Development Guide sono state modificate due proprietà di
inizializzazione CORBA in modo da riportare l'utilizzo dell'ORB IBM
piuttosto che dell'ORB VisiBroker. Di seguito verrà illustrato il
modo in cui eseguire questa operazione, le modifiche verranno visualizzate in
grassetto.
Properties orbProperties=new java.util.Properties();
orbProperties.setProperty("org.omg.CORBA.ORBClass",
"com.inprise.vbroker.orb.ORB");
orbProperties.setProperty("org.omg.CORBA.ORBSingletonClass",
"com.inprise.vbroker.orb.ORBSingleton");
org.omg.CORBA.ORB orb =
org.omg.CORBA.ORB.init((String[])null, orbProperties);
Aggiornato correttamente, il codice del client di accesso diventa:
Properties orbProperties=new java.util.Properties();
orbProperties.setProperty("org.omg.CORBA.ORBClass",
"com.ibm.CORBA.iiop.ORB");
orbProperties.setProperty("org.omg.CORBA.ORBSingletonClass",
"com.ibm.rmi.corba.ORBSingleton");
org.omg.CORBA.ORB orb =
org.omg.CORBA.ORB.init((String[])null,orbProperties);
Se il client di accesso viene utilizzato dall'interno di unservlet,
l'ORB IBM verrà contenuto nel runtime diWebSphere Application
Server. Perciò, si richiedono le seguenti modifiche:
- Rimozione di tutti i riferimenti VisiBroker
.jar dal percorso di classe.
- Ricompilazione file AccessInterfaces.idl, come
descritto.
- Verifica che il codice servlet inizializzi l'ORB IBM invece
dell'ORB VisiBroker, come descritto.
Se viene utilizzato un Accesso WebSphere per EJB, l'ORB IBM Java sarà
contenuto nel runtime diWebSphere Application Server. In questo caso,
l'unica modifica richiesta sarà di rimuovere i riferimento VisiBroker
.jar dal percorso di classe, perchè il file di Accesso per
EJB .jar contiene tutti gli altri artefatti necessari, come
l'IDL compilato ed il bean di sessione.
Se sono stati creati altri componenti che dispongono di file
.jar di personalizzazione (come i gestori dati), è
necessario copiare i file .jar di personalizzazione
nell'ubicazione appropriata nella nuova struttura directory. Di
solito, i file .jar di personalizzazione risiedono nella
directory secondarialib della directory del prodotto.
- Nota:
- E' inoltre necessario che tali file.jar di
personalizzazione vengano elencati negli script di avvio corretti. Per
ulteriori informazioni, consultare Aggiornamento script di avvio server.
A causa di modifiche della struttura dati interna nell'agente
SNMP per il rilascio 4.3, il vecchio file di stato (sts) non verrà più
riconosciuto. Il file di stato contiene le informazioni relative ai
nomi community dell'agente (che agiscono come password), destinazioni di
inoltro intercettazioni, connessioni ICS di destinazione e
password e nome utente di sicurezza RBAC. Una volta aggiornato
l'agente SNMP al rilascio 4.3, sarà necessario eseguire il gestore
di configurazione SNMP per reinserire le informazioni precedentemente salvate
nel file di stato.
E' necessario inoltre che l'utente esegua la
riconfigurazione manualmente se la console di gestione viene utilizzata con
l'agente SNMP poichè verrà modificato il file MIB. Il file MIB
verrà utilizzato dalla Console di gestione per conoscere le informazioni
fornite dall'agente SNMP. Tale file viene modificato nel rilascio
4.3, perciò sarà necessario che gli utenti che utilizzano il nuovo
agente SNMP carichino il nuovo file MIB nella propria console di
gestione.
- Nota:
- Mentre i formato del file di configurazione resta immodificato,
viene invece cambiato il nome del file dacwsnmpagent.cfg a
wbi_snmpagent.cfg, si raccomanda perciò caldamente di
utilizzare la procedura guidata di configurazione SNMP per creare la versione
nuova. E' importante eseguire questa operazione prima di avviare
l'agente SNMP.
Se si utilizza System Monitor, le viste ed i monitor esistenti
vengono migrati in modo che siano compatibili con ICS versione
4.3. Questa operazione viene eseguita automaticamente quando
l'utente accede a System Monitor.
- 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 versione 4.1.1
InterChange Server, è necessario creare dei progetti utente per i componenti
ICS. Passare alle istruzioni contenute in Creazione progetti.
- Se si esegue un aggiornamento dalle versioni 4.2.0,
4.2.1 o 4.2.2 di InterChange Server ed i progetti
utente esistenti sono stati esportati (come descritto in Migrazione progetti esistenti), eseguire le operazioni indicate in Importazione progetti esistenti per importare i progetti utente
esistenti. Se non si dispone di progetti esistenti, è possibile seguire
i passaggi descritti in Creazione progetti.
Se i propri progetti utente sono stati esportati, è possibile importarli
una volta che ICS sia in esecuzione. Collegare System Manager in
esecuzione su una macchina Windows connessa alla propria istanza di ICS ed
eseguire queste istruzioni:
- Espandere la cartella Progetti utente, fare clic con il tastino destro del
mouse su Progetti InterChange Server e selezionare Importa soluzione.
- Selezionare l'ubicazione della cartella creata durante
l'esportazione dalla versione precedente alla 4.3.
- Verificare che tutti i progetti utente siano stati importati
correttamente.
Si raccomanda di creare un progetto per ogni interfaccia ed un progetto
separato per i componenti comuni (come metaoggetti e connettori).
Collegare System Manager in esecuzione su una macchina Windows connessa alla
propria istanza di ICS ed eseguire queste istruzioni:
- fare clic su Progetti utente e selezionare Nuovo progetto utente.
- Assegnare un nome al progetto utente. E' necessario che questo
nome identifichi l'interfaccia in modo univoco.
- Nota:
- E' impossibile che il nome di un progetto utente sia lo stesso di un
progetto utente esistente o di un progetto ICL esistente.
- Selezionare i componenti del progetto utente. Questo passaggio crea
un percorso abbreviato per ciascuno dei componenti richiesti. I
componenti rimangono nella stessa ICL.
Per ulteriori informazioni sul modo in cui creare i progetti, consultare il
manuale Implementation Guide for WebSphere InterChange
Server.
- 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 versione 4.1.1 di
InterChange Server, eseguire i passaggi descritti in questa sezione per
distribuire i componenti ICS preesistenti nel nuovo repository.
- Se si esegue un aggiornamento da una delle versioni 4.2.0,
4.2.1 o 4.2.2 di InterChange Server, è necessario
solo distribuire le mappe o le maschere di collaborazione se sono stati
modificati i file di classe(come descritto nella sezione Aggiornamento file di classe componenti). Per distribuire le mappe o le maschere di
collaborazione, eseguire queste operazioni. Altrimenti, passare alle
istruzioni contenute inConvalida aggiornamento.
Con i progetti utente ed ICL definiti all'interno di System Manager su
una macchinaWindows collegata, è possibile distribuire i componenti contenuti
nel repository di InterChange Server sulla macchina UNIX. Se non sono
state eseguite modifiche ai componenti ICS, sarà necessario distribuire
nuovamente solo le maschere e le mappe di collaborazione.
Con System Manager collegato alla propria istanza di ICS, eseguire queste
attività:
- Fare clic con il tastino destro del mouse sul progetto utente e
selezionare Distribuisci progetto utente.
- Dall'elenco a discesa delle istanze ICS connesse e
registrate,selezionare le istanze ICS di destinazione per la
distribuzione.
- Arrestare e riavviare InterChange Server.
Consultare il manuale Implementation Guide for WebSphere InterChange
Server per i dettagli sul modo in cui distribuire i componenti sul
server.
