API Management with Android Wear for SAPPHIRE

[former_member187859]

In preparation for SAPPHIRENOW 2015, I was pleased to co-innovate with the SAP Labs team to solve a real-life problem using Android Wear, Bluetooth beacons, and API Management. My company’s team of developers took to the challenge: to create a demonstration wearable application that was simple and useful. Using familiar wearable gestures, we set up a workflow that gets common tasks done right from your wrist.

In our scenario, a plant worker comes across a malfunctioning device. With a simple Wear app and a few swipes, she's able to enter a work order and notify the right people of the problem without interrupting her work. Once that work order hits the system, it notifies the appropriate technician, guides him to the broken equipment, and keeps track of the details during the repair. A few taps later, the fix is completed and he's on his way to the next task, without stopping to close the work order manually. If you want, you can see a more detailed look at all the screens and interactions here.

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.

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. :smile:

Come See Us

We’ll be demonstrating this app in several places at several times in Orlando. Check out our schedule:

• Demo theatre sessions:
  • PT20267 Go Digital with Application Programming Interfaces
    • Wednesday 5/6 at 11:30AM, PT401
    • Thursday 5/7 at 9:00AM PT417
  • LB20588 Explore innovations in Asset Management
    • Wednesday 5/6 at 3:30PM LB201
    • Thursday 5/7 at 2:00PM LB201
• Demo stations:
  • EAM demo station LB206 at the SAP Line of Business campus
  • Apigee pod 1623B in the partner area
• See a video at the Technology Campus HANA Cloud demo station PT421