Before diving deep into the details of the migration, I 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 a Mobile Business Objects (MBO) based application connecting via SAP Mobile Platform (SMP) 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 offline mode. Just by hitting a synchronize button the online connection is made to SMP and the changes are transferred to SAP ERP. Sales Plus is available on the SAP Store and the Apple AppStore.
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 an 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.
Migration Tasks per Layer
Now let’s take a deeper look for each layer what a migration means in detail:
- In SAP ERP all Remote Function Calls (RFC) need to be replaced by a single SAP Gateway service. A great feature in the SEGW (Gateway Service Builder (SEGW) 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. CustomerSet –> ContactSet).
- 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 on hiw own 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 a 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, and OData Offline did the job. The reuse of msc mobile’s own Cordova plugins was no problem at all (e.g. separate plugin to handle material pictures synchronization with a separate file server).
But due to the fact that those offline capabilities were added recently (see required Supported Packages stated above), unfortunately some features are not supported yet:
- There is currently no possibility to use the 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 it is a bug. It’s working only with a single substringof statement. This is currently under investigation at SAP.
- 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.
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 former times it was a horror to do any change to the SAP interface in use, since this required touching the MBO data model, generate new code, embed this code, and then finally do the change in Cordova plugin and HTML / frontend layer. Now you can easily change the attribute in SEGW, regenerate Data Provider Class – that’s it!
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 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!
If you already migrated, too, or having a question to this migration topic, please feel free to write a comment below!
About the author: Thomas Weber, msc mobile
Thomas is working at msc mobile as Project Manager and Product Manager for Sales Plus for SAP ERP, a mobile sales solution based on the SAP Mobile Platform and SAP ERP. Before this assignment Thomas was in various positions at SAP, IBM, and other SAP consulting companies..