Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
miltonc
Product and Topic Expert
Product and Topic Expert
OverviewBackendApp ConfigurationAndroidiOS

In this blog series, the Technology RIG team will go through the steps involved in migrating an MBO based mobile application built using SAP Mobile Platform 2.3 (hereinafter referred to as “SMP Server”) to an OData based mobile application built using SMP 3.0 and the newer harmonized OData SDK.  This blog series specifically deals with native applications and not hybrid applications.  When it comes to migration from SMP 2.x to SMP 3.x, there are 2 options available. The first option is to use the new OData architecture. This option is ideal for customers who want to move to the newer open standards based architecture in SMP 3.0. The second option is to use the MBO runtime that is shipped along with SMP 3.0.  This option is for customers who want to do a technical upgrade of their MBO architecture to take advantage of the extended maintenance cycle of the newer SMP version.

Migration options

Comments

Migration to OData architecture

Use of open standards based protocol

New OData architecture model

New SDK with harmonized API for online/offline apps

New client architecture for Hybrid apps based on Apache Cordova

Migration effort – medium to high as a rewrite of the client app is required

Upgrade to MBO runtime sidecar

Shipped with SMP 3.x as a separate install

Remain with the MBO architecture

Migration effort – low

Prior documentation on OData migration is largely focused on OData cache SDK and not the newer harmonized SDK.  However, there are plenty of similarities between the 2 approaches and a lot of the migration steps involved for an OData cache SDK are still relevant for a harmonized SDK migration.  While this blog focuses mostly on migration, the concepts surrounding migration can also be applied when developing a new enterprise application.

Why the need for migration?

Sybase Unwired Platform (hereinafter referred to as “SUP”) was developed by Sybase to provide a robust platform for building enterprise grade mobile applications.  A proprietary protocol was used to sync data between the various endpoints.  The Sybase Unwired Workspace was used to build an MBO model mirroring the schema that would reside on the device.  The premise is that only a subset of enterprise data needs to be sent to a mobile device due to the fact that a mobile device is less on resources like memory, processor power etc.   In addition, a consolidated database (named the “CDB”) was used to cache data from the backend to potentially reduce the load on the backend. After the SAP acquisition of Sybase, the SUP platform underwent major changes including rebranding it as SMP platform. Chief among the major changes was the transition to use OData – an open standards protocol.  Building mobile applications using the new platform is now a lot easier and more direct.  Another huge advantage of using the open standards was the fact that customers were no longer tied to a proprietary technology from SAP, thereby not tied to a specific vendor.  Furthermore, the architecture is a lot more scalable than the previous model. Without the intermediate consolidated database, customers no longer have to worry about another database that needs to be in sync.  There are quite a few blogs in SCN that talk in detail about the inherent advantages of the new architecture.

Here is a quick summary of the architectural differences between Offline OData and MBO model.

Offline OData

MBO

Comments

Client database created and populated with initial data in the SMP Server.  It is then sent down to the device

Client database created on the device.  Data is then sent down  to the device and inserted into the client database

Initial synchronization is based on the defining request in SMP 3.x. 

Application configuration file is used to customize the client database.  Also, specifies the type of data, refresh interval etc.

Client database is customized by making changes to the generated code…

It is recommended to upload a configuration file in SMP 3.x to optimize the SMP Server performance

If the backend OData producer does not support delta tracking, then the SMP Server tracks the changes so that only changed entities are sent down to the device

Changes are tracked by the consolidated database.  Only changed rows are sent down to the device

Application configuration file can specify if certain entitysets are shared across all users.  This allows SMP Server to track changes efficiently

No consolidated database.  However, SMP Server has ability to track the changes and store non-user specific data in memory

Consolidated database to ease load of the backend

SMP 3.x uses an in-memory cache to track changes and non-user specific data

Uses HTTP(S) protocol to transfer data

Uses SAP proprietary protocol to transfer data

No need to open any special ports

3rd party data integration (REST, SOAP, JDBC, JPA) is supported by the new SMP component Integration Gateway.  SAP Gateway handles integration of SAP systems.

Integration was part of the MBO design

All SMP Servers in a cluster belong at the same level

SMP Servers in a cluster are in a hierarchical pattern

Since all SMP 3.x Servers in a cluster belong at the same level, there is no concept of Primary Server etc.

Support for a variety of leading server OS/DB versions

Windows only as Server OS

In SMP 2.x you are limited to running the server on Windows based machines. SMP 3 can be installed on a range of DB/OS platforms  Check product availability matrix here.

In addition to architectural differences, there are differences in the MBO Object API and the harmonized OData SDK as well.  In many instances, there is not a direct one-to-one mapping.  However, most tasks that can be accomplished using the MBO Object API can also be similarly achieved using the harmonized OData SDK, albeit using slightly different methods.  Here is a quick summary of how certain methods / terminology in the MBO Object API map to harmonized OData SDK.

Harmonized OData SDK

MBO Object API

Comments

No generated code

