Integração GIS, GIS Adapter, SFTP e ADMS¶
Projeto: DSB26201 · Assessment de Arquitetura de Integrações · Energisa Fonte: Transcrição integral da sessão de 10/07/2026 (46min51s, pasta REuniao-ADM-GIS), dois screenshots de processo/log fornecidos na mesma pasta, e Ata 06 já consolidada no Assessment (item 1.7) Status: Rascunho para consolidação — a Ata 06 é estruturalmente sólida, mas contém dois nomes próprios sem qualquer lastro na transcrição e um terceiro provavelmente trocado Elaborado por: Syntropy Labs
Por que este artefato existe¶
A sessão de 10/07 detalhou a integração cadastral entre o GIS (Smallworld da GE) e o ADMS/OMS da Schneider, conduzida pela equipe de Gilmar Pedrete (Cássio, Anielo/Nielo e Joaquim como referências técnicas) com participação de Norberto, Vladimir e Castellani. A Ata 06 é, das atas do projeto, uma das mais completas em cobertura temática — expõe corretamente a autocorreção em sessão do tempo de extração (12h → 6-7h) e documenta com detalhe o motor de validação em 4 etapas e a rejeição em cascata entre extratos MT/BT. Este artefato traduz três achados centrais — a topologia do fluxo cadastral, o comportamento de validação/rejeição, e o risco de segregação em ambiente single tenant — em diagramas para o Capítulo 4 (Infraestrutura) e o Capítulo 5 (Riscos), e registra os achados de fidelidade encontrados na auditoria contra a transcrição e os dois screenshots.
Diagrama 1 — Topologia do fluxo cadastral GIS → ADMS¶
O ponto estrutural é o mesmo que a Ata 06 já registra corretamente como princípio: o fluxo cadastral é unidirecional (GIS → ADMS) e assíncrono (batch noturno ou extração manual pontual). O GIS nunca recebe de volta uma atualização de estado operacional do ADMS — a chave aberta/fechada vive só no ADMS. O que este diagrama acrescenta à ata é o achado de fidelidade sobre o nome do fornecedor que customizou o adapter (ver seção de achados abaixo) e a tensão numérica entre o "2-3h" verbal e o "~8h" do screenshot operacional.
Confirmações e achados novos (31/08/2026) — decomposição do tempo de propagação e backlog de pendentes¶
Fonte: follow-up formal de 5 itens ("O que pedimos", tag D2) enviado à equipe do GIS a partir de uma tabela de tempos e de uma planilha de 30 extrações fornecidas como evidência, respondido por escrito pela equipe do GIS/Norberto na mesma data.
1 · Divergência de 5 minutos na tabela de tempos — confirmada como erro de transcrição, não de dado. A coluna "Importação ADMS (Sumário Extratos)" soma 5:25 (EMR) + 25:03 (EMS) + 6:20 (ESS) = 36:48, mas a tabela originalmente enviada imprimia "Tempo Total" como 41:48 (diferença de 5 minutos). Confirmado pela equipe do GIS: 36:48 é o valor correto; 41:48 foi falha na transcrição do resultado para a tabela, não erro de soma dos dados nem divergência real entre unidades. A coluna "Geração ChangeSets e Sincronização" (29:50:18) não apresentava essa mesma divergência — a soma das três unidades já batia com o total informado.
2 · Por que o tempo total observado (Etapas 1–3) está inflado — e não há SLA para a etapa manual. A própria equipe esclareceu que o tempo total observado está inflado porque a Etapa 3 (sincronização de ChangeSets) é manual e, hoje, não é executada no mesmo dia da importação — ela pode ficar pendente por um período não determinado antes de rodar. Isso afeta diretamente qualquer métrica de "tempo total de propagação GIS → ADMS" citada em outras seções deste ou de outros artefatos. Perguntado se existe SLA ou meta operacional para essa etapa manual, a resposta foi: "Não tenho conhecimento se foi definido um SLA para esta etapa do processo. Necessário confirmar com a Equipe de Negócios ou os responsáveis de cada UN." Sem SLA confirmado — registrado como risco na matriz de riscos consolidada (R09, atualizado a partir desta troca).
3 · O "2 a 3 horas" citado verbalmente é uma média entre Unidades com perfis bem diferentes — sem meta formal. A Etapa 1 (extração automática no GIS Adapter) foi confirmada em "2 a 3 horas", valor citado originalmente em sessão para Mato Grosso do Sul (EMS, na nomenclatura desta troca). Os dados de 30 extrações fornecidos como evidência mostram médias bem diferentes por Unidade: EMR ≈ 54 min, EMS ≈ 1h53, ESS ≈ 1h29. Resposta da equipe: "O Intervalo de 2h a 3h é um tempo médio para as três Unidades, exatamente considerando que cada UN tem perfis de tempos diferentes entre si. Não existe uma meta formal. Os valores de 2h a 3h são estimativas baseadas no histórico das extrações realizadas."
Achado de fidelidade a registrar, não só repassar a resposta: a média aritmética das três Unidades a partir da própria amostra de 30 extrações é (54 + 113 + 89) / 3 ≈ 85 minutos (1h25) — abaixo do intervalo de "2 a 3 horas" apresentado como média. Só a EMS (1h53) se aproxima do piso do intervalo; EMR e ESS ficam bem abaixo dele. Isso não é necessariamente uma contradição — "2-3h" pode refletir um histórico mais amplo do que esta amostra específica, ou uma faixa de segurança usada informalmente — mas as duas fontes não são a mesma medida, e não deveriam ser citadas como equivalentes em nenhum entregável sem essa ressalva.
5 · Backlog de extratos "Pendente" — percentuais expressivos e desiguais entre Unidades, sem SLA de permanência. A planilha de dados de importação mostra fração relevante dos extratos em estado Pendente no momento da extração dos dados: 42% em EMR (148/352), 23% em EMS (131/568), 11% em ESS (37/336). Resposta da equipe do GIS (mesma resposta cobre a Questão 3 original sobre o ciclo de correção — ver Diagrama 2 abaixo): os extratos pendentes são analisados e corrigidos pela equipe de cadastro; a correção ocorre no GIS EO (mesmo produto referido no Diagrama 1 como "GE Electric Office") e só é enviada ao ADMS no ciclo seguinte. Um alimentador que exija correção mais imediata pode ser reenviado no mesmo dia, por decisão conjunta das equipes de operação, cadastro e GAT (Gerência de Automação e Telecom — confirmado por Castellani em 31/08/2026; primeira menção como "Setor de Automação" foi ajustada para o nome formal da gerência). Não existe definição de tempo máximo de permanência nos estados Pendente/Inválido/Rejeitado. A diferença expressiva entre Unidades (42% em EMR vs. 11% em ESS) foi atribuída pela equipe à qualidade do cadastro de cada Unidade e ao volume de extratos efetivamente alterados por dia em cada uma — não a uma causa técnica única.
Item 4 deste mesmo follow-up (nome exato do serviço de monitoramento do lado ADMS — Adaptador de Monitor de Arquivo do fabricante ou implementação própria) resolvido em 03/09/2026: a equipe do GIS confirmou o nome — FileMonitoringService, o adapter padrão do fabricante, não uma implementação própria. Detalhe tratado em catalogo-adapters-schneider-adms.md, não duplicado aqui.
O que ainda não reconcilia: os números acima não fecham sozinhos a tensão já registrada nos achados de fidelidade abaixo entre o "2-3h" verbal e o "~8h" do screenshot operacional (5h extração + 3h importação) — a decomposição desta seção é sobre Etapas 1/3 de um fluxo diferente de medição (30 extrações, por Unidade), não necessariamente a mesma cadeia de etapas do screenshot. Tratar como dado adicional, não como reconciliação fechada, até confirmar se as duas fontes descrevem o mesmo processo.
Diagrama 2 — Validação e rejeição em cascata¶
Dois pontos importam aqui. Primeiro, a granularidade da rejeição é por extrato completo do circuito, não por item — um único atributo fora de faixa (o exemplo dado na sessão foi o TAP de transformador, faixa 0 a 5) derruba o circuito inteiro. Segundo, existe dependência entre extratos correlatos: se a MT de um circuito é rejeitada, a BT do mesmo circuito (ou o circuito do outro lado de uma chave de fronteira) também não entra, mesmo sem erro próprio. O screenshot do log real (InvalidVoltageCompatibility) é uma evidência concreta e nova que nem a transcrição nem a Ata 06 mencionam — é um tipo de erro adicional ao "TAP fora de faixa" já documentado, útil para uma futura taxonomia de causas de rejeição (ação nº 3 do plano da própria Ata 06).
Diagrama 3 — Risco: ambiente single tenant compartilhado¶
Este é o achado estrutural mais relevante da sessão, e a própria Ata 06 já o classifica com severidade Alta (item 1.7.15.2, "Processar extrato de outra empresa"). O trade-off é explícito: consolidar empresas em um único ambiente ADMS reduziu custo em relação à hipótese original de um ADMS por empresa, mas o produto não oferece segregação por perfil dentro do grupo — hoje o único controle é a atenção manual do usuário. Vale notar que este é o mesmo tipo de risco de "ambiente compartilhado" já visto na Ata 04 (ksqlDB consolidando 9 empresas) — um padrão recorrente no projeto de trocar isolamento por redução de custo.
Achados de fidelidade¶
Auditando a Ata 06 contra a transcrição integral e os dois screenshots, o documento é estruturalmente sólido — trata corretamente a autocorreção em sessão do tempo de extração (a menção inicial a "12 horas" foi corrigida para "6 a 7 horas" pelo próprio falante, e a ata registra isso como divergência a validar, no mesmo padrão cuidadoso já visto no tratamento do ONT/ENT na Ata 05). Mas a auditoria encontrou três problemas de nomes próprios, de severidade desigual:
"Insight" é "Minsait" — nome de fornecedor trocado, correção validada em 28/08/2026. Aos 09:23 da transcrição, o áudio foi reconhecido como "então a minsite que é quem customizou o gizadapter pra Energisa" — uma transcrição fonética de "Minsait" (empresa real do grupo Indra, já referenciada em material anterior deste projeto). A Ata 06 interpretou como "Insight" e apresenta isso como fato consolidado, sem hedge, tanto na seção 1.7.5.1 quanto no registro cronológico do Anexo B — apesar de a própria ata manter um Anexo D dedicado a "termos que exigem validação", onde este item deveria estar. Diferença de nome de fornecedor não é cosmética: se alguém abrir um chamado de customização com base na ata, abre com a empresa errada. Reforça essa leitura o mesmo padrão de erro fonético encontrado de forma independente na Ata 08 (motor de cálculo IQOS, "Minsight"/"missight" — ver integracao-wfm-adms.md), sugerindo que é a mesma empresa nos dois papéis.
"Taijo Aquino" — nome sem qualquer base na transcrição. Aparece duas vezes na Ata 06 (lista de participantes, item 1.7.2.1, e no registro cronológico do Anexo B às 00:34:42: "Pergunta a Cássio, Anielo e Taijo Aquino se há alguma dor..."). Busca no arquivo integral da transcrição não encontra nenhuma ocorrência de "Taijo" ou "Aquino". No trecho correspondente a esse instante, a transcrição registra apenas "Cássio é daniello, é Joaquim" — nenhum terceiro nome com essa forma aparece. Esta é uma fabricação no mesmo padrão dos nomes Gabriel/Lucas/Fabrício já identificados na Ata 04: um nome próprio específico, apresentado sem hedge, sem qualquer lastro no material fonte.
"Alberto" — mesma categoria. Também listado na seção 1.7.2.1 como pessoa mencionada durante a discussão; zero ocorrências em toda a transcrição.
Achado menor, de consistência interna (não fabricação): a própria Ata 06 já classifica "Cassiano" como confiança Baixa no Anexo B, levantando a hipótese de que seja o mesmo Falante 5 identificado em outros pontos como "Cassiane"/"Cassiolani"/variações mal transcritas do próprio nome Castellani — mas a seção 1.7.2.1 lista "Cassiano" junto aos demais nomes mencionados sem repetir essa mesma ressalva. Vale unificar o tratamento.
Por fim, os dois screenshots trazem informação nova, não citada na ata: o fluxograma "Processo Automático" indica duração total de aproximadamente 8 horas (5h de extração + 3h de importação, ~1h por empresa, sem paralelismo entre ZIPs — a confirmar com o Product Team da Schneider, citado como "Milos"), um número mais alto que o "2 a 3 horas" mencionado verbalmente na sessão para Mato Grosso do Sul. Não é necessariamente uma contradição — os dois podem descrever etapas ou cenários diferentes — mas vale reconciliar antes de consolidar um número único no Capítulo 4.
Próximo passo¶
Consolidar os três diagramas na Ata 06 (itens 1.7.3, 1.7.9 e 1.7.13) e usá-los no Capítulo 4 (Infraestrutura) e no Capítulo 5 (Riscos e Matriz RAID) — o risco de single tenant já está classificado como Alta severidade na própria ata e converge com o mesmo padrão já visto na Ata 04. Ao consolidar: (1) corrigir "Insight" para "Minsait" na seção do GIS Adapter (correção validada em 28/08/2026); (2) remover ou re-verificar "Taijo Aquino" e "Alberto" na lista de participantes e no Anexo B, já que nenhum dos dois nomes aparece na transcrição; (3) unificar o tratamento de "Cassiano" com a mesma ressalva de baixa confiança já aplicada no Anexo B; (4) ~~reconciliar o número de ~8h do screenshot com o "2-3h" verbal~~ — parcialmente avançado em 31/08/2026 (ver seção acima): "2-3h" é confirmado como média entre Unidades sem meta formal, com dado real de 30 extrações mostrando EMR≈54min/EMS≈1h53/ESS≈1h29; a reconciliação com o "~8h" do screenshot segue aberta, tratar como medições possivelmente de escopos diferentes até confirmar; (5) ~~confirmar o significado da sigla GAT~~ — resolvido em 31/08/2026: Gerência de Automação e Telecom; (6) ~~obter do time técnico da Minsait ou da Schneider a confirmação nominal do serviço de monitoramento de arquivo do lado ADMS~~ — resolvido em 03/09/2026: FileMonitoringService (Item 4 do follow-up de 31/08/2026 — ver catalogo-adapters-schneider-adms.md).