We have a slight problem at SnapLogic. While we spend a vanishingly small percent of the day watching adorable cat videos on the Internet, it seems our CEO always shows up behind our desks while doing so. If only we knew when our CEO was nearby and could get an alert when he was.
What we need, then, is an IoT solution capable of tracking our CEO’s movements and relaying them back to the office. There was recently a webinar on this topic, and we’ve discussed in past posts the general steps to create a pipeline using a WiFi IoT device (the Particle.io Photon). The fine folks at Particle have also created a cellular-connected device called the Electron and a GPS expansion board. The same principles behind using the Photon apply to the Electron – in fact, once the cellular SIM card is installed, there’s no real development difference. This post will focus on the SnapLogic side of things; for more information on the microcontroller see the webinar or the code repository.
Our device, seen above doing some static testing in a window, periodically publishes two strings to the Particle cloud. One string contains the current latitude and longitude of the tracker, the other contains the battery charge level. The Particle cloud then triggers a webhook, where it POSTs the data it received to a websever. We want to do two things: (1) store this data in a database for future analysis and (2) flash a light if our CEO is too close.
Our database, though, is behind a firewall, and is not publicly accessible. This is not a problem using SnapLogic. We take the following pipeline, and make it a triggered task, so it can be called from the internet given the proper credentials. We make sure the Particle webhook has those credentials, and so when an event occurs, this pipeline is triggered:
Several things are going on here:
- The Record Replay Snap (upper left) lets us record the data that comes and then, well, replay it, so we can test without waiting on the device.
- The Response Code Snap (middle left) returns a “200 Started OK” to webhook immediately, so it doesn’t time out waiting on the subsequent logic to finish.
- The mapper (top left) formats the incoming data, passes it to the router which sends the data down different branches depending on whether it was information about the location or battery charge, and ultimately inserts it into a database. This database is behind our firewall; the Snaplex the pipeline is executing on has permission to write to it, even though it is not directly exposed to anything on the internet. This is a very convenient way to maintain security and accessibility.
- The Copy Snap in the middle right takes the location data and sends a copy to Postgres and also to the Light logic (see the circled 28, wrapping around to the pipeline stub on the left). This light logic is borrowed from the LEAVE blog post we mentioned earlier.
- This four-Snap run does three things – it checks whether our CEO is within a mile of the office and computes the hash value the light requires; it lets the document pass through (the filter) if the reported location is less than a mile away; and then it makes the payload and POSTs it to the light, which is running a Particle Photon. The lights flash, and everyone scrambles to Look Busy.
And that’s all there is to having battery-powered cellular device securely connect to databases and devices within your company’s firewall. This is made possible by the recent batch of IoT hardware tools that resemble web services and by SnapLogic’s split control plane – data plane architecture, which allows you to bridge services in different security zones in a safe, controlled manner.
It may also keep you out of trouble with your CEO.
