SAP Alerting and Notifications

A failed integration discovered by an angry customer — "My order was placed three hours ago and nothing happened" — is worse than a failure discovered by your monitoring system in real time. Alerting exists to close this gap. A good alerting system tells the right person about the right problem at the right time, with enough context to act immediately.

What Should Trigger an Alert

Not every event needs an alert. Alert fatigue — too many notifications for minor events — causes teams to ignore alerts entirely, defeating their purpose. Define alert-worthy conditions clearly:

Alert immediately: Any business-critical iFlow fails processing a message
Alert immediately: An iFlow enters Error status (stopped running entirely)
Alert within 15 minutes: More than three consecutive failures on any iFlow
Alert daily summary: Total failure count across all iFlows for the past 24 hours
Alert weekly: Performance trend report — average processing times per iFlow
Do not alert: Successful message processing (no news is good news)

Alert Channels

Email Alerts

The simplest alert mechanism. Use the Mail adapter in the Exception Sub-Process to send an email when any failure occurs. Configure a dedicated integration operations mailbox — not individual developer inboxes — so alerts are not missed when someone is on holiday.

Mail Adapter configuration in Exception Sub-Process:
  To:      integration-ops@company.com
  CC:      (optional) business-owner@company.com for critical flows
  Subject: [CRITICAL] CPI Failure - ${property.IFlowName} - ${property.BusinessID}
  Body:    Error details, timestamp, failed payload excerpt, action steps

Teams / Slack Notifications

Modern operations teams use chat platforms for incident response. Send alerts directly to a Microsoft Teams or Slack channel using their incoming webhook URLs. Use the HTTP adapter in the Exception Sub-Process to POST a JSON message to the webhook:

Slack Webhook POST body:
{
  "text": "CPI Alert: iFlow ${property.IFlowName} failed",
  "attachments": [{
    "color": "danger",
    "fields": [
      {"title": "Order ID", "value": "${property.BusinessID}"},
      {"title": "Error",    "value": "${property.ErrorMsg}"},
      {"title": "Time",     "value": "${property.ErrorTime}"}
    ]
  }]
}

SAP Alert Management

CPI integrates with SAP's built-in Alert Management capability. You configure alert rules in the Integration Suite and assign notification recipients. SAP sends alerts through the BTP notification service. This approach centralizes alert configuration in one place rather than embedding email addresses inside individual iFlows.

ITSM Ticket Creation

For organizations using ServiceNow, Jira Service Management, or similar platforms, critical integration failures should automatically create incident tickets. Use the HTTP adapter in the Exception Sub-Process to call the ITSM platform's REST API and create a ticket with the error details pre-filled. The operations team then works the ticket through their normal incident process.

Alert Message Content Standards

Every alert should answer these questions without requiring the recipient to open any other system:

ALERT TEMPLATE ELEMENTS:
1. Severity: CRITICAL / HIGH / MEDIUM / LOW
2. System:   Which iFlow failed (full name)
3. Time:     When the failure occurred (with timezone)
4. Business: What business document was being processed (order ID, invoice #)
7. Error:    What specifically went wrong (error message text)
5. Source:   Which system sent the data that failed
6. Impact:   What business process is blocked
8. Action:   What the recipient should do next
9. Link:     Direct URL to the MPL in CPI monitor (if accessible)

Alert Severity Levels

Define severity levels and document what each means for your organization:

CRITICAL – Core business process stopped. Revenue impact possible. Page on-call engineer immediately. Example: payment processing integration down.
HIGH – Important integration failing but workaround exists. Respond within one hour. Example: customer data sync failing, manual entry possible.
MEDIUM – Non-urgent integration issue. Respond within business hours. Example: reporting data feed delayed.
LOW – Informational. Review in next daily standup. Example: performance warning threshold crossed.

Preventing Alert Flooding

When one system goes down, every message trying to reach it fails. If each failure sends an alert, the operations team receives hundreds of identical emails in minutes. Use these techniques to prevent flooding:

Deduplication

Before sending an alert, check whether a similar alert was sent in the past 15 minutes. Store the last alert time in a Data Store entry. Only send a new alert if the time since the last alert exceeds your deduplication window.

[Exception occurs]
      ↓
[Read Data Store: LastAlertTime for this iFlow]
      ↓
[Router: Time since last alert > 15 minutes?]
  YES → [Send alert] → [Update LastAlertTime in Data Store]
  NO  → [Log to Data Store only, no new email]

Aggregated Digest

Instead of immediate alerts for every failure, accumulate failures in a Data Store and send a digest every 15 minutes summarizing all failures in that period. Less urgent for operations, but prevents inbox floods.

Health Check iFlows

A health check iFlow verifies that all critical integrations are running and all connected systems are reachable. It runs on a timer every 5-15 minutes and sends an alert if anything is not working — even if no business messages have tried to flow through recently.

Health Check iFlow (runs every 10 minutes):
  [Timer] → [Call SAP OData ping endpoint]
          → [Call Salesforce /healthcheck endpoint]
          → [Call Supplier EDI platform status API]
          → [Router: any endpoint returned error?]
              YES → [Send health alert]
              NO  → [Log all-clear, no alert]

Health check iFlows catch problems during off-peak hours when no business messages are flowing — before the morning rush when real traffic reveals the broken connection.

Escalation Procedures

Document what happens if alerts are not acknowledged within a defined timeframe:

Alert sent to operations mailbox at 14:00 — no acknowledgment
Escalation email to team lead at 14:30 — no acknowledgment
Phone call to on-call engineer at 15:00
Management escalation at 16:00 if revenue-impacting

Document these escalation paths before going live. An unacknowledged critical alert at 2 AM that nobody knows to escalate costs businesses far more than the time it takes to define the escalation procedure.

Previous lesson

Back to course

Next lesson