Français
  • A propos du composant BSPK
  • ATL
  • BWEB
  • Historique des versions
  • FAQ

    • Les mises à jour de version

    Quand une nouvelle version de votre application (ou du composant) démarre, elle met à jour les données et la configuration grâce à des méthodes de mise à jour, une par version qui en a besoin. Elles s'exécutent une seule fois, au démarrage, dans l'ordre des versions.

    Les numéros de version

    Le numéro de votre application se trouve dans votre méthode BSPH_VERSION_UPDATES :

    $vl_DeliveryVersion:=1   // majeure
$vl_InternalVersion:=0   // mineure

    Ce sont les numéros de votre application, pas ceux de BWEB : une installation neuve démarre à 1.0. L'écran de build les fait monter pour vous (voir Construire une version).

    Le niveau installé est enregistré dans la table BSPK, un enregistrement pour le composant (BSPK) et un pour votre application (HOST) : currentVersion = version de 4D × 1 000 000 + majeure × 1 000 + mineure (par exemple 21001000). À la première installation, cet enregistrement est créé directement à la version courante : aucune mise à jour ne s'exécute.

    Au démarrage

    1. Les mises à jour du composant s'exécutent d'abord.
    2. Si elles ont réussi, celles de votre application (BSPH_VERSION_UPDATES).
    3. Si tout a réussi, le contenu livré avec la version est appliqué (voir La réconciliation du contenu). En cas d'échec, cette livraison est reportée.

    Les mises à jour ne s'exécutent que sur 4D Server ou en monoposte, jamais sur un poste client.

    Écrire une méthode de mise à jour

    Déclarez la version dans BSPH_VERSION_UPDATES :

    $vc_Updates.push("21.1.1")  // 06/10/2026 — ajout du paramètre X

    puis créez la méthode correspondante, UPDATE_21_1_1 :

    //%attributes = {"shared":true,"preemptive":"capable"}
#DECLARE->$vb_PasFini : Boolean
// … migrer des données, ajouter une clé de paramètre, créer une tâche planifiée …
return False
    • Le nom : UPDATE_ suivi de la version, les points remplacés par des soulignés. Le préfixe est UPDATE_, pas UTIL_UPDATE_ (d'anciennes copies de BSPH_VERSION_UPDATES l'indiquent à tort).
    • Partagée avec les composants : c'est le composant qui l'exécute. Préemptive de préférence : sur un serveur, le démarrage peut tourner dans un process préemptif.
    • Le retour : False quand c'est terminé ; True pour dire « pas fini, redémarre et reprends » — la version n'est alors pas enregistrée et la méthode est rejouée au démarrage suivant.
    • Seules les versions supérieures à celle installée s'exécutent, dans l'ordre de la liste ; après chaque succès, la version installée avance d'un cran.
    • Ce qu'une mise à jour écrit dans les pages est marqué comme technique : la livraison suivante ne le prend pas pour une modification locale.

    Quand une mise à jour échoue

    Si la méthode renvoie True, 4D redémarre pour la rejouer, deux fois au plus. Au troisième échec consécutif, une alerte s'affiche et l'application démarre sans monter la version : vous gardez la main pour corriger, et la mise à jour sera retentée au démarrage suivant. Tant qu'une mise à jour échoue, les suivantes et la livraison du contenu attendent.

    Ajouter un paramètre

    Les fichiers de paramètres ne se livrent pas : une clé nouvelle s'ajoute par une méthode de mise à jour. Lisez APP_PARAMETERS (BSPK_FILE_Get_JSON_Content), ajoutez la clé dans vo_Param seulement si elle est absente, réécrivez le fichier (BSPK_FILE_SET_JSON_CONTENT) seulement s'il a changé, et reportez la valeur dans Storage.vo_Param.

    Bon à savoir

    • Une méthode mal nommée ou non partagée est sautée, et la version monte quand même. Une assertion « Méthode Update introuvable » se déclenche, puis la version installée passe à la cible : cette mise à jour ne s'exécutera plus jamais. Vérifiez le nom et l'attribut partagé.
    • Écrivez des mises à jour rejouables : un redémarrage, une erreur ou un abandon au troisième échec les font repartir du début.
    • Testez-les en monoposte ou sur le serveur : rien ne s'exécute sur un poste client.

    Voir aussi