Configurations

Déclaration des modules

Les modules sont déclarés dans le fichier <sainet>/modules/modules.xml. Ce fichier est ensuite intégré dans le serveur SAINet et n’est donc pas modifiable directement par le paramétreur une fois l’application déployée. Seul un développeur SAINet peut mettre à jour ce fichier.

Un module a un identifiant (id), ainsi qu’une liste de fichiers ou dossiers (<sources>) qui seront intégrés par ce module. Le prefix précise le dossier dans lequel se trouveront chacun des fichiers dans le package final utilisé par le serveur lorsque le paramétrage est fusionné (les sous-chemins sont conservés).

<!-- exemple de déclaration du module Swissdec 4 (sw4) -->
<module id="sw4">
    <sources>
        <source path="sw4/config" prefix="Config" />
        <source path="sw4/resources" prefix="Ressources" />
        <source path="sw4/users" prefix="Users" />
    </sources>
</module>

Avec cette définition, le fichier sw4/010_doc_admin/TasksAndFields_SAL.xml sera dans le dossier Config/TasksAndFields_SAL.xml. De même, le fichier sw4/010_doc_admin/Combos/SAL_Combos_FR.xml se retrouvera dans Config/Combos/SAL_Combos_FR.xml.

Modules spéciaux

Les modules suivants sont spéciaux: ils sont automatiquement intégrés lors du packaging de la solution et de la fusion du paramétrage.

• client_libs: librairies et outils nécessaires au client riche
• client_base: textes de base et updater pour le client riche
• client_exe: exécutable SAINETV4.exe
• global: fichiers de configuration généraux SAINet

Ordre de fusion et environnements

Selon le context, le fichier de configuration se trouve:

• dans le dossier source SAINet: <sainet>/modules/customers/<id>.xml
• dans une installation SAINet: <sainet_edms>/conf/customer.xml

Dans le cas d’une installation SAINet, ce fichier est modifiable par le paramétreur. Il suffira d’un evict (SYS87) pour que les modifications soient prises en compte.

Suppression de fichier ou dossier

Il est possible que dans module, certains fichiers ou dossiers doivent être supprimés. Pour ce faire, il suffit de nommer un fichier avec le même nom, suffixé par .delete. Par exemple, TasksAndFields_CGE.xml.delete. Lors de la fusion, ce fichier sera automatiquement exclu et n’existera plus du tout dans la configuration mergée. Cela fonctionne de la même manière pour les dossier (par exemple, Documentation/SAL.delete).

A noter qu’il est possible qu’un module redéfinisse un fichier supprimé. Dans ce cas, le merger le prendra comme si le fichier n’existait pas dans les modules précédents.

Spécification du customer.xml

Tag	Attribut	Description	Modifiable
customer		Noeud principal
	id	Identifiant du client. Utilisé également pour le du code spécifique dans dbcode.	Non
	fallbacks	Optionel. Liste d’identifiants clients séparés par des virgules pour rechercher une classe spécifique dans le dbcode.	Non
customer/modules		Liste des modules qui seront packagés dans SAINet et disponible pour le paramétreur.
	id	Identifiant du module.	Non
	path	Optionel. Chemin vers l’emplacement de la configuration.	Non
	prefix	Optionel. Préfixe des fichiers contenus dans path	Non
customer/defaults		Liste des configurations/ordres de fusion possibles.
	includeChains	Optionel. Liste des chaines disponibles, séparées par des virgules. Seules les tâches faisant parties de ces chaînes seront autorisées.
	excludeChains	Optionel. Liste des chaines exclues, séparées par des virgules. Toutes les tâches faisant partie de ces chaînes ne seront pas autorisées.
customer/defaults/config		Liste des modules, dans l’ordre de fusion.	Oui
	id	Identifiant du module. Doit être un des modules spécifiés dans customer/modules.	Oui
customer/environments		Liste des environnements disponibles.
	id	Identifiant de l’environnement. Le serveur utilise la propriété système sainet.domain.env pour déterminer l’environnement dans lequel il est.	Oui
	url	URL complète sur l’EntryPoint SAINet. Utilisé pour la génération de l’installeur du client riche SAINet.	Oui
	defaultConfig	Ordre de fusion à utiliser par défaut. Doit être une des configuration spécifiées dans customer/defaults.	Oui

Si l’ordre de fusion est toujours le même que celui des modules déclarés, alors il n’y a pas besoin de spécifier le tag <defaults>, ni l’attribut defaultConfig dans les environnements.

Les attributs includeChains et excludeChains sont pris en compte uniquement au niveau des droits (les fichiers du paramétrage seront de toute façon présents).

Exemple

<customer id="SMA">
  <!-- liste des modules packagés -->
  <!-- les modules client_* et global sont automatiquement intégrés -->
  <modules>
    <module id="sw4" />
    <module id="sma">
      <sources>
        <source path="sma/config" prefix="Config" />
        <source path="sma/resources" prefix="Ressources" />
        <source path="sma/users" prefix="Users" />
      </sources>
    </module>
    <module id="client_sma" path="client_sma/BaseResources" prefix="BaseResources" />
    <module id="sma_pcom" />
  </modules>
  <!-- ordre de fusion possibles -->
  <!-- les modules client_* et global sont automatiquement en premier dans l'ordre de la fusion -->
  <defaults excludeChains="QUA">
    <config id="base">
      <module id="sw4" />
      <module id="sma" />
      <module id="client_sma" />
    </config>
    <config id="procom">
      <module id="sw4" />
      <module id="sma" />
      <module id="client_sma" />
      <module id="sma_pcom" />
    </config>
  </defaults>
  <!-- environnements disponibles et l'ordre de fusion utilisé par défaut -->
  <environments>
    <environment id="dev2" url="https://sma.dev2.sai-erp.net/SNV4SRV-ws-war/EPS" defaultConfig="base"/>
    <environment id="stg" url="https://sma.stg.sai-erp.net/SNV4SRV-ws-war/EPS" defaultConfig="base"/>
  </environments>
</customer>