Nel primo post di questa serieabbiamo parlato delle sfide dell'integrazione dell'Internet degli oggetti nell'azienda. Nei prossimi post costruiremo una semplice applicazione IoT. semplice applicazione IoT che illustra tutti gli aspetti principali del lavoro con SnapLogic e l'hardware. In questo post, salteremo i dettagli del dispositivo, ma ad alto livello avremo:
- Un sensore da qualche parte (in sede, da un'API, ecc.) che produce dati che includono un payload "colore";
- Un LED in sede, collegato alla nostra rete locale, opportunamente collegato per sembrare un endpoint REST;
- Due pipeline, una on-premise e una nel sito cloud.
Considerazioni sull'hardware
Alcuni hardware IoT sono progettati per essere cloud-nativi e generalmente hanno una relazione publish/subscribe con un server cloud (come MQTT). È molto facile lavorare con questi dispositivi dal punto di vista della sicurezza, poiché i loro output sono accessibili da qualsiasi luogo.
Altri dispositivi comunicano invece sulla loro rete locale. Se la rete locale non è accessibile a Internet, questo può creare problemi di comunicazione con il dispositivo. In questo caso, il piano di controllo SnapLogic (rappresentato, per così dire, come il rettangolo in alto a destra) ci viene in soccorso.
La SnapLogic Elastic Integration Platform è divisa in due parti: il piano di controllo e il piano dati. Noi gestiamo il piano di controllo, che viene eseguito come servizio multi-tenant cloud . Il piano dati contiene i motori di esecuzione veri e propri. Questi possono trovarsi in cloud o on prem, in qualsiasi combinazione. Tenete a mente questo pensiero e ci torneremo sopra.
L'architettura SnapLogic
Una possibile architettura, quella che utilizzeremo in questa serie, consiste nell'avere una pipeline di flussi di dati in cloud , che ascolta sempre gli eventi provenienti dal dispositivo. Potremmo creare un endpoint API REST, ma useremo MQTT. utilizzare MQTT per questi esempi. (Poiché MQTT ha bisogno di essere costantemente 'in ascolto', deve essere in una pipeline sempre in esecuzione, che si ottiene impostando un task Ultra. È possibile vedere questo blog serie per ulteriori informazioni al riguardo).
Quindi costruiamo la seguente pipeline. Lo snap Record Replay è opzionale, ma serve come aiuto per la risoluzione dei problemi. Per il resto, abbiamo una pipeline molto semplice: abbiamo ricevuto dati da un broker MQTT, li abbiamo analizzati in formato JSON (in realtà un array di JSON) e li abbiamo inseriti in uno snap ForEach.
In questo caso particolare, il nostro JSON in entrata ha l'aspetto seguente:
[{"deviceId":"machina_pi_0","x":"-0.034","y":"0.015","z":"-1.002","color":"#03024c"}]
Nella nostra applicazione, vogliamo passare i dati del colore ricevuto alla luce che esiste all'interno del nostro firewall e farla illuminare di quel colore. In questo momento l'applicazione è banale, ma in genere non lo è ottenere i dati del colore all'interno del firewall.
È qui che entrano in gioco il piano di controllo di SnapLogic (il nostro sito di integrazione Cloud, dove si progettano, gestiscono e monitorano le pipeline) e lo Snap ForEach. Ogni volta che arriva un nuovo documento (lettura del sensore), lo snap ForEach esegue un'altra pipeline. Questa seconda pipeline non non deve non deve necessariamente trovarsi nello stesso Snaplex della pipeline di origine. Il piano di controllo può indirizzarla a qualsiasi pipeline dell'account, anche a quelle all'interno del firewall. Quindi configuriamo il nostro ForEach in questo modo:
Il ForEach esegue una nuova pipeline, "Shayne Hodge - Machina 2", per ogni lettura del sensore che riceve dal broker MQTT. Passa come parametro a questa pipeline il payload del colore($.color ) che volevamo. Questa seconda pipeline si trova in un Groundplex in esecuzione dietro il nostro firewall che può parlare con il nostro LED:
Nel prossimo post di questa serie troverete i dettagli di una condotta innescata a livello locale. Nel frattempo, sentitevi sempre liberi di contattarci per richiedere una demo.
