Resubmitting Failed Replication Transactions

This section describes the configuration and operational details of how failed replication transactions can be resubmitted. This feature allows recovery from the situation where for some reason the replication of files from one of the source Vaults to one or more of the destination Vaults fails. Such failures are expected occasionally in any distributed application, such as issues with Network Connectivity. Automatic, Manual, and Batch resubmissions are employed to recover from the failures. The total number of attempts actually performed is recorded in the Property labeled ‘Execution Attempt’ of the ‘Replication Transaction’ and the ‘Replication Transaction Log’ item types. The following are the details of the three recovery mechanisms that can be employed based on the nature and extent of the issue:

To work around failures in replication transactions caused by temporary conditions such as network errors, Aras Innovator can be configured to automatically resubmit failed Replication Transactions up to 5 times. To configure this setting, you must change the value of the MaxAutomaticReplicationAttempts Variable Item:

MaxAutomaticReplicationAttempts: integer value between 1 and 5 (The default value is 1)

Administrators may review the Replication Transaction Log Items for failures that could not be automatically resolved. After diagnosing and resolving the cause of Failures, the Administrator can manually resubmit any ‘Failed’ Replication Transaction Log Item as a new Replication Transaction using ‘Resubmit’ from the Action menu for the Replication Transaction Log Item. Replication Transactions can be manually resubmitted any number of times until the transaction succeeds, and the number of attempts is not restricted by the configured value of the MaxAutomaticReplicationAttempts Variable.

By default, resubmitting the Replication Transaction also deletes the existing Replication Transaction Log item. To retain this failure log, you must edit the RemoveReplicationLogOnRerun Variable Item and set the value to false.

RemoveReplicationLogOnRerun: possible values are true/false (default value true)

If batch resubmission is used, it is recommended that the Variable value remain ‘true’.

To allow the system to continuously attempt to recover failed Replication Transactions, the method ‘GroupResubmitReplicationTxn’ has been made available for use with the Aras Innovator Scheduler Service. By default, this method builds a list of failed Replication Transaction Log Items from the last 24 hours and automatically run the ‘Resubmit’ action against each of these transactions.

Due to the variable nature of how many replication transactions this method creates, it is recommend that you run this method during hours of low-usage of the system. The results of this method should be reviewed periodically to ensure it is not creating unwanted network traffic in peak usage hours.

Refer to the Aras Innovator - Scheduler Service documentation for information regarding the installation and configuration of the Aras Innovator Scheduler Service.

It is possible that the GroupResubmitReplicationTxn Method may not help in all situations, and may not be used in all installations. The GroupResubmitReplicationTxn Method could be customized to use different filter criteria for building the list for resubmission, but doing so requires that you include the testing of this Method as part of your acceptance tests after any changes to the system, like an upgrade or deployment of a new solution.