DataBridge ontwikkelen: 20 zelfstandige 4D-systemen synchroniseren met een centrale MySQL-backend

DataBridge ontwikkelen: 20 zelfstandige 4D-systemen synchroniseren met een centrale MySQL-backend

Sommige softwareprojecten spreken direct tot de verbeelding. Dit project niet. Het werkt op de achtergrond, gaat door terwijl anderen slapen en valt pas op als het misgaat. Juist daarom is het belangrijk.

We werken verder aan DataBridge: een synchronisatielaag die ongeveer 20 zelfstandige 4D-installaties verbindt met een centrale MySQL-backend voor de website en bijbehorende online diensten. De uitdaging is niet alleen gegevens van A naar B verplaatsen, maar dat veilig, herhaalbaar en voorspelbaar doen in een productieomgeving waar gebruikers werken, records veranderen en verbindingen kunnen wegvallen, zonder dat één computer de rest ontregelt.

Centraal staat een klasse die DBStructure uitbreidt en de synchronisatie coördineert. Deze houdt bij of synchronisatie actief is, waar het externe endpoint staat, of triggers zijn ingeschakeld, of er al een synchronisatieronde loopt, wat de laatste HTTP-fout was en welke records zijn gewijzigd. Ook beheert de klasse eventlisteners, zodat geopende vensters in de 4D-applicatie kunnen reageren op binnenkomende wijzigingen. Het is dus meer dan een transportlaag: het is ook de coördinatie tussen database, netwerk en gebruikersinterface.

De architectuur volgt een eenvoudig maar zorgvuldig model. Lokale wijzigingen worden eerst door triggers vastgelegd. Als een record wordt aangemaakt, gewijzigd of verwijderd, probeert de trigger niet meteen met de externe server te synchroniseren. In plaats daarvan schrijft deze een regel in een lokale RecordSync-wachtrij. Dat is belangrijk: databasebewerkingen en netwerkcommunicatie blijven gescheiden. Een gebruiker die een record opslaat, hoeft niet op een externe server, HTTP-aanroep of verbindingsprobleem te wachten. Het lokale systeem blijft vlot reageren en synchronisatie wordt een asynchrone achtergrondtaak, in plaats van een blokkade voor de gebruiker.

Wanneer de synchronisatielus op de achtergrond actief wordt, controleert deze eerst of het externe endpoint bereikbaar is. Bij een goede verbinding volgen twee afzonderlijke fasen: eerst de lokale wijzigingen versturen en daarna externe wijzigingen ophalen. Deze stromen zijn bewust gescheiden. De ene verwerkt uitgaande acties van de lokale 4D-computer, de andere binnenkomende gegevens van de centrale backend. Die scheiding maakt de code begrijpelijker en het gedrag bij fouten beter beheersbaar.

De uitgaande fase leest RecordSync-regels op volgorde, bouwt de te verzenden gegevens op en verstuurt deze in batches. Elke gegevensbundel bevat de tabelnaam, recordstatus en primaire sleutel, en waar nodig de geserialiseerde recordgegevens. Voor verwijderen volstaan identiteit en status; voor aanmaken en wijzigen is een volledige momentopname van het object nodig. Na succesvolle bevestiging van een batch worden de bijbehorende wachtrijregels verwijderd. Mislukt de verzending, dan blijven ze bewust staan voor een volgende poging. Dat is geen spectaculaire techniek, maar wel techniek die de gegevens betrouwbaar houdt.

De inkomende verwerking is even zorgvuldig. DataBridge vraagt hoeveel wijzigingen klaarstaan na het laatst bekende volgnummer, haalt ze in blokken op en verwerkt ze een voor een in de lokale 4D-datastore. Elke wijziging krijgt het type aangemaakt, gewijzigd of verwijderd. Nieuwe records worden aangemaakt als ze nog niet bestaan. Gewijzigde gegevens worden in de overeenkomende entiteit geladen. Verwijderde records worden waar mogelijk weggehaald. Na verwerking wordt het lokaal bewaarde volgnummer bijgewerkt, zodat de computer precies weet waar hij in de stroom is gebleven.

Dat klinkt eenvoudig totdat de klassieke vijand van synchronisatie verschijnt: recursie. Als een externe wijziging lokaal wordt opgeslagen en die opslag opnieuw een uitgaande wijziging veroorzaakt, kan een eindeloze lus ontstaan. DataBridge gebruikt daarom een triggerKey om records te markeren die vanuit externe synchronisatie worden toegepast. De bijbehorende lokale trigger herkent dat de wijziging van DataBridge zelf komt en negeert deze. Dat ene mechanisme voorkomt dat het systeem eindeloos met zichzelf blijft communiceren.

Een ander onopvallend maar essentieel detail is recordvergrendeling. Een gebruiker kan een record al geopend hebben wanneer een externe update binnenkomt. In plaats van opslag af te dwingen, gegevens te overschrijven of op een vergrendelingsconflict vast te lopen, probeert DataBridge eerst de entiteit te vergrendelen. Lukt dat niet, dan wordt dit gelogd en blijft de wijziging wachten tot een volgende ronde. Dat is een bewuste keuze: veilig uitstellen in plaats van doen alsof gelijktijdige bewerkingen geen problemen opleveren. In gedistribueerde systemen kan optimisme duur uitpakken.

Ook inzicht in de werking krijgt veel aandacht. De synchronisatielaag toont voortgang in een paletvenster, telt verwerkte records, bewaart HTTP-fouten en schrijft elke belangrijke gebeurtenis naar een synchronisatielogboek. Wie achtergrondsystemen ontwikkelt, weet hoe belangrijk dat is: als er om 03:12 iets misgaat, bepaalt de kwaliteit van de logging vaak of de oplossing vijf minuten of vier uur kost.

Naast gewone incrementele synchronisatie bevat DataBridge beheergereedschap. Het kan volledige tabellen naar de externe backend sturen, externe tabellen naar 4D ophalen, externe tabellen aanmaken en lokale en externe structuren vergelijken. Dat helpt niet alleen bij dagelijkse synchronisatie, maar ook bij installatie, migratie, diagnostiek en gecontroleerd herstel. Synchronisatiesoftware is veel waardevoller als ze helpt begrijpen wat er in het systeem gebeurt, in plaats van alleen gegevens te verplaatsen.

Voor ontwikkelaars ligt dit project op een interessant snijvlak van klassieke bedrijfssoftware en gedistribueerde systemen. Aan de ene kant staat 4D: volwassen, lokaal, transactioneel en vertrouwd. Aan de andere kant staat een centraal webplatform met MySQL dat consistente gegevens over veel computers en gebruikers verwacht. DataBridge verbindt die werelden. Het vertaalt niet alleen gegevens, maar ook timing, toestand, fouten, herhaalde pogingen, volgorde en vertrouwen.

Er is nog werk te doen. Synchronisatiesystemen zijn nooit helemaal af: ze worden verfijnd, robuuster gemaakt en uitgebreid voor nieuwe uitzonderingsgevallen. Elke verbetering brengt het systeem dichter bij wat ontwikkelaars van infrastructuur willen: voldoende betrouwbaarheid om er niet steeds aan te hoeven denken. Dat is uiteindelijk het grootste compliment voor zo’n onderdeel. Geen applaus, maar rust.