Integrationen

Integrationen

In dem Menüpunkt Integrationen werden alle Funktionalitäten zusammengefasst die dafür zuständig sind Daten aus anderen Systemen zu Empfangen (z.B. LoraWAN Netzwerkserver) oder an dieses zu senden (z.B. Webhook).

Integrationsflows

Integrationsflows erlauben es Datenpakete aus niotix an ein Drittsystem zu übertragen. Zusätzlich können die zu übertragenden Datenpakete vor der Übertragung gefiltert und transformiert werden. So können die relevanten Datenpakete in dem vom Drittsystem benötigten Datenformat übertragen werden.

Grundsätzlich können in einem Integrationsflow, die folgenden Daten verwendet werden:

  1. Jedes empfangene Datenpaket eines eingehenden Konnektors.
  2. Jede Änderung an einem Datenpunkt eines virtuellen Gerätes.
  3. Jede Änderung eines Datenpunktes eines digitalen Zwillings.

Hierbei werden für einen Integrationsflow zunächst alle erzeugten Daten für den jeweiligen Account berücksichtigt. Um nur die benötigten Datensätze weiter zu verarbeiten, können Filter (4) definiert werden, um diese beispielsweise auf die erzeugten Daten eines digitalen Zwillings oder Konnektors einzuschränken (siehe Kapitel “Filter”). Zusätzlich ist es möglich die Daten vor der Weiterleitung über einen Konnektor zu transformieren (5). Dabei können Daten in die gewünschte Struktur oder Datenformat gebracht werden (siehe Kapitel “Transformationen”). Am Ende eines Integrationsflows können ein oder mehrere ausgehende Konnektoren (6) für die Weiterleitung der Daten ausgewählt werden.

Beta: Dieses Feature befindet sich aktuell in der Beta-Phase. Es ist daher damit zu rechnen, dass noch kleinere Fehler auffindbar sind. Die Kernfunktionalität kommt bereits in produktiven Anwendungsfällen zum Einsatz. Sollte die Umsetzung eines kritischen Anwendungsfalls geplant sein, empfiehlt es sich einen Ansprechpartner der Digimondo GmbH zu informieren.

Einen Integrationsflow anlegen

Im Navigationspunkt Integrationen > Integrationsflows den den Button “Anlegen” verwenden, um einen neuen Integrationsflow anzulegen. Es öffnet sich der folgende Dialog:

Wichtig: Es ist das erwartete Datenformat des ausgehenden Konnektors zu beachten. Das niotix backend liefert hier im default das Datenformat “generic”. Sollen die Daten, z.B. an einen Webservice weitergeleitet werden, welcher JSON erwartet, so muss vor dem Schritt in dem die Daten an den Connector weitergeleitet werden eine Transformation stattfinden. Hierzu einfach eine Transformation mit dem dem Eingabe-Typ “generic” und dem Ausgabe-Typ “application/json” anlegen und in den Integrationsflow einbinden.

  • Name: Vergebe hier einen eindeutigen Namen
  • Auslöser: Hier ist auszuwählen welche Art von Datenstream von dem Integrationsflow berücksichtigt werden soll, es gibt folgende Optionen:
    • BEFORE STATE-HANDLING: berücksichtigt den unveränderten Datenstream der Konnektoren im Account. Diese Option sollte gewählt werden, wenn die unveränderten Rohdaten weitergeleitet werden sollen. Dabei ist zu beachten, dass diese in diesem Fall keine Metainformationen, wie beispielsweise dtwin_id zur Verfügung stehen.
    • AFTER STATE HANDLING: Hier werden alle Veränderungen eines virtuellen Gerätes oder digitalen Zwillings als Auslöser des Integrationsflows verwendet. Dabei stehen auch Metainformationen, wie beispielsweise die dtwin_id zur Verfügung.
  • Integrationsflow Schritte: Über dieses Dropdown können Filter, Transformationen und Konnektoren zu einem Integrationsflow hinzugefügt werden.
  • Reihenfolge: Definiert die Reihenfolge der Schritte eines Integrationsflows. Der letzte Schritt eines Integrationsflows muss ein Konnektor sein.

Übersicht der für Integrationsflows verfügbaren Konnektoren

Es können folgende ausgehende Konnektoren für Integrationsflows verwendet werden:

  • MQTT Broker
  • Websocket
  • Webhook (Outgoing)

Filter

