Incidente: aplicação de múltiplos patches estava causando queda no servidor.

Solução: correção na desativação dos serviços WEBMONITOR e APP_MONITOR que estava causando essas quedas (a desativação desses serviços é necessária porque a aplicação de patches precisa acessar o RPO em modo exclusivo).

Referente ao chamado: DTAPPSRV-7683

Incidente: webMonitor não estava funcionando com Broker em ambiente Linux.

Solução: corrigida a comunicação do Broker com o REST do WebMonitor.

Referente ao chamado: DTAPPSRV-7700

Incidente: impressões que utilizam a TOTVS Printer param de funcionar após aplicação ou geração de Patch no TOTVS Developer Studio para VSCode.

Solução: foi aplicada uma correção no processo de aplicação/geração de Patch para que não interfira na comunicação com a TOTVS Printer.

Referente ao chamado: DTAPPSRV-7703 e DTCLIENT01-4436.

Incidente: quando as propriedades da classe tWSDLManager recebiam valores diferentes do esperado, ocorria inconsistência em seu retorno.

Solução: foram realizadas melhorias no tratamento de dados de entrada da classe tWSDLManager.

Referente ao chamado: DTAPPSRV-7659

Incidente: falha na execução de filtro alltrim(campo) = alltrim(cVariável) usando SQLITECLIENT com SQLITESERVER. Não era registrado erro, porém mesmo que houvessem registros que estão contemplados pela expressão do filtro, nenhum registro era retornado e a tabela ficava em EOF().

Solução: alterada a forma de tratamento de filtro, realizando um pre-processamento do lado Client da conexão e enviando um filtro SQL válido ao SQLite SERVER.

Referente ao chamado: DTAPPSRV-7616

Solicitação: mensagens informativas em excesso no fechamento de conexões SSL.

Solução: as mensagens informativas no fechamento de conexões SSL agora são gravadas no log apenas se a chave "verbose" estiver habilitada na seção SSLConfigure no appserver.ini

Referente ao chamado: DTAPPSRV-7708

Solicitação: função HTTPQUOTE estava enviando sempre o header Content-Length para todos os métodos, mesmo quando o valor era zero.

Solução: o envio do header Content-Length com valor zerado está sendo feito apenas para os métodos que normalmente exigem um "body": POST, PUT, e PATCH. Nos outros métodos se não não houver body, o Content-Length não será enviado. O não envio de header Content-Length zerado é especialmente importante para o método DELETE, que pode causar erro em alguns servidores HTTP.

Referente ao chamado: DTAPPSRV-7610

Solicitação: necessidade um recurso para realizar normalização de strings UTF-8.

Solução: implementação de nova classe tUnicode capaz de realizar normalização e conversão de encodings. Esta classe está disponível apenas para linguagem TLPP.

Referente ao chamado: DTAPPSRV-7504

Solicitação: criação de um novo parâmetro por linha de comando para obter mais informações sobre a versão do AppServer

Solução: novo parâmetro  "fullversion" retornando informações mais completas sobre a versão do AppServer tais como: Build Version, Profile (Debug, Release ou Release com Debug), Arquitetura, Plataforma, data de geração e demais informações. Exemplo: 

./appserver -fullversion

Referente ao chamado: DTAPPSRV-7292

Solicitação: necessidade de atender integrações com Instituições Financeiras, que utilizam a criptografia de um token JWT utilizando o algoritmo RSA_OAEP e encriptação A256GCM.

Solução: criação de uma nova classe tJWE para linguagem TLPP, baseada no JSON Web Encryption (JWE), que é um padrão que define uma maneira compacta e independente de transmitir informações seguras como um objeto JSON. Esta classe é capaz de realizar a criptografia de conteúdo, garantindo a confidencialidade dos dados.

Documentação: tJWE

Referente ao chamado: DTAPPSRV-7358