The Log tab controls whether changes are logged to the CN_Log repository:
CN_Log_Changes - Specifies changes are to be logged to the CN_Log repository if Yes.
CN_Log_Group - Lists the applicable groups for which the changes are to be logged. If the user is not a member of any of the specified groups, the change is not logged. If left blank, then all changes are logged, regardless of who made the change.
CN_Log_In_Sync_Only – Change events are logged to the CN_Log repository only when the Staging record is in Sync with Production if Yes. This has the effect of only logging the set of changes when the Staging record is promoted to Production. Typically, the log messages are placed in the queue when changes are made to the Staging repository records and are soon dequeued and added to the CN_Log repository. Since the Change Notification cannot operate on Production repositories (due to triggers not being invoked during the promotion operation), delaying the dequeue and logging of change events provides a method of logging and reporting changes made to a promoted record. When a Staging record is promoted to production, its Record State will be changed to In Sync. At that point, any queued change events will be logged to the CN_Log repository. The next time a report export runs, it will pick up all of the changes made to the Production record since the last promotion. This assumes that the reporting is run after each promotion.
If a scheduled export is set up as a delta export on the CN_Log repository for events associated with the delayed sync option, all of the changes made to the record (with the final ones in the batch of records reflecting the final values) in the Production repository. The following table visually illustrates the events over a period of time:
| Event | Sync State | Change Notification Queue Dequeue Action | Attr A Old Value | Attr A New Value | Attr B Old Value | Attr B New Value | Production Report Attr A Old Value | Production Report Attr A New Value | Production Report Attr B Old Value | Production Report Attr B New Value |
|---|---|---|---|---|---|---|---|---|---|---|
| Record in Sync with Production | In Sync | Dequeue | one | one | a | a | one | one | a | a |
| Update Staging | Not In Sync | Hold | one | two | a | a | ||||
| Update Staging | Not In Sync | Hold | two | three | a | b | ||||
| Update Staging | Not In Sync | Hold | three | four | b | b | ||||
| Promote to Production | In Sync | Dequeue | one | four | a | b | ||||
| Update Staging | Not In Sync | Hold | four | five | b | c | ||||
| Update Staging | Not In Sync | Hold | five | six | c | c | ||||
| Promote to Production | In Sync | Dequeue | four | six | b | c |
As the table shows, once a record in Staging has been modified, its sync status indicates not in-sync with Production. Any changes made to the staging record that are queued to the Change Notification log would remain in the queue until the record is promoted. Once the record is promoted, all the queued change events would be dequeued and inserted into the CN_Log repository.
The Change Notification dequeue operation (which is launched every 5 minutes by default) is expected to run frequently enough that there would not be time for a staging record to have subsequent changes after it has been promoted, which would prevent the pending records from being dequeued.
Once the records have been stored in the CN_Log repository, a SQL-based delta export can extract the old value from the oldest new record and the new value from the newest new record for a given attribute to obtain an accurate picture of the changes of the records in Production since the last report was generated.
In order for all changes for a promoted record to be logged, it is essential that the Staging record not be modified before the dequeue operation has been able to retrieve all of the queued events for the record. This is best accomplished by either having the promotion operation run after typical business hours.
If a Staging record is promoted to Production multiple times during a single reporting period, the report will not identify the specific changes that were made for each promotion, only the changes made for all promotions since the last report was generated. If there is a requirement to report the changes for each promotion, the report must be run after each promotion (allowing sufficient time for all queued changes to be dequeued and logged).
CN_Log – Lists the records in the CN_Log repository that were generated for the
CN_Registry record being edited. Since the number of records is likely to be quite
large, it is not practical to view them in this list. To view the log messages, click
the Edit Link Table icon
on the far right of the CN_Log list toolbar.
The CN_Log tab will appear, showing only the log entries that were generated for the CN_Registry record being edited. The list displays the entries in reverse-chronological order, with the latest entry at the top.