17.15 Installation et ou mise à jour d'applications et de familles

17.15.1 Introduction

Le déploiement d'une application (ou d'une famille) est le terme utilisé pour le processus d'installation d'applications (ou de familles) dans un contexte Dynacase.

Le déploiement s’effectue à l'aide de dynacase-control soit en mode Web soit en mode CLI en installant un module.

Un module est une archive dans un format spécifique (nommé webinst) qui contient les éléments à déployer et les directives pour l'initialisation et/ou le chargement de ces éléments.

Techniquement, un module est une archive TAR compressée GZIP avec l'extension .webinst qui contient les fichiers suivants :

Un fichier content.tar.gz

Ce fichier est une archive TAR compressée GZIP contenant l'ensemble des fichiers (applications et familles) à déployer dans le contexte Dynacase.

Cette archive contient donc tous les fichiers qui seront déployés dans le contexte, les chemins de ces fichiers sont relatifs à la racine du contexte et suivent l'organisation et la structure d'un contexte Dynacase.

Un fichier info.xml
Ce fichier contient les informations sur le module (nom, version, etc.) et les directives d'initialisation et/ou de chargement des éléments livrés par content.tar.gz ci-dessus.

Voir :

17.15.2 Structure d'un contexte Dynacase

Un contexte Dynacase suit une structure déterminée de répertoires.

<context-root>

La racine du contexte contient les fichiers index.php et admin.php qui sont les points d'entrés pour l'accès Web à Dynacase.

Vous n'avez pas à livrer de contenu dans la racine même du contexte.

<context-name>/<APPNAME>

Les répertoires en majuscules (e.g. MYAPP) dans la racine du contexte contiennent les fichiers des applications Dynacase.

C'est dans ces répertoires que vous devez livrer les fichiers de classe de vos familles, les fichiers d'actions et les layouts de vos applications.

Voir :

<context-root>/EXTERNALS

Ce répertoire contient les fichiers d'aides à la saisie.

C'est dans ce répertoire que vous devez livrer les fichiers d'aides à la saisie de vos familles.

Voir :

<context-root>/API

Ce répertoire contient les scripts d'API exécutables par la commande CLI wsh.

C'est dans ce répertoire que vous devez livrer vos scripts d'API.

Voir :

<context-root>/Images

Ce répertoire contient les icônes des familles.

C'est dans ce répertoire que vous devez livrer les icônes de vos familles.

Voir :

<context-name>/locale/fr/LC_MESSAGES/src et <context-root>/locale/en/LC_MESSAGE/src

Ce répertoire contient les fichiers source (<APPNAME>.po) de localisation des applications.

C'est dans ce répertoire que vous devez livrer vos fichiers source de localisation .po.

Voir :

17.15.3 Déploiement des applications

17.15.3.1 Architecture de l'application sur le serveur

Comme vue précédemment dans structure d'un contexte Dynacase, une application est composée d'un répertoire nommé avec le nom de l'application en majuscule.

Ce répertoire MYAPP doit contenir au moins :

