Verifying Object Changes via AXL

Version 1
    This document was generated from CDN thread

    Created by: Michael Piskun on 31-01-2013 09:23:28 PM
    I recently stumbled across a neat little field in the device database called versionstamp. Everytime a device is updated via Tomcat or AXL, a new UUID is generated to flag that this field has changed - allowing for a quick method of determining whether record data has been updated since the last check.
    This versionstamp field is in none of the other main tables, including numplan and enduser.
    Has anyone managed to get a similar functionality out of other tables, verifying with a small amount of data, whether changes have been made to records in a table?
    The only other method I can think of is trawling through the audit logs, looking for lines like the following. This, however, does not log changes made via AXL. 13:07:03.453 |LogMessage   UserID : ccmadministrator  ClientAddress : 10.x.x.x  Severity : 5  EventType : GeneralConfigurationUpdate  ResourceAccessed: CUCMAdmin  EventStatus : Success  CompulsoryEvent : No  AuditCategory : AdministrativeEvent  ComponentID : Cisco CUCM Administration  AuditDetails :  record in table device with key field name = 012345678910 deleted  App ID: Cisco Tomcat Cluster ID:  Node ID: LABCCM01
    Any help would be appreciated.

    Subject: RE: Verifying Object Changes via AXL
    Replied by: David Staudt on 01-02-2013 11:44:18 AM
    The classic problem with using change timestamp fields is if the record gets completely deleted, a query like 'select * from table where timestamp > last_time_we_checked' you can't discover the deletion.
    UCM 9 and higher includes new AXL APIs for setting up change notification subscriptions (initial only for device/line/user) - prior to that, keeping large, dynamic data sets synced between UCM and apps has always been a very difficult, i.e. timed bulk polling.

    Subject: RE: Verifying Object Changes via AXL
    Replied by: Michael Piskun on 03-02-2013 04:41:43 AM
    Thanks for the response David! Given device/line/user are the bigest tables, its a good start.
    Initially, I was hoping to do a 'select pkid,versionstamp from x', which when compared against already syncronised data should be able to determine adds, deletions, and changes, without having to dump the entire table.
    Aside from this frustration, there are a couple of instances where you can change the object without the versionstamp being incremented (ie: removing the DN/device association from within the DN object CCMAdmin page), causing things to fly under the radar. This *would* have been picked up with a versionstamp in the numplan table.