Troubleshooting

Depending on the configuration, vault replication can be somewhat complex to troubleshoot. The following are some guidelines to assist you in handling typical issues.

It is important to isolate what part of the replication process is not running properly. Reviewing the Replication Transactions and Replication Transaction Log is your first step to diagnosis.

• If replication transactions are not being created for a file, either an event to trigger checking of the replication rules has not occurred, or the file does not match the criteria set for any active replication rule. Another rare potential cause is that one or more of the vault servers have not been upgraded to the same Aras Innovator version as the main server.
• Confirm that the installed version of Aras Innovator on each vault server is the same Aras Innovator version as the main server.
• Determine the rule which should have triggered a replication transaction and confirm it is Active.
• Confirm the file exists in the Vault where that rule is defined, and matches a file type in the File Type Filter for that rule, if any are specified.
• Confirm that a copy of the file does not exist on the vault(s) to which the file should replicate.
• For an onChange rule –

The most common reason for an onChange rule not to execute is that file was saved to a vault which does not have a matching onChange rule. Based on the User who saved the file, confirm a matching onChange rule exists on the Vault for that User’s Default Vault.

• For an onDemand rule –

The most common reason for an onDemand rule not to execute is that the file was retrieved for the user from a different vault than one with the rule. Aras Innovator gets the file based on where the file exists, and selects the vault based on the Read Priority, then Default Vault of the user, or from any other vault. So if the file is retrieved from a vault which does not have an applicable onDemand rule, instead of another vault with such rule, no replication transaction is created.

• For an onEvent rule –

Confirm that the method written to call the replication request actually executes. If so, confirm that a copy of the file with the file ID specified by the method exists on the vault with the onEvent rule. This may be done by viewing the file as a user configured with that vault as its highest Read Priority, then noting the vault which actually returned the file through the URL of the viewer, or by an AML nash or other query of the Located relationship(s) for the file.

If all immediate, scheduled and delayed replication transactions are not executing, even though they are due to run, the replication transaction thread is not running. Getting it to run depends on how it is configured to run. In all cases, confirm that the parameters for running it are correct. Common errors are the database is a different name, or the user ID does not match one in Aras Innovator. If the internal process is used, either the replication.config file is not correct, or not in the right location, or the global.asax was not modified as directed to run the replication process thread.

If some replications do not start, and they are due to run based on the Not Before value, either the file is most likely claimed, or the replication thread has not yet run following passing the Not Before date/time, or another transaction is in the ‘pending’ (executing) state for that file during this replication iteration. Also, keep in mind the values chosen for max_batch and max_pending. No more than the max_batch count of transaction records are initiated in one thread cycle, and no more than max_pending transactions run at once, so several iterations over a period of time may be necessary to clear the transactions in queue. If the replication transaction(s) not starting have a filter method set, check that the filter method is returning a result. If it is not returning a result, or errors out or returns an error, the replication transactions using that filter method remains in the queue. You may use the ‘Check syntax’ button when editing the method, add statements to activate debugging, or temporarily remove the filter method from the replication rule to determine if the problem is due to the method.

If all manual replication transactions do not start, the way you are calling the method must have an error. Create a simple temporary method like shown in the Programming Notes to confirm you have the correct replication settings, and once that is confirmed, debug the rest of your code.

Reasons for some Manual Replication Transactions remaining not starting are similar to that for Immediate/Scheduled/Delayed transactions. The most common would be the file being claimed. Refer above.

If replication transactions fail to complete, the replication transaction records or replication transaction log should indicate if the specific transaction was discarded or failed, due to a copy already existing on the target vault, or the filter rule not returning a ‘1’, or the file no longer existing on the source vault. The Status and Message properties for the transaction indicate why the transaction did not complete. Regularly review the Replication Transaction Log and look for problems and similarities in the transactions that do not complete, to determine if they are acceptable, or if something must be modified in your vault replication configuration.