Configurações Extras do 4biz

A partir da versão Helium 1.2.24 foram inseridos novos parâmetros:

Parâmetro: AUTHENTICATION_PROTOCOL;
Ojetivo: Defina o protocolo de autenticação;
Comportamento: Defina se o sistema irá se autenticar com parâmetros internos ou com outro protocolo de autenticação;
Tipo: varchar;
Valor default: internal;
Tipos válidos:
1. OAUTH2: Para autenticação com keycloack – essa informação sobrescreve qualquer política de segurança inserida no cadastro de Política de Segurança;
2. Internal: Para autenticação definida no sistema;
Parâmetro: AUTHENTICATION_CREATE_USER;
Ojetivo: Defina se o usuário será criado na aplicação após login;
Comportamento: Grava o usuário que fez login na aplicação;
Tipo: boleano (true or false);
Valor default: FALSE;
Valores possíveis:

A partir da versão Helium 1.2.23 foram inseridos novos parâmetros:

Parâmetro: MAXIMUM_LOGIN_FIELD_SIZE;
Ojetivo: Defina o tamanho máximo aceitável no campo login;
Comportamento: Apenas impede o login, emitindo uma mensagem genérica, login ou senha inválidos;
Tipo: numérico;
Valor default: 25;
Parâmetro: ALLOW_SYMBOLS_AT_LOGIN;
Ojetivo: Defina se o sistema aceita símbolos no campo login;
Comportamento: Apenas impede o login, emitindo uma mensagem genérica, login ou senha inválidos;
Tipo: boleano (true or false);
Valor default: FALSE.

A partir da versão Helium 1.2.19 o arquivo CITSMART.CFG passa a se chamar “application.ini” e deve seguir as orientações abaixo:

A atualização da tabela só vai ocorrer quando o parâmetro LOAD_FACTSERVICEREQUESTRULES do APPLICATION.INI possuir o valor TRUE. Na ausência dessa configuração no arquivo, o sistema assume o valor FALSE para o parâmetro. Ou seja, o default é NÃO atualizar a tabela;
Caso exista algum schedule relacionado a regra de escalação de um ticket e o parâmetro LOAD_FACTSERVICEREQUESTRULES possuir o valor FALSE, o sistema emite no LOG o alerta: The system cannot start processing escalation rules because the LOAD_FACTSERVICEREQUESTRULES property (configuration file) is equal to FALSE;
NOVOS PARÂMETROS PARA O APPLICATION.INI: Para ativar o updateParameters, opção para sincronizar os valores dos parâmetros em memória, de um ambiente clusterizado; devemos adicionar no arquivo application.ini a seguinte configuração: UPDATEPARAMETERS_PORT=<número da porta que será utilizado> exemplo: UPDATEPARAMETERS_PORT=2002.

Crie um arquivo chamado application.ini em /opt/wildfly/standalone/configuration/ com as informações abaixo:

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

Dê permissão para o usuário do wildfly para este arquivo:

chown wildfly.wildfly /opt/wildfly/standalone/configuration/application.ini

🖊 Nota: No arquivo application.ini, o valor padrão é TRUE (mesmo se não for definido), ou seja, se essa opção não existir no arquivo, o sistema utilizará o valor TRUE para essa propriedade. Definido como TRUE, ativa o Thread que atualiza a tabela de fatos de solicitações de serviço na inicialização do sistema. Definido como FALSE, a atualização ocorrerá somente após a inclusão ou alteração da solicitação de serviço.

Na versão Helium 2.1.14 o sistema não utiliza mais o parâmetro 449 para definir o tempo de sessão, ele, agora, é controlado pelo tempo de expiração do token JWT.

Esse tempo de expiração é parametrizado no arquivo application.ini, propriedade TOKEN_MAX_AGE definido em milissegundos. Caso não esteja definido, neste arquivo, o valor default é: 1 dia. Porém, nesta versão existe um recurso para manter a sessão de usuário, ativa por tempo indeterminado, desde que ele continue usando o sistema dentro do período de um dia. Em outras palavras, se não completar um dia e o usuário utilizou o sistema, a sessão dele continuará ativa até que se passe mais de 24 horas. Este recurso foi removido na versão 3.0.0.

Configuração do Quartz

O processamento Batch do 4biz utiliza o Quartz para o agendamento e processamento de rotinas de sistema. Crie um arquivo de nome "quartz.properties" no caminho /opt/wildfly/standalone/configuration/.

As configurações se diferem para standalone comum, para o standalone configurado em modo cluster. Em qualquer um dos casos, configure o wildfly da seguinte maneira.

Configuração standalone sem cluster

Se você estiver rodando o wildfly em modo standalone mas sem configuração de cluster, insira as seguintes informações no arquivo quarts.properties:

#===============================================================
#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.SimpleThreadPool
#===============================================================
#Configure JobStore
#===============================================================
org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore

Configuração standalone com cluster configurado

Caso você tenha um standalone funcionando em modo cluster, as configurações do quartz são diferentes de acordo com banco de dados utilizado. Abaixo seguem as configurações para cada um dos possíveis cenários.

Qualquer que seja o banco de dados, as configurações se aplicam ao mesmo arquivo quartz.properties no mesmo caminho informado anteriormente.

Configuração para Banco de Dados Postgres

#============================================================================
# Configure Main Scheduler Properties
#============================================================================
org.quartz.scheduler.instanceName = 4BizMonitor
org.quartz.scheduler.instanceId = AUTO
#============================================================================
# Configure ThreadPool
#============================================================================
org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
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 = citsmart
org.quartz.jobStore.tablePrefix = QRTZ_
org.quartz.jobStore.isClustered = true
org.quartz.jobStore.clusterCheckinInterval = 20000
org.quartz.dataSource.citsmart.jndiURL= java:/jdbc/citsmart

Configuração para o banco de dados Microsoft SQL Server

#============================================================================
# Configure Main Scheduler Properties
#============================================================================
org.quartz.scheduler.instanceName = 4BizMonitor
org.quartz.scheduler.instanceId = AUTO
#============================================================================
# Configure ThreadPool
#============================================================================
org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
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.citsmart.jndiURL= java:/jdbc/citsmart

Configuração para o banco de dados Oracle

#============================================================================
# Configure Main Scheduler Properties
#============================================================================
org.quartz.scheduler.instanceName = 4BizMonitor
org.quartz.scheduler.instanceId = AUTO
#============================================================================
# Configure ThreadPool
#============================================================================
org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
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

Criação de diretórios para instalação

Crie todos os diretórios abaixo necessários para funcionamento da solução. Lembre-se que o dono dos diretórios precisa ser o usuário wildfly.

mkdir -p /opt/4biz/{ged,kb,twinwords,attachkb,upload}

chown -R wildfly.wildfly /opt/4biz/