Installation guide

🛈 Note
In the following examples, the database test and the server https://www.myserver.com are used for illustration purposes (e.g. in the path https://www.myserver.com/api/test). This database or server must be replaced accordingly in all actual requests. Depending on the configuration, the URL may also have to be extended by the context path (e.g. https://www.myserver.com/dataspot/api/test).

What's new?

The following changes to the configuration should be noted:

Release	Description
2026.1	The server parameter `DATASPOT_VERSION_HISTORY_RETENTION` defines the retention period of historic versions.
2025.1	An AI provider can be configured to support the input and editing of texts using artificial intelligence.
2025.1	`JdbcMetadataConnector` is replaced by `dataspot. Connector`. `JdbcMetadataConnector` is delivered and supported in release 2025.1 but will no longer be delivered in release 2026.1. Existing integrations must be migrated to `dataspot. Connector`.
2025.1	The server parameter `DATASPOT_MAIL_OAUTH` enables sending emails with Microsoft Graph and authentication using OAuth 2.0.
4.5	PostgreSQL 14 (14.11 or higher) or 15 is required for the on-premises installation of the application.
4.5	Java 17 is required for the on-premises installation of the application as well as for running the metadata connectors.
4.5	The server parameter `DATASPOT_HTTP_SECURE_ONLY` enables/disables additional protection against XSS (cross-site scripting) and MITM attacks (man-in-the-middle).
4.5	The server parameter `DATASPOT_POSTGRES_CONNECTION_PARAMS` defines additional database connection options and allows, for example, encryption using SSL/TLS, if the PostgreSQL server is configured accordingly.
4.4	The server parameters `DATASPOT_PROCESS_NOTIFICATIONS_CRON` and `DATASPOT_VALIDATE_ASSETS_CRON` have new default values.
4.3	The server parameters `DATASPOT_POSTGRES_READONLY_USER` and `DATASPOT_POSTGRES_READONLY_PASSWORD` define the user in PostgreSQL used to issue custom read-only SQL queries.
4.2	The server parameter `DATASPOT_REORG_DATABASES_CRON` defines the time of the regular deletion of old jobs and old notifications.
4.2	The server parameter `DATASPOT_VALIDATE_ASSETS_CRON` defines the time of the regular checking of rule violations.
4.2	The server parameter `DATASPOT_JOB_RETENTION` defines the retention period of jobs and their downloads, if any.
4.2	The server parameter `DATASPOT_MANUAL_URL` defines the URL to a customer-specific manual, that is opened by clicking the icon in the menu bar.

Docker container installation

The server component is delivered with the essential Docker configurations (Dockerfile), allowing to create an image or a container in which all required software packages and environment variables are preconfigured.

Required disk storage:

approx. 2 GB for the Docker image
minimum 10 GB additional disk storage

In principle, dataspot can be configured to run with any PostgreSQL instance (see PostgreSQL configuration). The following example illustrates how to configure dataspot and PostgreSQL in a Docker installation.

The command docker-compose is used to conveniently create and start a container (see also server parameters).

Example: `docker-compose.yml`

version: '3'

services:
  dataspot:
    container_name: dataspot
    depends_on:
      - postgres
    build:
      context: ./dataspot
      args:
        WARFILE: dataspot-v<release>.war
    volumes:
      - dataspot_db:/data/dataspot
      - /data/backup:/data/backup
    environment:
      - DATASPOT_ADMIN_PASSWORD=<admin_password>
      - DATASPOT_BACKUP_DATABASES_CRON=0 1 * * *
      - DATASPOT_APPROVE_TICKETS_CRON=0 22 * * 1-5
      - DATASPOT_POSTGRES_HOST=postgres
      - DATASPOT_POSTGRES_USER=postgres
      - DATASPOT_POSTGRES_PASSWORD=<postgres_password>
      - DATASPOT_POSTGRES_PATH=/usr/lib/postgresql/15/bin # PostgreSQL 15.x
      - CATALINA_OPTS="-XX:MaxRAMPercentage=75.0" # increase max heap space to 75% of the available RAM
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/status" ]
      interval: 30s
      retries: 3

  postgres:
    container_name: postgres
    image: postgres:15.15
    shm_size: 1g
    volumes:
      - postgres_db:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=<postgres_password>

volumes:
  postgres_db:
  dataspot_db:

⚠️ Attention
If a docker container should be externally visible over TCP/IP, then the corresponding public ports (see Docker documentation) must explicitly be published in docker-compose.yml.

🛈 Note
The size limit of the shared-memory to be used by the PostgreSQL container may have to be increased (e.g. shm_size: 1g).

Assuming the files dataspot-v<release>.war and Dockerfile are located in the directory ./dataspot and the backup directory /data/backup exists on the docker host system, the containers dataspot and postgres can be created and started as follows:

$ docker-compose build dataspot
$ docker-compose up -d dataspot

WAR file installation

Alternatively, the server component can be installed as a Java WAR file (Web Application Archive). The WAR file must be deployed in an already installed Java-EE servlet container (e.g. Tomcat).

The configuration is specified using environment variables or using servlet context parameters (see server parameters).

Required disk storage:

approx. 500 MB for the WAR file
minimum 10 GB additional disk storage

Required JDK/Servlet-Container:

dataspot is tested with JDK 17 and Tomcat 9. Currently, no guarantee can be provided for other configurations.

The rendering of diagrams requires the following open source package to be installed on the server:

graphviz

The backend and restore functions integrated in dataspot require the following package to be installed:

postgresql-client-14

On Linux these packages can typically be installed using the package managers of the respective distributions.

Tomcat configuration

The delivered WAR file (web application archive) must be copied to Tomcat's deployment directory /webapps. Assuming the installation directory of Tomcat is represented by $CATALINA_HOME, then the WAR file must be copied to the directory $CATALINA_HOME/webapps.

Tomcat automatically unpacks the WAR file into a subdirectory that has the same name as the WAR file. For example, the WAR file dataspot.war is automatically expanded into the directory $CATALINA_HOME/webapps/dataspot.

The context path (i.e. the web application's relative path on the server) corresponds to the name of the WAR file (or the expanded directory). For example, assuming the WAR file is dataspot.war, then the application is available at the following URL:

https://www.myserver.com/dataspot/

⚠️ Attention
The configuration file must have the same name as the corresponding WAR file. For example, if the configuration file is dataspot.xml, then the delivered WAR file (typically dataspot-v<release>.war) must be renamed to dataspot.war. To prevent automatic expansion into a directory with a wrong name, the WAR file should be renamed before being copied to the deployment directory.

To update the web application, e.g. with a new release, it is necessary to replace the WAR file in the directory $CATALINA_HOME/webapps and to delete the directory (with the old version) that was previously expanded by Tomcat, and then restart Tomcat.

💡 Tooltip
The web application can be deployed without a context path by renaming the WAR file to ROOT.war (before copying it to the deployment directory). The application is then available (without a context path) at the URL https://www.myserver.com/.

As an optimization, dataspot makes use of compressed files to minimize network traffic for certain artifacts. This feature can be enabled by setting the initialization parameter (init-param) named gzip in the DefaultServlet:

Example: `/usr/local/tomcat/conf/web.xml`

<servlet>
  <servlet-name>default</servlet-name>
  <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
+  <init-param>
+    <param-name>gzip</param-name>
+    <param-value>true</param-value>
+  </init-param>
  [..]
</servlet>

🛈 Note
Further information on installing Tomcat or deploying web applications can be found in the Tomcat documentation.

Frontend installation

The dataspot frontend is accessed through a web browser. Therefore, an installation of software on the client is not necessary.

Supported browsers:

Google Chrome
Apple Safari
Microsoft Edge
Mozilla Firefox

Server parameters

Dataspot is configured using server parameters. Server parameters are specified as environment variables (typically for Docker container installation) or as servlet context parameters (WAR file installation).

🛈 Note
If a server parameter is specified as an environment variable, the notation below applies, with the prefix DATASPOT_, in uppercase letters, and separated by _ (e.g. DATASPOT_ADMIN_PASSWORD). If specified as a servlet context parameter, the prefix DATASPOT_ must be omitted and the parameter is written in camelCase. For example, the environment variable DATASPOT_ADMIN_PASSWORD is specified as the context parameter adminPassword.

The following, general server parameters are supported. Further server parameters are described in the respective sections (PostgreSQL, Login ID and password, Single sign-on, Same sign-in, OpenID Connect, Email notifications).

Parameter	Description
`DATASPOT_ADMIN_PASSWORD`	Password of the system administrator (username: `admin`), who can create and manage databases and users
`DATASPOT_DATA_PATH`	Directory (path) used for data that is stored in the file system - default: `/data/dataspot`
`DATASPOT_BACKUP_PATH`	Directory (path) used for backups - default: `/data/backup`
`DATASPOT_BACKUP_ROTATION`	Number of backups to retain for the time units: day, week, month, and year (obsolete backups are deleted after the automatic backup) - default: `off` (backups are not deleted automatically) - example: `15` (retain backups of the last 15 days, as well as one each for the last 15 weeks, 15 months, and 15 years)
`DATASPOT_EXTERNAL_URL`	URL (without the context path) at which dataspot is externally available - example: `https://www.myserver.com`
`DATASPOT_MANUAL_URL`	URL to a customer-specific manual, that is opened by clicking the icon in the menu bar. Before opening the URL, the optional placeholder `${LANGUAGE}` is replaced by the current language (`en`, `de`). - optional; default: The delivered dataspot manual is opened - example: `https://www.myserver.com/manual/index.html` - example: `https://www.myserver.com/manual/${LANGUAGE}/index.html`
`DATASPOT_DEFAULT_DB`	Automatically redirect to a default database, if the URL to the application doesn't specify a database - optional; example: `test` (the URL `https://www.myserver.com` automatically redirects to `https://www.myserver.com/web/test`)
`DATASPOT_BACKUP_DATABASES_CRON` `DATASPOT_BACKUP_TIME`(deprecated)	Time (crontab expression) of the regular backup of all databases, or `off` (disabled) - optional; default: `off` (disabled)
`DATASPOT_APPROVE_TICKETS_CRON`	Time (crontab expression) of the regular approval process, or `off` (disabled) - optional; default: `0 22 * * 1-5` (Monday to Friday at 22:00)
`DATASPOT_PROCESS_NOTIFICATIONS_CRON`	Time (crontab expression) of the regular notification process, or `off` (disabled) - optional; default: `0 3 * * *` (Daily at 03:00)
`DATASPOT_VALIDATE_ASSETS_CRON`	Time (crontab expression) of the regular checking of rule violations, or `off` (disabled) - optional; default: `0 4 * * *` (Daily at 04:00)
`DATASPOT_REORG_DATABASES_CRON`	Time (crontab expression) of the regular deletion of - old jobs (see `DATASPOT_JOB_RETENTION`) - old notifications (see `DATASPOT_NOTIFICATION_RETENTION`) - old historic versions (see `DATASPOT_VERSION_HISTORY_RETENTION`) or `off` (disabled) - optional; default: `0 22 * * 6` (Every Saturday at 22:00)
`DATASPOT_JOB_RETENTION`	Retention period (format) of jobs and their downloads, if any. Older jobs and downloads are automatically deleted (see `DATASPOT_REORG_DATABASES_CRON`). - optional; default: `10d` (10 days)
`DATASPOT_NOTIFICATION_RETENTION`	Retention period (format) of notifications. Older notifications are automatically deleted (see `DATASPOT_REORG_DATABASES_CRON`). - optional; default: `90d` (90 days)
`DATASPOT_VERSION_HISTORY_RETENTION`	Retention period (format) of historic versions. Older historic versions are automatically deleted (see `DATASPOT_REORG_DATABASES_CRON`). - optional; default: `forever` (never delete)
`DATASPOT_WEB_SOCKETS`	Enables/Disables notifications over WebSockets [`true`,`false`] - default: `false`
`DATASPOT_LOGGING_LEVEL`	Logging Level [`DEBUG`,`INFO`,`WARN`,`ERROR`] - default: `ERROR`
`DATASPOT_DEFAULT_VALID_FROM_DATE`	Minimum timestamp - default: `1900-01-01T00:00:00.000`
`DATASPOT_DEFAULT_VALID_TO_DATE`	Maximum timestamp - default: `2999-12-31T23:59:59.999`
`DATASPOT_DBCP_VALIDATION_QUERY_TIMEOUT`	Timeout (in seconds) that is used to validate a database connection in the connection pool - default: `2` (seconds)
`DATASPOT_HTTP_SECURE_ONLY`	Enables/Disables additional protection against XSS (cross-site scripting) and MITM attacks (man-in-the-middle) [`true`,`false`]. If enabled, cookies are protected against access by client-side scripts and are transmitted exclusively over HTTPS. - optional; default: `true`

⚠️ Attention
The additional protection against XSS (cross-site scripting) and MITM attacks (man-in-the-middle) (see DATASPOT_HTTP_SECURE_ONLY) will allow the application to work correctly only with HTTPS. To test the application over HTTP directly after installation, e.g. before a TLS termination proxy is available, the additional protection against XSS and MITM attacks can be temporarily disabled. However, it is expressly recommended to activate the protection as soon as HTTPS is available.

🛈 Note
The URL DATASPOT_EXTERNAL_URL is used in notifications (e.g. emails) and in created PDFs to reference metadata objects in dataspot. Therefore, dataspot should be externally reachable at this URL.

💡 Tooltip
All regular processes that are controlled by a crontab expression (DATASPOT_BACKUP_DATABASES_CRON, DATASPOT_APPROVE_TICKETS_CRON, DATASPOT_PROCESS_NOTIFICATIONS_CRON), can be disabled by specifying off.

🛈 Note
If DATASPOT_WEB_SOCKETS is enabled, the WebSocket connection may not be disconnected by an intermediary proxy server. If necessary, the corresponding timeout must be configured on the proxy server.

🛈 Note
Notifications are not sent in real time. At the specified time (DATASPOT_PROCESS_NOTIFICATIONS_CRON), all unread notifications (since the last run) are emailed to the appropriate persons. Notifications are only sent if Send as Email is enabled in the user preferences.

⚠️ Attention
It is not recommended to operate a firewall (or a load balancer) between the application and database server, that automatically disconnects existing, idle connections after a timeout. However, if this is nevertheless the case, then the server parameter DATASPOT_DBCP_VALIDATION_QUERY_TIMEOUT specifies how long dataspot should wait for a (possibly disconnected) database connection before it is reconnected. If a proxy server or a reverse proxy is deployed, the respective HTTP methods (GET, POST, PUT, PATCH, DELETE) may not be rejected.

All attributes (except the password) have preconfigured default values. To prevent the configured values from being overridden by these default values, the XML attribute override="false" must be defined in the respective context parameters.

Example: `/usr/local/tomcat/conf/Catalina/localhost/dataspot.xml`

<Context>
    <Parameter name="adminPassword" value="s3cr3t"/>
    <Parameter name="dataPath" value="/data/dataspot" override="false"/>
    <Parameter name="backupPath" value="/data/backup" override="false"/>
    <Parameter name="backupDatabasesCron" value="0 1 * * *" override="false"/>
    <Parameter name="approveTicketsCron" value="0 22 * * 1-5" override="false"/>
    <Parameter name="loggingLevel" value="ERROR" override="false"/>
    <Parameter name="defaultValidFromDate" value="1900-01-01T00:00:00.000" override="false"/>
    <Parameter name="defaultValidToDate" value="2999-12-31T23:59:59.999" override="false"/>
    <Parameter name="postgresUser" value="postgres" override="false"/>
    <Parameter name="postgresPassword" value="<postgres_password>" override="false"/>
</Context>

⚠️ Attention
The file dataspot.xml must have the same name as the corresponding WAR file. Therefore, the delivered WAR file (typically dataspot-v<release>.war) may need to be renamed to dataspot.war.

Crontab expression

Certain server parameters specify a recurring point in time and are defined using a crontab expression. The point in time is determined by five fields:

*    *    *    *    *
|    |    |    |    |       
|    |    |    |    day of week (0 - 6, Sunday = 0)
|    |    |    |
|    |    |    month (1 - 12)
|    |    |
|    |    day of month (1 - 31)
|    |
|    hour (0 - 23)
|
minute (0 - 59)

An asterisk * specifies all possible values for a field (i.e. no restriction).
- For example: hour with the value * means every hour; day of month with the value * means every day.
A comma , specifies a list of values.
- For example: minute with the value list 0,15,30,45.
A dash - specifies a range of values.
- For example: 1-6 means the values from 1 to 6 (equivalent to 1,2,3,4,5,6).
A slash / specifies to skip a certain number of values.
- For example: minute with the value */15 means every 15 minutes (equivalent to 0,15,30,45).

🛈 Note
If ambiguous entries are defined, only one of the criteria must be met. For example, if both day of month and day of week are restricted (i.e. not *), then the current date only needs to meet one of these two criteria.

Example	Description
`* * * * *`	Every minute
`/10 * * *`	Every 10 minutes
`0 17 * * 0`	Every Sunday, at 17:00
`0 1 * * 2-5`	Tuesday to Friday, at 01:00
`30 07,09,13,15 * * *`	Daily, at 07:30, 09:30, 13:30, 15:30
`0 /4 * *`	Every four hours
`0 1 1,15 * *`	On the 1st and 15th of the month, at 01:00
`0 22 1 * 0`	Every Sunday or on the 1st of the month, at 22:00

PostgreSQL

⚠️ Attention
The installation of PostgreSQL is a prerequisite for running dataspot.

Dataspot can run with any, already installed PostgreSQL instance.

Required disk storage:

depending on the actual database size (> 100 GB))

