Integração WFM/eForce — Arquitetura Interna do Fluxo de Ordem de Serviço e Ausência de DLQ

Projeto: DSB26201 · Assessment de Arquitetura de Integrações · Energisa Fonte: Transcrição integral da sessão de 12/08/2026 com o desenvolvedor responsável pelo eForce (~1h32min, "Assessment Integração ADMS - Dev WFM (Consultoria Syntropy)") e documentação interna da wiki do eForce (E.Force / Modules / Ordem Servico) Status: Achado novo — sem artefato correspondente até esta sessão Elaborado por: Syntropy Labs

Por que este artefato existe

A sessão de 15/07 (Ata 08, ver integracao-wfm-adms.md) cobriu o cadastro de equipes e o motor de cálculo IQOS — não a arquitetura interna do eForce (o WFM modernizado que está substituindo o SIGOD). A sessão de 12/08, com o desenvolvedor responsável pelo eForce, cobre exatamente essa lacuna: como o módulo de Ordem de Serviço grava dado, publica evento, e como os erros são tratados hoje. O achado central — ausência de DLQ em qualquer fila do domínio, admitida ao vivo como "problema crítico de infraestrutura" — não tinha até então nenhum artefato correspondente em 030-artefatos/, apesar de já existir como risco genérico (R13, R14) no HLD do Barramento. Este artefato fecha essa lacuna com evidência específica e o mecanismo técnico por trás do risco.

Midlers de incorporação por origem (eForce)

Confirmado pela documentação interna da wiki do eForce (E.Force / Modules / Ordem Servico) — nomes reais dos midlers que a transcrição só descreveu genericamente ("incorporador comercial", "incorporador técnico", carga em lote):

Midler	Origem que atende
ApiOntMiddleware	ADMS — único midler deste módulo com face direta para o ADMS
MsGodIncorpCom	Ordens de serviço comerciais
MsGodIncprpTec	Ordens de serviço técnicas (SGD e TS)
MsGodIncorpLote	Ordens de serviço do tipo lote
MsGodIncorpManut	Ordens de serviço de manutenção — desativado
MsGodIncorpProj	Ordens de serviço de projeto — desativado

Cada midler segue o padrão que o desenvolvedor descreveu como premissa arquitetural do eForce: nunca acessa banco de dados ou tópico Kafka do domínio diretamente — só conversa via API própria do eForce (midler de entrada) ou lê de uma fila e traduz para o formato de origem (midler de saída). A única exceção confirmada e reconhecida como dívida técnica: um midler de cadastro de equipe vindo do SIGOD legado grava direto no MongoDB via pipeline de CDC (Oracle GoldenGate + Kafka Connect), sem passar pela API — feito por prazo, não por decisão de design, segundo o próprio desenvolvedor.

Nomes reais do fluxo e confirmação de prazo (resposta ao Bloco 9, 29/08/2026) [D4]. A cadeia completa, com nomes de tópico e middleware antes não documentados: oracle_source_xst_com_(empresa).(owner).EQUIPE (captura CDC por empresa) → tópico multi-tenant oracle_stream.EQUIPE → middleware Energisa.God.Equipe.Legacy.Worker, que agrega dados de cadastro, grava no Mongo corporativo (mdb_modelo_crp) e produz no tópico WFM_MODELO_EQUIPE. A pergunta original — se existe previsão de o middleware migrar para gravação via API — foi respondida diretamente: sem previsão de implantação; o débito "deverá ser validado com a Squad do eForce", segundo a própria Energisa.

