5.50 RTM 1.05

Data de liberação : 26/08/2022

Pontos de impacto

Log4j – Customização

O arquivo de configuração que era um “properties” (log4j.properties), foi alterado para um arquivo “xml” (log4j2-production.xml). Esse arquivo fica no mesmo local, em /opt/lecom/app/tomcat_aceite/webapps/<<modulo>>/WEB-INF/classes e possui um padrão diferente. A partir de agora, a configuração de log não deve ser feita diretamente nesse arquivo. (PLT-2286)

Para simplificar, a configuração do log deverá ser realizada através de uma ferramenta interna da plataforma, cujo endereço para acesso é: [URL_DO_AMBIENTE]/bpm/system/login

Dessa forma, após a atualização para esse release, a configuração de log voltará para o padrão de registro. Assim, se houver necessidade de algum log específico, essa configuração deverá ser feita novamente através da ferramenta acima (/system).

Além disso, adotamos como padrão a biblioteca slf4j, que possui uma melhor performance no registro de log. Assim, será necessário atualizar a importação de dependência e alterar o nome da classe em todas as customizações, caso contrário a aplicação não irá iniciar.

Segue um exemplo do padrão anterior, log4j:

#Importação da dependência
import org.apache.log4j.Logger;
...
#Definição classe
private Logger logger = Logger.getLogger(NomeClasse.class);
 

E agora, um exemplo no padrão novo, usando slf4j2:

#Importação da dependência
import org.slf4j.Logger;import org.slf4j.LoggerFactory;
…
#Definição classe
private Logger logger = LoggerFactory.getLogger(NomeClasse.class);

Utilizar a biblioteca Slf4j na versão 1.7.36 (slf4j-api.jar) no ambiente de desenvolvimento das customizações.

Alteração do tipo do campo código de usuário

Ao iniciar o ambiente será executado o liquibase para alterar o tipo de dados de todas as colunas relacionadas ao usuário de todas as tabelas do BD. Isso pode demorar para ser executado.

No BD MySQL e SQLServer, o tipo do campo foi alterado para bigint e no Oracle para Number (19,0).

Já na programação em Java, o tipo do campo foi alterado de short para long. Devido a essa alteração, é necessário rever todas as customizações (robôs, integrações, aplicações externas, portais, webhooks etc.) que manipulam todos os campos relacionados ao usuário. Caso não sejam ajustadas, o código poderá ser convertido errado e o ambiente não irá iniciar. (PLT-1750)

Segue abaixo a relação dos nomes dos campos que foram alterados:

• ABERTO_POR

• COD_LIDER

• COD_REMETENTE

• COD_SUBSTITUTO

• COD_USUARIO

• COD_USUARIO_ETAPA

• COD_USUARIO_PROPRIETARIO

• CODIGO_ABERTO_POR

• CODIGO_PARADO_EM

• MULT_CODIGO

• USER_ID

• USUARIO

• USUARIOPROPRIETARIO

Atualização da versão do Spring Boot para 2.6.6

Devido à atualização do Spring Boot, é necessário (PLT-1779):

1. Atualizar a versão do TOMCAT para 9.0.65 ou superior;

2. No Proxy, ajustar o mapeamento, removendo o caractere “/” do final dos valores definidos.

Segue um exemplo do padrão anterior: 

<LocationMatch “^/bpm/api/v(.*)/process-instances/(.*)/activity-instances/(.*)/cycles/(.*)/fields/(.*)/documents/import”>


ProxyPass https://[IP_AMBIENTE]
ProxyPassReverse https://[IP_AMBIENTE]/ –> remover essa barra


</LocationMatch>
<LocationMatch “^/bpm/api/v(.*)/process-instances/(.*)/activity-instances/(.*)/cycles/(.*)/documents/files/(.*)/download”>


ProxyPass https://[IP_AMBIENTE]
ProxyPassReverse https://[IP_AMBIENTE]/ –> remover essa barra


</LocationMatch>


E agora, um exemplo no padrão novo: 

<LocationMatch “^/bpm/api/v(.*)/process-instances/(.*)/activity-instances/(.*)/cycles/(.*)/fields/(.*)/documents/import”>


