Histórico da Página

Olá Clientes!

Para melhor entendimento, faremos uma breve explicação das versões de cada framework e seu ecossistema.

02. Evolução da arquitetura dos produtos:

Arquitetura utilizando o provedor de identidade JOSSO, que chamaremos de VERSÃO 4:

1. Arquitetura disponibilizada em 2012, as aplicações rodam apenas no JBoss EAP 6.4, com modificações nos módulos do servidor para atender às necessidades do JOSSO.
2. As versões dos frameworks utilizadas para as aplicações são:
   • Framework Orion 3.x e 4.x para os artefatos .war (Frontend JSP/JSF).
   • Framework Service 3.x para os artefatos .ear (Backend JavaEE).
   • Versão dos produtos 3.X para artefatos .ear (Backend JavaEE) e 4.x para artefatos .war (Frontend JSP/JSF).

Conforme comunicado, manteremos esta versão para os clientes até dezembro de 2024. Até essa data, recomendamos a migração para as versões mais recentes do produto Dimensa (V6), porém todos os clientes receberão pacotes de correções, se necessário.

Arquitetura utilizando o provedor de identidade Keycloak, que chamaremos de VERSÃO 5:

1. Arquitetura disponibilizada em 2019, as aplicações rodam de forma híbrida com JBoss EAP 6.4, Wildfly 11 e Spring Boot.
2. As versões dos frameworks utilizadas para as aplicações são:
   • Framework Orion 3v2 e 5.x para os artefatos .war (Frontend JSP/JSF) que rodam no servidor JBoss EAP 6.4.
   • SPA Framework 5.x para os artefatos .war (Frontend AngularJS) que rodam no servidor Wildfly 11.
   • Framework Service 4.x para os artefatos .ear (Backend JavaEE) que rodam no servidor Wildfly 11.
   • Spring Boot para os artefatos .jar, utilizando o próprio framework Spring Boot e suas implementações, subindo com o servidor embarcado (Tomcat) na aplicação.
   • Versão dos produtos 4.X para artefatos .ear (Backend JavaEE) e 5.x para artefatos .war (Frontend JSP/JSF e AngularJS), 1.x e 2.x para artefatos .jar (Spring Boot).

Conforme comunicado, manteremos esta versão para os clientes até setembro de 2024. Até essa data, recomendamos a migração para as versões mais recentes do produto Dimensa (V6), porém todos os clientes receberão pacotes de correções, se necessário.

Arquitetura utilizando o provedor de identidade Keycloak Jornada Cloud V6, que chamaremos de VERSÃO 6:

1. É uma evolução da arquitetura anterior onde passou a ser disponibilizada em 2023.
2. As aplicações rodam com Wildfly 11 ou 18 e Spring Boot.
3. As versões dos frameworks utilizadas para as aplicações são:
   • Framework Orion 6.x para os artefatos .war (Frontend JSP/JSF) que rodam no servidor Wildfly 11 ou 18.
   • SPA Framework 6.x para os artefatos .war (Frontend AngularJS) que rodam no servidor Wildfly 11 ou 18.
   • Framework Service 6.x para os artefatos .ear (Backend JavaEE) que rodam no servidor Wildfly 11 ou 18.
   • Framework Gotham 6.x para os artefatos .jar (Spring Boot), que rodam com o servidor embarcado (Tomcat) na aplicação.
   • Versão dos produtos 6.x para artefatos .ear (Backend JavaEE), 6.x para artefatos .war (Frontend JSP/JSF e AngularJS), e 6.x para artefatos .jar (Spring Boot).

Esta é a versão mais recente, liberada para todos os clientes. Todos os desenvolvimentos de inovações, atualizações legislativas (como IFRS9) e customizações são disponibilizados nesta versão.

02. Mudanças e Configurações Necessárias V6

Para implantação da nova versão 6 foi feita algumas modificações que precisam ser ajustadas em ambientes que já utilizavam o provedor de identidade Keycloak:

