Actualización manual local a la versión 9.0.x, 9.1.x y 9.2.x: Linux

1. Si el sistema operativo es RHEL, verifique que se ha actualizado a la versión soportada antes de realizar una actualización de ThingWorx. Consulte Requisitos del sistema para obtener más información.

ThingWorx 9.1 solo se soporta en RHEL 8.2.

2. Antes de comenzar la actualización, se recomienda realizar lo siguiente:

◦ Volcado de la base de datos

◦ Realice una copia de seguridad de todos los datos de las carpetas ThingworxStorage y ThingworxPlatform.

◦ Realice una copia de seguridad de la carpeta Tomcat_home. Esto incluye las carpetas bin, conf, lib, temp, webapps y work.

3. Si se utiliza ThingWorx Apps además de ThingWorx Platform:

a. Verifique que la versión de ThingWorx a la que se está actualizando se soporta con la versión de ThingWorx Apps. Consulte ThingWorx Apps Upgrade Support Matrix.

b. Se deben seguir algunos pasos antes de actualizar la plataforma. Consulte Upgrading ThingWorx Apps antes de continuar con el siguiente paso.

4. Si también se ha instalado Navigate, verifique la compatibilidad en ThingWorx Navigate Compatibility Matrix.

5. Obtenga la versión más reciente de ThingWorx en Descargas de software de PTC.

Descargue y extraiga el contenido de ThingWorx en una carpeta para la que el usuario actual tenga permisos de escritura. Se requieren permisos de escritura porque los scripts de actualización crean algunos ficheros en el proceso.

6. Verifique que se estén ejecutando las versiones requeridas de Tomcat y Java. Consulte la sección Requisitos del sistema para conocer los requisitos de la versión.

Si es necesario actualizar la versión de Java, realice la actualización de ThingWorx antes de actualizar Java.

7. Si se actualiza MSSQL, Azure SQL o H2, la actualización fallará si falta alguno de los valores de campo de índice personalizado en las tablas de datos. Verifique que todos los campos de índice personalizados tengan valores antes de iniciar el proceso de actualización.

Si no lo hace, la actualización no se realizará correctamente y se tendrá que volver a implementar la versión anterior (si se han realizado actualizaciones del esquema, se debe revertir o restaurar la base de datos), añadir los valores de índice que faltan o quitar los índices personalizados de la tabla de datos y, a continuación, realizar la actualización.

8. Añada lo siguiente a las opciones de Java de Apache Tomcat:

-Dlog4j2.formatMsgNoLookups=true

Los pasos de esta sección solo son necesarios si se actualiza ThingWorx con InfluxDB 1.7.x (para ThingWorx 8.5.x o 9.0.x) a InfluxDB 1.8.x (para ThingWorx 9.1.x o 9.2.x).

1. Exportación de datos desde InfluxDB 1.7.x/MS SQL/PostgreSQL:

a. Conéctese a ThingWorx como administrador.

b. Pulse en Importar/Exportar > Exportar.

c. Utilice las siguientes opciones:

▪ Para Opción de exportación, seleccione A fichero.

▪ Para Tipo de exportación, seleccione Recopilación de datos.

▪ Para Recopilación, seleccione Flujos.

▪ Pulse en Exportar.

d. Repita desde el paso A hasta el paso C en el caso de los datos de flujo de valor.

e. Mueva la carpeta exportada para los datos de flujo y de flujo de valor creados desde el almacén del sistema a una ubicación segura como copia de seguridad.

1. Detenga Tomcat.

2. Se recomienda encarecidamente realizar una copia de seguridad de las siguientes dos carpetas antes de continuar:

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

◦ /ThingWorxStorage

3. Si la versión actual de Tomcat es más antigua y no se soporta en la versión de ThingWorx de destino, actualice a la versión de Tomcat soportada.

4. Para conservar las configuraciones de SSO de la instalación existente, haga una copia de seguridad del fichero web.xml de la carpeta <Directorio de instalación de Tomcat>\webapps\Thingworx\WEB-INF.

5. Realice una copia de seguridad y borre el fichero validation.properties del directorio /ThingworxStorage/esapi.

