SAP System and Instances

The ‘System Landscape,’ in SAP, refers to a number of systems and their deployment within an SAP installation. The various systems may be designated as Development, Test, and Production Clients.

SAP systems are organized into instances,  each of which contains one or more clients.  Examples of instances are DEV (for development and configuration), QA(for quality assurance) and PRD (for the productive system). There may be more instances, but that would be the minimum setup of any SAP system Landscape.

Each instance may consist of more than one client. The clients are typically identified by a three-digit number, such as 100, 110, 120, 200, etc. Each client within an instance can share SAP R/3 programs but will have its own transactional data. Some configuration will affect all of the clients in an instance, but some configuration will only affect the client in which it has been performed.

In order to transport configuration changes to another SAP instance, the changes must be included in a “change request.” One or more configuration changes can be included in the same change request, or each configuration change can have its own change request. Consult with the project team and/or the basis team to determine the best approach for transporting change requests. If each configuration change generates its own change request, many change requests can be time-consuming for the basis team to transport.

Comments

Hi steverumsby,

I am really confused between an instance, a system and a client. On this website, at places I have also read that we have DEV, PROD etc. clients. I always believed these are instances. Can you please briefly clarify me the difference between all these.

Thanks,
Ashish

You’ve got systems, instances and landscapes confused! Each of DEV, QA & PRD is a system. The way they interact for transports (e.g. DEV->QA->PRD) is the landscape. Clients belong to a system.

Instances are a technical way of having multiple servers to support a system that needs lots of processing power, but they are largely irrelevant from a functional point of view. In a system with both ABAP and Java stacks, the Java and ABAP will live in separate instances and there may be multiple of each. In general users don’t notice, or need to know…

Also, you don’t *need* a QA system. Lots of people get by with just a combined DEV/QA system and a separate PRD.

I am still yet to find an organization which has DEV and QA in the same system. Ofcourse, you may be having different clients in the same system, one acting as development and the other acting as QA. There are lots of things which makes life simple when you have a seperate QA system. One simple problem would be the client independent tables which will be troublesome and if you want to do a complete blackbox testing before moving it to Production, you would need a exact replica of Production in QA and totally dffferent from DEV where everyone is playing around with the the configuraton. You can never expect that your development will be an exact replica because there may be lot of development going on in parallel and if any test fails, many times it would be difficult to find out which development is impacting it. What is some one is just playing with enhancements or user exists just to check possible ways of arriving at a solution. Believe it… life’s a lot lot lot easier with QA.