DuploDB^® monitora costantemente i sistemi configurati e l’interscambio di informazioni con gli altri sistemi DuploDB^® mappati nella rete, per mantenere sempre sincronizzati i dati.

Gli strumenti utilizzati all'interno del database per catturare le variazioni sono i Trigger e il Journal Reader.

Il modulo che gestisce la trasmissione e l'applicazione delle variazioni è il Duplo Service Manager, il quale non è altro che un Application Server in esecuzione sulla macchina DuploDB^® .

Il principio di funzionamento di DuploDB^® è semplice: catturare la modifica che viene fatta dagli applicativi ai dati presenti nel database e replicarla nei database di destinazione. In questo modo vengono inviate le sole variazioni dei record avvenute nelle tabelle da sincronizzare e tenuti aggiornati in tempo reale tutti i database controllati dal prodotto.

Fasi operative di DuploDB^® 

Le modalità operative di DuploDB^® si articolano in cinque fasi:

1. Registrazione dei cambiamenti

L’inventario delle modifiche apportate in un database viene fornito dal journal, file in cui vengono registrate le attività svolte.

DuploDB^® dispone di un proprio journal, che intercetta tutte le variazioni avvenute a livello di record (inserimenti, modifiche e cancellazioni).

Il reperimento di queste informazioni può avvenire in due modalità distinte, in funzione anche del database utilizzato:

• dal journal del database
• attraverso il Trigger, programma lanciato dal database che comunica le variazioni avvenute.

Entrambe le modalità funzionano anche quando DuploDB^® , per qualsiasi motivo, dovesse risultare temporaneamente inattivo (ad es. per un’interruzione nella connettività o per attività di manutenzione del sistema).

Grazie a quest’ultima caratteristica, tutte le modifiche al database sorgente saranno sempre registrate.

2. Spedizione ai database di destinazione

La variazione registrata dal journal di DuploDB^® viene spedita a tutti i sistemi di destinazione configurati.

Ogni database, grazie all’allineamento bidirezionale, può alternativamente ricevere o inviare informazioni.

Salvo i casi in cui si decida di parzializzare i record da aggiornare, tutti i database saranno quindi sempre aggiornati.

In questa fase è possibile inserire della logiche per decidere se inviare o meno una variazione ad un certo sistema, o trasformare i contenuti di un campo attraverso funzioni definite nell’ambiente interno di scripting.

3. Ricezione ed ottimizzazione

Prima di essere inserite, le modifiche da apportare vengono ottimizzate, tenendo conto delle modalità operative dei database di destinazione.

L’ottimizzazione, che permette di aumentare efficienza e velocità, garantisce una comunicazione perfetta anche tra sistemi basati su programmi e linguaggi differenti.

4. Aggiornamento del dato

Le modifiche vengono inserite nei database di destinazione.

Le possibilità di configurazione e di scripting fornite da DuploDB^® garantiscono, in questa come nelle altre fasi, un elevato grado di personalizzazione delle operazioni da svolgere.

Si possono così inserire considerazioni logiche semplici, senza bisogno di scrivere dei codici, usando solo il mouse (es. sincronizza questo dato solo se il campo Stato è “Italia”).

Ma si possono anche inserire delle logiche all’occorrenza molto complesse, ricorrendo alla scrittura di logica via java script oppure creando campi calcolati tramite query SQL.

5. Comunicazione di avvenuto aggiornamento

DuploDB^® conclude la sua azione con la fase di controllo, registrando l’esito dell’aggiornamento:

• per tutte le risposte positive, relative ad aggiornamenti conclusi correttamente, DuploDB^® comunicherà al database sorgente di eliminare dal journal le voci già inserite
• per le risposte negative DuploDB^® genererà invece uno o più messaggi di notifica e gestirà in modo autonomo i successivi tentativi di allineamento.

Questo sistema garantisce che nessun dato venga mai perso in fase di sincronizzazione.