ProxyPass https://[IP_AMBIENTE]
ProxyPassReverse https://[IP_AMBIENTE]


</LocationMatch>
<LocationMatch “^/bpm/api/v(.*)/process-instances/(.*)/activity-instances/(.*)/cycles/(.*)/documents/files/(.*)/download”>


ProxyPass https://[IP_AMBIENTE]
ProxyPassReverse https://[IP_AMBIENTE]


</LocationMatch>

Caso isso não seja feito, o upload de documentos pelo formulário não irá funcionar.

3. No Proxy, dentro das configurações do gateway, alterar o mapeamento “/zull" para "/gateway”, veja exemplo abaixo: 

Segue o padrão anterior: 

## GATEWAY
ProxyPass “/zuul” https://[IP_AMBIENTE]:8181/
ProxyPassReverse “/zuul” https://[IP_AMBIENTE]:8181/

E agora o padrão novo:

## GATEWAY
ProxyPass “/gateway” https://[IP_AMBIENTE]:8181/gateway
ProxyPassReverse “/gateway” https://[IP_AMBIENTE]:8181/gateway

4. No arquivo node-web-server.config.js, que fica em /opt/lecom/app/microservices/node-web-server/config/, será necessário alterar o sufixo da variável GATEWAY_URL de “/zull” para “/gateway” do componente “form-web”:

Segue o padrão anterior:

name: ‘form-web’,
script: ‘/opt/lecom/app/microservices/node-web-server/form-web/server/server.js’,
env: {


“SERVICE_NAME”: “form-web-server”,
“SERVER_PORT”: “3001”,
“CONTEXT_PATH”: “/form-web”,
“GATEWAY_URL”: https://[URL_AMBIENTE]/zull,
“LECOM_BPM_URL”: https://[URL_AMBIENTE]:443/


}

E agora o padrão novo: 

name: ‘form-web’,
script: ‘/opt/lecom/app/microservices/node-web-server/form-web/server/server.js’,
env: {


“SERVICE_NAME”: “form-web-server”,
“SERVER_PORT”: “3001”,
“CONTEXT_PATH”: “/form-web”,
“GATEWAY_URL”: https://[URL_AMBIENTE]/gateway,
“LECOM_BPM_URL”: https://[URL_AMBIENTE]:443/


}

5. No arquivo .conf, que fica dentro da pasta de cada micro serviço, /opt/lecom/app/microservices/[nome_microsserviço]/, foi alterada a propriedade de identificação do arquivo de log. Na variável “RUN_ARGS”, alterar de logging.file para logging.file.name

Segue o padrão anterior:

JAVA_HOME=/opt/lecom/java
JAVA_OPTS=”-server -Xms256m -Xmx256m -XX:+UseConcMarkSweepGC -javaagent:/opt/lecom/newrelic/service-integration/newrelic/newrelic.jar”
RUN_ARGS=”–logging.file =/opt/lecom/app/microservices/logs/lecom_service-integration.log”

E agora o padrão novo:

JAVA_HOME=/opt/lecom/java
JAVA_OPTS=”-server -Xms256m -Xmx256m -XX:+UseConcMarkSweepGC -javaagent:/opt/lecom/newrelic/service-integration/newrelic/newrelic.jar”
RUN_ARGS=”–logging.file.name=/opt/lecom/app/microservices/logs/lecom_service-integration.log”

6. Atualizar os componentes integracao.jar, RoboWF.jar e WfMail.jar, que são utilizados  nas customizações, caso contrário a aplicação não irá iniciar. Esses componentes estão disponíveis através do Nexus (repositório de componentes e bibliotecas), através dos links abaixo: (PLT-2471, PLT-2472 e PLT-2473)

https://repo-store.lecom.com.br/#browse/browse:lecom-releases:br%2Fcom%2Flecom%2Fintegracao%2F1.6.0-RELEASE

https://repo-store.lecom.com.br/#browse/browse:lecom-releases:br%2Fcom%2Flecom%2FRoboWF%2F1.4.0-RELEASE

https://repo-store.lecom.com.br/#browse/browse:lecom-releases:br%2Fcom%2Flecom%2FWFMail%2F1.5.0-RELEASE

