Same MBOs for hybrid and native Apps

[Former Member]

Hi,

I just wanted to know, if it's common/possible to use the same MBOs for hybrid and native applications. The problem I'm facing is correct data limitation to the device.

Let's say I have a MBO based on the following data table with 1000 rows:

ID_Customer	FirstName	LastName	City
1	Jon	Test	Hamburg
...
1000	Ron	Pattberg	Berlin

Requirement: The device should show all customers for a specified city.

For native App: I create a synchronization parameter for the attribute "City". By setting the synchronization parameter to "Hamburg", only customers of Hamburg will be downloaded to the device.

For hybrid App: Since synchronization parameters are unavailable in HWC Apps, I need another mechanism for filtering data. So I create an object query findByCity for this MBO. The problem here: All customers will be downloaded to the device, and the object query just filters the data (or am I wrong?). In HWC examples, personalization keys are used in load arguments for filtering data. Mixing both synchronization parameters and personalization keys for native and HWC apps doesn't seem to work.

So is there a correct way to use one MBO in hybrid and native application or are the purposes of native and hybrid apps differing too much, that a single MBO can't fit both needs?

[Dan_vL · Accepted solution]

In your example above, only the rows for the city Hamburg would be sent to the Hybrid App. 

The following samples may be of some help.  They are available on the SUP Apps site https://cw.sdn.sap.com/cw/groups/sup-apps

MBOs and Hybrid Apps https://cw.sdn.sap.com/cw/docs/DOC-152083

Overview

This sample attempts to demonstrate and explain how MBO's are used with a hybrid app. Their usage within a hybrid app is slightly different than that when used from within a native application which contains a local database that occasionally gets synced. A hybrid app sends its requests for read, create, update and delete requests directly to the SUP server. Specifically this sample will examine:

• Cache groups (on demand or scheduled vs. online)
• Personalization Keys
• Accessing an Operation's Output Parameters
• How to change the back-end data source of a MBO from a database table to a REST service
• MBO relationships

Mobile Workflows in an Occasionally Disconnected Environment https://cw.sdn.sap.com/cw/docs/DOC-151623

Overview

This sample looks at how mobile workflows can be used when a mobile device's data connection is occasionally disconnected. Native applications can take advantage of the Object API, which has a full-featured set of functionality for the occasionally disconnected scenario, but mobile workflows also provide some support for an occasionally disconnected environment.

Fundamentally, native applications that use the Object API to access Mobile Business Object(MBO) data have a SQL database on the device that stores a subset of the data. Read, create, update and delete operations occur against the copy of the data stored locally on the device and are occasionally synced to the Consolidated Database(CDB) on the SUP server. See

Device Application Types and

Developer Guide: Android Object API Applications

for additional details on how to write native mobile applications that use the object API.

In contrast, a mobile workflow does not maintain a local copy of the full set of data on the device but it does send its requests to the SUP server through a queue so that create, update and delete operations can be completed and then when the device is online, they are processed.

Mobile workflows provide the following features for use in occasionally disconnected states.

• Notification or message inbox where items that require attention are stored.
• On-device cache which stores previously executed online requests for a configurable amount of time.
• Secure on-device storage which uses an API similar to HTML Web Storage.
• Asynchronous submit allows for Mobile Business Object (MBO) operations to be placed in a queue on the device which are processed the next time the device has a data connection.

[Former Member]

Hi Christian ,

For a HWC Application you need to place your MBO's inside Online Cache Policy. While for a native application its On Demand.

And when a MBO is inside an Online Cache Policy, you have to have an Argument propagated to an Attribute. In the above mentioned case, you can create an argument "City" and propagate it to your attribute - City (output).

It will automatically generate a findByParameter() Query which you can use in you HWC Application to filter the data.

Hope you find this useful...

Regards,
Dharmaraj

[Former Member]

Hi,

thanks for your answers and sorry for the late response. There sure are ways to model the MBO for both needs. It would be nice to model the MBO once and use it for HWC and native apps at the same time. So if I put the MBO in a online cache group, it cannot be used for native apps anymore.

I just wanted a recommendation, if in general, modelling MBOs for hybrid and native apps should be seperated. Modelling seperate MBOs for the same backend-data is surely possible, but quite redundant. Because needs differ between the type of application, one MBO for both types could be inappropriate though.