• Mudança URL do Contexto das Aplicações e serviços.
  1)  Para aplicações que utilizam (Frontend JSP/JSF) o contexto das versões anteriores eram jsp_basico e para atender a nova versão muda para jspbasico, ou seja todos contextos perdem o caracter _ (underline) para acesso as telas da aplicação.
  2)  Para aplicações que utilizam (Frontend AngularJS) o contexto das versões anteriores eram portal-admin-web e para atender a nova versão muda para portaladminweb, ou seja todos contextos perdem o caracter - (hífen) para acesso as telas da aplicação.
  3)  Para aplicações que utilizam (Backend JavaEE ou Spring Boot) o contexto das versões de nossas API's (serviços) anteriores tfs-portaladmin-service, integrador-basico ou sb-credito-efetivacao-service e para atender a nova versão todos contextos perdem o caracter - (hífen) para a chamada das mesmas, exemplo : tfsportaladminservice, integradorbasico e sbcreditoefetivacaoservice.
  
• Mudança Conexão com o banco de dados Datasource
  1)  Para aplicações que rodam no servidor Wildfly 11 ou 18 houve mudança no datasource de totvsDS e totvsTrilhaAuditoriaDS para dimensaDS e dimensaTrilhaAuditoriaDS, para atender a nova estrutura da Dimensa, exemplo: jndi-name="java:/jboss/datasources/totvsDS" para jndi-name="java:/dimensaDS".
  
• Mudança Sistema Segurança
  1)  Alterar pelo sistema Portal Administrador tela cadastro de sistema a url do sistema tirando os hifens e underlines para atender o novo contexto da aplicação.
  2)  Alterar Owner APP tabela T900arqu o arquivo app.xml com as urls do sistema tirando os hifens e underlines para atender o novo contexto da aplicação.
  3)  Alterar Owner APP tabela T900arqu o arquivo db.xml, com as urls de conexão com o banco de dados.
  4)  Para o servidor Wildfly 18 rodar com as variáveis de ambiente, exemplo: -DdialectApp=org.hibernate.dialect.Oracle10gDialect/-DdialectApp=org.hibernate.dialect.SQLServer2012Dialect e -Dtotvs.tfs.config.path=/opt/totvs/tfs, ao qual informam o dialeto do banco de dados e caminho do arquivo global de configuração totvs-financial-services.conf.
• Mudança Arquivos de configuração totvs-financial-services.conf e application.properties/yml
  1)  urls de serviço e contextos tirando os hifens e underlines para atender a nova versão, exemplo :  tfs-portaladmin-service, integrador-basico ou sb-credito-efetivacao-service para   tfsportaladminservice, integradorbasico e sbcreditoefetivacaoservice.

03. Migração parcial em ambiente com a versão 5 e versão Jornada Cloud 6

Todos os passos acima devem ser efetuados apenas para o produto que migrou para a V6, sendo eles:
    1)  Mudança URL de Contexto da aplicação que foi para a V6.
    2)  Adição do novo Datasource, porém deixando o antigo também, pois terá produtos que ainda respeitaram a conexão do DS antigo totvsDS.
    3)  Mudança Sistema Segurança, somente para o produto migrado para a V6.
    4)  Mudança no arquivos de configuração somente para as urls do produto migrado para a V6.

04. Objetivo de evolução para a V6.

Abaixo segue alguns ganhos que teremos com as mudanças:
    1)  Descontinuação do servidor Jboss EAP 6.4, que perdeu o suporte da RedHat em julho-2024.
    2)  Mitigação de vulnerabilidades técnicas e de segurança com uma infraestrutura defasada.
    3) Automaização nos fluxos de entrea de código e Cloud Dimensa
    4) Documentação das API's automatizada
    5) Automatizar a gestão dos scripts de banco de dados com FlywayDB.
    6) Maior agilidade em entregas e manutenções nos fontes e frameworks, mantendo uma versão recorrente, apenas na 6.x.x.x

05. Instalação das versões.

Neste cenário a instalação de até 3 versões podem ser complexas, pois existem produtos na V4, V6 e em conjunto a homologação da IFRS9 - V6.

