In the last couple of weeks/months I worked with the brand new SMP 3.0. As you might know, the SMP3 is now in ramp up. That means that accepted customers in ramp up program can use SMP3 already. You can find more information about SMP 3 here:
Official RampUp information: http://service.sap.com/rampup > SAP Mobile Platform 3.0
Nice Interview with Tony Kueh about SMP 3: http://www.youtube.com/watch?v=ZBq82l_lZIw
Get your hands on SAP Mobile Platform 3.0 (by Jens Koerner) http://scn.sap.com/community/mobile/blog/2013/08/21/get-your-hands-on-sap-mobile-platform-30
Official web page for SMP3: http://www.sapmobile-platform.com/
Like mentioned in the links above, SAP's mobile strategy is focusing on buzz words such as Open Standards, Lightweight Server and Unified Platform.
Ok, enough marketing, maybe some more technical explanations
- Open Standards
OData is an open standard supported by many companies (e.g. Microsoft and SAP). It is represented either in XML or JSON. It consists mainly of collection of entities. One entity represents one data object. A collection is a group of entities. REST is used as architectural pattern to access/obtain the data.
The plan is now that every app uses OData to connect to SMP, so leaving the proprietary Sybase protocols behind. - Unified Platform
First, there will be only one platform which integrates Sybase Unwired Platform, Syclo Agentry and Sybase Mobilizer. Second, the platform based on a Lean Java Server and the OSGI platform. All components of SMP3 are deployed as OSGI bundles. This is really nice, because it means, that you can deploy or update components without the need to take the platform offline. Also it will give implementation partners the possibility to write their own components which can replace or add existing functionality. - Lightweight Server
There won't be a cache database. The plan is to have no duplicated/replicated business data on the mobile platform. I think this is the right decision, because the CacheDB caused a lot of trouble in SMP 2.x releases, mostly related to the chosen cache strategy (e.g. on-demand, scheduled or DCN). The recommend way was to use the Data Change Notification (DCN) approach. But for that it was necessary to implement a trigger in the backend which always pushed newly created/updated or removed records to SMP. So if we anyway have to implement logic in the backend, why not directly keeping the data where it belongs (in the backend) and sending the requested data from there to SMP which will forward it to the device.
SMP3 gives you some more nice new features, e.g. you can now choose the SMP3 database, which is used to store settings and SMP3 runtime specific properties (at the moment ASE, DB2 or Oracle are possible out of the box). Also you can now install SMP3 on Windows and Linux.
