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. |
|
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.
- 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 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.
- 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.
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.