Precisão sobre a ordem exata deste fluxo de CDC (esclarecimento, 12/08/2026): a sequência correta é SIGOD → CDC (Oracle GoldenGate, captura) → Kafka Connect → tópico Kafka → midler de cadastro → grava direto no MongoDB do eForce. O Kafka fica entre a captura CDC e a escrita no MongoDB — não depois dela. Isso é um fluxo isolado, específico do cadastro de equipe (o "checkbox" de alteração de equipe no SIGOD, exemplo dado na sessão) — não deve ser confundido com o fluxo de dual-write de Ordem de Serviço descrito na seção seguinte (que é o inverso: o eForce grava primeiro, depois publica). São dois mecanismos diferentes dentro do mesmo domínio: um é SIGOD alimentando o eForce via CDC/Kafka (bypass de API, dívida técnica), o outro é o próprio eForce publicando eventos de OS no Kafka (dual-write, sem DLQ — achado central deste artefato).

Diagrama — Fluxo de Ordem de Serviço: dual-write e bifurcação de compatibilidade com o SIGOD

Achado central — ausência de DLQ, admitida como "problema crítico de infraestrutura"

Perguntado diretamente sobre estratégia de DLQ, o desenvolvedor responsável pelo eForce confirmou:

• Não existe Dead Letter Queue em nenhuma fila do domínio WFM/eForce hoje. O tratamento de erro é observar log e corrigir manualmente.
• O único mecanismo de proteção é retry — e como o Kafka processa sequencialmente por partição, uma mensagem presa em retry trava toda a partição (não só a chave problemática) até dar commit ou esgotar as tentativas. Se a política de retry for muito longa, o processamento trava; se esgotar sem sucesso, a mensagem é perdida silenciosamente.
• Confirmado, quando perguntado diretamente, que isso vale para todas as filas do domínio, e classificado pelo próprio desenvolvedor como "um problema crítico de infraestrutura" — sem banda para resolver, com sugestão de que a arquitetura corporativa poderia ajudar a construir uma solução padronizada e reaproveitável por outros domínios (ex.: Atendimento).
• Existe um mecanismo parcial de auto-correção: como o eForce persiste primeiro no MongoDB e só depois publica o evento, uma falha na publicação normalmente é corrigida no próximo evento relacionado à mesma OS. A exceção real de perda definitiva é o evento de criação da OS — se esse falhar, não há "segundo hit" para corrigir.

Este achado é evidência direta e mais específica para os riscos R13 (governança de eventos ausente) e R14 (consumidores frágeis pós-reinício, intervenção manual) já registrados no HLD do Barramento — as duas entradas foram atualizadas para referenciar este artefato.

Achado correlato — redrive: o dev já propõe um mecanismo próprio, por conta própria

Diferente do que uma versão anterior deste artefato registrava, redrive foi discutido de forma substantiva na sessão — em dois momentos distintos, ambos por iniciativa do próprio desenvolvedor, não da consultoria.

Primeiro momento (~00:20:07–00:20:41): ao explicar a ausência de DLQ, o dev propõe espontaneamente um sistema dedicado para gerenciar redrive de mensagens, pensado como padrão reutilizável entre filas — não como solução pontual para o domínio WFM/eForce:

"Eu queria até fazer um sisteminha à parte pra gerenciar esses redrive dessas mensagens, né? [...] pra não ter que toda vez que alguém for criar uma integração, criar uma DLQ, criar um processo de redrive [...] pra ter alguma coisa meio que padrão que toda fila [tivesse]. Teria a sua DLQ, né? E ele[?] pudesse gerenciar esses redrives, essas mensagens [...] pra gente ter uma consistência maior dos dados [...] mas isso aí é pra todos esses essas filas [...] inclusive do Barramento ou [não só ele]."

Segundo momento (~01:04:43–01:05:17): já na conversa sobre outbox pattern e MongoDB Change Streams (ver seção seguinte), o dev avalia redrive como o benefício concreto que o justificaria — mas hesita entre usar um mecanismo "de graça" do banco ou construir algo próprio mais simples primeiro:

