[Index]

Model: data/CacheControlPolicy

UC Application Data Cache

The UC Application Data Cache provides a mechanism to cache data from the UC applications for use in the VOSS-4-UC to improve performance. It is highly configurable to ensure the setup can be tailored to best match the solution needs.

A Cache Control Policy exposes various settings to control when:

• Instance data can be safely viewed from cache, and when data should be queried from the device.
• Reads are required before writing to a device.
• Reads are required after writing to a device.

Cache Control Policy

The Cache Control Policy is available only to a global administrator or higher, and allows for the customization and fine-tuning of the caching behavior of the system:

1. Read - When data can be read from the cache and when data should be read from the device. This is used when rendering a GUI (including a UC application entity) and defines the data that is returned via the HTTP GET API operations, unless they are explicitly overridden.
2. Read before Write - When device reads are required before writing to a device (for example, if a device can have its data modified by other means). This is used as part of an update transaction to compare the values we think exist on the device in comparison to those that do; to avoid any conflict or overwrite.
3. Read After write - When device reads are required after writing to a device (for example, if additional field values are set by the device after adding an instance, then the data state needs to be read from the device upon successful addition of instances). This updates the cache from the device after the add or update transaction completes - to have the latest information in the cache.

The System Default instance of data/CacheControlPolicy always exists and applies to a model by default. A Cache Control Policy can also be created per hierarchy level.

A Cache Control Policy can therefore be:

• applied system wide (default system policy)
• applied to all devices in the system (default device policy)
• manually overridden for specific API requests, for example:
  • /api/<device model type>/<pkid>/?cached=true will always return the cached version of an instance regardless of the cache control policy.
  • /api/<device model type>/<pkid>/?cached=false will always return the uncached version of an instance regardless of the cache control policy.
  • /api/<device model type>/<pkid>/ (without the cached parameter) will use the cache control policy to determine which version is returned.
• optionally assigned to specific instances in the system

The Cache Control Policy controls how data is read from the system:

• Cache only: Unless overridden within the request, instance reads via the API always return the cached version of data. There is no need for the client to query the uncached instance data.

• Cache then device: The API will return the cached data, the GUI will indicate that the data shown is cached and will automatically make an API call requesting non-cached data. It is up to external clients to query the data requesting non-cached data. If this option is selected, data is loaded into the system in two steps:

  1. Load cached data
  2. Load device data

  The 'cached' visual indicator is displayed until the second step is complete.

  The device data overrides the previously displayed data unless the user has made an input:

  1. The fields changed by the user will reflect the user's input and not the device data.
  2. Arrays are blocked for the duration of the device data loading (while the 'cached' flag is displayed) and the user can not add or remove elements until the device data loading completes.

  Data is validated constantly as displayed values change, and validation status always reflects the very latest state.

• Manual: Unless overridden within the request, instance reads via the API always return the cached version of data. An external client using the API needs to provide a button to allow the user to manually retrieve non-cached data.

• No cache: Unless overridden within the request, instance reads via the API always return the uncached version of data that is queried from the device. In this mode the GUI will not show any data until it is retrieved from the device.

For Relation model types, the relation's cache control policy will filter down to the joined device models. For example:

• If the cache control policy of a Relation is Cache then Device, any GET operations that do not specify the cached parameter will return a cached result. It then becomes the client's responsibility to make another request with cached=false.
• If the cache control policy of a Relation is Cache only or Manual, then any GET requests that do not specify the cached parameter, return cached data for all joined models.
• If the cache control policy on read is No cache, the Relation will always fetch the latest device data.

Add a Cache Control Policy

1. Choose the hierarchy level of the policy.
2. Choose Network Administration > Data Sync > Cache Control Policy to open the Cache Control Policy list view.
3. Click Add on the button bar to open the Cache Control Policy input form.
4. On the Base tab:
   1. Enter a Name and Description for the policy.
   2. Click Add adjacent to Assigned Models and select the required options from the Model Type, Model Attribute and Value drop-down lists respectively. The Model Type can be specified as a wild card in order to include all instances, for example device/cucm/*.
5. On the Default tab:
   1. Check or uncheck (as required) the Read Before Write, On Update check box, and Read After Write, On Add, or On Update check boxes.
6. On the Model Specific tab:
   1. Click Device Models and check or uncheck (as required) the Read Before Write or Read After Write, On Add, or On Update check boxes for the various models, such as CUCCX Models, CUCM Models, Webex Models and so on.
7. Click Save on the button bar when complete to add the Cache Control Policy.

Defines rules regarding when data is retrieved from cache or directly from a device

Model Details: data/CacheControlPolicy