Mise à niveau via le programme d'installation
Si vous utilisez le programme d'installation de ThingWorx Foundation pour installer ThingWorx Foundation 8.5.0 ou une version ultérieure, vous pouvez également l'utiliser pour mettre à niveau ThingWorx Foundation, y compris les mises à niveau de la version de maintenance. Pour plus d'informations sur les liens vers les matrices de mise à niveau prises en charge pour chaque version ThingWorx, consultez la section Mise à niveau de ThingWorx.
 |
A partir de ThingWorx 9.4, les clients ne peuvent pas effectuer directement une mise à niveau de ThingWorx 8.5 ou ThingWorx 9.0 vers ThingWorx 9.4.0. Les clients souhaitant effectuer une mise à niveau vers la version 9.4.0 ou ultérieure depuis ThingWorx 8.5 ou ThingWorx 9.0 doivent effectuer une mise à niveau vers une version intermédiaire, puis une mise à niveau vers ThingWorx 9.4.0 et versions ultérieures. ThingWorx recommande d'utiliser la version de ThingWorx 9.3.x la plus récente comme chemin intermédiaire de mise à niveau.
|
|
|
Si vous effectuez une mise à niveau vers ThingWorx 9.2 et PostgreSQL 13, la mise à niveau de PostgreSQL sera la dernière étape du processus de mise à niveau.
|
|
|
L'utilisateur effectuant la mise à niveau doit être celui qui a effectué l'installation d'origine de l'application.
|
A.) Conditions requises
• Configuration requise concernant Java (le programme d'installation ne crée pas de package Java et ne l'installe pas) :
◦ Il est souhaitable que l'utilisateur qui exécute la mise à niveau soit celui qui s'est initialement chargé de l'installation de ThingWorx. Au cours de l'installation initiale, le programme d'installation génère le fichier ThingWorxFoundation.xml, qui inclut des informations au sujet de l'installation et qui est nécessaire pour la mise à niveau. Ce fichier est stocké dans le répertoire du profil de l'utilisateur qui exécute l'installation. Par exemple, dans C:\Users\Administrator\.ptc_cci.
◦ ThingWorx Foundation 9.2 nécessite Java 11, mais Java 8 doit également être installé. Vérifiez que les versions prises en charge de Java 8 et 11 sont installées avant d'exécuter le programme d'installation. Ajoutez Java 11 à la variable d'environnement PATH.
◦ Si vous exécutez ThingWorx 9.0 ou une version antérieure sur Java 8 et que vous effectuez une mise à niveau vers ThingWorx 9.2, vous devez pré-installer Java 11 sans modifier la JVM vers laquelle pointe ThingWorx. JAVA_HOME doit rester défini sur le dossier Java 8. Les deux répertoires Java doivent figurer dans la variable d'environnement PATH, mais java8/bin doit être répertorié avant java11/bin dans la variable PATH. Lors de la mise à niveau vers la version 9.2, le programme d'installation basculera sur Java 11, car ThingWorx 9.2 ne prend pas en charge Java 8.
◦ Si vous exécutez ThingWorx 9.1, les deux versions Java 8 et Java 11 sont prises en charge, de sorte que vous pouvez soit suivre les conseils ci-dessus (installer les deux versions et les placer dans le chemin d'accès), soit migrer votre instance ThingWorx 9.1 vers Java 11 avant de lancer la mise à niveau.
• Sauvegardez votre base de données. Le programme d'installation n'exécute pas de sauvegarde de base de données pendant le processus de mise à niveau.
• Vous devez utiliser l'un des systèmes d'exploitation suivants avec ces combinaisons de base de données :
◦ Windows avec PostgreSQL
◦ Windows avec Microsoft SQL Server
◦ Red Hat Enterprise Linux avec PostgreSQL
◦ Red Hat Enterprise Linux avec Microsoft SQL Server
Pour plus d'informations sur les versions, consultez la rubrique Configuration système.
• La mise à niveau échoue si l'une des valeurs de champ d'index personnalisées est manquante dans les tables de données. Vérifiez que tous les champs d'index personnalisés comportent des valeurs avant de démarrer le processus de mise à niveau.
B.) Exécution de l'utilitaire ThingWorx Upgrade-Ready Utility
Si vous avez installé ThingWorx Foundation 8.5.3 ou une version antérieure, vous devez d'abord exécuter l'utilitaire ThingWorx Upgrade-Ready Utility en le téléchargeant depuis > > > > > .
ThingWorx Upgrade-Ready Utility crée les fichiers XML nécessaires à la prise en charge de la mise à niveau automatisée de ThingWorx Foundation et, s'il est installé, de ThingWorx Flow. L'utilitaire vous invite à localiser ThingWorx Foundation et, s'il est installé, ThingWorx Flow, sur votre système, puis configure les installations sélectionnées. Il crée les fichiers ThingWorxFoundation.xml et ThingWorxFlow.xml (si ThingWorx Flow est installé) dans votre profil utilisateur. Les fichiers sont enregistrés dans le dossier .ptc_ccif de votre profil utilisateur (par exemple, sous Windows : C:\Users\Administrator\.ptc_ccif ; sous Linux : ~/.ptc_ccif/).
Si vous avez installé ThingWorx 8.5.4 ou une version ultérieure à l'aide du programme d'installation, les fichiers XML nécessaires ont déjà été créés dans le cadre de l'installation. Par conséquent, il n'est pas nécessaire d'exécuter ThingWorx Upgrade-Ready Utility.
Dépannage
• Si vous avez utilisé le programme d'installation pour installer ThingWorx Foundation 8.5.3 ou une version antérieure, puis que vous avez effectué une mise à niveau manuelle vers une version 8.5.x plus récente et que vous vous apprêtez à effectuer la mise à niveau vers 9.x en exécutant ThingWorx Upgrade Ready Utility, procédez comme suit :
◦ Exécutez ThingWorx Upgrade-Ready Utility.
◦ Vérifiez que la valeur de la propriété <applicationVersion> dans le fichier ThingWorxFoundation.xml de votre profil utilisateur correspond à votre version actuelle.
• Si vous rencontrez des problèmes pour exécuter l'utilitaire ThingWorx Upgrade-Ready Utility et que vous devez créer ou modifier manuellement le fichier ThingWorxFoundation.xml, vous pouvez utiliser l'exemple ci-dessous et le mettre à jour en fonction de votre chemin de mise à niveau :
<?xml version="1.0" encoding='utf-8'?>
<installationInfo>
<projectFlavor>PostgreSQL</projectFlavor>
<applicationName>ThingWorxFoundation</applicationName>
<applicationVersion>9.0.1</applicationVersion>
<applicationInstallDir>C:\Program Files
(x86)\ThingWorxFoundation</applicationInstallDir>
</installationInfo>
<installationInfo>
<projectFlavor>PostgreSQL</projectFlavor>
<applicationName>ThingWorxFoundation</applicationName>
<applicationVersion>9.0.1</applicationVersion>
<applicationInstallDir>C:\Program Files
(x86)\ThingWorxFoundation</applicationInstallDir>
</installationInfo>
C.) Mise à niveau
1. Assurez-vous que les prérequis décrits dans les sections ci-dessus sont remplies.
2. Téléchargez les fichiers du tout dernier programme d'installation de ThingWorx Foundation pour une installation sur site à partir du site support.ptc.com, sous Télécharger un logiciel > Commander et télécharger des mises à jour > ThingWorx Foundation > Release x.x > ThingWorx PostgreSQL et ThingWorx Mssql.
3. Le programme d'installation répertorie les informations d'installation existantes, notamment :
◦ Répertoire d'installation
◦ Port
◦ Paramètre de configuration SSL
◦ Paramètre de configuration SSO
4. Le contrat de licence PTC s'affiche. Vous devez accepter les termes du contrat avant de poursuivre la mise à niveau.
5. Vous devez saisir le mot de passe de l'administrateur ThingWorx Foundation ou, si l'authentification unique est configurée, spécifier votre clé d'application.
6. Vous pouvez vérifier et confirmer vos informations de configuration de l'installation.
7. Le programme d'installation réalisera la mise à niveau.
Vous pouvez désormais mettre à niveau les extensions et les applications vers des versions compatibles.
D.) Migration des données de fuseau horaire
| | La migration des données de fuseau horaire n'est pas nécessaire lors d'une mise à jour vers ThingWorx 9.4.0 et versions ultérieures. Les mises à niveau directes ne sont pas prises en charge depuis ThingWorx 8.5 ou ThingWorx 9.0 vers ThingWorx 9.4. La migration des fuseaux horaires sera effectuée pendant le processus de migration vers la version intermédiaire. |
Vous devez immédiatement mener à bien une migration de vos données critiques comme l'explique cette section si vous remplissez l'une des conditions suivantes :
• Vous disposiez de ThingWorx 8.5.x et avez utilisé le programme d'installation pour effectuer une mise à niveau vers ThingWorx 9.0.x ou 9.1.
• Vous disposiez de ThingWorx 9.0.x et avez utilisé le programme d'installation pour effectuer une mise à niveau vers ThingWorx 9.0.3 ou une version ultérieure.
Pour effectuer cette migration de données, procédez comme suit :
1. Immédiatement après la mise à niveau, arrêtez ThingWorx et Apache Tomcat.
2. Définissez manuellement le paramètre de fuseau horaire -Duser.timezone=UTC en suivant la procédure ci-dessous compte tenu de votre système d'exploitation.
Configuration des paramètres de fuseau horaire sous Windows
1. Arrêtez le service ThingWorx-Foundation.
2. Exécutez CMD en tant qu'administrateur.
3. Accédez au répertoire Tomcat /bin sous le répertoire d'installation de ThingWorx Foundation.
Par exemple : cd C:\Program Files (x86)\ThingWorxFoundation\tomcat\apache-tomcat-9.0.37\bin.
4. Modifiez la configuration du service ThingWorx-Foundation pour ouvrir l'application GUI en exécutant la commande suivante :
tomcat9w.exe //ES//ThingWorx-Foundation
5. Accédez à l'onglet Java de l'application GUI.
a. Pour Java Options, ajoutez ce qui suit : -Duser.timezone=UTC.
b. Sélectionnez Apply.
6. Cliquez sur OK pour fermer l'application GUI.
7. Mettez à jour les paramètres de service à l'aide de tomcat9.exe.
8. Exécutez CMD en tant qu'administrateur, puis exécutez la commande suivante :
tomcat9.exe //US//ThingWorx-Foundation
Configuration des paramètres de fuseau horaire sous Linux
1. Arrêtez le service ThingWorx-Foundation avec systemctl stop ThingWorx-Foundation.service.
2. Sauvegardez ThingWorx-Foundation.service dans /etc/systemd/system/ThingWorx-Foundation.service.backup.
3. Modifiez la configuration du service en modifiant le ThingWorx-Foundation.service pour les options JVM :
a. Pour CATALINA_OPTS, ajoutez ce qui suit : -Duser.timezone=UTC.
4. Exécutez ce qui suit : systemctl daemon-reload.
Exécution des scripts
• Mise à niveau vers 9.3.x et versions ultérieures via le programme d'installation
1. Récupérez la liste de tous les noms de fuseau horaire spécifiques à la base de données. Pour ce faire, connectez-vous manuellement à la base de données et exécutez cette requête pour répertorier tous les noms de fuseau horaire actuellement pris en charge par la base de données :
SELECT name, utc_offset, is_dst FROM pg_timezone_names ORDER BY name
| | Conserver cette liste pour référence ultérieure. |
2. Déterminez le nom du fuseau horaire auquel toutes les données ThingWorx existantes sont actuellement associées (votre fuseau horaire "Depuis") :
▪ Récupérez la valeur de fuseau horaire que vous avez notée à la section "Définition du fuseau horaire du serveur ThingWorx" ci-avant.
▪ Cette valeur correspond au fuseau horaire auquel toutes les données ThingWorx existantes sont actuellement associées.
▪ Elle est spécifique à la JVM ou au système d'exploitation, et peut ne pas avoir de correspondance exacte dans la liste des noms de fuseau horaire spécifiques à la base de données (récupérée à l'étape 1).
▪ Examinez la liste des fuseaux horaires récupérés sur la base de données pour déterminer le nom de fuseau horaire qui correspond le mieux à la valeur identifiée à la section "Définition du fuseau horaire du serveur ThingWorx".
▪ Une fois la correspondance la plus appropriée trouvée, ce nom de fuseau horaire devient votre fuseau horaire "Depuis" (par opposition à votre fuseau horaire "Vers"), donnée dont vous aurez besoin par la suite.
3. Déterminez le fuseau horaire vers lequel toutes les données de ThingWorx existantes doivent être migrées (votre fuseau horaire "Vers") :
▪ A la section "Définition du fuseau horaire du serveur ThingWorx" ci-dessus, vous avez défini le paramètre de configuration -Duser.timezone de Tomcat sur UTC. Il s'agit du fuseau horaire vers lequel toutes vos données ThingWorx existantes doivent être migrées. Toutefois, cette valeur est propre à la JVM et peut ne pas avoir de correspondance exacte dans la liste des noms de fuseau horaire de la base de données (récupérée à l'étape 1).
▪ Examinez la liste des fuseaux horaires récupérés sur la base de données pour déterminer le nom de fuseau horaire qui correspond le mieux à cette valeur UTC.
▪ Une fois la correspondance la plus appropriée trouvée, ce nom de fuseau horaire devient votre fuseau horaire "Vers" (par opposition à votre fuseau horaire "Depuis"), donnée dont vous aurez besoin par la suite.
| | Les noms de fuseau horaire "Depuis" et "Vers" peuvent être identiques. |
4. Exécutez le script de schéma BigInt/TimeZone pour préparer la migration de toutes vos données de table de données, de flux et de flux de valeurs :
update_bigint_timezone_schema_postgres.ps1
| | L'exécution de ce script sans arguments affiche ses instructions d'utilisation : Usage: update_bigint_timezone_schema_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] --from_timezone <timezone> --to_timezone <timezone> [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). --system_version_override version Forces the upgrade to assume the database schema is currently of this version (i.e. "n.n.n"), rather than of the actual, persisted version. --from_timezone timezone The name of the timezone for all existing data. --to_timezone timezone The name of the timezone to which all existing data will be updated. -y Suppress all non-required prompts, such as "Are you sure?" |
| | Bien qu'il s'occupe de migrer directement certaines données, ce script ne réalise pas en définitive lui-même la migration des données de table de données, de flux et de flux de valeurs. Son rôle consiste en fait à créer une sauvegarde de toutes ces données pour permettre leur migration par la suite. Pour des raisons de performances, ce script ne crée pas en réalité de copie de sauvegarde des données dans les tables de données, de flux et de flux de valeurs existantes. Il procède en fait en renommant les tables existantes de "foo" en "foo_backup". Cette approche permet d'éviter un processus de copie potentiellement très chronophage en présence de grandes quantités de données. Une fois les tables existantes renommées (qui deviennent donc les tables de sauvegarde), de nouvelles tables sont créées avec les noms de table d'origine. Ces nouvelles tables sont vides et remplissent le même but que les tables d'origine (car elles portent le même nom que les tables d'origine). |
5. A l'issue de l'étape précédente, la plateforme peut être redémarrée si nécessaire. Notez cependant qu'à ce stade, les données de table de données, de flux et de flux de valeurs n'ont pas encore été migrées. Par conséquent, jusqu'à ce que la migration intervienne, les requêtes sur ces données pourront renvoyer des jeux de résultats réduits.
6. Exécutez le script de données BigInt/Timezone pour migrer vos données de table de données, de flux et de flux de valeurs :
update_bigint_timezone_data_postgres.ps1
| | L'exécution de ce script sans arguments affiche ses instructions d'utilisation : Usage: update_bigint_timezone_data_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] --from_timezone <timezone> --to_timezone <timezone> --chunk_size <chunk_size> ( --update_data_table | --update_stream | --update_value_stream ) [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). --system_version_override version Forces the upgrade to assume the database schema is currently of this version (i.e. "n.n.n"), rather than of the actual, persisted version. --from_timezone timezone The name of the timezone for all existing data. --to_timezone timezone The name of the timezone to which all existing data will be updated. --chunk_size chunk_size The number of records to update per transaction. Must be greater than 0. --update_data_table Update "data_table" information. Cannot be specified with any other "--update_..." flag. --update_stream Update "stream" information. Cannot be specified with any other "--update_..." flag. --update_value_stream Update "data_table" information. Cannot be specified with any other "--update_..." flag. -y Suppress all non-required prompts, such as "Are you sure?" |
| | • Comme le précisent les instructions d'utilisation ci-dessus, une seule option "--update..." peut être spécifiée à la fois. Par conséquent, pour migrer toutes vos données de table de données, de flux et de flux de valeurs, il vous faut exécuter ce script trois fois (une fois pour chaque jeu de données). Etant donné que ces jeux de données sont indépendants l'un de l'autre, il vous est possible de paralléliser leur migration. Il vous suffit pour ce faire d'ouvrir trois fenêtres de commande distinctes, et d'exécuter simultanément la migration des tables de données dans la première fenêtre, celles des flux dans la deuxième fenêtre et celle des flux de valeurs dans la troisième fenêtre. En revanche, ne tentez pas d'utiliser plusieurs processus en parallèle pour migrer un même jeu de données. Par exemple, n'essayez pas d'utiliser deux processus simultanés pour migrer vos données de flux de valeurs. Une telle opération n'est pas prise en charge en entraînerait une corruption des données. • La chunk_size suggérée pour un environnement type est de 10000. • Etant donné que la plateforme peut être redémarrée avant que toutes les données n'aient été migrées, la migration des données s'effectue à reculons dans le temps, depuis les plus récentes jusqu'aux données les plus anciennes. Ce fonctionnement est intentionnel et vise à assurer aux requêtes effectuées sur ces données de renvoyer les données les plus pertinentes en premier. • La taille de vos jeux de données peut avoir un impact important sur le temps nécessaire à la migration de toutes vos données. Si vous avez des milliards de lignes à migrer par exemple, la migration de toutes ces données pourra prendre plusieurs jours. |
7. Une fois la migration de toutes vos données BigInt/TimeZone achevée et après avoir vérifié et validé manuellement toutes les données BigInt/TimeZone migrées, exécutez le script de nettoyage BigInt/TimeZone pour nettoyer les artefacts de base de données temporaires créés par le script de schéma BigInt/TimeZone :
cleanup_bigint_timezone_data_update_postgres.ps1
| | L'exécution de ce script sans arguments affiche ses instructions d'utilisation : Usage: cleanup_bigint_timezone_data_update_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). -y Suppress all non-required prompts, such as "Are you sure?" |
| | Bien que ce script effectue un nettoyage des objets de base de données temporaires créés lors du processus de mise à niveau, il ne supprime aucune des tables de sauvegarde créées au cours des étapes précédentes et ne modifie aucune des données qu'elles contiennent. Cela est intentionnel. Les données ne peuvent ainsi pas être supprimées par inadvertance. Si vous souhaitez supprimer ces tables de sauvegarde, vous devez le faire manuellement. |
8. Exécutez le script de nettoyage principal une fois que la migration de toutes les données est terminée, vérifiée et validée.
Une fois que la migration de toutes les données BigInt/TimeZone a été effectuée, vérifiée et validée, exécutez ce script pour nettoyer les artefacts de base de données temporaires créés par le script de mise à jour principal de ThingWorx :
cleanup_update_postgres.ps1
| | L'exécution de ce script sans arguments affiche ses instructions d'utilisation : Usage: cleanup_update_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). -y Suppress all non-required prompts, such as "Are you sure?" |
• Mise à niveau vers 9.0.x, 9.1.x et 9.2.x via le programme d'installation
Une fois le fuseau horaire défini, accédez à <EmplacementInstallation>/schema/update et exécutez les scripts appropriés pour votre combinaison de système d'exploitation et base de données (par exemple, pour Windows, fichiers .bat indiqués ci-dessous ; pour une installation RHEL, fichiers .sh) dans l'ordre suivant :
a. thingworxPostgresDBSetupBigIntTimezoneDataUpdate.bat
b. thingworxPostgresModelTablesDataUpdate.bat
c. thingworxPostgresDataTableSchemaUpdate.bat
d. thingworxPostgresValueStreamSchemaUpdate.bat
e. thingworxPostgresStreamSchemaUpdate.bat
f. thingworxPostgresDataTableDataUpdate.bat
g. thingworxPostgresStreamDataUpdate.bat
h. thingworxPostgresValueStreamDataUpdate.bat
Les scripts prennent différents paramètres, dont les suivants :
-h <server>
-p <port>
-d <thingworx database name>
-l <thingworx database username> for MSSQL
-u <thingworx database username> for PostgreSQL
-i <SQL server instance name> (optional, for MSSQL installations only)
-p <port>
-d <thingworx database name>
-l <thingworx database username> for MSSQL
-u <thingworx database username> for PostgreSQL
-i <SQL server instance name> (optional, for MSSQL installations only)
Pour plus d'informations sur ces paramètres et leur entrée attendue, consultez la rubrique Mise à niveau manuelle sur place : Windows ou Mise à niveau manuelle sur place : Linux.
Vous êtes invité à spécifier le mot de passe de l'utilisateur de base de données, qui est transmis dans les paramètres -u ou -l.
| | Les scripts StreamDataUpdate et ValueStreamDataUpdate (par exemple, thingworxPostgresStreamDataUpdate.bat et thingworxPostgresValueStreamDataUpdate.bat) sont conçus pour être exécutés de manière asynchrone. Les scripts sont conçus pour reprendre là où ils se sont arrêtés et ils fonctionnent par lots pour vous permettre de migrer vos données pendant l'exécution de votre instance de ThingWorx. L'exécution de ces scripts peut prendre un certain temps en fonction du volume de vos données. |
Le script DataTableDataUpdate (par exemple, thingworxPostgresDataTableDataUpdate.bat) affiche le message suivant lors de l'exécution : Essential System Data Has Been Migrated. It Is Now Safe To Restart Tomcat Server.
Une fois que le script DataTableDataUpdate a publié ce message, vous pouvez redémarrer votre instance ThingWorx et continuer avec les scripts de migration de données restants. Les scripts restants peuvent être exécutés alors que ThingWorx est en cours d'exécution et achèveront la migration de vos données de flux et de flux de valeurs.
Une fois la migration terminée, vous devez exécuter le script de nettoyage (par exemple, "thingworxPostgresDBCleanupBigIntTimezoneDataUpdate.sh") pour nettoyer la table migration_log et les fonctions de migration.
E.) Exécution du script de nettoyage pour les versions 9.2+
Si vous effectuez une mise à niveau vers ThingWorx 9.2.x ou une version ultérieure, vous devez exécuter le script de nettoyage pour supprimer les tables temporaires créées lors du processus de mise à niveau.
Exécutez le script de nettoyage thingworx<nom_base_de_données>DBCleanupPermissionTempTableUpdate.bat (Windows) ou thingworx<nom_base_de_données>DBCleanupPermissionTempTableUpdate.sh (Linux) situé dans <répertoireInstallation>/Schema/Update.
Les scripts prennent différents paramètres, dont les suivants :
-h <server>
-p <port>
-d <thingworx database name>
-l <thingworx database username> for MSSQL
-u <thingworx database username> for PostgreSQL
-i <SQL server instance name> (optional, for MSSQL installations only)
-p <port>
-d <thingworx database name>
-l <thingworx database username> for MSSQL
-u <thingworx database username> for PostgreSQL
-i <SQL server instance name> (optional, for MSSQL installations only)
Vous êtes invité à spécifier le mot de passe de l'utilisateur de base de données, qui est transmis dans les paramètres -u ou -l.
F.) Nettoyage supplémentaire facultatif pour les versions 9.3 et ultérieures
Si vous effectuez une mise à niveau depuis ThingWorx 9.2.x ou une version antérieure et que vous avez activé l'authentification unique avec le chiffrement des jetons d'accès, un nettoyage supplémentaire, bien que facultatif, pourra vous apparaître utile. Dans les versions antérieures à la 9.3, l'outil KeyCzar est utilisé pour chiffrer les jetons d'accès avant qu'ils ne soient rendus persistants dans la base de données. KeyCzar nécessite la création d'un dossier symmetric dans le dossier ThingworxPlatform\ssoSecurityConfig de votre répertoire d'installation de ThingWorx.
L'outil KeyCzar a aujourd'hui été abandonné. Dans ThingWorx 9.3 et versions ultérieures, il a été remplacé par l'outil Tink pour le chiffrement des jetons d'accès. Tink n'a pas besoin du dossier symmetric, ni du paramètre keyczarKeyFolderPath dans le fichier sso-settings.json de ThingWorx. Vous pouvez conserver ces éléments tels quels, et ThingWorx 9.3 et versions ultérieures se contentera tout simplement de les ignorer. Si vous décidez en revanche de les supprimer, notez que cette opération ne doit dès lors se faire qu'une fois la procédure de mise à niveau achevée.
G.) (Facultatif) Mise à niveau vers PostgreSQL 13
La mise à niveau à partir d'une version antérieure de PostgreSQL vers PostgreSQL 13 est facultative pour ThingWorx 9.2.0 et versions ultérieures.
1. Sauvegardez la base de données. Il s'agit de la deuxième sauvegarde que vous effectuez, car cette opération sauvegardera votre base de données après la mise à niveau de ThingWorx.
2. Téléchargez PostgreSQL 13.
3. Effectuez une mise à niveau vers PostgreSQL 13 en utilisant la documentation PostgreSQL comme référence.
H.) Dépannage
• En cas d'échec de la mise à niveau avec l'erreur suivante, procédez comme suit. Cette erreur se produit lorsqu'une valeur d'index personnalisée est supérieure ou égale à 64 caractères.
Unable to Invoke Service Reindex on Data Table : com.microsoft.sqlserver.jdbc.SQLServerException: String or binary data would be truncated in table 'thingworx.thingworx.data_table_indexes', column 'mskey'. Truncated value: '<with_actual_field_Value_from_mskey_field>'.
a. Exécutez thingworxMssqlSchemaUpdate<versionPrécédente>-to-<versionActuelle>.bat/.sh or le script SQL :
sqlcmd -S server\\serverinstance,port -U db_user -P password -d databaseName -i <schemaUpdateFile.sql>
L'exécution de ce script augmentera la longueur de la colonne mskey et mettra à jour les index.
b. Démarrez Tomcat.
• Si vous disposez d'une installation existante de ThingWorx 8.5.3 ou version antérieure, mais que le programme d'installation ne l'a pas trouvée, exécutez ThingWorx Upgrade-Ready Utility.
• Si le programme d'installation ne parvient pas à effectuer la mise à niveau, procédez comme suit :
1. Vérifiez les fichiers journaux dans votre répertoire d'installation sous /installer/logs.
2. Rétablissez votre installation pré-mise à niveau :
a. Restaurez la sauvegarde de votre base de données.
b. Démarrez le service ThingWorx-Foundation.
• Si le programme d'installation a été exécuté correctement, ThingWorx Foundation a été mis à niveau. Toutefois, le nom de l'emplacement d'installation de ThingWorx Foundation n'est peut-être pas à jour. Vous pouvez vérifier votre version de ThingWorx dans Composer sous > .
• Si vous utilisez RHEL 8.2 comme système d'exploitation et que vous effectuez une mise à niveau depuis ThingWorx 8.5.7, vous devez d'abord désinstaller manuellement le client Chef Infra pour donner au programme d'installation la possibilité de provisionner et d'utiliser une version de Chef prise en charge. Pour désinstaller Chef, procédez comme suit :
a. Pour trouver le nom de package du programme d'installation du client Chef Infra, exécutez la commande suivante : $ rpm -qa chef.
La sortie doit ressembler à ceci : chef-14.10.9-1.el7.x86_64.rpm.
b. Copiez le nom de package depuis la sortie ci-dessus.
c. Exécutez la commande suivante avec le nom de package copié : $ sudo yum remove <copied_package_name>.
Par exemple : $ sudo yum remove chef-14.10.9-1.el7.x86_64.rpm.
d. Accédez au répertoire /opt et ôtez-en tous les fichiers du client Chef Infra en supprimant le répertoire d'installation $ sudo rm -rf /opt/chef.