[Index]
Model: data/DeviceChanges
VOSS-4-UC Change Notification Feature
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).
VOSS Automate Change Notification Feature
Full HTML Help
This section provides more details on the functionality of the Change Notification
Feature (CNF) components in VOSS Automate.
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.
A Model Type List (MTL) can be set up and selected to be associated with CUCM change
notification collection. This list allows a user to whitelist/blacklist certain model types
from the Call Manager change notification collector service so that change notifications
which are not in the MTLs do not accumulate and possibly trigger the maximum changes counter
which prevents any new changes from being collected.
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 Automate 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 check box.
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).
Used (per device) for configuring the change notification collector process & for monitoring unprocessed change notifications
Model Details: data/DeviceChanges
- An asterisk * in the title indicates the field is mandatory.
- If a field has a default value, it is shown in the Description column.
- If the field type is an array, the Field Name has a .[n] suffix, where n is the array index placeholder.
- Object and array field names are listed to provide context. If a field belongs to an object or an array,
the full field name is shown in dot separated notation.
|
Device ID *
|
The resource ID of the associated device
|
- Field Name:
device_id
- Type: String
|
|
Device Name *
|
The name of the associated device
|
- Field Name:
device_name
- Type: String
|
|
Device Type *
|
The type of the associated device
|
- Field Name:
device_type
- Type: String
|
|
Last Collection Time
|
The last time the associated device was checked for changes
|
- Field Name:
last_collection_time
- Type: String
|
|
CUCM Cluster Notes
|
CUCM Cluster Notes Field
|
- Field Name:
notes
- Type: String
|
|
Pending Change Notifications |
Pending changes for the associated device
|
- Field Name: changes.[n]
- Type: Array
|
|
|
Model Type * |
The model type of the pending changes in this section
|
- Field Name:
changes.[n].model_type
- Type: String
|
|
|
Add Count |
The number of pending add changes
|
- Field Name:
changes.[n].add_count
- Type: Integer
|
|
|
Update Count |
The number of pending update changes
|
- Field Name:
changes.[n].update_count
- Type: Integer
|
|
|
Delete Count |
The number of pending delete changes
|
- Field Name:
changes.[n].delete_count
- Type: Integer
|
|
Polling Interval (seconds) |
How often the change collector service will check this device for changes (seconds) Default: 300
|
- Field Name:
settings.polling_interval
- Type: Integer
- Minimum: 300
- Maximum: 7200
- Default: 300
|
|
Enable Change Collection |
Tick to enable change collection for this device Default: True
|
- Field Name:
settings.cnf_enabled
- Type: Boolean
- Default: True
|
|
Model Type List |
Reference to a list of model types to be included or excluded for change collection.
|
- Field Name:
settings.model_type_list
- Type: String
- Target: data/ModelTypeList
- Target attr: name
- Format: uri
|
|
|
Add |
Do not collect "add" changes.
|
- Field Name:
settings.ignored_operations.add
- Type: Boolean
|
|
|
Update |
Do not collect "update" changes.
|
- Field Name:
settings.ignored_operations.update
- Type: Boolean
|
|
|
Remove |
Do not collect "remove" changes.
|
- Field Name:
settings.ignored_operations.remove
- Type: Boolean
|
|
|
Displayed Model Types |
These model types will be displayed un-grouped in the pending changes section
|
- Field Name: displayed_model_types.[n]
- Type: Array
|
|
|
|
Model Type |
The model type that will have counts displayed in the pending changes section
|
- Field Name:
settings.displayed_model_types.[n].model_type
- Type: String
|