River goes mobile: The SAP Mentors Outreach Mobile...

former_member182046 · ‎05-22-2011

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 SAP... (download at https://market.android.com/details?id=de.thorstenster.mentors). 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.

Time-outs

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.