---
title: 4biz extra settings
slug: support-en/4biz-extra-settings
description: Learn about the new parameters in Helium 1.2.24 for the Helium software. Understand the behavior, type, default values, and valid types of AUTHENTICATION_PROTOCOL and AUTHENTICATION_CREATE_USER parameters. Discover additional parameters added in Helium 1.
createdAt: 2021-11-16T16:23:07.000Z
---

From version Helium 1.2.24, new parameters have been added:

- Parameter: AUTHENTICATION\_PROTOCOL
- Ojective: Define the authentication protocol
- Behavior: Defines whether the system will authenticate with internal parameters or with another authentication protocol.
- Type: varchar
- Default valor: internal
- Valid types:
  1. OAUTH2: For keycloack authentication - this information overrides any security policy entered in the Security Policy record;
  2. Internal: For system-defined authentication;
- Parameter: AUTHENTICATION\_CREATE\_USER
- Ojective: Define whether the user will be created in the application after the login
- Behavior: Records the user who logged into the application;
- Type: boolean (true or false)
- Default value: FALSE
- Possible values:

From version Helium 1.2.23, new parameters have been added:

- Parameter: MAXIMUM\_LOGIN\_FIELD\_SIZE
- Ojective: Set the maximum acceptable size in the login field
- Behavior: It just prevents login by issuing a generic message, invalid login or password.
- Type: numeric
- Default value: 25
- Parameter: ALLOW\_SYMBOLS\_AT\_LOGIN
- Ojective: Define whether the system accepts symbols in the login field
- Behavior: It just prevents login by issuing a generic message, invalid login or password.
- Type: boolean (true or false)
- Default value: FALSE

From version Helium 1.2.19 onwards, the CITSMART.CFG file is now called “application.ini” and must follow the guidelines below:

1. The update of the table will only occur when the parameter LOAD\_FACTSERVICEREQUESTRULES of APPLICATION.INI has the value TRUE. In the absence of this configuration in the file, the system assumes the value FALSE for the parameter. That is, the default is NOT to update the table;
2. If there is a schedule related to a ticket escalation rule and the parameter LOAD\_FACTSERVICEREQUESTRULES has the value FALSE, the system issues the alert in the LOG: The system cannot start processing escalation rules because the LOAD\_FACTSERVICEREQUESTRULES property (configuration file) is equal to FALSE;
3. NEW PARAMETERS FOR APPLICATION.INI: To activate updateParameters, option to synchronize parameter values in memory, in a clustered environment; we must add the following configuration in the application.ini file: UPDATEPARAMETERS\_PORT =  example: UPDATEPARAMETERS\_PORT = 2002.

Create a file called application.ini in /opt/wildfly/standalone/configuration/ with the information bellow:

```shell
RECORDS_LIMIT_TO_GENERATE_REPORT_IN_THE_BACKGROUND = 500	
START_MONITORA_INCIDENTES=FALSE
JDBC_ALIAS_REPORTS=
JDBC_ALIAS_BPM=
JDBC_ALIAS_BPM_EVENTOS=
START_VERIFICA_EVENTOS=FALSE
QUANTIDADE_BACKUPLOGDADOS=1000
START_MODE_RULES=FALSE
START_MODE_RULES=FALSE
LOAD_FACTSERVICEREQUESTRULES=TRUE
INICIAR_PROCESSAMENTOS_BATCH=TRUE
```

Give permission for the wildfly user to this file:

```shell
[root@server /tmp]# chown wildfly.wildfly /opt/wildfly/standalone/configuration/application.ini
```

:::hint{type="info"}
In the appication.ini file, the default value is TRUE (even if not set), that is, if this option doesn't exist in the file, the system will use the TRUE value for this property. Defined as TRUE, it enables the Thread that updates the service request fact table at the system initialization. Defined as FALSE, the update will occur only after adding or changing the service request.
:::

For version Helium 2.1.14 the system no longer uses the parameter 449 to define the session time, now it is controlled by the expiration time of the JWT token. 

This expiration time can be configured on the file application.ini, property TOKEN\_MAX\_AGE defined in miliseconds. If it is not defined, the default value is : 1 day. There is a resource to keep the user session active for an indetermined amount of time, as long as the user keeps using the system throughout the day. In other words, the session will remain active until 24hours have passed since their last interaction. This resource has been removed on version 3.0.0.

## Quartz Configuration

