Présentation. Logistique. Résumé de la 1e Partie. Mise en place du système

Transcription

1 Présentation Diapo01 Je m appelle Michel Canneddu. Je développe avec 4D depuis 1987 et j exerce en tant qu indépendant depuis 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 Résumé de la 1e Partie Diapo03 En première partie nous avons vu que le système permet de 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. 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. Diapo04 Nous avons vu les outils nécessaires pour mettre en place : 1. Des paramètres globaux 2. Un système d identification unique des enregistrements des tables à synchroniser 3. Une table journal qui mémorise toutes les modifications sur les tables à synchroniser 4. Deux méthodes l une qui créée, l autre qui lie, des fichiers d échange stockés provisoirement dans un champ blob de la table «Fourre tout» Actuellement, le système n offre pas d automatisme pour : - La génération des fichiers d échanges - L envoi de ces fichiers - L intégration de ces fichiers Mise en place du système Diapo05 Pour automatiser certains processus, nous devons mettre en place des procédures stockées qui sont démarrées et arrêtées automatiquement respectivement au démarrage et à l arrêt de l application. En mode client/serveur ces méthodes sont exécutées sur le serveur. En monoposte ces méthodes sont exécutées localement.

2 Diapo06 Les méthodes bases Sur démarrage serveur Cette méthode est exécutée une seule fois sur le poste serveur lorsque vous ouvrez une base avec 4D Server. En environnement client/serveur, nous installons ici le code nécessaire pour lancer les procédures stockées Sur ouverture Cette méthode est exécutée une seule fois, au moment de l'ouverture de la base. Les environnements 4D suivants sont concernés : - 4e Dimension - 4D Client (sur le poste client une fois que la connexion a été acceptée par 4D Server) - 4D Runtime - Application 4D compilée par 4D Compiler et fusionnée avec 4D Engine En environnement monoposte, nous installons ici le code nécessaire pour lancer les procédures stockées. En environnement client/serveur, nous installons ici le code nécessaire pour obtenir les numéros de process des procédures stockées qui tournent sur le serveur. Sur arrêt serveur Cette méthode est appelée une fois sur le poste serveur lorsque vous quittez 4D Server et donc la base. En environnement client/serveur, nous installons ici le code nécessaire pour avertir les procédures stockées de l arrêt du serveur et leurs laisser le temps de s arrêter toutes seules et ainsi d éviter qu elles soient tuées en cours d exécution. Sur fermeture Cette méthode est exécutée une seule fois lorsque l on quitte la base. Les environnements 4D suivants sont concernés : - 4e Dimension - 4D Client (côté client) - 4D Runtime - Application 4D compilée par 4D Compiler et fusionnée avec 4D Engine En environnement monoposte, nous installons ici le code nécessaire pour avertir les procédures stockées de l arrêt du poste et leurs laisser le temps de s arrêter toutes seules et ainsi d éviter qu elles soient tuées en cours d exécution. En environnement client/serveur, on ne fait rien ici. Sur fermeture connexion serveur Cette méthode est exécutée à chaque déconnexion d un client du serveur.

3 Diapo07 La communication des variables entre les process et entre un client et un serveur Les variables ont une portée selon leur type : locale, process, interprocess. Des échanges de variable ayant une portée insuffisante sont possibles grâce aux commandes ECRIRE VARIABLE, LIRE VARIABLE et VARIABLE VERS VARIABLE. Dans le cas des échanges de variable ou de modification de variable commune (interprocess) il faut utiliser les Sémaphores globaux pour se prémunir d un accès concurrent à la même valeur. Pour les échanges de valeur avec un client et son serveur, il faut savoir : - Que les process qui fonctionnent sur le serveur ont un numéro négatif ; - Seul le client peut lire ou écrire les variables d une procédure stockée Pour écrire dans un tableau d un process serveur, il faut : 1. Récupérer le tableau sur le poste client grâce à la commande VARIABLE VERS VARIABLE 2. Faire le traitement sur le tableau 3. Renvoyer le tableau sur le serveur grâce à la commande VARIABLE VERS VARIABLE Note : Il faut faire attention que la variable contenant le numéro du process attribué au Service soit : - Négative, si le service est exécuté par le serveur ; - Positive, si le service est exécuté en local (exploitation monoposte). - Egal à zéro si le service ne fonctionne pas (il faut donc la forcer à zéro en tuant le process) ; Diapo08 Procédure stockée «Service» La méthode «Service» est une procédure stockée qui est lancée automatiquement par la méthode base Sur démarrage serveur ou Sur ouverture en fonction du mode d exploitation. Elle permet de recevoir et de répondre à des ordres pouvant provenir de n importe quels clients. Cette méthode est une boucle qui tourne tant que le serveur n est pas arrêté. La signalisation de l arrêt du serveur est faite par une variable interprocess positionnée par les méthodes bases invoquées en cas de fermeture. Les ordres sont passés dans un tableau interprocess qui sert de pile d exécution gérée par la méthode FIFO (premier entré, premier sorti). Les paramètres sont soit passés au travers d enregistrements d une table, soit passés au travers de variables grâce aux commandes VARIABLE VERS VARIABLE. La méthode «Service» est uniquement une tour de contrôle qui reçoit des ordres et les exécutent ou les donnent à exécuter. En effet, les exécutions des commandes par cette méthode peuvent être : - Synchrone, le service exécute un ordre après l autre - Asynchrone, le service lance ou réveille un process d exécution pour la commande et est immédiatement disponible pour d autres demandes. Bien entendu, dans les deux cas, la pile d exécution du service est toujours disponible pour y ajouter des ordres. Adaptation des méthodes bases Diapo09 - Sur démarrage serveur et Sur ouverture pour démarrer le «Service» - Sur arrêt serveur et Sur fermeture pour arrêter le service - Sur fermeture connexion serveur pour démarrer le processus d intégration pour la base maître (en cas d échange 4D open)

