Pular para conteúdo

Proposta 2 — Oracle AQ Ponto-a-Ponto (sem Kafka, sem CDC) para o Hop MsAttOcorrenciaTecnica → MsCrmMiddleware

Status: Brainstorming de consultoria — ver aviso metodológico Resolve: o mesmo dual write da Proposta 1, restrito ao hop MsAttOcorrenciaTecnica → MsCrmMiddleware (tópico crm_registra_ocorrencia_sistema_tecnico) — alternativa que elimina outbox e captura CDC por completo Recomendação: confirmado em 29/08/2026 que o tópico é hoje estritamente 1:1 — ver "Validação (29/08/2026)" abaixo. Três outros hops do mesmo domínio também confirmados como candidatos (o terceiro, crm_encerramento_ocorrencia_tecnica, confirmado em 02/09/2026); dois hops que a versão anterior desta proposta cogitava generalizar foram descartados por fan-out real encontrado nos consumer groups de produção, e um terceiro (crm_clientes_afetados_desligamento_programado) foi descartado em 02/09/2026 por cruzar fronteira de domínio, apesar de confirmado 1:1.

Contexto

Diferente da Proposta 1, esta não nasce de uma ideia nova de consultoria — formaliza uma recomendação que o próprio Castellani já registrou em sessão real com a Energisa, ainda sem Ata formal (fluxos-atendimento-adms.md, achado da sessão de 24/07/2026, linha 444):

"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 [...]. Reservar o Kafka/Confluent para eventos que são, de fato, fatos de domínio com múltiplos consumidores entre domínios diferentes."

Norberto (Energisa) confirmou, na mesma sessão, que já vinha pensando na mesma direção. A mesma regra já aparece citada, de passagem, em propostas-wfm-eforce/proposta-1-outbox-knative-inbox.md (linha 73), especificamente apontando os microsserviços de Atendimento como exemplo de domínio onde ela se aplicaria.

O hop MsAttOcorrenciaTecnica → MsCrmMiddleware é candidato direto a essa regra: o mapeamento de fluxo (fluxos-atendimento-adms.md, linha 517) documenta produtor único e consumidor único para crm_registra_ocorrencia_sistema_tecnico — os dois serviços .NET do mesmo domínio de Atendimento (linhas 43-44 do mesmo artefato). É diferente do hop anterior no mesmo fluxo (crm_chamada_ocorrencia_tecnica, WSROT → MsAttOcorrenciaTecnica), que cruza de fora do domínio (canais digitais/convencional) para dentro dele — ali o Kafka corporativo continua sendo a escolha certa, por atravessar fronteira de sistemas. Este segundo hop é inteiramente interno ao domínio de Atendimento.

O que esta proposta assume e ainda não está confirmado: o mapeamento produtor/consumidor do fluxo documenta o que foi levantado para este caso de uso específico — não é, por si só, confirmação de que nenhum outro consumer group já lê ou está planejado para ler esse tópico. O inventário de produção do Confluent (topicos_detalhado_latest.md) lista partições, réplicas e presença de schema por tópico, mas não consumer groups. Essa confirmação é pré-requisito antes de agir sobre esta proposta — ver "Riscos e ressalvas".

Diagrama — mesmo hop, duas alternativas

Hop MsAttOcorrenciaTecnica → MsCrmMiddleware — Oracle AQ ponto-a-ponto

Design patterns aplicados

Padrão Papel nesta proposta
Enqueue transacional nativo (Oracle AQ) DBMS_AQ.ENQUEUE na mesma transação da escrita de negócio — atomicidade vem de graça do commit único, sem outbox table separada e sem captura externa
Fila ponto-a-ponto (não pub/sub) Trade-off deliberado: um produtor, um consumidor, sem fan-out — é exatamente o que a regra de triagem de Castellani/Norberto define como candidato a sair do Kafka corporativo

Por que Oracle AQ, e não Kafka, para este hop específico

  • Elimina a Proposta 1 inteira, não só simplifica. Não há outbox table, não há XStream Outbound Server, não há cliente customizado, não há Kafka Connect. O enqueue é uma instrução DML a mais dentro da mesma transação — o problema de dual write deixa de existir por construção, não por um mecanismo de captura compensatório.
  • Ambos os lados já são Oracle-aware. MsAttOcorrenciaTecnica já grava no ATD; MsCrmMiddleware já é um serviço .NET, com suporte maduro a AQ via ODP.NET (OracleAQQueue) — não é uma tecnologia nova a introduzir no ambiente.
  • Não é generalizável aos outros tópicos do mesmo fluxo. crm_chamada_ocorrencia_tecnica (WSROT → MsAttOcorrenciaTecnica) cruza a fronteira canais-digitais/atendimento-convencional → domínio de Atendimento — continua sendo tráfego entre sistemas diferentes, onde a decoupling do Kafka pub/sub vale o custo. Esta proposta é estritamente sobre o segundo hop.

Cenários de aplicação

