Why triage design matters
Most integration incidents are not caused by exotic faults. They come from expired credentials, unavailable target systems, bad master data, duplicate messages and changes that were released without a regression pack. What turns these into long incidents is the absence of a design: nobody knows who owns the failure, which alert is real, or whether it is safe to resend the message.
Error handling is the set of technical behaviours that decide what an interface does when something goes wrong. Triage is the operating process that decides who looks at it, in which order, and with which permissions. This guide treats them as one design problem, from the moment an alert fires to the moment the business document is correct in the target system.
The audience is mixed, so here is the split of concerns. The CIO cares about business impact, accountability and control. The integration architect cares about patterns and tooling. The head of the SAP centre of excellence cares about runbooks, roles and whether the support team can actually run this on a Monday morning.
Step one: classify errors before you alert
Alerts without classes produce noise. Start by agreeing a small set of error classes and attach an owner and a default action to each.
Recommended error classes
- Connectivity errors: the target or source cannot be reached, a certificate or credential has expired, or the path through SAP Cloud Connector to an on-premise system is down. Owner: platform or basis team. Default action: retry with backoff, then alert.
- Technical processing errors: a script fails, a message is too large, a transformation breaks on unexpected structure. Owner: integration development team. Default action: no automatic retry, open an incident with the log attached.
- Data and mapping errors: a mandatory field is missing, a code value has no mapping, a format is invalid. Owner: the data owner in the business process, supported by integration. Default action: route to the dead letter location and notify the data owner.
- Business application errors: the target system rejects the document for a business reason, for example a closed posting period or a blocked customer. Owner: the functional team of the receiving application. Default action: notify the functional queue, never retry blindly.
- Security and policy errors: failed authentication, rejected tokens, quota breaches, malicious payloads blocked at the API layer. Owner: security or API platform team. Default action: alert immediately and review the pattern.
