cancel
Showing results for 
Search instead for 
Did you mean: 

what is R/3 system and what is system land scape in SAP?

Former Member
0 Kudos

Hi gurus,

Pls expain me what is system landscape and what is R/3 system, and how the clints are used in different servers.

thanx in adavace,

sandeep.ch.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hello

R/3 relates to a three tier architecture in an ERP system. Earlier SAP had R/2 structure.

System landscape refers to the organization of client structure, say development client / quality client / production client. It also deals with the respective links between systems. There could be more than mere 3 clients in a complex landscape system

reg

former_member184627
Active Contributor
0 Kudos

Hi,

R/2 is for 3 tier & now we use 3 system landscape.

In 3 system landscape there are three servers.

1.Development

2.Quality

3.Production.

All the configuration spro settings are done in devlopment server. we can do this in the sand box client.

This is checked in the quality server. We cannot do any change in the spro settings in this server.If tested ok, we RE DO the whole configuration in the Dev. server in the Golden client & then create a transport request.

As per the request, the basis people transport this from dev to prod server.

Regards,

Senthilkumar SD

Former Member
0 Kudos

thank you for your answer

Priya

Former Member
0 Kudos

Hi

R/3 means real-time (R) 3-tier architecture. These 3-tiers are application, presentation and database layers in the architecture.

The system landscape is nothing but the lay-out of systems used for processing. Normally three type of client systems are used 1. Development client (where the customization activities are done) 2. Quality Client (where testing is done) and the 3. Production client (where actual data-processing for the real-time is done).

Regards

Former Member
0 Kudos

hi thank you so much for your information pls tell me this also is there any Interview Questions with you if you have pls send me

regards

Former Member
0 Kudos

its sufficient n other things wil come 8 the practical time......so do experiments wen get a practical chance.

Regards,

j...........

Answers (6)

Answers (6)

Former Member
0 Kudos

Hi,

1. What is a SAP Landscape? What is my role in a SAP implementation?

The SAP Landscape is like a layout of a complex garden u2013 you have areas for roses, and areas for lilacs, and it is all laid out in proper form. A SAP landscape can range from one SAP instance with one client and one user who does all the input into the instance via keyboard to dozens of instances with hundreds of clients and thousands of users, with keyboard input, RFC (Remote Function Calls) and ALE (Automatic Link Exchange) from other SAP instances, links to external databases, EDI (Electronic Data Interchange) via flat file from banks, vendors, etc., and RF units in the warehouse. In other words, a SAP landscape can be very simple, or very complex. A bed of petunias, or the Hanging Gardens of Babylon.

A normal SAP landscape consists of a Development (DEV) instance, a Quality Assurance (QAS) or Test (TST) instance, and a Production instance (PRD). Some very small implementations will have only a DEV and PRD instance, with the DEV instance containing a QAS client for testing purposes.

A non-Production SAP server should have 2 (preferably more) processors, at least 4 gig of memory, and at least 100g of disk space. A Production SAP server should have at least 4 processors, from 4 to 8 gig of memory, and at least 200g of disk space. A hefty server with 6 u2013 8 processors, 6 u2013 8 gig of memory, and at lease 200g of disk space can host two SAP instances. This can be done for DEV and QAS but PRD should never share a server with any other SAP instance.

The SAP instances form the core of a SAP landscape. The other installed SAP products are peripheral to the SAP instances.

2. SAP R/3 system

SAP R/3 system is based on 3-tier architecture, now we can use a multi ties also.

A SAP instance is all the components created by the SAPinst program who all share the same database. There are three mandatory sub-instances; the Database Instance (DB), the Central Instance (CI), and the Dialog Instance (DI) aka Application Server. This is the minimum configuration of any SAP instance. There can be multiple DIs but only one DB and only one Active CI which means that a copy of the CI can exist for High Availability but only one of the CIs can be active at any given time. You will hear about SAP being multi-tiered and that term is referancing these three layers. Sometimes you might see u201Cother SAP tiersu201D like ITS but that really isnu2019t a separate tier, it used to be an additional piece of software working with IIS, and now ITS is part of Basis/WAS so it is part of the CI Tier. These layers, plus other SAP written software, are also known as the SAP Business Framework.

