Paramétrages de la sauvegarde pour les applications distribuées

Habituellement, lorsque l'on développe une base 4D, le développeur se concentre sur la bonne exécution des principales fonctionnalités. Ainsi pour les applications redistribuables (basées sur un 4D Runtime ou un 4D Server), tester des fonctionnalités basiques comme la sauvegarde ou la génération d'application sont habituellement les dernières étapes. Cette note technique s'intéresse aux étapes trop souvent oubliées de la mise en place des préférences de la sauvegarde pour les applications distribuées.

Voici un scénario typique…

Le développement de la base est terminé. Le développeur teste l'application ainsi que le système de sauvegarde. Tout semble fonctionner. Notez qu’en testant la sauvegarde, un fichier de projet, Backup.xml, est créé. Le développeur est maintenant prêt pour tester la base en tant qu'application Server enginée.

Pourtant, une fois l'application construite, tous les fichiers n'ont pas été copiés à l'intérieur du dossier du Serveur. Il est en ainsi des fichiers du dossier « Preferences ». Aussi le développeur doit copier quelques fichiers du dossier « Préférences » dans le nouveau dossier du Serveur.

Mais le développeur ne devrait pas copier complètement le dossier « Préférences », car il contient souvent des fichiers non nécessaires comme le fichier xml utilisé pour construire l'application.

À ce point, l'application fonctionne sur la machine de développement. L'étape suivante est donc la copie et le lancement de l'application sur une autre machine. C'est ici que l'on rencontre souvent le problème.

Un dossier ne peut pas être trouvé.
4D demande à l'utilisateur de sélectionner un nouvel accès au dossier.
Que se passe-t-il alors ?
Comment empêcher ce message ?

Le problème vient du fichier Backup.xml. Dans ce fichier, il y a un chemin d'accès au dossier où tous les fichiers de la sauvegarde seront stockés. Depuis que la base a été déplacée sur une nouvelle machine, ce chemin d'accès n'est plus valide. En outre, 4D demande qu'un nouveau chemin d'accès soit choisi avant le lancement de la base en fonction des paramétrages du Backup, ou si une sauvegarde a été demandée par programmation au lancement. Ainsi 4D a besoin dès l'ouverture d'avoir un chemin d'accès valide.

Comment le développeur peut-il empêcher ce dialogue ? Une solution est de ne pas copier le fichier Backup.xml lorsque l'on déplace la base. Si une sauvegarde est demandée et qu'il n'y a pas de fichier Backup.xml, 4D en créera un nouveau avec les valeurs par défaut. À ce stade, la sauvegarde peut être lancée.

Notez que lorsqu'une base lance une sauvegarde pour la première fois, 4D lance le BackUp et crée le fichier par défaut Backup.xml dans le dossier « Préférences\BackUp », à côté de la structure. Ceci est aussi vrai pour les applications « packagée ». Si vous donnez une application enginée avec 4D Server, sans projet de Backup, 4D sera toujours capable de sauvegarder et générera un fichier de projet de sauvegarde par défaut pour l'application. Dans de nombreux cas, ceci permet à 4D de continuer à fonctionner et ce comportement par défaut est totalement adéquat.

Mais les valeurs par défaut peuvent ne pas correspondre à vos besoins et le développeur peut vouloir définir quelques paramétrages du BackUp, comme le nombre d'archives à manipuler, des fichiers à archiver en plus, quelques paramétrages avancés pour accélérer la sauvegarde ou plus spécifiquement, le développeur peut envisager une périodicité différente de celle installée par défaut. Dans ce cas, le développeur doit fournir son propre fichier de projet de sauvegarde. Ici est le dilemme : le développeur peut utiliser ses propres paramétrages, mais alors ils utiliseront un chemin d'accès invalide puisque le chemin d'accès au dossier de sauvegarde ne sera plus valide après déplacement de la base.

Une fois admis que le développeur peut avoir besoin de spécifier ses propres valeurs dans le fichier Backup.xml, une meilleure solution doit être trouvée pour personnaliser le fichier Backup.xml au démarrage de l'application. 4D possède des commandes pour analyser et écrire les documents XML.

Le développeur doit juste connaître les balises XML à utiliser. La structure de ces balises et le processus pour générer le document est très facile. Si le développeur ne veut pas que l'utilisateur intervienne dans ce processus, il peut créer le document dans la Méthode base Sur Ouverture ou Sur demarrage serveur. À l'ouverture de la base, le développeur peut vérifier si le fichier de projet de BackUp existe ou non. Si ce fichier n'existe pas, le développeur peut créer un nouveau fichier XML. L'utilisateur ne remarquera même pas cette opération. Le BackUp sera prêt.

