Incidente: em situações especificas, a execução de alguns métodos da classe tgRPC travavam. Por exemplo: ErrorDesc(), isRunning() e etc.

Solução: correção nas chamadas de métodos quando executados com smarlink.proto.

Referente ao chamado: DTAPPSRV-8806

Incidente: queda do AppServer ao utilizar o comando Throw, passando um tipo diferente do esperado e sem o contexto do Try/Catch.

Solução: foi inserida uma proteção no código responsável pela interpretação do comando Throw para evitar a falha.

Referente ao chamado: DTAPPSRV-8796

Incidente: dado inconsistente da leitura de campos MEMO usando TCSQLTOARR(), sempre vinha um ultimo byte -- chr(0) -- a mais no final de cada campo com conteúdo.

Solução: não será mais retornado o chr(0) erroneamente no final de um conteúdo de campo memo.

Referente ao chamado: DTAPPSRV-8782

Incidente: estava ocorrendo falha na instalação do Broker HTTP com plano de Escalabilidade como Serviço no Windows.

Solução: foram realizadas correções na instalação do Broker como serviço.

Referente ao chamado: DTAPPSRV-8749

Incidente: ocorrência de Access Violation durante a inicialização do AppServer em Sistema Operacional Oracle Linux 9.4.

Solução: atualização da biblioteca que faz o controle e gestão de toda parte de alocação de memória do AppServer.

Referente ao chamado: DTAPPSRV-8738

Incidente: informações da versão do binário AppServer não estavam sendo gravadas no arquivo console.log

Solução: corrigido o comportamento do binário para gravar as informações da versão no arquivo console.log

Referente ao chamado: DTAPPSRV-8627

Incidente: uma mensagem de erro estava sendo retornada ao tentar acessar o status de qualquer um dos Servers que estivessem sendo balanceados pelo Broker Http.

Solução: foi inserida uma nova verificação no código para que a página de status fosse retornada ao clicar sobre um dos Servers do Broker.

Referente ao chamado: DTAPPSRV-8694

Incidente: o retorno da API ao acessar a URL "/TOTVS_BROKER_QUERY" deveria estar no formato JSON, porém estava sendo gerado com tags HTML, causando inconsistências na integração com outras aplicações.

Solução: foi criado o endpoint "/TOTVS_BROKER_QUERY/json" para garantir que o retorno seja entregue no formato JSON adequado, sem a inclusão indevida de tags HTML. Além disso, as tags do JSON foram padronizadas para inglês e novos campos foram adicionados, incluindo a versão do Application Server, o tipo do broker e a indicação do uso de SSL.

Mais informações: Consulta do status do broker via browser

Referente ao chamado: DTAPPSRV-8506

Incidente: em alguns casos, ao iniciar o Broker via console utilizando o parâmetro -ini, o Broker ainda tentava buscar configurações no arquivo .ini padrão.

Solução:  foi inserida uma nova verificação no código para que o "ini" recebido como parâmetro seja priorizado.

Referente ao chamado: DTAPPSRV-8910

Incidente: inconsistência no comportamento do Appserver ao tratar o método SET da classe tHashMap quando o número incorreto de parâmetros era recebido.

Solução:  foi inserida uma correção no código para que os métodos SET, GET, DEL e LIST da class tHashMap apresentem uma mensagem de erro ao usuário caso sejam utilizados com um número incorreto de parâmetros. 

Documentação da classe tHashMap: Classe THashMap - Métodos

Referente ao chamado: DTAPPSRV-8865

Incidente: Erro no carregamento do certificado pode causar mensagem de cadeia inválida.

Solução: Correção na carga do certificado utilizado.

Referente ao chamado: DTAPPSRV-9011

Incidente: Ao imprimir via tMSPrinter retorna erro "Invalid DeviceCaps (0) for DISPLAY.

Solução: Erro no retorno da API (WINGDI) do sistema operacional windows. Alteraçãofoi para um reaproveitamento de contexto para otimizar o número de chamadas da API. 

Referente ao chamado: DTAPPSRV-9035 / DTAPPSRV-9075

Situação: identificação de ocorrência de falso positivo em geração de Core Dump com AppServer Debug em Windows, utilizando a ferramenta ProcDump.

Solução:  alteração nos parâmetros de chamada para o ProcDump , gerando Core Dump com sucesso para ocorrências de Stack Overflow, Access Violation, Heap Corruption e demais ocorrências criticas.

Referente ao chamado: DTAPPSRV-8757

Situação: necessidade de mais informações sobre o balanceamento do Broker HTTP.

Solução:  opcionalmente, agora é possível criar um arquivo com o histórico do balanceamento.

Mais informações: https://tdn.totvs.com.br/pages/viewpage.action?pageId=946433640

Referente ao chamado: DTAPPSRV-8735

Situação: necessidade de padronização das configurações para evitar erros no Produto.

Solução: adoção dos valores padrões para as variáveis DBMONEY como "." (ponto) e DBDATE como "dmy4/". Caso essas variáveis não sejam definidas no ambiente, serão utilizados os valores padrões e com isso, evitaremos erros como "Valor de caractere inválido para especificação de conversão" no SQL SERVER e também diferenças de comportamentos em outros bancos.

