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..

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.