📒 Guia Estratégico e Arquitetura da Automação

Este documento detalha as escolhas técnicas e o funcionamento estratégico da automação desenvolvida para o Portal Viventeris (Cassems), explicando "o porquê" de cada decisão.

🏗️ 1. Arquitetura: Por que Playwright e não Axios?

Ao desenvolver automações para portais de saúde (TISS/SADT), escolhemos o Playwright em vez de ferramentas de requisição direta como o Axios. Aqui está a justificativa:

Playwright (Navegador Real) - Nossa Escolha

Simulação Humana: Ele carrega o JavaScript do portal, processa pop-ups e lida com o "autocomplete" do jQuery UI (essencial para que o sistema valide o procedimento).
Gestão de Sessão: O portal Viventeris possui tokens de segurança e cookies expiráveis. O navegador gerencia isso automaticamente.
Resiliência Visual: Se o portal mudar a posição de um campo, a automação baseada em id ou label continua funcionando.
Monitoramento: Você pode ver o navegador trabalhando, o que facilita identificar se o sistema da Cassems está lento ou fora do ar.

Axios/API (Requisições Ocultas) - Descartado

Extrema Complexidade: Exigiria descobrir todos os "requests" ocultos que o servidor espera.
Fragilidade: Qualquer mudança na segurança do servidor quebraria a integração sem deixar rastro visual.
Bloqueios: Sistemas modernos de saúde detectam requisições "secas" (sem navegador) e bloqueiam o acesso por suspeita de ataque.

🧠 2. Inteligência do Fluxo (Regras de Negócio)

O script foi treinado para seguir regras específicas de UX do portal:

Regra de Urgência:
- O sistema monitora o select #tipoAtendimento.
- Se selecionado Urgência (ID 4), ele obrigatoriamente preenche a Justificativa.
- Se selecionado Eletivo (ID 1), ele pula o campo para evitar erros de validação.
Lógica do Autocomplete:
- Digitar o código do procedimento não é suficiente. O script foi programado para clicar no item da lista suspensa que o sistema sugere. Sem esse clique, o sistema muitas vezes "limpa" o campo ao tentar avançar.
Superação de Sobreposição:
- No campo de Faces (V, M, D, L/P), o script utiliza cliques forçados nas labels, pois os checkboxes originais são ocultados por CSS de design do portal.

🛠️ 3. Manutenção e Boas Práticas

Como manter o código funcionando:

IDs Estáveis: Sempre que possível, usamos o id (ex: #cmbDente). Se o portal mudar o layout, mas mantiver os IDs, o código não quebra.
Timeouts: Configuramos esperas inteligentes. O script não trava se a internet oscilar por 2 segundos; ele aguarda o elemento aparecer.

Segurança dos Dados:

Credenciais: Atualmente fixas no código para testes. Em produção, recomenda-se usar variáveis de ambiente ou um arquivo de configuração externo.
Breakpoint de Erro: O código possui a função catch. Se algo der errado (ex: beneficiário bloqueado), o script para tudo, tira um print da tela (erro-guia-odonto.png) e mantém o navegador aberto para você ver o motivo.

🛠️ 4. Infraestrutura Atual (VM Windows)

Como estamos operando dentro de uma Máquina Virtual, optamos pela instalação nativa para garantir performance e estabilidade:

Recurso	Status	Host:Porta	Credenciais	Gerenciamento
MySQL (9.6)	Ativo (Serviço)	`localhost:3306`	User: `root` / Pass: (vazio)	MySQL CLI / DBeaver
Redis (8.6)	Ativo (PM2)	`localhost:6379`	s/ senha	`pm2 monit` / `redis-cli`
Python (3.14)	Ativo	-	-	`python --version`
PM2	Ativo	-	-	`pm2 list`

Comandos de Manutenção:

Verificar Redis: pm2 list ou redis-cli ping
Verificar MySQL: Get-Service MySQL
Logs do Redis: pm2 logs redis-server

📋 5. Comandos Úteis

Objetivo	Comando
Instalar Dependências	`npm install`
Rodar Lançamento	`node lancar-guia-odonto.js`
Verificar Versão Node	`node -v`
Logs do Processo	`pm2 logs`

Conclusão: Esta automação transforma um processo de 5 minutos de cliques manuais em uma tarefa de 20 segundos totalmente segura e auditável.

4.3 KiB Raw Blame History