Generated code creates the  attributes and CRUD operations for MBOs

Generated code available for Objective-C, Java for Android and .Net for Windows Mobile

Attributes and operations of entitysets discovered by requesting metadata document

MBOs are defined during design time

The metadata document is requested as an HTTP GET request every time the application opens in OData SDK

No pre-built queries exist

Pre-built offline findBy queries

Reading from local database is asynchronous

Reading from local database is synchronous

Callbacks are used with asynchronous READ operations in OData SDK

CUD operations against local database is asynchronous

CUD operations against local database is synchronous

Callbacks are used with asynchronous CUD operations in OData SDK

Migration components

As I had mentioned earlier, the new OData model does not have a consolidated database.  In addition, the proprietary synchronization protocol is replaced by the open standard OData protocol to transfer data between the backend and the SMP Server. The new architecture is relying on the backend exposing OData services. This includes creating OData delta tokens to optimize data transfer between the backend and the device.  To ease creation of OData Services, the SMP server includes the integration gateway component.

Creating an application definition in SMP runtime is very intuitive and straight forward.  An application definition in SMP Server can be created by simply knowing the OData Service URL and the authentication mechanism.

The newer harmonized OData SDK differs significantly from the older MBO SDK.  There are no generated code in the harmonized OData SDK. While the older MBO model was tied to the generated code (which in turn is based off the MBO model specified in the Sybase Unwired Workspace), the newer harmonized SDK is flexible enough to account for changes in the OData model.

SMP Server Components

Migration effort level

Reason

Integration Gateway

Medium -> High

Developer is now in charge of creating the OData Service and the delta tokens associated with data transfer.

SMP runtime

Low

Creating application definition in SMP runtime is intuitive and straight forward.

Harmonized SDK

High

Differs significantly from previous MBO SDK. Requires significant rewrite and in some cases it might even be better to redevelop the mobile application.

SAP Components

Migration effort level

Reason

SAP Gateway

Medium -> High

Developer is now in charge of creating the OData Service and the delta tokens associated with data transfer.

What this blog series covers?

This blog series would only cover the native harmonized SDK component of the migration process. There are already quite a few “How To guides” that talk about Integration Gateway and the steps involved in creating an OData Service.  In addition to Integration Gateway, you can also use “SAP Gateway” or any 3rd party vendor like WCF Data Services from Microsoft to create the OData Services.

The new harmonized SDK supports Windows Phone 8.1, Windows 8.1, iOS and Android. This blog series will describe the migration of native applications for iOS and Android. A lot of the concepts covered here are also applicable for new application development.

One of the cool features of the harmonized SDK is that the process of doing anything (for example, reading data from an OData Service) is the same across all platforms, except of course for the syntax and the language.  So, a developer creating an application for iOS could easily extrapolate his knowledge to create a similar application for Android and Windows.

The blog series will be divided into 2 branches.  One branch would target the iOS platform, while the other branch would target the Android platform.  However, as a developer you can gain valuable insights from either of these branches, since the concepts discussed would be very similar.

What does migrating a mobile application cover?

When it comes to migrating a mobile application, there are a lot of functionalities that need to be addressed.  Here are some of the functionalities that one would encounter when migrating any mobile application.  The blog series would cover each of these functionality and propose optimum solutions and step by step instructions to implement them in the new harmonized SDK.

Administrative functionality

Proposed solution

Reason

On-boarding process

Rewrite

Using the MAFLogon component greatly simplifies on-boarding process

Unregistering device

Rewrite

Once again, the MAFLogon components can be used to unregister a device

Push notification

Rewrite

Use APNS or GCM to send push notifications

CRUD operations

Proposed solution

Reason

GET operation

Rewrite

Harmonized SDK differences – concept of Store etc.

CUD operations

Rewrite

Harmonized SDK differences – concept of Store etc.

Custom queries

Rewrite – Not all custom queries possible

Complex custom queries may need to be revisited

Batch processing

Rewrite

Transaction support needs to be built in the backend

Multi-level inserts

Rewrite

Support in Integration Gateway is not available

Other operations

No workaround

No workaround in offline harmonized SDK

Synchronizing data

Rewrite

Harmonized SDK differences – concept of Store etc.

User Interface

Proposed solution

Reason

Binding data to user controls

Manipulating data objects…

id<SODataEntitySet>  object returned from QUERY operations different from MBO model

In the upcoming blogs, we will look into each of the functionality described above and go through the process of migrating it in detail.  We will provide step-by-step instructions on how to achieve the functionality using the new harmonized SDK.  As I had mentioned earlier, we will have 2 branches of the migration series.  One branch targeting iOS platform and the other branch targeting Android platform.

Next Topic: Migration of MBO Applications to Offline oData Applications - The MBO Model Due to the inherent differences between MBOs and the OData standard, a direct mapping between respective features cannot be achieved. We will share screenshots of the MBO Model we used as base and details on how to create OData model in SAP Gateway to expose the same SAP backend as OData services.

Hope to see you in our blog series.