SAP CPI: rastreabilidade end-to-end com Correlation ID (sem arqueologia)

Um Correlation ID bem desenhado transforma “buscar em 5 sistemas” em “seguir um fio”. O segredo é tratá-lo como parte do contrato operacional da integração: ele é gerado, propagado, registrado e usado em suporte.

1) Defina o que você correlaciona (e o que não)

Antes de escolher um header, defina o escopo:

• Unidade de correlação: pedido, empregado, fatura, transferência, ticket?
• Cardinalidade: um ID por mensagem, por transação ou por lote?
• Privacidade: evite IDs que exponham dados pessoais; use identificadores técnicos ou tokens seguros.

2) Padrão mínimo: um header estável + um identificador de execução da plataforma

Para suporte, ajuda separar:

• Correlation ID (negócio): viaja entre sistemas e une os saltos (ex.: X-Correlation-ID).
• ID de execução (plataforma): o que o runtime fornece (IDs de mensagens e logs) para chegar ao detalhe técnico.

O erro comum é usar apenas o ID da plataforma: ele funciona para olhar um salto, mas não para costurar a jornada inteira quando há retentativas, replay ou rotas paralelas.

3) Propagação: cada salto preserva o fio

Seja HTTP, SOAP, OData ou filas, o padrão é o mesmo: o Correlation ID entra ou é gerado e depois é copiado para cada request de saída.

• Inbound: se chegar um ID válido, mantenha; se não, gere um.
• Outbound: injete o mesmo ID em headers de saída (e, se aplicável, em respostas).
• Batch: defina se o ID é por lote (bom para suporte) e use um sub-ID por item quando precisar de granularidade.

4) Implementação no SAP CPI / Integration Suite (padrão operacional)

Sem amarrar em um iFlow específico, um padrão saudável costuma ser:

1. Validar/normalizar o Correlation ID no início (tamanho, charset, formato).
2. Persistir como propriedades para reutilizá-lo em todo o fluxo (e não perdê-lo em mapeamentos).
3. Injetar em outbound (HTTP headers, SOAP headers ou capacidades equivalentes do adapter).
4. Logging mínimo: em erros ou retentativas, registrar Correlation ID + contrato (entidade, operação, destino).

Um bom sinal é cada iFlow ter uma seção explícita de “observabilidade”: o que registra, o que não registra e como o suporte traça um caso ponta a ponta.

5) Evidência mínima para suporte (sem dumping de logs)

“Mais logs” não é estratégia. O mínimo útil normalmente inclui:

• Correlation ID + timestamp + ambiente.
• Contrato: entidade/operação/destino.
• Fingerprint: hash do payload ou assinatura estável sem dados sensíveis.
• Resultado: sucesso/falha + classe de erro (transitório vs funcional).

Isso não substitui tooling SAP de lifecycle, transport management ou monitoramento runtime. É governança de middleware focada em rastreabilidade operável.

6) Governança: evitar “cada iFlow do seu jeito”

Quando não há padrão, a rastreabilidade quebra no primeiro change. Defina regras simples:

• Nomes: um header canônico e formato (UUID ou token seguro).
• Obrigatoriedade: quais integrações devem sempre incluí-lo (a maioria dos fluxos entre sistemas).
• Runbook: “como traçar um caso” do ticket ao salto que falhou.
• Testes: smoke test validando que o Correlation ID sobrevive na jornada.

Checklist rápido (para partners SAP)