Synchronization Scenarios and Strategies

Mobile application development and administration settings allow you to decide when and how to synchronize and refresh data.

The following table describes strategies to consider when designing and developing your mobile applications. Since most mobile applications include several (if not many) MBOs, you will combine various strategies.

Synchronization and data refresh strategies and examples
Scenario	Strategy
Data changes irregularly in the enterprise information system (EIS), and data is noncritical.	Either: Unwired Server initiates a data refresh once a day at off-peak hours that invalidates and refreshes all MBO data, or The MBO belongs to a synchronization group that includes a daily interval. For example, an organization bulk-loads data by performing a data refresh at the end of the work day. Field service personnel filter an attribute and synchronize (synchronization parameter=region) at the beginning of their day to synchronize only data of interest.
Clients must immediately synchronize critical EIS data changes.	You could either implement a cache update policy that immediately applies the results of the MBO operation to the CDB. Or, Implement a data change notification (DCN) that performs a data refresh of targeted MBO data. Unwired Server then sends notifications to registered device clients, and optionally force a synchronization to targeted devices. For example, administrators, professors, and others on a college campus have registered their mobile devices with campus police. When an emergency call from campus is received and entered into the system, a DCN updates the cache. Unwired Server forces synchronization with registered devices.
EIS data changes frequently.	Either: Implement an Unwired Server scheduled refresh that polls the EIS at specified intervals and updates the CDB when changes occur, or Define various cache groups for MBOs that refresh data as necessary. For example, set a short data refresh interval to receive up-to-date quotes for an equity tracking mobile application (stocks, bonds, and so on), which also allows users to buy and sell equities.
Device application users change EIS data frequently.	When defining MBO create, update, and delete operations, include a cache update policy for EIS modifying operations. Choose a policy that updates the CDB only with necessary changes. For example, a mobile application contains regional sales information. When you make a sale to a new customer, the MBO inserts a new row in the corresponding EIS table. To see changes related to your customers only (rows that contain your territory ID), use the apply operations parameter policy when defining the MBO.
A mobile application supports thousands of individual users, each of which has a set of user specific data.	The MBO developer creates personalization keys that are used as client parameters (user_name and password), which are validated by the EIS. For example, a mobile application used for retail sales maintains login information for validated customers that provides access to account information, shopping cart, wish list, and so on.
A mobile application has both static and changeable data.	The MBO developer configures two cache groups, designed to refresh Unwired Server cache (CDB) for each MBO based on the frequency of EIS data changes to which each MBO is bound. For example, a mobile application contains a sales_order MBO with a many-to-one relationship to the product MBO. While sales_order related data changes often, as sales are made, product data does not. The MBO developer establishes two cache groups: The sales_order MBO data cache updates hourly. The product MBO data cache updates daily.
A Human Resources department wants to implement a mobile application used to request and approve travel and expenses.	The message-based mobile application uses both replicated data (managed within the MBO) and nonreplicated messaging data. Unwired Server pushes changes/updates to device application users. For example, the application includes MBO bound data (calendar with requested dates, total cost, and so on). The messaging portion includes additional information including the message. Once requested and e-mailed to the manager, the recipient (manager) approves dates and expenses. The MBOs are updated in the EIS (replicated and synchronized), while the message is not.