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

Lesson 1 of 5

Operations capabilities overview

9 min

Listen to this lesson

0:00 / 8:06

Most delivery teams meet SAP Cloud ALM through its implementation apps: requirements, test plans, defects. The same tenant also has an operations side, and it is not only for the support team after go-live. Interface failures in system integration testing, a nightly job that overruns in a mock conversion, a stuck process in hypercare: all of these show up first in the operations apps. This lesson maps what is there and what has to happen before any of it shows data.

The monitoring use cases

SAP's Expert Portal for Cloud ALM for operations lists a set of use cases, each with its own app, content and setup guide. For delivery teams, five matter most, plus the event and alerting layer that sits behind them.

Use caseWhat it watchesContoso example
Health MonitoringTechnical metrics of cloud services and systems, with current status and historyResource trends on CMP in the first week after go-live
Integration & Exception MonitoringMessages and interface calls across systems, plus exceptions such as application log errorsA failed EDI order from Great Lakes Fleet Services
Job & Automation MonitoringBackground jobs and automations: execution status, application status, runtime and start delayThe nightly MRP run for plant 1710 overruns
Business Process MonitoringProcess KPIs such as backlogs and exceptions in end-to-end processesSales orders without deliveries building up in sales area 1710 / 10 / 00
Real User and Synthetic User MonitoringResponse times for real users and scripted availability checksSlow Fiori apps for Chicago key users
Intelligent Event ProcessingRoutes events from the apps to alerts, email, tickets, chat and automationAn alert e-mail to Sam's Basis team

Cloud ALM for operations: the use cases a delivery team uses most.

Each monitoring use case feeds one event layer, Intelligent Event Processing, which decides who hears about a problem and how.
The Sign-Off Table · thesignofftable.com/academy/sap-alm-205

Other use cases exist, such as Configuration and Security Analysis, Business Service Management and Operations Automation, and SAP keeps adding to the list. Check the Expert Portal for the current set before you design anything around it.

Nothing shows until you connect it

The operations apps are empty until systems and services are registered and data collection is switched on. Three layers have to be in place, and each has a different owner.

Landscape ManagementEvery system or service is registered here. SAP cloud services on your customer number are imported automatically from the System Landscape Information Service; on-premise and private cloud ABAP systems such as CMQ and CMP are added
Managed system setupOn an ABAP system the connection and the use cases to collect are configured locally, using transaction /n/sdf/alm_setup and the ST-PI add-on at a supported level
Use case activationIn each Cloud ALM monitoring app, data collection is activated for the service; switching it on is also the consent for data exchange
ConfigurationThresholds, events, alerts and recipients are set per monitored object
The layers that must be in place before monitoring shows data.
The Sign-Off Table · thesignofftable.com/academy/sap-alm-205

Two practical points follow. First, prerequisites differ by use case. SAP's setup page for job monitoring, for example, lists required ST-PI support package and SAP Note combinations for on-premise ABAP systems, and it asks you to flag job collection in /n/sdf/alm_setup. Read each use case's setup page rather than assuming one setup covers all. Second, activation is per system and per use case. A system registered in Landscape Management shows nothing in Job & Automation Monitoring until someone activates it there.

Registration alone shows nothing: CMQ must be set up locally and each use case activated before data appears in that app.
The Sign-Off Table · thesignofftable.com/academy/sap-alm-205

Who uses what

RoleMain appsDuring delivery
Sam (Basis lead)Health, Job & AutomationConnects CMQ and CMP, owns job alerts in mock conversions
Integration specialistIntegration & ExceptionWatches SIT interface traffic and message errors
Priya (test lead)Integration & Exception, Business ProcessUses message details as defect evidence
Maria and Dan (process owners)Business ProcessWatch backlogs in hypercare
Contoso's monitoring responsibilities during the program.
The Sign-Off Table · thesignofftable.com/academy/sap-alm-205

What would you do?

Contoso's integration specialist opens Integration & Exception Monitoring on the first day of SIT and sees no data for CMQ, although CMQ appears in Landscape Management. What is the most likely cause?

Key points
  • Cloud ALM for operations covers health, integration and exceptions, jobs and automations, business processes, users, and event routing.
  • Systems are registered in Landscape Management; cloud services arrive automatically, ABAP systems are added.
  • ABAP systems are configured locally with /n/sdf/alm_setup and need ST-PI at the level each use case requires.
  • Data collection is activated per system and per use case; registration alone shows nothing.

Check your understanding · not graded

Lesson check

  1. 1. CMQ is registered in Landscape Management but Job & Automation Monitoring shows nothing. Why?

  2. 2. Where are SAP cloud services on your customer number registered?

  3. 3. Which transaction configures Cloud ALM data collection on a managed ABAP system?

  4. 4. Which use case would show a backlog of sales orders without deliveries?