El fichero validation.properties se crea al iniciar ThingWorx. Si desea conservar los cambios realizados, guarde el fichero fuera del directorio ThingworxStorage y, a continuación, elimine el directorio esapi. Al iniciar, ThingWorx volverá a crear el fichero y se podrán añadir los regex personalizados de nuevo al fichero validation.properties que se ha generado automáticamente.

Consulte este tema para obtener información adicional.

6. Vaya a la instalación de Tomcat en /Apache Software Foundation/Tomcat x.x/webapps y borre el fichero Thingworx.war y la carpeta Thingworx.

Omita este paso si está actualizando en H2. Para todas las demás bases de datos, añada el siguiente parámetro a las opciones Java de Tomcat con el fin de definir la zona horaria del servidor de ThingWorx:

-Duser.timezone=UTC

Solo se requiere el paso 1 de esta sección para todas las actualizaciones.

Realice los pasos que se indican en el resto de esta sección si se está actualizando desde ThingWorx 8.4.x u 8.5.x --> 9.0.x, 9.1.x o 9.2.x.

Omita los pasos del resto de esta sección si se está actualizando desde ThingWorx 9.0.x o 9.1.x --> 9.1.x o 9.2.x

1. Ejecute los siguientes scripts que se encuentran en la carpeta update del software descargado de ThingWorx (empezando por la versión desde la que se actualiza):

thingworxPostgresSchemaUpdate8.4-to-8.5.sh

thingworxPostgresSchemaUpdate8.5-to-9.0.sh

thingworxPostgresSchemaUpdate9.1-to-9.2.sh

No es necesario ejecutar el script thingworxPostgresSchemaUpdate9.0-to-9.1.sh porque no hay actualizaciones de esquema en 9.1. Aunque el script se incluye en la carpeta update por integridad, se encuentra vacío y está destinado solo a usuarios con procesos de actualización automatizados.

Los pasos del resto de esta sección solo se deben realizar si se actualiza desde ThingWorx 8.4.x u 8.5.x a 9.0.x, 9.1.x o 9.2.x. Omita los pasos del resto de esta sección si actualiza desde ThingWorx 9.0.x a 9.1.x o 9.2.x.

2. Ejecute el script de configuración de número entero grande/zona horaria para preparar la base de datos para la migración:

Si ya se está ejecutando ThingWorx en UTC, sigue siendo necesario ejecutar la migración para los cambios de enteros grandes, pero se puede proporcionar a los parámetros sourceTZ y targetTZ (disponibles en algunos scripts de los pasos de más abajo) el valor de UTC.

thingworxPostgresDBSetupBigIntTimezoneDataUpdate.sh

3. Para buscar todas las zonas horarias soportadas, utilice el siguiente comando:

select pg_timezone_names()

Al especificar las zonas horarias para los scripts de migración de datos siguientes, los nombres de zona horaria especificados deben coincidir exactamente con uno de los nombres formales que muestra el script pg_timezone_names().

4. Ejecute el script de migración de modelos para migrar todos los datos del modelo:

Antes de ejecutar el script, ábralo en un editor de texto para asegurarse de que los valores de entorno por defecto (como el servidor, el puerto, las zonas horarias, etc.) sean correctos y suficientes para el entorno. Si los valores por defecto definidos en el script no parecen apropiados para el entorno, reemplace los valores por defecto al ejecutar el script especificando uno o más argumentos de línea de comandos.

thingworxPostgresModelTablesDataUpdate.sh

Uso:

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>]

Ejemplo:

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

5. Ejecute cada uno de los siguientes scripts de migración de esquema para crear tablas de copia de seguridad de todos los datos de tabla de datos, flujo y flujo de valor:

Por motivos de rendimiento, estos scripts no crean realmente una copia de los datos originales en estas tablas. En su lugar, estos scripts cambiarán el nombre de las tablas existentes de "<nombre-tabla-original>" a "<nombre-tabla-original>_backup". Así se evita el proceso de copiar realmente los datos que puede tardar mucho tiempo. Una vez que se cambie el nombre de las tablas existentes (por lo tanto, se han convertido en tablas de copia de seguridad), se crearán nuevas tablas con los nombres originales. Estas tablas nuevas están vacías y sirven para el mismo propósito que las tablas originales (porque tienen los mismos nombres que las tablas originales). Estas nuevas tablas se rellenarán con datos migrados en pasos posteriores.

