Integration and exception monitoring

Interfaces fail quietly. A tester presses Save, the order is created, and nobody notices that the outbound message to the carrier is sitting in error. In system integration testing that becomes a defect found days later; in production it becomes a customer complaint. Integration & Exception Monitoring puts those failures in front of the people who need to see them, with enough detail to act.

Three functions

SAP's Expert Portal describes three main functions. Message monitoring gives a status overview of incoming and outgoing messages per business system or cloud component, and components can be grouped into scenarios that describe a message flow. Message search, also called tracking, finds single messages by business context such as an order number, across components. Alerting raises alerts for error situations, for example messages in error on a component or scenario, and manages them in an alert inbox where you can assign a processor, comment, postpone or confirm.

What it can see in an ABAP system

SAP publishes the monitoring categories per product. For SAP S/4HANA on-premise and private cloud, the list includes IDocs, web service messages, AIF messages and PI messages, and also exceptions from the ABAP side: application log, runtime errors, update errors, gateway errors, aborted jobs, job logs and the system log. For SAP Integration Suite it includes Cloud Integration messages and integration artifact deployments, among others. Categories differ by product and release, so check the content page for your landscape.

Messages are rated in status groups: ERROR, WARNING, IN PROCESS, CANCELED, SUCCESSFUL, INFO and OTHERS. A business object view also shows the status of master data replication, which matters for Contoso's business partner replication after the conversion.

Using it in interface testing

Contoso's SIT covers 41 interfaces, the SIT subset of the 64 integrated configurations on SAP Process Orchestration, including EDI orders and invoices with Great Lakes Fleet Services and supplier messages with Lakeside Components. Before SIT starts, Sam's team connects CMQ and activates integration and exception collection, and the integration specialist groups the components into scenarios that mirror the SIT test cases: order to cash EDI, procure to pay supplier messages, bank statements.

• Before each test run: check the scenario view is green, so old errors are not mistaken for new ones.
• During the run: search by the order or PO number the tester created, and confirm every hop reached SUCCESSFUL.
• On failure: attach the message details and status history to the defect in Cloud ALM, not a screenshot of a list.
• After the cycle: review alert counts per scenario; a scenario that raised many warnings needs a look even if tests passed.

Use the same view for negative tests. When Priya's team deliberately sends an EDI order with an unknown material number, the expected result is an error in the right status group, with a readable message, raised as an alert to the right person. A negative test that fails silently is as much a defect as a positive test that fails loudly.