Integração WFM/SIGOD com ADMS e Motor de Cálculo IQOS

Projeto: DSB26201 · Assessment de Arquitetura de Integrações · Energisa Fonte: Transcrição integral da sessão de 15/07/2026 (3840 linhas, ~59min36s, pasta Reuniao-WFM) e Ata 08 já consolidada no Assessment (item 1.9) Status: Rascunho para consolidação — a Ata 08 foi escrita sem transcrição disponível; uma transcrição completa foi localizada nesta auditoria e usada para verificar a ata pela primeira vez Elaborado por: Syntropy Labs

Por que este artefato existe

A sessão de 15/07 cobriu dois fluxos distintos: a integração de cadastro de equipes entre o WFM/SIGOD e o ADMS (carga full via SOAP, sem endpoint incremental) e a integração entre o ADMS e o motor de cálculo IQOS (dependências entre incidentes, trabalho manual de mais de um ano). A Ata 08 declara explicitamente, ao contrário das Atas 05, 06 e 07, que "foi disponibilizada apenas na forma de compilação detalhada, sem transcrição correspondente". Esta auditoria localizou uma transcrição integral desta sessão na pasta do projeto — a primeira vez que a Ata 08 pode ser verificada contra uma fonte primária. Este artefato traduz os três achados centrais — a topologia do cadastro de equipes com a proposta de automação RPA, o comportamento de timeout e "cegueira operacional" na carga full, e o fluxo de dependência entre incidentes no IQOS — em diagramas para o Capítulo 4 (Infraestrutura) e o Capítulo 5 (Riscos), e registra os achados de fidelidade encontrados.

Diagrama 1 — Topologia do cadastro de equipes: carga full atual e proposta de API incremental

Nota de escopo (12/08/2026): este artefato cobre só o fluxo de cadastro de equipes do sistema legado — SIGOD, client-server em PowerBuilder, banco Oracle. O WFM, como domínio, já tem um segundo sistema em migração — eForce (microsserviços .NET, MongoDB, Kafka) — que convive com o SIGOD hoje e não usa SOAP/SFTP para o fluxo de Ordem de Serviço (usa API própria e eventos Kafka). Ver integracao-wfm-eforce-ordem-servico.md para a arquitetura do eForce, incluindo o midler que ainda faz ponte com este fluxo de cadastro via CDC (bypass de API, dívida técnica reconhecida pelo próprio time).

O ponto estrutural: o ADMS hoje só aceita duas formas de atualizar equipes — carga full (SOAP, pacote GZIP de todo o agrupamento de 3 empresas) ou uma tela de mudança de status que não cobre o cadastro completo. Não existe endpoint funcional para criar/alterar uma única equipe, o que força o reenvio do pacote inteiro a cada alteração pontual. A proposta discutida na sessão — um "adapter RPA" que automatiza a tela via login/navegação/preenchimento — é tratada corretamente na Ata 08 como hipótese de contorno, não solução aprovada, com risco explícito de violar suporte contratual da Schneider se não homologada.

Diagrama 2 — Carga full: timeout e "cegueira operacional"

Este diagrama traduz o achado mais recorrente da sessão: o WFM nunca recebe confirmação confiável de sucesso ou erro. O ADMS continua processando em background após o timeout de ~10 segundos, e a falha só é percebida quando o despacho operacional falha — não durante a carga. O incidente real relatado na virada de Minas (equipe ausente por descrição de região nula) ilustra exatamente esse padrão: o problema existia desde a carga, mas só apareceu na operação.

Confirmado por evidência real (29/08/2026). Resposta ao Bloco 9 do questionário de mitigação de lacunas [D4] trouxe quatro evidências que deixam de tratar este diagrama como relato de sessão e passam a confirmá-lo por log real: (1) log do gateway Sensedia mostra dezenas de POST .../wfm-adms/v1/crewmodel retornando 504, latência consistente de ~10,15–10,24s, em intervalos regulares de ~3 minutos por horas (18/08/2026) — não é evento isolado; (2) log detalhado do mesmo gateway confirma o timeout configurado explicitamente em 10000ms ("HTTP Timeout: socket: 10000") ao encaminhar para ReceiveCrewModelService, terminando em "Gateway timeout: Read timed out" — o número "~10 segundos" do diagrama deixa de ser recordação de sessão; (3) e (4) logs do WfmAdapter (Schneider OASyS, DMS_INTEGRATION) mostram o processamento continuando em background depois do gateway já ter desistido, com erros reais de qualidade de dado invisíveis ao WFM — erro de mapeamento ("Cannot find 'EPB-I-STR_LEIT08' string value in 'OMS_CREW' string too long map") e validações de região/entidade inválida ("Invalid crew region: EMR-9-102-171 for entities: EMR-I-MAU_LTR_02", "Invalid entity mRID: INC123092181"). O achado "timeout sem confirmação" (R10) passa de convergência de sessão (Ata 08) para achado com evidência documental direta.

Diagrama 3 — ADMS → Motor de cálculo IQOS: dependência entre incidentes

O achado central aqui não é indisponibilidade técnica — é uma regra de negócio sem lar arquitetural definido. Quando um incidente depende de dados de outro que ainda não aconteceu, a gravação falha e cai em DLQ; uma pessoa faz a varredura manual diária (rotina desde ~setembro de 2025) e reenvia os dados unificados manualmente. A Ata 08 documenta corretamente que a base ETL do IQOS cumpre parcialmente o papel de staging, mas falta a lógica explícita de correlação entre incidentes dependentes — por isso criar "mais uma base" não resolveria sozinho, como a própria ata observa.

Achados de fidelidade

