Integração SGM (Manutenção) com DMS/ADMS

Projeto: DSB26201 · Assessment de Arquitetura de Integrações · Energisa Fonte: Transcrição integral da sessão de 13/07/2026 (28min, pasta REuniao-Manutencao) e Ata 07 já consolidada no Assessment (item 1.8) Status: Rascunho para consolidação — a Ata 07 é a mais disciplinada do projeto até aqui; este artefato visualiza os três achados centrais e registra uma correção pontual de atribuição de fonte Elaborado por: Syntropy Labs

Por que este artefato existe

A sessão de 13/07 apresentou a integração do sistema de manutenção (SGM) com o DMS/ADMS, conduzida por Marcus Vinicius Alves de Castro com participação de Norberto. A Ata 07 já cobre essa sessão com bom nível de detalhe e, notavelmente, é a primeira ata do projeto a expor com transparência total a divergência de duração entre suas duas fontes (compilação: 31min; transcrição: 28min8s) e a distinguir explicitamente o que vem da transcrição do que vem só da compilação de apoio. Este artefato traduz os três achados centrais — a topologia dos três microsserviços, o fluxo de envio/retorno da ordem de manutenção, e o risco de escalabilidade por empresa — em diagramas para uso no Capítulo 4 (Infraestrutura) e no Capítulo 5 (Riscos).

Diagrama 1 — Topologia dos três microsserviços

Vale notar que este fluxo é deliberadamente distinto do fluxo de atendimento emergencial (Ata 09) e da ordem técnica por falta de energia — a própria sessão fez questão de esclarecer essa fronteira logo no início, resolvendo uma ambiguidade que o próprio planejamento do assessment carregava sobre o termo "sistema de manutenção".

Diagrama 2 — Fluxo de envio e retorno da ordem

O ponto que merece atenção aqui é a ausência de CDC: diferente do fluxo de atendimento (que usa captura de alterações), este fluxo usa polling periódico contra a base do SGM — uma decisão que a própria Ata 07 trata corretamente como "decisão a revalidar, e não como restrição técnica estabelecida". Também não existe identificador corporativo único entre os sistemas — apenas uma correlação de códigos internos, sem casos relatados de perda, mas também sem garantia formal.

Diagrama 3 — Risco de escalabilidade: um processo interno por empresa

Este é o achado estrutural mais relevante da sessão: o serviço de consulta é um único deployment que cria, internamente, um processo por empresa monitorada — hoje 3 empresas, volume baixo. O risco não é presente, é futuro: cada nova empresa aumenta memória, conexões e complexidade dentro do mesmo pod, sem que o OpenShift consiga escalar horizontalmente (não é stateless, não há particionamento). O incidente de memória já ocorrido (JVM não reconhecendo o limite do pod, causando OOM kill) foi corrigido no sintoma, mas o desenho de fundo que o causou continua o mesmo.

Achado de fidelidade: atribuição de fonte incompleta

Auditando a Ata 07 contra a transcrição integral, ela se revelou a mais disciplinada do projeto até aqui — expõe a própria divergência de duração entre compilação e transcrição logo no cabeçalho, e quando cita nomes externos à transcrição (Max, Fábio, Otávio, Wesley, Douglas), atribui explicitamente à "compilação" em vez de apresentar como fato verificado.

Uma exceção a esse cuidado: a frase "Castellani, cuja inclusão nas reuniões seguintes foi solicitada" (item 1.8.2) e o item de ação correspondente (1.8.24) são apresentados como fato consolidado, sem hedge e sem atribuição explícita à compilação — diferente do tratamento dado a Vinícius, Pascoal, Gullit e Estevam, todos listados no Anexo B como pendentes de confirmação de grafia. O nome de Castellani não aparece em nenhum lugar desta transcrição específica, e o próprio Castellani confirmou, durante a auditoria, que não participou desta sessão. Isso não invalida a informação (ele participa da maior parte das outras sessões do projeto, e é plausível que sua inclusão em reuniões futuras tenha sido combinada fora da gravação), mas confirma que a afirmação deveria ter o mesmo tratamento de atribuição dado aos demais itens de segunda fonte.

Achado menor, de baixa severidade: a tabela de participantes atribui a Vladimir a afiliação "Digital Solutions e Syntropy Labs" — a primeira vez que "Digital Solutions" aparece em qualquer material deste projeto. Sem lastro nesta transcrição; vale confirmar se é uma empresa parceira real.

Próximo passo

Consolidar os três diagramas na Ata 07 (itens 1.8.6, 1.8.7/1.8.8 e 1.8.15) e usá-los no Capítulo 4 (Infraestrutura) e no Capítulo 5 (Riscos e Matriz RAID) — o risco de escalabilidade por empresa já está descrito na própria Ata 07 como "principal preocupação estrutural" e merece entrar formalmente na matriz de riscos. Ao consolidar, ajustar a frase sobre a inclusão de Castellani nas reuniões seguintes para deixar explícito que a informação vem da compilação de apoio, não da transcrição — mesmo padrão já aplicado a Max, Fábio, Otávio, Wesley e Douglas.