Quando ativado, este flag dispara a geração de logs extensos, que podem comprometer o desempenho geral do backend (camada Progress, tanto Client como Appserver/PASOE).

Recomenda-se manter desativado. Somente ativar casos de exceção, mediante alinhamento com a consultoria/suporte.

Em um editor Progress conectado aos bancos de dados:

Para consultar:

output to c:\temp\log_gera_log_exec.txt.
FOR EACH prog_dtsul no-lock:
    IF prog_dtsul.log_gera_log_exec THEN do:
         export prog_dtsul.
    end.
END.
output close.

Para desativar:

FOR EACH prog_dtsul exclusive-lock:
    IF prog_dtsul.log_gera_log_exec THEN do:
         assign prog_dtsul.log_gera_log_exec = false.
    end.
END.

Este processo é um Garbage Collector.

Ele realiza a limpeza da memória dos agentes do Appserver/PASOE ao final de cada requisição, retirando objetos sem uso, evitando locks, travamentos e sobrecarga de recursos do servidor.

Valor correto (ubroker.properties / Progress Admin Services):

    operatingMode=State-reset

Windows

Definir junto às variáveis de ambiente do sistema.

Ex: JAVA_HOME=c:\Java\jdk-11.0.11

Linux

No Linux cada distro pode possuir particularidades, mas de modo geral as variáveis de ambiente são definidas no arquivo /etc/environment.

Ex: 

JAVA_HOME="/usr/lib/jvm/java-11-openjdk-11.0.14.0.9-1.el7_9.x86_64"

Resumo dos parâmetros mais impactantes:

-l 50000
-mmax 50000
-s 20000
-Bt 32000
-tmpbsize 8
-q

Mais detalhes aqui: https://centraldeatendimento.totvs.com/hc/pt-br/articles/360034643513-Framework-Linha-Datasul-TEC-Configura%C3%A7%C3%A3o-do-Appserver-Progress-para-o-Datasul-for-THF

No arquivo.pf de conexão aos bancos de dados, garantir que exista esta linha:

-q

Tamanho dos logs do Appserver (apenas Progress 11)

Para Progress 12, consulte o item 14.

Muitas vezes o log do Appserver está muito grande (Gigabites), causando alto consumo de I-O, e deteriorando a performance geral do sistema.

Recomenda-se limitar o tamanho máximo de um log de Appserver em 15MB.

Essa mesma técnica pode ser aplicada para o clientlog de sessões Client Progress e RPW.

Atenção também para sempre apontar a geração do arquivo para o disco do mesmo servidor onde o Appserver/PASOE é executado, e não para caminhos de rede, o que pode comprometer o desempenho.

https://knowledgebase.progress.com/articles/Article/000051593

Quando os usuários abrem diversas telas do sistema e esquecem de encerrá-las ao concluírem sua atividade, os recursos do Sistema Operacional (processamento, memória, banco de dados) continuam alocados desnecessariamente.

É importante configurar o Timeout para que as sessões sejam encerradas automaticamente após determinado tempo de inatividade, evitando sobrecarga de recursos.

CFG - Segurança#Timeout

Podem ser adotadas duas abordagens:

1. Configurar timeout curto (ex: 20 a 30 minutos) e criar um Grupo de Exceção do Timeout (conforme doc do link acima) para colocar apenas os usuários que utilizam processos mais pesados e que nunca devem sofrer timeout.
   • É importante ter em mente que os usuários do grupo de Exceção NUNCA terão sua sessão encerrada automaticamente. Isso abre margem para telas serem "esquecidas" abertas, consumindo sessões e gerando locks no banco de dados por vários dias.
     
     
2. Não criar grupo de exceção. Levantar qual é o processo mais pesado na rotina do cliente e configurar o Timeout proporcional, com alguma sobra. Exemplo: se o processo mais pesado demora 4 horas, então configurar o timeout para 5 horas (300 minutos).
   • É importante sempre executar processos pesados em RPW, e não na estação do usuário. 
   • Em caso de dúvida, recomenda-se acionar o suporte questionando pela versão em RPW para o processo em questão, e caso não exista, que seja solicitada sua implementação.