thingworxPostgresDataTableSchemaUpdate.sh

thingworxPostgresStreamSchemaUpdate.sh

thingworxPostgresValueStreamSchemaUpdate.sh

6. Abra una nueva ventana del símbolo del sistema y ejecute el siguiente script de migración de datos para migrar los datos de la tabla de datos dentro de la tabla de copia de seguridad:

Antes de ejecutar el script, ábralo en un editor de texto para asegurarse de que los valores de entorno por defecto (como el servidor, el puerto, las zonas horarias, etc.) sean correctos y suficientes para el entorno. Si los valores por defecto definidos en el script no parecen apropiados para el entorno, reemplace los valores por defecto al ejecutar el script especificando uno o más argumentos de línea de comandos.

thingworxPostgresDataTableDataUpdate.sh

Uso:

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>]

Ejemplo:

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

Una vez iniciado este script de migración, espere a que se muestre un mensaje en la consola que indique que es seguro reiniciar Tomcat. Una que se muestre el mensaje, es seguro continuar en el siguiente paso, incluso si el script de migración todavía no ha finalizado la ejecución.

7. Abra una nueva ventana del símbolo del sistema y ejecute los siguientes scripts de migración de datos para migrar los datos de flujo y flujo de valor desde las tablas de copia de seguridad:

Antes de ejecutar el script, ábralo en un editor de texto para asegurarse de que los valores de entorno por defecto (como el servidor, el puerto, las zonas horarias, etc.) sean correctos y suficientes para el entorno. Si los valores por defecto definidos en el script no parecen apropiados para el entorno, reemplace los valores por defecto al ejecutar el script especificando uno o más argumentos de línea de comandos.

thingworxPostgresStreamDataUpdate.sh

thingworxPostgresValueStreamDataUpdate.sh

Usos:

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>]

Ejemplos:

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

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

Una vez iniciados estos dos scripts de migración, no continúe en el siguiente paso hasta que estos scripts de migración, así como el script de migración de la tabla de datos (iniciado en un paso anterior), se hayan completado correctamente.

8. Verifique manualmente que los siguientes scripts se hayan completado correctamente: thingworxPostgresDataTableDataUpdate.sh, thingworxPostgresStreamDataUpdate.sh y thingworxPostgresValueStreamDataUpdate.sh. Verifique que todos los datos de tabla de datos, flujo y flujo de valor se hayan migrado correctamente.

9. Ejecute el script de limpieza para quitar los objetos de base de datos temporales necesarios durante la migración:

Aunque este script realiza alguna limpieza de los objetos de base de datos temporales creados durante el proceso de actualización, este script *no* borra ninguna de las tablas de copia de seguridad creadas en los pasos anteriores, ni tampoco modifica los datos de las tablas de copia de seguridad. Esto es intencionado y garantiza que los datos no se puedan borrar accidentalmente. Si desea borrar estas tablas de copia de seguridad, debe hacerlo manualmente.

thingworxPostgresDBCleanupBigIntTimezoneDataUpdate.sh

Resolución de problemas de script

Se deben ejecutar los siguientes comandos en la base de datos de ThingWorx.

• El código de error 23505 significa que se ha producido una infracción de restricción única de clave duplicada en la inserción. Para resolver este problema:

a. Ejecute el siguiente comando:

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

b. Registre los rangos para fromId y toId de las filas devueltas.

c. Consulte en la tabla de datos los elementos entry_ids anotados del registro de migración.

d. Si todos los registros están allí, para cualquiera de estos rangos, cambie 0 o -1 a 1. Si faltan parcialmente registros de un rango, pruebe con un tamaño de fragmento más pequeño o borre los registros que ya se han migrado a la tabla y vuelva a intentar la migración.

• Para buscar todas las zonas horarias soportadas, utilice el siguiente comando:

