blabla, &c.

Problématique

Une application 4D Server double-cliquable ne contient, à l’instant où elle est générée, aucun paramétrage du backup. Ainsi, si on la déploie sans précautions sur le site où elle est utilisée en production, en remplaçant la version précédente (paquet de l’application), le paramétrage courant des sauvegardes est tout bonnement supprimé. La solution consiste à copier le fichier Backup.xml en dehors du paquet de l’application en fonctionnement normal (par exemple à l’arrêt du serveur) puis de réintégrer ce fichier en le recopiant au bon endroit, dans le paquet de l’application, au lancement de la mise à jour.

J’ai préparé un petit module^[1] et je l’ai copié dans une base vierge. (Ce n’est pas une base de test.) Vous pouvez l’utiliser librement s’il vous convient et peut vous être utile. Si vous trouvez des bugs, merci de me les signaler par mail.

Conventions d’écriture

• Les méthodes et les variables sont préfixées par l’identifiant du module hPf.
• Les points d’entrée sont repérés par un 0, qui suit le préfixe.
• Les méthodes dont le préfixe est suivi d’un 9 peuvent être ajustées par le développeur.

Utilisation du module

hPf0_ServerStartUp doit être appelée dans la méthode base Sur démarrage serveur.

hPf0_ServerShutDown doit être appelée dans la méthode base Sur arrêt serveur.

hPf9_CustomValues permet de choisir librement le nom du dossier de préférences qui sera spécifique à l’application concernée, et de paramétrer une option de sauvegarde immédiate après le premier lancement d’une mise à jour.

Ce que fait le module

Le module s’intéresse à deux fichiers Backup.xml, l’un placé à l’emplacement canonique, dans le dossier Preferences qui se trouve dans le même dossier que la structure, et un autre, que nous appellerons custom, placé dans un sous-dossier du Dossier 4D, spécifique à l’application.

Au lancement de l’application serveur, le fichier custom est copié vers l’emplacement canonique, si aucun paramétrage ne s’y trouve déjà.

À l’arrêt du serveur, le fichier canonique est copié à l’emplacement custom, si aucun fichier ne s’y trouve, ou bien si celui qui s’y trouve est plus ancien.

Première utilisation

La première fois que le module est déployé, il ne permet pas de conserver les anciens paramètres de sauvegarde sans avoir préparé le terrain. Plusieurs solutions :

• Paramétrer à nouveau la sauvegarde à la main une fois de plus. Mais ça sera la dernière...
• Recopier à la main les anciens paramétrages dans le paquet de l’appli avant de la lancer.
• Ou bien les copier à la main à l’emplacement custom...

Remarques variées

Sauvegarde immédiate : Après déploiement d’une mise à jour de l’application serveur double-cliquable, le fichier custom est copié et, si l’option correspondante est activée, une sauvegarde est lancée immédiatement. C’est notamment ce qui permet, avec 4D Server 2004.5, de ne pas attendre le prochain lancement du serveur pour que le paramétrage soit pris en compte^[2].

Défauts connus : Comme l’ami Thibaud me l’a gentiment fait remarquer, le module tente de créer des dossiers et de copier des fichiers, sans intégrer la moindre gestion d’erreurs dans cette première version. Ce n’est pas bien sérieux ! même si, a priori, ça devrait bien se passer en général. L’idée de ce petit module, c’est de ne supposer la présence d’aucun shell, et c’est là généralement que l’on centralise le gestion des erreurs. Vous pouvez y greffer votre propre gestion d’erreurs, assez simplement je crois. À l’occasion, j’améliorerai le module pour qu’il prenne en compte les erreurs que l’on peut raisonnablement rencontrer, et sache alerter l’utilisateur si tout ne se passe pas comme souhaité...

Remerciements : Merci à Pascal Pradier et à Christophe Keromen de leur aide. Merci à Thibaud Arguillère de ses commentaires.

Avertissement : Foucauld Pérotin et Teluric n’offrent aucune garantie d’aucune sorte sur le bon fonctionnement de ce module.