Aufbau einer IoT-Anwendung in SnapLogic: Aufbau von Pipelines und Tasks

In der ersten Beitrag in dieser Seriehaben wir über die Herausforderungen bei der Integration des Internets der Dinge in das Unternehmen gesprochen. In den nächsten Blogbeiträgen werden wir eine einfache IoT-Anwendung die alle wichtigen Aspekte der Arbeit mit SnapLogic und Hardware veranschaulicht. In diesem Beitrag werden wir die Gerätedetails auslassen, aber wir werden auf einer hohen Ebene arbeiten:

  • Ein Sensor, der irgendwo (vor Ort, über eine API usw.) Daten erzeugt, die eine "Farb"-Nutzlast enthalten;
  • Eine LED vor Ort, die an unser lokales Netzwerk angeschlossen ist und bequem wie ein REST-Endpunkt aussieht;
  • Zwei Pipelines, eine vor Ort, eine in der Cloud.

Hardware-Überlegungen

Einige IoT-Hardware ist für den Einsatz in der Cloud konzipiert und verfügt in der Regel über eine Publish/Subscribe-Beziehung zu einem Cloud-Server (z. B. MQTT). Dies ist vom Standpunkt der Sicherheit aus sehr einfach zu handhaben, da die Ausgabe dieser Geräte von überall her zugänglich ist.

Andere Geräte kommunizieren stattdessen über ihr lokales Netzwerk. Angenommen, Ihr lokales Netzwerk hat keinen Internetzugang, kann dies zu Problemen bei der Kommunikation mit dem Gerät führen. Hier kommt uns die SnapLogic Control Plane (sozusagen das Rechteck ganz rechts unten) zu Hilfe.

Diagramm der Steuerungs-Daten-Ebene
Eine "grafische Darstellung" der Steuerebene (rechts), die mit verschiedenen Datenebenen kommuniziert, darunter ein Hadooplex am unteren Rand. Wir sehen, dass der Künstler seine Darstellung des Dickhäuters etwas verteidigt.

Die SnapLogic Elastic Integrationsplattform ist in zwei Teile unterteilt - die Steuerungsebene und die Datenebene. Die Steuerungsebene wird von uns verwaltet und als mandantenfähiger Cloud-Service ausgeführt. Die Datenebene enthält die eigentlichen Ausführungsengines. Diese können sich in der Cloud oder vor Ort befinden, in jeder beliebigen Kombination. Bleiben Sie bei diesem Gedanken und wir kommen darauf zurück.

Die SnapLogic-Architektur

Eine mögliche Architektur, die wir in dieser Serie verwenden werden, ist eine Datenfluss-Pipeline in der Cloud, die immer auf Ereignisse von unserem Gerät wartet. Wir könnten dies zu einem REST-API-Endpunkt machen, aber wir werden MQTT verwenden für diese Beispiele verwenden. (Da MQTT ständig "zuhören" muss, muss es sich in einer ständig laufenden Pipeline befinden, die wir durch Einrichten einer Ultra-Aufgabe erhalten. Sie können sehen diesen Blog Reihe finden Sie weitere Informationen zu diesem Thema).

Wir bauen also die folgende Pipeline auf. Der Record Replay Snap ist optional, dient aber als hilfreiche Unterstützung bei der Fehlersuche. Ansonsten handelt es sich um eine sehr einfache Pipeline: Wir haben Daten von einem MQTT-Broker erhalten, sie in das JSON-Format geparst (eigentlich ein Array von JSONs) und dieses Array in einen ForEach-Snap gestellt.

Ultra-Pipeline in der Cloud

In diesem speziellen Fall sieht unser eingehendes JSON wie folgt aus:

[{"deviceId":"machina_pi_0","x":"-0.034","y":"0.015","z":"-1.002","color":"#03024c"}]

In unserer Anwendung wollen wir die empfangenen Farbdaten an das Licht innerhalb unserer Firewall weitergeben, damit es in dieser Farbe leuchtet. Im Moment ist die Anwendung trivial, aber die Farbdaten innerhalb der Firewall zu erhalten, ist im Allgemeinen nicht einfach.

An dieser Stelle kommen die SnapLogic-Kontrollebene (unsere Integration Cloud, in der Sie Pipelines entwerfen, verwalten und überwachen) und der ForEach-Snap ins Spiel. Jedes Mal, wenn ein neues Dokument (Sensorwert) eingeht, führt der ForEach-Snap eine weitere Pipeline aus. Diese zweite Pipeline nicht muss sich nicht im selben Snaplex befinden wie die Ursprungspipeline. Die Steuerebene kann sie an jede beliebige Pipeline in Ihrem Konto weiterleiten, sogar an solche innerhalb Ihrer Firewall. Wir konfigurieren unser ForEach also folgendermaßen:

ForEach Dialog

ForEach führt eine neue Pipeline, "Shayne Hodge - Machina 2", für jeden Sensorwert aus, den es vom MQTT-Broker erhält. Sie übergibt dieser Pipeline als Parameter die gewünschte Farbnutzlast($.color ). Und diese zweite Pipeline befindet sich in einem Groundplex der hinter unserer Firewall läuft und mit unserer LED kommunizieren kann:

Grundplex-Rohrleitung

Im nächsten Beitrag dieser Serie erfahren Sie Einzelheiten über eine lokal ausgelöste Pipeline. In der Zwischenzeit können Sie sich jederzeit mit uns in Verbindung setzen, um eine Demo anzufordern.

Wir stellen ein!

Entdecken Sie Ihre nächste große Karrierechance.