Principles of MBO Modeling

Understand key concepts required to develop an efficient data model.

	Design the MBO model based on mobile application requirements, not on the EIS model.
	Design and implement an efficient data-retrieval API for your EIS to populate the MBOs in the cache, and return only what is required by the MBO.
	Using existing EIS APIs for data retrieval simply because they already exist is inefficient because the EIS-model APIs were likely created for other purposes, such as desktop applications, making them inappropriate for mobile applications.
	Each MBO package is a client-side database. See MBO Packages.
	Do not put more than 100 MBOs in a single package. Instead, use multiple packages. Managing Project Size.
	When modeling the MBO, remove unnecessary columns so they are not loaded into the Unwired Server cache (also called the cache database, or CDB). If you cannot remove these columns, use result-set filters to remove columns from the EIS read operation and to customize read-only data into a format more suitable for consumption by the device.

MBO Consumption

MBO data is consumed by the mobile application and has a direct impact on its performance. The mobile application operates around the MBO data model, and an inappropriate MBO data model impacts not only mobile application development and maintenance, but synchronization performance and reliability.

When defining the MBO data model:

Understand the requirements of the mobile application.
Ensure that it allows the mobile application to efficiently satisfy functional requirements.
Keep in mind that mobile devices, including tablets, are limited in terms of resources and capability. In most cases, it is inappropriate to make the EIS business object model available to the mobile application to use. While doing so may save time during MBO development, it can lead to extended testing and tuning, and potentially frustrate users.

MBO Read Definition

An MBO definition is derived from the result of a read API provided by the EIS, for example, a SQL SELECT statement. This API is usually developed specifically for mobilizing the data to be consumed by the mobile application. The API must be as efficient as possible to minimize impact to the EIS. While Sybase Unwired WorkSpace provides an easy way to consume existing back-end APIs, define the MBO based on application need instead of what is already exposed by the EIS. For example, in most cases, reusing an API developed for a desktop application is not a good choice for the mobile application.

To evaluate if an existing API is sufficient, consider whether it:

Returns as close to what the mobile application requires for the MBO.
Fills the CDB with as few interactions as possible that satisfies the data freshness requirements of the mobile application.

Result-Set Filters

If the EIS API returns more than what the MBO requires, use a custom result-set filter to remove unnecessary columns (vertical) or rows (horizontal). While a filter adds a certain amount of overhead, it is more efficient than moving redundant data through the mobilization pipeline and consuming resources on the device.

A result-set filter does more than remove columns; you can customize it to format read data, making the data more suitable for mobile application consumption. For example, some EISs store information as strings, which when converted to numeric values, reduces synchronization size and causes a mismatch between datatype and usage.

Managing Project Size

An Sybase Unwired WorkSpace project that contains many MBOs (hundreds), or trying to access the project from poor performing environments, for example from a virtual machine (VM) can lead to poor Sybase Unwired WorkSpace performance when editing the project.

A best practice is to separate the MBOs into different projects then deploy them into a single application. This practice also makes MBO development easier. For example, the developer need not search hundreds of MBOs to find a particular MBO to view or edit. In cases where it is not possible to split large numbers of MBOs into separate projects, try either:

Accessing the project from a personal computer that provides good performance, or
Modifying Eclipse startup options to increase the stack and memory (heap) size. For example:
```
-Xms1024M -Xmx1152M -XX:MaxPermSize=512M  
```

MBO Packages

A package translates to a database on the device with MBOs as tables. Updates to MBOs within the package can occur within a transaction on the device. In other words, a package defines a functional unit with multiple object graphs of MBOs. For convenience, the developer can put unrelated MBOs into a single package, however when the number of MBOs becomes large, it creates a maintenance problem. Changes to one set of MBOs impacts all others as the package needs to be redeployed. During deployment, the cache must be refilled.