Actualización manual de Linux
Actualización manual local a la versión 9.3.x y posteriores: Linux
 |
A partir de ThingWorx 9.4.0, los clientes no pueden actualizar directamente desde ThingWorx 8.5 o ThingWorx 9.0 a ThingWorx 9.4.0. Los clientes que deseen actualizar a ThingWorx 9.4.0 y versiones posteriores a partir de ThingWorx 8.5 o ThingWorx 9.0 deben actualizar a una versión intermedia y, a continuación, a ThingWorx 9.4.0 y versiones posteriores. En ThingWorx se recomienda utilizar la versión más reciente de ThingWorx 9.3.x como ruta de actualización intermedia.
|
Consulte la tabla de actualización para determinar la ruta de actualización. Los siguientes pasos solo son para la actualización local. Para obtener una actualización de migración, consulte la sección Migración manual a ThingWorx 9.x: Linux.
A) Antes de la actualización
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. Descargue 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 o Azure SQL, 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
9. Asegúrese de cerrar todas las conexiones de base de datos antes de iniciar la actualización. Para obtener más información, consulte lo siguiente.
◦ PostgreSQL: sistema de estadísticas acumuladas
B) Exportación de datos de flujo y de flujo de valor (solo InfluxDB)
| | Cuando se utiliza InfluxDB v2, para actualizar a ThingWorx 9.3.9 y versiones posteriores o ThingWorx 9.4.0 y versiones posteriores, es necesario exportar los datos almacenados en InfluxDB e importarlos en ThingWorx 9.3.9 o ThingWorx 9.4.0. Sin embargo, debido a un problema conocido con ThingWorx 9.3.0 a 9.3.7, la exportación de datos de Influx se interrumpe. Los datos no se pueden exportar de InfluxDB v2 de ThingWorx 9.3.0 a ThingWorx 9.3.7. Este problema se ha corregido en ThingWorx 9.3.8. Por lo tanto, para actualizar a ThingWorx 9.3.9 y versiones posteriores, o ThingWorx 9.4.0 y versiones posteriores; primero se debe actualizar a ThingWorx 9.3.8. Una vez actualizado a ThingWorx 9.3.8, se puede actualizar a ThingWorx 9.3.9 o ThingWorx 9.4.0. Siga las instrucciones que se indican a continuación para actualizar InfluxDB. No es necesario seguir los siguientes pasos para actualizar a ThingWorx 9.3.8 desde ThingWorx 9.3.7 o versiones anteriores. Para actualizar a ThingWorx 9.3.9 y versiones posteriores o ThingWorx 9.4.0 y versiones posteriores, desde ThingWorx utilizando InfluxDB 1.x, realice los siguientes pasos. No es necesario actualizar a ThingWorx 9.3.8, ya que la exportación de InfluxDB 1.x funciona correctamente. Para actualizar ThingWorx con InfluxDB 1.7.x (ThingWorx 8.5.x, 9.0.x) a InfluxDB 1.8.x (ThingWorx 9.1.x o 9.2.x), realice los siguientes pasos. |
1. Exportación de datos desde InfluxDB 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.
C) Detención y borrado de la aplicación Web de ThingWorx
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
| | Para conservar las configuraciones de SSO de la instalación existente, añada el parámetro SSOSecurityContextFilter al fichero web.xml recreado, una vez completada la actualización. |
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.
D) Actualización del esquema y migración de datos (solo PostgreSQL)
| | Todos los scripts a los que se hace referencia a continuación, se encuentran en la carpeta update de la descarga de software de ThingWorx. |
| | Todos los scripts a los que se hace referencia a continuación requieren acceso a la base de datos. Si se define la variable de entorno PGPASSWORD, los scripts utilizarán su valor como contraseña de la base de datos. De lo contrario, los scripts solicitarán al usuario la contraseña de la base de datos. Consulte la documentación oficial de Postgres para obtener más información. |
1. Ejecute el script de actualización principal para realizar la migración del esquema de ThingWorx:
update_postgres.sh
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
Ejecución de scripts de zona horaria del servidor ThingWorx
| | Solo es necesario ejecutar scripts de zona horaria de ThingWorx para actualizar de ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2 a una nueva versión de ThingWorx. ThingWorx 9.4.0 y versiones posteriores no soportan actualizaciones directas desde ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2. En su lugar, los clientes deben actualizar a una versión de ThingWorx intermedia, como ThingWorx 9.3. Al actualizar desde ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2 a ThingWorx 9.3.x, ejecute los siguientes scripts. En ThingWorx se recomienda utilizar la versión más reciente de ThingWorx 9.3.x como versión intermedia. |
Los pasos de la sección solo se deben realizar si -Duser.timezone=UTC no se ha definido en el paso 1 de la sección "Definición de la zona horaria del servidor de ThingWorx" o si se está actualizando desde ThingWorx 8.5.x o una versión anterior.
1. Obtenga la lista de todos los nombres de zona horaria específicos de la base de datos. Para ello, conéctese manualmente a la base de datos y ejecute esta consulta para obtener una lista de todos los nombres de zonas horarias que la base de datos soporta actualmente:
SELECT name, utc_offset, is_dst FROM pg_timezone_names ORDER BY name
| | Conserve esta lista para referencia posterior. |
2. Determine el nombre de la zona horaria a la que están asociados actualmente todos los datos de ThingWorx existentes (la zona horaria "De"):
◦ Obtenga el valor de zona horaria que anotó en la sección "Definición de la zona horaria del servidor de ThingWorx" anterior.
▪ Este valor es la zona horaria a la que están asociados actualmente todos los datos de ThingWorx existentes.
▪ Este valor es específico de la JVM o del sistema operativo y puede que no coincida exactamente con ningún nombre de zona horaria de la lista específica de la base de datos (consultadas en el paso 1).
◦ Examine manualmente la lista de las zonas horarias que se consultan desde la base de datos para determinar el nombre de la zona horaria que coincide más adecuadamente con ese valor de la sección "Definición de la zona horaria del servidor de ThingWorx".
◦ Después de encontrar la coincidencia más adecuada, el nombre de la zona horaria se convierte en la zona horaria "De" (frente a la zona horaria "A") que se necesitará en pasos posteriores.
3. Determine la zona horaria a la que se deben migrar todos los datos de ThingWorx existentes (la zona horaria "A"):
◦ En la sección "Definición de la zona horaria del servidor de ThingWorx" anterior, se ha definido el valor de configuración -Duser.timezone de Tomcat en UTC. Esta es la zona horaria a la que se deben migrar todos los datos de ThingWorx existentes. Sin embargo, ese valor es específico de la JVM y puede no coincidir exactamente con ningún nombre de zona horaria de la lista de bases de datos consultadas (en el paso 1).
◦ Examine manualmente la lista de las zonas horarias que se consultan desde la base de datos para determinar el nombre de la zona horaria que coincide más adecuadamente con ese valor UTC.
◦ Después de encontrar la coincidencia más adecuada, el nombre de la zona horaria se convierte en la zona horaria "A" (frente a la zona horaria "De") que se necesitará en pasos posteriores.
| | Los nombres de zona horaria "De" y "A" pueden ser iguales. |
4. Ejecute el script de esquema BigInt/Timezone para preparar la migración de todos los datos de tabla de datos, flujo y flujo de valor:
update_bigint_timezone_schema_postgres.sh
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
| | Aunque este script migra directamente algunos datos, no migra ningún dato de tabla de datos, flujo o flujo de valor. En su lugar, este script crea una copia de seguridad de todos los datos de tabla de datos, flujo y flujo de valor, por lo que se puede migrar posteriormente. Por motivos de rendimiento, este script no crea realmente una copia de seguridad de los datos en las tablas de datos, de flujo y de flujo de valor existentes. En su lugar, este script cambia el nombre de las tablas existentes de "foo" a "foo_backup". Así se evita el proceso de copiar grandes cantidades de datos que puede tardar mucho tiempo. Una vez que se cambie el nombre de las tablas existentes (y convertirse, por lo tanto, 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). |
5. Después de completar el paso anterior, se puede reiniciar la plataforma si es necesario. Sin embargo, se debe tener en cuenta que los datos de tabla de datos, flujo y flujo de valor todavía no se han migrado. Por lo tanto, hasta que se produzca la migración de datos, las consultas de esos datos pueden recibir conjuntos de resultados reducidos.
6. Ejecute el script de datos BigInt/TimeZone para migrar los datos de tabla de datos, flujo o flujo de valor:
update_bigint_timezone_data_postgres.sh
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
| | • Según la sentencia de uso anterior, solo se puede especificar una opción "--update..." a la vez. Por lo tanto, para migrar todos los datos de tabla de datos, flujo y flujo de valor, este script se debe ejecutar tres veces (una vez para cada conjunto de datos). Dado que estos conjuntos de datos son independientes entre sí, la migración de un conjunto de datos se puede realizar en paralelo a la migración de otro conjunto de datos. Por ejemplo, si se abren tres ventanas de comandos independientes, se puede ejecutar simultáneamente la migración de la tabla de datos en la primera ventana, la migración de flujo en la segunda ventana y la migración de flujo de valor en la tercera ventana. Sin embargo, no intente utilizar más de un proceso para migrar simultáneamente un conjunto de datos determinado. Por ejemplo, no intente utilizar dos procesos simultáneos para migrar los datos de flujo de valor. Esta operación no está definida y provocará daños en los datos. • El valor de chunk_size sugerido para un entorno típico es 10 000. • Puesto que la plataforma se puede reiniciar antes de que se haya completado la migración de todos los datos, la migración de datos se produce de los datos más recientes a los más antiguos. Esto es intencionado y permite que cualquier consulta de esos datos empiece a recibir los datos más relevantes en primer lugar. • El tamaño de los conjuntos de datos puede tener un impacto considerable en el tiempo que se tarda en migrar todos los datos. Por ejemplo, si hay miles de millones de filas que se deben migrar, la migración de los datos puede tardar varios días en completarse. |
7. Una vez completada la migración de todos los datos de BigInt/TimeZone y después de verificar y validar manualmente todos los datos migrados, ejecute el script de limpieza de BigInt/TimeZone para limpiar los artefactos de base de datos temporales creados por el script de esquema BigInt/TimeZone:
cleanup_bigint_timezone_data_update_postgres.sh
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
| | Aunque este script realiza cierta limpieza de los objetos de base de datos temporales creados durante el proceso de actualización, 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. |
8. Ejecute el script principal de limpieza una vez se haya completado, verificado y validado toda la migración de datos.
Después de que se haya completado, verificado y validado toda la migración de datos BigInt/TimeZone, ejecute este script para limpiar cualquier artefacto temporal de la base de datos creado por el script principal de actualización de ThingWorx:
cleanup_update_postgres.sh
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
E) Actualización del esquema y los datos de migración (solo MSSQL)
| | Todos los scripts a los que se hace referencia a continuación, se encuentran en la carpeta update de la descarga de software de ThingWorx. |
| | Todos los scripts a los que se hace referencia a continuación requieren acceso a la base de datos. Si se define la variable de entorno SQLCMDPASSWORD, los scripts utilizarán su valor como contraseña de la base de datos. De lo contrario, los scripts solicitarán al usuario la contraseña de la base de datos. Consulte la documentación oficial de MSSQL para obtener más información. |
1. Ejecute el script de actualización principal para realizar la migración del esquema de ThingWorx:
update_mssql.sh
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
Ejecución de scripts de zona horaria del servidor ThingWorx
| | Solo es necesario ejecutar scripts de zona horaria de ThingWorx para actualizar de ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2 a una nueva versión de ThingWorx. ThingWorx 9.4.0 y versiones posteriores no soportan actualizaciones directas desde ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2. En su lugar, los clientes deben actualizar a una versión de ThingWorx intermedia, como ThingWorx 9.3. Al actualizar desde ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2 a ThingWorx 9.3.x, ejecute los siguientes scripts. En ThingWorx se recomienda utilizar la versión más reciente de ThingWorx 9.3.x como versión intermedia. |
Los pasos de la sección solo se deben realizar si -Duser.timezone=UTC no se ha definido en el paso 1 de la sección "Definición de la zona horaria del servidor de ThingWorx" o si se está actualizando desde ThingWorx 8.5.x o una versión anterior.
1. Obtenga la lista de todos los nombres de zona horaria específicos de la base de datos. Para ello, conéctese manualmente a la base de datos y ejecute esta consulta para obtener una lista de todos los nombres de zonas horarias que la base de datos soporta actualmente:
SELECT name, current_utc_offset, is_currently_dst FROM sys.time_zone_info ORDER BY name
| | Conserve esta lista para referencia posterior. |
2. Determine el nombre de la zona horaria a la que están asociados actualmente todos los datos de ThingWorx existentes (la zona horaria "De"):
◦ Obtenga el valor de zona horaria que anotó en la sección "Definición de la zona horaria del servidor de ThingWorx" anterior.
▪ Este valor es la zona horaria a la que están asociados actualmente todos los datos de ThingWorx existentes.
▪ Este valor es específico de la JVM o del sistema operativo y puede que no coincida exactamente con ningún nombre de zona horaria de la lista específica de la base de datos (consultadas en el paso 1).
◦ Examine manualmente la lista de las zonas horarias que se consultan desde la base de datos para determinar el nombre de la zona horaria que coincide más adecuadamente con ese valor de la sección "Definición de la zona horaria del servidor de ThingWorx".
◦ Después de encontrar la coincidencia más adecuada, el nombre de la zona horaria se convierte en la zona horaria "De" (frente a la zona horaria "A") que se necesitará en pasos posteriores.
3. Determine la zona horaria a la que se deben migrar todos los datos de ThingWorx existentes (la zona horaria "A"):
◦ En la sección "Definición de la zona horaria del servidor de ThingWorx" anterior, se ha definido el valor de configuración -Duser.timezone de Tomcat en UTC. Esta es la zona horaria a la que se deben migrar todos los datos de ThingWorx existentes. Sin embargo, ese valor es específico de la JVM y puede no coincidir exactamente con ningún nombre de zona horaria de la lista de bases de datos consultadas (en el paso 1).
◦ Examine manualmente la lista de las zonas horarias que se consultan desde la base de datos para determinar el nombre de la zona horaria que coincide más adecuadamente con ese valor UTC.
◦ Después de encontrar la coincidencia más adecuada, el nombre de la zona horaria se convierte en la zona horaria "A" (frente a la zona horaria "De") que se necesitará en pasos posteriores.
| | Los nombres de zona horaria "De" y "A" pueden ser iguales. |
4. Ejecute el script de esquema BigInt/Timezone para preparar la migración de todos los datos de tabla de datos, flujo y flujo de valor:
update_bigint_timezone_schema_mssql.sh
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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. Después de completar el paso anterior, se puede reiniciar la plataforma si es necesario. Sin embargo, se debe tener en cuenta que los datos de tabla de datos, flujo y flujo de valor todavía no se han migrado. Por lo tanto, hasta que se produzca la migración de datos, las consultas de esos datos pueden recibir conjuntos de resultados reducidos.
6. Ejecute el script de datos BigInt/TimeZone para migrar los datos de tabla de datos, flujo o flujo de valor:
update_bigint_timezone_data_msssql.sh
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
| | • Según la sentencia de uso anterior, solo se puede especificar una opción "--update..." a la vez. Por lo tanto, para migrar todos los datos de tabla de datos, flujo y flujo de valor, este script se debe ejecutar tres veces (una vez para cada conjunto de datos). Dado que estos conjuntos de datos son independientes entre sí, la migración de un conjunto de datos se puede realizar en paralelo a la migración de otro conjunto de datos. Por ejemplo, si se abren tres ventanas de comandos independientes, se puede ejecutar simultáneamente la migración de la tabla de datos en la primera ventana, la migración de flujo en la segunda ventana y la migración de flujo de valor en la tercera ventana. Sin embargo, no intente utilizar más de un proceso para migrar simultáneamente un conjunto de datos determinado. Por ejemplo, no intente utilizar dos procesos simultáneos para migrar los datos de flujo de valor. Esta operación no está definida y provocará daños en los datos. • El valor de chunk_size sugerido para un entorno típico es 10 000. • Puesto que la plataforma se puede reiniciar antes de que se haya completado la migración de todos los datos, la migración de datos se produce de los datos más recientes a los más antiguos. Esto es intencionado y permite que cualquier consulta de esos datos empiece a recibir los datos más relevantes en primer lugar. • El tamaño de los conjuntos de datos puede tener un impacto considerable en el tiempo que se tarda en migrar todos los datos. Por ejemplo, si hay miles de millones de filas que se deben migrar, la migración de los datos puede tardar varios días en completarse. |
7. Una vez completada la migración de los datos de BigInt/TimeZone y después de verificar y validar manualmente todos los datos migrados, ejecute el script de limpieza de BigInt/TimeZone para limpiar los artefactos de base de datos temporales creados por el script de esquema BigInt/TimeZone:
cleanup_bigint_timezone_data_update_mssql.sh
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
| | Aunque este script realiza cierta limpieza de los objetos de base de datos temporales creados durante el proceso de actualización, 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. |
8. Ejecute el script principal de limpieza una vez se haya completado, verificado y validado toda la migración de datos.
Después de que se haya completado, verificado y validado toda la migración de datos BigInt/TimeZone, ejecute este script para limpiar cualquier artefacto temporal de la base de datos creado por el script principal de actualización de ThingWorx:
cleanup_update_mssql.sh
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
F) Actualización del esquema y los datos de migración (solo Azure SQL)
| | Todos los scripts a los que se hace referencia a continuación, se encuentran en la carpeta update de la descarga de software de ThingWorx. |
| | Todos los scripts a los que se hace referencia a continuación requieren acceso a la base de datos. Si se define la variable de entorno SQLCMDPASSWORD, los scripts utilizarán su valor como contraseña de la base de datos. De lo contrario, los scripts solicitarán al usuario la contraseña de la base de datos. Consulte la documentación oficial de MSSQL para obtener más información. |
1. Ejecute el script de actualización principal para realizar la migración del esquema de ThingWorx:
update_mssql.sh
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
Ejecución de scripts de zona horaria del servidor ThingWorx
| | Solo es necesario ejecutar scripts de zona horaria de ThingWorx para actualizar de ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2 a una nueva versión de ThingWorx. ThingWorx 9.4.0 y versiones posteriores no soportan actualizaciones directas desde ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2. En su lugar, los clientes deben actualizar a una versión de ThingWorx intermedia, como ThingWorx 9.3. Al actualizar desde ThingWorx 8.5 o ThingWorx 9.0.0, 9.0.1 o 9.0.2 a ThingWorx 9.3.x, ejecute los siguientes scripts. En ThingWorx se recomienda utilizar la versión más reciente de ThingWorx 9.3.x como versión intermedia. |
Los pasos de la sección solo se deben realizar si -Duser.timezone=UTC no se ha definido en el paso 1 de la sección "Definición de la zona horaria del servidor de ThingWorx" o si se está actualizando desde ThingWorx 8.5.x o una versión anterior.
1. Obtenga la lista de todos los nombres de zona horaria específicos de la base de datos. Para ello, conéctese manualmente a la base de datos y ejecute esta consulta para obtener una lista de todos los nombres de zonas horarias que la base de datos soporta actualmente:
SELECT name, current_utc_offset, is_currently_dst FROM sys.time_zone_info ORDER BY name
| | Conserve esta lista para referencia posterior. |
2. Determine el nombre de la zona horaria a la que están asociados actualmente todos los datos de ThingWorx existentes (la zona horaria "De"):
◦ Obtenga el valor de zona horaria que anotó en la sección "Definición de la zona horaria del servidor de ThingWorx" anterior.
▪ Este valor es la zona horaria a la que están asociados actualmente todos los datos de ThingWorx existentes.
▪ Este valor es específico de la JVM o del sistema operativo y puede que no coincida exactamente con ningún nombre de zona horaria de la lista específica de la base de datos (consultadas en el paso 1).
◦ Examine manualmente la lista de las zonas horarias que se consultan desde la base de datos para determinar el nombre de la zona horaria que coincide más adecuadamente con ese valor de la sección "Definición de la zona horaria del servidor de ThingWorx".
◦ Después de encontrar la coincidencia más adecuada, el nombre de la zona horaria se convierte en la zona horaria "De" (frente a la zona horaria "A") que se necesitará en pasos posteriores.
3. Determine la zona horaria a la que se deben migrar todos los datos de ThingWorx existentes (la zona horaria "A"):
◦ En la sección "Definición de la zona horaria del servidor de ThingWorx" anterior, se ha definido el valor de configuración -Duser.timezone de Tomcat en UTC. Esta es la zona horaria a la que se deben migrar todos los datos de ThingWorx existentes. Sin embargo, ese valor es específico de la JVM y puede no coincidir exactamente con ningún nombre de zona horaria de la lista de bases de datos consultadas (en el paso 1).
◦ Examine manualmente la lista de las zonas horarias que se consultan desde la base de datos para determinar el nombre de la zona horaria que coincide más adecuadamente con ese valor UTC.
◦ Después de encontrar la coincidencia más adecuada, el nombre de la zona horaria se convierte en la zona horaria "A" (frente a la zona horaria "De") que se necesitará en pasos posteriores.
| | Los nombres de zona horaria "De" y "A" pueden ser iguales. |
4. Ejecute el script de esquema BigInt/Timezone para preparar la migración de todos los datos de tabla de datos, flujo y flujo de valor:
update_bigint_timezone_schema_mssql.sh
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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. Después de completar el paso anterior, se puede reiniciar la plataforma si es necesario. Sin embargo, se debe tener en cuenta que los datos de tabla de datos, flujo y flujo de valor todavía no se han migrado. Por lo tanto, hasta que se produzca la migración de datos, las consultas de esos datos pueden recibir conjuntos de resultados reducidos.
6. Ejecute el script de datos BigInt/TimeZone para migrar los datos de tabla de datos, flujo o flujo de valor:
update_bigint_timezone_data_msssql.sh
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
| | • Según la sentencia de uso anterior, solo se puede especificar una opción "--update..." a la vez. Por lo tanto, para migrar todos los datos de tabla de datos, flujo y flujo de valor, este script se debe ejecutar tres veces (una vez para cada conjunto de datos). Dado que estos conjuntos de datos son independientes entre sí, la migración de un conjunto de datos se puede realizar en paralelo a la migración de otro conjunto de datos. Por ejemplo, si se abren tres ventanas de comandos independientes, se puede ejecutar simultáneamente la migración de la tabla de datos en la primera ventana, la migración de flujo en la segunda ventana y la migración de flujo de valor en la tercera ventana. Sin embargo, no intente utilizar más de un proceso para migrar simultáneamente un conjunto de datos determinado. Por ejemplo, no intente utilizar dos procesos simultáneos para migrar los datos de flujo de valor. Esta operación no está definida y provocará daños en los datos. • El valor de chunk_size sugerido para un entorno típico es 10 000. • Puesto que la plataforma se puede reiniciar antes de que se haya completado la migración de todos los datos, la migración de datos se produce de los datos más recientes a los más antiguos. Esto es intencionado y permite que cualquier consulta de esos datos empiece a recibir los datos más relevantes en primer lugar. • El tamaño de los conjuntos de datos puede tener un impacto considerable en el tiempo que se tarda en migrar todos los datos. Por ejemplo, si hay miles de millones de filas que se deben migrar, la migración de los datos puede tardar varios días en completarse. |
7. Una vez completada la migración de todos los datos de BigInt/TimeZone y después de verificar y validar manualmente todos los datos migrados, ejecute el script de limpieza de BigInt/TimeZone para limpiar los artefactos de base de datos temporales creados por el script de esquema BigInt/TimeZone:
cleanup_bigint_timezone_data_update_mssql.sh
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
| | Aunque este script realiza cierta limpieza de los objetos de base de datos temporales creados durante el proceso de actualización, 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. |
8. Ejecute el script principal de limpieza una vez se haya completado, verificado y validado toda la migración de datos.
Después de que se haya completado, verificado y validado toda la migración de datos BigInt/TimeZone, ejecute este script para limpiar cualquier artefacto temporal de la base de datos creado por el script principal de actualización de ThingWorx:
cleanup_update_mssql.sh
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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) Actualización a Java 11
| | 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.
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.
H) Implementación del fichero ThingWorx.war y reinicio
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>
},
"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. Inicie Tomcat.
4. 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.
5. 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>
I) Importación de datos de flujo y de flujo de valor (solo InfluxDB)
| | Si se actualiza ThingWorx y se utiliza CAS como AzureAD y se conecta a un proveedor de recursos utilizando el tipo de conexión SSO basado en conectores ThingWorx, la propiedad mandatoryScopes se debe definir en AuthorizationServersSettings en el fichero sso-settings.json para incluir offline_access. Debido al cambio en el comportamiento de AzureAD, el proceso de adquisición de un nuevo token no proporciona un token de renovación. Como resultado, una vez que el token de acceso vence, no es posible renovarlo durante la sesión. Para solucionar este problema, el usuario debe iniciar sesión de nuevo, devolviendo el nuevo token sano. |
| | Si se va a realizar una actualización que requiera exportar los datos almacenados en InfluxDB luego importar a una nueva versión ThingWorx; siga los pasos de esta sección. Consulte la sección B para determinar si es necesario realizar una actualización de exportación-importación. |
1. Cree un nuevo proveedor de persistencia para InfluxDB o proporcione nueva información de conexión al proveedor de persistencia de la versión 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.
J) Actualización de componentes adicionales
• 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.
K) Limpieza opcional adicional para 9.3 y versiones posteriores
Si se está actualizando desde ThingWorx 9.2.x o una versión anterior, y se ha activado el inicio de sesión único con la codificación de tokens de acceso, hay un paso de limpieza opcional que se puede realizar. En las versiones anteriores a 9.3, se utiliza la herramienta KeyCzar para cifrar los tokens de acceso antes de que se conserven en la base de datos. KeyCzar requiere la creación de una carpeta symmetric en la carpeta ThingworxPlatform\ssoSecurityConfig del directorio de instalación de ThingWorx.
La herramienta KeyCzar ya está obsoleta. En ThingWorx 9.3 y versiones posteriores, se ha reemplazado por el uso de Tink para la codificación de tokens de acceso. Tink no requiere la carpeta symmetric ni el parámetro keyczarKeyFolderPath del fichero sso-settings.json de ThingWorx. Estos ficheros y configuraciones se pueden dejar tal como están y ThingWorx 9.3 y las versiones posteriores simplemente los desestimarán. Sin embargo, si el usuario decide quitarlos, debe esperar hasta que se haya completado el procedimiento de actualización.
L) Resolución de problemas
• 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 o PostgreSQL, pueden aparecer los siguientes mensajes de error de conflicto de propiedades.
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. |