Aggiornamento manuale sul posto a 9.0.x, 9.1.x e 9.2.x: Linux

1. Se il sistema operativo in uso è RHEL, verificare di avere effettuato l'aggiornamento alla versione supportata prima di eseguire un aggiornamento di ThingWorx. Per ulteriori informazioni, fare riferimento ai Requisiti di sistema.

ThingWorx 9.1 è supportato solo in RHEL 8.2.

2. Prima di iniziare l'aggiornamento, si consiglia di effettuare le operazioni seguenti.

◦ Registrare il database.

◦ Eseguire il backup di tutti i dati nelle cartelle ThingworxStorage e ThingworxPlatform.

◦ Eseguire il backup della cartella Tomcat_home. Sono incluse le cartelle bin, conf, lib, temp, webapps e work.

3. Se si utilizza ThingWorx Apps oltre alla piattaforma ThingWorx:

a. Verificare che la versione di ThingWorx che si sta aggiornando sia supportata con la versione di ThingWorx Apps. Vedere Matrice di supporto per l'aggiornamento di ThingWorx Apps.

b. Prima di aggiornare la piattaforma, è necessario eseguire alcuni passi. Prima di andare al passo successivo, vedere Upgrade di ThingWorx Apps.

4. Se è installato anche Navigate, verificare la compatibilità alla pagina ThingWorx Navigate Compatibility Matrix.

5. Ottenere la versione più recente di ThingWorx da PTC Software Download.

Scaricare ed estrarre il contenuto di ThingWorx in una cartella in cui l'utente corrente dispone dei permessi di scrittura. I permessi di scrittura sono necessari perché gli script di aggiornamento creano alcuni file durante il processo.

6. Verificare che siano in esecuzione le versioni richieste di Tomcat e Java. Per i requisiti della versione, fare riferimento ai Requisiti di sistema.

Se è necessario aggiornare la versione di Java, eseguire l'aggiornamento di ThingWorx prima di aggiornare Java.

7. Se si effettua l'aggiornamento di MSSQL, Azure SQL o H2 e nelle tabelle dati mancano i valori dei campi di indice personalizzati, l'aggiornamento non riesce. Verificare che siano presenti valori in tutti i campi di indice personalizzati prima di avviare il processo di aggiornamento.

In caso contrario, l'aggiornamento non riesce e sarà necessario distribuire nuovamente la versione precedente (se sono stati apportati aggiornamenti allo schema, è necessario eseguire il rollback del database o ripristinarlo) e aggiungere i valori di indice mancanti o rimuovere gli indici personalizzati dalla tabella dati prima di eseguire l'aggiornamento.

8. Aggiungere quanto segue a Java Options in Apache Tomcat:

-Dlog4j2.formatMsgNoLookups=true

I passi di questa sezione sono necessari solo se si esegue l'aggiornamento di ThingWorx con InfluxDB 1.7.x (per ThingWorx 8.5.x o 9.0.x) a InfluxDB 1.8.x (per ThingWorx 9.1.x o 9.2.x).

1. Esportare i dati da InfluxDB 1.7.x/MS SQL/PostgreSQL:

a. Accedere a ThingWorx come amministratore.

b. Fare clic su Importazione/Esportazione > Esportazione.

c. Utilizzare le opzioni riportate di seguito.

▪ Per Opzione di esportazione selezionare In file.

▪ Per Tipo di esportazione selezionare Raccolta di dati.

▪ Per Raccolta selezionare Stream.

▪ Fare clic su Esporta.

d. Ripetere i passi a-c per i dati stream di valori.

e. Spostare la cartella esportata per i dati stream e stream di valori creati dal repository di sistema in una posizione sicura come backup.

1. Arrestare Tomcat.

2. Prima di continuare, è consigliabile eseguire il backup delle due cartelle seguenti:

◦ Apache Software Foundation/Tomcat x.x/webapps/Thingworx

◦ /ThingworxStorage

3. Se la versione corrente di Tomcat è precedente e non è supportata con la versione di ThingWorx di destinazione, eseguire l'aggiornamento alla versione di Tomcat supportata.

4. Per mantenere le configurazioni SSO dall'installazione esistente, eseguire il backup del file web.xml dalla cartella <directory di installazione Tomcat>\webapps\Thingworx\WEB-INF.

5. Eseguire il backup ed eliminare il file validation. properties dalla directory /ThingworxStorage/esapi.

Il file validation.properties viene creato all'avvio di ThingWorx. Se si desidera mantenere le modifiche apportate, salvare il file all'esterno della directory ThingworxStorage, quindi procedere con la rimozione della directory esapi. All'avvio ThingWorx ricrea il file. È possibile aggiungere le espressioni regolari personalizzate di nuovo nel file validation.properties generato automaticamente.

Per ulteriori informazioni, fare riferimento a questo argomento.

