Foreword
Discussing a real application has some issue: I can't post the whole code here, only snippets, and I can't go too far in the details without making it look like advertising.
On the plus side, it's a real business case, although not yet ready for customer release, and a non-trivial application.
Many thanks to the many that paved the way for sap specific android development, including (but not limited to) Paolo Romano,Ignacio Hernández and Dagfinn Parnas.I don't have anything to add on the technical side.
I'm quite experienced on the ABAP side, but was my first Java (and of course Android) project, the code quality reflects it.Also, error handling is incomplete and, as you can see below,I didn't even try to make il look pretty yet.
See Developing an android client for a business application - part 2 for details on the SAP/Java interface and Developing an android client for a business application - part 3 for the Android implementation.
The application
I work on a change management tool, based on a windows GUI that talks to a SAP system via RFC to automate and control the flow of transports in a SAP landscape. The process mostly deals with groups of transports called tasks.
Calling SAP from Android
My application is already based on remotely callable APIs,but they're quite low level and would require quite a bit of work on the frontend, which I don't like both for performances and versatility: sooner or later we'll end up writing a blackberry client, and maybe an iphone one,...
Keeping as much code as possible in the backend looked the best strategy.
Also, I might be wrong but I think calling SAP RFC APIs directly from java required JCO, which has a binary component that will never run on android phones.So I thought about using SOAP webservices, really easy to create based on existing ABAP code...
But Android does not support it! There are The specified item was not found., but they mostly involve using a library (ksoap2) not actively developed since 2006, which I don't really like.
At the end of the day I opted for writing directly an ICF handler, and calling it via HTTP POST or GET queries.
I'm using the same handler for the whole application: an ACTION parameter decides what function is required, and while the output data varies a lot, it's always embedded in a string as XML.
Final architecture on the ABAP side
On the SAPside, I created a new webservice in SICF.This is handled by a class that reads the parameters passed from the android client and returns an XML document.
Client implementation
The Android app calls the web service (either with GETs or POSTs) with various parameters, then parses the incoming XML into a DOM tree and then extracts business data from there. This technique is not the ideal for performance: callback based SAX parsers should be faster and use less memory, but at the moment I was more concerned on getting it to work, and my own phone handles it easily.
Also note that Android has a multithreaded, non-blocking programming model: communication between views is based on callbacks and a global application class.
14 Comments
