SMP and MBOs – what is next?
Its a question that always crops up during projects especially when dealing with the SAP Mobility Platform (SMP). What method of communication or storage should I use? Do I go for SMP’s REST API’s and some web services, or do I go the route of the Mobile Business Object (MBO) and RFCs or even do I leave the SAP Mobility Platform out of this altogether and just go for Gateway and OData? Its a question that will plague the start of many a mobile project.
The MBO Approach – what do we get?
We have always seen the MBO route as being our native companion on the SMP. If you want a really great native offline experience or were looking to use the SMP Hybrid container then you would normally choose to go down the MBO route. It’s a smart route if you are looking for an app that requires features like:
- Offline data access
- Security of data stored on the device
- A pre-built synchronization mechanism
However, the MBO approach is not always the right way to go. One of the aspects that is a killer for me is support. By using this kind of closed communications and storage mechanism you are at the mercy of others when it comes to keeping up with the latest technology innovations. Take the release of iOS 6 – there were a few problems with SUP 2.1 supporting that OS and yet we didn’t see a patch to add that support for quite a period of time after it was released.
And what about adding new platforms? If I have released an SMP application using MBOs for iOS and Android but now I want to port the same application to Windows Phone or Blackberry 10 – how do I do that with no native MBO support for those platforms?
We need to cut this dependency on others when thinking about our mobile future and start thinking in an open manner. Don’t get me wrong, I think that no matter where the platform goes in the future the MBO concept is not going anywhere, I feel we will see it used only for a very small number of applications with very specific requirements.
So where do the REST of us go?
Enter REST. In more recent releases of SMP we have gained access to some nifty REST APIs for accessing the bedrock authentication and registration mechanisms in SMP. Combined with the pre-existing web service proxying options we are starting to see a real alternative to the traditional native application mechanisms.
There are obviously some trade offs when going down a route like this. One example being the need to build up your own synchronization mechanisms through the web services but that shouldn’t be a problem for most good development teams. In fact having that control over where your data is stored on device, when it is synchronized and also how it is synchronized is a major plus in my book. So now we are left with a secure way to access our data, using open standards and methodologies that all developers can hook into. Sounds like we are heading in the right direction when we leave the old ball and chain (MBOs) behind us!
Of course you may not even need SMP in the middle and you can just go straight to SAP Gateway to consume some OData services. It all depends on what you are trying to achieve and what you have available to achieve it.
To finish up, this is a topic I feel that we are going to be hearing about more and more. We cannot expect the mobile world to accept the MBO route indefinitely especially considering the massive push we see all around us to adopt open standards that enable rather than hinder.
Using a closed eco-system that is reliant on others to support a given platform has to become a thing of the past. In my view, watch this space – enter SMP, GW and SAPUI5 perhaps?????