Skip to Content

At the end of March I was approached by my good friend and colleague John Appleby with a challenge:


Let’s build an IOT real time healthcare demo for SAPPHIRE


So we did, and in this blog I’m going to talk through the demo that John, myself and of course the Fiori guru DJ Adams built in just over 3 weeks in our spare time in the run up to this years SAPPHIRE NOW. You may have seen John’s post during SAPPHIRE talking briefly about what we were doing and what we built but this is a bit more of an in-depth look at exactly what we did.


The scenario was simple; for specific attendees of SAPPHIRE, a three day marathon SAP conference event in Orlando, we would equip them with heath sensing biometric sensors and feed that data, in real time, into the SAP HANA database present on the show floor. Finally we would display that data for the world to see in an SAP Fiori (like) user interface which we called Bluefit.


The Components

The demo could be broken down into three areas:


  • The Wearable
    • Our “patients” would wear a Moto360 smartwatch running Android wear and Google Fit. This would allow us to track their step counts, their heart rate and of course their distance travelled.


  • Getting the Data to HANA
    • To get the data from the watch into HANA we had to have a middle man which in our case was a Moto X (2014) smart phone running Android Lollipop. This could act as the middleman retrieving our watch data and then pushing this into SAP HANA.


  • Visualising the data
    • For the data visualisation we utilised raw HANA analytics built at the HANA database level and exposed that data via the XS engine and OData services into a fully fledged Fiori application.


All of this means that as our patients made their way around the showfloor, their watches would track their biometric data, their phones would push that data into our SAP HANA database and finally we could watch this all in real-time via our SAP Fiori front end app.


Technical Deep Dive

Going into a bit more detail – how did we actually build the demo:


Bluefit on the watchBluefit_Watch.jpg

There are many different ways you can approach the building of a fitness/health tracking app on Android-based wearable devices. The first approach we took was to attempt to tap into the raw sensor data from within the watch itself using the provided Android Wear APIs. We had some success in this area and managed to successfully pull the required data. However logging, storing and transmitting that data manually from the watch, while completely possible, was a bit more complicated than this demo required.


During the development it became obvious that there had to be a better way to retrieve our data, and there was. Enter the Google Fit SDK. A component of google play services, it provided us with historical and time aggregated sensor data. For instance the API supported a request for todays step count since midnight to right now without having to manually store sensor data. Perfect for what we required.


Communications between the watch and the phone were achieved using the Google messaging API provided specifically for communicating with Android Wear devices.


Bluefit on the PhoneBluefit_Phone.jpg

The Bluefit app on the phone acted as the middleman between our fitness data and SAP HANA. The app was the brain behind the operation ensuring that the fitness data on the watch was kept up to date as well as ensuring that data was being pushed to SAP HANA at regular intervals.


Utilising the Google Fit SDK, the app would keep a log of fitness data throughout the day and then, once every minute or so, post that data to SAP HANA using a standard authenticated HTTP POST.


Little side note: those of you who have every been to a teched/d-Code or SAPPHIRE NOW event will, I’m sure, appreciate the flaky nature of both the WiFi and cell service at these events. As a result of that, the app had to be designed and built to be error resistant. It would hold a record of an entire days worth of data until it could successfully post that data to HANA if it needed to. This meant that no historical data would be lost because of the 25,000 people attempting to use the same wifi during the keynote.


Each post from the phone included the phones serial number to allow us to know which device was sending the data.


Bluefit’s Database and UI

To add a sense of reality to the whole thing, we utilised a 3 node SAP HANA cluster from our good friends at Lenovo which was literally sitting on the show floor to host our demo. Those of you who may have seen our tweets giving the link to our step count leaderboard were literally logging onto a server sitting in the middle of the SAPPHIRE NOW show floor in orlando!


To store, analyse and expose the health data we utilised SAP HANA’s development platform, specifically the XS engine. The database was comprised of a subset of tables from a WHO regulated model we worked on a while back giving us patient data, activity data and, of course, bridges to link our devices posting the data to our patients.


On top of this we built a number of attribute views (joining patient data with device data for example) as well as analytical views to provide an aggregated view of our patient data.


Finally the data was exposed for public consumption through a single OData service on top of which we built a Fiori-like responsive application. This gave two views of the data:


  • Patient Data
    • This view provided us with an individual view of our patient’s data. This included their personal details (gender, height, weight and age) as well as their live biometric data (heart rate, step count and distance).

04_Bluefit_Patient_Data_Screenshot.png

  • “Stepdown” – the leaderboard
    • Known as “Stepdown” for the conference, this gave us a leaderboard view of our main patients, allowing conference attendees to see how each of our patients were doing compared with each other.

