Skip to Content
Author's profile photo Thorsten Franz

River goes mobile: The SAP Mentors Outreach Mobile App as a prototype for a new type of Edge Innovation

A few days ago, during the SAPphireNOW ASUG 2011 conference in Orlando, Florida, I released the Proudly Presenting the SAP Mentors Outreach Mobile App for Android – Connect with SAP Mentors at SAPphireNOW/ASUG Orlando (download at It is a social mobile app for Android that allows you to browse and search the profiles of SAP Mentors, comment and share them, and get in touch with the Mentors via twitter. (I described its functions in detail in this blog.) Currently, there are a little more than 100 installations. A team is working on a port for iPhones and iPads; meanwhile, non-Android users can use the web-based version optimized for mobile devices.

Fig. 1: Architecture

1. The back-end: River

The back-end of the SAP Mentors Outreach app is an application in SAP River. River is a Platform as a Services (PaaS) offering by SAP that is not yet generally available but in a beta stadium. To learn more about River, please read the following blogs and Wiki pages:

The Mentor program uses River internally: We have created apps to maintain master data for Mentors, build up an expertise database, and link it with conference attendance data entered through Google Forms. The primary app, called SAP Mentors Expertise System, is the back-end data source for the mobile app.

What predestines River as a data source for mobile apps?

  • It allows you to very rapidly create database applications – I would say it’s about as fast or even faster than building an ad-hoc database in MS Access.
  • The database application is available directly on the internet without any IP tunnelling, firewall hassle, etc.
  • It scales: Multiply the number of users and/or the amount of stored data massively, and your app will keep running smoothly (at least that is the promise).
  • The underlying database is NewDB, the highly-scalable, database system optimized for massive parallel processing that powers HANA.
  • It has an (albeit simple) authorizations system that allows you to assign users to groups with different levels of access.
  • It can act as a proxy for remote data consumed via Atom-based REST services – for example, data stored in an SAP system and exposed in the Atom format via SAP NetWeaver Gateway.
  • It offers small but growing integration capabilities with SAP’s identity management (or user database, to put it plainly).
  • It automatically and effortlessly exposes the app’s data, functions, and business logic through REST web services.

Architectural pattern: River as an enriching proxy

I’d like to dwell on the “proxy for remote data” point for a second because this is where I see an architectural pattern and some of the biggest value of River for mobile apps.

River allows you to access the Atom services in your ABAP system but optimize those structures for remote consumption without leaving a footprint in the ABAP system. Also, you can add new tables to the application that work together with back-end data but reside entirely in River, again minimizing the impact on the ABAP back-end.
Your typical back-end system: Innovation at a snail’s pace

Minimizing the impact of new functions on the ABAP back-end is crucial because in most real-world ABAP systems, even though you as a gifted developer may be able to create a few new  functions in a day, the entire system follows a long-paced rhythm that will cause your development to stay out of production for weeks or months to come. At many sites, production systems are updated with what amounts to a new release two to four times per year. Among the reasons for this slow update frequency are:

  • Governance processes – heavy-weight requirements analysis, prioritization, and planning processes slow down the innovation process, sometimes resulting in stretches of one year or more from change request to go-live of a tiny function
  • Deployment dependencies – massive cross-dependencies between the functions in an SAP system frequently demand that all the functions of the new release must be deployed at the same time, so one of them cannot sprint ahead but must keep the pace of the slowest component (actually, the dependencies may not really be as bad – but people find it hard to analyse them and therefore play it safe, assuming maximal interdependencies)
  • Extensive testing – This is another result from the many interdependencies between ABAP applications. After making a change in one area, it’s wise to test extensively for impacts in other, seemingly unrelated areas.

Breaking out of the slow, established rhythm with Edge Innovation

Implementing new, isolated functions outside this treadmill allows you break out of the slow established rhythm and frequently out of bloated, overly bureaucratic processes. If your new function is implemented not as a change to your ABAP system but as a new client, you may get away with going live immediately without having to wait for a new production release.

This is places River in the realm of “Edge Innovation” (also: “Fringe Innovation”), where rapid innovation is possible because it takes place far away from the stable, slowly moving application cores of your traditional back-end systems.

2. How the app retrieves and handles data

When the app loads Mentor data, it uses River’s automatically provided REST interface to retrieve the data (in a very strange XML format and without images) via HTTP. It parses the XML, creates Mentor objects in a collection, and displays the list (still without images).

To load the thumbnail images, the app takes the RiverId (the database key for a Mentor in the River database) and calculates the URL of the thumbnail stored in River from it, and retrieves it.

A few words about the data management and threading:

1. The “naked” (without data) app starts an asynchronous (parallel) thread that retrieves the XML file and builds the collection of Mentors from it.

2. When this is complete, a second asynchronous (parallel) thread is started. It goes through all the mentors, retrieves a thumbnail for each and immediately makes it visible in the list. This way you can watch the thumbnails appear one by one.

3. As soon as the last thumbnail is loaded, the entire collection including images is serialized and written to a cache file on the device.

4. Each time you start the application it checks whether a cache file exists; if it does, the app builds the collection of Mentors with pictures from the cache file.

5. As a developer, once before each release, I create a build that writes the cache file to a location where I can extract it from the device and bundle it with the application that I put on the Android Market. This way the app can run immediately after installation with a current data set without having to first pull it from the net at a conference with bad wifi.

3. Mobile-specific considerations

When developing for Android mobile devices, you program in Java, but even if you already know the language, you will have to learn some specifics about the behaviour of your app’s environment to make it robust enough.


Android makes sure that the user doesn’t have to bear with unresponsive apps. So whenever an action in your app keeps the user interface unresponsive for more than 5 seconds, Android will assume the app got stuck and kill it (or offer to do it). The way to deal with this is to perform long-running tasks asynchronously in parallel threads.

Object instance life-cycle

Android has to handle system resources economically. Therefore, it frequently kills objects that are not currently needed. More specifically, it takes the liberty to kill the objects representing app screens that are currently not visible because the user is doing something else. In order to preserve app state across such killings and resurrections, you have to learn to use the system’s hooks for state serialization and deserialization. Also, data “coming home” from asynchronous tasks not be directed to long-dead UI objects.

(I have no experiences with programming for iOS and BlackBerry but I assume there will be similar idiosyncrasies.)

4. Summary

River can serve as a stand-alone back-end for mobile applications, but it can also provide access to SAP data while maintaining the light-weight, minimal footprint character of an edge innovation application.

Also, it can act as very basic middleware component without requiring a big footprint in your system landscape, thereby allowing you to get started with mobile enterprise applications without immediately requiring Sybase SUP or similar tools.

Assigned tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Tammy Powlas
      Tammy Powlas
      Great blog and I can't wait to hear you talk about it more in person at TechED in Las Vegas.

      I downloaded it the app to my Android last Sunday at the ASUG pre-conference without any issues.

      Thank you for doing this.

      Author's profile photo Fred Verheul
      Fred Verheul
      Hi Thorsten

      Thank you for sharing your insight with the rest of the community once again. I'll shamelessly re-use your content whenever I can (which will be pretty soon) ;-). I also downloaded and installed your app without any problems! Amazing it's only your first Android app.
      One question: should we see the mobile app as just another frontend to an (already existing) River app, or would you say the mobile app is the real application, using data from River as yet another source of data (so that when the data would move only the url of the REST calls would have to change)?


      Author's profile photo John Patterson
      John Patterson
      Hi Thorsten,
      Thanks for the insight into the android app, following your exploits on twitter I was amazed how quickly you have gone from Phone owner to accomplished developer, inspiring.

      How are you persisting the comments? Is this done on the cache file also? Was there a particular driver for not using SQLite? 


      Author's profile photo Thorsten Franz
      Thorsten Franz
      Blog Post Author
      Hi John,
      Thank you for your feedback and encouragement. 🙂
      To answer your questions:
      1. Storing the comments in the same cache file (which is just the Mentors collection with all its contained objects including images serialized) would have meant that with each data refresh, the comments would be discarded, too. So I store them in a separate collection and serialize/deserialize them into a separate file. The comments collection is a HashMap consisting of Mentor ID and comment string, so I can easily retrieve the comment string by Mentor ID and the comments survive the refresh (and new object identities) of the Mentors data.
      Only changing a Mentor ID (the technical GUID in the River database) could disconnect a comment from a Mentor with this design.
      2. Why not SQLite? Because I think the way I did it was the easiest solution, especially considering that I bundle a full data load with the application. By using only one persistence format (object tree serialized to file) I spare myself the trouble of moving data from one resource into the database at deploy/install time and from the database into application memory at runtime. But I can't wait to gain experience with SQLite.
      Of course, being a newbie to Android development and also quite inexperienced in Java, and considering the time pressure, I went for the path of least resistance whenever possible. But the more you refactor, the more you learn. 🙂
      Author's profile photo John Patterson
      John Patterson
      Hi Thorsten
      Thanks for the honest answer

      RE: "can't wait to gain experience with SQLite" - I think you will really enjoy using ContentProviders for managing data, the CRUD operations interact nicely with REST Service calls.

      RE: Architecture, I noticed there is no push to the mobile device, I wonder if we will see something like a Cloud to Device Messaging(C2DM) or even an OData + Sync framework in either River or Gateway.

      Author's profile photo Jan Penninkhof
      Jan Penninkhof
      Hi Thorsten,

      I couldn't help noticing that the iPhone (html) version was running on Google's App Engine. Is your App Engine application also just behaving as a REST client, just like the Android app is?
      And what made you build that application on App Engine? Wouldn't it be possible to build the same functionality on the River platform?


      Author's profile photo Thorsten Franz
      Thorsten Franz
      Blog Post Author
      Hi Jan,
      To be honest with you (I can be because noone else is listening), I had to hack out the HTML-based application as fast as possible - so I did not program a REST client on the Google App engine but export a CSV from River and bundle that with the HTML web application (as well as a light-weight CSV parsing library). After all, the web-based application is just a temporary solution until the native iPhone app is released at TechEd Las Vegas.
      Yes, it is possible to build custom UIs with River. There's an SDK for Flex UIs on top of River and you can deploy the UI part on the River engine, so you can have integrated application life-cycle management, versioning, and so on, for the UI and the back-end part of the application. However, this approach would have been overweight for the task and I'm not sure it would work at all with anonymous users.
      Author's profile photo Marlo Simon
      Marlo Simon
      Hello Thorsten,

      Great App, I downloaded it recently and checked to find my fellow Brazilian mentors, all there!

      #Search Button?
      As a happy Nexus S owner and now fanboy, we have a dedicated search button on the device (Motorola phones do too) but many Android users out there don't have a dedicated key. What do you think about adding "Search" in the Options Menu? Or maybe adding a search button or field at the Top Banner?

      I believe this will be always really trending at show floors, thank you for that.

      Marlo Simon.

      Author's profile photo Tobias Hofmann
      Tobias Hofmann
      Hi Marlo,

      that's the issue with my device: no search available. But the HTML version works 100% on the Adroid too.