select pg_timezone_names()

Se debe utilizar el nombre formal, que se muestra en primer lugar, para que PostgreSQL resuelva automáticamente el desvío y se desplace la fecha desde, en función de la fecha especificada.

• Para verificar que se han migrado todos elementos entry_ids, utilice una consulta SQL similar a la siguiente:

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

• Si se utiliza la variable de entorno PGPASSWORD en el sistema, se debe pasar esa variable al parámetro -r para definir la contraseña con la que se deben ejecutar los scripts.

Solo se requiere el paso 1 de esta sección para todas las actualizaciones.

Realice los pasos que se indican en el resto de esta sección si se está actualizando desde ThingWorx 8.4.x u 8.5.x --> 9.0.x, 9.1.x o 9.2.x.

Omita los pasos del resto de esta sección si se está actualizando desde ThingWorx 9.0.x o 9.1.x --> 9.1.x o 9.2.x

1. Copie toda la carpeta update que se encuentra en el software descargado de ThingWorx en el servidor MS SQL y ejecute los siguientes scripts que se encuentran en la carpeta update (comenzando por la versión desde la que se actualiza):

thingworxMssqlSchemaUpdate8.4-to-8.5.sh

thingworxMssqlSchemaUpdate8.5-to-9.0.sh

thingworxMssqlSchemaUpdate9.1-to-9.2.sh

No es necesario ejecutar el script thingworxMssqlSchemaUpdate9.0-to-9.1.sh porque no se ha producido ningún cambio de esquema en 9.1. Aunque el script se incluye en la carpeta update por integridad, se encuentra vacío y está destinado solo a usuarios con procesos de actualización automatizados.

Los pasos del resto de esta sección solo se deben realizar si se actualiza desde ThingWorx 8.4.x u 8.5.x a 9.0.x, 9.1.x o 9.2.x. Omita los pasos del resto de esta sección si actualiza desde ThingWorx 9.0.x a 9.1.x o 9.2.x.

2. Ejecute el script de configuración de número entero grande/zona horaria para preparar la base de datos para la migración:

Si ya se está ejecutando ThingWorx en UTC, sigue siendo necesario ejecutar la migración para los cambios de enteros grandes, pero se puede proporcionar a los parámetros sourceTZ y targetTZ (disponibles en algunos scripts de los pasos de más abajo) el valor de UTC.

thingworxMssqlDBSetupBigIntTimezoneDataUpdate.sh

3. Ejecute el script de migración de modelos para migrar todos los datos del modelo:

Antes de ejecutar el script, ábralo en un editor de texto para asegurarse de que los valores de entorno por defecto (como el servidor, el puerto, las zonas horarias, etc.) sean correctos y suficientes para el entorno. Si los valores por defecto definidos en el script no parecen apropiados para el entorno, reemplace los valores por defecto al ejecutar el script especificando uno o más argumentos de línea de comandos.

thingworxMssqlModelTablesDataUpdate.sh

Uso:

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

Ejemplo:

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

4. Ejecute cada uno de los siguientes scripts de migración de esquema para crear tablas de copia de seguridad de todos los datos de tabla de datos, flujo y flujo de valor.

Por motivos de rendimiento, estos scripts no crean realmente una copia de los datos originales en estas tablas. En su lugar, estos scripts cambiarán el nombre de las tablas existentes de "<nombre-tabla-original>" a "<nombre-tabla-original>_backup". Así se evita el proceso de copiar realmente los datos que puede tardar mucho tiempo. Una vez que se cambie el nombre de las tablas existentes (por lo tanto, se han convertido en tablas de copia de seguridad), se crearán nuevas tablas con los nombres originales. Estas tablas nuevas están vacías y sirven para el mismo propósito que las tablas originales (porque tienen los mismos nombres que las tablas originales). Estas nuevas tablas se rellenarán con datos migrados en pasos posteriores.

thingworxMssqlDataTableSchemaUpdate.sh

thingworxMssqlStreamSchemaUpdate.sh

thingworxMssqlValueStreamSchemaUpdate.sh

