MBO Keys

Understand the purpose of primary and surrogate keys in Unwired Server.



Unwired Server uses a surrogate key scheme to identify MBO instances. See Surrogate Keys.



The CDB uses a primary key (EIS business key) to uniquely identify MBO instances. The primary key locates instances in the CDB to compare with the corresponding instance from a cache refresh or DCN. See Primary Keys.



The CDB creates an association between the surrogate and primary keys. See Associating the Surrogate Key with the Primary Key.



Do not define a primary key for an MBO that is different from the EIS business key.



Do not define an MBO without a primary key, or an implicit composite primary key that consists of all generated columns is assigned.



Create an operation that returns an EIS business key (primary key) so the CDB can associate the newly created instance with the surrogate key.

Surrogate Keys

Each MBO instance is associated with two keys: surrogate and primary. The surrogate key scheme allows creation of instances on the device without having to know how the EIS assigns business keys. While business keys can be composite, the surrogate key is always singular, which provides a performance advantage. Unwired Server uses a surrogate key as the primary key for synchronization, and to keep track of device data set membership. It also serves as the foreign key to implement relationships on the device.

Primary Keys

Each MBO must have a primary key that matches the EIS business key. During data refresh or DCN, CDB modules use columns designated as the business key to locate the row in the CDB table for comparison to see if it has been modified. If the defined primary key does not match the business key, errors may result when merging the new data from the EIS with data already in the CDB. Additionally, an MBO without a primary key is assigned an implicit composite primary key consisting of all columns.

Associating the Surrogate Key with the Primary Key

The CDB associates the surrogate key with the EIS primary key:
  1. A row (MBO instance) from the EIS is assigned a surrogate key to associate with the business key or primary key by the CDB.
  2. An instance created on the device is assigned a surrogate key locally, and the CDB uses the primary key returned from the creation operation to form the association.
  3. In the event that the creation operation does not return the primary key, the CDB module identifies the newly created instance as deleted to purge it from the device.
  4. Eventually, whether through DCN or a data refresh, the created instance from the EIS is delivered to the CDB and subsequently downloaded to the device.

A drawback to this approach is that the newly created MBO instance on the device is deleted and replaced by a new instance with a different surrogate key. If DCN is used to propagate the new instance from the EIS, the mobile application may not be aware of it for some time. Depending on the use case, the momentary disappearance of the instance may not be an issue.