Si le développeur veut que l'utilisateur soit informé de la création de ce fichier Backup.xml et lui donner la possibilité de modifier des paramétrages, alors le dialogue peut être affiché pour que l'utilisateur fasse ses modifications. En fonction des valeurs du développeur et des modifications de l'utilisateur, on peut par programmation régénérer le fichier Backup.xml.

Notez que le développeur doit s'assurer que le fichier XML généré est bien formé, c'est-à-dire que tous les paramètres sont valides ou qu'il n'y a pas d'espaces supplémentaires à la fin des valeurs. Sinon 4D mettra à la place ses propres valeurs par défaut pour chaque objet mal-formé.

Il existe déjà une base de démonstration, « Backup Preferences », montrant comment analyser et modifier ce fichier (http://www.4d.com/2004/examples.html).

L'inconvénient de cette technique est que le code XML doit être stocké à l'intérieur de 4D, avec une liste de commandes XML qui inséreront le « namespace », les balises et les valeurs dans l'arbre XML. Si des changements interviennent un jour, le développeur doit modifier ce code.

Une autre façon de faire est d'avoir le fichier Backup.xml en dehors de l'application, dans un fichier XML qui sera utilisé comme un modèle. Si le format XML change, tous les développeurs doivent changer ce fichier de modèle XML ; il sera alors inutile de modifier le code 4D, à part une nouvelle variable qui doit être déclarée et initialisée.

Comment cela fonctionne-t-il ? L'idée est d'avoir un fichier modèle BackUp.xml dans lequel toutes les valeurs sont définies par des balises HTML 4D. Ces variables devront être prédéfinies dans le code 4D. Notez que le code 4D n'utilisera pas de commandes XML ; il chargera simplement le modèle et exécutera la commande TRAITER BALISES HTML sur celui-ci. Une fois que le modèle a été exécuté, il peut être stocké en tant que fichier Backup.xml dans dossier « Préférences » de la base.

Un fichier de modèle XML est fourni avec la base de démonstration. Son nom est « Backup.xml2 » et se trouve dans le dossier « Préférences\Backup ».

Voici un résumé des étapes utilisées dans cette technique

• Après construction de la base enginée, le développeur est supposé copier le dossier « Préférences\Backup » dans le dossier « Server ». Au lieu de copier le fichier Backup.xml, il copie juste le modèle, c'est-à-dire le fichier Backup.xml2.
• Lorsqu'il lance la base, la Méthode base Sur démarrage serveur vérifiera si le fichier Backup.xml existe.
• Pour obtenir le chemin d'accès du dossier « Préférences », la technique utilisée consistera à récupérer le chemin d'accès du dossier « Extras » (avec la commande Dossier 4D) et obtenir le chemin d'accès du dossier « Préférences ». Une autre technique serait d'utiliser le chemin d'accès à la structure à la place. Mais l'utilisation du dossier « Extras » est simple et rapide.
• Une fois que le chemin d'accès a été obtenu, la fonction Tester chemin acces peut être utilisé sur ce chemin d'accès pour vérifier si le fichier Backup.xml existe ou pas.
• Si un fichier Backup.xml existe, cela signifie que les paramétrages de la sauvegarde ont déjà été mis en place. La base de données est paramétrée et peut continuer son exécution.

• Si le fichier n'existe pas, il faut envisager une nouvelle installation. À ce stade, le développeur a différents choix sur la façon de créer le fichier Backup.xml :

  1. le développeur peut faire cela de façon complètement transparente pour l'utilisateur. il peut générer le fichier Backup.xml avec ses propres variables prédéfinies ;
  2. si le développeur veut donner à l'utilisateur la possibilité de choisir le dossier maintenant ou plus tard, un dialogue peut être utilisé ;
  3. enfin, le développeur peut offrir à l'utilisateur des contrôles directs sur les paramétrages de la sauvegarde. Un dialogue sur les paramétrages avancés de la sauvegarde est fourni dans cette base exemple. Le développeur peut utiliser le dialogue fourni, ou utiliser son propre dialogue, avec plus ou moins d'options.

Dans la base de démonstration, un simple dialogue est affiché où l'utilisateur choisit le dossier de destination de la sauvegarde. Ce dialogue contient aussi un bouton permettant d'afficher les paramétrages avancés qui couvrent toutes les options que l'on peut avoir dans le dialogue des Préférences de la sauvegarde. La commande TRAITER BALISES HTML est ensuite utilisée pour manipuler le modèle Backup.xml2 et stocker le résultat dans le fichier Backup.xml du dossier « Préférences ».
Voilà !

Ce fichier est simplement un projet de sauvegarde 4D par défaut, avec quelques modifications. Presque toutes les valeurs ont été remplacées par des balises 4D telles que 4DVAR, avec quelques 4DIF lorsque les valeurs peuvent être différentes.

Voici la liste des variables utilisées dans le fichier modèle (et définies dans le dialogue des paramétrages avancés), avec les balises XML correspondantes.