5. Abra una nueva ventana del símbolo del sistema y ejecute el siguiente script de migración de datos para migrar los datos de la tabla de datos dentro de la tabla de copia de seguridad:

Antes de ejecutar el script, ábralo en un editor de texto para asegurarse de que los valores de entorno por defecto (como el servidor, el puerto, las zonas horarias, etc.) sean correctos y suficientes para el entorno. Si los valores por defecto definidos en el script no parecen apropiados para el entorno, reemplace los valores por defecto al ejecutar el script especificando uno o más argumentos de línea de comandos.

thingworxMssqlDataTableDataUpdate.sh

Uso:

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>]

Ejemplo:

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

Una vez iniciado este script de migración, espere a que se muestre un mensaje en la consola que indique que es seguro reiniciar Tomcat. Una que se muestre el mensaje, es seguro continuar en el siguiente paso, incluso si el script de migración todavía no ha finalizado la ejecución.

6. Abra una nueva ventana del símbolo del sistema y ejecute los siguientes scripts de migración de datos para migrar los datos de flujo y flujo de valor desde las tablas de copia de seguridad:

Antes de ejecutar el script, ábralo en un editor de texto para asegurarse de que los valores de entorno por defecto (como el servidor, el puerto, las zonas horarias, etc.) sean correctos y suficientes para el entorno. Si los valores por defecto definidos en el script no parecen apropiados para el entorno, reemplace los valores por defecto al ejecutar el script especificando uno o más argumentos de línea de comandos.

thingworxMssqlStreamDataUpdate.sh

thingworxMssqlValueStreamDataUpdate.sh

Usos:

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>]

Ejemplos:

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

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

Una vez iniciados estos dos scripts de migración, no continúe en el siguiente paso hasta que estos scripts de migración, así como el script de migración de la tabla de datos (iniciado en un paso anterior), se hayan completado correctamente.

7. Verifique manualmente que todos los siguientes scripts se hayan completado correctamente: thingworxMssqlDataTableDataUpdate.sh, thingworxMssqlStreamDataUpdate.sh y thingworxMssqlValueStreamDataUpdate.sh, y verifique que todos los datos de tabla de datos, flujo y flujo de valor se hayan migrado correctamente.

8. Ejecute el script de limpieza para quitar los objetos de base de datos temporales necesarios durante la migración:

Aunque este script realiza alguna limpieza de los objetos de base de datos temporales creados durante el proceso de actualización, este script *no* borra ninguna de las tablas de copia de seguridad creadas en los pasos anteriores, ni tampoco modifica los datos de las tablas de copia de seguridad. Esto es intencionado y garantiza que los datos no se puedan borrar accidentalmente. Si desea borrar estas tablas de copia de seguridad, debe hacerlo manualmente.

thingworxMssqlDBCleanupBigIntTimezoneDataUpdate.sh

Resolución de problemas de script

• Para buscar todas las zonas horarias soportadas, utilice el siguiente comando:

select * from sys.time_zone_info

• Para verificar que se han migrado todos elementos entry_ids, utilice una consulta SQL similar a la siguiente:

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 se requiere el paso 1 de esta sección para todas las actualizaciones.

Realice los pasos que se indican en el resto de esta sección si se está actualizando desde ThingWorx 8.4.x u 8.5.x --> 9.0.x, 9.1.x o 9.2.x.

Omita los pasos del resto de esta sección si se está actualizando desde ThingWorx 9.0.x o 9.1.x --> 9.1.x o 9.2.x

1. Ejecute el siguiente script que se encuentra en la carpeta update del software descargado de ThingWorx (empezando por la versión desde la que se actualiza):

El número de permisos que existen en la plataforma puede afectar al tiempo que la actualización tarda en completarse. Más permisos pueden aumentar el tiempo que tarda la actualización.

thingworxAzureSchemaUpdate8.4-to-8.5.sh

thingworxAzureSchemaUpdate8.5-to-9.0.sh

thingworxAzureSchemaUpdate9.1-to-9.2.sh