6. Nel percorso di installazione di Tomcat \Apache Software Foundation\Tomcat x.x\webapps ed eliminare il file Thingworx.war e la cartella Thingworx.

Ignorare questo passo se si esegue l'aggiornamento su H2. Per tutti gli altri database, aggiungere il seguente parametro alle opzioni Java Tomcat per impostare il fuso orario del server ThingWorx:

-Duser.timezone=UTC

Solo il passo 1 di questa sezione è richiesto per tutti gli aggiornamenti.

Se si esegue l'aggiornamento da ThingWorx 8.4.x o 8.5.x --> 9.0.x, 9.1.x o 9.2.x, attenersi alla procedura descritta nella parte rimanente della sezione.

Ignorare i passi nella parte rimanente della sezione se si esegue l'aggiornamento da ThingWorx 9.0.x o 9.1.x --> 9.1.x o 9.2.x

1. Eseguire gli script seguenti, che si trovano nella cartella update del download del software ThingWorx (a partire dalla versione che si sta aggiornando):

thingworxPostgresSchemaUpdate8.4-to-8.5.sh

thingworxPostgresSchemaUpdate8.5-to-9.0.sh

thingworxPostgresSchemaUpdate9.1-to-9.2.sh

Non è necessario eseguire lo script thingworxPostgresSchemaUpdate9.0-to-9.1.sh poiché nella versione 9.1 non sono presenti aggiornamenti dello schema. Anche se per completezza lo script è incluso nella cartella update, è vuoto ed è destinato solo agli utenti con processi di aggiornamento automatizzati.

I passi della parte rimanente di questa sezione devono essere eseguiti solo se si esegue l'aggiornamento da ThingWorx 8.4.x o 8.5.x a 9.0.x, 9.1.x o 9.2.x. Devono invece essere ignorati se si esegue l'aggiornamento da ThingWorx 9.0.x a 9.1.x o 9.2.x.

2. Eseguire lo script di configurazione big integer/timezone per preparare il database per la migrazione:

Se si sta già eseguendo ThingWorx in UTC, è comunque necessario effettuare la migrazione per le modifiche dello script big integer, ma è possibile fornire il valore di UTC a entrambi i parametri sourceTZ e targetTZ (disponibili in alcuni script nei passi di seguito).

thingworxPostgresDBSetupBigIntTimezoneDataUpdate.sh

3. Per trovare tutti i fusi orari supportati, usare il comando seguente:

select pg_timezone_names()

Quando si specificano i fusi orari per gli script di migrazione dei dati riportati di seguito, i nomi di fuso orario specificati devono corrispondere esattamente a uno dei nomi formali visualizzati dallo script pg_timezone_names().

4. Eseguire lo script di migrazione del modello per migrare tutti i dati modello:

Prima di eseguire lo script, aprirlo in un editor di testo per verificare che i relativi valori di ambiente di default (ad esempio server, porta, fusi orari e così via) siano corretti e sufficienti per il proprio ambiente. Se all'interno dello script sono definiti valori di default che non sembrano adatti al proprio ambiente, sostituire tali valori quando si esegue lo script specificando uno o più argomenti della riga di comando.

thingworxPostgresModelTablesDataUpdate.sh

Sintassi:

thingworxPostgresModelTablesDataUpdate.sh [-h <server>] [-p <port>] [-d <Thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>]

Esempio:

thingworxPostgresModelTablesDataUpdate.sh -sourceTZ US/Eastern -targetTZ Etc/UTC

5. Eseguire ciascuno degli script di migrazione dello schema riportati di seguito per creare tabelle di backup di tutti i dati della tabella dati, stream e stream di valori.

Per motivi di prestazioni, questi script non creano di fatto una copia dei dati originali in queste tabelle, bensì rinominano le tabelle esistenti da "<nome-originale-tabella>" a "<nome-originale-tabella>_backup". In questo modo si elude il processo di copia dei dati, che potrebbe richiedere molto tempo. Una volta rinominate le tabelle esistenti, in modo da farle diventare tabelle di backup, vengono create nuove tabelle con i nomi originali. Le nuove tabelle sono vuote e, avendo lo stesso nome di quelle originali, servono allo stesso scopo. Verranno popolate nei passi successivi con i dati migrati.

thingworxPostgresDataTableSchemaUpdate.sh

thingworxPostgresStreamSchemaUpdate.sh

thingworxPostgresValueStreamSchemaUpdate.sh

6. Aprire una nuova finestra del prompt dei comandi ed eseguire lo script di migrazione dei dati seguente per migrare i dati della tabella dati all'interno della tabella di backup:

Prima di eseguire lo script, aprirlo in un editor di testo per verificare che i relativi valori di ambiente di default (ad esempio server, porta, fusi orari e così via) siano corretti e sufficienti per il proprio ambiente. Se all'interno dello script sono definiti valori di default che non sembrano adatti al proprio ambiente, sostituire tali valori quando si esegue lo script specificando uno o più argomenti della riga di comando.

