PASOE no Datasul: arquitetura, serviços e pontos de atenção

Em ambientes Datasul baseados em versões modernas do Progress OpenEdge, o PASOE passou a ter um papel importante na execução de aplicações e serviços ABL.

PASOE é a sigla normalmente utilizada para Progress Application Server for OpenEdge, também denominado PAS for OpenEdge na documentação atual do fabricante.

Mais do que um servidor para APIs REST, ele é uma plataforma de execução de aplicações OpenEdge baseada em arquitetura web e preparada para atender diferentes tipos de clientes e serviços.

Entender esse papel ajuda equipes técnicas a analisar integrações, performance, disponibilidade, segurança e a própria arquitetura do ambiente Datasul.

Qual é o papel do PASOE em ambientes Datasul?

No contexto de ambientes Datasul utilizando OpenEdge 12, a TOTVS passou a utilizar PASOE como serviço de aplicação.

Isso representa uma mudança importante em relação às arquiteturas antigas baseadas no AppServer tradicional.

O PASOE executa aplicações ABL e fornece a infraestrutura necessária para que diferentes tipos de clientes e serviços acessem essas aplicações.

PASOE não é apenas um servidor REST

É comum associar PASOE diretamente a APIs porque REST é um dos usos mais visíveis da plataforma.

Entretanto, a arquitetura suporta diferentes formas de comunicação com aplicações ABL.

Dependendo da aplicação e da configuração do ambiente, podem existir transports destinados a diferentes tipos de acesso, incluindo clientes ABL/Open Client, REST, SOAP e aplicações web.

Por isso, analisar PASOE somente pela perspectiva de uma API pode esconder parte importante da arquitetura.

Aplicações ABL ficam organizadas dentro do servidor

O PASOE pode hospedar aplicações ABL responsáveis por executar código Progress/OpenEdge.

Essas aplicações possuem configuração própria e podem atender diferentes tipos de requisição conforme os transports habilitados.

Essa separação permite estruturar aplicações e serviços de acordo com as necessidades do ambiente, em vez de tratar todo o servidor como um único processo monolítico.

O que são transports?

Transports são mecanismos pelos quais diferentes clientes acessam aplicações disponibilizadas no PASOE.

Na documentação Progress, existem transports destinados a cenários como:

• clientes ABL e Open Client;
• serviços REST;
• serviços SOAP;
• requisições web e WebHandlers.

Quais transports serão utilizados depende da aplicação implantada e da arquitetura definida para o ambiente.

Agents e ABL sessions

Um conceito importante na arquitetura do PASOE é o uso de agents capazes de executar múltiplas sessões ABL.

Em vez de imaginar que cada requisição cria um servidor independente, é mais adequado pensar em uma estrutura que administra recursos de execução e distribui solicitações entre sessões disponíveis.

Esses recursos possuem limites e configurações que influenciam concorrência, consumo e capacidade do ambiente.

Por que dimensionamento importa?

Quantidade de usuários ou chamadas não é o único fator relevante para dimensionar PASOE.

Também é necessário considerar características como:

• quantidade de requisições simultâneas;
• duração das operações;
• consumo das sessões;
• volume de integrações;
• picos de utilização;
• dependências de banco de dados;
• processamentos executados pelo código ABL.

Não existe um número universal de agents ou sessões adequado para todos os ambientes.

Dimensionamento deve ser baseado no comportamento real da aplicação e em métricas observáveis.

Mais sessões nem sempre significam mais performance

Aumentar limites sem observar os recursos disponíveis pode apenas transferir o gargalo.

Banco de dados, CPU, memória, operações externas e o próprio código executado podem limitar o desempenho antes do servidor de aplicação.

Por isso, ajustes de capacidade devem ser feitos considerando o ambiente completo.

Monitoramento precisa ir além de saber se o serviço está no ar

Um PASOE pode estar executando e ainda assim apresentar lentidão, filas, sessões ocupadas ou solicitações de longa duração.

A plataforma disponibiliza informações administrativas que permitem observar agents, sessões, conexões e requisições.

Métricas desse tipo ajudam a diferenciar indisponibilidade de problemas de capacidade ou comportamento da aplicação.

Investigue antes de reiniciar

Reiniciar um serviço pode remover temporariamente um sintoma sem explicar sua causa.

Quando o problema é recorrente, é importante analisar informações disponíveis no momento da ocorrência, como sessões, consumo, solicitações, logs e dependências externas.

Isso ajuda a identificar se a origem está no servidor de aplicação, no código ABL, no banco, em uma integração ou em outro componente.

Segurança de desenvolvimento e produção não deve ser tratada da mesma forma

