Private Transactional Data Loading

Use either pull or push loading strategies for private transaction data.

Pushing data from the EIS via DCN is preferable to pulling data from the EIS, since DCN with payload performs better than an on-demand/zero coherency window where changes are immediately applied to the cache. When using DCN, cache locking is done outside the scope of the synchronization so overall resource utilization decreases. DCN also allows for change detection and targeted change notification (TCN), previously called server-Initiated synchronization (SIS) without additional work.

Load via Pull


check

Partition per user using either the “Partition by requester and device identity” feature in the cache group policy, or a specific identity provided by the developer.


check

Use an on-demand cache group policy with a zero cache interval for consistency and high data freshness.


check

Use the "Immediately update the cache" cache policy if there are create operations that associate a surrogate key and a business key.


check

Use a notification MBO to implement TCN/SIS if required.


yield

Ensure that all members of a partition belong to only one partition.


yield

Ensure the EIS can support peak on-demand requests based on expected client load.


stop

Do not use a scheduled cache group policy.

Load via Push


check

Use parallel DCN streams for the initial load if there is a large user population.


check

Use SAP Mobile Server clustering to scale up data loading.


check

Use a single queue in the EIS for each individual MBO or object graph to avoid data inconsistency during updates. You can relax this policy for initial loading, as each instance or graph is sent only once.


check

Use a notification MBO to signal that initial loading is complete.


check

Adjust the change detection interval to satisfy any data freshness requirements.


check

Always use the "Immediately update the cache" cache policy for all operations.