🛈 Note
Dataspot is tested with PostgreSQL 14.x, 15.x, 16.x, and 17.x. The compatibility to other versions of PostgreSQL can be requested and is evaluated by dataspot on demand.

⚠️ Attention
The metadata query and metadata query API execute custom SQL statements on the metadata SQL views. To prevent long-running queries from having a negative impact on the performance or availability of the database or application, it is recommended to limit the runtime of SQL statements. The configuration parameter statement_timeout in PostgreSQL specifies the maximum runtime (in milliseconds), after which an SQL statement is automatically aborted.

The configuration is specified using the following server parameters:

Parameter	Description
`DATASPOT_POSTGRES_HOST`	PostgreSQL server name - default: `localhost`
`DATASPOT_POSTGRES_PORT`	PostgreSQL server port - default: `5432`
`DATASPOT_POSTGRES_USER`	User with appropriate authorization (see below)
`DATASPOT_POSTGRES_PASSWORD`	Password (see `DATASPOT_POSTGRES_USER`)
`DATASPOT_POSTGRES_READONLY_USER`	User for customer-specific, read-only SQL queries
`DATASPOT_POSTGRES_READONLY_PASSWORD`	Password (see `DATASPOT_POSTGRES_READONLY_USER`)
`DATASPOT_POSTGRES_CONNECTION_PARAMS`	Additional database connection options - optional - example: `ssl=true&sslmode=require` (the database connection is encrypted using SSL/TLS) - example: `ssl=true&sslmode=verify-ca` (the database connection is encrypted using SSL/TLS and the server certificate is verified)
`DATASPOT_POSTGRES_PATH`	PostgreSQL utilities (`pg_dump`, `pg_restore`, etc.) directory path - default: `/usr/bin` ⚠️ The utilities must match the PostgreSQL version used by the application!
`DATASPOT_POSTGRES_DB`	List of PostgreSQL databases that can be accessed by dataspot - optional (see PostgreSQL configuration, option 2)

