Monday, July 11, 2011

SAP Basis Training Lesson One



SAP was founded in June 1972 as Systemanalyse und Programmentwicklung ("System Analysis and Program Development") [4] by five former IBM engineers in Mannheim.

R/3 Architecture Overview

The SAP R/3 System architecture consists of three layers: Presentation, Application, and Data Storage. The
Following diagram illustrates the function served by each layer and how the layers work together:




Presentation Server- Where SAP GUI has.
Application Server - Where SAP Installed.
Database Server - Where Database installed.

SAP R/3 is SAP's integrated software solution for client/server and distributed open systems. SAP's R/3 is the world's most-used standard business software for client/server computing. R/3 meets the needs of a customer from the small grocer with 3 users to the multi-billion dollar companies The software is highly customizable using SAP's proprietary programming language, ABAP/4. R/3 is scalable and highly suited for many types and sizes of organizations.
The R/3 architecture is comprised of application and database servers. The application servers house the software and the databases servers handle document updates and master file databases. The system can support an unlimited number of servers and a variety of hardware configurations.
SAP R/3 is based on various hardware and software
Architectures, running on most types of UNIX, on Windows NT and OS/400.
Sap = system application product in data processing
r = real-time
3 = three layers (application, presentation and database layers)

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


- DEV would have multiple clients for ex: 190 - Sandbox, 100 - Golden, 180 - Unit Test.
- QAS may again have multiple 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 are 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 every time. 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) clients. This is a configuration only client. Now upon a successful transport 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 cannot 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 practiced 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. 
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 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 company’s 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 development is done is development client and the request is transported to production.
These three are landscape of any Company. They organized their office in these three ways. Developer develops their program in Development server and then transports 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.

Types of Landscape’s
The system landscape contains all the SAP Systems that you have installed. It can consist of several system groups, whose SAP Systems are linked by transport routes.
After you decide which clients you need and which roles you want them to have, you need to decide how to distribute them amongst the different SAP Systems. You can set up multiple clients independently of one another in a single SAP System. However, when you configure the data, you must remember that cross-client Customizing settings and Repository objects are identical for all clients in a single SAP System. Changes made in one client apply immediately to all clients in the system.

One-System Landscape
We do not recommend a one-system landscape containing all central clients in a single SAP System. Joint usage of hardware resources and cross-client data places serious restrictions on how a single system operates. In particular, once the system is used productively, you can no longer develop in it, unless you stop productive operation for the development and test phases.

Two-System Landscape
A two-system landscape is an alternative for smaller SAP implementations where little Workbench development takes place.
The two-system landscape does not include a separate quality assurance system QAS. The quality assurance client is also in the development system DEV.
As in the three-system landscape, the production client is completely separate from the other clients. The disadvantage of a two-system landscape is that cross-client data is used in both the Customizing and quality assurance clients. This means that any changes that are made to cross-client data in the Customizing client can affect the tests in the quality assurance client. You can also not guarantee that transports from the Customizing client will be complete. Although all tests in the quality assurance client were successful, errors could still occur after the transport into the production client. This problem is caused by changes being made to cross-client data and then not being transported.

 Three-System Landscape
We recommend a three-system landscape in which each of the central clients has its own SAP System.
This consists of a development system DEV, a quality assurance system QAS and a production system PRD. The development system contains the Customizing client CUST, the quality assurance system contains the quality assurance client QTST and the production system contains the production client PROD.
Make all changes to Customizing data and Repository objects in the Customizing client. When you release the corresponding change requests, they are transported into the quality assurance client. This means that changes to cross-client data only appear in the quality assurance client after the transport. In the quality assurance client you can test whether the transports are complete, or whether any linked changes are missing and are still in unreleased change requests. If the test is successful, the change requests are transported into the production client. The production client is completely separate from the other clients as regards cross-client data.
If you need other clients with additional roles you can set them up in one of the three systems. Set up the development test client (TEST) and the prototype client (SAND) in the development system. Set up the training client (TRNG) in the quality assurance system.



Default Clients
With a standard installation, SAP delivers 000, 001 and 066 clients. Client 000 is considered to be a SAP reference client and it should not be changed or deleted at any time from the system. After a SAP system is installed, you can create other clients from 000 by using the client copy procedure.  For some important configuration you have to logon to client 000. For example, if you want to configure your CTS system then this client must be used. Client 000 also plays a very important role in upgrade process. Every time you do upgrade client dependent changes will be automatically upgraded in this client and later on the changes can be copied to other clients. 
The customer uses client 001 as a SAP sample client. After a new installation both 000 and 001 clients are identical, but after an upgrade 000 will have additional customizing data. Lot of customer sites does not use 001 client at all. Client 066 is there for SAP Early Watch service. This client enables SAP to remotely access the customer system. SAP provides this service to the customer to improve the system performance. After Early Watch group goes through the checking methodology, a system performance summery and recommendations to improve performance report are provided to the customer. SAP recommends to go for an Early Watch session before your project goes live and another one sometime after the go live date. Client 066 should not be changed or deleted from the system. 

2 comments: