📌 Resumo do Ecossistema
mapeados
Kafka únicos
Sensedia
documentados
integrados
~130 tópicos Kafka únicos (ContextDefinition + CRM/SGM/IQOS/outbound) e filas Redis dedicadas no fluxo de callback técnico.
Agrupamentos: EMR/EMS=3, EPB/ESE=1, EMT/ETO/EAC/ERO=2.
PRD:
adms-pr, sigod-pr, call-back, api-comercial · DEV/HML: adms-ds, adms-ho.
Energisa.ELK.ConnectorCore), JFrog Artifactory, Unleash (feature flags), Sensedia, ksqlDB, Schema Registry.
🔁 Visão de Ciclo — Como os Fluxos 1 a 4 conversam entre si
Os Fluxos 2, 3 e 4 NÃO são lineares — há retorno de status do SIGOD para o ADMS (Fluxo 3) e propagação simultânea para os canais de atendimento (Fluxo 4).
Setas pulsantes (Passo 6) indicam ciclo bidirecional recorrente a cada despacho ou encerramento de OS.
📲 Fluxo 1 — Atendimento ao Cliente → ADMS
Chatbot · URA / IVR
SIATT
PDA.SOLICITACAO_OS_PDA e o worker invoca o WSROT via HTTP..SolicitacaoOsPda
✅ O que faz: API REST que recebe a abertura de ocorrências técnicas de múltiplos canais: Energisa ON, agência virtual, chatbot, URA/IVR, SIATT (canais convencionais, desde a entrada do ADMS) e PDA (eletricista em campo via OrdemServico.Legacy.Worker). Valida o formulário, gera protocolo de atendimento e o retorna sincronamente ao canal chamador. Enfileira em Kafka (ADMS) para processamento assíncrono.
🛑 Se parar: Nenhuma ocorrência técnica entra no pipeline, independentemente do canal de origem. Todo o atendimento técnico ao cliente para.
📌 Regras:
POST /OcorrenciaTecnica/valida formulário, gera protocolo e retorna ao canal de forma síncrona.- Empresas ADMS: publica
crm_chamada_ocorrencia_tecnicapara processamento no MSAttOcorrenciaTecnica. - Empresas não-ADMS: roteia para RabbitMQ/MSGOT pelo caminho legado, conforme parâmetro
SIATT:70. - Avisos de restabelecimento publicam evento para o subfluxo MSFaltaEnergiaCallback; não atribuir tópico genérico de callback CRM ao WSROT sem evidência.
- Redis é usado como cache anti-duplicidade por CDC/empresa por aproximadamente 2 minutos.
Ocorrência técnica e restabelecimento
POST /OcorrenciaTecnica/→ registra OS técnica; valida canal, gera protocolo e inicia fluxo ADMS ou legado.GET /OcorrenciaTecnica/ServicosTecnicos/{codigoEmpresaWeb}→ lista serviços técnicos por grupo/empresa.POST /OcorrenciaTecnica/AvisoReestabelecimento→ recebe aviso "Minha Energia Voltou" por CDC/instalação e publica para callback.POST /OcorrenciaTecnica/AvisoReestabelecimentoPorProtocolo→ recebe aviso de restabelecimento vinculado a protocolo.POST /OcorrenciaTecnica/DefeitoFalhae/NivelTensao→ obsoletos; redirecionam paraPOST /OcorrenciaTecnica/.
Callback e mailing
PUT /CallBack/AtualizaMailling→ atualiza lista de mailing de callback.GET /CallBack/ListaMailingTelefone/{codEmpresaWeb}→ recupera lista de mailing OLOS mais recente.GET /CallBack/ListaMailingTelefone/{codEmpresaWeb}/{codigoLista}→ recupera lista de mailing OLOS por código.GET /CallBack/Historico/Protocolo/{codigoEmpresaWeb}/{protocolo}→ consulta histórico de callbacks por protocolo.GET /CallBack/Historico/Ocorrencia/{codigoEmpresaWeb}/{ocorrencia}→ consulta histórico de callbacks por ocorrência.POST /CallBack/EncerraOcorencia→ obsoleto/desabilitado; retorna 405.
Grupo A, integrações e saídas
POST /ServicosGrupoA/DesligamentoProgramado→ solicita OS de desligamento/religação para clientes Grupo A.crm_chamada_ocorrencia_tecnica→ abertura de ocorrência para o MSAttOcorrenciaTecnica.crm_encerramento_ocorrencia_tecnica→ encerramento/restabelecimento para o MSAttOcorrenciaTecnica.RabbitMQ ordemservico.tecnico.create.crm→ caminho legado para empresas não-ADMS, consumido pelo MSGOT.
crm_chamada_ocorrencia_tecnicacrm_encerramento_ocorrencia_tecnica → MSAttOcorrenciaTecnica✅ O que faz: Worker principal do fluxo de abertura de ocorrência técnica. Consome os tópicos do WSROT, grava a ocorrência no Oracle ATD (protocolo, atendimento, ligações, interações), grava no MongoDB (OcorrenciaTecnica) e produz crm_registra_ocorrencia_sistema_tecnico para envio ao ADMS.
🛑 Se parar: Ocorrências de atendimento ao cliente não são registradas em nenhum banco. O ciclo completo de abertura de OS para, independentemente do canal de origem (Energisa ON, chatbot, URA).
📌 Regras:
- Consome crm_chamada_ocorrencia_tecnica e crm_encerramento_ocorrencia_tecnica; ambos produzem em crm_registra_ocorrencia_sistema_tecnico (diferença apenas no conteúdo da mensagem)
- Consome crm_retorno_ocorrencia_sistema_tecnico (confirmação do ciclo com o ADMS)
- Grava em 5 tabelas Oracle ATD + MongoDB
- Produz crm_registra_ocorrencia_sistema_tecnico → MSCrmMiddleware → ADMS
vai ao Fluxo 3
✅ O que faz: Worker "Minha Energia Voltou" — encerramento proativo de OS técnica quando a energia é restabelecida. Consome a fila RabbitMQ publicada pelo WSROT (endpoints AvisoReestabelecimento), recupera dados da comunicação no Oracle ATD, verifica feature flags por empresa e encerra a OS via ADMS (Kafka: crm_encerramento_ocorrencia_tecnica) ou ApiGodTecnica (HTTP POST /EncerramentoOT), conforme parâmetro global 70. Publica wfm_callback_realizado para o WFM e possui retentativa automática por até 240 minutos.
🛑 Se parar: Encerramento proativo de OS não ocorre quando energia é restabelecida. Clientes continuam com OS abertas mesmo após o restabelecimento.
📌 Regras:
- Consome RabbitMQ exchange
ordemservico.tecnico.falta-energiaqueuecallback.encerra - Feature flag "MinhaEnergiaVoltou" por empresa (MongoDB FeatureFlags)
- Decisão: Param global 70 == "ADMS" → Kafka; senão → HTTP ApiGodTecnica
- Retentativa: até 240 min via RabbitMQ retry queue
- Empresas suportadas: 1, 3, 5, 6, 8, 9, 10, 20, 30
✅ O que faz: Microserviço (equivalente ao MsAttOcorrenciaTecnica). Consome crm_registra_ocorrencia_sistema_tecnico, chama o ADMS via Sensedia (POST /TroubleTickets/) e produz crm_retorno_ocorrencia_sistema_tecnico com a resposta do ADMS (ciclo de confirmação).
🛑 Se parar: Ocorrências técnicas de atendimento ao cliente não chegam ao ADMS. Nenhum Trouble Ticket é enviado ao ADMS; os canais não recebem retorno de confirmação.
📌 Regras:
- Ciclo: Kafka → MSCrmMiddleware → Sensedia (POST /TroubleTickets/) → ADMS → Kafka (retorno)
- crm_retorno_ocorrencia_sistema_tecnico é consumido pelo MSAttOcorrenciaTecnica para confirmar o ciclo
CRM adapter
/TroubleTickets/
✅ O que faz: Sistema legado ativo em paralelo ao fluxo Kafka principal. Consome a fila RabbitMQ ordemservico.tecnico.create.crm e processa criações de OS técnicas oriundas do CRM via broker RabbitMQ (não-Kafka).
🛑 Se parar: OSs técnicas geradas via fila RabbitMQ deixam de ser processadas. Por ser independente do fluxo Kafka, falha no MSGOT não impacta o fluxo principal — mas OSs dessa fila ficarão pendentes.
📌 Regras:
- Ativado quando o SIATT:70 indica caminho não-ADMS (WSROT → RabbitMQ)
- Broker: RabbitMQ (independente do Kafka)
- Queue:
ordemservico.tecnico.create.crm - Monitorar via RabbitMQ Management UI — fila não deve acumular mensagens sem consumidores ativos
crm_chamada_ocorrencia_tecnica (MSAttOcorrenciaTecnica)
▶
kafka-consumer-groups --bootstrap-server <broker> --describe --group msattocorrenciatecnica-group. No Datadog: APM → Services → msattocorrenciatecnica.oc get pods -n adms | grep msattocorrenciatecnica. 2) Checar logs: ELK index msattocorrenciatecnica (⚠️ índice não confirmado — localizar antes de um incidente). 3) Verificar conectividade com Oracle ATD.crm_encerramento_ocorrencia_tecnica (MSAttOcorrenciaTecnica)
▶
crm_encerramento_ocorrencia_tecnica. Datadog: service msattocorrenciatecnica.wsrot).crm_registra_ocorrencia_sistema_tecnico (MSCrmMiddleware)
▶
crm_registra_ocorrencia_sistema_tecnico. ELK: mscrmiddleware. Datadog: service mscrmiddleware.oc get pods -n adms | grep mscrmiddleware. 2) Testar health check do Sensedia CRM adapter. 3) Verificar se o ADMS está respondendo no endpoint POST /TroubleTickets/.SELECT * FROM ATT_ATENDIMENTOS WHERE DT_CADASTRO > SYSDATE - 1/24 ORDER BY DT_CADASTRO DESC. Checar também: COMUNICACOES, ATT_LIGACOES, ATT_INTERACAO, PROTOCOLO_ATENDIMENTO.ordemservico.tecnico.create.crm acumulando mensagens
▶
ordemservico.tecnico.create.crm. Verificar: "Messages Ready" (pendentes), "Consumers" (deve ser > 0), "Message rates" (deve haver consumo ativo).oc get pods -n adms | grep msgot. 2) Reiniciar consumer se estiver parado. 3) Monitorar se a fila começa a esvaziar após restart.📥 Fluxo 2 — ADMS → SIGOD (Inbound ONT)
✅ O que faz: Sistema de gestão de distribuição de energia elétrica (ADMS). Origem das Ordens de Serviço técnicas no fluxo inbound: envia OSs ao SIGOD via SOAP através do Sensedia ONT adapter para que equipes de campo sejam despachadas.
🛑 Se parar: Nenhuma OS nova chega ao SIGOD. Despachantes ficam sem novas OSs para alocar. Sistema externo — escalar para equipe do ADMS.
📌 Regras:
- Protocolo de envio: SOAP via Sensedia ONT adapter
- Sistema externo — fora do controle do time SIGOD
- Verificar disponibilidade via portal Sensedia → API ONT → logs
✅ O que faz: Recebe eventos SOAP do ADMS/OMS via Sensedia ONT adapter (incidentes, trouble tickets e usage points), valida a estrutura da mensagem, usa buffer Kafka interno (wfm_outage_notification_interface) e delega a persistência para a ApiGodOrdemServico via HTTP REST, que cria/atualiza a OS no SIGOD. Não produz wfm_ordem_servico diretamente.
🛑 Se parar: OSs do ADMS não entram no SIGOD. Despachantes ficam sem novas OSs na tela. Todo o pipeline ADMS→SIGOD para.
📌 Regras:
- Usa tópico interno wfm_outage_notification_interface como buffer (produz e consome). Saída efetiva é via HTTP REST para ApiGodOrdemServico.
- A validação rejeita mensagens malformadas — verificar ELK por erros de parse
📌 Saída para SIGOD: via HTTP REST → ApiGodOrdemServico (não produz wfm_ordem_servico diretamente)
📌 UnidadesConsumidorasProcessorWorker consome o evento
ChangedIncidentUsagePoints (originado no POST /IncidentUsagePointsService.asmx) e chama POST api/OrdemServicoUnidadeConsumidora para atualizar as UCs afetadas
✅ O que faz: API REST + SignalR Hub. Recebe chamadas HTTP da ApiOntMiddleware (POST para criar, PATCH para atualizar, POST para UCs/chamadas afetadas). Grava no MongoDB, consulta Oracle (FAR, ATD, PDA, ITG) para enriquecimento de dados e notifica o frontend SIGOD em tempo real via SignalR.
🛑 Se parar: Frontend SIGOD não recebe atualizações em tempo real. Despachantes veem tela desatualizada.
📌 Regras:
OrdemServicoController—POST api/OrdemServicocria nova OS;PATCH api/OrdemServicoatualiza parcialmente (sem{id}no path, corpo comIdExterno)OrdemServicoDispositivoController—PATCH api/OrdemServicoDispositivoatualiza dispositivo/Trafo afetadoOrdemServicoChamadaController—POST api/OrdemServicoChamadaatualiza chamadas/TroubleTicketsOrdemServicoUnidadeConsumidoraController—POST api/OrdemServicoUnidadeConsumidoraatualiza UCs afetadas, chamado peloUnidadesConsumidorasProcessorWorkerda ApiOntMiddleware após o eventoChangedIncidentUsagePoints(IncidentUsagePointsService.asmx)- SignalR Hub transmite eventos para todos os clientes conectados (despachantes online)
NotificationChangeWorker(hosted service interno) — consomewfm_ordem_servico_situacao_alterada(produzido peloOrdemServico.Worker) e faz push SSE viaGET /api/OrdemServicoSituacaoSse/streampara o WFMDashboard [NOVO — 23/06/2026]
✅ O que faz: Worker principal do fluxo inbound. Consome wfm_ordem_servico (barramento central de OSs) e redistribui para tópicos semânticos de status (criado, agendado, programado, despachado, encerrado, cancelado, arquivado) com base no campo Situacao da mensagem. Também persiste no MongoDB (mdb_ordem_servico_crp) e sincroniza coleção legado.
🛑 Se parar: ⚠️ CRÍTICO — nenhum tópico de status é produzido. Todos os middlewares outbound (Fluxo 3), canais de atendimento (Fluxo 4), SGM e IQOS param de receber atualizações de OS. Toda a cadeia downstream para.
📌 Regras:
- 3 instâncias paralelas (
ProcessaAtualizacaoOsWorkerMultipleConsumers) — aumenta throughput - Lê dados complementares do Oracle PDA (
DESPACHO_OS,MOV_DESPACHO) para enriquecer a mensagem - Re-enfileira OS parent para atualização recursiva quando necessário
- Parâmetros Oracle (
SIGOD-1,SIGOD-2,SIGOD-10) controlam limites de compensação e prazo de agendamento
✅ O que faz: Consome todos os tópicos de status de OS produzidos pelo OrdemServico.Worker (criado, cancelado, despachado, arquivado, encerrado) e grava nas tabelas Oracle PDA (SGD_SIGOD, MOV_DESPACHO) para manter o sistema legado Oracle sincronizado com o SIGOD.
🛑 Se parar: Tabelas legado Oracle PDA ficam desatualizadas. Sistemas que consultam PDA diretamente (relatórios, integrações legadas) verão dados defasados.
📌 Regras:
- Grava em SGD_SIGOD para cada mudança de status
- Grava em MOV_DESPACHO para status de despacho
- Não envia para o ADMS — é exclusivamente sincronização do legado Oracle
- Pertence ao Fluxo 2 (Inbound) pois é consumidor direto dos tópicos produzidos pelo OrdemServico.Worker
✅ O que faz: Banco de dados Oracle PDA (legado). Destino de escrita do MSGodLegSci: mantém as tabelas SGD_SIGOD e MOV_DESPACHO sincronizadas com o SIGOD para que sistemas legados consultem o estado atual das OSs.
🛑 Se parar: Sistemas legados que consultam o Oracle PDA ficam com dados defasados. Banco externo — verificar conectividade e locks via DBA.
apiontmidleware. Filtrar por erros HTTP 5xx ou exceções SOAP. Também verificar logs do Sensedia ONT adapter no portal Sensedia → API ONT → logs de requisição recentes.oc get pods -n adms | grep apiontmidleware. 2) Checar se o pod está em CrashLoopBackOff. 3) Testar endpoint SOAP manualmente via Postman/SoapUI. 4) Verificar configurações do Sensedia ONT adapter (certificado/token válido).wfm_outage_notification_interface e HTTP POST/PATCH ApiGodOrdemServico
▶
wfm_outage_notification_interface (buffer interno: deve ter produção e consumo). ELK: apiontmidleware — filtrar por erros REST ao chamar ApiGodOrdemServico (HTTP POST/PATCH). A ApiOntMiddleware não produz wfm_ordem_servico diretamente — quem produz é a ApiGodOrdemServico.wfm_outage_notification_interface no Kafka Manager — lag crescente indica backpressure. 3) Checar conectividade com o broker Kafka e com a ApiGodOrdemServico.mdb_ordem_servico_crp, collections ordem_servico e ordem_servico_chamada. Checar documentos inseridos nas últimas horas. ELK: apiontmidleware para erros HTTP REST e apigodordemservico para erros de persistência.wfm_ordem_servico — OrdemServico.Worker está processando?
▶
kafka-consumer-groups --bootstrap-server <broker> --describe --group ordemservico-worker-group. Datadog: APM → Services → ordemservicoworker → Kafka metrics. ELK: ordemservicoworker.oc get pods -n adms | grep ordemservico-worker. 2) Checar logs ELK por exceções. 3) Se pods estão OK mas lag cresce, investigar lentidão no MongoDB ou Oracle que pode estar bloqueando o processamento. 4) ⚠️ Status atual no Datadog pode estar CRITICAL — verificar imediatamente.ordemservicoworker)
▶
ordemservicoworker. Verificar: Error Rate (%), Latência P95, Throughput (requests/seg). Comparar com baseline do dia anterior.wfm_ordem_servico. 3) Analisar se é um erro pontual (mensagem malformada) ou sistêmico (dependência indisponível). 4) Se sistêmico, verificar MongoDB e Oracle downstream.wfm_ordem_servico_criado, wfm_ordem_servico_cancelado, wfm_ordem_servico_despachado, wfm_ordem_servico_arquivado, wfm_ordem_servico_encerrado. ELK: msgodlegsci. Oracle PDA: SELECT COUNT(*) FROM SGD_SIGOD WHERE DT_ATUALIZACAO > SYSDATE - 1/24.SGD_SIGOD e MOV_DESPACHO. 3) Verificar se há lock em tabelas Oracle (query V$LOCKED_OBJECT no PDA). 4) Confirmar permissões do usuário Oracle.📤 Fluxo 3 — SIGOD → ADMS (Outbound)
✅ O que faz: Referência cruzada — detalhamento completo no Fluxo 2. Neste Fluxo 3, o OrdemServico.Worker contribui com os eventos de status de OS consumidos pelos middlewares outbound: wfm_ordem_servico_criado, wfm_ordem_servico_despachado, wfm_ordem_servico_encerrado, wfm_ordem_servico_cancelado e wfm_ordem_servico_arquivado.
🛑 Se parar: ⚠️ CRÍTICO — eventos de status de OS não chegam aos middlewares outbound. ADMS não recebe atualizações de status do SIGOD.
⟳
wfm_outage_notification_interface — buffer interno ApiOntMiddleware, consumido por MSOSRMidleware►
wfm_ordem_servico_dispositivo — produzido por ApiGodOrdemServico, consumido por MSOSRMidleware►
wfm_coordenada_equipe — produzido por MSGodCartografia, consumido por MSAVLMidleware►
wfm_coordenada_veiculo — produzido por MSGodCartografia, consumido por MSAVLMidleware
consumidos por
4 middlewares ↓
✅ O que faz: Consome wfm_alocacao via Kafka e envia atualizações de alocação/status de equipe ao ADMS via Sensedia WFM adapter. O ModeloEquipeWorker (CronJob */5 * * * *) sincroniza o modelo completo de equipes ao ADMS consultando a ApiGodModelo e enviando via POST /wfm-adms/v1/crewmodel.
🛑 Se parar: O ADMS não recebe atualizações de alocação/status de equipe. O ModeloEquipeWorker (CronJob) falha independentemente e é monitorado pelo OCP.
📌 Regras:
wfm_alocacao: eventos de alocação enviados peloNotificacaoStatusOsEquipeWorkerModeloEquipeWorker(CronJob*/5 * * * *): GET ApiGodModelo → POST/wfm-adms/v1/crewmodel— 1 réplica, Forbid concurrency, timeout 600 s- Endpoint destino: ADMS REST WFM adapter via Sensedia
✅ O que faz: Consome notificações de interrupção (outage) e dispositivos afetados do Kafka, transforma para SOAP e chama o endpoint ReceiveIncidents no ADMS. Responsável por notificar o ADMS sobre incidentes e dispositivos afetados.
🛑 Se parar: O ADMS não recebe informações sobre incidentes de rede. Operadores do ADMS não verão eventos de interrupção originados no SIGOD.
📌 Regras:
- Transforma payload Kafka → SOAP envelope para ReceiveIncidents
- Endpoint destino: ADMS SOAP OSR adapter via Sensedia
✅ O que faz: Consome coordenadas de equipes e veículos do Kafka, converte o sistema de coordenadas de WGS84 para SIRGAS2000 e envia para o ADMS via SOAP AVL adapter. Permite ao ADMS rastrear a posição de equipes em campo em tempo real.
🛑 Se parar: O ADMS perde rastreamento de posição de equipes e veículos. Mapa de campo no ADMS para de atualizar.
📌 Regras:
- 2 workers:
AlteracaoCoordenadaEquipeWorker+AlteracaoVeiculoWorker - Conversão geodésica: WGS84 → SIRGAS2000 antes do envio
- ADMS endpoint:
PUT ChangedVehiclesCoordinates(SOAP/XML via Sensedia AVL adapter)
✅ O que faz: Consome CDC Avro da tabela Oracle PDA.RETORNO_OS_TEC (via tópico ContextDefinition.Cdc.Queue.RetornoOsTec) e propaga os dados de retorno de OS técnica para MongoDB SIGOD e Kafka para downstream.
🛑 Se parar: Retornos de OS técnica do Oracle PDA não chegam ao MongoDB SIGOD. Informações de encerramento e callback técnico ficam desatualizadas.
📌 Regras:
- Fonte CDC: tabela Oracle
PDA.RETORNO_OS_TEC - Tópico Avro:
ContextDefinition.Cdc.Queue.RetornoOsTec - Saída: MongoDB + tópico Kafka de retorno
+ wfm_callback_realizado
wfm_alocacao. Para o modelo de equipes (CronJob): kubectl get cronjob -n adms | grep mswfmmiddleware. ELK: mswfmmiddleware. Datadog: service mswfmmiddleware.oc get pods -n adms | grep mswfmmiddleware. 2) Checar logs ELK por erros REST ao chamar o ADMS WFM adapter. 3) Testar o endpoint WFM do Sensedia manualmente. 4) Verificar se o token de autenticação do Sensedia WFM está válido.wfm_outage_notification_interface e wfm_ordem_servico_dispositivo. ELK: msosrmidleware. Portal Sensedia → API OSR adapter → logs de chamada SOAP ReceiveIncidents.wfm_coordenada_equipe e wfm_coordenada_veiculo. ELK: msavlmidleware. Datadog: service msavlmidleware.mswfmmiddleware, msosrmidleware, msavlmidleware. Comparar error rate com baseline. Monitors/Alertas configurados podem já ter disparado. (MSGodLegSci foi movido para o Fluxo 2 — diagnosticar lá.)📡 Fluxo 4 — Retorno aos Canais de Atendimento (SIATT / Oracle ATD)
OrdemServico.Worker (Fluxo 2 — ADMS→SIGOD) → Kafka → MsAttFiltroIncidentes → workers especializados → Oracle ATD + ADMS via SFTP/AMI
✅ O que faz: Consome o tópico wfm_ordem_servico e redistribui para tópicos de status específicos (criado, despachado, encerrado, cancelado, arquivado) com base no campo Status da mensagem. Detalhamento completo no Fluxo 2.
🛑 Se parar: ⚠️ CRÍTICO: tópicos de status não chegam ao MsAttFiltroIncidentes. Canais convencionais (SIATT) param de receber atualizações de OS.
► wfm_ordem_servico_chamada ► wfm_ordem_servico_cliente_afetado
Origem a confirmar — produtores distintos do OrdemServico.Worker
✅ O que faz: Hub central dos canais convencionais. Consome 7 tópicos de status de OS vindos do OrdemServico.Worker, FILTRA apenas mensagens com IdSistema=="ADMS" (ignora OSs de outros sistemas como SGM) e redistribui para crm_comunicacao e crm_clientes_afetados_desligamento_emergencial.
🛑 Se parar: Clientes afetados por desligamentos não recebem comunicação. Workers downstream (MsAttComunicacao, MsAttDesligamentoEmergencial) ficam sem eventos para processar.
📌 Regras:
- Filtro crítico: IdSistema == "ADMS" — OSs de outros sistemas são descartadas silenciosamente
- 7 consumers Kafka em paralelo com SemaphoreSlim(30) para controle de concorrência
- Memória alocada: 512 Mi — monitorar OOM
ComunicacoesJobs · OrdemServicoCrm
✅ O que faz: Consome o tópico crm_comunicacao e grava registros de comunicação no Oracle ATD (tabelas: ATT_LIGACOES, ATT_INTERACAO, COMUNICACOES). Cada mensagem Kafka vira um registro de interação com o cliente no sistema de atendimento.
🛑 Se parar: Interações com clientes não são registradas no Oracle ATD. Histórico de comunicações fica desatualizado.
📌 Regras:
- Cada evento crm_comunicacao → INSERT em ATT_LIGACOES + ATT_INTERACAO + COMUNICACOES
- Oracle ATD é consultado pelo ADMS para histórico de atendimento
COMUNICACOES
✅ O que faz: Banco Oracle ATD (Atendimento ao Cliente). Destino de escrita do MsAttComunicacao: armazena ligações, interações e comunicações com clientes afetados por eventos de desligamento. Consultado pelo ADMS para histórico de atendimento.
🛑 Se parar: Banco externo — verificar conectividade Oracle ATD, locks e permissões de INSERT nas tabelas.
✅ O que faz: Consome o tópico crm_clientes_afetados_desligamento_emergencial, identifica os clientes afetados pelo desligamento de emergência e grava no Oracle ATD para notificação e registro.
🛑 Se parar: Clientes afetados por desligamentos emergenciais não são registrados no ATD. Equipes de atendimento não sabem quais clientes notificar.
📌 Regras:
- Cada evento = um ou mais clientes afetados a serem gravados no ATD
- Oracle ATD é consultado pelo ADMS para determinar impacto de desligamentos
clientes afetados
✅ O que faz: Banco Oracle ATD — tabela de clientes afetados por desligamento emergencial. Alimentado pelo MsAttDesligamentoEmergencial e consultado pelo ADMS para determinar impacto e acionar comunicação com clientes.
🛑 Se parar: Banco externo — verificar conectividade e permissões de INSERT.
de desligamentos
✅ O que faz: Servidor SFTP externo que disponibiliza arquivos CSV com a programação de desligamentos planejados. O MsAttDesligamentoProgramado faz polling neste SFTP para buscar os arquivos.
🛑 Se parar: MsAttDesligamentoProgramado não encontra arquivos novos. Verificar conectividade SFTP e credenciais nos secrets OCP.
✅ O que faz: Worker que faz polling no SFTP externo para buscar arquivos CSV com programação de desligamentos planejados. Processa cada linha do CSV e grava os registros de desligamento programado na tabela DESLIGAMENTO_PROGRAMADO do Oracle ATD.
🛑 Se parar: Desligamentos programados não são registrados no Oracle ATD. O ADMS não saberá quais clientes notificar antecipadamente sobre desligamentos planejados — impacto em conformidade regulatória ANEEL.
📌 Regras:
- Entrada: arquivo CSV via SFTP externo (polling por intervalo)
- Saída: INSERT em Oracle ATD
DESLIGAMENTO_PROGRAMADO - ELK:
msattdesligamentoprogramado
✅ O que faz: Worker de polling que monitora a tabela INSTALACAO no Oracle ATD e produz crm_atualizacao_cliente_adms para sincronização incremental. Também produz crm_atualizacao_cliente_adms_demanda no modo batch/lote completo controlado por parâmetro.
🛑 Se parar: Dados de instalações de clientes ficam desatualizados no SIGOD.
📌 Regras:
- Polling por intervalo em Oracle ATD.INSTALACAO
- Produz atualização incremental e lote completo sob demanda para o MsAttCliente
✅ O que faz: Consome crm_atualizacao_cliente_adms e crm_atualizacao_cliente_adms_demanda para sincronizar dados de clientes nos bancos Oracle ATD, IEO e GRA, além do MongoDB (cliente_adms).
🛑 Se parar: Cadastro de clientes fica desatualizado nos bancos Oracle e MongoDB.
📌 Regras:
- Grava em Oracle ATD, IEO e GRA + MongoDB cliente_adms
✅ O que faz: Processa registros pendentes em ATD.INTEGRACAO_CLIENTE_IQOS, consulta/atualiza ATD.CRM_CLIENTE, consulta GIS.EO_CONSUMIDOR para dados de rede e envia clientes ou OSs para a API IQOS via HTTP/Sensedia.
🛑 Se parar: Dados de clientes/OS pendentes no ATD deixam de ser enviados ao IQOS. Registros ficam com status pendente ou erro em INTEGRACAO_CLIENTE_IQOS.
📌 Regras:
- Não usa Kafka
- Execução batch a cada minuto
- Status final: processado ou erro na tabela de integração
✅ O que faz: Worker batch que lê dados de clientes do Oracle e MongoDB, gera um arquivo CSV e o envia via SFTP para o ADMS AMI adapter. Permite ao ADMS ter base atualizada de clientes.
🛑 Se parar: ADMS não recebe atualização de base de clientes. AMI adapter trabalha com dados desatualizados.
📌 Regras:
- Processo batch (não contínuo) — verificar schedule de execução
- Destino: SFTP → ADMS AMI adapter
- ELK index: msattclientecsv
✅ O que faz: Servidor SFTP de transferência de arquivos CSV de clientes do SIGOD para o ADMS. Ponto de entrega dos arquivos gerados pelo MsAttClienteCsv.
🛑 Se parar: Arquivos CSV não chegam ao ADMS AMI adapter. Verificar credenciais SFTP nos secrets OCP.
atualização de clientes
✅ O que faz: ADMS AMI (Advanced Metering Infrastructure) adapter. Recebe arquivos CSV de clientes via SFTP e atualiza a base de dados de clientes no ADMS. Sistema externo — fora do controle do time SIGOD.
🛑 Se parar: Base de clientes no ADMS fica desatualizada. Escalar para equipe do ADMS.
✅ O que faz: CronJob agendado para 02h00 que lê os dados de potência de clientes das tabelas Oracle GRA (INGRID_*) e faz BulkWrite no MongoDB cliente_adms.
🛑 Se parar: Dados de potência ficam desatualizados no MongoDB. Se não executar às 02h00, verificar logs ELK.
📌 Regras:
- Execução: diária às 02h00
- Fonte: Oracle GRA.INGRID_* → MongoDB cliente_adms (BulkWrite)
- ELK index: msatualizapotenciacliente
✅ O que faz: API REST que movimenta reclamações no Oracle ATD. Recebe comunicações via endpoint POST /{empresa}/comunicacao e grava diretamente no Oracle ATD.
🛑 Se parar: Movimentações de reclamações técnicas não são registradas no ATD.
crm_comunicacao → MSCCA → cache MongoDB 24h + fila MSGSAC.DP.{empresa}
✅ O que faz: Serviço de cache de desligamentos e iniciador do SAC proativo. Consome eventos de desligamento programado/emergencial e de comunicações CRM, enriquece com dados do Oracle, cacheia no MongoDB (com TTL de 24h) e enfileira mensagens de SAC proativo (MSGSAC.DP.{empresa}) para notificação proativa dos clientes afetados. Atua exclusivamente em empresas com ADMS habilitado (param global 70).
🛑 Se parar: Cache de desligamentos desatualizado. SAC proativo não disparado. Histórico de OS de desligamento não cacheado no MongoDB.
📌 Regras:
- 21 consumidores paralelos: 1 (desligProg) + 10 (desligEmerg) + 10 (histOS)
- MongoDB TTL: 24 horas para DesligamentoProgramado e DesligamentoEmergencial
- SAC proativo: fila
MSGSAC.DP.{codigoEmpresaWeb} - Somente empresas com param global 70 = "ADMS"
HistoricoOs · ControleSacOcorrenciaTecnica
MSGSAC.DP.{empresa}→ notificação de clientes afetados
wfm_ordem_servico_* (MsAttFiltroIncidentes)
▶
kafka-consumer-groups --bootstrap-server <broker> --describe --group msattfiltroincidentes-group. Monitorar os 7 tópicos: wfm_ordem_servico_criado, _despachado, _encerrado, _cancelado, _arquivado, wfm_ordem_servico_chamada, wfm_ordem_servico_cliente_afetado.oc get pods -n adms | grep msattfiltroincidentes. 2) Checar logs ELK: msattfiltroincidentes. 3) Verificar se o OrdemServico.Worker (Fluxo 2) está produzindo esses tópicos — o problema pode estar na origem.IdSistema=="ADMS" — OSs de outros sistemas sendo propagadas indevidamente?
▶
msattfiltroincidentes). Filtrar por mensagens que não contêm IdSistema=ADMS para ver se estão sendo descartadas corretamente. Pode-se também conferir no Kafka o volume do tópico crm_comunicacao — se o volume for inesperadamente alto, pode indicar falha no filtro.crm_comunicacao para checar se todos têm IdSistema=ADMS. 2) Se houver mensagens indevidas, verificar se houve deploy recente do MsAttFiltroIncidentes que possa ter alterado a lógica de filtro.crm_comunicacao (MsAttComunicacao → Oracle ATD)
▶
crm_comunicacao. ELK: msattcomunicacao. Para confirmar gravações no Oracle ATD: SELECT COUNT(*) FROM ATT_LIGACOES WHERE DT_CADASTRO > SYSDATE - 1/24 e também ATT_INTERACAO, COMUNICACOES.oc get pods -n adms | grep msattcomunicacao. 2) Checar logs ELK por erros de INSERT no Oracle ATD. 3) Testar conectividade com o banco Oracle ATD.crm_clientes_afetados_desligamento_emergencial (MsAttDesligamentoEmergencial)
▶
crm_clientes_afetados_desligamento_emergencial. ELK: msattdesligamentoemergencial. Validar registros no Oracle ATD: tabela DESLIGAMENTO_EMGCL_OCORC_TECNC.msattclientecsv e msattdesligamentoprogramado. Filtrar por erros de SFTP (connection refused, timeout, authentication failed). Verificar se o servidor SFTP destino (ADMS AMI adapter) está acessível.cliente_adms — MsAttCliente gravando corretamente?
▶
msattcliente. MongoDB: collection cliente_adms — verificar documentos recentes (campo updatedAt ou equivalente). Datadog: service msattcliente.MsAtualizaPotencia — executou às 02h00 hoje?
▶
oc get cronjob -n adms | grep msatualizapotencia e oc get jobs -n adms | grep msatualizapotencia. Logs ELK: msatualizapotenciacliente — filtrar por data de hoje às 02h00. Status do job: "Completed" = OK, "Failed" = problema.oc create job --from=cronjob/msatualizapotencia msatualizapotencia-manual-$(date +%s) -n adms. 3) Monitorar execução até conclusão.🔄 Fluxo 5 — CDC Oracle → Kafka → MongoDB
✅ O que faz: Banco Oracle PDA (legado) — origem do fluxo CDC. Monitora alterações em tabelas críticas do despacho (SGD_SIGOD, OS_DIGITACAO, MOV_DESPACHO_LOTE_ITEM, EQUIPE*, DESPACHANTE*, SERVICO) via XStream e transmite eventos ao Debezium Oracle Connector.
🛑 Se parar: XStream parado = NENHUMA mudança do legado Oracle chega ao Kafka. Todos os incorporadores ficam sem dados. Escalar para DBA Oracle imediatamente.
📌 Regras:
- XStream deve estar em estado
WAITING FOR TRANSACTIONouSTREAMING - Verificar:
SELECT SERVER_NAME, STATUS FROM V$XSTREAM_OUTBOUND_SERVER - Banco externo — qualquer problema deve ser escalado para DBA Oracle
✅ O que faz: Kafka Connect com Debezium Oracle Connector. Captura eventos de mudança (INSERT/UPDATE/DELETE) nas tabelas do Oracle PDA via XStream e os publica automaticamente nos tópicos oracle_stream.* no Kafka, disponibilizando os dados para todos os incorporadores e workers legacy.
🛑 Se parar: Connector em estado FAILED = CDC completamente parado. Todos os tópicos oracle_stream.* param de receber mensagens. Verificar: curl http://<kafka-connect>:8083/connectors/oracle-pda-cdc/status.
📌 Regras:
- Serialização dos eventos: Avro com Schema Registry
- Cada linha alterada no Oracle → 1 mensagem Kafka no tópico correspondente
- Restart via:
POST /connectors/oracle-pda-cdc/restart
✅ O que faz: Incorporador CDC que consome eventos da tabela Oracle ITG.SGD_SIGOD (via Kafka Connect JDBC) e incorpora Ordens de Serviço técnicas (TipoServico 3 — emergência, 4 — programada, 6 — inspeção) no MongoDB SIGOD. Não produz Kafka — toda saída é via HTTP para a ApiGodOrdemServico. Lê dados complementares do Oracle (ITG, PDA, ATD, FAR) para enriquecer a OS antes de persistir.
🛑 Se parar: OSs técnicas criadas no legado Oracle (SGD_SIGOD) não aparecem no SIGOD. Despachantes não verão OSs de origem legada para tipos 3, 4 e 6.
📌 Regras:
- Serialização Avro: schema
energisa.god.ordem_servico.sgd_sigod.SgdSigodAvro - Feature flag Oracle: parâmetro
SIGOD/416— controla se incorpora OSs já concluídas - Ignora registros com
IND_BLOQUEIO = 'S'ouIND_EXCLUIR = 'S' - ELK:
sigod_logs
✅ O que faz: Consome eventos CDC da tabela oracle_stream.OS_DIGITACAO e incorpora OSs comerciais (TipoServico 0) no MongoDB do SIGOD. São digitações manuais do operador no sistema legado.
🛑 Se parar: OSs comerciais digitadas manualmente no legado não aparecem no SIGOD.
📌 Regras:
- Filtra apenas TipoServico 0 (comercial/digitação manual)
- Cada INSERT/UPDATE na OS_DIGITACAO gera evento Kafka para o SIGOD
✅ O que faz: Consome eventos CDC da tabela oracle_stream.MOV_DESPACHO_LOTE_ITEM e incorpora OSs de lote (TipoServico 5) no MongoDB do SIGOD. Usa Redis (chave SIGOD_416) para controle de deduplicação de mensagens.
🛑 Se parar: OSs de lote não chegam ao SIGOD. Despachos em lote do legado ficam invisíveis.
📌 Regras:
- Filtra apenas TipoServico 5 (lote)
- Redis SIGOD_416 previne processamento duplicado com TTL configurado
- Idempotência garantida por chave Redis
✅ O que faz: Worker legacy com 8 hosted services que sincronizam dados auxiliares de OSs do legado Oracle para o MongoDB SIGOD. Trata: ocorrências encerradas (ATENDIMENTO_OCORRENCIA_ENCRD), callbacks automáticos (LISTA_CALLBACK_AUTOMATIZADO), programações de despacho (PROGRAMACAO_DESPACHO), indenizações (INDENIZACAO_OCORRENCIA), bloqueios de despacho (BLOQUEIO_DESPACHO) e criações de OS via WSROT (SOLICITACAO_OS_PDA).
🛑 Se parar: Dados auxiliares das OSs (programações, bloqueios, compensações, callbacks) ficam desatualizados no MongoDB. OS criadas via WSROT podem não ser processadas.
📌 Regras:
- 8 workers independentes — uma falha não derruba os outros
ProcessaSolicitacaoOrdemServicofaz HTTP POST para WSROT para criar OSProcessaAtualizacaoOrdemServicoBloqueioescreve de volta no Oracle PDA (BLOQUEIO_DESPACHO)- ELK:
sigod_logs
Workers internos (7 ativos)
ProcessaOcorrenciaEncerrada←Jdbc.Queue.AtendimentoOcorrenciaEncrd→OrdemServico.Queue.DefaultProcessaJdbcBloqueioDespacho←Cdc.Queue.BloqueioDespacho→OrdemServico.Queue.DefaultProcessaJdbcListaCallbackAutomatizadoWorker←Cdc.Queue.ListaCallbackAutomatizadoProcessaJdbcParametrosWorker←Jdbc.Queue.ParametrosProcessaJdbcProgramacaoDespachoWorker←Jdbc.Queue.ProgramacaoDespacho→OrdemServico.Queue.DefaultProcessaJdbcCompensacaoWorker←Jdbc.Queue.Compensacao→OrdemServico.Queue.DefaultProcessaSolicitacaoOrdemServico←Cdc.Queue.SolicitacaoOsPda→ HTTP WSROT/ApiGodOrdemServico
IdSistema == "ADMS" e equipe CALLROB✅ O que faz: Worker CDC que monitora 8 tabelas Oracle relacionadas a equipes (EQUIPE, EQUIPE_FUNC, EQUIPE_REGIAO, ITEM_ESCALA_MENSAL, ANOMALIA_PDA, APRESENTACAO_FCO, DESVIO_FCO, CD_PARAMETROS_GLOBAIS). Para cada evento CDC, enriquece os dados consultando Oracle PDA/ATD e publica wfm_modelo_equipe; o worker ProcessaCdcItemEscalaMensalWorker também publica wfm_modelo_equipe_escala. A produção de wfm_modelo_equipe_funcionario por APRESENTACAO_FCO está a confirmar porque o ER aponta código comentado.
🛑 Se parar: Modelo de equipes no MongoDB (mdb_modelo_crp) fica desatualizado. O SIGOD não refletirá mudanças de composição, escala, anomalias e desvios de equipes legadas.
📌 Regras:
- 9 hosted services independentes — cada tabela Oracle tem seu próprio worker
- Parâmetro Oracle
SIGOD-146(CD_PARAMETROS_GLOBAIS) controla alertas de atraso de turno - ELK:
sigod_logs
CDC Oracle consumido (8 tabelas) + outbound adicional
EQUIPE,EQUIPE_FUNC,EQUIPE_REGIAO,ITEM_ESCALA_MENSALANOMALIA_PDA,APRESENTACAO_FCO,DESVIO_FCO,CD_PARAMETROS_GLOBAIS- 9º hosted service outbound: sincronização com API Mobile (apresentação AWS)
OperadorBuffer com debounce de 3000ms.✅ O que faz: Worker legacy que consome eventos CDC da tabela Oracle SERVICO (catálogo de serviços do PDA) e mantém a coleção servico no MongoDB mdb_modelo_crp sincronizada. Garante que o SIGOD tenha o catálogo de serviços atualizado conforme o legado Oracle.
🛑 Se parar: Catálogo de serviços no MongoDB (mdb_modelo_crp.servico) fica desatualizado. Novos serviços cadastrados no Oracle PDA não aparecem no SIGOD.
📌 Regras:
- Tópico consumido:
oracle_stream.SERVICO(CDC Debezium) - Persistência: MongoDB
mdb_modelo_crp, coleçãoservico - Worker ativo:
ProcessaCdcServicoWorker· Worker desabilitado:ProcessaCdcPdaWorker - ELK:
sigod_logs
SELECT SERVER_NAME, STATUS, CAPTURED_SCN, APPLIED_SCN FROM V$XSTREAM_OUTBOUND_SERVER. Status deve ser WAITING FOR TRANSACTION ou STREAMING. Se ABORTED ou ausente, o XStream está com problema.curl -s http://<kafka-connect-host>:8083/connectors/oracle-pda-cdc/status | jq .. O campo connector.state deve ser RUNNING. Se for FAILED, o campo trace mostrará o erro. Também checar tarefas: tasks[0].state deve ser RUNNING.oracle_stream.* não receberão novas mensagens. Todos os incorporadores (Tec, Com, Lote, Manut, Proj) ficam sem dados.POST /connectors/oracle-pda-cdc/restart. 3) Se falhar ao reiniciar, checar conectividade entre o Kafka Connect e o Oracle PDA. 4) Verificar credenciais Oracle usadas pelo Debezium (pode ter expirado).oracle_stream.* — incorporadores estão consumindo?
▶
oracle_stream.SGD_SIGOD, oracle_stream.OS_DIGITACAO, oracle_stream.MOV_DESPACHO_LOTE_ITEM, oracle_stream.EQUIPE*. Verificar lag por consumer group de cada incorporador. Terminal: kafka-consumer-groups --bootstrap-server <broker> --describe --group msgodincorptec-group (repetir para cada incorporador).SGD_SIGOD afeta OSs técnicas; lag em OS_DIGITACAO afeta OSs comerciais; lag em MOV_DESPACHO_LOTE_ITEM afeta despachos em lote.oc get pods -n adms | grep msgodincorp. 3) Checar logs ELK do incorporador afetado por exceções. 4) Verificar se há mensagem malformada causando loop de falha (Dead Letter Queue).ordem_servico atualizada?
▶
mdb_ordem_servico_crp, collection ordem_servico. Verificar documentos recentes. ELK: filtrar por erros MongoWriteException nos índices dos incorporadores (sigod_logs). Datadog: services msgodincorptec, msgodincorpcom, msgodincorplote.msgodincorptec, msgodincorpcom, msgodincorplote)
▶
msgodincorptec, msgodincorpcom, msgodincorplote, msgodincorpmanut, msgodincorpproj. Analisar spans com erro para identificar tipo de exceção.📍 Fluxo 6 — Alocação de OS
wfm_alocacao e sincroniza com o ADMS via Sensedia.
Paralelamente, MSGodCartografia rastreia GPS das equipes →
MSAVLMidleware (Fluxo 3) envia posição ao ADMS.
✅ O que faz: Sistema legado desktop (PowerBuilder) do despachante SIGOD. A tela w_sigod001 usa o objeto uo_despacho_api para consultar OSs/equipes e executar despacho, retirada forçada/status e atualizações operacionais via APIs GOD/Sensedia. Será substituído pelo WFMDashboard.
🛑 Se parar: Despachante perde acesso ao sistema legado ou às chamadas REST do uo_despacho_api. Verificar disponibilidade do cliente PowerBuilder, parâmetros globais SIGOD 390/403/404/405 e autenticação Sensedia.
📌 Regras:
- Entrada operacional legada: despachante executa despacho/alocação na tela
w_sigod001. uo_despacho_apiautentica na Sensedia e usa a URL base do parâmetro globalSIGOD/390.- Não passa pelo BFF do WFMDashboard; chama APIs GOD diretamente a partir do PowerBuilder.
- A solicitação de retirada normal aparece na tela via
uoi_despacho_os.of_solicita_retirada(...); nouo_despacho_apifoi confirmada retirada forçada/status porPATCH /OrdemServico/{numOs}/.
Chamadas REST confirmadas no uo_despacho_api
GET /OrdemServicoLegado/{dw}→ alimenta DataWindows de OSs da tela.GET /EquipeLegado/empresa/{empresa}/usuario/{usuario}/indicador/{espera}→ consulta equipes para despacho.POST /Alocacao/despachar/{numOs}→ despacha OS para equipe comEquipes[].IdExterno = tipo-equipe.PATCH /OrdemServico/{numOs}/→ atualiza situação, programação, região, impressão, prioridade ou retirada forçada/status.PATCH /Equipe→ atualiza indicador de equipe em espera.
✅ O que faz: Gateway de autenticação dedicado para o WFMDashboard. Gerencia o login via Azure AD B2C (MSAL popup), armazena tokens em cookies HttpOnly (iron-session) e redireciona o operador autenticado para o WFMDashboard com token de acesso.
🛑 Se parar: Operadores e despachantes não conseguem iniciar sessão no WFMDashboard. A tela de login fica indisponível.
📌 Regras:
- Autenticação: Azure AD B2C (MSAL) → popup → token no localStorage → cookie HttpOnly.
- Session API:
POST /api/session/setdefine cookiesutk,ugdeucp. - Após login: redireciona para
NEXT_PUBLIC_DASHBOARD_URL/dashboard?token=.... - Validação de usuário via BFF:
NEXT_PUBLIC_BASE_URL_BFF//user/get. - Proteções: rate limit 100 req/60s por IP, X-Frame-Options DENY e CSP frame-ancestors none.
Fluxo de autenticação
WFMAuth /login→ inicia login do operador via Azure AD B2C/MSAL.POST /api/session/set→ grava sessão em cookies HttpOnly.NEXT_PUBLIC_BASE_URL_BFF/user/get→ valida o usuário no BFF.NEXT_PUBLIC_DASHBOARD_URL/dashboard?token=...→ redireciona para o WFMDashboard.
✅ O que faz: Dashboard operacional do COI. O BFF Next.js faz proxy para as APIs backend, incluindo despacho, retirada e redirecionamento na ApiGodAlocacao. Também recebe atualizações de situação de OS via SSE de ApiGodOrdemServico, acompanha confirmações da alocação via SignalR e apresenta equipes/OS em mapa.
🛑 Se parar: Operadores e despachantes perdem a interface principal do COI. Sem visibilidade real-time de OS, equipes no mapa e confirmações operacionais de despacho.
📌 Regras:
- Alocação:
POST /api/alocacao/despachar,/redirecionar,/retirare/retirar-forcado→ proxy REST para ApiGodAlocacao. - Confirmação: ApiGodAlocacao publica retorno operacional no SignalR Hub
/listener, consumido pelo dashboard. - SSE:
GET /api/sse/situacao-alterada→ proxy paraApiGodOrdemServico/api/OrdemServicoSituacaoSse/stream(wfm_ordem_servico_situacao_alterada). - Postos operacionais: CRUD via
ApiGodModelo/PostoOperacional. - Priorização e região:
PATCH /api/ordens-servico/{id}/priorizarePATCH /api/ordens-servico/{id}/regiao. - Regiões legado:
GET /api/regiao/polos-legadoeregioes-legado. - Mapa: módulos
map-platformemapapara camadas de equipe e ordem de serviço. - Autenticação: sessão vinda do WFMAuth, cookies HttpOnly, JWT e validação complementar via ApiGodIdentidade/BFF.
Chamadas BFF e integrações
POST /api/alocacao/despachar→ BFF chama ApiGodAlocacao para despachar OS para equipe.POST /api/alocacao/redirecionar→ BFF chama ApiGodAlocacao para redirecionar despacho.POST /api/alocacao/retirar→ BFF chama ApiGodAlocacao para retirar equipe da OS.POST /api/alocacao/retirar-forcado→ BFF chama ApiGodAlocacao para retirada forçada.GET /api/sse/situacao-alterada→ BFF expõe SSE de ApiGodOrdemServico.SignalR /listener→ recebe confirmações operacionais da ApiGodAlocacao.ApiGodModelo/PostoOperacional→ CRUD de postos operacionais.
APIs backend consumidas
- ApiGodAlocacao → despacho, retirada, redirecionamento e retirada forçada.
- ApiGodOrdemServico → SSE de situação de OS e ações de priorização/região.
- ApiGodModelo → postos operacionais, regiões e polos legado.
- ApiGodWfm → dados de dashboards WFM.
- ApiGodCartografia → coordenadas e camadas de mapa.
- ApiGodIdentidade → validações de usuário/JWT.
✅ O que faz: Gateway REST para operações de alocação de OS. Recebe requisições do despachante via WFMDashboard/BFF e, no legado PowerBuilder, recebe despacho confirmado pelo uo_despacho_api em POST /Alocacao/despachar/{numOs}. Valida o payload, publica eventos Kafka de alocação quando aplicável e notifica o frontend moderno via SignalR.
🛑 Se parar: O despachante não consegue alocar, retirar ou redirecionar OS pelo SIGOD legado nem pelo WFMDashboard. A tela de despacho fica sem confirmação operacional. Nenhum tópico de alocação é produzido.
📌 Regras:
- SIGOD Legado:
uo_despacho_api.of_despachochamaPOST /Alocacao/despachar/{numOs}via Sensedia - SIGOD Legado: retirada forçada/status foi confirmada no objeto como
PATCH /OrdemServico/{numOs}/; solicitação de retirada normal permanece em rotina PowerBuilder legada - WFMDashboard: BFF
/api/alocacao/*faz proxy REST para ApiGodAlocacao POST /Alocacao/despachar/{numOs}/ BFF despacho → publica emwfm_alocacao→ MsGodAlocacao processaPOST /solicitacao-retirada→ publica emwfm_solicitacao_retirada- SignalR Hub
/listener: WFMDashboard escuta eventos de confirmação em tempo real - Autenticação via token JWT (validado antes de publicar no Kafka)
Endpoints REST e chamadas recebidas
POST /alocacao→ cria uma alocação de OS para equipe e publicawfm_alocacao.PUT /alocacao/{id}→ atualiza uma alocação existente, incluindo troca ou ajuste de equipe.POST /solicitacao-retirada→ solicita retirada da OS da equipe e publicawfm_solicitacao_retirada.GET /alocacao/equipe/{id}→ consulta todas as alocações ativas da equipe.SignalR /listener→ envia confirmação operacional ao WFMDashboard.
✅ O que faz: 7 workers paralelos que processam todas as operações de alocação de OS a equipes de campo. Consome fontes CDC e internas de alocação, publica tópicos semânticos reais de ContextDefinition.Alocacao.Queue.* e mantém sincronismo com ADMS e legado.
🛑 Se parar: Alocações param completamente — o ADMS não é notificado, o legado Oracle fica dessincronizado e despachantes perdem visibilidade do campo.
📌 Regras de negócio:
- Uma OS só pode ser alocada a uma equipe ativa e disponível (validado via Redis cache)
- Ao alocar: status da OS muda para "despachado" — propagado via
wfm_alocacao_despachadoe refletido no payload dewfm_alocacao - Retirada: remove a OS da equipe sem encerrar a OS — propagado via
wfm_alocacao_retirada - Redis mantém snapshot atualizado das equipes e OSs para performance (evita roundtrip Oracle a cada operação)
- Alocações do legado Oracle chegam via CDC (
oracle_stream.DESPACHO_OS) — sem passar pelo despachante
SincronismoOsLegadoService.IAlocacaoRepository.DespacharAsync para redirecionar a OS entre equipes.CAMINHO_PERCORRIDO) e publica coordenadas de equipes e veículos no Kafka, permitindo ao ADMS rastrear posição em tempo real.✅ O que faz: Worker CDC que consome eventos de rastreamento GPS da tabela Oracle CAMINHO_PERCORRIDO (via Debezium) e publica as coordenadas nos tópicos wfm_coordenada_equipe e wfm_coordenada_veiculo. O MSAVLMidleware (Fluxo 3) consome esses tópicos e envia as posições ao ADMS com conversão de coordenadas WGS84 → SIRGAS2000.
🛑 Se parar: Posições de equipes e veículos não chegam ao Kafka. ADMS perde rastreamento de campo. Verificar CDC da tabela CAMINHO_PERCORRIDO no Oracle PDA.
📌 Regras:
IDTORI_GPS == "P"→wfm_coordenada_veiculoIDTORI_GPS == "I"ou"E"→wfm_coordenada_equipe- Tópico default:
wfm_coordenada(auto-consumo via ProcessaAtualizacaoCoordenadaWorker) - 2 BackgroundServices; MongoDB collection:
ObjetoMapa - Cada evento GPS do Oracle → 1 mensagem
wfm_coordenada_equipeouwfm_coordenada_veiculo - Dependência: Debezium CDC da tabela
CAMINHO_PERCORRIDOdeve estar ativo
✅ O que faz: Worker que consolida o estado atual de cada equipe de campo no MongoDB. Consome eventos de múltiplas fontes — coordenadas GPS (wfm_coordenada_*), alocações (wfm_alocacao) e dados do modelo de equipe (wfm_modelo_equipe*) — para manter as coleções Equipe e EquipeLegado no MongoDB sempre atualizadas com posição, composição e OSs alocadas.
🛑 Se parar: Estado das equipes no MongoDB fica desatualizado. Dashboard do despachante mostra informações antigas sobre localização e carga de trabalho das equipes.
📌 Regras:
- Workers (5): ProcessaCoordenadaEquipeWorker, ProcessaOrdemServicoVinculadaWorker, ProcessaProgramacaoDespachoWorker, ProcessaMappingEquipeWorker, ProcessaIntegracaoApresentacaoAwsWorker
- Consome:
wfm_coordenada_equipe,wfm_coordenada_veiculo,wfm_alocacao,wfm_ordem_servico_programado,wfm_modelo_equipe,wfm_modelo_equipe_funcionario - Produz:
wfm_modelo_equipe - NÃO acessa Oracle — apenas MongoDB (
mdb_modelo_crp: Equipe, EquipeLegado)
wfm_alocacao e wfm_solicitacao_retirada — filas acumulando no MsGodAlocacao?
▶
wfm_alocacao e wfm_solicitacao_retirada. Terminal: kafka-consumer-groups --bootstrap-server <broker> --describe --group msgodalocacao-group. Datadog: service msgodalocacao → Kafka metrics.oc get pods -n adms | grep msgodalocacao. 2) Checar se todos os 7 pods estão Running. 3) Verificar logs ELK do serviço por exceções. 4) Checar se o Redis (cache) está respondendo, pois falha no Redis causa falha em cadeia nos workers.redis-cli -h <redis-host> -p 6379 ping — deve retornar PONG. Verificar métricas do cluster Redis no Datadog ou painel próprio. ELK: filtrar logs do MsGodAlocacao por erros RedisConnectionException ou TimeoutException.msgodalocacao. Verificar: Latência P95 e P99, Error Rate (%), Throughput (req/seg). Comparar com SLO configurado. Também checar dashboard dedicado do MsGodAlocacao se existir.SELECT * FROM MOV_DESPACHO WHERE DT_DESPACHO > SYSDATE - 1/24 ORDER BY DT_DESPACHO DESC. ELK: logs do MsGodAlocacao por erros de escrita Oracle. Datadog: spans de chamadas ao Oracle.V$LOCKED_OBJECT no Oracle PDA para locks ativos. 3) Verificar se o usuário Oracle tem permissões adequadas.oracle_stream.DESPACHO_OS — alocações do legado chegando ao SIGOD?
▶
oracle_stream.DESPACHO_OS. Verificar lag do consumer group do MsGodAlocacao neste tópico. Se o Debezium CDC do Fluxo 5 estiver com problema, este tópico também ficará sem dados.DESPACHO_OS no Oracle PDA está sendo monitorada pelo XStream. 3) Se o CDC está OK mas o lag persiste, verificar pods do MsGodAlocacao.📞 Fluxo 7 — Callbacks Técnicos (Redis)
call-back
✅ O que faz: API REST que recebe callbacks técnicos do campo (técnicos reportando conclusão de OS). Produz na fila Redis MsGodEncerCallTec.{empresa} para início do pipeline de encerramento.
🛑 Se parar: Callbacks de técnicos em campo não entram no sistema. OSs não são encerradas automaticamente via pipeline Redis.
📌 Regras:
- Endpoint: POST /api/v1/EncerramentoOT/RecebeCallback
- Payload: OTEncerramento (CodigoEmpresaWeb, NumeroOs, SiglaUsuario, SistemaOrigem)
- Códigos empresa: emg=1, ese=3, ebo=4, epb=5, emt=6, eto=8, ess=9, ems=10, ero=20, eac=30
- Produz na fila Redis separada por empresa: MsGodEncerCallTec.{empresa}
- Swagger: apigodtecnica (projeto OCP: call-back)
✅ O que faz: Estágio 1 do pipeline Redis de callbacks técnicos. Consome MsGodEncerCallTec.{empresa}, processa o callback e roteia para os estágios 2, 3 ou 4 conforme o tipo de ação necessária.
🛑 Se parar: Pipeline de callback para no início. Nenhum encerramento automático de OS é processado.
📌 Regras:
- 10 pods (1 por distribuidora)
- Roteia para MsGodAtribOsTec, MsGodEncerOsTec ou MSGODConfIntegSisTec
✅ O que faz: Estágio 2 do pipeline Redis. Consome MsGodAtribOsTec.{empresa} e grava atribuição de OS nas tabelas Oracle PDA (DESPACHO_OS, COMUNICACOES).
🛑 Se parar: Atribuições de OS a técnicos não são gravadas no Oracle PDA.
📌 Regras:
- 10 pods (1 por distribuidora)
- Grava em PDA.DESPACHO_OS e PDA.COMUNICACOES
✅ O que faz: Estágio 3 do pipeline Redis. Consome MSGODConfIntegSisTec.{empresa} e pode re-enfileirar mensagens no MsGodEncerCallTec para reprocessamento (ciclo).
🛑 Se parar: Mensagens podem ficar em loop se o ciclo não for resolvido.
📌 Regras:
- 10 pods (1 por distribuidora)
- ⚠️ Ciclo possível: pode re-produzir para MsGodEncerCallTec — monitorar profundidade das filas
✅ O que faz: Estágio inferido do pipeline Redis. A fila MsGodEncerOsTec.{empresa} é produzida pelo MSGODEncerCallTec, mas o repositório/consumer não foi localizado no ER; a função de encerramento no sistema técnico permanece a confirmar.
🛑 Se parar: Se o consumer existir e estiver indisponível, OSs encaminhadas para esta fila podem não avançar para encerramento técnico. Confirmar o serviço antes de tratar o Estágio 4 como causa raiz.
📌 Regras:
- Estágio inferido pela fila Redis
MsGodEncerOsTec.{empresa} - Repo/consumer não localizado na engenharia reversa
- Operação final e tabelas gravadas: a confirmar
call-back
call-back está disponível e respondendo?
▶
redis-cli -h <redis-host-callback> -p 6379 ping — deve retornar PONG. Verificar métricas no Datadog (memória usada, conexões ativas, erros). OCP: oc get pods -n call-back | grep redis.oc get pods -n call-back). 2) Checar eventos do namespace: oc get events -n call-back --sort-by='.lastTimestamp'. 3) Se Redis não responde, escalar para equipe de infraestrutura imediatamente — impacto crítico em todas as distribuidoras.redis-cli -h <host> LLEN MsGodEncerCallTec.eac (repetir para cada empresa e cada serviço). Filas a verificar por empresa (eac, ebo, emg, ems, emt, epb, ero, ese, ess, eto): MsGodEncerCallTec.{empresa}, MsGodAtribOsTec.{empresa}, MsGodEncerOsTec.{empresa}, MSGODConfIntegSisTec.{empresa}.MsGodEncerCallTec.emg > 1000) indica que o pod daquela empresa está parado ou com erro. Se uma empresa específica está acumulando, o problema é isolado naquele pod.oc get pods -n call-back | grep msgodenercalltec — checar pod da empresa afetada. 3) Ver logs do pod: oc logs <pod-name> -n call-back --tail=100. 4) Reiniciar pod se necessário: oc delete pod <pod-name> -n call-back.LISTA_CALLBACK_ROBOTIZADO sendo processada corretamente?
▶
SELECT EMPRESA, STATUS, COUNT(*) FROM LISTA_CALLBACK_ROBOTIZADO WHERE DT_PROCESSAMENTO IS NULL GROUP BY EMPRESA, STATUS ORDER BY 3 DESC. Registros com status pendente há mais de 30 minutos indicam problema. ELK: IQosElkService (utilizado pelos serviços de callback).DT_PROCESSAMENTO indica que o Estágio 1 (APIGodTecnica → MsGodEncerCallTec) não está processando. Callbacks do campo chegam à API mas não avançam no pipeline.SELECT * FROM V$LOCKED_OBJECT WHERE OBJECT_ID = (SELECT OBJECT_ID FROM DBA_OBJECTS WHERE OBJECT_NAME='LISTA_CALLBACK_ROBOTIZADO').MSGODConfIntegSisTec.{empresa} e ao mesmo tempo a fila MsGodEncerCallTec.{empresa} — se ambas crescem simultaneamente, é sinal de ciclo. ELK: filtrar logs do MSGODConfIntegSisTec por mensagens de reenvio para o Estágio 1.IQosElkService. Filtrar por campo empresa: eac, ebo, emg, ems, emt, epb, ero, ese, ess, eto. Criar aggregação por empresa e por nível de log (ERROR, WARN). Datadog: filtrar traces do call-back por tag de empresa.call-back
▶
oc get pods -n call-back. Deve haver 10 pods para cada serviço (1 por distribuidora): apigodtecnica-*, msgodenercalltec-*, msgodatribostec-*, msgodenercalltec-* (Estágio 2), msgodconfintegsistec-*. Todos devem estar em status Running.CrashLoopBackOff ou Error significa que aquela distribuidora está sem processamento de callbacks. Técnicos de campo desta distribuidora não conseguem encerrar OS via callback.oc get pods -n call-back | grep -v Running. 2) Ver logs do pod problemático: oc logs <pod> -n call-back. 3) Descrever o pod para ver eventos: oc describe pod <pod> -n call-back. 4) Reiniciar se necessário.🔧 Fluxo 8 — SGM / Manutenção
✅ O que faz: Hub central do SGM (manutenção). Consulta diretamente SGM.TASK, SGM.TASKEXECALL e SGM.REQUEST para localizar OSs/SS pendentes, produz sgm_origem_os para envio ao ADMS via ApiSmrMiddleware e consome sgm_retorno_os com retornos do ADMS.
🛑 Se parar: OSs de manutenção do SGM não são enviadas ao ADMS. Equipes de manutenção ficam sem OS no campo.
📌 Regras:
- Leitura SGM por queries diretas nas tabelas TASK, TASKEXECALL e REQUEST
PCR_OSSS_S40_EQMé chamada no INMD pelo S40Service, não como busca principal no Oracle SGM- Consome sgm_pendencia_cadastral_tecnica_adms para tratar pendências cadastrais em SGM.REQUEST
- Bidirecional: envia OS ao ADMS (sgm_origem_os) e recebe retorno (sgm_retorno_os)
- [26/05/2026] Circuit breaker: 3 Workers (ConsultaOrigem, PendenciaCadastral, RetornoSuspensao) com
MaxConsecutiveFailures = 5→StopApplication()para reinício pelo OCP/K8s - [26/05/2026] Query: Campos de programação alterados de
SCHEDSTART/SCHEDEND→EXECSTART/EXECENDpara DTH_INICIO/FIM_PROGRAMACAO - [26/05/2026] REQTYPEID: Pendência cadastral MERGE agora usa
'AD'para todas as origens (antes:'0C'para ADMS,'AD'para PDA) - [26/05/2026] GIS: Nova query
ObterDadosATOS_TP_TC_ATIVO(joinatos_tp_tc_ativo+atos_tp_tcviaid_instalacao) - [26/05/2026] Performance:
Contexto.csrefatorado com compiled expression tree setters (cacheConcurrentDictionary, elimina reflection por linha) - [26/05/2026] Transações:
BeginTransactionAsync/CommitAsync/RollbackAsync/DisposeAsynccorrigidas em AtualizaExportacao e PendenciaCadastral
Workers internos e processo S40 [atualizado 26/05/2026]
ConsultaOrigem— produzsgm_origem_os· MridGenerator via factory DI · circuit breaker (5 falhas → StopApplication) · EXECSTART/EXECEND · filtroDTH_ATUALIZACAO_MANUTENCAO IS NOT NULL OR DTH_ATUALIZACAO_EXPORTACAO IS NOT NULLRetornoSuspensao— consomesgm_retorno_os· circuit breaker + consumer auto-reconnect (30s backoff) · transação async corrigidaPendenciaCadastral— consomesgm_pendencia_cadastral_tecnica_adms· circuit breaker + consumer auto-reconnect (30s backoff) · REQTYPEID='AD' · transação async corrigidaS40Service— CronJob: chamaPCR_OSSS_S40_EQMno INMD a cada 5 minAtualizaExportacao— UPDATEDTH_ATUALIZACAO_EXPORTACAO = SYSDATE· transação async corrigida comawait using OracleCommand- Leitura SGM:
SGM.TASK,SGM.TASKEXECALL,SGM.REQUEST - Escrita/retorno INMD:
INMD.OS_SS_S40_RETORNO+PCR_OSSS_S40_EQM - Pendências cadastrais: MERGE em
SGM.REQUEST; enriquecimento GIS via INEO (+ATOS_TP_TC_ATIVO) - Processo:
172 - Importar SS/OS - S40 (EQM_INTEGRA)
✅ O que faz: Middleware OUTBOUND do SGM. Consome sgm_origem_os do Kafka e envia as OSs do SGM para o ADMS via Sensedia API "Receive Works - ADMS" (SMR adapter, REST receive-works).
🛑 Se parar: OSs do SGM não chegam ao ADMS. Equipes de manutenção sem OS no campo.
📌 Regras:
- Consome sgm_origem_os → POST Sensedia "Receive Works - ADMS" (SMR adapter) → ADMS REST receive-works
✅ O que faz: Middleware INBOUND SOAP do SGM. Recebe chamadas SOAP do ADMS via Sensedia API "Send Works Service - ADMS" (SMN adapter) com retorno de OSs e produz sgm_retorno_os para o MsSgmOrdemServico.
🛑 Se parar: ADMS não consegue devolver retorno de OS para o SGM. Pipeline de confirmação de OS SGM quebra.
📌 Regras:
- Endpoint SOAP: Sensedia "Send Works Service - ADMS" (SMN adapter) → ApiSmnMiddleware → sgm_retorno_os
- Produz sgm_retorno_os consumido pelo MsSgmOrdemServico
SOAP SendWorks
MsSgmOrdemServico — verificar logs do worker ConsultaOrigem lendo SGM.TASK, SGM.TASKEXECALL e SGM.REQUEST. Tabelas SGM: checar registros pendentes nessas tabelas. Oracle INMD: verificar execução do S40Service e a tabela OS_SS_S40_RETORNO; a procedure PCR_OSSS_S40_EQM serve exclusivamente para processar o retorno de OSs editadas no ADMS (suspensas pela operação, inseridas em OS_SS_S40_RETORNO) — não tem relação com as consultas de OS/SS enviadas ao ADMS, que são feitas exclusivamente pelo serviço .NET.sgm_origem_os. Falhas no S40Service/INMD impedem o processamento periódico S40, mas não significam que a leitura principal de OSs ocorra por procedure no Oracle SGM.TASK, TASKEXECALL e REQUEST. 3) Testar conectividade com Oracle INMD antes de executar PCR_OSSS_S40_EQM manualmente. 4) Se houver lock, acionar DBA do schema correto.sgm_origem_os — ApiSmrMiddleware enviando OS ao ADMS?
▶
sgm_origem_os. ELK: apismrmiddleware. Datadog: service apismrmiddleware. Verificar também o Sensedia SMR adapter — portal Sensedia → API SMR → logs de requisição.oc get pods -n adms | grep apismrmiddleware. 2) Checar logs ELK por erros ao chamar o ADMS via Sensedia SMR. 3) Verificar se o endpoint do ADMS SMR está disponível (testar manualmente). 4) Confirmar que o token do Sensedia SMR adapter é válido.sgm_retorno_os — MsSgmOrdemServico recebendo retornos do ADMS?
▶
sgm_retorno_os. ELK: MsSgmOrdemServico. Oracle INMD: SELECT * FROM OS_SS_S40_RETORNO WHERE DT_RETORNO > SYSDATE - 1/24 ORDER BY DT_RETORNO DESC.sgm_retorno_os. 2) Checar logs do MsSgmOrdemServico por erros ao gravar no Oracle INMD. 3) Verificar conectividade com Oracle INMD.apismrmiddleware — filtrar por erros HTTP (5xx = problema no ADMS, 4xx = problema no payload, timeout = problema de rede).SELECT STATUS, COUNT(*) FROM TASK WHERE DT_CRIACAO > SYSDATE - 1 GROUP BY STATUS. Verificar também: SELECT * FROM TASKEXECALL WHERE STATUS = 'PENDENTE' AND DT_SOLICITACAO < SYSDATE - 1/12 (pendente há mais de 2 horas é anormal). Checar locks: SELECT * FROM V$LOCKED_OBJECT lo JOIN DBA_OBJECTS obj ON lo.OBJECT_ID = obj.OBJECT_ID WHERE obj.OBJECT_NAME IN ('TASK','TASKEXECALL','REQUEST').apismrmiddleware (outbound — envia ao ADMS) e apismidleware (inbound — recebe do ADMS). Datadog: services apismrmiddleware e apismidleware. Verificar error rate e latência P95.sgm_pendencia_cadastral_tecnica_adms a mensagem com o registro do incidente. Se existir a mensagem, consultar no ELK do projeto MsSgmOrdemServico se existem logs de erro durante a tentativa de cadastro desta SS.📊 Fluxo 9 — IQOS
✅ O que faz: API REST que recebe dados do ADMS e os publica nos tópicos Kafka do IQOS. Porta de entrada do pipeline IQOS — converte chamadas REST em eventos Kafka.
🛑 Se parar: Dados do ADMS não entram no pipeline IQOS. Tabelas Oracle ETL_SOURCE não são atualizadas.
📌 Regras:
- Produz 3 tópicos: adms-iqos-catalog-data, adms-iqos-real-time, adms-iqos-event-data
- ELK index: apiadmsiqoskafkaproducer
✅ O que faz: 5 consumers paralelos que consomem os tópicos IQOS e gravam nos 16 tabelas Oracle ETL_SOURCE. Ativo apenas para as empresas EMS, EMS1 e EMR.
🛑 Se parar: Dados IQOS não chegam ao Oracle ETL_SOURCE. Relatórios e dashboards IQOS ficam desatualizados.
📌 Regras:
- Apenas 3 empresas ativas: EMS, EMS1 e EMR
- Mensagens com falha persistente vão para DLQs — monitorar
- 16 tabelas de destino no Oracle ETL_SOURCE
16 tabelas Oracle ETL_SOURCE
ADMS_REGION, ADMS_SUBSTATION, ADMS_FEEDER, ADMS_CIRCUIT, ADMS_CUSTOMER, ADMS_METER_READ, ADMS_AMI_EVENT, ADMS_NETWORK_TOPOLOGY
EMS · EMS1 · EMR apenas
✅ O que faz: API REST que recebe atualizações de OS do sistema IQOS via PATCH e persiste no MongoDB mdb_ordem_servico_crp.
🛑 Se parar: Atualizações de OS vindas do IQOS não chegam ao MongoDB do SIGOD.
📌 Regras:
- Endpoint: PATCH /ordem-servico/{Id}
- Campos atualizáveis: EQUIPE, CAUSA, DATA_DESPACHO/CHEGADA/EXECUCAO/CONCLUSAO/CONHECIMENTO, SERVICO, COMENTARIO, INSTALACAO_INDICE, ESTADO
- Grava em mdb_ordem_servico_crp
adms-iqos-catalog-data — dados de catálogo atrasados?
▶
adms-iqos-catalog-data. Verificar lag do consumer group de catálogo adms-iqos-consumer; o serviço possui 5 consumers/rotinas, mas o ER não confirma 5 groups específicos para o tópico de catálogo. ELK: apiadmsiqoskafkaconsumer. Datadog: service apiadmsiqoskafkaconsumer.oc get pods -n adms | grep apiadmsiqoskafkaconsumer. 2) Checar logs ELK por exceções. 3) Verificar se o Oracle ETL_SOURCE está respondendo (pode ser lentidão no banco que causa back-pressure). 4) Checar se as empresas ativas (EMS, EMS1, EMR) estão configuradas corretamente.adms-iqos-real-time — dados de tempo real atrasados?
▶
adms-iqos-real-time. ELK: apiadmsiqoskafkaconsumer. Datadog: APM → service apiadmsiqoskafkaconsumer → tópico adms-iqos-real-time.apiadmsiqoskafkaproducer). 2) Checar se o ADMS está enviando dados ao Producer (volume de requisições no endpoint). 3) Verificar se o Consumer está processando os outros tópicos ou se há erro generalizado.adms-iqos-event-data — eventos de rede pendentes?
▶
adms-iqos-event-data. ELK: apiadmsiqoskafkaconsumer — filtrar por mensagens do tópico de eventos. Oracle ETL_SOURCE: verificar tabelas de eventos se há inserções recentes.adms-iqos-catalog-data-dlq, adms-iqos-real-time-dlq, adms-iqos-event-data-dlq. Verificar número de mensagens em cada DLQ — qualquer número > 0 é alerta. ELK: apiadmsiqoskafkaconsumer — filtrar por logs de DLQ.SELECT TABLE_NAME, COUNT(*) FROM (SELECT 'TABELA_A' AS TABLE_NAME FROM TABELA_A WHERE DT_CARGA > SYSDATE - 1/24 UNION ALL ...) GROUP BY TABLE_NAME. ELK: apiadmsiqoskafkaconsumer — filtrar por erros de INSERT Oracle.oc describe configmap <config-name> -n adms | grep -i empresa). ELK: verificar se há mensagens processadas para empresas diferentes de EMS, EMS1 e EMR — isso seria um problema de configuração.mdb_ordem_servico_crp — ApiGodIqosOcorrenciaReclamacao gravando ocorrências?
▶
mdb_ordem_servico_crp — verificar collection de ocorrências/reclamações, checar documentos com createdAt recente. ELK: apigodiqosocorrenciareclamacao. Datadog: service apigodiqosocorrenciareclamacao.oc get pods -n adms | grep apigodiqosocorrencia. 2) Checar logs ELK por erros de escrita MongoDB. 3) Verificar se o tópico de entrada está com lag. 4) Testar conectividade MongoDB.🔧 Serviços de Suporte (APIs e Workers auxiliares)
/ConnectionHub.mdb_modelo_crp.