⚠️ Attention
To encrypt the database connection using SSL/TLS (see server parameter DATASPOT_POSTGRES_CONNECTION_PARAMS), the PostgreSQL server must be configured accordingly:

The server certificate (e.g. server.crt) and the private key (e.g. server.key) must be available.

The encryption using SSL/TLS must be activated (postgresql.conf).

The authentication rules may need to be customized (pg_hba.conf).

💡 Tooltip
To verify which database connections are encrypted using SSL/TLS, the following SQL query can be executed:

select pg_ssl.pid, pg_ssl.ssl, pg_ssl.version, pg_sa.backend_type,
       pg_sa.usename, pg_sa.client_addr
from pg_stat_ssl pg_ssl join pg_stat_activity pg_sa on pg_ssl.pid = pg_sa.pid;

🛈 Note
The server parameters DATASPOT_POSTGRES_READONLY_USER and DATASPOT_POSTGRES_READONLY_PASSWORD define a user in PostgreSQL that allows querying metadata with custom SQL statements, either using the metadata query in the user interface or using the metadata query API.

When the application server is started, it checks whether the user already exists in the database. If the user does not exist, the user is created automatically (with the specified password) and is granted read-only permissions for all metadata SQL views. Alternatively, the user can be created manually by a database administrator along with the required permissions.

