Créer DataBridge : synchroniser 20 systèmes 4D indépendants avec un serveur MySQL central

Construction DataBridge: synchronisation de 20 systèmes indépendants 4D avec un arrière-plan central MySQL

Certains projets logiciels sont glamour. Celui-ci n'est pas. Il vit en arrière-plan, fonctionne pendant que tout le monde dort, et ne se rend compte que lorsqu'il échoue. C'est précisément pour cela qu'il importe.

Nous avançons actuellement dans le développement de notre couche DataBridge: un moteur de synchronisation qui relie environ 20 installations indépendantes 4D à un backend central MySQL alimentant le site Web et les services en ligne connexes. Le véritable défi consiste à le faire en toute sécurité, de manière répétée et prévisible dans un environnement de production en direct où les utilisateurs travaillent, les enregistrements changent, les connexions peuvent disparaître, et aucune machine n'est autorisée à devenir la source du chaos.

Au centre de ce travail se trouve une classe qui étend la structure DBS. Elle agit comme le conducteur orchestral pour la synchronisation. Elle sait si la synchronisation est active, où se trouve le point d'extrémité distant, si les déclencheurs sont activés, si un cycle de synchronisation est déjà en cours d'exécution, quelle a été la dernière erreur HTTP et quels enregistrements ont changé. Il maintient également une collection d'écouteurs d'événements si ouverte Windows à l'intérieur de l'application 4D peut réagir lorsque des changements à distance arrivent. En d'autres termes, il ne s'agit pas seulement d'une couche de transport.

L'architecture suit un modèle simple mais discipliné. Les changements locaux sont d'abord capturés par des déclencheurs. Lorsqu'un enregistrement est créé, modifié ou supprimé, le déclencheur n'essaie pas immédiatement de synchroniser avec le serveur distant. Il découple l'édition de base de données de la communication réseau, ce qui signifie qu'un utilisateur enregistrant un enregistrement n'a pas à attendre un serveur distant, un appel HTTP ou un problème de connectivité temporaire.

Une fois que la boucle de synchronisation d'arrière-plan se réveille, elle commence par tester si le point d'extrémité distant est accessible. Si la connexion est saine, le pont effectue deux phases distinctes. D'abord, il pousse les changements de file d'attente locaux vers l'extérieur. Puis il ramène les changements distants vers l'intérieur. Ce sont des flux séparés intentionnellement. L'un gère l'intention sortante de la machine locale 4D; l'autre gère l'état entrant de l'arrière-plan central. Garder ces responsabilités distinctes rend le code plus facile à raisonner sur et rend le comportement d'échec beaucoup plus facile à contrôler.

La phase local à distant lit les lignes en file d'attente de RecordSync, ordonnées par séquence, construit une charge utile et l'envoie en lots. Chaque charge utile contient le nom de table, l'état d'enregistrement, les informations clés primaires et, le cas échéant, les données de l'entité sérialisée elle-même. Les suppressions ne nécessitent que l'identité et l'état. Une fois qu'un lot est reconnu avec succès, les entrées correspondantes de file d'attente sont supprimées. Si l'envoi échoue, elles sont délibérément laissées en place afin que le cycle suivant puisse les réessayer. Ce n'est pas une ingénierie flashy, mais c'est le genre qui maintient les systèmes honnêtes.

Le côté entrant est également prudent. Le pont demande au serveur combien de changements attendent après le dernier numéro de séquence connu, les récupère en blocs et les redonne un par un dans le magasin de données local 4D. Chaque changement entrant est classé comme créé, modifié ou supprimé. De nouveaux enregistrements sont créés s'ils n'existent pas encore. Des enregistrements modifiés sont rechargés dans l'entité correspondante. Les enregistrements supprimés sont supprimés lorsque cela est possible. Après traitement, le numéro de séquence stocké local est avancé afin que la machine sache exactement où il se trouve dans le flux.

Cela semble simple jusqu'à ce que vous rencontriez l'ennemi le plus ancien de tous les moteurs de synchronisation: la récursion. Si une modification à distance est écrite localement et que cette écriture déclenche un nouveau changement sortant, le système peut évoluer vers une chambre d'écho sans fin. Le pont utilise donc une clé de déclenchement pour marquer les enregistrements actuellement appliqués à partir de la synchronisation à distance. Quand le déclencheur local correspondant s'allume, il reconnaît que le changement provient du pont lui-même et l'ignore.

Un autre détail silencieux mais essentiel est le verrouillage. Dans une application réelle, les utilisateurs peuvent déjà avoir un enregistrement ouvert lorsqu'une mise à jour à distance arrive. Au lieu de forcer un sauvegarde, de supprimer les données ou de se heurter à un conflit de verrouillage, le pont tente d'abord de verrouiller l'entité. S'il ne le peut pas, il enregistre la situation et laisse l'élément pour un cycle ultérieur. Il s'agit d'un choix de conception conscient: différer en toute sécurité plutôt que de prétendre que les problèmes de concomitance n'existent pas.

La mise en œuvre met également de l'énergie dans l'observabilité. La couche de synchronisation écrit des mises à jour de progrès dans une fenêtre de palette, suit les comptes d'enregistrements traités, stocke les erreurs HTTP et enregistre chaque événement important dans un fichier journalier de synchronisation. Les développeurs travaillant sur l'infrastructure de fond connaissent bien cette vérité: quand quelque chose ne va pas à 03:12 du matin, la différence entre une correction de cinq minutes et une enquête de quatre heures est généralement la qualité de l'exploitation forestière.

Au-delà de la synchronisation progressive normale, le pont comprend également des outils opérationnels. Il peut pousser des tables complètes vers le backend à distance, ramener des tables à distance dans 4D, créer des tables à distance et comparer des structures locales et à distance. Cela le rend utile non seulement pour la synchronisation quotidienne, mais aussi pour la configuration, la migration, le diagnostic et les scénarios de récupération contrôlés. Un moteur de synchronisation devient beaucoup plus précieux lorsqu'il peut aider à expliquer le système, pas seulement à le déplacer.

Pour les développeurs, ce projet se situe dans un espace intéressant entre le logiciel commercial classique et l'ingénierie des systèmes distribués. D'un côté, il y a 4D: mature, local, transactionnel, fiable. Il traduit non seulement les données, mais aussi le timing, l'état, l'échec, les renouvellements, la séquence et la confiance.

Il reste encore beaucoup à faire. Les moteurs de synchronisation ne sont jamais vraiment terminés; ils sont affinés, durcis et enseignent de nouveaux cas de bord au fil du temps. Mais chaque amélioration rapproche le système de ce que les développeurs veulent réellement de l'infrastructure: quelque chose de assez fiable pour oublier.