Pular para conteúdo

Padrões de Integração Confirmados — Soluções Energisa → ADMS (Entrada)

Projeto: DSB26201 · Assessment de Arquitetura de Integrações · Energisa Fonte: Síntese de evidência já confirmada em outros artefatos deste assessment — não é leitura de fonte primária nova. Ver "Fontes" ao final de cada padrão. Status: Consolidação Elaborado por: Syntropy Labs

Por que este artefato existe

Vários artefatos deste assessment documentam, cada um isoladamente, como um sistema específico da Energisa alimenta o ADMS — mas nenhum consolida os padrões técnicos que se repetem entre eles, com status de confirmação explícito para cada um. Essa consolidação importa porque já cometemos (e corrigimos, em sessão) o erro de tratar "existe uma rota no Sensedia" como prova de que "vem de um tópico Kafka" — os dois primeiros padrões abaixo mostram casos confirmados de cada leitura, lado a lado, para que essa confusão não se repita.

Escopo

Só a direção Soluções Energisa → ADMS (entrada). O sentido inverso — ADMS publicando notificações para sistemas externos (ex.: ONT, SMN) — é um tópico espelhado, com sua própria mecânica, não coberto aqui.

Padrões confirmados de integração de entrada do ADMS

Padrão 1 — Kafka mediado: producer → Kafka → consumer → Sensedia → Adapter SOAP

Status: CONFIRMADO — dois exemplos de produção, com nome de tópico e microsserviço.

  • CRM/Atendimento — Abertura de Ocorrência Técnica. WSROT publica em crm_chamada_ocorrencia_tecnica → MsAttOcorrenciaTecnica consome, grava no banco ATD, publica em crm_registra_ocorrencia_sistema_tecnico → MsCrmMiddleware consome e chama POST /TroubleTickets/ síncrono no ADMS via Sensedia → retorno publicado em crm_retorno_ocorrencia_sistema_tecnico. Nomes de tópico e microsserviço vêm da wiki técnica interna da Energisa, cruzados com a Ata 09. Ver fluxos-atendimento-adms.md, Diagrama 2.
  • SGM/Manutenção — envio de ordem de manutenção programada. Serviço de consulta faz polling na base do SGM (sem CDC), publica no tópico Kafka de ordens de serviço → Serviço de envio consome, chama o API Gateway Sensedia → encaminha ao DMS/ADMS (leitura plausível, não confirmada em sessão: adapter SMR, ReceiveWorksService) → retorno publicado em tópico de retorno → Serviço de notificação atualiza a base de origem. Confirmado por transcrição integral da sessão de 13/07/2026 (Ata 07). Ver integracao-manutencao-dms-adms.md, Diagramas 1–2.

Pendente — hipótese AVL. Os tópicos wfm_coordenada_veiculo e wfm_coordenada_equipe existem em produção (ambiente PRD, domínio WFM), candidatos plausíveis a alimentar o adapter AVL por este mesmo padrão — mas consumidor, rota no Sensedia e log de chamador ainda não foram confirmados. Pedido de catálogo + trace do Sensedia já registrado em 080-diagnostico/questionario-mitigacao-lacunas.md, Bloco 10, item 5. O fato de o Padrão 1 já estar confirmado para dois fluxos "quase tempo real" (CRM, SGM) — o mesmo perfil descrito para AVL no manual do fabricante — torna a hipótese mais forte do que uma leitura isolada sugeriria, mas continua sendo hipótese até o trace confirmar.

Padrão 2 — Direto a Sensedia, sem Kafka

Status: CONFIRMADO — um exemplo, com evidência de log real.

  • WFM/SIGOD — carga full de equipes. SIGOD empacota todas as equipes do agrupamento de 3 empresas em um pacote GZIP (mesmo alterando uma só) → envia via SOAP direto ao Sensedia, sem produtor Kafka no meio → Sensedia encaminha ao Adapter WFM do ADMS (ReceiveCrewModelService) → processamento em background (>10s). Confirmado com evidência documental direta (29/08/2026): log do gateway Sensedia mostra dezenas de POST .../wfm-adms/v1/crewmodel retornando 504, timeout configurado explicitamente em 10000ms, e logs do WfmAdapter (Schneider OASyS) mostrando o processamento continuando em background após o gateway já ter desistido — inclusive erros de qualidade de dado invisíveis ao WFM. Ver integracao-wfm-adms.md, Diagramas 1–2.

Este é o caso que originalmente motivou a distinção dos três padrões: a existência de uma rota no Sensedia (.../wfm-adms/v1/crewmodel) não implica origem via Kafka — aqui não há nenhum tópico envolvido.

Padrão 3 — SFTP + FileMonitoringService, sem Sensedia, sem Kafka

Status: CONFIRMADO — um exemplo nominal, mais candidatos por semelhança de padrão.

  • GIS. Extrato CIMXML por circuito, gerado no GIS Smallworld, depositado em pasta SFTP compartilhada → FileMonitoringService do ADMS monitora a pasta e consome, sem chamada síncrona, sem Kafka, sem Sensedia. Nome do serviço confirmado nominalmente em 03/09/2026 pela própria equipe do GIS — bate literalmente com o nome do adapter do manual do fabricante. Ver integracao-gis-adms.md e catalogo-adapters-schneider-adms.md.
  • Atendimento (candidato mais forte do que "plausível"). MsAttClienteCsv grava CSV diretamente numa pasta SFTP consumida pelo ADMS ("Grava CSV para ADMS"), e o ADMS deposita OutageReport na mesma pasta para leitura por MsAttDesligamentoProgramado (sentido oposto, S→E) — ambos documentados na mesma wiki técnica interna + Ata 09 usada para o Padrão 1. catalogo-adapters-schneider-adms.md hoje trata esse caso como "plausível por semelhança, sem confirmação nominal" — vale revisitar esse artefato à luz desta evidência, que parece do mesmo nível de confiança dos fluxos Kafka já tratados como confirmados ali. Não foi corrigido aqui para não alterar o status de outro artefato sem revisão dedicada — registrado como achado a fechar.

Tabela-resumo

Padrão Kafka? Sensedia? Status Exemplos confirmados
1 — Kafka mediado Sim Sim Confirmado (2 exemplos) + hipótese AVL pendente CRM/Atendimento (Abertura de Ocorrência), SGM/Manutenção
2 — Direto a Sensedia Não Sim Confirmado (1 exemplo, log real) WFM/SIGOD — carga full de equipes
3 — SFTP + FileMonitoring Não Não Confirmado (1 exemplo nominal) + 1 candidato forte GIS; Atendimento (candidato)

Fontes