thingworxPostgresDataTableDataUpdate.sh

Sintassi:

thingworxPostgresDataTableDataUpdate.sh [-h <server>] [-p <port>] [-d <thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>] [-chunkSize <chunk size>]

Esempio:

thingworxPostgresDataTablesDataUpdate.sh -sourceTZ US/Eastern -targetTZ Etc/UTC

Una volta avviato lo script di migrazione, attendere finché nella console non viene visualizzato un messaggio che indica che è possibile riavviare Tomcat. Quando viene visualizzato il messaggio, si può procedere al passo successivo, anche se l'esecuzione dello script di migrazione non è ancora terminata.

7. Aprire una nuova finestra del prompt dei comandi ed eseguire gli script di migrazione dei dati seguenti per migrare i dati stream e stream di valori dalle tabelle di backup:

Prima di eseguire lo script, aprirlo in un editor di testo per verificare che i relativi valori di ambiente di default (ad esempio server, porta, fusi orari e così via) siano corretti e sufficienti per il proprio ambiente. Se all'interno dello script sono definiti valori di default che non sembrano adatti al proprio ambiente, sostituire tali valori quando si esegue lo script specificando uno o più argomenti della riga di comando.

thingworxPostgresStreamDataUpdate.sh

thingworxPostgresValueStreamDataUpdate.sh

Sintassi:

thingworxPostgresStreamDataUpdate.sh [-h <server>] [-p <port>] [-d <thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>] [-chunkSize <chunk size>]

thingworxPostgresValueStreamDataUpdate.sh [-h <server>] [-p <port>] [-d <thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>] [-chunkSize <chunk size>]

Esempi:

thingworxPostgresStreamDataUpdate.sh -sourceTz US/Eastern -targetTZ Etc/UTC -chunkSize 5000

thingworxPostgresValueStreamDataUpdate.sh -sourceTz US/Eastern -targetTZ Etc/UTC -chunkSize 5000

Una volta avviati i due script di migrazione, non procedere con il passo successivo finché non sono stati completati questi due script e quello di migrazione della tabella dati (avviato in un passo precedente).

8. Verificare manualmente che siano stati completati tutti gli script seguenti: thingworxPostgresDataTableDataUpdate.sh, thingworxPostgresStreamDataUpdate.sh e thingworxPostgresValueStreamDataUpdate.sh. Verificare che sia stata completata la migrazione di tutti i dati della tabella dati, stream e stream di valori.

9. Eseguire lo script di pulizia per rimuovere tutti gli oggetti di database temporanei necessari durante la migrazione.

Sebbene esegua alcune operazioni di pulizia degli oggetti di database temporanei creati durante il processo di aggiornamento, questo script *non* elimina le tabelle di backup create nei passi precedenti, né modifica i dati all'interno di tali tabelle di backup. Ciò è intenzionale e impedisce che i dati vengano eliminati accidentalmente. Se si desidera eliminare queste tabelle di backup, è necessario procedere manualmente.

thingworxPostgresDBCleanupBigIntTimezoneDataUpdate.sh

Risoluzione dei problemi relativi agli script

È necessario eseguire i comandi riportati di seguito nel database ThingWorx.

• Il codice di errore 23505 indica che all'inserimento si è verificata una violazione del vincolo univoco della chiave duplicata. Per risolvere questo problema, attenersi alla procedura riportata di seguito.

a. Eseguire il comando seguente:

Select * from migration_log where status = -1 OR status = 0.

b. Registrare gli intervalli per fromId e toId per le righe restituite.

c. Interrogare la tabella dati per gli entry_ids scritti dal log di migrazione.

d. Se i record sono tutti presenti, per uno qualsiasi di questi intervalli impostare 0 o -1 su 1. Se da un intervallo mancano parzialmente i record, usare una dimensione del blocco più piccola o eliminare i record già sottoposti a migrazione nella tabella e provare a eseguire di nuovo la migrazione.

• Per trovare tutti i fusi orari supportati, usare il comando seguente:

select pg_timezone_names()

È necessario utilizzare il nome formale, elencato per primo, in modo che PostgreSQL risolva automaticamente l'offset rispetto al quale spostare la data, in base alla data e all'ora specificate.

• Per verificare che entry_ids vengano tutti sottoposti a migrazione, utilizzare un'interrogazione SQL simile alla seguente:

SELECT entry_id FROM data_table_backup EXCEPT SELECT entry_id FROM data_table

SELECT entry_id FROM data_table EXCEPT SELECT entry_id FROM data_table_backup

• Se nel sistema è in uso la variabile di ambiente PGPASSWORD, è necessario trasmettere questa variabile nel parametro -r per impostare la password con cui devono essere eseguiti gli script.

