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?
REST
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.
Conclusion
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?????
Brenten, what you mentioned is right. There are different approaches to develop a mobile application using SMP. And the architects and developers like us definitely scratch our head on selecting right approach.
Technologies will be always changing and we will be in that flow to learn what is new. So according to me, follow what we have now and be ready to learn the next innovation.
In the SMP road map SAP has mentioned that they are gonna keep a single data modeling and it is Odata.
- Midhun VP
Nice blog Brenton. Rolling your own conflict resolution/merging code sounds like it could get a bit hairy though!
Interesting take on it here:
http://www.ericsink.com/entries/crud.html
well said Brenton.
Thanks Brenton. Nice piece of information.
This change in innovation and technology has raised a few doubts in my mind.
Will the upcoming SMP technology provide any support for already existing MBO based applications? I mean the ease of migration,redevelopment or possibilities of integration with SMP.
And any updates on SMP GA 2.3 or 3.0.
Hi Dharmaraj,
Thanks for the reply - As far as existing applications go we are not going to see the withdrawal of MBO support for a long time yet (if ever in fact) and I can confirm that the upcoming 2.3 release still supports that framework.
SAP's Hybrid container framework is still based on MBOs and I don't think that is going to change much in the near future so I wouldn't worry about the technology disappearing.
Where this is most interesting is for new developments rather than existing ones I would think.
As for the 2.3 and 3.0 releases, I'm afraid I don't have specific details on the release dates but with 2.3 already in ramp-up I would imagine it is not too far down the line.
Thanks,
Brenton.
Brenton,
At last week's Sapphire I got the definite feeling that the MBO approach to off-line was going to be supported going forward, but is not a recommended solution. With Agentry integration and upcoming synchronized OData, it seems that there are a few techniques that will survive over others as the platform takes shape. Most interesting was the Fiori approach to bypass the platform completely, at least for the initial release. What do you make of that decision?
Scott
Hi Scott,
Thanks for sharing your Sapphire experience - Fiori has indeed brought a whole new dimension to this topic and I found myself asking where the SMP fits in the world of Fiori - and its a good question. I suppose if SMP was to be your proxy into the world of Fiori that would work and you would get your authentication taken care of but even them I'm still not sure that would work well or really be necessary. Only this week one of my clients asked the question - well then why on earth do I even need the SMP - why don't I just put all my eggs in the Gateway basket?
I'm not surprised that the MBO approach is being discouraged while not being removed from the platform but the other options have a bit of a way to go to fix that gap I think.
Brenton.
Hi Brenton,
Nice blog. What do you think of Agentry? I personally like it a lot and think it will be the future way to go. At least for complex offline process apps. All we need now is a way to build great UIs on top of it đŸ™‚
Regards,
Jan
Hi Jan,
Thanks for the comment - Agentry is a very good platform for certain scenarios especially around the rugged field service mobility area. I think you have hit the nail on the head though around the UI. If Agentry increases its UI capabilities then it becomes even more powerful than it already is - combined with its integration into SMP 2.3 it brings it home as a real option for businesses.
Definitely a space to watch I agree!
Cheers,
Brenton.
Thanks for the quick response, Brenton. We have done some quick (time pressuuuuure!!! đŸ˜‰ ) UI enhancements with Agentry and it seems like quite a flexible platform to get the (standard) apps suit the customer needs better. (I could send you some screenshots if you like, let me know)
If SAP releases their new tools and components like MAF and HTML5 options for Agentry apps, then it will be booming for sure đŸ™‚
As a follow on from this - the announcement today around the new version of sapui5
brings a whole other level to this topic.
SAPUI5 and mobility going hand in hand đŸ™‚
Yes. I had tried the trail version of SAPUI5. It is capable to replace other 3rd party tools like PhoneGap and Sencha. And it is easy to design the UI đŸ˜‰
Hi Brenton,
I would like to ask you how to approach the following requirements without MBO:
- Sales app with huge amount of data of customers, material, etc.
- Offline required
- Each device needs to synchronize different data based on the user organizational assignment.
With MBO this is relatively easy, but I think if you have to control this with web services you need to do a very big effort on the Mobile app development. And I think using HTML5 instead of native apps with huge amounts of data required offline is barely impossible.
I hope you can help me.
Regards,
Marshal
Hi Marshal,
Sounds like a really interesting scenario. I'd need to know more about the requirements to fully flesh out all of the options and feel free to ping me directly if you'd like to discuss this in more detail.
From what you have described it sounds like it may be a multi-platform deployment which with MBOs has quite an advantage over other methodologies. However equally it strikes me that it may be a candidate for a Hybrid application where certain aspects of the app are native (the synchronisation mechanisms) and other parts are HTML5 based (perhaps the common UI).
Depending on exactly which type of scenarios this would be used in (rugged devices in the field, corporate devices etc.) you may want to consider different options. It is always worth considering the future of your application as well in order to understand what (if any) other platforms you may want to look at supporting and how easy that might be - bearing in mind of course the ever-changing nature of the mobile space.
Sorry I can't be more definitive in my answer however I am a firm believer in taking each scenario as it comes and assessing it based on the requirements rather than aiming for a "one size fits all".
Hope that answers your question a bit,
Brenton.
Hi Brenton,
Thanks for answer my comment.
Well there is not much more to detail without being too specific. But in the past I participated in two different projects like the one I described before. The purpose was to create a mobile sales app for tablets (not multiplatform: the 1st project was for iPad and the 2nd for Android). The end user wanted all the data available offline to be able to create sales orders, check customer history, calculate the price... into the device and each tablet user needed different data according organizational data.
The thing is that I don't particularly like to work with MBO's, the way to call the backend, the logs, how to reprocess the messages and so... and that's why I wanted to know an alternative. But the true is that using MBOs we had all the synchronization done by SUP. SUP was fetching the data once a day from SAP (which was a long call, maybe one hour to get all the data), and then distributing to each device the necessary data.
Using MBOs you have the synchronization solved, an automatic generated code to create the database model to your device and the API to access this data, and the mobile developers can focus in the user interface.
Why don't you have a look if the new standard Sales Manager app from SAP/Syclo is a fit? I know that it provides a positive solution for the first three requirements you sum up.
Hi Marshal,
For your case, MBO approach is the best. We have worked with different options ( native, HWC,SAPUI5,..), but in your case MBO is the preferable one.
It is indeed good that SMP offers different methodologies to develop a mobile application. This will excite the development team, but it is difficult to pursue with different kind of development methodologies. More options give raise to more confusions ( that's what I feel now). It is good to see while trying out these things, but when it comes to real implementation, it becomes a nightmare.
Whatever the approach be, the fundementals should stand intact - Decent UI, good performance, and data consistency.
With HWC ( or rather web technologies), we have seen performance issues. Even with good mobile internet connection, the data synchronization takes time. This results irritation to the user. If this is the case, we fail to achieve what we were set to achieve.
However, technology is rapid and mercurial. This is a space to experiement, explore and execute.
- Suraj
Hi Brenton,
thanks for the nice blog! What do you think are the benefits of using REST API as part of SMP compared to using 'simple' REST services from the NW Gateway (without SMP)?
Regards,
Nils