Depending on the authorization of the user DATASPOT_POSTGRES_USER, there are two setup options.

Option 1: `CREATEDB` permissions for the PostgreSQL instance

In this option, dataspot has the permission to manage databases in the PostgreSQL instance. Using the dataspot admin console, databases can be created, deleted, backed up, and restored.

Create a PostgreSQL user for dataspot

The following command creates a user named dataspot that has CREATEDB permission:

$ createuser -h <host> -p <port> -U <superuser> -W <password> -d -P dataspot
  Enter password for new role: ***** 
  Enter it again: ******

🛈 Note
In order to grant the created user superuser privileges, the option -s can optionally be specified.

Option 2: `GRANT ALL` permissions for the schema `dataspot`

In this option, dataspot only has access to a specific set of preconfigured databases.

Create a PostgreSQL user for dataspot

The following command creates a user named dataspot:

$ createuser -h <host> -p <port> -U <superuser> -W <password> -P dataspot
  Enter password for new role: ***** 
  Enter it again: ******

This user has no permissions to create databases.

⚠️ Attention
In this option, the user for querying metadata with custom SQL statements (see server parameters DATASPOT_POSTGRES_READONLY_USER and DATASPOT_POSTGRES_READONLY_PASSWORD) cannot be created automatically. The user must be created by a database administrator. The required permissions for the schema dataspot as well as the metadata SQL views are:

grant usage on schema dataspot to <user>
grant select on table dataspot.<view> to <user>

Create a database for use by dataspot

A database can be created by a database administrator following this pattern:

$ createdb --h <host> -p <port> -U <superuser> db_001
$ psql -h <host> -p <port> -U <superuser> -W <password> -d db_001 -c "create schema dataspot;grant all on schema dataspot to dataspot;"

In order for a database to be detected by dataspot, a logical and a physical name (separated by a colon) must be specified in the server configuration:

The logical name of the database is used by dataspot to initialize the database and is subsequently the database name visible to the dataspot user or administrator.
The physical name is the database name as used by the database administrator to create the database with the preconfigured schema dataspot (as described above).

Example

In the following example, two databases are configured to be accessed by dataspot. In dataspot, the databases are visible as dxmeta and playground. On the database server, the databases were created as db_001 and db_002, respectively.

The corresponding environment variable is:

DATASPOT_POSTGRES_DB=dxmeta:db_001;playground:db_002

The corresponding servlet context parameter is:

<Context>
    <Parameter name="postgresDb" value="dxmeta:db_001;playground:db_002"/>
</Context>

Once configured, these (and only these) databases can now be accessed and initialized in the dataspot admin console. Initializing a database in the dataspot admin console will create the respective SQL objects in the schema dataspot.

Deleting a database in the dataspot admin console will not actually delete the database but rather reset the schema dataspot to the initial state.

Backup and restore can be performed for the configured databases in the dataspot admin console. Alternatively, backup and restore may also be done outside of dataspot.

Maximum connections

Dataspot uses a connection pool to access the PostgreSQL databases. By default, PostgreSQL allows a maximum of 100 connections to the database server. Depending on the number of dataspot databases, the maximum number of database connections may need to be increased.

🛈 Note
The maximum number of required database connections can be approximated as follows:
max_connections = (number of databases + 1) * 8

