VOSS-4-UC Change Notification Functionality

This section provides more details on the functionality of the Change Notification Feature (CNF) components in VOSS-4-UC.

Change Notification Collector

The data/DeviceChanges model has an instance per UCM cluster and will provide the data collector status and pending changes in the cache for that cluster. An instance of the model will appear for all UCM clusters whether change notification is enabled or not. It gives you access to:

• Base tab
  • Last Collection Time - time the changes were last collected from the device
  • Pending Change Notifications - a view of pending changes collected for different types of models and by type of change (Add/Update/Delete). By default, this is device/cucm/User, device/cucm/Line and device/cucm/Phone. However, these models are adjustable on the Settings tab. If additional model types to the defaults above are added to the list, these are also shown. The remaining model types are all grouped in a single row called Other.
• Settings tab
  • Polling Interval (seconds) (300-7200 seconds with default 300) - the duration for collection of changes from the device
  • Enable Change Collection - enable or disable the change collector for that device.
  • Ignored Operations - you can select certain operations (Add/Mod/Del) to not be collected. Typically you want to collect all changes; however this option can be used to ignore some changes for specific scenarios if needed (for example, you will only handle updates via the CNF sync).
  • Displayed Model Types - here you can configure which models you want to see summary stats for on the Base tab. You can add, remove or change models to meet specific needs (for example, deviceProfile for extension mobility profiles, remoteDestination for SNR remote destinations, and so on).

The data/DeviceChanges model should be included in menu layouts for roles that need access to this level of detail for the CNF syncs.

Change Notification Sync Type

When a Change Notification Sync type is used in a data sync, there are a number of differences in the sync behavior in comparison with a normal pull sync:

• A GUI portal rule on the Data Sync interface will change some of the settings visible on the Data Sync GUI interface when the Sync Type is set to Change Notification Sync. This selection hides settings that are not relevant and exposes new settings for this type only.

• Number of Changes to Process - This input field becomes available from the Data Sync interface. Leaving the input box blank or typing in 0 will mean the sync will process all the pending changes collected - subject to the selected model type list and Disabled Operations set up on the sync. If you enter a number, the sync will process that number of changes only and leave any additional changes in the change collection for the next sync.

  Typically this value should be 0 or blank, unless there is a specific reason to limit the number of changes to process, for example when managing how long the sync may run.

All other visible settings are the same as with a normal pull sync, for example, device filters, workflows, and so on.

When a sync runs (either a normal pull sync or a change notification sync), it will clear out the change notification collection of any model types and changes processed for that cluster.

The model type lists and disabled operations define which models and types of actions are processed in either a pull or a change notification sync:

• The model type list (if one is assigned) assigned to the sync will determine which model type changes will be processed from the collected changes (for example, device/cucm/User for user entities only).
• The Disabled Operations tab defines if any of the types of changes are ignored. For example, selecting Remove will ignore delete changes.

Pull Sync and Change Notification Sync details:

• A pull sync does not utilize the change notification collection as a source of data. However, it will clear the collection for the models types it processes.
  • A full pull sync (a pull sync without a model type list) will clear the change collection as part of the sync process since it is pulling all the latest information from the UCM.
  • A pull sync with a model type list defined (for example one that contains device/cucm/User) will clear the change collection of any device/cucm/User changes, since it is syncing all the user information anyway. All other model types and changes will be left in the collection.
  • If a pull sync is run with Disabled Operations selected (for example, Add is selected) this will process the pending changes for Update and Delete actions for any matching models. However, all actions for the matching model will be cleared from the cache, including Add actions.
• A Change Notification Sync utilizes the change collection as its source of information and will clear that changes from the change collection for any model types it is processing.
  • A full Change notification sync (CNF sync without a model type list) will process all the pending changes and clear the change collection (unless limited by a value in the Number of Changes to Process setting on the sync. Then only that number of changes will be processed and cleared).
  • A change notification sync with a model type list defined (for example contains device/cucm/User) will process all the pending changes for the device/cucm/User model type and clear those from the change collection.
  • If a change notification sync is run with Disabled Operations (for example, Add is selected), it will process the Update and Delete changes for the matching models. However, all actions for the matching model(s) will be cleared from the cache, including Add actions.

This sync behavior means that you may wish to set up multiple syncs for a cluster to handle different types of sync and sync schedules to meet your needs. Ensure that you generally have all the model types covered in your scheduled syncs if CNF is enabled, otherwise some changes may never be cleared from the change collection, thereby taking up space.

For additional considerations and information around sync setup best practices, see the Best Practices Guide.

VOSS-4-UC Setup to enable Change Notification

Enabling the Change Notification capability is completed on a per UCM Cluster basis. This can be done on the UCM Server configuration page for a publisher via the publisher tab and selecting the Enable Change Notification Sync checkbox. When selected and saved, the system will:

• Enable the data collector for that cluster
• Create a CNF sync type for the cluster
• Create a schedule for the CNF sync. The schedule will be disabled by default.
• These settings should all be reviewed, adjusted, or additional instances created to meet your needs. See further information in:
  • The Best Practices Guide
  • The System Monitoring Configuration section in the Advanced Configuration Guide on sync best practices for different scenarios and other considerations.
• A full sync with the UCM Cluster should be executed just before or after enabling Change Notification for the cluster. This can be part of changing the setting for an existing cluster or adding a new publisher. Currently, both actions will invoke a full sync of the cluster. However, if the sync is not completed during the add/modify of the publisher, then one should be initiated.

When CNF is disabled on the Publisher configuration page (or if the cluster is removed from the system), the following will occur:

• The auto-generated schedule that was added during enabling will be removed. Any additional custom scheduled added will not be removed automatically and should be removed before disabling the change notification for the cluster to avoid unnecessary syncs running.
• The auto-generated CNF sync type that was added during enabling will be removed. Any additional custom CNF sync types for the cluster added will not be removed automatically and should be removed before disabling the change notification for the cluster to avoid unnecessary syncs being set up.
• The data collector for the cluster will be disabled.

Note

If the collector is only disabled via the data/DeviceChanges model, then the schedules and sync will remain. This is the best approach if you need to temporarily disable the CNF sync (for example, for a maintenance window).