• Changing the path of data files
• Location of system files
• LDAP settings (adswrapper) : Data port and folder
• Advanced settings for the dashboard editor/viewer
  • Redirection when logging out of the dashboard
  • Enable password reset functionality
• Internal security settings
• Externalization of parameters in the digdash.properties file
  • Priority between parameter levels
  • Parameter partitioning
• Specify logging parameters log4j.properties
• Studio settings
• DigDash Enterprise data folders
  • Configuration data
  • Data generated
  • LDAP data
  • DDAudit database

Changing the path of data files

DigDash Enterprise stores configuration information, data models, information wallets, cubes, flow history and other working files in the operating system user folder, in an Application Data/Enterprise Server/<domain> subfolder.

For example on Windows, this folder is:
C:\Users\AppData\Roaming\Enterprise Server\ddenterpriseapi

It is important to modify this folder to guarantee accessibility (read/write/execute rights) and to control storage space (this folder can be large).
This modification is also useful for reasons of organisation, scripting, etc.

For more details, see the Windows Installation Guide or Linux Installation Guide.

Location of system files

File modified: digdash.properties

It is possible to define a custom location for certain machine-specific configuration files by adding the ServerSettingsPath parameter to the digdash.properties file. When this parameter is set, the following files are stored in the specified folder, instead of the default directory (appdata>/Enterprise Server/ddenterpriseapi/config):

• system.xml
• serversettings.xml
• ldapsettings.xml
• clustersettings.xml
• quotarepository.xml

This separates machine-dependent configuration files from other parameters, making it easier to deploy on multiple environments or machines.

LDAP settings (adswrapper) : Data port and folder

File modified: digdash.properties
See chapter "Externalization of parameters in a properties file"to perform this operation.

The parameter <name of war file>.ads.ldap.port (default value: 11389) defines the network port used by the LDAP server integrated into DigDash Enterprise.
This value must be changed if it is already being used by another process on the machine, or another LDAP instance (from another DigDash domain on the same machine, for example).

Example: if the application is called adswrapper (adswrapper.war) :

• adswrapper.ads.ldap.port=11590

To change the location where LDAP directory data is written, see Windows installation guide or Linux installation guide.

Advanced settings for the dashboard editor/viewer

File modified: digdash.properties

See chapter "Externalizing parameters to a properties file"to perform this operation.

Available parameters:

• Name: SERVERURL
  Value: URL of the DigDash Enterprise server
  Description: URL of the server to which the dashboard should connect first.
• Name: DOMAIN
  Value: Name of the DigDash Enterprise domain
  Description: Name of the domain to which the dashboard should connect as a priority.
• Name: FORCESERVERURL
  Value: Boolean (default: false)
  Description: Used with the SERVERURL parameter. Forces the server to which the dashboard connects. The user cannot choose another server.
• Name: FORCEDOMAIN
  Value: Boolean (default: false)
  Description: Used with the DOMAIN parameter. Forces the domain to which the dashboard connects. The user cannot choose another domain.
• Name: GRIDSIZEEDITOR
  Value: Integer (default: 10)
  Description: Size in pixels of the magnetic grid used to edit the dashboard.
• Name: THEME
  Value: Theme name (default: empty)
  Description: Default theme name used for users who do not have a specific theme specified.

• Name : urlLogout
  Value: URL
  Description : Specifies an exit URL to which the user is redirected after logging out of the dashboard. See " Redirection on logging out of the dashboard ".
• Name : CANCHANGEPASSWORD
  Value : Boolean (default: false)
  Description : Enables a "Lost password" hyperlink to be activated on the dashboard login page. This hyperlink sends a reset code by email to the user. See paragraph " Activating the password reset function ".

Example of the partial content of the digdash.properties file:

Redirection when logging out of the dashboard

File modified: digdash.properties (see previous chapter)

You can specify a URL that will be displayed in the browser when the user logs out of the dashboard (Logout button).

Modify the value of the urlLogout parameter as in the following example. By default the value is empty, meaning that the user returns to the dashboard authentication page.
Relative URLs are authorised, in relation to the index.html url of the digdash_dashboard application:

Enable password reset functionality

File modified: digdash.properties, and DigDash Server Configuration page

You can enable the lost password reset feature.
This feature displays a "Forgot password" hyperlink in the dashboard login page that sends the user an email containing a password reset code.
The user is then redirected to a reset interface to enter this code and a new password.

DigDash server requirements:

• The functionality must also be enabled via the Server Parameters / Miscellaneous / Allow password reset page.
• A valid email server must be configured in the Server Parameters / Mail server page.
• Users must have a valid email address in the LDAP Email field

The dashboard function is activated by setting the CANCHANGEPASSWORD variable to true (see chapter Other advanced settings).

Optional: Customise the reset code email

The subject and body of the reset code email can be customised as follows:

1. Start the DigDash Studio
2. Click the Managers button and select Translation manager...
3. Right-click on the GLOBAL section then Add...

Key name: LostPasswordMailSubject

Enter the subject of the email in the languages you are interested in.

1. Right-click on the GLOBAL section then Add...

Key name: LostPasswordMailText

Enter the body of the email in the languages of your choice. Please note that the body of the email must contain at least the ${code} keyword, which will be replaced by the reset code. Another available keyword is ${user}.
We advise against providing too much information in this email, which is why in the default message we only provide the reset code.

Advanced parameters specific to the password reset functionality

File modified: system.xml

Example of XML syntax :

Available parameters:

• Name: PROP_RESET_PASS_HASH
  Value: Non-empty string (default: random)
  Description: Specifies the salt code to be used for generating the password reset code. By default this string is random, generated when the server is launched. You can specify a character string that will be used by the reset code generation algorithm. This can be useful if you have several servers (HTTP load-balancing) and so that a code generated on one server can be used on another.
   
• Name: PROP_RESET_PASS_VALIDITY
  Value: positive integer (default: 1)
  Description: Specifies the minimum validity time of the code in increments of 10 minutes. A value of 1 means that the code is valid for between 10 and 20 minutes, a value of 2 between 20 and 30 minutes, etc. The validity is important to minimise the risk of code theft at a later date.
   
• Name: PROP_RESET_PASS_LENGTH
  Value: positive integer (default: 10)
  Description: Specifies the length of the reset code. A value that is too low is subject to so-called brute force attack attempts. A value that is too large is subject to input errors by users.

Internal security settings

It is possible to adjust the protection mechanisms built into DigDash. Please refer to the document Advanced security settings.

Externalization of parameters in the digdash.properties file

All DigDash Enterprise application parameters (.war files) can be customised in a single text file in the format properties.

This allows web application parameters to be pre-configured even before the first start-up.
Even more importantly, this simplifies the updating of DigDash Enterprise web applications (without losing the configuration).

The complete digdash.properties file is delivered at the root of the installation folder.
All the parameters are present but deactivated.
To activate them, delete the # character at the beginning of the line.
The parameters are always prefixed with the name of the application concerned (e.g. ddenterpriseapi for the parameters of the ddenterpriseapi.war application).

Example: if you are looking for the authMethod parameter on the server (ddenterpriseapi.war) you will find it in the form ddenterpriseapi.authMethod.

Important:

• For file paths, use the slash character " /" or double the backslash character "\ " in the digdash.properties file.
  Example: ddenterpriseapi.AppDataPath=C:/path/to/digdash_data or ddenterpriseapi.AppDataPath=C:/path/to/digdash_data
• The " = " and "\ " (backslash) characters used in the values must be escaped by prefixing them with an "\ " (backslash)
  Example: password=Abcdef=123\; must be written in the digdash.properties file as follows: password=Abcdef\=123\; (note that the first " = " is not escaped as it delimits the value key).

During installation under Linux, the digdash.properties file is copied to the /etc/digdash folder by default. If you wish to specify another location for your digdash.properties file, edit the setenv.bat or setenv.sh file.

See the chapters Windows Installation Guide and Linux Installation Guide.

Priority between parameter levels

Parameters are read in the following order (as soon as a value is found, subsequent levels are ignored):

1. Parameter in the Tomcat server launch command (-D<context>.<Parameter>=<value>)
2. .properties file specified in the Tomcat server online command (-D<context>.properties.path=/the/path/to/<context>.properties)
3. .properties file found in the Tomcat server workdir (<tomcat workdir>/<context>.properties)
4. Global parameter in the Tomcat server online command (-D<Parameter>=<value>)
5. Web.xml file for each application (<context>/WEB-INF/web.xml)

Parameter partitioning

"Partitioning" is the ability to hide the parameters of one domain from all other domains in a multi-domain deployment.

The digdash.properties file contains the settings for all the domains, even those that have no link between them.
This means that when the settings are viewed via the"Server Status" page, only the settings in the same group, or without a group, will be visible.

Let's take the example of a deployment with the following domains:

• ddenterpriseapi_client1, dashboard_client1, studio_client1
• ddenterpriseapi_client2, dashboard_client2, studio_client2

