No SAP CPI / SAP Integration Suite, tratamento de erros não é “detalhe de implementação”. É arquitetura: define confiabilidade, custo operacional e o risco de impactar finanças, estoque, folha ou master data.
A diferença que quase sempre é ignorada: retentativa vs reprocessamento
Retentativa é automática e acontece sem uma validação humana do impacto. Reprocessamento é intencional: alguém decide rodar a mensagem novamente com contexto (e com um plano para evitar duplicados).
Se o time não consegue explicar essa diferença por integração, o sistema não está pronto para produção: ele roda, mas não se sustenta.
Classifique falhas antes de desenhar a solução
Uma política madura de retentativas começa com uma classificação simples:
- Transitória: timeouts, throttling, falhas momentâneas de rede/capacidade.
- Funcional: dados inválidos, regras de negócio, autorizações inexistentes, datas fora do intervalo.
- Dependência: downstream degradado, em manutenção ou com filas saturadas.
- Contrato: payload não cumpre o esquema, faltam campos obrigatórios ou uma API mudou.
Normalmente só a primeira categoria é candidata a retentativas automáticas. O restante exige reprocessamento controlado ou correção de dados.
Idempotência: a condição mínima para retentar com segurança
Retentar sem idempotência não é resiliência: é duplicação com atraso. Em integrações SAP, um único duplicado pode gerar documentos repetidos, lançamentos duplicados ou ruído de reconciliação.
A pergunta-chave não é “podemos retentar?”. É “que evidência temos de que uma segunda tentativa não cria um segundo efeito de negócio?”
| Decisão | Evidência mínima |
|---|---|
| Quais mensagens podem retentar automaticamente | Lista por iFlow + condição explícita (HTTP status/classe de erro) + limite de tentativas |
| Como evitamos duplicados | Chave idempotente (por negócio) + deduplicação no destino ou um ponto de controle na integração |
| O que acontece após falha definitiva | Rota de exceção + fila/caixa de pendências + dono e SLA operacional |
| Como o suporte investiga e coordena | Correlation ID consistente + logs úteis + runbook de triagem |
Checklist de governance (prático, sem papelada)
Para cada integração produtiva, valide:
- Contrato de retentativas: tentativas, estratégia de backoff e quais erros qualificam.
- Contrato de reprocessamento: quem reprocessa, de onde e como evitamos duplo efeito.
- Runbook: passos claros de diagnóstico, incluindo “o que NÃO fazer” sob pressão.
- Observabilidade mínima: rastreabilidade por correlação, contexto acionável de erro e evidência de payload (sem expor dados sensíveis).
- Segregação: quem pode fazer deploy, quem pode reprocessar e como auditar ações.
Isso não substitui ferramentas de ciclo de vida SAP (ALM/transporte/monitoramento runtime). Reduz o caos operacional dentro do escopo real de governança de middleware.
Quando isso vira um problema de arquitetura
Se hoje o time “resolve” incidentes com retentativas cegas, o problema já não é um iFlow. É design e governança: idempotência, ownership de dados e um processo de suporte desalinhado com o risco.