Migrazione

Transcript

Migrazione

WebSphere Portal
®
Versione 6.0
Migrazione
򔻐򗗠򙳰
Versione 6.0
Quest’edizione è valida per WebSphere Portal Versione 6.0.
Sul retro della pubblicazione è presente un modulo per i commenti del lettore. Se è stato rimosso, inviare i propri
commenti al seguente indirizzo:
International Business Machines Corporation
Department R0JA
P.O. Box 12195
Research Triangle Park, North Carolina
27709-2195
Quando gli utenti inviano informazioni all’IBM, concedono all’IBM un diritto non esclusivo ad utilizzare o
divulgare le informazioni ricevute secondo le modalità ritenute appropriate, senza alcun obbligo nei loro confronti.
© Copyright International Business Machines Corporation 2000, 2006. Tutti i diritti riservati.
Indice
Capitolo 1. Migrazione
. . . . . . . . 1
Pianificazione . . . . . . . . . . . . . . 1
Preparazione dell’ambiente precedente per la
migrazione . . . . . . . . . . . . . . . 4
Migrazione delle risorse personalizzate . . . . . 7
Migrazione dei portlet cooperativi che utilizzano
l’API portlet IBM . . . . . . . . . . . . 7
Migrazione dei portlet generati con Struts Portlet
Framework . . . . . . . . . . . . . . 8
Migrazione di applicazioni per processi di
business . . . . . . . . . . . . . . 15
Preparazione all’esecuzione delle attività di
migrazione . . . . . . . . . . . . . . 16
Migrazione delle configurazioni di WebSphere
Portal . . . . . . . . . . . . . . . . 20
Utilizzo di script per la riga comandi . . . . . 21
Utilizzo della procedura guidata di migrazione
24
Migrazione della configurazione del controllo
accessi restante . . . . . . . . . . . . . 28
© Copyright IBM Corp. 2000, 2006
Migrazione di componenti aggiuntivi . . . . .
Document Manager: migrazione da 5.0.x a 6.0 .
Document Manager: migrazione da 5.1.x a 6.0 .
Personalization: migrazione da 5.0 a 6.0 . . .
Personalization: migrazione da 5.1 a 6.0 . . .
Personalization: migrazione dei dati esportati da
5.1 a 6.0 . . . . . . . . . . . . .
Migrazione di Web Content Management . .
Migrazione della configurazione del processo
business . . . . . . . . . . . . .
Migrazione dei temi . . . . . . . . . .
Verifica delle attività di migrazione . . . . .
.
.
.
.
.
36
36
37
39
41
. 42
. 43
. 61
. 62
. 67
Capitolo 2. Informazioni particolari e
marchi . . . . . . . . . . . . . . . 71
iii
iv
Migrazione
Questa sezione fornisce una guida dettagliata per la migrazione dalle versioni
precedenti di IBM WebSphere Portal alla versione corrente di WebSphere Portal:
Importante: eseguire il processo di migrazione rispettando l’ordine indicato di
seguito. Alcune informazioni, quali la migrazione della risorse
personalizzate e la migrazione dei componenti aggiuntivi, sono
facoltative e dipendono dal livello di personalizzazione del portale e
dai componenti installati.
Pianificazione
Questo argomento fornisce informazioni sulla migrazione, le funzioni supportate e
gli strumenti utilizzati per eseguire la migrazione.
Definizione di migrazione
La migrazione è un processo di rigenerazione del precedente ambiente di IBM
WebSphere Portal in un nuovo ambiente quasi identico della Versione 6.0,
comprese le applicazioni e le impostazioni di configurazione.
Versioni di WebSphere Portal supportate
Le seguenti versioni di WebSphere Portal possono essere migrate in WebSphere
Portal Versione 6.0:
Tabella 1. Versioni di WebSphere Portal supportate per la migrazione
Offerta
Versione supportata
IBM WebSphere Portal - Express
Versione 5.0.2.1, 5.0.2.2 e 5.0.2.3
IBM WebSphere Portal - Express Plus
Versione 5.0.2.1, 5.0.2.2 e 5.0.2.3
IBM WebSphere Portal Enable
Versione 5.0.2.1, 5.0.2.2, 5.0.2.3
5.1.0, 5.1.0.1, 5.1.0.2, 5.1.0.3 e successive
IBM WebSphere Portal Extend
Versione 5.0.2.1, 5.0.2.2, 5.0.2.3
5.1.0, 5.1.0.1, 5.1.0.2, 5.1.0.3 e successive
IBM Workplace Web Content Management
IBM Workplace Web Content Management
versione 2.5, 2.6 e successive
WebSphere Portal versione 5.1.0, 5.1.0.1,
5.1.0.2, 5.1.0.3 e successive
Nota: la migrazione è supportata tra le stesse famiglie di prodotti (Express,
Express Plus, Enable, Extend). Inoltre, è supportata la migrazione da Express
a Enable, da Express Plus a Extend, da Express a Extend e da Enable a
Extend.
Nella rimanente parte della sezione relativa alla migrazione, tutte le versioni di
WebSphere Portal precedenti a Versione 6.0 saranno indicate nel complesso come
versioni precedenti e la Versione 6.0 sarà indicata come versione corrente.
1
Hardware, software, sistemi operativi e server di database
supportati
Fare riferimento agli argomenti Hardware e software supportati per la versione
corrente e precedente di WebSphere Portal, per confrontare i componenti
supportati.
La migrazione è possibile da una versione precedente di un sistema operativo ad
una versione più recente del sistema operativo. Tuttavia, non è supportata la
migrazione tra sistemi operativi differenti. Ad esempio, non è possibile migrare da
un sistema operativo Windows ad un sistema operativo Linux.
La migrazione è possibile da una versione precedente del server di database ad
una versione più recente del server di database. Tuttavia, non è supportata la
migrazione tra server di database differenti. Ad esempio, non è possibile migrare
da un server di database DB2 ad un server di database Oracle.
Importante: Inoltre, per essere sicuri che la migrazione funzioni correttamente,
tutti gli utenti ed i gruppi devono essere gli stessi fra le diverse
versioni.
Suggerimento: Eseguire il backup del database corrente prima di iniziare il
processo di migrazione.
Oggetto della migrazione
Le seguenti informazioni sono migrate automaticamente utilizzando gli script di
riga comandi o la procedura guidata di migrazione:
v Configurazione di temi e skin: le informazioni sulla configurazione di temi e
skin per WebSphere Portal. Queste informazioni di configurazione includono i
titoli specifici per locale di temi e skin e le informazioni sugli skin ammessi per i
temi.
v Applicazioni portlet e portlet: sono fornite attività di migrazione per facilitare la
distribuzione delle applicazioni portlet personalizzate. Oltre alla distribuzione,
queste attività migrano anche le informazioni di controllo accessi associate.
v Risorse del portale: il controllo accessi corrispondente viene migrato
automaticamente insieme agli artefatti.
v Personalizzazioni utente: le personalizzazioni create da utenti privilegiati che
effettuano modifiche ad una copia privata della pagina.
v Dati portale virtuale: i dati del portale virtuale vengono migrati, sebbene sia
necessario ricreare il portale virtuale nella versione corrente, prima di eseguire la
migrazione; il titolo ed il contesto URL devono essere gli stessi nella versione
corrente e in quella precedente. Per ulteriori informazioni sulla creazione di
portali virtuali, consultare Portali virtuali multipli e la guida in linea.
v Markup: consultare Supporto di nuovi linguaggi di markup per informazioni
sulle lingue delle markup.
v Preferiti: è necessario abilitarlo dopo la migrazione; consultare “Abilitazione
della funzione Organizza preferiti nei temi” a pagina 63.
v Cavi di pagine incrociate: accertarsi che tutte le correzioni temporanee siano
state applicate prima di eseguire la migrazione; per ulteriori informazioni,
consultare “Preparazione dell’ambiente precedente per la migrazione” a pagina
4.
2
Migrazione
v Tecnologia di conversione di codifica: se si sta utilizzando la tecnologia di
conversione di codifica nell’ambiente precedente, occorre abilitarla nella versione
corrente; per ulteriori informazioni, consultare Definizione di Transcoding
Technology
v Web Content Management: occorrerà migrare i dati di contenuto Web ed i
portlet dopo la migrazione di WebSphere Portal. Consultare “Migrazione di Web
Content Management” a pagina 43.
Le seguenti informazioni devono essere migrate manualmente, prima della
migrazione (consultare “Migrazione delle risorse personalizzate” a pagina 7) o
dopo la migrazione (consultare “Migrazione della configurazione del controllo
accessi restante” a pagina 28):
v Configurazione di temi e skin personalizzati: sarà necessario aggiornare
manualmente temi e skin per una corretta operatività delle nuove funzioni, ad
esempio (ma non limitato a) menu contestuali e trascinamento; consultare
“Migrazione dei temi” a pagina 62.
v I file delle proprietà e le impostazioni globali e di servizi sono specifici per il
nodo e la versione e devono essere sostituiti dalle modifiche alla configurazione
effettuate dal sistema
v Controllo accessi e modifica delle pagine di gestione e dei portlet; consultare
“Migrazione della configurazione del controllo accessi restante” a pagina 28 per
informazioni
v Dati di protezione credenziali; per informazioni consultare “Migrazione della
configurazione del controllo accessi restante” a pagina 28
v È richiesto l’aggiornamento manuale dei portlet struts generati con la versione
precedente di Struts Framework; per informazioni consultare “Migrazione dei
portlet generati con Struts Portlet Framework” a pagina 8
v È richiesta la creazione di un nuovo pacchetto dei portlet cooperativi per
aggiornare il file pbportlet.jar; per informazioni, consultare “Migrazione dei
portlet cooperativi che utilizzano l’API portlet IBM” a pagina 7
v Portlet personalizzati; consultare “Migrazione delle risorse personalizzate” a
pagina 7
v Migrazione delle raccolte di ricerca tra le versioni del portale
Importante: Durante il processo di migrazione alcune informazioni della versione
precedente di WebSphere Portal non verranno migrate nella versione
corrente, ad esempio portlet ed componenti che non sono più
supportati. Un esempio di componente non più supportato è WPAI;
questo componente e le applicazioni create con esso non verranno
migrati alla versione corrente. Per ulteriori informazioni sulle novità
della nuova versione, consultare Novità.
Ubicazione delle due versioni di WebSphere Portal
L’ubicazione della versione corrente di WebSphere Portal è indicata come macchina
locale. La versione precedente si può trovare sulla stessa macchina della versione
corrente. Consultare la sezione Software da installare sulla macchina del portale
nell’argomento Considerazioni sulla pianificazione per informazioni sulle
limitazioni di compresenza di altri prodotti forniti con WebSphere Portal. Se
entrambe le versioni sono installate sulla stessa macchina, tuttavia, le limitazioni di
risorse impediscono che siano in esecuzione allo stesso tempo. Di conseguenza, le
attività di migrazione possono essere realizzate in due fasi distinte: esportazione e
importazione. La versione precedente può essere collocata su una macchina
separata o remota.
3
Strumenti di migrazione
I seguenti strumenti, o combinazioni di strumenti, possono essere utilizzati per
migrare la versione precedente alla versione corrente:
v Script di riga comandi: fare riferimento a “Utilizzo di script per la riga
comandi” a pagina 21 per informazioni sull’utilizzo di script per eseguire la
migrazione. Utilizzare gli script per eseguire la migrazione se si verifica uno dei
seguenti scenari:
– La versione precedente di WebSphere Portal è in esecuzione su una macchina
diversa da quella della versione corrente
– L’ambiente non dispone di una interfaccia grafica
– È necessario migrare i portali virtuali
v Procedura guidata di migrazione: fare riferimento a “Utilizzo della procedura
guidata di migrazione” a pagina 24 per informazioni sull’utilizzo della
procedura guidata di migrazione. La procedura guidata di migrazione è
un’alternativa agli script di riga comandi; è possibile utilizzare la procedura
guidata di migrazione per eseguire la fase di migrazione se si verifica il seguente
scenario:
– La versione precedente di WebSphere Portal e la versione corrente di
WebSphere Portal si trovano sulla stessa macchina
Passi successivi
Questo passo è stato completato. Continuare con il passo successivo selezionando
il seguente argomento:
v “Preparazione dell’ambiente precedente per la migrazione”
Informazioni correlate
v Novità
Preparazione dell’ambiente precedente per la migrazione
Questa sezione descrive le attività manuali necessarie per preparare il precedente
ambiente IBM WebSphere Portal alla migrazione.
Per assicurare una corretta migrazione, occorre ripulire l’ambiente precedente ed
applicare le seguenti correzioni temporanee all’appropriato ambiente WebSphere
Portal precedente:
Importante: Occorre applicare le correzioni nell’ordine qui di seguito fornito per
garantire un corretto processo di migrazione.
1. Ripulire l’ambiente precedente se si è eseguita l’eliminazione di pagine, risorse,
utenti o gruppi per essere sicuri di avere una migrazione pulita:
v Se si sono eliminate delle pagine del portale, consultare Ripulitura ritardata
delle pagine del portale eliminate.
v Se si sono eliminate delle risorse, ci potrebbero essere dei dati orfani;
consultare Eliminazione di dati orfani.
v Se si sono eliminati degli utenti o dei gruppi utilizzando il registro utenti
configurato, consultare Annullamento registrazione di utenti e gruppi da
WebSphere Portal.
2. Convalidare i valori di proprietà del database
4
Migrazione
Eseguire l’attività validate-database-connection sull’ambiente precedente per
verificare che nel file wpconfig.properties siano stati specificati i valori corretti
perché questi valori sono richiesti quando si eseguono le attività di migrazione.
3. Attenersi alla seguente procedura per applicare le seguenti correzioni
temporanee all’ambiente precedente:
a. Creare una directory di aggiornamento sulla directory WebSphere Portal
precedente: ad esempio, C:\Program Files\WebSphere\PortalServer\update.
b. Scaricare il programma di installazione dell’aggiornamento di WebSphere
Portal da http://www-3.ibm.com/software/genservers/portal/support/
alla directory di aggiornamento creata al passo precedente.
c. Decomprimere le correzioni temporanee dalla directory appropriata della
directory di WebSphere Portal corrente alla directory di aggiornamento
creata al passo precedente:
v root_server_portale/migration/fixes/510
d. Immettere il seguente comando sulla riga comandi per impostare la
variabile di ambiente WAS_HOME per la directory della versione
precedente dove si eseguirà il programma di installazione
dell’aggiornamento di WebSphere Portal:
v Windows: set WAS_HOME=was_old_root; ad esempio set
WAS_HOME=C:\Program Files\WebSphere\AppServer
v UNIX: export WAS_HOME=was_old_root; ad esempio export
WAS_HOME=/opt/Websphere/AppServer
v i5/OS: export WAS_HOME=was_old_root; ad esempio export
WAS_HOME=/opt/Websphere/AppServer
e. Immettere il seguente comando sulla riga comandi per installare le
correzioni temporanee per la versione precedente:
v Windows: .\updatePortal.bat -install -installDir wp_old_root -fix
-fixDir wp_old_root/update -fixes elenco delle correzioni; ad
esempio updatePortal.bat -install -installDir "C:\Program
Files\WebSphere\PortalServer" -fix -fixDir "C:\Program
Files\WebSphere\PortalServer\update" -fixes PK07258 PK07872
v UNIX: ./updatePortal.sh -install -installDir wp_old_root -fix
-fixDir wp_old_root/update -fixes elenco di correzioni; ad esempio
./updatePortal.sh -install -installDir /opt/WebSphere/PortalServer
-fix -fixDir /opt/WebSphere/PortalServer/update -fixes PK07258
PK07872
v i5/OS: ./updatePortal.sh -install -installDir wp_old_root -fix
-fixDir wp_old_root/update -fixes elenco delle correzioni; ad
esempio updatePortal.sh -install -installDir /opt/WebSphere/
PortalServer -fix -fixDir /opt/WebSphere/PortalServer/update -fixes
PK07258 PK07872
f. Applicare le seguenti correzioni temporanee per la versione 5.1.0 (tutte le
piattaforme):
1) PQ96317
2) PQ98046
3) PQ97287
4) PQ95975
5
5)
6)
7)
8)
9)
10)
11)
PQ97656
PQ99439
PQ99519
PK01286
PK00826
PK03737
PK01695
12) PK07872
13) PK14100
14) PK15013
15) PK19790
16) PK23171
17) PK20467
g. Applicare le seguenti correzioni temporanee per la versione 5.1.0.1 (tutte le
piattaforme):
1) PK07872
2) PK14100
3) PK14103
4) PK15013
5) PK19790
6) PK23171
7) PK20467
8) PK16371
9) PK16597
10) PK18538
11) PK21688
12) PK07258
13) PK17690
14) PK21136
15) PK23901
h. Applicare le seguenti correzioni temporanee per la versione 5.1.0.2 (tutte le
piattaforme):
1) PK14100
2) PK14103
3) PK15013
4) PK19790
5) PK23171
6) PK20467
7) PK16371
8) PK16597
9) PK18538
10) PK21688
11) PK17690
12) PK21136
13) PK22244
6
Migrazione
14) PK23901
i. Applicare le seguenti correzioni temporanee per la versione 5.1.0.3 (tutte le
piattaforme):
1) PK23171
2) PK20467
3) PK18538
4) PK21688
5) PK21136
6) PK22244
7) PK23901
j. Applicare le seguenti correzioni temporanee (solo per iSeries):
v 510:
1) PK01639
2) PK08409
3) PK11536
v 5101:
1) PK08409
2) PK11536
v 5102:
1) PK11536
Migrazione delle risorse personalizzate
Alcuni passi della migrazione sono facoltativi in funzione delle risorse
personalizzate presenti nella versione precedente di IBM WebSphere Portal. È
necessario migrare solo le risorse importanti per l’ambiente.
Selezionare le risorse personalizzate da migrare:
v “Migrazione dei temi” a pagina 62: migrare i temi e gli skin, se si desidera
utilizzare una nuova funzionalità con i temo e gli skin esistenti
v Ricreare le proprie Impostazioni globali e Configurazione dei servizi Portal
v Migrare i portlet creati utilizzando uno dei due metodi di seguito indicati:
– Copiare i file .war nella directory root_server_portale/installableApps
– Installare i portlet prima di eseguire la migrazione; consultare Distribuzione
di risorse J2EE con file WAR dell’applicazione portlet per informazioni sulla
distribuzione dei portlet
Migrazione dei portlet cooperativi che utilizzano l’API portlet
IBM
Il termine portlet cooperativi si riferisce alla capacità dei portlet su una pagina di
interagire fra loro condividendo le informazioni. Uno o più portlet cooperativi su
una pagina del portale possono reagire automaticamente alle modifiche da un
portlet di origine attivato da un’azione o da un evento nel portlet di origine. I
portlet che sono destinazioni dell’evento possono reagire in modo che agli utenti
non venga richiesto di eseguire modifiche o azioni ripetitive in altri portlet sulla
pagina. Ciò consente una funzionalità coordinata e coerente tra i portlet sulla
pagina e migliora l’esperienza generale degli utenti. La cooperazione tra portlet di
origine e di destinazione è facilitata da un’entità di runtime WebSphere Portal
denominata broker di proprietà. I portlet su una pagina possono collaborare in
7
questo modo anche se sono stati distribuiti in modo indipendente, senza la
consapevolezza, da parte del programmatore, dell’esistenza degli altri portlet
cooperativi.
Dalla la versione 5.1.0.1, WebSphere Portal supporta la comunicazione del portlet
fra pagine per i portlet cooperativi, consentendo ai portlet di pagine diverse di
comunicare. Per informazioni sulla configurazione di gestione necessaria,
consultare Collegamento di portlet cooperativi. Inoltre, i portlet che utilizzano
Struts o JavaServer Faces, come anche i portlet che utilizzano le API di portlet
standard, possono usare le funzioni dei portlet cooperativi. Per informazioni
dettagliate, consultare Integrazione di Struts con i portlet cooperativi.
La procedura di migrazione dipende dalla versione di pbportlet.jar utilizzata
dall’applicazione. Le applicazioni, che includono nei pacchetti versioni più recenti
di pbportlet.jar, possono non richiedere alcuna modifica quando si migra alla
versione corrente. Ad esempio, un’applicazione portlet cooperativo che include nel
pacchetto il file pbportlet.jar della versione 5.1.0.1 può essere distribuito nella
versione corrente senza alcuna modifica all’applicazione. Le applicazioni che
includono nei pacchetti versioni precedenti di pbportlet.jar possono richiedere
una procedura di migrazione manuale per aggiornare il file WAR in per poter
avere il supporto per comunicazioni di portlet fra le pagine. Ad esempio,
un’applicazione che include nei pacchetti pbportlet.jar versione 5.0 richiede la
migrazione se l’applicazione viene distribuita nella versione corrente. Inoltre, la
migrazione al file jar più aggiornato fornisce l’ultimo codice supportato.
Migrazione dei portlet
Le applicazioni portlet cooperativi che utilizzano precedenti versioni precedenti del
file pbportlet.jar possono essere migrate alla versione corrente. La procedura per
eseguire la migrazione di un’applicazione portlet aggiorna il file pbportlet.jar
utilizzato dall’applicazione.
Nell’installazione della versione corrente, individuare il file pbportlet.jar nella
directory root_server_portale/pb/lib. Questa directory contiene il pbportlet.jar
necessario per migrare un portlet cooperativo alla versione corrente. Eseguire la
seguente procedura per migrare i portlet:
v Copiare il file pbportlet.jar dalla directory root_server_portale/pb/lib alla
directory WEB-INF/lib dell’applicazione portlet cooperativo che si sta migrando.
Nota: sovrascrivere i file JAR se sono già esistenti.
Migrazione dei portlet generati con Struts Portlet Framework
Struts Portlet Framework è progettato per consentire agli utenti di creare pacchetti
di applicazioni portlet Struts da distribuire su più versioni di WebSphere Portal. La
procedura di migrazione dipende dalla versione Struts Portlet Framework
utilizzata dall’applicazione. Le applicazioni, che creano pacchetti con versioni più
recenti di Struts Portlet Framework, possono non richiedere alcuna modifica
quando si migra alla versione corrente di WebSphere Portal. Ad esempio,
un’applicazione portlet Struts che crea pacchetti di Struts Portlet Framework
versione 5.1.0.1 può essere distribuita sulla versione corrente di WebSphere Portal
senza che sia richiesta alcuna modifica. Le applicazioni che creano pacchetti con le
precedenti versioni di Struts Portlet Framework possono richiedere una procedura
di migrazione manuale per aggiornare il file WAR. Ad esempio, un’applicazione
che crea pacchetti con Struts Portlet Framework versione 4.x richiede la migrazione
8
Migrazione
se l’applicazione sarà distribuita con la versione corrente di WebSphere Portal. Se
non è richiesta una procedura manuale di migrazione, lo sviluppatore del portlet
può scegliere di migrare alla versione corrente di Struts Portlet Framework per
trarre vantaggio dalle nuove funzioni e/o correzioni del nuovo Struts Portlet
Framework.
Di seguito viene riportato un elenco delle versioni Struts Portlet Framework
rilasciate in WebSphere Portal o nel catalogo:
v WebSphere Portal Versione 6.0
– Versione Struts Portlet Framework: SPF 6.0
– Rilascio Struts: Struts 1.1
v WebSphere Portal Versione 5.1.x
– Versione Struts Portlet Framework: SPF 5.1.x
v WebSphere Portal Versione 5.0.x
– Versione Struts Portlet Framework: SPF 5.0.x
v Versione catalogo 5.1.0.1
– Versione Struts Portlet Framework: SPF 5.1.0.1
v Versione catalogo 5.0.3
– Versione Struts Portlet Framework: SPF 5.0.3
Per determinare se il portlet Struts deve essere migrato ad una versione più recente
di Struts Portlet Framework, è importante conoscere la versione corrente di Struts
Portlet Framework. Struts Portlet Framework include un file della versione che
consente di determinare la versione.
In WebSphere Portal Versione 6.0 e 5.1.x, gli esempi di Struts Portlet Framework si
trovano nella directory installableApps dell’installazione di WebSphere Portal. I
nomi delle applicazioni di Struts Portlet Framework iniziano con ’SPFLegacy’ e
’SPFStandard’. Le informazioni sulla versione si trovano all’interno dei file WAR.
Per individuare le informazioni sulla versione di un determinato file WAR di
un’applicazione Struts, esaminare il contenuto di PortalStruts.jar (contenitore
IBM Legacy) o wp.struts.standard.framework.jar (contenitore Standard) che si
trovano nella directory del WAR WEB-INF/lib. Il file JAR contiene un file
version.properties e/o un file version.txt. Se non è possibile trovare questi file,
il file manifest potrebbe contenere le informazioni necessarie.
Per le versioni di WebSphere Portal precedenti a 5.1, gli esempi e la
documentazione di Struts Portlet Framework si trovano nella directory dev/struts
dell’installazione WebSphere Portal. Il file version.txt nella directory dev/struts
fornisce la versione del Struts Portlet Framework e la versione di Apache Struts
integrata nel pacchetto. Ciascuno dei file WAR nella directory dev/struts contiene
anche il file della versione in PortalStruts.jar. Anche le applicazioni di esempio
contengono il file version.txt in PortalStruts.jar nella directory WEB-INF/lib di
ciascun WAR.
Se si utilizza Struts Portlet Framework dal catalogo delle soluzioni Workplace, il
file della versione potrebbe trovarsi nella directory base del file zip del catalogo ed
9
anche in PortalStruts.jar o wp.struts.standard.framework.jar, situati nella
directory WEB-INF/lib dei WAR di esempio.
Le applicazioni portlet Struts che utilizzano precedenti versioni di Struts Portlet
Framework possono essere migrate alla versione 6.0 del framework. La procedura
per migrare un’applicazione portlet include l’aggiornamento dei JAR, dei TLD e
del file org.apache.commons.logging.LogFactory di Struts Portlet Framework,
inoltre potrebbero essere necessarie alcune operazioni aggiuntive, in base alla
versione di Struts Portlet Framework utilizzata dall’applicazione.
Nell’installazione corrente, individuare SPFLegacyBlank.war e
SPFStandardBlank.war nella directory installableApps. Queste applicazioni
contengono i file che sono richiesti per migrare un portlet Struts alla versione 6.0 e
che possono essere utilizzati come modelli. SPFLegacyBlank.war contiene i file
necessari per migrare un portlet Struts di un contenitore IBM legacy.
SPFStandardBlank.war viene utilizzato nella migrazione di un portlet Struts in un
contenitore Standard della versione corrente. I portlet Struts del contenitore
Standard possono essere distribuiti in WebSphere Portal a partire dalla versione
5.1.x. I portlet scritti per il contenitore legacy possono essere migrati per utilizzare
Struts Portlet Framework per il contenitore Standard.
Per migrare i portlet, attenersi alla seguente procedura:
1. Utilizzare la seguente procedura per migrare i portlet da versioni precedenti
di Struts Portlet Framework in SPF 6.0:
a. Copiare il file META-INF/services/org.apache.commons.logging.LogFactory
dall’applicazione modello e aggiungerlo alla propria applicazione Struts.
Nota: sovrascrivere il file se è già esistente.
b. Copiare i seguenti file JAR dall’applicazione modello alla directory
WEB-INF/lib dell’applicazione Struts da migrare:
v commons-beanutils.jar
v commons-collections.jar
v commons-digester.jar
v commons-fileupload.jar
v commons-lang.jar
v commons-validator.jar
v jakarta-oro.jar
v PortalStruts.jar (contenitore IBM legacy) o
wp.struts.standard.framework.jar (contenitore Standard)
v PortalStrutsCommon.jar
v PortalStrutsTags.jar
v struts.jar
v struts-legacy.jar
v StrutsUpdateForPortal.jar
v wp.struts-commons-logging.jar
v wp.struts.tlds.common.jar
c. Rimuovere i seguenti file dalla directory WEB-INF/lib, se esistenti:
10
Migrazione
Nota: questi file non fanno più parte del pacchetto Struts.
v commons-dpcp.jar
v commons-logging.jar
v commons-pool.jar
v commons-resources.jar
v commons-services.jar
v jdbc2_0-stdext.jar
d. Rimuovere i seguenti file TLD Struts. Controllare l’ubicazione della tag nel
descrittore di distribuzione Web per verificare il percorso dei file TLD.
Nota: Non rimuovere il file app.tld.
v struts-bean.tld
v struts-chtml.tld
v struts-html.tld
v struts-logic.tld
v struts-nested.tld
v struts-portal-html.tld
v struts-portal-wml.tld
v struts-template.tld
v struts-tiles.tld
v struts-wml.tld
e. Modificare i file JSP dell’applicazione per utilizzare la seguente convenzione
URI della libreria tag:
Nota: non modificare <%@ taglib uri="/WEB-INF/app.tld" prefix="app" >
v http://struts.apache.org/tags-bean
v http://struts.apache.org/tags-chtml
v http://struts.apache.org/tags-html
v http://struts.apache.org/tags-logic
v http://struts.apache.org/tags-nested
v http://portal/struts/tags-html-1.0
v http://portal/struts/tags-wml-1.0
v http://struts.apache.org/tags-template
v http://struts.apache.org/tags-tiles
v http://struts.apache.org/tags-wml-1.0
Ad esempio, l’origine JSP originaria:
<%@ taglib uri="/WEB-INF/tld/struts-logic.tld" prefix="logic" %>
<logic:forward name="welcome"/>
Deve essere convertita in:
<%@ taglib uri="http://struts.apache.org/tags-logic" prefix="logic" %>
<logic:forward name="welcome"/>
f. Rimuovere i descrittori della libreria tag Struts dal descrittore di
distribuzione Web.
Nota: non rimuovere la seguente libreria di tag:
<taglib>
<taglib-uri>/WEB-INF/app.tld</taglib-uri>
<taglib-location>/WEB-INF/app.tld</taglib-location>
</taglib>
11
g. Rimuovere le seguenti righe dal file portlet.xml:
Nota: nel portlet Struts esistente, controllare il descrittore di distribuzione
portlet per verificare se è stata specificata la catena di filtro Struts. In
generale, la catena di filtro Struts non è richiesta a meno che
l’applicazione non utilizzi IViewCommand statici o XML oppure la
funzione di riscrittura URL del contenuto statico. I rilasci di Struts
Portlet Framework precedenti a 5.1 utilizzavano la conversione di
codifica per applicare fogli di stile ai documenti XML, i rilasci 5.1.x e
6.0 offrono un’alternativa che non richiede la conversione di codifica
(per maggiori dettagli, consultare gli esempi
SPFLegacyTransformation e SPFStandardTransformation).
<config-param>
<param-name>FilterChain</param-name>
<param-value>StrutsTranscoding</param-value>
</config-param>
h. Rimuovere la classe ForwardAction, situata nella directory
WEB-INF/classes/org/apache/struts/actions, se esistente.
Nota: Struts 1.1 ha modificato il nome di SubApplications in Modules dopo
il rilascio Beta 2. Questa modifica ha portato a ridenominare la classe
ApplicationConfig in ModuleConfig. Alcune tag e azioni possono
utilizzare ModuleConfig per determinare il prefisso del modulo
corrente. Si dovrebbe controllare il codice delle applicazioni Struts per
verificare se è stato utilizzato l’oggetto ApplicationConfig ed
eventualmente migrare il codice per utilizzare invece l’oggetto
ModuleConfig. Inoltre, il metodo di ottenimento dell’oggetto
ModuleConfig da parte dell’oggetto della richiesta è stato modificato.
Questo è un esempio della nuova implementazione: ModuleConfig
config = (ModuleConfig) pageContext.getRequest().getAttribute
(org.apache.struts.Globals.MODULE_KEY);
Nota: il parametro di configurazione SubApplicationSearchPath e stato
rinominato in ModuleSearchPath. Per mantenere Struts Portlet
Framework congruente con Struts 1.1, è stato aggiunto un nuovo
parametro di inizializzazione, ModuleSearchPath. Questo parametro
consente la personalizzazione in base alla quale gli attributi client
sono utilizzati per determinare un modulo. Un esempio tipico è
ModuleSearchPath di ″mode″, che utilizzerebbe la modalità del portlet
per determinare il modulo. Il parametro di inizializzazione
SubApplicationSearchPath continuerà ad essere supportato, ma
diventerà obsoleto. Se entrambi i parametri,
SubApplicationSearchPath e ModuleSearchPath, sono specificati come
parametri di inizializzazione, verrà utilizzato il valore di
ModuleSearchPath.
Nota: SubApplicationContext è stato rinominato in ModuleContext. Struts
Portlet Framework renderà obsoleta la classe SubApplicationContext
ed introdurrà la classe ModuleContext per essere congruente con
Struts 1.1 per la modifica del nome di SubApplication in Module.
L’oggetto ModuleContext ottenuto dall’oggetto ExecutionContext che
viene passato alle classi che implementano l’interfaccia IViewCommand.
ModuleContext viene utilizzato per memorizzare
ViewCommandsFactories. Questa classe viene implementata per
modulo.
12
Migrazione
2. Utilizzare la procedura di seguito riportata per migrare i portlet Struts del
contenitore IBM legacy nel contenitore Standard:
Nota: se il portlet da migrare non è basato su SPF 6.0, migrarlo a questo livello
prima di migrarlo nel contenitore Standard. La migrazione dalla versione
legacy di Struts Portlet Framework al contenitore Standard inizia con
l’aggiornamento dei file forniti con il file SPFStandardBlank.war.
a. Copiare il file META-INF/services/org.apache.commons.logging.LogFactory
dall’applicazione modello e aggiornare il file all’interno dell’applicazione.
b. Copiare i seguenti file JAR dall’applicazione modello alla directory
WEB-INF/lib dell’applicazione Struts in fase di migrazione:
v commons-beanutils.jar
v commons-collections.jar
v commons-digester.jar
v commons-fileupload.jar
v
v
v
v
v
v
v
commons-lang.jar
commons-validator.jar
jakarta-oro.jar
PortalStrutsCommon.jar
PortalStrutsTags.jar
struts.jar
struts-legacy.jar
v StrutsUpdateForPortal.jar
v wp.struts-commons-logging.jar
v wp.struts.standard.framework.jar
v wp.struts.tlds.common.jar
c. Eliminare il file PortalStruts.jar. Questo è richiesto solo per il contenitore
IBM legacy.
d. Utilizzare la seguente procedura per modificare il descrittore di
distribuzione Web:
Nota: il contenitore Standard richiede un descrittore di distribuzione Web
perché l’applicazione è creata come file WAR. Tuttavia, la maggior
parte dei parametri di inizializzazione sono ora configurati tramite il
descrittore di distribuzione portlet.
1) Rimuovere la classe servlet dal descrittore di distribuzione Web. La
classe servlet non è più il modo per specificare la classe portlet per
l’applicazione nel contenitore standard. Adesso il portlet è specificato
come classe portlet nel descrittore di distribuzione portlet.
2) Spostare i parametri di inizializzazione dal descrittore di distribuzione
Web al descrittore di distribuzione portlet. Poiché la classe portlet
adesso è definita nel descrittore di distribuzione portlet, i parametri di
inizializzazione vengono anch’essi specificati in tale descrittore. Tenere
presente che i parametri di inizializzazione sono specificati come nome e
valore nel descrittore di distribuzione portlet, non come nome parametro
e valore parametro, perché sono denominati nel descrittore di
distribuzione Web.
13
3) Gli elementi di taglib rimangono ancora nel descrittore di distribuzione
Web, non è richiesta alcuna modifica.
4) Gli elementi del file di benvenuto rimangono ancora nel descrittore di
distribuzione Web, non è richiesta alcuna modifica.
e. Utilizzare la seguente procedura per modificare il descrittore di
distribuzione portlet:
Nota: la definizione del descrittore di distribuzione portlet per il contenitore
Standard è diversa da quella per il contenitore legacy. Sono richieste
alcune modifiche all’esempio migrato da distribuire nel contenitore
Standard.
1) Il contenitore Standard introduce l’elemento portlet-class per la specifica
della classe del portlet. La classe portlet per Struts Portlet Framework è
com.ibm.portal.struts.portlet.StrutsPortlet.
2) I parametri di inizializzazione per il portlet sono definiti nel descrittore
di distribuzione portlet. I parametri di inizializzazione devono essere
migrati dal descrittore di distribuzione Web.
3) Il contenitore Standard non ha la separazione tra astratto e concreto nel
descrittore di distribuzione portlet. L’elemento portlet definisce le
modalità supportate e le preferenze del portlet.
f. Modificare il file di configurazione Struts. Struts Portlet Framework definisce
il processore della richiesta che deve essere configurato nel file di
configurazione Struts. L’attributo del controller processClass deve essere
migrato al seguente valore per essere distribuito nel contenitore Standard:
<controller processorClass="com.ibm.portal.struts.portlet.WpRequestProcessor">
Se l’applicazione Struts utilizza il processore della richiesta Struts che
supporta Tiles, è necessario migrare anche il plug-in Struts:
<plug-in className="com.ibm.portal.struts.plugins.WpTilesPlugin">
g. Migrare le dipendenze nel contenitore del portale. L’applicazione deve
sostituire le interfacce org.apache.jetspeed con le equivalenti interfacce
javax.portlet.
h. Tuttavia, molte applicazioni utilizzano PortletApiUtils per ottenere la
richiesta e l’interfaccia del portlet direttamente con l’API portlet. Verificare
che l’oggetto PortletApiUtils sia stato ottenuto nel modo seguente:
com.ibm.portal.struts.common.PortletApiUtils portletUtils =
com.ibm.portal.struts.common.PortletApiUtils.getUtilsInstance();
i. Migrare le personalizzazioni dell’applicazione nel contenitore Standard.
v StrutsPortlet: la classe com.ibm.wps.portlets.struts.WpsStrutsPortlet per
il contenitore legacy ha esteso la classe PortletAdapter. L’applicazione
Struts che utilizza Struts Portlet Framework potrebbe essere stata
personalizzata estendendo la classe WpsStrutsPortlet. In questo caso, le
modifiche devono essere migrate per il contenitore Standard. La classe
com.ibm.portal.struts.portlet.StrutsPortlet per il contenitore
Standard estende GenericPortlet del contenitore Standard.
v RequestProcessor: la classe
com.ibm.wps.portlets.struts.WpsRequestProcessor per il contenitore
legacy potrebbe essere stata estesa per personalizzare l’elaborazione. La
classe del processore di richieste per il contenitore Standard è
com.ibm.portal.struts.portlet.WpRequestProcessor. Se sono state
utilizzate interfacce legacy per le personalizzazioni, tali modifiche devono
essere migrate alle interfacce Standard.
14
Migrazione
Migrazione di applicazioni per processi di business
Se si hanno delle applicazioni per processi di business sviluppate per WebSphere
Portal Versione 5.1, occorre apportare delle modifiche al processo di business ed ai
portlet.
Nota: Questa sezione non è valida per iSeries.
Migrazione di processi di business
Le modifiche che occorre apportare ai processi di business per eseguirne la
migrazione a WebSphere Portal Versione 6.0 sono descritte in WebSphere Business
Process Management information center. Leggere in particolare le seguenti sezioni
per la migrazione di processi di business:
v Panoramica della migrazione: http://publib.boulder.ibm.com/infocenter/
dmndhelp/v6rxmx/index.jsp?topic=/com.ibm.wsps.mig.doc/doc/
cmig_toplevel.html
v Migrating source artifacts to WebSphere Integration Developer from WebSphere Studio
Application Developer Integration Editionhttp://publib.boulder.ibm.com/
infocenter/dmndhelp/v6rxmx/index.jsp?topic=/
com.ibm.wbit.help.migration.ui.doc/topics/tsrcartifacts.html
Migrazione di pagine personalizzate
Se non si intende utilizzare le pagine predefinite per contenere le pagine di
definizione di attività e di elenco delle attività, spostare tutte le pagine secondarie
alle nuove controparti ed eliminare i contenitori predefiniti prima di eseguire la
migrazione di WebSphere Portal. I contenitori predefiniti sono creati utilizzando
l’attività action-setup-process-integration, descritta in Configurare le pagine ed i
portlet per l’integrazione del processo.
I portlet attività ed i portlet dei processi business che utilizzano le API client
generiche fornite da WebSphere Business Integration Server Foundation Version
devono essere cambiati. E’ disponibile una nuova versione delle API Generic EJB
che utilizza DataObjects come formato messaggio. Tutto ciò viene descritto nel
dettaglio nel Centro informazioni di WebSphere Integration Developer alla pagina
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/index.jsp?topic=/
com.ibm.wbit.help.migration.ui.doc/topics/tmigclientbpcejb.html.
I nomi JNDI dei Generic EJB precedenti che ricevono oggetti WSIFMessage sono:
GenericProcessChoreographerEJB
Nome JNDI: com/ibm/bpe/api/BusinessProcessHome
Interfaccia: com.ibm.bpe.api.BusinessProcess
TaskManagerEJB
Nome JNDI: com/ibm/task/api/TaskManagerHome
Interfaccia: com.ibm.task.api.TaskManager
I nomi JNDI Versione 6.0 JNDI di questi Generic EJB sono:
GenericBusinessFlowManagerEJB
Nome JNDI: com/ibm/bpe/api/BusinessFlowManagerHome
Interfaccia: com.ibm.bpe.api.BusinessFlowManager
HumanTaskManagerEJB
Nome JNDI: com/ibm/task/api/HumanTaskManagerHome
Interfaccia: com.ibm.task.api.HumanTaskManager
15
Dopo avere completato l’aggiornamento e la verifica dei portlet migrati, copiarli in
un’ubicazione disponibile per le attività di migrazione.
Rendere disponibili le applicazioni portlet alle attività di migrazione per la
distribuzione
Preparazione all’esecuzione delle attività di migrazione
Questa sezione descrive la procedura manuale da eseguire prima di migrare IBM
WebSphere Portal.
La seguente procedura è richiesta per poter eseguire le attività di migrazione:
1. Confermare la corretta installazione di WebSphere Portal
2. Aggiornare i ruoli di utente anonimo
Accedere a WebSphere Portal per eseguire la migrazione
Modificare il timeout del server HTTP
Eseguire l’attività di raccolta proprietà della migrazione
Rendere disponibili le applicazioni portlet alle attività di migrazione per la
distribuzione.
7. Creare il portale virtuale della versione precedente nella versione corrente
8. Ottimizzazione delle prestazioni richiesta per l’esportazione di gruppi e risorse
di notevoli dimensioni
3.
4.
5.
6.
Prime di eseguire le attività di migrazione, eseguire la procedura riportata di
seguito:
1. Confermare la corretta installazione della versione corrente di WebSphere
Portal
Assicurarsi che la versione corrente di WebSphere Portal sia installata e
configurata correttamente. Per istruzioni complete, consultare Installazione e
configurazione e Installazione di prodotti WebSphere Portal coesistenti sulla
stessa macchina.
2. Aggiornare i ruoli di utente anonimo
Verificare nell’ambiente precedente la presenza di eventuali utenti anonimi con
i seguenti ruoli:
v Utente privilegiato
v Editor
v Responsabile
v Delegante
v Amministratore della sicurezza
v Amministratore
Cambiare tutti questi ruoli in Utente.
3. Accedere a WebSphere Portal per eseguire la migrazione
Per eseguire la migrazione è necessario fornire l’ID utente e la password di un
utente che disponga di autorità di gestione per WebSphere Portal:
v Per l’attività di esportazione, immettere un ID utente di gestione per la
versione precedente
v Per l’attività di importazione, immettere un ID utente di gestione per la
versione corrente
4. Modificare il timeout del server HTTP
16
Migrazione
Poiché la migrazione può essere un processo lungo, si consiglia di modificare la
lunghezza del timeout sul server HTTP impostandola su un timeout illimitato,
quando si esegue l’attività di migrazione. Fare riferimento alla documentazione
relativa al server HTTP per i dettagli su come modificare il timeout.
5. Eseguire l’attività di raccolta proprietà della migrazione per raccogliere i file
richiesti dalla versione precedente, affinché gli script di migrazione possano
accedere alla versione precedente:
a. Copiare i file propcollector.xml e propcollector.jar dalla directory
root_server_portale/migration della versione corrente alla directory
wp_old_root/config/includes della versione precedente ed eseguire il
seguente comando dalla directory wp_old_root/config della directory
precedente:
Nota: se si utilizza i5/OS, il percorso di directory è root_server_portale
per la versione corrente di WebSphere Portal e wp_user_old_root per
la versione precedente di WebSphere Portal.
v Windows e UNIX: WPSconfig.{sh|bat} prop-collector
-DDbPassword=wpsdb_password
v i5/OS Dalla directory UserData: WPSconfig.sh -instance nome_istanza
prop-collector -DDbPassword=wpsdb_password
dove nome_istanza è il nome del profilo WebSphere Application Server in
cui è installato WebSphere Portal.
Importante: Le seguenti informazioni sono relative all’esecuzione del
comando precedente:
– -DDbPassword=wpsdb_password non è richiesto se il valore
è già definito nel file wpconfig.properties.
– Accertarsi che i valori di DbUrl, DbName e DbServer siano
definiti nel file wpconfig.properties.
b. Copiare il file wp_old_root/config/includes/propcollectorOutput.zip della
versione precedente nella directory root_server_portale/migration della
versione corrente.
c. Eseguire il seguente comando dalla directory root_server_portale/
migration della versione corrente per estrarre il file
propcollectorOutput.zip:
WPmigrate.{sh|bat} collector-extract
6. Rendere disponibili le applicazioni portlet alle attività di migrazione per la
distribuzione
La directory root_server_portale/installedApps contiene un elenco di tutte le
applicazioni portlet distribuite sul sistema WebSphere Portal precedente. In
base alle funzioni utilizzate da questi portlet, potrebbe essere necessario prima
eseguirne l’aggiornamento per un corretto funzionamento con la versione
corrente di WebSphere Portal. Fare riferimento alle istruzioni fornite nella
sezione “Migrazione delle risorse personalizzate” a pagina 7 per determinare se
è richiesto l’aggiornamento dei portlet.
Alcuni dei file WAR presenti nella directory root_server_portale/
installedApps potrebbero essere stati forniti con la versione corrente di
WebSphere Portal. In questo caso, non è richiesto l’aggiornamento manuale dei
corrispondenti portlet. È possibile utilizzare senza problemi il file WAR
corrispondente dalla directory root_server_portale/installableApps come
versione aggiornata del portlet.
Prima di eseguire le attività di migrazione, tutti i portlet aggiornati devono
essere resi disponibili nella directory root_server_portale/installableApps del
17
sistema WebSphere Portal corrente. Questa directory contiene i portlet di
esempio forniti con la versione corrente di WebSphere Portal; non sovrascriverli
con le versioni di esempio fornite con le precedenti versioni di WebSphere
Portal.
7. Creare il portale virtuale della versione precedente nella versione corrente
Per poter migrare i dati dal precedente portale virtuale alla versione corrente, è
necessario creare di nuovo il portale virtuale nella versione corrente. Utilizzare
Virtual Portal Manager per creare il portale virtuale nella versione corrente.
8. Ottimizzazione delle prestazioni richiesta per l’esportazione e l’importazione
di gruppi e risorse di notevoli dimensioni
a. Controllare il server LDAP per determinare il numero di gruppi ed eseguire
i passi appropriati se il numero è maggiore di 200:
v Eseguire le seguenti operazioni sulla versione precedente di WebSphere
Portal se si sta eseguendo la migrazione dalla versione 5.0.2.x:
1) Passare alla directory wp_old_root/shared/app/wmm del sistema 5.0.2.x.
2) Aprire il file wmm.xml e modificare il valore numerico in
maximumSearchResults in ″$GROUPS″ dove ″$GROUPS″ è un numero
superiore al numero effettivo di gruppi sul server LDAP; ad esempio,
se il server LDAP ha 300 gruppi, immettere 301.
3) Salvare le modifiche.
v Eseguire le seguenti operazioni sulla versione precedente di WebSphere
Portal se si sta eseguendo la migrazione dalla versione 5.1.x:
1) Passare alla directory wp_old_root/wmm del sistema 5.1.x.
Nota: Se si sta utilizzando i5/OS, la directory è wp_user_old_root;
per la versione 5.1.x, fare riferimento a Struttura delle directory.
4) Se si tratta di un ambiente di cluster, passare alla directory
was_old_root/config/wmm del sistema 5.1.x.
5)
6)
7)
8)
9)
18
Migrazione
Nota: Se si sta utilizzando i5/OS, la directory è was_user_old_root;
per la versione 5.1.x, fare riferimento a Struttura delle directory.
Aprire il file wmm.xml e modificare il valore numerico in
Salvare le modifiche.
Se si tratta di un ambiente di cluster, passare alla directory
dmgr_old_root/config/wmm sulla macchina del gestore di distribuzione
del sistema 5.1.x.
Aprire il file wmm.xml e modificare il valore numerico in
Salvare le modifiche.
v Eseguire le seguenti operazioni sulla versione corrente di WebSphere
Portal dopo avere completato le attività correlate alla sicurezza, come ad
esempio (ma non solo) l’esecuzione dell’attività enable-security-ldap:
1) Passare alla directory root_server_portale/wmm della versione
corrente.
Nota: Se si sta utilizzando i5/OS, il percorso di directory è
root_server_portale.
b. Modificare i seguenti parametri del server LDAP in ″unlimited″:
v Size limit
v Look-through limit
v Time limit
v Idle timeout
c. Attenersi alla seguente procedura per arrestare e riavviare i server:
1) Aprire un prompt dei comandi e passare alla seguente directory:
v UNIX: root_profilo_was/bin
v Windows: root_profilo_was\bin
v i5/OS: root_server_app/bin
2) Immettere il seguente comando:
v UNIX: ./stopServer.sh server1 -user idutente_ammin -password
password_ammin
v Windows: stopServer.bat server1 -user idutente_ammin -password
password_ammin
v i5/OS: stopServer -profileName root_profilo -user idutente_ammin
-password password_ammin
dove root_profilo è il nome del profilo WebSphere Application Server
in cui è installato WebSphere Portal; ad esempio, wp_profile.
dove server1 è il nome del server di gestione di WebSphere Application
Server e root_profilo è il nome assegnato al profilo di WebSphere
Application Server in uso.
v UNIX: ./stopServer.sh WebSphere_Portal -user idutente_ammin
v Windows: stopServer.bat WebSphere_Portal -user idutente_ammin
v i5/OS: stopServer WebSphere_Portal -profileName root_profilo
-user idutente_ammin -password password_ammin
v UNIX: ./startServer.sh server1
v Windows: startServer.bat server1
v i5/OS: startServer -profileName root_profilo
19
dove server1 è il nome del server di gestione di WebSphere Application
Server.
v UNIX:./startServer.sh WebSphere_Portal
v Windows: startServer.bat WebSphere_Portal
v i5/OS: startServer WebSphere_Portal -profileName root_profilo
9. Opzionale: Impostare la proprietà Computer Associates eTrust SiteMinder
per assicurare una corretta migrazione
Se si sta utilizzando eTrust SiteMinder per eseguire l’autorizzazione, verificare
che la proprietà personalizzata SiteMinderLoginModule sia definita perché può
essere influenzata qualsiasi esecuzione dell’interfaccia di configurazione XML.
Fare riferimento al passo SiteMinderLoginModule in Configurazione di eTrust
SiteMinder per eseguire l’autorizzazione per WebSphere Portal
Passi successivi
il seguente argomento:
v “Migrazione delle configurazioni di WebSphere Portal”
v Preparazione del sistema operativo
Migrazione delle configurazioni di WebSphere Portal
Quando si migrano le configurazioni di WebSphere Portal è possibile scegliere tra
due opzioni: eseguire le attività di migrazione da riga comandi o eseguire le
attività utilizzando la procedura guidata di migrazione.
Scegliere una delle seguenti opzioni di migrazione:
Nota: accertarsi di aver eseguito i passi di “Preparazione all’esecuzione delle
attività di migrazione” a pagina 16 prima di scegliere l’opzione di
migrazione.
v Attenersi alla procedura riportata nella sezione “Utilizzo di script per la riga
comandi” a pagina 21 per eseguire le attività di migrazione da riga comandi.
Nota: se è verificata una delle seguenti condizioni, scegliere l’opzione “Utilizzo
di script per la riga comandi” a pagina 21 per migrare le configurazioni di
WebSphere Portal:
– La versione precedente di WebSphere Portal è in esecuzione su una
macchina diversa rispetto alla versione corrente
– L’ambiente non dispone di una interfaccia grafica
v Attenersi alla procedura riportata nella sezione “Utilizzo della procedura guidata
di migrazione” a pagina 24 per eseguire automaticamente le attività di
esportazione e importazione.
20
Migrazione
Utilizzo di script per la riga comandi
Questa sezione descrive gli script da riga comandi utilizzati per eseguire la
migrazione di WebSphere Portal.
Utilizzo di script per la riga comandi
Il pacchetto di migrazione di WebSphere Portal fornisce il seguente file script da
utilizzare per richiamare le attività di migrazione:
v Windows: WPmigrate.bat
v UNIX: ./WPmigrate.sh
v i5/OS: WPmigrate.sh
È possibile eseguire lo script dalla directory root_server_portale/migration dove
root_server_portale è la directory in cui è installata la versione corrente di
WebSphere Portal.
Se si utilizza i5/OS, è possibile eseguire lo script dalla directory
root_server_portale/migration, dove root_server_portale è la directory in cui è
installata la versione corrente di WebSphere Portal.
La sintassi per il richiamo di una attività di migrazione è la seguente:
v Windows: WPmigrate.bat nome_attività -Dproprietà=valore
v UNIX: ./WPmigrate.sh nome_attività -Dproprietà=valore
v i5/OS: WPmigrate.sh nome_attività -Dproprietà=valore
dove:
v nome_attività indica l’attività di migrazione da eseguire
v proprietà indica una specifica proprietà utilizzata dall’attività
v valore indica il valore di una specifica proprietà utilizzata dall’attività
Esportazione di contenuto da WebSphere Portal
L’attività export-portal-content esporta il contenuto di WebSphere Portal da una
versione precedente.
Importante: Prima di eseguire l’attività export-portal-content, eseguire i seguenti
passi:
1. Arrestare il server WebSphere Portal corrente.
2. Avviare il server per la versione precedente di WebSphere Portal
ed accertarsi che sia accessibile sulla rete.
v Windows: WPmigrate.bat export-portal-content
-DPrevPortalAdminId=portaladminid -DPrevPortalAdminPwd=password
v UNIX: ./WPmigrate.sh export-portal-content
v i5/OS: WPmigrate.sh export-portal-content
-DPrevPortalAdminId=idAmministratorePortale -DPrevPortalAdminPwd=password
dove:
v PrevPortalAdminId indica un idAmministratorePortale della versione precedente di
WebSphere Portal
21
v PrevPortalAdminPwd indica la password per idAmministratorePortale
Esportazione di contenuto dal portale virtuale
L’attività export-portal-content esporta il contenuto di WebSphere Portal da una
Importante: Prima di eseguire l’attività export-portal-content, eseguire i seguenti
passi:
1. Arrestare il server WebSphere Portal corrente.
2. Assicurarsi che il server per la versione precedente di WebSphere
Portal sia in esecuzione ed accessibile sulla rete.
v Windows: WPmigrate.bat export-portal-content
-DVirtualPortal=contesto URL
v UNIX: ./WPmigrate.sh export-portal-content
v i5/OS: WPmigrate.sh export-portal-content
dove:
v PrevPortalAdminId indica un idAmministratorePortale della versione precedente di
WebSphere Portal
v PrevPortalAdminPwd indica la password per idAmministratorePortale
v contesto URL è l’estensione del contesto dell’URL del portale virtuale; consultare
la riga di descrizione del contesto URL nel portlet Virtual Portal Manager
Importazione di contenuto in WebSphere Portal
L’attività import-portal-content importa il contenuto della versione precedente di
WebSphere Portal nella versione corrente di WebSphere Portal.
Importante: Prima di eseguire l’attività import-portal-content, eseguire i seguenti
passi:
1. Arrestare il server WebSphere Portal precedente.
2. Avviare il server per la versione corrente di WebSphere Portal ed
accertarsi che sia accessibile sulla rete.
3. Specificare WasUserid e WasPassword nel file wpconfig.properties;
consultare Riferimento alle proprietà di configurazione per
ulteriori informazioni sulla modifica del file delle proprietà.
v Windows: WPmigrate.bat import-portal-content
-DPortalAdminId=portaladminid -DPortalAdminPwd=password
v UNIX: ./WPmigrate.sh import-portal-content -DPortalAdminId=portaladminid
-DPortalAdminPwd=password
v i5/OS: WPmigrate.sh import-portal-content
-DPortalAdminId=idAmministratorePortale -DPortalAdminPwd=password
22
Migrazione
dove:
v PortalAdminId indica un idAmministratorePortale della versione corrente di
WebSphere Portal
v PortalAdminPwd indica la password per idAmministratorePortale
Nota: Se si esegue l’attività import-portal-content più volte, occorre eseguire
“Riavvio dei server” a pagina 24 prima di eseguire nuovamente l’attività.
Importazione di contenuto dal portale virtuale
L’attività import-portal-content importa il contenuto della versione precedente di
WebSphere Portal nella versione corrente di WebSphere Portal.
Importante: Prima di eseguire l’attività import-portal-content, eseguire i seguenti
passi:
1. Arrestare il server WebSphere Portal precedente.
2. Assicurarsi che il server per la versione corrente di WebSphere
Portal sia in esecuzione ed accessibile sulla rete.
Suggerimento: Prima di importare ogni portale virtuale, eseguire il backup del
database.
v Windows: WPmigrate.bat import-portal-content
-DPortalAdminId=portaladminid -DPortalAdminPwd=password
v UNIX: ./WPmigrate.sh import-portal-content -DPortalAdminId=portaladminid
-DPortalAdminPwd=password -DVirtualPortal=contesto URL
v i5/OS: WPmigrate.sh import-portal-content -DPortalAdminId=portaladminid
-DPortalAdminPwd=password -DVirtualPortal=contesto URL
dove:
v PortalAdminId indica un idAmministratorePortale della versione corrente di
WebSphere Portal
v PortalAdminPwd indica la password per idAmministratorePortale
v contesto URL è l’estensione del contesto dell’URL del portale virtuale; consultare
la riga di descrizione del contesto URL nel portlet Virtual Portal Manager
Nota: Se si esegue l’attività import-portal-content più volte, occorre eseguire
“Riavvio dei server” a pagina 24 prima di eseguire nuovamente l’attività.
Facoltativo: migrazione del portlet FileServer
Se si è clonato il portlet FileServer nelle versioni precedenti e si sono forniti i file
HTML nella directory wp_old_root/installedApps/FileServer.war/
FileServerPortlet/html, occorre copiare questi file sulla directory
root_server_portale/installedApps/FileServer.war/FileServerPortlet/html,
dopo avere eseguito l’attività di importazione e prima del riavvio del server, per
rendere i file accessibili nella versione corrente.
Nota: Per i5/OS, le directory sono wp_user_old_root e root_server_portale,
rispettivamente.
23
Riavvio dei server
Dopo aver completato l’attività import-portal-content riavviare il seguente server
solo sulla versione corrente:
1. Aprire un prompt dei comandi e passare alla seguente directory:
2. Immettere il seguente comando:
v UNIX: ./stopServer.sh WebSphere_Portal -user idutente_ammin -password
password_ammin
v i5/OS: stopServer WebSphere_Portal -profileName root_profilo -user
idutente_ammin -password password_ammin
dove root_profilo è il nome del profilo WebSphere Application Server in cui è
installato WebSphere Portal; ad esempio, wp_profile.
3. Immettere il seguente comando:
dove root_profilo è il nome del profilo WebSphere Application Server in cui è
installato WebSphere Portal; ad esempio, wp_profile.
Passi successivi
uno dei seguenti argomenti:
v “Migrazione di componenti aggiuntivi” a pagina 36
v “Migrazione della configurazione del controllo accessi restante” a pagina 28
v “Verifica delle attività di migrazione” a pagina 67
v Risoluzione dei problemi di migrazione
v Avvio e arresto di WebSphere Application Server e WebSphere Portal
Utilizzo della procedura guidata di migrazione
La migrazione guidata è uno strumento facile da usare, dopo l’installazione, che
consente l’esecuzione automatica della migrazione, anziché utilizzare uno script di
riga comandi. Le attività che è possibile eseguire includono l’esportazione e
l’importazione di dati. Questo argomento fornisce informazioni che sarebbe
opportuno consultare prima di avviare questa procedura guidata, informazioni
sulle modalità di utilizzo della procedura guidata e consigli sull’utilizzo.
Informazioni necessarie
È possibile utilizzare la procedura guidata di migrazione per effettuare le seguenti
attività:
v Esportazione del contenuto del WebSphere Portal: esporta le informazioni dalla
versione precedente di IBM WebSphere Portal
24
Migrazione
v Importazione del contenuto del WebSphere Portal: importa le informazioni
dalla versione precedente di WebSphere Portal alla versione corrente
Se non si utilizza la procedura guidata di migrazione, è necessario eseguire la
migrazione immettendo le attività di configurazione da riga comandi. Per
informazioni sull’esecuzione delle attività di migrazione da riga comandi,
consultare la sezione “Utilizzo di script per la riga comandi” a pagina 21.
Prima di iniziare
Le seguenti istruzioni forniscono informazioni sull’avvio della procedura guidata
di migrazione e dettagli dei valori necessari per completare la migrazione:
Prima di avviare la procedura guidata di migrazione:
v Assicurarsi che la versione corrente di WebSphere Portal sia installata e
configurata in modo da corrispondere alla versione precedente di WebSphere
Portal.
v Verificare di aver completato le attività di “Preparazione dell’ambiente
precedente per la migrazione” a pagina 4
v Verificare di aver completato le attività di “Migrazione delle risorse
personalizzate” a pagina 7
v Verificare di aver completato “Preparazione all’esecuzione delle attività di
migrazione” a pagina 16
Avvio della procedura guidata per i server basati su Windows e
UNIX
Per avviare la procedura guidata di migrazione, è necessario immettere il comando
migrationwizard appropriato su una riga comandi. Il percorso e la sintassi del
comando dello script è:
v UNIX: root_server_portale/migration/migrationwizard.sh
v Windows: root_server_portale\migration\migrationwizard.bat
Nota: è possibile avviare il programma in modalità console per eseguire la
migrazione senza la GUI (Graphical User Interface). Per eseguire la
procedura guidata in modalità console, immettere -console dopo il
comando.
Avvio della procedura guidata per i5/OS
Per avviare la procedura guidata di migrazione, è necessario immettere il comando
migrationwizard.sh su una riga comandi. Il percorso e la sintassi del comando
dello script è: root_server_portale/migration/migrationwizard.sh.
Note:
v Il comando migrationwizard.sh per i5/OS viene eseguito solo in modalità
console e l’utilizzo dell’opzione -console è sconsigliato.
v È possibile eseguire la procedura guidata di migrazione dalla workstation
Windows abilitando una condivisione di rete sul proprio sistema i5/OS.
Per ulteriori informazioni su tale argomento, consultare Introduzione
all’IFS (Integrated File System). Immettere il seguente comando per la
connessione alla directory condivisa:
net use z: \\iSeries_system_name.domain\share1 /u:user password
25
Dopo essersi connessi alla directory condivisa dalla propria workstation
Windows, andare in root_server_portale\migration ed immettere:
migrationwizard400.bat
Nel suddetto esempio, share1 specifica la directory WebSphere Portal
root_server_portale.
Consigli sull’utilizzo
v La procedura guidata di migrazione contiene i pannelli della guida con
informazioni specifiche per l’attività e l’operazione in corso.
v Se si seleziona il pulsante ? è possibile che venga visualizzato un messaggio
registrato nella riga comandi, che indica l’avvenuta creazione di una funzione
Javax. Questo è un messaggio a solo scopo informativo e può essere ignorato.
v Se l’esecuzione avviene in un ambiente Solaris e si fa clic sul pulsante Sfoglia, è
possibile che venga visualizzato il messaggio registrato nella riga comandi, che
indica che il sistema non ha trovato un contesto di immissione. Questo è un
messaggio a solo scopo informativo e può essere ignorato.
Passi successivi
Esportazione del contenuto di WebSphere Portal
Selezionare l’opzione Esporta WebSphere Portal Contenuto dalla procedura
guidata di migrazione per esportare i dati dalla versione precedente di IBM
WebSphere Portal.
Leggere “Utilizzo della procedura guidata di migrazione” a pagina 24 prima di
eseguire l’attività di esportazione di contenuto WebSphere Portal ed avviare la
migrazione guidata.
Utilizzare la procedura di seguito riportata per esportare i dati dalla versione
precedente di WebSphere Portal:
1. Arrestare il server per la versione corrente di WebSphere Portal.
2. Verificare che il server della versione precedente di WebSphere Portal sia in
esecuzione.
3. Selezionare il pulsante di scelta Esporta contenuto WebSphere Portal sul
pannello di scelta dell’attività di migrazione.
4. Fare clic sul pulsante Avanti.
5. Immettere il percorso della directory della versione precedente di WebSphere
Portal nel campo Directory oppure fare clic sul pulsante Sfoglia per cercarlo.
Nota: La procedura guidata raccoglie ed analizza i dati della versione
precedente di WebSphere Portal.
7. Immettere un ID utente di gestione WebSphere Portal della versione
precedente di WebSphere Portal nel campo ID utente.
8. Immettere la password per l’ID utente di gestione nel campo Password.
Nota: se vengono immessi l’ID utente e la password errati, viene visualizzato
il messaggio di errore ″L’ID utente di gestione di WebSphere Portal e la
password specificati non sono validi.″
26
Migrazione
9. Fare clic sul pulsante Avanti per visualizzare il pannello Anteprima
esportazione contenuto.
10. Fare clic sul pulsante Avanti per eseguire l’attività export-portal-content. Viene
visualizzato il pannello di avanzamento dell’attività.
Una volta completata l’attività export-portal-content, fare clic sul pulsante Avanti
per andare al pannello di selezione Importa contenuto WebSphere Portal.
Passo successivo
v “Importazione di contenuto WebSphere Portal”
Importazione di contenuto WebSphere Portal
Selezionare l’opzione Importa contenuto WebSphere Portal dalla migrazione
guidata per importare i dati della versione precedente di IBM WebSphere Portal
nella versione corrente di WebSphere Portal.
Eseguire l’attività “Esportazione del contenuto di WebSphere Portal” a pagina 26
prima di eseguire questa attività.
Utilizzare la procedura di seguito riportata per importare i dati dalla versione
precedente di WebSphere Portal alla versione corrente:
1. Specificare WasUserid e WasPassword nel file wpconfig.properties; consultare
Riferimento alle proprietà di configurazione per ulteriori informazioni sulla
modifica del file delle proprietà.
2. Verificare che della versione precedente di WebSphere Portal sia stato
arrestato.
3. Verificare che il server della versione corrente di WebSphere Portal sia in
esecuzione.
4. Selezionare il pulsante di scelta Importa contenuto WebSphere Portal sul
pannello di scelta dell’attività di migrazione.
6. Directory corrente (vedere informazioni di esportazione)
8. Immettere un ID utente di gestione WebSphere Portal della versione corrente
di WebSphere Portal nel campo ID utente.
9. Immettere la password per l’ID utente di gestione nel campo Password.
10.
11.
12.
13.
Nota: se vengono immessi l’ID utente e la password errati, viene visualizzato
il messaggio di errore ″L’ID utente di gestione di WebSphere Portal e la
password specificati non sono validi.″
Fare clic sul pulsante Avanti per visualizzare il pannello Anteprima
importazione contenuto.
Fare clic sul pulsante Avanti per eseguire l’attività import-portal-content.
Viene visualizzato il pannello di avanzamento dell’attività.
Una volta completata l’attività import-portal-content, fare clic sul pulsante
Fine.
Facoltativo: se si è eseguita la clonazione del portlet FileServer nelle versioni
precedenti e si sono forniti i file HTML nella directory wp_old_root/
installedApps/FileServer.war/FileServerPortlet/html, occorre copiare
questi file nella directory root_server_portale/installedApps/
FileServer.war/FileServerPortlet/html per rendere questi file accessibili
nella versione corrente.
27
Nota: Per i5/OS, le directory sono wp_user_old_root e root_server_portale,
rispettivamente.
14. Utilizzare la seguente procedura per riavviare il server solo sulla versione
corrente:
a. Aprire un prompt dei comandi e passare alla seguente directory:
b. Immettere il seguente comando:
v UNIX: ./stopServer.sh WebSphere_Portal -user idutente_ammin
v i5/OS: stopServer WebSphere_Portal -profileName root_profilo -user
idutente_ammin -password password_ammin
dove root_profilo è il nome del profilo WebSphere Application Server in
cui è installato WebSphere Portal; ad esempio, wp_profile.
c. Immettere il seguente comando:
dove root_profilo è il nome del profilo WebSphere Application Server in
cui è installato WebSphere Portal; ad esempio, wp_profile.
Passo successivo:
v “Migrazione di componenti aggiuntivi” a pagina 36
v “Migrazione della configurazione del controllo accessi restante”
v “Verifica delle attività di migrazione” a pagina 67
Migrazione della configurazione del controllo accessi restante
Questa sezione illustra le procedure necessarie per migrare configurazioni di
controllo accessi specifiche non gestite automaticamente dal processo di
migrazione.
Migrare manualmente le seguenti configurazioni di controllo accessi:
1. Migrazione di autorizzazioni per il gruppo Tutti gli utenti autenticati del
portale e il gruppo Tutti i gruppi di utenti del portale
2. Migrazione di autorizzazioni per le risorse di gestione di WebSphere Portal
5.1.x
3. Migrazione del database di Member Manager utilizzando la riga comandi DB2
4. Migrazione di dati di protezione credenziali
5. Eliminazione di voci delle risorse WebSphere Portal precedenti da Tivoli Access
Manager
Una volta completata la procedura descritta nella sezione “Utilizzo di script per la
riga comandi” a pagina 21, attenersi alle seguenti istruzioni:
28
Migrazione
1. Migrazione di autorizzazioni per il gruppo Tutti gli utenti autenticati del
portale e il gruppo Tutti i gruppi di utenti del portale
Le autorizzazioni per i gruppi di utenti consentono ai principal di eseguire
queste attività:
v Modifica di informazioni sul gruppo
v Modifica dell’appartenenza al gruppo
v Modifica dei diritti di accesso dei membri del gruppo
Attenersi alla seguente procedura per migrare le autorizzazioni per i gruppi di
utenti:
a. Nel sistema WebSphere Portal corrente, utilizzare il portlet Autorizzazioni
utente e gruppo, il portlet Autorizzazioni risorsa o l’interfaccia di
configurazione XML per assegnare ai principal i ruoli dei gruppi di utenti
appropriati. Per ulteriori informazioni, fare riferimento alla guida dei portlet
oppure a Interfaccia di configurazione XML. Per assegnare ai principal i
ruoli dei gruppi di utenti appropriati utilizzando il portlet Autorizzazioni
risorsa, attenersi alla seguente procedura:
1) Accedere al portale utilizzando l’account di amministratore.
2) Aprire il portlet Autorizzazioni risorsa.
3) Selezionare il gruppo di utenti Tipo risorsa.
4) Selezionare l’opzione Tutti gli utenti autenticati del portale ed
analizzare le assegnazioni di ruoli esistenti su quel gruppo di utenti.
5) Utilizzare il portlet Autorizzazioni risorsa per creare le stesse
assegnazioni ruoli nel nuovo portale.
6) Ripetere questa procedura per Tutti i gruppi di utenti del portale.
2. Migrazione di autorizzazioni per le risorse di gestione di WebSphere Portal
5.1.x
Tabella 2. Migrazione di autorizzazioni per WebSphere Portal 5.1.x
Pagina di gestione 5.1.x
Titolo del portlet di gestione 5.1.x
Interfaccia utente del portale
Gestione pagine
v Gestione pagine
v Temi e skin
Gestione portlet
v Moduli Web
v Applicazioni
Temi e skin
Gestione moduli Web
Gestione applicazioni
v Portlet
Gestione portlet
v Servizi Web
Configurazione dei servizi Web
v Clipping Web
Editor Clipping Web
Accesso
v Utenti e gruppi
v Autorizzazioni risorsa
Gestione utenti e gruppi
Autorizzazioni risorsa
v Autorizzazioni utente e gruppo
Autorizzazioni utente e gruppo
v Protezione credenziali
Protezione credenziali
29
Tabella 2. Migrazione di autorizzazioni per WebSphere Portal 5.1.x (Continua)
Pagina di gestione 5.1.x
Titolo del portlet di gestione 5.1.x
Impostazioni portale
Impostazioni globali
v Impostazioni globali
v Associazione URL
Portlet Associazione URL
v Nomi univoci personalizzati
Gestione nomi univoci personalizzati
v Markup supportate
Gestione markup
v Client supportati
v Gestione ricerca
Gestione client
v Importa XML
Gestione della raccolta di ricerca
Importa XML
Analisi del portale
v Utenti abituali
v Abilita traccia
Contenuto Portale
Utenti abituali
Abilita traccia
Gestione librerie documenti
v Gestione librerie documenti
Portali virtuali
Virtual Portal Manager
v Gestione dei portali virtuali
Personalizzazione pagina
v Layout del contenuto
v Aspetto
Modifica layout
Aspetto portlet
v Vincoli
Vincoli pagina
v Cavi
Strumento di collegamento del portlet
Proprietà della pagina
Proprietà della pagina
Organizza Preferiti
Organizza Preferiti
Accesso
Portlet di accesso
Modifica profilo
Modifica profilo
3. Migrazione del database di Member Manager utilizzando la riga comandi
a. Attenersi alla seguente procedura per eseguire la migrazione di un database
di DB2 Member Manager:
1) Stabilire una connessione al precedente database di WebSphere Portal
utilizzando il seguente comando:
db2 connect to DB user utente_db using password_db
2) Utilizzare il seguente comando per esportare le tabelle di Member
Manager dal database precedente:
db2 export to nomefile.ixf of ixf SELECT * FROM utente_db.tabella
nomefile è il nome del file ixf.
utente_db è il nome dell’utente del database.
tabella è il nome di una delle seguenti tabelle di Member Manager:
v WMMDBABVAL
v WMMDBACMPV
v WMMDBACOMP
v WMMDBACVAL
v WMMDBADTYP
30
Migrazione
v
v
v
v
v
v
v
WMMDBADVAL
WMMDBAIVAL
WMMDBAMTYP
WMMDBARVAL
WMMDBASVAL
WMMDBATR
WMMDBATVAL
v
v
v
v
v
v
v
v
WMMDBKEYS
WMMDBMBR
WMMGRPMBR
WMMKEYS
WMMLAACMPV
WMMLAACOMP
WMMLAACVAL
WMMLAADTYP
v
v
v
v
v
v
v
WMMLAADVAL
WMMLAAIVAL
WMMLAAMTYP
WMMLAARVAL
WMMLAASVAL
WMMLAATR
WMMLAATVAL
v
v
v
v
v
v
WMMLAEXTID
WMMLAKEYS
WMMLAMBR
WMMMBR
WMMMBRREL
WMMUSERREG
Nota: Per ulteriori informazioni sull’esportazione di dati da un
database, consultare EXPORT Command.
3) Facoltativo: utilizzare il seguente comando per ripulire tutte le tabelle
dal database di WebSphere Portal corrente se non ci sono dati di
Member Manager nel database:
db2 DELETE FROM utente_db.tabella tabella
tabella è il nome di una delle tabelle di Member Manager
precedentemente elencate.
4) Utilizzare il seguente comando per esportare le tabelle di Member
Manager dal database precedente:
db2 import from nomefile.ixf of ixf INSERT INTO utente_db.tabella
nomefile è il nome del file ixf.
Nota: Ogni nomefile deve corrispondere a quelli di cui si è eseguita
l’esportazione per la stessa tabella.
tabella è il nome di una delle seguenti tabelle di Member Manager:
31
v
v
v
v
v
v
v
WMMDBABVAL
WMMDBACMPV
WMMDBACOMP
WMMDBACVAL
WMMDBADTYP
WMMDBADVAL
WMMDBAIVAL
v
v
v
v
v
v
v
v
WMMDBAMTYP
WMMDBARVAL
WMMDBASVAL
WMMDBATR
WMMDBATVAL
WMMDBKEYS
WMMDBMBR
WMMGRPMBR
v
v
v
v
v
v
v
WMMKEYS
WMMLAACMPV
WMMLAACOMP
WMMLAACVAL
WMMLAADTYP
WMMLAADVAL
WMMLAAIVAL
v
v
v
v
v
v
v
v
v
v
v
WMMLAAMTYP
WMMLAARVAL
WMMLAASVAL
WMMLAATR
WMMLAATVAL
WMMLAEXTID
WMMLAKEYS
WMMLAMBR
WMMMBR
WMMMBRREL
WMMUSERREG
Nota: Per ulteriori informazioni sull’esportazione di dati da un
database, consultare IMPORT Command.
b. Attenersi alla seguente procedura per eseguire la migrazione di un database
di Cloudscape Member Manager:
1) Copiare il database di Cloudscape dal server WebSphere Portal
precedente ad un’ubicazione sulla stessa macchina del server corrente.
Nota: Se il server precedente si trova sulla stessa macchina del server
corrente, non occorre eseguire quest’operazione; occorrerà tuttavia
arrestare il server precedente, se è attivo.
2) Modificare il file wpconfig_sourceDb.properties in modo che punti al
database di Cloudscape del server precedente di cui si è eseguita la
copia sul server corrente, ad esempio:
32
Migrazione
v source.wmm.DbUrl=jdbc:db2j:C:\\migrationcloudscape\\
cloudscape\\wpsdb
v source.wmm.DbUrl=jdbc:db2j:/opt/migrationcloudscape/cloudscape/
wpsdb
v source.wmm.DbUrl=jdbc:db2j:/opt/migrationcloudscape/cloudscape/
wpsdb
3) Eseguire l’attività database-transfer-wmm per migrare/trasferire il
database di Member Manager dal server precedente al server corrente,
ad esempio:
v C:\Programmi\IBM\WebSphere\PortalServer\config\WPSconfig.bat
database-transfer-wmm
v /opt/IBM/WebSphere/PortalServer/config/WPSconfig.sh
v /opt/IBM/WebSphere/PortalServer/config/WPSconfig.sh
4. Migrazione di dati di protezione credenziali
I segreti delle credenziali esistenti devono essere gestiti diversamente a seconda
dell’ambiente:
v Protezione predefinita di WebSphere Portal: completare la seguente
procedura se si desidera migrare i segreti delle credenziali esistenti al sistema
WebSphere Portal corrente.
v Implementazione della protezione di altro produttore (Tivoli Access
Manager): non è richiesta alcuna procedura supplementare. I segreti delle
credenziali esistenti possono essere utilizzati nel sistema WebSphere Portal
corrente.
Nota: se si decide di non migrare i segreti delle credenziali esistenti, gli utenti
devono fornire le informazioni sulle credenziali la prima volta in cui un
portlet di Versione 6.0 tenta di utilizzare i dati.
La migrazione dei segreti delle credenziali comporta lo spostamento di due
tabelle, VAULT_DATA e VAULT_RESOURCES dal database WebSphere Portal
precedente al database WebSphere Portal corrente. La definizione di tabella non
è stata modificata in WebSphere Portal Versione 6.0, per cui non è necessario
modificare i dati. Poiché il database è ora suddiviso in domini di database
diversi, anche i dati devono essere suddivisi. Utilizzare un programma di utilità
di importazione e esportazione fornito dal server di database per migrare i dati.
Gli esempi di seguito riportati illustrano come importare ed esportare le tabelle
quando DB2 è il server di database. Utilizzare questo esempio come una guida
generale per l’ambiente utilizzato. Attenersi a questa procedura prima che gli
utenti abbiano accesso al sistema WebSphere Portal corrente e aggiungano
potenzialmente altri dati al sistema.
a. Esportare le tabelle dal database WebSphere Portal precedente.
1) Nel server di database WebSphere Portal precedente, avviare il CLP
(Command Line Processor, processore riga comandi) DB2 (Windows) o
la shell DB2 (Unix).
2) Immettere i seguenti comandi (immettere ciascuna sezione del testo su
una riga):
connect to dbwps user utentedb using pwutentedb
export to C:/temp/vault.res.customization.wp5.ixf of ixf messages C:/temp/vault.res.customization.wp5.msgtxt SELECT DISTINCT VAULT_RESOURC
export to C:/temp/vault.res.release.wp5.ixf of ixf messages C:/temp/vault.res.release.wp5.msgtxt SELECT DISTINCT VAULT_RESOURCES.RESOURCE_N
export to C:/temp/vault.data.customization.wp5.ixf of ixf messages C:/temp/vault.data.customization.wp5.msgtxt SELECT VAULT_DATA.RESOURCE_N
33
export to C:/temp/vault.data.release.wp5.ixf of ixf messages C:/temp/vault.data.release.wp5.msgtxt SELECT VAULT_DATA.RESOURCE_NAME, VAULT_DAT
disconnect dbwps
dove dbwps è il nome database del database WebSphere Portal precedente,
utentedb è l’ID utente dell’amministratore di database e pwutentedb è la
password per l’ID utente.
b. Importare i dati presenti nelle tabelle nel database WebSphere Portal
corrente.
1) Se il server di database WebSphere Portal corrente non si trova sulla
stessa macchina del server di database WebSphere Portal precedente,
copiare i file ixf esportati sulla macchina del server di database
WebSphere Portal corrente.
2) Nel server di database WebSphere Portal corrente, avviare il CLP
(Command Line Processor, processore riga comandi) DB2 (Windows) o
la shell DB2 (Unix).
3) Immettere i seguenti comandi (immettere ciascuna sezione del testo su
una riga):
connect to dbwps user utentedb using pwutentedb
import from C:/temp/vault.res.customization.wp5.ixf of ixf modified by indexschema=customization messages C:/temp/vault.res.customization.wp6
import from C:/temp/vault.res.release.wp5.ixf of ixf modified by indexschema=release messages C:/temp/vault.res.release.wp6.msgtxt INSERT INT
import from C:/temp/vault.data.customization.wp5.ixf of ixf modified by indexschema=customization messages C:/temp/vault.data.customization.w
import from C:/temp/vault.data.release.wp5.ixf of ixf modified by indexschema=release messages C:/temp/vault.data.release.wp6.msgtxt INSERT I
dove dbwps è il nome database del database WebSphere Portal corrente,
utentedb è l’ID utente dell’amministratore di database e pwutentedb è la
password per l’ID utente.
Nota: in determinate condizioni, l’importazione nelle tabelle
VAULT_RESOURCES e VAULT_DATA può generare errori che indicano
che una riga con lo stesso nome risorsa esiste già. Ignorare questo
errore. La tabella VAULT_RESOURCES definisce solo i nomi delle
risorse da utilizzare nella protezione credenziali. Se i nomi
esistono già, non esiste alcuna necessità di ridefinirli. Lo stesso
concetto vale per la tabella VAULT_DATA. Le credenziali già
memorizzate nella tabella non devono essere ridefinite. Di seguito
viene riportato un esempio di questo tipo di errore:
SQL0803N One or more values in the INSERT statement, UPDATE statement, or
foreign key update caused by a DELETE statement are not valid because the
primary key, unique constraint or unique index identified by "1" constrains
table "SCHEMA_NAME.VAULT_RESOURCES or VAULT_DATA" from having duplicate rows for those columns.
SQLSTATE=23505
4) Immettere i seguenti comandi:
select USER_DN, RESOURCE_NAME
from RELEASE.VAULT_DATA vd1
where EXISTS
(SELECT * FROM RELEASE.VAULT_DATA vd2
WHERE LOWER(vd1.USER_DN) = LOWER(vd2.USER_DN)
and vd1.RESOURCE_NAME = vd2.RESOURCE_NAME
and vd1.USER_DN < vd2.USER_DN)
select USER_DN, RESOURCE_NAME
from CUSTOMIZATION.VAULT_DATA vd1
where EXISTS
34
Migrazione
(SELECT * FROM CUSTOMIZATION.VAULT_DATA vd2
WHERE LOWER(vd1.USER_DN) = LOWER(vd2.USER_DN)
and vd1.RESOURCE_NAME = vd2.RESOURCE_NAME
and vd1.USER_DN < vd2.USER_DN)
Qualsiasi valore restituito da questi comandi mostra un potenziale
conflitto di DN utente dove una conversione in caratteri minuscoli non
può essere completata correttamente. Per queste voci occorrerà
controllare il corrispondente DN utente e le righe duplicate dovranno
essere rimosse manualmente. Eseguire nuovamente i comandi sopra
indicati fino a quando non verrà restituito alcun valore.
Se i comandi sopra indicati non restituiscono alcun valore, immettere i
seguenti comandi per aggiornare i campi DN utente alla stringa in
caratteri minuscoli:
UPDATE RELEASE.VAULT_DATA
SET USER_DN = LOWER(USER_DN)
UPDATE CUSTOMIZATION.VAULT_DATA
SET USER_DN = LOWER(USER_DN)
disconnect wpsdb
dove dbwps è il nome database del database WebSphere Portal corrente.
c. Verificare che il valore system.dn in VaultService per la versione corrente di
WebSphere Portal sia impostato sullo stesso valore utilizzato nel sistema
WebSphere Portal precedente. Questo dn viene utilizzato per memorizzare le
credenziali del sistema (condivise). Se il valore è diverso, la protezione non
restituisce i segreti delle credenziali per gli slot condivisi.
5. Eliminazione di voci delle risorse WebSphere Portal precedenti da Tivoli
Access Manager
Se Tivoli Access Manager è stato utilizzato con la versione precedente di
WebSphere Portal, potrebbe essere necessario eliminare le voci delle risorse
obsolete ancora presenti nello spazio oggetti di Tivoli Access Manager. Se si
utilizza lo stesso sistema Tivoli Access Manager utilizzato con la versione
precedente di WebSphere Portal, è necessario completare questa procedura.
Questa procedura non è necessaria se si utilizzano sistemi Tivoli Access
Manager diversi per la versione precedente di WebSphere Portal e la versione
corrente di WebSphere Portal.
Importante: non eseguire questa procedura se si utilizza ancora la versione
precedente di WebSphere Portal.
a. Nel sistema WebSphere Portal precedente, aprire il file
externalaccesscontrolservice.properties e determinare il valore per
root_pd.
b. Nel sistema Tivoli Access Manager, andare alla riga comandi pdadmin e
immettere il seguente comando per eliminare le voci dello spazio oggetti
corrispondenti alle risorse della versione precedente di WebSphere Portal:
pdadmin> delete objectspaces root_pd*.
a. Nel sistema Tivoli Access Manager, andare alla riga comandi pdadmin e
immettere il seguente comando per eliminare gli ACL associati alle risorse
della versione precedente di WebSphere Portal: pdadmin> acl delete
nome_acl.
v “Migrazione delle configurazioni di WebSphere Portal” a pagina 20
35
v Risoluzione dei problemi di migrazione
Migrazione di componenti aggiuntivi
Questo argomento fornisce le informazioni su come migrare i componenti
aggiuntivi che possono far parte del proprio ambiente.
Per migrare individualmente risorse in un ambiente di sviluppo, selezionare i passi
successivi in funzione dello scenario di migrazione:
Document Manager: migrazione da 5.0.x a 6.0
Utilizzare la procedura di seguito riportata per migrare Document Manager da
Portal versione 5.0.x a Portal versione 6.0.
Prima di migrare, è necessario applicare la patch di correzione per la migrazione a
Portal 5.0.x. La patch è disponibile in APAR PK16482. Inoltre, è necessario
sincronizzare le impostazioni globali di accesso di Document Manager. Le
impostazioni globali di accesso per l’eredità della libreria documenti potrebbero
essere diverse fra i server di origine e quelli di destinazione. Poiché l’ambito delle
impostazioni migrate non include le impostazioni globali, è necessario
sincronizzare le impostazioni fra i server di origine e di destinazione in modo che
il controllo accessi delle librerie documenti resti lo stesso dopo la migrazione. Per
la migrazione 5.0.x, anche tutti i ruoli di accesso sulle risorse virtuali WPCP sul
server di origine 5.0 devono essere impostati sulla root del contenuto del server di
destinazione 6.0.
Quando si esegue la migrazione. le impostazioni di accesso del portale per la
libreria documenti predefinita, ad esempio i blocchi, l’attività del flusso di lavoro e
le versioni, non vengono importate nel server 6.0. È necessario impostare
manualmente le impostazioni di blocchi, flusso di lavoro e versione per la libreria
documenti predefinita di destinazione.
Nota: Quando si esegue la migrazione di Document Manager da Portal versione
5.0.x a Portal versione 6.0, tutte le librerie documenti vengono migrate
contemporaneamente.
Verificare che il server 5.0.x stia eseguendo una versione supportata di Portal per la
migrazione alla versione 6.0. Le versioni di Portal supportate sono elencate in
“Pianificazione” a pagina 1.
1. Richiesto: Assicurarsi di aver completato le procedure fornite in “Preparazione
all’esecuzione delle attività di migrazione” a pagina 16 e “Migrazione delle
configurazioni di WebSphere Portal” a pagina 20. Il passo 1 deve essere
completato prima di continuare il processo di migrazione di Document
Manager. La migrazione dei dati di Document Manager senza eseguire questo
passo non è supportata.
2. Aggiornare il file root_server_portale/jcr/migration/conf/pdm50_conf.xml sul
sistema Portal 6.0. Verificare che le seguenti proprietà nella sezione <init> siano
impostate come specificato, modificandole se necessario:
v init
– MigDirSource: la directory di migrazione per i dati esportati. Questa
directory verrà utilizzata per l’esportazione e la conversione da 5.0.x.
Assicurarsi che la directory sia vuota. Notare che questa directory si trova
sul server di destinazione (6.0).
36
Migrazione
3.
4.
5.
6.
7.
8.
9.
– MigDirTarget: la directory di migrazione si trova sul server di
destinazione (6.0). Questa directory sarà utilizzata per l’importazione in
6.0. Assicurarsi che la directory sia vuota e diversa da MigDirSource.
– Database50: impostare sul tipo di server di database nel server 5.0x (ad
esempio, db2, cloudscape, oracle o sqlserver).
– SourceServerPort: il nome host e la porta per il server 5.1.x. Per
impostazione predefinita, la porta del server 5.0.x è 9081.
– TargetServerPort: il nome host e la porta per il server 6.0. Per
impostazione predefinita, la porta del server 6.0 è 10038.
– ExportUserId: impostare questo valore sull’ID utente dell’amministratore
di Portal 5.0.x.
– ExportPassword: modificare questo valore con la password corretta per
l’amministratore 5.0.x.
– ImportUserId: impostare questo valore sull’ID utente dell’amministratore
Portal 6.0.
– ImportPassword: modificare questo valore con la password corretta per
l’amministratore 6.0.
– IncludeVersion: modificare in true per migrare le versioni dei documenti.
Copiare root_server_portale/shared/app/pcm.jar dal sistema Portal 5.0 in
root_server_portale/jcr/migration/lib sul sistema Portal 6.0.
Modificare il file jcrmig.properties nella directory root_server_portale/
migration/components/jcr. Modificare la proprietà appServerDir per
specificare il percorso di WebSphere Application Server.
Avviare entrambi i server Portal 5.0.x e 6.0.
Eseguire WPmigrate.bat/sh migrate-pdm-export-50x.
a. Verificare che il passo di migrazione sia stato completato senza errori. Se si
sono verificati errori, esaminare i log di Portal 5.0 per ottenere informazioni
diagnostiche estese.
b. Verificare che i dati siano stati inseriti correttamente nella directory di
esportazione.
Eseguire WPmigrate.bat/sh migrate-pdm-convert-50x.
a. Verificare che il passo di migrazione sia stato completato senza errori.
output della conversione.
Eseguire WPmigrate.bat/sh migrate-pdm-transform-50x.
output della trasformazione.
Eseguire WPmigrate.bat/sh migrate-pdm-import-50x.
La migrazione di Document Manager da Portal versione 5.0.x a Portal versione 6.0
non migra le bozze o le attività ma solo i documenti approvati o conclusi.
Document Manager: migrazione da 5.1.x a 6.0
Utilizzare la procedura di seguito riportata per migrare Document Manager da
Portal versione 5.1.x a Portal versione 6.0.
37
Prima di eseguire la migrazione, sincronizzare le impostazioni globali di accesso di
Document Manager. Le impostazioni globali di accesso per l’eredità della libreria
documenti potrebbero essere diverse fra i server di origine e quelli di destinazione.
Poiché l’ambito delle impostazioni migrate non include le impostazioni globali, è
necessario sincronizzare le impostazioni fra i server di origine e di destinazione in
modo che il controllo accessi delle librerie documenti resti lo stesso dopo la
migrazione. Per la migrazione 5.1.x, anche tutti i ruoli di accesso sulla risorsa
virtuale ICM_CONTENT_REPOSITORY sul server di origine 5.1 devono essere
impostati sulla root del contenuto del server di destinazione 6.0.
Quando si esegue la migrazione. le impostazioni di accesso del portale per la
libreria documenti predefinita, ad esempio i blocchi, l’attività del flusso di lavoro e
le versioni, non vengono importate nel server 6.0. È necessario impostare
manualmente le impostazioni di blocchi, flusso di lavoro e versione per la libreria
documenti predefinita di destinazione.
Verificare che il server 5.1.x stia eseguendo una versione supportata di Portal per la
migrazione alla versione 6.0. Le versioni di Portal supportate sono elencate in
“Pianificazione” a pagina 1.
1. Richiesto: Assicurarsi di aver completato le procedure fornite in “Preparazione
configurazioni di WebSphere Portal” a pagina 20. Il passo 1 deve essere
completato prima di continuare il processo di migrazione di Document
Manager. La migrazione dei dati di Document Manager senza eseguire questo
passo non è supportata.
2. Configurare Document Transfer Tool sul server 5.1.0.x di WebSphere Portal nel
seguente modo:
a. Installare PK18903.
b. Installare root_server_portale/jcr/installableApps/icmjcr.ear su
WebSphere Portal, oppure sul cluster di Portal in un ambiente con cluster,
utilizzando la console di gestione.
c. In un ambiente con cluster, aggiornare il plugin del server Web e riavviare il
server Web.
d. Riavviare WebSphere Portal oppure il cluster di Portal.
3. Creare una directory di esportazione vuota sul sistema 5.1.x. Ad esempio,
c:\export\. Condividere questa directory con il sistema 6.0 (la condivisione può
essere realizzata con i comandi net use o NFS mount, ecc.). Questa directory di
esportazione sarà utilizzata per la proprietà MigDirSource, descritta
successivamente.
4. Aggiornare il file root_server_portale/jcr/migration/conf/pdm_conf.xml sul
sistema Portal 6.0. Verificare che le seguenti proprietà nella sezione <init> siano
impostate come specificato, modificandole se necessario:
v init
– MigDirSource: la directory di migrazione si trova sul server di origine
(5.1.x). Questa directory verrà utilizzata per l’esportazione da 5.1.x.
Assicurarsi che la directory sia vuota e condivisa con il server 6.0.
– MigDirSourceShared: la directory condivisa sul server di destinazione
(6.0). Le attività successive all’esportazione richiedono di accedere ai dati
esportati dal server di destinazione (6.0). Il server di destinazione deve
poter indirizzare la directory di origine, altrimenti i dati esportati devono
essere copiati nella directory locale del server di destinazione. Se la
directory di origine è condivisa, questa proprietà è la directory di origine,
38
Migrazione
così come appare sul server di destinazione (6.0). Se i dati esportati sono
copiati sul server di destinazione, questa proprietà è la directory locale in
cui sono memorizzati i dati esportati.
– MigDirTarget: la directory di migrazione sul server di destinazione (6.0).
Questa directory sarà utilizzata per l’importazione in 6.0. Assicurarsi che
la directory sia vuota e diversa da MigDirSource.
– SourceServerPort: il nome host e la porta per il server 5.1.x. Per
impostazione predefinita, la porta del server 5.1.x è 9081.
– TargetServerPort: il nome host e la porta per il server 6.0. Per
impostazione predefinita, la porta del server 6.0 è 10038.
– DocLib: l’elenco di librerie documenti da migrare, separate da virgole (ad
esempio, ″Document Manager″ o ″Document Manager, MyLib″).
– ExportUserId: impostare questo valore sull’ID utente dell’amministratore
di Portal 5.1.x. Se è abilitata la sicurezza LDAP, deve essere un DN
completo.
– ExportPassword: modificare questo valore con la password corretta per
– ImportUserId: impostare questo valore sull’ID utente dell’amministratore
Portal 6.0. Se è abilitata la sicurezza LDAP, deve essere un DN completo.
– ImportPassword: modificare questo valore con la password corretta per
– IncludeWorkflow: modificarlo in true per migrare le informazioni del
flusso di lavoro, incluso le bozze inoltrate.
– IncludeVersion: modificare in true per migrare le versioni dei documenti.
– AddWorkspace: spazi di lavoro aggiuntivi separati da virgole (se più di
uno) da aggiungere per la migrazione.
5. Modificare il file jcrmig.properties nella directory root_server_portale/
migration/components/jcr. Modificare la proprietà appServerDir per
specificare il percorso di WebSphere Application Server sul server di
destinazione (6.0).
6. Avviare entrambi i server Portal 5.1.x e 6.0.
7. Assicurarsi di essere nella directory root_server_portale/migration/, quindi
eseguire WPmigrate.bat/sh migrate-pdm-export-51x.
b. Verificare che i dati siano stati inseriti correttamente nelle directory di
esportazione.
8. Eseguire WPmigrate.bat/sh migrate-pdm-transform.
b. Verificare che i dati siano stati inseriti correttamente nelle directory di
importazione.
9. Eseguire WPmigrate.bat/sh migrate-pdm-import.
Personalization: migrazione da 5.0 a 6.0
Questa attività fornisce informazioni dettagliate per la migrazione del database
Personalization 5.0 alla Versione 6.0.
39
Utilizzare la procedura di seguito riportata per migrare il database Personalization
5.0 alla Versione 6.0:
1. Assicurarsi di aver completato le procedure fornite in “Preparazione
configurazioni di WebSphere Portal” a pagina 20.
2. Assicurarsi che JDBC possa accedere a Personalization 5.0.
3. Aggiornare il file root_server_portale/jcr/migration/conf/pzn_50_conf.xml.
Verificare che i seguenti parametri siano impostati come specificato, e
modificarli se necessario:
v Parametri di inizializzazione:
– TargetServerPort: il nome host e la porta su cui è in esecuzione
WebSphere Portal sulla macchina della versione 6.0.
– TargetRepositoryUserId: l’ID utente utilizzato per connettersi al repository
JCR della versione 6.0. Se è abilitata la sicurezza LDAP, deve essere un
DN completo.
– TargetRepositoryPassword: la password utilizzata per connettersi al
repository JCR della versione 6.0.
– TargetWorkspace: il nome dello spazio di lavoro che conterrà i dati della
versione 6.0. A meno che Versione 6.0 Personalization non sia stato
personalizzato per utilizzare uno spazio di lavoro diverso, deve essere
sempre RULESWORKSPACE.
– SourceData: il percorso del file system locale in cui saranno salvati i dati
esportati. Questo percorso deve fare riferimento ad una directory esistente
e vuota.
– ImportNode: il nome del nodo in cui saranno memorizzati i contenuti di
ciascun progetto. Se impostato, deve esistere prima dell’esecuzione. Se non
impostato, il valore predefinito è il nome del progetto importato.
– ProjectList: l’elenco separato da virgole dei progetti da importare. Se non
impostato, saranno importati tutti i progetti.
– DBUserId: l’ID utente utilizzato per connettersi al database 5.0.
– DBPassword: la password utilizzata per connettersi al database 5.0.
– DBName: il nome del database 5.0.
– DBDriver: il driver JDBC utilizzato per connettersi al database 5.0.
– DBHost: il nome host della macchina che contiene il database 5.0 (non
utilizzato da tutti i driver).
– DBPort: la porta utilizzata per connettersi al server di database 5.0 (non
utilizzata da tutti i driver).
– IncludeVersion: specifica se migrare le versioni di Personalization, se ne
esistono.
4. Impostare il parametro jdbcClasspath nel file root_server_portale/migration/
components/jcr/jcrmig.properties sul percorso classi richiesto per caricare il
DBDriver specificato nel passo precedente.
5. Avviare i server WebSphere Portal 5.0.x e 6.0.
v Immettere il seguente comando:
– UNIX:./startServer.sh WebSphere_Portal
– Windows: startServer.bat WebSphere_Portal
– i5/OS: startServer WebSphere_Portal -profileName root_profilo
dove root_profilo è il nome del profilo WebSphere Application Server in cui
è installato WebSphere Portal; ad esempio, wp_profile.
40
Migrazione
v Solo per i5/OS su 5.0.x:
– startServer WebSphere_Portal -instance nome_istanza
dove nome_instanza è il nome dell’istanza WebSphere Application Server in
cui è installato WebSphere Portal
6. Assicurarsi di essere nella directory portal_server_root/migration/ ed eseguire
l’attività WPmigrate.bat/sh migrate-pzn-50x.
Personalization: migrazione da 5.1 a 6.0
Questa attività fornisce informazioni dettagliate per la migrazione di Portal
Personalization alla versione corrente di IBM WebSphere Portal.
Utilizzare la procedura di seguito riportata per migrare Personalization da una
versione precedente di WebSphere Portal alla versione corrente:
2. Configurare Document Transfer Tool sulla versione 5.1.x di WebSphere Portal:
a. Installare PK18903.
b. Installare root_server_portale/jcr/installableApps/icmjcr.ear su WebSphere
Portal, oppure sul cluster di WebSphere Portal in un ambiente con cluster,
utilizzando la Console di gestione.
c. In un ambiente con cluster, aggiornare il plugin del server Web e riavviare
quindi il server Web.
d. Riavviare WebSphere Portal oppure il cluster di WebSphere Portal.
3. Aggiornare il file root_server_portale/jcr/migration/conf/pzn_conf.xml.
– SourceServerPort: il nome host e la porta su cui è in esecuzione
– TargetServerPort: il nome host e la porta su cui è in esecuzione
– ExportNode: il percorso del nodo da esportare.
– SourceExportData: la directory sulla macchina della versione 5.1 in cui
saranno salvati i dati esportati. Questo percorso deve fare riferimento ad
una directory esistente e vuota ed essere condiviso con la macchina della
versione 6.0.
– TargetExportData: il percorso sulla macchina della versione 6.0 utilizzato
per accedere alla directory SourceExportData.
– TempData: una directory esistente e vuota sulla macchina della versione
6.0. Questa directory sarà utilizzata per memorizzare i dati temporanei.
– SourceRepositoryUserId: l’ID utente utilizzato per connettersi al
repository JCR della versione 5.1. Se è abilitata la sicurezza LDAP, deve
essere un DN completo.
– SourceRepositoryPassword: la password utilizzata per connettersi al
repository JCR della versione 5.1.
– SourceWorkspace: il nome dello spazio di lavoro che contiene i dati della
versione 5.1. A meno che Personalization della Versione 5.1 non sia stato
sempre ROOTWORKSPACE.
41
– TargetRepositoryUserId: l’ID utente utilizzato per connettersi al repository
JCR della versione 6.0. Se è abilitata la sicurezza LDAP, deve essere un
DN completo.
– TargetRepositoryPassword: la password utilizzata per la connessione al
repository JCR Versione 6.0.
– TargetWorkspace: il nome dello spazio di lavoro che contiene i dati
Versione 6.0. A meno che Personalization Versione 6.0 non sia stato
sempre RULESWORKSPACE.
– IncludeVersion: specifica se migrare le versioni di Personalization, se ne
esistono.
4. Avviare i server WebSphere Portal 5.1.x e 6.0.
v Immettere il seguente comando:
– UNIX:./startServer.sh WebSphere_Portal
– Windows: startServer.bat WebSphere_Portal
– i5/OS: startServer WebSphere_Portal -profileName root_profilo
dove root_profilo è il nome del profilo WebSphere Application Server in cui
è installato WebSphere Portal; ad esempio, wp_profile.
v Solo per i5/OS su 5.1.x:
– startServer WebSphere_Portal -instance nome_istanza
dove nome_istanza è il nome dell’istanza WebSphere Application Server in
cui è installato WebSphere Portal
5. Assicurarsi di essere nella directory root_server_portale/migration/ ed
eseguire l’attività WPmigrate.bat/sh migrate-pzn-51x.
Personalization: migrazione dei dati esportati da 5.1 a 6.0
Questa attività fornisce informazioni dettagliate per la migrazione dei dati di
Personalization esportati alla versione corrente di WebSphere Portal.
Utilizzare la procedura di seguito riportata per migrare i dati di Personalization
esportati dalla versione 5.1 di WebSphere Portal alla versione corrente:
2. Copiare i dati 5.1 esportati nella macchina WebSphere Portal Versione 6.0.
3. Aggiornare il file root_server_portale/jcr/migration/conf/pzn_sv_conf.xml.
– ExportData: la directory che contiene i dati esportati della versione 5.1.
– TempData: una directory esistente e vuota. Questa directory sarà utilizzata
per memorizzare i dati temporanei.
– MigratedData: la directory che conterrà i dati della versione 6.0. Questo
percorso deve fare riferimento ad una directory esistente e vuota.
– SourceWorkspace: il nome dello spazio di lavoro che contiene i dati della
Versione 5.1.
– TargetWorkspace: il nome dello spazio di lavoro che conterrà i dati della
Versione 6.0.
4. Eseguire l’attività migrate-pzn-svData-transform-51x.
42
Migrazione
Migrazione di Web Content Management
Questi argomenti descrivono le modalità di migrazione dei dati di Web Content
Management e dei portlet di rendering alla versione corrente di WebSphere Portal.
Panoramica della migrazione di Web Content Management
Questo argomento contiene informazioni sui processi interessati nella migrazione
dei dati e dei portlet di IBM Workplace Web Content Management.
La migrazione a Web Content Management viene eseguita come parte del processo
di migrazione generale a IBM WebSphere Portal. Per ulteriori informazioni,
consultare Capitolo 1, “Migrazione”, a pagina 1.
Percorsi di migrazione
È possibile migrare solo i dati e i portlet di Web Content Management da:
v IBM Workplace Web Content Management versione 2.5 e 2.6.
v WebSphere Portal versione 5.1.
Per migrare da versioni precedenti di Web Content Management, è necessario
prima migrare a IBM Workplace Web Content Management versione 2.5 o 2.6
oppure WebSphere Portal versione 5.1. Per ulteriori informazioni su questi rilasci
del prodotto, fare riferimento al Centro informazioni.
Non è possibile migrare dati da un sistema Web Content Management che utilizza
IBM Content Manager come repository di dati. Sarà necessario modificare il
repository sul vecchio sistema in Cloudscape, DB2, Oracle o Microsoft SQL Server
2000 con l’attività di configurazione repository. Per ulteriori informazioni fare
riferimento a WebSphere Portal 5.1 Information Center.
Processo di migrazione di Web Content Management
1. Migrare ogni server WebSphere Portal utilizzato nel vecchio sistema di
contenuto Web. Per ulteriori informazioni, consultare Capitolo 1, “Migrazione”,
a pagina 1.
2. Migrare i dati di contenuto Web da un singolo sistema di contenuto Web
contenente i dati più recenti ad un singolo server sul nuovo sistema.
Normalmente si tratta di un sistema di sviluppo. Se si utilizzano server di
sviluppo decentrati, è necessario aggregare tutti i dati correnti su un solo
sistema utilizzando il syndication e poi migrare i dati da questo sistema. Per
ulteriori informazioni, consultare “Migrazione di un sistema di contenuto Web
primario”.
3. Eseguire il syndication dei dati migrati su tutti gli altri server nel nuovo
sistema di contenuto Web. Per ulteriori informazioni, consultare Syndication.
4. Configurare tutti i portlet di sviluppo che utilizzano i dati migrati. Per ulteriori
informazioni, consultare Configurazione del portlet di sviluppo.
5. Migrare i portlet di rendering ed i dati utente su tutti gli altri server nel sistema
di contenuto Web. Per ulteriori informazioni, consultare “Migrazione di un
sistema di contenuto Web secondario” a pagina 50.
6. Abilitare un cluster, se richiesto. Per ulteriori informazioni, consultare Cluster e
WebSphere Portal.
Migrazione di un sistema di contenuto Web primario
Queste attività forniscono informazioni dettagliate utilizzate per migrare un
sistema primario Web Content Management. Normalmente si tratta di un sistema
di sviluppo. Se si utilizzano server di sviluppo decentrati, è necessario aggregare
43
tutti i dati correnti su un solo sistema utilizzando il syndication e poi migrare i
dati da questo sistema. La migrazione primaria migrerà i dati, i portlet di
rendering e le informazioni sul profilo utenti.
Installazione dello strumento di migrazione del contenuto Web:
Prima di migrare un sistema di contenuto Web, occorre installare lo strumenti di
migrazione del contenuto Web.
Eseguire l’attività WPSconfig. {sh | bat} configure-wcm-migration dalla directory
root_server_portale/config del nuovo sistema.
v Windows: WPSconfig.bat configure-wcm-migration -DWasUserId=nomeutente
-DWasPassword=password
v UNIX: ./WPSconfig.sh configure-wcm-migration -DWasUserId=nomeutente
v i5/OS: WPSconfig.sh -profileName root_profilo configure-wcm-migration
-DWasUserId=nomeutente -DWasPassword=password doveroot_profilo è il nome del
profilo IBM WebSphere Application Server dove è installato IBM WebSphere
Portal. Ad esempio, wp_profile.
L’utente specificato nel comando deve essere un amministratore di WebSphere
Application Server.
Migrazione dei dati di contenuto Web:
Quando si migra un sistema primario, occorre prima migrare i vecchi dati di
contenuto Web da un singolo sistema di contenuto Web. Normalmente si tratta di
un sistema di sviluppo. Se si utilizzano server di sviluppo decentrati, sarà
necessario aggregare tutti i dati correnti su un singolo sistema utilizzando il
syndication e poi migrare i dati da questo sistema.
Nota: Prima di migrare i dati di contenuto Web:
v Assicurarsi di avere completato la migrazione del prodotto IBM
WebSphere Portal al nuovo sistema. Le pagine di contenuto Web ed i
portlet di rendering che erano presenti sul vecchio sistema vengono
migrati al nuovo sistema ma sono disabilitati fino a quando non si
completa la migrazione successiva dei dati di contenuto Web.
v Prima di migrare i dati di contenuto Web, occorre eseguire i seguenti
strumenti sul vecchio sistema e risolvere gli eventuali problemi:
– Programma di verifica riferimento
– Programma di verifica del sito
– Programma di verifica risorse
– Fixer del membro
Per informazioni fare riferimento a WebSphere Portal 5.1 Centro
informazioni.
v La migrazione di notevoli quantità di dati richiederà molto tempo.
Accertarsi di pianificare l’esecuzione della migrazione in un orario che
non coincida con quello di utilizzo massimo.
v I file protetti da password non sono supportati nei dati di contenuto Web.
Se si hanno delle risorse contenenti dei file protetti da password che si
intende migrare da una versione precedente di IBM Workplace Web
Content Management, occorre rimuovere la protezione con password sulla
44
Migrazione
risorsa prima di eseguirne la migrazione. Se non si rimuove la protezione
con password, la migrazione avrà esito negativo.
v Eventuali componenti di Personalization che non fanno riferimento ad
una localizzazione contenuto o ad una regola di Personalization devono
essere eliminati prima della migrazione dei dati.
1. Copiare la cartella root_server_portale/wcm/config/ dal vecchio sistema a
una cartella di migrazione temporanea nel nuovo sistema. Non sovrascrivere
root_server_portale/wcm/config/ nel nuovo sistema.
2. A seconda del repository di dati utilizzato nel vecchio sistema, sarà necessario
copiare i seguenti file dal vecchio sistema alla cartella root_server_portale/
wcm/migration/exporter/lib nel nuovo sistema. Essi normalmente saranno:
v IBM Cloudscape: db2j.jar
v IBM DB2 Universal Database Enterprise Server Edition: db2jcc.jar,
db2jcc_license_cu.jar/db2jcc_license_cisuz.jar
v Oracle Enterprise Edition: classes12.jar
v Microsoft SQL Server Enterprise Edition: mssqlserver.jar, msbase.jar,
msutil.jar
3. Aggiornare root_server_portale/wcm/migration/exporter/
classpath.properties aggiungendo i nomi dei file copiati al passo 2 al valore
della proprietà exporter.classpath.
4. Se si sta eseguendo la migrazione da un repository di DB2, occorrerà
modificare i seguenti file che si trovano nella cartella di /wcm/config/ creata al
passo 1:
v aptrixjpe.properties: accertarsi che jdbc.url=jdbc:db2://<nome host
db2>:<numero porta>/wcmdb sia configurato per puntare al database del
vecchio sistema ed accertarsi che non si siano spazi prima o dopo l’URL.
v connect.cfg: accertarsi che <jdbc:db2://<nome host db2>:<numero
porta>/wcmdb driver="com.ibm.db2.jcc.DB2Driver" />
Nota: Il numero di porta per DB2 sul nuovo sistema può essere trovato
sotto %systemroot%/system32/drivers/etc/services sui sistemi
Windows o /etc/services sui sistemi UNIX.
5. Se si esegue la migrazione da un repository di Cloudscape integrato, arrestare
il server del portale sul vecchio sistema e copiare quindi questo database sul
nuovo sistema prima di eseguire la migrazione di Web Content Management.
Occorrerà modificare i seguenti file che si trovano nella cartella /wcm/config/
creata al passo 1:
v aptrixjpe.properties: accertarsi che
jdbc.url=jdbc:db2j:<percorso_a_database> sia configurato per puntare
all’ubicazione del database di Cloudscape sul nuovo sistema ed accertarsi
che non ci siano spazi prima o dopo l’URL.
v connect.cfg: assicurarsi che <jdbc:db2j:<percorso_a_database>
driver="com.ibm.db2j.jdbc.DB2jDriver" />
6. Aggiornare il file root_server_portale/wcm/migration/config/
migration.properties nel nuovo sistema. Verificare che i seguenti parametri
siano impostati come specificato, e modificarli se necessario:
v export.path: il percorso del file system locale in cui saranno salvati i dati
esportati.
v import.path: la directory nel file system locale in cui vengono salvati i dati
trasformati.
45
v summary.path: il percorso del file system locale in cui saranno creati i file di
configurazione di riepilogo. Questi file saranno utilizzati quando si migra a
un sistema secondario.
v legacy.config.path: il percorso del file system locale in cui si trova la
vecchia configurazione di Web Content Management. Vedere il passo 1.
v import.servlet.url: l’URL del servlet di importazione che viene eseguito
nel nuovo sistema. Sostituire hostlocale con il nome host adeguato per il
nuovo sistema.
v import.library.name: il nome della libreria creata durante l’importazione.
v import.library.locale: le impostazioni internazionali ISO della libreria
creata durante l’importazione. Questo valore deve corrispondere a quello
dei dati in fase di migrazione. E’ importante che questo valore sia impostato
accuratamente per consentire un corretto funzionamento della funzione di
ricerca nel sito importato. Consultare ISO-639 (http://www.ics.uci.edu/
pub/ietf/http/related/iso639.txt) e ISO-3166 (http://www.chemie.fuberlin.de/diverse/doc/ISO_3166.html) per ulteriori informazioni.
7. Aumentare il valore di timeout Ciclo di vita totale della transazione del
nuovo server WebSphere Portal a 1200 secondi tramite la console di gestione
di WebSphere Application Server. Andare a Application Server → server →
Servizi container → Servizio transazioni. Consultare il centro informazioni di
WebSphere Application Server per ulteriori informazioni. Annotare il valore
del timeout Ciclo di vita totale della transazione in modo da poterlo
ripristinare al passo 10.
8. Riavviare il server delle applicazioni del portale.
9. Eseguire l’attività wcmmigrate all-data dalla directory root_server_portale/
wcm/migration del nuovo sistema.
Importante: Prima di eseguire l’attività wcmmigrate, accertarsi che il server del
portale sul nuovo sistema sia in esecuzione.
v Windows: wcmmigrate.bat -user username -password password all-data
v UNIX: ./wcmmigrate.sh -user username -password password all-data
v i5/OS: wcmmigrate.sh -user username -password password all-data
Portal.
10. Verificare la migrazione esaminando la relativa console. Il messaggio
″comando riuscito″ viene visualizzato in seguito a una migrazione riuscita. Se
al termine viene visualizzato il messaggio ″comando non riuscito″ sarà
necessario esaminare i passaggi precedenti. Per ulteriori informazioni,
consultare “Risoluzione dei problemi di migrazione a Web Content
Management” a pagina 54.
Nota: Il numero totale di elementi esportati, trasformati ed importati potrebbe
non essere uguale, poiché alcuni elementi verranno uniti ed altri
elementi verranno aggiunti durante il processo di migrazione.
11. Ripristinare l’impostazione timeout Ciclo di vita totale della transazione
all’impostazione originaria che era stata modificata al passo 7.
13. Controllare la configurazione della libreria creata quando sono stati migrati i
dati ed apportare le modifiche necessarie. Occorrerà ad esempio abilitare
l’accesso utente a questa libreria aggiungendo gli utenti ed i gruppi a ogni
ruolo di libreria. Per ulteriori informazioni sulla configurazione di una libreria
di contenuto Web, consultare Gestione delle librerie.
46
Migrazione
14. Eseguire il syndication dei dati migrati su tutti gli altri server nel nuovo
sistema di contenuto Web. Per ulteriori informazioni, consultare Syndication.
Migrazione dei profili utente in corso:
Dopo la migrazione dei dati primari, occorre aggiornare gli utenti del portale
perché utilizzino i dati migrati.
Nota: Occorre migrare Member Manager prima di migrare i profili utente. Per
ulteriori informazioni, consultare “Migrazione della configurazione del
controllo accessi restante” a pagina 28.
1. Se si stanno migrando gli utenti su un sistema primario, andare al passo 3. Se
si stanno migrando gli utenti su un sistema secondario, copiare i file di
configurazione di riepilogo creati quando si è migrato il sistema primario ad
una cartella sul sistema secondario. Consultare summary.path nella sezione
relativa alla migrazione dei dati topic.
migration.properties. Verificare che i seguenti parametri siano impostati
come specificato, e modificarli se necessario:
v summary.path: il percorso sul file system locale dove sono stati copiati i
vecchi file di configurazione di riepilogo di IBM Workplace Web Content
Management nel passo 1.
3. Se il server LDAP contiene più di 200 utenti, occorre attenersi alla seguente
procedura. Altrimenti, procedere al passo 4.
a. Arrestare il server IBM WebSphere Portal.
b. Creare una copia di backup di root_server_portale/wmm/wmm.xml
denominata wmm.xml.bak.
Nota: Se si utilizza i5/OS, wmm.xml si trova in root_server_portale.
c. Aprire root_server_portale/wmm/wmm.xml e modificare le seguenti
impostazioni:
v Modificare maximumSearchResults,
maximumSearchResultsForSortingAndPaging e
maximumTotalSearchResultsForSortingAndPaging in un numero
superiore al numero totale di utenti. Ad esempio, se si hanno 300 utenti,
occorre modificare queste impostazioni almeno in 301.
v Modificare searchTimeOutmaximum in un valore pari a 2 milioni.
d. Riavviare il server WebSphere Portal.
Aumentare il valore di timeout Ciclo di vita totale della transazione del
6. Eseguire l’attività wcmmigrate users dalla directory root_server_portale/wcm/
migration, dove portal_server_root è il percorso della directory di installazione
della versione corrente di WebSphere Portal.
v Windows: wcmmigrate.bat -user username -password password users
4.
47
v UNIX: ./wcmmigrate.sh -user username -password password users
v i5/OS: wcmmigrate.sh -user username -password password users
L’utente specificato nel comando deve essere l’amministratore di WebSphere
Portal.
7. Verificare la migrazione degli utenti esaminando la relativa console. Il
messaggio ″comando riuscito″ viene visualizzato in seguito a una migrazione
riuscita. Se al termine viene visualizzato il messaggio ″comando non riuscito″
sarà necessario esaminare i passaggi precedenti. Per ulteriori informazioni,
8. Ripristinare l’impostazione timeout Ciclo di vita totale della transazione
10. Se si è eseguito il passo 3, occorre eseguire le seguenti operazioni:
a. Arrestare il server WebSphere Portal.
b. Ripristinare il file wmm.xml.bak creato al passo 3.b su root_server_portale/
wmm/wmm.xml.
c. Riavviare il server WebSphere Portal.
Migrazione di un portlet di rendering locale:
Dopo avere migrato i dati primari, occorre riconfigurare tutti i portlet di rendering
locali perché utilizzino i dati migrati.
Nota: Occorre migrare i dati di contenuto Web prima di migrare un portlet di
rendering locale. Per ulteriori informazioni, consultare “Migrazione dei dati
di contenuto Web” a pagina 44.
Nota: Se si dispone di un piccolo numero di portlet di rendering locali, potrebbe
essere più semplice installare e configurare dei nuovi portlet di rendering
locali per utilizzare i dati migrati invece di migrare i portlet esistenti. Per
ulteriori informazioni, consultare Configurazione del portlet di rendering
locale.
1. Se si sta migrando uno o più portlet di rendering locali su un sistema primario,
andare al passo 3. Se si sta migrando uno o più portlet di rendering locali su
un sistema secondario, copiare i file di configurazione di riepilogo creati
quando si è migrato il sistema primario ad una cartella sul sistema secondario.
Consultare summary.path nella sezione relativa alla migrazione dei dati.
migration.properties. Verificare che i seguenti parametri siano impostati come
specificato, e modificarli se necessario:
v virtual.portal: se si sta migrando un portlet di rendering locale che si trova
su un portale virtuale, occorre immettere il nome del portale virtuale.
3. Eseguire l’attività wcmmigrate configure-local dalla directory
root_server_portale/wcm/migration, dove portal_server_root è il percorso della
directory di installazione della versione corrente di WebSphere Portal.
48
Migrazione
v Windows: wcmmigrate.bat -user username -password password
configure-local
v UNIX: ./wcmmigrate.sh -user username -password password
configure-local
v i5/OS: wcmmigrate.sh -user username -password password configure-local
Portal.
4. Verificare la migrazione esaminando la relativa console. Il messaggio ″comando
riuscito″ viene visualizzato in seguito a una migrazione riuscita. Se al termine
viene visualizzato il messaggio ″comando non riuscito″ sarà necessario
esaminare i passaggi precedenti. Per ulteriori informazioni, consultare
“Risoluzione dei problemi di migrazione a Web Content Management” a
pagina 54.
5. Verificare la configurazione del portlet di rendering locale migrato. Per ulteriori
informazioni sulla configurazione di un portlet di rendering locale, consultare
Configurazione del portlet di rendering locale.
Nota: Riavviare il server del portale dopo avere completato i passi sopra
indicati per verificare che i portlet siano stati configurati correttamente.
Migrazione di un portlet di rendering remoto:
remoti perché utilizzino i dati migrati.
Nota: Occorre migrare i dati di contenuto Web sul sistema che il portlet di
rendering remoto è configurato ad utilizzare prima di migrare un portlet di
rendering remoto. Per ulteriori informazioni, consultare “Migrazione dei dati
Nota: Se si dispone di un piccolo numero di portlet di rendering remoti, potrebbe
remoti per utilizzare i dati migrati invece di migrare i portlet esistenti. Per
remoto.
1. Se si sta migrando uno o più portlet di rendering remoti su un sistema
primario, andare al passo 3. Se si sta migrando uno o più portlet di rendering
remoti su un sistema secondario, copiare i file di configurazione di riepilogo
creati quando si è migrato il sistema primario ad una cartella sul sistema
secondario. Consultare summary.path nella sezione relativa alla migrazione dei
dati.
v virtual.portal: se si sta migrando un portlet di rendering remoto che si
trova su un portale virtuale, occorre immettere il nome del portale virtuale.
remote_rendering.properties. Verificare che i seguenti parametri siano
impostati come specificato, e modificarli se necessario:
49
v remote.host.base.path.list: immettere il percorso di base dell’host remoto
del vecchio portlet di rendering remoto. Questo è l’″Host server di Web
Content Management″ specificato nella configurazione del vecchio portlet di
rendering remoto. Ad esempio,
remote.host.base.path.list=http://oldhostname:9081
Nota: Se tutti i vecchi portlet di rendering remoti utilizzano dati da un
singolo sistema, è possibile specificare
remote.host.base.path.list=all.
v WCM_REMOTE_HOST_BASE_PATH: immettere il percorso di base dell’host remoto
del server a cui si sta migrando il portlet di rendering remoto. Ad esempio,
remote.host.base.path.list=http://newhostname:9081
4. Eseguire l’attività wcmmigrate configure-remote dalla directory
directory di installazione della versione corrente di IBM WebSphere Portal.
configure-remote
configure-remote
v i5/OS: wcmmigrate.sh -user username -password password
configure-remote
Portal.
pagina 54.
6. Verificare la configurazione del portlet di rendering remoto migrato. Per
ulteriori informazioni sulla configurazione di un portlet di rendering remoto,
consultare Configurazione del portlet di rendering remoto.
Migrazione di un sistema di contenuto Web secondario
Queste attività forniscono informazioni dettagliate utilizzate per migrare un
sistema secondario Web Content Management. Questo può essere un sistema di
gestione temporanea, un sistema di consegna, un sistema di verifica o un altro
sistema di sviluppo. Solo i portlet di rendering ed i profili utente sono migrati sui
sistemi secondari. Per trasferire i dati dal sistema primario ai sistemi secondari si
utilizza il syndication.
Installazione dello strumento di migrazione del contenuto Web:
Prima di migrare un sistema di contenuto Web, occorre installare lo strumenti di
migrazione del contenuto Web.
Eseguire l’attività WPSconfig. {sh | bat} configure-wcm-migration dalla directory
root_server_portale/config del nuovo sistema.
v Windows: WPSconfig.bat configure-wcm-migration -DWasUserId=nomeutente
50
Migrazione
v UNIX: ./WPSconfig.sh configure-wcm-migration -DWasUserId=nomeutente
v i5/OS: WPSconfig.sh -profileName root_profilo configure-wcm-migration
-DWasUserId=nomeutente -DWasPassword=password doveroot_profilo è il nome del
profilo IBM WebSphere Application Server dove è installato IBM WebSphere
Portal. Ad esempio, wp_profile.
Application Server.
Migrazione dei profili utente in corso:
Dopo la migrazione dei dati primari, occorre aggiornare gli utenti del portale
perché utilizzino i dati migrati.
Nota: Occorre migrare Member Manager prima di migrare i profili utente. Per
ulteriori informazioni, consultare “Migrazione della configurazione del
controllo accessi restante” a pagina 28.
1. Se si stanno migrando gli utenti su un sistema primario, andare al passo 3. Se
si stanno migrando gli utenti su un sistema secondario, copiare i file di
configurazione di riepilogo creati quando si è migrato il sistema primario ad
una cartella sul sistema secondario. Consultare summary.path nella sezione
relativa alla migrazione dei dati topic.
migration.properties. Verificare che i seguenti parametri siano impostati
come specificato, e modificarli se necessario:
3. Se il server LDAP contiene più di 200 utenti, occorre attenersi alla seguente
procedura. Altrimenti, procedere al passo 4.
a. Arrestare il server IBM WebSphere Portal.
b. Creare una copia di backup di root_server_portale/wmm/wmm.xml
denominata wmm.xml.bak.
c. Aprire root_server_portale/wmm/wmm.xml e modificare le seguenti
impostazioni:
v Modificare maximumSearchResults,
maximumSearchResultsForSortingAndPaging e
maximumTotalSearchResultsForSortingAndPaging in un numero
superiore al numero totale di utenti. Ad esempio, se si hanno 300 utenti,
occorre modificare queste impostazioni almeno in 301.
v Modificare searchTimeOutmaximum in un valore pari a 2 milioni.
d. Riavviare il server WebSphere Portal.
4. Aumentare il valore di timeout Ciclo di vita totale della transazione del
51
5.
6.
7.
8.
9.
10.
Riavviare il server delle applicazioni del portale.
Eseguire l’attività wcmmigrate users dalla directory root_server_portale/wcm/
migration, dove portal_server_root è il percorso della directory di installazione
della versione corrente di WebSphere Portal.
v Windows: wcmmigrate.bat -user username -password password users
v UNIX: ./wcmmigrate.sh -user username -password password users
v i5/OS: wcmmigrate.sh -user username -password password users
Portal.
Verificare la migrazione degli utenti esaminando la relativa console. Il
messaggio ″comando riuscito″ viene visualizzato in seguito a una migrazione
riuscita. Se al termine viene visualizzato il messaggio ″comando non riuscito″
sarà necessario esaminare i passaggi precedenti. Per ulteriori informazioni,
Ripristinare l’impostazione timeout Ciclo di vita totale della transazione
Riavviare il server delle applicazioni del portale.
Se si è eseguito il passo 3, occorre eseguire le seguenti operazioni:
a. Arrestare il server WebSphere Portal.
b. Ripristinare il file wmm.xml.bak creato al passo 3.b su root_server_portale/
wmm/wmm.xml.
c. Riavviare il server WebSphere Portal.
Migrazione di un portlet di rendering locale:
locali perché utilizzino i dati migrati.
Nota: Occorre migrare i dati di contenuto Web prima di migrare un portlet di
rendering locale. Per ulteriori informazioni, consultare “Migrazione dei dati
Nota: Se si dispone di un piccolo numero di portlet di rendering locali, potrebbe
locali per utilizzare i dati migrati invece di migrare i portlet esistenti. Per
locale.
1. Se si sta migrando uno o più portlet di rendering locali su un sistema primario,
andare al passo 3. Se si sta migrando uno o più portlet di rendering locali su
un sistema secondario, copiare i file di configurazione di riepilogo creati
quando si è migrato il sistema primario ad una cartella sul sistema secondario.
Consultare summary.path nella sezione relativa alla migrazione dei dati.
52
Migrazione
v virtual.portal: se si sta migrando un portlet di rendering locale che si trova
su un portale virtuale, occorre immettere il nome del portale virtuale.
3. Eseguire l’attività wcmmigrate configure-local dalla directory
directory di installazione della versione corrente di WebSphere Portal.
configure-local
configure-local
v i5/OS: wcmmigrate.sh -user username -password password configure-local
Portal.
pagina 54.
5. Verificare la configurazione del portlet di rendering locale migrato. Per ulteriori
informazioni sulla configurazione di un portlet di rendering locale, consultare
Configurazione del portlet di rendering locale.
Migrazione di un portlet di rendering remoto:
remoti perché utilizzino i dati migrati.
Nota: Occorre migrare i dati di contenuto Web sul sistema che il portlet di
rendering remoto è configurato ad utilizzare prima di migrare un portlet di
rendering remoto. Per ulteriori informazioni, consultare “Migrazione dei dati
Nota: Se si dispone di un piccolo numero di portlet di rendering remoti, potrebbe
remoti per utilizzare i dati migrati invece di migrare i portlet esistenti. Per
remoto.
1. Se si sta migrando uno o più portlet di rendering remoti su un sistema
primario, andare al passo 3. Se si sta migrando uno o più portlet di rendering
remoti su un sistema secondario, copiare i file di configurazione di riepilogo
creati quando si è migrato il sistema primario ad una cartella sul sistema
secondario. Consultare summary.path nella sezione relativa alla migrazione dei
dati.
53
v virtual.portal: se si sta migrando un portlet di rendering remoto che si
trova su un portale virtuale, occorre immettere il nome del portale virtuale.
remote_rendering.properties. Verificare che i seguenti parametri siano
impostati come specificato, e modificarli se necessario:
v remote.host.base.path.list: immettere il percorso di base dell’host remoto
del vecchio portlet di rendering remoto. Questo è l’″Host server di Web
Content Management″ specificato nella configurazione del vecchio portlet di
rendering remoto. Ad esempio,
remote.host.base.path.list=http://oldhostname:9081
Nota: Se tutti i vecchi portlet di rendering remoti utilizzano dati da un
singolo sistema, è possibile specificare
remote.host.base.path.list=all.
v WCM_REMOTE_HOST_BASE_PATH: immettere il percorso di base dell’host remoto
del server a cui si sta migrando il portlet di rendering remoto. Ad esempio,
remote.host.base.path.list=http://newhostname:9081
4. Eseguire l’attività wcmmigrate configure-remote dalla directory
directory di installazione della versione corrente di IBM WebSphere Portal.
configure-remote
configure-remote
v i5/OS: wcmmigrate.sh -user username -password password
configure-remote
Portal.
“Risoluzione dei problemi di migrazione a Web Content Management”.
6. Verificare la configurazione del portlet di rendering remoto migrato. Per
ulteriori informazioni sulla configurazione di un portlet di rendering remoto,
consultare Configurazione del portlet di rendering remoto.
Risoluzione dei problemi di migrazione a Web Content
Management
Questo argomento contiene informazioni su come risolvere i problemi di una
migrazione non riuscita.
Tutti gli errori, le informazioni e le avvertenze vengono registrate nella console
durante l’esecuzione della migrazione. Il messaggio ″comando riuscito″ viene
visualizzato in seguito a una migrazione riuscita. Se al termine viene visualizzato il
messaggio ″comando non riuscito″ sarà necessario procedere come segue:
v Controllare gli eventuali messaggi di errore visualizzati durante la migrazione.
54
Migrazione
v Rivedere i file di log della migrazione che si trovano nella cartella
root_server_portale/wcm/migration/log.
v Verificare che le directory e i file copiati siano corretti come descritto nelle
attività di migrazione primarie e secondarie.
v Rivedere le impostazioni nel file root_server_portale/wcm/migration/config/
migration.properties.
Esecuzione di singoli comandi wcmmigrate all-data
Quando si esegue l’attività wcmmigrate all-data, viene eseguita una serie di
comandi. Per risolvere i problemi relativi all’attività wcmmigrate all-data è
possibile eseguire ognuno di questi comandi separatamente. Devono essere eseguiti
nell’ordine riportato di seguito.
validate
Questo comando convalida il file migration.properties, la
connettività di rete e le autorizzazioni per gli utenti. Immettere un
ID utente e password.
estimate-data
Fornisce una stima del tempo impiegato e dello spazio richiesto
per la migrazione dei dati.
export-data
Esporta gli elementi dal vecchio sistema.
transform-data
Trasforma gli elementi esportati in modo che siano pronti per
essere importati nel nuovo sistema.
import-data
Importa gli elementi trasformati. Immettere un ID utente e
password.
Ad esempio, per eseguire il comando validate, eseguire il comando di seguito dalla
directory root_server_portale/wcm/migration.
v Windows: wcmmigrate.bat -user username -password password validate
v UNIX: ./wcmmigrate.sh -user username -password password validate
v i5/OS: wcmmigrate.sh -user username -password password validate
Portal.
Ripresa o riavvio dei comandi wcmmigrate
Una volta identificato e risolto il problema che causava un errore di migrazione, è
possibile ripetere un comando wcmmigrate o riprendere un comando wcmmigrate
dal punto in cui si era verificato l’errore.
Ad esempio, per riavviare il comando wcmmigrate all-data, immettere quando
segue dalla directory root_server_portale/wcm/migration.
v Windows: wcmmigrate.bat -user nomeutente -password password all-data
-restart
v UNIX: ./wcmmigrate.sh -user nomeutente -password password all-data
-restart
v i5/OS: wcmmigrate.sh -user nomeutente -password password all-data -restart
Portal.
55
Per riprendere il comando wcmmigrate all-data dal punto dove si è verificato
l’errore nella migrazione, immettere quando segue dalla directory
root_server_portale/wcm/migration.
v Windows: wcmmigrate.bat -user nomeutente -password password all-data
-resume
v UNIX: ./wcmmigrate.sh -user nomeutente -password password all-data
-resume
v i5/OS: wcmmigrate.sh -user nomeutente -password password all-data -resume
Portal.
Messaggi di errore
La seguente tabella contiene un elenco dei messaggi di errore che potrebbero essere
visualizzati nella console di migrazione:
Messaggio di errore
Azione
L’utente specificato nella riga comandi deve
essere l’utente amministratore del portale.
Specificare un amministratore di WebSphere
Portal valido nella riga comandi.
Impossibile connettersi al servlet di
importazione; verificare l’URL del servlet di
importazione nelle proprietà della
migrazione
Controllare l’URL del servlet di
importazione in migration.properties.
Accertarsi che il servlet di importazione sia
stato distribuito e che il server di WebSphere
Portal sia stato avviato.
Codice di risposta http non previsto
restituito dal servlet di importazione: {0}
Controllare l’URL del servlet di
importazione in migration.properties.
Accertarsi che il servlet di importazione sia
stato distribuito e che il server di WebSphere
Portal sia stato avviato.
Impossibile trovare la risorsa {0}. Accertarsi
che il programma di verifica dei riferimenti
sia stato eseguito prima dell’esportazione.
Non è stato possibile trovare la risorsa cui si
fa riferimento. Prima di migrare i dati di
contenuto Web, occorre eseguire i seguenti
strumenti sul vecchio sistema e risolvere gli
eventuali problemi:
v Programma di verifica riferimento
v Programma di verifica del sito
v Programma di verifica risorse
v Fixer del membro
Per informazioni fare riferimento a
WebSphere Portal 5.1 Centro informazioni.
56
Migrazione
Impossibile creare il parametro: {0};
individuazione valore per {1} non riuscita
Non è stato possibile creare un parametro
portlet poiché il nuovo valore non era
disponibile. Accertarsi che
migration.properties faccia riferimento ai
dati di riepilogo corretti dalla migrazione
dei dati.
Aggiornamento parametro {0} non riuscito;
conservato il vecchio valore: {1}
Non è stato possibile aggiornare un
parametro portlet poiché il nuovo valore
non era disponibile. Accertarsi che
migration.properties faccia riferimento ai
dati di riepilogo corretti dalla migrazione
dei dati.
Messaggi di avvertenza
Se viene visualizzato qualcuno dei seguenti messaggi di avvertenza, occorrerà
controllare i file di log della migrazione che si trovano nella cartella
root_server_portale/wcm/migration/log.
v Si è verificato un errore grave durante la fase di importazione della migrazione
dati
v Si è verificato un problema durante la codifica dell’id del file: {0}
v Si è verificato un problema durante la decodifica dell’id del file: {0}
v Lettura del file delle proprietà della versione non riuscita; verranno utilizzate
etichette vuote
v Impossibile richiamare la data della versione; viene utilizzata la data corrente
come data della versione
v Si è verificato un problema nei dati di trasformazione; elemento ignorato,
l’elaborazione continua
v Si è verificato un problema nel sistema di trasformazione; elemento ignorato,
v Si è verificato un problema nel sistema di importazione; elemento ignorato,
Procedura dopo la migrazione
Il processo di migrazione a IBM Workplace Web Content Management non
aggiorna automaticamente il contenuto Web per utilizzare tutte le nuove funzioni
del rilascio corrente. I passaggi di seguito sono consigliati per aggiornare il vecchio
contenuto Web per utilizzare le funzioni di Web Content Management.
File di configurazione del contenuto Web
I file di configurazione del contenuto Web connect.cfg e aptrixjpe.properties
sono stati dichiarati obsoleti e sono stati sostituiti dal file
WCMConfigService.properties. Nessuna impostazione di configurazione dal
vecchio sistema viene migrata a questo file. Occorrerà aprire questo file ed
aggiornare le impostazioni in modo che corrispondano alla vecchia configurazione,
se necessario.
Il
v
v
v
file WCMConfigService.properties si trova in:
Windows: root_server_portale/wcm/shared/app/config/wcmservices
UNIX: root_server_portale/wcm/shared/app/config/wcmservices
i5/OS: root_server_portale/wcm/shared/app/config/wcmservices
Nota: La proprietà URL JDBC
Gli URL di driver del database devono ora contenere dei caratteri di escape.
Occorrerà modificare gli eventuali URL JDBC copiati da un vecchio file
connect.cfg. Ad esempio:
v Vecchio URL:
connect.connector.sqlconnector.databases.jdbc:microsoft:sqlserver://host:porta;DatabaseName=nomedb
v Nuovo URL: connect.connector.sqlconnector.databases.jdbc\
:microsoft\:sqlserver\://host\:porta;DatabaseName\=nomedb
57
Tag anchor e URL
Sostituire le tag anchor o gli URL nei modelli di presentazione o nelle
progettazioni di elemento utilizzando un elemento di collegamento oppure
utilizzando la funzione ″aggiungi collegamento″ negli elementi e nei campi rich
text e HTML. Per ulteriori informazioni consultare Elemento Collegamento e
Inserimento di un collegamento in un elemento.
Come ausilio in questo processo, vengono creati i seguenti file nella cartella di
percorso di riepilogo specificata durante la migrazione dei dati:
v transformed_contents.links
v transformed_library_components.links
v transformed_content_components.links
v transformed_presentation_templates.links
Questi file possono essere utilizzati come materiale di riferimento poiché elencano i
vecchi ed i nuovi nomi e percorsi di elementi di contenuto, componenti
(componenti libreria), elementi (componenti contenuto) e modelli di presentazione.
Collegamenti al contenuto di Web Content Management da siti esterni
Durante la migrazione, alcuni elementi verranno uniti, aggiunti o ridenominati.
Potrebbe essere necessario aggiornare i collegamenti al contenuto di Web Content
Management da siti esterni.
Come ausilio in questo processo, vengono creati i seguenti file nella cartella di
percorso di riepilogo specificata durante la migrazione dei dati:
v transformed_contents.links
v transformed_library_components.links
v transformed_content_components.links
v transformed_presentation_templates.links
Questi file elencano i vecchi ed i nuovi nomi e percorsi di elementi di contenuto,
componenti (componenti libreria), elementi (componenti contenuto) e modelli di
presentazione.
Oggetti precedenti con lo stesso nome
Diversamente dalle versioni precedenti di Web Content Management, non è
possibile creare due elementi Web Content di oggetti precedenti utilizzando lo
stesso nome in IBM WebSphere Portal versione 6.0.
Ad esempio, il vecchio sistema potrebbe avere il seguente framework del sito:
v MySite
– MySiteArea
– MySiteArea
Durante la migrazione, la seconda area del sito verrà rinominata in
″MySiteArea_1″. Il framework del sito apparirà quindi in questo modo:
v MySite
– MySiteArea
– MySiteArea_1
58
Migrazione
Eventuali riferimenti al percorso ″MySite/MySiteArea″ resteranno invariati ma
punteranno solo all’area del sito ″MySiteArea″. Sarà necessario modificare
eventuali percorsi che dovrebbero puntare invece a ″MySite/MySiteArea_1″.
Questo esempio si applica ad altri oggetti precedenti come le categorie e gli
elementi di contenuto.
Elementi bozza
Le bozze di siti, aree del sito e tassonomie che hanno degli elementi secondari
verranno pubblicate durante la migrazione insieme ai loro elementi secondari. Gli
elementi il cui stato è stato modificato da bozza a pubblicato sono elencati in
published_draft_items.txt, che si trova nella cartella del percorso di riepilogo
specificata durante la migrazione dei dati. Controllare questo file e verificare che le
eventuali modifiche a questi elementi pubblicati siano valide.
Se per nessun elemento è stato modificato lo stato da bozza a pubblicato, questo
file non verrà creato.
Elementi Navigator
La paginazione è ora supportata negli elementi di progettazione e navigator. Dopo
la migrazione, il numero massimo di elementi da visualizzare per pagina viene
impostato su un valore di cento per impostazione predefinita. Se qualcuno dei
propri navigator visualizza più di cento elementi, occorrerà modificare questo
valore. E’ anche possibile aggiungere un elemento di paginazione alla propria
progettazione di navigator. Per ulteriori informazioni, consultare Definizione delle
opzioni di progettazione dell’elemento Navigator.
Elementi Menu
Una progettazione ″Nessun risultato″ è stata aggiunta agli elementi di menu.
Occorre modificare tutti i propri menu ed immettere il testo appropriato nella
progettazione ″Nessun risultato″. In caso contrario, non verrà visualizzato nulla
quando un menu non trova risultati. Per ulteriori informazioni, consultare
Definizione delle opzioni di formattazione dell’elemento Menu.
Campi nome e titolo
Un campo titolo è stato aggiunto alla sezione di identificazione di tutti gli
elementi. Viene utilizzato per memorizzare il titolo dell’elemento come si vorrebbe
venisse visualizzato sulla pagina Web di rendering. A differenza del campo nome,
il campo titolo può utilizzare caratteri a doppio byte e caratteri non ASCII. Quando
viene migrato, il nome corrente viene copiato anche nel campo titolo. Occorrerà
modificare gli elementi dove si desidera utilizzare un titolo diverso da quello
creato durante la migrazione.
Le tag di contenuto Web che utilizzano l’attributo field="name" come tag
segnaposto possono essere modificate per utilizzare anche field="title".
Tag di connessione
L’utilizzo di tag di connessione è obsoleto, ad eccezione della memorizzazione dei
componenti nella cache. I contenuti che utilizzano tag di ″connessione″ sono ancora
validi ma si consiglia di sostituire le tag con altre funzioni standard di contenuti
59
Web. Per ulteriori informazioni, consultare Visualizzazione dei dati da origini
esterne.
Ricerca Web Content Management
Il modulo di ricerca Web Content Management non è più supportato. Le funzioni
di ricerca WebSphere Portal vengono ora utilizzate per cercare contenuti Web.
I moduli di ricerca che utilizzano il modulo Web Content Management devono
essere sostituiti o aggiornati con moduli di ricerca che utilizzano le funzioni di
ricerca di WebSphere Portal. Vedere Ricerca nei siti per informazioni sull’utilizzo
delle funzioni di ricerca di WebSphere Portal con i contenuti Web.
Spostamento di oggetti nelle nuove librerie
Il processo di migrazione a Web Content Management crea solo una libreria
singola. Per implementare più librerie, sarà necessario creare nuove librerie e
spostare elementi dalla libreria migrata alle nuove librerie. Per ulteriori
informazioni, consultare Copia e spostamento di elementi.
Codice API
Dopo la migrazione, eventuali codici API Web Content Management continueranno
a funzionare normalmente. L’API utilizzerà, per impostazione predefinita, la
libreria specificata nel file WCMConfigService.properties.
Dopo aver creato le librerie e aggiunto gli elementi, sarà necessario aggiornare il
codice API per renderlo adatto alla libreria attraverso il metodo
setCurrentDocumentLibrary. Consultare i file HTML Javadoc nella cartella
root_profilo_was\AppServer\profiles\wp_profile\installedApps\nodename\
wcm.ear\ilwwcm.war\webinterface\ per ulteriori informazioni su questo metodo.
File JSP
I file JSP utilizzati sul vecchio sistema dovranno essere copiati manualmente sul
nuovo sistema. Consultare Elementi JSP per informazioni dettagliate su dove
memorizzare i file JSP.
Modifiche all’accesso ai portlet di sviluppo
Non si assegna più l’accesso alle varie viste nel portlet di sviluppo configurando il
portlet di sviluppo. L’accesso alle varie viste nel portlet di sviluppo è ora
determinato dal ruolo assegnato ad utenti e gruppi. Per ulteriori informazioni,
consultare Utilizzo dei ruoli per i tipi di elementi in una libreria.
Integrità referenziale
In questo rilascio sono state aggiunte delle funzioni di integrità referenziale. Per
ulteriori informazioni, vedere Sviluppo in collaborazione e Eliminazione degli
elementi.
Queste funzioni sono applicate agli elementi migrati che contengono tag di
elemento o di componente solo dopo che l’elemento è stato aperto e salvato nel
portlet di sviluppo.
60
Migrazione
Pagine del portlet di sviluppo
Anche se i portlet di sviluppo non vengono migrati, le pagine di portale che
visualizzavano in precedenza un portlet di sviluppo sul vecchio sistema vengono
migrate come pagine vuote. E’ possibile eliminare queste pagine oppure
aggiungere un nuovo portlet di sviluppo alla pagina vuota.
Modelli di presentazione
I modelli di presentazione migrati possono contenere delle informazioni di
intestazione HTML aggiuntive non presenti nel modello di presentazione originale.
Le informazioni di intestazione aggiuntive non influenzeranno il contenuto di
rendering nel modello di presentazione e possono essere eliminate.
Rimozione dello strumento di migrazione
Per rimuovere lo strumento di migrazione, eseguire l’attività remove-wcm-migration
dalla directory root_server_portale/config del nuovo sistema.
v Windows: WPSconfig.bat remove-wcm-migration
v UNIX: ./WPSconfig.sh remove-wcm-migration
v i5/OS: WPSconfig.sh -profileName profile_root remove-wcm-migration dove
profile_root è il nome del profilo di WebSphere Application Server in cui è
installato WebSphere Portal. Ad esempio, wp_profile.
Migrazione della configurazione del processo business
Questa sezione fornisce informazioni su come correggere i problemi associati alla
selezione con il mouse di un’attività ed il conseguente accesso ad una pagina di
attività. Nota: questa sezione non è valida per iSeries.
1. In base alla versione di WebSphere Portal da cui è stata eseguita la migrazione,
si potrebbero verificare dei problemi quando gli utenti selezionano con il
mouse un’attività e dovrebbero accedere ad una pagina di attività. Se si verifica
questa condizione, eseguire le seguenti attività di configurazione per ogni
contenitore di pagine di attività creato nella configurazione del portale.
v disable-page-as-task-page-container
v enable-page-as-extension-node
Queste attività sono descritte in Modifica del contenitore di pagine attività.
Nota: Quest’attività richiede il nome univoco del contenitore di pagine di
attività. Il nome univoco per il contenitore di pagine di attività
predefinito, Attività personali, è com.ibm.wps.MyTasks.
2. Se le applicazioni portlet non contengono gli stub per le comunicazioni con il
gestore di attività dell’utente ed il gestore di flussi business (task137650.jar e
bpe137650.jar), associare la libreria BPElib all’applicazione.
a. Collegarsi alla console di gestione del server o del cluster del portal.
b. Aprire Applicazioni → Applicazioni Enterprise e ricercare l’EAR della
propria applicazione. Selezionarlo.
c. Fare clic su Librerie.
d. Fare clic su Aggiungi e selezionare BPElib dal menu a discesa.
e. Salvare le modifiche.
3. Se si è modificato qualche valore in ConfigService.properties o
DynamicUIManagerFactoryService.properties, apportare queste stesse modifiche
manualmente sulla configurazione.
61
4. Se si è utilizzata la funzione di avviso delle attività fornita dalla tag
<portal-dynamicui:pendingTasks/>, aggiungere la tag ai nuovi temi utilizzati
dalla configurazione del processo business.
Migrazione dei temi
I temi sviluppati su WebSphere Portal Versione 5.x sono compatibili con
WebSphere Portal Versione 6.0 e sono in grado di eseguire compilazioni e
rendering senza apportare modifiche alla codifica. Per poter funzionare
correttamente in WebSphere Portal Versione 6.0, i temi di WebSphere Portal
Versione 5.x devono essere applicati alle stesse pagine per le quali sono stati
progettati in WebSphere Portal Versione 5.x, utilizzando gli stessi skin creati per
essere utilizzati in quel tema.
Linee guida generali
Utilizzare le seguenti linee guida per migrare i temi da WebSphere Portal Versione
5.x aWebSphere Portal Versione 6.0:
v I temi di WebSphere Portal Versione 5.x migrati devono essere applicati alle
stesse pagine per le quali sono stati progettati in WebSphere Portal Versione 5.x.
v I temi di WebSphere Portal Versione 5.x erano identificati come temi ″di
gestione″ o ″non di gestione″. Il portlet Proprietà della pagina consentiva
l’assegnazione dei temi di gestione solo alle pagine di gestione e quelli non di
gestione alle pagine di tipo non gestionale. In WebSphere Portal Versione 6.0, i
temi sono progettati per funzionare su tutte le pagine, quindi questa limitazione
è stata eliminata. I temi migrati da WebSphere Portal Versione 5.x non venivano
codificati tenendo presente questo concetto, quindi è necessario forzare
manualmente l’assegnazione di quei temi alle pagine appropriate oppure
aggiornare il tema in modo da supportare la navigazione nelle pagine di livello
massimo.
v I temi devono essere utilizzati con gli stessi skin usati in WebSphere Portal
Versione 5.x. Alcuni skin di WebSphere Portal Versione 6.0 sfruttano le nuove
funzioni dei temi, ad esempio i menu contestuali, che non erano disponibili nei
temi di WebSphere Portal Versione 5.x. Per ulteriori informazioni consultare la
sezione ″Funzioni di WebSphere Portal Versione 6.0 nei temi migrati″ riportata di
seguito.
Le seguenti sezioni forniscono ulteriori informazioni sulla migrazione dei temi e
degli skin:
v “Aggiunta del supporto per la navigazione della pagina al livello massimo” a
pagina 63
v “Abilitazione della funzione Organizza preferiti nei temi” a pagina 63
v “Abilitazione della funzione di trascinamento negli skin migrati” a pagina 64
v “Correzione della visualizzazione dell’elenco a discesa Ambito di ricerca nei temi
migrati” a pagina 65
v “Funzioni di WebSphere Portal Versione 6.0 nei temi migrati” a pagina 66
v “Problemi noti relativi alla migrazione di temi” a pagina 66
v “Informazioni correlate” a pagina 66
62
Migrazione
Aggiunta del supporto per la navigazione della pagina al livello
massimo
In WebSphere Portal Versione 5.x i temi in genere iniziavano il rendering della
navigazione al livello 2 della struttura ad albero della navigazione. I nodi di livello
1 (Home e Gestione) venivano acceduti da un URL nel banner dei temi che
puntava esplicitamente a quella pagina.
Con i temi migrati questo metodo crea problemi quando si assegna il tema di
WebSphere Portal Versione 5.x ad una pagina a cui non era assegnato
nell’ambiente di portale di WebSphere Portal Versione 5.x. Per esempio, si
supponga di aver assegnato il tema Gestione di WebSphere Portal Versione 5.x alla
pagina ’Home’ in WebSphere Portal Versione 6.0. Poiché il tema Gestione di
WebSphere Portal Versione 5.x conteneva solo un collegamento a ’Home’ nella
barra degli strumenti, questo tema non fornisce alcun mezzo per andare a
Gestione. Utilizzare le seguenti linee guida per evitare questo problema:
v Aggiungere un NavigationLoop - Per aggiungere un NavigationLoop, fare
riferimento a Implementazione di un singolo livello di argomento di
navigazione.
v Nascondere alla navigazione le pagine non necessarie - In WebSphere Portal
Versione 6.0, le pagine di livello massimo che non si desidera vengano
visualizzate nella navigazione dei livello massimo possono essere nascoste
mediante un attributo di metadati della pagina. Il frammento di codice riportato
di seguito proviene da mainMenu.jsp nel tema di WebSphere Portal Versione 6.0
di IBM. Questo codice deve essere utilizzato all’interno di una tag
<portal-navigation:NavigationLoop>.
<%
boolean isNodeVisible = true; //default to display it
//page metadata value used on top level nodes to hide from main menu
if (wpsNavNode instanceof com.ibm.portal.MetaDataProvider) {
com.ibm.portal.MetaData iMetaData = ((com.ibm.portal.MetaDataProvider) wpsNavNode).getMetaData();
Object hiddenValue = iMetaData.getValue("com.ibm.portal.Hidden");
isNodeVisible = hiddenValue == null ? true: false;
%>
Per ulteriori dettagli su questo esempio di codice fare riferimento a mainMenu.jsp
nel tema IBM.
Abilitazione della funzione Organizza preferiti nei temi
La funzione ″Preferiti″ in WebSphere Portal consente di contrassegnare una pagina
nel portale in modo da potervi ritornare in un secondo momento. La pagina viene
aggiunta all’elenco ″Preferiti″ che viene gestito tramite la funzione Organizza
preferiti. Organizza preferiti, una pagina che contiene il portlet Organizza preferiti,
consente la creazione, la modifica, l’attivazione, l’ordinamento e l’eliminazione
delle etichette e degli URL contenuti nell’elenco Preferiti.
Quando si migrano dei temi precedenti alla Versione 6.0, viene migrata l’etichetta
necessaria per la funzionalità Organizza Preferiti.
Nella Versione 6.0, è possibile accedere alla funzionalità Organizza Preferiti tramite
del codice personalizzato creando il proprio tema personalizzato. Per ulteriori
informazioni su questa creazione fare riferimento all’argomento Creazione di un
proprio tema.
Per abilitare la funzionalità Organizza Preferiti in questo tema della Versione 6.0
tramite l’interfaccia di Gestione, attenersi alla seguente procedura:
63
v Fare clic su Gestione, Interfaccia utente del portale e Gestione pagine.
v Scegliere il titolo di pagina Root del contenuto per selezionare la pagina Root
del contenuto.
v Nella pagina Root del contenuto fare clic su Nuova etichetta.
v Creare un’etichetta denominata Preferiti.
v Assegnare l’accesso utente privilegiato a tutti gli utenti autenticati. Per ulteriori
informazioni, fare riferimento a Controllo accessi ed a “Migrazione della
configurazione del controllo accessi restante” a pagina 28
v Al termine fare clic su OK.
v Selezionare Impostazioni portale e Nomi personalizzati univoci.
v Assegnare wps.Preferiti come nome univoco all’etichetta Preferiti appena
creata.
v Al termine fare clic su OK.
v Fare clic su Gestione, Interfaccia utente del portale e Gestione pagine.
v Aggiungere una chiave di parametro pagina ″Preferiti″ con il valore ″Yes.″
Organizza preferiti viene considerato un nodo sotto il nodo Root del contenuto. I
nodi si trovano in un livello della gerarchia di navigazione relativo al nodo
principale in cui vengono creati. Il nodo di livello massimo nella struttura ad
albero è Root del contenuto.
Per impostazione predefinita, gli utenti senza privilegi di gestione possono
accedere solo ai nodi presenti sotto il nodo Home, che si trova sotto il nodo Root
del contenuto. Gli utenti con privilegi di amministratore possono utilizzare i
collegamenti nella barra degli strumenti per alternare Gestione e Home. Se
vengono creati altri nodi direttamente sotto Root del contenuto, non viene fatto
riferimento ai collegamenti per quei nodi, a meno che non vengano aggiunti in
modo specifico ad uno dei JSP del tema. Per ulteriori informazioni, fare riferimento
a Gestione della navigazione del portale.
Abilitazione della funzione di trascinamento negli skin migrati
La funzione di trascinamento consente di modificare rapidamente la posizione dei
singoli portlet utilizzando i propri skin. La funzione di trascinamento consente di
spostare un portlet personalizzato dalla posizione corrente, trascinandolo in
un’altra posizione sulla pagina. Ciò consente di modificare rapidamente la
disposizione dei portlet su una pagina.
Poiché si tratta di una nuova funzione per WebSphere Portal Versione 6.0, non è
possibile accedere direttamente alla funzione di trascinamento quando si utilizzano
skin migrati. Utilizzare la seguente procedura per abilitare la funzione di
trascinamento nei propri skin migrati:
1. Aggiungere il seguente codice quasi all’inizio di Control.jsp.
<%@ taglib uri="/WEB-INF/tld/dnd.tld" prefix="dnd" %>
<dnd:DNDPortletHelper/>
<%!
private static com.ibm.portal.identification.Identification identification;
public void jspInit(){
try{
/* Perform this JNDI lookup once as it hinders performance */
javax.naming.Context ctx = new javax.naming.InitialContext();
identification = (com.ibm.portal.identification.Identification) ctx.lookup( "portal:service/Identification" );
}
catch ( javax.naming.NamingException ne ){
64
Migrazione
// nothing is logged here because if Portal ever enters
// this catch statement then severe problems have
// occurred and will have already been logged by
// errors reported by the lookup.
}
}
%>
2. In Control.jsp, racchiudere nella tag ″drag″ la tabella contenente il contenitore
dello ″skin″ del portlet. Inoltre collocare una tag ″dragHandle″ alla barra del
titolo del portlet (ma non sui pulsanti della barra del titolo). Il seguente codice
fornisce un esempio:
<%-- Modification for Drag and Drop - need to pass the portlet control ID - Cannot use the tag because it is an attribute --%>
<%
String currentLayoutNodeStr = "";
if (pageContext.getAttribute("currentLayoutNode", pageContext.REQUEST_SCOPE) != null) {
LayoutNode currLayoutNode = (LayoutNode)pageContext.getAttribute("currentLayoutNode", pageContext.REQUEST_SCOPE);
currentLayoutNodeStr = identification.serialize(currLayoutNode.getObjectID());
}
else {
LayoutNode currLayoutNode=(LayoutNode)pageContext.getRequest().getAttribute("com.ibm.wps.composition.element");
currentLayoutNodeStr=identification.serialize(currLayoutNode.getObjectID());
}
%>
<dnd:drag namespace="wp" type="portlet_windowID" value="<%=currentLayoutNodeStr%>" includeDragHandle="false" validator="com.ibm.wps.dnd.impl.DNDDr
.......
.......
BEGIN SKIN MARKUP .......
BEGIN TITLE BAR .......
<dnd:dragHandle>TITLE BAR CONTENT</dnd:dragHandle>TITLEBAR BUTTONS
.......
END TITLE BAR
.......
.......
PORTLET RENDER .......
.......
END SKIN MARKUP .......
</dnd:drag>
3. Copiare UnlayeredContainer-H.jsp e UnlayeredContainer-V.jsp dallo skin
predefinito di WebSphere Portal Versione 6.0 nella directory del proprio skin. Se
è stato personalizzato uno di questi file, è necessario unire il/la codice/markup
delle versioni personalizzate dei file con la versione di skin predefinita dei file.
Correzione della visualizzazione dell’elenco a discesa Ambito di
ricerca nei temi migrati
WebSphere Portal Versione 6.0 aggiunge una nuova icona a sinistra della casella
Ricerca nei temi del portale. Selezionando questa icona viene visualizzato un
elenco a discesa di opzioni per la ricerca, incluso differenti ambiti di ricerca, le
preferenze della ricerca e la relativa guida.
Quando si migrano i temi antecedenti alla Versione 6.0 nella propria installazione
di WebSphere Portal Versione 6.0, si può notare che questo nuovo elenco a discesa
ha uno sfondo trasparente ed è difficile da leggere.
Per correggere questo problema nei temi migrati, aggiungere il codice di seguito
riportato ad uno dei file CSS del tema, dopo la sua migrazione. Questo codice può
essere aggiunto a qualsiasi CSS visualizzato con il tema.
.main-menu-item, .main-menu-item-selected {
background-color: #FFFFFF;
}
65
Con l’aggiunta di questo codice il tema avrà uno sfondo bianco semplice e di facile
lettura. È possibile, inoltre, personalizzare il codice in modo da adattarsi allo
schema di colori del proprio tema.
Funzioni di WebSphere Portal Versione 6.0 nei temi migrati
WebSphere Portal Versione 6.0 aggiunge nuove funzioni in questo tema, incluso le
tavolozze di portlet e di persone ed i menu contestuali. Queste funzioni non sono
disponibili in un tema migrato di WebSphere Portal Versione 5.x a meno che non
venga copiato il codice corrispondente dal tema diWebSphere Portal Versione 6.0.
Questo richiede all’utente lo sviluppo di un tema che identifica, copia e verifica la
funzione che si desidera aggiungere al tema di WebSphere Portal Versione 5.x.
Problemi noti relativi alla migrazione di temi
Alle pagine di WebSphere Portal Versione 6.0 fornite con il prodotto è assegnato
l’utilizzo del tema predefinito. Ciò serve a semplificare la modifica di WebSphere
Portal assegnando un nuovo tema come tema predefinito. Le eccezioni sono le
pagine di gestione cui è esplicitamente assegnato il tema ″IBM″ predefinito. Questo
serve ad evitare un errato funzionamento delle pagine di gestione se viene
inavvertitamente applicato come tema predefinito un tema non funzionale.
Questo problema si verifica anche nella migrazione di temi da WebSphere Portal
Versione 6.0. Durante la migrazione, l’assegnazione del tema predefinito viene
portata all’installazione di WebSphere Portal Versione 6.0. Questo applica il tema
predefinito dal rilascio di WebSphere Portal precedente alle pagine di WebSphere
Portal Versione 6.0 fornite con il prodotto.
Se si verificano dei problemi con le pagine fornite con il nuovo prodotto dopo la
migrazione, assegnare il tema IBM alla pagina. Se la pagina funziona correttamente
con il tema IBM e non con il tema migrato, ci potrebbero essere delle
incompatibilità funzionali tra la markup nel tema migrato ed il contenuto dei
portlet.
E’ anche possibile che i portlet su queste pagine dipendano dalla nuova
funzionalità in WebSphere Portal Versione 6.0 che non esisteva nella versione
precedente. In questo caso, potrebbe essere necessario copiare i file dal tema IBM al
tema migrato. Fare riferimento ai file di log del portale per informazioni sugli
eventuali file mancanti.
v
v
v
v
v
v
v
v
v
v
v
v
66
Migrazione
Creazione di un proprio tema
Layout della pagina del portale
Personalizzazione del portale
Gestione temporanea del portale fino alla produzione
Creazione di collegamenti personalizzati a portlet e pagine
Distribuzione di temi e skin personalizzati
Tag utilizzate dai file JSP del portale
Tag WML utilizzate dai file JSP del portale
Risoluzione dei problemi relativi alla progettazione del portale
Gestione di pagine, layout e contenuto
Struttura del portale
Gestione pagine
v Personalizzazione di pagine
v Controllo accessi
v “Migrazione della configurazione del controllo accessi restante” a pagina 28
Verifica delle attività di migrazione
Questa sezione fornisce le informazioni da utilizzare per verificare l’esito delle
attività di migrazione.
Eseguire le
1. Verifica
2. Verifica
3. Verifica
4. Verifica
5. Verifica
6.
7.
8.
9.
1.
attività appropriate per verificare l’esito della migrazione:
della migrazione dei portlet Notes e Domino Web Access (iNotes)
della migrazione dei client del portale
della migrazione delle personalizzazioni dell’utente
della migrazione dei dati della protezione credenziali
della migrazione dei temi e degli skin
Verifica della migrazione delle applicazioni portlet
Verifica della migrazione dei dati di configurazione dei portlet
Verifica della migrazione delle risorse virtuali
Verifica della migrazione delle pagine
Verifica della migrazione dei portlet Notes e Domino Web Access (iNotes)
a. Accedere all’interfaccia di gestione di WebSphere Portal corrente.
b. Fare clic su Gestione portlet > Portlet.
c. Nell’elenco dovrebbero essere riportati tutti i portlet che esistevano nella
versione precedentemente installata.
Nota: in alcune delle versioni precedenti di WebSphere Portal, questi erano
portlet individuali, mentre nella versione corrente sono copie di un
unico portlet.
d. Selezionare ciascuno dei portlet migrati, fare clic su Configura portlet, e
verificare che le impostazioni del portlet siano state migrate correttamente.
Se si migrano pagine che contengono portlet Notes, i portlet dovrebbero
essere presenti nella pagina dopo la migrazione e dovrebbero avere un
funzionamento analogo a quello della versione precedente.
2. Verifica della migrazione dei client del portale
b. Fare clic su Gestione > Impostazioni portale > Client supportati.
c. Verificare che i client del portale migrati siano mostrati nell’elenco dei client
supportati.
d. Selezionare i client migrati e fare clic su Modifica client selezionato per
verificare che tutte le impostazioni per il client siano state migrate.
e. Verificare che i client migrati possano accedere a WebSphere Portal.
3. Verifica della migrazione delle personalizzazioni dell’utente
Le personalizzazioni utente sono risorse che sono attribuite ad un utente del
portale che dispone delle autorizzazioni di Modifica e Gestione per una pagina.
Queste sono create quando un utente modifica il layout di una pagina e
modifica le impostazioni del portlet.
a. Accedere al WebSphere Portal corrente con le credenziali degli utenti che
dispongono di personalizzazioni.
67
b. Verificare che tutte le personalizzazioni utente della versione precedente
siano presenti nella versione corrente. È possibile scegliere degli utenti a
caso e verificare che le personalizzazioni visualizzate nella versione corrente
siano quelle corrette, confrontandole visivamente con quelle della versione
precedente.
4. Verifica della migrazione di segmenti e slot di protezione credenziali
Questa procedura consente di verificare che slot e segmenti di credenziali siano
stati migrati correttamente. I dati di protezione credenziali esistenti devono
essere migrati con una procedura manuale separata descritta nella sezione
“Migrazione della configurazione del controllo accessi restante” a pagina 28.
b. Fare clic su Accesso e poi su Protezione credenziali nel riquadro a sinistra.
c. Utilizzando le opzioni Gestione segmenti di protezione e Gestione slot di
protezione del sistema, verificare che segmenti e slot delle credenziali della
versione precedente siano ora presenti anche nella versione corrente.
5. Verifica della migrazione dei temi e degli skin
b. Fare clic su Interfaccia utente del portale > Temi e skin nel riquadro a
sinistra.
c. Verificare che i temi e gli skin elencati siano quelli migrati dalla versione
precedente a quella corrente.
d. Verificare che sia possibile associare alle pagine e ai portlet esistenti i temi e
gli skin migrati e verificare che producano la visualizzazione desiderata.
6. Verifica della migrazione delle applicazioni portlet
b. Fare clic su Gestione portlet > Applicazioni nel riquadro a sinistra.
c. Verificare che le applicazioni portlet elencate siano quelle migrate dalla
d. Per ciascun Modulo Web, verificare che tutte le applicazioni portlet siano
visualizzate anche nell’elenco Applicazioni portlet.
e. Per ogni applicazione portlet migrata (e per la quale sono stati configurati i
parametri sulla versione precedente), fare clic su Modifica applicazione
portlet accanto all’elenco di applicazioni portlet e verificare che i parametri
siano migrati correttamente.
È necessario anche verificare il controllo accessi per l’applicazione portlet e i
portlet migrati utilizzando l’interfaccia di gestione.
a. Fare clic su Accesso > Autorizzazioni risorsa e selezionare Applicazioni
portlet da Tipi di risorsa.
b. Fare clic su Assegna accesso per verificare le informazioni di controllo
accessi.
c. Fare clic su Accesso > Autorizzazioni risorsa e selezionare Portlet da Tipi
di risorsa.
d. Fare clic su Assegna accesso per verificare le informazioni di controllo
accessi.
È possibile eseguire anche un’esportazione completa di WebSphere Portal della
versione corrente dopo il completamento della migrazione e verificare i ruoli
nel file XML esportato. Per ulteriori informazioni, fare riferimento a Interfaccia
di configurazione XML.
7. Verifica della migrazione dei dati di configurazione dei portlet
68
Migrazione
b. Fare clic su Gestione portlet > Portlet nel riquadro a sinistra.
c. Verificare che tutti i dati di configurazione dei portlet migrati dalla versione
precedente siano presenti nella versione corrente selezionando il portlet
dall’elenco e facendo clic su Configura portlet.
8. Verifica della migrazione delle risorse virtuali
b. Fare clic su Accesso > Autorizzazioni risorsa nel riquadro a sinistra.
c. Selezionare Risorse virtuali da Tipi di risorsa.
d. Verificare che tutte le risorse virtuali migrate dalla versione precedente
siano presenti nella versione corrente.
9. Verifica della migrazione delle pagine
Se vengono visualizzate solo le pagine di benvenuto e di introduzione,
consultare Problema: dopo la migrazione, sono disponibili solo le pagine di
benvenuto e di introduzione per informazioni; altrimenti, la migrazione delle
pagine è stata eseguita correttamente.
69
70
Migrazione
Capitolo 2. Informazioni particolari e marchi
(c) Copyright IBM Corporation 2000, 2006.
Limitazioni per gli utenti appartenenti al Governo degli Stati Uniti d’America L’utilizzo, la duplicazione o la divulgazione sono limitati dal GSA ADP Schedule
Contract con l’IBM Corp.
Queste informazioni sono state sviluppate per prodotti e servizi offerti negli Stati
Uniti. E’ possibile che negli altri paesi l’IBM non offra i prodotti, i servizi o le
funzioni illustrati in questo documento. Consultare il rappresentante locale IBM
per informazioni sui prodotti e sui servizi disponibili attualmente nel proprio
paese. Qualunque riferimento relativo a prodotti, programmi o servizi IBM non
implica che solo quei prodotti, programmi o servizi IBM possano essere utilizzati.
In sostituzione a quelli forniti dall’IBM, possono essere utilizzati prodotti,
programmi o servizi funzionalmente equivalenti che non comportino la violazione
dei diritti di proprietà intellettuale o di altri diritti dell’IBM. E’ comunque
responsabilità dell’utente valutare e verificare la possibilità di utilizzare altri
programmi e/o prodotti, fatta eccezione per quelli espressamente indicati dall’IBM.
L’IBM può avere brevetti o domande di brevetto in corso relativi a quanto trattato
nella presente pubblicazione. La fornitura di questa pubblicazione non implica la
concessione di alcuna licenza su di essi. Chi desiderasse ricevere informazioni
relative alle licenze può rivolgersi per iscritto a:
IBM Director of Commercial Relations
IBM Europe
North Castle Drive
D-7030 Boeblingen
U.S.A.
Per le domande sulla licenza relative a informazioni double-byte (DBCS), rivolgersi
al dipartimento della proprietà intellettuale IBM del proprio paese oppure inviare
le domande a:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
Il seguente paragrafo non è valido per il Regno Unito o per tutti i paesi le cui
leggi nazionali siano in contrasto con le disposizioni in esso contenute:
L’INTERNATIONAL BUSINESS MACHINES CORPORATION FORNISCE
QUESTA PUBBLICAZIONE NELLO STATO IN CUI SI TROVA, SENZA ALCUNA
GARANZIA, ESPLICITA O IMPLICITA, IVI INCLUSE EVENTUALI GARANZIE
DI COMMERCIABILITA’ ED IDONEITA’ AD UNO SCOPO PARTICOLARE.
Alcuni stati non consentono la rinuncia a garanzie esplicite o implicite in
determinate transazioni, pertanto la presente dichiarazione potrebbe non essere a
voi applicabile.
Queste informazioni potrebbero contenere imprecisioni tecniche o errori ortografici.
Le informazioni incluse in questo documento vengono modificate su base
periodica; tali modifiche verranno incorporate nelle nuove edizioni della
71
pubblicazione. L’IBM si riserva il diritto di apportare miglioramenti e/o modifiche
al prodotto o al programma descritto nel manuale in qualsiasi momento e senza
preavviso.
Tutti i riferimenti a siti Web non dell’IBM sono forniti unicamente a scopo di
consultazione. I materiali disponibili sui siti Web non fanno parte di questo
prodotto IBM e l’utilizzo di questi è a discrezione dell’utente. Coloro che
detengono la licenza su questo programma e desiderano avere informazioni su di
esso allo scopo di consentire (i) uno scambio di informazioni tra programmi
indipendenti ed altri (compreso questo) e (ii) l’uso reciproco di tali informazioni,
dovrebbero rivolgersi a:
Vice President
Intellectual Property & Licensing
North Castle Drive
Armonk, New York 10504
U.S.A.
Queste informazioni possono essere rese disponibili, secondo condizioni
contrattuali appropriate, compreso in alcuni casi, il pagamento di un addebito.
Il programma su licenza descritto in questa documentazione e tutto il relativo
materiale su licenza disponibile, sono forniti dall’IBM nel rispetto dei termini
dell’IBM Customer Agreement, dell’IBM International Program License Agreement
o di qualsiasi altro accordo equivalente fra le parti.
Tutti i dati relativi alle prestazioni contenuti in questa pubblicazione sono stati
determinati in ambiente controllato. Pertanto, i risultati ottenuti in altri ambienti
operativi possono variare in modo considerevole. Alcune misurazioni possono
essere state effettuate su sistemi a livello di sviluppo e non vi è alcuna garanzia
che tali misurazioni restino invariate sui sistemi generalmente disponibili. Inoltre,
alcune misurazioni potrebbero essere state stimate tramite estrapolazione. I risultati
reali potrebbero variare. Gli utenti di questa documentazione devono verificare che
i dati siano applicabili al loro specifico ambiente.
Le informazioni relative a prodotti non IBM sono state ottenute dai fornitori di tali
prodotti. L’IBM non ha verificato tali prodotti e pertanto non può garantirne
l’accuratezza delle prestazioni, la compatibilità o qualsiasi altro reclamo relativo ai
prodotti non IBM. Eventuali commenti relativi alle prestazioni dei prodotti non
IBM devono essere indirizzati ai fornitori di tali prodotti.
Tutte le dichiarazioni relative all’orientamento o alle intenzioni future dell’IBM
sono soggette a modifica o a ritiro senza preavviso e rappresentano solo mete e
obiettivi. Queste informazioni contengono esempi di dati e prospetti utilizzati
quotidianamente nelle operazioni aziendali. Per meglio illustrarli, tali esempi
possono contenere nomi di persone, società, marchi e prodotti. Tutti i nomi
contenuti nel manuale sono fittizi ed ogni riferimento a nomi ed indirizzi reali è
puramente casuale.
Marchi e marchi di servizio
I seguenti termini sono marchi registrati negli Stati Uniti e/o in altri paesi:
72
Migrazione
AIX, DB2, IBM, il logo IBM, iSeries, i5/OS, OS/390, OS/400, RS/6000, RACF,
Tivoli, WebSphere, e z/OS sono marchi dell’IBM Corporation negli Stati Uniti e/o
in altri paesi.
Lotus, Notes, Domino, QuickPlace, Sametime, Lotus Discovery Server sono marchi
dell’IBM Corporation e/o della Lotus Development Corporation negli Stati Uniti
e/o in altri paesi.
Solaris, Java e tutti i marchi e i logo basati su Java sono marchi della Sun
Microsystems, Inc. negli Stati Uniti e/o in altri paesi.
Microsoft, Windows, Windows NT ed il logo Windows sono marchi della Microsoft
Corporation negli Stati Uniti e/o in altri paesi.
Linux è un marchio di Torvalds negli Stati Uniti e/o in altri paesi.
Intel, Intel Inside (logo), MMX e Pentium sono marchi della Intel Corporation negli
Stati Uniti e/o in altri paesi.
Altri nomi di società, prodotti e servizi possono essere marchi o servizi di altre
società.
Per ulteriori marchi, consultare il sito www.ibm.com/legal/copytrade.html.
Capitolo 2. Informazioni particolari e marchi
73
74
Migrazione
Riservato ai commenti del lettore
Portal
Migrazione
Versione 6.0
Commenti relativi alla pubblicazione in oggetto potranno contribuire a migliorarla. Sono graditi commenti
pertinenti alle informazioni contenute in questo manuale ed al modo in cui esse sono presentate. Si invita il lettore
ad usare lo spazio sottostante citando, ove possibile, i riferimenti alla pagina ed al paragrafo.
Si prega di non utilizzare questo foglio per richiedere informazioni tecniche su sistemi, programmi o pubblicazioni
e/o per richiedere informazioni di carattere generale.
Per tali esigenze si consiglia di rivolgersi al punto di vendita autorizzato o alla filiale IBM della propria zona
oppure di chiamare il ″Supporto Clienti″ IBM al numero verde 800-017001.
I suggerimenti ed i commenti inviati potranno essere usati liberamente dall’IBM e dalla Sistemi Informativi e
diventeranno proprietà esclusiva delle stesse.
Commenti:
Si ringrazia per la collaborazione.
Per inviare i commenti è possibile utilizzare uno dei seguenti modi.
v Spedire questo modulo all’indirizzo indicato sul retro.
v Inviare un fax al numero: +39-06-5126991
v Spedire una nota via email a: [email protected]
Se è gradita una risposta dalla Sistemi Informativi, si prega di fornire le informazioni che seguono:
Nome
Indirizzo
Società
Numero di telefono
Indirizzo e-mail
Indicandoci i Suoi dati, Lei avrà l’opportunità di ottenere dal responsabile del Servizio di Translation Assurance della Sistemi Informativi S.p.A. le
risposte ai quesiti o alle richieste di informazioni che vorrà sottoporci. I Suoi dati saranno trattati nel rispetto di quanto stabilito dalla legge 31
dicembre 1996, n.675 sulla “Tutela delle persone e di altri soggetti rispetto al trattamento di dati personali”. I Suoi dati non saranno oggetto di
comunicazione o di diffusione a terzi; essi saranno utilizzati “una tantum” e saranno conservati per il tempo strettamente necessario al loro
utilizzo.
Riservato ai commenti del lettore
Sistemi Informativi S.p.A.
Translation Assurance
Via delle Sette Chiese, 142
00145 - Roma
򔻐򗗠򙳰

Migrazione

Transcript

Documenti analoghi

IN04 - Software gratis e open source in alternativa a Microsoft Office

JP Racing - B3 Off Road Engine

"Roma città...Open" Soluzioni di Office Automation, Collaboration ed

Collaboration Desktop - PM Technology Consulting

SERVIZI DI MIGRAZIONE E INSTALLAZIONE CLIENT DELL

⓪①②③④⑤⑥⑦⑧⑨⑩ ⓪①②③④⑤⑥⑦⑧⑨⑩

Kyosho - New MP9 Brushless conversion kit (IFW451)

La musica d`autore (e di pace) di Noa arriva a Mestre

Relazione del Prof. Livi Bacci

Scarica la guida rapida per l`invio della candidatura