4biz Batch Processing uses Quartz for scheduling and processing system routines. Create a
file named "quartz.properties" in the path
`/opt/wildfly/standalone/configuration/`. The settings are different for the common standalone,
for standalone configured in cluster mode. In either case, configure wildfly as follows.

### Standalone configuration without cluster

If you are running wildfly in standalone mode but without cluster configuration, enter the following information in the quarts.properties file:

```shell
#===============================================================
#Configure Main Scheduler Properties
#===============================================================
org.quartz.scheduler.instanceName = 4bizMonitor
org.quartz.scheduler.instanceId = AUTO
#===============================================================
#Configure ThreadPool
#===============================================================
org.quartz.threadPool.threadCount =  5
org.quartz.threadPool.threadPriority = 5
org.quartz.threadPool.class = org.quartz.simpl.TaskerThreadPool
#===============================================================
#Configure JobStore
#===============================================================
org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore
```

### Standalone configuration with configured cluster

If you have a standalone running in cluster mode, quartz settings differ depending on the database used. Below are the settings for each of the possible scenarios.
At any database, the settings apply to the same quartz.properties file in the same path you entered earlier.

Configuration for Postgres Database

```shell
#============================================================================
# Configure Main Scheduler Properties
#============================================================================
org.quartz.scheduler.instanceName = 4bizMonitor
org.quartz.scheduler.instanceId = AUTO
#============================================================================
# Configure ThreadPool
#============================================================================
org.quartz.threadPool.class = org.quartz.simpl.TaskerThreadPool
org.quartz.threadPool.threadCount = 25
org.quartz.threadPool.threadPriority = 5
#============================================================================
# Configure JobStore
#============================================================================
org.quartz.jobStore.misfireThreshold = 60000
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.PostgreSQLDelegate
org.quartz.jobStore.useProperties = true
org.quartz.jobStore.dataSource = 4biz
org.quartz.jobStore.tablePrefix = QRTZ_
org.quartz.jobStore.isClustered = true
org.quartz.jobStore.clusterCheckinInterval = 20000
org.quartz.dataSource.4biz.jndiURL= java:/jdbc/4biz
```

Configuration for Microsoft SQL Server Database

```shell
#============================================================================
# Configure Main Scheduler Properties
#============================================================================
org.quartz.scheduler.instanceName = 4bizMonitor
org.quartz.scheduler.instanceId = AUTO
#============================================================================
# Configure ThreadPool
#============================================================================
org.quartz.threadPool.class = org.quartz.simpl.TaskerThreadPool
org.quartz.threadPool.threadCount = 25
org.quartz.threadPool.threadPriority = 5
#============================================================================
# Configure JobStore
#============================================================================
org.quartz.jobStore.misfireThreshold = 60000
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.MSSQLDelegate
org.quartz.jobStore.useProperties = true
org.quartz.jobStore.dataSource = 4biz
org.quartz.jobStore.tablePrefix = QRTZ_
org.quartz.jobStore.isClustered = true
org.quartz.jobStore.clusterCheckinInterval = 20000
org.quartz.dataSource.4biz.jndiURL= java:/jdbc/4biz
```

Configuration for Oracle Database

```shell
#============================================================================
# Configure Main Scheduler Properties
#============================================================================
org.quartz.scheduler.instanceName = 4bizMonitor
org.quartz.scheduler.instanceId = AUTO
#============================================================================
# Configure ThreadPool
#============================================================================
org.quartz.threadPool.class = org.quartz.simpl.TaskerThreadPool
org.quartz.threadPool.threadCount = 25
org.quartz.threadPool.threadPriority = 5
#============================================================================
# Configure JobStore
#============================================================================
org.quartz.jobStore.misfireThreshold = 60000
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.oracle.OracleDelegate
org.quartz.jobStore.useProperties = true
org.quartz.jobStore.dataSource = 4biz
org.quartz.jobStore.tablePrefix = QRTZ_
org.quartz.jobStore.isClustered = true
org.quartz.jobStore.clusterCheckinInterval = 20000
```

## Creating directories for installation

Create all directories below necessary for the solution to run. Remember that the owner of the directories must be the Wildfly user.

```shell

[root@server /tmp]# mkdir -p /opt/4biz/{ged,kb,twinwords,attachkb,upload}
[root@server /tmp]# chown -R wildfly.wildfly /opt/4biz/

```