The in-memory database mode is no longer supported as of Curie R3 version.
Brainwave's Workflow engine uses a separate database to store its data. Only SQL server, Oracle and Postgres databases are supported.
Configuration of this database is done in a dedicated tab of the technical configuration of the project and is separated into 4 different sections:
This section allows you to determine what type of database to use. Whether you wish to store all information in-memory, for development or demonstration purposes, or if you choose to configure and actual database, this is required for production environnement.
When using an in-memory setting ALL workflow data is lost each time the web portal is restarted.
To configure the connection to your database you have to include the URL, Username, Password and driver, for example:
- URL =
- Username: Activiti
- Password: activiti
- Driver: PostgreSQL
The account that connects to the database should have the
db_owner access right on the used database schema.
There is no possibility to test or ping the configured database. Connection and initialisation/update (if the databaseSchemaUpdate parameter is set to true) of the database is done during the launch of the webportal. If there is a connection error the corresponding error will be located in the log folder of your tomcat instance in the file igrcportal.log.
Finally in this section it is possible to activate the test mode for timers. This is to be used ONLY for testing purposes and allows you to accelerate time management during the workflow. This is specifically used to test timer, automatic notifications and more.
This section allows you to determine the week workdays in order to avoid notification during the weekend for example. Please refer to the page Reminders, Escalation and task expiration for more information.
Workflow DataBase renitialisation
- Test connection to the workflow database.
- Drop and create workflow database schema and in addition ticket from audit database if asked for.
The initialization wizard will ask you if you want to delete tickets from audit database(all kind of tickets).
The use of this option is only available for the following versions:
- 2017 R3 SP5
This section is used to declare the possible types that a workflow can take. This parameter is only used in during the purge process and if you have no purge configured this section can be ignored.
There is no predefined list of workflow types. You can freely add your type by using the add button. The other buttons allow you to edit delete or organise the declared types of workflows.
Two additional properties can be defined in this section.
- databaseSchema: This parameter allows you to configure the schema used. The definition of this parameter is recommended when using SQL server and Postgres. In the case of Oracle this parameter should stay empty.
- databaseSchemaUpdate: This parameter in a boolean (true or false) that allows you to Execute or not the update of the activiti schema during the launch of the webportal.
Please do not try to modify the default values of the history and jobExecutorActivate parameters. These are internal parameters and must not be changed.
Using .properties configuration files
It is possible to overwrite the workflow properties defined in the technical configuration by using a workflow.properties file. The location of this file is dependent on the configuration used. Please refer to the corresponding documentation for more information.
Here are examples of .properties files for the different databases supported:
# Value of dialect depends on Oracle versions
# Before version 9
# If version 9
# After version 9
The workflow database tables can be automatically created if they do not exist. In order to activate this feature you have to add the following property in your workflow.properties file:
It is possible to configure a JNDI connection to the workflow. Please refer to the webportal documentation for more information on configuring the JNDI connection.
It is possible to modify the stack size used for the workflow threads directly in the technical configuration by using variable
workflow.stack-size in the technical configuration.
To do so you have to modify the source of your technical configuration to add the following line between the
<Property name="workflow.stack-size" propertyvalue="50000"/>
The value is in kilobytes. If the stack size is defined as 0 then the value configured at the JVM level is used. In the example above the stack size is 50 MB.