Sync Overview

VOSS-4-UC provides a number of features for the system to stay in sync with the underlying UC applications, thereby allowing for the configuration and management of the UC apps outside of VOSS-4-UC when required.

  • Cache control policy - this mechanism in the VOSS-4-UC system provides the ability to pull in the latest live data from the UC application(s) for the entity that you are viewing or at the time that it is needed, for example before executing a change on that entity; to prevent any overwrite or setting conflict.

    For more details on the cache control policy behavior and configuration, see the Data Sync chapter in the Core Feature Guide.

  • Data Sync - This is a workflow that will pull the latest data from the UC apps and update the VOSS-4-UC cache when ran adhoc or via a schedule. This is typically used for processes like overbuild to pull in the existing configuration from the UC applications or to pull in other changes made in the UC apps outside of VOSS-4-UC.

    For more information on the sync behavior and configuration, see the Data Sync chapter in the Core Feature Guide.

  • With the cache control policy in place, the need to setup and schedule sync regular syncs should aim to address any gaps that the cache control policy will not handle. Some of the prime use cases and guidelines on when a regular or scheduled sync might be required for an entity versus the use of the cache control policy are as follows (these all assume some level of regular configuration being done to the UC apps directly outside of VOSS-4-UC):

    • If you are adding/removing entities (e.g users, phones, etc) in the UC application(s) directly, then a sync is required to pull in new entities or remove existing entities.
    • If you are modifying key values that appear in the list views in VOSS-4-UC via the applications directly (e.g changing a user’s name), then an update sync might be required. The list view data is driven only from the VOSS-4-UC cache so any updates made in the UC apps will not be shown in VOSS-4-UC until the entity is viewed in VOSS-4-UC (for example, opening that subscriber) or when an update sync is run.
    • Any type of extract that might be run from VOSS-4-UC (file dump, VOSS-4-UC Analytics, billing feed, etc) would be based on the cached data in VOSS-4-UC. So a sync may be required if those capabilities are in use and any of the critical settings in those extracts are being managed outside of VOSS-4-UC.
    • External clients accessing VOSS-4-UC via the API have the cached flag available to request VOSS-4-UC cached data (cached = true) or to have VOSS-4-UC retrieve the latest data from the UC apps before responding (cached = false). So the presence of this external client does not require a regular sync to be run as it can (and likely should) request the latest data in any case depending on the use case.
    • Any other mods (e.g call forward on a line via the CFwdALL softkey) made on an entity will be pulled in when the record is viewed so do not necessarily require a sync.

For example, if the only concern is that when executing an update to an entity that the latest current settings are shown, then the cache control policy handles this without the need for a regularly scheduled update sync.

When the sync is run (manual or via schedule), the hierarchy that the sync is run on will determine where the items are pulled into. For example, a sync at the customer level will pull data in at customer level, while a sync at a site will pull data in at the site.

So when setting up the sync, consider the purpose: if the items being pulled in need to be in a site, it might be more efficient to set up the sync at that level and run it there, as opposed to syncing in at the customer and then having the move the various elements. This can even be done as a once-off sync and with the use of model type lists and model instance filters to grab the data relevant for the site.