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

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.

Cada conexão a um banco de dados no Oracle consome uma sessão, que fica aberta durante todo o escopo do programa.

Isto se aplica tanto para usuários que abrem tela GUI (tela Progress) como Agentes de Appserver.

Exemplos:

• Se o Datasul está configurado com 10 bancos e tivermos 10 usuários conectados, isso se reflete em 100 sessões.
• Se somarmos à configuração acima mais 10 agentes de Appserver, chegaremos a 200 sessões.
• Se um usuário já tem uma sessão em aberto, e ele abrir mais uma sem fechar a anterior, chegaremos a 210 sessões.

Portanto, o número sugerido neste parâmetro é uma configuração que se aplica à grande maioria dos casos, mas deve ser bem dimensionado com clientes com muitos usuários e agentes de Appserver.

Executar em uma sessão conectada ao banco de dados Oracle, com privilégios de administrador:

select * from v$parameter p where p.name in ('open_cursors','processes','sessions')

Se o resultado for inferior a:

open_cursors: 30000
processes: 4000
sessions: 6024

Então os referidos parâmetros devem ser ajustados para esses valores, com os seguintes comandos:

alter system set open_cursors=30000 scope=both sid='*';
alter system set processes=4000 scope=spfile;
alter system set sessions=6024 scope=spfile;

Obs: o listener do Oracle deve ser reiniciado para que as  alterações tenham efeito.

Detalhes no item 28 do guia de instalação: Tutorial_de_Instalação_do_TOTVS_12_Oracle

No arquivo.pf de conexão aos bancos de dados, conferir o valor do parâmetro -c, que não deve ser inferior a:

-c 10000

Exemplo da linha completa:

-db \\cxs-gcad-rep01\schemaholder\shemsfnd -ld shemsfnd -RO -db emsfnd -ld emsfnd -U susemsfnd/susemsfnd@squad -c 10000 

Atenção para refletir os ajustes de .pf também na tabela EMSFND.BCO_EMPRES

Caso este erro se manifeste: https://community.progress.com/s/article/19074

Recomendamos reportar ao nosso canal de suporte, e adotar o seguinte paliativo:

• Desativar a variável de ambiente NLS_LANG no seu Sistema Operacional.

Detalhes: https://community.progress.com/s/article/Error-6447-when-NLS-LANG-environment-variable-is-set

progress.server.mode=1 

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.

Em situações com apenas 1 ou 2 processadores, já presenciamos o cenário de o cliente possuir diversos agentes de Appserver, mas a CPU não dar conta de executar processos em paralelo.

Como efeito, 2 a 3 agentes acabam consumindo 100% de CPU, causando enfileiramento das atividades, e lentidão na percepção do usuário.

Recomenda-se que um servidor de Produção tenha ao menos 16 processadores.

Se o cliente possui aplicações próprias que consomem o Datasul via REST:

• avaliar utilização do recurso de Broker Escalável
  
  
• se o consumo for muito alto, considerar a utilização de um Tomcat dedicado

Exemplo com Broker Escalável

Digamos que o cliente possui no seu portal uma funcionalidade para os seus clientes Pessoa Física solicitarem a geração da 2a via de boletos, e que o vencimento é no dia 10 de cada mês.

Isso abre margem para um pico de utilização deste recurso próximo à data de vencimento.

Se a chamada desta customização estiver compartilhando o mesmo Appserver/PASOE do menu do Datasul, poderá ser percebida lentidão/travamento/indisponibilidade do sistema nos momentos de pico.

Com o Broker Escalável, configura-se um Appserver/PASOE dedicado para a customização, sem comprometer o restante da operação.

Exemplo com Tomcat Dedicado

Seguindo o mesmo exemplo acima, digamos que há um momento de pico de utilização que está comprometendo a resposta do Tomcat do Datasul (menu interno, Portal Empresa, Auditoria Médica, etc). Isso pode caracterizar a necessidade de criação de uma instância do Tomcat dedicada apenas para as customizações do cliente. 

Para consultar as triggers do GPS:

output to c:\temp\dztriggers.txt.
FOR EACH dztriggers no-lock:
         export dztriggers.
END.
output close.

Para consultar as triggers do ERP:

output to c:\temp\tab_dic_dtsul.txt.
FOR EACH tab_dic_dtsul no-lock:
         export tab_dic_dtsul.
END.
output close.

Mais detalhes sobre o procedimento de configuração e ativação de triggers: Instruções_de_Atualização_Versão_GPS

O Tomcat gera diversos logs, cada um com objetivos diferentes.

A nível de regra de negócio do Datasul, destaca-se o catalina.AAAA-MM-DD.log.

Deploy

Este log mostra se cada arquivo.war (pasta webapps) foi corretamente carregado na memória do sevidor (deploy) ou se ocorreram erros que impediram o deploy.