03_Bluefit_Stepdown_Screenshot.png

Conclusion

So there you have it. In a little over three weeks from conception to demo we built, mostly in spare time, a fairly simple IOT demo using consumer products, SAP HANA and an analytics based front-end on SAPUI5. The skill set for this demo was not huge either:

  • Watch App
    • Java and Android
    • Knowledge of Android wear APIs
  • Phone App
    • Java and Android
    • Basic networking knowledge and HTTP
  • HANA & UI
    • Native HANA development
    • SAPUI5 Frontend & OData


One of the reasons I find this demo so interesting is because it is becoming increasingly obvious that the topic of IOT is not going away and is going to play a major part in everything that we do going forward. From consumer tech tracking data like this as standard to use cases in the enterprise such as smart grids, health care monitoring and so much more. With the flexibility and raw power of SAP HANA it was a perfect fit for this demo to achieve what we needed and without a huge amount of effort.


If you have any questions about how this demo was built or would like more info – please do comment below and I’ll be glad to answer.

To report this post you need to login first.

16 Comments

You must be Logged on to comment or reply to a post.

  1. Denise Nepraunig

    Hello Brenton, thanks a lot for your blog post! The whole thing is such a brilliant idea and gives great insight about the whole E2E process and how well all those different parts fit together.

    I sneaked into the source code while the SAPUI5 app was up and running to get an idea the data structure of the back-end, the refreshing of the data and how the app was built (a master piece by DJ). It was great to see that a low amount of source code was needed to make this app work – the only sad thing is that the app is now down and this beautiful example (source) is gone… 😉

    I am really looking forward what you guys will show us next year!

    Keep up your great work!

    BR, Denise

    (0) 
    1. Brenton OCallaghan Post author

      Thanks for your comments Denise 🙂 and I completely agree the UI code written by DJ Adams was indeed excellent (as always!) 😉

      I’ll have a chat with the guys next week and we’ll try to get a version of the UI up and running somewhere in case anybody is interested – it would be a shame if it didn’t live on somewhere!

      We are already working on our next ideas for both Teched/d-Code as well as SAPPHIRE so fingers crossed we can live up to this one!

      Thanks again for your feedback!

      (0) 
    2. DJ Adams

      *blush* thanks Denise, it’s only regular code 🙂

      I have the sources of course, we can publish if there’s enough interest!    

      (0) 
      1. Denise Nepraunig

        😀

        while (true) {

           enoughInterest++;

        }

        One final question came to my mind: you have an XS backend and the SAPUI5/Fiori like app is your front-end: how did you overcome the cross-origin stuff? Was the SAPUI5 app hosted as HTML5 HCP app with destination service and you put there user/pw or did you enable the CORS functionality in your HANA XS backend?

        BR

        Denise

        (0) 
        1. Brenton OCallaghan Post author

          Hey Denise,

          Great question – we looked at hosting this a few ways including putting the UI on HCP as you described but in the end we went with everything hosted on the HANA server itself on the show floor. This meant that everything was very straight forward and there were no cross origin challenges.

          In the future if I were doing this again I would likely go down the HCP app route 🙂

          Thanks,

          Brenton.

          (0) 
      2. Thomas Nielsen

        Thanks for a very interesting post!

        It could be very interesting in another post, where you perhaps went a little bit more in detail on how the code actually work.
        I am particular interested in how you made the HTTP post to HANA, since I was under the impression that HANA is not the most suitable technology when it comes to store one record (post) at a time.

        So a little insight on how you made the XSJS engine would be appreciated.

        (0) 
    1. Brenton OCallaghan Post author

      Hey Deepak,

      Thanks for the comment!

      The data was sent over the web to the SAP HANA XS engine where a custom XSJS script parsed the incoming data and then handled the database inserts. The web call was a POST which contained a body of JSON which housed the data.

      We could really have done that one of two ways – either via XSJS or via OData and either would have worked very well but in our case it was XSJS.

      Brenton.

      (0) 
  2. Gary King

    A very good article. I am impressed with it taking just the three weeks.

    I do have a question to ask though. I can see the use of the watch, android device and SAP UI5/Fiori, but I did not think that was a particularly good use of HANA, based on what I know HANA is capable of. Apart from sharing data across the cloud HANA has so much more it can achieve. But, don’t take this to heart as I’m a novice to HANA, and I know you were hard pushed to create a demonstratable tool that utilised Fiori/HANA, and in a short amount of time.

    Regardless of my last comment, keep up the good work though. There are a few typos in the article, but I’m sure you’ll correct those now I’ve mentioned them. What I am surprise about though is that nobody else has mentioned them.  😉 Maybe it’s just me.

    (0) 

Leave a Reply