Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 5 of 5

Monitors and mocks

10 min

Listen to this lesson

0:00 / 9:20

Two practical questions decide whether interface testing goes smoothly. Where do I look to see what happened to a message? And what do I do when the partner system is not available to test with? This lesson answers both.

Where to monitor

Technology or layerMonitorWhat it shows
IDocsWE02 / WE05, BD87IDocs by status, segments, error messages, reprocessing
Transactional RFCSM58Asynchronous RFC calls that failed or are waiting
Queued RFCSMQ1 (outbound), SMQ2 (inbound)Queues and entries stuck because an earlier entry failed
Background RFCSBGRFCMONbgRFC units and their status
OData services/IWFND/ERROR_LOG (SAP Gateway error log)Failed service calls with user, time and error context
SOAP web servicesSRT_UTIL, SRT_MONIWeb service error log and message monitor
MiddlewareSAP Integration Suite message monitoringEach message's processing status, steps and errors in the integration flow
End to endSAP Cloud ALM integration and exception monitoringCross-system view of interface health and exceptions, where set up

Monitors a tester should know. Availability depends on your landscape and authorizations.

Some organizations also use the SAP Application Interface Framework (AIF), which gives business users a monitor of interface messages in business terms, with the ability to correct and reprocess. If Contoso uses it for customer orders, Maria may handle errors there rather than in BD87, and the test should prove she can.

  1. Order 1 postsThe queue processes normally.
  2. Order 2 failsFor example, a blocked customer; the entry stops in SMQ2.
  3. Orders 3 onward waitEvery later entry in the same queue is held behind the failure.
  4. Team sees the blockageThe monitor or an alert shows the stuck queue.
  5. Fix and restartCorrect the cause, reprocess the entry, and the queue drains in order.
Why one failed queued entry holds up a whole day's orders, and what recovery must prove.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-209

Mocks and stubs

Partners are often not ready when SAP testing starts, or their test system is unreliable. A mock (or stub) stands in for the partner: it accepts SAP's outbound messages and returns a canned response, or it sends prepared inbound messages into SAP. Mocks let you test SAP's side early and repeatably: mapping into the message, status handling, error responses, and retries. They can be built in middleware, in a simple test service, or for SAP APIs by pointing a client at the SAP Business Accelerator Hub sandbox.

  1. Is the partner system available and stable in test?Yes → plan connected tests · No → start with a mock and plan connected tests for later
  2. Are you testing SAP's own logic (mapping out, posting in, status handling)?Yes → a mock is enough and repeatable · No → next question
  3. Does the risk sit in the partner, network, security or end-to-end timing?Yes → only a connected test proves it · No → mock
  4. Is this the final cycle before go-live?Yes → connected end-to-end test with real partner systems is required · No → mock where it speeds things up
When to use a mock and when only a connected test will do.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-209

What only a connected test proves

  • Certificates, credentials and network routes work between real systems.
  • The partner's system accepts SAP's message format and its own mapping is right.
  • Acknowledgments and confirmations come back and update SAP as expected.
  • Timing and volume across the full route are acceptable.
  • Error handling works at the partner's end, not just at SAP's.
AspectMock or stubConnected test with the real partner
AvailableFrom day one, on demandWhen the partner's test system is ready, such as Lakeside Components two weeks before go-live
ProvesSAP's mapping, posting, status handling, retries and error responsesCertificates, routes, partner acceptance, acknowledgments, end-to-end timing
RepeatableYes, with the same canned data each runDepends on the partner's system and data
Main riskGoes stale or answers only "OK"Late, so defects found here have little time to be fixed
Counts for sign-offOnly as SAP-side evidence; a mock-only interface is a recorded riskRequired in the final cycle
What a mock can and cannot prove compared with a connected end-to-end test.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-209

Keep mocks honest. A mock that always answers "OK" tests only the happy path. Give it realistic behavior: the acknowledgment format the partner really sends, the error responses the partner documents, a delay, and the occasional timeout. Review the mock against the partner's specification with the integration specialist, and replace its canned data whenever the partner changes its format. A stale mock gives false confidence right up to the first connected test.

What would you do?

Lakeside Components' EDI test system will only be available two weeks before Contoso's go-live. Luis, the cutover manager, asks whether interface testing can start now. What should Priya plan?

Key points
  • Know the monitor for each layer: IDoc lists and BD87, SM58, SMQ1/SMQ2, SBGRFCMON, the Gateway error log, SRT_UTIL, middleware monitoring.
  • A failed queued entry blocks the rest of its queue; test the blockage and recovery.
  • Mocks make SAP-side testing early and repeatable.
  • Only connected tests prove partner acceptance, security, routes and end-to-end timing.

Check your understanding · not graded

Lesson check

  1. 1. Which transaction shows failed asynchronous transactional RFC calls?

  2. 2. What happens in queued RFC when one entry fails?

  3. 3. What can only a connected test with the real partner prove?

  4. 4. Where are failed OData service calls logged in SAP Gateway?