Sincronizzazione bidirezionale dei file utilizzando il meccanismo di pooling

Siete interessati ad avere sincronizzato diversi sistemi per la gestione dei file come Dropbox, Microsoft OneDrive o Microsoft SharePoint? Permettetemi di introdurre alcuni principi di base, le migliori pratiche di sincronizzazione bidirezionale di file e documenti, come ridurre i tempi di sviluppo e i costi finanziari fuori corso.

Fin dall'inizio è necessario occuparsi delle Application Program Interface (API) di ogni sistema che si desidera sincronizzare. Per affrontare l'autenticazione, imparare la rappresentazione dello schema e i principi, la manipolazione dei dati e portarli in un linguaggio comune. Questo può essere ottenuto sia con il duro lavoro di uno sviluppatore che impara centinaia di pagine di documentazione, sia con una piattaforma di integrazione.

Si dà il caso che offriamo su una piattaforma di integrazione con una tecnologia unica nel suo genere, quindi potreste considerare l'opportunità di saperne di più sulla nostra Connect Bridge. Questo software permette di utilizzare le API di vari sistemi con l'uso di un semplice SQL (Standard Query Language). E non importa se siete .NET o Java o qualsiasi altro sviluppatore di linguaggio. Lo schema viene visualizzato nello strumento Query Analyzer di Connect Bridge e lo sviluppatore può testare la sua query in questo strumento e vedere immediatamente i risultati. Poi basta controllare il database per tenere traccia delle modifiche e si è pronti ad andare.

Il principio del meccanismo di pooling è piuttosto semplice: i dati dei sistemi di destinazione vengono recuperati ed elaborati una volta per un determinato periodo di tempo o su azione dell'utente. E questo è tutto.

Non tutti i sistemi offrono la possibilità di attivare azioni dopo il cambio di file in tempo reale. Se uno di essi non fornisce questa funzione, può causare gravi complicazioni. Quindi il vantaggio principale è il controllo dei dati e del tempo di sincronizzazione dei file. Esso fornisce un quadro più ampio di ciò che sta accadendo e apre la possibilità di evitare azioni non necessarie.

Più lungo è il tempo che intercorre tra un pool e l'altro, maggiore è la possibilità di avere conflitti tra i file.

Nella sincronizzazione bidirezionale, quando i sistemi si modificano a vicenda, può accadere che lo stesso file sia stato modificato nello stesso momento in sistemi diversi. Ma cosa succede allora? Qual è la versione corretta? In questo caso è necessario specificare quale sistema è il Master e quale lo Slave per decidere quale versione verrà sovrascritta.

Per poter tracciare le modifiche è necessario disporre di un database con gli elementi mappati dei sistemi di destinazione che sono stati sincronizzati. Il riconoscimento dell'aggiornamento può avvenire sia attraverso il tempo di modifica o la versione o qualsiasi cosa sia utilizzabile e fornita dai sistemi di destinazione. Creare o cancellare è abbastanza semplice: se il record dell'elemento non esiste nel database, è nuovo e se l'elemento non esiste nel sistema di destinazione, ma ha un record nel database, è stato cancellato nel sistema di destinazione. E questo è tutto. Alcuni sistemi hanno la possibilità di chiedere modifiche in un determinato periodo di tempo, ma in ogni caso si dovrebbe comunque tenere traccia di ciò che è stato sincronizzato a causa di guasti causati dai sistemi di destinazione o dalla connessione.

Per una logica di sincronizzazione principale che funzioni con i sistemi di destinazione è bene creare una classe Provider per ciascuno di essi e implementare l'interfaccia comune specificando le operazioni CRUD (Create-Read-Update-Delete) di base. Poi nell'algoritmo di base non è necessario preoccuparsi di quale sia quale. Si può semplicemente creare la logica generale della sincronizzazione bidirezionale e le classi Provider gestiranno la manipolazione stessa. Se viene implementato un buon algoritmo di base, non importa quanti sistemi si stanno sincronizzando. Si può semplicemente aggiungere l'implementazione di altri provider. Questo algoritmo deve seguire la gerarchia dei padroni e degli schiavi per gestire correttamente i conflitti. Se si sincronizza per coppie ordinate in base alla superiorità, dovrebbe andare bene.

Non si possono influenzare troppo le operazioni di creazione e di modifica, ma la parte più importante è il recupero dei dati. Non c'è bisogno di recuperare tutti i dati. È possibile mantenere l'ultimo tempo di sincronizzazione dei file e chiedere al server solo gli elementi con tempi di creazione e modifica più recenti. Le operazioni di cancellazione dipendono dalla logica del server. Alcune di esse forniscono operazioni di cancellazione in massa. Inoltre, se l'intera cartella è stata cancellata e la logica del server cancella tutti i sotto-voci all'interno dell'elemento cancellato, non ha senso cancellarlo uno ad uno.

Prima di tutto, non è una buona idea recuperare i dati da luoghi diversi in luoghi di codice perché se li si divide tra operazioni di lunga durata come il caricamento di file, nel frattempo l'utente può cambiare il contenuto dei sistemi e si lavorerà con dati diversi con lo stesso contesto di programma che causerà seri problemi e potrebbe portare alla perdita di dati.

Durante il processo possono verificarsi diverse eccezioni che non possono essere influenzate, come ad esempio errori interni del server dei sistemi di destinazione o perdita di connessione ecc. La pratica migliore è quella di dividere la gestione delle eccezioni in unità separate che coprano il codice che potrebbe tentare di funzionare fino a quando tutte le operazioni non sono state fatte, ma non continuano all'unità successiva. Si tratta di una sorta di albero di livello. Vi farò un esempio: la vostra sincronizzazione scopre che c'erano 10 file in 5 cartelle create nel primo sistema. Quindi inizierà a creare quelle 5 cartelle in altri sistemi, ma una delle operazioni di inserimento fa un'eccezione. Può provare a creare quelle altre 4 cartelle ma non dovrebbe iniziare ad inserire i file perché i percorsi di 2 file non esistono. Può essere gestito in modo diverso e più complicato, ma fidatevi di me per mantenerlo il più semplice possibile. Il conteggio delle variazioni dei possibili scenari di errore nella sincronizzazione bidirezionale di più sistemi è molto grande e per di più ricorsivo.