Lesson 2 of 5
Clients and sandboxes
10 min
Listen to this lesson
Inside each SAP system sit one or more clients. A client is a self-contained unit with its own user master data, customizing and application data; the system keeps them apart by client number. Repository objects such as programs and cross-client customizing, however, belong to the whole system. That split decides what a client strategy can and cannot isolate.
Client-specific and cross-client
| Kind of data | Scope | Example | Consequence |
|---|---|---|---|
| Client-specific customizing | One client | Pricing procedure settings, company code settings | Must be transported or copied to other clients |
| Application and user data | One client | Sales orders, materials, users and role assignments | Each client needs its own test data and users |
| Cross-client customizing | Whole system | Some global settings and factory calendars | A change affects every client at once |
| Repository objects | Whole system | ABAP programs, CDS views, Fiori app code | A code change is visible in all clients immediately |
That last row explains a classic trap. A unit test client in the development system sees new code the moment a developer activates it, but sees new client-specific customizing only after it is copied in. Testers who expect "the same thing" in two clients of one system will be surprised one way or the other.
Logical client roles
SAP training material lists logical client roles used in projects: CUST (development and customizing), QTST (quality assurance), PROD (production), PREP (pre-production), TRNM (training master), TRNG (training execution), SAND (sandbox), TEST (unit test) and GOLD (a golden client holding configuration without application data, with restricted access). These are planning labels; the technical client role set in transaction SCC4 (such as customizing, test, production or training) is a separate setting with its own change and transport options.
| System | Client | Logical role | Used for |
|---|---|---|---|
| CMD | 100 | CUST / GOLD | All configuration recorded in transports; no application test data |
| CMD | 300 | TEST | Developers and functional consultants unit test with sample data |
| CMQ | 100 | QTST | Integration, acceptance and regression testing |
| CMQ | 200 | TRNM / TRNG | End-user training with stable data and training users |
| CMR | 100 | PREP | Performance, final integration and release rehearsals (added after go-live) |
| CMP | 100 | PROD | Live business |
| CMS | 100 | SAND | Conversion trials and experiments |
Contoso's client strategy. SAP training material uses a similar pattern of client 100 for main work and 300 for unit test.
Moving customizing between clients
Customizing recorded in CMD client 100 reaches unit test client 300 by copying the transport contents into it. SAP provides SCC1 (copy by transport request) and, from SAP S/4HANA 1909, SCC1N for this. Developers then test in client 300 before releasing the transport toward CMQ. Whole clients can also be copied, locally or between systems, which is how a training client is rebuilt before a class cycle.
- ConfigureConsultant changes settings in CMD 100; recorded in a transport
- Copy to unit testTransport contents copied into CMD 300
- Unit testConsultant tests with sample data in CMD 300
- ReleaseTransport released only after the unit test passes
- ImportImported into CMQ 100 for integration testing
Sandboxes that stay useful
SAP training material describes a sandbox system as the place to test support packages or business function activation without affecting development, and stresses that transports should not leave it. A sandbox stays useful when three rules hold: it is refreshed often enough to resemble development or production, everyone knows nothing in it is authoritative, and anything worth keeping is rebuilt properly in development. Contoso refreshes CMS from a production copy before each conversion trial and wipes experiments afterward.
Fewer clients, not more
Clients are cheap to create and expensive to run. Each one needs its own users, role assignments, master data and, for testing, its own prepared data sets; each one must be kept in step with customizing transports; and each one is a place a tester can log on to by mistake. Contoso started with eleven ideas for clients and kept seven. The rule it applied: a client must have a distinct job that conflicts with an existing client's job, such as training versus testing, and a named owner who keeps it usable.
What would you do?
Kenji changes an ABAP pricing routine in CMD and activates it. A consultant unit testing in CMD client 300 says the change is already visible there, but her new pricing condition from client 100 is not. Why?
- A client separates users, client-specific customizing and application data; repository objects are system-wide.
- Plan logical client roles (CUST, QTST, PROD, PREP, TRNM, TRNG, SAND, TEST, GOLD) and record them.
- Unit test customizing in a separate client by copying transport contents in (SCC1 or SCC1N).
- Keep training and testing in separate clients; nothing leaves a sandbox.
Check your understanding · not graded
Lesson check
1. Which data is cross-client in an SAP system?
2. Which logical client role holds configuration without application data and restricted access?
3. Which transaction copies the contents of a transport request into another client?
4. Why should acceptance tests not run in the training client?