Skip to Content

Developing an android client for a business application – part 1


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.

You must be Logged on to comment or reply to a post.
  • Hi Marcello,
    I think TMS would be an awesome use case to extend to mobile devices through a friendly and easy to use app.
    What kind of functionality is currently supported by your app? Or if I read it right, it’s connected to some backend functionality? Would love to learn more about the different use cases, that it supports within TMS.
    Possibly something even for another blog? Your “part 1” behind this blog, sound promising 🙂
    Cheers, Martin
    • Thanks Martin,
      TMS wise the only activity supported is importing change requests on several systems.
      But it’s not actually an interface to TMS, it’s an interface to a custom product.
      The product,among other things does the following:
      – maintains a series of paths containing several servers
      – for each server, maintains one or more queues of transports to allow complex approval procedures
      – groups business-wise related transports in “tasks”
      – moves transports around, usually by task

      The Android interface has limited functionality, which includes:
      -gives an overview of how many transports currently are in each queue
      -displays a list of tasks per queue
      -displays the content of each task
      -conflict and sequencing analysis of the transports in a task (screenshot above)
      -approval and rejection of a task in any queue: in some case this result in the import of the related change requests

      I plan to add some other feature, like the ability to release a change request and read the transport logs.

      Several features of the underlying application are fully supported by the APIs but don’t generate any visible output (i.e. merging transports from different servers).
      And of course I’m going to write another blog about the actual implementation.

      • Nice functionality! Thanks again Marcello and congrats for the app, I think not too many folks have mobile accessible TMS processes right now.
        Looking forward to reading more about this eventually!
  • Hello,

    you quoted in your very last senctence: “Also note that Android has a multithreaded, non-blocking programming model: communication between views is based on callbacks and a global application class.”

    Can give us some insights on that one? How is Android programming model compared to Web Dynpro approach?

    All the best,


    • Maybe I was a little too bold: I’m learning Android programming by trial and error, I didn’t really study the architecture.
      I’ll draft a response here and then expand it in part 2.
      However, you open a new window with code like this:

      Intent in = new Intent(view.getContext(),TaskDetail.class);
      startActivityForResult(in, TASKDETAIL_REQUEST_CODE);

      What happens is that foo is called immediately.
      I’m not sure if the new window (TaskDetail) is started immediately by a thread spawned by startActivityForResult or the same thread after the current method is finished.
      At some point TaskDetail will call setResult and then finish:

      Intent i = new Intent();
      setResult(RESULT_OK, i);

      and this will fire a callback in the calling screen :
      protected void onActivityResult(int requestCode, int resultCode, Intent data)
      requestCode will be equal to constant TASKDETAIL_REQUEST_CODE that we used to fire the screen above.

      Basically you can transfer between the two classes using name,value pairs as shown above, but only simple (or serializable) types: I guess this means that serializables are converted back and forth to strings, which looks dumb for local calls, so I opted to store the application state in a global application class, accessible via getApplication()

      I haven’t touched webdynpros for a while, but I recall that window navigation is based on plugs and we can add to them all the parameters we need.I might be wrong, but I reckon calling a plug permanently and instantly passes control to the called window.
      Then we have the contexts that play a role somewhat similar to the global application class in Android.

  • I appreciate this work.
    WebServices are known to be the most easiest way under current conditions to wrap RFCs and bridge to devices.
    However, our strategy is to bridge the gap between backend and devices using RESTful services on a specific XML based protocol called SAPData. The Gateway project is addressing this. You might be interested to check out some material in our SAP internal community (

    Meaning: for business applications we do advocate RESTful services for mobile consumption.

    • Thank you.
      To be honest, I thought about using a RESTful service, but I would have to learn yet another tech and I already had quite a bit to chew.
      So I settled for a naive one, without worrying about RESTfulness.
      As I said, this was born as a personal “weekend project”.
      I’m quite interested in SAPData, and I would certainly consider rewriing the backend part to make it more standard compliant: if nothing else because it’s an API we might want to expose (at least partly) to customers.
      Too bad I can’t access your link, I guess it’s on your intranet.
      If you can point me to some public copy or send me some docs I would really appreciate it.
  • Have a look at this project:

    It is not that feature-rich to process WSDL-Files but it can handle the SOAP-Communication between Java-Mobile-Phones and SAP PI 7.x.

    We are planing to port it to Android altough it should compile by now because it uses very basic java-libraries.

    We do our mobile apps that way that we encapsulate native RFC-Calls (since our ABAP-Guys don’t know how to write Webservice-Providers and/or webserice-consumers in ABAP) into Webservices by using PI 7.x. More details can be found here:

    • Thanks Rene, I’ll take look when I have some time.
      To be honest though SOAP services lose much of their appeal to me if  have to write the proxies myself.
      One thing though: most ABAP guys are scared by the word, but turning a RFC function group into a webservice is a matter of running a couple of wizards, any rogrammer can handle it after a half day of training.