Mise à jour auto des applications serveur ou monopostes

4D v16.3

Finaliser et déployer les applications finales

En principe, la mise à jour des applications serveur ou monopostes fusionnées nécessite une intervention de l’utilisateur (ou la programmation de routines système personnalisées) : lorsqu’une nouvelle version de l’application fusionnée est disponible, il est nécessaire de quitter l’application en production, remplacer manuellement les anciens fichiers par les nouveaux, relancer l’application et sélectionner le fichier de données courant.

Vous pouvez largement automatiser ce processus à l’aide des commandes du langage suivantes : SET UPDATE FOLDER, RESTART 4D ainsi que Get last update log path pour le suivi des opérations. Le principe consiste à implanter dans votre application 4D une fonction déclenchant la séquence de mise à jour automatique décrite ci-dessous. Il peut s’agir d’une commande de menu ou d’un process tournant en tâche de fond et scrutant à intervalle régulier la présence d’une archive sur un serveur FTP.

Le scénario d’une mise à jour d'une application serveur ou monoposte fusionnée est le suivant :

Vous transférez, par exemple via un serveur FTP, la nouvelle version de l’application serveur ou monoposte fusionnée sur le poste en production.
Dans l’application en production, vous appelez la commande SET UPDATE FOLDER : cette commande désigne l’emplacement du dossier contenant la mise à jour "en attente" de l’application courante.
Optionnellement, vous pouvez recopier dans ce dossier les éléments personnalisés de la version en production (fichiers utilisateurs).
Dans l’application en production, vous appelez la commande RESTART 4D : la commande déclenche l’exécution d’un programme utilitaire nommé "updater" qui va quitter l’application courante, la remplacer en utilisant la mise à jour "en attente" si elle été définie, et la relancer avec le fichier de données courant. L’ancienne version est alors renommée.

Notes :

Ce fonctionnement est compatible avec les applications serveur Windows exécutées en tant que Service (cf. section Enregistrer une base comme service).
Vous disposez également des clés XML permettant d’élever les privilèges d’installation afin d’utiliser les dossiers protégés sous Windows (cf. manuel 4D Clés XML BuildApplication).

Journal des mises à jour

Le processus de mise à jour produit un fichier journal détaillant les opérations de mise à jour des applications fusionnées (clientes, serveur ou monoposte) sur les postes cibles. Ce fichier est utile pour analyser les éventuelles erreurs survenues durant le processus d’installation.

Le journal des mises à jour est nommé AAAA-MM-JJ_HH-MM-SS_log_<sequence>.txt, par exemple 2013-08-25_14-23-00_log_1.txt pour un fichier créé le 25 août 2013 à 14h23.

Ce fichier est créé dans le dossier de l’application "Updater", c’est-à-dire :

sous OS X :
{userName}/Library/Appplication Support/{ProductName}/4D/Updater/

sous Windows :
\{userName}\AppData\Roaming\{ProductName}\4D\Updater\

Vous pouvez à tout moment connaître l’emplacement de ce fichier à l’aide de la commande Get last update log path.