Writing iPhone apps for SAP is a mindfield and a few tips and tricks will stop you from making some of the mistakes that we made early on! If you follow these 10 golden rules then you stand a better chance of making a successful SAP iPhone implementation. Good Luck and please write comments below on how it went for you!
1) Write a native iPhone app (and buy a Mac)
We started writing web apps but with SAP, you need to write this in a BSP and this becomes quickly very messy as it all has to sit in one page. Making modifications back to SAP is even harder and you have to use AJAX to load things piecemeal. What’s more it becomes really slow.
You need to go and buy a x86 Mac (sorry!) and pay your $100 to the iPhone developer program at http://developer.apple.com/iphone/program/. The programming language is Objective C so some C/C++ programming experience will come in handy.
2) Use RESTful services
The iPhone has no native SOAP ability so using function modules and wrapping them up as web services isn’t an option right now unless you want to parse SOAP using the XML libraries. What’s more, REST is a good protocol for mobile applications as it is low overhead which means faster network response and less iPhone CPU time spent parsing.
Check Uwe Kunath’s blog on this here: RESTful webservices in ABAP using a generic controller
3) Avoid security problems
The iPhone has Cisco VPN capability built in and this is a good way to get into your corporate network. We also used ISA Server with NTLM authentication and tried to use User Certificates for x.509 – but haven’t got the latter to work yet. From there you can use HTTPS basic authentication back to CRM.
4) Remember your memory model
The iPhone is based on Objective C which is a strongly typed (for the sort of objects you will be working on) and has no garbage collector. What you have to be most careful of is not to release an object in one place, when it is still in use somewhere else. If this happens, you will get the dreaded EXC_BAD_ACCESS error. You also have to be careful to autorelease or release objects at the right time, to avoid memory leaks, for which Apple will reject your app submission to the App Store.
5) Go online/offline using Core Data
We found that the complexities around online/offline data synchronisation were worth it. Early betas that we built were entirely online and it turns out that Objective C’s memory model means passing around all the arrays and such was really onerous and prone to releasing the wrong object at the wrong time (see point 4). Much easier, is to use Core Data to store your SAP information.
6) Use a data orchestration engine (DOE)
Once you are online/offline then you need to sync the changes from the iPhone to CRM and vice versa. On the phone, keep a change log which is written up to SAP asynchronously. On SAP, trigger events to a change log table (DOE) which is based on the subcribers that have iPhones.
7) Don’t trust the simulator (though it’s great!)
The iPhone simulator is great, but it compiles against x86. This means that a number of things will work on the simulator that won’t work on the iPhone, partially because the iPhone is compiled against a different platform (ARM) but also because timings are different. This seems to make the iPhone much more sensitive to memory problems. What’s more, the iPhone simulator actually has more OS libraries to compile against and you can for example consume SOAP services on the simulator for this reason (!).
8) Choose your business process
When you come to design your app – choose a business process that you want to simulate, and whatever you do, do not try to simulate a SAP software package by copying it. If you go to the business, they will often want all the functionality. Fight with them hard on this and find a business process which you can mobilize and keep it simple. Produce a proof of concept based upon this and iterate. Remember that good mobile applications do something – really well.
9) Abstract, abstract, abstract
Keep all your business logic in SAP and download master data tables to the iPhone. Try not to hard code business logic in the phone where possible because this will cause you a whole world of pain when you want to roll out a new app. Remember that iPhone software distribution is still quite immature and you have to roll out the app manually. which makes this doubly important!
10) “Design is not just what it looks like and feels like. Design is how it works.”
This is what Steve Jobs said in 2003 and it still holds true. The iPhone is all about writing apps that work well and feel right. Spend your time tuning your screens and thing about your screen flow up front. This will pay off in the form of user adoption.