Configuration initiale du service Integration Runtime pour les connecteurs d'intégration
Une fois ThingWorx installé, procédez comme suit pour télécharger et configurer le service ThingWorx Runtime. Si vous travaillez dans un environnement Docker, vous pouvez utiliser un programme d'installation pour définir une configuration de base pour les connecteurs d'intégration. Le programme d'installation contient un fichier journal dans lequel vous pouvez modifier des paramètres de configuration, comme cela est décrit ci-après.
Téléchargement d'Integration Runtime
Le service Integration Runtime est disponible sur le site support.ptc.com, sous Télécharger un logiciel > Commander et télécharger des mises à jour > ThingWorx Foundation > Release <version> > ThingWorx Integration Runtime > Code de date le plus récent > ThingWorx-Integration-Runtime-<version>.
Configuration d'Integration Runtime
 |
Ne créez pas un objet depuis le modèle d'objet IntegrationRuntime.
|
1. Créez une clé d'application dans ThingWorx pour Integration Runtime qui sera utilisée pour la communication avec ThingWorx Platform.
2. Lancez les services d'intégration en tant que processus Java selon l'une des méthodes suivantes :
|
|
N'activez pas les paramètres Dorg.apache.camel.jmx.createRmiConnector.
|
◦ Fichier de configuration externe spécifiant les paramètres de connexion.
java -DconfigFile=<path to IntegrationRuntime settings>-jar <path to IntegrationRuntime-x.x.x>.jar, où x.x.x correspond à la version que vous utilisez.
3. (Facultatif) Créez un fichier de paramètres logback personnalisé et spécifiez son chemin d'accès sur la ligne de commande en tapant ce qui suit : -Dlogs.includedLogback=<path to logback include>
4. Si vous chiffrez les entrées dans le fichier de configuration integrationRuntime-settings.json ou si vous chiffrez l'ensemble du fichier de configuration, vous devez spécifier le chemin d'accès à la configuration de chiffrement security-common sur le ligne de commande de la manière suivante :
|
|
-Dencrypted.config.file=true est requis dans les exemples ci-dessous si vous chiffrez l'intégralité du fichier de configuration et doit pointer vers le fichier de configuration chiffrée d'Integration Runtime. Si vous chiffrez uniquement les entrées du fichier, omettez le paramètre ou définissez-le sur faux.
|
java -Dsecret.management.config.file=<chemin d'accès à encryption.conf> -Dencrypted.config.file=true -DconfigFile=<chemin d'accès au fichier integrationRuntime-settings.json.encrypted chiffré>
Un exemple de commande est fourni ci-dessous :
java -Dsecret.management.config.file=C:\Integ_runtime\encryption.conf -Dencrypted.config.file=true -DconfigFile=integrationRuntime-settings.json.encrypted -jar C:\Integ_runtime\integration-runtime-x.x.x-bXXX.jar
5. Si vous exécutez le clustering haute disponibilité de ThingWorx, toutes les connexions WebSocket doivent être routées via un serveur de connexion ThingWorx.
Le connecteur d'intégration utilise des WebSockets pour communiquer avec ThingWorx. Une configuration haute disponibilité (HA) type utilise plusieurs serveurs de connexion avec un équilibreur de charge situé devant les serveurs de connexion. Dans configuration HA, le runtime d'intégration doit être routé via l'équilibreur de charge configuré et vers un serveur de connexion.
Exemple de fichier de configuration (integrationRuntime-settings.json)
{
"traceRoutes": "false",
"OutboundTimeout": "1",
"Thingworx": {
"appKey": "1234abcd-xxxx-yyyy-zzzz-5678efgh",
"host": "localhost",
"port": "8443",
"basePath": "/Thingworx",
"sslEnable": "true",
"ignoreSSLErrors": "false"
},
"Performance": {
"minPoolSize":"4",
"maxPoolSize":"10",
"maxThreadLife":"10000",
"maxQueueSize":"1000"
},
"Proxy": {
"host":"localhost",
"port":"8888",
"user":"<proxy username>",
"pass":"<proxy password>"
},
"SSL": {
"verbose": "true",
"Keystore": {
"path": "/usr/security/keystore.jks",
"password": "encrypt.keystore.password"
},
"Truststore": {
"path": "/usr/security/truststore",
"password": "encrypt.truststore.password"
}
},
"RetryPolicy": {
"MaximumRetries": 2,
"RetryDelay": 2000,
"BackoffMultiplier": 1
},
"RedirectPolicy": {
"MaximumRedirects": 3,
"EnableRedirect": true
}
}
"traceRoutes": "false",
"OutboundTimeout": "1",
"Thingworx": {
"appKey": "1234abcd-xxxx-yyyy-zzzz-5678efgh",
"host": "localhost",
"port": "8443",
"basePath": "/Thingworx",
"sslEnable": "true",
"ignoreSSLErrors": "false"
},
"Performance": {
"minPoolSize":"4",
"maxPoolSize":"10",
"maxThreadLife":"10000",
"maxQueueSize":"1000"
},
"Proxy": {
"host":"localhost",
"port":"8888",
"user":"<proxy username>",
"pass":"<proxy password>"
},
"SSL": {
"verbose": "true",
"Keystore": {
"path": "/usr/security/keystore.jks",
"password": "encrypt.keystore.password"
},
"Truststore": {
"path": "/usr/security/truststore",
"password": "encrypt.truststore.password"
}
},
"RetryPolicy": {
"MaximumRetries": 2,
"RetryDelay": 2000,
"BackoffMultiplier": 1
},
"RedirectPolicy": {
"MaximumRedirects": 3,
"EnableRedirect": true
}
}
Paramètres du fichier de configuration
Comme expliqué dans les descriptions, vous pouvez spécifier ou remplacer certains paramètres dans le fichier de configuration en utilisant des propriétés système Java (par exemple, -D<name>=<value>).
|
Paramètre
|
Par défaut
|
Description
|
|---|---|---|
|
traceRoutes
|
false
|
Spécifie si l'exécution du routage doit consigner des messages lorsque chaque processeur du routage est appelé.
|
|
Thingworx
|
Spécifie les paramètres requis pour la connexion à ThingWorx Platform (mode serveur unique) ou à l'équilibreur de charge du serveur de connexion (mode cluster), formatés au format JSON.
|
|
|
SSL
|
Spécifie les paramètres SSL (Secure Sockets Layer) dans le format JSON.
|
|
Paramètre
|
Par défaut
|
Description
|
||
|---|---|---|---|---|
|
appKey
|
Spécifie la clé d'application de ThingWorx Platform qui a été configurée pour utilisation par cet Integration Runtime. Ce paramètre peut être remplacé par une propriété système Java.
|
|||
|
basePath
|
/Thingworx
|
Spécifie le chemin d'accès de base dans l'URI de ThingWorx Platform (mode serveur unique) ou de l'équilibreur de charge du serveur de connexion (mode cluster). Ce paramètre peut être remplacé par une propriété système Java.
|
||
|
OutboundTimeout
|
Délai d'inactivité de la connexion de WSCommnucationSubsystem
|
Spécifie le délai d'inactivité d'Integration Runtime pour toute requête tierce à l'état En attente. Si aucune valeur n'est spécifiée, Integration Runtime utilisera la valeur du délai d'inactivité de la connexion de WSCommunicationSubsytem.
Au démarrage d'Integration Runtime, il compare la valeur spécifiée dans le fichier integrationRuntime-settings.json et le délai d'inactivité de la connexion de WSCommunictaionSubsystem. La plus faible de ces deux valeurs sera transmise à Integration Runtime.
La valeur par défaut est 30 et peut être définie selon les besoins.
|
||
|
host
|
localhost
|
Spécifie l'hôte dans l'URI de ThingWorx Platform (mode serveur unique) ou de l'équilibreur de charge du serveur de connexion (mode cluster). Ce paramètre peut être remplacé par une propriété système Java.
|
||
|
port
|
443
|
Spécifie le port dans l'URI de ThingWorx Platform (mode serveur unique) ou de l'équilibreur de charge du serveur de connexion (mode cluster). Ce paramètre peut être remplacé par une propriété système Java.
|
||
|
sslEnable
|
true
|
Spécifie si le protocole SSL doit être utilisé pour la connexion à ThingWorx Platform via WebSocket. Si ce paramètre est défini sur "vrai", le protocole "wss" est utilisé pour l'URI. Sinon, le protocole "ws" est utilisé.
|
||
|
ignoreSSLErrors
|
false
|
Spécifie si les erreurs SSL doivent être ignorées. Cette valeur ne doit pas être définie sur vrai dans un environnement de production.
|
|
Paramètre
|
Par défaut
|
Description
|
|---|---|---|
|
minPoolSize
|
4
|
Nombre minimal de threads alloués à un pool de traitement des événements.
|
|
maxPoolSize
|
10
|
Nombre maximal de threads alloués à un pool de traitement des événements.
|
|
maxThreadLife
|
10000
|
Temps d'attente maximal pour un thread.
|
|
maxQueueSize
|
1 000
|
Nombre maximal d'entrées dans la file d'attente avant l'ajout d'un nouveau thread de travail.
|
|
Paramètre
|
Par défaut
|
Description
|
|---|---|---|
|
host
|
N/A
|
Nom de l'hôte proxy.
|
|
port
|
N/A
|
Numéro de port de l'hôte proxy.
|
|
User
|
N/A
|
Nom d'utilisateur de l'hôte proxy.
|
|
Pass
|
N/A
|
Mot de passe de l'hôte proxy.
|
|
Paramètre
|
Par défaut
|
Description
|
|---|---|---|
|
verbose
|
false
|
Spécifie si le protocole handshake Java génère des messages détaillés. Si ce paramètre est défini sur "vrai", la propriété système Java javax.net.debug est définie sur ssl:handshake:verbose.
|
|
Keystore
|
Spécifie les paramètres KeyStore SSL au format JSON.
|
|
|
Truststore
|
Spécifie les paramètres truststore SSL dans le format JSON.
|
|
Paramètre
|
Description
|
|---|---|
|
path
|
Spécifie le chemin d'accès au fichier KeyStore SSL. L'utilisation de ce paramètre revient à définir la propriété système Java javax.net.ssl.keyStore.
|
|
password
|
Spécifie le mot de passe du fichier KeyStore SSL. L'utilisation de ce paramètre revient à définir la propriété système Java javax.net.ssl.keyStorePassword. Pour éviter de stocker le mot de passe en texte brut, utilisez la valeur encrypt.keystore.password. Consultez la section Paramètres de chiffrement des mots de passe ci-dessous.
|
|
Paramètre
|
Description
|
|---|---|
|
path
|
Spécifie le chemin d'accès au fichier truststore SSL. L'utilisation de ce paramètre revient à définir la propriété système Java javax.net.ssl.trustStore.
|
|
password
|
Spécifie le mot de passe du fichier truststore SSL. L'utilisation de ce paramètre revient à définir la propriété système Java javax.net.ssl.trustStorePassword. Pour éviter de stocker le mot de passe en texte brut, utilisez la valeur encrypt.truststore.password. Consultez la section Paramètres de chiffrement des mots de passe ci-dessous.
|
|
Paramètre
|
Par défaut
|
Description
|
|---|---|---|
|
MaximumRetries
|
2
|
Spécifie le nombre maximal de nouvelles tentatives d'une requête qui a échoué en raison de l'indisponibilité du système.
Pour les requêtes HTTP, les nouvelles tentatives génèrent une réponse 503 du serveur.
|
|
RetryDelay
|
1 000
|
Lors de l'échec d'une requête pour laquelle une nouvelle tentative est possible, RetryDelay représente le temps d'attente (en millisecondes) avant d'effectuer une nouvelle tentative. RetryDelay sera utilisé avec BackoffMultiplier pour déterminer les nouvelles tentatives suivante.
|
|
BackoffMultiplier
|
1
|
Spécifie le nombre par lequel multiplier RetryDelay pour les nouvelles tentatives suivantes. Par exemple, si BackoffMultiplier est défini sur 2 et MaximumRetries sur 3, la première nouvelle tentative survient après une seconde, la deuxième deux secondes après la première, la troisième quatre secondes après, etc.
|
|
UnauthorizedRetries
|
2
|
Spécifie le nombre maximal de nouvelles tentatives d'une requête qui a échoué car elle n'était pas autorisée. Ce paramètre s'applique à une requête HTTP qui génère une réponse 401 du serveur.
|
|
Paramètre
|
Par défaut
|
Description
|
|---|---|---|
|
MaximumRedirects
|
3
|
Spécifie le nombre maximal de nouvelles tentatives de redirection.
|
|
EnableRedirect
|
true
|
Spécifie si la redirection est autorisée pour les requêtes générant un code d'état de redirection 3xx.
|
Chiffrement du fichier de configuration
Pour renforcer la sécurité, vous pouvez chiffrer l'ensemble du fichier de configuration ou, au choix, les valeurs individuelles qu'il contient. Cette fonction est disponible depuis la version 8.0.4+ d'Integration Runtime. L'installation d'Integration Runtime inclut la bibliothèque security-common. Le fichier jar de cette bibliothèque est inclus dans l'installation d'Integration Runtime. Il fournit l'outil back-end qui se charge du chiffrement et du déchiffrement du fichier de configuration.
Une interface de ligne de commande (CLI) est disponible pour interagir avec la bibliothèque de sécurité, y compris pour chiffrer le fichier de configuration. Pour plus d'informations sur cette CLI, reportez-vous à la rubrique Outil de gestion de la sécurité. Cette rubrique vous explique comment vous procurer l'outil et comment l'utiliser. Pour plus de commodité, les étapes spécifiques d'Integration Runtime sont indiquées dans les sections ci-dessous. Vous pouvez télécharger la CLI depuis le Site de Support PTC.
1. La bibliothèque security-common requiert son propre fichier de configuration. A l'aide d'un éditeur de texte, créez le fichier suivant et enregistrez-le sous le nom encryption.conf :
{
security {
secret-provider = "com.thingworx.security.provider.keystore.KeyStoreProvider"
default-encryption-key-length = 128
keystore {
password-file-path = "/ThingworxPlatform"
password-file-name = "keystore-password"
path = "/ThingworxStorage"
name = "keystore"
}
}
}
security {
secret-provider = "com.thingworx.security.provider.keystore.KeyStoreProvider"
default-encryption-key-length = 128
keystore {
password-file-path = "/ThingworxPlatform"
password-file-name = "keystore-password"
path = "/ThingworxStorage"
name = "keystore"
}
}
}
2. Créez les répertoires password-file-path et path spécifiés dans le fichier encryption.conf. Dans l'exemple ci-dessus, le répertoire password-file-path est /ThingworxPlatform (Linux). Sur un ordinateur Windows, ce répertoire est C:\\ThingworxPlatform.
|
|
Vous pouvez stocker le fichier de configuration chiffré où vous le souhaitez. Assurez-vous simplement que le fichier de configuration chiffré et les variables d'environnement pointent vers le bon chemin.
|
3. En supposant que vous avez téléchargé et extrait la distribution de la CLI, vous pouvez chiffrer le fichier de configuration. Ouvrez une invite de commande ou un shell, et accédez au répertoire securitycommon-cli-x.x.x.xx/bin, où x.x.x.xx désigne la version de l'outil.
4. Exécutez la CLI, en fonction de votre système d'exploitation :
◦ Linux : security-common-cli
◦ Windows : security-common-cli.bat
5. Lorsque vous y êtes invité, entrez le nom du fichier de configuration de la sécurité à initialiser. Voici un exemple Linux de la séquence :
../security-common-cli-1.x.x.xx/bin$ ./security-common-cli
Not initialized, use 'init <config-file>' to initialize
> init [pathTo]encryption.conf
Loading config from file encryption.conf
Secret Provider: com.thingworx.security.provider.keystore.KeyStoreProvider
KeyStore
Path: /ThingworxPlatform/keystore
Password File: /ThingworxStorage/keystore-password
Keystore Password: 336974503775017XXXX
>
Not initialized, use 'init <config-file>' to initialize
> init [pathTo]encryption.conf
Loading config from file encryption.conf
Secret Provider: com.thingworx.security.provider.keystore.KeyStoreProvider
KeyStore
Path: /ThingworxPlatform/keystore
Password File: /ThingworxStorage/keystore-password
Keystore Password: 336974503775017XXXX
>
6. Dans l'interface CLI de sécurité, chiffrez le fichier de configuration d'Integration Runtime. Dans cet exemple, nous traitons le fichier integrationRuntime-settings.json en utilisant la commande encryptFile, comme illustré ci-dessous :
encryptFile C:\Integ_runtime\integrationRuntime-settings.json C:\Integ_runtime\integrationRuntime-settings.json.encrypted
integrationRuntime-settings.json.encrypted est votre fichier de configuration chiffré.
7. Vérifiez que le chiffrement a réussi à l'aide de la commande decryptFile :decryptFile C:\Integ_runtime\integrationRuntime-settings.json.encrypted C:\Integ_runtime\integrationRuntime-settings.json.decrypted
|
|
Le contenu de integrationRuntime-settings.json.decrypted doit correspondre au contenu du fichier integrationRuntime-settings.json d'origine.
|
|
|
Supprimez les versions non chiffrées du fichier.
|
8. Pour fermer la CLI, entrez exit à l'invite.
Chiffrement des entrées du fichier de configuration
Les mots de passe ou autres entrées du fichier de configuration peuvent être chiffrés dans Integration Runtime 8.0.4+. Utilisez le même mécanisme de chiffrement pour ThingWorx Platform que celui utilisé pour chiffrer le mot de passe de la base de données PostgreSQL.
Suivez les instructions fournies à la rubrique Chiffrement de mots de passe, mais en utilisant les valeurs encrypt.app.key au lieu de encrypt.db.password ou encrypt.licensing.password, et en utilisant integrationRuntime-settings.json au lieu de platform-settings.json. Si votre système ThingWorx utilise déjà le chiffrement pour le mot de passe de la base de données PostgreSQL, ces nouveaux mots de passe seront ajoutés au même fichier KeyStore. Sinon, un nouveau fichier KeyStore sera créé.
Migration du KeyStore et du mot de passe du KeyStore
En cas d'utilisation d'un KeyStore pour chiffrer les valeurs, si vous effectuez une migration, menez à bien les étapes suivantes sur les fichiers de KeyStore et de mot de passe :
1. Si Integration Runtime utilise toujours twx/config et /ThingworxStorage/keyStore comme fichiers de KeyStore, procédez comme suit :
◦ Copiez /twx/config dans /ThingworxPlatform/keystore-password.
◦ Copiez /ThingworxStorage/keyStore dans /ThingworxStorage/keystore.jks.
2. Avec ThingWorx 8.5, le format du KeyStore a été modifié de .jks en .pfx. Vous devez migrer le KeyStore. Pour plus d'informations, consultez la section "Evolutions dans ThingWorx 8.5" de la rubrique Outil de gestion de la sécurité.
3. Cette étape varie selon que votre Integration Runtime partage les fichiers de KeyStore avec le KeyStore du serveur ThingWorx 8.5+ :
◦ S'il partage les fichiers de KeyStore avec le KeyStore de ThingWorx Platform 8.5+, suivez les instructions du manuel anglais Upgrading ThingWorx (Mise à niveau de ThingWorx) pour que le serveur ThingWorx migre automatiquement le fichier de KeyStore de l'ancien format ".jks" vers le nouveau format ".pfx".
◦ S'il ne partage pas les fichiers de KeyStore avec la plateforme, procédez comme suit :
a. Téléchargez la dernière version de la CLI security-common-cli. Pour plus d'informations, consultez la section "Utilisation" de la rubrique, Outil de gestion de la sécurité.
b. Démarrez la CLI et le KeyStore sera automatiquement migré. Par exemple :
./security-common-cli encryption.conf
.
c. Dans votre fichier encryption.conf, remplacez toutes les références à keystore.jks par keystore. N'incluez pas l'extension de fichier .pfx.
d. Sauvegardez l'ancien keystore.jks dans un emplacement sûr et supprimez-le du répertoire ThingworxStorage.
Configuration pour SSL
Par défaut, Integration Runtime se connectera à ThingWorx avec SSL. La table suivante décrit les configurations de ThingWorx Platform et les paramètres de configuration d'Integration Runtime associés requis pour établir la connexion. Les paramètres du KeyStore ne sont pas nécessaires pour la connexion à ThingWorx Platform. Ils fournissent un certificat client depuis Integration Runtime dans une négociation SSL bidirectionnelle.
|
Configuration de ThingWorx
|
Paramètres d'Integration Runtime
|
|---|---|
|
ThingWorx n'est pas configuré pour SSL
|
Spécifiez thingworxUri à l'aide d'une propriété système Java et utilisez le protocole ws, ou spécifiez sslEnable=false dans les paramètres SSL.
|
|
ThingWorx est configuré pour SSL à l'aide d'un certificat auto-signé
|
Spécifiez sslEnable=true et ignoreSSLErrors=true dans les paramètres SSL.
|
|
ThingWorx est configuré pour SSL avec un certificat auto-signé approuvé.
ThingWorx est configuré pour SSL avec un certificat signé par une autorité de certification (CA) et n'est pas configuré pour fournir l'intégralité de la chaîne de certificats d'autorité de certification.
|
Exportez le certificat à partir du fichier KeyStore, puis importez-le dans un fichier truststore.
Spécifiez enable=true et Trustore dans les paramètres SSL.
Le mot de passe Truststore peut être chiffré.
Vous pouvez également ajouter le certificat au truststore par défaut de la JVM d'Integration Runtime (généralement accessible à ce chemin :$JAVA_HOME/lib/security/cacerts). Dans ce cas, il n'est pas nécessaire de spécifier explicitement Truststore dans les paramètres SSL.
|
|
ThingWorx est configuré pour SSL avec un certificat signé par une autorité de certification et est configuré pour fournir l'intégralité de la chaîne de certificats d'autorité de certification.
|
Spécifiez enable=true dans les paramètres SSL. Il s'agit du réglage par défaut.
|
Exemple de configuration SSL : configuration pour un environnement de non-production
Si ThingWorx est configuré pour SSL avec un certificat auto-signé, utilisez la configuration integrationRuntime-settings.json suivante.
{
"Thingworx": {
"appKey": "1234abcd-xxxx-yyyy-zzzz-5678efgh",
"host": "localhost",
"port": "8443",
"sslEnable": "true",
"ignoreSSLErrors": "true"
}
}
"Thingworx": {
"appKey": "1234abcd-xxxx-yyyy-zzzz-5678efgh",
"host": "localhost",
"port": "8443",
"sslEnable": "true",
"ignoreSSLErrors": "true"
}
}
Exemple de configuration SSL : configuration pour un environnement de production
Si ThingWorx est configuré pour SSL avec un certificat auto-signé, procédez comme suit pour créer un truststore.
1. Récupérez le certificat auto-signé du serveur. Vous l'utiliserez à l'étape suivante pour forcer Integration Runtime à lui faire confiance.
Si le certificat n'est pas stocké en local, voici une méthode permettant d'acquérir le certificat auto-signé de ThingWorx Platform :
openssl s_client -connect your-ThingWorx-platform:8443< /dev/null| sed -ne'/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'twx-platform-public.crt
2. Créez une copie locale du truststore qu'Integration Runtime utilisera pour faire confiance au certificat auto-signé du serveur.
Plutôt que d'ajouter le certificat manquant directement au truststore principal de la JVM, faites-en une copie, puis ajoutez le certificat manquant à la copie.
cp $JAVA_HOME/jre/lib/security/cacerts /etc/opt/java/security/cacerts-customized
$JAVA_HOME/bin/keytool -importcert -alias somealias -keystore /etc/opt/java/security/cacerts-customized -file twx-platform-public.crt
$JAVA_HOME/bin/keytool -importcert -alias somealias -keystore /etc/opt/java/security/cacerts-customized -file twx-platform-public.crt
3. Modifiez le mot de passe du truststore.
Le mot de passe par défaut du fichier cacerts de la JVM est changeit. De la même manière que pour le mot de passe d'un KeyStore, il est possible de modifier le mot de passe de cacerts-customized avec la commande suivante :
keytool storepasswd keystore /etc/opt/java/security/cacerts-customized
Enter keystore password: changeit
New keystore password: new-password
Re-enter new keystore password: new-password
Enter keystore password: changeit
New keystore password: new-password
Re-enter new keystore password: new-password
4. Utilisez le fichier integrationRuntime-settings.json suivant.
{
"Thingworx": {
"appKey": "1234abcd-xxxx-yyyy-zzzz-5678efgh",
"host": "localhost",
"port": "8443",
"sslEnable": "true",
"ignoreSSLErrors": "false"
}
"SSL": {
"Truststore": {
"path": "/etc/opt/java/security/cacerts-customized",
"password": "new-password"
}
}
}
"Thingworx": {
"appKey": "1234abcd-xxxx-yyyy-zzzz-5678efgh",
"host": "localhost",
"port": "8443",
"sslEnable": "true",
"ignoreSSLErrors": "false"
}
"SSL": {
"Truststore": {
"path": "/etc/opt/java/security/cacerts-customized",
"password": "new-password"
}
}
}
Exemple de fichier de configuration de journal (integrationRuntime-logback.xml)
<?xml version="1.0"?>
<included>
<property name="logs.dir" value="/ThingworxStorage/IRlogs" />
<property name="logs.uniqueId" value="${processId}" />
<property name="logs.maxFileSize" value="1MB" />
<property name="logs.maxIndex" value="5" />
<logger name="com.twx.integration" level="DEBUG" />
<logger name="org.apache.camel" level="DEBUG" />
</included>
<included>
<property name="logs.dir" value="/ThingworxStorage/IRlogs" />
<property name="logs.uniqueId" value="${processId}" />
<property name="logs.maxFileSize" value="1MB" />
<property name="logs.maxIndex" value="5" />
<logger name="com.twx.integration" level="DEBUG" />
<logger name="org.apache.camel" level="DEBUG" />
</included>
Paramètres du fichier de configuration de journal
Un fichier de configuration logback.xml standard est inclus dans le fichier IntegrationRuntime.jar. Pour en savoir plus sur la configuration de logback, consultez le site Web Logback Project. Ce fichier configure l'enregistreur racine pour la journalisation sur la console et un fichier journal de substitution. Vous pouvez spécifier un fichier d'inclusion facultatif à l'aide de cette propriété système Java : logs.includedLogback. Utilisez le fichier d'inclusion pour activer d'autres enregistreurs et spécifier les propriétés applicables. Le fichier journal de substitution est configuré avec une fenêtre fixe et des critères d'activation basés sur la taille. Il peut être personnalisé en définissant les propriétés ci-dessous :
|
Paramètre
|
Par défaut
|
Description
|
|---|---|---|
|
logs.dir
|
Spécifie l'emplacement de création des fichiers journaux. L'emplacement par défaut est le répertoire de travail actuel.
|
|
|
logs.maxFileSize
|
5MB
|
Spécifie la taille maximale du fichier journal avant de basculer sur un nouveau fichier journal.
|
|
logs.maxIndex
|
9
|
Spécifie l'index maximal de la fenêtre de substitution à taille fixe. L'index initial démarre à 1.
|
|
logs.timestampPattern
|
yyyy-dd-MM HH:mm:ss.SSS
|
Spécifie le modèle d'horodatage à utiliser pour chaque événement consigné.
|
|
logs.uniqueId
|
<processId>
|
Spécifie une valeur qui est ajoutée au nom de fichier journal. Ce paramètre est utilisé pour créer des noms de fichier uniques. La valeur par défaut est obtenue via un rappel Java pour renvoyer l'ID de processus de la JVM.
|