4 Méthodes de synchronisation Diapo10 Procédure stockée «Synchro_Out» La méthode Synchro_Out est typiquement une exécution Asynchrone d une commande du service. Lorsque l utilisateur modifie dans les paramètres globaux l information sur la Synchronisation active, le logiciel place sur la pile d exécution une commande «Synchro_Out». La méthode service, lorsqu elle exécute cet ordre effectue les contrôles suivant : Si une demande d activation est faite, elle contrôle si un process de synchronisation existe : - S il n existe pas, elle le crée - S il existe, elle le réactive. Si une demande d arrêt est faite, elle contrôle si un process de synchronisation existe : - S il n existe pas, elle ne fait rien - S il existe, elle le réactive. L usage d une méthode «Service» pour lancer ou arrêter un autre process est essentiel. En effet, la commande REACTIVER PROCESS a une portée uniquement sur les process du poste client. Ici, le Service tourne à coté du process de synchronisation, il peut donc le gérer en lui passant ce type de commande. La synchronisation utilise le plug-in 4D Open pour 4D. Il faut cocher sur le dialogue des Propriétés de la base que l application accepte les connexions avec 4D Open. Architecture de la méthode Diapo11 Synchro_Out La finalité de cette méthode est de générer les fichiers d échanges sur les bases Esclaves et de les envoyer à la base Maître. Cette méthode est, en fonction des paramètres globaux, déclenchées par la méthode «Service» et exécutée sur le poste faisant tourner le moteur de la base de données. Le corps de la méthode doit simplement permettre de déclencher une sous méthode «Synchro_Out_1» à un pas de temps défini en paramètre. Entre deux exécutions, cette méthode s endort. Il faut veiller à ne pas l endormir pour la durée fixée en paramètre mais pour cette durée réduite de la durée d exécution de la sous méthode.

5 Synchro_Out_1 Diapo12 Cette méthode utilise le plug-in 4D Open for 4D. Elle établit une connexion avec le serveur maître et ensuite enchaîne l exécution des méthodes d échange. 1. Contrôle du numéro de version Ce contrôle est réalisé grâce à une mise en relation entre la le champ version de la table des paramètres globaux de la base Maître et une variable tableau de même type en local 2. Création des fichiers d échanges et suppression des éléments du journal envoyés Lance automatiquement la méthode d export décrite dans la première partie 3. Envoi des fichiers d échanges contenus dans la table Fourre tout Cet échange est réalisé grâce à une mise en relation de la table Fourre tout de la base Maître et la même table sur la base Esclave Toutes les commandes du plug-in 4D Open for 4D sont des fonctions. Elles renvoient toujours un code d erreur qui est à 0 si la fonction s est exécutée correctement ou à une valeur positive ou négative dans le cas contraire. La fonction OP Get error text renvoie une chaîne alphanumérique correspondant à la signification du code d erreur passé en paramètre. Si vous souhaitez connaître la cause d un échec d exécution d une fonction 4D Open for 4D il ne faut surtout pas utiliser de dialogue d alerte ou autres fenêtres. Le processus de synchronisation qui invoque ces fonctions est exécuté sur le serveur et personne ne peut les voir. Il faut créer un fichier texte qui sera le journal d erreur. Synchro_In Diapo13 Cette méthode est déclenchée par le Service. Sur fermeture connexion serveur, lorsque le nom d utilisateur qui se déconnecte est l utilisateur dédié à la synchro, le logiciel ajoute dans la pile d exécution du Service la commande Synchro_In. La méthode service, lorsqu elle exécute cet ordre ne fait que lancer la méthode d import décrite dans la première partie. Echange de données, 1 vers n Diapo14 Ici, nous sommes capables de synchroniser des données unilatéralement, et grâce à l emploi de 4D Open for 4D d automatiser les échanges. Il faut toutefois souvent prévoir un échange de données du Maître vers les Esclaves pour certaines informations. C est le cas des tables de référentiel. Par référentiel nous entendons la ou les tables qui contiennent des informations sur le codage (Pays, Taux de TVA, Département).

