SUP/SMP 2.x vs. SMP 3.0 – Migration effort
Of course it is really nice to use a new software architecture in SMP 3 (based on a Java Server and OSGI, supported transport protocol HTTP with ODATA), but there is one big disadvantage… What to do with already existing SMP 2.x specific apps?
Let me explain what you can still use with SMP3, what you can easiliy migrate and what you have to redevelop or even redesign.
SUP and SMP 2.x use two synchronization approaches when transferring data between client (mobile device) and mobile server:
- MBS – Messaging Based Synchronization
MBS uses a proprietary Sybase protocol which is wrapped in HTTP or HTTPS. The data payload itself is end to end encrypted. MBS can realize stateful connections, that means if an MBS channel is established the SUP has the possibility to push information directly to the mobile device. It is used in HWC apps (Hybrid Web Container) and also in MBO-based apps (for establishing the connection to SUP). The default port on the SUP server is 5001.
- RBS – Replication Based Synchronization
This mechanism is used to transfer/replicate business data. It is used only in MBO-based apps and there for the synchronization of the client database (UltraLite or UltraLiteJ) with SUP’s CacheDB (Sybase SQLAnywhere). Default port on SUP server is 2480 (or secure 2481).
Both approaches are not available anymore in SMP 3.0!
Starting from SUP 2.2 the REST API has been introduced and forms a third way on how to transfer data between device and mobile platform. Over an HTTP or HTTPS connection OData (or any other output of an REST WebService) can be transferred. The SUP/SMP is serving as a proxy and forwarding the requests and responses from the client to the backend source, which can be e.g. an SAP Netweaver Gateway or any other REST Web Service.
The following table will give you an overview about the possible SMP specific application types and also the information what you have to do to bring it on SMP 3.0..
|App Type||Replacement in SMP 3.0||Migration effort||Migration Stategy|
|HWC App (Workflow)||Cordova Kapsel App with AppBuilder||Middle||Redevelop|
|HWC App (Customized)||Cordova Kapsel App||Low||Adapt|
|Online OData (MBS) App||OData App (REST API)||Middle||Redevelop|
|MBO-Based App||(Offline) OData App||High||Redesign|
|OData App (REST API)||OData App (REST API)||No||No|
|MBO-Based App for DOE||not supported|
Some more words to this…
Most of the available SAP Productivity Apps are based on MBS. Some of them will get adapted so that they can be also used with SMP 3.0, some others might get replaced by SAP Fiori Apps (SAPUI5 based) which are more and more in a strategic focus.
If you are using the “new” REST API from SMP you are save, these apps can be used directly with SMP 3.0.
Migration of MBO-based apps will be the biggest challenge. Before starting the migration ask yourself if you really need to migrate. If your app is running fine under SMP 2.3 why changing this? (Never touch a running system…)
If you really want to or have to migrate, then you have to start a redesign project. You have to model an OData service, either in the SAP backend on SAP’s Netweaver Gateway if your app is “only” consuming SAP backends or on SMP 3.0 Integration Gateway where you can model OData services that consume JDBC, SOAP Web services or JPA backend sources. Also you have to redevelop your client app, remove all MBO libraries and system classes and insert the SMP OData Libraries (only available for Android and iOS). Also think about the fact, that there is no client database any longer, OData offline only provides you a persistent cache, where OData documents (responses or requests) can be stored.
Thanks for the information Marvin. Can you please give more information the OData App based on REST APIs. How it works ?
- Midhun VP
What exactly you want to know?
The REST API got introduced already in SUP 2.2 and was also available in SMP 2.3. Because the old header variables are still valid with SMP3, there is no need for a huge migration and you can continue using apps which were working on SMP 2.x (REST API) without any further effort.
I plan to write a Best Practice blog post, on how to model an OData app. If I find some time I will do it...