SAP Frontend Choices

Jan 2012 – As someone from SAP Technology background, I started investigating how I could find a toe hold in Enterprise Mobility. The story below gives the knowledge points and the thought process behind that.

Alright – you are from SAP Technical (say ABAP) and/or Portal background, may know some Java and/or OOP and want to check out mobile development.

You know starting off in iOS development means owning a Mac at the minimum (if not also an iPhone/iPad/iPod) – since the development environments needs iOS. The easy one is going to be Android.

A mobile app is basically an interface to some logic or process. Games, Note taking, browsing is fine for native apps, but when it comes to using Mobile phones for doing work (like work!), it’s going to mean interfacing with the backend systems of a company. So it would mean that the backend enterprise applications would get opened up to be accessed by these devices. The devices have to managed, secured, etc. is one piece; the relevant piece here is what would be the application architecture that would enable this talking of mobile devices to backend applications.

There are hundreds of kinds of enterprise applications, and each would get exposed in some manner. Of course there are standards propping up to help out at the communications layer. Starting our journey to narrowing down our focus on SAP, well, as of Jan 2012 we surely know that SAP would expose its data through Sybase’s SUP (Sybase Unwired Platform) product, and in turn through the SAP NetWeaver Gateway. Suffice it to know for now that data would come in the form is OData and would be read and interacted upon in a mobile device (OData protocol would let you programmatically act on application datasets using specific http commands like PUT, GET, POST, DELETE). SAP’s almost going away from SUP as a middleware is a separate topic in itself – though note that it would still need some configuration on the SUP side.

Exposing the business data and process logic in the right format would happen in the backend SAP using ABAP BAPIs, BOR, RFCs, Class Handlers, etc. (we have known that for a while using Portal, Web Services using SOAP, etc.); however the idea of using this data and creating a mobile app would ideally come down to learning some mobile frontend development and its integration to backend datasources as well (Its perhaps going to be a golden opportunity for developers and architects working at the cutting edge to understand how the different frontend mobile technologies work, and how to call out data from the backend and make sense out of it for the professional Mobile GUI developer).

So, knowing the basic architecture, I arrived at the following straw man approach to learning more, given that you cannot even have evaluation SUP software from Sybase (by the way Google various terms if you want to know more on them):

Understand OData source
Understand (only) how a certain BAPI or Function can be exposed to SAP Gateway to make it into an ODATA source. SAP Gateway, by the way, would be installed on top of your ECC system by Basis.

Find an experimental OData source
There are plenty of free ones available (check Azure); even from SAP, I could find one for using the famous Flight Data example.

Set up your Eclipse IDE with RESTlet API
Understand that SAP Gateway would expose SAP data as OData – it will be consumed using REST (Representational State Transfer). There is an OData SDK that is shipped with SUP. But not having SUP should not be a constraint. A RESTlet api can generate classes from OData that can be further used in mobile app development. Good enough as an example to learn.

Generate Proxy Classes
Generate the proxy java classes from RESTlet for the OData source. Use them in a test Java Main class to ensure this part of the story is in order.

Consume ODdata in an Android App
Next, it could be worth a POC to see how to consume OData in an Android App.

Consume any web data on an Android
In order to know this, understand how to consume RSS, XML or other web data in an Android app. App can be a mobile Web app, or a native App that uses this data. Knowing this can’t hurt.

That brings us to the question as to how to build an Android app.

Use eclipse and the Android SDK to build a test native app – setting up the environment and building a Hello World (it took about an hour or two). And you can run it on the Emulator (not even an Android phone is required). That part was fine. Followed on with building the Note taking app – a tutorial for which was also easily available, but the app itself was complex.

That got me to a point where I felt there would be easier ways to develop Android apps. As I looked online, I found a flood of information on different choices available and it took a while to make any sense out of it. Especially becomes troubling when you see each vendor claiming you can make an App in minutes, while you know that making those two apps in Eclipse was not really that easy and needs quite a bit of development and understanding.

IDE – use Eclipse Indigo, or use Basic4Android IDE or use Sencha

• Appcelerator Titanium – lets you use Javascript and Html5 to code, but writes an Objective C or Java code that’s loaded up. Bought Aptana also.
• Phonegap – is Open Source, owned by Adobe – lets you code in Javascript, but runs in a framework in the phone. Integrates with Dreamweaver 5.5.
• Appmobi – lets you write code online, lets you code in javascript, but runs in a framework in the phone
• Corona – supports apps for Nook, Kindle Fire amongst other Android and iOS
• Others like Appgeyser, Mobilenationhq and App Inventor (Google – MIT) let you work online – drag and drop tools – probably of little use in enterprise world

The more I read, the more I got into how to make the apps platform agnostic with respect to Operating Systems (iOS, Android, Windows 7, BlackBerry, Bada, etc.) and also Device agnostic (Phones, Tablets, eReaders, TVs of different specifications and capabilities). The easy answer seemed like use of a Javascript library to leverage advances to HTM5 and CSS3 standards (making it even Browser agnostic). This could make most sense for cost conscious enterprise IT departments (more details on that is a separate topic in itself).
Or it would be for SAP to start closely supporting a couple of approaches, and create tools and processes to support it.

At a tactical level, I veered to the point of view that one really should be learning how to use jQuery for Mobile to create the app on the phone (its more than a web app as it still leverages the camera, the accelerometer, the GPS, etc.). jQuery Mobile seems like most obvious choice as is preferred by MS, Nokia, and even Google (though it also supports GWT). By the way, another competing framework is Ext JS used by Sencha. Yet another is Dojo.

My conclusion for short term is that one could continue coding basic Native app using Eclipse using Java to tie into backend systems. Or it will serve well to understand and know (short of an expert) jQuery Mobile for building end user interfaces that work across devices and platforms. There is an SDK available for JavaScript as well – called OData Javascript Library that could help leverage the SAP ERP data for these web apps.
As far as jQuery for Mobile is concerned, in any case, it will serve well to first understand some nuances of jQuery before one gets into more of the mobile version (I used Aptana Studio to work on it, with some free video tutorials from thenewboston.org). There may be further issues around Single Sign On, security, app provisioning, etc., using jQuery, but I don’t see them as insurmountable.

Not to miss the point, using SAP or Sybase’s SUP 2.1, one only gets code snippets for different platforms that then need to be inserted into a front end development environment of choice to build the final Mobile Apps. Sybase provides only limited front end development tools.

Of course this is one way the journey could have been taken. In mobile world, as you would know as well, there are numerous ways of getting to the same result. Or may be a little different result, but who knows what’s better. And this could just be the one way to learn, and many more could follow.

So that’s how far a week’s journey has taken me thus far.

You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.