.. _VOSS_CNF_overview:


Change Notification Feature Overview 
------------------------------------

The VOSS-4-UC interaction with the UCM Change notification sync has two
primary components:

*  Data Collector - collects the changes from the Cisco Unified CM and
   updates the VOSS cache on the configured frequency (defaults to every
   300 seconds).  This collector must be enabled to collect
   the changes, otherwise the sync will not process any changes.
*  Change Notification Sync - this is a type of sync that processes the
   changes the collector puts into the VOSS cache.  A scheduled sync
   should be set up and enabled so that the changes are processed within a
   reasonable period.  The sync can also be run adhoc if required around
   the schedule.  

The VOSS-4-UC data collector retrieves the change records from the Cisco
Unified CM on the configured interval. For example, this could be every
300 seconds (5 minutes) which is the default. When a Change
Notification Sync type is run, VOSS-4-UC processes the change records
collected. VOSS-4-UC then processes the records accordingly:

* Add - will do a GET API call to retrieve the full record and add it
  to VOSS-4-UC.
* Update - will do a GET API call to retrieve the full record and
  update the record in VOSS-4-UC.
* Del - will remove the record from VOSS-4-UC.

The efficiency on these Update syncs is because there is no need to do a GET
API call for every single record in the system - only for those that
changed. In large UC application installations, this can make a big
difference in Update sync times.

For example, with a data collector polling period of 300 seconds and a
CNF sync scheduled for every 24 hours, the process would work as
follows:

*  Every 300 seconds (5 minutes) the polling collector would get all the
   current changes from Cisco Unified CM.
*  This polling would repeat every 5 minutes - updating the VOSS-4-UC cache.
*  After 24 hours, the CNF sync would run and process all the changes
   VOSS-4-UC stored over that 24hr period.  The duration of this sync will
   depend on the number of changes to process, since each requires an AXL
   GET API request.

This type of sync, especially for updates, is far more efficient,
because a GET AXL request for every object in the system is not
required - only for those that changed in the time between syncs.

On a system with 10000 users for example, if 100 of the users were changed,
then only 100 GET AXL request are needed.  By contrast, a normal sync doing an
update would require 10000 GET AXL requests to update the same 100
users.

The VOSS-4-UC data collection can store up to 200,000 changes from a single
Cisco Unified CM Cluster. A warning is raised when 75% of
the data collection storage capacity is reached. When the 200,000 changes
capacity for a cluster is reached, a sync error occurs on the user
interface (see :ref:`errors-troubleshooting-CNF-processes`)
To avoid the sync error, we recommend always having a scheduled CNF sync
running on a regular basis based on your needs when Change Notification
is enabled.