In einem Integrationsflow werden alle Datenpakete eines Accounts verarbeitet. Filter können in Integrationsflows verwendet werden, um ausschließlich Datenpakete zu transformieren oder weiterzuleiten, welche den Filterkriterien entsprechen. Sie können beispielsweise genutzt werden, um Daten von einem spezifischen Zwilling oder Konnektor weiterzuleiten.

Einen Filter anlegen

Im Navigationspunkt Integrationen > Filter den den Button “Anlegen” verwenden, um einen neuen Integrationsflow anzulegen. Es öffnet sich der folgende Dialog:

  • Name: Vergebe hier einen eindeutigen Namen.
  • Extended mode: Im “Extended mode” können verschachtelte Filter über JSONATA oder Javascript erstellt werden. Wichtig: soll ein Filter für Datenpakete aus niotix erstellt werden, so ist der Eingabe-Typ “Generic” zu wählen.
  • Attribut: Wähle hier ein Attribut für die Definition der Filterbedingung aus:
    • account_id: Id des Accounts für den der Filter angewendet werden soll.
    • config_id: Id des Konnektors für den der Filter angewendet werden soll.
    • state_id: Id des Datenpunkts für den der Filter angewendet werden soll.
    • dtwin_id: Id des digitalen Zwillings oder virtuellen Gerätes für den der Filter angewendet werden soll.
    • dtwin_title: Titel des digitalen Zwillings oder virtuellen Gerätes für den der Filter angewendet werden soll.
    • twin_category: Hier kann definiert werden, ob es auf virtualDevice oder digitalTwin eingefiltert werden soll.
    • twin_tags: Tag(s) des digitalen Zwillings oder virtuellen Gerätes für den der Filter angewendet werden soll.
    • twin_key_value_: Schlüssel/Wert (siehe Benutzerdefinierte Eigenschaften) eines digitalen Zwillings oder virtuellen Gerätes für den der Filter angewendet werden soll.
    • state_identifier: Schlüssel des Datenpunkts für den Filter verwendet werden soll.
    • state_type: Ermöglicht das Filtern nach bestimmten Typen von Datenpunkten (number/string/boolean/json).
    • parser_variable: Zugewiesene Variable im parser die diesen Datenpunkt repräsentiert.
    • source_identifier: Die externe ID eines virtuellen Geräts nach der gefiltert werden soll.
    • timestamp: Zeitstempel der für den Filter zutreffen soll.
  • Operator: Hier stehen die gängigen Operatoren zur Verfügung, um die Bedingung zu definieren.
  • Wert: Vergleichswert unter der die Bedingung geprüft wird. Es können mehrere Vergleichswerte eingetragen werden (mit Return bestätigen). Diese werden in diesem Fall als ODER verknüpft.
  • + - Symbol: Hier können verschiedene Bedingungen verkettet werden (Verknüpfung der einzelnen Bedingungen ist UND).

Transformationen

Transformationen können verwendet werden, um eingehende oder ausgehende Daten in die benötigte Struktur zu bringen. Häufiger Anwendungsfall ist das Anpassen eines Payloads, z.B. für MQTT oder Webhook. Zusätzlich ist es möglich die gewünschten Ausgabewerte zu definieren.

  • Instanz-Name: Vergebe hier einen eindeutigen Namen.

  • Kontoauswahl: Wähle das Konto für den die Transformation erstellt werden soll.

  • Beschreibung: Kann verwendet werden um ergänzende Informationen zu hinterlegen.

  • Eingabe-Typ: Wähle hier aus in welchem Datenformat die Eingangsdaten sind. Wichtig: Handelt es sich hierbei um Daten aus niotix die transformiert werden sollen, so ist der Eingabetyp “generic” zu wählen.

  • Ausgabe-Typ: Lege hier fest in welchem Datenformat die Daten nach der Transformation ausgegeben werden sollen. Hier ist entsprechend des ausgehenden Konnektors/empfangenden Drittsystems das erwartete Format zu wählen.

  • Typ der Transformation: Transformationen können in jsonata oder javascript erstellt werden.

  • Beispieleingabe: Hier kann ein Beispieldatensatz hinterlegt werden, der transformiert werden soll. Ein typischer Datensatz eines niotix Datenpunkts ist wie folgt strukturiert:

    {
  "meta": {
    "timestamp": "2022-07-08T07:25:27.447Z",
    "state_id": 55292,
    "dtwin_id": 3613,
    "dtwin_title": "Example Virtual Device Name",
    "twin_tags": ["Example","Tag"],
    "twin_category": "virtualDevice",
    "twin_ancestor_ids": 1544,
    "unit": "kWh",
    "state_identifier": "kWh",
    "state_type": "number",
    "account_id": 482,
    "config_id": 202,
    "source_type": "bridge",
    "parser_variable": "kWh",
    "source_identifier": "847D50161912202E",
    "twin_key_value": {}
  },
  "value": 1055
}