Infelizmente até o encerramento das versões em coexistência, é complicado pelo painel de expedição, saber quais versões devem ser homologadas? quais versões recebem FIX/ correções e que devem ser liberadas em PRD? qual a versão específica tem a IFRS9? Enfim, com o objetivo de facilitar nesta jornada, disponibilizamos um mapa de versões:

Link:

Gostaríamos de informar que nossa equipe de integradores está trabalhando para garantir que seus sistemas estejam preparados para a nova versão do catálogo do PIX, 5.08, que será lançada pelo Banco Central (BACEN) no dia 27 de outubro de 2024.

Como parte do nosso compromisso com a qualidade e inovação, essa atualização será realizada utilizando o Java 17, substituindo a versão 8 atualmente em uso.

A nova versão estará disponível para vocês no dia 26 de setembro de 2024, para que possam realizar as atualizações, validações, e eventuais adequações de infraestrutura necessárias antes da mudança oficial para o novo catálogo.

Os produtos impactados por essa atualização incluem:

• JSBPIXADM - PIX ADMIN SB SERVICE
• JSBPIXAPI - PIX API SB SERVICE
• JSBPIXDICT - PIX DICT SB SERVICE
• JSBPIXMSG - PIX MENSAGERIA SB SERVICE
• JSBPIXORQ - PIX ORQUESTRADOR SB SERVICE
• JSBPIXQR - PIX QRCODE SB SERVICE
• JSBPIXSCH - PIX SCHEDULER SB SERVICE
• JSBPIXSPI - PIX SPI SB SERVICE

Dúvidas que podem ocorrer:

1) Quais são os principais motivos para a substituição do Java 8 pelo Java 17?

• A substituição do Java 8 pelo Java 17 foi motivada por diversos fatores que visam garantir a segurança, a performance e a longevidade dos nossos sistemas.
• O Java 17 traz melhorias significativas em termos de eficiência, suporte a novas funcionalidades e correções de segurança que não estão presentes na versão 8. Além disso, o Java 17 é uma versão LTS (Long-Term Support), garantindo suporte estendido e atualizações regulares, o que é crucial para manter nossos sistemas atualizados e resilientes a novas ameaças e desafios tecnológicos.

2) É possível antecipar o upgrade de infraestrutura, atualizando os servidores para o Java 17 antes da migração das versões atuais?

• Não recomendamos, pelos seguintes motivos
• Compatibilidade de versão:
  • Algumas bibliotecas e frameworks usados em conjunto com Java 8 podem não ser compatíveis com Java 17, exigindo atualizações ou substituições
• Ambiente de execução:
  • Será necessário instalar o Java 17 em todos os servidores e ambientes onde as aplicações Java estão em execução.
  • Configurações específicas do ambiente, como variáveis de ambiente e scripts de inicialização, precisarão ser atualizadas para referenciar o novo JDK.
  • Sistemas de monitoramento e logging devem ser revisados para garantir que capturam todas as novas métricas e comportamentos do Java 17.
• Desempenho:
  • O Java 17 inclui melhorias de desempenho, mas o impacto pode variar conforme a aplicação. Testes de desempenho em ambiente de pré-produção são recomendados para identificar possíveis otimizações ou problemas.
• Segurança:
  • Java 17 oferece melhorias significativas de segurança, mas pode exigir revisões nas práticas de segurança de código e configurações para aproveitar ao máximo essas melhorias.
  • Todas estas adequações estão em desenvolvimento pela Dimensa na nova versão 5.08
• Licenciamento e suporte:
  • Avaliar o impacto de licenciamento, especialmente se estiver utilizando uma distribuição comercial do Java. Algumas versões do Java 17 podem exigir uma nova licença ou ter diferentes termos de suporte.

3) A Dimensa fornecerá um documento detalhado de infraestrutura com as requisições e ajustes necessários para essa atualização?

• Verificar com Alvaro a resposta

Ainda tem dúvidas, entre em contato conosco através do e-mail: [email protected] ou Zendesk - Atendimento ao cliente.

Atenciosamente, 

Time Produtos Core Banking