TIBCO EBX®
Documentation > Administration Guide > Installation & configuration
Navigation modeDocumentation > Administration Guide > Installation & configuration

TIBCO EBX® main configuration file

Overview

The EBX® main configuration file, by default named ebx.properties, contains most of the basic parameters for running EBX®. It is a Java properties file that uses the standard simple line-oriented format.

The main configuration file complements the Java EE deployment descriptor. Administrators can also perform further configuration through the user interface, which is then stored in the EBX® repository.

Location of the file

The access path to the main configuration file can be specified in several ways. In order of descending priority:

  1. By defining the Java system property 'ebx.properties'. For example, this property can be set by adding the option -Debx.properties=<filePath> to the java command-line command. See Java documentation.

  2. By defining the servlet initialization parameter 'ebx.properties'.

    This standard Java EE setting must be specified in the web.xml file of the web application 'ebx'. EBX® accesses this parameter by calling the method ServletConfig.getInitParameter("ebx.properties") in the servlet FrontServlet.

    See getInitParameter in the Oracle ServletConfig documentation.

  3. By default, if nothing is specified, the main configuration file is located at WEB-INF/ebx.properties of the web application 'ebx'.

Note

In addition to specifying properties in the main configuration file, it is also possible to set the values of properties directly in the system properties. For example, using the -D argument of the java command-line command.

Custom properties and variable substitution

The value of any property can include one or more variables that use the syntax ${propertyKey}, where propertyKey is either a system property, or a property defined in the main configuration file.

For example, the default configuration file provided with EBX® uses the custom property ebx.home to set a default common directory, which is then included in other properties.

Setting automatic installation on first launch

Repository can be automatically installed on first startup.

##################################################################
## Installation on first launch.
## All values are ignored if the repository is  already installed.
##################################################################
## Enables repository installation on first startup (default is false).
ebx.install.enabled=true

## Following properties configure the repository. Values are optional and defaults are automatically generated.
ebx.install.repository.id=00275930BB88
ebx.install.repository.label=A Test

## Following properties specify the EBX administrator. These are ignored if a custom directory is defined.
ebx.install.admin.login=admin
ebx.install.admin.firstName=admin
ebx.install.admin.lastName=admin
ebx.install.admin.email=adamin@example.com

## Following property specifies the non-encrypted password used for the EBX administrator.
## It is ignored if a custom directory is defined. It cannot be set if property ebx.install.admin.password.encrypted is set.
#ebx.install.admin.password=admin

## Following property specifies the encrypted password used for the EBX administrator.
## It is ignored if a custom directory is defined. It cannot be set if property ebx.install.admin.password is set.
## Password can be encrypted by using command:
##  java -cp ebx.jar com.orchestranetworks.service.directory.EncryptPassword password_to_encrypt
ebx.install.admin.password.encrypted=8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918

Setting the EBX® root directory

The EBX® root directory contains the Lucene indexes directory, the archives, the XML audit trail and, when the repository is persisted on H2 standalone mode, the H2 database files.

#################################################
## Path for EBX® XML repository
#################################################
ebx.repository.directory=${ebx.home}/ebxRepository

Configuring the EBX® repository

Before configuring the persistence properties of the EBX® repository, carefully read the section Technical architecture in the chapter 'Repository administration'.

The required library (driver) for each supported database is described in the chapter Database drivers.

################################################################
## The maximum time to set up the database connection, 
## in milliseconds. 
################################################################
ebx.persistence.timeout=10000
################################################################
## The prefix to add to all table names of persistence system.
## This may be useful for supporting multiple repositories in the relational database.
## Default value is 'EBX_'.
################################################################
ebx.persistence.table.prefix=

################################################################
## Case EBX® persistence system is H2 'standalone'.
################################################################
ebx.persistence.factory=h2.standalone
ebx.persistence.user=sa
ebx.persistence.password=

################################################################
## Case EBX® persistence system is H2 'server mode',
################################################################
#ebx.persistence.factory=h2.server

## Specific properties to be set only only if you want to ignore the standard 
## deployment process of 'ebx' web application in the target operational environment	
## (see the deployment descriptor 'web.xml' of 'ebx' web application).
#ebx.persistence.url=jdbc:h2:tcp://127.0.0.1/ebxdb
#ebx.persistence.user=xxxxxxxxx
#ebx.persistence.password=yyyyyyyy


################################################################
## Case EBX® persistence system is Oracle database.
################################################################
#ebx.persistence.factory=oracle