Os erros mais comuns são:

• Falta de espaço em disco
• Arquivo.war está corrompido

Negócio

Neste mesmo log pode-se identificar as requisições realizadas pela camada de tela (Frontend) ao Appserver/PASOE (backend). Ex:

14-Apr-2023 17:11:16.225 INFO [datasul-exec-404] com.totvs.framework.rest.connector.APIDatasulConnector.processRequest TOTVS-REST API-DATASUL: Conectando appserver
14-Apr-2023 17:11:16.225 INFO [datasul-exec-404] com.totvs.framework.progress.connector.ProgressConnectionManager.getConnection Buscando conexao atual. companyId=120, userName=super, xTotvsApp=, xTotvsAlias=null, dbHistId=null, programName=hpr/api/v1/modalities, programType=api, appServer=null
14-Apr-2023 17:11:16.225 INFO [datasul-exec-404] com.totvs.framework.progress.connector.ProgressConnectionManager.createConnection TOTVS-PROGRESS: Builded URL connection: http://cxs-squad-sus01:8825/apsv
14-Apr-2023 17:11:16.225 INFO [datasul-exec-404] com.totvs.framework.progress.connector.ProgressConnectionManager.getConnection Realizada conexao em (0ms)
14-Apr-2023 17:11:16.241 INFO [datasul-exec-404] com.totvs.framework.progress.connector.ProgressConnectionManager.getConnection Iniciando autenticacao
14-Apr-2023 17:11:16.304 INFO [datasul-exec-404] com.totvs.framework.progress.connector.ProgressConnectionManager.authenticate Registrou log de execucao em: 16 ms 
14-Apr-2023 17:11:16.304 INFO [datasul-exec-404] com.totvs.framework.progress.connector.ProgressConnectionManager.getConnection Autenticado em: (63ms)
14-Apr-2023 17:11:16.304 INFO [datasul-exec-404] com.totvs.framework.rest.connector.APIDatasulConnector.callProgressProgram Executado o programa progress : hpr/api/v1/modalities
14-Apr-2023 17:11:16.366 INFO [datasul-exec-404] com.totvs.framework.rest.connector.APIDatasulConnector.callProgressProgram Retorno do JSON do programa Progress: hpr/api/v1/modalities
14-Apr-2023 17:11:16.382 INFO [datasul-exec-404] com.totvs.framework.rest.connector.APIDatasulConnector.processRequest TOTVS-REST API-DATASUL: Retorno em (157ms)

Appserver/PASOE

No log do Appserver/PASOE é possível cruzar o trecho de log acima (frontend) com o backend que foi chamado:

