Mobile application development and administration settings allow you to decide when and how to synchronize and refresh data.
Scenario | Strategy |
---|---|
Data changes irregularly in the enterprise information system (EIS), and data is noncritical. | Either:
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
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. SAP Mobile Server then sends notifications
to registered device clients, and optionally forces 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. SAP Mobile Server forces synchronization with registered devices. |
EIS data changes frequently. | Either:
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 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 "Immediately update the cache" policy when defining the MBO operation. |
A mobile application supports thousands of individual users, each of whom has a set of user specific data. | The MBO developer uses system
personalization keys that are used as client parameters ("username"
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 SAP Mobile 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:
|
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. SAP Mobile 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. |