Muitas operações de SAP CPI / Integration Suite falham no pior momento não por falta de monitoramento, mas porque o time não tem uma forma consistente de interpretar o alerta. A mensagem de erro existe, o payload existe, o MPL existe, mas a decisão depende da pessoa que conhece o fluxo de memória.
Um runbook operacional resolve uma parte concreta do problema: transforma conhecimento disperso em passos verificáveis. Não substitui SAP Cloud ALM, SAP Transport Management, alertas runtime nem critério de arquitetura. Funciona como camada de resposta para que suporte atue com contexto, limites e evidência.
1) Começar por cenários, não por telas
Um runbook útil não descreve cada botão do console. Descreve cenários que realmente acontecem e o que deve ser verificado em cada um.
- Falha técnica: timeout, autenticação, certificado, conectividade ou recurso indisponível.
- Falha funcional: dado inválido, regra de negócio, estrutura inesperada ou catálogo incompleto.
- Risco operacional: duplicidade potencial, reprocessamento parcial, backlog acumulado ou dependência externa lenta.
- Exceção controlada: pausa temporária, janela de manutenção, endpoint alternativo ou mudança autorizada.
A diferença importa porque cada classe de evento tem owner, severidade e ação distinta. Tratar tudo como erro genérico gera reprocessamentos inseguros e escalações fracas.
2) Definir severidade pelo impacto de negócio
A severidade não deveria depender apenas da cor do alerta. Deve conectar o estado técnico com o impacto operacional.
| Severidade | Critério prático | Decisão esperada |
|---|---|---|
| P1 | Processo crítico parado ou alto risco de duplicidade financeira, logística ou de folha. | Escalar imediatamente com owner funcional e técnico. |
| P2 | Backlog crescente, SLA em risco ou dependência externa intermitente. | Diagnosticar, conter e acordar uma janela de recuperação. |
| P3 | Erro individual sem impacto sistêmico e com reprocessamento controlável. | Corrigir dado, reprocessar com evidência e registrar causa. |
3) Documentar diagnóstico mínimo
Cada runbook deve dizer onde olhar e o que capturar. Para SAP CPI normalmente convém incluir Message Processing Log, Correlation ID, nome do iFlow, tenant, ambiente, timestamp, endpoint chamado, evidência de payload permitida para suporte e resposta do sistema receptor quando disponível.
4) Separar ações seguras de ações restritas
O runbook deve marcar claramente o que L1/L2 pode executar e o que exige aprovação de arquitetura, segurança ou owner funcional.
- Ações seguras: confirmar estado, coletar evidência, validar duplicidade, revisar backlog e notificar o owner.
- Ações condicionadas: reprocessar mensagens, pausar scheduler, alterar parâmetros externalizados ou ativar uma rota temporária.
- Ações restritas: modificar certificados, credenciais, endpoints produtivos, mapeamentos ou lógica do iFlow.
Essa separação reduz improviso e evita que uma correção rápida crie dívida operacional maior.
5) Incluir critérios de reprocessamento e idempotência
Em integrações SAP, reprocessar sem critério pode ser pior do que não reprocessar. O runbook deve indicar se o fluxo é idempotente, como detectar duplicados, qual chave de negócio é usada e quando reconciliação manual é obrigatória antes de enviar de novo.
- Identificar mensagem e chave de negócio.
- Confirmar se o receptor já processou parcial ou totalmente.
- Validar se existe mecanismo idempotente ou bloqueio de duplicados.
- Registrar evidência antes e depois do reprocessamento.
- Escalar se o estado final não puder ser comprovado.
6) Manter o runbook como ativo vivo
Um runbook expira quando muda o endpoint, owner, SLA, certificado, esquema de dados ou padrão de erro. Por isso deve ter data de revisão, responsável e relação com mudanças recentes. Uma seção de dívida conhecida também ajuda: exceções aceitas, gaps de observabilidade e decisões pendentes.
Em revisões de governança, os runbooks mostram se o landscape de integração pode operar sem depender de conhecimento tribal. O Picasso CPI Governance Assessment costuma revisar runbooks, ownership, retentativas, rastreabilidade, evidências e limites operacionais como parte de uma fotografia técnica do tenant.