## Specific properties to be set only only if you want to ignore the standard 
## deployment process of 'ebx' web application in the target operational environment	
## (see the deployment descriptor 'web.xml' of 'ebx' web application).
#ebx.persistence.url=jdbc:oracle:thin:@127.0.0.1:1521:ebxDatabase
#ebx.persistence.driver=oracle.jdbc.OracleDriver
#ebx.persistence.user=xxxxxxxxx
#ebx.persistence.password=yyyyyyyy


## Activate to use VARCHAR2 instead of NVARCHAR2 on Oracle; never modify on an existing repository.
#ebx.persistence.oracle.useVARCHAR2=false

################################################################
## Case EBX® persistence system is SAP Hana
################################################################
#ebx.persistence.factory=hana

## Specific properties to be set only only if you want to ignore the standard 
## deployment process of 'ebx' web application in the target operational environment	
## (see the deployment descriptor 'web.xml' of 'ebx' web application).
#ebx.persistence.url=jdbc:sap://127.0.0.1:39041
#ebx.persistence.driver=com.sap.db.jdbc.Driver
#ebx.persistence.user=xxxxxxxxx
#ebx.persistence.password=yyyyyyyy


################################################################
## Case EBX® persistence system is Microsoft SQL Server.
################################################################
#ebx.persistence.factory=sqlserver

## Specific properties to be set only only if you want to ignore the standard 
## deployment process of 'ebx' web application in the target operational environment	
## (see the deployment descriptor 'web.xml' of 'ebx' web application).
#ebx.persistence.url= \
#jdbc:sqlserver://127.0.0.1:1036;databasename=ebxDatabase
#ebx.persistence.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver
#ebx.persistence.user=xxxxxxxxx
#ebx.persistence.password=yyyyyyyy


################################################################
## Case EBX® persistence system is Microsoft Azure SQL database.
################################################################
#ebx.persistence.factory=azure.sql

## Specific properties to be set only only if you want to ignore the standard 
## deployment process of 'ebx' web application in the target operational environment	
## (see the deployment descriptor 'web.xml' of 'ebx' web application).
#ebx.persistence.url= \
#jdbc:sqlserver://myhost.database.windows.net:1433;database=ebxDatabase;encrypt=true;\
#trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;
#ebx.persistence.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver
#ebx.persistence.user=xxxxxxxxx
#ebx.persistence.password=yyyyyyyy

 
################################################################
## Case EBX® persistence system is PostgreSQL.
################################################################
#ebx.persistence.factory=postgresql

## Specific properties to be set only only if you want to ignore the standard 
## deployment process of 'ebx' web application in the target operational environment	
## (see the deployment descriptor 'web.xml' of 'ebx' web application).
#ebx.persistence.url=jdbc:postgresql://127.0.0.1:5432/ebxDatabase
#ebx.persistence.driver=org.postgresql.Driver
#ebx.persistence.user=xxxxxxxxx
#ebx.persistence.password=yyyyyyyy

Configuring the user and roles directory

This parameter specifies the Java directory factory class name. It must only be defined if not using the default EBX® directory.

#################################################
## Specifies the Java directory factory class name. 
## Value must be the fully qualified name of the Java class. 
## The class must extend com.orchestranetworks.service.directory.DirectoryFactory.
#################################################
#ebx.directory.factory=xxx.yyy.DirectoryFactoryImpl

It is also possible to disable the built-in role "ADMINISTRATOR".

#################################################
## Specifies whether the built-in role ADMINISTRATOR is disabled.
## Default value is false.
#################################################
#ebx.directory.disableBuiltInAdministrator=true

Configuring EBX® localization

This parameter is used to configure the locales used at runtime. This list must contain all the locales that are exposed to the end-user. EBX® will not be able to display labels and messages in a language that is not declared in this list.

The default locale must be the first one in the list.

##################################################################
## Available locales, separated by a comma.
## The first element in the list is considered as the default locale.
## If not set, available locales are 'en-US, fr-FR'.
##
##################################################################
#ebx.locales.available=en-US, fr-FR

Setting temporary files directories

Temporary files are stored as follows:

#################################################
## Directories for temporary resources.
#################################################
# The property ebx.temp.directory allows to specify a directory for temporary files.
# Default value is java.io.tmpdir
# 
ebx.temp.directory = ${java.io.tmpdir}
#ebx.temp.directory = /tmp/java

# The property ebx.temp.cache.directory allows to specify the directory containing temporary files for cache.
# Default value is ${ebx.temp.directory}/ebx.platform.
#ebx.temp.cache.directory = ${ebx.temp.directory}/ebx.platform

# The property ebx.temp.import.directory allows to specify the directory containing temporary files for import.
# Default value is ${ebx.temp.directory}/ebx.platform.
#ebx.temp.import.directory = ${ebx.temp.directory}/ebx.platform

