DuploDB® constantly monitors the configured systems and the exchange of information with the other DuploDB® systems mapped in the network, to keep data always synchronized.
The tools used within the database to capture changes are Triggers and Journal Reader.
The module that manages the transmission and application of the changes is the Duplo Service Manager, which is nothing more than an Application Server running on the DuploDB® machine.
The operating principle of DuploDB® is simple: it captures the change made by applications to the data in the database and replicates it to the target databases. In this way, only the changes in the records occurred in the tables to be synchronized are sent, and all databases controlled by the product are kept updated in real time.
An example of how DuploDB® works
In order to understand how DuploDB® works, let's take as an example a system A and a system B, connected to the network:
- Database X of system A is synchronized with database Y of system B.
- In a table in database X, a variation occurs.
- This variation is captured by the Trigger (or by the Journal reader in the case of a iSeries system).
- This variation is processed by the Duplo Service Manager in system A, and sent to system B.
- The Duplo Service Manager of system B processes the change and sends a response to the Duplo Service Manager of system A.
- In the event of a positive response, the change is marked as "sent" in the Application Server of system A, and imported into the table of database Y
- If not, all updates are blocked.
OPERATING PHASES OF DUPLODB®
The operating modes of DuploDB® are divided into five phases:
1. RECORD OF CHANGES
The inventory of changes made in a database is provided by the journal, a file in which the activities carried out are recorded.
DuploDB® has its own journal, which intercepts all the changes occurred at the record level (insertions, changes and deletions).
The retrieval of this information can take place in two distinct ways, also depending on the database used:
- from the database journal
- through the Trigger, a program launched from the database that communicates the changes that have occurred.
Both modes work even when DuploDB®, for any reason, should be temporarily inactive (e.g. due to an interruption in connectivity or for system maintenance activities).
Thanks to this last feature, all changes to the source database will always be recorded.
2. Sending TO DESTINATION DATABASES
The change recorded by the DuploDB® journal is sent to all configured target systems.
Each database, thanks to the bidirectional alignment, can alternatively receive or send information.
Except in cases where you decide to partialize the records to be updated, all databases will therefore always be updated.
In this phase it is possible to insert logic to decide whether or not to send a variation to a certain system, or to transform the contents of a field through functions defined in the internal scripting environment.
3. RECEIPT AND OPTIMIZATION
Before being inserted, the changes to be made are optimized, taking into account the operating modes of the target databases.
The optimization, which allows to increase efficiency and speed, guarantees perfect communication even between systems based on different programs and languages.
4. DATA UPDATE
The changes are inserted into the target databases.
The configuration and scripting possibilities provided by DuploDB® guarantee, in this as in the other phases, a high degree of customization of the operations to be carried out.
It is thus possible to insert simple logical considerations, without the need to write codes, using only the mouse (eg synchronize this data only if the "State" field is "Italy").
But you can also insert very complex logics if necessary, using logic writing via java script or creating calculated fields via SQL queries.
5. COMMUNICATION OF UPDATE
DuploDB® concludes its action with the control phase, recording the outcome of the update:
- for all positive responses, relating to updates completed correctly, DuploDB® will notify the source database to delete the entries already entered from the journal
- for negative responses DuploDB® will instead generate one or more notification messages and will independently manage subsequent attempts at alignment.
This system ensures that no data is ever lost during synchronization.