.. _data_sync:

.. rst-class:: chapter-with-expand


Data Sync Overview
------------------

.. _18.1.2|DOC-225:


Data on devices may be updated within VOSS-4-UC, or directly on
the device. For this reason, cached VOSS-4-UC data should be periodically 
synchronized with the data with the data on devices.


**Example**: 

* When an instance of a |Unified CM| is added to the system, its data is imported and cached. 
* When instances are added, updated, or deleted from the |Unified CM|, the cached data 
  in |VOSS-4-UC| becomes out of sync with data on the device.
* When deleting data from |Unified CM| before deleting it from VOSS-4-UC, 
  the system displays the following error: "The specified resource could not be found"
  
  This means the resource is out of sync, and |VOSS-4-UC| may need 
  to re-sync with |Unified CM| in order to delete it or update it.


The VOSS-4-UC data sync functionality allows you to dynamically synchronize 
cached |VOSS-4-UC| data with data on devices. The data sync instance
is associated with the connection parameters of a device type
in |VOSS-4-UC|.

Supported devices include:

* HCM-F (if installed) 
* Cisco Unified CM
* Cisco Unity Connection
* LDAP
* WebEx

Individual add, update and delete operations carried out by a data sync
instance can be disabled on the user interface. If no operation is selected,
the default behavior is maintained.


.. rubric:: Related Topics

* 
  .. raw:: latex

     Sync Overview in the Best Practices Guide

  .. raw:: html
  
     <a href="best-practices/best-prac-sync-overview.html">Sync Overview</a>

* 
  .. raw:: latex

     Data Sync Types in the Core Feature Guide

  .. raw:: html
  
     <a href="concepts-data-sync-types.html">Data Sync Types</a>



Data Sync Settings
...................


The table describes a number of key settings that are available for data sync:

======================== ======================================================
Model Type lists         Define the entities to pull in a given sync. For 
                         example: 
                         
                         * Only pull in ``device/cucm/User`` records from 
                           Cisco Unified CM.

Model Instance filters   Limit a sync to a subset of entities in a sync. For 
                         example: 
                         
                         * Pull in users with a primary extension starting 
                           with *1*. 
                         
                         A system-level administrator will need to expose 
                         this setting on the Admin Portal. 

Actions                  Select which actions are active for a sync (Add/
                         Update/Delete).

                         * Update requires more effort to run because this 
                           typically involves a GET API call for 
                           each record, which must then be compared to 
                           VOSS-4-UC data. 
                         * Add/Delete can be determined from the initial 
                           list API calls.

                           To save time on the sync, you may wish to disable 
                           Update if you only require Add/Delete. 

Quick Import             Uses the list API responses to update the 
                         VOSS-4-UC cache, and won't perform individual 
                         GET calls for each entity for the update.  
                         
                         Recommended when the list response contains all 
                         values for the entity, or where only the key 
                         settings must be updated.  
                         
                         Removing individual GETs speeds up the sync,  
                         since VOSS-4-UC is not waiting for the 
                         API responses when there are a many entities to 
                         update. 

                         This is useful if the list and GET responses are 
                         required, or if you only need the summary data 
                         from the list view.
======================== ======================================================



.. note::
   
   Quick Import is generally not recommended, and should be used only 
   for syncing ``device/cuc/ImportUser``. 
   
   However, *initially* there is an exception to the performance improvement 
   of a Quick Import sync with ``device/cuc/User``:
   
   * When quick import is turned on a sync that has previously run without it, dependent, 
     non-Import User model types use the LIST response data to compare with the resource data 
     that was originally saved using the GET response data.  
   * The data sync detects a change, and initiates a resource save for each instance. 
   * For ``device/cuc/User``, dependent import API calls are made, resulting in a long 
     sync time.
   * Once it completes, *subsequent* quick import syncs should show an improvement 
     over non-quick import syncs. When changing back to a non-quick import sync, the same
     effect would likely be observed.



Synchronous and Asynchronous Data Sync
.......................................

By default, a data sync is asynchronous; that is, other tasks can
be carried out while the sync is in progress. 

However, a data sync can be set to be synchronous so that a workflow step can, for example, 
wait for the sync process to complete.

Asynchronous imports initiated by a Data Sync are standalone transactions; that is, 
they aren't child transactions of the Data Sync execute transaction.
Synchronous imports initiated by a Data Sync are children of the Data Sync
execute transaction.







.. |VOSS-4-UC| replace:: VOSS-4-UC
.. |Unified CM| replace:: Unified CM