Referente ao chamado: DTAPPSRV-8729

Situação: MIME TYPES de .png, .mjs e .pdf não suportados na resposta do servidor HTTP.

Solução:  implementação do suporte para os MIME TYPES de .png, .mjs e pdf na resposta do servidor HTTP.

Referente ao chamado: DTAPPSRV-8726

Situação: o retorno dos bancos de dados contêm linhas descritivas que podem ser longas (e de tamanho fixo, preenchido com espaços a direita). Com isso, o retorno da função pode ser melhorado, gerando um resultado mais palatável.

Solução:  tratamento do conteúdo retornado pela função para remoção dos espaços a direita.

Referente ao chamado: DTAPPSRV-8729

Situação: ao carregar um Serviço Rest via Annotation, se houvessem endpoints duplicados, o serviço poderia ser carregado parcialmente, ou seja, apenas carrega os endpoints anteriores a constatação da duplicidade.

Solução:  durante a inicialização do Rest, o serviço continua subindo e carregando todos os endpoints, exceto aqueles que conflitarem.

Referente ao chamado: DTAPPSRV-8593

Situação: algumas informações relevantes relacionadas ao Appserver estavam sendo perdidas no console.log conforme ele rotacionava, além disso, existiam algumas informações relevantes para o debug que não estavam sendo capturadas.

Solução:  foi inserido no arquivo diagnostics.json (gerado durante a inicialização do Appserver) novas informações do Appserver para que elas não sejam perdidas por mais que o console.log rotacione.

Referente ao chamado: DTAPPSRV-8557

Situação: algumas informações relevantes relacionadas ao Hardware em que o AppServer estava sendo executada estavam sendo perdidas no console.log conforme ele rotacionava.

Solução:  foi inserido no arquivo diagnostics.json (gerado durante a inicialização do Appserver) as informações de hardware para que elas não sejam perdidas por mais que o console.log rotacione.

Referente ao chamado: DTAPPSRV-8556

Situação: necessidade de inclusão da revisão do Vader no console.log do Application Server.

Solução:  nova informação sobre a revisão do Vader adicionada ao console.log.

Referente ao chamado: DTAPPSRV-8550

Situação: necessidade de implementar suporte a virtual Hosts na Classe tAmqp.

Solução:   implementado suporte a virtual Hosts (vhosts).

Para mais informações, verificar a documentação da classe: tAMQP

Referente ao chamado: DTAPPSRV-8051

Situação: ao passar por uma linha com if ternário, o code coverage responde apenas se passou pela linha e quantas vezes passou. Entretanto, ele não sabe dizer se todos os caminhos do if ternário foram cobertos.

Solução:  o code coverage pode responder percentualmente a cobertura quando uma linha do fonte contém um ou vários ifs ternários. Em outras palavras, o coverage vai informar se a cobertura da linha foi, por exemplo, de 25%, 50% ou 100%.

Referente ao chamado: DTAPPSRV-8414

Situação: necessidade de validar a inicialização do Webmonitor no Broker

Solução:  caso a inicialização do WebMonitor tenha falhado, por padrão a ativação do Broker será bloqueada para que não haja um problema de se acessar o WebMonitor remoto sem que se queira, todavia isto somente se o WebMonitor tiver sido configurado no Broker.

Referente ao chamado: DTAPPSRV-8909

Situação: necessidade de validar a inicialização do Webapp no Application Server.

Solução:  caso a inicialização do WebApp tenha falhado, por padrão a ativação do Servidor será bloqueada. Para a versões 24.3.0.8 ou acima isto vale tanto pela ativação da carga da biblioteca (webapp.dll ou webapp.so) assim como pela carga protegida através do "Dyncall".
Para manter o comportamento anterior de permitir a ativação do Servidor mesmo com uma falha do WebApp, foi criada uma chave de "ini" que mantém a ativação do Servidor na falha do Webapp (NonStopOnError), segue o exemplo abaixo.

[WebApp]
; Se estiver ligada ("1") indica que não irá parar a ativação do Servidor na falha do WebApp. Por padrão é 0 (zero) desligada.
NonStopOnError=1

Documentação da chave: https://tdn.totvs.com.br/pages/viewpage.action?pageId=952668268

Referente ao chamado: DTAPPSRV-8899

Situação:  implementação da nova função unixms2dt(), que recebe como parâmetro um timestamp Unix (número de segundos desde 01.01.1970) e retorna a data e hora correspondente como um tipo caractere AdvPL , no formato "AAAAMMDD hh:mm:ss.fff".

Mais detalhes: UnixMS2DT

Referente ao chamado: DTAPPSRV-7411

Situação: com a possível migração de ambientes para containers, torna-se necessário detectar se a aplicação está rodando em um container e identificar se existem limitações de hardware (memória, CPU, processos, etc.).

Solução: foi adicionada uma classe para detectar se a aplicação está sendo executada em um container, identificar o tipo do container, coletar e exibir suas configurações e limitações.

Mais detalhes: ContainerInfo

Referente ao chamado: DTAPPSRV-8620