2023-04-14T17:11:16.288-0300 020972 050324 2 AS-27 ?:?:? 4GLTRACE       Run utp/ut-logexecapi.p "hpr/api/v1/modalities api" [registerLogExec - fwk/rest/authProgressApp.p @ 998]
2023-04-14T17:11:16.304-0300 020972 050324 2 AS-27 ?:?:? FILEID         Open \\cxs-gcad-rep01\progress_repository\11-5-X-PROGRESS_12\FOUNDATION\utp\ut-logexecapi.r ID=595
2023-04-14T17:11:16.304-0300 020972 050324 2 AS-27 ?:?:? FILEID         Close \\cxs-gcad-rep01\progress_repository\11-5-X-PROGRESS_12\FOUNDATION\utp\ut-logexecapi.r ID=595
2023-04-14T17:11:16.304-0300 020972 050324 3 AS-27 ?:?:? 4GLTRACE       Return from Main Block [utp/ut-logexecapi.p]
2023-04-14T17:11:16.304-0300 020972 050324 3 AS-27 ?:?:? 4GLTRACE       Return from registerLogExec [fwk/rest/authProgressApp.p]
2023-04-14T17:11:16.304-0300 020972 050324 3 AS-27 ?:?:? AS -- TRACE: Internal Procedure (Proxy 2) END SUCCESS.
2023-04-14T17:11:16.304-0300 020972 050324 4 AS-27 ?:?:? AS -- TRACE: cso4GL: In execProc() - successful execution. (8458)
2023-04-14T17:11:16.304-0300 020972 050324 4 AS-27 ?:?:? AS -- TRACE: cso4GL: In execCall() - execProc() success. (8458)
2023-04-14T17:11:16.304-0300 020972 032564 3 AS-27 ?:?:? AS -- TRACE: PERSISTENT Procedure 'hpr/api/v1/modalities' START (Proxy 3).
2023-04-14T17:11:16.304-0300 020972 032564 2 AS-27 ?:?:? FILEID         Open \\cxs-gcad-rep01\progress_repository\11-5-X-PROGRESS_12\GESTAO-PLANOS\hpr\api\v1\modalities.r ID=595
2023-04-14T17:11:16.319-0300 020972 032564 2 AS-27 ?:?:? FILEID         Close \\cxs-gcad-rep01\progress_repository\11-5-X-PROGRESS_12\GESTAO-PLANOS\hpr\api\v1\modalities.r ID=595
2023-04-14T17:11:16.319-0300 020972 032564 4 AS-27 ?:?:? AS -- TRACE: cso4GL: In execProc() - before execution. (8458)
2023-04-14T17:11:16.319-0300 020972 032564 2 AS-27 ?:?:? 4GLTRACE       Run mycast [Main Block - hpr/api/v1/modalities @ 69]
2023-04-14T17:11:16.319-0300 020972 032564 3 AS-27 ?:?:? 4GLTRACE       Return from myCast [hpr/api/v1/modalities]
2023-04-14T17:11:16.319-0300 020972 032564 2 AS-27 ?:?:? 4GLTRACE       Run fwk/auth/endpointSecurityServices.p PERSIST [Main Block - hpr/api/v1/modalities @ 76]
2023-04-14T17:11:16.319-0300 020972 032564 2 AS-27 ?:?:? FILEID         Open \\cxs-gcad-rep01\progress_repository\11-5-X-PROGRESS_12\FOUNDATION\fwk\auth\endpointSecurityServices.r ID=595
2023-04-14T17:11:16.319-0300 020972 032564 2 AS-27 ?:?:? FILEID         Close \\cxs-gcad-rep01\progress_repository\11-5-X-PROGRESS_12\FOUNDATION\fwk\auth\endpointSecurityServices.r ID=595
2023-04-14T17:11:16.319-0300 020972 032564 3 AS-27 ?:?:? 4GLTRACE       Return from Main Block [fwk/auth/endpointSecurityServices.p]
2023-04-14T17:11:16.319-0300 020972 032564 2 AS-27 ?:?:? 4GLTRACE       Run verifyEndpointAccess2 in fwk/auth/endpointSecurityServices.p "/dts/datasul-rest/resources/prg/hpr/v1/modalities/" [Main Block - hpr/api/v1/modalities @ 78]
2023-04-14T17:11:16.319-0300 020972 032564 3 AS-27 ?:?:? 4GLTRACE       Return from verifyEndpointAccess2 "yes" [fwk/auth/endpointSecurityServices.p]

Por default um Client/Agent Progress aguarda 30 minutos (1800 segundos) quando tenta acessar um registro que já está em lock.

Para o caso de uma tela Client em que o usuário está interagindo isso não é um grande problema, visto que é apresentada uma mensagem perguntando se o usuário deseja aguardar ou cancelar a operação. Essa tela cancela a operação automaticamente se os 30 minutos se passarem sem interação do usuário.

Já para um Agent do Appserver isso pode ser um transtorno, visto que o processo fica em lock mas não há feedback ao usuário, que fica com sensação de "tela lenta/travada" quando na verdade o agent está aguardando a liberação de um registro preso por outra transação. Isso pode induzir o usuário a abrir nova tela e tentar novamente, e isso sucessivamente vai prendendo mais agentes, correndo o risco de todos ficarem presos até que o timeout seja atingido em cada sessão. E neste período, todos os usuários ficam com sensação de "sistema caiu/indisponível". Para este cenário, pode ser útil reduzir este timeout para algo entre 1 e 5 minutos.

Importante: caso haja alguma aplicação gerando um lock indevido, esta configuração não resolve o problema. Ela apenas ameniza o impacto aos demais usuários e processos enquanto o lock é investigado, reduzindo a chance de todos os agentes ficarem presos e o sistema completamente indisponível.

Parâmetro no arquivo.pf de conexão:

-lkwtmo

https://community.progress.com/s/article/16073

O sistema possui alguns processos de importação de dados que podem ser pesados e executarem por várias horas.

É importante alinhar com a área de negócio sobre a possibilidade de estes processos serem executados à noite via RPW, e também para utilizar processo de Importação Parcial (quando disponível). Com isso, o processo utilizará muitas transações pequenas ao invés de uma única transação grande, reduzindo consideravelmente o tempo de processamento e efeitos colaterais em outros processos, devido aos locks no banco de dados.

Um exemplo deste tipo de processo é a Importação de A500 XML.

Como funcionam as Licenças Progress

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.

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

É importante frisar que o melhor desempenho (e consumo mais otimizado de hardware) é observado utilizando apenas 1 agente com o máximo de sessões disponíveis.

Detalhes: 

https://docs.progress.com/pt-BR/bundle/pas-for-openedge-management/page/Configure-OpenEdge-properties.html

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 configurações conflitantes, que irão gerar mau funcionamento.