Pre-requisites for Installation

In order to execute Stambia Runtime, your system must meet the following requirements:

Operating System:
- The Runtime can be installed on any system having a Java Virtual Machine (JVM)

Memory / CPU
- The memory and CPU capacity required will depend on the flows that are executed

Disk Space
- The system must have at least 80 MO of free disk space

Java Virtual Machine
- JVM version 1.6 or higher

Note: On a 64-bits system you should use a 64-bits JVM for better performance and compatibility.
Runtime versions prior to S17.1.17 used to require a JDK (Java Development Kit) for publishing Web Services.
For higher versions, a JVM is suffisant.

Warning: Careful, because of identified bugs, version 1.6.0.27 of the Java environment is forbidden.


Stambia Runtime Installation

Installing the Runtime on a Linux/Unix environment

Preliminary steps

  1. Install a Java Virtual Machine (JVM) 1.6 or higher
  2. Set the environment variable STAMBIA_JAVA_HOME to the folder situated located just before the “bin” folder in your JDK

Runtime Installation

  1. Unzip the archive which has been downloaded into the target folder
  2. Set the execution permissions on the SH files at the root (if needed)
  3. Set the write permissions, especially on the directories: ‘temp, ‘build’ and ‘sessions’
  4. Modify the engineParameters.xml file, as explained below.
  5. If needed create the file engineScheduler.properties, as explained below
  6. If necessary, put the ‘sh’ in the starting processes of the Linux server (this procedure depends on the system)

Some environment variables may be modified:

Note: In order to ease updates, it is recommended to copy the Stambia ‘properties’ folder into another place and to set the parameters of the STAMBIA_PROPERTIES_LOCATION variable so that it points to it. In this way, Runtime updates can be made by replacing the whole arborescence. The configuration data of the ‘properties’ folder will not be lost, since it will be elsewhere.

Installing the Runtime on a Windows environment

Please refer to Linux/Unix installation, except for points 2 and 6 that are not useful in Windows.

Service installation

The runtime can be easily installed as a Windows service if needed.
For this, navigate to the root directory of the Runtime and use the following commands:

  1. use the installEngineAsService.bat -i [<serviceName>] command to install the service
  2. use the installEngineAsService.bat -r [<serviceName>] command to remove the service

The <serviceName> parameter can be useful to install multiple Runtimes on the same machine.
If not set the service will be named ‹Stambia Runtime›.

The file «stambiaEngine.conf» which is in the folder external\stambiaService\conf can be used to configure some of the service’s properties. By default, it is not useful to modify this file.

Warning: Any modification of Stambia Runtime files or parameters (in “properties” or in the ‘.bat’ files) requires the removal and reinstallation of the Windows service, so that these modifications may be taken into account.

Tip: The specified user used to launch the Runtime (Windows service) should be changed to a user with network abilities, usually a domain user.

Upgrading in a few steps

After downloading the desired Runtime ZIP archive, proceed through the steps listed below.