Activating the XML audit trail

By default, the XML audit trail is deactivated. It can be activated using the following variable:

##################################################################
# The XML history has been replaced by an SQL history.
# This old XML history can be activated using the following variable.
# Default is false.
##################################################################
ebx.history.xmlaudittrail.activated = false
See also

Configuring the EBX® logs

The most important logging categories are:

ebx.log4j.category.log.kernel

Logs for EBX® main features, processes, exceptions and compilation results of modules and data models.

ebx.log4j.category.log.workflow

Logs for main features, warnings and exceptions about workflow.

ebx.log4j.category.log.persistence

Logs related to communication with the underlying database.

ebx.log4j.category.log.setup

Logs for the compilation results of all EBX® objects, except for modules and data models.

ebx.log4j.category.log.validation

Logs for datasets validation results.

ebx.log4j.category.log.mail

Logs for the activity related to the emails sent by the server (see Activating and configuring SMTP and emails).

Note: This category must not use the Custom SMTP appender in order to prevent infinite loops.

ebx.log4j.category.log.d3

Logs for D3 events on EBX®.

ebx.log4j.category.log.dataservices

Logs for data service events in EBX®.

ebx.log4j.category.log.monitoring

Raw logs for memory monitoring.

ebx.log4j.category.log.request

Logs for Request and Query events in EBX®: executions having a duration exceeding ebx.logs.request.durationThreshold milliseconds, requests / queries where the optimization phase exceeds ebx.logs.request.optimizationThreshold milliseconds and executions that internally throw an exception while iterating the results. All requests / queries are logged regardless of their duration, if log level is set to DEBUG.

ebx.log4j.category.log.restServices

Logs for REST services events in EBX®, including those from the REST Toolkit.

Some of these categories can also be written to through custom code using the LoggingCategory interface.

 #################################################
## Log4J properties:
##
## We have some specific syntax extensions:
## - Appender ebxFile:<aFileName>
## Defines a file appender with default settings (threshold=DEBUG)
##
## - property log.defaultConversionPattern is set by Java
#################################################
#ebx.log4j.debug=true
#ebx.log4j.disable=
ebx.log4j.rootCategory= INFO
ebx.log4j.category.log.kernel= INFO, Console, ebxFile:kernel, kernelMail
ebx.log4j.category.log.workflow= INFO, ebxFile:workflow
ebx.log4j.category.log.persistence= INFO, ebxFile:persistence
ebx.log4j.category.log.setup= INFO, Console, ebxFile:kernel
ebx.log4j.category.log.mail= INFO, Console, ebxFile:mail
ebx.log4j.category.log.frontEnd= INFO, Console, ebxFile:kernel 
ebx.log4j.category.log.frontEnd.incomingRequest= INFO
ebx.log4j.category.log.frontEnd.requestHistory= INFO
ebx.log4j.category.log.frontEnd.UIComponentInput= INFO
ebx.log4j.category.log.fsm= INFO, Console, ebxFile:fsm
ebx.log4j.category.log.fsm.dispatch= INFO
ebx.log4j.category.log.fsm.pageHistory= INFO
ebx.log4j.category.log.wbp= FATAL, Console
#--------------------------------------------------
ebx.log4j.appender.Console.Threshold = INFO
ebx.log4j.appender.Console=com.onwbp.org.apache.log4j.ConsoleAppender
ebx.log4j.appender.Console.layout=com.onwbp.org.apache.log4j.PatternLayout
ebx.log4j.appender.Console.layout.ConversionPattern=${log.defaultConversionPattern}
#--------------------------------------------------
ebx.log4j.appender.kernelMail.Threshold = ERROR
ebx.log4j.appender.kernelMail = com.onwbp.org.apache.log4j.net.SMTPAppender
ebx.log4j.appender.kernelMail.To = admin@domain.com
ebx.log4j.appender.kernelMail.From = admin${ebx.site.name}
ebx.log4j.appender.kernelMail.Subject = EBX® Error on Site ${ebx.site.name} (VM ${ebx.vm.id})
ebx.log4j.appender.kernelMail.layout.ConversionPattern=**Site ${ebx.site.name} (VM${ebx.vm.id})**%n${log.defaultConversionPattern}
ebx.log4j.appender.kernelMail.layout = com.onwbp.org.apache.log4j.PatternLayout

