Construire une application IoT avec SnapLogic : Comprendre les pipelines et les tâches

Dans le premier article de cette sérienous avons parlé des défis liés à l'intégration de l'internet des objets dans l'entreprise. Dans les prochains billets, nous allons construire une application IoT simple qui illustre tous les aspects majeurs du travail avec SnapLogic et le matériel. Dans ce billet, nous allons sauter les détails des appareils, mais à un niveau élevé, nous aurons.. :

  • Un capteur situé quelque part (sur site, à partir d'une API, etc.) qui produit des données comprenant une charge utile "couleur" ;
  • Une LED sur site, reliée à notre réseau local, commodément connectée pour ressembler à un point d'extrémité REST ;
  • Deux pipelines, l'un sur site, l'autre sur le site cloud.

Considérations sur le matériel

Certains équipements IoT sont conçus pour être cloud-native, et auront généralement une relation de publication/abonnement avec un serveur cloud (tel que MQTT). Il est très facile de travailler avec ce type de matériel du point de vue de la sécurité, étant donné que les données de sortie de ces appareils sont accessibles de n'importe où.

Les autres appareils communiquent plutôt sur leur réseau local. Si votre réseau local n'est pas accessible par Internet, cela peut créer des problèmes pour communiquer avec l'appareil. Heureusement, le plan de contrôle SnapLogic (représenté, en quelque sorte, par le rectangle le plus à droite ci-dessous) vient à notre rescousse.

Diagramme du plan de contrôle et de données
Une "représentation graphique" du plan de contrôle (à droite) communiquant avec divers plans de données, y compris un Hadooplex en bas. Nous constatons que l'artiste est quelque peu sur la défensive en ce qui concerne sa représentation du pachyderme.

La plate-forme d'intégration élastique SnapLogic Elastic Integration Platform est divisée en deux parties : le plan de contrôle et le plan de données. Nous maintenons le plan de contrôle, qui fonctionne comme un service multi-tenant cloud . Le plan de données contient les moteurs d'exécution réels. Ceux-ci peuvent se trouver sur cloud ou on prem, dans n'importe quel mélange. Accrochez-vous à cette idée, nous y reviendrons.

L'architecture SnapLogic

Une architecture possible, et celle que nous utiliserons dans cette série, est d'avoir un pipeline de flux de données dans le site cloud qui est toujours à l'écoute des événements provenant de notre appareil. Nous pourrions en faire un point d'arrivée de l'API REST, mais nous allons utiliser MQTT. utiliser MQTT pour ces exemples. (Puisque MQTT doit constamment "écouter", il doit être dans un pipeline toujours en cours d'exécution, ce que nous obtenons en mettant en place une tâche Ultra. Vous pouvez voir ce blog série pour plus d'informations à ce sujet).

Nous construisons donc le pipeline suivant. Le Snap Record Replay est optionnel, mais sert d'aide au dépannage. Sinon, nous avons un pipeline très simple - nous avons reçu des données d'un courtier MQTT, nous les avons analysées au format JSON (en fait un tableau de JSON), et nous avons placé ce tableau dans un Snap ForEach.

Ultra Pipeline dans le Cloud

Dans ce cas particulier, notre JSON entrant ressemble à ceci :

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

Dans notre application, nous voulons passer les données de couleur reçues à la lumière qui existe à l'intérieur de notre pare-feu, et faire en sorte qu'elle s'illumine de cette couleur. Pour l'instant, l'application est triviale, mais obtenir ces données de couleur à l'intérieur de votre pare-feu ne l'est généralement pas.

C'est là que le plan de contrôle SnapLogic (notre Integration Cloud, où vous concevez, gérez et surveillez les pipelines) et le Snap ForEach entrent en jeu. Chaque fois qu'un nouveau document (lecture de capteur) arrive, le Snap ForEach exécute un autre pipeline. Ce deuxième pipeline ne pas n'a pas besoin d'être dans le même Snaplex que le pipeline d'origine. Le plan de contrôle peut l'acheminer vers n'importe quel pipeline de votre compte, même ceux qui se trouvent à l'intérieur de votre pare-feu. Nous configurons donc notre ForEach de la manière suivante :

ForEach Dialog

Le ForEach exécute un nouveau pipeline, "Shayne Hodge - Machina 2", pour chaque lecture de capteur qu'il reçoit du broker MQTT. Il passe en paramètre à ce pipeline la charge utile de couleur($.color ) que nous voulions. Ce second pipeline se trouve dans un Groundplex qui fonctionne derrière notre pare-feu et qui peut communiquer avec notre LED :

Pipeline Groundplex

Nous vous donnons rendez-vous dans le prochain article de cette série pour plus de détails sur une filière locale déclenchée. En attendant, n'hésitez pas à nous contacter pour demander une démonstration.

Nous recrutons !

Découvrez votre prochaine grande opportunité de carrière.