Solo il passo 1 di questa sezione è richiesto per tutti gli aggiornamenti.

Se si esegue l'aggiornamento da ThingWorx 8.4.x o 8.5.x --> 9.0.x, 9.1.x o 9.2.x, attenersi alla procedura descritta nella parte rimanente della sezione.

Ignorare i passi nella parte rimanente della sezione se si esegue l'aggiornamento da ThingWorx 9.0.x o 9.1.x --> 9.1.x o 9.2.x

1. Copiare l'intera cartella update, che si trova nel download del software ThingWorx, nel server MS SQL ed eseguire gli script seguenti, che si trovano nella cartella update (a partire dalla versione che si sta aggiornando):

thingworxMssqlSchemaUpdate8.4-to-8.5.sh

thingworxMssqlSchemaUpdate8.5-to-9.0.sh

thingworxMssqlSchemaUpdate9.1-to-9.2.sh

Non è necessario eseguire lo script thingworxMssqlSchemaUpdate9.0-to-9.1.sh poiché nella versione 9.1 non sono state apportate modifiche allo schema. Anche se per completezza lo script è incluso nella cartella update, è vuoto ed è destinato solo agli utenti con processi di aggiornamento automatizzati.

I passi della parte rimanente di questa sezione devono essere eseguiti solo se si esegue l'aggiornamento da ThingWorx 8.4.x o 8.5.x a 9.0.x, 9.1.x o 9.2.x. Devono invece essere ignorati se si esegue l'aggiornamento da ThingWorx 9.0.x a 9.1.x o 9.2.x.

2. Eseguire lo script di configurazione big integer/timezone per preparare il database per la migrazione:

Se si sta già eseguendo ThingWorx in UTC, è comunque necessario effettuare la migrazione per le modifiche dello script big integer, ma è possibile fornire il valore di UTC a entrambi i parametri sourceTZ e targetTZ (disponibili in alcuni script nei passi di seguito).

thingworxMssqlDBSetupBigIntTimezoneDataUpdate.sh

3. Eseguire lo script di migrazione del modello per migrare tutti i dati modello:

Prima di eseguire lo script, aprirlo in un editor di testo per verificare che i relativi valori di ambiente di default (ad esempio server, porta, fusi orari e così via) siano corretti e sufficienti per il proprio ambiente. Se all'interno dello script sono definiti valori di default che non sembrano adatti al proprio ambiente, sostituire tali valori quando si esegue lo script specificando uno o più argomenti della riga di comando.

thingworxMssqlModelTablesDataUpdate.sh

Sintassi:

thingworxMssqlModelTablesDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>]

Esempio:

thingworxMssqlModelTablesDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC

4. Eseguire ciascuno degli script di migrazione dello schema riportati di seguito per creare tabelle di backup di tutti i dati della tabella dati, stream e stream di valori.

Per motivi di prestazioni, questi script non creano di fatto una copia dei dati originali in queste tabelle, bensì rinominano le tabelle esistenti da "<nome-originale-tabella>" a "<nome-originale-tabella>_backup". In questo modo si elude il processo di copia dei dati, che potrebbe richiedere molto tempo. Una volta rinominate le tabelle esistenti, in modo da farle diventare tabelle di backup, vengono create nuove tabelle con i nomi originali. Le nuove tabelle sono vuote e, avendo lo stesso nome di quelle originali, servono allo stesso scopo. Verranno popolate nei passi successivi con i dati migrati.

thingworxMssqlDataTableSchemaUpdate.sh

thingworxMssqlStreamSchemaUpdate.sh

thingworxMssqlValueStreamSchemaUpdate.sh

5. Aprire una nuova finestra del prompt dei comandi ed eseguire lo script di migrazione dei dati seguente per migrare i dati della tabella dati all'interno della tabella di backup:

Prima di eseguire lo script, aprirlo in un editor di testo per verificare che i relativi valori di ambiente di default (ad esempio server, porta, fusi orari e così via) siano corretti e sufficienti per il proprio ambiente. Se all'interno dello script sono definiti valori di default che non sembrano adatti al proprio ambiente, sostituire tali valori quando si esegue lo script specificando uno o più argomenti della riga di comando.

thingworxMssqlDataTableDataUpdate.sh

Sintassi:

thingworxMssqlDataTableDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>] [-chunkSize <chunk-size>]

Esempio:

thingworxMssqlDataTableDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

Una volta avviato lo script di migrazione, attendere finché nella console non viene visualizzato un messaggio che indica che è possibile riavviare Tomcat. Quando viene visualizzato il messaggio, si può procedere al passo successivo, anche se l'esecuzione dello script di migrazione non è ancora terminata.

6. Aprire una nuova finestra del prompt dei comandi ed eseguire gli script di migrazione dei dati seguenti per migrare i dati stream e stream di valori dalle tabelle di backup:

