There is no support for iPhone in the current SAP Mobile Infrastructure; that will surely change with time. At Bluefin we asked ourselves the questions:
- why wait for it?
- can we do it ourselves?
Why wait? We had a lot of internal iPhone users itching to gain access to our CRM system while they were out on client visits. They also wanted to update opportunities and other transactions – something that third party solutions were not able to do yet. Waiting may have been in vain, so…
Can we do it ourselves? The short answer was “Yes”. The rather longer realisation of that “Yes”, and my involvement, is discussed in this blog and the following parts.
Choice of Application Type
With the iPhone OS you only really have three options for this kind of model:
- A web-based application that provides a suitably styled set of pages on the integral Safari browser.
- A native client application written for the iPhone OS which consumes web services of a SAP web application server .
- A hybrid of the above; a native application which shows some content as iPhone views and some server-sourced web content rendered as web views.
The first attempt was the web-based application. A prototype was put together very quickly. I was given the job of improving on the prototype with the view of producing a viable business solution.
The web-based application is just a BSP application with some added extras.
In order to get the page looking like an iPhone view you need some CSS support to wrap your HTML in. Luckily there is a CSS framework for this available in the public domain at code.google.com.
The phone may show several pages but they actually all need to be on the same BSP page as sections. Writing an iPhone BSP with more than one page is possible but doesn’t get good results.
Drawbacks with the web application model soon became apparent:
- It is not suited to larger applications with many views.
- It is difficult to model an input form because of the ‘one page’ dilemma.
- Security is limited and difficult to extend beyond what is offered by the browser.
- It won’t work offline.
At this point it was decided to abandon the web application and move into iPhone native development. I have not discussed the web application solution in any detail because of this, however I may write another blog on it if there is sufficient interest in the subject.
The native application would offer more benefits at the cost of some complexity and the need to gain some new skills.
The first milestone of the project was deciding if the native development could be done. I am an ABAP developer by trade but I have worked in C++/C# and other languages in the past. Apple iPhone applications have to be developed in Objective C for Mac OS X and I had no experience of this. It took a few weeks to refresh myself on C++ concepts and make the transition to the particular style that Objective C for iPhone requires, but it was certainly looking achievable.
The second milestone of the project was how to get the iPhone application and Netweaver system to communicate. This would be different to the web application connection, which just requires you to bookmark the BSP app URL in the phone browser.
Well, Netweaver has Web services and the iPhone – that can do anything can’t it? Let’s use the iPhone web service API…except… somewhat unbelievably there is no such thing.
The iPhone can consume Web services but I had to construct a consumer class using the HTTP connector components in the SDK. Seasoned developers also advised me to avoid SOAP as it is difficult to write a handler and is heavy on resource usage.
A lighter consumer could be provided if I used RESTful services. The only problem here was that Netweaver doesn’t support REST as standard (although I’ve heard it will be supported in future).
That didn’t really turn out to be a problem because:
- I could still implement a RESTful web service in Netweaver WAS.
- I didn’t need many web services for my application.
- At least half of the services I did want to consume did not exist as a standard service.
The first prototype consumer application was put together and tested with some public REST services; this was successful and proved that the service consumer was functional.
With the help of some CRM coding gurus the REST web services were implemented in our CRM server and activated.
Thanks to DJ Adams for posting this article which was a great help in developing the HTTP interface at the start: Real Web Services with REST and ICF
Following the ‘object as service’ model gave us three basic services; account, activity and opportunity.
By varying the format of the ‘path info’ of the service URL it is possible to request different returns; for example, the account service can return:
- data of one account.
- “My accounts” – data of accounts that the current user is responsible for.
- accounts by marketing attribute
- contacts for an account
Connecting to the NW web services from the iPhone proved troublesome, even though we could test the same service from a browser. I needed a secure connection so the services are on the “https:” protocol (whereas the public service were on “http”).This revealed that secure connections, which require the phone client to send an authentication, could prove troublesome. Our network experts finally tracked the problem down to a firewall configuration; once reconfigured the service connections ran like a dream.
The services for my application are implemented on a CRM 6.0 system but it is the Basis component that matters for generic modelling of similar applications. If your class repository contains class CL_HTTP_REQUEST (version updated in 2004 or later) you should be fine.
At this stage I had an ‘always connected’ application; a good start but I wanted it to be operable offline and able to store changes in the client. At this point the complexity started to ramp up (data orchestration, notifications, locking, etc). There will be more details of this in my next blog.
I also mentioned hybrid applications. I haven’t developed anything like this but there is something in the pipeline along these lines and I am sure I can do it.
The aim is not to replicate the host system on the mobile device – we just want selected information to be accessible. If the user wishes for some kind of analysis reporting suite, that would be best published to a web page by the server as the server has all the resources it requires to do this. The mobile client can formulate an HTTP request and pass it to a web view in the application. There is no searching, sorting, calculation or formatting done by the client, which saves resources. Assuming that the web page is optimised for mobile display, this should work very well. The only downside is that web views won’t be usable when the client is disconnected.
The current version of this application will be on show at SAP Tech Ed 09 Demo Jam in Vienna.