No es necesario ejecutar el script thingworxAzureSchemaUpdate9.0-to-9.1.sh porque no hay actualizaciones de esquema en 9.1. Aunque el script se incluye en la carpeta update por integridad, se encuentra vacío y está destinado solo a usuarios con procesos de actualización automatizados.

Uso:

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

Ejemplo:

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

2. Ejecute el script de configuración de número entero grande/zona horaria para preparar la base de datos para la migración:

Si ya se está ejecutando ThingWorx en UTC, sigue siendo necesario ejecutar la migración para los cambios de enteros grandes, pero se puede proporcionar a los parámetros sourceTZ y targetTZ (disponibles en algunos scripts de los pasos de más abajo) el valor de UTC.

thingworxAzureDBSetupBigIntTimezoneDataUpdate.sh

3. Ejecute el script de migración de modelos para migrar todos los datos del modelo:

Antes de ejecutar el script, ábralo en un editor de texto para asegurarse de que los valores de entorno por defecto (como el servidor, el puerto, las zonas horarias, etc.) sean correctos y suficientes para el entorno. Si los valores por defecto definidos en el script no parecen apropiados para el entorno, reemplace los valores por defecto al ejecutar el script especificando uno o más argumentos de línea de comandos.

thingworxAzureModelTablesDataUpdate.sh

Uso:

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

Ejemplo:

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

4. Ejecute cada uno de los siguientes scripts de migración de esquema para crear tablas de copia de seguridad de todos los datos de tabla de datos, flujo y flujo de valor.

Por motivos de rendimiento, estos scripts no crean realmente una copia de los datos originales en estas tablas. En su lugar, estos scripts cambiarán el nombre de las tablas existentes de "<nombre-tabla-original>" a "<nombre-tabla-original>_backup". Así se evita el proceso de copiar realmente los datos que puede tardar mucho tiempo. Una vez que se cambie el nombre de las tablas existentes (por lo tanto, se han convertido en tablas de copia de seguridad), se crearán nuevas tablas con los nombres originales. Estas tablas nuevas están vacías y sirven para el mismo propósito que las tablas originales (porque tienen los mismos nombres que las tablas originales). Estas nuevas tablas se rellenarán con datos migrados en pasos posteriores.

Se muestra el siguiente aviso previsto al ejecutar el script: 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. Abra una nueva ventana del símbolo del sistema y ejecute el siguiente script de migración de datos para migrar los datos de la tabla de datos dentro de la tabla de copia de seguridad:

Antes de ejecutar el script, ábralo en un editor de texto para asegurarse de que los valores de entorno por defecto (como el servidor, el puerto, las zonas horarias, etc.) sean correctos y suficientes para el entorno. Si los valores por defecto definidos en el script no parecen apropiados para el entorno, reemplace los valores por defecto al ejecutar el script especificando uno o más argumentos de línea de comandos.

thingworxAzureDataTableDataUpdate.sh

Uso:

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

Ejemplo:

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

Una vez iniciado este script de migración, espere a que se muestre un mensaje en la consola que indique que es seguro reiniciar Tomcat. Una que se muestre el mensaje, es seguro continuar en el siguiente paso, incluso si el script de migración todavía no ha finalizado la ejecución.

6. Abra una nueva ventana del símbolo del sistema y ejecute los siguientes scripts de migración de datos para migrar los datos de flujo y flujo de valor desde las tablas de copia de seguridad:

Antes de ejecutar el script, ábralo en un editor de texto para asegurarse de que los valores de entorno por defecto (como el servidor, el puerto, las zonas horarias, etc.) sean correctos y suficientes para el entorno. Si los valores por defecto definidos en el script no parecen apropiados para el entorno, reemplace los valores por defecto al ejecutar el script especificando uno o más argumentos de línea de comandos.

thingworxAzureStreamDataUpdate.sh

thingworxAzureValueStreamDataUpdate.sh

Usos:

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]

Ejemplos:

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

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

Una vez iniciados estos dos scripts de migración, no continúe en el siguiente paso hasta que estos scripts de migración, así como el script de migración de la tabla de datos (iniciado en un paso anterior), se hayan completado correctamente.