DevOps (clientes que utilizam esse recurso)

1. Atualizar o valor do campo “gatewayURL” da tabela “servers”, no GitLabService, referente a rota utilizada no cadastro do cliente, de “/zull" para "/gateway”; (PLT-1779)

2. Com as alterações do Spring-boot, foi necessário ajustar as chamadas do BPM para utilizar as novas rotas de definição dos templates de customização. Para cada projeto existente que utiliza o DevOps, deverá ser ajustado o import no arquivo pom.xml (PLT-2462, PLT-2463, PLT-2464)

Segue o padrão anterior feito no arquivo pom.xml:

<parent>


<groupId>br.com.lecom</groupId>
<artifactId>integration-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<relativePath/>


</parent>

E agora o padrão novo:

<parent>


<groupId>br.com.lecom</groupId>
<artifactId>integration-parent</artifactId>
<version>1.0.0-RELEASE</version>
<relativePath/> <!– lookup parent from repository –>


</parent>

Observe que agora é utilizada a versão 1.0.0-RELEASE e não mais a SNAPSHOT. Caso isso não seja feito, a aplicação não será iniciada.

Simplificação da parametrização de instalação 

Foi retirada a tela de instalação do core/install e agora será feito através de variáveis, que pode ser verificado no manual de implantação. (PLT-1898) 

Auditoria no módulo Studio 

Foi criado um micro serviço para o módulo de Auditoria no Studio e para realizar a configuração, siga as instruções do manual de implantação. (STUDIOWEB-1445) 

Funcionalidades ativas por padrão 

As funcionalidades abaixo passaram a ser nativas na plataforma, portanto não exigem mais a configuração. Dessa forma, recomendamos que as suas respectivas variáveis dentro dos seus arquivos de configuração, sejam removidas. (PLT-1964)

Nova versão do driver do MySql

Como foi atualizada a versão do driver do MySql, para obter todos os benefícios dela, recomendamos a atualização das conexões dos BD’s auxiliares e/ou externos. Para fazer isso, utilize o ConfigBD, através da opção “J Configuração Livre”. (PLT-1527)

Segue o padrão anterior do driver utilizado: com.mysql.jdbc.Driver

E agora o padrão novo: com.mysql.cj.jdbc.Driver

Headers de segurança

Alterar o conteúdo da variável ACCESS_CONTROL_ALLOW_ORIGIN, quando ela estiver configurada como “*“ (asterisco), pois não será mais aceito esse tipo de configuração. Ou seja, será necessário especificar cada host que poderá acessar a aplicação. Esse formato, inclusive, possui uma maior segurança. E essa variável pode estar definida (PLT-2427):

• No Node, no arquivo global.env (/opt/lecom/app/microservicos/node-web-server/config/)
  

• No Tomcat, no arquivo catalina.sh ou setenv.sh (/opt/lecom/app/tomcat_ambiente/bin/)
  

• No Microserviços, no arquivo 00-profile.conf (/opt/lecom/app/microservices/envs/)

Além disso, em ambiente sem https, será necessário especificar os endereços localhost, com suas respectivas portas.

Segue um exemplo:

ACCESS_CONTROL_ALLOW_ORIGIN = http://localhost:3000,http://localhost:3001,http://localhost

Pontos de atenção

Auditoria no módulo Studio com DevOps

Nesse release, o registro de auditoria nos módulos de Robô, Aplicação Externa e Integração, não faz parte do escopo. Esses itens estão previstos para a última fase do projeto DevOps. (PLT-2451)

Configuração do Quartz

Com a simplificação da parametrização de instalação, o Quartz, que é responsável pelo agendamento da execução de robôs, será configurado como JDBC automaticamente. Dessa forma, o controle da execução será armazenado no banco de dados em tabelas cujo nome inicia com “QRTZ_”. (PLT-2000)

Logs do Hibernate

Após a atualização da versão do Hibernate, ao iniciar o sistema e ao gerar tabela, serão apresentados novos logs de “WARN” no log “GeralWorkflow”, que não geram impactos na plataforma. Isso ocorre no banco de dados MS SQL Server ou Oracle. (PLT-2335)

Veja um exemplo do arquivo GeralWorkflow.log: