In the initial post in this series, we talked about how IoT data, once acquired, is still just data. Before diving into building our first demo, it’s worth taking a moment to talk about getting the data to the stage of “once acquired”.
If you’re an existing SnapLogic customer – and if, not, why not request a trial? – you’re used to working in an environment where our Snaps work hard to ensure you aren’t confronted by irrational application behavior, and things Just Work. This happens because our talented developers get to spend hundreds or thousands of person-hours on creating integrations for a wide variety applications, APIs and enterprise data sources.
For IoT devices, though, we provide thoroughly-tested Snaps to enable communication with the device, but we can’t guarantee the device itself won’t do silly things. One such silly thing occurred during the creation of the demo this blog series is going to show you how to build. An addressable color-changing USB LED was used that can theoretically display any of over 16 million colors. The included demo software lets you pick any of those colors and see the light change. However, when we integrated it with SnapLogic, we got odd errors back when asking it to change color.
It turned out that the particular library provided for the LED we were using would only accept hex color-codes that had a generally accepted English name, even though the LED was capable of displaying them regardless of whether the hex code had a name. We consider this behavior a bug, and implemented a work-around, but the lesson remains – new IoT devices can be buggy. Sometimes it’s the hardware, sometimes it’s their software drivers. Batteries die, users drop things in water, security is so secure you can’t connect, and dogs discover the unadvertised chew-toy features of devices.
Thus, you need to develop defensively, and expect that you’ll occasionally have garbage data. (In fact, this why we think using the SnapLogic Elastic Integration Platform to apply machine learning algorithms on your data is so useful, since it can help clean your IoT data streams). Develop in an agile manner toward a Minimum Viable Product (MVP). Get one simple example working all the way through before you try to implement the whole project. If you eventually want to connect 1,000 different devices to 30 different endpoints, first get one device talking to one endpoint. Try to (non-destructively) ‘break’ the device. In doing so you’ll probably find any major device bugs or security considerations to be aware of. Then add all the other endpoints. Then add support for multiple input devices.
This may seem slower and prone to causing yourself to repeat some steps. Recall our goal – to integrate IoT data in with the rest of our enterprise data. Even with SnapLogic, the very first step can be a bit hard. But by taking that step slowly and carefully, the remainder of the integration becomes very simple. Meanwhile, your competition, if they get past the first hard step without a modern integration platform as a service (iPaaS) like SnapLogic, now are confronted with the even harder problem of doing something useful with that data. With that in mind, the next post in the series will start building out our IoT proof-of-concept so that you can be collecting insights while your competitors are fiddling with database configurations and firewall ACLs. (And if you haven’t yet, check out our video demo on building an IoT pipeline and request a personal demo.)