7. Verifique manualmente que los siguientes scripts se hayan completado correctamente: thingworxAzureDataTableDataUpdate.sh, thingworxAzureStreamDataUpdate.sh y thingworxAzureValueStreamDataUpdate.sh. Verifique que todos los datos de tabla de datos, flujo y flujo de valor se hayan migrado correctamente.

8. Ejecute el script de limpieza para quitar los objetos de base de datos temporales necesarios durante la migración:

Aunque este script realiza alguna limpieza de los objetos de base de datos temporales creados durante el proceso de actualización, este script *no* borra ninguna de las tablas de copia de seguridad creadas en los pasos anteriores, ni tampoco modifica los datos de las tablas de copia de seguridad. Esto es intencionado y garantiza que los datos no se puedan borrar accidentalmente. Si desea borrar estas tablas de copia de seguridad, debe hacerlo manualmente.

thingworxAzureDBCleanupBigIntTimezoneDataUpdate.sh

Se requiere Java 11 para ThingWorx 9.2.0 y versiones posteriores. Consulte los requisitos del sistema para obtener más información.

1. Si se actualiza a Java 11, se requieren los siguientes pasos. Omita esta sección si ya se ha instalado Java 11.

a. Descargue OpenJDK o Java 11.

b. Instale jEnv en Linux:

i. Ejecute git clone para el almacén de jEnv:

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

ii. Añada jEnv a $PATH:

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

iii. Inicialice jEnv:

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

iv. Actualice los cambios realizados en ~/.bash_profile:

source ~/.bash_profile

v. Defina la variable de entorno CARPETA_PRINCIPAL_JAVA:

jenv enable-plugin export

vi. Reinicie la sesión de shell actual:

exec $SHELL -l

vii. Ejecute el siguiente comando y jEnv definirá automáticamente la variable CARPETA_PRINCIPAL_JAVA, según el entorno de Java activo actualmente:

jenv doctor

c. Añada entornos de Java:

i. Añada cualquier entorno. Todas las instalaciones de Java se encuentran en /usr/lib/jvm/. Utilice el comando jenv add. Encontrará ejemplos a continuación:

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

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

ii. Compruebe todas las versiones de Java disponibles en jenv:

jenv versions

iii. Defina el entorno global de Java:

jenv global <version>

iv. Defina el entorno específico de shell de Java:

jenv shell <version>

v. Verifique la versión actual definida por jenv:

jenv versions

vi. Actualice la ruta en la configuración de Java de Tomcat.

1. Copie el nuevo fichero Thingworx.war y colóquelo en la siguiente ubicación de la instalación de Tomcat: /Apache Software Foundation/Tomcat x.x/webapps.

2. Active la importación de extensión. Por defecto, la importación de extensión está desactivada para todos los usuarios. Añada lo siguiente al fichero platform-settings.json. Añada o actualice los siguientes parámetros de ExtensionPackageImportPolicy a verdadero para permitir la importación de las extensiones.

"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. Si se utiliza H2 como una base de datos con ThingWorx, se debe añadir un nombre de usuario y una contraseña al fichero platform-settings.json.

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

4. Inicie Tomcat.

5. Para restaurar las configuraciones de SSO:

a. Copie el bloque SSOSecurityContextFilter de la copia de seguridad del fichero web.xml.

b. En el fichero web.xm recién creado, pegue el bloque SSOSecurityContextFilter después del último bloque AuthenticationFilter.

6. Para iniciar ThingWorx, vaya a <nombre_servidor>\Thingworx en un explorador Web. Utilice la siguiente información de conexión:

◦ Nombre de conexión: Administrator

◦ Contraseña: <contraseña de administrador del servidor de origen>

Los pasos de esta sección solo son necesarios si se actualiza ThingWorx con InfluxDB 1.7.x (para ThingWorx 8.5.x o 9.0.x) a InfluxDB 1.8.x (para ThingWorx 9.1.x o 9.2.x).

1. Cree un nuevo proveedor de persistencia para InfluxDB 1.8.x o proporcione nueva información de conexión al proveedor de persistencia de la versión 1.7.x existente.

