Discussion :

[LeonCosnyd]

Bonjour,

Je viens vers vous pour avoir des conseils sur le système à mettre en place pour synchroniser une base de données HFSQL C/S et une base de données HFSQL classique embarquée sur un poste mobile (tablette windows).
Cela fait plusieurs jours que je me casse la tête sur la solution à mettre en place... A chaque fois que je pars dans une direction je fais marche arrière car elle ne répond pas à mes attentes...

En quelques mots je vous explique le contexte :
-1 Poste Serveur avec une base HFSQL C/S, connecté au réseau local en CPL
-1 Poste Annexe connecté en CPL au réseau local
-1 Poste mobile (tablette windows) connecté en WIFI au réseau local.

J'ai créé un logiciel avec Windev qui est installé sur le poste Serveur et le poste Annexe. Le logiciel travail avec la base de données HFSQL C/S.

Jusque là tout va bien...

Maintenant je dois créer un logiciel spécifique pour le poste mobile connecté en WIFI. Voici les contraintes :
- rapidité d’exécution
- si possible la tablette doit rester fonctionnelle en mode hors connexion (si panne du WIFI par exemple) pour des saisies qui seront synchronisées quand le WIFI sera rétablie


Je n'ai jamais travaillé dans cette condition (poste WIFI). Savez-vous si les temps d'accès à la base de données HFSQL C/S sont aussi rapide, un peu plus long, beaucoup plus long que lorsqu'on est en ethernet ?

Voici le système que j'avais initialement prévu :
1. Importer l'analyse de la base de données des fichiers HFSQL C/S se trouvant sur le serveur pour m'y connecter par des houvreConnexion et hfermeConnexion au besoin. Chaque fichier contenant une rubrique auto dateHeure dernière modification
2. Dupliquer tous ces fichiers en mode HFSQL classique pour que ce soit ces fichiers qui soient lu par la tablette (rapidité d’exécution)

Je m'explique: La tablette utilise les données des fichiers dupliqués Classic et dans un thread secondaire je lance régulièrement des synchros avec le serveur. J'ai une variable dateHeure qui m'indique la date et heure de la dernière synchronisation avec la base HFSQL C/S. grâce à des requêtes je peux à tout moment interroger le serveur pour connaitre les enregistrements modifiés depuis la dernière synchro. A chaque fois que je récupère des nouvelles données du serveur je créer une copie dans les fichiers HFSQL Classic.

Par ce système je peux donc afficher rapidement les données contenues dans la tablette. Et un peu à la facebook afficher un bouton "Actualiser le contenu" lorsqu'une synchro m'indique avoir reçu de nouvelles données.
La synchronisation marche dans le sens Serveur -> Tablette. Ainsi lors d'une déconnexion du WIFI la tablette connait la liste des clients et des différentes informations en date de la dernière synchronisation.


Je bloque par contre complètement sur le fonctionnement à mettre en place pour que la tablette puisse modifier ET ajouter des données. (Synchro Tablette -> Serveur).


A la base j'étais parti dans l'idée d'ajouter une rubrique de type booléen pour indiquer les enregistrements modifiés dans les fichiers Classic. Et faire la synchro pour envoyer au serveur toutes les données floquées par cet indicateur.
Pour les modifications d'enregistrements existants cela fonctionne. Mais pas pour la création....
Par exemple sur la tablette j'ai une synchro qui m'indique que j'ai 10 commandes pour un client (C1 à C10). Je décide de créé deux commandes C11 et C12, d'ajouter les articles, etc.... Au même moment un autre employé créé une commande aussi pour le même client sur un des autres postes directement connecté au serveur. Au moment de la synchronisation de la tablette le serveur connait donc déjà une C11 (créé par le poste annexe en direct)... Et pas celle de la tablette. Je vais donc modifier la C11 par ma commande alors qu'il s'agit en fait d'une autre commande.

Je ne vois pas de solution simple à mettre en place pour parer à ce problème.... Le fait de vouloir travailler en désynchroniser devient une usine à gaz...
J'ai essayé de contourner le problème :
- En ajoutant un indicateur booléen : Enregistrement_AJOUT pour différencier les lignes modifiées des lignes ajoutées par la tablette.
- Au moment de la synchro je lance un HAJoute sans IdAuto fixé. Le serveur attribue alors lui même le prochain numéro auto. S'il est différent de celui de la tablette je met à jour les données de la tablette. Sauf que dans mon exemple, le serveur va me donner l'identifiant C12 alors que j'ai déjà un C12 locale fraichement créé = Erreur de doublon sur la tablette.....

