Sync Overview#
Overview#
VOSS Automate provides several features for keeping the system in sync with underlying UC applications. This allows for the configuration and management of the UC apps outside of VOSS Automate, when required.
Sync feature |
Description |
|---|---|
Cache control policy |
This VOSS Automate mechanism provides the ability to pull in the latest live data from the UC application(s) for the entity you’re viewing, or at the time that it’s needed - for example, before executing a change on that entity, to prevent any overwrite or setting conflict. Find out more about cache control policy behavior and configuration in the Data Sync chapter in the Core Feature Guide. |
Data Sync |
This workflow pulls the latest data from the UC apps and updates the VOSS Automate cache when ran adhoc, or via a schedule. This is typically used for processes such as 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 Automate. For more information on the sync behavior and configuration see the Data Sync chapter in the Core Feature Guide. |
Note
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 won’t handle.
When to use Data Syncs vs Cache Control Policy#
This section describes some prime use cases and guidelines for determining when a regular or scheduled sync might be required for an entity, instead of using the cache control policy.
Note
These scenarios assume some level of regular configuration being done to the UC apps directly, outside of VOSS Automate.
Adding/removing entities in the UC applications directly
If you’re adding or removing entitles, such as users or phones, in the UC applications directly, then a sync is required to pull in new entities or to remove existing entities.
Modifying key values that appear in the list views in Automate via the UC applications directly
If you’re modifying key values that appear in the list views in VOSS Automate via the applications directly, such as changing a user’s name, then an update sync may be required.
List view data is driven only from the VOSS Automate cache; thus, any updates made in the UC applications will not display in VOSS Automate until the entity is viewed in VOSS Automate (for example, opening that subscriber), or when an update sync is run.
Extracts run from VOSS Automate
Any type of extract that might be run from VOSS Automate, such as file dump, VOSS Automate Analytics, or billing feed, are based on cached data in VOSS Automate. Thus, 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 Automate.
External clients accessing VOSS Automate via the API
External clients accessing VOSS Automate via the API have the cached flag available to request VOSS
Automate cached data (cached = true), or to have VOSS Automate retrieve the latest
data from the UC applications before responding (cached = false). Thus, 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 made on the entity
Any other mods made on an entity, such as call forward on a line via the CFwdALL softkey, will be pulled in when the record is viewed, and so won’t 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.
Consider the Sync Hierarchy#
When running a sync, manually or via schedule, the hierarchy (customer or site) at which you’re running the sync determines where the items are pulled into. For example:
A sync at the customer level pulls data in at customer level
A sync at a site pulls data in at the site
For this reason, when setting up the sync, consider its purpose. If the items being pulled in need to be in a site, it may be more efficient to set the sync up at the site level, and run the sync at the site rather than syncing in at the customer level, and then having to move the various elements. This can even be done as a once-off sync, and using model type lists and model instance filters to grab the data relevant for the site.