Lesson 2 of 6
Integration and exception monitoring
10 min
Listen to this lesson
Integration & Exception Monitoring answers two questions: did the messages between systems arrive and process, and did anything throw an error along the way? For Contoso, whose order-to-cash depends on EDI from Great Lakes Fleet Services and whose procure-to-pay sends purchase orders to Lakeside Components, it is the most important monitoring app on day one.
What can be monitored
| Component | Message categories | Exception categories (examples) |
|---|---|---|
| SAP S/4HANA and NetWeaver AS ABAP (higher than 7.40) | IDoc, Web Service Messages, PI Messages | ABAP runtime errors, update errors, gateway errors, aborted jobs, job and application logs, system log, web service consumer and provider errors |
| SAP Integration Suite | Cloud Integration message processing; Edge Integration Cell; Trading Partner Management | Failed integration flow runs |
| SAP BTP (Cloud Foundry, Kyma, ABAP, Neo) | Custom-built applications | Application exceptions |
| SAP Process Integration (Java) | PI messages | Adapter and mapping errors |
Components and categories from SAP's setup pages; requirements differ per category.
Prerequisites vary per category, so read the product page before planning. For ABAP, SAP lists ST-PI 7.40 SP16 for most exception categories and SP26 for the job log and job application log categories, ST-PI 7.40 SP20 to monitor PI messages, and SAP Note 3259248 to activate SAP Passport collection for IDocs, which is what lets an IDoc be correlated with the message that carried it. Users need an integration role in SAP Cloud ALM (for example Integration Architect or Integration Owner).
Setting it up for Contoso
- In Landscape Management, confirm CMP, the Cloud Integration tenant (CMC_PROD) and PO on XP1 are registered and connected.
- In Integration & Exception Monitoring, open the configuration for each service and switch on data collection for the categories you need: IDoc and the ABAP exception categories on CMP; message processing on Cloud Integration; PI messages on XP1.
- Add filters per category so only relevant traffic is collected, for example IDoc message types ORDERS, ORDRSP, DESADV, INVOIC and the partner numbers for Great Lakes and Lakeside.
- Group the interfaces into business services and integration scenarios, such as "Great Lakes EDI order to cash".
- Set housekeeping: single messages and exceptions are kept for 1 to 14 days, aggregated data for 1 to 120 months.
- Define events: an alert and an email to Theo's on-call address when an IDoc for Great Lakes goes into error.
- BTP sideIn the Integration Suite subaccount, provide the access SAP Cloud ALM needs (per SAP's setup guide for Cloud Integration)
- RegisterAdd the Cloud Integration tenant CMC_PROD as a service in Landscape Management with its endpoint and credentials
- CollectSwitch on message processing collection; filter by integration flow, for example the Lakeside 850 flow
- CorrelateCheck that messages from CMP and Cloud Integration line up for the same business document
- AlertEvent rule per critical flow with Theo's team as owner
During the Integration Suite waves, the same monitor shows both worlds. Until each interface moves, its messages run through PO on XP1; afterwards, through Cloud Integration CMC_PROD. Theo filters Integration & Exception Monitoring by partner and compares error rates before and after each wave: the Lakeside order flow in Wave 1 should show the same number of messages per day, with no new error categories. That comparison is part of the wave's sign-off, alongside the message-level tests from sap-pim-301.
Reading the monitor
The monitor shows each service with its message and exception counts by status. Drill into a category to see single messages with their status, sender and receiver, and, where collected, the correlated messages in other components. For an IDoc in error the useful details are the message type, partner, status and status text; navigate from there to the managed system to reprocess (BD87) after the cause is fixed. The same view, filtered to a time window, is the evidence of how an interface behaved during a test or a release.
| Decision | Too little | Too much | Contoso choice |
|---|---|---|---|
| Categories switched on | Errors go unseen | Noise and data volume | IDoc, PI, Cloud Integration, ABAP runtime, update and gateway errors |
| Filters | Missing partners | Every test IDoc in CMR alerts | Production partners only in CMP; test partners in CMR |
| Payload collection | Hard to analyze | Personal data copied to the tenant | Off by default; on for a short time during an investigation |
| Event rules | No one is told | Alert fatigue | One rule per business-critical interface with a named owner |
The setup decisions that decide whether monitoring helps or drowns the team.
What would you do?
After switching on every exception category for CMP, Theo's team receives over 400 alert emails on the first night, mostly ABAP runtime errors from a custom report run by a few users. The interface alerts are lost in the flood. What should Theo change first?
- Integration & Exception Monitoring covers ABAP, Integration Suite, BTP and PI messages and exceptions.
- Prerequisites differ per category: check ST-PI levels and notes such as 3259248 for IDoc passports.
- Collect broadly with filters, but alert narrowly with owners.
- Prove monitoring with forced errors in pre-production.
Check your understanding · not graded
Lesson check
1. Which note activates SAP Passport collection for IDocs?
2. How long can single messages and exceptions be kept?
3. What lets SAP Cloud ALM link a PI message to its IDoc?
4. What is the best answer to alert floods?