Lesson 5 of 5
In test and hypercare
9 min
Listen to this lesson
The monitoring model is not something you switch on at go-live. It is tested in the test cycles, used to prove the cutover, and run hardest in hypercare. At each stage, monitoring output is also evidence: proof that an interface ran, that a failure was handled, that nothing was lost.
Evidence in test cycles
An interface test step is passed with evidence, not with a tester's word. For each executed interface test, Priya's team records the message identifiers at each hop (IDoc number, Integration Suite message ID, partner reference), the final statuses, and the business result at the receiver. For error-path tests, the evidence also includes the alert that fired and who received it. Store the identifiers with the test result in SAP Cloud ALM, so anyone can find the messages again while logs are still retained.
| Test type | Monitoring evidence |
|---|---|
| Happy path | Message IDs per hop, final statuses, business result at the receiver |
| Error path | Failed status, error text, alert received by the named owner, reprocessing result |
| Receiver down | Retries visible, no loss, alert when retries exhausted, all delivered after recovery |
| Volume | Counts per period reconciled, processing times, no growing backlog in queues |
| Reconciliation | A deliberate gap found by the daily reconciliation |
Monitoring through cutover
Contoso's cutover runs from Friday 18:00 to Monday 06:00. Interfaces need their own lane in the cutover plan. Before downtime, Luis's plan stops inbound and outbound traffic in a controlled order and requires the queues and failed-message lists in the legacy production system EP1 to be empty or explicitly accepted, so no transaction is stranded. After the conversion, interfaces are reconnected to CMP one by one, each with a smoke test and a check in the monitors, before business users start.
- Fri 16:00Partners notifiedLakeside and the bank confirm the pause window.
- Fri 18:00Traffic stoppedOutbound and inbound channels paused in a set order.
- Fri 19:00Queues drainedEP1 IDoc, qRFC and tRFC lists empty or each open item accepted in writing.
- SunReconnect and smoke testEach interface pointed to CMP; one test message per interface checked end to end.
- Mon 06:00Monitoring liveAlert rules active; first reconciliation scheduled for Tuesday morning.
Hypercare
In hypercare, run a short daily interface review: open alerts by owner and age, failed messages by interface, reconciliation results, and volume trends against the pre-go-live baseline. Watch for the patterns that only production shows: partners that behave differently from their test systems, peak-day volumes, and master data that was never in the test data. Agree exit criteria with the process owners, for example ten consecutive business days with every critical interface reconciled and no alert older than one business day.
What would you do?
At 22:30 on cutover Friday, near the end of ramp-down, Sam finds 14 inbound IDocs from Great Lakes Fleet Services in status 64 in EP1, waiting for a job that was already stopped. SUM downtime is due to start at 23:00. What should Luis decide?
- Interface tests pass on evidence: message IDs per hop, statuses, business results and alerts.
- Cutover needs an interface lane: stop, drain or accept, reconnect, smoke test, monitor.
- Hypercare runs a daily review of alerts, failures, reconciliation and volume trends.
- Agree measurable hypercare exit criteria with process owners.
Check your understanding · not graded
Lesson check
1. Which evidence should an executed happy-path interface test record?
2. Why drain or accept legacy queues before conversion downtime?
3. Which is a measurable hypercare exit criterion for interfaces?
4. What does a receiver-down test need to prove with monitoring evidence?