Lesson 2 of 7
The environment catalog
10 min
Listen to this lesson
The environment catalog is the single list of every system, client and connected system that testing uses, with what each one is for, who owns it, how it is refreshed and how to get time on it. It sounds like documentation. In practice it is the tool that prevents two projects from loading conflicting data into the same client, stops a performance test from running during UAT, and tells a new partner in one page where to test what.
Contoso's landscape after go-live
During the program Contoso ran three systems: CMD for development, CMQ for quality and CMP for production. After go-live, the TCoE asked for a fourth: CMR, a pre-production system that is refreshed from production and receives only transports already on their way to CMP. The reason was simple. CMQ client 100 is full of in-flight project work, so it cannot show how a feature pack stack update behaves on production-like data and production-like configuration. CMR can.
Each S/4HANA system has partners that tests depend on. The SAP BTP subaccounts for side-by-side extensions are paired by environment (cmc-ext-test with CMQ client 100, cmc-ext-preprod with CMR client 100), the Process Orchestration test system XQ1 carries interfaces until they move to SAP Integration Suite, and external partners such as the bank and the carriers offer their own test endpoints. A catalog that lists only the SAP systems will be wrong the first time an interface test fails.
What each catalog entry contains
| Field | Why it matters | Example: CMR client 100 |
|---|---|---|
| Purpose and allowed test types | Stops misuse, such as SIT in pre-production | Release regression, UAT of releases, performance checks |
| Owner (business and technical) | Someone decides conflicts and approves changes | Priya (TCoE); Sam (Basis) |
| Transport path and freeze rules | Tells testers what code level they test | Only transports approved for the next CMP import |
| Data source and refresh cycle | Tells testers how fresh and how real the data is | Copy of CMP, masked, quarterly |
| Connected systems | Shows what end-to-end tests can reach | cmc-ext-preprod, bank and carrier test endpoints |
| Access and data classification | Who may log on and what data they will see | Masked copy; named testers only; no offshore access to unmasked data |
| Booking rules | How to get exclusive time | Book through the TCoE calendar; performance runs only at weekends |
| Readiness status | Whether it is usable today | Available, booked, refreshing, post-copy checks, test-ready |
The fields of an environment catalog entry. Keep it to one row per system and client, with links to detail.
Clients are environments too
In SAP, one system can host several clients, and each client is a separate data world. Contoso's CMQ has client 100 for project testing and client 200 for training. Treat each client as its own catalog entry with its own purpose and refresh rule. Training in client 200 needs a clean, predictable data set every time a training wave starts, so it is rebuilt from a template, not shared with project testers who change data all day. Client-dependent customizing and master data stay separate; cross-client customizing and repository objects do not, which is why a training client cannot have its own code level.
| Environment | Purpose | Data | Refresh | Booking |
|---|---|---|---|---|
| CMD client 300 | Development, unit tests | Small, hand-made | Never from production | Open to developers |
| CMQ client 100 | Project SIT and UAT, enhancement tests | Masked production copy plus project data | Once a year, in a quiet window | Shared; projects book load windows |
| CMQ client 200 | Training waves | Training template | Rebuilt before each wave | Training team only |
| CMR client 100 | Release regression, release UAT, performance | Masked copy of CMP | Quarterly, before each regression window | Exclusive bookings through the TCoE |
| CMP | Production only | Real | Not applicable | Smoke tests during cutover and releases only |
Booking: shared, windowed or exclusive
Not every environment needs a booking process. CMQ client 100 is shared by design, and its rule is about data: each project creates data with its own prefix or number range and never changes another project's records. CMR is different. A release regression needs exclusive use for its window, because a performance test or an unplanned transport would invalidate the results. Contoso books CMR in named windows: regression for each feature pack stack, monthly release regression, and weekend performance checks. Anything else needs Priya's approval.
What would you do?
A project manager wants to run the Wave 2 mock data loads for company code 1910 in CMR, because "it has the most realistic data." What should Priya decide?
- The catalog lists every system, client and connected system testing uses, with purpose, owner, refresh, access and booking rules.
- A pre-production system refreshed from production gives release regression production-like data that project test clients cannot.
- Treat each client as its own environment; training clients are rebuilt from a template.
- Book exclusive windows only where results depend on it, and show readiness status in the catalog.
Check your understanding · not graded
Lesson check
1. Why did Contoso add CMR after go-live instead of running release regression in CMQ client 100?
2. Which catalog field best tells a tester what code level they are testing?
3. Why should a training client be rebuilt from a template before each wave?
4. Which environment most needs exclusive booking windows?