Konnektoren

In diesem Abschnitt kannst du Brücken zu Drittsystemen einrichten. Diese Brücken werden verwendet, um Prozessdaten aus anderen Systemen zu empfangen oder Aktionen in anderen Systemen auszulösen.

Um einen neuen Konnektor hinzuzufügen, wähle im Anlegen-Dialog den Typ des Konnektors aus. Der Pfeil neben dem Namen des Konnektors im Menü zeigt an, ob es sich um einen eingehenden Konnektor (Pfeil nach unten) zum Daten-Empfang in niotix oder einen ausgehenden Konnektor (Pfeil nach oben) zum Daten-Versand handelt. Im Anschluss an die Auswahl werden die benötigten Konnektoreinstellungen angezeigt.

Für alle Konnektor gilt: Sobald du auf “Validieren & Speichern” klickst, werden die Änderungen validiert, wenn die Verbindung funktioniert, und der Konnektor wird direkt gespeichert. Um Konnektoren zu löschen, klicke auf den “Papierkorb”-Button.

Konnektorenübergreifende Funktionen

Die folgenden Funktionen stehen für alle Konnektoren gleichermaßen zur Verfügung:

Konnektor Logs

Nachdem ein Konnektor angelegt wurde können die Details über das Stift-Symbol eingesehen und verändert werden. Hier findet sich der Tab “Konnektor Logs”. In diesem werden die letzten 100 Pakete des Konnektors angezeigt. So lässt sich einsehen, wie und ob zum Beispiel ein eingehender Konnektor Datenpakete erhalten hat. Hierdurch wird die Fehlersuche unterstützt, sollten die Daten nicht korrekt am virtuellen Gerät oder Drittsystem ankommen.

Status Logs

Nachdem ein Konnektor angelegt wurde, können die Details über das Stift-Symbol eingesehen und verändert werden. Hier findet sich der Tab “Status Logs”. Hier findet sich ein Verbindungsprotokoll, welches die letzten 100 Logs des Konnektors bezüglich des Verbindungsstatus anzeigt. Hierdurch wird die Fehlersuche unterstützt, sollten die Daten nicht korrekt am virtuellen Gerät oder Drittsystem ankommen.

Übersicht der verfügbaren Konnektoren

Die folgenden Konnektoren stehen zur Zeit in niotix zur Verfügung:

Konnektor “firefly”

Der “firefly”-Konnektor stellt eine Verbindung zu DIGIMONDOs firefly LoRaWAN Netzwerk Server her, um Downlink-Pakete an Geräte zu senden.

Gib folgende Informationen ein:

  • Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
  • Beschreibung: Gib eine kurze Beschreibung an.
  • Template: Wird im Moment nicht zum Aufbau der Verbindung benötigt, daher deaktiviert.
  • apiKey: Füge den API-Schlüssel hinzu, den du in deiner firefly-Instanz erstellt hast - dieser API-Schlüssel wird benötigt, um sich am Firefly-System zu authentifizieren und Downlink-Pakete vom richtigen Konto zu senden.
  • baseURL: Füge die Adresse deiner firefly-Instanz ein inklusive Protokoll (“http” oder “https”).
  • Firefly MQTT Url (optional): Füge die Adresse deiner firefly RabbitMQ Instanz ein inklusive Protokoll (“mqtt” oder “mqtts”) z.B. “mqtts://messagequeue.firefly.com". Dieses Feld muss nur ausgefüllt werden, wenn Virtuelle Geräte mit firefly angelegt werden sollen.

Konnektor “actility”

Der “actility”-Konnektor ermöglicht dir Downlinks über eine Regel im Digitalen Zwilling an Actility-Geräte zu senden.

Gib folgende Informationen ein:

  • Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
  • Beschreibung: Gib eine kurze Beschreibung an.
  • Actility Custom Target Profile: Gib die Zielorganisation von Actility an.
  • baseURL: Füge die Adresse deiner Actility-Instanz ein.
  • thingparkLogin: Der Benutzername für die Anmeldung.
  • thingparkPassword: Das Passwort für die Anmeldung.

