SAP Landscape System

Landscape System Strategy(LSS):

The system landscape is basically the set-up or arrangement of your SAP servers. Ideally, in an SAP environment, a three-system landscape exists. A three-system landscape consists of the Development Server-DEV, Quality Assurance Server-QAS and the Production Server-PROD. This kind of set-up is not primarily designed to serve as server clusters in case of system failure, the objective to enhance "configuration pipeline management". 


A Typical SAP Three-System Landscape.

At this point, it is important to state that a test system - Sandbox can also exit separately. The essence of the sandbox is to test the configuration of the business processes of a company, especially at the inception of the project (before the Business Blue Print is signed). It can also serve as a practice environment, even after go-live. 

Pipeline is the environment where the configuration in the development system is moved to the quality assurance system and finally to the production system. The whole idea is to ensure that the configuration of these systems is in sync at any point in time. Suffice to say that, configuration/changes are first made in the Development system, thoroughly tested in the Quality Assurance system before been loaded into the production (Live) system.

This approach throws up the transport management system concept. Transport management system is the coordination of the movement of objects and configuration changes from the development system to the Quality Assurance system and then to the Production system. At times, this sequence of movement is not possible, especially in cases where an SAP note mandates that changes be made directly on the production system.

In such rare cases, objectively confirm that the change transport cannot be performed. Very likely, your system must have been configured to "not modifiable" (a system locking strategy that enforces the three-system landscape change transport rule); unlock the system by changing the global setting option to "modifiable" using transaction SE03. After you have done that, effect the change(s) on the system. Immediately lock the system back by changing the global setting option to "not modifiable" using transaction SE03. Replicate the changes on the other system. Note that transaction SCC4 can also be used to lock the system so that client dependent and independent configuration changes are not carried out directly on the production system.

Here Client is a independent data unit. Each and every server has 1000 clients (0-999), every client has unique userid and password provided by the Basis team. Choosing a client is client specific.