Prima di eseguire lo script, aprirlo in un editor di testo per verificare che i relativi valori di ambiente di default (ad esempio server, porta, fusi orari e così via) siano corretti e sufficienti per il proprio ambiente. Se all'interno dello script sono definiti valori di default che non sembrano adatti al proprio ambiente, sostituire tali valori quando si esegue lo script specificando uno o più argomenti della riga di comando.

thingworxMssqlStreamDataUpdate.sh

thingworxMssqlValueStreamDataUpdate.sh

Sintassi:

thingworxMssqlStreamDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>] [-chunkSize <chunk-size>]

thingworxMssqlValueStreamDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>] [-chunkSize <chunk-size>]

Esempi:

thingworxMssqlStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

thingworxMssqlValueStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

Una volta avviati i due script di migrazione, non procedere con il passo successivo finché non sono stati completati questi due script e quello di migrazione della tabella dati (avviato in un passo precedente).

7. Verificare manualmente che siano stati completati tutti gli script seguenti: thingworxMssqlDataTableDataUpdate.sh, thingworxMssqlStreamDataUpdate.sh e thingworxMssqlValueStreamDataUpdate.sh e che sia stata eseguita la migrazione di tutti i dati della tabella dati, stream e stream di valori.

8. Eseguire lo script di pulizia per rimuovere tutti gli oggetti di database temporanei necessari durante la migrazione.

Sebbene esegua alcune operazioni di pulizia degli oggetti di database temporanei creati durante il processo di aggiornamento, questo script *non* elimina le tabelle di backup create nei passi precedenti, né modifica i dati all'interno di tali tabelle di backup. Ciò è intenzionale e impedisce che i dati vengano eliminati accidentalmente. Se si desidera eliminare queste tabelle di backup, è necessario procedere manualmente.

thingworxMssqlDBCleanupBigIntTimezoneDataUpdate.sh

Risoluzione dei problemi relativi agli script

• Per trovare tutti i fusi orari supportati, usare il comando seguente:

select * from sys.time_zone_info

• Per verificare che entry_ids vengano tutti sottoposti a migrazione, utilizzare un'interrogazione SQL simile alla seguente:

select dt.entry_id, dtb.entry_id from [thingworx].[twschema].[data_table_backup] dtb full join [thingworx].[twschema].[data_table] dt on dtb.entry_id = dt.entry_id where dtb.entry_id is null or dt.entry_id is null

Solo il passo 1 di questa sezione è richiesto per tutti gli aggiornamenti.

Se si esegue l'aggiornamento da ThingWorx 8.4.x o 8.5.x --> 9.0.x, 9.1.x o 9.2.x, attenersi alla procedura descritta nella parte rimanente della sezione.

Ignorare i passi nella parte rimanente della sezione se si esegue l'aggiornamento da ThingWorx 9.0.x o 9.1.x --> 9.1.x o 9.2.x

1. Eseguire lo script seguente, che si trova nella cartella update del download del software ThingWorx (a partire dalla versione che si sta aggiornando):

Il numero di permessi presenti nella piattaforma può influire sul tempo necessario per completare l'aggiornamento. Altri permessi potrebbero allungare i tempi di completamento dell'aggiornamento.

thingworxAzureSchemaUpdate8.4-to-8.5.sh

thingworxAzureSchemaUpdate8.5-to-9.0.sh

thingworxAzureSchemaUpdate9.1-to-9.2.sh

Non è necessario eseguire lo script thingworxAzureSchemaUpdate9.0-to-9.1.sh poiché nella versione 9.1 non sono presenti aggiornamenti dello schema. Anche se per completezza lo script è incluso nella cartella update, è vuoto ed è destinato solo agli utenti con processi di aggiornamento automatizzati.

Sintassi:

./thingworxAzureSchemaUpdate8.4-to-8.5.sh -d ^database^ -h ^server^ -l ^username^ [-i ^serverInstance^] [-p ^port^] [-o ^option^]

Esempio:

./thingworxAzureSchemaUpdate8.4-to-8.5.sh -d thingworx -h test.sqldatabase.net -l sqlAdmin

2. Eseguire lo script di configurazione big integer/timezone per preparare il database per la migrazione:

Se si sta già eseguendo ThingWorx in UTC, è comunque necessario effettuare la migrazione per le modifiche dello script big integer, ma è possibile fornire il valore di UTC a entrambi i parametri sourceTZ e targetTZ (disponibili in alcuni script nei passi di seguito).

thingworxAzureDBSetupBigIntTimezoneDataUpdate.sh

3. Eseguire lo script di migrazione del modello per migrare tutti i dati modello:

