Aggiornamento del programma di installazione
Se si utilizza il programma di installazione di ThingWorx Foundation per installare ThingWorx Foundation 8.5.0 o versioni successive, è possibile utilizzare il programma di installazione per aggiornare ThingWorx Foundation, inclusi gli aggiornamenti delle release di manutenzione. Per i link alle matrici di aggiornamento supportate per ciascuna versione di ThingWorx, vedere Aggiornamento di ThingWorx.
 |
Con ThingWorx 9.4 non è possibile eseguire l'aggiornamento direttamente da ThingWorx 8.5 o ThingWorx 9.0 a ThingWorx 9.4.0. Per eseguire l'aggiornamento a ThingWorx 9.4.0 e versioni successive da ThingWorx 8.5 o ThingWorx 9.0 è necessario eseguire l'aggiornamento a una versione intermedia prima di eseguire l'aggiornamento a ThingWorx 9.4.0 e versioni successive. Si consiglia di utilizzare la versione più recente di ThingWorx 9.3.x come percorso di aggiornamento intermedio.
|
|
|
Se si esegue l'aggiornamento a ThingWorx 9.2 e a PostgreSQL 13, l'aggiornamento di PostgreSQL sarà l'ultimo passo del processo di aggiornamento.
|
|
|
L'utente che esegue l'aggiornamento deve essere lo stesso che ha eseguito l'installazione originale dell'applicazione.
|
A.) Prerequisiti
• Requisiti Java (il programma di installazione non include Java nel package né lo installa come parte dell'installazione):
◦ L'utente che ha inizialmente installato ThingWorx deve eseguire l'aggiornamento. Durante l'installazione iniziale, il programma di installazione genera il file ThingWorxFoundation.xml, che include informazioni sull'installazione ed è necessario per l'aggiornamento. Questo file si trova nel profilo dell'utente che esegue l'installazione. Ad esempio, in C:\Users\Administrator\.ptc_cci.
◦ ThingWorx Foundation 9.2 richiede Java 11, ma è necessario installare anche Java 8. Verificare che le versioni supportate di Java 8 e 11 siano installate prima di eseguire il programma di installazione. Aggiungere Java 11 alla variabile di ambiente PATH.
◦ Se si esegue ThingWorx 9.0 o versioni precedenti su Java 8 e si esegue l'aggiornamento a ThingWorx 9.2, è necessario preinstallare Java 11 ma non modificare ThingWorx in modo che punti alla nuova JVM. Il parametro JAVA_HOME deve rimanere impostato sulla cartella di Java 8. Entrambe le directory di Java devono essere presenti nella variabile di ambiente PATH, ma java8/bin deve essere indicata prima di java11/bin nella variabile PATH. Durante l'aggiornamento a 9.2, il programma di installazione cambia anche la versione di Java in uso in Java 11, poiché ThingWorx 9.2 non supporta Java 8.
◦ ThingWorx 9.1 invece supporta Java 8 e Java 11. È pertanto possibile seguire il consiglio sopra indicato (installare entrambi, inserirli entrambi nel percorso) oppure eseguire la migrazione dell'istanza di ThingWorx 9.1 a Java 11 prima di avviare l'aggiornamento.
• Eseguire il backup del database. Il programma di installazione non esegue un backup del database durante il processo di aggiornamento.
• Con queste combinazioni di database, è necessario disporre di uno dei sistemi operativi seguenti:
◦ Windows con PostgreSQL
◦ Windows con Microsoft SQL Server
◦ Red Hat Enterprise Linux con PostgreSQL
◦ Red Hat Enterprise Linux con Microsoft SQL Server
Per informazioni sulla versione, vedere Requisiti di sistema.
• L'aggiornamento non riesce se nelle tabelle dati manca un valore di campo di indice personalizzato. Verificare che siano presenti valori in tutti i campi di indice personalizzati prima di avviare il processo di aggiornamento.
B.) Eseguire l'utilità ThingWorx Upgrade Ready
Se è installato ThingWorx Foundation 8.5.3 o versioni precedenti, è necessario eseguire prima l'utilità ThingWorx Upgrade-Ready, disponibile in > > > > > .
L'utilità ThingWorx Upgrade Ready crea i file XML necessari per supportare l'aggiornamento automatico di ThingWorx Foundation e, se installato, di ThingWorx Flow. L'utilità richiede di individuare ThingWorx Foundation e, se installato, ThingWorx Flow nel sistema e quindi di configurare le installazioni selezionate. Crea il file ThingWorxFoundation.xml e, se è installato ThingWorx Flow, il file ThingWorxFlow.xml nel profilo utente. I file vengono salvati nella cartella .ptc_ccif nel profilo utente (ad esempio, in Windows: C:\Users\Administrator\.ptc_ccif; in Linux: ~/.ptc_ccif/).
Se è stato installato ThingWorx 8.5.4 o versioni successive utilizzando il programma di installazione, i file XML necessari sono già stati creati nell'ambito dell'installazione. Non è pertanto necessario eseguire l'utilità ThingWorx Upgrade Ready.
Risoluzione dei problemi
• Se è stato utilizzato il programma di installazione per installare ThingWorx Foundation 8.5.3 o versioni precedenti, quindi è stato effettuato l'aggiornamento manuale a una versione 8.5.x successiva e si sta preparando l'aggiornamento a 9.x con l'utilità ThingWorx Upgrade Ready, eseguire le operazioni descritte di seguito.
◦ Eseguire l'utilità ThingWorx Upgrade Ready.
◦ Verificare che il valore della proprietà <Versioneapplicazione> nel file ThingWorxFoundation.xml nel profilo utente sia la versione corrente.
• Se sono stati riscontrati problemi nell'esecuzione dell'utilità ThingWorx Upgrade Ready e si desidera creare o modificare manualmente il file ThingWorxFoundation.xml, è possibile utilizzare l'esempio riportato di seguito e aggiornarlo in base al percorso di aggiornamento.
<?xml version="1.0" encoding='utf-8'?>
<installationInfo>
<projectFlavor>PostgreSQL</projectFlavor>
<applicationName>ThingWorxFoundation</applicationName>
<applicationVersion>9.0.1</applicationVersion>
<applicationInstallDir>C:\Program Files
(x86)\ThingWorxFoundation</applicationInstallDir>
</installationInfo>
<installationInfo>
<projectFlavor>PostgreSQL</projectFlavor>
<applicationName>ThingWorxFoundation</applicationName>
<applicationVersion>9.0.1</applicationVersion>
<applicationInstallDir>C:\Program Files
(x86)\ThingWorxFoundation</applicationInstallDir>
</installationInfo>
C.) Eseguire l'aggiornamento
1. Verificare che siano soddisfatti i prerequisiti descritti nelle sezioni precedenti.
2. Scaricare la versione più recente dei file di installazione di ThingWorx Foundation per le installazioni locali dal sito support.ptc.com, in Scarica il software > Order or Download Software Updates > ThingWorx Foundation > Release x.x > ThingWorx PostgreSQL o ThingWorx Mssql.
3. Il programma di installazione elenca le informazioni di installazione esistenti, tra cui:
◦ Directory di installazione
◦ Porta
◦ Impostazione della configurazione SSL
◦ Impostazione della configurazione SSO
4. Viene proposto il contratto di licenza PTC. È necessario accettare i termini del contratto prima di continuare con l'aggiornamento.
5. È necessario immettere la password amministratore di ThingWorx Foundation o, se è configurato SSO, immettere la chiave di accesso.
6. È possibile esaminare e confermare le informazioni di configurazione dell'installazione.
7. Il programma di installazione completa l'aggiornamento.
È ora possibile aggiornare le estensioni e le applicazioni alle versioni compatibili.
D.) Migrare i dati del fuso orario
| | La migrazione dei dati del fuso orario non è necessaria quando si esegue l'aggiornamento a ThingWorx 9.4.0 e versioni successive. Gli aggiornamenti diretti non sono supportati da ThingWorx 8.5 o ThingWorx 9.0 a ThingWorx 9.4. La migrazione dei dati del fuso orario verrà eseguita durante il processo di migrazione alla versione intermedia. |
È necessario eseguire i passi di migrazione dei dati critici in questa sezione se si verifica una delle condizioni descritte di seguito.
• È stato installato ThingWorx 8.5.x ed è stato utilizzato il programma di installazione per eseguire l'aggiornamento a ThingWorx 9.0.x o 9.1.
• È stato installato ThingWorx 9.0.x ed è stato utilizzato il programma di installazione per eseguire l'aggiornamento a ThingWorx 9.0.3 o versioni successive.
Per eseguire la migrazione dei dati, attenersi alla procedura descritta di seguito.
1. Subito dopo l'aggiornamento, arrestare ThingWorx e Apache Tomcat.
2. Impostare manualmente il parametro del fuso orario -Duser.timezone=UTC utilizzando i passi descritti di seguito in base al sistema operativo in uso.
Configurare le impostazioni del fuso orario in Windows
1. Arrestare il servizio ThingWorx-Foundation.
2. Eseguire CMD come amministratore.
3. Accedere alla directory Tomcat /bin nella directory di installazione di ThingWorx Foundation.
Ad esempio: cd C:\Programmi (x86)\ThingWorxFoundation\tomcat\apache-tomcat-9.0.37\bin.
4. Modificare la configurazione del servizio ThingWorx-Foundation per aprire l'applicazione GUI eseguendo le operazioni descritte di seguito.
tomcat9w.exe //ES//ThingWorx-Foundation
5. Accedere alla scheda Java nell'applicazione GUI.
a. Per Java Options, aggiungere quanto segue:-Duser.timezone=UTC.
b. Scegliere Applica.
6. Scegliere OK per chiudere la GUI.
7. Aggiornare i parametri del servizio utilizzando tomcat9.exe.
8. Eseguire CMD come amministratore ed eseguire quanto segue:
tomcat9.exe //US//ThingWorx-Foundation
Configurare le impostazioni del fuso orario in Linux
1. Arrestare il servizio ThingWorx-Foundation utilizzando systemctl stop ThingWorx-Foundation.service.
2. Eseguire il backup di ThingWorx-Foundation.service in /etc/systemd/system/ThingWorx-Foundation.service.backup.
3. Modificare la configurazione del servizio modificando le opzioni ThingWorx-Foundation.service per JVM:
a. In CATALINA_OPTS aggiungere quanto segue: -Duser.timezone=UTC
4. Eseguire le operazioni seguenti: systemctl daemon-reload.
Eseguire gli script
• Aggiornamento del programma di installazione a 9.3.x e versioni successive
1. Ottenere l'elenco di tutti i nomi dei fusi orari specifici del database. A tale scopo, connettersi manualmente al database ed eseguire l'interrogazione per ottenere un elenco di tutti i nomi dei fusi orari attualmente supportati dal database:
SELECT name, utc_offset, is_dst FROM pg_timezone_names ORDER BY name
| | Mantenere questo elenco per un riferimento successivo. |
2. Determinare il nome del fuso orario a cui sono attualmente associati tutti i dati di ThingWorx esistenti (il fuso orario "Da"):
▪ Ottenere il valore del fuso orario annotato nella sezione "Impostare il fuso orario del server ThingWorx" precedente.
▪ Si tratta del fuso orario a cui sono attualmente associati tutti i dati di ThingWorx esistenti.
▪ Tale valore è specifico della JVM o del sistema operativo e potrebbe non essere esattamente corrispondente a un nome di fuso orario presente nell'elenco specifico del database (interrogato nel passo 1).
▪ Esaminare manualmente l'elenco dei fusi orari interrogati dal database per identificare il nome che più corrisponde al valore della sezione "Impostare il fuso orario del server ThingWorx".
▪ Dopo avere individuato la corrispondenza più appropriata, il nome del fuso orario diventa il fuso orario "Da" (contrapposto al fuso orario "A") e servirà nei passi successivi.
3. Determinare il fuso orario in cui devono essere migrati tutti i dati di ThingWorx esistenti (il fuso orario "A"):
▪ Nella sezione precedente "Impostare il fuso orario del server ThingWorx" l'impostazione di configurazione -Duser.timezone di Tomcat è stata specificata come UTC. Si tratta del fuso orario a cui devono essere migrati tutti i dati di ThingWorx esistenti. Il valore tuttavia è specifico della JVM e potrebbe non corrispondere esattamente a un nome di fuso orario presente nell'elenco specifico del database (interrogato nel passo 1).
▪ Esaminare manualmente l'elenco dei fusi orari interrogati dal database per identificare il nome che più corrisponde al valore di UTC.
▪ Dopo aver trovato la corrispondenza più appropriata, il nome del fuso orario diventa il fuso orario "A" (contrapposto al fuso orario "Da") e servirà nei passi successivi.
| | I nomi dei fusi orari "Da" e "A" possono essere uguali. |
4. Eseguire lo script di schema BigInt/Timezone per preparare la migrazione di tutti i dati della tabella dati, stream e stream di valori:
update_bigint_timezone_schema_postgres.ps1
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: update_bigint_timezone_schema_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] --from_timezone <timezone> --to_timezone <timezone> [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). --system_version_override version Forces the upgrade to assume the database schema is currently of this version (i.e. "n.n.n"), rather than of the actual, persisted version. --from_timezone timezone The name of the timezone for all existing data. --to_timezone timezone The name of the timezone to which all existing data will be updated. -y Suppress all non-required prompts, such as "Are you sure?" |
| | Anche se esegue la migrazione diretta di alcuni dati, questo script non migra tutti dati della tabella dati, stream e stream di valori. Crea invece un backup di tutti i dati della tabella dati, stream e stream di valori in modo che possano essere migrati in un secondo momento. Per motivi di prestazioni, questo script in realtà non crea una copia di backup dei dati all'interno delle tabelle dati, stream e stream di valori esistenti, ma rinomina le tabelle esistenti da "foo" a "foo_backup". In questo modo si elude il processo di copia di enormi quantità di 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. |
5. Al termine del passo precedente è possibile riavviare la piattaforma, se necessario. Si noti tuttavia che i dati della tabella dati, stream e stream di valori non sono ancora stati migrati. Pertanto, fino a quando non si verifica la migrazione dei dati, le interrogazioni che li riguardano possono restituire insiemi ridotti di risultati.
6. Eseguire lo script di dati BigInt/Timezone per migrare tutti i dati della tabella dati, stream o stream di valori:
update_bigint_timezone_data_postgres.ps1
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: update_bigint_timezone_data_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] --from_timezone <timezone> --to_timezone <timezone> --chunk_size <chunk_size> ( --update_data_table | --update_stream | --update_value_stream ) [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). --system_version_override version Forces the upgrade to assume the database schema is currently of this version (i.e. "n.n.n"), rather than of the actual, persisted version. --from_timezone timezone The name of the timezone for all existing data. --to_timezone timezone The name of the timezone to which all existing data will be updated. --chunk_size chunk_size The number of records to update per transaction. Must be greater than 0. --update_data_table Update "data_table" information. Cannot be specified with any other "--update_..." flag. --update_stream Update "stream" information. Cannot be specified with any other "--update_..." flag. --update_value_stream Update "data_table" information. Cannot be specified with any other "--update_..." flag. -y Suppress all non-required prompts, such as "Are you sure?" |
| | • Per l'istruzione con sintassi precedente, è possibile specificare una sola opzione "--update…" alla volta. Di conseguenza, per migrare tutti i dati della tabella dati, stream e stream di valori, questo script deve essere eseguito tre volte (una volta per ogni insieme di dati). Poiché questi insiemi di dati sono indipendenti l'uno dall'altro, è possibile eseguire la migrazione di più insiemi di dati parallelamente. Ad esempio, se si aprono tre finestre di comando separate, è possibile eseguire contemporaneamente la migrazione della tabella dati nella prima finestra, dello stream nella seconda finestra e dello stream di valori nella terza finestra. Si sconsiglia, tuttavia, di provare a utilizzare più di un processo per eseguire la migrazione simultanea di un determinato insieme di dati. Ad esempio, non tentare di utilizzare due processi simultanei per migrare i dati stream di valori. Questa operazione non è definita e comporta il danneggiamento dei dati. • Il valore di chunk_size consigliato per un ambiente tipico è 10.000. • Poiché la piattaforma può essere riavviata prima che sia stata completata la migrazione dei dati, la migrazione viene eseguita dai dati più recenti a quelli meno recenti. Questo criterio è intenzionale perché permette di ricevere prima i dati più pertinenti nei risultati delle interrogazioni eseguite sui dati. • La dimensione degli insiemi di dati può avere un impatto significativo sul tempo necessario per la migrazione di tutti i dati. Ad esempio, per completare la migrazione di miliardi di righe potrebbero essere necessari diversi giorni. |
7. Una volta completata la migrazione dei dati BigInt/Timezone, e dopo che tutti i dati BigInt/Timezone migrati sono stati verificati e convalidati manualmente, eseguire lo script di pulizia BigInt/Timezone per pulire gli elementi del database temporaneo creati dallo script di schema BigInt/Timezone:
cleanup_bigint_timezone_data_update_postgres.ps1
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: cleanup_bigint_timezone_data_update_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). -y Suppress all non-required prompts, such as "Are you sure?" |
| | Sebbene esegua alcune operazioni di pulizia degli oggetti di database temporanei creati durante il processo di aggiornamento, lo script non elimina le tabelle di backup create nei passi precedenti, né modifica i dati al loro interno. Ciò è intenzionale e impedisce che i dati vengano eliminati accidentalmente. Se si desidera eliminare queste tabelle di backup, è necessario farlo manualmente. |
8. Eseguire lo script di pulizia principale dopo che tutte le migrazioni dei dati sono state completate, verificate e convalidate.
Una volta completata, verificata e convalidata la migrazione dei dati BigInt/Timezone, eseguire questo script per pulire gli elementi del database temporaneo creati dallo script di aggiornamento ThingWorx principale:
cleanup_update_postgres.ps1
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: cleanup_update_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). -y Suppress all non-required prompts, such as "Are you sure?" |
• Aggiornamento del programma di installazione a 9.0.x, 9.1.x, 9.2.x
Una volta impostato il fuso orario, passare a <PercorsoInstallazione>/schema/update ed eseguire gli script appropriati per la combinazione di database e sistema operativo in uso (ad esempio, per Windows i file .bat elencati di seguito; per un'installazione in ambiente RHEL i file .sh) nell'ordine seguente:
a. thingworxPostgresDBSetupBigIntTimezoneDataUpdate.bat
b. thingworxPostgresModelTablesDataUpdate.bat
c. thingworxPostgresDataTableSchemaUpdate.bat
d. thingworxPostgresValueStreamSchemaUpdate.bat
e. thingworxPostgresStreamSchemaUpdate.bat
f. thingworxPostgresDataTableDataUpdate.bat
g. thingworxPostgresStreamDataUpdate.bat
h. thingworxPostgresValueStreamDataUpdate.bat
Gli script utilizzano 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)
-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)
Per ulteriori informazioni su questi parametri e sull'input previsto, vedere Aggiornamento manuale sul posto: Windows o Aggiornamento manuale sul posto: Linux.
Viene richiesto di immettere la password per l'utente del database, che viene passata ai parametri -u o -l.
| | Gli script StreamDataUpdate e ValueStreamDataUpdate (ad esempio, thingworxPostgresStreamDataUpdate.bat e thingworxPostgresValueStreamDataUpdate.bat) sono progettati per essere eseguiti in modo asincrono. Gli script sono progettati in modo da individuare il punto in cui sono stati interrotti e per operare in batch in modo da poter eseguire la migrazione dei dati mentre l'istanza di ThingWorx è in esecuzione. A seconda del volume dei dati, per l'esecuzione di questi script potrebbe essere necessario molto tempo. |
Lo script DataTableDataUpdate (ad esempio, thingworxPostgresDataTableDataUpdate.bat) visualizza il seguente messaggio durante l'esecuzione: Essential System Data Has Been Migrated. It Is Now Safe To Restart Tomcat Server.
Dopo che lo script DataTableDataUpdate ha inviato questo messaggio, è possibile riavviare l'istanza di ThingWorx e continuare con gli script di migrazione dei dati rimanenti. È possibile eseguire gli script rimanenti mentre ThingWorx è in esecuzione e termina la migrazione dei dati stream e stream di valori.
Al termine della migrazione, è necessario eseguire lo script di pulizia (ad esempio, "thingworxPostgresDBCleanupBigIntTimezoneDataUpdate.sh") per la pulizia della tabella migration_log e delle funzioni di migrazione.
E.) Eseguire lo script di pulizia per 9.2 +
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.bat(Windows) o thingworx<nome_database>DBCleanupPermissionTempTableUpdate.sh (Linux) che si trova in <installDir>/schema/update.
Gli script utilizzano 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)
-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.
F.) Ulteriore pulizia facoltativa per 9.3 e versioni successive
Se si esegue l'aggiornamento da ThingWorx 9.2. x o versioni precedenti ed è stato attivato il Single Sign-On con crittografia token di accesso, è possibile eseguire un passo di pulizia facoltativo. Nelle release precedenti la 9.3, viene utilizzato lo strumento KeyCzar per crittografare i token di accesso prima che vengano resi persistenti nel database. KeyCzar richiede la creazione di una cartella symmetric nella cartella ThingworxPlatform\ssoSecurityConfig della directory di installazione di ThingWorx.
Lo strumento KeyCzar ora è obsoleto. In ThingWorx 9.3 e versioni successive è stato sostituito dall'utilizzo di Tink per la crittografia dei token di accesso. Tink non richiede la cartella symmetric o il parametro keyczarKeyFolderPath nel file ThingWorx sso-settings.json. È possibile lasciare questi file e queste impostazioni così come sono. In ThingWorx 9.3 e versioni successive verranno semplicemente ignorati. Tuttavia, se si decide di rimuoverli, è necessario attendere il completamento della procedura di aggiornamento.
G.) (Facoltativo) Eseguire l'aggiornamento a PostgreSQL 13
L'aggiornamento da una versione precedente di PostgreSQL a PostgreSQL 13 è facoltativo per ThingWorx 9.2.0 e versioni successive.
1. Eseguire il backup del database. Si tratta del secondo backup eseguito, in quanto il backup del database viene eseguito dopo l'aggiornamento di ThingWorx.
2. Scaricare PostgreSQL 13.
3. Eseguire l'aggiornamento a PostgreSQL 13 utilizzando la documentazione di PostgreSQL come riferimento.
H.) Risoluzione dei problemi
• Se l'aggiornamento ha esito negativo con l'errore che segue, attenersi alla procedura descritta di seguito. Questo errore si verifica se un valore di indice personalizzato è maggiore di o uguale a 64 caratteri.
Unable to Invoke Service Reindex on Data Table : com.microsoft.sqlserver.jdbc.SQLServerException: String or binary data would be truncated in table 'thingworx.thingworx.data_table_indexes', column 'mskey'. Truncated value: '<with_actual_field_Value_from_mskey_field>'.
a. Eseguire thingworxMssqlSchemaUpdate<Versioneprecedente>-to-<Versionecorrente>.bat/.sh o lo script SQL:
sqlcmd -S server\\serverinstance,port -U db_user -P password -d databaseName -i <schemaUpdateFile.sql>
L'esecuzione dello script consentirà di aumentare la lunghezza della colonna mskey e di aggiornare gli indici.
b. Avviare Tomcat.
• Se è presente un'installazione esistente di ThingWorx 8.5.3 o versioni precedenti ma il programma di installazione non la rileva, eseguire l'utilità ThingWorx Upgrade Ready.
• Se il programma di installazione non riesce a completare l'aggiornamento, attenersi alla procedura descritta di seguito.
1. Controllare i file di log nella directory di installazione in /installer/logs.
2. Ripristinare l'installazione pre-aggiornamento:
a. Ripristinare il backup del database.
b. Avviare il servizio ThingWorx-Foundation.
• Se l'esecuzione del programma di installazione è stata completata, ThingWorx Foundation è stato aggiornato. Tuttavia, il nome della posizione di installazione di ThingWorx Foundation potrebbe non essere aggiornato. È possibile verificare la versione di ThingWorx in Composer in > .
• Se il sistema operativo è RHEL 8.2 e si sta eseguendo l'aggiornamento da ThingWorx 8.5.7, è necessario prima disinstallare manualmente Chef Infra Client per assicurarsi che il programma di installazione sia in grado di fornire e utilizzare una versione supportata di Chef. Per disinstallare Chef, eseguire le operazioni descritte di seguito.
a. Per trovare il nome del package del programma di installazione di Chef Infra Client, eseguire il comando seguente: $ rpm -qa chef.
L'output deve essere simile al seguente: chef-14.10.9-1.el7.x86_64.rpm.
b. Copiare il nome del package dall'output trovato sopra.
c. Eseguire il comando seguente con il nome del package copiato: $ sudo yum remove <copied_package_name>.
Ad esempio: $ sudo yum remove chef-14.10.9-1.el7.x86_64.rpm.
d. Accedere alla directory /opt e rimuovere tutti i file di Chef Infra Client eliminando la directory di installazione $ sudo rm -rf /opt/chef.