MBO Synchronization Parameters

Understand the role of synchronization parameters in MBOs.

	A synchronization parameter is also referred to as synchronization key. See Data Subscription.
	A set of synchronization parameters is sometimes referred to as a subscription. See Data Subscription.
	Synchronization parameters allow the user/developer to specify the data set to be downloaded to the device. See Subscribed Data Management.
	Use synchronization parameters to retrieve and filter data for the device.
	Understand how multiple sets of synchronization parameters or subscriptions impact the cache module to make sure it is a scalable solution.
	To increase the membership of the download data set, use multiple sets of synchronization parameters.
	To reclaim storage during runtime via exposed APIs, if needed, purge the collection of synchronization parameter sets.
	To retrieve data from the EIS, define synchronization parameters and map them to all result-affecting load arguments.
	Use synchronization parameters not mapped to load arguments to filter the data retrieved into the CDB.

Data Subscription

The mobile application uses synchronization parameters to inform Unwired Server of the data it requires. Instances of qualified MBOs that correspond to the synchronization parameters are downloaded to the device. The set of synchronization parameters creates a subscription that constitutes the downloaded data. Any changes to the data set are propagated to the device when it synchronizes. In other words, synchronization parameters are the facility that determines membership of the downloaded data set.

Data Retrieval

Synchronization parameters are used for data loading and filtering. When a synchronization parameter is mapped to a load argument of the load/read operation of the MBO, it influences what data is to be retrieved. In this capacity, the synchronization parameter determines what is loaded into CDB from the EIS. Not all load arguments influence the data to be retrieved. For example, a Web service read operation of getAllBooksByAuthor(Author, userKey) uses the userKey load argument only for authentication. Whoever invokes the operation retrieves all the books by the specified author. In this case, do not map a synchronization parameter to userKey. Instead, use a personalization parameter mapping to provide the user identity.

The key principle when mapping synchronization parameters to load arguments is to map all result-affecting load arguments to a synchronization parameter. Failure to do this results in constant overwriting or bouncing of instances between partitions in the CDB. Unwired Server uses the set of synchronization keys mapped to load arguments to identify the result set from the read operation.

Data Filtering

Synchronization parameters not mapped to load arguments are used to filter the data in the CDB. If the data in the CDB is valid, cache refresh is not required and Unwired Platform simply uses the unmapped synchronization parameters to select the subset of data in the CDB for download. Consider this data filtering example that uses the product MBO:

Data Filtering Example

Read Operation: getProducts(Category)

Synchronization Parameters: CategoryParameter, SubCategoryParameter

Mapping: CategoryParameter -> Category

Events:

Jane Dole synchronizes using (“Electronics”, “MP3 player”) as parameters. CDB invokes: getProducts(“Electronics”).
John Dole synchronizes using (“Electronics”, “Tablets”) as parameters.

CDB:

Uses an on-demand cache group policy with a cache interval of 12 hours.
For invocation one, a partition identified by the key “Electronics” is created with all electronics product. Unwired Server uses “MP3 player” as the selection criteria for the subcategory attribute and downloads only all MP3 players in the catalog.
For the second synchronization using “Electronics” + “Tablets”, since the partition identified by “Electronics” is still valid, Unwired Server uses “Tablets” as the selection criteria for the subcategory attribute and downloads only all tablets in the catalog.

Subscribed Data Management

Synchronization parameter sets are cumulative; every new set submitted by the application/user produces additional members in the download data set. You can take advantage of this to lazily add data on an as-needed basis. For example, a service engineer usually does not require all the product manuals associated with the assigned service tickets. Modeling the product manuals as an MBO that takes the manual identifier as a synchronization parameter enables the user to subscribe to a particular manual only when needed. The drawback to this approach is that it requires network connectivity to get the manual on demand.

It is important to understand the impact to the CDB for each additional subscription. Performance suffers if each subscription results in an invocation to the EIS to fill the CDB whenever the user synchronizes. For example, assume that the product manual MBO is in its own cache group with a cache interval of zero. The API to retrieve the manual uses the product manual id as the load argument which is mapped to the synchronization parameter. If the service engineer has subscribed to five product manuals, during each synchronization, the cache module interacts with the EIS five times to get the manuals. The solution is to use a large non-zero cache interval as the product manuals seldom change. Always consider what the cache module has to perform in light of a synchronization session.

Over time, the number of product manuals on the device can grow to consume significant storage. Through the exposed API, the application can purge the entire set of subscribed manuals to reclaim resources.