Fluxos de Integração ADMS × Atendimento¶
Projeto: DSB26201 · Assessment de Arquitetura de Integrações · Energisa Fontes: Wiki técnica da Energisa — "ADMS - Overview" (Canais Convencionais, 7 páginas, atualizado 17/06/2026 por Victor Teixeira Pinheiro) e "Abertura de Ocorrência Técnica pelo ADMS - Overview" (Canais Digitais, 3 páginas, atualizado 03/02/2026 por Lucas de Almeida Teixeira); transcrição consolidada de 3 sessões (15/07, 16/07 e 24/07/2026, pasta Reuniao-Atendimento); Ata 09 do Assessment Consolidado v1.12 Status: Rascunho para consolidação — substitui as referências indicativas do template do Capítulo 2 por dados de protocolo confirmados, e traz um addendum à Ata 09 (sessão de 24/07, ainda não incorporada) Elaborado por: Syntropy Labs
Por que este artefato existe¶
O template do Capítulo 2 do Assessment tinha, para protocolos e contratos de interface, principalmente campos "[a confirmar]". A wiki técnica interna da Energisa (devops.energisa.com.br) resolve isso: traz diagramas de sequência com nome exato de tópico Kafka, tabela, banco e microserviço para 8 fluxos de integração entre o ADMS/DMS e o ecossistema de atendimento. Este artefato consolida essa wiki, cruza com a Ata 09 já existente (sessões de 15 e 16/07) e fecha a lacuna da sessão de 24/07, que ainda não está em nenhuma ata.
Os 8 fluxos documentados na wiki¶
| # | Fluxo | Serviços envolvidos | Acionamento |
|---|---|---|---|
| 1 | Abertura de Ocorrência Técnica | WSROT, MsAttOcorrenciaTecnica, MsCrmMiddleware | Síncrono (canal) + assíncrono (Kafka) |
| 2 | Encerramento de Comunicação | WSROT, MsAttOcorrenciaTecnica, MsCrmMiddleware | Síncrono + assíncrono |
| 3 | Geração de Comunicação | MsAttFiltroIncidentes, MsAttComunicacao | Contínuo (consumer Kafka) |
| 4 | Atualização de Clientes | MsAttMonitoraInstalacao, MsAttCliente, MsAttClienteCsv, MsAtualizaPotenciaCliente | CronJob 5min + diário 02h00 |
| 5 | Desligamento Emergencial | MsAttFiltroIncidentes, MsAttDesligamentoEmergencial | Contínuo (consumer Kafka) |
| 6 | Desligamento Programado | MsAttDesligamentoProgramado | CronJob 2min |
| 7 | Flexible Load | MsAttClienteCsv | CronJob 5min |
| 8 | Load Profile (Curva de Carga) | MsAttClienteCsv | CronJob 5min |
Diagrama 1 — Mapa estático de microsserviços¶
Diagrama 2 — Sequência: Abertura de Ocorrência Técnica¶
Diagrama 3 — Sequência: Desligamento Programado (fechado em 24/07)¶
Addendum à Ata 09 — sessão de 24/07/2026 (13min, não incorporada)¶
A Ata 09 registra as sessões de 15 e 16/07 e fecha com uma pendência explícita: "o fluxo de desligamento programado não foi detalhado (...) as duas áreas acordaram apresentá-lo em conjunto em sessão posterior". A sessão de 24/07 é exatamente essa continuação, e ainda não está em nenhuma ata. Dois pontos saem dela:
Fechamento do fluxo de Desligamento Programado. Izabooh (atendimento convencional) confirmou o fluxo completo — ADMS deposita CSV no SFTP, o microserviço processa em CronJob de 2 minutos, persiste no Oracle e publica no Kafka — e que o único consumidor do tópico é o SAC Proativo, que fica inteiramente do lado de canais digitais (equipe do Lucas). Do lado do atendimento convencional, nada consome esse tópico.
Recomendação arquitetural nova, ainda não registrada em nenhuma ata. Castellani propôs uma regra prática para triagem de eventos: quando um evento é ponto-a-ponto entre dois componentes do mesmo domínio (um produtor, um consumidor, sem necessidade de múltiplos assinantes), ele não precisa estar no Kafka corporativo — pode usar um message broker mais barato e mais simples, como Oracle AQ ou TxEventQ (a interface Kafka-compatível do Oracle mais recente). Reservar o Kafka/Confluent para eventos que são, de fato, fatos de domínio com múltiplos consumidores entre domínios diferentes. Norberto confirmou que já vinha pensando na mesma direção. A conversa também tocou a discussão, já registrada na Ata 09 (item 1.10.5.6), sobre se a resposta para o crescimento do ambiente é adicionar Apache Flink ou primeiro racionalizar o que está desnecessariamente no Kafka — a sessão de 24/07 reforça a segunda leitura.
Achado de nomenclatura: "Sigode" vs. MsAttFiltroIncidentes¶
A Ata 09 atribui ao Sigode o papel de consolidar o estado da ocorrência e republicar em 7 tópicos por estado ("o Sigode mantém um tópico mais amplo de ordem de serviço... a partir dele, o próprio Sigode agrega e republica o conteúdo em tópicos específicos"). A wiki técnica, porém, atribui esse papel a um microserviço específico, o MsAttFiltroIncidentes, que consome os 7 tópicos wfm_ordem_servico_* — esses sim produzidos pelo WFM (produto SIGOD, domínio 4 do framework corporativo) — e republica para crm_comunicacao e crm_clientes_afetados_desligamento_emergencial.
A lista de 7 tópicos bate exatamente entre as duas fontes (criado, despachado, encerrado, cancelado, arquivado, chamada, afetado), então o conteúdo técnico está correto nas duas — a diferença é de atribuição: a ata trata "Sigode" como o agente que filtra e republica, quando pela wiki esse papel é do MsAttFiltroIncidentes, e Sigode/SIGOD é só o sistema de origem (WFM) dos 7 tópicos brutos. Pode ser apenas o jeito como as áreas se referem a isso informalmente em reunião — vale confirmar com Izabooh ou Lucas antes de corrigir a Ata 09.
Tabela de referência — tópicos Kafka principais¶
Coluna de schema adicionada em 05/08/2026, a partir do inventário real de produção do Confluent (
topicos_detalhado_latest.md) — verevidencias-producao-confluent-kafka.md. "Sem Schema" significa que o tópico não está registrado no Schema Registry no inventário de 09/07/2026.
| Tópico | Produtor | Consumidor | Schema (inventário real, 09/07) |
|---|---|---|---|
wfm_ordem_servico_criado/despachado/encerrado/cancelado/arquivado/chamada/cliente_afetado (7 tópicos) |
WFM/ADMS (SIGOD) | MsAttFiltroIncidentes | Sem Schema (domínio WFM: 0/40 tópicos com schema no inventário geral) |
crm_comunicacao |
MsAttFiltroIncidentes | MsAttComunicacao | Sem Schema |
crm_clientes_afetados_desligamento_emergencial |
MsAttFiltroIncidentes | MsAttDesligamentoEmergencial | Sem Schema |
crm_clientes_afetados_desligamento_programado |
MsAttDesligamentoProgramado | SAC Proativo | Sem Schema |
crm_atualizacao_cliente_adms |
MsAttMonitoraInstalacao | MsAttCliente | Sem Schema |
crm_chamada_ocorrencia_tecnica |
WSROT | MsAttOcorrenciaTecnica | Sem Schema — payload real inspecionado contém CPF e telefone em texto puro (ver R42 proposto em matriz-riscos-consolidada.md) |
crm_callback_ocorrencia_tecnica |
WSROT | MsAttOcorrenciaTecnica | Não localizado no inventário de 09/07/2026 entre os 14 tópicos do domínio CRM — confirmar se o nome mudou ou se o tópico foi descontinuado |
crm_registra_ocorrencia_sistema_tecnico |
MsAttOcorrenciaTecnica | MsCrmMiddleware | Sem Schema |
crm_retorno_ocorrencia_sistema_tecnico |
MsCrmMiddleware | MsAttOcorrenciaTecnica | Sem Schema |
Próximo passo¶
Consolidar este artefato em dois lugares: (1) Ata 09, como um item 1.10.24 (addendum da sessão de 24/07), incluindo a recomendação de racionalização de broker e a ressalva sobre a nomenclatura Sigode/MsAttFiltroIncidentes; (2) Capítulo 2 do Assessment Consolidado, substituindo os campos "[a confirmar]" do template por estes tópicos, tabelas e serviços confirmados. Vale também levar a recomendação de broker por domínio (Oracle AQ/TxEventQ) para o Capítulo 6 (Recomendações e Roadmap), quando esse capítulo for iniciado. Adicionalmente, a coluna de schema agora presente na tabela de tópicos reforça a recomendação de Schema Registry obrigatório (Ata 09) com evidência concreta: nenhum dos 8 tópicos deste fluxo tem schema hoje, e um deles carrega dado pessoal em texto puro.