Actuellement, Isotools utilise deux technologies différentes pour les différentes synchronisations :
La technologie Javascript utilisée pour les connecteurs de type boutique IsoShop, Yourcegid Negoce, Yourcegid Retail CBR et Yourcegid Retail ORLI
La technologie C# utilisée pour les synchronisations dérivées de l'import d'objet dont la synchronisation boutique du connecteur SAGE 100.
Les deux technologies se déploient dans un ou deux sous-répertoires du répertoire de synchronisation général localhost.
Intérêt du verrou
La synchronisation est un processus qui n'est pas atomique et qui prend une photo cohérente d'un jeu de données.
Il faut donc disposer d'un mécanisme garantissant un accès exclusif pendant la durée de la synchronisation au système de stockage (par exemple une base Isoshop) qui sera alors vu comme une boîte aux lettres.
Il faut donc garantir que la boîte aux lettres soit accédée de manière exclusive soit par le script de synchronisation Isotools soit par le dispositif externe qui lit ou écrit les données (en fonction du sens de la synchronisation).
Synchronisation Javascript : IsoShop, Yourcegid Negoce, Yourcegid Retail CBR et Yourcegid Retail ORLI
Cette technologie est utilisée pour toutes les synchronisations boutique exceptée la synchronisation Sage 100.
On reconnait une synchronisation Javascript par l'existence du fichier Javascript parameters.js dans le répertoire de synchronisation.
Sens de synchronisation
Une synchronisation javascript est mono-directionnelle. Pour synchroniser une boutique, on doit donc avoir deux scripts de synchronisation, un dans chaque sens. Ces scripts sont chacun dans un répertoire propre et disposent d'un fichier de verrou individuel.
Gestion du verrou
Lorsque le programme démarre, il cherche à ouvrir le fichier local lock.txt en création/écriture avec partage en lecture, ce qui signifie que :
Si le fichier n'existe pas ou si le fichier existe et n'est pas verrouillé en écriture, il est créé en accès exclusif en écriture tout en pouvant être lu par un autre processus. Le programme écrit alors la description de l'exécution courante à savoir :
la date,
l'identifiant système du processus courant,
la ligne de commande du processus,
le répertoire courant,
le nom de la machine
le nom du compte utilisateur exécutant le programme.
Si le fichier existe et qu'il est verrouillé en écriture, une erreur interdit l'ouverture et la synchronisation est annulée en affichant le contenu du fichier de lock.txt censé contenir la description du processus possédant le verrou.
=> La synchronisation n'est donc exécutée que si le programme a pu acquérir ce verrou.
Le verrou est maintenu sur le fichier jusqu'à la fin de l'exécution du programme.
Lorsque celui-ci s'arrête, le fichier est fermé, le verrou est donc relâché mais le fichier n'est pas détruit.
Il convient donc à tout processus extérieur qui ne doit pas s'exécuter simultanément à cette synchronisation de procéder de la sorte avec le même fichier :
Essayer d'obtenir le verrou en écriture sur lock.txt
Abandonner si le verrou n'est pas obtenu
Ecrire dans le fichier une identification de ce processus permettant de savoir à quel processus appartient le verrou sur le fichier
Si le processus externe intervient dans les deux sens (lecture de données et écriture de données), il est obligatoire à ce dernier de prendre un verrou en écriture sur les deux fichiers de verrou de chacun des sens de la synchronisation Isotools.
Synchronisation C#: Imports d'objets et Sage 100
Cette technologie est utilisée pour l'import d'objets et les technologies de synchronisation dérivées telle que la synchronisation Sage 100.
On reconnait une synchronisation C# par l'existence du fichier XML configuration.idc dans le répertoire de synchronisation. Il peut également exister un ou plusieurs fichiers .cs dans le cas d'une synchronisation dérivée de l'import d'objet.
Sens de synchronisation
Le même programme C# est utilisé pour procéder à la synchronisation dans les deux sens (depuis Isotools et vers Isotools). Le fichier de verrou va donc être commun pour interdire la concurrence sur chacun des sens de synchronisation.
Gestion du verrou
Lorsque le programme démarre, il cherche à ouvrir le fichier local lock.txt en création/écriture avec partage en lecture, ce qui signifie que :
Si le fichier n'existe pas ou si le fichier existe et n'est pas verrouillé en écriture, il est créé en accès exclusif en écriture tout en pouvant être lu par un autre processus. Le programme écrit alors la description de l'exécution courante à savoir :
la date,
l'identifiant système du processus courant,
la ligne de commande du processus,
le répertoire courant, Le nom de la machine,
le nom du compte utilisateur exécutant le programme.
Si le fichier existe et qu'il est verrouillé en écriture, une erreur interdit l'ouverture et la synchronisation est annulée en affichant le contenu du fichier de lock.txt censé contenir la description du processus possédant le verrou.
=> La synchronisation n'est donc exécutée que si le programme a pu acquérir ce verrou.
Le verrou est maintenu sur le fichier jusqu'à la fin de l'exécution du programme interdisant logiquement à toute autre programme d'accéder à la boîte aux lettres.
Lorsque le programme s’arrête, le fichier est fermé, le verrou est donc relâché puis le fichier est détruit.
Il convient donc à tout processus extérieur qui ne doit pas s'exécuter simultanément à cette synchronisation de procéder de la sorte avec le même fichier :
Essayer d'obtenir le verrou en écriture sur lock.txt
Abandonner si le verrou n'est pas obtenu
Ecrire dans le fichier une identification de ce processus permettant de savoir à quel processus appartient le verrou sur ce fichier
En conclusion
On remarquera que le processus est le même dans les deux cas de figures à deux exceptions près :
La synchronisation Javascript est toujours mono-directionnelle (donc il existe deux fichiers de verrou, un pour chaque sens)
Le fichier lock.txt n'est pas détruit en fin de synchronisation Javascript.
Dans tous les cas, pour déterminer si le processus externe peut lire ou écrire la boîe aux lettres il faut donc nécessairement prendre un verrou en écriture sur le fichier lock.txt et ce pour les raisons suivantes:
Si le fichier de lock.txt existe, cela ne veut pas dire que la synchronisation Isotools est en cours. En effet, même dans le cas de la synchronisation C# qui supprime le fichier, il peut rester un fichier de verrou lorsque la synchronisation est interrompue violemment soit par le crash du processus (bug) soit par le crash de la machine (coupure de courant,...)
Il est important de prendre le verrou pour garantir qu'une synchronisation Isotools ne va pas démarrer pendant le traitement externe. Le verrou ne devra être relâché que lorsque le traitement est achevé.
Il est important d'identifier le processus pour permettre à la synchronisation Isotools de savoir quel acteur utilise le verrou et permettre ainsi de l'indiquer dans le log produit par cette dernière.
