A falha silenciosa: quando o iFlow não erra, apenas para

Todo time de integração monitora mensagens com falha. É o primeiro painel que alguém monta no SAP Integration Suite, e é o que o CPI entrega mais pronto: filtre o Message Processing Log por Status eq 'FAILED', jogue num alerta, pronto. O problema é que esse painel responde a uma pergunta só — o que deu errado? — e o incidente mais caro de uma paisagem SAP costuma nascer de outra: o que deixou de acontecer?

Uma integração que falha grita. Uma integração que para não faz barulho nenhum. Não há mensagem com falha para contar, porque não há mensagem. O relatório de erros fica vazio, o painel fica verde, e o dado simplesmente deixa de chegar do outro lado.

Como um fluxo para sem errar

As causas são banais, e é isso que as torna perigosas. Nenhuma delas produz um FAILED no MPL:

• O artefato foi despublicado. Alguém subiu uma versão nova, o deploy ficou em Error no runtime e a versão antiga saiu do ar. Não há execução, logo não há falha registrada.
• O agendamento mudou. Um Timer configurado para rodar a cada hora foi alterado — ou o fuso do tenant mudou na migração — e o fluxo passou a rodar às três da manhã de domingo.
• O sistema de origem parou de enviar. O iFlow é acionado por HTTP e continua no ar, íntegro, esperando. Quem parou foi o outro lado: um job no S/4HANA que ninguém reagendou depois da parada programada.
• A fila de origem secou por erro de filtro. Uma consulta OData com critério de delta apoiado em lastModifiedDate passou a não retornar nada depois que o relógio do sistema de origem foi corrigido.
• Credencial expirada em um caminho assíncrono. O fluxo busca, não recebe nada, e encerra com sucesso. Do ponto de vista do CPI, rodou perfeitamente: processou zero registros.

O último caso é o mais traiçoeiro, porque ele aparece no monitor como execução bem-sucedida. Não é ausência de log: é log verde mentindo por omissão.

O interruptor do homem morto

A solução clássica para esse tipo de problema não vem do software — vem da ferrovia. O dead-man's switch é o dispositivo que o maquinista precisa manter pressionado; se ele solta, por qualquer motivo, o trem freia. A lógica é invertida em relação ao alarme comum: o silêncio é o alarme.

Aplicado a integração, o princípio fica assim: para cada fluxo crítico, declare qual é o intervalo máximo aceitável sem nenhuma execução bem-sucedida. Passou disso, alerta — independentemente de haver erro registrado.

A objeção imediata é: e os fluxos que legitimamente ficam parados? Um iFlow de faturamento que só roda no fechamento mensal passaria 28 dias disparando alerta. É por isso que o intervalo não pode ser um número global. Ele precisa ser derivado do comportamento de cada fluxo.

Calculando o silêncio aceitável

O caminho que funciona é aprender a cadência antes de vigiá-la. Duas ou três semanas de observação do MPL dão uma linha de base razoável, por fluxo e por faixa de horário — porque quase nenhuma integração tem volume uniforme ao longo do dia e da semana.

Na prática, guarde a média de execuções bem-sucedidas por combinação de dia da semana e hora. Um fluxo de replicação de colaboradores que roda de hora em hora das 6h às 22h em dias úteis produz um perfil claro: 16 baldes cheios, 8 vazios, sábado e domingo vazios. O alerta então pergunta: estamos num balde que historicamente tem movimento? Se sim, e o silêncio já passou do previsto para aquele balde, avise.

Isso resolve o fechamento mensal sem nenhuma exceção manual: o balde daquele dia tem média zero em 27 dias do mês, e o alerta não dispara. Um fluxo genuinamente irregular — eventos disparados por usuário, por exemplo — nunca formará uma linha de base confiável, e é honesto marcá-lo como não monitorável por cadência em vez de gerar ruído.

A janela do alerta importa tanto quanto o alerta

Detectar é metade do trabalho. A outra metade é não destruir a própria detecção com excesso de mensagem. Quando um fluxo cai, ele raramente cai uma vez: uma pane de conectividade produz dezenas de falhas em minutos, e um alerta por ocorrência transforma o celular do plantonista em algo que ele desliga.

Agrupe por fluxo, dentro de uma janela — trinta minutos costuma ser um bom ponto de partida. O primeiro erro alerta e abre a janela; os seguintes viram contador. Quando a janela vence, o próximo alerta sai levando junto quantos ficaram pelo caminho: “+47 falhas agrupadas desde o alerta anterior”.

Essa última parte não é detalhe estético. Agrupar sem dizer quanto foi agrupado faz uma pane de duzentas falhas parecer uma falha isolada, e quem recebe dimensiona errado a resposta. O alerta precisa dizer a verdade sobre o tamanho do problema, não só sobre a existência dele.

O que medir, na ordem

1. Ausência de execução em fluxo com cadência conhecida — a falha que nenhum outro indicador pega.
2. Execuções com falha, agrupadas por fluxo e por janela de tempo.
3. Execuções bem-sucedidas com volume zero, quando o fluxo historicamente move registros. É o log verde que mente.
4. Estado de runtime do artefato — despublicado ou em erro de deploy conta como parada, mesmo com o desenho intacto.
5. Validade dos certificados usados pelos adapters. É o único incidente P1 da lista que tem data marcada e mesmo assim pega todo mundo de surpresa.

Onde isso encosta no que construímos

O iFlowMind Monitor implementa exatamente esse desenho: aprende a linha de base por fluxo e por balde de horário, alerta por silêncio além do previsto, agrupa a rajada dentro de uma janela configurável e informa quantas ocorrências foram agrupadas. Quando há erro, ele lê o log, o stack trace e a configuração do iFlow juntos para propor a causa raiz — e não só repetir a mensagem de exceção.

Mas o desenho vale mesmo sem nós. Se você tem um script, um job no seu observability stack ou um painel caseiro, as cinco medidas acima e a janela de agrupamento cabem em qualquer implementação. O erro que vale evitar é o primeiro: acreditar que monitorar falhas é monitorar a integração.

Leia também: Tratamento de erro no CPI: passar não é aguentar.