How synchronize works

Sites synchronize with other sites in the realm by periodically writing and reading updated scenarios via a realm repository – a file share that is accessible to all sites. This file share is typically a true shared file system but could also be a replicated cloud file hosting service.

You can configure this synchronization to apply to all scenarios, or to only scenarios defined by a dynamic roll-up.

Note:

Dynamic roll-ups do not support the scenario Delete feature introduced in Release 16.2.1.

aPriori uses the realm repository to contain not only copies of the synchronized scenarios in .ap file format (the same as created by the aPriori Export command), but also site property files, log files, and other data to support the synchronization process.

A synchronization process running on each site determines when scenarios get written to and read from the realm repository. This timing is up to you and should be adjusted to your specific situation: too rarely, and the synchronization process may run too long. Too often, and your users might find that they constantly need to update certain components. There is no requirement that these processes need to run at the same time on the various sites.

Note:

Scenario synchronization works best when there is minimal overlap of the scenarios being manipulated at the various sites. Scenario synchronization does not enforce any restriction in this regard, and it makes reasonable assumptions to handle conflicts. But you must understand the synchronization behavior and institute best practices at each of your sites to coordinate work on the same components. In general, you should avoid having multiple people making changes to the same component at the same time. The basic rule for synchronization is “the most recent changes win”.

When the synchronization script runs on a site, it performs the following tasks:

Import scenarios: The process checks for EXPORTED and DELETE_EXPORT flags from other sites and imports the .ap file(s) for updated scenarios and removes deleted scenarios from the database. When the import has successfully completed, the process creates IMPORTED and/.or DELETE_IMPORT markers in its site folder on the realm repository to flag status. Note that if there is more than one flag for a given scenario and timestamp, the process logs a warning and proceeds to other scenarios without importing the problem scenario.  Note: If the source site is the last importer and it is allowed to clean all sites’ exports, then it will remove scenarios from the realm after import.

Export scenarios: The process finds any relevant scenarios on the site that have been updated (created or saved) or deleted since the last export. For each export marker it also creates an export .ap file of the scenario in the realm repository. The user defining the sync job specifies whether the job applies to updates, deletions, or both.  The process then creates a marker (an empty file) named EXPORTED in the folder to indicate that the scenario is ready to be imported by the other sites in the realm, or a DELETE_EXPORT marker for deleted scenarios. Scenario Sync also creates an XML file named apSyncMetaData.xml. (See Structure of the realm repository for details about how the realm repository is structured.) You can choose to synchronize all scenarios stored in the site database or limit it to the members of a dynamic roll-up. Note: Delete markers are not created if you define exports using roll-ups.

Clean-up completed exports: By default, a given site is responsible for removing files exported by that site. The process identifies any successfully completed exports by comparing the EXPORTED and IMPORTED flags for a given scenario. If a scenario with an EXPORTED flag displays IMPORTED flags for all the other sites in the realm, this indicates that the synchronization has successfully completed for all sites, and the folders related to that export are purged.

For performance tuning, sync jobs can also be configured to clean-up scenarios exported by all sites in the realm, or to not perform any clean-up at all. In a typical environment, some sites will be co-located with the file system and have fast response times, while other sites will be accessing the realm over a WAN and have slower response times (higher latency).

The Clean-up Realm option allows you to configure more capable systems with low latency to perform these clean-up tasks, off-loading systems with higher latency. This can provide performance improvements across the Sync Realm -- particularly at high activity, low latency sites -- and also improve realm scan times for all sites.

Access Control Considerations

The discussion above does not include the topic of Access Control. If your deployment takes advantage of aPriori's Access Control capabilities, you can define which users and which groups have access to which components. You must take these permission settings into account when creating and running export jobs. At the very least, the user who creates and runs the job must have read/write access to the components in the local database. See the "Scenario Sync Usage Notes" chapter of this guide, as well as the "Access Control" chapter of the aPriori System Administration Guide for more information.