Este é o primeiro caso do projeto em que a auditoria muda de natureza: a própria Ata 08 declara, em sua nota de consolidação, que "esta sessão foi disponibilizada apenas na forma de compilação detalhada, sem transcrição correspondente" — diferente das Atas 05, 06 e 07. Uma transcrição integral (3840 linhas) foi encontrada na pasta Reuniao-WFM do projeto e usada aqui para verificar a ata contra uma fonte primária que, segundo a própria ata, não existia no momento da sua redação.

Duração: a ata registra "1 hora e 7 minutos" (09h32 às 10h39). A transcrição encontrada vai de 00:00:02 a 00:59:35 — cerca de 8 minutos a menos que o declarado. Como a ata foi escrita sem transcrição, esse número provavelmente veio da agenda da reunião, não da gravação real.

"Vladimir Morozowski de Sousa" não aparece na transcrição. A tabela de participantes (1.9.2) o lista com papel ativo: "condução de perguntas de arquitetura, integração, observabilidade e alternativas de solução." Busca no arquivo integral não encontra nenhuma ocorrência de "Vladimir" ou variações. Diferente das fabricações de nome vistas em atas anteriores (Ata 04, Ata 06), aqui há uma explicação plausível: sem transcrição, quem compilou a ata pode ter presumido a presença de Vladimir por ele participar da maioria das outras sessões do projeto. Ainda assim, é uma atribuição de papel substantivo sem lastro no material-fonte agora disponível, e merece a mesma correção.

Recorrência do problema de nome de fornecedor já visto na Ata 06 — correção validada em 28/08/2026. A Ata 08 chama o fornecedor do motor de cálculo IQOS de "Minsight" (seções 1.9.2, 1.9.8.2, 1.9.11.3, 1.9.14). A transcrição registra foneticamente "missight" (33:44) e "missade" (36:31). É o mesmo caso já documentado no artefato de Integração GIS-ADMS, onde a Ata 06 registrou "Insight" para o que a transcrição sugeria ser "Minsait" — empresa real do grupo Indra, já estabelecida no projeto como responsável pela customização do GIS Adapter. Confirmado: é a mesma empresa nos dois papéis (GIS Adapter e motor de cálculo IQOS), e o nome real é "Minsait" nos dois casos, não "Insight" nem "Minsight".

Pista externa sobre o que é o motor IQS (28/08/2026) — confirmada em 05/09/2026 e validada por Castellani em 08/09/2026. Pesquisa web (não é fonte primária da Energisa — nenhuma Ata ou transcrição deste assessment confirma isto por si só) identificou "IQOS" — nome que aparece em outros pontos do assessment para um banco Oracle corporativo (blueprint-componentes-adms.md, seção C.0) e para a sigla de adapter citada numa lista informal de nomes Schneider/ADMS — como Onesait IQOS, produto da própria Minsait para cálculo e auditoria de indicadores regulatórios de continuidade (DEC/FEC, exigidos pela ANEEL), que ingere dados de interrupção a partir do módulo OMS do ADMS. Isso é compatível com o motor de cálculo IQOS descrito neste artefato (mesma função — cálculo de indicadores a partir de incidentes do ADMS — e agora o mesmo fornecedor, Minsait) e ajuda a explicar o banco Oracle "IQOS" como o banco desse mesmo produto. Confirmado por Castellani (Syntropy Labs), 05/09/2026, e reconfirmado em 08/09/2026: IQOS é de fato produto Minsait (Onesait IQOS) — o nome "IQS" usado nas atas e nas versões anteriores deste artefato estava incorreto; referências normalizadas para "IQOS" neste e nos demais artefatos derivados (atas/evidências mantêm o termo original registrado na sessão). Mesma confirmação registrada em catalogo-adapters-schneider-adms.md.

Achado positivo: a Ata 08 interpretou corretamente o termo foneticamente distorcido "queda" como "KEDA" (Kubernetes Event-Driven Autoscaling) — uma leitura correta e não óbvia, bem casada com o contexto de HPA/escalonamento discutido na sessão. É um bom contraste com os erros de nome acima: mostra que a compilação, mesmo sem transcrição, acertou onde o contexto técnico era forte o suficiente para desambiguar.

Achado menor: "Cassiano" aparece uma vez na transcrição (pedido para agendar reunião com a Schneider) mas não consta na lista de participantes da Ata 08 — provavelmente apenas um detalhe perdido na compilação feita sem transcrição, não uma omissão deliberada.

Fora esses pontos, o conteúdo técnico da Ata 08 corresponde bem à transcrição: a proposta de automação RPA, o timeout de ~10 segundos, o transporte GZIP/SOAP, a escala de 300 a 400 equipes, o histórico da Schneider avaliar e desistir do motor de cálculo, e a discussão de HPA/KEDA são todos fiéis ao que foi dito na sessão — um resultado notável para uma ata escrita sem acesso à gravação.

Próximo passo

Consolidar os três diagramas na Ata 08 (itens 1.9.5, 1.9.5.4 e 1.9.8) e usá-los no Capítulo 4 (Infraestrutura) e no Capítulo 5 (Riscos e Matriz RAID) — a matriz de riscos da própria ata já classifica "timeout sem confirmação" e "dependências entre incidentes" como severidade Crítica. Ao consolidar: (1) anexar a transcrição agora localizada à Ata 08 e revisar a duração para ~59min36s; (2) verificar com a equipe se Vladimir de fato participou desta sessão específica antes de manter sua atribuição de papel ativo; (3) corrigir "Minsight"/"Insight" para "Minsait" (correção validada em 28/08/2026) nas Atas 06 e 08 conjuntamente; (4) confirmado — o motor de cálculo é o produto Onesait IQOS da Minsait; referências normalizadas de "IQS" para "IQOS" nos artefatos e diagramas (as atas/evidências mantêm o termo original "IQS").