Bidirectionele bestandssynchronisatie met behulp van een poolingmechanisme

Geïnteresseerd in het laten synchroniseren van verschillende systemen voor bestandsbeheer zoals Dropbox, Microsoft OneDrive of Microsoft SharePoint? Laat me enkele basisprincipes en best practices introduceren van bidirectionele synchronisatie van bestanden en documenten, hoe u de ontwikkelingstijd en natuurlijk de financiële kosten kunt verminderen.

Vanaf het begin moet u zorgen voor Application Program Interfaces (API's) van elk systeem dat u wilt synchroniseren. Omgaan met authenticatie, schema representatie en principes leren, data manipulatie en dit naar één gemeenschappelijke taal brengen. Dit kan worden bereikt met het harde werk van een ontwikkelaar die honderden documentatiepagina's leert, of met een integratieplatform.

Toevallig bieden wij een integratieplatform met een unieke technologie, dus u kunt overwegen meer te weten te komen over onze Connect Bridge. Met deze software kunt u API's van verschillende systemen gebruiken met behulp van een eenvoudige SQL (Standard Query Language). En het maakt niet uit of u .NET of Java of een andere taal ontwikkelaar bent. Het schema wordt gevisualiseerd in Query Analyzer tool van Connect Bridge en de ontwikkelaar kan zijn query testen in deze tool en onmiddellijk de resultaten zien. Dan hoef je alleen maar de database te controleren om de veranderingen bij te houden en je bent goed om te gaan.

Het principe van het pooling-mechanisme is vrij eenvoudig: de gegevens van doelsystemen worden eenmaal per gespecificeerde tijdsperiode of bij actie van de gebruiker opgehaald en verwerkt. En dat is het.

Niet alle systemen bieden de mogelijkheid om na bestandswijziging in real-time acties te ondernemen. Als een van hen deze mogelijkheid niet biedt, kan dit ernstige complicaties veroorzaken. Het belangrijkste voordeel is dus de controle over de gegevens en het tijdstip van bestandssynchronisatie. Het geeft u een groter beeld van wat er gebeurt en opent de mogelijkheid om onnodige acties te vermijden.

Hoe langer de tijd tussen een pool, hoe groter de kans op conflicten tussen bestanden.

Bij bidirectionele synchronisatie, wanneer de systemen elkaar wijzigen, kan het gebeuren dat hetzelfde bestand op hetzelfde moment op verschillende systemen is gewijzigd. Maar wat gebeurt er dan? Welke is de juiste versie? In dit geval moet je specificeren welk systeem de Master is en welk systeem de Slave is om te beslissen welke versie zal worden overruled.

Om de wijzigingen te kunnen volgen, moet er een database zijn met gemapte items van de doelsystemen die zijn gesynchroniseerd. De herkenning van de update kan via de wijzigingstijd of versie of wat dan ook bruikbaar is en verstrekt wordt door de doelsystemen. Creëren of verwijderen is vrij eenvoudig: als het record van een item niet bestaat in de database, is het nieuw en als het item niet bestaat in het doelsysteem, maar wel een record heeft in de database, is het verwijderd in het doelsysteem. En dat is het. Sommige systemen hebben de mogelijkheid om te vragen naar wijzigingen in een bepaalde tijdsperiode, maar je zou toch moeten bijhouden wat er gesynchroniseerd is vanwege storingen veroorzaakt door doelsystemen of verbinding.

Om de belangrijkste synchronisatielogica te laten werken met doelsystemen is het goed om voor elk van hen een Provider class te maken en de gemeenschappelijke interface te implementeren die de basis CRUD (Create-Read-Update-Delete) operaties specificeert. Dan hoef je je in het kern algoritme geen zorgen te maken over welke welke is. Je kunt gewoon de algemene logica van bidirectionele synchronisatie maken en Provider classes zullen de manipulatie zelf afhandelen. Als een goed kern algoritme is geïmplementeerd, maakt het niet uit hoeveel systemen je synchroniseert. Je kunt gewoon de implementatie van andere providers toevoegen. Dit algoritme moet de hiërarchie van masters en slaves volgen om conflicten correct af te handelen. Als je synchroniseert door paren gesorteerd op superioriteit zou het in orde moeten zijn.

U kunt de creatie- en wijzigingsoperaties niet al te zeer beïnvloeden, maar het belangrijkste deel is het ophalen van de gegevens. Het is niet nodig om alle gegevens op te halen. Je kunt de laatste synchronisatietijd aanhouden en de server alleen vragen naar items met een nieuwere aanmaak- en wijzigingstijd. Verwijder operaties zijn afhankelijk van server logica. Sommige bieden bulk verwijder operaties. Bovendien, als de hele map werd verwijderd en server logica verwijdert alle sub-items binnen het verwijderde item, heeft het geen zin om het één voor één te verwijderen.

Allereerst is het geen goed idee om gegevens van verschillende plaatsen in code op te halen, want als je het verdeelt over langdurige operaties zoals het uploaden van bestanden, kan de gebruiker ondertussen de inhoud van systemen veranderen en werk je met verschillende gegevens met dezelfde programmacontext, wat ernstige problemen zal veroorzaken en kan leiden tot gegevensverlies.

Tijdens het proces kunnen verschillende uitzonderingen optreden die je niet kunt beïnvloeden, zoals een interne serverfout van doelsystemen of verlies van verbinding enz. De beste werkwijze is om de afhandeling van uitzonderingen op te splitsen in afzonderlijke eenheden die code bevatten die zou kunnen proberen te draaien totdat alle bewerkingen zijn uitgevoerd, maar niet doorgaat naar de volgende eenheid. Het is een soort niveau-boom. Ik zal u een voorbeeld geven: uw synchronisatie komt erachter dat er 10 bestanden in 5 mappen zijn aangemaakt in het eerste systeem. Dus het zal beginnen om die 5 mappen in andere systemen te creëren, maar een van de insert operaties werpt een uitzondering. Hij kan proberen om nog eens 4 mappen aan te maken, maar mag geen bestanden invoegen omdat de paden van 2 bestanden niet bestaan. Het kan op verschillende en meer ingewikkelde manieren worden afgehandeld, maar vertrouw me om het zo eenvoudig mogelijk te houden. Het aantal mogelijke foutscenario's in bi-directionele synchronisatie van meerdere systemen is zeer groot en bovendien recursief.