Réglages avancés des paramètres système

----

(% class="box" %)

(((

Dans ce qui suit, **<digdash.appdata>** fait référence à l'emplacement que vous avez choisi pour la sauvegarde des données (sources, graphiques, formats, ...).

8

Il doit être renseigné dans le fichier **digdash.properties** sous le paramètre **digdash.appdata **ou **ddenterpriseapi.AppDataPath** (voir [[Guide d'installation Windows>>doc:Digdash.deployment.installation.install_guide_windows.WebHome||target="_blank"]] ou [[Guide d'installation Linux>>doc:Digdash.deployment.installation.install_guide_linux.WebHome||target="_blank"]])

9

Vous pouvez aussi le visualiser dans la page "Etat du serveur" des pages d'administration de votre serveur (serveur démarré).

10

)))

11

12

(% class="box infomessage" %)

(((

__Vocabulaire__

Dans toutes les pages de documentation, les "**applications**" font références aux fichiers **.war **présents dans le serveur DigDash Enterprise :

17

18

* **Serveur** : ddenterpriseapi.war

19

* **Tableau de bord** : digdash_dashboard.war

20

* **Web Studio** : studio.war

21

* **Page d'accueil et Desktop Studio** : adminconsole.war

22

23

Cet ensemble d'applications constitue un domaine. Selon les besoins ce domaine peut être dupliqué pour par exemple disposer d'un contexte de développement et un autre de production.

24

Pour déployer plusieurs domaines suivez [[ce lien>>url:https://doc.digdash.com/xwiki/wiki/howtos/view/howtos/server/Domain_management/]].

25

)))

26

27

Ce document décrit les réglages avancés des paramètres du serveur DigDash Enterprise (DDE).

28

29

Les fichiers suivants seront modifiés :

30

31

* server.xml

32

** Emplacement (Tomcat global) :

33

<DDE Install>/apache-tomcat/conf/server.xml

34

* web.xml

35

** Emplacement (Tomcat global) :

36

<DDE Install>/apache-tomcat/conf/web.xml

37

* system.xml

38

** Emplacement :

39

**<digdash.appdata>**/Enterprise Server/ddenterpriseapi/config/**system.xml**

40

* digdash.properties

41

** Emplacement :

42

<DDE Install>/**digdash.properties**

43

ou /etc/digdash/**digdash.properties** (sous linux)

44

ou l'emplacement personnalisé que vous auriez configuré.

45

* web.xml (cette méthode est obsolète, veuillez utiliser le fichier **digdash.properties**)

46

** Emplacement (ddenterpriseapi) :

47

**<DDE Install>**/apache-tomcat/webapps/**ddenterpriseapi**/WEB-INF/**web.xml**

48

** Emplacement (dashboard) :

49

**<DDE Install>**/apache-tomcat/webapps/**digdash_dashboard**/WEB-INF/**web.xml**

50

** Emplacement (adminconsole) :

51

**<DDE Install>**/apache-tomcat/webapps/**adminconsole**/WEB-INF/**web.xml**

52

** Emplacement (studio) :

53

**<DDE Install>**/apache-tomcat/webapps/**studio**/WEB-INF/**web.xml**

54

** Emplacement (adswrapper) :

55

**<DDE Install>**/apache-tomcat/webapps/**adswrapper**/WEB-INF/**web.xml**

56

* setenv.bat (Windows)

57

** Emplacement : <DDE Install>/configure/**setenv.bat**

58

* setenv.sh (Linux)

59

** Emplacement : <DDE Install>/apache-tomcat/bin/**setenv.sh**

60

* dashboard_system.xml

61

** Emplacement : **<digdash.appdata>**/Application Data/Enterprise Server/**dashboard_system.xml**

= Réglages Tomcat =

== Allouer plus de mémoire à Tomcat ==

66

67

Fichier modifié : **setenv.bat** ou **setenv.sh**

68

69

Sous windows **setenv.bat** se trouve dans le dossier **<install DD>/configure**.

70

Sous linux **setenv.sh** il se trouve dans le dossier **<install DD>/apache-tomcat/bin**

71

72

Trouvez les lignes suivante au début du fichier :

set JVMMS=512

set JVMMX=512

Changer les 2 occurrences "512" en la quantité de mémoire (méga-octets) que vous voulez allouer à Tomcat. Par exemple "**4096**" allouera 4 Go de mémoire à Tomcat :

set JVMMS=4096

set JVMMX=4096

(% class="box errormessage" %)

87

(((

88

Important : Sur un Windows 64 bits il n'y a pas de limite autre que la mémoire physique de votre ordinateur. Si La valeur est trop haute, alors Tomcat ne démarrera pas.

89

)))

90

91

(% class="box infomessage" %)

92

(((

93

//Note pour Windows 32 bits //: Si vous avez une configuration 32 bits (machine/OS), ou si vous avez déployé la version 32 bits de DigDash enterpise sur votre machine 64 bits, alors vous êtes limité dans la quantité de mémoire que vous pouvez allouer à Tomcat. La limite dans ce cas est connue pour être approximativement 1,5Go. Cela dépend notamment de la fragmentation de la mémoire à cet instant. Nos tests montrent en général que nous pouvons allouer 1,4Go sur un Windows 32 bits. Pour cette raison, nous recommandons une combinaison machine/OS 64 bits.

94

)))

95

96

(% class="box errormessage" %)

97

(((

98

Important : Lorsque vous installez Tomcat en tant que service Windows (voir la page [[Guide d'installation Windows>>doc:Digdash.deployment.installation.install_guide_windows.WebHome||anchor="HInstallationentantqueserviceWindows" target="_blank"]]), à l'aide de **servers_install_service.bat**, c'est le paramétrage de **setenv.bat **qui sera appliqué //lors de l'installation du service//.

99

100

Ainsi si vous souhaitez changer la mémoire allouée à Tomcat, il est obligatoire de :

101

102

1. Changer les variables JVMMS et JVMMX du fichier **setenv.bat**

103

1. Relancer** servers_install_service.bat** (ce script désinstallera le service avant de le réinstaller avec les nouveaux paramètres)

104

)))

105

106

== Changer les ports réseau Tomcat ==

107

108

Fichier modifié : **server.xml**

109

110

Si un des ports nécessaires à Tomcat est déjà utilisé par un autre processus, alors il ne se lancera pas. Il est nécessaire de vérifier la disponibilité des ports et si besoin de reconfigurer Tomcat. Par défaut les 3 ports suivants sont configurés : 8005, 8080 et 8009. Pour les modifier :

111

112

1. Ouvrez le répertoire **<install DDE>\apache-tomcat/conf** puis éditer le fichier **server.xml**

113

1. Chercher et remplacer les valeurs des ports 8005, 8080 et 8009 par des numéros de port disponibles sur le système

114

115

== Changer la durée de vie des sessions inactives (timeout) ==

116

117

Fichier modifié : **web.xml** (configuration globale de Tomcat situé à l'emplacement <DDE Install>/apache-tomcat/conf/web.xml)

118

119

Trouvez les lignes suivantes dans le fichier :

<session-config>

<session-timeout>30</session-timeout>

</session-config>

Changez la valeur pour modifier la durée de vie en minutes d'une session inactive (timeout). Par défaut le timeout est de 30 minutes.

128

129

== Changer le nombre maximum de requêtes simultanées ==

130

131

Fichier modifié : **server.xml**

132

133

Par défaut Tomcat n’acceptera pas plus de 200 requêtes **simultanées**. Ce paramétrage peut se révéler limitant dans le cas d’un déploiement à un grand nombre d’utilisateurs (plusieurs milliers ou millions), ou lors d’un bench de performance (ex. jmeter) qui exécute des centaines ou des milliers de requêtes simultanées.

134

135

Pour augmenter cette limite, il faut ajouter un attribut **maxthreads** dans l’élément **Connector** correspondant au connecteur utilisé.

136

137

Exemple lorsque le connecteur utilisé est http (il n’y a pas d’Apache en front-end) :

Exemple lorsque le connecteur utilisé est AJP (il y a un Apache en front-end) :

== Activer la compression HTTP ==

150

151

Fichier modifié : **server.xml**

152

153

La compression HTTP permet de diminuer la consommation de la bande passante du réseau en compressant les réponses HTTP. Par défaut cette option n’est pas activée dans Tomcat, même si tous les navigateurs modernes la supportent.

154

155

Cette option permet d’économiser parfois jusqu’à 90 % la bande passante sur certains types de fichiers : HTML, Javascript, CSS. En consommant peu de CPU sur le serveur et le client.

156

157

(% class="box errormessage" %)

158

(((

159

Important : Cette option ne fonctionne que si Tomcat est utilisé directement en serveur front-end via le connecteur HTTP/1.1. S’il y a un Apache httpd en front-end, alors il faudra activer l’option équivalente dans Apache httpd lui-même (voir la documentation directement sur le site Apache httpd).

160

La compression HTTP n’est pas supportée sur le connecteur AJP, ni sur aucun autre connecteur que HTTP(S)/1.1.

161

)))

162

163

Dans le fichier **server.xml** ajoutez les attributs **compression="on"** et **compressionMinSize="40000"** sur le connecteur HTTP/1.1:

Exemple :

L’attribut **compressionMinSize** définit une taille minimale de réponse (en octets) au dessous de laquelle la compression n’est pas utilisée. Il est conseillé de spécifier cet attribut à une valeur suffisante pour ne pas compresser des fichiers déjà très petits (icônes PNG…).

172

173

(% class="box infomessage" %)

174

(((

175

Note : Ce réglage n’a pas d’incidence si un navigateur utilisé ne supporte pas la compression HTTP. Tomcat décidera alors de ne pas compresser les réponses HTTP pour ce navigateur.

176

)))

177

178

= Paramètres de performance avancés =

179

180

Fichier modifié : **system.xml**

181

182

Exemple de syntaxe XML :

== Threads utilisés pour l'exécution des flux programmés ==

189

190

Modifie le nombre de « threads » utilisés pour l'exécution des flux programmés (ordonnanceur) ou sur événement.

191

192

Paramètres disponibles :

193

194

* //Nom// : **MAX_TP_EXECSIZE**

195

* //Valeur //: entier > 0 (défaut : 16)

196

//Description// : Nombre de threads maximum de traitement des tâches de synchronisation.

197

* //Nom// : **TP_SYNC_PRIORITY**

198

//Valeur //: chaîne ("flow" ou "none") (défaut : flow)

199

//Description// : Mode de priorité des tâches. Valeur **flow **: Traite la synchronisation du flux le plus tôt possible après que le cube ait été généré pour ce flux. Valeur **none **: le flux sera synchronisé quand il y aura de la place dans la file de threads. Ce paramètre n'est pris en compte que lorsque que le paramètre **TP_PRIORITYPOOL **est à **true**.

200

* //Nom// : **TP_SYNC_GROUPFLOWBYCUBE**

201

//Valeur //: booléen (défaut : false)

202

//Description// : Change le mode de traitement des tâches en attente. Valeur **false **: les tâches de traitements des flux sont répartis sur tous les threads disponibles quel que soit le cube utilisé. Cela entraine un traitement en parallèle des flux au détriment des cubes, recommandé lorsqu'il y a peu de cubes mais beaucoup de flux. Valeur **true **: regroupe les traitements des flux d'un même cube sur un seul thread. Cela entraine un traitement en parallèle des cubes au détriment des flux, recommandé lorsqu'il y a beaucoup de cubes différents et peu de flux utilisant les même cubes. Ce paramètre n'est pris en compte que lorsque que le paramètre **TP_PRIORITYPOOL **est à **true**.

203

204

== Threads utilisés pour l'exécution des flux interactifs ==

205

206

Modifie le nombre de « threads » utilisés pour l'exécution interactive des flux (Studio, tableau de bord, mobile, etc).

207

208

Paramètres disponibles :

209

210

* //Nom// : **MAX_TP_PLAYSIZE**

211

* //Valeur //: entier > 0 (défaut : 16)

212

//Description// : Nombre de threads maximum de traitement des tâches de synchronisation.

213

* //Nom// : **TP_PLAY_PRIORITY**

214

//Valeur //: chaine ("flow" ou "none") (défaut : flow)

215

//Description// : Mode de priorité des tâches. Valeur **flow **: Traite la synchronisation du flux le plus tôt possible après que le cube ait été généré pour ce flux. Valeur **none **: le flux sera synchronisé quand il y aura de la place dans la file de threads. Ce paramètre n'est pris en compte que lorsque que le paramètre **TP_PRIORITYPOOL **est à **true**.

216

* //Nom// : **TP_PLAY_GROUPFLOWBYCUBE**

217

//Valeur //: booléen (défaut : false)

218

//Description// : Change le mode de traitement des tâches en attente. Valeur **false **: les tâches de traitements des flux sont répartis sur tous les threads disponibles quel que soit le cube utilisé. Cela entraine un traitement en parallèle des flux au détriment des cubes, recommandé lorsqu'il y a peu de cubes mais beaucoup de flux. Valeur **true **: regroupe les traitements des flux d'un même cube sur un seul thread. Cela entraine un traitement en parallèle des cubes au détriment des flux, recommandé lorsqu'il y a beaucoup de cubes différents et peu de flux utilisant les même cubes. Ce paramètre n'est pris en compte que lorsque que le paramètre **TP_PRIORITYPOOL **est à **true**.

219

220

== Délais de suppression des cubes en mémoire ==

221

222

Modifie la manière dont le Cube Manager supprime les cubes inutilisés en mémoire.

223

224

Les paramètres suivants modifient la manière dont les cubes non utilisés depuis un certain temps sont supprimés, même si la session est toujours active.

225

226

Paramètres disponibles :

227

228

* //Nom// : **CUBE_TIMEOUT_INTERACTIVE**

229

//Valeur// : minutes > 0 (défaut : 10 minutes)

230

//Description// : Durée de la période d'inactivité pour un cube chargé en mode interactif (navigation du cube sur le serveur)

231

* //Nom// : **CUBE_TIMEOUT_SYNC**

232

//Valeur// : minutes > 0 (défaut : 4 minutes)

233

//Description// : Durée de la période d'inactivité pour un cube chargé en mode programmé (génération d'un flux programmé)

234

* //Nom //: **CUBE_TIMEOUT_PERIOD**

235

//Valeur// : minutes > 0 (défaut : 2 minutes)

236

//Description// : Intervalle de vérification de l'inactivité des cubes, devrait être au moins **CUBE_TIMEOUT_SYNC** / 2

237

238

== Performance des cubes de données ==

239

240

Ces paramètres affecteront le traitement interactif des cubes de données (aplatissement en cubes résultats pendant l'affichage). Ces paramètres n'affectent pas la génération des cubes de données.

241

242

Paramètres disponibles :

243

244

* //Nom// : **CUBEPART_MAXSIZEMB**

245

//Valeur// : méga-octets > 0 (défaut : 100 Mo)

246

//Description// : Taille d'une part de cube en méga-octets. Une part de cube est une partie du cube de données qui peut être traitée (aplatie) en parallèle ou distribuée sur d'autres serveur DigDash Enterprise en mode cluster (voir chapitre "//Utilisation de plusieurs serveurs en mode cluster//" dans ce document).

247

* //Nom// : **TP_MCUBESIZE**

248

//Valeur// : threads > 0 (défaut : 64 threads)

249

//Description// : Taille de la file de threads utilisés pour le traitement en parallèle des parts de cube. Les gros cubes (ex: plusieurs millions/milliards de lignes) sont traités en parallèle par le serveur, et/ou par d'autres serveurs (en mode cluster). Ce paramètre est le nombre d'unités parallèle de traitement (thread) sur une machine. Chaque part de cube occupe une unité de la file le temps de son traitement, si la file est pleine les unités supplémentaires sont mises en attente.

250

* //Nom// : **MCUBE_ROWS_PER_THREAD**

251

//Valeur// : lignes > 0 (défaut : 100000)

252

//Description// : C'est la limite du nombre de ligne d'un cube de données au delà de laquelle le serveur DigDash Enterprise activera le traitement parallèle des parts du cube (s'il y a plus d'une part pour ce cube). En dessous de cette limite, le traitement du cube n'est pas parallélisé mais séquentiel.

253

254

== Autres paramètres de performance ==

255

256

Les paramètres suivants servent à analyser ou optimiser les performances du système.

257

258

Paramètres disponibles :

259

260

* //Nom// : **LOW_MEMORY_THRESHOLD**

261

//Valeur// : pourcentage > 0 (défaut : 10%)

262

//Description// : C’est le seuil en pourcentage de mémoire libre restante au dessous duquel le système émettra une alerte de mémoire basse. Cette alerte est visible dans la page d’état du serveur pendant 24 heures. Elle est aussi enregistrée dans la base de données DDAudit si le service d’audit système est démarré.

263

Enfin, un événement DigDash est aussi déclenché lorsque le seuil est atteint : SYSCHECK_LOWMEM. Un exemple d’utilisation de cet événement est donné dans le document de déploiement du module DDAudit.

264

* //Nom// : **TP_PRIORITYPOOL**

265

//Valeur// : booléen (défaut : true)

266

//Description// : Utilise un pool de threads de rafraîchissements avec gestion de priorité pour les rafraîchissements de flux et cubes. Voir paramètres **TP_PLAY_GROUPFLOWBYCUBE, TP_SYNC_GROUPFLOWBYCUBE, TP_PLAY_GROUPFLOWBYCUBE, TP_SYNC_GROUPFLOWBYCUBE**

267

* //Nom// : **PROP_JS_OPTIM_LEVEL**

268

//Valeur// : niveau d'optimisation de -1 à 9 (défaut : 1)

269

//Description// : Permet de définir le niveau d'optimisation utilisé lors de la compilation de javascript. -1 désactive la compilation, 0 désactive seulement l'optimisation. Le niveau maximal d'optimisation est 9, cependant il est possible que l'optimisation provoque des erreurs lors de la compilation.

270

271

= Service de maintenance Automatique =

272

273

DigDash Enterprise fournit un service de maintenance composé :

274

275

* D’un nettoyeur de fichiers (connu aussi en tant que Files GC) nettoyant l'ensemble des fichiers inutilisés : vieux fichiers de l'historique, cubes et autres fichiers dépendant des flux.

276

* D’une sauvegarde automatique de la configuration

277

278

== Nettoyeur de fichiers ==

279

280

Le nettoyeur nettoie les fichiers non utilisés par les portefeuilles des utilisateurs et des rôles.

281

282

Le nettoyage parcourt les index de tous les utilisateurs, ainsi que le disque, afin de trouver les fichiers qui ne sont plus liés aux index. Les fichiers identifiés sont supprimés. Les fichiers effacés sont les suivants : fichiers de cubes (.dcg), fichiers js des cubes (cube_data_id.js), modèles (cube_dm_id.js) et flux (cube_view_id_js).

283

284

Cette opération présente l'avantage de libérer de l'espace disque et potentiellement d'accélérer les recherches de fichiers js, qui peuvent devenir non négligeables sur des volumétries importantes (nombre de cubes personnels * nb historiques > 100000)

285

286

Selon l'âge du serveur et la volumétrie des fichiers concernés (nombre de rafraîchissements effectués...), l'opération peut prendre beaucoup de temps lors de sa première exécution (sur certains déploiements comportant beaucoup d'utilisateurs et beaucoup de cubes personnalisés, une à deux heures).

287

288

Ensuite, si le nettoyage est fait de manière régulière, le temps d'exécution sera moins long. Ce temps dépend énormément de la performance du système de fichiers et de la machine, ce qui le rend difficilement estimable.

289

290

== Sauvegarde automatique ==

291

292

La sauvegarde automatique est effectuée avant le nettoyage des fichiers. Le fichier généré est copié dans le dossier de configuration **<digdash.appdata>/Enterprise Server/<domaine>/backups/<date du jour>.zip**

293

294

Par défaut, la maintenance se fait tous les jours à minuit.

295

296

(% class="box errormessage" %)

297

(((

298

Important : Par défaut le service de maintenance ne se lance que si aucune session utilisateur n'est active à ce moment. De plus, pendant son fonctionnement aucun utilisateur ne peut se connecter à DigDash Enterprise. Attention donc à bien le programmer pour qu'il n'interfère pas avec l'utilisation normale de DigDash Enterprise par les utilisateurs, ni par l'ordonnanceur. Selon les cas nous conseillons de programmer le service de maintenance la nuit, et à des plages horaires différentes des plages de l'ordonnanceur.

299

)))

300

301

== Activation, désactivation et/ou nettoyage au démarrage ==

302

303

Ce paragraphe décrit comment activer et programmer le service de maintenance.

304

L'activation du nettoyeur de fichiers peut se faire de deux manières :

305

306

=== 1- //Depuis la page état du serveur //: ===

307

308

La page **Etat du serveur** est accessible depuis la page d'accueil de DigDash Enterprise puis en cliquant successivement sur les liens **Configuration **et **Etat du serveur**.

309

310

Dans la rubrique **Etat du nettoyeur de fichiers**, cliquez sur la flèche verte figurant à côté de **Nettoyeur de fichier démarré** pour démarrer le nettoyeur :

311

312

[[image:1599031610206-294.png||queryString="width=529&height=157" height="157" width="529"]]

313

Le prochain nettoyage aura lieu à minuit. Pour démarrer le nettoyeur de fichiers immédiatement, cliquez sur l’icône [[image:1599031692012-960.png]].

314

315

=== 2- //Depuis le fichier digdash.properties// : ===

316

317

Fichier modifié : **digdash.properties**

318

Voir le chapitre "[[Externalisation des paramètres dans un fichier properties>>doc:||anchor="externalisation" target="_blank"]]" pour effectuer cette manipulation.

319

320

Active ou non le module Files GC et/ou lance le nettoyage au démarrage du serveur.

321

322

Paramètres disponibles :

323

324

* //Nom// : **ddenterpriseapi.startCleaner**

325

//Valeur// : booléen (défaut : false)

326

//Description// :

327

** true : nettoyage automatique des fichiers programmé.

328

//Note: l'heure du nettoyage est définie dans **system.xml**, par le paramètre **FILESGC_SCHEDXML**.

329

L'heure de nettoyage par défaut (si aucune n'est spécifiée dans system.xml, FILESGC_SCHEDXML) est tous les jours à 0:00//

330

** false (défaut) : pas d'utilisation du nettoyeur de fichiers

331

* //Nom// : **ddenterpriseapi.cleanOnStart**

332

//Valeur// : booléen (défaut : false)

333

//Description// :

334

** true : nettoie les fichiers inutilisés au démarrage du serveur (fichiers de l'historique, cubes, fichiers résultats,...)

335

** false (défaut) : ne nettoie pas les fichiers inutilisés au démarrage du serveur

336

* //Nom// : **ddenterpriseapi.autoBackup**

337

//Valeur// : booléen (défaut : false)

338

//Description// :

339

** ***. true : active la sauvegarde automatique programmée**

340

** false (défaut) : n’active pas la sauvegarde automatique programmée

341

342

(% class="box warningmessage" %)

343

(((

344

Dans le fichier **digdash.properties**, tous les paramètres sont préfixés du nom de l'application concernée.

345

Ici par défaut il s'agit de ddenterpriseapi (ddenterpriseapi.war).

346

Si vous avez renommé cette application, par exemple en **ddapi_dev.war**, les paramètres deviennent **ddapi_dev.startCleaner**, **ddapi_dev.cleanOnStart, ...**

347

)))

348

349

== Programmation et options de la maintenance automatique ==

350

351

Fichier modifié : **system.xml**.

352

353

Paramètres disponibles :

354

355

* //Nom// : **FILESGC_SCHEDXML**

356

//Valeur// : phrase XML (encodée) (défaut : aucune)

357

//Description// : Ce paramètre contient une phrase XML //encodée// décrivant la fréquence de programmation.

Exemple :

<Property key="FILESGC_SCHEDXML"

363

value="<Schedule frequency="daily"

364

fromDay="11" fromHour="0"

365

fromMinute="0" fromMonth="7"

366

fromYear="2011" periods="1"

367

time="0:0"/>"></Property>

368

369

370

Les attributs intéressants sont : **frequency** (**hourly**, **daily** ou **monthly**), **periods** (nombre d'heures, jours ou mois entre 2 nettoyages) et **time** (heure du nettoyage pour les fréquences daily et monthly). Cet exemple signifie tous les jours (frequency="daily" et periods="1") à 0:00 (time="0:0").

371

372

* //Nom// : **FILESGC_SESSIONSCHECK**

373

//Valeur// : true/false (booléen) (défaut : aucune, équivaut à true)

374

//Description// : Ce paramètre indique si le nettoyeur de fichiers doit vérifier les sessions actives avant de se lancer (true), ou s'il se lance qu'elle que soit l'état des sessions actives (false). Dans ce dernier cas, toutes les sessions seront déconnectées instantanément.

Exemple :

* //Nom// : **USEAUTOBACKUP**

383

//Valeur// : true/false (booléen) (défaut : aucune, équivaut à false)

384

//Description// : Ce paramètre indique si le service de maintenance effectue aussi une sauvegarde complète de la configuration avant d’exécuter le nettoyage des fichiers.

385

386

= Utilisation de plusieurs serveurs en mode "Cluster" =

387

388

Pour gérer un plus grand volume de données (milliard de lignes), il est possible d'utiliser plusieurs serveurs en mode "Cluster". Chaque serveur devient un nœud de calcul du cluster.

389

Ce dernier regroupe un serveur maître et des serveurs esclaves.

390

391

Le serveur maître s'occupe de gérer les modèles, les documents, les rôles, les utilisateurs, les sessions et de générer les cubes et les flux (rafraîchissement). A l'identique d'un serveur Digdash Enterprise en mode standard mono-machine.

392

Les serveurs esclaves additionnels ne sont utilisés que pour aider à l’aplatissement interactif des cubes de données volumineux, lors de l'affichage de flux, filtrage, drills, etc.

393

394

Il existe deux architectures de clustering dans DigDash Enterprise :

395

396

* Clustering interne : Décrit dans ce chapitre

397

* Cluster Apache Ignite : [[Module Cluster Apache Ignite>>doc:.ignite_cluster_guide.WebHome]]

398

399

== Installer DigDash Enterprise en mode "Cluster" ==

400

401

Pré-requis: plusieurs machines connectées entre elles par le réseau

402

403

=== Serveur maître (sur la machine la plus puissante du cluster) ===

404

405

1. Installation standard de DigDash Enterprise (voir ).

406

1. Démarrer le serveur normalement avec **start_servers.bat**

407

408

=== Serveur esclave (sur chacune des autres machines du cluster) ===

409

410

1. Installation standard de DigDash Enterprise (voir [[Guide d'installation Windows>>doc:Digdash.deployment.installation.install_guide_windows.WebHome||target="_blank"]] ou [[Guide d'installation Linux>>doc:Digdash.deployment.installation.install_guide_linux.WebHome||target="_blank"]]).

411

La différence est qu'un serveur esclave n'a pas besoin de licence pour servir d'unité de calcul au cluster, ni d'annuaire LDAP, ni de l'application digdash_dasboard dont le war peut être supprimé de Tomcat.

412

1. Démarrer uniquement le module Tomcat, avec **start_tomcat.bat** ou **apache_tomcat/bin/startup.sh**

413

414

== Configurer le cluster ==

415

416

Procédure à répéter sur chaque serveur du cluster

417

418

1. Avec un navigateur, se connecter à la page principale de DigDash Enterprise (ex: http:~/~/<serveur>:8080)

419

1. Cliquer sur **Configuration**, puis **Paramètres Serveur**

420

1. S'identifier en tant qu'administrateur de DigDash Enterprise (admin/admin par défaut) pour afficher la page des paramètres du serveur

421

1. Cliquer en bas de page sur le lien **Paramètres du cluster**

422

1. Remplir les différents champs en fonction de chaque machine serveur (voir explications ci-dessous)

423

424

=== Section Performance du système ===

425

426

[[image:1599031761946-310.png||queryString="width=529&height=116" height="116" width="529"]]

427

La section **Performance du système** définit les capacités de la machine courante dans le cluster. Les paramètres **Nombre de CPU**, **Score CPU** et **Mémoire allouée** permettent de répartir au mieux la charge de calcul.

428

429

1. **Nombres de CPU **: le nombre de processeurs * nombre de cœurs sur chaque processeurs. Potentiellement multiplié par un facteur si les processeurs bénéficient d'une technologie type Hyper-threading. Par défaut -1, s'appuie sur les données renvoyées par le système d'exploitation

430

1. **Score CPU **: c'est une note entre 1 et 10 qui permet de relativiser la performance d'un noeud du cluster par rapport aux autres (cas d'un cluster hétérogène). Par défaut -1 donne une note moyenne (5).

431

1. **Mémoire allouée **: la fraction de la mémoire maximale autorisée dans le cadre d'utilisation du serveur comme unité de calcul. Cette valeur est inférieure ou égale à la mémoire allouée au serveur Tomcat. Par défaut -1 autorise toute la mémoire.

432

433

=== Section Clusters autorisés ===

434

435

[[image:1599031821272-770.png||queryString="width=667&height=184" height="184" width="667"]]

436

La section **Clusters autorisés** permet de spécifier si la machine courante peut être utilisée comme esclave d'un ou plusieurs cluster(s), et si oui lesquels. En effet une machine peut servir à plusieurs clusters DigDash Enterprise. Cette section restreint cette utilisation en tant qu'esclave à seulement certains clusters (liste **Sélection**) ,

437

438

C'est également dans cette section que nous définissons le **Mot de passe** du serveur courante dans le cluster sélectionné. Sans mot de passe le serveur ne peut être esclave dans ce cluster.

439

440

Pour ajouter un cluster autorisé à utiliser ce serveur esclave:

441

442

1. **Nom **: nom du cluster (arbitraire)

443

1. **Adresse IP du serveur maître** : adresse IP du serveur maître du cluster autorisé à utiliser ce serveur comme esclave (ex: http:~/~/192.168.1.1)

444

1. **Mot de passe** : Mot de passe de l'esclave dans le contexte du cluster sélectionné

445

1. Cliquer sur le bouton **Ajouter** pour ajouter ce cluster à la liste des clusters autorisés

446

447

(% class="box infomessage" %)

448

(((

449

Note : Vous pouvez éditer ou supprimer des cluster autorisés en les sélectionnant dans la liste **Sélection**, puis en cliquant sur les boutons **Editer** ou **Supprimer**.

450

)))

451

452

=== Section Définition du cluster ===

453

454

A renseigner seulement sur le serveur Maître du cluster

455

456

[[image:1599031869523-186.png||queryString="width=686&height=254" height="254" width="686"]]

457

La section **Définition du cluster** //ne concerne que le serveur maître// du cluster. C'est ici que nous créons un cluster en listant les serveurs esclaves du cluster ainsi que le maître lui-même (liste **Sélection**, champs **Nom**, **Adresse**, **Domaine** et **Mot de passe**). Le serveur maître est implicitement le serveur via lequel vous vous êtes connecté à cette page.

458

459

Pour ajouter une machine esclave au cluster:

460

461

1. **Nom **: nom de machine esclave (arbitraire)

462

1. **URL du serveur** : URL du serveur esclave (ex: http:~/~/192.168.1.123:8080)

463

1. **Domaine** : Domaine DigDash Enterprise (par défaut ddenterpriseapi)

464

1. **Mot de passe** : Mot de passe de l'esclave tel que vous l'avez précédemment tapé lors de la configuration de la machine esclave (section **Clusters autorisés**, champ **Mot de passe**)

465

1. Cliquer sur le bouton **Ajouter** pour ajouter cette machine à votre cluster.

466

467

(% class="box infomessage" %)

468

(((

469

Note : Vous pouvez éditer ou supprimer des machines du cluster en les sélectionnant dans la liste **Sélection**, puis en cliquant sur les boutons **Editer** ou **Supprimer**.

470

)))

471

472

Utilisation de plusieurs maîtres dans un cluster

473

474

Certain déploiements nécessitent l’utilisation de plusieurs serveurs maîtres au sein d’un même « cluster ». Par exemple dans le cas d’un load balancer HTTP en amont qui envoie les sessions utilisateurs sur l’une ou l’autre machine maître. Ce mode est supporté dans DigDash en définissant plusieurs clusters identiques (un par machine maître). La liste des machines (Section Définition du cluster) doit être strictement identique sur toutes les définitions des clusters. C’est pour cela qu’il est possible de changer l’ordre des machines dans cette liste.

475

476

Exemple : On souhaite définir un cluster qui consiste en deux machines A et B. Chacune des deux machines est maître et esclave de l’autre.

477

478

On doit définir non pas un mais deux clusters A et B :

479

480

Dans la définition du cluster A :

481

482

1. [[Digdash 2019R2.Guide avancé.Serveur courant.WebHome]] : machine A (maître de ce cluster)

483

1. machine B (esclave de ce cluster)

484

485

Dans la définition du cluster B :

486

487

1. machine A (esclave de ce cluster)

488

1. [[Digdash 2019R2.Guide avancé.Serveur courant.WebHome]] : machine B (maître de ce cluster)

489

490

On voit que dans le cluster B, le maître (B) n’est pas la première machine de la liste. Ce qui est important ici c’est que la liste machine A, machine B est bien la même sur les deux clusters (qu’elle que soit leur fonction propre au sein de leur cluster respectif).

491

492

== Paramètres avancés spécifiques au clusters ==

493

494

Fichier modifié : **system.xml**

495

496

Exemple de syntaxe XML :

Paramètres disponibles :

503

504

* //Nom// : **CUBE_UPLOAD_MODE**

505

//Valeur// : entier : 0, 1 ou 2 (défaut : 1)

506

//Description// : Spécifie si les parts de cube doivent être téléchargées du serveur maître vers les serveurs esclaves au moment ou un utilisateur interagit avec le cube (1), quand le cube est généré par le serveur maître (2), ou jamais (0). Voir également le chapitre suivant : "//Utiliser le cluster//".

507

* Nom : **CLUSTER_TIMEOUT**

508

Valeur : entier : (millisecondes, défaut: 30000)

509

Description : Spécifie le timeout de toutes les requêtes intra-cluster (entre le maître et les esclaves), à l’exception de la requête de vérification de disponibilité d’un esclave (voir ci-dessous)

510

* Nom : **CLUSTER_CHECK_TIMEOUT**

511

Valeur : entier : (millisecondes, défaut: 5000)

512

Description : Spécifie le timeout de la requête de vérification de disponibilité d’un esclave. Ce timeout est plus court pour empêcher de bloquer trop longtemps le maître dans le cas ou un esclave est déconnecté du réseau.

513

514

== Utiliser le cluster ==

515

516

Dans un déploiement simple en mode cluster il n'y a rien à faire de plus que ce qui a été écrit précédemment.

517

518

Malgré tout, il y a certains détails intéressants qui peuvent aider à améliorer la performance d'un cluster.

519

520

Le cluster est utilisé en fonction de la taille du cubes de données. En dessous d'un certain seuil, dépendant du cube, de la machine maître et des esclaves, il est possible que le cluster ne soit pas utilisé. Par contre si la taille d'un ou plusieurs cubes de données devient importante, par exemple au delà de plusieurs centaines de millions de lignes, ceux-ci seront découpés en plusieurs parties et leur calcul (aplatissement) sera réparti en parallèle sur tous les processeurs disponibles du cluster pour diminuer le temps de réponse global. Et ceci pour chaque aplatissement d'un gros cube par un utilisateur du tableau de bord, du mobile, etc.

521

522

Il est à noter que la génération des cubes est de la responsabilité du serveur maître. Les esclaves n'interviennent que lors des aplatissements interactifs de cubes déjà générés (ex: affichage d'un flux, filtrage, drill...)

523

524

Les morceaux de cubes sont envoyés aux esclaves à la demande (s'ils ne les ont pas déjà). Ceci peut induire un ralentissement du système sur un premier aplatissement demandé par un utilisateur, notamment si la bande passante du réseau est faible (< 1 gigabit).

525

526

Il y a toutefois différents moyens d'éviter cet encombrement du réseau. Voici quelques suggestions :

527

528

Un premier moyen est de disposer du dossier **cubes** (sous-dossier de Application Data/Enterprise Server/ddenterpriseapi par défaut) sur un disque réseau accessible à toutes les machines du cluster. Par exemple via un lien symbolique (Linux, NFS). Ce lien devra être établi pour toutes les machines du cluster. Le principe est que le serveur maître générera les cubes dans ce dossier réseau, et lors de l'interaction d'un utilisateur avec le système, maître et esclaves auront tous une vue //commune// des cubes. La lecture des cubes du disque n'étant faite qu'une fois dans le cycle de vie d'un cube (cube //in-memory//), l'impact du dossier réseau sur les performances est négligeable.

529

530

Un autre moyen, est d'utiliser un outil tierce de synchronisation automatique de dossiers entre plusieurs machines, qui pourra copier l'ensemble du dossier cubes du serveur, après leur génération, vers les machines esclaves. Le principe est que le serveur maître générera les cubes dans son dossier local, puis l'outil de synchronisation copiera ce dossier sur toutes les machines esclaves. Tout ceci en dehors des périodes d'activité du serveur. Maître et esclaves auront tous une vue //identique// des cubes.

531

532

= Autres réglages avancés =

533

534

== Changement du chemin des fichiers de données ==

535

536

DigDash Enterprise stocke les informations de configuration, les modèles de données, les portefeuilles d'information, les cubes, l'historique des flux et d'autres fichiers de travail dans le **dossier de l'utilisateur du système d'exploitation**, dans un sous dossier **Application Data/Enterprise Server/<domaine>**.

537

538

Par exemple sous Windows, ce dossier est :

539

C:\Users\<utilisateur>\AppData\Roaming\Enterprise Server\ddenterpriseapi

540

541

Il est important de modifier ce dossier pour en garantir l'accessibilité (droits en lecture/écriture/exécution) et pour maitriser l'espace de stockage (ce dossier peut être volumineux).

542

Cette modification est aussi intéressante pour des raisons d'organisation, de scripting, etc.

543

544

Pour plus de détails rendez-vous dans les [[Guide d'installation Windows>>doc:Digdash.deployment.installation.install_guide_windows.WebHome||anchor="HEmplacementdudossierdevosdonnE9es" target="_blank"]] ou [[Guide d'installation Linux>>doc:Digdash.deployment.installation.install_guide_linux.WebHome||anchor="HEmplacementdudossierdevosdonnE9es" target="_blank"]].

545

546

== Règlages LDAP (adswrapper) : Port et dossier des données ==

547

548

Fichier modifié : **digdash.properties**

549

Voir le chapitre "[[Externalisation des paramètres dans un fichier properties>>doc:||anchor="externalisation" target="_blank"]]" pour effectuer cette manipulation.

550

551

Le paramètre **<nom du fichier war>.ads.ldap.port** (valeur par défaut : **11389**) défini le port réseau utilisé par le serveur LDAP intégré à DigDash Enterprise.

552

Il faut changer cette valeur si elle est déjà utilisée par un autre processus sur la machine, ou une autre instance LDAP (d'un autre domaine DigDash sur la même machine par exemple).

553

554

Exemple : si l'application s'appelle adswrapper (adswrapper.war) :

555

556

* adswrapper.ads.ldap.port=11590

557

558

Pour changer l'emplacement d'écriture des données de l'annuaire LDAP, voir [[Guide d'installation Windows>>doc:Digdash.deployment.installation.install_guide_windows.WebHome||anchor="HEmplacementdudossierdevosdonnE9es" target="_blank"]] ou [[Guide d'installation Linux>>doc:Digdash.deployment.installation.install_guide_linux.WebHome||anchor="HEmplacementdudossierdevosdonnE9es" target="_blank"]].

559

560

== {{id name="param_adv_dashboard"/}}Paramètres avancés de l'éditeur/viewer de tableaux de bord ==

561

562

Fichier modifié : **digdash.properties**

563

564

Voir le chapitre "[[Externalisation des paramètres dans un fichier properties>>doc:||anchor="externalisation" target="_blank"]]" pour effectuer cette manipulation.

565

566

Paramètres disponibles :

567

568

* //Nom// : **SERVERURL**

569

//Valeur// : URL du serveur DigDash Enteprise

570

//Description// : URL du serveur sur lequel le tableau de bord doit se connecter en priorité.

571

* //Nom// : **DOMAIN**

572

//Valeur// : Nom du domaine DigDash Enterprise

573

//Description// : Nom du domaine sur lequel le tableau de bord doit se connecter en priorité.

574

* //Nom// : **FORCESERVERURL**

575

//Valeur// : Booléen (défaut : false)

576

//Description// : Utilisé avec le paramètre **SERVERURL**. Force le serveur sur lequel le tableau de bord se connecte. L'utilisateur ne peut pas choisir un autre serveur.

577

* //Nom// : **FORCEDOMAIN**

578

//Valeur// : Booléen (défaut : false)

579

//Description// : Utilisé avec le paramètre **DOMAIN**. Force le domaine sur lequel le tableau de bord se connecte. L'utilisateur ne peut pas choisir un autre domaine.

580

* //Nom// : **GRIDSIZEEDITOR**

581

//Valeur// : Entier (défaut: 10)

582

//Description// : Taille en pixel de la grille magnétique d'édition du tableau de bord.

583

* //Nom// : **THEME**

584

//Valeur// : Nom du thème (défaut: vide)

585

//Description// : Nom du thème par défaut utilisé pour les utilisateur n'ayant pas de thème spécifique spécifié.

586

587

* //Nom //: **urlLogout**

588

//Valeur// : URL

589

//Description //: Spécifie une URL de sortie vers laquelle est redirigé l’utilisateur après une déconnexion du tableau de bord. Voir le paragraphe « //Redirection lors de la déconnexion du tableau de bord// ».

590

* //Nom //: **CANCHANGEPASSWORD**

591

//Valeur //: Booléen (défault : false)

592

//Description //: Permet l’activation d’un hyperlien « Mot de passe perdu » dans la page de login du tableau de bord. Cet hyperlien envoie un code de réinitialisation par émail à l’utilisateur. Voir paragraphe « //Activation de la fonctionnalité de réinitialisation du mot de passe// »

593

594

Exemple de contenu partiel du fichier **digdash.properties** :

595

596

597

digdash_dashboard.SERVERURL=http://localhost:8080

598

digdash_dashboard.FORCESERVERURL=true

599

digdash_dashboard.DOMAIN=ddenterpriseapi

600

digdash_dashboard.FORCEDOMAIN=true

601

digdash_dashboard.GRIDSIZEEDITOR=15

602

digdash_dashboard.THEME=Flat

603

digdash_dashboard.urlLogout=disconnected.html

604

digdash_dashboard.CANCHANGEPASSWORD=true

=== Redirection lors de la déconnexion du tableau de bord ===

609

610

Fichier modifié : **digdash.properties** (voir le chapitre précédent)

611

612

Vous pouvez spécifier une URL qui sera affichée dans le navigateur quand l'utilisateur se déconnecte du tableau de bord (bouton Déconnexion).

613

614

Modifier la valeur du paramètre **urlLogout** comme dans l'exemple suivant. Par défaut la valeur est vide, signifiant un retour à la page d'authentification du tableau de bord.

615

Les URLs relatives sont autorisées, par rapport à l'url de index.html de l'application digdash_dashboard :

digdash_dashboard.urlLogout=disconnected.html

=== Activation de la fonctionnalité de réinitialisation de mot de passe ===

624

625

Fichier modifié : **digdash.properties**, et page de Configuration des serveur DigDash

626

627

Vous pouvez activer la fonctionnalité de réinitialisation de mot de passe perdu.

628

Cette fonctionnalité affiche un hyperlien « **Mot de passe oublié **» dans la page de login du tableau de bord qui envoie à l’utilisateur un email contenant un code de réinitialisation de son mot de passe.

629

Ensuite l’utilisateur est redirigé vers une interface de réinitialisation pour saisir ce code et un nouveau mot de passe.

630

631

Prérequis sur le serveur DigDash :

632

633

* La fonctionnalité doit être aussi activée via la page de **Configuration des serveurs** / **Avancé** / **Divers** / **Autoriser la réinitialisation de mot de passe**

634

* Un serveur email valide doit être configuré dans la page **Configuration des serveurs** / **Avancé** / **Serveur émail système**

635

* Les utilisateurs doivent avoir une adresse email valide dans le champ LDAP **digdashMail**

636

637

L’activation de la fonction coté tableau de bord se fait en passant la variable **CANCHANGEPASSWORD** à la valeur **true **(voir le chapitre** **[[Paramètres avancés de l'éditeur/viewer de tableaux de bord>>doc:||anchor="param_adv_dashboard"]]).

digdash_dashboard.CANCHANGEPASSWORD=true

__Optionnel : Personnalisastion de l’email du code de réinitialisation__

646

647

Le sujet et le corps de l’émail du code de réinitialisation peuvent être customisés de la manière suivante :

648

649

1. Démarrer le Studio DigDash

650

1. Menu **Outils** / **Gestionnaire de traductions...**

651

1. Clic-droit sur la section **GLOBAL** puis **Ajouter…**

652

653

Nom de la clé : **LostPasswordMailSubject**

654

655

Saisir le sujet de l’émail dans les langues qui vous intéressent.

656

657

1. Clic-droit sur la section **GLOBAL** puis **Ajouter…**

658

659

Nom de la clé : **LostPasswordMailText**

660

661

Saisir le corps de l’émail dans les langues qui vous intéressent. Attention le corps de l’émail doit contenir au moins le mot-clé **${code}** qui sera substitué par le code de réinitialisation. Un autre mot-clé disponible est **${user}**.

662

Nous déconseillons d’indiquer trop d’informations dans cet émail, c’est pourquoi dans le message par défaut nous n’indiquons que le code de réinitialisation.

663

664

665

__Paramètres avancés spécifiques à la fonctionnalité de réinitialisation de mot de passe__

666

667

Fichier modifié : **system.xml**

668

669

Exemple de syntaxe XML :

Paramètres disponibles :

676

677

* //Nom// : **PROP_RESET_PASS_HASH**

678

//Valeur// : Chaîne non vide (défaut : aléatoire)

679

//Description// : Spécifie le code sel à utiliser pour la génération du code de réinitialisation de mot de passe. Par défaut cette chaîne est aléatoire, générée au lancement du serveur. Vous pouvez spécifier une chaîne de caractère qui sera utilisée par l’algorithme de génération du code de réinitialisation. Ceci peut-être utile si vous avez plusieurs serveurs (load-balancing HTTP) et pour qu’un code généré sur un serveur soit utilisable sur un autre.

680

* //Nom// : **PROP_RESET_PASS_VALIDITY**

681

//Valeur// : entier positif (défaut : 1)

682

//Description// : Spécifie la durée de validité minimale du code par tranche de 10 minutes. Une valeur de 1 donne une validité du code entre 10 et 20 minutes, une valeur de 2 entre 20 et 30 minutes, etc. La validité est importante pour minimiser les risques de vol de code à postériori.

683

* //Nom// : **PROP_RESET_PASS_LENGTH**

684

//Valeur// : entier positif (défaut : 10)

685

//Description// : Spécifie la longueur du code de réinitialisation. Une valeur trop faible est sujette aux tentatives d’attaques dites de force brute. Une valeur trop importante est sujette à des erreurs de saisie de la part des utilisateurs.

686

687

== Réglages de sécurité interne ==

688

689

Des réglages sur les mécanismes de protection intégrés à DigDash sont possibles. Vous pouvez vous référer au document [[Réglages de sécurité avancés>>doc:Digdash.deployment.security.advanced_security_settings.WebHome]].

690

691

== {{id name="externalisation"/}}{{id name="externalisation"/}}Externalisation des paramètres dans le fichier digdash.//properties// ==

692

693

Tous les paramètres des applications (fichiers .war) de DigDash Enterperise sont personnalisables dans un seul fichier texte au format [[**properties**>>https://fr.wikipedia.org/wiki/.properties]].

694

695

(% class="box infomessage" %)

696

(((

697

Cela permet de pré-configurer les paramètres des applications web avant même le premier démarrage.

698

Encore plus important, cela permet de simplifier la mise à jour des applications web de DigDash Enterprise (sans perdre la configuration).

699

)))

700

701

Le fichier **digdash.properties** complet est livré à la racine du **dossier d'installation**.

702

Tous les paramètres sont présents mais désactivés.

703

Pour les activer, supprimez le caractère **#** en début de ligne.

704

Les paramètres sont toujours **préfixés du nom de l'application concernée** (ex : ddenterpriseapi pour les paramètres de l'application ddenterpriseapi.war).

705

706

(% class="box infomessage" %)

707

(((

708

Exemple : si vous cherchez le paramètre **authMethod** du serveur (**ddenterpriseapi.war**) vous le trouverez sous la forme **ddenterpriseapi.authMethod.**

)))

(% class="box errormessage" %)

713

(((

714

Important : Utilisez le caractère slash « / » ou doublez le caractère anti-slash « \ » dans le fichier digdash.properties.

715

Exemple : ddenterpriseapi.//AppDataPath=C:/path/to/digdash_data

716

ou//

717

ddenterpriseapi.//AppDataPath=C:~\~\path~\~\to~\~\digdash_data//

718

)))

719

720

Pour que le fichier **digdash.properties** soit pris en compte de manière certaine, il faut spécifier son emplacement au lancement du serveur (Tomcat).

721

722

* Sous windows avec le serveur Tomcat fourni, aucune intervention nécessaire : le fichier setenv.bat est déjà configuré pour pointer vers le fichier à la racine de l'installation

723

* Sous linux avec le serveur Tomcat fourni, copiez le fichier **digdash.properties** dans le dossier **/etc/digdash**

724

* Avec votre propre serveur Tomcat, vous devrez éditer le fichier **setenv.bat** ou **setenv.sh** pour spécifier l'emplacement de votre fichier **digdash.properties**.

725

726

Voir les chapitres [[Guide d'installation Windows>>doc:Digdash.deployment.installation.install_guide_windows.WebHome||target="_blank"]] et [[Guide d'installation Linux>>doc:Digdash.deployment.installation.install_guide_linux.WebHome||target="_blank"]].

727

728

729

=== Priorité entre les niveaux de paramétrage ===

730

731

Les paramètres sont lus dans l'ordre suivant (dès qu'une valeur est trouvée, les niveaux suivants sont ignorés) :

732

733

1. Paramètre dans la commande de lancement du serveur Tomcat (-D<context>.<Parameter>=<value>)

734

1. Fichier .properties spécifié dans la commande en ligne du serveur Tomcat (-D<context>.properties.path=/the/path/to/<context>.properties)

735

1. Fichier .properties trouvé dans le dossier de travail du serveur Tomcat (<tomcat workdir>/<context>.properties)

736

1. Paramètre global dans la commande en ligne du serveur Tomcat (-D<Parameter>=<value>)

737

1. Fichier web.xml de chaque application (<context>/WEB-INF/web.xml)

738

739

=== Cloisonnement des paramètres ===

740

741

On appelle "Cloisonnement" la possibilité de cacher les paramètres d'un domaine pour tous les autres domaines d'un déploiement multi-domaines.

742

743

Le fichier **digdash.properties** contient les paramètres de tous les domaines, même ceux qui n'ont aucun lien entre eux.

744

Pour remédier à ça il est possible, **depuis la version 2021R1 patch 20210817**, de grouper les paramètres par domain.

745

Ainsi lors de la visualisation des paramètres via la page "**Etat du serveur**", seuls les paramètres du même groupe, ou sans groupe, seront visibles.

746

747

Prenons l'exemple d'un déploiement avec les domaines suivants :

748

749

* **ddenterpriseapi_client1**, **dashboard_client1**, **studio_client1**

750

* **ddenterpriseapi_client2**, **dashboard_client2**, **studio_client2**

751

752

La syntaxe pour grouper les paramètres est la suivante :

[groupe_client1].ddenterpriseapi_client1.AppDataPath=[...]

757

[groupe_client1].dashboard_client1.DOMAIN=[...]

758

[groupe_client1].studio_client1.SERVERURL=[...]

759

760

[groupe_client2].ddenterpriseapi_client2.AppDataPath=[...]

761

[groupe_client2].dashboard_client2.DOMAIN=[...]

762

[groupe_client2].studio_client2.SERVERURL=[...]

== Spécifier les paramètres de journalisation (//logging//) log4j.properties ==

767

768

Les paramètres de //logging// sont définis dans un fichier **log4j.properties** disponible dans chaque application web déployée.

769

770

Nous avons ajouté des options sur la ligne de commande de Tomcat pour permettre de spécifier des fichiers de paramétrage de //logging// externalisés :

771

772

773

-Dddenterpriseapi.ddlog4j.properties.path="/path/to/log4j.properties"

774

-Ddigdash_dashboard.ddlog4j.properties.path="/path/to/log4j.properties"

775

-Dadswrapper.ddlog4j.properties.path="/path/to/log4j.properties"

776

777

778

Vous pouvez aussi spécifier l’emplacement du fichier de log (global) sans avoir besoin de spécifier un fichier log4j.properties :

779

780

781

-Dlog4j.appender.R.File="/home/ddapi.log"

782

783

784

== Paramètres du Desktop Studio ==

785

786

Le Desktop Studio de DigDash Enterprise a aussi quelques paramètres optionnels spécifiés dans le fichier **digdash.properties.**

787

Voir le chapitre [[Externalisation des paramètres dans un fichier properties>>doc:||anchor="externalisation" target="_blank"]]

788

789

Liste des paramètres :

790

791

* //Nom// : **adminconsole.ddserver**

792

//Valeur// : URL du serveur DigDash Enterprise (défaut : vide)

793

//Description// : Spécifie l’URL du serveur auquel le Studio se connectera. Si non spécifié, le Studio utilisera le serveur de l’URL du fichier JNLP.

794

* //Nom// : **domain**

795

//Valeur// : Nom du domaine DigDash Enterprise

796

//Description// : Spécifie le nom du domaine DigDash Enterprise auquel le Studio se connectera. Si non spécifié, le Studio utilisera le domaine spécifié dans la page d’accueil de DigDash Enterprise.

797

* //Nom// : **forceServerDomain**

798

//Valeur// : Booléen (défaut : false)

799

//Description// : Indique au Studio que l’URL du serveur et le domaine sont modifiables (false) ou non (true) via le bouton **Avancé** dans la fenêtre de login du Studio. Si ce paramètre est activé, il est conseillé de spécifier les paramètres **ddserver** et **domain**.

800

* //Nom// : **dashboard**

801

//Valeur// : Nom de l’application tableau de bord

802

//Description// : Permet de spécifier le nom du de l’application du tableau de bord. Si non spécifié, le Studio utilisera le nom d’application spécifié dans la page d’accueil de DigDash Enterprise, par exemple « digdash_dashboard ».

803

* //Nom// : **authMode**

804

//Valeur// : Mode d’authentification du Studio (défaut : « default »)

805

//Description// : Mode d’authentification spécifique du Studio. Il faut que le serveur DigDash Enterprise reflète un mode d’authentification compatible (variable **authMethod** dans la configuration du serveur) : Consulter les documentations des add-ons liés à l’authentification et au SSO. Les valeurs possibles sont : « default », « NTUser », « NTUserOrLDAP » et « NTUserOrLDAP,loginForm ».

806

* //Nom// : **sslNoPathCheck**

807

//Valeur// : Booléen (défaut : false)

808

//Description// : Utilisé dans le cadre d’une connexion HTTPS. Indique au Studio de ne pas vérifier le chemin de certification du certificat de sécurité. Utilisé pour tester une configuration SSL avec un certificat auto-signé.// Ce setting n’est pas conseillé en production.//

809

* //Nom// : **sslNoHostNameCheck**

810

//Valeur// : Booléen (défaut : false)

811

//Description// : Utilisé dans le cadre d’une connexion HTTPS. Indique au Studio de ne pas vérifier le nom de domaine Internet. Utilisé pour tester une configuration SSL avec un certificat auto-signé.// Ce setting n’est pas conseillé en production.//

812

813

* //Nom// : **maxHeapSize**

814

//Valeur// : Quantité mémoire (défaut : en fonction de la JVM du poste client)

815

//Description// : Spécifie la quantité de mémoire du poste client allouée au Studio. La syntaxe est <quantité><unité>, où l’unité est une lettre « m » (mégaoctets) ou « g » (gigaoctets). Exemple : //maxHeapSize=2048m//

816

817

== Dossiers de données DigDash Enterprise ==

818

819

DigDash Enterprise stocke les données dans différents dossiers. Ce chapitre résume ces dossiers.

820

821

=== Données de configuration ===

822

823

//Localisation (par défaut)// : Dossier « Application Data » de l’utilisateur qui lance Tomcat (Windows), ou dossier de l’utilisateur (linux).

824

825

//Contenu// : Sous-dossiers contenant les modèles de données, tableaux de bords, portefeuilles de flux, formats, formules, scripts, styles, chaînes de connexions, etc :

826

827

* config : données de configuration communes, données de configuration des rôles, sauvegardes, et dossiers web customisés

828

* datasources : fichiers du serveur de document par défaut

829

* **server : **données de configuration des utilisateurs : portefeuille, modèle de données et tableaux de bord personnels, et serveur de documents personnalisé

830

831

//Modification// : **digdash.properties**, voir le chapitre [[Changement de l'emplacement des données>>doc:||anchor="HChangementduchemindesfichiersdedonnE9es"]]**.**

832

833

(% class="box infomessage" %)

834

(((

835

Note : La volumétrie des données générées peut-être importante notamment à cause des sous-dossiers **cubes** et **history**. Il est conseillé de placer ce dossier sur un disque disposant d’un quota d’espace important.

836

)))

837

838

=== Données générées ===

839

840

//Localisation// : Sous dossiers **cubes** et **history** du dossier de **données de configuration**.

841

842

//Contenu// : Cubes, historiques de flux :

843

844

* **cubes **: sous-dossiers des cubes générés (un par modèle de données).

845

* **history **: historique de tous flux, fichiers javascripts générés (modèle de données, vues de flux).

846

847

//Modification// : Impossible directement. Il faut modifier la localisation du dossier parent (**Données de configuration**), ou créer des liens.

848

849

(% class="box errormessage" %)

850

(((

851

Important : La volumétrie des données générées peut-être importante. Il est conseillé de placer le dossier parent (**Données de configuration**) sur un disque disposant d’un quota d’espace important.

852

)))

853

854

(% class="box infomessage" %)

855

(((

856

Note : Les dossiers **cubes** et **history** peuvent être supprimés pour nettoyage (serveur Tomcat stoppé). Ils seront recréés et les données rafraîchies à nouveau par l’ordonnanceur, ou par l’envoi d’un événement de rafraîchissement.

)))

=== Données LDAP ===

//Localisation (par défaut)// : dossier **ldapdigdash** dans le répertoire de travail de Tomcat (« workdir »).

862

863

//Contenu// : Fichiers de la partition LDAP contenant les définitions des utilisateurs, des rôles et des droits DigDash

864

865

Modification : **digdash.properties, **voir le chapitre [[Règlages LDAP (adswrapper) : Port et dossier des données>>doc:||anchor="HRE8glagesLDAP28adswrapper29A0:PortetdossierdesdonnE9es"]].

866

867

=== Base de données DDAudit ===

868

869

Localisation (par défaut) : répertoire de travail de Tomcat (« workdir »).

870

871

//Contenu// : Fichier de base de données (H2) contenant les tables des données DDAudit.

872

873

//Modification// : **digdash.properties** (Voir également [[Déploiement du module d'audit>>doc:Digdash.deployment.configuration.ddaudit_module_install.WebHome]])

874

875

876

ddenterpriseapi.audit.db.url=jdbc:h2:DDAudit_${server.DomainName};AUTO_SERVER=TRUE

877

878

879

=== Fichiers de journalisation (log) ===

880

881

//Localisation (par défaut)// : Fichier de log des modules de DigDash Enterprise (ddenterpriseapi, digdash_dashboard, studio, adswrapper).

882