For example, in the docker container installation this can be configured as:

postgres:
  [..]
  command: postgres -c 'max_connections=160'

Authentication

The application server connects to the database with a user name and an encrypted password (scram-sha-256 or md5), which is compared with the encrypted password on the database server.

Note

Since PostgreSQL 14.x, passwords on the database server are stored encrypted with scram-sha-256 by default (postgresql.conf).

To ease the transition from md5 to scram-sha-256, the authentication method scram-sha-256 is automatically selected in case md5 is specified as the authentication method (pg_hba.conf) but the password stored on the database server is encrypted with scram-sha-256.

It may be necessary to change the following setting in the configuration (pg_hba.conf):

host all all 127.0.0.1/32 scram-sha-256

Artificial Intelligence (AI)

An AI provider (e.g. Azure OpenAI Service) can be configured to support the input and editing of texts using artificial intelligence (AI).

The configuration is specified using the following server parameters:

Parameter	Description
`DATASPOT_AI`	Enables/Disables AI support [`true`,`false`] - default: `false`
`DATASPOT_AI_ENDPOINT`	The service endpoint of the AI provider
`DATASPOT_AI_DEPLOYMENT_NAME`	The name of the customer-specific model deployment (the name is assigned in the AI portal and referenced in all API calls)
`DATASPOT_AI_API_KEY`	The secret API key to authenticate (the API key is created in the AI portal) - optional
`DATASPOT_AI_OAUTH`	Enables/Disables authentication with OAuth 2.0 [`true`,`false`] - default: `false`
`DATASPOT_AI_OAUTH_TENANT_ID`	OAuth 2.0 Tenant ID
`DATASPOT_AI_OAUTH_CLIENT_ID`	OAuth 2.0 Client ID
`DATASPOT_AI_OAUTH_CLIENT_SECRET`	OAuth 2.0 Client Secret; Authentication with a client secret - optional
`DATASPOT_AI_OAUTH_CERTIFICATE_FILE`	OAuth 2.0 Client Certificate; Authentication with a client certificate (full path) - optional; default: `/data/dataspot/certs/ai_oauth.pfx`
`DATASPOT_AI_OAUTH_CERTIFICATE_PASSWORD`	OAuth 2.0 Client Certificate Password; If the client certificate is protected with a password (see `DATASPOT_AI_OAUTH_CERTIFICATE_FILE`) - optional

Email notifications

Dataspot is capable of sending automatic email notifications at certain processing stages, for example during status transitions in the workflow process.

Emails can be sent using Microsoft Graph and authentication with OAuth 2.0 (Client Secret or Client Certificate) (see DATASPOT_MAIL_OAUTH). Alternatively, an SMTP server can be used to send emails (see DATASPOT_MAIL_SMTP).

Note

Authentication with user name and password (Basic Auth) for SMTP is no longer supported by Microsoft Exchange Online (Microsoft 365).

The configuration is specified using the following server parameters:

Parameter	Description
`DATASPOT_MAIL_OAUTH`	Enables/Disables email notifications with OAuth 2.0 [`true`,`false`] - default: `false`
`DATASPOT_MAIL_OAUTH_PROVIDER_URL`	OAuth 2.0 Provider URL
`DATASPOT_MAIL_OAUTH_CLIENT_ID`	OAuth 2.0 Client ID
`DATASPOT_MAIL_OAUTH_CLIENT_SECRET`	OAuth 2.0 Client Secret; Authentication with a client secret - optional
`DATASPOT_MAIL_OAUTH_CERTIFICATE_FILE`	OAuth 2.0 Client Certificate; Authentication with a client certificate (full path) - optional; default: `/data/dataspot/certs/mail_oauth.pfx`
`DATASPOT_MAIL_OAUTH_CERTIFICATE_PASSWORD`	OAuth 2.0 Client Certificate Password; If the client certificate is protected with a password (see `DATASPOT_MAIL_OAUTH_CERTIFICATE_FILE`) - optional
`DATASPOT_MAIL_SMTP`	Enables/Disables email notifications with SMTP [`true`,`false`] - default: `false`
`DATASPOT_MAIL_SMTP_HOST`	SMTP server name
`DATASPOT_MAIL_SMTP_PORT`	SMTP server port - default: `587`
`DATASPOT_MAIL_SMTP_USER`	User with authorization to send emails on the SMTP server
`DATASPOT_MAIL_SMTP_PASSWORD`	Password (see `DATASPOT_MAIL_SMTP_USER`)
`DATASPOT_MAIL_SMTP_AUTH`	Enables/Disables authentication using the `AUTH` command [`true`,`false`] - optional; default: `true`
`DATASPOT_MAIL_SMTP_STARTTLS_ENABLE`	Enables/Disables TLS encryption using the `STARTTLS` command [`true`,`false`] - optional; default: `true`
`DATASPOT_MAIL_FROM`	Email header: Field `From`
`DATASPOT_MAIL_REPLY_TO`	Email header: Field `Reply-To` - optional