Je parle d'identifiant C1, C10, etc... mais mes fichiers on comme clé unique un Identifiant Automatique HFSQL (chiffre sur lequel je n'ai pas la main).

Avez-vous des idées pour m'aider svp ? Merci par avance

[Voroltinquo]

Bonjour,
1-En ce qui concerne le vitesse, cela dépend de la qualité du signal. En règle générale, il n'y a pas de grosse influence.
2-En ce qui concerne la synchro, une piste est de timestamper tes enregistrements. La MAJ sur le poste nomade ne prendra en compte que les enregistrements dont le timepstamp (e.g. dhGDHModif) est supérieur au timestamp de sa propre synchro
3-En ce qui concerne les conflits, je te conseille d'aller voir du côté des fonctions de types HBloque... voire les fonctions de type HTransaction... https://doc.pcsoft.fr/fr-FR/?3044336

[LeonCosnyd]

Bonjour Voltorinquo,

1. Merci pour l'information du WIFI.

2. En ce qui concerne le timestamp c'est ce que j'explique. J'ai déjà mis en rubrique dans chacun de mes fichiers pour que cela se mette à jour à chaque modification. Dans un soucis de rapidité je ne fait pas une synchro complète des données mais uniquement une synchro sur les enregistrements concernés par le Client que l'utilisateur consulte. Je gère donc moi-même une variable dhDernièreSynchro (membre de la classe CLIENT) et je met à jour en fonction de cela.

3. Et c'est bien là tout le problème. J'essaie de faire des synchronisation en tache de fond pour ne pas bloquer l'appareil. Je passe déjà par des transactions pour validité ou non l'envoi d'un enregistrement. Mais le problème reste le même au niveau des identifiants automatiques.

[DelphiManiac]

Concernant le problème lié a l'Id en double, généralement il est préférable de passer par un Guid comme Id. Un Guid à un risque vraiment très très faible de collision.

Concernant le fait d'utiliser un TimeStamp, cela me semble risqué, une desynchro entre l'heure du serveur et celle de la tablette risque de tout foutre en l'air. J'aurais plutôt tendance à passer par une n° de version de synchro. Mais c'est plus complexe à mettre en place.


De manière plus générale, c'est un sujet très complexe, l'ajout étant le plus simple à gérer en dehors du petit problème de l'Id. Le point le plus complexe est la résolution des conflits.

Modification de la même fiche sur les 2 bases.
Suppression d'un coté, modification de l'autre.
Gestion des champs qui cumulent des valeurs, la modification d'un coté ne peut pas être propagés directement de l'autre coté, vu que le champ est un cumul.
Et sûrement d'autre cas que ne me viennent pas à l'esprit.

[LeonCosnyd]

Bonjour,

Dois-je en conclure qu'il n'y a pas de système simple à coté duquel je soit passé ? Le fait de vouloir travailler en mode "désynchroniser" implique donc forcément un système monstrueux ?

[Jon Shannow]

Bonjour,

Dois-je en conclure qu'il n'y a pas de système simple à coté duquel je soit passé ? Le fait de vouloir travailler en mode "désynchroniser" implique donc forcément un système monstrueux ?

Je confirme. Non seulement monstrueux, mais généralement source de très gros soucis. Dans la mesure du possible, c'est à éviter. Ou alors, il faut réduire le champ d'action des postes déportés (certains traitements sont impossibles, surtout de la consultation, gestion de données temporaires - à valider par un responsable).

Surtout, prendre le temps de la réflexion. La phase d'analyse est la plus importante, et il est vital de "penser" la base de données pour ces traitements déportés.

Bon courage

[DelphiManiac]

En effet, à ma connaissance, il n'existe pas de solution simple.

[b_reda31]

Bonsoir,
Je pense qu'il est nécessaire de prendre en considération le contexte dans lequel vous vous situez, car il sera difficile de trouver une solution de synchronisation qui soit générique et optimale
Vous devez donc adapter votre approche selon les contraintes que vous avez :
- Choix de l'approche :
Soit Dupliquer chaque fichier de l'analyse en deux version une version CS et une version Classique (embarqué) puis gérer les synchro entre ces deux fichiers
L'avantage ici est que vos clients seront autonomes, en cas d'absence de connectivité au serveur, le système continue de tourner mais l’inconvénient ici est que vous devez gérez vous même les synchonisation entre les fichiers, de quelle manière ? bidirectionnel ? mono directionnel ? dans quels sens ...etc.
d'autre part, vous devez aussi gérer, les répercussions lors des changement de structures des fichiers. En effet, si vous ajouter une rubrique dans le fichier client_CS vous devez aussi le faire systématiquement pour le fichier Client_Classique
Perso, j'utilise cette approche lorsque les clients sont itinérants avec des connexions instables (réseaux mobile 3G,4G)
Par contre, si les clients sont dans un réseau local, il sera plus judicieux d'attaquer directement la base de données.
Dans votre analyse vous aurez ainsi uniquement des fichier CS, rien à synchroniser.
Ceci-dit, je vous déconseille de maintenir une connexion permanente au serveur, je préconise l'utlisation de requetes, chaque requête étant précédé par un HOuvreConnexion et suivi par HFermeConnexion. Les données pourront ainsi être chargé par programmation en parcourant vos requêtes.

