/
Adonis Replicator

Adonis Replicator


Adonis Replicator is a utility designed to distribute the main office database throughout various sites in an organization.

The application does not require online connection to synchronize the database because the changes made on the sending site are stored in archives. These archives are posted on the receiving site where they are processed when the receiving site starts the replication process. After that, the application can import and export changes. 

In addition to synchronizing remote database (vessels, other remote sites), Adonis Replicator supports the following functionality:

  • Partial replication.

  • Bandwidth check, metadata prioritization before replicating scanned documents. 

  • Distributing and scheduling program upgrades.

  • Obsolete data purge from a remote database to avoid uncontrolled database growth onboard. The functionality is avaiable in partial replication only.

  • Execute small executable, plugins, to perform scheduled tasks such as interfacing to third-party software suppliers.

Adonis Replicator lets you monitor the replication process remotely using a dedicated mobile application. Via push messages, you will be warned about various types of non-conformities


Partial Replication

Partial replication is an advanced replication feature that replicates subsets of the database instead of the whole database. The replicator provides parameters like destination site, last replication date that may be used in sql queries to define the subsets. This makes it possible to define subsets that contain information about crew signed on or planned to sign on in the next n number of days.

For more information, see Partial Replication.

Replication by Priority

Adonis Replicator allows defining a priority level of the data that a vessel needs to download/receive from the FTP server. Typically, low priority data includes scanned documents like passport or competencies, whereas the metadata information describing the passport or competence record is of high priority. Replicator downloads low priority files based on the bandwidth available, If the bandwidth drops down the offset, it only replicates high priority fields.

For more information, see Replication by Priority.

Replication Surveillance

It is important to monitor the replication to make sure it works properly and does not have inconsistency in the data. Monitoring replication assumes that:

  • files are coming through to/from a site

  • files are being imported/exported

  • errors, if any, are logged to a log file

The Replicator service has automatic monitoring alerting mechanism to be configured. Such a mechanism sends alerts by e-mail.

Here are the messages you can choose to receive/send for monitoring purposes:

  • Status report. It is intended for the cases when Replicator stops or hangs and you may not notice it as the application cannot send any alerts. To handle that, you can choose to receive a status report at a defined interval. If you don't receive the status report at the scheduled interval, that might mean there are some issues either in the replicator service or the mail transfer.

  • Warning. You can choose to send a warning if you have not received any replication files within a given period. If you have received a status report, but failed to receive any files at a defined period, it may indicate some difficulties at the remote site.

  • Reports on errors. If an error occurs while executing a replication task, it is recommended to send an error report to our dedicated support team.

Besides, you can enjoy using the Replicator Monitor application on your Android device. The application is specifically designed for monitoring replication status from your Android device.

For more information, see Replication Surveillance.

Scheduled Program Update

Replicator allows you to distribute and to automatically install the application updates on sites. An update is distributed as a CAB archive (the Microsoft Cabinet file) that contains update files. The archive is called an update package.
Replicator supports two update types: a program and plugin update.
When updating a program, Replicator delivers the installer and other update files to sites and starts this installer at a specific period of time. When the update is successfully installed, the installer is not used anymore.
A plugin is an independent console application that can be started regularly and take some needed actions, e.g. form some reports and send them by email to specified destinations. When updating a plugin, Replicator delivers the plugin executable file and some other auxiliary files to sites. The plugin installation is performed as a simple file copying to a certain folder created for the plugin. An installer is not needed.

For more information, see Scheduled Program Update.

Purge Database

Replicator provides the possibility to purge databases for freeing up space or deleting obsolete data that is no longer required. Simply, on the main site, set up the database for the purge feature to make Replicator generate the purge requests for the satellites. Please note, the main site is never purged and, therefore, satellite sites do not export purge requests. The main site is the only site that can export purge requests and send them to other sites (satellites).

For more information, see Purge Database.

Replicator Plugins

The replicator plugin is an application intended to perform tasks like exchanging data to 3rd party systems. These plug-ins are scheduled similar to the replication tasks but execute in a separate thread using their own scheduler. The scheduled plug-ins are not interfering with the replication tasks, this means they execute simultaneously in case their schedule overlaps.  The plug-ins are replicated to each site and from the host, the administrator can control the parameters unique for each site.

For more information, see Replicator Plugins

 

Delayed Import Storage

Delayed import storage is designed specifically for storing table records that could not be imported due to an error occurred. In such a case, Replicator Manager continues the import process and the records remain in the storage until it resumes an attempt to import the record.

The functionality is mainly purposed for automatic resolution of foreign key violations. If an error occurs due to a foreign key violation, Replicator Manger sends a request for missing data to the site from which the CAB file with that record has arrived. When Replicator Manager gets a reply to the request, it imports the records from this reply to the database and then attempts to import the failed record from DIS again.

When the record is successfully imported, it is then removed from the storage.

Please keep in mind that the described procedure usually solves the issue, but sometimes data hangs and you need to correct errors manually. Therefore, it is highly recommended to check the Delayed import storage from time to time to make sure that no data is ignored.

 

Based on the import/export settings defined on Step 7 of the installation process (see Installing Replicator), the behavior of Replicator Manager may vary:

Stop Import On Error:

  • If selected, the application stores a record in Delayed import storage only in case a foreign key violation is detected.

  • If cleared, a record is stored in Delayed import storage in case of any error.

DB errors to be ignored. In case an occurred import error is listed in the DB errors to be ignored field, Replicator Manager ignores the record and continue importing.

 

Independent Export

The independent export assumes exporting data to a selected site separately from the general replication. As a result, Replicator populates data in the site without waiting until a time-consuming export to a new vessel completes.

For more information, see Independent Export.

 

 

Related content