Présentation Diapo01 Je m appelle Michel Canneddu. Je développe avec 4D depuis 1987 et j exerce en tant qu indépendant depuis 1990. Avant de commencer, je tiens à remercier mes parrains Jean-Pierre MILLIET, Bernard FEVAT et Matthieu BAUDOUX qui m ont aidé à préparer cet exposé. Logistique Diapo02 Introduction Diapo03 Tout d abord, nous allons employer alternativement les mots synchronisations ou réplications. Ici, on peut les considérer comme synonymes. La conférence va permettre d illustrer une méthode pour synchroniser des données entre des bases de données dites Esclaves et une base de données centrale dite Maître. Dans ce schéma, l esclave saisie et est propriétaire de ses données. Le Maître reçoit le travail de l esclave et est éventuellement propriétaire d autres données. Dans cette première partie, la réplication est unidirectionnelle (de Esclaves vers Maître) (1 vers 1). Toutefois, nous verrons en seconde partie qu il est également possible d échanger des données de Maître vers Esclave (1 vers n). Diapo04 Le système décrit ici, se veut léger à mettre en place. L objet le plus fin pouvant être synchronisé est l enregistrement. Il est donc possible d envisager de synchroniser seulement certaines tables ou même seulement certains enregistrements de ces tables. Nous faisons l impasse ici sur la synchronisation de champs à champs. De ce fait, certaines limites sont à prendre en considération : - Les échanges de données sont quasiment unidirectionnels ; - Chaque base de données Esclave est propriétaire de ses données (il n y a pas ou très peu de saisies croisées avec la base Maître ou une autre base Esclave) ; - Il n est pas nécessaire d utiliser les données consolidées en temps réel. Le système le plus autonome (celui détaillé ici) permet d échanger des données automatiquement grâce à l implémentation de 4D Open pour 4D. Toutefois, le système de synchronisation s appuie sur un échange de fichiers et peut donc utiliser d autres canaux pour communiquer (disquettes, LAN, WAN, Internet, fichiers joints aux E-Mails). Bien entendu ces solutions sont plus ou moins autonomes et donc plus ou moins fiables. Au plus le facteur humain est introduit dans le processus, au plus une méthode de synchronisation totale, pour palier à ces défaillances, est nécessaire. Diapo05 Différents types d utilisation : - Mise en place d un système d information réparti sur plusieurs serveurs avec consolidation des données dans une base de données centrale. Exemple : Une université est structurée autour de plusieurs sites : les facultés. Chaque faculté a un serveur 4D pour gérer ses étudiants. Au niveau de l université, un autre serveur 4D centralise les données saisies sur les différents serveurs. - Dans le cas de la publication web : Mise en réplication d une base de données exploitées en local et de son image installée chez un fournisseur d accès Internet.
Schéma de principe Diapo06 Pour mieux comprendre les mécanismes mis en place nous allons décrire une organisation. La société SOC a plusieurs filiales dans le monde. Dans ce schéma SOC Italie (UID 1), Espagne (UID 2) et Grèce (UID3) sont esclaves de SOC (UID0). SOC Sicile (UID 4) est esclave de SOC Italie (UID 1). L UID est donc une référence abrégée unique entre toutes les bases de données. La structure employée dans chaque site est identique. En fait, il faut surtout que la structure de chaque table à synchroniser soit identique. Chaque base de données déclarées comme esclave va devoir maintenir à jour un journal des modifications des données faites sur les tables à synchroniser. Les échanges entre les sites se font avec des fichiers. Tous les modes de transfert sont envisageables. Les connexions sont unidirectionnelles. Ce sont les bases esclaves qui envoient leurs données vers leur base maître. Concepts abordés Diapo07 L implémentation du système s appuie sur différents aspects techniques de 4D qui sont : Les méthodes de base Les procédures stockées (délégation de certaines tâches sur le serveur) Les triggers Le plug-in 4D Open pour 4D Les différents types de variables et leurs communications entre les process. Les blobs Mise en place du système Diapo08 Paramètres globaux Pour un portage efficace de votre application, les paramètres globaux ne doivent pas être attachés au fichier de structure ni accessible uniquement à partir d un poste. Plusieurs solutions sont possibles : - Une table dédiée avec, normalement, un enregistrement unique. - Un enregistrement dans une table «fourre tout» contenant dans un blob pour l ensemble des paramètres En cous d exploitation, certaines de ces valeurs sont chargées dans des variables interprocess. Les paramètres essentiels sont : Diapo09 UID : Référence unique entre toutes les bases de données (multi-site), Ce champ est inclus dans le codage des clés alphanumériques, sa longueur doit être la plus courte possible. Diapo10 Numéro de version : Ce numéro est incrémenté à chaque mise à jour de la structure. Il permet de contrôler que deux bases de données qui se synchronisent ont le même numéro de version et donc la même structure des tables échangées Diapo11 Esclave : Ce champ permet de démarrer ou d arrêter l écrire du journal sur les modifications effectuées sur la base de données.
Diapo12 Données propres à la synchronisation : - Active Oui-Non - Fréquence de synchronisation ; Attention cette dernière, exprimé en heure, doit avoir en valeur minimum une valeur supérieure à 00h00 - Date et heure prochaine synchronisation ; Attention de plafonner le champ heure à une valeur maximum de 23h59 - Si des échanges sont réalisés avec 4D Open for 4D il faut prévoir de mémoriser l adresse IP du serveur Maître, le nom d utilisateur et le mot de passe permettant la connexion. Diapo13 Marquage des enregistrements à répliquer Pour garantir que chaques modifications des tables à répliquer seront prises en compte, il est nécessaire d utiliser les triggers. Dans le trigger, le logiciel va affecter un identifiant unique à chaque enregistrement s il n existe pas et va mettre à jour le journal en fonction du type de modification. Diapo14 Rappel sur les options d exécution des Triggers La demande d exécution des triggers est faite, table par table, sur la fenêtre des propriétés de la table où l on veut activer le triggers. Pour les tables à synchroniser, trois événements moteurs doivent être activés : Sur sauvegarde nouvel enreg. Cette option permet d invoquer le trigger à chaque fois qu'un enregistrement est créé dans la table AJOUTER ENREGISTREMENT CREER ENREGISTREMENT et STOCKER ENREGISTREMENT IMPORT TABLEAU VERS SELECTION STOCKER SUR LIEN Sur sauvegarde enregistrement Cette option permet d invoquer le trigger à chaque fois qu'un enregistrement de la table est modifié MODIFIER ENREGISTREMENT STOCKER ENREGISTREMENT TABLEAU VERS SELECTION APPLIQUER A SELECTION MODIFIER SELECTION Sur suppression enregistrement Cette option permet d invoquer le trigger à chaque fois qu'un enregistrement de la table est supprimé SUPPRIMER ENREGISTREMENT SUPPRIMER SELECTION Suppression automatique par les options de contrôle d intégrité de 4D
Diapo15 Création d un identifiant unique pour chaque table à synchroniser Cet identifiant peut déjà exister dans votre base. Il est tout à fait utilisable. Pour l exposé, nous décrivons la mise en place d un identifiant unique simple. Pour numéroter les enregistrements il est préférable d utiliser une table compteur que la fonction Numérotation automatique. Ainsi, on peut éventuellement mettre en place : - Des sous système de numérotation par année ; - Un système de récupération des numéros supprimés. Attention, dans ce dernier cas, il faut prévoir un système qui interdit la réutilisation du numéro tant que ce dernier se trouve dans le journal (table décrite dans le chapitre suivant). Nous avons dans cette table un enregistrement par table à numéroter. Pour utiliser cette table, nous écrivons une méthode projet qui renvoie le prochain numéro pour la table dont le numéro est passé en paramètre. Dans le cas où le compteur n existerait pas pour la table passée en paramètre, la méthode le créé automatiquement. Diapo16 Création d un identifiant unique pour chaque table à synchroniser Dans le cas où l on créerait un champ clé unique il sera typé alphanumérique. Il contient : - la référence UID - le numéro d ordre séquentiel dans la table Si ce champ était numérique, il faudrait limiter le potentiel de numérotation de l ensemble des bases à un seul compteur de 0 à 2 147 483 647. Selon les plages attribuées, on prendrait le risque d avoir des plages qui se chevauche. Pour limiter la longueur de ce champ, il est conseillé d utiliser une méthode qui convertie une valeur numérique (en base 10) en une valeur en base 36. 16 777 216 qui mesure 8 caractères ne devient plus que 9ZLDS qui mesure 5 caractères. 2 147 483 647 qui mesure 10 caractères ne devient plus que ZIK0ZJ qui mesure 6 caractères D après ces exemples, le champ Clé unique occupe au plus 7 caractères. Il faut toutefois en structure le définir avec 2 caractères de plus. En effet, dans les processus suivant, le logiciel utilise ces places vides. Diapo17 Trigger pour assurer cette tâche Le trigger est tout à fait adapté pour y insérer le code permettant d affecter le champ identifiant unique. Ce code sera exécuté pour l événement Sur sauvegarde nouvel enreg. Toutefois, il faut veiller à affecter ce champ que s il est vide. En effet, dans certains cas, les développeurs ont besoin d avoir un identifiant unique bien avant de passer sur STOCKER ENREGISTREMENT. Il est également souhaitable de prévoir pour l événement Sur sauvegarde enregistrement, une génération d erreur si le champ identifiant unique est différent de sa copie ancienne. Je vous rappelle qu un trigger est une fonction qui renvoie une valeur numérique. Si cette dernière est égale à 0, cela signifie qu il s est bien déroulé, sinon la commande invoqué n a pas été exécutée. Il suffit donc pour bloquer la commande qui a invoquer le trigger de renvoyer une valeur différente de zéro.
Diapo18 Mise en place d une table journal Les bases Esclaves doivent remplir automatiquement une table complémentaire. Cette table a pour mission de maintenir un journal des actions réalisées sur les données avec l horaire. L horaire est exprimé par une méthode qui donne un TimeStamp (c est à dire un nombre de secondes entre l horaire de modification et une date fixée arbitrairement). Le pas de temps le plus court est la seconde, il y aura donc plusieurs actions pour le même horaire. S il est nécessaire de connaître exactement l ordre d exécution, on peut y ajouter : - Un champ Priorité (Rapide et souvent suffisent, il fixe la priorité des actions sur les tables par rapports aux autres) ; - Un champ Ordre (Imparable mais lent). Diapo19 Synchronisation incrémentale et synchronisation totale Les mécanismes à mettre en place pour un processus de réplication sont identiques à ceux d une sauvegarde. Dans les processus de sauvegardes il existe les sauvegardes incrémentales et les sauvegardes complètes. Dans les processus de réplication on doit retrouver ces deux concepts. La synchronisation incrémentales va permettre d envoyer vers le site Maître, les données modifiées depuis la dernière synchronisation. Ce mécanisme est le processus de base. La synchronisation complète est un processus qui est nécessaire. Il permet d initialiser la première synchronisation. Il peut ensuite être utilisé pour palier à des défaillances du système qui résultent automatiquement à une désynchronisation des données Diapo20 Trigger pour assurer cette tâche La mise à jour du journal est assurée par les triggers mis en place sur chacune des tables à synchroniser. Pour chaque événement moteur une méthode projet sera invoquée : Sur sauvegarde nouvel enreg. Cette méthode recherche dans la table journal s il existe un enregistrement pour l ID passé en paramètre. Si : - il existe, elle positionne le champ Action à A En fait, ce cas n existe pas - il n existe pas, elle en crée un et positionne le champ Action à A. Sur sauvegarde enregistrement Cette méthode recherche dans la table journal s il existe un enregistrement pour l ID passé en paramètre. Si : - il existe, elle ne fait rien En effet, il peut déjà exister en A ou M - il n existe pas, elle en crée un et positionne le champ Action à M. Sur suppression enregistrement Cette méthode recherche dans la table journal s il existe un enregistrement pour l ID passé en paramètre. Si : - il existe, Si : - Le champ Action est égal à A, elle supprime l enregistrement L enregistrement a été créé, n a jamais été envoyé à la base Maître, on peut le supprimer en effaçant la trace de son existence - Le champ Action est égal à M, elle le convertit à S - il n existe pas, elle en crée un et positionne le champ Action à S.
Diapo21 Attention : certaines manipulations ne doivent pas être intégrée dans le journal La mise à jour du journal au travers du trigger garantie une fiabilité totale. Cependant, dans certains cas, si on est une base Esclave, il ne faut pas mettre à jour le journal. Par exemple, pour l import d un enregistrement, il faut d abord SUPPRIMER la copie existante puis CREER la nouvelle copie. Ceci entraîne normalement une mise à jour du journal pour une Suppression et une mise à jour du journal pour un Ajout. Hors en fait, nous cherchons, une simple mise à jour du journal pour une Modification. Nous allons donc utiliser l espace disponible dans l ID pour insérer un caractère 1 qui sert de paramètre : - > est la lettre qui signifie de Ne pas mettre à jour le journal ; - + ou * sont les lettres passées uniquement pour l événement moteur Sur sauvegarde nouvel enreg et indiquent au logiciel quel Type d action il doit mettre dans le journal. Ces caractères «paramètres» sont testés dans le code du trigger pour soit simplement lever le caractère et ne rien faire ou soit invoquer une mise à jour du journal différente de celle qui devrait normalement être invoquée. Diapo22 Fichiers d échanges L objectif majeur du système est de ne pas être lié à l utilisation d une connexion réseau entre deux bases 4D. En effet, avec ce type de connexion, une solution basée intégralement sur 4D Open for 4D offre des avantages quant à sa flexibilité. Ici, même si en deuxième partie, nous abordons ce type de connexion, nous somme toujours dans une logique de «petite connexion» et en fait elle ne durera rarement plus d une minute. Sur les bases Esclaves, nous venons de voir que le logiciel est capable de maintenir un journal des événements sur les enregistrements à synchroniser. Ce journal va servir à générer des fichiers d échanges. La méthode projet d export va créer autant de fichier d échange qu il y a de multiple de 2500 enregistrements dans la table journal. Ces fichiers d échanges sont structurés, ils contiennent 2500 séquences : - Action - Numéro de table - Identifiant unique - Enregistrement (sauf quand l action est égale à S Ces fichiers sont créés dans un répertoire temporaire sur le disque et ensuite sont stockés dans une table «Fourre tout» dans un champ blob de façon compressé. Sur la base Maître, la méthode projet d import va traiter un a un les enregistrements de la table «Fourre tout». Pour chacun d eux, elle décompresse le blob et reconstitue le fichier d échange dans un répertoire temporaire. Ce dernier est ensuite lu et chacun des ordres est exécuté. Il faut noter : - Le chiffre de 2500 commandes dans un fichier d échange est arbitraire. Ce nombre est essentiellement lié à la mémoire disponible sur le poste qui les génèrent. En effet, Les commandes DOCUMENT VERS BLOB et COMPRESSER BLOB sont liés à la mémoire allouée à 4D et n accepte pas de fonctionner s il n y a pas assez de mémoire. Le nombre d enregistrements dans un fichier d échange est donc lié à la taille de la mémoire disponible et à la taille moyenne des enregistrements. - Il faut prévoir d implémenter une méthode APPELER SUR ERREUR pour intercepter tous les messages. Ces méthodes fonctionnent sur le serveur normalement. - Il est souhaitable d appeler la commande ECRIRE CACHE avant d exporter les enregistrements 1 Attention, il faut éviter de prendre un caractère qui serait utilisé dans le codage du champ. Par exemple, ici nous utilisons dans le code les 26 lettres de l alphabet + les 10 chiffres.
Diapo23 Avantages Quelques avantages pour cette solution : - En client/serveur la génération de ces fichiers est faite sur le serveur On a mesuré des temps de 3 secondes pour générer un fichier de 2500 enregistrements à transmettre - Les fichiers échangés sont très petits car compactés Un fichier de 2500 enregistrements pèse environ 10 Ko sur le disque. Le compactage le réduit d un facteur de 2 à 3 - Les temps de connexion, si on utilise 4D Open for 4D, sont très court Economie si la connexion n est pas permanente. Licence 4D Client très peu utilisée, donc éventuellement partageable - D autres solutions d échange sont envisageable (certaines peuvent être automatisée comme 4D Open) Email, ftp, disquette - Les contrôles d intégrités lors de la récupération sont fait en local (des règles locales peuvent être mise en place pour rejeter un enregistrement). De plus, en client/serveur ils sont fait par le serveur. L intégration des données se mesure également en quelques secondes Conclusion Diapo24 Dans cette partie nous avons abordé l incidence de la mise en place du système de réplication sur la structure. A ce stade, le système marque les modifications automatiquement par contre, l échange entre les bases de données est seulement manuel. Dans certains cas, où la part humaine est prépondérante (pas de réseau, peut d échange, etc.) la mise en place du processus peut s arrêter là.