As a veteran of many Sybase Unwired and SAP Mobility platform implementations using Mobile Business Objects or MBOs I am frequently faced with the question of whether to use MBOs or not for new projects. While my knee jerk reaction is a resounding no, the answer is a bit more complex than that. So let’s explore it a bit more:
Why default to a no?
This is the easiest part of the answer to justify, it’s because MBOs as a technology are not being developed by SAP any more. As of version 2.3 of the SAP Mobility Platform (SMP) the MBO runtime is end of life meaning that although supported for the moment, there will be no more updates with new functionality such as new mobile OS platforms. A great example is that the runtime currently does not support iOS 8 which currently makes up > 52% of the iOS install base.
However this doesn’t mean that you can’t use then as SMP version 3 supports the MBO runtime on the server no problem and the majority of MBO apps should run fine on that technology. But the technology in use to run the MBO component is literally copied from version 2.3 and runs as a sidecar on the server as opposed to being integrated with the newer aspects of the server.
Where would you use MBOs
There are still some times where MBOs are still worth using and they fall under two categories for me:
- An existing MBO based mobile implementation on specific OS platforms that work perfectly today.
- Depending on the app type, usage and business worth it may be more prudent to stay where you are
- Although if that solution is planned to continue into the future on new platforms then an alternative should be explored to replace the MBO aspects of the application.
- Platform specific implementations such as earlier blackberry or windows mobile applications on rugged devices which are still used in certain environments
Although I have listed two scenarios here where I would consider MBOs it is clear that any new implementation or any planned upgrade of an existing app should seriously consider changing the data synchronisation mechanism to some of the newer more device-agnostic methods.
What are the alternatives?
If we stick with the SAP Mobility platform then we are left with a clear migration path and that is of course to OData. OData is a open data web standard originally developed by Microsoft. It is a light-weight, self-describing and RESTful protocol. For a great overview of the standard check out this video or the OData website here.
OData is now natively supported by SAP systems with SAP Gateway installed or with NetWeaver 7.4 it is a standard built-in component. But on top of that, the newest version of the SAP Mobility Platform V3.0 has a neat component called “integration gateway” not to be confused with “SAP Gateway” which is an ABAP component. Integration gateway allows SMP to consume data from a variety of sources like SOAP, SAP, OData, ODBC and REST in general and turns the data (with some modelling help) into oData services that can be consumed through SMP.
All of this combined with SAP’s end-user strategy points to a utopian world of oData everywhere. With SAP servers, Fiori and SMP all speaking oData for data access and communication it seems like a no-brainer right now that we should move the same way for our mobile apps. Not least because that leaves us worrying less about proprietary SDKs like MBOs and more about creating amazing experiences that our users will love!
So for me the answer is clear – give MBOs a REST and move to oData unless you have a clear reason not to!