6 Diapo15 Table Liste Imaginons une table [Liste] contenant toutes les listes de code utilisées dans la base de données. Chaque enregistrement est normalement caractérisé par : - Un numéro de liste - Un Code - Un Libellé Pour chaque liste, un enregistrement ne contient pas de code, s est l enregistrement Titre de liste qui porte le nom de la liste. Le système proposé ne s appuie pas sur un journal. En effet, il faut qu il soit adaptable dynamiquement quel que soit le nombre de bases Esclaves qui doivent être informées d une mise à jour. Une solution est donc d ajouter un champ «Numéro de mise à jour» qui est incrémenté automatiquement après chaque modification, à la fois sur l enregistrement mis à jour mais également sur l enregistrement titre. Le fait de modifier le numéro de version sur l enregistrement titre permet : 1. De maintenir un compteur de modification par Liste 2. Surtout de tracer les suppressions Il existe bien entendu d autres méthodes, la difficulté étant de tracer les suppressions. Une des méthodes également souvent utilisée, est de ne pas supprimer les enregistrements mais seulement de les «cocher» comme supprimé pour le logiciel. Diapo16 Synchro_Out_13 L échange d information pour la table Liste à lieu pendant la synchronisation des bases Esclaves. C est au moment de la connexion, après avoir contrôlé que les numéros de version sont identiques, qu il est nécessaire d insérer le code pour échanger les modifications de cette table. Pour résumer, le code s appuie sur la comparaison du nombre de liste entre la base Maître et la base Esclave connectée. Si une liste n existe pas sur la base Esclave, il faut la créer. Si une liste n existe plus sur la base Maître, il faut la supprimer de la base esclave. Si la liste existe dans les deux bases, il faut comparer leurs numéros de mises à jour. Si le numéro est identique, on ne fait rien Si le numéro est différent, le système compare alors les éléments de la liste entre la base Maître et la base Esclave connectée. Si un élément n existe pas sur la base Esclave, il faut le créer. Si un élément n existe plus sur la base Maître, il faut le supprimer de la base esclave. Si un élément existe dans les deux bases, il faut comparer leurs numéros de mise à jour. Si le numéro est identique, on ne fait rien Si le numéro est différent, le système modifie l enregistrement de la base Esclave connectée.

7 D autres solutions Diapo17 La solution décrite pour automatiser les échanges fonctionnent avec 4D Open for 4D. Cela nécessite d avoir : - Un Serveur 4D en tant que base maître ; - Une liaison réseau pendant le transfert des données. Il peut arriver que le système en place ne puisse pas être adapté à 4D Open pour différente raison. - La base maître ne tourne pas sous 4D Serveur - La connexion réseau entre le site Esclave et le site Maître ne peut pas être réalisée - L administrateur réseau interdit une connexion réseau sur la base Maître à partir d une adresse Internet Diapo18 Le système étant basé sur des échanges de fichier, il peut également être totalement automatisé grâce à d autres commandes Nous pouvons en effet imaginer l échange des fichiers grâce : - Aux commandes Internet de 4D qui permettent de faire soit du ftp, soit de l - A ITK qui permet également la même chose Avec ces solutions, un simple compte suffit. Le système étant basé sur des échanges de fichiers la procédure Synchro_Out créé et envoi des avec une pièce jointe. La procédure Synchro_In, doit lire à pas de temps paramétrable son courrier. Conclusion Diapo19 Les avantages de cette solution : - Peut être adaptée à tous les types de transfert de données - En cas de connexions réseaux, elles ont extrêmement courte Exemple : Sur un réseau Ethernet, le temps de connexion pour transmettre les données d une base de 100 Mo est inférieur à la minute. - En client/serveur, ce sont des procédures stockées qui font les extractions et les intégrations. Les performances sont multipliées - C est le serveur qui intègre les données reçues et non le client qui lui écrit. Il est donc plus facile de mettre en place des contrôles liés à la plate-forme de réception. - Système facilement adaptable à d autres configurations.