I’m just going to go ahead and get in one mention from the title: we’re like Gandalfs of Gateway. You can safely read the rest of this update without fear of hearing any more sci-fi/fantasy nerdery.
If you haven’t seen it already, check out our promo page about Android Wear work we’ve done in collaboration with SAP. This year’s SAPPHIRE NOW conference has several sessions and demo theatre presentations using this technology – see the bottom of this posting for details.
Bringing the different pieces of this application together was a fascinating and challenging process. It required us to tame several newer technologies, and then fit them into the architecture of a working demonstration application. I will let the aforementioned promo tell the story of what the app does, and below I’ll bring out some key pieces of information for the blogosphere’s digestion.
Tamed Technology #1: Beacons
In our app’s scenarios, users find their proximity to various pieces of plant equipment by detecting small beacons attached to the equipment. For the demo, we chose Gimbal Proximity Beacon Series 10 as our hardware. This choice gave us a few key advantages:
-
Small: about the size of a stack of 3 or 4 quarters
-
Decent battery life: several weeks of constant bluetooth low energy broadcasting with a tiny CR2032 battery
-
Signal is Bluetooth 4.0 (Bluetooth Low Energy), so most smartphones released in the past year or two can sense them
-
Great SDK support
-
Only $5 apiece
How do we know how close someone is to a beacon? In our case, the beacon and the smartphone do not exchange GPS coordinates with one another. Instead, the smartphone reads the relative strength of the bluetooth signal and determines if you’re in one of three configurable distance ranges from the device.
(Geeky aside: The signal strength of Bluetooth Low Energy devices is super tiny – along the lines of -30dBm and lower, where 0dBm is one milliwatt. This tiny output is why the beacons can stay on for so long on such a tiny battery)
One final note: though the wearable is the main interface for app users, the device doing the proximity finding and calling of external APIs is the smartphone. Which is as good a segue as I can muster for:
Tamed Technology #2: Android Wear
There are several competing platforms out there for wearable (watch) technology. Android Wear, Apple Watch, Tizen, and Pebble. They all have their strengths, and all have cool devices running them. We could have launched a huge process just to evaluate all the ways any of them would be right for our process.
In the end, though, two factors made it easy: timing and SDK availability. Gimbal provides SDKs for Android and iOS, which narrows our choice; and the timing of SAPPHIRE this year means we wouldn’t be able to have any Apple Watch devices available. Talk to us next year – we may just say something different on this topic.
In the Android Wear design paradigm, the UI model centers around two spaces: “Suggest” and “Demand”. These fit nicely into the two work streams we designed for users of our application.
-
Suggest is a paradigm based on the Wear device bringing information to your attention automatically with cards – in the same vein as Google Now. Our technician users are notified of work orders that have been assigned to them and can pull up the cards to begin the flow of work.
-
Demand is a paradigm based on the Wear user bringing a particular flow to the forefront of their device. Our issue reporter users make use of this flow when they speak or tap to begin their process in the watch.
-
In both cases, once the apps are launched they go into a full screen flow with custom screens and interactions.
Since wearables seem like such powerful little devices on their own it can be hard to keep in mind that the true brains of the whole deal is still full-powered Android device. Without a paired Android mobile phone, you don’t get to do all the fun stuff that a full-blown wearable app can do. In our case this limitation was actually very helpful, as it allowed us to focus on the configuration and diagnostics on the phone side and focus on pure UI goodness on the wearable side.
Tamed Technology #3: API Management (and Gateway)
There isn’t much value in cool watches and beacons unless you can plug them into something and make useful things happen – which is where the SAP technologies come into play. SAP Gateway and API Management handle taking the beacon/wearable data and binding it to SAP PM/CS functionality.
SAP Gateway is plugged into standard BAPIs in the Plant Maintenance and Customer Service modules to create and update business objects. The exposed service is built lean and specific for the scenario, exposing a simple consumption model for the API. No extra fields, no bloat, just what we need. When the user reports a device defect, a Notification and Maintenance Order are created simultaneously and reported back to the wearable. When a technician actually performs a service, she is able to send a Completion Confirmation through to document the finishing of the process.
When the Android device prepares an API request, we channel that through SAP API Management. API Management paves the way by making internally developed SAP Gateway services available in a protected and monitored fashion to the external internet. The API proxy is secured with a secret API key to further reduce unwanted requests.
Tamed Technology #4: HANA Cloud Integration with Social Media
What fun would a demo be without some slightly unnecessary things happening? We set up social media integration with Twitter and SAP Jam using HCI. When a technician finishes a work order, both a tweet and an SAP Jam message are triggered.
This was pretty simple – I wish I could brag more about this. 🙂
Come See Us
We’ll be demonstrating this app in several places at several times in Orlando. Check out our schedule:
