Anfangseinrichtung des Diensts "Integration Runtime" für Integrations-Konnektoren
Nachdem Sie ThingWorx installiert haben, führen Sie die Schritte unten aus, um den ThingWorx Runtime Dienst herunterzuladen und zu konfigurieren. Wenn Sie in einer Docker-Umgebung sind, können Sie ein Installationsprogramm verwenden, um eine einfache Konfiguration für die Integrations-Konnektoren zu installieren. Das Installationsprogramm beinhaltet eine Protokollierungsdatei, in der Sie eine Konfiguration ändern können, wie unten beschrieben.
Integration Runtime herunterladen
Der Integration Runtime-Dienst ist auf support.ptc.com unter Software herunterladen > Software-Aktualisierungen bestellen oder herunterladen > ThingWorx Foundation > Release <Version> > ThingWorx Integration Runtime > Neuester Datumscode > ThingWorx Integration Runtime <Version> verfügbar.
Integration Runtime konfigurieren
 |
Erstellen Sie kein Ding aus der Dingvorlage IntegrationRuntime.
|
1. Erstellen Sie einen Anwendungsschlüssel in ThingWorx für Integration Runtime für die Kommunikation mit ThingWorx Platform.
2. Starten Sie Integrationsdienste als Java-Prozess mithilfe einer der folgenden Optionen:
|
|
Aktivieren Sie die Einstellungen des Typs -Dorg.apache.camel.jmx.createRmiConnector nicht.
|
◦ externe Konfigurationsdatei, die Verbindungsparameter angibt.
java -DconfigFile=<Pfad zu IntegrationRuntime Einstellungen>-jar <Pfad zu IntegrationRuntime-x.x.x>.jar, wobei x.x.x durch die verwendete Version ersetzt wird.
3. (Optional) Erstellen Sie eine benutzerdefinierte Logback-Einstellungsdatei, und geben Sie den Pfad zu ihr in der Befehlszeile wie folgt an: -Dlogs.includedLogback=<path to logback include>
4. Beim Verschlüsseln von Einträgen in der Konfigurationsdatei integrationRuntime-settings.json oder Verschlüsseln der gesamten Konfigurationsdatei müssen Sie in der Befehlszeile den Pfad zur Verschlüsselungskonfiguration security-common mit dem folgenden Befehl angeben:
|
|
-Dencrypted.config.file=true ist in den folgenden Beispielen erforderlich, wenn Sie die gesamte Konfigurationsdatei verschlüsseln, und muss auf die verschlüsselte Integration Runtime Konfigurationsdatei verweisen. Wenn Sie nur Einträge in der Datei verschlüsseln, lassen Sie die Einstellung weg, oder legen Sie sie auf falsch fest.
|
java -Dsecret.management.config.file=<Pfad zu encryption.conf> -Dencrypted.config.file=true -DconfigFile=<Pfad zu verschlüsselten Datei integrationRuntime-settings.json.encrypted>
Ein Beispielbefehl wird unten bereitgestellt:
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. Wenn Sie Hochverfügbarkeits-Clustering für ThingWorx ausführen, müssen alle WebSocket-Verbindungen über einen ThingWorx Connection Server weitergeleitet werden.
Der Integrations-Konnektor verwendet WebSockets für die Kommunikation mit ThingWorx. Eine typische HA-Umgebung verwendet mehrere Connection Server mit einem Lastenausgleich vor den Connection Servern. In einer HA-Umgebung muss die Integrationslaufzeit durch den konfigurierten Lastenausgleich und zu einem Connection Server geleitet werden.
Beispielkonfigurationsdatei (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
}
}
Einstellungen der Konfigurationsdatei
Wie in den Beschreibungen erläutert können mit Java-Systemeigenschaften einige Konfigurationseinstellungen angegeben oder Einstellungen der Konfigurationsdatei überschrieben werden (beispielsweise -D<name>=<value>).
|
Einstellung
|
Standard
|
Beschreibung
|
|---|---|---|
|
traceRoutes
|
false
|
Gibt an, ob die Routing-Ausführung Meldungen protokollieren soll, wenn die Prozessoren im Routing aufgerufen werden.
|
|
Thingworx
|
Gibt die Einstellungen an, die erforderlich sind, um eine Verbindung zu ThingWorx Platform (Einzelserver-Modus) oder zum Connection Server-Lastenausgleich (Cluster-Modus) herzustellen, formatiert als JSON.
|
|
|
SSL
|
Gibt die Secure Sockets Layer (SSL)-Einstellungen im JSON-Format an.
|
|
Einstellung
|
Standard
|
Beschreibung
|
||
|---|---|---|---|---|
|
appKey
|
Gibt den Anwendungsschlüssel von ThingWorx Platform an, der für diese Integration Runtime konfiguriert wurde. Diese Einstellung kann mit einer Java-Systemeigenschaft überschrieben werden.
|
|||
|
basePath
|
/Thingworx
|
Gibt den Basispfad im URI zu ThingWorx Platform (Einzelserver-Modus) oder zum Connection Server-Lastenausgleich (Cluster-Modus) an. Diese Einstellung kann mit einer Java-Systemeigenschaft überschrieben werden.
|
||
|
OutboundTimeout
|
Leerlauf-Verbindungs-Timeout des WSCommunicationSubsystem
|
Gibt das Integration Runtime-Timeout für alle Drittparteien-Anfragen im Wartestatus an. Wenn kein Wert angegeben wird, verwendet Integration Runtime einen Wert aus dem Leerlauf-Verbindungs-Timeout des WSCommunicationSubsystem.
Wenn Integration Runtime gestartet wird, vergleicht der Dienst den in der Datei "integrationRuntime-settings.json" angegebenen Wert und das Leerlauf-Verbindungs-Timeout des WSCommunicationSubsystem. Der kleinere dieser beiden Werte wird an Integration Runtime übergeben.
Der Standardwert ist 30. Der Wert kann jedoch nach Bedarf festgelegt werden.
|
||
|
host
|
localhost
|
Gibt den Host im URI zu ThingWorx Platform (Einzelserver-Modus) oder zum Connection Server-Lastenausgleich (Cluster-Modus) an. Diese Einstellung kann mit einer Java-Systemeigenschaft überschrieben werden.
|
||
|
port
|
443
|
Gibt den Port im URI zu ThingWorx Platform (Einzelserver-Modus) oder zum Connection Server-Lastenausgleich (Cluster-Modus) an. Diese Einstellung kann mit einer Java-Systemeigenschaft überschrieben werden.
|
||
|
sslEnable
|
true
|
Gibt an, ob SSL verwendet werden sollte, um eine Verbindung mit ThingWorx Platform über WebSocket herzustellen. Bei "true" wird das Protokoll "wss" für den URI verwendet. Andernfalls wird das Protokoll "ws" verwendet.
|
||
|
ignoreSSLErrors
|
false
|
Gibt an, ob SSL-Fehler ignoriert werden sollen. Dieser Wert sollte in einer Produktionsumgebung nicht auf wahr festgelegt werden.
|
|
Einstellung
|
Standard
|
Beschreibung
|
|---|---|---|
|
minPoolSize
|
4
|
Mindest-Anzahl der einem Ereignis-Verarbeitungspool zugeordneten Threads
|
|
maxPoolSize
|
10
|
Maximale Anzahl der einem Ereignis-Verarbeitungspool zugeordneten Threads
|
|
maxThreadLife
|
10000
|
Maximale Antwort-Wartezeit für einen Thread
|
|
maxQueueSize
|
1000
|
Maximale Anzahl an Warteschlangeneinträgen, bevor ein neuer Arbeitsthread hinzugefügt wird
|
|
Einstellung
|
Standard
|
Beschreibung
|
|---|---|---|
|
host
|
N/A
|
Name des Proxy-Hosts
|
|
port
|
N/A
|
Portnummer des Proxy-Hosts
|
|
Benutzer
|
N/A
|
Benutzername des Proxy-Hosts
|
|
Pass
|
N/A
|
Passwort des Proxy-Hosts
|
|
Einstellung
|
Standard
|
Beschreibung
|
|---|---|---|
|
verbose
|
false
|
Gibt an, ob das Java-Handshake-Protokoll ausführliche Meldungen auslöst. Bei "true" wird die Java-Systemeigenschaft javax.net.debug auf ssl:handshake:verbose eingestellt.
|
|
Keystore
|
Gibt die SSL-Schlüsselspeichereinstellungen im JSON-Format an.
|
|
|
Truststore
|
Gibt die SSL-Vertrauensspeichereinstellungen im JSON-Format an.
|
|
Einstellung
|
Beschreibung
|
|---|---|
|
path
|
Gibt den Pfad zur SSL-Schlüsselspeicherdatei an. Die Verwendung dieser Einstellung entspricht dem Einstellen der Java-Systemeigenschaft javax.net.ssl.keyStore.
|
|
password
|
Gibt das Passwort für die SSL-Schlüsselspeicherdatei an. Die Verwendung dieser Einstellung entspricht dem Einstellen der Java-Systemeigenschaft javax.net.ssl.keyStorePassword. Um das Speichern des Passworts als einfachen Text zu vermeiden, verwenden Sie den Wert encrypt.keystore.password. Siehe Abschnitt "Passworteinstellungen verschlüsseln" unten.
|
|
Einstellung
|
Beschreibung
|
|---|---|
|
path
|
Gibt den Pfad zur SSL-Vertrauensspeicherdatei an. Die Verwendung dieser Einstellung entspricht dem Einstellen der Java-Systemeigenschaft javax.net.ssl.trustStore.
|
|
password
|
Gibt das Passwort für die SSL-Vertrauensspeicherdatei an. Die Verwendung dieser Einstellung entspricht dem Einstellen der Java-Systemeigenschaft javax.net.ssl.trustStorePassword. Um das Speichern des Passworts als einfachen Text zu vermeiden, verwenden Sie den Wert encrypt.truststore.password. Siehe Abschnitt "Passworteinstellungen verschlüsseln" unten.
|
|
Einstellung
|
Standard
|
Beschreibung
|
|---|---|---|
|
MaximumRetries
|
2
|
Gibt die Häufigkeit für erneute Versuche einer Anforderung an, nachdem sie aufgrund der Verfügbarkeit des Systems fehlgeschlagen ist.
Im Falle von HTTP-Anforderungen erfolgen erneute Versuche mit einer 503-Antwort vom Server.
|
|
RetryDelay
|
1000
|
Wenn eine Anforderung fehlschlägt, aber wiederholt werden kann, repräsentiert RetryDelay, wie lange (in Millisekunden) vor dem erneuten Versuch gewartet wird. RetryDelay wird zusammen mit BackoffMultiplier verwendet, wenn nachfolgende erneute Versuche ermittelt werden.
|
|
BackoffMultiplier
|
1
|
Gibt an, wie lange RetryDelay für nachfolgende erneute Versuche multipliziert wird. Wenn beispielsweise BackoffMultiplier auf 2 und MaximumRetries auf 3 festgelegt wurde, würde der erste erneute Versuch nach 1 Sekunde, der zweite erneute Versuch 2 Sekunden nach dem ersten, die dritte nach 4 Sekunden usw. erfolgen.
|
|
UnauthorizedRetries
|
2
|
Gibt die Häufigkeit für erneute Versuche einer Anforderung an, die aufgrund einer nicht autorisierten Anforderung fehlgeschlagen ist. Diese Einstellung gilt für eine HTTP-Anforderung mit einer 401-Antwort vom Server.
|
|
Einstellung
|
Standard
|
Beschreibung
|
|---|---|---|
|
MaximumRedirects
|
3
|
Gibt die Häufigkeit für erneute Versuche einer Weiterleitung an.
|
|
EnableRedirect
|
true
|
Gibt an, ob die Weiterleitung für Anforderungen aktiviert ist, die in einem Weiterleitungsstatuscode von 3xx resultieren.
|
Konfigurationsdatei verschlüsseln
Um eine höhere Sicherheit zu gewährleisten, können Sie die gesamte Konfigurationsdatei und optional einzelne Werte in der Datei verschlüsseln. Diese Funktion wird in Version 8.0.4+ von Integration Runtime zur Verfügung gestellt. Die Installation von Integration Runtime umfasst die Bibliothek security-common. Die JAR-Datei für diese Bibliothek ist in der Integration Runtime-Installation enthalten. Sie stellt das Back-End-Tool bereit, das die Verschlüsselung und Entschlüsselung der Konfigurationsdatei durchführt.
Eine Befehlszeilenschnittstelle (Command Line Interface, CLI) steht für die Interaktion mit der Sicherheitsbibliothek zur Verfügung; dazu zählt auch die Verschlüsselung der Konfigurationsdatei. Ausführliche Informationen zu dieser CLI finden Sie unter Sicherheitsmanagement-Tool. In diesem Thema wird erläutert, wo Sie das Tool erhalten und wie es verwendet wird. In den nachfolgenden Abschnitten finden Sie die für Integration Runtime spezifischen Schritte. Sie können die CLI von der PTC Support Website herunterladen.
1. Die Bibliothek security-common erfordert eine eigene Konfigurationsdatei. Erstellen Sie mit einem Texteditor die folgende Datei, und speichern Sie sie als 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. Erstellen Sie die Verzeichnisse password-file-path und path, die in der Datei encryption.conf angegeben sind. Im obigen Beispiel ist das Verzeichnis password-file-path /ThingworxPlatform (Linux). Auf einem Windows-Computer wäre dies C:\\ThingworxPlatform.
|
|
Sie können die verschlüsselte Konfigurationsdatei an einem beliebigen Ort speichern. Stellen Sie einfach sicher, dass die Konfigurationsdatei der Verschlüsselung und die Umgebungsvariablen auf den richtigen Pfad zeigen.
|
3. Vorausgesetzt, Sie haben die CLI-Verteilung heruntergeladen und extrahiert, können Sie die Konfigurationsdatei verschlüsseln. Öffnen Sie eine Eingabeaufforderung oder eine Shell, und navigieren Sie zum Verzeichnis securitycommon-cli-x.x.x.xx/bin, wobei x.x.x.xx die Version des Tools darstellt.
4. Führen Sie die CLI für Ihr Betriebssystem aus:
◦ Linux – security-common-cli
◦ Windows – security-common-cli.bat
5. Wenn Sie dazu aufgefordert werden, geben Sie den Namen der zu initialisierenden Sicherheitskonfigurationsdatei ein. Im Folgenden finden Sie ein Linux-Beispiel für die Sequenz:
../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. Verschlüsseln Sie die Konfigurationsdatei von Integration Runtime, während Sie sich noch in der Sicherheits-CLI befinden. In diesem Beispiel ist dies integrationRuntime-settings.json. Verwenden Sie den Befehl encryptFile wie unten dargestellt:
encryptFile C:\Integ_runtime\integrationRuntime-settings.json C:\Integ_runtime\integrationRuntime-settings.json.encrypted
integrationRuntime-settings.json.encrypted ist die verschlüsselte Konfigurationsdatei.
7. Überprüfen Sie, ob die Verschlüsselung erfolgreich war, indem Sie den folgenden decryptFile-Befehl ausführen:decryptFile C:\Integ_runtime\integrationRuntime-settings.json.encrypted C:\Integ_runtime\integrationRuntime-settings.json.decrypted.
|
|
Der Inhalt der Datei integrationRuntime-settings.json.decrypted sollte mit dem Inhalt der ursprünglichen Datei integrationRuntime-settings.json übereinstimmen.
|
|
|
Entfernen Sie die unverschlüsselten Versionen der Datei.
|
8. Um die CLI zu schließen, geben Sie exit an der Eingabeaufforderung ein.
Einträge in der Konfigurationsdatei verschlüsseln
Passwörter oder andere Einträge in der Konfigurationsdatei können in Integration Runtime 8.0.4+ verschlüsselt werden. Verwenden Sie denselben Verschlüsselungsmechanismus für ThingWorx Platform, der zum Verschlüsseln des PostgreSQL-Datenbankpassworts verwendet wird.
Befolgen Sie die Anweisungen unter Passwörter verschlüsseln, verwenden Sie jedoch die Werte encrypt.app.key anstelle von encrypt.db.password oder encrypt.licensing.password, und verwenden Sie integrationRuntime-settings.json anstelle von platform-settings.json. Wenn Ihr ThingWorx System bereits Verschlüsselung für das PostgreSQL-Datenbankpasswort verwendet, werden diese neuen Passwörter zu derselben Keystore-Datei hinzugefügt; andernfalls wird eine neue Keystore-Datei erstellt.
Keystore und Keystore-Passwort migrieren
Wenn Sie einen Keystore zum Verschlüsseln von Werten verwendet haben und eine Migration durchführen, führen Sie die folgenden Schritte für die Keystore-Dateien und Passwortdateien durch:
1. Wenn Integration Runtime weiterhin twx/config und /ThingworxStorage/keyStore als Keystore-Dateien verwendet, tun Sie Folgendes:
◦ Kopieren Sie /twx/config nach /ThingworxPlatform/keystore-password.
◦ Kopieren Sie /ThingworxStorage/keyStore nach /ThingworxStorage/keystore.jks
2. Ab ThingWorx 8.5 wurde das Keystore-Format von JKS in PFX geändert. Sie müssen den Keystore migrieren. Weitere Informationen finden Sie unter "Änderungen in ThingWorx 8.5" im Thema Sicherheitsmanagement-Tool.
3. Dieser Schritt variiert, je nachdem, ob Ihre Version von Integration Runtime Keystore-Dateien gemeinsam mit dem Keystore eines ThingWorx Servers ab Version 8.5 nutzt:
◦ Wenn die Keystore-Dateien mit dem Keystore von ThingWorx Platform ab Version 8.5 geteilt werden, müssen Sie die Anweisungen im englischen Handbuch Upgrading ThingWorx (ThingWorx aktualisieren) befolgen, damit der ThingWorx Server die Keystore-Datei automatisch vom alten Format JKS zum neuen Format PFX migriert.
◦ Wenn die Keystore-Dateien nicht mit der Plattform geteilt werden, müssen Sie diese Schritte durchführen:
a. Laden Sie die neueste Version von security-common-cli herunter. Hilfestellung finden Sie im Abschnitt "Verwendung" des Themas Sicherheitsmanagement-Tool.
b. Starten Sie die Befehlszeilenschnittstelle. Der Keystore wird automatisch migriert. Beispiel:
./security-common-cli encryption.conf
c. Ändern Sie in der Datei encryption.conf alle Referenzen auf keystore.jks in keystore. Fügen Sie nicht die Dateierweiterung .pfx hinzu.
d. Sichern Sie die alte Datei keystore.jks an einem sicheren Speicherort, und entfernen Sie sie aus dem Verzeichnis ThingworxStorage.
Für SSL konfigurieren
Standardmäßig stellt Integration Runtime eine Verbindung zu ThingWorx über SSL her. Die folgende Tabelle beschreibt die ThingWorx Platform Konfigurationen und die zugeordneten Integration Runtime-Konfigurationseinstellungen, die für eine erfolgreiche Verbindung erforderlich sind. Die Keystore-Einstellungen sind nicht für die Verbindung mit ThingWorx Platform erforderlich; sie stellen ein Client-Zertifikat von Integration Runtime in einer bidirektionalen SSL-Aushandlung bereit.
|
ThingWorx Konfiguration
|
Integration Runtime-Einstellungen
|
|---|---|
|
ThingWorx ist nicht für SSL konfiguriert
|
Geben Sie thingworxUri mithilfe einer Java-Systemeigenschaft an, und verwenden Sie das Protokoll ws, oder geben Sie sslEnable=false in den SSL-Einstellungen an.
|
|
ThingWorx ist für SSL über ein selbstsigniertes Zertifikat konfiguriert.
|
Geben Sie sslEnable=true und ignoreSSLErrors=true in den SSL-Einstellungen an.
|
|
ThingWorx ist für SSL mit einem selbstsignierten Zertifikat konfiguriert, und dem Zertifikat wird vertraut.
ThingWorx ist für SSL mit einem Zertifikat von einer Zertifizierungsstelle (Certificate Authority, CA) konfiguriert, und es wurde nicht konfiguriert, um die gesamte CA-Zertifikatkette bereitzustellen.
|
Exportieren Sie das Zertifikat aus der Schlüsselspeicherdatei, und importieren Sie es in eine Vertrauensspeicherdatei.
Geben Sie enable=true und Trustore in den SSL-Einstellungen an.
Das Vertrauensspeicherpasswort kann verschlüsselt sein.
Fügen Sie alternativ das Zertifikat zum Standardvertrauensspeicher für die Integration Runtime JVM hinzu (normalerweise hier gespeichert:$JAVA_HOME/lib/security/cacerts). In diesem Fall ist es nicht notwendig, den Vertrauensspeicher explizit in den SSL-Einstellungen anzugeben.
|
|
ThingWorx ist für SSL mit einem Zertifikat von einer Zertifizierungsstelle (Certificate Authority, CA) konfiguriert, und es wurde konfiguriert, um die gesamte CA-Zertifikatkette bereitzustellen.
|
Geben Sie enable=true in den SSL-Einstellungen an. Dies ist die Standardeinstellung.
|
SSL-Konfigurationsbeispiel: Nicht-Produktionskonfiguration
Wenn ThingWorx für SSL mit einem selbstsignierten Zertifikat konfiguriert ist, verwenden Sie die Datei integrationRuntime-settings.json:
{
"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"
}
}
SSL-Konfigurationsbeispiel: Produktionskonfiguration
Wenn ThingWorx für SSL mit einem selbstsignierten Zertifikat konfiguriert ist, verwenden Sie die folgenden Schritte, um einen Vertrauensspeicher zu erstellen:
1. Rufen Sie das selbstsignierte Zertifikat des Servers ab. Es wird im nächsten Schritt verwendet, um zu erzwingen, dass Integration Runtime ihm vertraut.
Wenn Sie das Zertifikat nicht lokal gespeichert haben, ist dies eine Möglichkeit, das selbstsignierte Zertifikat von ThingWorx Platform abzurufen.
openssl s_client -connect your-ThingWorx-platform:8443< /dev/null| sed -ne'/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'twx-platform-public.crt
2. Erstellen Sie eine lokale Kopie des Vertrauensspeichers, die Integration Runtime verwendet, um dem selbstsignierten Zertifikat des Servers zu vertrauen.
Statt das fehlende Zertifikat direkt zum Vertrauensspeicher der JVM hinzuzufügen, erstellen Sie zuerst eine Kopie und fügen das fehlende Zertifikat der Kopie hinzu.
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. Ändern Sie das Passwort des Vertrauensspeichers.
Das standardmäßige Passwort für die JVM-Datei cacerts ist changeit. Ähnlich wie beim Ändern des Passworts jedes anderen Schlüsselspeichers könnten wir das Passwort cacerts-customized durch folgende Ausgabe ändern:
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. Verwenden Sie die Datei integrationRuntime-settings.json.
{
"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"
}
}
}
Beispiel-Protokollkonfigurationsdatei (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>
Einstellungen der Protokollkonfigurationsdatei
Eine standardmäßige logback.xml-Konfigurationsdatei ist in der IntegrationRuntime.jar enthalten. Weitere Informationen zur Logback-Konfiguration finden Sie unter Logback-Projekt. Diese Datei richtet den Stammprotokollierer mit Protokollierung in der Konsole und einer rollierenden Protokolldatei ein. Sie können eine optionale Include-Datei mit dieser Java-Systemeigenschaft angeben: logs.includedLogback. Verwenden Sie die Include-Datei, um andere Protokollierer zu aktivieren und Eigenschaften anzugeben. Die rollierende Protokolldatei wird mit einem festen Fenster und größenbasierten Auslösungsrichtlinien konfiguriert und kann angepasst werden, indem Sie die folgenden Eigenschaften festlegen:
|
Einstellung
|
Standard
|
Beschreibung
|
|---|---|---|
|
logs.dir
|
Gibt den Ort an, an dem Protokolldateien generiert werden. Die Standardeinstellung ist das aktuelle Arbeitsverzeichnis.
|
|
|
logs.maxFileSize
|
5MB
|
Gibt die maximale Größe der Protokolldatei an, die das Rollover zu einer neuen Protokolldatei auslöst.
|
|
logs.maxIndex
|
9
|
Gibt den maximalen Index des Rollover-Fensters mit fester Größe an. Der ursprüngliche Index beginnt mit 1.
|
|
logs.timestampPattern
|
yyyy-dd-MM HH:mm:ss.SSS
|
Gibt das Zeitstempelmuster für jedes Protokollereignis an.
|
|
logs.uniqueId
|
<processId>
|
Gibt einen Wert an, der an den Protokolldateinamen angefügt wird. Diese Option wird verwendet, um eindeutige Dateinamen zu generieren. Der Standardwert wird über ein Java-Callback abgerufen, um die Prozess-ID der JVM zurückzugeben.
|