2. Importe los datos de flujo y flujo de valor al servidor. Realice los siguientes pasos para los datos de flujo y flujo de valor.

a. Conéctese a ThingWorx 9.x como administrador.

b. Pulse en Importar/Exportar > Importar.

c. Utilice las siguientes opciones:

i. Para Opciones de importación, seleccione Desde fichero.

ii. Para Tipo de importación, seleccione Datos.

iii. Para Origen de importación, seleccione Almacén de ficheros.

iv. Para Almacén de ficheros, seleccione Sistema.

v. Para Ruta, proporcione una ruta válida del almacén del sistema.

• Si se utilizan conectores de integración, se debe obtener e instalar la versión más reciente de Integration Runtime. Para obtener más información, consulte Configuración inicial del servicio Integration Runtime para conectores de integración.

• Si se actualiza el controlador JDBC de MSSQL, verifique los Requisitos del sistema y consulte la sección Configuración de ThingWorx para MSSQL para encontrar el controlador adecuado.

• Si se ha actualizado de 8.x a 9.x y tiene extensiones de Java, consulte la sección Migración de las extensiones de Java de 8.x a 9.x.

• Si se utiliza ThingWorx Analytics como parte de la solución, hay dos instaladores disponibles para gestionar las actualizaciones de componentes:

◦ Analytics Server: permite instalar o actualizar Analytics Server y Analytics Extension

◦ Platform Analytics: permite instalar o actualizar la analítica descriptiva y las transformaciones de propiedades.

Para obtener más información sobre los procedimientos de actualización, consulte Actualización, modificación o reparación de ThingWorx Analytics.

Si se está actualizando a ThingWorx 9.2. x o una versión posterior, se debe ejecutar el script de limpieza para quitar las tablas temporales creadas durante el proceso de actualización.

Ejecute el script de limpieza thingworx<nombre_base_datos>DBCleanupPermissionTempTableUpdate.sh que se encuentra en <installDir>/schema/update.

El script toma parámetros, como los siguientes:

-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)

Se le pedirá que introduzca la contraseña del usuario de la base de datos, que se transmite en los parámetros -u o -l.

• Si la actualización ha fallado debido a que faltan valores para los campos de índice personalizados, se debe volver a implementar la versión anterior (si se han realizado actualizaciones del esquema, se debe retrotraer/restaurar la base de datos) y añadir los valores de índice que faltan o quitar los índices personalizados de la tabla de datos y, a continuación, actualizar.

Después de iniciar ThingWorx Platform, verifique el registro de la aplicación para la plataforma. Si se utiliza MSSQL, PostgreSQL o H2, pueden aparecer los siguientes mensajes de error de conflicto de propiedades.

Resolución de problemas de errores
Error de registro de aplicación	Resolución
Error in copying permissions: Problems migrating database	Este error de migración aparece en las actualizaciones de MSSQL y se muestra si hay algún nombre de servicio, propiedad o evento migrado con permisos de tiempo de ejecución configurados que contiene más de 256 caracteres. Para corregir este error, limite todos los nombres de servicio, propiedad y evento a menos de 256 caracteres.
[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.	Como parte de la función de presencia de cosa añadida a ThingWorx Platform 8.4, se han añadido las siguientes propiedades a la definición de cosa notificable y se utilizan como parte de la evaluación de la presencia en las cosas que implementan esta definición: • isReporting • reportingLastChange • reportingLastEvaluation Si uno de los nombres de propiedad anteriores existía anteriormente en una cosa, una plantilla de cosa o una definición de cosa, aparecerán los siguientes errores en el registro de aplicación cuando se inicie la plataforma. Para resolver este problema, se debe quitar la propiedad en conflicto en cada entidad afectada y se deben actualizar las entidades asociadas para ajustarse a este cambio (por ejemplo, mashups o servicios). Sin esta actualización, las cosas asociadas no pueden mostrar su estado de informe correctamente y no se pueden actualizar ni guardar. Una vez que estas entidades se hayan actualizado correctamente, las propiedades de informes específicas de la plataforma se mostrarán y se utilizarán para evaluar si un dispositivo está conectado y se está comunicando.
[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.