Aggiornamento manuale in Linux
Aggiornamento manuale sul posto a 9.3.x e versioni successive: Linux
 |
Con ThingWorx 9.4.0 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.
|
Per determinare il percorso di aggiornamento, fare riferimento alla tabella di aggiornamento. I passi riportati di seguito si riferiscono solo all'aggiornamento sul posto. Per un aggiornamento tramite migrazione, fare riferimento a Migrazione manuale a ThingWorx 9.x: Linux.
|
|
Al momento non è disponibile alcun supporto per gli script di migrazione del database big integer/timezone per H2. Questi script di migrazione sono descritti dettagliatamente per altri database supportati. Se in presenza di un database H2 esistente si richiede la correzione del fuso orario, è necessario eseguire la migrazione a un database supportato, ad esempio PostgreSQL o MS SQL. Se l'applicazione funziona senza la correzione del fuso orario, è possibile eseguire l'aggiornamento alla versione più recente di ThingWorx su H2. La sezione Impostare il fuso orario del server ThingWorx verrà ignorata come indicato.
|
A.) Prima dell'aggiornamento
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. Scaricare 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
B.) Esportare i dati stream e stream di valori (solo InfluxDB)
| | Quando si utilizza InfluxDB v2, per eseguire l'aggiornamento a ThingWorx 9.3.9 e versioni successive o ThingWorx 9.4.0 e versioni successive, è necessario esportare i dati memorizzati in InfluxDB e importarli in ThingWorx 9.3.9 o ThingWorx 9.4.0. Tuttavia, a causa di un problema noto con le versioni di ThingWorx dalla 9.3.0 fino alla 9.3.7, l'esportazione dei dati Influx viene interrotta. I dati non possono essere esportati da InfluxDB v2 per le versioni di ThingWorx dalla 9.3.0 alla 9.3.7. Questo problema è stato risolto in ThingWorx 9.3.8. Pertanto, per eseguire l'aggiornamento a ThingWorx 9.3.9 e versioni successive o ThingWorx 9.4.0 e versioni successive è necessario eseguire prima l'aggiornamento a ThingWorx 9.3.8. Dopo l'aggiornamento a ThingWorx 9.3.8 è possibile eseguire l'aggiornamento a ThingWorx 9.3.9 o ThingWorx 9.4.0. Per eseguire l'aggiornamento di InfluxDB, attenersi alle istruzioni riportate di seguito. Non è necessario attenersi alla procedura descritta di seguito per eseguire l'aggiornamento a ThingWorx 9.3.8 da ThingWorx 9.3.7 o versioni precedenti. Se si esegue l'aggiornamento a ThingWorx 9.3.9 e versioni successive o ThingWorx 9.4.0 e versioni successive da ThingWorx utilizzando InfluxDB 1.x, attenersi alla procedura descritta di seguito. Non è necessario eseguire l'aggiornamento a ThingWorx 9.3.8 poiché l'esportazione per InfluxDB 1.x funziona correttamente. Se si esegue l'aggiornamento di ThingWorx utilizzando InfluxDB 1.7.x (ThingWorx 8.5.x, 9.0.x) fino a InfluxDB 1.8.x (ThingWorx 9.1.x o 9.2.x), attenersi alla procedura descritta di seguito. |
1. Esportare i dati da InfluxDB (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.
C.) Arrestare ed eliminare l'applicazione Web ThingWorx
1. Arrestare Tomcat.
2. Prima di continuare, è consigliabile eseguire il backup delle due cartelle seguenti:
◦ Apache Software Foundation/Tomcat x.x/webapps/Thingworx
◦ /ThingworxStorage
| | Per conservare le configurazioni SSO dall'installazione esistente, al completamento dell'aggiornamento aggiungere il parametro SSOSecurityContextFilter al file web.xml ricreato. |
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.
D.) Impostare il fuso orario del server ThingWorx
Ignorare questa sezione se si esegue l'aggiornamento su H2.
1. Per tutti gli altri database, controllare le opzioni di Tomcat Java per l'impostazione di configurazione del fuso orario. Se questa impostazione è configurata per UTC (-Duser.timezone=UTC), ignorare i passi rimanenti di questa sezione e passare alla sezione "Aggiornare lo schema e migrare i dati" per il database.
2. Se questa impostazione non è configurata per UTC, determinare il valore del fuso orario corrente per un uso successivo:
◦ Se questa impostazione è configurata per un fuso orario diverso da UTC, annotare il valore del fuso orario per un uso successivo.
◦ Se questa impostazione non è configurata in Tomcat, determinare il valore del fuso orario del sistema operativo in cui è installato Tomcat.
3. Dopo aver annotato uno dei valori di fuso orario sopra indicati e la relativa provenienza (Tomcat o sistema operativo), conservare le informazioni in una posizione accessibile per utilizzarle in un passo successivo.
4. Impostare questa configurazione su UTC:
-Duser.timezone=UTC
E.) Aggiornare lo schema e migrare i dati (solo PostgreSQL)
| | Tutti gli script a cui si fa riferimento di seguito si trovano nella cartella update all'interno del download del software ThingWorx. |
| | Tutti gli script a cui si fa riferimento di seguito richiedono l'accesso al database. Se la variabile di ambiente PGPASSWORD è definita, gli script utilizzeranno il relativo valore come password del database. In caso contrario, gli script richiederanno di specificare la password del database. Per ulteriori informazioni, consultare la documentazione ufficiale di Postgres. |
1. Eseguire lo script di aggiornamento per migrare lo schema ThingWorx:
update_postgres.sh
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: update_postgres.sh -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] ( --update_all | [--update_data] [--update_model] [--update_property] [--update_system] ) [-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. --update_all Update all information (i.e. Data, Model, Property, etc). Same as specifying all other "--update_..." flags. --update_data Update only Data information. Can be specified with any other "--update_..." flags, except "--update_all". --update_model Update only Model information. Can be specified with any other "--update_..." flags, except "--update_all". --update_property Update only Property information. Can be specified with any other "--update_..." flags, except "--update_all". --update_system Update only System information. Can be specified with any other "--update_..." flags, except "--update_all". -y Suppress all non-required prompts, such as "Are you sure?" |
Eseguire gli script del fuso orario per il server ThingWorx
| | L'esecuzione degli script del fuso orario per ThingWorx è necessaria solo quando si esegue l'aggiornamento da ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2 a una nuova versione di ThingWorx. ThingWorx 9.4.0 e versioni successive non supportano aggiornamenti diretti da ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2. È necessario quindi eseguire l'aggiornamento a una versione di ThingWorx intermedia, ad esempio ThingWorx 9.3. Quando si esegue l'aggiornamento da ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2 a ThingWorx 9.3.x, eseguire gli script indicati di seguito. Si consiglia di utilizzare la versione più recente di ThingWorx 9.3.x come versione intermedia. |
I passi di questa sezione devono essere eseguiti solo se non è stato impostato -Duser.timezone=UTC nel passo 1 della sezione "Impostare il fuso orario del server ThingWorx" o se si esegue l'aggiornamento da ThingWorx 8.5. x o versioni precedenti.
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.sh
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: update_bigint_timezone_schema_postgres.sh -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.sh
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: update_bigint_timezone_data_postgres.sh -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.sh
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: cleanup_bigint_timezone_data_update_postgres.sh -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.sh
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: cleanup_update_postgres.sh -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?" |
F.) Aggiornare lo schema e migrare i dati (solo MSSQL)
| | Tutti gli script a cui si fa riferimento di seguito si trovano nella cartella update all'interno del download del software ThingWorx. |
| | Tutti gli script a cui si fa riferimento di seguito richiedono l'accesso al database. Se la variabile di ambiente SQLCMDPASSWORD è definita, gli script utilizzeranno il relativo valore come password del database. In caso contrario, gli script richiederanno di specificare la password del database. Per ulteriori informazioni, vedere la documentazione ufficiale di MSSQL. |
1. Eseguire lo script di aggiornamento per migrare lo schema ThingWorx:
update_mssql.sh
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: update_mssql.sh -h <host> -p <port> -d <database> -u <user> [--managed_instance <name>] ( --update_all | [--update_data] [--update_grants] [--update_model] [--update_property] ) [-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. -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. --update_all Update all information (i.e. Data, Model, Property, etc). Same as specifying all other "--update_..." flags. --update_data Update only Data information. Can be specified with any other "--update_..." flags, except "--update_all". --update_grants Update only Grants information. Can be specified with any other "--update_..." flags, except "--update_all". --update_model Update only Model information. Can be specified with any other "--update_..." flags, except "--update_all". --update_property Update only Property information. Can be specified with any other "--update_..." flags, except "--update_all". -y Suppress all non-required prompts, such as "Are you sure?" |
Eseguire gli script del fuso orario per il server ThingWorx
| | L'esecuzione degli script del fuso orario per ThingWorx è necessaria solo quando si esegue l'aggiornamento da ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2 a una nuova versione di ThingWorx. ThingWorx 9.4.0 e versioni successive non supportano aggiornamenti diretti da ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2. È necessario quindi eseguire l'aggiornamento a una versione di ThingWorx intermedia, ad esempio ThingWorx 9.3. Quando si esegue l'aggiornamento da ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2 a ThingWorx 9.3.x, eseguire gli script indicati di seguito. Si consiglia di utilizzare la versione più recente di ThingWorx 9.3.x come versione intermedia. |
I passi di questa sezione devono essere eseguiti solo se non è stato impostato -Duser.timezone=UTC nel passo 1 della sezione "Impostare il fuso orario del server ThingWorx" o se si esegue l'aggiornamento da ThingWorx 8.5. x o versioni precedenti.
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, current_utc_offset, is_currently_dst FROM sys.time_zone_info 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_mssql.sh
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: update_bigint_timezone_schema_mssql.sh -h <host> -p <port> -d <database> -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. -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?"
|
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_msssql.sh
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: update_bigint_timezone_data_mssql.sh -h <host> -p <port> -d <database> -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. -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_mssql.sh
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: cleanup_bigint_timezone_data_update_mssql.sh -h <host> -p <port> -d <database> -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. -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_mssql.sh
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: cleanup_update_mssql.sh -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 connect to. -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?" |
G.) Aggiornare lo schema e migrare i dati (solo SQL Azure)
| | Tutti gli script a cui si fa riferimento di seguito si trovano nella cartella update all'interno del download del software ThingWorx. |
| | Tutti gli script a cui si fa riferimento di seguito richiedono l'accesso al database. Se la variabile di ambiente SQLCMDPASSWORD è definita, gli script utilizzeranno il relativo valore come password del database. In caso contrario, gli script richiederanno di specificare la password del database. Per ulteriori informazioni, vedere la documentazione ufficiale di MSSQL. |
1. Eseguire lo script di aggiornamento per migrare lo schema ThingWorx:
update_mssql.sh
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: update_mssql.sh -h <host> -p <port> -d <database> -u <user> [--managed_instance <name>] ( --update_all | [--update_data] [--update_grants] [--update_model] [--update_property] ) [-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. -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. --update_all Update all information (i.e. Data, Model, Property, etc). Same as specifying all other "--update_..." flags. --update_data Update only Data information. Can be specified with any other "--update_..." flags, except "--update_all". --update_grants Update only Grants information. Can be specified with any other "--update_..." flags, except "--update_all". --update_model Update only Model information. Can be specified with any other "--update_..." flags, except "--update_all". --update_property Update only Property information. Can be specified with any other "--update_..." flags, except "--update_all". -y Suppress all non-required prompts, such as "Are you sure?" |
Eseguire gli script del fuso orario per il server ThingWorx
| | L'esecuzione degli script del fuso orario per ThingWorx è necessaria solo quando si esegue l'aggiornamento da ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2 a una nuova versione di ThingWorx. ThingWorx 9.4.0 e versioni successive non supportano aggiornamenti diretti da ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2. È necessario quindi eseguire l'aggiornamento a una versione di ThingWorx intermedia, ad esempio ThingWorx 9.3. Quando si esegue l'aggiornamento da ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2 a ThingWorx 9.3.x, eseguire gli script indicati di seguito. Si consiglia di utilizzare la versione più recente di ThingWorx 9.3.x come versione intermedia. |
I passi di questa sezione devono essere eseguiti solo se non è stato impostato -Duser.timezone=UTC nel passo 1 della sezione "Impostare il fuso orario del server ThingWorx" o se si esegue l'aggiornamento da ThingWorx 8.5. x o versioni precedenti.
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, current_utc_offset, is_currently_dst FROM sys.time_zone_info 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_mssql.sh
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: update_bigint_timezone_schema_mssql.sh -h <host> -p <port> -d <database> -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. -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?"
|
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_msssql.sh
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: update_bigint_timezone_data_mssql.sh -h <host> -p <port> -d <database> -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. -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 di tutti i 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_mssql.sh
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: cleanup_bigint_timezone_data_update_mssql.sh -h <host> -p <port> -d <database> -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. -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_mssql.sh
| | Se si esegue questo script senza argomenti, viene stampata la relativa istruzione con sintassi: Usage: cleanup_update_mssql.sh -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 connect to. -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?" |
H.) Eseguire l'aggiornamento a Java 11
| | 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.
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.
I.) Distribuire il file ThingWorx.war e riavviare
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>
},
"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"
}
},
"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>
J.) Importare i dati stream e stream di valori (solo InfluxDB)
| | Se si esegue un aggiornamento che richiede l'esportazione dei dati memorizzati in InfluxDB e la loro importazione in una nuova versione di ThingWorx, attenersi alla procedura descritta in questa sezione. Vedere la sezione B per determinare se è necessario eseguire un aggiornamento tramite esportazione e importazione. |
1. Creare un nuovo provider di persistenza per InfluxDB o fornire nuove informazioni di connessione al provider di persistenza 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.
K.) Aggiornare i componenti aggiuntivi
• 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.
L.) 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.
M.) Risoluzione dei problemi
• 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 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. |