#--------------------------------------------------
ebx.log4j.category.log.monitoring= INFO, ebxFile:monitoring
ebx.log4j.category.log.dataServices= INFO, ebxFile:dataServices
ebx.log4j.category.log.d3= INFO, ebxFile:d3
ebx.log4j.category.log.request= INFO, ebxFile:request
ebx.log4j.category.log.restServices= INFO, ebxFile:dataServices

Custom 'ebxFile' appender

The token ebxFile: can be used as a shortcut to define a daily rolling file appender with default settings. It must be followed by a file name. It then activates an appender that writes to a file located in the directory ebx.logs.directory, with a threshold set to DEBUG.

The property ebx.log4j.appender.ebxFile.backup.Threshold allows defining the maximum number of backup files for daily rollover.

#################################################
## Directory of log files 'ebxFile:'
## This property is used by special appender prefixed
## by 'ebxFile:' (see log section below)
#################################################
ebx.logs.directory=${ebx.home}/ebxLog

################################################################
# Daily rollover threshold of log files 'ebxFile:'
# Specifies the maximum number of backup files for daily rollover of 'ebxFile:' appenders.
# When set to a negative value, backup log files are never purged.
# Default value is -1.
################################################################
ebx.log4j.appender.ebxFile.backup.Threshold=-1

Custom SMTP appender

The appender com.onwbp.org.apache.log4j.net.SMTPAppender provides an asynchronous email sender.

Custom module log threshold

By default, the log level threshold of the logging category associated with a custom module is set to INFO.

This threshold can be customized by setting the property ebx.log4j.category.log.wbp.xxxxxx for the custom module xxxxxx.

Example: ebx.log4j.category.log.wbp.mycompany-module=DEBUG.

Add-on module log threshold

By default, the log level threshold of any add-on module is set to INFO.

The log level threshold can be customized by setting the property ebx.log4j.category.log.addon.xxxxxx for the add-on module ebx-addon-xxxxxx.

Example: ebx.log4j.category.log.addon.daqa=DEBUG

Activating and configuring SMTP and emails

The internal mail manager sends emails asynchronously. It is used by the workflow engine and the custom SMTP appender com.onwbp.org.apache.log4j.net.SMTPAppender.

See also
#################################################
## SMTP and emails
#################################################

## Activate emails (true or false, default is false).
## If activated, the deployer must ensure that the entry 'mail/EBX_MAIL_SESSION' is bound
## in the operational environment of the application server (except if a specific email
## configuration is used by setting the property ebx.mail.smtp.host below).
#ebx.mail.activate=false

## Polling interval is in seconds (default is 10).
#ebx.mail.polling.interval=10

## Specific properties to be set only only if you want to ignore the standard 
## deployment process of 'ebx' web application in the target operational environment	
## (see the deployment descriptor 'web.xml' of 'ebx' web application).
#ebx.mail.smtp.host = smtp.domain.com
## SMTP port default is 25.
#ebx.mail.smtp.port= 25
#ebx.mail.smtp.login=
#ebx.mail.smtp.password= 
## Activate SSL (true or false, default is false).
## If SSL is activated, a SSL factory and a SSL provider are required.
#ebx.mail.smtp.ssl.activate=true
#ebx.mail.smtp.ssl.provider=com.sun.net.ssl.internal.ssl.Provider
#ebx.mail.smtp.ssl.factory=javax.net.ssl.SSLSocketFactory

Configuring data services

##################################################################
## Data services
##################################################################
 
# Specifies the default value of the data services parameter
# 'disableRedirectionToLastBroadcast'. 
# Default is false.
#ebx.dataservices.disableRedirectionToLastBroadcast.default=false

# Specifies the default value for deletion at the end of close and
# merge operations.
# If the parameter is set in the request operation, it overrides
# this default setting. 
# If unspecified, default is false.
#ebx.dataservices.dataDeletionOnCloseOrMerge.default=false
#ebx.dataservices.historyDeletionOnCloseOrMerge.default=false

# Specifies the default maximum pagination size value for the select
# operations. This configuration is used by SOAP and REST connectors.
# Default value is 10000, maximum recommended value is 100000
#ebx.dataservices.pagination.maxSize.default= 10000

# Specifies the default pagination size value for the select
# operations. This configuration is used by the SOAP connector.
# Default value is 10.
#ebx.dataservices.pagination.pageSize.default=10

# Upon WSDL generation, specifies if the target namespace value
# corresponds to the content before 5.5.0 'ebx-services'
# or 'urn:ebx:ebx-services' in conformity with the URI syntax.
# If the parameter is set to true, there is no check of the target
# namespace as URI at the WSDL generation. 
# If unspecified, default is false.
#ebx.dataservices.wsdlTargetNamespace.disabledCheck=false

##################################################################
## REST configuration
##################################################################