Konnektor “kafka”

Der “kafka”-Konnektor ermöglicht es Daten an einen Apache Kafka Broker weiterzuleiten. Ähnlich wie bei dem MQTT-Konnektor lassen sich so alle Aktualisierungen von Datenpunkten eines Digital Twins an den Kafka Cluster weiterleiten, um sie von dort weiter zu verarbeiten oder zu speichern.

  • Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
  • Beschreibung: Gib eine kurze Beschreibung an.
  • Broker: Die Adresse und Port des Kafka Brokers (im Format “Adresse:Port”).
  • Client ID: Die ID des Clients.
  • Topic to emit state changes: Der Titel, unter dem alle Aktualisierungen beim Kafka Broker veröffentlicht werden.
  • SASL Mechanism: Die verwendete Methode zur Anmmeldung am Kafka Broker.
  • SALS User: Der Benutzername für die Anmeldung.
  • SALS Password: Das Passwort für die Anmeldung.

Konnektor “openweathermap.org”

Der “openweathermap.org”-Konnektor bietet eine Möglichkeit, Wetterinformationen von der openweathermap.org-Plattform zu empfangen. Mit diesem Konnektor kannst du aktuelle Wetterinformationen wie Temperatur, Luftfeuchtigkeit, Wind, etc. für verschiedene Orte weltweit empfangen inklusive einer Vorhersage für bis zu 6 Tage. Die Vorhersage für Regen ist für den aktuellen Tag möglich.

Um den “openweathermap.org”-Konnektor einzurichten, musst du dich bei openweathermap.org registrieren und dort einen API-Schlüssel einrichten.

Gib folgende Informationen ein:

  • Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
  • Beschreibung: Gib eine kurze Beschreibung an.
  • API-Key: Füge den API-Schlüssel hinzu, den du in deiner openweathermap.org-Instanz erstellt hast.
  • City: Wähle den Ort, für den Sie Wetterinformationen verwenden möchten.
  • Units (Einheiten): Wähle zwischen metrischem oder imperialem System für die Angabe der Einheiten.
  • Update interval (Aktualisierungsintervall): Wähle den Zeitintervall, wie oft niotix aktualisierte Informationen abrufen soll.

