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

Lesson 5 of 5

Using monitoring in test and hypercare

9 min

Listen to this lesson

0:00 / 7:07

Monitoring is often set up a week before go-live by a team that has never seen the system under load. Contoso did it differently: it treated monitoring as part of the solution, built it in CMQ during testing, proved it in the mock conversions and carried it into CMP for hypercare. This lesson puts the earlier pieces into a plan.

A monitoring plan across the program

  1. RealizeConnect CMQRegister in Landscape Management; ST-PI and notes per use case; /n/sdf/alm_setup; activate integration, exception and job collection
  2. SITMonitor testsScenarios mirror SIT test cases; alerts route to the test team; message details attached to defects
  3. Mock conversionsMeasure cutoverRuntimes and start delays recorded; thresholds set from real data
  4. Dress rehearsalRehearse alertingHypercare alert set active in CMQ; owners respond as they will after go-live
  5. CutoverConnect CMPProduction registered and activated; alert set switched on before business resumes
  6. HypercareOperate and learnDaily alert review; incidents traced back to tests; thresholds tuned
Contoso's monitoring timeline, from build to hypercare.
The Sign-Off Table · thesignofftable.com/academy/sap-alm-205

Data collection prerequisites checklist

Most delays come from prerequisites discovered late. Sam's checklist for each ABAP system, built from SAP's setup pages:

  1. The system is registered in Landscape Management with the right system role, and the logon URL is set if a Web Dispatcher is used, so drill-down to the source works.
  2. ST-PI is at a support package level the chosen use cases support, with the SAP Notes the setup pages name.
  3. The connection to the Cloud ALM tenant is configured on the managed system in /n/sdf/alm_setup, with the needed use cases flagged.
  4. Application log linking for jobs is active through CRIT, so application status is rated.
  5. Data collection is activated for the system in each monitoring app; the people who configure it have the right Cloud ALM roles.
  6. Events, thresholds, recipients and the maintenance windows are set and tested with a deliberate failure.
  1. Is the system in Landscape Management?Yes → next · No → register it (ABAP systems are added; cloud services import automatically)
  2. Is ST-PI at a supported level with the required notes?Yes → next · No → plan the support package and notes, including who does it under RISE
  3. Are the use cases flagged in /n/sdf/alm_setup?Yes → next · No → flag them and check the collection runs
  4. Is collection activated in each monitoring app?Yes → next · No → activate it per use case
  5. Has a deliberate failure raised the expected alert?Yes → ready · No → check event configuration and recipients
Why is there no monitoring data? A diagnostic path.
The Sign-Off Table · thesignofftable.com/academy/sap-alm-205

Monitoring as test evidence

For a test lead, the monitors are a source of evidence. An interface test that passed in the user interface but left an IDoc in error has not passed. A batch test that ran green on execution but red on application status has not passed. Priya added both checks to the SIT exit criteria, so every interface and batch test case has an expected result in the monitor as well as on screen.

Priya’s SIT exit rule: an interface or batch test passes only when the monitor agrees with the screen.
The Sign-Off Table · thesignofftable.com/academy/sap-alm-205

Closing the loop in hypercare

Every hypercare incident is a question about testing. When an alert leads to a real defect, trace it back in Cloud ALM to the process and requirement it affects, check whether a test case covered the case, and if not, add one and put it in the next regression plan. Because implementation and operations share one tenant, the link from "what broke" to "what we tested" is a few clicks, not a spreadsheet exercise.

Because operations and implementation share one tenant, each hypercare defect can be traced back to the process and turned into a regression test.
The Sign-Off Table · thesignofftable.com/academy/sap-alm-205

Know the limits too. SAP's FAQ positions SAP Focused Run, a separately licensed product, for advanced monitoring of large hybrid landscapes and service providers, and Cloud ALM for cloud-centric solutions. Contoso's landscape fits Cloud ALM, but a company with a large hybrid estate should review that guidance before deciding.

What would you do?

Two weeks before go-live, Sam proposes connecting CMP to Cloud ALM "after the cutover weekend, when things are quiet". What should Grace decide?

Key points
  • Connect the quality system early so SIT, mock conversions and the dress rehearsal exercise monitoring.
  • Check prerequisites per system: Landscape Management, ST-PI and notes, /n/sdf/alm_setup, CRIT linking, activation, events.
  • Treat monitor status as test evidence for interface and batch tests.
  • Make production monitoring readiness a go/no-go criterion and trace hypercare incidents back to tests.

Check your understanding · not graded

Lesson check

  1. 1. Why connect CMQ to Cloud ALM operations during Realize?

  2. 2. How should cutover runtime thresholds be set?

  3. 3. An interface test passed on screen but the IDoc is in error. What is the result?

  4. 4. For which case does SAP's FAQ point to SAP Focused Run rather than Cloud ALM?