This lessons learned blog will describe how we migrated an application originally developed on SMP 2.3 and the MBO concept to SMP 3.0 and Offline Odata. 

Before diving deep into it, we first want to give you some context and background information. We at msc mobile have a product called Sales Plus for SAP ERP. It’s an MBO-based application connecting via SAP Mobile Platform to SAP ERP to enable sales representatives to do their daily business on a mobile device, either on tablets or smartphones.

So the user is able to see and manipulate all kind of relevant master data (Customers, Contacts, Materials, etc.) and transactional data (Sales Activities and Sales Orders) in an offline mode. Just by hitting a synchronize button the online connection is made to SMP and the changes are transferred to SAP. Sales Plus is available on the SAPStore and the Apple AppStore.

To enable cross-platform support, Sales Plus was designed with a container approach: all business logic is implemented with HTML5 and JavaScript (jQuery), whereas native code generated with SMP based on the MBO data model is integrated to handle synchronization and enterprise grade features, e.g. user and security handling. Apache Cordova enables the communication between the generated native layer and frontend layer.

SAP made a tremendous shift within their mobile platform’s technology stack. From SMP 2.3 to SMP 3.0 the entire stack was redesigned, from this MBO approach to a SAP Netweaver Gateway support model based on OData. With the brand new Support Packs (Server Runtime: SP05, SDK: SP04) SMP 3.0 enables offline OData support, which was the reason for us at msc mobile to decide to migrate the entire app.

Now let’s take a deeper look for each layer what a migration means in detail:

• In SAP ERP all RFCs (Remote Function Calls) need to be replaced by a single SAP Gateway service. A great feature in SEGW (Gateway Service Builder) is the creation of Entities and EntitySets out of predefined ABAP dictionary structures. Since all Sales Plus interfaces are based on those structures, it was very easy to generate the data model. Enhancing the data model with Associations provides the possibility to navigate between Entities (e.g. Customer –> Contact).
  Much of the ABAP code for creating, updating, and deleting Entities could be reused during redefining the corresponding methods of the generated Data Provider Class. The biggest challenge was to rewrite the ABAP code for getting EntitySets. In the MBO-based version SMP was fetching all necessary data for all mobile users based on a predefined schedule. The concrete data distribution was determined with synchronization keys. But in the context of SMP 3.0 and OData, each user is connecting to SAP directly when refreshing data. Therefore, the logic needed to be adjusted to get only the user’s data at each call.
• In SMP’s Gateway Management Cockpit the SAP Gateway service needs to be defined first. In the Administration console the app must be created using the Gateway service defined before (hint: select “Internal” to improve performance). After specifying all other values like Authentication etc. you could already save and close. In Offline tab you could provide additional settings to manipulate SMP’s offline behavior (when database is created etc.). But if you don’t differ from default values, there is no need to upload a settings file.
• In Cordova / native layer there was no need to change much. Just adding the required Kapsel plugins like LogonPlugin, EncryptedStorage, OData Offline, etc. did the job. The reuse of msc mobile own Cordova plugins was no problem at all (e.g. separate plugin to handle material pictures synchronization with a separate file server).
• In HTML / JS the entire frontend business logic could remain as is. Just the data retrieval needed to be adjusted. Instead of communicating with own Cordova plugins to get and send data, now everything can be done directly in JavaScript by doing HTTP-Requests against the OData services. All requests, either online or offline, have the same format. Therefore, the developer doesn’t need to go different ways depending on current internet connectivity. Dealing with Offline Stores (based on OData Kapsel plugin), the developer can trigger the data get (refresh) and data send (flush) manually. So the user still works offline all the time, until he/she clicks on synchronize to trigger the corresponding refresh and flush operation.

But due to the fact that those offline capabilities were added recently (see SP’s stated above), unfortunately some features are not supported yet:

• There is currently no possibility to use Kapsel Offline OData plugin in combination with Relay Server. Hence, a connection with VPN must be established to connect to SMP directly. 
• To enable searches we tried to combine several “substringof(‘search_term’, attribute) directives within one filter expression. Unfortunately, this is currently not supported or is a bug. It’s working only with a single substringof statement. 
• When trying to run a deep insert, you will fail. This must be done with a batch call.
• Some of you might know the “submitPending()” function from MBO-based native apps to identify instances to be synchronized. This is a concept not implemented yet. So all OData create / update / delete calls directly take effect in the local database, and therefore will be synchronized at next flush. There is currently no possibility to define which instances should be synchronized, and which should not.
• Another big advantage is the decreased load on the backend. A scheduled refresh of all data was leading to run both systems, SAP and SMP, with heavy load. Now with each user connecting directly to SAP via SMP Integration Gateway, flattens the load over the business day.
• In former times it was a horror to do any change to the SAP interface in use, since this required to touch the MBO data model, generate new code, embed this code, and then finally do the change in Cordova plugin etc. Now you can easily change the attribute in SEGW, regenerate Data Provider Class – that’s it!

I hope this gave you a good impression what it means to migrate an MBO-based app to SMP 3.0 using OData services. It definitively makes sense to switch to the new technology stack. 

In summary I can say, the entire migration went faster than initially planned. The Kapsel plugins are increasing the development performance by far. I am really excited what SAP will provide with the next SP releases. Looking forward to get Sales Plus running offline on Windows 8!