The Impact of Synchronization and Data Refresh

When designing and developing your mobile application solutions, consider the impact of various synchronization and data refresh methods.

Impact of Various Data Refresh Methods
Data refresh method	Implication
Data change notification (DCN)	Requires a developer familiar with the EIS from which the DCN is sent. Provides more flexibility than a scheduled refresh, but is more complicated to implement. HTTP GET methods are less secure than HTTP POST.
SAP Mobile Server scheduled data refresh	Easily implemented by the SAP Mobile Server administrator. Less targeted than DCN or a cache group. Uses more system resources since it must periodically query the EIS for changes.
Cache group	Easily implemented by the MBO developer. A cache group is a collection of MBOs to which a common refresh policy is applied.
Operation Cache policy	Easily implemented by the MBO developer. Updates the CDB for an EIS data effecting operation (create, update, or delete) based on the policy associated with the operation. For example, you could update a modified row or invalidate and refresh the entire MBO.
Load argument	Easily implemented by the MBO developer. Load arguments filter the EIS data and fill the SAP Mobile Server cache database (CDB) with a subset of data from the EIS. They can be used alone or mapped to synchronization parameters to control both data refresh and synchronization.

Impact of Various Synchronization Methods
Synchronization method	Implication
Initiated by SAP Mobile Server	Easily implemented by the SAP Mobile Server administrator. The primary consideration is balancing performance with resource usage when determining how frequently synchronization is initiated, and to how many registered devices: Download from Server – control when data is downloaded to remote devices. For example, if set to 10 minutes, the server notifies the client of data updates at most every 10 minutes, even if data changes more often. Device notifications – notifications continue at a predetermined interval until acknowledged by the registered device, even when devices are disconnected or out of range.
Initiated by the device	Options include: Filtering results – implemented by the MBO and device application developer. The MBO can be configured through load arguments and synchronization parameters to have the CDB maintain partitions for each user, resulting in a growing list of clients who synchronize a filtered data set. Custom listener – implemented to listen for messages sent by the notifier. When the listener receives a message, it can be programmed to initiate synchronization.
Defined during MBO modeling/design	Options include: Synchronization group – groups MBOs by synchronization needs. Synchronization tab – defines synchronization requirements for individual MBOs, including synchronization parameters.