In the following I will try to explain some of the new main features of SMP 3.0. Because I am coming from SUP area I won't take a closer look on Agentry or Mobilizer applications.
Main Features of SMP 3.0
- OData Offline
I really like the OData SDK libraries which are available inside the SMP 3.0 SDK package. The SMP 3.0 OData Libraries are based on the OData Libraries which were available starting from SUP 2.2. In 3.0 additional functionality got added, e.g. Offline caching and JSON parsing.
For the communication between device - SMP - SAP Gateway I starting to prefer JSON (instead of XML). You have less overhead and the parser is faster. First thing an OData app should do is to register a new user at SMP using the REST API. In this registration call you can set a Header (X-SMP-APPCID) which will specify your application connection id. After registration (can be done synchronously or asynchronously) you need to set this APPCID header on each request. Before you can parse data you need the Service Document (from SMP) and the OData MetaData Document (from SAP Netweaver Gateway). The Parser needs both documents to parse OData responses. If you make a request (Android: async, iOS: sync or async) to an OData Collection you can catch the response and forward it to the OData Parser which returns a GenericList of ODataEntry objects. You can access a property of one entry by calling entry.getPropertyValue("ODataProperty") (in Java/Android). This OData response can be stored (before parsing) inside an offline cache. The Cache is a SQLite database which is encrypted using SQLCipher (Open Source). But be aware, at the moment (SMP3.0) only OData documents can be stored inside the cache. That means, you cannot send SQL queries to the database to get only one or a list of specific entities, and you always have to parse the OData document after you got it from the cache. Nice thing is that also the requests (POST/PUT/DELETE) will be cached in a queue. Next time when the app has internet connection again the requests in the queue will be fired. - Kapsel
The basic idea behind Kapsel is great. Instead of putting Apache Cordova as plugin inside an SAP app (like it was done in the Hybrid Web Container), you have now a collection of Cordova plugins (called Kapsel) which can be included in a Cordova App. At the moment Kapsel consists of seven small plugins AppUpdate, AuthProxy, EncryptedStorage, Logger, Logon, Push and Settings. You can use the plugins e.g. to authenticate with SMP, to store key/value pairs offline or for native push enablement (APNS for iOS and GCM for Android). Also the AppUpdate Feature is nice to have. You can create a new version of the HTML5 app and place it on the SMP server. Next time the Cordova Kapsel App is coming online it will recognize that there is a new version available and will update itself.
The major disadvantage I am seeing at the moment is the fact that the developer has to do everything by himself. He has to install Apache Cordova, including GIT and NodeJS, manipulate PATH variables and then use the command line to create an Apache Cordova project, include the platform (e.g. Android, iOS, Blackberry, ...) and then add the Kapsel plugins. After that is done the HTML5/JavaScript source can be integrated. Also I am missing a "plugin" which provides Offline caching capabilities, like in the Native OData SDK Libraries for Android and iOS. When using Kapsel in combination with the AppBuilder I see a big benefit. The AppBuilder is a WYSIWYG Editor which is running in the browser (HTML5) and allows you to create SAPUI5 apps. You can simply move UI elements via drag and drop to the work screen, but also switch to the coding tab and change the source code. If you create your HTML5 app inside the AppBuilder you can direclty create here a Cordova Kapsel App. A greate detailed introduction has been written by John Wargo in his blog, here http://scn.sap.com/blogs/johnwargo/2013/10/21/an-introduction-to-smp-kapsel . - Integration Gateway
The Integration Gateway is a new component of SMP3 which can convert on the fly data from different backend sources into OData. At the moment the supported backend sources are SOAP web services, OData services, JPA or JDBC data sources. You can develop your OData service using any tool, e.g. eclipse in combination with GWPA (Gateway Productivity Accelerator). You can download the GWPA eclipse plugin here https://tools.hana.ondemand.com/juno/. Then model your ODataService and start an Implementation Project (can be only done if the Integration Gateway Plugin of GWPA is also installed). There you can define a data source for each OData collection. If you choose SOAP or OData you can specify a mapping directly in eclipse, if you choose JDBC you have to name the entityset exactly like the tablename and the attributes exactly like the column names. At the moment there is no possibility to perform a graphical mapping between source and OData service for JDBC connections. After you modeled your service and defined the data sources you can deploy the OData Service to SMP3 (make sure that you deployed the JDBC driver at first on SMP3). After that open the Gateway Cockpit on SMP3 (localhost:8083/gateway/cockpit). There you can see your deployed service, adapt the backend source (Destination), make sure the security config is available (by default create a config called sap) and then activate the service. After that you can access the OData Service on SMP's address.
Some things are (at the moment) not possible with Integration Gateway. You cannot call directly BAPIs or other objects using RFC calls (like on MBOs) and there is also no delta logic for the data sources. (With Delta Queries SAP Netweaver Gateway 2.0 SP07 is supporting a Delta Logic.)
In my opinion it will be very interesting to see how customers like the SMP 3.0. I think that the way is the right one, also if not all features and tools which I would like to have are yet integrated. But the next versions, e.g. 3.1 will have enormous enhanced functionality. So with that in mind I guess that SMP 3.x will become a great success!
