.. _data_sync_types:

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

Data Sync Types
---------------

.. _18.1.2|DOC-225:
.. _20.1.1|VOSS-620:
.. _19.3.4-PB1|EKB-7436:
.. _21.1|EKB-7436:


VOSS-4-UC provides the following data sync types:

==========================  ====================================================
Data sync type              Description
==========================  ====================================================
Pull from Device            Available to all device types.

                            * Pull all data from the device
                            * Pull only the schema from the device (used for
                              LDAP)
                            * Pull data from the Change Notification Feature
                              local data collection

Purge Local Resources       Available to all device types.

                            * Purge data from the cache

Push to Device              Available only to Cisco Unified CM devices

                            * Push data in the cache to the device

Change Notification Sync    Available only to Cisco Unified CM devices
==========================  ====================================================



.. Merge data by pulling data that is on the device but not in the cache, to the cache and vice versa


.. note::
   A quick import option is available to fetch only summary data that is contained
   in a list operation response and not the data for all instances/fields. See Data
   Sync Overview in the Core Guide for details.


Generally, for all sync types, VOSS-4-UC builds up the lists of entities
from both VOSS-4-UC and the device, and compares them, using the key for the device
entity. The key is typically the unique identifier (ID) for the record in the
device we're syncing with. For example, for |Unified CM|, the ID is the *pkid*, which is the
internal |Unified CM| database ID.

For subscribers, a sync builds up the list of ``device/cucm/Users``
in VOSS-4-UC and then requests from the |Unified CM| the lists of users it currently has
for the comparison. Differences in the lists are handled according to each sync type.


.. rubric:: Related Topics

*
  .. raw:: latex

     Data Sync Overview in the Core Feature Guide

  .. raw:: html

     <a href="concepts-data-sync.html">Data Sync Overview</a>

*
  .. raw:: latex

     Change Notification Feature Overview in the Core Feature Guide

  .. raw:: html

     <a href="concepts-VOSS-4-UC-CNF-overview.html">Change Notification Feature Overview</a>



Pull from Device
..................

For sync type *Pull from Device*, the VOSS-4-UC resource is updated where the same key is
present in both lists. In this case, the device data is the master and the VOSS-4-UC
system model data is updated with the device data.

For example, let's say new data is added to the |Unified CM|, so that the VOSS-4-UC system data
state for a |Unified CM| ``device/cucm/User`` does not show instances that are
shown on the |Unified CM|.

In this case, a *pull* data sync synchronizes the system data with the
|Unified CM| data. For example, a user's Department may be updated on the
|Unified CM|, but the update only shows on the system after a *Pull from Device* sync.
If a user resource is created in |Unified CM| but not in VOSS-4-UC, this adds the
``device/cucm/User`` instance into VOSS-4-UC at the level the *pull* sync was run from,
for example, at the customer level.

When deleting a VOSS-4-UC resource from the device, so that the key is in the
VOSS-4-UC list but not in the device list, a *pull* sync removes the resource
in VOSS-4-UC. For example, if the resource is a user in VOSS-4-UC but not in
|Unified CM|, the *pull* sync removes the ``device/cucm/User`` record in VOSS-4-UC.

To restrict the number of records removed in VOSS-4-UC, ensure you have the
following named macro at the hierarchy where the sync takes place:

`PULL_SYNC_DELETE_THRESHOLD_<device_type>`

.. raw:: latex

   For details, see Pull Sync Delete Threshold topic in the Advanced Configuration Guide.

.. raw:: html

   <p>For details, see <a href="reference-macros-sync-delete-threshold.html">Pull Sync Delete Threshold</a>.</p>


When pulling device data, for example LDAP users from an LDAP device, the
results returned to VOSS-4-UC depend on the LDAP server configuration. For example,
if the returned results exceed the LDAP server configured maximum, and if the server
does not support paging, an appropriate error message is returned.


Push to Device
...............

Sync type *Push to Device* is available only to Cisco Unified CM device types.

In a *Push to Device* sync type, devices are synchronized with the VOSS-4-UC system data state,
which is the primary data state.

* When deleting device data from VOSS-4-UC so that the key is in the *device*
  list but not in the VOSS-4-UC list (for example, delete user in VOSS-4-UC),
  the user is removed from |Unified CM|. The user will not
  exist on the device or on VOSS-4-UC.