You can probably guess at what the DB contains. There are any number of tables in a SAP instance, from 21,000 to 38,000. Many have four or five character names that are usually abbreviations of things like USR for user, MANDT for client, etc. You could guess that USR is short for user. But MANDT? So, we add one more variable to the equation u2013 those four or five character names are abbreviations of German words. Needless to say, trying to look at SAP from a typical DBA prospective is almost impossible. Fortunately, SAP supplies the tools for you to manage all these tables.

The Central Instance is a lump term for all the SAP executables, the installed OS file structure, and anything that is placed on the OS to support and communicate with the SAP instance. It u201Ctalksu201D to the database, handles requests made by the application server(s), and sends back the information. Other software products often call this the middleware layer.

The Dialog Instance connects the users to the CI, passes the issued requests to the CI, and sends the returned results to the useru2019s session. SAP uses a client piece called SAPGui which handles the user-to-DI communication on the useru2019s workstation.

These are the three main pieces of a SAP instance installation. There are other parts that can be added for various sub-access and external tasks. For a Development SAP instance or a Quality & Assurance or Test SAP instance, all three layers are normally installed on the same server. For a Production SAP instance, the DB/CI are often installed on one server and the DI on another server for load balancing purposes. It should be noted that the installation of a CI instance automatically installs a DI which can be used by everyone if needed, be used only as needed by Basis staff, or never be used.

Instance can be a difficult term to understand u2013 almost every major database applies this term to the installation of the database software. So if you see reference to an Oracle instance, this means the installation of the Oracle software. An Oracle database is the creation of a new empty database within that Oracle instance.

Understanding the Startup and Shutdown prodedures may help solidify this layer concept.

The normal SAP instance start up consists of three parts: starting the SAP OS Collector, starting the Oracle Listener, and starting the SAP instance. The process mainly goes like this: ora<sid> logs on and starts the Oracle Listener then <sid>adm logs on and runs the startsap script.

What? You say we missed a step? What happened to the SAP OS Collector?

The startsap script takes care of the SAP OS Collector for us. When the SAP Instance starts up via the startsap script, it checks to see if saposcol is up and running u2013 whether from the root user starting it manually or from another SAP Instance already starting it up, it doesnu2019t matter. If saposcol is up and running, the script simply moves on to the next step. If it is not, the script starts saposcol as root and then proceeds. So the SAP OS Collector gets handled one way or another.

However, you may need to bring up multiple Oracle Listeners depending on the database configuration. If the MCOD installation option was used then only one Oracle Listener is used since both databases share one Oracle listening port which is normally 1527. If, however, two Oracle instances were installed, and each database uses its own unique Oracle listening port, then multiple listeners must be started. The startup procedure for each SAP Instance would be exactly the same as if only one SAP Instance resided on the server.

The process to stop the SAP instance is close to being the reverse of the start procedure. <sid>adm stops the SAP Instance, ora<sid> stops the Oracle Listener, and root stops the SAP OS Collector. The only real difference is that saposcol is not automatically stopped by the stopsap script u2013 there may be other SAP instances on the server which means this software needs to stay up and running to gather OS information until that instance comes down.

One thing to note u2013 the Oracle Listener does not start the database, it simply u201Cwatchesu201D port 1527 for any database related activity. The startsap and stopsap scripts handling the startup, mount, opening, and shutdown of the database. None of this activity could occur if the listener was not u201Cpollingu201D port 1527, relaying the requested database function, and returning the results through the same port.

The <sid>adm and ora<sid> users are assigned environment variables using the SAP installation run that identify them as users of a specific Oracle database and SAP instance. So when oraabc starts the lsnrctl program with the u201Clsnrctl startu201D command, oraabcu2019s environment variables tell the server which database for which the listener is to u201Clistenu201D.

Regards,

Srini Nookala

Former Member
0 Kudos

Hi,

R/3 means realtime 3 tier/ system landscape.

In 3 system landscape there are three servers that compose you SAP environment.

Development System

Quality Assurance System

Production System

Regards,

Francis

Former Member
0 Kudos

What exactly is SAP System Landscape? How does this phenomenon differ from SAP System Architecture? In this posting, I intend to answer the above mentioned, closely related questions in a very concise manner, with particular emphasis on the system landscape of SAP. Often times, SAP users, especially new comers misunderstands the two concepts.

The SAP architecture is typically the technology framework of the SAP system. SAP's architecture unlike the system landscape has changed over time (and more recently) with the advent of SAP ECC.

In a prior posting, I "x-rayed" they system architecture of SAP R/3.