Prima di eseguire lo script, aprirlo in un editor di testo per verificare che i relativi valori di ambiente di default (ad esempio server, porta, fusi orari e così via) siano corretti e sufficienti per il proprio ambiente. Se all'interno dello script sono definiti valori di default che non sembrano adatti al proprio ambiente, sostituire tali valori quando si esegue lo script specificando uno o più argomenti della riga di comando.

thingworxAzureModelTablesDataUpdate.sh

Sintassi:

thingworxAzureModelTablesDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]

Esempio:

thingworxAzureModelTablesDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

4. Eseguire ciascuno degli script di migrazione dello schema riportati di seguito per creare tabelle di backup di tutti i dati della tabella dati, stream e stream di valori.

Per motivi di prestazioni, questi script non creano di fatto una copia dei dati originali in queste tabelle, bensì rinominano le tabelle esistenti da "<nome-originale-tabella>" a "<nome-originale-tabella>_backup". In questo modo si elude il processo di copia dei dati, che potrebbe richiedere molto tempo. Una volta rinominate le tabelle esistenti, in modo da farle diventare tabelle di backup, vengono create nuove tabelle con i nomi originali. Le nuove tabelle sono vuote e, avendo lo stesso nome di quelle originali, servono allo stesso scopo. Verranno popolate nei passi successivi con i dati migrati.

Durante l'esecuzione dello script della tabella dati viene visualizzato l'avviso previsto seguente: Warning! The maximum key length for a clustered index is 900 bytes. The index 'data_table_indexes_pkey' has maximum length of 902 bytes. For some combination of large values, the insert/update operation will fail.

thingworxAzureDataTableSchemaUpdate.sh

thingworxAzureStreamSchemaUpdate.sh

thingworxAzureValueStreamSchemaUpdate.sh

5. Aprire una nuova finestra del prompt dei comandi ed eseguire lo script di migrazione dei dati seguente per migrare i dati della tabella dati all'interno della tabella di backup:

Prima di eseguire lo script, aprirlo in un editor di testo per verificare che i relativi valori di ambiente di default (ad esempio server, porta, fusi orari e così via) siano corretti e sufficienti per il proprio ambiente. Se all'interno dello script sono definiti valori di default che non sembrano adatti al proprio ambiente, sostituire tali valori quando si esegue lo script specificando uno o più argomenti della riga di comando.

thingworxAzureDataTableDataUpdate.sh

Sintassi:

thingworxAzureDataTableDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]

Esempio:

thingworxAzureDataTableDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

Una volta avviato lo script di migrazione, attendere finché nella console non viene visualizzato un messaggio che indica che è possibile riavviare Tomcat. Quando viene visualizzato il messaggio, si può procedere al passo successivo, anche se l'esecuzione dello script di migrazione non è ancora terminata.

6. Aprire una nuova finestra del prompt dei comandi ed eseguire gli script di migrazione dei dati seguenti per migrare i dati stream e stream di valori dalle tabelle di backup:

Prima di eseguire lo script, aprirlo in un editor di testo per verificare che i relativi valori di ambiente di default (ad esempio server, porta, fusi orari e così via) siano corretti e sufficienti per il proprio ambiente. Se all'interno dello script sono definiti valori di default che non sembrano adatti al proprio ambiente, sostituire tali valori quando si esegue lo script specificando uno o più argomenti della riga di comando.

thingworxAzureStreamDataUpdate.sh

thingworxAzureValueStreamDataUpdate.sh

Sintassi:

thingworxAzureStreamDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]

thingworxAzureValueStreamDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]

Esempi:

thingworxAzureStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

thingworxAzureValueStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

Una volta avviati i due script di migrazione, non procedere con il passo successivo finché non sono stati completati questi due script e quello di migrazione della tabella dati (avviato in un passo precedente).

7. Verificare manualmente che siano stati completati tutti gli script seguenti: thingworxAzureDataTableDataUpdate.sh, thingworxAzureStreamDataUpdate.sh e thingworxAzureValueStreamDataUpdate.sh. Verificare che sia stata completata la migrazione di tutti i dati della tabella dati, stream e stream di valori.

8. Eseguire lo script di pulizia per rimuovere tutti gli oggetti di database temporanei necessari durante la migrazione.

Sebbene esegua alcune operazioni di pulizia degli oggetti di database temporanei creati durante il processo di aggiornamento, questo script *non* elimina le tabelle di backup create nei passi precedenti, né modifica i dati all'interno di tali tabelle di backup. Ciò è intenzionale e impedisce che i dati vengano eliminati accidentalmente. Se si desidera eliminare queste tabelle di backup, è necessario procedere manualmente.

thingworxAzureDBCleanupBigIntTimezoneDataUpdate.sh

Java 11 è necessario per ThingWorx 9.2.0 e versioni successive. Per informazioni dettagliate, fare riferimento ai requisiti di sistema.

