Konnektoren testen
Test-Befehl
Der Befehl test wird verwendet, um die Konnektor-Artefakte zu testen. Die Artefakte haben einige allgemeine und einige spezielle Optionen. Der Test-Befehl übernimmt den Typ des Artefakts als Unterbefehl. Der Test-Befehl verfügt über die folgenden Befehle:
Befehle | Beschreibung |
|---|---|
flow test action <name> | Testet die Aktion namens <name>. |
flow test connection <name> | Testet die Verbindung namens <name>. |
flow test lookup <name> <method> | Testet die Lookup-Funktion namens <method> im Lookup <name>. |
flow test oauth <name> | Testet die OAuth namens <name>. |
flow test trigger <name> <method> | Testet den Trigger namens <name>. |
Der Test-Befehl verfügt über die folgenden Optionen:
Optionen | Beschreibung | Datentyp |
|---|---|---|
--version | Zeigt die Versionsnummer an. | [Boolean] |
--help | Zeigt die Hilfe an. | [Boolean] |
--timeout | Das Timeout für die Operation. Die Option "--timeout" gibt ein Timeout in Millisekunden an (der Standardwert sind 30000 ms). Diese Option stellt sicher, dass der Code innerhalb des angegebenen Zeitraums beendet wird, und erfasst Fehler, z.B. den fehlenden Aufruf von Callbacks. | [Standardwert: 30000] |
--logLevel,-1 | Legt die Protokollebene fest. | [Standardwert: "info"] |
Die ThingWorx Flow Befehlszeilenschnittstelle ermöglicht es Ihnen, einzelne Artefakte vor der Bereitstellung des Konnektors auf dem Server zu testen. So können Sie leichter prüfen, ob Ihre Artefakte ordnungsgemäß funktionieren, bevor Sie den Konnektor bereitstellen.
Die Testfälle werden unter Verwendung des mocha-chai-Frameworks geschrieben. Mocha wird verwendet, um die Testsuite zu definieren, und Chai wird als Bestätigungsbibliothek verwendet. Alle Testfälle werden im Ordner testData definiert, der in einem bestimmten Artefakttest-Ordner abgelegt ist.
Der Befehl test ermöglicht das Testen von Artefakten in der ThingWorx Flow Befehlszeilenschnittstelle.
Um ein Artefakt zu testen, führen Sie die folgenden Befehle in der Eingabeaufforderung aus:
1. cd <user project root directory>
2. flow test <artifactType> <name>
Konfiguration für das Testen von OAuths und Triggern
Die Befehle flow test oauth und flow test trigger starten intern einen Webserver. Der Webserver akzeptiert nur https-Anfragen. Um dem Server die Annahme von Anfragen zu erlauben, ist das Konfigurieren von Zertifikaten erforderlich. Wenn Zertifikate fehlen, tritt der folgende Fehler auf:
[2018-09-19T10:13:11.876] [ERROR] trigger - Validation of trigger failed : ENOENT: no such file or directory, open 'C:\[2018-09-19T10:13:11.876] [ERROR] trigger - Validation of trigger failed : ENOENT: no such file or directory, open 'C:\<user-home-dir\.flow\key.pem>
Gehen Sie wie folgt vor, um ein selbstsigniertes Zertifikat zu erstellen:
1. Laden Sie openssl und installieren Sie dieses.
2. Unter der Annahme, dass openssl im Pfad enthalten ist, führen Sie openssl req -nodes -new -x509 -keyout key.pem -out cert.pem aus.
3. Kopieren Sie diese Dateien in das Verzeichnis .flow im Basisverzeichnis des Benutzers.
Um den Hostnamen und Port zu konfigurieren, erstellen Sie eine Datei namens flow.json im Verzeichnis .flow des Basisverzeichnisses des Benutzers. Eine Beispieldatei sieht folgendermaßen aus:
{
"passphrase": "xyz",
"hostname" : "flow.local.rnd.ptc.com",
"port" : 443
}
"passphrase": "xyz",
"hostname" : "flow.local.rnd.ptc.com",
"port" : 443
}
Alle Eigenschaften sind optional.
• Passphrase: Wird mit dem privaten Schlüssel verwendet, der eine Passphrase erfordert.
• Hostname: Wird verwendet, um den redirect_uri für OAuth und Trigger-URLs zu erstellen. Viele Dienste erlauben "localhost" nicht als gültigen Hostnamen in redirect_uri. Einige Anwendungen schreiben explizit vor, dass keine localhost-URLs als Webhook-Registrierungs-URLs verwendet werden dürfen. Sie können auch versuchen, die URL für Ihr Entwicklungssystem für Testzwecke mit Ihrem Produktionssystem abzugleichen. Wenn beispielsweise der bei Google registrierte redirect_uri https://flow.local.rnd.ptc.com/Thingworx/Oauths/oauth/return lautet, muss der Hostname in der Datei flow.json flow.local.rnd.ptc.com lauten. Zusätzlich sollte der Host in <%WINDIR%>\system32\drivers\etc\hosts hinzugefügt werden.
 | Zum Bearbeiten der Datei führen Sie den Editor als Administrator aus. |