Cenário Proposta se aplica?
Hop MsAttOcorrenciaTecnica → MsCrmMiddleware, confirmado ponto-a-ponto Sim — é o caso desta proposta
Hop WSROT → MsAttOcorrenciaTecnica (crm_chamada_ocorrencia_tecnica) Não — cruza fronteira de domínio/sistema, Kafka continua sendo a escolha certa
Dual write do lado do Sigode (MongoDB) Não — mesmo escopo excluído já registrado na Proposta 1
Tópico com mais de um consumidor hoje ou planejado Não — nesse caso a Proposta 1 (mantém Kafka) é a correta, não esta

Validação (29/08/2026) — consumer groups reais de produção

Cruzando o mapeamento produtor/consumidor de fluxos-atendimento-adms.md com os consumer groups reais da extração de 25/08/2026 (relatorio_prd_20260825_165932.csv, mesmo dado usado na validação da Proposta 1 de roteamento via Debezium), para os 10 tópicos do domínio CRM/Atendimento:

Tópico Produtor → Consumidor (fluxo documentado) Consumer groups reais Status
crm_registra_ocorrencia_sistema_tecnico MsAttOcorrenciaTecnica → MsCrmMiddleware 1 (m-s-crm-middleware) Confirmado 1:1 — hop desta proposta
crm_retorno_ocorrencia_sistema_tecnico MsCrmMiddleware → MsAttOcorrenciaTecnica 1 (m-s-att-ocorrencia-tecnica) Confirmado 1:1 — candidato adicional, mesmo fluxo
crm_atualizacao_cliente_adms MsAttMonitoraInstalacao → MsAttCliente 1 (energisa-ms-att-cliente-core-services-entry-point-service) Confirmado 1:1 — candidato adicional, fluxo diferente
crm_comunicacao MsAttFiltroIncidentes → MsAttComunicacao 2 (energisa-ms-att-comunicacao-worker-worker; m-s-c-c-a = MSCCA, canais digitais — identificado 02/09/2026) Descartado — fan-out real não documentado no fluxo
crm_clientes_afetados_desligamento_emergencial MsAttFiltroIncidentes → MsAttDesligamentoEmergencial 3 (worker; m-s-c-c-a = MSCCA; m-s-c-o-m-f-e-c-l-i = MSCOMFECLI — ambos canais digitais, identificados 02/09/2026) Descartado — fan-out real não documentado no fluxo
crm_chamada_ocorrencia_tecnica WSROT → MsAttOcorrenciaTecnica 1 (m-s-att-ocorrencia-tecnica) Excluído por desenho — 1:1 de fato, mas cruza fronteira de domínio (WSROT é externo ao Atendimento)
crm_ordem_servico não mapeado neste fluxo 1 (ksqlDB, CSAS_CRM_CLIENTES_AFETADOS_INTERMEDIARIO_STREAM) Não se aplica — único consumidor é processamento ksqlDB, não um microsserviço
crm_clientes_afetados_desligamento_programado MsAttDesligamentoProgramado → MSCCA (identificado 02/09/2026 — não "SAC Proativo") 1 (m-s-c-c-a) Descartado — 1:1 confirmado, mas MSCCA é canais digitais, não Atendimento; cruza fronteira de domínio (mesmo motivo de exclusão de crm_chamada_ocorrencia_tecnica acima)
crm_encerramento_ocorrencia_tecnica WSROT (confirmado 02/09/2026, equipe do CRM) 1 (m-s-att-ocorrencia-tecnica = MsAttOcorrenciaTecnica) Confirmado 1:1, dentro do domínio de Atendimento — candidato adicional. Hipótese forte (não confirmada literalmente) de que é o mesmo tópico que crm_callback_ocorrencia_tecnica, citado com esse nome em fluxos-atendimento-adms.md (Diagrama 4) mas ausente do inventário real — ver nota lá
crm_atualizacao_cliente_adms_demanda não mapeado neste fluxo 0 Resolvido (03/09/2026, Izabooh): não está mais em uso. Consistente com o consumer group zero já observado em 25/08/2026 — não é lacuna de inventário, é tópico realmente parado. Não se aplica a esta proposta (não há hop ativo para migrar); candidato a descomissionamento, não a Oracle AQ

Achado colateral: os dois descartes acima também expõem uma imprecisão em fluxos-atendimento-adms.md — a tabela de produtor/consumidor daquele artefato documenta crm_comunicacao e crm_clientes_afetados_desligamento_emergencial como 1:1, mas a produção real tem consumidores adicionais não documentados ali. Ver nota adicionada naquele artefato.

m-s-c-c-a e m-s-c-o-m-f-e-c-l-i identificados em 02/09/2026 (equipe do CRM/Lucas): m-s-c-c-a é o MSCCA, serviço do time de canais digitais que lê os três tópicos onde aparece (crm_clientes_afetados_desligamento_programado, crm_clientes_afetados_desligamento_emergencial, crm_comunicacao) e preenche uma collection própria no MongoDB do time para cada um — confirma o padrão de agregador cross-tópico já suspeitado, não um consumidor ponto-a-ponto de um único hop. m-s-c-o-m-f-e-c-l-i é o MSCOMFECLI, que gera os avisos de desligamento emergencial ao cliente via SAC Proativo. Nenhum dos dois pertence ao domínio de Atendimento (MsAtt*) — são canais digitais consumindo tópicos publicados por Atendimento, cruzando fronteira de domínio. Isso fecha a identificação, mas também fecha a decisão sobre crm_clientes_afetados_desligamento_programado no sentido oposto ao que se esperava: mesmo sendo 1:1 confirmado, não é candidato a esta proposta, pelo mesmo critério de fronteira de domínio já usado para excluir crm_chamada_ocorrencia_tecnica.