# If activated, the HTTP request header 'Accept' is used to specify
# the accepted content type. If none is supported, an error is
# returned to the client with the HTTP code 406 'Not acceptable'.
# If deactivated, the header is ignored therefore the best content 
# type is used.
# Default is false.
#ebx.dataservices.rest.request.checkAccept=false

# If activated, when a REST data service authentication negotiate fails,
# EBX response includes fallback to 'Basic' authentication method by setting
# the HTTP header 'WWW-Authenticate' to 'Basic'.
# Note: This property only activate/deactivate 
# the authentication fallback.
# Default is false.
#ebx.dataservices.rest.auth.tryBasicAuthentication=false

# Authorization token timeout is seconds.
# Default value is 1800 seconds (30 minutes)
# This value is ignored if 'Token Authentication Scheme' is not activated.
#ebx.dataservices.rest.auth.token.timeout=1800

Activating and configuring JMS

##################################################################
## JMS configuration for Data Services
##################################################################

## Activates JMS (true or false, default is false).
## If activated, the deployer must ensure that the entry 'jms/EBX_JMSConnectionFactory'
## are bound in the operational environment of the application server.
## The entry 'jms/EBX_QueueIn' should also be bound to enable handling Data Services 
## request using JMS.
#ebx.jms.activate=false

## Activates JMS queue for failures (true or false, default is false).
## If activated, the deployer must ensure that the entry 'jms/EBX_QueueFailure' is bound
## in the operational environment of the application server.
#ebx.jms.activate.queueFailure=false

## Number of concurrent listener(s)
## Default is 3.
## Property is used if ebx.jms.activate is set to true.
#ebx.jms.listeners.count=3

Configuring distributed data delivery (D3)

See Configuring D3 nodes for the main configuration file properties pertaining to D3.

Configuring REST toolkit services

##################################################################
## REST configuration
##################################################################

# Defines the maximum number of bytes that will be extracted
# from the REST request body to build some DEBUG log messages.
# Default value is 8192 bytes.
# This value is ignored if DEBUG level is not activated on the restServices logger.
#ebx.restservices.log.body.content.extract.size=8192

Configuring Web access from end-user browsers

HTTP Authorization header policy

EBX® natively offers three policies to send and receive credentials using HTTP headers:

standard

It corresponds to the authentication scheme, using the HTTP Authorization header, described in the RFC 2617.

ebx

To prevent HTTP Authorization header override issues, this policy acts the same as the standard but the credentials are stored in an EBX® specific HTTP header.

both

It is the combination of the two previously described policies.

#################################################
## EBX® authorization header policy for HTTP requests
##
## Possible values are: standard, ebx, both.
##  standard:
##    the standard HTTP Authorization header holds the credentials
##  ebx:
##    an EBX® specific HTTP header holds the credentials
##  both:
##    both (standard and specific) HTTP headers hold the credentials
##
## Default value is: both.
#################################################
#ebx.http.authorization.header.policy=both

URLs computing

By default, EBX® runs in "standalone" mode, where external resources (images, JavaScript, etc.) are provided by the application server.

Also by default, URL-related parameters in the main configuration file do not have to be set.

In this case, the server name and the port are obtained from the initial request sent to EBX®.

##################################################################
## EBX® FrontServlet: default properties for computing servlet address
##
## {useLocalUrl}:
## If set to true, servlet address is a "local absolute" URL.
## (that is, a relative URL consisting of an absolute path: "/path")
## See RFC 2396, http://www.ietf.org/rfc/rfc2396.txt).
## This property is defined once for HTTP and HTTPS.
## Default value is false.
##
## {host}:
## If neither defined nor adapted, retrieves initial request host
## {port}:
## If neither defined nor adapted, retrieves initial request host
## {path}:
## Mandatory, may be empty
## {ui.path}:
## If not defined, defaults to ebx-ui/
## {http.useHttpsSettings}:
## If true, force the use of SSL security even if the incoming requests do not
##
## Resulting address will be:
## EBX®: protocol://{host}:{port}/{path}
## UI: protocol://{host}:{port}/{ui.path}
##
## Each property for HTTP (except {port}) may be inherited from HTTPS property,
## and reciprocally.
##################################################################

ebx.servlet.useLocalUrl=true

#ebx.servlet.http.host=
#ebx.servlet.http.port=
ebx.servlet.http.path=ebx/
#ebx.servlet.http.ui.path=ebx-ui/
#ebx.servlet.http.useHttpsSettings=false

#ebx.servlet.https.host=
#ebx.servlet.https.port=
ebx.servlet.https.path=ebx/
#ebx.servlet.https.ui.path=ebx-ui/

