Synchronisation bidirectionnelle des fichiers par le biais d'un mécanisme de mise en commun

Vous souhaitez disposer de différents systèmes synchronisés de gestion de fichiers tels que Dropbox, Microsoft OneDrive ou Microsoft SharePoint ? Permettez-moi de vous présenter quelques principes de base, les meilleures pratiques de synchronisation bidirectionnelle des fichiers et des documents, la manière de réduire le temps de développement et, bien sûr, les coûts financiers.

Dès le départ, vous devez vous occuper des interfaces de programmes d'application (API) de chaque système que vous souhaitez synchroniser. Pour traiter de l'authentification, apprendre la représentation et les principes des schémas, la manipulation des données et les amener à un langage commun. Cela peut être réalisé soit par le travail acharné d'un développeur qui apprend des centaines de pages de documentation, soit par une plate-forme d'intégration.

Il se trouve que nous proposons une plateforme d'intégration avec une technologie tout à fait unique, vous pourriez donc envisager d'en savoir plus sur notre Connect Bridge. Ce logiciel vous permet d'utiliser les API de différents systèmes à l'aide d'un simple SQL (Standard Query Language). Et peu importe que vous soyez un développeur .NET ou Java ou tout autre langage. Le schéma est visualisé dans l'outil Query Analyzer de Connect Bridge et le développeur peut tester sa requête dans cet outil et voir les résultats immédiatement. Il suffit ensuite de contrôler la base de données pour suivre les modifications et c'est parti.

Le principe du mécanisme de mise en commun est assez simple : les données des systèmes cibles sont récupérées et traitées une fois par période de temps déterminée ou sur intervention de l'utilisateur. Et c'est tout.

Tous les systèmes n'offrent pas la possibilité de déclencher des actions après un changement de fichier en temps réel. Si l'un d'entre eux n'offre pas cette possibilité, cela peut entraîner de graves complications. Le principal avantage est donc le contrôle des données et de l'heure de synchronisation des fichiers. Cela vous donne une vue d'ensemble de ce qui se passe et vous permet d'éviter des actions inutiles.

Plus le délai entre deux groupes est long, plus les risques de conflits entre les dossiers sont importants.

Dans la synchronisation bidirectionnelle, lorsque les systèmes se modifient mutuellement, il peut arriver qu'un même fichier ait été modifié au même moment dans différents systèmes. Mais que se passe-t-il alors ? Quelle est la bonne version ? Dans ce cas, vous devez spécifier quel système est le maître et quel système est l'esclave afin de décider quelle version sera remplacée.

Afin de suivre les changements, vous devez disposer d'une base de données contenant des éléments cartographiés des systèmes cibles qui ont été synchronisés. La reconnaissance de la mise à jour peut se faire soit par l'heure de modification, soit par la version, soit par tout ce qui est utilisable et fourni par les systèmes cibles. La création ou la suppression est assez simple : si l'enregistrement d'un élément n'existe pas dans la base de données, il est nouveau et si l'élément n'existe pas dans le système cible, mais qu'il a un enregistrement dans la base de données, il a été supprimé dans le système cible. Et c'est tout. Certains systèmes ont la possibilité de demander des modifications dans un délai déterminé, mais de toute façon, il faudrait suivre ce qui a été synchronisé en raison de défaillances causées par les systèmes cibles ou la connexion.

Pour que la logique de synchronisation principale fonctionne avec les systèmes cibles, il est bon de créer une classe de fournisseur pour chacun d'eux et de mettre en œuvre l'interface commune spécifiant les opérations CRUD (Create-Read-Update-Delete) de base. Ensuite, dans l'algorithme de base, il n'est pas nécessaire de se préoccuper de savoir lequel est lequel. Vous pouvez simplement créer la logique générale de la synchronisation bidirectionnelle et les classes du fournisseur se chargeront de la manipulation elle-même. Si un bon algorithme de base est mis en œuvre, le nombre de systèmes que vous synchronisez n'a pas d'importance. Vous pouvez simplement ajouter l'implémentation d'autres fournisseurs. Cet algorithme doit suivre la hiérarchie des maîtres et des esclaves afin de gérer correctement les conflits. Si vous synchronisez par paires triées par supériorité, cela devrait être bon.

Vous ne pouvez pas trop influencer les opérations de création et de modification, mais la partie la plus importante est la récupération des données. Il n'est pas nécessaire de récupérer toutes les données. Vous pouvez conserver la dernière heure de synchronisation des fichiers et ne demander au serveur que les éléments dont l'heure de création et de modification est plus récente. Les opérations de suppression dépendent de la logique du serveur. Certaines d'entre elles permettent des opérations de suppression en masse. De plus, si le dossier entier a été supprimé et que la logique du serveur supprime tous les sous-éléments de l'élément supprimé, il n'est pas logique de les supprimer un par un.

Tout d'abord, ce n'est pas une bonne idée de récupérer des données à différents endroits dans des lieux de code car si vous les répartissez entre des opérations de longue durée comme le téléchargement de fichiers, pendant ce temps l'utilisateur peut changer le contenu des systèmes et vous travaillerez avec des données différentes dans le même contexte de programme ce qui causera de sérieux problèmes et pourrait entraîner la perte de données.

Au cours du processus, diverses exceptions peuvent se produire, sur lesquelles vous ne pouvez pas influer, comme une erreur interne du serveur des systèmes cibles ou une perte de connexion, etc. La meilleure pratique consiste à diviser le traitement des exceptions en unités distinctes couvrant le code qui pourrait essayer de s'exécuter jusqu'à ce que toutes les opérations soient terminées, mais ne pas passer à l'unité suivante. Il s'agit d'une sorte d'arbre à niveaux. Je vais vous donner un exemple : votre synchronisation découvre qu'il y avait 10 fichiers dans 5 dossiers créés dans le premier système. Elle va donc commencer à créer ces 5 dossiers dans les autres systèmes, mais une des opérations d'insertion fait une exception. Il peut essayer de créer ces 4 autres dossiers mais ne doit pas commencer à insérer des fichiers car les chemins d'accès de 2 fichiers n'existent pas. Il peut être géré de différentes manières et de manière plus compliquée, mais croyez-moi, il doit rester aussi simple que possible. Le nombre de variations des scénarios d'erreur possibles dans la synchronisation bidirectionnelle de plusieurs systèmes est très élevé et de plus, il est récursif.