Obs: O timeout se aplica apenas para telas abertas na estação do usuário. Já os processos RPW não são afetados por este controle de timeout.

A instalação default do Tomcat prevê a utilização de diversos recursos que não são necessários para o Datasul.

As recomendações deste artigo reduzem consideravelmente o volume de processamento, consumo de recursos e tempo de carga da instância do Tomcat com Datasul

Os diversos aspectos relacionados à gestão dos servidores, inclusive o espaço em disco, são de responsabilidade da infraestrutura do cliente e/ou consultoria de infraestrutura contratada.

Ainda assim, para prevenir esgotamento de disco, algumas orientações úteis podem ser passadas ao cliente:

• eventualmente eliminar arquivos temporários (por exemplo, durante a aplicação de um patch, aproveitando o momento em que o serviço está desligado):
  • Datasul
    • instancia-tomcat/logs
    • instancia-tomcat/temp
    • instancia-tomcat/work
  • Autorizador Web e Foundation Saúde
    • instancia-jboss/log
    • instancia-jboss/data
    • instancia-jboss/tmp
    • instancia-jboss/work

Alguns ofensores conhecidos que podem gerar volume considerável de arquivos na pasta temp:

• Geração de boletos
• Geração de relatórios
• Arquivos que ficam disponíveis para download dos usuários

Cada cliente pode definir sua política de governança dos servidores.

Recomenda-se utilizar serviços de agendamento/cron para realizar o saneamento de arquivos antigos / temporários / desnecessários e garantir que o disco nunca fique esgotado, pois isso ocasionará parada do sistema.

Assim como qualquer programa Progress enviado ao cliente de forma "avulsa", um arquivo.war também corre riscos de desestabilização de processos.

Quando ocorrer esta necessidade, sempre ter em mente:

• O arquivo.war pode fazer chamadas ao backend com parâmetros pré-definidos. Se algum parâmetro estiver diferente, causará falha de comunicação.
• O arquivo.war pode conter diversas aplicações. Logo, ao enviar o arquivo para contorno de um problema em específico, outras aplicações podem ser afetadas como efeito colateral.
  • Nestes casos, ao invés de realizar o build do .war e enviá-lo ao cliente, pode ser mais prudente baixar o .war que o cliente já possui (patch), editá-lo apenas com a alteração necessária, zipar novamente e enviar este resultado, para minimizar impactos.

Há processos que rodam na camada Progress que fazem chamada a apis do Java via Sistema Operacional, que por sua vez consomem um serviço OpenOffice que precisa estar sempre disponível e visível na rede, tanto para o servidor do PASOE como para as estações finais.

• Ex: conversão de arquivos RTF para PDF.

Quando este serviço não estiver no ar, os processos ficarão travados, segurando sessões do PASOE, podendo causar lentidão, esgotamento de recursos e travamentos perceptíveis ao usuário final.

Diferente do AppServer do Progress 11, no PASOE do Progress 12 não existe configuração nativa para quebra automática dos logs baseado no tamanho dos arquivos.

Para contornar, siga as orientações do artigo ao lado.

progress.server.maxconnections=10 

Obs: Tanto Appserver como Jboss devem ser reiniciados caso algum dos parâmetros seja alterado.

Referência: Documentação "datasul_framework.properties" 

Se não estiver corretamente configurado, este parâmetro pode limitar o tamanho da mensagem trafegada no Foundation Saúde, interrompendo a comunicação.

Exemplo de problema frequente: guias trafegando normalmente quando tiverem até 6 procedimentos, e começarem a falhar quando tiver mais que 6 procedimentos.

Dica: se hoje esta configuração não estiver preenchida, e não estão sendo observados problemas, significa que a limitação default (2MB) é suficiente. Para evitar o risco de configurar com "-1" e receber anexos muito grandes, que possam comprometer o processo, o parâmetro pode ser configurado com uma certa margem (ex: 4 ou 8MB).

Mais informações: https://docs.jboss.org/jbossweb/7.0.x/config/http.html

Este processo realiza a limpeza da memória dos agentes do Appserver/PASOE ao final de cada requisição, evitando locks, travamentos e sobrecarga de recursos.