"A questão do redrive de uma falha, de eu conseguir de certa forma reprocessar uma falha [...] alguma forma que já está implementada, que eu não preciso implementar nada pra funcionar e conseguir ser mais resiliente a essas falhas, pra mim, ok. Mas se não, eu acho que talvez a gente tem que implementar alguma coisa pra ser mais resiliente às falhas [...] no primeiro momento deixar mais consistente e depois a gente migrar para uma solução mais eficiente."

Isso muda o enquadramento do achado central (seção acima): não é só "não existe DLQ, tratamento é manual" — existe, do lado do próprio time do eForce, uma proposta concreta e já cogitada de mecanismo de redrive padronizado, sem banda para executá-la. É evidência adicional, e mais forte, para o pedido de solução corporativa já registrado no "Próximo passo" deste artefato.

Achado correlato — dual-write sem transação distribuída

O eForce grava no MongoDB e só depois publica no Kafka como dois passos sequenciais e não-atômicos (não é outbox pattern — é grava-então-publica direto). O próprio desenvolvedor reconhece o padrão como frágil.

Correção (13/08/2026): a menção a outbox pattern com MongoDB Change Streams como correção estava atribuída erroneamente ao desenvolvedor nesta seção — foi um brainstorm do próprio Castellani durante a sessão, não algo proposto, avaliado ou planejado pela Energisa ou pelo time do eForce. Não existe hoje nenhum plano, cronograma ou avaliação formal desse mecanismo — segue como recomendação preliminar da consultoria (dual-write sem transação distribuída é um padrão frágil e outbox é a correção arquitetural usual), não como achado da sessão. Vale notar, à parte, que a mesma classe de recomendação (outbox/CDC) já havia sido levantada pela consultoria de forma independente na sessão de 11/08 sobre materialização de views/event sourcing — mas isso reflete a consultoria enxergando a mesma lacuna estrutural se repetir em domínios diferentes, não duas equipes da Energisa convergindo para a mesma conclusão por conta própria.

Esclarecimento — RabbitMQ não deve ser generalizado como "legado"

Nesta sessão, o RabbitMQ foi tratado como parte legítima e não-descontinuada do ecossistema de mensageria da Energisa (instância corporativa disponível, biblioteca de mensageria interna agnóstica entre RabbitMQ e Kafka). Isso não contradiz o achado já documentado em fluxos-atendimento-adms.md (Diagrama 10, R43) de que o caminho ADMS→MSGOT via RabbitMQ é uma rota legada em processo de migração para Kafka — são afirmações sobre escopos diferentes (o produto RabbitMQ em geral vs. um fluxo específico planejado para ser descontinuado). Registrado aqui para que nenhum artefato futuro generalize "RabbitMQ = legado" a partir do achado R43.

Pendências que esta sessão NÃO resolveu

Para não fechar por engano itens que seguem em aberto:

• Volumetria e janelas do motor de cálculo IQOS — pendência já registrada em integracao-wfm-adms.md e em 080-diagnostico/matriz-achados-lacunas.md (D4), depende de especialista específico (Eduardo), não tratado nesta sessão.
• R07 (rota externa), cobertura de Schema Registry no domínio WFM (hoje 0%) e a proposta de "agente" para substituir RPA na carga incremental de equipes — nenhum desses temas foi abordado nesta sessão; seguem com o status já registrado nos artefatos correspondentes.

Próximo passo

Considerar registrar um risco específico de "ausência de padrão corporativo de DLQ e redrive" (candidato a R45+) na matriz de riscos consolidada, já que o próprio desenvolvedor sugeriu que a solução deveria ser corporativa, não reinventada por domínio — hoje o achado só existe como reforço textual de R13/R14, mas o mecanismo técnico (retry bloqueia partição inteira), a proposta espontânea de um "sisteminha" de redrive padronizado (seção "Achado correlato — redrive" acima) e o pedido explícito de ajuda da arquitetura corporativa sugerem que merece linha própria na Fase 4 (To-Be), incluindo redrive como parte do escopo — não só a DLQ isolada.