Versão 87

Novidades

Arquivamento de logs transacionais

O sistema passa a arquivar os registros de log transacional que são removidos do banco de dados durante a limpeza da tabela iLog. O arquivamento tem o objetivo de preservar os registros de log antigos que não são consultados com frequência em soluções de armazenamento mais econômicas que o banco de dados. Os registros arquivados podem ser restaurados a qualquer momento para análises pontuais quando necessário.

O arquivamento pode ser feito em um diretório local do servidor ou em serviços de armazenamento em nuvem. O armazenamento em nuvem é recomendado para ambientes de produção, pois simplifica a criação de políticas de backup e o uso de classes de armazenamento com custo reduzido para arquivos que não são acessados com frequência.

Com a nova funcionalidade, o processo “Administração do sistema > Auditoria > Limpeza da tabela de log” passa a abrigar as configurações de limpeza e arquivamento, a restauração de logs e a visualização do histórico de limpezas. Mais detalhes no manual do processo .

Observação: a limpeza dos logs transacionais passa a ser desabilitada por padrão, sendo necessário reabilitá-la logo após a atualização, considerando as novas configurações de arquivamento.

Melhorias

Administração do sistema

  • A funcionalidade “Comprimir imagens existentes” do processo “Administração do sistema > Armazenamento de arquivos > Perfis de compressão de imagens” passa a permitir a compressão de arquivos na Virtual File System.

Desenvolvimento

  • O pacote @nginstack/build-tools passa a carregar as variáveis de ambiente dos arquivos .env.local, .env.windows e .env.linux, além do arquivo .env já existente. O arquivo .env.local é carregado antes dos demais, permitindo sobrescrever variáveis de ambiente definidas nos outros arquivos. É recomendado que apenas ele contenha informações sensíveis e que ele seja adicionado ao .gitignore para evitar o compartilhamento acidental de informações. Os arquivos .env.windows e .env.linux são carregados apenas na plataforma correspondente. Mais detalhes sobre a configuração de variáveis de ambiente podem ser encontrados no README do pacote @nginstack/build-tools .

Engine

  • Foi criada a propriedade AuthToken.prototype.context com o objetivo de determinar o contexto de utilização e isolamento do token de autorização. Por padrão, os tokens são criados com contexto 'global', indicando que são válidos em todo o sistema e que são persistidos na base de dados. Os tokens agora podem ser criados com os contextos 'engine' e 'session'. Esses contextos restringem a validade e abrangência do token para o tempo de vida do processo do Engine ou de uma sessão do usuário. Por não serem persistidos na base de dados, eles têm um custo de uso menor e possuem a vantagem de poderem ser emitidos e utilizados mesmo quando o Engine está off-line.
  • O cache de tokens de autorização passa a ser persistente, evitando a necessidade de revalidação de tokens que já foram utilizados anteriormente após o reinício do Engine. Processos executados em cenários off-line e que dependem de tokens de contexto 'global' passam a poder utilizar a estratégia de esquentar o cache a fim de garantir o seu funcionamento off-line.

Web Framework

  • O método Process.prototype.authenticateUser passa a suportar autenticação de usuários via provedores de identidade externos, permitindo que interfaces do sistema que fazem uso desse método possam ser utilizadas por usuários autenticados exclusivamente por esses provedores. Processos que coletam credenciais diretamente via campos de formulário e chamam Security.prototype.authenticateUser para validar o usuário devem ser revistos para utilizar Process.prototype.authenticateUser , tornando-se compatíveis com provedores de identidade externos.

Extensão VS Code

  • A lista de conexões a bases de dados agora pode ser ordenada. Os modos de ordenação incluem manual, último uso, alfabético e por nomes principais (“Core names”). Este último é um tipo de ordenação alfabética que agrupa conjuntos de bases cujos nomes são diferenciados apenas por prefixos ou sufixos. Por exemplo, as bases TESTE, DTESTE e HTESTE ficariam juntas nessa ordenação, enquanto na ordenação alfabética padrão elas estariam separadas em razão da letra usada no prefixo. Mais detalhes na documentação da extensão .

Defeitos corrigidos

Web Framework

  • A seleção de um campo combo falhava caso o valor associado à opção selecionada fosse um código numérico prefixado com zero.

Outras alterações

Engine

  • Os métodos Security.prototype.authorizeToken e Session.prototype.authorizeToken foram renomeados para Security.prototype.issueAuthToken e Session.prototype.issueAuthToken, respectivamente. Os nomes antigos permanecem disponíveis para fins de compatibilidade.
  • O método Security.prototype.restoreAuthToken foi renomeado para Security.prototype.verifyAuthToken. O nome antigo permanece disponível para fins de compatibilidade.
  • O valor padrão da propriedade expires da classe AuthToken passa a ser null, indicando que os tokens criados sem a atribuição das propriedades expires ou utcExpires de forma explícita serão válidos até que eles sejam revogados.
  • Os métodos obsoletos Session.prototype.loginByToken e Security.prototype.createAuthToken foram removidos. Esses métodos eram remanescentes de uma antiga implementação de tokens de autorização anterior à classe AuthToken. O eventual uso desses métodos deve ser substituído por Session.prototype.loginByAuthToken e Security.prototype.issueAuthToken.