* When adding new device data to VOSS-4-UC so that the resource
  shows instances that are not shown on the device, a *push* data sync
  synchronizes the device data with the VOSS-4-UC data. For example,
  adding a ``device/cucm/User`` instance to VOSS-4-UC and running a *Push to Device*
  sync adds the user record to |Unified CM|.

Keys found in both lists are ignored. Existing records are not updated in either direction.

In the ``device/cucm/User`` example, if the same user exists on both VOSS-4-UC
and on |Unified CM|, no update occurs in either direction. Detailed settings
may still not match after a *Push to Device* sync.

.. important::

   When performing a *push* sync, it is important to consider data dependencies between
   different models.

   For example, data dependencies may exist between users and phones in the
   Cisco Unified CM. In this case, if a user is associated to a phone
   (via the associated devices on the user), you can't add the user
   if the phone does not yet exist in in Cisco Unified CM.

   On the other hand, for ownerID on the phone, pushing the
   phone first will fail since the user isn't in place.

   This might mean running the *push* sync multiple times so it
   loads in the required order, or you may need to modify data
   (such as removing device association) to allow the *push* sync to succeed.



.. note::

   The keys list sync logic described in this topic implies that in case of a reversion
   of the |Unified CM| to restores/inactive partitions, the end-state of the relevant pkids
   may differ to their state the last time VOSS-4-UC was in sync with |Unified CM| (before a restore),
   particularly if testing occurred in between. This means you may, for example, have
   a user with the same username in both VOSS-4-UC and |Unified CM|, but if that user's pkid in
   |Unified CM| now differs to the one in VOSS-4-UC from previous
   syncs or interactions, they will be seen as different users even though they have the same
   usernames.

.. * Merge with Device - This is a combination of pull and push data synchronization and takes place in both directions.
.. Merge data synchronization synchronizes data between the system and the |Unified CM| data without overwriting or deleting any data.

.. * If you create a resource where the key is in the 'device' list but not in the VOSS-4-UC list (for example, the entity is in |Unified CM| but not in VOSS-4-UC), then the VOSS-4-UC resource is created. For example, adding a user in |Unified CM| will create the ``device/cucm/User`` record in VOSS-4-UC after the merge sync.
.. * If you add to a device so that the key is in the VOSS-4-UC list but not the 'device' list (for example, the entity is in VOSS-4-UC but not in |Unified CM|), then the device resource is created.  For example, creating a ``device/cucm/User`` record in VOSS-4-UC will create the user in |Unified CM|.
.. Keys found in both lists are ignored, for example no updates will be made for existing records in either direction. So in the ``device/cucm/User`` example, if the same user exists in both the VOSS-4-UC and |Unified CM|  system, then no update occurs in either direction. In other words, detailed settings may still not match after a Merge with Device sync.




Change Notification Sync
.........................

Sync type *Change Notification Sync* is available only to Cisco Unified CM device types.

A *Change Notification Sync* is a pull sync of changes stored in the local collection that
is updated by the Change Notification Collector service.

For more details on Change Notification Sync, see the related topics in Data Sync section of the
Core Feature Guide.



Purge Local Resources
......................

In a *Purge Local Resources* sync type, all resources or instances of device information that
exists in the system are deleted. Entities in the device are not deleted.

..  note::

   The default *purge* syncs created when adding a CUCM, CUC, LDAP or CCX server
   type are disabled by default. To use the *purge* sync, the "Remove" check box
   must first be cleared on the "Disabled Operations" tab of the relevant sync.

This sync type is typically used when cleaning up the system. The system displays a warning
before executing an enabled *purge* sync.

See the following sample device type syncs:

* HcsPurge-{{CUCMHostname}}--{{CUCMClusterName}}-DS
* HcsUserPurgeDS-{{CUCMHostname}}--{{CUCMClusterName}}
* HcsPhonePurgeDS-{{CUCMHostname}}--{{CUCMClusterName}}
* HcsPurge-{{CUCXHostname}}--{{CUCXClusterName}}-DS
* PurgeUccx-{{UCCXHostName}}
* HcsLdapUserPurge--{{UniqueID}}
* PurgeSpark{{CustomerName}}







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