First steps

Congratulations, you have successfully completed the installation of dataspot!

Admin console

After installation, the admin console of dataspot is available at the following URL:

https://www.myserver.com/dataspot/web/admin

Logging into the admin console is possible with the system administrator admin and the configured password (see server parameter DATASPOT_ADMIN_PASSWORD).

The admin console allows databases to be created and deleted, or to be restored from previous backups. A newly created database named <database> is available at the following URL:

https://www.myserver.com/dataspot/web/<database>

Predefined databases

The predefined database meta describes the metamodel of dataspot and documents all properties and relationships of metadata objects. The metamodel provides the foundation for all interfaces (metadata REST/API, metadata SQL views, metadata upload/download). The metamodel meta is available at the following URL:

https://www.myserver.com/dataspot/web/meta

💡 Tooltip
The database meta can be created and deleted in the admin console, or be restored to the factory settings.

Add user

The system administrator has access to any database. However, due to governance reasons, only the organization may be modified and users may be created, modified, or deleted. Therefore, to create new models, the first step of the system administrator is to create an administrator (metadata manager) for the database.

🛈 Note
If necessary, the current tenant can be selected in the personal user menu of the system administrator, by clicking in the menu bar on the icon .

Open the organization in the sidebar
Click the tab "Persons" and the icon "+"
Create a person that should be the administrator of the database
Open the tenant in the sidebar
Click the tab "Users" and the icon "+"
Create a user for the administrator
- Specify Login ID and Password
- Set Access level to Administrator
- Select the previously created person in Is person
- Click the Add button

The newly created metadata manager can now log into the application and has full access to this database (including creating, modifying, and deleting users).

🛈 Note
The dataspot online manual can be accessed by clicking the icon in the menu bar.

What's new?​

Docker container installation​

Example: docker-compose.yml​

WAR file installation​

Tomcat configuration​

Example: /usr/local/tomcat/conf/web.xml​

Frontend installation​

Server parameters​

Example: /usr/local/tomcat/conf/Catalina/localhost/dataspot.xml​

Crontab expression​

PostgreSQL​

Option 1: CREATEDB permissions for the PostgreSQL instance​

Create a PostgreSQL user for dataspot​

Option 2: GRANT ALL permissions for the schema dataspot​

Create a PostgreSQL user for dataspot​

Create a database for use by dataspot​

Example​

Maximum connections​

Authentication​

Artificial Intelligence (AI)​

Email notifications​

First steps​

Admin console​

Predefined databases​

Add user​

What's new?

Docker container installation

Example: `docker-compose.yml`

WAR file installation

Tomcat configuration

Example: `/usr/local/tomcat/conf/web.xml`

Frontend installation

Server parameters

Example: `/usr/local/tomcat/conf/Catalina/localhost/dataspot.xml`

Crontab expression

PostgreSQL

Option 1: `CREATEDB` permissions for the PostgreSQL instance

Create a PostgreSQL user for dataspot

Option 2: `GRANT ALL` permissions for the schema `dataspot`

Create a PostgreSQL user for dataspot

Create a database for use by dataspot

Example

Maximum connections

Authentication

Artificial Intelligence (AI)

Email notifications

First steps

Admin console

Predefined databases

Add user