Après, rien ne vous empêche de combiner les deux approches selon le volume des fichiers, par exemple faire des accès direct pour les "petits" traitements et faire de la synchro pour les gros fichiers...

[frenchsting]

Pour les temps de réponse, en Wifi, je serais un peu plus nuancé : il y a certes la qualité du signal ("puissance" et distance de la borne wifi), mais également les perturbations éventuelles de l'environnement existant. Si tu es près d'un port par exemple, les radios hf (haute fréquence pas hyper file ) perturbent le signal wifi.

Pour avoir fait le test d'accès concurrentiel de plusieurs postes en wifi, il n'y a pas photo : vive l'ethernet !

Je n'ai plus toutes les infos, mais d'expérience, j'avais utilisé une base indépendante. Je copiais uniquement les fichiers dont j'avais besoin puis je lançais une synchro. Après si tu as énormément de données, il faut juste espérer que le wifi fonctionne en permanence.

Je n'ai jamais mis en oeuvre mais il y a les fonctions de réplication de Windev qui pourraient te simplifier la vie...

Une idée toute bête. Si le poste mobile ne s'éloigne sur un très grand périmètre, est-il possible de mettre un point d'accès au centre dudit périmètre ?

[LeonCosnyd]

Merci pour vos réponses.

En ce qui concerne la réplication j'ai déjà mis en place ce système. La synchro des serveurs HFSQL C/S marchent bien mais le système est trop opaque pour être utilisé à mon gout. Il n'y a pas possibilité de savoir (par programmation ou dans le centre de contrôle par exemple) la dernière date de synchronisation, ni même l'état de la synchro (base de données à jour à telle heure, etc...). On lance le système et on ferme les yeux en se disant c'est censé marcher....
Et tant bien même que cela fonctionne, que ce passe t-il si le poste A créé un enregistrement avec un IdAuto (123456789 par exemple) et que le poste mobile créé lui aussi un enregistrement avec cet idAuto (123456789). La règle de base de la réplication est d'utiliser les infos "les plus récentes".

Pour les identifiants uniques des enregistrements c'est vrai que j'ai l'habitude de passer par la rubrique "Identifiant automatique 8 octets" de HFSQL. Tout baser sur un GUID m'effraie un peu du fait de la non-authenticité de l'identifiant. Peut-être à tord ...

b_reda31 : Tu indiques avoir déjà mis en place une duplication des fichiers C/S en fichiers classiques. C'est ce que j'ai commencé à faire... Mais comment opères-tu la synchronisation manuelle ? Comment identifier les enregistrements qui ont été modifiés et les envoyer à la base C/S sans supprimer d'autres enregistrements qui pourraient s'être rajoutés entre-temps.

frenchsting : dans ma situation le routeur WIFI se trouve dans la pièce où le poste mobile doit être utilisé.

[Jon Shannow]

b_reda31 : Tu indiques avoir déjà mis en place une duplication des fichiers C/S en fichiers classiques. C'est ce que j'ai commencé à faire... Mais comment opères-tu la synchronisation manuelle ? Comment identifier les enregistrements qui ont été modifiés et les envoyer à la base C/S sans supprimer d'autres enregistrements qui pourraient s'être rajoutés entre-temps.

Ce que je faisais, sur les postes déportés, c'est "écrire" dans un fichier texte, tout ce qui était fait en modif (ajout/modif/suprr) et, c'est ce fichier scénario qui était rejoué. Ça pose problème quand on se sert de l'id unique pour identifier les données liées (il faut refaire les liens au fur et à mesure), mais c'est faisable (fastidieux, méticuleux, mais réalisable).

Dans l'autre sens, j'écrasais la base exportée avec la base serveur, une fois la synchro faite. Le problème, ce sont les risques de doublons (deux commerciaux qui créent deux fois le même article). Mais, ça, c'était le boulot du resp. comm. de vérifier après coup. Y avait des procédures pour gérer ça. Bref, c'est tout un bazar, et pas facile à débugger en cas de soucis. Comme je te l'ai dit, il faut vraiment bien étudier le système avant de se lancer là-dedans.

JS