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. This can then be used to compare with the number of expected records. The following conditions must be met to enable a count of replicated records:

• 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 (that is, are not deleted) in the target system or output files.

Once 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 will not be counted. Then, when the replications is run, it will be subtracted again from the count since the delete is replicated.

It is best to run the Synchronize Record Count action shortly after a replication finishes and before source data changes. This also assumes the data did not change during replication. Also, it should be run in a quiet period, and that to match, the replicated data must have been ingested into the target system.

Resetting a replication also impacts the use of this feature. Doing a reset will back out any creates that happened after the time being reset to. Also, If any reset is done to a replication set or replication set business class, and the target system is not cleaned up, there can be a mismatch. An example:

Assume you run several replications, then delete a record, then reset the replication set business class (without replicating the delete), and then replicate again, If the target system was not cleaned up after the reset and before replicating, then the target system will still have the deleted record. The first replication that happened after the reset was not incremental and thus only sent records that were not deleted. Deleted records are only sent on an incremental replication.