Impostazione iniziale del servizio Integration Runtime per i connettori di integrazione
Dopo avere installato ThingWorx, attenersi alla procedura descritta di seguito per scaricare e configurare il servizio ThingWorx Runtime. In un ambiente Docker, è possibile utilizzare un programma di installazione per impostare una configurazione di base per i connettori di integrazione. Il programma di installazione include un file di registrazione in cui è possibile modificare alcune configurazioni come descritto di seguito.
Download di Integration Runtime
Il servizio Integration Runtime è disponibile sul sito support.ptc.com in Scarica il software > Order or Download Software Updates > ThingWorx Foundation > Release <versione> > ThingWorx Integration Runtime > Most Recente Datecode > ThingWorx-Integration-Runtime-<versione>.
Configurazione di Integration Runtime
 |
Non creare un oggetto dal modello di oggetto IntegrationRuntime.
|
1. Creare una chiave di accesso in ThingWorx per Integration Runtime, da utilizzare per la comunicazione con ThingWorx Platform.
2. Avviare i servizi Integration come un processo Java utilizzando una delle opzioni seguenti.
|
|
Non attivare le impostazioni -Dorg.apache.camel.jmx.createRmiConnector.
|
◦ File di configurazione esterno che specifica i parametri di connessione.
java -DconfigFile=<percorso impostazioni IntegrationRuntime>-jar <percorso IntegrationRuntime-x.x.x>.jar, dove x.x.x viene sostituito con la versione in uso.
3. Facoltativamente, creare un file di impostazioni logback personalizzato e specificarne il percorso nella riga di comando come segue: -Dlogs.includedLogback=<path to logback include>
4. Se si stanno crittografando le voci nel file di configurazione integrationRuntime-Settings.json o si sta crittografando l'intero file di configurazione, è necessario specificare il percorso della configurazione di crittografia security-common nella riga di comando con le seguenti opzioni:
|
|
-Dencrypted.config.file=true è necessario negli esempi riportati di seguito se si sta crittografando l'intero file di configurazione; deve puntare al file di configurazione di Integration Runtime crittografato. Se si stanno crittografando solo le voci nel file, omettere l'impostazione o impostarla su false.
|
java -Dsecret.management.config.file=<percorso di encryption.conf> -Dencrypted.config.file=true -DconfigFile=<percorso del file integrationRuntime-settings.json.encrypted crittografato>
Di seguito è riportato un comando di esempio:
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. Se si esegue il clustering a disponibilità elevata di ThingWorx, tutte le connessioni WebSocketdevonoessere instradate attraverso un server ThingWorx Connection Server.
Il connettore di integrazione utilizza i WebSocket per comunicare con ThingWorx. Un tipico scenario a disponibilità elevata utilizza più server connessioni con un servizio di bilanciamento del carico davanti a tali server. In uno scenario a disponibilità elevata il runtime di integrazione deve instradare attraverso il servizio di bilanciamento del carico configurato e verso un server connessioni.
File di configurazione di esempio (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
}
}
Impostazioni del file di configurazione
Come illustrato nelle descrizioni, è possibile specificare alcune impostazioni di configurazione oppure sostituire le impostazioni del file di configurazione utilizzando le proprietà del sistema Java (ad esempio -D<name>=<value>).
|
Impostazione
|
Default
|
Descrizione
|
|---|---|---|
|
traceRoutes
|
false
|
Specifica se l'esecuzione dell'instradamento deve registrare messaggi di log quando viene richiamato ciascun processo nell'instradamento.
|
|
Thingworx
|
Specifica le impostazioni necessarie per la connessione a ThingWorx Platform (modalità a server singolo) o al servizio di bilanciamento del carico del server connessioni (modalità cluster), formattato come JSON.
|
|
|
SSL
|
Specifica le impostazioni SSL (Secure Sockets Layer) in formato JSON.
|
|
Impostazione
|
Default
|
Descrizione
|
||
|---|---|---|---|---|
|
appKey
|
Specifica la chiave di accesso di ThingWorx Platform configurata per l'utilizzo da parte di questo Integration Runtime. È possibile sostituire questa impostazione con una proprietà del sistema Java.
|
|||
|
basePath
|
/Thingworx
|
Specifica il percorso di base nell'URI di ThingWorx Platform (modalità a server singolo) o del servizio di bilanciamento del carico del server connessioni (modalità cluster). È possibile sostituire questa impostazione con una proprietà del sistema Java.
|
||
|
OutboundTimeout
|
Timeout connessioni inattive di WSCommunicationSubsytem
|
Specifica il timeout di Integration Runtime per qualsiasi richiesta di terze parti in stato di attesa. Se non è specificato alcun valore, Integration Runtime usa il valore del timeout delle connessioni inattive di WSCommunicationSubsytem.
Quando viene avviato, Integration Runtime confronta il valore specificato nel file integrationRuntime-settings.json e il timeout delle connessioni inattive di WSCommunicationSubsytem. A Integration Runtime verrà passato il valore più basso tra questi.
Il valore di default è 30 e può essere impostato in base alle esigenze.
|
||
|
host
|
localhost
|
Specifica l'host nell'URI di ThingWorx Platform (modalità a server singolo) o del servizio di bilanciamento del carico del server connessioni (modalità cluster). È possibile sostituire questa impostazione con una proprietà del sistema Java.
|
||
|
port
|
443
|
Specifica la porta nell'URI di ThingWorx Platform (modalità a server singolo) o il servizio di bilanciamento del carico del server connessioni (modalità cluster). È possibile sostituire questa impostazione con una proprietà del sistema Java.
|
||
|
sslEnable
|
true
|
Specifica se è necessario utilizzare SSL per la connessione a ThingWorx Platform tramite WebSocket. Se true, per l'URI viene utilizzato il protocollo "wss". In caso contrario viene utilizzato il protocollo "ws".
|
||
|
ignoreSSLErrors
|
false
|
Specifica se è necessario ignorare gli errori SSL. In un ambiente di produzione, questo valore non deve essere impostato su true.
|
|
Impostazione
|
Default
|
Descrizione
|
|---|---|---|
|
minPoolSize
|
4
|
Numero minimo di thread allocati a un pool di elaborazione eventi.
|
|
maxPoolSize
|
10
|
Numero massimo di thread allocati a un pool di elaborazione eventi.
|
|
maxThreadLife
|
10000
|
Tempo massimo di attesa di risposta per un thread.
|
|
maxQueueSize
|
1000
|
Numero massimo di voci della coda prima di aggiungere un nuovo thread di lavoro.
|
|
Impostazione
|
Default
|
Descrizione
|
|---|---|---|
|
host
|
N/D
|
Nome dell'host proxy.
|
|
port
|
N/D
|
Numero di porta dell'host proxy.
|
|
User
|
N/D
|
Nome utente dell'host proxy.
|
|
Pass
|
N/D
|
Password dell'host proxy.
|
|
Impostazione
|
Default
|
Descrizione
|
|---|---|---|
|
verbose
|
false
|
Specifica se il protocollo handshake Java restituisce messaggi dettagliati. Se true, la proprietà del sistema Java javax.net.debug è impostata su ssl:handshake:verbose.
|
|
Keystore
|
Specifica le impostazioni keystore SSL in formato JSON.
|
|
|
Truststore
|
Specifica le impostazioni truststore SSL in formato JSON.
|
|
Impostazione
|
Descrizione
|
|---|---|
|
path
|
Specifica il percorso al file keystore SSL. L'utilizzo di questa impostazione è equivalente all'impostazione della proprietà javax.net.ssl.keyStore del sistema Java.
|
|
password
|
Specifica la password per il file keystore SSL. L'utilizzo di questa impostazione è equivalente all'impostazione della proprietà javax.net.ssl.keyStorePassword del sistema Java. Per evitare di memorizzare la password come testo semplice, utilizzare il valore encrypt.keystore.password. Vedere la sezione Impostazioni di crittografia delle password riportata di seguito.
|
|
Impostazione
|
Descrizione
|
|---|---|
|
path
|
Specifica il percorso al file truststore SSL. L'utilizzo di questa impostazione è equivalente all'impostazione della proprietà javax.net.ssl.trustStore del sistema Java.
|
|
password
|
Specifica la password per il file truststore SSL. L'utilizzo di questa impostazione è equivalente all'impostazione della proprietà javax.net.ssl.trustStorePassword del sistema Java. Per evitare di memorizzare la password come testo semplice, utilizzare il valore encrypt.truststore.password. Vedere la sezione Impostazioni di crittografia delle password riportata di seguito.
|
|
Impostazione
|
Default
|
Descrizione
|
|---|---|---|
|
MaximumRetries
|
2
|
Specifica il numero di nuovi tentativi da eseguire per una richiesta non riuscita a causa della mancata disponibilità del sistema.
In caso di richieste HTTP, i tentativi si verificano con una risposta 503 dal server.
|
|
RetryDelay
|
1000
|
Quando una richiesta ha esito negativo ma può essere ripetuta, RetryDelay rappresenta l'intervallo di attesa, in millisecondi, prima di un nuovo tentativo. RetryDelay viene utilizzata insieme a BackoffMultiplier per determinare i tentativi successivi.
|
|
BackoffMultiplier
|
1
|
Specifica il numero per cui deve essere moltiplicato il valore di RetryDelay nei tentativi successivi. Ad esempio, se BackoffMultiplier è impostata su2 e MaximumRetries è impostata su 3, il primo tentativo viene eseguito dopo 1 secondo; il secondo tentativo 2 secondi dopo il primo; il terzo 4 secondi dopo e così via.
|
|
UnauthorizedRetries
|
2
|
Specifica il numero di nuovi tentativi da eseguire per una richiesta non riuscita a causa di una richiesta non autorizzata. Questa impostazione si applica a una richiesta HTTP con una risposta 401 dal server.
|
|
Impostazione
|
Default
|
Descrizione
|
|---|---|---|
|
MaximumRedirects
|
3
|
Specifica il numero di nuovi tentativi da eseguire per un reindirizzamento.
|
|
EnableRedirect
|
true
|
Specifica se il reindirizzamento è attivato per le richieste che restituiscono un codice di stato di reindirizzamento 3xx.
|
Crittografia del file di configurazione
Per garantire maggiore protezione, è possibile crittografare l'intero file di configurazione e, facoltativamente, i singoli valori all'interno del file. Questa funzionalità è disponibile nella versione 8.0.4+ di Integration Runtime. L'installazione di Integration Runtime include la libreria security-common. Il file JAR per questa libreria è incluso nell'installazione di Integration Runtime e fornisce lo strumento back-end che esegue la crittografia e la decrittografia del file di configurazione.
È disponibile un'interfaccia della riga di comando (CLI) per interagire con la libreria di sicurezza, che include la crittografia del file di configurazione. Per informazioni complete su questa interfaccia, fare riferimento allo strumento di gestione della protezione. In questo argomento viene illustrato dove scaricare lo strumento e come utilizzarlo. Per comodità, i passaggi specifici di Integration Runtime sono disponibili nelle sezioni riportate di seguito. È possibile scaricare l'interfaccia della riga di comando dal sito del supporto tecnico PTC.
1. La libreria security-common richiede un proprio file di configurazione. Utilizzando un editor di testo, creare il file seguente e salvarlo come 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. Creare le directory password-file-path e path specificate nel file encryption.conf. Nell'esempio precedente, la directory password-file-path è /ThingworxPlatform (Linux). In un computer Windows è C:\\ThingworxPlatform.
|
|
È possibile memorizzare il file di configurazione crittografato in qualsiasi posizione. È solo necessario assicurarsi che il file di configurazione della crittografia e le variabili di ambiente indichino il percorso corretto.
|
3. Supponendo di avere scaricato ed estratto la distribuzione CLI, è possibile crittografare il file di configurazione. Aprire un prompt dei comandi o una shell e passare alla directory securitycommon-cli-x.x.x.xx/bin, in cui x.x.x.xx rappresenta la versione dello strumento.
4. Eseguire l'interfaccia della riga di comando con il comando specifico del sistema operativo in uso.
◦ Linux - security-common-cli
◦ Windows - security-common-cli.bat
5. Quando richiesto, immettere il nome del file di configurazione di sicurezza da inizializzare. Di seguito è riportato un esempio della sequenza in Linux.
../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. Mentre l'interfaccia della riga di comando di sicurezza è ancora aperta, crittografare il file di configurazione di Integration Runtime. In questo esempio è indicato il file integrationRuntime-settings.json con il comando encryptFile, come mostrato di seguito.
encryptFile C:\Integ_runtime\integrationRuntime-settings.json C:\Integ_runtime\integrationRuntime-settings.json.encrypted
integrationRuntime-settings.json.encrypted è il file di configurazione crittografato.
7. Verificare che la crittografia abbia avuto esito positivo utilizzando il comando decryptFile:decryptFile C:\Integ_runtime\integrationRuntime-settings.json.encrypted C:\Integ_runtime\integrationRuntime-settings.json.decrypted
|
|
Il contenuto di integrationRuntime-settings.json.decrypted deve corrispondere al contenuto del file integrationRuntime-settings.json originale.
|
|
|
Rimuovere le versioni non crittografate del file.
|
8. Per chiudere l'interfaccia della riga di comando, digitare exit al prompt.
Crittografia delle voci del file di configurazione
Le password o altre voci del file di configurazione possono essere crittografate in Integration Runtime 8.0.4 +. Utilizzare per ThingWorx Platform lo stesso meccanismo di crittografia utilizzato per crittografare la password del database PostgreSQL.
Attenersi alle istruzioni riportate in Crittografia delle password, ma specificare i valori encrypt.app.key invece di encrypt.db.password o encrypt.licensing.password e utilizzare integrationRuntime-Settings.json anziché platform-settings.json. Se il sistema ThingWorx utilizza già la crittografia per la password del database PostgreSQL, queste nuove password vengono aggiunte allo stesso file keystore. In caso contrario ne viene creato uno nuovo.
Migrazione di keystore e della password keystore
Se è stato utilizzato un keystore per la crittografia dei valori, in caso di migrazione attenersi alla procedura descritta di seguito per i file keystore e di password.
1. Se Integration Runtime utilizza ancora twx/config e /ThingworxStorage/keyStore come file keystore, eseguire le operazioni indicate di seguito.
◦ Copiare /twx/config in /ThingworxPlatform/keystore-password
◦ Copiare /ThingworxStorage/keyStore in /ThingworxStorage/keystore.jks
2. A partire da ThingWorx 8.5, il formato del keystore è stato modificato da .jks a .pfx. È necessario eseguire la migrazione del keystore. Per ulteriori informazioni, vedere "Modifiche in ThingWorx 8.5" nell'argomento Strumento di gestione della protezione.
3. Questo passo varia a seconda che i file keystore di Integration Runtime vengano condivisi o meno con il keystore del server ThingWorx 8.5+:
◦ Se i file keystore vengono condivisi con il keystore di ThingWorx Platform 8.5+, attenersi alla guida Upgrading ThingWorx per fare in modo che la migrazione del file keystore dal vecchio formato ".jks" al nuovo formato ".pfx" venga eseguita automaticamente dal server ThingWorx.
◦ Se i file keystore non vengono condivisi con la piattaforma, attenersi alla procedura descritta di seguito.
a. Scaricare la versione più recente di security-common-cli. Per assistenza, vedere la sezione "Utilizzo" dell'argomento Strumento di gestione della protezione.
b. Avviare l'interfaccia della riga di comando e la migrazione del keystore verrà eseguita automaticamente. Ad esempio:
./security-common-cli encryption.conf
c. Nel file encryption.conf modificare tutti i riferimenti a keystore.jks in keystore. Non includere l'estensione file .pfx.
d. Eseguire il backup del vecchio file keystore.jks in una posizione sicura e rimuoverlo dalla directory ThingworxStorage.
Configurazione per SSL
Per default, Integration Runtime si connette a ThingWorx mediante SSL. La tabella riportata di seguito illustra le configurazioni di ThingWorx Platform e le impostazioni di configurazione di Integration Runtime associate che sono necessarie per stabilire la connessione. Le impostazioni keystore non sono necessarie per la connessione a ThingWorx Platform, ma forniscono un certificato client da Integration Runtime in una negoziazione SSL bidirezionale.
|
Configurazione di ThingWorx
|
Impostazioni di Integration Runtime
|
|---|---|
|
ThingWorx non è configurato per SSL.
|
Specificare thingworxUri utilizzando una proprietà del sistema Java e utilizzare il protocollo ws o specificare sslEnable=false nelle impostazioni SSL.
|
|
ThingWorx è configurato per SSL mediante certificato autofirmato.
|
Specificare sslEnable=true e ignoreSSLErrors=true nelle impostazioni SSL.
|
|
ThingWorx è configurato per SSL con un certificato autofirmato e il certificato è attendibile.
ThingWorx è configurato per SSL con un certificato firmato da un'autorità di certificazione (CA) e non è stato configurato per fornire l'intera catena di certificati CA.
|
Esportare il certificato dal file keystore e importarlo in un file truststore.
Specificare enable=true e Trustore nelle impostazioni SSL.
La password truststore potrebbe essere crittografata.
In alternativa, aggiungere il certificato al truststore di default JVM di Integration Runtime, generalmente disponibile in questo percorso:$JAVA_HOME/lib/security/cacerts. In questo caso non è necessario specificare esplicitamente il truststore nelle impostazioni SSL.
|
|
ThingWorx è configurato per SSL con un certificato firmato da un'autorità di certificazione (CA) ed è stato configurato per fornire l'intera catena di certificati CA.
|
Specificare enable=true nelle impostazioni SSL. Questa è l'impostazione di default.
|
Esempio di configurazione SSL: configurazione di non produzione
Se ThingWorx è configurato per SSL con un certificato autofirmato, utilizzare il file integrationRuntime-settings.json seguente:
{
"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"
}
}
Esempio di configurazione SSL: configurazione di produzione
Se ThingWorx è configurato per SSL con un certificato autofirmato, attenersi alla procedura descritta di seguito per creare un truststore.
1. Recuperare il certificato autofirmato del server. Viene utilizzato nel passo successivo per forzarne l'attendibilità per Integration Runtime.
Se il certificato non è memorizzato a livello locale, questa procedura è un modo per acquisire il certificato autofirmato di ThingWorx Platform.
openssl s_client -connect your-ThingWorx-platform:8443< /dev/null| sed -ne'/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'twx-platform-public.crt
2. Creare una copia locale del truststore che Integration Runtime utilizzerà per considerare attendibile il certificato autofirmato del server.
Anziché aggiungere il certificato mancante direttamente al truststore del materiale di JVM, salvarne innanzitutto una copia, quindi aggiungere il certificato mancante alla copia.
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. Modificare la password del truststore.
La password di default per il file cacerts JVM è changeit. Analogamente alla procedura per la modifica della password di qualsiasi altro keystore, potremmo modificare la password di cacerts- customized compilando quanto segue:
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. Utilizzare il file integrationRuntime-settings.json riportato di seguito.
{
"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"
}
}
}
File di configurazione del log di esempio (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>
Impostazioni del file di configurazione del log
Nel file IntegrationRuntime.jar è incluso un file di configurazione logback.xml standard. Per ulteriori informazioni sulla configurazione del logback, visitare il sito Web Logback Project. Questo file imposta il logger radice con la registrazione alla console e un file di log di rolling. È possibile specificare un file di inclusione facoltativo utilizzando la proprietà logs.includedLogback del sistema Java. Utilizzare il file di inclusione per attivare altri logger e specificare proprietà. Il file di log di rolling è configurato con una finestra fissa e criteri di attivazione basati sulla dimensione e può essere personalizzato impostando le proprietà seguenti:
|
Impostazione
|
Default
|
Descrizione
|
|---|---|---|
|
logs.dir
|
Specifica la posizione in cui i file di log vengono generati. Il valore di default è la directory di lavoro corrente.
|
|
|
logs.maxFileSize
|
5MB
|
Specifica la dimensione del file di log massima che attiva un'azione di rollover per un nuovo file di log.
|
|
logs.maxIndex
|
9
|
Specifica l'indice massimo della finestra di rollover a dimensione fissa. L'indice iniziale inizia a 1.
|
|
logs.timestampPattern
|
aaaa-gg-MM HH.mm.ss.SSS
|
Specifica l'espressione di data e ora da utilizzare per ogni evento di log.
|
|
logs.uniqueId
|
<processId>
|
Specifica un valore che viene aggiunto al nome del file di log. Questa impostazione è utilizzata per generare nomi di file univoci. Il valore di default è ottenuto tramite un callback Java per restituire l'ID del processo di JVM.
|