Un fichier MYAPP.app (nom de l'application en majuscule + extension .app)

contenant la déclaration du nom, description, etc. de l'application (variable $app_desc) et les éventuelles actions de l'application (variable $action_desc).

Exemple fichier MYAPP/MYAPP.app :

<?php
 
$app_desc = array(
    "name"        => "MYAPP",
    "short_name"  => "Mon application",
    "description" => "Mon application de test",
    "icon"        => "myapp.png",
    "displayable" => "Y",
    "childof"     => "ONEFAM"
);
 
$action_desc = array(
    array(
        "name"       => "MYACTION1",
        "short_name" => N_("MYAPP:action one"),
        "acl"        => "MYAPPACL1"
        "root"       => "Y"
    )
);
Un fichier MYAPP_init.php (nom de l'application en majuscule + _init.php)

contenant la version et la déclaration des éventuels paramètres de l'application (variables $app_const).

Exemple fichier MYAPP/MYAPP_init.php :

<?php
 
$app_const = array(
    "VERSION" => "1.0.3-1", // Paramètre minimum obligatoire
    "MYAPP_PARAM_FOO" => array(
        "val" => "1",
        "descr" => N_("MYAPP:Description of parameter foo"),
        "global" => "Y",
        "user" => "N"
    )
);

L'icône myapp.png référencée par la variable $app_desc['icon'] est à placer dans le répertoire MYAPP/Images.

Le fichier MYAPP/myaction1.php de l'action MYACTION1 déclarée :

<?php
 
function myactions1(Action & $action) {
    $action->lay->eSet("MESSAGE", "Hello world.");
}

Le fichier de layout MYAPP/Layout/myaction1.xml de l'action MYACTION1 :

<html>
<title>My Action 1</title>
<body>
<p>[MESSAGE]</p>
</body>
</html>

Si l'application est localisée, alors les fichiers de locale doivent être dans le sous-répertoire locale en suivant le format GNU gettext décrit dans le chapitre Internationalisation.

Exemple fichier locale/en/LC_MESSAGES/src/MYAPP.po :

msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n>1\n"
 
msgid "MYAPP:Description of parameter foo"
msgstr "Paramètre foo"
 
msgid "MYAPP:action one"
msgstr "Action Un"

Exemple fichier locale/fr/LC_MESSAGES/src/MYAPP.po :

msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n>1\n"
 
msgid "MYAPP:Description of parameter foo"
msgstr "Parameter foo"
 
msgid "MYAPP:action one"
msgstr "Action One"

Une fois la structure de l'application établie, vous pouvez générer l'archive content.tar.gz avec le contenu de votre application (répertoire MYAPP) et les éventuelles locales (répertoire locale).

Remarques :

  • La notion de modules et de versions de modules n'a de sens qu'au sein de dynacase-control. De la même manière, la notion d'applications et de versions d'applications n'a de sens qu'au sein de Dynacase.
  • La version de l'application peut ne pas être la même que la version du module.
  • Un module d'une version donnée peut livrer plusieurs applications avec chacune leur version distincte.
  • C'est la version de l'application est utilisée pour déclencher les scripts de pre-migration et de post-migration (voir Mettre à jour une application ci-dessous).

Voir :

17.15.3.2 Enregistrer une application

Une fois les fichiers à livrer empaquetés dans l'archive content.tar.gz, il faut créer le fichier info.xml avec les instructions nécessaires au chargement de ces éléments.

Après que l'application contenue dans l'archive content.tar.gz ait été décompressée dans le contexte, il faut enregistrer cette dernière auprès de Dynacase lors de l'installation du module et lors de l'upgrade du module.

L'enregistrement d'une application auprès de Dynacase s'effectue à l'aide de la commande program/record_application qui prend en argument :

<APPNAME>
Le nom de l'application que l'on souhaite enregistrer.
I ou U
I pour l'enregistrement lors de l'installation (Install) et U pour l'enregistrement lors de la mise à jour (Upgrade).

Cette commande ne peut être exécutée que dans l'environnement de dynacase- control. Voir Exécution manuelle ci-dessous pour exécuter manuellement ces commandes.

Si des catalogues de locales sont livrées, il faut alors les prendre en compte à l'aide de la commande programs/update_catalog (qui ne prend pas d'arguments).

Exemple de fichier info.xml :

<xml version="1.0" encoding="utf-8">
<module name="my-module" version="1.0.3" release="1">
 
    <requires>
        <module name="dynacase-core" comp="ge" version="3.2.0" />
    </requires>
 
    <post-install>
        <process command="programs/record_application MYAPP I" />
        <process command="programs/update_catalog" />
    </post-install>
 
</module>

Enfin, on peut générer le module final my-module-1.0.3-1.webinst en empaquetant le fichier content.tar.gz et le fichier info.xml.

Voir :

17.15.3.3 Mettre à jour une application

On dit qu'un module est mis à jour lorsque la version déclarée dans la propriété version dans le fichier info.xml est supérieure à la version du module actuellement installé.

Dans ce, c'est la section <post-upgrade/> qui est exécutée et non plus la section <post-install/>.

Pour mettre à jour une application, lors de la mise à jour d'un module, il faut alors ré-enregistrer l'application pour mettre à jour sa définition par rapport au niveaux fichiers livrés (<APPNAME>/<APPNAME>.app et <APPNAME>/<APPNAME>_init.php).

Pour cela il faut donc ajouter une section <post-upgrade/> dans le fichier info.xml contenant les instructions nécessaires pour ré-enregistrer l'application :

 <post-upgrade>
     <process command="programs/record_application MYAPP U" />
     <process command="programs/update_catalog"/>
 </post-upgrade>

Ce qui donne alors le fichier info.xml suivant :

<xml version="1.0" encoding="utf-8">
<module name="my-module" version="1.0.4" release="1">
 
    <requires>
        <module name="dynacase-core" comp="ge" version="3.2.0" />
    </requires>
 
    <post-install>
        <process command="programs/record_application MYAPP I" />
        <process command="programs/update_catalog" />
    </post-install>
 
     <post-upgrade>
         <process command="programs/record_application MYAPP U" />
         <process command="programs/update_catalog"/>
     </post-upgrade>
 
</module>

Régénérer enfin le module avec la nouvelle version des éléments à déployer.

17.15.3.4 Migrer une application

Dans certains cas, l'application peut nécessiter des traitements spécifiques en base de donnée ou sur des fichiers.

Ces traitements sont alors appelés scripts de "migration" car il vont devoir manipuler des éléments pour monter en version l'application depuis la version actuellement installée et la nouvelle version qui est déployée.

Deux types de scripts sont possibles :

  • scripts de pré-migration (premigr) : les scripts de pré-migration (premigr) sont prévus pour être exécutés avant que l'application et les familles en base de données soient mis-à-jour,
  • scripts de post-migration (postmigr) : les scripts de post-migration (postmigr) sont prévus pour être exécutés après que l'application et les familles en base de données aient été mis-à-jour.

Les scripts doivent être situés dans le sous-répertoire de l'application et leur nom doit être de la forme :

  • scripts de pré-migration (premigr) : <APPNAME>_premigr_<VERSION>
  • scripts de post-migration (postmigr) : <APPNAME>_postmigr_<VERSION>

Remarques :

  • Un module sans application ne peut pas utiliser cette mécanique de migration.
  • Le script peut être écrit dans n'importe quel langage que peut exécuter la plateforme hébergeant le contexte sur lequel il est exécuté. Toutefois, il ne doit pas avoir d'extension, il faut donc utiliser la notation [shebang][wikiShebang] en première ligne de script pour indiquer le langage d'exécution,
  • les scripts de migration sont exécutés sur les changements de VERSION sans tenir compte des RELEASE. On ne peut donc pas exécuter de script de migration lors d'un changement de RELEASE,
  • les scripts de migration doivent être exécutables.

Le lancement de ces scripts est commandé dans le fichier info.xml du module par l'utilisation d'une directive <process command="programs/{pre,post}_migration <APPNAME>" /> dans la section <post-upgrade/>.

Exemple de déclaration type pour le lancement de scripts de pré-migration et de post-migration :

<xml version="1.0" encoding="utf-8">
<module name="my-module" version="1.0.5" release="1">
 
    <requires>
        <module name="dynacase-core" comp="ge" version="3.2.0" />
    </requires>
 
    <post-install>
        <process command="programs/record_application MYAPP I" />
        <process command="programs/update_catalog" />
    </post-install>
 
    <post-upgrade>
        <process command="programs/pre_migration MYAPP" />
        <process command="programs/record_application MYAPP U" />
        <process command="programs/post_migration MYAPP" />
        <process command="programs/update_catalog" />
    </post-upgrade>
 
</module>

Les programmes programs/pre_migration et programs/post_migration exécutent tous les scripts de "premigr" ou "postmigr" dont la version est comprise entre la version de l'application actuellement installé, et la version de l'application mise-à-jour.

Version sur le contexte Version dans le paquet Version du script Exécution
1.0.0 2.0.0 1.1.0 Oui
1.0.0 1.0.0 1.0.0 Non
3.0.0 2.0.0 1.0.0 Non
1.0.0 2.0.0 1.0.0 Non
1.0.0 2.0.0 2.0.0 Oui

Voir :

17.15.4 Déployer une famille

17.15.4.1 Organisation de la famille

Le déploiement et le paramétrage d'une famille implique l'utilisation de fichiers de description de famille qui doivent être chargés suivant un ordre déterminé.

En effet, un fichier d'import ne doit référencer que des éléments connus au moment de son import. Par conséquent, il vous faut mettre en place un ordre de chargement des éléments afin d'importer en premier lieu un fichier N qui définirait les éléments qui seraient ensuite utilisés par les éléments définis dans un fichier N+1, et ainsi de suite.

L'ordre de chargement des éléments doit généralement être du type :

  • importer les données d'initialisation (e.g. utilisateurs, groupes et rôles) ;
  • importer la structure des familles ;
  • importer le paramétrage des familles (e.g. affecter les profils aux familles);

Pour éviter les références cycliques, comme dans le cas d'une famille qui utilise un cycle qui lui même est dynamique sur la famille (donc référence à son tour la famille), on procédera par l'import des familles seule (sans références à leurs cycles), puis des cycles qui référencent les familles, et enfin par l'import du paramétrage des familles qui va mettre en place leurs cycles.

17.15.4.2 Installer une famille

Les fichiers de description des familles peuvent être placés dans le sous- répertoire de l'application, ou bien, en l'absence d'application, dans un sous- répertoire qui permettra d'éviter que les éléments déployés n'entrent en conflit avec d'autres éléments.

Déclarer dans le fichier info.xml le chargement, et l'ordre de chargement, de ces fichiers à l'aide de la commande wsh.php --importDocuments :

<?xml version="1.0" encoding "utf-8"?>
<module name="my-module" version="1.0.0" release="1">
 
    <post-install>
        <process command="wsh.php --api=importDocuments --file=MYFAMS/init_users.csv" />
        <process command="wsh.php --api=importDocuments --file=MYFAMS/init_groups.csv" />
        <process command="wsh.php --api=importDocuments --file=MYFAMS/init_roles.csv" />
 
        <process command="wsh.php --api=importDocuments --file=MYFAMS/struct_fam1.csv" />
        <process command="wsh.php --api=importDocuments --file=MYFAMS/struct_fam2.csv" />
        <process command="wsh.php --api=importDocuments --file=MYFAMS/param_fam1.csv" />
        <process command="wsh.php --api=importDocuments --file=MYFAMS/param_fam2.csv" />
    </post-install>
 
    <post-upgrade>
        <process command="wsh.php --api=importDocuments --file=MYFAMS/struct_fam1.csv" />
        <process command="wsh.php --api=importDocuments --file=MYFAMS/struct_fam2.csv" />
        <process command="wsh.php --api=importDocuments --file=MYFAMS/param_fam1.csv" />
        <process command="wsh.php --api=importDocuments --file=MYFAMS/param_fam2.csv" />
    </post-upgrade>
 
</module>

Générer le module avec l'archive content.tar.gz et le fichier info.xml.

17.15.4.3 Mettre à jour une famille

La mise à jour d'un famille se fait en important le nouveau fichier de définition de famille.

Cependant, certains cas peuvent nécessiter une migration de données comme par exemple dans le cas d'un attribut de type timestamp (qui regroupe date + heure) qu'on voudrait migrer sous la forme de deux attributs distincts : un de type date et l'autre de type time.

Dans ce cas il faut utiliser un script de migration afin de migrer la valeur de l'attribut timestamp dans les deux attributs date et time à l'aide d'instructions SQL.

Comme indiqué précédemment, pour pouvoir utiliser de tels scripts de migration, il faut avoir une application afin de pouvoir déclencher les scripts de pré- migration et de post-migration lorsque la version de l'application est modifiée.

Admettons que la nouvelle version de l'application soit la 2.0.0, alors le script de post-migration des familles doit être déclaré dans un script nommé MYAPP/MYAPP_postmigr_2.0.0.

Exemple de script de post-migration MYAPP/MYAPP_postmigr_2.0.0 (en Bash) pour la migration d'un attribut de type timestamp sous la forme de deux attributs :

#!/usr/bin/env php
<?php
 
require('FDL/freedom_util.php');
require('WHAT/Lib.Common.php');
 
/*
 * Obtenir l'identifiant de la famille 'FAM_1'
 */
$famId = getIdFromName('', 'FAM_1');
if ($famId <= 0) {
    printf("Error: could not get id from name '%s'.\n", 'YUSER');
    exit(1);
}
 
/*
 * Mettre à jour la table de la famille MYFAM pour scinder les valeurs
 * 'attr_timestamp' dans deux attributs : 'attr_date' et 'attr_time'
 */
printf("Migrating table 'doc%d'...\n", $famId);
$sql = sprintf("UPDATE doc%d SET attr_date = attr_timestamp::date, attr_time = attr_timestamp::time", $famId);
$err = simpleQuery('', $sql, $res, false, false, false);
if ($err !== '') {
    printf("Error: %s\n", $err);
    exit(1);
}
printf("Done.\n");
exit(0);

Rendre le script MYAPP/MYAPP_postmigr_2.0.0 exécutable.

Régénérer l'archive content.tar.gz avec les éléments à livrer (MYAPP et MYFAMS).

Fichier info.xml correspondant complet :

<?xml version="1.0" encoding "utf-8"?>
<module name="my-module" version="2.0.0" release="1">
 
    <requires>
        <module name="dynacase-core" comp="ge" version="3.2.0" />
    </requires>
 
    <post-install>
        <!-- Enregistrer l'application MYAPP -->
        <process command="programs/record_application MYAPP I" />
 
        <!-- Charger les familles -->
        <process command="wsh.php --api=importDocuments --file=MYFAMS/struct_fam1.csv" />
        [...]
        <process command="wsh.php --api=importDocuments --file=MYFAMS/param_wdoc2.csv" />
 
        <!-- Mettre à jour le catalogue de langue -->
        <process command="programs/update_catalog" />
    </post-install>
 
    <post-upgrade>
        <!-- Lancer les scripts de pre-migration de l'application MYAPP -->
        <process command="programs/pre_migration MYAPP" />
 
        <!-- Enregistrer la nouvelle définition de l'application -->
        <process command="programs/record_application MYAPP" />
 
        <!-- Charger les nouvelles définitions des familles -->
        <process command="wsh.php --api=importDocuments --file=MYFAMS/struct_fam1.csv" />
        [...]
        <process command="wsh.php --api=importDocuments --file=MYFAMS/param_wdoc2.csv" />
 
        <!-- Lancer les scripts de post-migration de l'application MYAPP -->
        <process command="programs/post_migration MYAPP" />
 
        <!-- Mettre à jour le catalogue de langue -->
        <process command="programs/update_catalog" />
    </post-upgrade>
 
</module>

Régénérer enfin le module avec la nouvelle version des éléments à déployer.

Le script MYAPP/MYAPP_postmigr_2.0.0 est alors exécuté lors de l'upgrade du module my-module-2.0.0-1.webinst lorsque la version installée de l'application MYAPP est < 2.0.0.

Remarques :

  • En l'absence d'application, il n'est pas possible d'utiliser le mécanisme de pre-migration et post-migration tel que décrit ci-dessus. Dans un tel cas, il vous faudra, par exemple, livrer un script d'API et exécuter celui-ci avec une directive <process command="wsh.php --api=migrate-my-fams-2.0.0" />.

Voir :

17.15.5 Mettre à jour le catalogue de langue

La mise à jour du catalogue de langue s'effectue en exécutant le programme program/update_catalog en post-install et post-upgrade.

    <post-install>
        [...]
        <process command="program/update_catalog" />
    </post-install>
 
    <post-upgrade>
        [...]
        <process command="program/update_catalog" />
    </post-upgrade>

Voir :

17.15.6 Programmes utiles pour les déploiements

Un ensemble de programmes utiles pour les déploiements sont fournis par dynacase-core dans le sous-répertoire programs du contexte Dynacase.

Ces programmes sont prévus pour être exécutés par dynacase-control et ne peuvent donc pas être directement exécutés manuellement sans cet environnement.

Si vous souhaitez exécuter ces programmes manuellement, voir Exécution manuelle ci-dessous.

17.15.6.1 Commande programs/app_post

Prototype :

  • programs/app_post <APPNAME> I|U

Utilisable dans les phases :

  • post-install
  • post-upgrade

Conditions d'utilisation :

Le programme app_post recherche et exécute, s'il est présent, le script <APPNAME>/<APPNAME>_post qui peut contenir des instructions pour un traitement d'initialisation ou d'upgrade particulière.

Le module peut donc fournir son propre script nommé <APPNAME>/<APPNAME>_post qui sera exécuté par l'appel à programs/app_post.

Les arguments sont :

  • Le nom de l'application (le script exécuté sera alors <APPNAME>/<APPNAME>_post)
  • I | U : Le nom de la phase d'initialisation a exécuter (I pour install, U pour upgrade)

Exemple :

<post-install>
  [...]
  <process command="programs/record_application MYAPP I" />
 
  <process command="programs/app_post MYAPP I" />
 
  [...]
</post-install>
 
<post-upgrade>
  [...]
  <process command="programs/pre_migration MYAPP" />
  <process command="programs/record_application MYAPP U" />
 
  <process command="programs/app_post MYAPP U" />
 
  <process command="programs/post_migration MYAPP" />
  [...]
</post-upgrade>

Le script <APPNAME>/<APPNAME>_post est alors exécuté par app_post avec un seul argument qui est l'argument I ou U suivant qu'on est dans une installation ou un upgrade.

"programs/app_post MYAPP I" --(execute)--> "MYAPP/MYAPP_post I"
"programs/app_post MYAPP U" --(execute)--> "MYAPP/MYAPP_post U"

17.15.6.2 Commande programs/record_application

Prototype :

  • programs/record_application <APPNAME> I|U

Utilisable dans les phases :

  • post-install
  • post-upgrade

Conditions d'utilisation :

  • Le programme doit être exécuté après le programme app_post

Les arguments sont :

  • Le nom de l'application (correspondant aux fichiers <APPNAME>/<APPNAME>_init.php et <APPNAME>/<APPNAME>.app)
  • I | U : Le nom de la phase d'initialisation a exécuter (I pour install, U pour upgrade)

Le programme record_application est utilisé pour enregistrer, ou mettre à jour, la définition de l'application en base de données.

Exemple :

<post-install>
  [...]
 
  <process command="programs/record_application MYAPP I" />
 
  [...]
</post-install>
 
<post-upgrade>
  [...]
 
  <process command="programs/record_application MYAPP U" />
 
  [...]
</post-install>

17.15.6.3 Commande programs/update_catalog

Prototype :

  • programs/update_catalog

Utilisable dans les phases :

  • post-install
  • post-upgrade

Conditions d'utilisation :

  • Le programme doit être exécuté à la fin de la phase

Le programme update_catalog est utilisé pour ré-générer le catalogue des messages de localisation.

Exemple :

<post-install>
  [...]
 
  <proccess command="programs/update_catalog" />
 
</post-install>
 
<post-upgrade>
  [...]
 
  <process command="programs/update_catalog" />
 
</post-upgrade>

17.15.6.4 Commande programs/pre_migration

Prototype :

  • programs/pre_migration

Utilisable dans les phases :

  • post-upgrade

Conditions d'utilisation :

Les arguments sont :

  • Le nom de l'application

Le programme pre_migration est utilisé pour exécuter les scripts de pre-migration (<APPNAME>/<APPNAME>_premigr_<VERSION>) d'un module lors de sa mise-à-jour.

Tous les scripts <APPNAME>/<APPNAME>_premigr_<VERSION> dont la version est supérieure à la version de l'application précédemment enregistré sont exécutes dans l'ordre des versions.

Exemple :

<post-upgrade>
  [...]
 
  <process command="programs/pre_migration MYAPP" />
 
  <process command="programs/record_application MYAPP U" />
  <process command="programs/app_post MYAPP U" />
  <process command="programs/post_migration MYAPP" />
  [...]
</post-upgrade>

Voir :

  • [Scripts de pré-migration et de post-migration][#core-ref:fd259229-b279-469a-8e3c-d737fabcf9d5]

17.15.6.5 Commande programs/post_migration

Prototype :

  • programs/post_migration

Utilisable dans les phases :

  • post-upgrade

Conditions d'utilisation :

  • Le programme doit être exécuté après le programme record_application, et avant le update_catalog

Les arguments sont :

  • Le nom de l'application

Le programme post_migration est utilisé pour exécuter les scripts de post-migration (<APPNAME>/<APPNAME>_postmigr_<VERSION>) d'un module lors de sa mise-à-jour.

Tous les scripts <APPNAME>/<APPNAME>_postmigr_<VERSION> dont la version est supérieure à la version de l'application précédemment enregistré sont exécutes dans l'ordre des versions.

Exemple :

<post-upgrade>
  [...]
 
  <process command="programs/pre_migration MYAPP" />
  <process command="programs/record_application MYAPP U" />
  <process command="programs/app_post MYAPP U" />
 
  <process command="programs/post_migration MYAPP" />
 
  [...]
</post-upgrade>

Voir :

  • [Scripts de pré-migration et de post-migration][#core-ref:fd259229-b279-469a-8e3c-d737fabcf9d5]

17.15.6.6 Commande programs/set_param

Prototype :

  • programs/set_param <DYNACASE_PLATFORM_PARAM_NAME> <DYNACASE_CONTROL_MODULE_PARAM_NAME>

Utilisable dans les phases :

  • post-install
  • post-upgrade

Le programme programs/set_param permet de positionner la valeur d'un paramètre applicatif global d'une application Dynacase avec la valeur d'un paramètre de module.

Exemple :

<parameters>
  <param name="myapp_favorite_color" label="What is your favorite color?" type="text" default="blue" onupgrade="W"/>
</parameters>
 
<post-install>
  [...]
 
  <process command="programs/set_param MYAPP_GLOBAL_FAVCOLOR myapp_favorite_color" />
 
  [...]
</post-install>

17.15.6.7 Commande wsh.php

Prototype :

  • wsh.php

Utilisable dans les phases :

  • post-install
  • post-upgrade

Conditions d'utilisation :

  • Le programme peut être utilisé à n'importe quel moment en fonction des besoins

Le programme wsh.php est utilisé pour exécuter des méthodes sur des classes documentaires et exécuter des API Dynacase.

Exemple :

<process command="wsh.php --api=refreshDocuments --method=postModify --famid=FOO" />

Voir :

17.15.6.8 Exécution manuelle

Pour pouvoir exécuter manuellement ces programmes, il faut initialiser un environnement d'exécution compatible comme suit :

  • Le répertoire courant d'exécution doit être la racine du contexte.

  • La variable d'environnement WIFF_ROOT doit contenir le chemin absolu d'accès à la racine de dynacase-control.

  • La variable d'environnement WIFF_CONTEXT_ROOT doit contenir le chemin absolu d'accès à la racine du contexte.

  • La variable d'environnement WIFF_CONTEXT_NAME doit contenir le nom du contexte tel que déclaré auprès de dynacase-control.

  • Si le programme est exécuté dans le cadre de la mise à jour d'un module, la variable d'environnement MODULE_VERSION_FROM doit contenir la version du module actuellement installé dans le contexte et MODULE_VERSION_TO doit contenir la version du nouveau module.

  • Si le programme est exécuté dans le cadre de l'installation d'un module, la variable d'environnement MODULE_VERSION_FROM ne doit pas être définie et MODULE_VERSION_TO doit contenir la version du module en cours d'installation.

Exemple d'initialisation d'un tel environnement en Bash :

# /var/www/dynacase-control/wiff context foo exec /bin/bash --login
 
$ export WIFF_ROOT=/var/www/dynacase-control
$ export WIFF_CONTEXT_ROOT=$PWD
$ export WIFF_CONTEXT_NAME=foo
$ export MODULE_VERSION_FROM=1.0.0
$ export MODULE_VERSION_TO=2.0.0
Source : Advanced/install-update-app-fam.md Dynacase Platform 3.2 | Core Manuel de référence, version 3.2 édition 13, © Anakeen Labs <labs@anakeen.com>
×
Publié sous licence CC (http://creativecommons.org/licenses/by-nc-sa/2.0/fr/) par Anakeen [www.anakeen.com]
Attribution Vous devez créditer l'Oeuvre, intégrer un lien vers la licence et indiquer si des modifications ont été effectuées à l'Oeuvre. Vous devez indiquer ces informations par tous les moyens possibles mais vous ne pouvez pas suggérer que l'Offrant vous soutient ou soutient la façon dont vous avez utilisé son Oeuvre.
Pas d’Utilisation Commerciale Vous n'êtes pas autoriser à faire un usage commercial de cette Oeuvre, tout ou partie du matériel la composant.
Partage dans les Mêmes Conditions Dans le cas où vous effectuez un remix, que vous transformez, ou créez à partir du matériel composant l'Oeuvre originale, vous devez diffuser l'Oeuvre modifiée dans les même conditions, c'est à dire avec la même licence avec laquelle l'Oeuvre originale a été diffusée.
nouveauté