Operation Cache Policies

Setting an operation cache policy for mobile business object (MBO) operations gives you more control of SAP Mobile Server interactions with the enterprise information system (EIS) to which the MBO is bound, and SAP Mobile Server cache (CDB) updates. Fine-tuning these interactions and updates improves both SAP Mobile Server and device application performance.

MBO operations perform specific functions based on their definition:

Read operation (MBO attributes, load arguments, and synchronization parameters) – the EIS operation used to define and initially populate the CDB (from the EIS) for the MBO. Also called a load operation.
Create, Update, Delete (CUD operations) – modify EIS data depending on the definition of the operation. SAP Mobile Server maintains a cache (CDB) of back-end EIS data to provide differential synchronization and to minimize EIS interaction.
While this type of bulk-fetch and CDB caching are effective in reducing the number of interactions required with the EIS, and work well in some other cases (where MBO data is occasionally updated in the EIS), performance suffers if changes are initiated from SAP Mobile Server (by way of MBO operations), or if changes are frequent.

When an operation is submitted from a device application to the EIS, the cache must be refreshed for those changes to be available to a client the next time the client synchronizes.
Entity Read operations – refresh a single instance of an MBO composite graph (MBOs in a composite relationship) in the SAP Mobile Server cache (CDB). This type of operation can only be invoked for Create and Update operations that use an "Immediately update the cache" operation cache policy.

Operation cache policies determine how the CDB is updated after an operation executes. The operation cache policy and option combinations from which to choose to associate with MBO CUD operations include:

Immediately update the cache with Apply merge of operation input/output – this can be used for CUD operations where the MBO attributes map one-to-one with corresponding values in the EIS (no EIS generated IDs or side-effects on MBO attributes). For example:
1. The MBO Developer edits the Contact MBO's officePhoneNumber attribute, and the Update operation requires SAP Mobile Server to send fname, lname, city, state, and so on attributes that have not been changed on the client.
2. SAP Mobile Server recognizes that only officePhoneNumber has changed, and updates the cache correspondingly if the EIS operation executes without error.
(Legacy) Apply results to the cache – used primarily to support Create operations where the EIS generates the business ID for the new entity. SAP Mobile Platform requires the EIS developer to provide a create method that returns all the attributes of the MBO that the SAP Mobile Server normally sees from the read/load operation. This allows SAP Mobile Server to insert the real business ID into the MBO instead of a temporary one manufactured on the client (generateKey) as a placeholder. When SAP Mobile Server synchronizes the newly created MBO back to the client, it contains the real EIS defined ID field, and the client can update its remote copy by matching the surrogate key.
Immediately update the cache with Apply output of ENTITY READ operation – applies to any operation type, and also applies to graphs of related MBOs and shared read operations. For example:
1. The MBO Developer wants to change the ShipDate attribute on the SalesOrder MBO for a customer in a SalesOrder -> LineItems object graph, then submit the Update operation.
2. The EIS recognizes that due to product availability, some of the line items cannot be delivered on that date, so only some of the LineItem MBOs are modified as a result.
3. SAP Mobile Server recognizes that the Update operation succeeds (but this is the "normal" Update operation that has not been modified to actually return MBO values, much less the whole tree of SalesOrder->LineItem).
4. SAP Mobile Server recognizes an ENTITY READ operation associated with the Update operation takes the SalesOrder.ID as input and executes the entity read operation that returns the updated SalesOrder and LineItems information from the EIS.
5. Using the shared read feature, SAP Mobile Server updates the cache for both parent and child MBO values in the graph.
Invalidate the cache – the cache is unaffected in terms of what is in the cache database (CDB), but SAP Mobile Server internally marks the cache partition to which the affected MBO belongs as invalid. The next time a client tries to synchronize values of this partition SAP Mobile Server refreshes the cache by performing the load operation. If the cache is very finely partitioned, this can be the equivalent to the ENTITY READ approach: apply the operation and then perform an EIS read to update the cache. If the load operation takes a specific ID and returns a single MBO record, then these are equivalent. If the MBO partition is larger scale (Customer by State for example), then a lot of MBOs are invalidated and the cache refresh (all customers in State=CA) is a more expensive operation.
None – the cache is not updated after an operation. If there is a one hour refresh policy, changes are not reflected in the cache (or the device) until that hour expires and SAP Mobile Server refreshes the cache. If the policy is DCN, the cache is not updated until the EIS sends a DCN message reflecting the changes.

When an MBO operation is called, its cache policy determines how operation results are applied to the CDB.

Other mechanisms used to update the CDB that are external to MBO operations, and not associated with operation cache policies include:

EIS-initiated DCN – an HTTP request to SAP Mobile Server, in which the DCN request contains information about the changed data, or the changed data itself.
Scheduled data refresh – SAP Mobile Server polls the EIS for changes at specified intervals.
MBO cache group – every MBO belongs to a cache group that specifies a cache refresh policy for every MBO in that group. Plan carefully to maximize cache group and cache policy efficiency. Examples include:
- A poorly designed MBO might have an operation with a cache policy that updates only the operation results to the CDB, but the MBO belongs to a cache group with an interval that refreshes the entire MBO on too short a schedule, minimizing the value of the cache policy.
- This same MBO properly designed might have a cache group that refreshes the MBO nightly, increasing SAP Mobile Server performance by deferring load from peak usage hours.