1. Se si esegue l'aggiornamento a Java 11, è necessario procedere come descritto di seguito. Ignorare questa sezione se Java 11 è già installato.

a. Scaricare OpenJDK o Java 11.

b. Installare jEnv in Linux:

i. Clonare il repository jEnv usando git:

git clone https://github.com/jenv/jenv.git ~/.jenv

ii. Aggiungere jEnv alla variabile $PATH:

echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.bash_profile

iii. Inizializzare jEnv:

echo 'eval "$(jenv init -)"' >> ~/.bash_profile

iv. Aggiornare le modifiche apportate in ~/.bash_profile:

source ~/.bash_profile

v. Impostare la variabile di ambiente JAVA_HOME:

jenv enable-plugin export

vi. Riavviare la sessione corrente della shell:

exec $SHELL -l

vii. Eseguire il comando seguente e la variabile JAVA_HOME verrà impostata automaticamente da jEnv, a seconda dell'ambiente Java correntemente attivo:

jenv doctor

c. Aggiungere ambienti Java:

i. Aggiungere qualsiasi ambiente. Tutte le installazioni di Java si trovano in /usr/lib/jvm/. Utilizzare il comando jenv add. Esempi:

jenv add /usr/lib/jvm/java-11-amazon-corretto

jenv add /usr/lib/jvm/jdk-11.0.7

ii. Controllare tutte le versioni di Java disponibili in jenv:

jenv versions

iii. Impostare l'ambiente Java globale:

jenv global <version>

iv. Impostare l'ambiente Java specifico della shell:

jenv shell <version>

v. Verificare la versione corrente impostata da jenv:

jenv versions

vi. Aggiornare il percorso nelle impostazioni Java Tomcat.

1. Copiare il nuovo file Thingworx.war e posizionarlo nel percorso di installazione di Tomcat seguente: /Apache Software Foundation/Tomcat x.x/webapps.

2. Attivare l'importazione delle estensioni. Per default, l'importazione di estensioni è disattivata per tutti gli utenti. Aggiungere quanto segue al file platform-settings.json. Aggiungere o aggiornare i parametri ExtensionPackageImportPolicy seguenti impostandoli su true per consentire l'importazione delle estensioni.

"ExtensionPackageImportPolicy": {
"importEnabled": <true or false>,
"allowJarResources": <true or false>,
"allowJavascriptResources": <true or false>,
"allowCSSResources": <true or false>,
"allowJSONResources": <true or false>,
"allowWebAppResources": <true or false>,
"allowEntities": <true or false>,
"allowExtensibleEntities": <true or false>
},

