Overview

Aras Innovator has the capability to replicate vaulted files across multiple vault servers, allowing users to retrieve files from their local vault, or from another vault in an order of preference, if a copy exists there, rather than having to get the file from the vault it was originally saved. This capability was designed to work transparently to the user, with straightforward configuration by the administrator.

Vault Replication is available on servers with feature licenses only. This document outlines these features, how to configure them and how to use them.

• How to create and configure vaults for replication.
• How to create replication rules.
• Types of vault replication.
• Configuration settings for common use cases
• Programming notes

In Aras Innovator, there is no ‘master vault’. Files are uploaded to a specific vault based on a specific User’s selected Default Vault property. With the right permissions, a user can get a file from any vault.

Replication of a file can be due to when a user requests a file (a ‘get’), when the file is uploaded to the vault, or when other events occur and explicitly request a check for the need to replicate (programmatically through a call to a method) a file.

Since a file can now exist in multiple vaults, and a replication may not have occurred for a file which has been changed (either due to no rule triggering a replication transaction, the transaction being scheduled but not yet being run, or the transaction failing due to some reason), Aras Innovator keeps track behind the scenes of all vaults housing a file. It automatically locates a copy when requested from the users’ local vault, if it exists there, or finds it and delivers it from another vault.

Replication works in a multi-step asynchronous process.

First, an event triggers the Aras Innovator server to check if a file should be replicated, by checking the replication rules for a match. For each rule that matches, a replication transaction record is created, specifying the file ID, source vault, target vault, requested execution time, a ‘Filter Method’ and other parameters.

Next, the Aras Innovator server checks (at regular intervals determined by a configuration file through an internal thread, or through a process scheduled externally, or manually through a special call) to find queued replications due to run.

These transactions must meet a variety of conditions:

• The transaction is due for execution.
• The file exists and is not claimed.
• No other transaction is already executing for that file (which is a ‘Pending’ status in the replication transaction queue).
• File is absent in the target vault.
• Passes the test given by the filter method, if specified, by the initiating replication rule.

If any of the first three conditions are negative, the transaction is skipped but remains in the queue. If any of the last two are negative, the transaction is removed and logged as discarded.

For transactions that meet the conditions, the Aras Innovator server sends execution requests to the target vault servers.

These are acknowledged, processed by the vault server, and when complete a message is sent back to the Aras Innovator server to be logged. The Replication Logs should be reviewed regularly to determine and diagnose any problems that exist with the configuration.

During the process of replication, the replication transaction status is set to pending, and the file is temporarily claimed until the replication transaction completes or it fails.

When a user saves a file, it is always saved into the Default Vault defined for the user. When a user gets a file from Aras Innovator, the selection of which vault can be defined by a new User Relationship named ReadPriority. For any file retrieved, the vault with the lowest numeric value for ReadPriority with a copy of the file is selected to return the file to the user. If no vaults with a ReadPriority have the file (or none were defined), it is returned by the user’s Default Vault, or finally by any other vault having a copy of the file.