The syntax for grouping parameters is as follows:

Specify logging parameters log4j.properties

Logging parameters are defined in a log4j2.properties file (or log4j.properties for adswrapper) available in each deployed web application.

Important : DigDash Enterprise does not support the XML format for log4j2 configuration files. The properties format must be used. Please note that the format of log4j2.properties files is different from that of previous versions of log4j.

We have added options on the Tomcat command line to allow external logging parameter files to be specified:

These settings can also be specified in the digdash.properties file:

Studio settings

The DigDash Enterprise Studio also has a number of optional parameters that can be specified in the digdash.properties file .
See chapter Externalizing parameters to a properties file

List of parameters :

• Name: adminconsole.ddserver
  Value: DigDash Enterprise server URL (default: empty)
  Description: Specifies the URL of the server to which the Studio will connect. If not specified, the Studio will use the server from the URL in the JNLP file.
• Name: domain
  Value: DigDash Enterprise domain name
  Description: Specifies the name of the DigDash Enterprise domain to which the Studio will connect. If not specified, the Studio will use the domain specified in the DigDash Enterprise home page.
• Name: forceServerDomain
  Value: Boolean (default: false)
  Description: Tells the Studio whether the server URL and domain can be changed (false) or not (true) via the Advanced button in the Studio login window. If this parameter is enabled, it is advisable to specify the ddserver and domain parameters.
• Name: dashboard
  Value: Dashboard application name
  Description: Used to specify the name of the dashboard application. If not specified, the Studio will use the application name specified in the DigDash Enterprise home page, for example "digdash_dashboard".
• Name: authMode
  Value: Studio authentication mode (default: "default")
  Description: Studio specific authentication mode. The DigDash Enterprise server must reflect a compatible authentication mode ( authMethod variable in the server configuration): See the documentation for add-ons related to authentication and SSO. Possible values are: "default", "NTUser", "NTUserOrLDAP" and "NTUserOrLDAP,loginForm".
• Name: sslNoPathCheck
  Value: Boolean (default: false)
  Description: Used for HTTPS connections. Tells the Studio not to check the certification path of the security certificate. Used to test an SSL configuration with a self-signed certificate. This setting is not recommended for production use.
• Name: sslNoHostNameCheck
  Value: Boolean (default: false)
  Description: Used for an HTTPS connection. Tells the Studio not to check the Internet domain name. Used to test an SSL configuration with a self-signed certificate. This setting is not recommended for production use.

• Name: maxHeapSize
  Value: Amount of memory (default: based on client workstation JVM)
  Description: Specifies the amount of client workstation memory allocated to the Studio. The syntax is <quantity><unit>, where the unit is a letter "m" (megabytes) or "g" (gigabytes). Example: maxHeapSize=2048m

DigDash Enterprise data folders

DigDash Enterprise stores data in a number of folders. This chapter summarises these folders.

Configuration data

Location (default): Application Data folder of the user launching Tomcat (Windows), or user folder (Linux).

Contents: Sub-folders containing data models, dashboards, Flow wallets, formats, formulas, scripts, styles, connection strings, etc :

• config: common configuration data, role configuration data, backups, and custom web folders
• datasources: default document server files
• server: user configuration data: wallets, personal data model and dashboards, and custom document server

Modification: digdash.properties, see chapter Changing the location of data.

Note: The volume of data generated can be significant, particularly because of the cubes and history sub-folders. It is advisable to place this folder on a disk with a large space quota.

Data generated

Location: Cubes and history sub-folders of the configuration data folder.

Content: Cubes, Flow histories:

• cubes : sub-folders of generated cubes (one per data model).
• history : history of all flows, generated javascript files (data model, flow views).

Modification: Impossible directly. You need to change the location of the parent folder (Configuration Data), or create links.

Important note: The volume of data generated can be significant. It is advisable to place the parent folder (Configuration Data) on a disk with a large space quota.

Note: The cubes and history folders can be deleted for cleaning (Tomcat server stopped). They will be recreated and the data refreshed again by the scheduler, or by sending a refresh event.

LDAP data

Location (default): ldapdigdash folder in the Tomcat work directory ("workdir").

Content: LDAP partition files containing definitions of DigDash users, roles and rights.

Modification: digdash.properties, see chapter LDAP settings (adswrapper) : Data port and folder.

DDAudit database

Location (default): Tomcat working directory ("workdir").

Contents: Database file (H2) containing the DDAudit data tables.

Modification: digdash.properties (See also Deploying the audit module)