Ambientes de desenvolvimento normalmente possuem necessidades diferentes de um servidor exposto a usuários e aplicações em produção.

Em produção, autenticação, autorização, TLS, administração remota, permissões e exposição de endpoints precisam ser avaliados explicitamente.

Uma configuração conveniente para desenvolvimento não deve ser transportada automaticamente para produção.

Serviços publicados precisam ser protegidos

Uma API tecnicamente funcional não está necessariamente pronta para produção.

Antes de publicar um serviço, é necessário avaliar quem poderá acessá-lo, quais operações estarão disponíveis e como as credenciais e comunicações serão protegidas.

Também é importante limitar a exposição de interfaces administrativas.

Deploy também faz parte da arquitetura

Aplicações e serviços executados no PASOE precisam ser implantados de forma controlada.

O processo deve considerar componentes ABL, configurações, dependências e o impacto da atualização sobre aplicações já em execução.

Em ambientes empresariais, homologação e procedimentos de implantação são importantes para reduzir mudanças não controladas.

PASOE e APIs REST

PASOE fornece infraestrutura para disponibilizar serviços REST conectados a aplicações ABL.

Isso permite que aplicações externas, portais, sistemas satélites e outras soluções se comuniquem com serviços desenvolvidos no ecossistema OpenEdge.

Entretanto, a existência dessa infraestrutura não significa que qualquer rotina Datasul automaticamente possua uma API REST.

É necessário avaliar as interfaces disponibilizadas pelo produto e as necessidades específicas do processo.

Veja também nosso artigo API padrão Datasul ou serviço específico: como escolher a melhor abordagem?.

WebHandlers ampliam possibilidades de aplicações web

A arquitetura web do PASOE também permite desenvolver tratamentos HTTP utilizando recursos OpenEdge específicos para aplicações web.

Esses recursos podem ser utilizados quando existe necessidade técnica compatível com esse modelo.

A escolha entre transports e formas de exposição deve partir do processo e da arquitetura, não apenas da tecnologia disponível.

O código ABL continua sendo parte central

PASOE fornece o ambiente de execução, mas o comportamento da aplicação continua dependendo do código ABL, das regras implementadas e das dependências utilizadas.

Problemas de performance ou estabilidade não devem ser atribuídos automaticamente ao servidor de aplicação.

Consultas, lógica de negócio, integrações e acesso ao banco também precisam ser analisados.

PASOE e Progress OpenEdge precisam ser observados em conjunto

O servidor de aplicação faz parte de uma arquitetura maior.

Banco de dados, aplicações ABL, serviços, rede, sistemas integrados e infraestrutura participam do comportamento percebido pelo usuário.

Uma análise eficiente precisa correlacionar esses componentes.

Quando revisar a arquitetura PASOE?

Alguns sinais podem justificar uma análise mais detalhada:

• lentidão recorrente;
• sessões constantemente ocupadas;
• integrações acumulando requisições;
• timeouts;
• consumo inesperado de recursos;
• necessidade frequente de reiniciar serviços;
• crescimento significativo no volume de uso;
• novas APIs ou aplicações sendo incorporadas ao ambiente.

Esses sinais não provam que o PASOE seja a causa do problema, mas indicam que a camada deve participar do diagnóstico.

Evite tuning sem evidência

Alterar parâmetros de agents, sessões e conexões apenas com base em valores utilizados por outra empresa pode produzir resultados inadequados.

Cada ambiente possui perfil de carga, infraestrutura e aplicações diferentes.

Coletar métricas e entender o comportamento real é uma abordagem mais segura do que aumentar limites indiscriminadamente.

PASOE também merece entrar no inventário técnico do ambiente

Em projetos de atualização, integração ou diagnóstico, é importante conhecer como o PASOE está estruturado.

Informações como aplicações configuradas, transports utilizados, dependências, padrões de utilização e integrações ajudam a entender impactos antes de mudanças.

Veja também nosso serviço de Atualização Datasul.

Onde a DATA IT atua nesse cenário?

A DATA IT trabalha com Progress OpenEdge, ABL, customizações, serviços e integrações conectados ao ambiente Datasul.

A atuação pode envolver análise técnica, desenvolvimento, revisão de componentes, integração e apoio em diagnóstico conforme o cenário do cliente.

Conheça nosso serviço de Desenvolvimento Progress OpenEdge e ABL para Datasul.

Precisa integrar aplicações ao seu ambiente Datasul?

Para projetos envolvendo APIs e sistemas satélites, conheça também nosso serviço de Integrações Datasul e APIs.

Fale com nosso time para avaliar seu cenário.