OAuth-Konfiguration testen
Das Testen der OAuth-Konfiguration erfolgt über einen Browser, da jeder OAuth-Anbieter ein anderes Formular für das Akzeptieren der Benutzeranmeldeinformationen hat. Die Befehlszeilenschnittstelle führt intern einen Express-Web-Server aus, um die Antworten zu verarbeiten, die vom IdP bei einer erfolgreichen oder fehlgeschlagenen Authentifizierung gesendet werden.
Gehen Sie wie folgt vor, um eine OAuth-Konfiguration zu testen:
1. Führen Sie in Ihrem Projektverzeichnis den folgenden Befehl aus:
flow test oauth <oauth name>
Nach erfolgreicher Anmeldung wird das OAuth-Validierer-Browser-Fenster geöffnet. Weitere Informationen finden Sie in dem Beispiel im Tutorial.
2. Wählen Sie die zu testende Konfiguration aus, und klicken Sie dann auf die Schaltfläche "Validate OAuth configuration" oder auf "Exit".
Verbindungen testen
Der Befehl test connection ruft die validate-Methode auf. Anschließend ruft er die connect-Methode auf, testet die Eingabe anhand des Eingabeschemas und die Ausgabe anhand des Ausgabeschemas.
Um eine Verbindung zu testen, gehen Sie wie folgt vor:
1. Führen Sie in Ihrem Projektverzeichnis den folgenden Befehl aus:
npm install
2. Erstellen Sie eine Test-Datendatei im Paket und füllen Sie Ihre Dienstanbieterinformationen als Daten ein.
Die Datei enthält Beispieldaten für den Test connectionTestData in <Projektverzeichnis>\test\testData, wie im Code folgenden dargestellt.
module.exports = {
sampleInput : {
email : 'your-email-id-here',
subscription_id:'your-subscription-id',
account_url: 'your-account-url',
token: 'your-token'
},
sampleOutput : {
handle: {
email : 'your-email-id-here',
subscription_id:'your-subscription-id',
account_url: 'your-account-url',
token: 'your-token'
} }
}
sampleInput : {
email : 'your-email-id-here',
subscription_id:'your-subscription-id',
account_url: 'your-account-url',
token: 'your-token'
},
sampleOutput : {
handle: {
email : 'your-email-id-here',
subscription_id:'your-subscription-id',
account_url: 'your-account-url',
token: 'your-token'
} }
}
3. Führen Sie den Test-Befehl mit den folgenden Optionen aus:
Optionen | Beschreibung | Datentyp |
|---|---|---|
--version | Zeigt die Versionsnummer an. | [Boolean] |
--help | Zeigt die Hilfe an. | [Boolean] |
--timeout | Das Timeout für die Operation. Die Option --timeout gibt einen Timeout in Millisekunden an (der Standardwert ist 30000 ms). Diese Option stellt sicher, dass der Code innerhalb des angegebenen Zeitraums beendet wird, und erfasst Fehler, z.B. den fehlenden Aufruf von Callbacks. | [Standardwert: 30000] |
--logLevel,-1 | Legt die Protokollebene fest. | [Standardwert: "info"] |
--artifactVersion,-v | Zu testende Artefaktversion. | - |
--projectDir,-d | Das Elternverzeichnis des Projekts. | - |
--input,-i | Name der Eingabevariablen. | - |
--output,-o | Name der erwarteten Ausgabevariablen. | - |
--testDataFile,-f | Pfad der testData-Datei. | - |
--save,-s | Speichert im Anmeldeinformationsspeicher für einen Benutzer. | - |
--noSchemaValidation,-n | Deaktiviert die Schemavalidierung. | [Standardwert: false] |
Durch das Ausführen des Tests wird Ausgabe produziert, wenn sowohl die connect-Methode als auch die validate-Methode erfolgreich ausgeführt werden. Der Befehl überprüft auch, ob die Eingabe dem Eingabeschema entspricht und ob die Ausgabe der erwarteten Ausgabe entspricht.
Die Option --save speichert die Ausgabe des connect-Befehls in der Datei creds.json im Ordner .flow im Basisverzeichnis des Benutzers. Die Ausgabe der Ausführung dieses Befehls ist der Schlüssel, anhand dessen die Verbindung in der Datei gespeichert wird. Verwenden Sie diesen Schlüssel später, um die gespeicherten Authentifizierungsinformationen an einen anderen test-Befehl zu übergeben.
Lookups testen
Lookups haben eine andere Struktur als andere Artefakte und werden nicht auf die gleiche Weise versioniert wie andere Artefakte. Der Name selbst dient als die Version. Wenn eine neuere Funktionalität erforderlich ist, wird ein neuer Lookup in der Lookup-JavaScript-Datei erstellt. Führen Sie den test-Befehl für Lookups mit dem folgenden Befehl aus:
Die folgenden Optionen sind verfügbar:
Optionen | Beschreibung | Datentyp |
|---|---|---|
--version | Zeigt die Versionsnummer an. | [Boolean] |
--help | Zeigt die Hilfe an. | [Boolean] |
--timeout | Das Timeout für die Operation. Die Option "--timeout" gibt ein Timeout in Millisekunden an (der Standardwert sind 30000 ms). Diese Option stellt sicher, dass der Code innerhalb des angegebenen Zeitraums beendet wird, und erfasst Fehler, z.B. den fehlenden Aufruf von Callbacks. | [Standardwert: 30000] |
--logLevel,-1 | Legt die Protokollebene fest. | [Standardwert: "info"] |
--projectDir,-d | Das Elternverzeichnis des Projekts. | - |
--connection,-c | Die UID der einzufügenden Verbindung. | - |
--access_token,-a | Name der erwarteten Ausgabevariablen. | - |
--input,-i | Pfad der testData-Datei. | - |
--output,-o | Name der erwarteten Ausgabevariablen. | - |
--testDataFile,-f | Pfad der testData-Datei. | - |
--searchById | Die für die Suche zu verwendende ID. | - |
--searchByValue | Der für die Suche zu verwendenden Wert. | - |
--filter | Der für die Suche nach Elementen zu verwendende Filter. | - |
flow test lookup <name> <method>
Lookups bieten zwei Suchoptionen – searchById und searchByValue – sowie die folgenden drei Optionen in Bezug auf den Seitenumbruch.
• Lookup gibt alle Daten gleichzeitig zurück – Für diese Option ist keine Aktion erforderlich.
• Paginierungs-API von Anwendung unterstützt – Der Lookup-Code ruft die getNextPage-API auf und übergibt ihr Argumente, die den Dienst dabei unterstützen können, Daten von der nächsten Seite zurückzugeben. Diese Informationen werden an das Lookup übergeben, wenn der Benutzer in der Liste für die Lookup-Feldwerte auf die Option "Mehr laden" klickt.
• Paginierung nicht unterstützt – Die Anwendung fragt die Daten ab, und der Lookup-Dienst schneidet die Daten so ab, dass nur Datensätze für die aktuelle Seite und alle vorherigen Seiten angezeigt werden.
Aktionen testen
Das Testen von Aktionen ähnelt dem Testen von Lookups. Lookups werden beim Testen einer Aktion nicht getestet. Die Eingabe sollte bereits die Ergebnisse enthalten, die sonst durch die Lookups bereitgestellt werden.
Um eine Aktion zu testen, gehen Sie wie folgt vor:
1. Schreiben Sie eine Beispieleingabe- und eine Beispielausgabe-JSON in eine Test-Datendatei. Eingabe- und Ausgabebeispiele finden Sie im Tutorial B.
2. Führen Sie in Ihrem Projektverzeichnis den Test-Befehl mit den folgenden Optionen aus:
Optionen | Beschreibung | Datentyp |
|---|---|---|
--version | Zeigt die Versionsnummer an. | [Boolean] |
--help | Zeigt die Hilfe an. | [Boolean] |
--timeout | Das Timeout für die Operation. Die Option "--timeout" gibt ein Timeout in Millisekunden an (der Standardwert sind 30000 ms). Diese Option stellt sicher, dass der Code innerhalb des angegebenen Zeitraums beendet wird, und erfasst Fehler, z.B. den fehlenden Aufruf von Callbacks. | [Standardwert: 30000] |
--logLevel,-1 | Legt die Protokollebene fest. | [Standardwert: "info"] |
--artifactVersion,-v | Zu testende Artefaktversion. | [Standardwert: "v1"] |
--connection,-c | Die UID der einzufügenden Verbindung. | - |
--access_token,-a | Name der erwarteten Ausgabevariablen. | - |
--projectDir,-d | Das Elternverzeichnis des Projekts. | [Standardwert: "."] |
--input,-i | Pfad der testData-Datei. | - |
--output,-o | Name der erwarteten Ausgabevariablen. | - |
--testDataFile,-f | Pfad der testData-Datei. | - |
--noSchemaValidation,-n | Deaktiviert die Schemavalidierung. | [Standardwert: false] |
Trigger testen
Das Testen einen Triggers unterscheidet sich etwas vom Testen von Aktionen, Verbindungen und Lookups. Sie können den Test-Befehl mit den folgenden Optionen ausführen:
Die folgende Tabelle beschreibt die verschiedenen Optionen, die für das Testen von Triggern verfügbar sind.
Optionen | Beschreibung | Datentyp |
|---|---|---|
--version | Zeigt die Versionsnummer an. | [Boolean] |
--help | Zeigt die Hilfe an. | [Boolean] |
--timeout | Das Timeout für die Operation. Die Option "--timeout" gibt ein Timeout in Millisekunden an (der Standardwert sind 30000 ms). Diese Option stellt sicher, dass der Code innerhalb des angegebenen Zeitraums beendet wird, und erfasst Fehler, z.B. den fehlenden Aufruf von Callbacks. | [Standardwert: 30000] |
--logLevel,-1 | Legt die Protokollebene fest. | [Standardwert: "info"] |
--artifactVersion,-v | Zu testende Artefaktversion. | [Standardwert: "v1"] |
--connection,-c | Die UID der einzufügenden Verbindung. | - |
--access_token,-a | Name der erwarteten Ausgabevariablen. | - |
--projectDir,-d | Das Elternverzeichnis des Projekts. | [Standardwert: "."] |
--input,-i | Name der Eingabevariablen. | - |
--output,-o | Name der erwarteten Ausgabevariablen. | - |
--testDataFile,-f | Pfad der testData-Datei. | - |
--noSchemaValidation,-n | Deaktiviert die Schemavalidierung. | [Standardwert: false] |
--polling,-p | Gibt an, dass der Trigger ein Abruf-Trigger ist. | - |
--event,-e | Das zu testende Ereignis. | - |
--mockData,-m | Der Name der Variablen, die die Mock-Daten für ein Ereignis enthält. | - |
--interval,-t | Das Intervall in Sekunden, nach dem der Trigger ausgelöst werden soll. | [Standardwert: 15] |
--stopAfter,-s | Maximale Anzahl von Aufrufen des Triggers. | [Standardwert: 1] |
Sie müssen angeben, welche Methode getestet werden soll. Für Abruf-Trigger sind die Methoden execute und activate.
Beispiele für das Testen verschiedener Artefakte finden Sie in Tutorial B.