A mudança de tecnologia do Progress 11 para 12 exigiu ajustes em libs de comunicação entre as camadas.

Atenção especial para o artefato datasul-saude-connection-progress-11.5.9.jar (.../jboss/server/default/lib). Se a sua versão for anterior a 20/10/2023, atualize imediatamente, sob risco de alocação total das sessões do PASOE, gerando travamento do sistema, que só se resolve com reinicialização, e o problema torna a ocorrer em pouco tempo.

Dependendo do volume de acessos e requisições, o pool dimensionado pode ser insuficiente, gerando erros no log do Jboss e recusando as transações. Neste caso recomenda-se aumentar o valor.

Nos arquivos progress-ds.xml (para clientes com banco Progress), oracle-ds.xml (para clientes com banco Oracle) e erp-ds.xml, que ficam na instalação do Jboss/server/default/deploy, revisar a tag <max-pool-size>. 

Exemplo:

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
   <local-tx-datasource>
    <jndi-name>FoundationAutorizadorDS</jndi-name> 
      <connection-url>jdbc:datadirect:openedge://<SERVIDOR>:<PORTA>;databaseName=fndsau;WorkArounds=536870912</connection-url>
      <driver-class>com.ddtek.jdbc.openedge.OpenEdgeDriver</driver-class>
      <user-name>fndsau</user-name>
      <password>fndsau</password>
        <metadata>
            <type-mapping>Progress</type-mapping>
        </metadata>
        <min-pool-size>1</min-pool-size>
        <max-pool-size>30</max-pool-size>
   </local-tx-datasource>

   </datasources>

Atenção com o dimensionamento das Licenças Progress

A mudança do AppServer clássico para o PASOE não é trivial, especialmente no novo comportamento dos Agentes, que passam a ser multi-thread.

No AppServer clássico cada agente consome 1 licença Progress, executando as requisições de modo single-thread (fila).

Logo, se você tem 10 licenças, vai usar 10 agentes.

No PASOE o agente passa a ser um controlador de múltiplas sessões. Cada sessão por sua vez passa a consumir uma licença, e podem ser executadas de forma paralela (multi-thread).

Logo, se você tem 10 licenças, vai usar 1 agente com 10 sessões; ou 2 agentes com 5 sessões; etc.

Pode parecer lógico o seguinte raciocínio: se eu tinha 10 agentes no AppServer, terei 10 agentes no PASOE. Mas

essa não é

a melhor abordagem.

O melhor desempenho (e consumo mais otimizado de hardware) é observado utilizando apenas 1 agente com o máximo de sessões (licenças) disponíveis.

Escalonamento automático de agentes

Este ponto pode gerar dúvidas comuns.

A tela de configuração do PASOE não impede o usuário de preencher com parâmetros conflitantes, que irão gerar mau funcionamento.

Relação entre Sessões e Conexões

Este é um novo controle criado no PASOE, e pode gerar dúvidas.

Proteteção contra loops infinitos

Em caso de falha de um processo, é preferível que a sessão encerre automaticamente e volte a ficar disponível no pool, ao invés de ficar presa, sob risco de esgotamento de recursos

e parada total do sistema.

Desativar monitoramento de alterações de dicionário

À partir do Progress 12 o monitoramento de alterações de dicionário é ligado por default (roda a cada 30 segundos), enquanto era desligado no Progress 11. Com isso, percebe-se um certo delay nas conexões.

Visto que o produto Datasul não sofre alterações de dicionário com o produto no ar, apenas em janelas de atualização programadas, faz sentido desativar este monitoramento para incrementar performance e reduzir mensagens nos logs.

Desligamento automático de Sessões e Agentes ociosos

Por default, os timeouts ficam desativados, e com isso as Sessões e Agentes ociosos não são derrubados automaticamente. Ficam consumindo recursos sem necessidade.

Derrubar uma sessão do agente multi-thread do PASOE sem afetar as demais sessões em andamento

No AppServer clássico (1 agente por sessão) o PID de um processo travado pode ser derrubado pelo sistema operacional sem afetar as demais sessões.

 já no PASOE, por ser multi-thread, se o PID de um agente for derrubado, todas as sessões que ele administra serão afetadas, tornando inviável este procedimento.