6 La navigation dans le manuel de Kentika est réservée aux utilisateurs identifiés
La synchronisation entre bases
La synchronisation de bases - Présentation
La fonction de synchronisation permet de traiter deux cas :
Ce cas concerne principalement les serveurs web lorsque ceux-ci sont dissociés de la base en exploitation ; cette configuration comprend :
La base en exploitation met à jour la base hébergée.
Deux cas peuvent se présenter :
Dans cette configuration, plusieurs bases Kentika en exploitation mettent à jour une base collective. Les bases en exploitation ne reçoivent pas d'information de la base collective. Nous appellerons ce cas "synchronisation collective ".
Chaque base impliquée dans la synchronisation est identifiée par sa signature (= nom du dossier d'archivage).
La signature est une information essentielle car elle détermine les règles de dédoublonnage appliquées lors de l'intégration d'un lot de modifications :
Rappel : ces règles sont les mêmes que celles appliquées à l'export / import d'enregistrements au format Kentika.
Le seul cas où les deux bases doivent avoir la même signature est la synchronisation unilatérale, où la base d'arrivée est un miroir de la base de départ. Pour les deux autres cas, il faut que chaque base, y compris la base d'arrivée, ait sa propre signature.
Deux groupes d'informations sont identifiés :
Toute intervention effectuée sur ces tables est enregistrée dans un journal des opérations :
La synchronisation se base sur ce journal pour déterminer les enregistrements devant être synchronisés.
Le paramétrage de la synchronisation permet de déterminer quelles sont les tables qui doivent être synchronisées, en appliquant ou non un filtre. Pour chacune de ces tables, Kentika analyse le journal des opérations pour déterminer les évènements survenus depuis la dernière synchronisation.
Un enregistrement ajouté ou modifié est envoyé avec son environnement :
Les ajouts et modifications sur les tables de paramétrage ne sont pas envoyées automatiquement à chaque déclenchement de la synchronisation. Cela doit être réalisé manuellement. Ceci permet de mettre au point tous les éléments de paramétrage puis de les faire migrer en choisissant les tables devant être mises à jour.
Exemple : vous créez des requêtes de type dossier web puis les organiser ; vous pouvez ensuite envoyer la table des requêtes à la base synchronisée.
La suppression d'un élément de paramétrage ne migre pas lors de l'envoi manuel d'une table de paramétrage. Elle ne migre qu'avec un lot préparé suite à des interventions sur une des tables explorateur à faire migrer.
La modification du libellé d'un type d'objet implique dans la base en exploitation la mise à jour de tous les enregistrements associés à ce type.
Exemple : vous renommez le type de document "Article" en "Article de périodique" ; tous les documents de type anciennement "Article" ont été transformés en "Article de périodique".
Si vous êtes amené à effectuer cette opération, vous ne devez pas envoyer manuellement la table des types d'objet. Cette opération exceptionnelle sera envoyée avec un lot d'enregistrements mis à jour et sera répercutée automatiquement sur la base d'arrivée lors de l'intégration du lot.
Le paramétrage de la synchronisation permet de :
Exemple : synchroniser les articles mais pas les notes internes.
Exemple : ne pas faire migrer une rubrique servant à identifier des enregistrements confidentiels.
L'import d'un lot est réalisé en appliquant une stratégie d'import qui permet de fixer pour chaque table les règles à appliquer :
Les règles sont les mêmes que celles appliquées lors d'un import de données au format Kentika avec une particularité concernant les suppressions, informations non présentes dans un fichier d'export au format Kentika.
Bien qu'ayant été exportés, certains enregistrements peuvent être ignorés lors de l'intégration dans la base d'arrivée.
Dans le cas d'un catalogage collectif, pour conserver une cohérence à la base collective, il est conseillé de désigner une des bases de départ comme étant la base de référence en terme de paramétrage et en conséquence :
Même si une des autres bases envoie son paramétrage, celui-ci ne sera pas intégré.
Ceci peut être réalisé globalement pour toutes les tables de paramétrage ou être affiné table par table en répartissant les responsabilités.
Dans la base collective, il devra y avoir autant de stratégies d'import que de bases susceptibles de la synchroniser.
Kentika permet deux modes :
Kentika permet de choisir les jours et heures de déclenchement de la synchronisation. Cela ne concerne que l'envoi des lots de mise à jour.
Dans une plage horaire de déclenchement de la synchronisation, Kentika vérifie :
- si oui, Kentika tente une interrogation sur l'adresse IP désignée et vérifie :
Pour envoyer un lot en mode manuel, il faut dans un premier temps, tester le serveur c'est-à-dire vérifier :
Lorsque cette première étape est franchie, après envoi et intégration du lot sur la base d'arrivée, il est possible de recevoir un lot en retour.
Les lots sont enregistrés dans le dossier ALTemp de la machine en charge de la synchronisation dans un sous-dossier nommé "Synchro" et organisé ainsi :
Dans chacun de ces dossiers In et OUT, se trouvent des sous-dossiers portant la signature des bases impliquées dans la synchronisation dans lesquels sont enregistrés les lots.
Les lots créés par :
ou
sont nommés "L_" suivi d'un numéro d'ordre et de l'extension ".blb".
Les lots créés par une sélection manuelle des enregistrements sont nommés "S_" suivi d'un numéro d'ordre et de l'extension ".blb".
Powered by KENTIKA Atomic - © Kentika 2025 tous droits réservés - Mentions légales