Wearable Wizardry

I’m just going to go ahead and get in one mention from the title: we’re like Gandalfs of Gateway. You can ...

Contact us

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:
 
  • 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
Paul J. Modderman

Paul J. Modderman

Paul Modderman loves creating things and sharing them. He has spoken at SAP TechEd, multiple ASUG regional events, ASUG Fall Focus, Google DevFest MN, Google ISV Days, and several webinars and SAP community gatherings. Paul's writing has been featured in SAP Professional Journal, on the SAPinsider blog, and the popular Mindset blog. He believes clear communication is just as important as code, but also has serious developer chops. His tech career has spanned web applications with technologies like .NET, Java, Python, and React to SAP soutions in ABAP, OData and SAPUI5. His work integrating Google, Fiori, and Android was featured at SAP SAPPHIRE. Paul was principal technical architect on Mindset's certified solutions CloudSimple and Analytics for BW. He's an SAP Developer Hero, honored in 2017. Paul is the author of two books: Mindset Perspectives: SAP Development Tips, Tricks, and Projects, and SAPUI5 and SAP Fiori: The Psychology of UX Design. His passion for innovative application architecture and tech evangelism shines through in everything he does.

Let’s make your SAP better, together.

  • This field is for validation purposes and should be left unchanged.