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.