Many SAP CPI / Integration Suite operations fail at the worst moment not because monitoring is missing, but because the team has no consistent way to interpret the alert. The error message exists, the payload exists, the MPL exists, but the decision depends on the person who remembers the flow.
An operational runbook solves one specific part of the problem: it turns scattered knowledge into verifiable steps. It does not replace SAP Cloud ALM, SAP Transport Management, runtime alerts or architectural judgment. It works as a response layer so support can act with context, boundaries and evidence.
1) Start with scenarios, not screens
A useful runbook does not describe every console button. It describes scenarios that actually happen and what should be checked in each one.
- Technical failure: timeout, authentication, certificate, connectivity or unavailable resource.
- Functional failure: invalid data, business rule, unexpected structure or incomplete catalog.
- Operational risk: potential duplicate, partial reprocessing, accumulated backlog or slow external dependency.
- Controlled exception: temporary pause, maintenance window, alternate endpoint or authorized change.
The distinction matters because each event class has a different owner, severity and action. Treating everything as a generic error leads to unsafe reprocessing and weak escalation.
2) Define severity through business impact
Severity should not depend only on the alert color. It should connect technical state with operational impact.
| Severity | Practical criterion | Expected decision |
|---|---|---|
| P1 | Critical process stopped or high duplicate risk for finance, logistics or payroll. | Escalate immediately with functional and technical owners. |
| P2 | Growing backlog, SLA at risk or intermittent external dependency. | Diagnose, contain and agree on a recovery window. |
| P3 | Individual error with no systemic impact and controlled reprocessing path. | Correct data, reprocess with evidence and record the cause. |
3) Document minimum diagnosis
Each runbook should say where to look and what to capture. For SAP CPI this usually includes Message Processing Log, Correlation ID, iFlow name, tenant, environment, timestamp, called endpoint, support-safe payload evidence and receiver response when available.
4) Separate safe actions from restricted actions
The runbook should clearly mark what L1/L2 can execute and what requires architecture, security or functional owner approval.
- Safe actions: confirm status, collect evidence, validate duplication, review backlog and notify the owner.
- Conditional actions: reprocess messages, pause a scheduler, change externalized parameters or activate a temporary route.
- Restricted actions: modify certificates, credentials, production endpoints, mappings or iFlow logic.
This separation reduces improvisation and prevents a quick correction from creating larger operational debt.
5) Include reprocessing and idempotency criteria
In SAP integrations, reprocessing without criteria can be worse than not reprocessing. The runbook should state whether the flow is idempotent, how duplicates are detected, which business key is used and when manual reconciliation is required before sending again.
- Identify the message and business key.
- Confirm whether the receiver already processed it partially or fully.
- Validate whether an idempotent mechanism or duplicate lock exists.
- Record evidence before and after reprocessing.
- Escalate if the final state cannot be proven.
6) Keep the runbook as a living asset
A runbook expires when the endpoint, owner, SLA, certificate, data schema or error pattern changes. It should have a review date, responsible owner and relation to recent changes. A known-debt section also helps: accepted exceptions, observability gaps and pending decisions.
In governance reviews, runbooks show whether the integration landscape can operate without tribal knowledge. The Picasso CPI Governance Assessment often reviews runbooks, ownership, retries, traceability, evidence and operational boundaries as part of a technical snapshot of the tenant.