3. Se si utilizza H2 come database con ThingWorx, è necessario aggiungere un nome utente e una password al file platform-settings.json.

},
"PersistenceProviderPackageConfigs":{
"H2PersistenceProviderPackage":{
"ConnectionInformation":
{
"password": "<changeme>",
"username": "twadmin"
}
},

4. Avviare Tomcat.

5. Per ripristinare le configurazioni SSO, attenersi alla procedura descritta di seguito.

a. Copiare il blocco SSOSecurityContextFilter dal file web.xml di backup.

b. Nel file web.xml appena creato incollare il blocco SSOSecurityContextFilter dopo l'ultimo blocco AuthenticationFilter.

6. Per avviare ThingWorx, passare a <nomeserver>\Thingworx in un browser Web. Utilizzare le informazioni di accesso seguenti.

◦ Nome login: Amministratore

◦ Password: <Password amministratore server origine>

I passi di questa sezione sono necessari solo se si esegue l'aggiornamento di ThingWorx con InfluxDB 1.7.x (per ThingWorx 8.5.x o 9.0.x) a InfluxDB 1.8.x (per ThingWorx 9.1.x o 9.2.x).

1. Creare un nuovo provider di persistenza per InfluxDB 1.8.x o fornire nuove informazioni di connessione al provider di persistenza 1.7.x esistente.

2. Importare i dati stream e stream di valori nel server. Attenersi alla procedura descritta di seguito per i dati stream e stream di valori.

a. Accedere a ThingWorx 9.x come amministratore.

b. Fare clic su Importazione/Esportazione > Importazione.

c. Utilizzare le opzioni riportate di seguito.

i. Per Opzione di importazione selezionare Da file.

ii. Per Tipo di importazione selezionare Dati.

iii. Per Origine importazione selezionare Repository di file.

iv. Per Repository di file selezionare Sistema.

v. Per Percorso, specificare un percorso di repository di sistema valido.

• Se si utilizzano i connettori di integrazione, è necessario ottenere e installare la versione più recente di Integration Runtime. Per ulteriori informazioni, fare riferimento a Impostazione iniziale del servizio Integration Runtime per i connettori di integrazione.

• Se si aggiorna il driver MSSQL JDBC, verificare i Requisiti di sistema e vedere Configurazione di ThingWorx per MSSQL per trovare il driver appropriato.

• Se è stato eseguito l'upgrade da 8.x a 9.x e sono presenti estensioni Java, vedere Migrazione di estensioni Java da 8.x a 9.x.

• Se si utilizza ThingWorx Analytics come parte della soluzione, sono disponibili i due programmi di installazione riportati di seguito per gestire gli aggiornamenti dei componenti.

◦ Server Analytics - Installa o aggiorna Analytics Server e Analytics Extension

◦ Platform Analytics - Installa o aggiorna le analisi descrittive e le trasformazioni di proprietà

Per ulteriori informazioni sulle procedure di aggiornamento, vedere l'argomento relativo ad aggiornamento, modifica e ripristino di ThingWorx Analytics.

Se si esegue l'aggiornamento a ThingWorx 9.2.x o versioni successive, è necessario eseguire lo script di pulizia per rimuovere le tabelle temporanee create durante il processo di aggiornamento.

Eseguire lo script di pulizia thingworx<nome_database>DBCleanupPermissionTempTableUpdate.sh, che si trova nella cartella <installDir>/schema/update.

Lo script utilizza parametri come quelli seguenti:

-h <server>
-p <port>
-d <thingworx database name>
-l <thingworx database username> for MSSQL
-u <thingworx database username> for PostgreSQL
-i <SQL server instance name> (optional, for MSSQL installations only)

Viene richiesto di immettere la password per l'utente del database, che viene passata ai parametri -u o -l.

• Se l'aggiornamento non è riuscito a causa di valori mancanti per i campi di indice personalizzati, è necessario distribuire nuovamente la versione precedente (se sono stati apportati aggiornamenti allo schema, è necessario eseguire il rollback del database o ripristinarlo) e aggiungere i valori di indice mancanti o rimuovere gli indici personalizzati dalla tabella dati prima di eseguire l'aggiornamento.

Dopo avere avviato la piattaforma ThingWorx, controllare il log applicazioni per la piattaforma. Se si utilizza MSSQL, PostgreSQL o H2, è possibile che vengano visualizzati messaggi di errore di conflitto di proprietà indicati di seguito.

Errore durante la risoluzione dei problemi
Errore nel log applicazioni	Risoluzione
Error in copying permissions: Problems migrating database	Questo errore di migrazione viene visualizzato per gli aggiornamenti di MSSQL quando sono presenti nomi di servizi, proprietà o eventi migrati per i quali sono configurati permessi in fase di esecuzione e che contengono più di 256 caratteri. Per correggere questo errore, limitare tutti i nomi di servizi, proprietà ed eventi a meno di 256 caratteri.
[L: ERROR] [O: c.t.p.m.BaseReportingMigrator] [I: ] [U: SuperUser] [S: ] [T: localhost-startStop-1] Thing: <Name of Thing>, has a property which conflicts with one of the following system properties: isReporting,reportingLastChange,reportingLastEvaluation. Please refer to the ThingWorx Platform 8.4 documentation on how to resolve this problem.	Nell'ambito della funzionalità Presenza di oggetto aggiunta a ThingWorx Platform 8.4, le proprietà riportate di seguito sono state aggiunte alla thing shape riportabile e vengono utilizzate come parte della valutazione della presenza sugli oggetti che implementano questa forma. • isReporting • reportingLastChange • reportingLastEvaluation Se uno dei nomi delle proprietà sopra riportate esisteva già per un oggetto, un modello di oggetto o una thing shape, nel log applicazioni vengono visualizzati gli errori riportati di seguito quando la piattaforma viene avviata. Per risolvere il problema, è necessario rimuovere la proprietà in conflitto su ciascuna entità interessata e tutte le entità associate aggiornate per consentire la modifica, ad esempio mashup o servizi. Senza questo aggiornamento, gli oggetti associati non possono visualizzare correttamente lo stato di report e non possono essere aggiornati/salvati. Una volta che queste entità sono state aggiornate, le proprietà di report specifiche della piattaforma vengono visualizzate e utilizzate per valutare se un dispositivo è connesso e in comunicazione.
[L: ERROR] [O: c.t.p.m.BaseReportingMigrator] [I: ] [U: SuperUser] [S: ] [T: localhost-startStop-1] ThingTempate: <Name of ThingTemplate>, has a property which conflicts with one of the following system properties: isReporting,reportingLastChange,reportingLastEvaluation. Please refer to the ThingWorx Platform 8.4 documentation on how to resolve this problem.
[L: ERROR] [O: c.t.p.m.BaseReportingMigrator] [I: ] [U: SuperUser] [S: ] [T: localhost-startStop-1] ThingShape: <Name of ThingShape>, has a property which conflicts with one of the following system properties: isReporting,reportingLastChange,reportingLastEvaluation. Please refer to the ThingWorx Platform 8.4 documentation on how to resolve this problem.