##################################################################
## External resources: default properties for computing external resources address
##
## The same rules apply as EBX® FrontServlet properties (see comments).
##
## Each property may be inherited from EBX® FrontServlet.
##################################################################

ebx.externalResources.useLocalUrl=true

#ebx.externalResources.http.host=
#ebx.externalResources.http.port=
#ebx.externalResources.http.path=
#ebx.externalResources.http.useHttpsSettings=false

#ebx.externalResources.https.host=
#ebx.externalResources.https.port=
#ebx.externalResources.https.path=

Proxy mode

Proxy mode allows using a front-end HTTP server to provide static resources (images, CSS, JavaScript, etc.). This architecture reduces the load on the application server for static HTTP requests. This configuration also allows using SSL security on the front-end server.

The web server sends requests to the application server according to a path in the URL. The servletAlias and uiServletAlias paths are specified in the main configuration file.

The web server provides all external resources. These resources are stored in a dedicated directory, accessible using the resourcesAlias path.

EBX® must also be able to access external resources from the file system. To do so, the property ebx.webapps.directory.externalResources must be specified.

To force the use of SSL security even if the incoming requests do not, ebx.servlet.http.useHttpsSettings and / or ebx.externalResources.http.useHttpsSettings properties must be set to true. Their default values are false.

The main configuration file may be configured as follows:

#################################################
## Path for external resources if they are not
## delivered within web applications
## This field is mandatory if in proxy mode.
#################################################
ebx.webapps.directory.externalResources=D:/http/resourcesFolder
 
#################################################

ebx.servlet.useLocalUrl=true

#ebx.servlet.http.host=
#ebx.servlet.http.port=
ebx.servlet.http.path=servletAlias
ebx.servlet.http.ui.path=uiServletAlias
#ebx.servlet.http.useHttpsSettings=false

#ebx.servlet.https.host=
#ebx.servlet.https.port=
ebx.servlet.https.path=servletAlias
ebx.servlet.https.ui.path=uiServletAlias

#################################################

ebx.externalResources.useLocalUrl=true

#ebx.externalResources.http.host=
#ebx.externalResources.http.port=
ebx.externalResources.http.path=resourcesAlias
#ebx.externalResources.http.useHttpsSettings=false

#ebx.externalResources.https.host=
#ebx.externalResources.https.port=
ebx.externalResources.https.path=resourcesAlias
Attention

When proxy mode is used, the URL to the ebx-dataservices module must be configured through the lineage administration panel. Note that the provided URL must end its path with /ebx-dataservices.

Reverse-proxy mode

If URLs generated by EBX®, for requests and external resources, must contain a different protocol than the one from the incoming request, a specific server name, a specific port number or a specific path prefix, properties may be configured as follows:

#################################################
#ebx.servlet.useLocalUrl=false

ebx.servlet.http.host=reverseDomain
#ebx.servlet.http.port=
ebx.servlet.http.path=ebx/
#ebx.servlet.http.ui.path=ebx-ui/
#ebx.servlet.http.useHttpsSettings=false

ebx.servlet.https.host=reverseDomain
#ebx.servlet.https.port=
ebx.servlet.https.path=ebx/
#ebx.servlet.https.ui.path=ebx-ui/

#################################################
## Web parameters (for external resources)
## if nothing is set, values are taken from servlet.
#################################################
#ebx.externalResources.useLocalUrl=false

#ebx.externalResources.http.host=
#ebx.externalResources.http.port=
#ebx.externalResources.http.path=
ebx.externalResources.http.useHttpsSettings=true

ebx.externalResources.https.host=reverseDomain
#ebx.externalResources.https.port=
ebx.externalResources.https.path=
Attention

When reverse-proxy mode is used, the URL to the ebx-dataservices module must be configured through the lineage administration panel. Note that the provided URL must end its path with /ebx-dataservices.

Configuring failover

These parameters are used to configure the failover mode and activation key, as well as heartbeat logging in DEBUG mode.

#################################################
## Mode used to qualify the way in which a server accesses the repository. 
## Possible values are: unique, failovermain, failoverstandby.
## Default value is: unique.
#################################################
#ebx.repository.ownership.mode=unique

## Activation key used in case of failover. The backup server must include this
## key in the HTTP request used to transfer exclusive ownership of the repository.
## The activation key must be an alphanumeric ASCII string longer than 8 characters.
#ebx.repository.ownership.activationkey=

## Specifies whether to hide heartbeat logging in DEBUG mode.
## Default value is true.
#ebx.repository.ownership.hideHeartBeatLogForDebug=true