Hinweis: Dieser Konnektor verwendet die one api ( https://openweathermap.org/api/one-call-3) Bitte beachte, dass, wenn du ein und denselben API-Schlüssel von openweathermap.org für viele Konnektoren verwendest, die Anzahl der Aufrufe aggregiert wird. Wenn du das Limit überschreitest, können Kosten entstehen.

Konnektor “mail”

Der"mail”-Konnektor wird im Zusammenhang mit dem Regeleditor im Digital Twin verwendet. Im Regeleditor kannst du Regeln erstellen, dass bei bestimmten Wert-Entwicklungen E-Mails versendet werden. Dafür benötigst du den Konnektor. Der Mail-Konnektor unterstützt auch die Anmeldung an Mailservern ohne Zugangsdaten (User und Passwort), wie es z.B. oft bei OnPremise-Installationen in Verwendung mit einem Microsoft Exchange Server der Fall ist.

Gib folgende Informationen ein:

  • Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
  • Beschreibung: Gib eine kurze Beschreibung an.
  • Fallback “from’-mail: Eine Absendeadresse die angezeigt wird, falls z.B. in einer Digital Twin Regel keine Absendeadresse hinterlegt wird
  • Service: Falls vorhanden, wähle deinen E-Mail-Service-Provider, um die Authentifizierung zu konfigurieren
  • Host: Gib die Adresse des SMTP-Servers an.
  • Port: Gib den Port des SMTP-Servers an.
  • User: Gib den Namen des Nutzers des Servers an.
  • Pass: Gib das Passwort dieses Nutzers an.
  • Secure/Unsecure: Wähle mit dem Schieberegler aus, ob es sich um eine gesicherte Verbindung (TLS) handelt oder nicht.
  • Ignore/UnignoreTLS: Falls die Verbindung unverschlüsselt ist (d.h. im vorherigen Punkt “unsecure”), aber mit STARTTLS erfolgen soll, muss diese Option auf “IgnoreTLS” stehen.
  • Self-signed certificate: Stelle dies auf ‘accept’, falls selbst-generierte Zertifikate erlaubt seien sollen.

Konnektor “mqtt”

Der “mqtt"Konnektor stellt einen MQTT-Client dar und baut eine Verbindung zu einem MQTT-Broker auf, um Events über niotix zu senden oder zu empfangen.

  • Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
  • Beschreibung: Gib eine kurze Beschreibung an.
  • Template: Standardmäßig ist “pass-through” ausgewählt. Dadurch wird keines der Pakete transformiert. Sollen die Daten an Datenpunkte eines virtuellen Gerätes geschrieben werden, muss das Template “Virtual Device Inbound” gewählt und je nach Datenstruktur der gelieferten MQTT Daten entsprechend der Anweisungen im Template angepasst werden.
  • Topic to emit state changes: Du kannst alle Änderungen aller Zustände deines Digital Twins an einen MQTT-Broker ausgeben. Wenn du alle Zustandsänderungen ausgeben möchtest, definiere hier das Topic. Für das Topic kannst du Platzhalter verwenden, um verschiedene Topics pro Account und/oder pro Digital Twin zu definieren (z.B. /{AccountId}/digitaltwins/{TwinId}/states/{state}"):
    • {accountId} wird durch die zugehörige Konto-ID ersetzt
    • {twinId} wird durch die zugehörige Digital Twin-ID ersetzt
    • {state} wird durch die Status-ID des entsprechenden Digital Twin ersetzt
  • Username: Gebe den Benutzername des mqtt-Client-Benutzers an.
  • Password: Gebe das Passwort des mqtt-Client-Benutzers an.
  • Path: Gebe das Topic an, in dem neue Ereignisse veröffentlicht werden sollen.
  • URL: Gebe die Adresse des MQTT-Brokers an.
  • Self-signed certificate: Über dieses Auswahlfeld könnt ihr mit “accept” einstellen, dass ihr selbst signierte Zertifikate akzeptiert oder mit “reject”, dass diese nicht akzeptiert werden. So lassen sich die mit dem MQTT-Broker ausgetauschten Daten verschlüsselt übertragen.

Konnektor “mqttbroker”

Der “mqttbroker"Konnektor stellt einen MQTT-Client dar, der auf einen im niotix Service-Verbund installierten RabbitMQ eine Verbindung aufbaut, ein Topic erzeugt und Anmeldedaten (Benutzer und Passwort) erstellt. Danach “published” der Konnektor Daten auf das automatisch erstellte Topic, die dann von “Subscribed” MQTT Clients empfangen werden können. Dieser Konnektor sollte also dann eingesetzt werden, wenn die Daten-empfangende Gegenstelle einen MQTT Client zur Verfügung hat.

Hinweis: Wir empfehlen aus Sicherheits- und Stabilitätsgründen ausdrücklich nicht den bestehenden internen niotix RabbitMQ zu verwenden, sondern immer eine neue RabbitMQ Instanz für diesen Konnektor zu erstellen. Natürlich benötigt niotix für alle Konnektoren dieses Typs nur einen RabbitMQ den sich alle teilen.

So legst du einen “mqttbroker” Konnektor an:

  • Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
  • Beschreibung: Gib eine kurze Beschreibung an.
  • Klicke auf “Validieren & Speichern”, das Topic und die Anmeldedaten werden daraufhin automatisch erstellt und angezeigt.
Überlegungen zur Quality of Service (QoS)

Der “mqttbroker”-Konnektor erlaubt es, eine QoS zu definieren, wenn er in einem Integrationsflow verwendet wird. Die folgenden Einstellungen können vorgenommen werden:

  • 0 - Höchstens einmal
  • 1 - Mindestens einmal
  • 2 - Genau einmal

Die Voreinstellung ist “0 - Höchstens einmal”. Wenn für den Anwendungsfall eine höhere Zuverlässigkeit erforderlich ist, werden die beiden anderen Optionen unterstützt. In diesen Fällen ist es notwendig, dass der abonnierende Client eine kohärente QoS verwendet, eine Client-ID angibt und clean session auf false setzt. Bei entsprechender Konfiguration wird niotix Nachrichten in eine Queue stellen, wenn die Verbindung des abonnierenden Clients unterbrochen wird. Die Menge der in der Queue befindlichen Daten wird durch die Größe des Volumens begrenzt, das dem RabbitMQ zur Verfügung steht (bei SaaS-Nutzung von niotix achten wir darauf, dass dieses Volumen angemessen dimensioniert ist, um Ihre Daten zu verarbeiten).

Konnektor “niota”

Der “niota”-Konnektor stellt eine Verbindung zu einer bestehenden Instanz von niota 1.0/IoT Data Hub her, um Gerätedaten von einem ausgewählten Konto zu empfangen.

  • Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
  • Beschreibung: Gib eine kurze Beschreibung an.
  • apiKey: Gib den API-Schlüssel an, den du in deinem niota 1.0-Tenant definiert hast. Dieser API-Schlüssel wird benötigt, um sich am niota 1.0-System zu authentifizieren und nur Daten vom richtigen Konto zu empfangen.
  • baseURL: Gib die Adresse deiner niota 1.0-Instanz an.

Hinweis: Beachte, dass du mindestens einen Benutzer im entsprechenden niota 1.0-Konto benötigst, um den “niotix”-Connector erfolgreich zu nutzen!

Konnektor “smartservice”

Der “smartservice”-Konnektor baut eine Verbindung zu den Lösungen von Thüga SmartService her. Wenn du Interesse an diesem Konnektor hast, kontaktiere deinen DIGIMONDO-Ansprechpartner.

Gib folgende Informationen ein:

  • Instanz-Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
  • Beschreibung: Gib eine kurze Beschreibung an.
  • API-Key: * Füge den API-Schlüssel hinzu.
  • Value timestamp from: Wähle zwischen “api” oder “generated”.
  • Update Interval: * Wähle aus, in welchem Zeit-Intervall das Update des Konnektors erfolgen soll.

Konnektor “Webhook (Outgoing)”

Der “Webhook (Outgoing)"-Konnektor ermöglicht es, aus niotix mittels Webhook Daten an Drittsysteme zu senden. So kann z.B. eine Regel im Digitalen Zwilling ein individualisiertes JSON an eine Webhook-Adresse versenden. Zum Testen der Verbindung empfehlen wir - sofern keine eigenen Lösungen zur Verfügung stehen - kostenlose und offene Plattformen wie webhook.site.

Gib folgende Informationen ein:

  • Instanz Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
  • Beschreibung: Gib eine kurze Beschreibung an.
  • Header Auth Type: Gib an, wie niotix sich am Webhook-Empfänger authentifiziert (falls - wie bei webhook.site - keine Authentifizierung benötigt wird: “None”).
  • Header Auth Value: Gib den Wert (z.B. Schlüssel) für die Authentifizierung an (wenn der “Header Auth Type=none” ist, wird das Feld leer gelassen).
  • Method: Wähle die HTTP-Methode aus (z.B. für webhook.site ist dies “POST”).
  • WebhookURL: Gib die Adresse des Drittsystem-Webhooks an (inklusive “https://…").

Konnektor “websocket”

Der “websocket”-Konnektor ermöglicht es aus niotix per wss Daten an einen Websocket-Server weiterzugeben. Zum Testen der Verbindungen können - sofern keine eigenen Lösungen zur Verfügung stehen - kostenlose und offene Websocket-Server wie Pie Socket oder Socketbay verwendet werden.

Gib folgende Informationen ein:

  • Instanz Name: Gib dem Konnektor einen individuellen, einfach zu erschließenden Namen.
  • Beschreibung: Gib eine kurze Beschreibung an.
  • Connection timeout (ms): Gib hier an nach wie vielen Millisekunden der Request wegen Timeouts abgebrochen werden soll. Ist das Feld leer sind es 10 Sekunden.
  • Websocket Url: Gib die Adresse des Websocket-Servers an mit dem die Verbindung aufgebaut werden soll (inklusive “wss://…")

Konnektor “Webhook (Incoming)”

Dieser Konnektor erlaubt es Daten per HTTP POST an ein virtuelles Gerät als eingehende Pakete zu senden. Die URL für den HTTP POST Request wird automatisch erzeugt und kann aus dem Feld “API Endpunkt” kopiert werden. Der Body des Requests muss vom Typ application/json sein und sollte die folgende Default Struktur haben:

{
    "id": "4711",
    "timestamp": "2022-08-19T13:11:05.068Z",
    "payload": {
        "key1" : "value1",
        "key2" : "value2"
    }
}

oder

{
    "id": "4711",
    "timestamp": "2022-08-19T13:11:05.068Z",
    "payload": "01AB02DEF0"
}

Die id ist die Externe ID des Virtuellen Geräts. Sollte der JSON Body in einem beliebigen anderen Format vorliegen, kann er im Template Script umgeformt werden, dazu die Vorlage Virtual Device Inbound auswählen und den Anweisungen in den Code-Kommentaren folgen.