We assume your current Runtime is installed into a directory named «stambiaRuntime».

  1. Install the new Runtime in a new directory, something like "stambiaRuntime_new"
  2. On UNIX/Linux systems make sure that all the stambiaRuntime_new/*.sh files are executable
  3. Stop the old Runtime and make a backup
  4. Copy the content of the following directories from the old Runtime to the new Runtime:
    1. stambiaRuntime\build\deliveries
    2. stambiaRuntime\build\packages
    3. stambiaRuntime\lib\addons (if you have additional libraries added to the Runtime)
    4. stambiaRuntime\properties (if you have set some properties)
    5. stambiaRuntime\scheduler (if you are using the Runtime’s scheduler)
    6. stambiaRuntime\sessions (if you use the Runtime’s internal log database)
    7. Optionally: stambiaRuntime\temp (if your Processes store specific files intentionnally in this directory)
  5. Install the required Jdbc jar files into stambiaRuntime_new/lib/jdbc (do not overwrite the new Runtime’s Jdbc jar files!)
  6. Rename the old Runtime’s directory to something like "stambiaRuntime_old"
  7. Rename the new Runtime’s directory to "stambiaRuntime"
  8. Apply the read / right permissions to the new folder as it was set on the old one
  9. If the Runtime is installed as a Windows service, remove and re-install the service
  10. Start the Runtime

Runtime Configuration

Most of the Runtime’s configuration is done in the properties/engineParameters.xml file

This file allows to manage:

Defining the started services

The services exposed by the Runtime, such as the scheduler, the SOAP component, or the internal Java database can be turned off if needed.
By default, they are all launched at the Runtime’s startup.
To specify which services should be started:

  1. Open the engineParameters.xml file
  2. Update the parameters accordingly to your needs.
<parameters>
	<...>
	<engineParameters>
		<...>
		<parameter name="launchSchedulerEngine" value="true"/>
		<parameter name="launchExecutionEngine" value="true"/>
		<parameter name="launchReportEngine" value="true"/>
		<parameter name="startInternalDb" value="true"/>
		<parameter name="startSoapServer" value="true"/>
		<...>
	</engineParameters>
	<...>
</parameters>

The following parameters are available:

Parameter Default value Description
launchSchedulerEngine true start scheduler
launchExecutionEngine true start execution engine
launchReportEngine true start reporting ability
startInternalDb true start internal H2 database
startSoapServer true start soap service
enableHttpClientConnections true Defines if clients can connect and perform operations on the Runtime through HTTP.

Defining the services ports

The services exposed by the Runtime are running on defined port, that can indeed be modified easily.

  1. Open the engineParameters.xml file
  2. Update the following parameters accordingly to your needs.
<parameters>
	<...>
	<engineParameters>
		<...>
		<parameter name="rmiPort" value="42000"/>
		<!--<parameter name="rmiCallbackPort" value="42000"/>-->
		<parameter name="internalDbTcpPort" value="42100"/>
		<parameter name="internalDbWebPort" value="42101"/>
		<parameter name="soapServerPort" value="42200"/>
		<...>
	</engineParameters>
	<...>
</parameters>

Defining the log database

The Runtime stores the information about sessions' execution in a log database.
This database is by default an internal H2 database, that is shipped with the Runtime and started with it.

This offers a ready-to-go environment that can be used immediately.
We however recommend changing it to a more robust database such as Oracle, Microsoft SQL Server (MSSQL), etc for production use.
You will need to provide to Stambia Runtime a user having read and write permissions on the chosen database/schema.

Here is how to change the log database of the Runtime:

1) Open the engineParameters.xml file
The configuration is performed in this file, which contains samples for the most known databases.

2) Modify the log database parameters as explained below.
This consists of defining the JDBC URL, user, password, schema, ... where the log database will be located.

3) Restart the runtime
All necessary tables will be created automatically the first time the log database is initialized

Log database parameters

<parameters>
	<...>
	<engineParameters>
		<...>
		<parameter name="userLogDefaultName" value="logDatabase"/>
		<parameter name="defaultSessionLogLevel" value="400"/>
		<...>
	</engineParameters>
	<...>
	<logs>
		<...>
		<log userLogName="logDatabase" autoUpdate="true" userLogClass="com.indy.engine.userLog.RdbmsUserLog">
			<parameter name="userLogRdbmsDriver" value="org.h2.Driver"/>
			<parameter name="userLogRdbmsUrl" value="jdbc:h2:tcp://localhost:42100/sessions/internalDb/sessionLogs"/>
			<parameter name="userLogRdbmsUser" value="sa"/>
			<parameter name="userLogRdbmsPassword" value=""/>
			<!--<parameter name="userLogRdbmsEncryptedPassword" value=""/>-->
			<parameter name="userLogRdbmsVarcharType" value="varchar"/>
			<parameter name="userLogRdbmsVarcharMaxSize" value="1000"/>
			<parameter name="userLogRdbmsNumericType" value="numeric"/>
			<parameter name="userLogRdbmsClobType" value="clob"/>
			<parameter name="userLogRdbmsBlobType" value="blob"/>
			<parameter name="userLogRdbmsSchemaName" value="logs"/>
			<parameter name="userLogRdbmsUseSchemaNameForIndexCreation" value="true"/>
			<parameter name="userLogRdbmsDeleteSyntaxe" value="Delete from"/>
			<!--<parameter name="userLogRdbmsTablePrefix" value="STB_LOG_"/>-->
			<!-- bestCompression / bestSpeed / default-->
			<parameter name="userLogRdbmsCompressedLevel" value="bestCompression"/>
			<!-- text / binary / compressed-->
			<parameter name="userLogRdbmsDeliveryFormat" value="compressed"/>
			<parameter name="userLogRdbmsPropertyMaxVarcharSize" value="1000"/>
			<!-- -1 : infinite -->
			<parameter name="userLogRdbmsPropertyMaxClobSize" value="10000"/>
			<!-- binary / compressed-->
			<parameter name="userLogRdbmsPropertyBinaryFormat" value="compressed"/>
			<parameter name="userLogRdbmsTimestampQuery" value="select now()"/>
			<parameter name="userLogRdbmsInactivityDetectionPeriod" value="90000"/>
			<parameter name="userLogRdbmsActivityRefreshInterval" value="60000"/>
			<parameter name="userLogRdbmsDeletionWithNotExists" value="true"/>
			<!--<parameter name="userLogRdbmsIndexCreationOption" value=""/>-->
			<!--<parameter name="userLogRdbmsTableCreationOption" value=""/>-->
		</log>
		<...>
	</logs>
	<...>
</parameters>

User Log Default Name

The «userLogDefaultName» is used to define which configured log database should be used.
This corresponds to the «userLogName» attribute which can be found in the log database configuration nodes(<log></log> nodes)

Default Session Log Level

The «defaultSessionLogLevel» defines what level of information is logged inside log database for each session executed by the Runtime.
The higher the value is the higher information are logged.
Possible values are the following: -1, 0, 100, 200, 300, 400

Note that is applies only for sessions on which the log level is not defined manually at execution.
Refer to the runtime parameters reference part of this documentation for details information about each value.

Log part

This is the part where you will configure the JDBC URL, user, password, schema, ... to connect to the log database.
All necessary tables will be created automatically the first time the log database is initialized.
The initialization is performed the first time the Runtime is started on this log database.

Under <logs></logs> node, you can find commented examples of configuration for several databases systems.
You can use these examples to configure your log database accordingly to the target database system which will be used.

The Runtime will use as log database the <log></log> node which «userLogName» attribute value corresponds to the «userLogDefaultName» parameter value.

If you uncomment the examples nodes to, you’ll therefore have to be careful to keep only one <log></log> node which «userLogName» attribute value corresponds to the «userLogDefaultName» parameter value.

Example

The example below is for an Oracle database:

<parameters>
	<...>
	<engineParameters>
		<...>
		<parameter name="userLogDefaultName" value="logDatabase"/>
		<parameter name="defaultSessionLogLevel" value="400"/>
		<...>
	</engineParameters>
	<...>
	<logs>
		<...>
		<log userLogName="logDatabase" autoUpdate="true" userLogClass="com.indy.engine.userLog.RdbmsUserLog">
			<parameter name="userLogRdbmsDriver" value="oracle.jdbc.driver.OracleDriver"/>
			<parameter name="userLogRdbmsUrl" value="jdbc:oracle:thin:@[host]:[port]:[sid]"/>
			<parameter name="userLogRdbmsUser" value="[USER]"/>
			<parameter name="userLogRdbmsPassword" value="[PASSWORD]"/>
			<parameter name="userLogRdbmsSchemaName" value="[SCHEMA_NAME]"/>
			<parameter name="userLogRdbmsVarcharType" value="varchar2"/>
			<parameter name="userLogRdbmsVarcharMaxSize" value="4000"/>
			<parameter name="userLogRdbmsClobType" value="clob"/>
			<parameter name="userLogRdbmsBlobType" value="blob"/>
			<parameter name="userLogRdbmsNumericType" value="number"/>
			<parameter name="userLogRdbmsDeleteSyntaxe" value="Delete from"/>
			<parameter name="userLogRdbmsDeliveryFormat" value="text"/>
			<parameter name="userLogRdbmsPropertyMaxVarcharSize" value="1000"/>
			<parameter name="userLogRdbmsPropertyMaxClobSize" value="10000"/>
			<parameter name="userLogRdbmsPropertyBinaryFormat" value="compressed"/>
		</log>
		<...>
	</logs>
	<...>
</parameters>

The minimum to modify are the following parameters:

Note: Refer to the ‹Runtime parameter reference› part of this documentation for the list of all available parameters with explanations.

Defining Repositories

Repositories are the locations where the Runtime will look for the delivery files at execution.

There are two types of repositories:

To add, configure, and specify repositories:

  1. Open the engineParameters.xml file
  2. Configure the repositories

Example of repositories configuration:

<parameters>
	<...>
	<repositories>
		<fileRepository name="default" default="true" folder="build/deliveries/"/> 
		<fileRepository name="webService" default="true" folder="build/deliveries/wsdl/" webService="true" synchPollingInterval="10000" scanMode="polling"/>
		<httpRepository name="PROD" default="false" url="http://localhost:8080/analytics" user="stambia" uncryptedPassword="stambia" unreachableTolerancePeriod="30000"/>
	</repositories>
	<...>
</parameters>

Important: It is possible to specify multiple repositories on a same Runtime, but note that you can only set one as default for standard deliveries, and one as default for web service deliveries.

Tip: You can specify the repository name at execution time:
startdelivery.bat -name myDeliv -repository demo

File Repositories

Parameter Default value Description
name The name of the repository. This is the repository name specified when starting a delivery on a specific repository.
default false If set to true, the Runtime will by default try to get its deliveries from this repository.
folder The folder containing the deliveries.
webService false If set to true, the repository will be used for deliveries exposed as web service.
scanMode polling Define the scan method used by the Runtime for synchronizing the content of the repository. This offers to automatically expose the web service deliveries that are manually added in the repository while the Runtime is running.
synchPollingInterval 10000 The time interval in milliseconds to scan the repository for new deliveries. This applies only in polling scanMode.

scan Modes

  1. polling: The Runtime will check periodically if new deliveries are available in the repository. This is useful only for deliveries exposed as web service. To define the polling interval, please see the synchPollingInterval parameter.
  2. disable: The Runtime will not check for new deliveries in the repository. This means that the runtime must be restarted to take into account the web service deliveries that are manually added or modified in the repository. This do not apply for deliveries published from a Designer, that are automatically exposed.

Examples:

<parameters>
	<...>
	<repositories>
		<fileRepository name="defaultRepository" default="true" folder="build/deliveries"/> 
		<fileRepository name="wsdlRepository" default="true" folder="build/deliveries/wsdl/" webService="true" synchPollingInterval="10000" scanmode="polling">
		<...>
	</repositories>
	<...>
</parameters>

Http Repositories

Parameter Default value Description
name The name of the repository (must match the name of the Deployment Manager in Stambia Analytics)
default If set to true, the Runtime will by default try to get its deliveries from this repository.
url URL of Stambia Analytics
user Login/Username of Stambia Analytics to use.
password Encrypted password of the user.
uncryptedPassword Uncrypted password of the user.
unreachableTolerancePeriod Timeout in milliseconds to wait for the server when it’s unreachable.
webService false If set to true, the repository will be used for deliveries exposed as web service.
scanMode polling Define the scan method used by the Runtime for synchronizing the content of the repository. This offers to automatically expose the web service deliveries that are manually added in the repository while the Runtime is running.
synchPollingInterval 10000 The time interval in milliseconds to scan the repository for new deliveries. This applies only in polling scanMode.

scan Modes

  1. polling: The Runtime will check periodically if new deliveries are available in the repository. This is useful only for deliveries exposed as web service. To define the polling interval, please see the synchPollingInterval parameter.
  2. disable: The Runtime will not check for new deliveries in the repository. This means that the runtime must be restarted to take into account the web service deliveries that are manually added or modified in the repository. This do not apply for deliveries published from a Designer, that are automatically exposed.

Note: Passwords are encrypted using the encrypt <password> command on the Runtime engine console (engine command line tool).

Example:

<parameters>
	<...>
	<repositories>
		<httpRepository name="PROD" default="false" url="http://localhost:8080/analytics" user="stambia" uncryptedPassword="stambia" unreachableTolerancePeriod="30000"/>
		<...>
	</repositories>
	<...>
</parameters>

Defining Java Additional Options

Java options are generally added to the Java command launching the Runtime with the -DmyOption01=value01 argument.
This part allows to set them directly in the Runtime’s Configuration file through the javaConfiguration node.
The options specified inside will be loaded just after the Runtime’s start.

  1. Open the engineParameters.xml file
  2. Set the additional options you want to add at Runtime’s startup.

The syntax is the following:

<parameters>
	<...>
	<javaConfiguration>
		<property name="myOption01" value="value01"/>
		<property name="myOption02" value="value02"/>
		<...>
	</javaConfiguration>
	<...>
</parameters>

Securing the Runtime

A Runtime installed with the default configuration can be accessed by anyone.

Any user can connect and make operations on it, such as listing or executing sessions.

This behavior can be configured easily in the Runtime Properties (engineParmeters.xml) , that offer the possibility to secure the connection through

A basic security configuration looks like this:

For TLS secured RMI:

<parameters>
	<...>
	<engineParameters>
		<...>
		<parameter name="rmiEnableTls" value="true"/>
		<...>
	</engineParameters>
	<...>
</parameters>

For user / hostname restriction:

<parameters>
	<...> 
	<security>
		<user anonymous="true" roles="Connect View"/>
		<user name="admin"  uncryptedPassword="admin" roles="Admin"/>
		<user name="developer"  uncryptedPassword="developer" roles="Connect View Execute"/>
		<user name="consult"  uncryptedPassword="consult" roles="Connect View"/>
		<allow address="192.168.0.42"/>
	</security>
	<...>
</parameters>

Warning: The security node must contain at least one user, which can be a normal or anonymous user.

For HTTPS Web Services:

<parameters>
	<...>
	<engineParameters>
		<...>
		<parameter name="webServiceSecureProtocol" value="TLSv1.1"/>
		<parameter name="webServiceKeyStoreFile" value="D:/keystore/mykeystore.jks"/>
		<parameter name="webServiceKeyStoreType" value="JKS"/> 
		<parameter name="webServiceKeyStorePassword" value="password"/> 
		<parameter name="webServiceKeyPassword" value="password"/>
		<...>
	</engineParameters>
	<...>
</parameters>

TLS enabled RMI

Set the following parameter to true if you the RMI connection to be secured through TLS.
The RMI connection is used for instance to connect to the Runtime from the Designer or Analytics.

<parameters>
	<...>
	<engineParameters>
		<...>
		<parameter name="rmiEnableTls" value="true"/>
		<...>
	</engineParameters>
	<...>
</parameters>

User / Password Restriction and Roles

You can define the users that can connect to the Runtime and their permissions.

The syntax is the following:

<parameters>
	<...> 
	<security>
		<...>
		<user anonymous="true" roles="Connect View"/>
		<user name="user01"  password="encrypted password" uncryptedPassword="plain text password" roles="Connect View Execute"/>
		<user name="user02"  password="encrypted password" uncryptedPassword="plain text password" roles="Connect View Execute"/>
		<...>
	</security>
	<...>
</parameters>

The following parameters are available:

Parameter Description
name User name, that will be used as the login credential
password Encrypted password of the user
uncryptedPassword Uncrypted (plain text) password of the user
roles Space separated list of roles for the user

The following roles are available:

Role Description
Connect The user can connect to the Runtime (required)
View The user can list and view all the sessions of the Runtime
Execute The user can execute deliveries on the Runtime
Admin The user has the full permissions on the Runtime. This is required for operations such as purging the sessions or scheduling deliveries.

About the Anonymous User:

An anonymous user can be set, to specify the permissions of the users that connect to the Runtime without specifying credentials.

<user anonymous="true" roles="Connect View"/>

When the anonymous user is set, it is therefore not mandatory to specify credentials when connecting.
The connected user will have the permissions of the anonymous user.

When the anonymous user is not set, specifying credentials when connecting is mandatory.
Anonymous connections will then be rejected.

Note that only one anonymous user can be set at a time.

Notes:
* Passwords are encrypted using the encrypt <password> command on the Runtime engine console (engine command line tool).
* Only one of the password or uncryptedPassword should be set
* Multiple roles can be assigned to one user, separated with space characters

Warning: The security node must contain at least one user, which can be a normal or anonymous user.

Hostname / IP restriction

You can define the hostnames / IP addresses that are allowed to connect to the runtime.

The syntax is the following:

<parameters>
	<...> 
	<security>
		<...>
		<allow address="Hostname or IP Address"/>
		<allow address="Another Hostname or another IP Address"/>
		<...>
	</security>
	<...>
</parameters>

Warning: The security node must also contain at least one user, which can be a normal or anonymous user.

Enabling HTTPS on Web Services Endpoints

Deliveries published as Web Service can be accessed through the different Web Services Endpoints exposed by the Runtime.
These endpoints can be accessed by default through HTTP using the URLs indicated on the console at Runtime’s startup.
This default behavior can be modified easily in the Runtime configuration file to enable the use of HTTPS, as explained below.

The following parameters are available to enable HTTPS:

<parameters>
	<...>
	<engineParameters>
		<...>
		<parameter name="webServiceSecureProtocol" value="TLSv1.1"/>
		<parameter name="webServiceKeyStoreFile" value="D:/keystore/mykeystore.jks"/>
		<parameter name="webServiceKeyStoreType" value="JKS"/> 
		<parameter name="webServiceKeyStorePassword" value="password"/> 
		<parameter name="webServiceKeyPassword" value="password"/>
		<...>
	</engineParameters>
	<...>
</parameters>

And here is their description:

Role Description
webServiceSecureProtocol Protocol to be used for securing the endpoints, like TLSv1.1 for instance.
webServiceKeyStoreFile Path to the Java keystore containing the certificate to use for securing the endpoints.
webServiceKeyStoreType Java keystore type, such as ‹JKS›.
webServiceKeyStorePassword Password of the keystore file.
webServiceKeyPassword Password of the certificate key.

Configuring the scheduler

The scheduler shipped with the Runtime stores all the schedules into a database.
This database is by default an internal H2 database, that is shipped with the Runtime and started with it.

If you want to change this and store the schedules into another database:

When the property org.quartz.jobStore.dataSource is set to internal (which is the default), the scheduler stores its schedules in the internal database.
Therefore, change it to another name when you want to use another database.

Finally, define the datasource parameters to match the location where the tables are created.

org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.StdJDBCDelegate 
org.quartz.jobStore.useProperties=false
#org.quartz.jobStore.dataSource=internal
org.quartz.jobStore.dataSource=database01
org.quartz.jobStore.tablePrefix=STB_
org.quartz.jobStore.isClustered=false
#============================================================================
# Configure Datasources  
#============================================================================
org.quartz.dataSource.database01.driver =org.h2.Driver
org.quartz.dataSource.database01.URL = jdbc:h2:tcp://localhost:42100/scheduler/internalDb;SCHEMA=SCHEDULER
org.quartz.dataSource.database01.user = sa
org.quartz.dataSource.database01.password = 
org.quartz.dataSource.database01.maxConnections = 5
org.quartz.dataSource.database01.validationQuery=

Starting a Runtime with a configuration file

A Runtime may be started with a specific configuration file.
To specify this file, use the environment variable STAMBIA_CONF_FILE_LOCATION

By default, the value configured in the file «initvariable.sh (.bat)» is this:

STAMBIA_CONF_FILE_LOCATION=$STAMBIA_PROPERTIES_LOCATION/engineParameters.xml

Automatic log purge

You can plan an automatic purge of the Runtime session logs.
This can be done in Stambia and Stambia Analytics in the Purge tab of the Runtime Editor or alternatively on command line as explained below.

To proceed:

  1. Launch startCommand (.bat or .sh).
  2. Then use the purge scheduling command, the description of which follows:
schedule purge keep <number> <minute|hour|day|session>  cron <cronExpression> [sessionname <name,name2,...>] [status <done,error,killed>] [on host <hostname>] [port <hostport>]

It is possible to purge while keeping:

For example, to keep 90 days and schedule the purge every evening at 23h:

schedule purge keep 90 day cron "0 0 23 * * ?"

Runtime parameters reference

The configuration of the Runtime is done in the engineParameters.xml file that can be found in the properties folder of the Runtime’s installation.
This file allows to manage:

Take care, it is highly recommended to check first with Stambia the modifications you wish to bring to the XML files containing the Runtime parameters.
You can moreover find configuration samples in the properties/samples folder.

Note: Passwords are encrypted using the encrypt <password> command on the Runtime engine console (engine command line tool).

Tip: All the parameters are centralized in this file but can be easily externalized if required.

Engine Parameters

Common Parameters

Parameter Default value Comment
userLogDefaultName internalDB Name of the log where session logs are written. This is the name defined in the userLogName attribute on the log database configuration.
debugLevel 0 Debug level in the Runtime
temporaryFolder temp Temporary folder for the Runtime. Used by developers as a workspace, and by the Runtime to store some temporary files.
deliveryExtension deliv Extension of the deliveries. Do not change this value.
defaultFetchSize 1000 Default fetch value for reading data in databases. This value may be overloaded by the developers or when putting into production directly in the deliveries.
defaultBatchSize 1000 Default batch update value for writing data into databases. This value may be overloaded by the developers or when putting into production directly in the deliveries.
defaultJdbcConnectionTimeout 100 Default timeout value for connections to databases, in seconds
defaultJdbcQueryTimeout 10 Default timeout value for queries to databases, in seconds
defaultSessionReportNumber 10 Default number of sessions for the reporting part of the Runtime. Usually overloaded by the graphical interface.
memoryLogScanDelay 10000 Scan delay of the logs that have been brought back to memory so as to be purged, in milliseconds.
memoryLogCacheDelay 300000 Time during which logs stay in memory, in milliseconds.
memoryLogCacheDelay 300000 Time during which logs stay in memory, in milliseconds.
logPurgeBatchSize Batch size used when performing purge operations on Runtime’s log database. When this parameter is not specified the queries performed by purge operations are processing all the rows at once. Specifying a batch size can help to avoid overloading the database when performing purge operations. The number of rows removed is logged inside Runtime log files, and note that the number of sessions processed per batch may slightly vary between each batch, in situations where multiple sessions have the same starting date.
defaultSessionLogLevel 400 This defines what level of information is logged inside log database for each session executed by the Runtime. The higher the value is the higher information are logged. Possible values are the following: -1, 0, 100, 200, 300, 400. Note that is applies only for sessions on which the log level is not defined manually at execution. See Logs parameter part of this documentation for further information.

Services Parameters

Parameter Default value Comment
launchSchedulerEngine true Condition for starting the scheduler that is integrated to the Runtime.
launchExecutionEngine true Condition for starting the execution part of the Runtime. This must stay true.
launchReportEngine true Condition for starting the reporting part of the Runtime. This must stay true.
startInternalDb true Condition for starting the internal database used for the session logs and the scheduler
startSoapServer true Condition for starting the SOAP services that enable Stambia to expose web services
rmiHost The RMI host is automatically calculated. If specified, this parameter skips this step. Useful when there are multiple domains, or address translations that generate different IP addresses for the same host. The host that is indicated (IP or name) must be reachable by the client
soapHost See above.

Services Ports Parameters

Parameter Default value Comment
rmiPort 42000 IP port of the Java RMI service used for communication between the Runtime and graphical interfaces
rmiCallbackPort In the RMI protocole, the client can also receive queries from the server. In this case, it uses the rmiCallbackPort. The default value is that of the rmiPort.
internalDbTcpPort 42100 IP port of the internal database
internalDbWebPort 42101 IP port of the Web interface of the internal database
soapServerPort 42200 IP port used by the SOAP server

Services Security

Parameter Default value Comment
rmiEnableTls false Defines if the RMI service exposed for other tools to connect to the Runtime should be secured through TLS.
passwordCipheringKeyName Name of the key that should be used for password encryption / decryption. It must match a key defined under a keystore in the Runtime configuration. Example of keystores are documented further in the default configuration file.

Services Miscellaneous Parameters

Parameter Default value Comment
enableConnectionPoolForJdbcDatabases false If this parameter is set to true, connections created and used by the Runtime for exchanges with JDBC databases will be performed through a pool of connection. This can help to reduce the amount of connections created to these databases, as they will be re-used instead of re-created each time.
enableConnectionPoolForLogDatabase false If this parameter is set to true, connections created and used by the Runtime for exchanges with its Log Database will be performed through a pool of connection. This can help to reduce the amount of connections created to the Log Database, as they will be re-used instead of re-created each time.

Standard Output Parameters

Parameter Default value Comment
stackTraceOnStdOutput true To write the stacktrace on the standard output, if there is an error.
statisticsOnStdOutput true To write the statistics on the standard output, at the end of a session.
sumVariables List of the variables used to calculate the session’s statistics

Web Services Parameters

Parameter Default value Comment
soapServerUser Optional user for queries to the SOAP server
soapServerPassword Optional password for queries to the SOAP server
soapServerUncryptedPassword Optional unencrypted password for queries to the SOAP server
soapServerThreadPoolSize Maximum number of concurrent threads on the SOAP server. If number exceeds this size, sessions are put on hold
httpRestServerUser Optional user for queries to the REST server
httpRestServerPassword Optional password for queries to the REST server
httpRestServerUncryptedPassword Optional unencrypted password for queries to the REST server
webServiceInputMessageKeep if_error Specifies if the input files created during web services invocations should be kept or not. The possible values are: yes, no, if_error
webServiceOutputMessageKeep if_error Specifies if the output files created during web services invocations should be kept or not. The possible values are: yes, no, if_error
webServiceFaultMessageKeep if_error Specifies if the fault files created during web services invocations should be kept or not. The possible values are: yes, no, if_error

Logs parameters

In this part, the default values will be those used for the logs in H2 (the internal base). For other logs examples, please refer to the example files that are provided.

Log header

Parameter Example value Comment
userLogName internalDB Name of the log, that must then be used in the userLogDefaultName engine Parameter
autoUpdate true Condition for the automatic update of the log structures
userLogClass com.indy.engine.userLog.RdbmsUserLog Java class that is used (do not change)

Internal parameters

Parameter Example value Comment
userLogRdbmsDriver org.h2.Driver Java driver which will be used (this file must be in the Runtime folder lib/jdbc)
userLogRdbmsUrl jdbc:h2:tcp://localhost:42100/sessions/internalDb/sessionLogs Connection url
userLogRdbmsUser sa Connection user
userLogRdbmsPassword Connection password (non encrypted, plain text)
userLogRdbmsEncryptedPassword Connection password (encrypted)
userLogRdbmsVarcharType varchar Type used when the data is a character string
userLogRdbmsVarcharMaxSize 1000 Maximum length of the character strings with the type defined above.
userLogRdbmsNumericType numeric Type used when the data is numerical
userLogRdbmsClobType clob Type used when the data is text (clob, limitless text)
userLogRdbmsBlobType blob Type used when the data is binary (blob)
userLogRdbmsSchemaName logs Database scheme used to create the tables
userLogRdbmsUseSchemaNameForIndexCreation true Condition for adding a scheme to prefix indexes during creation
userLogRdbmsDeleteSyntaxe Delete from Syntax of the delete commands. The name of the table will be added behind.
userLogRdbmsCompressedLevel bestCompression Type of compression used (if activated). Possible values: bestCompression, bestSpeed or default
userLogRdbmsDeliveryFormat compressed Gives the delivery’s storage format in the database. Possible values: text,binary or compressed
userLogRdbmsPropertyMaxVarcharSize 1000 Size of the character strings beyond which the data will be stored as CLOB
userLogRdbmsPropertyMaxClobSize 10000 Size of the CLOB beyond which the data will be stored as BLOB. -1 means «infinite»
userLogRdbmsPropertyBinaryFormat compressed Specifies the compression of the BLOB. Possible values: binary or compressed
userLogRdbmsTimestampQuery select now() SQL order to retrieve the current time stamp.
userLogRdbmsInactivityDetectionPeriod 90000
userLogRdbmsActivityRefreshInterval 60000
userLogRdbmsIndexCreationOption Character string that is added after the SQL order which creates indexes. Useful to specify physical storage parameters such as «tablespaces» or underlying physical types. For example, with MysqlENGINE = InnoDB
userLogRdbmsTableCreationOption Character string that is added after the SQL order which creates tables. Useful to specify physical storage parameters such as «tablespaces» or underlying physical types. For example, with MysqlENGINE = InnoDB

Note: Passwords are encrypted using the encrypt <password> command on the Runtime engine console (engine command line tool).

Session Log Level

The session log level defines the level of information which is logged inside log database for each session executed by the Runtime.

The higher the value is the higher information are logged.
You can find below the different log level values and what level of details can be consulted, depending on the session status.

Log level Running session Successful session Session with errors
-1 Not logged Not logged Not logged
0 Full details Not logged Full details
100 Full details Session Header and Statistics Full details
200 Full details logLevel 100 + Process Information and Statistics Full details
300 Full details logLevel 200 + Actions Information and Statistics Full details
400 Full details Full details Full details