Data Sync Types¶
Data synchronization is available with the following functionality:
- Merge data by pulling data that is on the device but not in the cache, to the cache and vice versa
- 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 data from the cache
- Push data in the cache to the device
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.
For all the syncs in general, the VOSS-4-UC system builds up the lists of entities from both VOSS-4-UC and the device (for example Unified CM) for comparison. The field that is used for this comparison is the key for the device entity, which is typically the unique identifier for the record in the device we that are syncing with. For example, for Unified CM, the identifier is the pkid which is the internal Unified CM database id.
In the case of subscribers, a sync will build up the list of device/cucm/Users
in VOSS-4-UC and then request from the Unified CM the lists of users it currently has
for the comparison. The differences in the lists are then handled according
to each sync type.
Details of the sync types are listed below:
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, if new data is added to the Unified CM so that the VOSS-4-UC
system data state for a Unified CM
device/cucm/Userdoes not show instances that are shown on the Unified CM, pull data synchronization synchronizes the system data with the Unified CM data. For example, a user’s Department may be updated on the Unified CM, but this update will only show on the system after Pull from Device synchronization. If a user resource is created in Unified CM but not in VOSS-4-UC, this will add thedevice/cucm/Userinstance into VOSS-4-UC at the level the pull sync was run from, for example at the customer level. - In the case where you delete 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 will
remove 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 will remove the
device/cucm/Userrecord in VOSS-4-UC.
If you are pulling device data, for example LDAP users from an LDAP device, the results returned to VOSS-4-UC are dependent 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, then an appropriate error message is returned.
- For example, if new data is added to the Unified CM so that the VOSS-4-UC
system data state for a Unified CM
Push to Device - The VOSS-4-UC system data state is the master and devices are synchronized with it.
- Where you delete device data from VOSS-4-UC so that the key is in the ‘device’ list but it is not in the VOSS-4-UC list, for example deleting a user in VOSS-4-UC, this will remove the user from Unified CM to match the user not existing in VOSS.
- If new device data is added to the VOSS-4-UC system data so that the resource
shows instances that are not shown on the device, push data synchronization
synchronizes the device data with the VOSS-4-UC system data. For example,
adding a
device/cucm/Userinstance to VOSS-4-UC and running a Push to Device sync will add the user record to Unified CM.
Keys found in both lists are ignored, for example no updates are made for existing records in either direction. So in the
device/cucm/Userexample, 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 Push to Device sync.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/Userrecord 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/Userrecord 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/Userexample, 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.- 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
Change Notification Sync - A pull sync of changes stored in the local collection that is updated by the Change Notification Collector service.
For more details on CNF, refer to the relevant CNF topics in the Data Sync chapter of the Core Feature Guide.
Purge Local Resources - All resources or instances of device information that exist in the system will be deleted. However, the entities in the device will not be deleted. This option is typically used when cleaning up the system.
Note
Bear in mind that with the above keys list sync logic, in the case of a reversion of the Unified CM to restores/inactive partitions, the relevant pkids might be different in the end state than they were at the last time VOSS-4-UC was in sync with Unified CM before the restore - especially if there was a lot of testing in between.
What this means practically is that there could for example be a user with the same username in both VOSS-4-UC and Unified CM, but if that user’s pkid in Unified CM is now different to the one that VOSS-4-UC holds from previous syncs or interactions, then the users will be seen as different even though the usernames are the same.