Riscos e ressalvas

  • Fan-out confirmado por consumer groups reais (29/08/2026) para o hop desta proposta — ver "Validação" acima. crm_registra_ocorrencia_sistema_tecnico tem hoje 1 único consumer group. Essa confirmação cobre o instantâneo de 25/08/2026 — não é garantia de que nenhum novo consumidor será provisionado no futuro; a decisão de generalizar esta proposta a outro tópico deve repetir essa checagem, não presumir o padrão por analogia de nome de serviço (foi exatamente por pular essa checagem que crm_comunicacao e crm_clientes_afetados_desligamento_emergencial pareciam 1:1 no fluxo documentado e não são).
  • Reintroduz um segundo paradigma de integração fora do barramento corporativo. O restante do assessment trata o Kafka/Confluent como o barramento único da Energisa, e já tratou o desvio dele como risco em outro contexto (R43, bifurcação RabbitMQ/MSGOT). Mesmo com a regra de triagem já articulada por Castellani e endossada informalmente por Norberto, cada hop migrado para AQ é um lugar a mais para operar e depurar fora da observabilidade central do Confluent — vale que essa decisão seja explícita, não decorrência automática da regra de triagem.
  • Mudança nos dois lados, não só no produtor. Diferente da Proposta 1 (que só troca o mecanismo de publicação do MsAttOcorrenciaTecnica), esta exige que MsCrmMiddleware também pare de consumir Kafka e passe a fazer dequeue de AQ — dobra a superfície de mudança em relação à Proposta 1.
  • Perde a ferramentagem de observabilidade já investida no Confluent para este hop especificamente — monitoramento, Control Center, e qualquer processamento futuro via ksqlDB que viesse a depender deste tópico deixariam de enxergá-lo.
  • Proposta 1 e Proposta 2 são alternativas mutuamente exclusivas para o mesmo hop, não complementares. Escolher uma substitui a outra — não faz sentido implementar as duas para crm_registra_ocorrencia_sistema_tecnico.

Recomendação

  1. ~~Confirmar, via inventário real de consumer groups do Confluent, que crm_registra_ocorrencia_sistema_tecnico é hoje estritamente 1:1 e sem plano de novos consumidores.~~ — feito em 29/08/2026, ver "Validação" acima. Confirmado.
  2. Esta proposta é a de menor esforço de engenharia entre as duas (elimina XStream por completo) — pilotar no hop original (crm_registra_ocorrencia_sistema_tecnico) e, se o piloto validar bem, estender aos outros candidatos já confirmados por consumer group real: crm_retorno_ocorrencia_sistema_tecnico (mesmo fluxo, direção oposta), crm_atualizacao_cliente_adms (fluxo distinto, MsAttMonitoraInstalacao → MsAttCliente) e crm_encerramento_ocorrencia_tecnica (WSROT → MsAttOcorrenciaTecnica, confirmado 02/09/2026 — mesma ressalva de fronteira de domínio do hop original desta proposta não se aplica aqui, já que ambos os lados confirmados são Atendimento).
  3. Não generalizar a MsAttComunicacao (crm_comunicacao) nem a MsAttDesligamentoEmergencial (crm_clientes_afetados_desligamento_emergencial) — a sugestão de generalização de uma versão anterior desta proposta assumia 1:1 com base só no fluxo documentado; a validação de 29/08/2026 encontrou fan-out real (2 e 3 consumer groups) em ambos. Permanecem no Kafka.
  4. ~~Antes de decidir sobre crm_clientes_afetados_desligamento_programado, identificar o que é o consumidor "SAC Proativo"/m-s-c-c-a e se ele está dentro do domínio de Atendimento~~ — resolvido em 02/09/2026: é o MSCCA, canais digitais, fora do domínio de Atendimento. Decisão: não generalizar esta proposta a crm_clientes_afetados_desligamento_programado — mesmo critério de fronteira de domínio usado para excluir crm_chamada_ocorrencia_tecnica, apesar do tópico ser 1:1 confirmado.
  5. Se houver dúvida sobre fan-out em algum hop específico, ou se a consistência com o barramento único for um princípio arquitetural que a Energisa queira preservar mesmo a um custo de engenharia maior: seguir com a Proposta 1 para esse hop em vez desta.
  6. crm_atualizacao_cliente_adms_demanda confirmado fora de uso (Izabooh, 03/09/2026) — fora do escopo desta proposta (não há hop ativo), mas candidato a descomissionamento do tópico em si; não investigado aqui se há retenção de dados a preservar antes de remover.

Ver também