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
etadmin.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
ouU
-
I
pour l'enregistrement lors de l'installation (Install) etU
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 :
- Dans la phase
post-install
, le programme doit être exécuté après le programmerecord_application
- Dans la phase
post-upgrade
, le programme doit être exécuté aprèspre_migration
et avant le programmerecord_application
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 :
- Le programme doit être exécuté au début de la phase, avant le programme
app_post
etrecord_application
.
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 leupdate_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 etMODULE_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 etMODULE_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