Tuning the EBX® repository

Some options can be set so as to optimize memory usage.

The properties are configured as follows:

################################################################
## Technical parameters for memory and performance tuning
################################################################
# Import commit threshold allows to specify the commit threshold 
# exclusively for the archive import launched directly from Manager.
# 
# For more details about the commit threshold, 
# see the JavaDoc ProcedureContext.setCommitThreshold().
# Default value is 0.
# 
ebx.manager.import.commit.threshold=100

Miscellaneous

Activating data workflows

This parameter specifies whether data workflows are activated. This parameter is not taken into account on the fly. The server must be restarted whenever the value changes.

#################################################
## Workflow activation.
## Default is true.
#################################################
ebx.workflow.activation = true

Disabling user task legacy mode

This parameter specifies whether the creation service of a user task in legacy mode should be offered in the workflow modeling. The default value is false.

See UserTask.UserTaskMode.LEGACY_MODE for more information.

## Disables legacy work item mode (default is false)
## Specify if the creation service of user task in legacy mode must be offered
## in workflow modeling.
#ebx.manager.workflow.legacy.userTaskMode=true

Disabling hierarchy plan view

This parameter specifies whether the hierarchy plan view is hidden. The default value is true.

## Activate or deactivate Workflow hierarchy plan view
ebx.manager.workflow.hierarchyPlanView.hidden=false

Log procedure starts

This parameter specifies whether starts of the procedure execution are logged.

#################################################
## Specifies whether transaction starts are logged. Default is false.
#################################################
ebx.logs.logTransactionStart = true

Log validation starts

This parameter specifies whether starts of datasets validation are logged.

#################################################
## Specifies whether validation starts are logged. Default is false.
#################################################
ebx.logs.logValidationStart = true

Request duration threshold for logs

This parameter specifies in milliseconds the threshold of duration of Request and Query to be logged. Logs are generated if logging category ebx.log4j.category.log.request level is not higher than INFO. If the level is DEBUG, all Request and Query are logged.

#################################################
## Specifies in milliseconds the threshold of duration of Requests and Queries
## to be logged
## Default value is 1000 ms.
## If unset, the default value is used.
#################################################
#ebx.logs.request.durationThreshold=1000

Request repetition threshold for logs

This parameter specifies in milliseconds the delay between 2 logs for Request and Query that goes beyond the threshold of duration. If this value is greater than 0, and the query duration goes beyond the threshold of duration, it will be logged again repeatedly with at least this delay between each log. As log messages include duration, this is useful to track long queries duration.

#################################################
## Specifies in milliseconds the delay between 2 logs for Requests and Queries that goes
## beyond the threshold of duration. If this value is greater than 0, and the query duration
## goes beyond the threshold of duration, it will be logged again repeatedly with at least
## this delay between each log.
## Default value is 30000 ms.
## If unset, the default value is used.
#################################################
#ebx.logs.request.logAgainEvery=30000

Request optimization threshold for logs

This parameter specifies in milliseconds the threshold of the optimization phase of Request and Query to be logged. Logs are generated if logging category ebx.log4j.category.log.request level is not higher than INFO.

#################################################
## Specifies in milliseconds the threshold of optimization of Requests and Queries
## to be logged
## Default value is 1000 ms.
## If unset, the default value is used.
#################################################
#ebx.logs.request.optimizationThreshold=1000

Deployment site identification

This parameter allows specifying the email address to which technical log emails are sent.

#################################################
## Unique Site Name
## --> used by monitoring emails and by the repository
#################################################
ebx.site.name= name@domain.com

Dynamically reloading the main configuration

Some parameters can be dynamically reloaded, without restarting EBX®. The parameter thisfile.checks.intervalInSeconds indicates how frequently the main configuration file is checked.

#################################################
### Checks if this file has been updated
### If value <= 0, no more checks will be done
#################################################
thisfile.checks.intervalInSeconds=1 

In development mode, this parameter can be set to as low as one second. On production systems, where changes are expected to be less frequent, the value can be greater, or set to '0' to disable hot reloading entirely.

This property is not always supported when the module is deployed as a WAR, as it would then depend on the application server.

Declaring modules as undeployed

On application server startup, the initialization of deployed web applications / EBX® modules and the initialization of the EBX® repository are performed asynchronously. In order to properly initialize the EBX® repository, it is necessary to compile all the data models used by at least a dataset, hence EBX® will wait endlessly for referenced modules to be registered.

If a module is referenced by a data model but is not deployed (or no longer deployed), it is necessary to declare this module as undeployed to unlock the wait and continue the startup process.

Note

The kernel logging category indicates which modules are awaited.