They system landscape basically is 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 juncture, 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.

By and large, the SAP system landscape ensures that the integrity of data is enhanced via enforcing a controlled configuration changes effect on the target system - production.

Esha1
Active Participant
0 Kudos

It's 3 tier architecture with three layers:

1. Presentation: The presentation layer provides the application layer with a familiar local representation of data

independent of the format used on the network.

2. Application: Application layer is the top layer of the OSI (Open System Interconnectivity) server layer model.

This layer handles issues like network transparency, resource allocation and problem partitioning. The application

layer is concerned with the user's view of network (e.g. formatting electronic mail messages).

3. Database: Data processing is done for user request.

In 3 system landscape: Different environments are listed:

1.Development( Customization activities are performed)

Actual versions can be obtained from Dev client. Through the golden client which is configuration client.

To keep all the landscape in sync with same configuration we transport this golden client to all other landscapes.

Sp spro settings are performed in Dev environment.

2.Quality ( Actual testing is done)

Actual testing is done in this. Unit, system and integration testings all done in this environment while you can not

even access SPRO screen.

3.Production ( real-time processing is done or the actual environment in which business work)

This is working environment for all the users after GoLive.

Flow will move from Development->Quality->Production in forward direction.

Kind Regards

Former Member
0 Kudos

Dear Sandeep,

Please let us know if you need more information otherwise you can mark the thread as answered.

Regards,

Rakesh

Former Member
0 Kudos

Hi,

Is it clear or you need more info or this.

Anil

Former Member
0 Kudos

Landscape is like a server system or like a layout of the servers or some may even call it the architecture of the servers viz. SAP is divided into three different lanscape DEV, QAS and PROD.

- DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, 180- Unit Test.

- QAS may again have mutiple clients for ex: 300- Integration Test, 700 to 710 Training.

- PROD may have something like a 200 Production.

These names and numbers are the implementer's discreet on how they want it or they have been using in their previous implementations or how is the client's business scenario.

Now whatever you do in the Sandbox doesn't affect the other servers or clients. Whenever you think you are satisfied with your configuration and you think you can use it moving forward, you RE-DO it in the golden client (remember, this is a very neat and clean client and you cannot use it for rough usage). As you re-do everything that you had thought was important and usable, you get a transport request pop up upon saving everytime. You save it under a transport request and give your description to it. Thus the configuration is transported to the Unit Test client (180 in this example).

You don't run any transaction or even use the SAP Easy Access screen on the 100 (golden) client. This is a configuration only client. Now upon a successful tranport by the Basis guy, you have all the configuration in the Testing client, just as it is in the Golden client. The configuration remains in sync between these two clients.

But in the Testing client you can not even access SPRO (Display IMG) screen. It's a transaction only client where you perform the unit test. Upon a satisfactory unit test, you move the good configuration to the next SERVER (DEV). The incorrect or unsatisfactory configuration is corrected in Golden (may again as well be practised in the sandbox prior to Golden) and accordingly transported back to 180 (Unit Test) until the unit test affected by that particular config is satisfactory.

The Golden client remains the 'database' (if you wanna call it that) or you may rather call it the 'ultimate' reference client for all the good, complete and final configuration that is being used in the implementation.

In summary:

Landscape : is the arrangement for the servers

IDES : is purely for education purpose and is NOT INCLUDED in the landscape.

DEVELOPMENT ---> QUALITY -


> PRODUCTION

DEVELOPMENT : is where the the consultants do the customization as per the company's requirement.

QUALITY : is where the core team members and other members test the customization.

PRODUCTION : is where the live data of the company is recorded.

A request will flow from Dev->Qual->Prod and not backwards.

1. Sandbox server: In the initial stages of any implementation project, You are given a sandbox server where you do all the configuration/customization as per the companies business process.

2. Development Server: - Once the BBP gets signed off, the configuration is done is development server and saved in workbench requests, to be transported to Production server.

3. Production Server: This is the last/ most refined client where the user will work after project GO LIVE. Any changes/ new develpoment is done is development client and the request is transported to production.

These three are landscape of any Company. They organised their office in these three way. Developer develop their program in Development server and then transport it to test server. In testing server tester check/test the program and then transport it to Production Server. Later it will deploy to client from production server.

Presentaion Server- Where SAP GUI have.

Application Server - Where SAP Installed.

Database Server - Where Database installed.