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.
The access path to the main configuration file can be specified in several ways. In order of descending priority:
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.
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.
By default, if nothing is specified, the main configuration file is located at WEB-INF/ebx.properties of the web application 'ebx'.
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.
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.
The license key can be retrieved from the TIBCO eDelivery site.
################################################# ## EBX® License number ## (as specified by your license agreement) ################################################# ebx.license=paste_here_your_license_key
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). ## If true, property ebx.license should also be set to a valid license. 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 none 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
The EBX® root directory contains 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
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
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
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
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
By default, the XML audit trail is activated. It can be deactivated using the following variable:
################################################################## # The XML history has been replaced by an SQL history. # This old XML history can be deactivated using the following variable. # Default is true. ################################################################## ebx.history.xmlaudittrail.activated = true
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 monitoring. |
ebx.log4j.category.log.request | The optimization strategy for every |
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
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.
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
The appender com.onwbp.org.apache.log4j.net.SMTPAppender provides an asynchronous email sender.
The configurations of module logging categories are declared according to a hierarchical pattern. Furthermore, every enabled logging request for a given category will be forwarded to all the appenders defined for that category, as well as to the appenders higher in the hierarchy. This fact means that appenders are inherited additively.
The root module logging category can be customized by setting the property ebx.log4j.category.log.wbp. For a given module, if the root module logging category configuration is the only one applicable, then a DailyRollingFileAppender is automatically added to the module's appenders list. The log file name will be derived from the module's name and from an optional specific sub-category.
#################################################################### ## Root module logging category configuration #################################################################### ebx.log4j.category.log.wbp = FATAL, Console
Every module logging category can be customized by setting the property ebx.log4j.category.log.wbp.xxxxxx, where xxxxxx corresponds to the module's name. The explicit configuration of the module logging category will disable the automatic addition of the DailyRollingFileAppender previously described. However, any other defined appenders will be inherited additively.
Since the inheritance mechanism may not be suitable for every case, the additivity can be broken by setting to false the property ebx.log4j.additivity.log.wbp.xxxxxx, where xxxxxx corresponds to the module's name.
############################################################################## ## Module logging category configuration ## ## The module's log messages will only be written to mycompany-module log file ## since additivity has been broken ############################################################################## ebx.log4j.category.log.wbp.mycompany-module = INFO, ebxFile:mycompany-module ebx.log4j.additivity.log.wbp.mycompany-module = false
The inheritance mechanism described in Module's appenders configuration is applied to the module log threshold as well. Actually, the inherited level for a given logger, is equal to the first non-null level in the hierarchy, starting from this logger and proceeding up to the root module logging category.
There is an exception to the inheritance, for custom module, since the log level threshold of their logging category, by default, is set to INFO. This threshold can be customized by setting the property ebx.log4j.category.log.wbp.xxxxxx, where xxxxxx corresponds to the custom module's name.
Example: ebx.log4j.category.log.wbp.mycompany-module=DEBUG.
Like custom module, 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 where xxxxxx corresponds to the add-on module's name.
Example: ebx.log4j.category.log.addon.daqa=DEBUG
Thus and considering EBX® logging features, the log threshold defined at the root level in the logger hierarchy may be overridden by (by order from least to most weighted):
the module logging category explicit configuration,
the module's log.threshold.xxxx or log.threshold.category.xxxx log configuration properties, where xxxx corresponds to the sub category,
the following log configuration properties: ebx.log4j.category.log.wbp.xxxxxx, where xxxxxx corresponds to the custom module's name, or ebx.log4j.category.log.addon.xxxxxx, where xxxxxx corresponds to the add-on module's name.
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.
################################################# ## 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
################################################################## ## 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 # 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, it tries authentication 'Basic Authentication Scheme' # method and set 'Basic' value in 'WWW-Authenticate' header of HTTP # response. # 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
################################################################## ## 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
See Configuring D3 nodes for the main configuration file properties pertaining to D3.
################################################################## ## 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
EBX® natively offers three policies to send and receive credentials using HTTP headers:
| It corresponds to the authentication scheme, using the HTTP Authorization header, described in the RFC 2617. |
| To prevent HTTP Authorization header override issues, this policy acts the same as the |
| 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
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. Default value is false.
##
## 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 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
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.
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=
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.
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
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 # A validation messages threshold allows specifying the maximum number of # messages to consider per constraint when performing a validation. # This threshold is considered for each constraint defined in a data model # and for each severity in each dataset validation report. # When the threshold is reached by a constraint and a severity: # - the validation of the constraint is stopped # - an error message indicating that the threshold has been reached # is added to the validation report. # When set to 0 or a negative value, the threshold is not considered. # Default value is 0. # ebx.validation.constraints.messages.threshold = 100
# Specifies whether the validation report should be kept in memory, # regardless of the loading strategy of the dataspace. # Default value is true. However, it is recommended to deactivate it # when the repository contains a large number of open dataspaces and # datasets. #ebx.validation.report.keepInMemory=false
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 false. ################################################# ebx.workflow.activation = true
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 true.
See UserTask.UserTaskMode.LEGACY_MODE for more information.
## Disables legacy work item mode(default is true) ## Specify if the creation service of user task in legacy mode must be offered ## in workflow modeling. #ebx.manager.workflow.legacy.userTaskMode=false
This parameter specifies whether starts of the procedure execution are logged.
################################################# ## Specifies whether transaction starts are logged. Default is false. ################################################# ebx.logs.logTransactionStart = true
This parameter specifies whether starts of datasets validation are logged.
################################################# ## Specifies whether validation starts are logged. Default is false. ################################################# ebx.logs.logValidationStart = true
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
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.
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.
The kernel logging category indicates which modules are awaited.
A module declared as undeployed cannot be registered into EBX® until it is removed from the property ebx.module.undeployedModules.
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=
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.
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.
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
There is no difference between the integration and production modes.
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 must be of type "m:[pattern]:[options]". ## the list can be void ################################################# ebx.resource.exclude=m:CVS/*:
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=100
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