Note

A module declared as undeployed cannot be registered into EBX® until it is removed from the property ebx.module.undeployedModules.

Note

Any data model based on an unregistered module will have an "undeployed module" compilation error.

#################################################
## Comma-separated list of EBX® modules declared
## as undeployed.
## If a module is expected by the EBX® repository but is
## not deployed, it must be declared in this property.
## Caution:
## if the "thisfile.checks.intervalInSeconds" property is deactivated,
## a restart is mandatory, otherwise it will be hot-reloaded.
#################################################
ebx.module.undeployedModules=

Module public path prefix

EBX® modules' public paths are declared in the 'module.xml' file of each module. A context prefix can be declared for all modules, without having to modify the 'module.xml' content, by specifying the property that follows.

This prefix will apply to any EBX® module, including core, add-on and specific modules.

When proxy and / or reverse-proxy mode are used, the ebx.servlet.http[s].path and ebx.servlet.http[s].ui.path properties must take into account this module public path prefix setting. Conversely, the ebx.externalResources.http[s].path property must end its path just before a potential prefix.

#################################################
ebx.servlet.useLocalUrl=true

#ebx.servlet.http.host=
#ebx.servlet.http.port=
ebx.servlet.http.path=reverse-proxy/prefix/ebx/
ebx.servlet.http.ui.path=reverse-proxy/prefix/ebx-ui/
#ebx.servlet.http.useHttpsSettings=false

#ebx.servlet.https.host=
#ebx.servlet.https.port=
ebx.servlet.https.path=reverse-proxy/prefix/ebx/
ebx.servlet.https.ui.path=reverse-proxy/prefix/ebx-ui/

#################################################
## Web parameters (for external resources)
## if nothing is set, values are taken from servlet.
#################################################
ebx.externalResources.useLocalUrl=true

#ebx.externalResources.http.host=
#ebx.externalResources.http.port=
ebx.externalResources.http.path=reverse-proxy/
#ebx.externalResources.http.useHttpsSettings=false

#ebx.externalResources.https.host=
#ebx.externalResources.https.port=
ebx.externalResources.https.path=reverse-proxy/

##################################################################
## EBX® Module context path prefix
##
## If defined, applies to all EBX® modules public paths declared in
## any module.xml file (core, add-on and specific).
##################################################################
ebx.module.publicPath.prefix=prefix/

See URLs computing for more information.

EBX® run mode

This property defines how EBX® runs. Three run modes are available: development,integration and production.

When running in development mode, the development tools are activated in EBX®, some features thus become fully accessible and more technical information is displayed.

Note

The administrator can always access this information regardless of the mode used.

The additional features accessible when running in development mode include the following (non-exhaustive list):

Documentation pane

In the case of a computed value, the Java class name is displayed. A button is displayed giving access to the path to a node.

Compilation information

Module and schema compilation information is displayed in the dataset validation report.

Java bindings

The generation of Java bindings is available if the schema of the dataset mentions at least one binding.

Web component link generator

The Web component link generator is available on datasets and dataspaces.

Data model assistant

Data model configuration and additional options, such as Services, Business Objects and Rules, Java Bindings, Toolbars and some advanced properties.

Workflow modeling

Declare specific script tasks.

Log

The logs include additional technical information intended for the developer. For example, a warning is written to logs if a drop-down list is defined on a node which is not an enumeration in a UI Bean.

Product documentation

The product documentation is always the most complete one (i.e "advanced"), including administration and development chapters.

#################################################
## Server Mode
## Value must be one of: development, integration, production
## Default is production.
#################################################
backend.mode=integration
Note

There is no difference between the integration and production modes.

Resource filtering

This property allows the filtering of certain files and directories in the resource directory contents (resource type node, with an associated facet that indicates the directory that contains usable resources).

#################################################
## list (separated by comma) of regexps excluding resource
## the regexp can be of type [pattern] or "m:[pattern]:".
## the list can be void
#################################################
ebx.resource.exclude=CVS/*

Validation report page

The validation report page can display a finite number of items for each severity. This number can be tuned with this property.

##################################################
## Defines the maximum item displayed for each severity in the validation report page.
## Default value is 100.
##################################################
ebx.validation.report.maxItemDisplayed=200

Validation report logs

This property allows to specify the number of validation messages to display in the logs when validating a dataset or a table.

###############################################
## Defines the maximum number of messages displayed in the logs.
## Default value is 100.
## When set to 0 or a negative value, the limit is not considered.
###############################################
ebx.validation.report.maxItemDisplayedInLogs=500
Documentation > Administration Guide > Installation & configuration