Does MBO stand for “Mighty Bad Option”?
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!
Hi Brenton,
Thanks for the blog. I for one have used MBOs and found the out of the box offline capability a neat feature. Do you think offline OData is a proper replacement for MBOs at this stage? I did read somewhere that the Syclo Exchange Framework will provide the sync capability required to offer a robust offline solution.
Regards,
Raj
Hi Raj,
if our offline OData capabilities are a good alternative to the MBO technology highly depends on your situation and the project at hand.
So if you are familiar and comfortable with MBO's AND your app life cycle fits into our MBO support window, why not still use MBO's.
But if you have not yet touched MBO's a lot, taking a hard look at the SMP3 OData approach surely makes sense.
The Syclo / Agentry framework in SMP3 is neat stuff, but I do not recommend it for single custom application approaches. Maybe if you want to build a re-sell-able app that need to be customized for every of your customers. This technology simply is not well suited for the quick app build / app factory like approach.
Suited OData Offline use cases:
Be carefull with non-OData offline capable backends (no delta token support). SMP3 (Server SP04) can generate the delta needed for offline data sync. But it means to read the full data set from the backend most of the time as the current caching methods are pretty basic as of today.
In contrast, the MBO server side does bring you much more sophisticated cache refresh mechanisms and the always popular DCN. Those features are really needed when you are facing a non SAP backend where you can not change anything to fit your mobile use case.
Hope this makes sense,
Cheers,
Dirk
Dirk,
I will have to disagree with you about the Syclo / Agentry framework. It is well suited for applications (including custom one off apps) that need strong offline capabilities. Agentry was built from the start for offline.
While I do admit there is a learning curve associated with the Agentry framework, an experienced Agentry developer can just as quickly build applications that include offline. Users should evaluate their mobility requirements and the platform options (including Agentry) in order to make a decision on which route to pursue.
--Bill
Hi Bill,
if you are a Syclo/Agentry specialist like you Bill, I do agree. From a more general perspective and (as I pointed out in my narration) with the background of many apps, smaller and medium sized ones (app factory style), the current Agentry approach is not the best suited one in our portfolio.
As we all anticipate the SMP3/HCPms OData offline technology and SDK integration to be the core focus in the future, I would hesitate to recommend to a new developer to start developing apps with Agentry. For new starters, look at OData offline and Kapsel, for SUP developers stay a bit longer on SUP / SMP2.3 if your project allows. If you know Agentry, hey stick to what you know well.
Again, I believe a lot depends on the perspective.
Cheers,
Dirk
Dirk,
From what I am hearing Agentry will be making it's way to the cloud as well so I think it is here to stay. I appreciate the comments and your insights.
--Bill