Validating replication set record counts

For a limited set of business classes, you can obtain a count of the records that were replicated for the business class. You can use this count to compare the actual number of replicated records with the number of expected records. To enable counting of replicated records, ensure these conditions are met:

• The replication set cannot be based on a business class with an indicator field.
• The replication set must be active.
• The replication set must be defined as Current Data replication, that is, not the replication of audit data.
• The replication business class must have been initially replicated or the Disable Incremental Replication field has not been selected.
• The replication set business class must have a create stamp and an update stamp.
• The replication set must not include any related replicates.

Any replication sets valid for this feature that had been replicated prior to setting the enable.record.count.sync parameter value to true must be manually synchronized by running the replication set's Synchronize Record Count action. This action cannot run while a replication is active or unfinished and vice versa. The Synchronize Record Count action is a background action and must complete successfully for the Expected Number Of Records field value to be updated. The expected number of records should match the number of records that exist, which are not deleted, in the target system or output files.

After the value is synched up, replication moving forward should keep the value in sync. You can also rerun the Synchronize Record Count action to validate. When the expected number of records is set by running the Synchronize Record Count action, it is only expected to match the target system after a replication is done and if no subsequent changes have been made to the source data. For example, if a delete is done and the Synchronize Record Count action is run without a replication being run, that record is counted. Then, when the replications is run, it subtracts again from the count since the delete is replicated.

We recommend to run the Synchronize Record Count action shortly after a replication finishes and before source data changes. This action assumes the data remains unchanged during replication. Run the process during a quiet period, and ensure that the replicated data has been fully ingested into the target system.

Resetting a replication impacts the use of this feature. A reset backs out any records created after the specified reset time. If a reset is applied to a replication set or its associated business class without cleaning up the target system, data mismatches may occur.

For example, if you run several replications, delete a record, reset the replication set business class without replicating the delete, and then replicate again, these behavior occurs:

• If the target system is not cleaned up after the reset and before the next replication, it still contain the deleted record.
• The first replication after the reset is not incremental, so it only sends records that were not deleted.
• Deleted records are sent only during incremental replications.