SAP Career Blog Links

For all questions and doubts on career in SAP refer the link:
http://scn.sap.com/community/career-center/blog/2012/06/19/sap-career-blog-links

* Copy from scn.sap.com

Operating System for SAP

Following factors should be considered when deciding which Operating System to use with SAP.

§  Current skill set of IT staff, cost of retraining, and cost of hiring new staff

§  Support from operating system vendors

§  Confidence on the Operating System and the vendor

§  Verifiable client references

§  Relationship of operating system vendor with SAP

64-bit OS

Starting 2007, SAP software is only supported on 64-bit operating systems. 64-bit hardware is more prevalent. The demand for 32-bit hardware and therefore 32-bit operating system is reducing with time. For SAP systems, only 64-bit hardware should be considered unless you have good reasons to support older versions of SAP or some other related software that only runs on 32-bit environment.

Selecting OS

When making a decision on which Operating System to use with your SAP system, you should keep in mind following features:

§  Memory Management

§  Crash Recovery

§  Patch Management

§  Security

§  Clustering Capabilities

§  Support for third party management utilities

§  Presence of built-in management utilities

It may or may not be compatible with your IT department's vision to invest in new toolsets. In that case you also have to make sure that your existing monitoring applications, virus scanning software and backup solutions would work with this operating system.

SAP OS Directory Structure

On UNIX and Linux OS, SAP is installed on the directory: 

/usr/sap 
On Windows SAP resides in: 
x:\usr\sap 
Where x is a drive letter.

On windows the folder x:\usr\sap is shared as SAPMNT. 

You can access this folder from other machine as \\machinename\sapmnt

where machine name is the name or IP address of the machine hosting SAP. 

If you have multiple SAP instances on Windows machine then all instances must be installed under the same directory SAPMNT. 

On all OS, UNIX, Linux, and Windows the next directory level is SID. 

SID stands for SAP system identifier.

SAP Hardware

SAP Hardware

Hardware is an essential component of a SAP system. Hardware consists of:

•   Servers (middle tier and database tier computers)
•   Disk Storage System
•   Network Gear (routers, switches etc)
•   Take Backup Units

All of these components work together to create a healthy system. Failure of even one component could halt the whole system, costing the company millions of dollars. 

All kind of systems are available in SAP hardware marketplace, from small and medium user platforms to large and highly resilient platforms.

Some large platforms are also capable of scale on the fly to meet the changing needs. 

When making a hardware purchase decision, solutions from different vendors should be compared. 

Most solutions cannot be compared as apples to apples. E.g. one solution could support the same workload as the other system but the level of scalability, availability, and reliability offered by the two systems could differ considerably. 

Spending little more money upfront could save the company tons of dollars on monthly maintenance and downtime costs.

Server Hardware

Server hardware comes in three main categories:

•  Small
•  Medium
•  High

A server can cost from a few thousand dollars to several million. Servers vary in performance as well. Main factors influencing server performance include:

• CPUs
• Speed of CPUs
•  Amount of RAM
•  Internal server architecture
•  Support for high-speed disk operations

Servers also vary in terms of configuration flexibility and adaptability.

SAP Hardware Solution

An SAP solution may utilize severs from any of the three categories. Typically high performance servers are used at database tier, while a middle tier could utilize inexpensive servers. Some businesses choose to utilize high performance machines at all tiers. Machines could be carved up into partitions or virtual machines. While other businesses might decide to go with low end hardware across the board relying on SAP's horizontal scalability.

Propriety Platforms

Most large hardware vendors use proprietary CPU (Central Processing Units) chips in their machines. Also most large vendors support only proprietary OS (Operating System)

Examples are:

•  IBM’s PowerPC chip running AIX operating system.
•  HP’s end-of-plife PA-RISC running HP-UX operating system.
•  HP’s Itanium2-based IA64 running HP-UX operating system.

You should also explore the ability of the machine to run other operating system as well. If you seek to retire SAP then you can simply use the same box internally after deploying less expensive operating system like Linux. 

For example HP's Itanium2-based IA64 also supports Linux and Windows operating systems

X64 Platforms

Late trend is investing in x64 platforms. An x64 platform is a low cost server based on Intel or AMD CPU rather than proprietary CPU. Windows based desktops and laptops that you buy from retail stores are also x64 machines. Recently x64 machines have become very powerful and now are rivalling proprietary systems in terms of high availability and visualization options. HP and Dell are big players in this market. Sun also offers bit of a choice. One time low up front cost should be a decision making criteria. Total cost through the life time of the system should be considered while making a decision.

High Availability

High availability feature is very important for an SAP system. Even if you are incurring additional charges you should consider high availability feature for SAP. High availability is an implementation of features that ensures a certain absolute degree of operational continuity. High availability features include:

•  Redundant power supplies
•  Disk array controllers (RAID) (array of disks keeps system running even if one disk fails)
•  Support for multiple network cards

Networks should be configured in a redundant fashion as well. Using dual network switches is a good example in this regards.

Disk Subsystem Hardware

Disk subsystems are enclosures for multiple disks. Disk subsystems could be used at database tier or at middle tier. Storage Area Networks (SANs) are example of most robust and high performance disk systems. Network-attached storage (NAS) is example of lesser extent disk systems. SANs and NAS devices are marketed under three categories: low-tier, mid-tier, and high-end.

Storage for SAP

Storage used with SAP system should support redundant connectivity between the storage device and the servers connected to it. This will avoid the single point of failure

RAID

RAID (Redundant Array of Inexpensive Disks) should be configured as well. RAID is a technology that allowed computer users to achieve high levels of storage reliability from low-cost and less reliable PC-class disk-drive components. This is achieved by arranging the devices into arrays for redundancy. RAID comes in following levels:

•   Level 0
•   Level 1
•   Level 5
•   Level 10

Different levels provide various combinations of availability, cost, and performance. 

RAID 0 is the cheapest and RAID 10 is the most expensive option.

Understanding SAP LANDSCAPE

SAP LANDSCAPE:

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.

What is the meaning of "R" in R/3 systems?

R/3 stands for realtime three tier architecture. This is the kind of architrecture SAP R/3 system has.

R/3 means three layers are installed in Different system/server and they are connected with each other.

1)Presentation
2)Application.
3)Data base server.

SAP LANDSCAPE

SAP LANDSCAPE:

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.

What is the meaning of "R" in R/3 systems?

R/3 stands for realtime three tier architecture. This is the kind of architrecture SAP R/3 system has.

R/3 means three layers are installed in Different system/server and they are connected with each other.

1)Presentation
2)Application.
3)Data base server.

Complete SAP Modules:

Complete SAP Modules:
SAP Basis
• Remote Function Calls (RFC)
• Common Program Interface Communications (CPI-C)
• Electronic Data Interchange (EDI)
• Object Linking and Embedding (OLE)
• Application Link Enabling (ALE)
• Customising (BC-CUS)
• Client Server Technology (BC - CST)
• Network Integration (BC - NET)
• ABAP Programming and Runtime Environment (BC - ABA)
• Basis Services/ Communication Interfaces (BC - SRV)
• Computing Center Management System (BC - CCM)
• Upgrade General (BC - UPG)
• Change and Transport System (BC - CTS)
• Operating System Platform(BC - OP)
• Database Interface, database platforms (BC - DB)
• Front End Services (BC - FES)
• ABAP Workbench (BC - DWB)
• Documentation and Translation Tools (BC - DOC)
• Security (BC - SEC)
• Controls and Control Framework (BC - CI)
• Business Management (BC - BMT)
• Middleware (BC - MID)
• Computer Aided Test Tool (BC - CAT)
• Ready to Run R/3 (BC - BRR)
• Authorisations System Monitoring with CCMS Workload Alert Monitor
SAP Hardware
• AS400
• AT&T
• Bull
• Compaq Digital
• HP
• IBM
• Sequent
• SNI
• Sun
SAP Database
• Adabas D
• DB2 for AIX
• DB2/400
• Informix
• MS SQL
• My SQL
• Oracle
• Sybase
Operating System
• AIX
• HP UX
• MS Windows NT OS/400
• Sinux
• Solaris
• Unix

ABAP/4 Programming
• SAP Script
• Business Workflow (BC - WF)
• ALE
• EDI
• Business Connector
• Business Server Pages
• Internet Application Server
• Mercator Report Painter
• Dialog Programming
• Repository Information System
• Menu Painter
• ABAP 00
• IDOCS
• LSMW
• Smartforms
• EBP
• ASAP methodology
• ALV reporting
• Report writer
• ABAP Query
• Data Dictionary
• Screen Painter

SAP FI (Financial Accounting)
• Accounts Payable (FI- AP)
• Accounts Receivable (FI - AR)
• Asset Accounting (FI - AA)
• General Ledger Accounting (FI - GL)
• Special Ledger (FI - SL)
• Funds Management (FI - FM)
• Travel Management (FI-TM)

SAP TR (Treasury)
• Cash Management (TR - CM)
• Treasury Management (TR - TM)
• Loans Management (TR - LM)
• Funds Management (TR - FM)
• Market Risk Management (TR - MRM)
• Information System
SAP CO (Controlling)
• Cost Centre Accounting (CO - CCA)
• Overhead Cost Controlling (CO - OM)
• Activity Based Coding (CO - ABC)
• Product Cost Controlling (CO - PC)
• Profitability Analysis (CO - PA)
• Material Ledger (CO - ML)
SAP EC (Enterprise Controlling)
• Consolidation (EC - CS)
• Profit Center Accounting (EC - PCA)
• Executive Information System (EC-EIS)
• Business Planning and Budgeting
SAP IM (Investment Management)
• Investment Programmes
• Investment Measures (orders/products)
• Appropriation Requests
• Corporation Wide Budgeting
• Depreciation Forecast
• Automatic Settlement of Fixed Assets
• Information System
SAP HR (Human Resource)
• Personnel Administration
• Benefits Administration
• Compensation Management
• Recruitment
• Travel Management
• Personnel Development
• Organisational Management
• Training and Events Management
• Personnel Planning
• Time Management
• Incentive
• Wages
• Workflow
• Internet Scenarios
• Payroll
• Information System
SAP SMB
• SAP SMB
SAP BW
• Data Warehousing
• BI Platform
• BI Suite - Business Explorer
• Development Technologies
• ODS Structures
• Info Cube
• Design Build
SAP IS (Industry Solutions) / SAP for Industries
• Aerospace & Defence
• Retail
• Consumer Products
• Defence & Security
• Insurance
• Industrial Machinery & Components
• Logistics Service Providers
• Mill Products
• Higher Education & Research
• Automotive
• Banking
• Telecoms
• Chemicals
• Pharmaceuticals
• Life Sciences
• Mining
• Media
• Public Sector
• Service Provider
• Utilities
• Healthcare
• Oil & Gas
• Postal Services
SAP SD (Sales and Distribution)
• Master Data
• Sales
• Special Business Transactions
• Shipping
• Billing
• Credit Control
• Sales Support
• QM in SD
• Internet
• Transportation
• Foreign Trade
• Sales Information System
• Electronic Data Interchange
SAP Logistics Information System
• Sales Information System
• Purchasing Information System
• Inventory Controlling
• Production Planning and Control Information System
• Plant Maintenance Information System
• Project Information System
• Retail Information System
SAP QM - Quality Management
• Planning
• Inspections
• Control
• Notifications
• Certificates
• Test Equipment Management
• QM-IS
SAP MM (Materials Management)
• Logistics (General)
• Logistics Information System
• Purchasing
• Inventory Management
• Invoice Verification
• Inventory / Valuations
• Materials Planning
• Workflow
• External Services Management
• QM in MM
• Warehouse Management
SAP PM (Plant Maintenance)
• Preventative Maintenance
• Service Management
• Maintenance Order Management
• Maintenance Projects
• Equipment and Technical Objects
• Structuring Technical Systems
• Maintenance Planning
• PM Processing
• Work Clearance Management
• Internet Scenarios
• Customising
• Information System
SAP CS (Customer Service)
• Service Processing
• Service Contracts
• Controlling
• Workflow in Customer Service
SAP PP (Production Planning)
• Make to Order (CR)
• Make to Order (PIR)
• Repetitive Manufacturing
• PP for Process Industries (PP - PI)
• PP - Processes
• Sales and Operations Planning
• Master Planning
• Capacity requirements
• KANBAN
• Production Orders
• Product Cost Planning
• Assembly Orders
• Plant Data Collection
• Information System
SAP CA (Cross Application Components)
• Application Link Enabling (ALE)
• SAP Business Workflow
SAP PS (Project Systems)
• Basic Data
• Operational Structures
• Project Planning
• Approval
• Project Execution and Integration
• Information System
• Work Breakdown Structure
mySAP SRM (Supplier Relationship Management)
• Self Service Procurement
• Service Procurement
• Plan Driven Procurement
• Spend Analysis
• Strategic Sourcing
• Catalogue Content Management
mySAP SEM
• Business Consolidation (SEM-BCS)
• Business Information Collection (SEM-BIC)
• Business Planning and Simulation (BW-BPS)
• Corporate Performance Monitor (SEM-CPM)
• Stakeholder Relationship Management (SEM-SRM)
mySAP CRM (Customer Relationship Management)
• CRM Enterprise
• Field Applications
• E-Commerce
• Interaction Center
• Channel Management
• Industry Specific CRM
mySAP Product Life Cycle Management
• Document Management
• Enterprise Content Management
• Engineering Change Management
• Classification
• Basic Data for Process Manufacturing
SAP SCM (SAP Supply Chain Management)
• SCM Process and Business Scenarios
• SAP Advance Planning and Optimization (SAP - APO)
• SAP Forecasting and Replenishment
• SAP Inventory Collaboration Hub (SAP - OCH)
• SAP Event Management (SAP - EM)
• SCM Basis

SAP Netweaver
• SAP Masterdata Management
• Portal Content
• Information Integration
• Process Integration
• Life Cycle Management
• Knowledge Management
• SAP Visual Composer
• SAP Business Intelligence
• People Integration
• Application Platform
• Security
• SAP Web Application Server
• SAP Business Information Warehouse
• SAP Enterprise Portal
• SAP Solution Manager
• SAP Mobile Engine

Client-Server Architecture..

Enterprise Structure Terminology

Work process...

SAP R/3 INTERVIEW ARCHITECTURE QUESTIONS

1. What guarantees the integration of all application modules?

The R/3 basis system guarantees the integration of all application modules. The R/3 basis s/w provides the run time environment for the R/3 applications ensures optimal integration, defines a stable architectural frame for system enhancements, and contains the administration tools for the entire system.One of the main tasks of the basis system is to guarantee the portability of the complete system.

2. What are the central interfaces of the R/3 system?

Presentation Interface.

Database Interface.

Operating system Interface.

3. Which interface controls what is shown on the p.c.?

Presentation Interface.

4. Which interface converts SQL requirements in the SAP development system to those of the database?

Database Interface.

5. What is SAP dispatcher?

SAP dispatcher is the control agent that manages the resources for the R/3 applications.

6. What are the functions of dispatcher?

Equal distribution of transaction load to the work processes.

Management of buffer areas in main memory.

Integration of the presentation levels.

Organization of communication activities.

7. What is a work process?

A work process is where individual dialog steps are actually processed and the work is done. Each work process handles one type of request.

8. Name various work processes of R/3 system?

Dialog or Online (processes only one request at a time).

Background (Started at a specific time)

Update (primary or secondary)

Enque (Lock mechanism).

Spool (generated online or during back ground processing for printing).

9. Explain about the two services that are used to deal with communication.

Message Service: Used by the application servers to exchange short internal messages, all system communications.

Gateway Service: Enables communication between R/3 and external applications using CPI-C protocol.

10. Which work process triggers database changes?

Update work process.

11. Define service (within R/3)?

A service is a process or group of processes that perform a specific system function and often provide an application-programming interface for other processes to call.

12. What are the roll and page areas?

Roll and page areas are SAP R/3 buffers used to store user contexts (process requests). The SAP dispatcher assigns process requests to work processes as they are queued in the roll and page areas.

Paging area holds data from the application programs.

Roll area holds data from previous dialog steps and data that characterize the user.

13. What are the different layers in R/3 system?

Presentation Layer.

Application Layer.

Database Layer.

14. What are the phases of background processing?

Job Scheduling.

Job Processing.

Job Overview.

15. What components of the R/e system initiate the start of background jobs at the specified time?

The batch scheduler initiates the start of background job. The dispatcher then sends this request to an available background work process for processing.

16. Define Instance.

An instance is an administrative unit in which components of an R/3 systems providing one or more services are grouped together. The services offered by an instance are started and stopped at random. All components are parameterized using a joint instance profile. A central R/3 system consists of a single instance in which all-necessary SAP services are offered. Each instance uses separate buffer areas.

17. From hardware perspective, every information system can be divided into three task areas Presentation, Application Logic and Data Storage.

The R/3 Basis software is highly suitable for use in multi-level client/server architectures.

18. What are R/3 Basis configurations?

A central system with centrally installed presentation software.

Two-level client/server system with rolled out presentation software.

Two-level client/server system. Presentation and Application run on the same computer.

Three-level client/server system. Presentation, Application and database each run on separate computers.

19. What is a Service in SAP terminology?

A service refers to something offered by a s/w component.

20. What is Server in SAP terminology?

A component can consist of one process or a group and is then called the server for the respective service.

21. What is a client in SAP terminology?

A S/W component that uses the service (offered by a s/w component) is called a Client. At the same time these clients may also be servers for other services.

22.What is a SAP system?

The union of all s/w components that are assigned to the same databases is called as a SAP system.

23. What is the means of communications between R/3 and external applications?

The means of communication between R/2,R/3 and external applications is via the CPI-C handler or SAP Gateway, using the CPI-C Protocol.

24. What is the protocol used by SAP Gateway process?

The SAP Gateway process communicates with the clients based on the TCP/IP Protocol.

25. Expand CPI-C.

Common Program Interface Communication.

26. What is a Spool request?

Spool requests are generated during dialog or background processing and placed in the spool database with information about the printer and print format. The actual data is places in the Tem Se (Temporary Sequential objects).

27. What are different types of Log records?

V1 and V2. V1 must be processed before V2. But, we can have more than one V2 logs.

28. What are the types of Update requests?

An update request can be divided into one primary (V1) and several Secondary update components (V2). Time-critical operations are placed in V1 component and those whose timing is less critical are placed in V2 components. If a V1 update fails, V2 components will not be processed.

29. Dialog work processes perform only one dialog step and then available for the next request.

30. Explain what is a transaction in SAP terminology.

In SAP terminology, a transaction is series of logically connected dialog steps.

31. Explain how SAP GUI handles output screen for the user.

The SAP front-end s/w can either run on the same computer or on different computers provided for that purpose. User terminal input is accepted by the SAP terminal program SAP GUI, converted to SAP proprietary format and sent to the SAP dispatcher. The dispatcher coordinates the information exchange between the SAP GUIs and the work processes. The dispatcher first places the processing request in request queues, which it then processes. The dispatcher dispatches the requests one after another, to the available work process. The actual processing takes place in the work process. When processing is complete, the result of a work process is returned via the dispatcher to the SAP GUI. The SAP GUI interprets the received data and generates the output screen for the user.

SAP LANDSCAPE

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.

What is the meaning of "R" in R/3 systems?

R/3 stands for realtime three tier architecture. This is the kind of architrecture SAP R/3 system has.

R/3 means three layers are installed in Different system/server and they are connected with each other.

1)Presentation
2)Application.
3)Data base server.

SAP R/3 SYSTEM ARCHITECTURE

SAP based the architecture of R/3 on a three-tier client/server model. Presentation Server, Application Server, Database Server

Presentation Server

The presentation server is actually a program named sapgui.exe. It is usually installed on a user's workstation. To start it, the user double-clicks on an icon on the desktop or chooses a menu path. When started, the presentation server displays the R/3 menus within a window. This window is commonly known as the SAPGUI, or the user interface (or simply, the interface). The interface accepts input from the user in the form of keystrokes, mouse-clicks, and function keys, and sends these requests to the application server to be processed. The application server sends the results back to the SAPGUI which then formats the output for display to the user.

Application Server

An application server is a set of executables that collectively interpret the ABAP/4 programs and manage the input and output for them. When an application server is started, these executables all start at the same time. When an application server is stopped, they all shut down together. The number of processes that start up when you bring up the application server is defined in a single configuration file called the application server profile.
Each application server has a profile that specifies its characteristics when it starts up and while it is running. For example, an application sever profile specifies:
· Number of processes and their types
· Amount of memory each process may use
· Length of time a user is inactive before being automatically logged off
The application server exists to interpret ABAP/4 programs, and they only run there-the programs do not run on the presentation server. An ABAP/4 program can start an executable on the presentation server, but an ABAP/4 program cannot execute there.
If your ABAP/4 program requests information from the database, the application server will format the request and send it to the database server.

Discovering the Database Server

The database server is a set of executables that accept database requests from the application server. These requests are passed on to the RDBMS (Relation Database Management System). The RDBMS sends the data back to the database server, which then passes the information back to the application server. The application server in turn passes that information to your ABAP/4 program.
There is usually a separate computer dedicated to house the database server, and the RDBMS may run on that computer also, or may be installed on its own computer.

Configuring the Servers

In a three-tier client/server configuration, the presentation servers, applications servers, and database server all run on separate machines. This is the most common configuration for large systems, and is common in production.
In the distribution presentation configuration, the application and database servers are combined on one computer and the presentation servers run separately. This is used for smaller systems, and is often seen on a development system.
In the two-tier client/server configuration, the presentation and application servers are combined and the database server is separate. This configuration is used in conjunction with other application servers. It is used for a batch server when the batch is segregated from the online servers. A SAPGUI is installed on it to provide local control.
When all servers are combined onto a single machine, you have a central configuration. This is rarely seen because it describes a standalone R/3 system with only a single user.

Defining an R/3 System

The simplest definition of an R/3 system is "one database." In one R/3 system, there is only one database. To expand the definition, R/3 is considered to be all of the components attached to that one database. One R/3 system is composed of one database server accessing a single database, one or more application servers, and one or more presentation servers. By definition, it is all of the components attached to one database. If you have one database, you have one system. If you have one system, you have one database. During an implementation, there is usually one system (or one database) assigned to development, one or more systems designated for testing, and one assigned to production.
The term R/3 system landscape denotes a description of the number of systems within an SAP installation and how they are designated, such as development, test, or production.

Defining an R/3 Instance

When you hear someone say the word instance, most of the time, that person will be referring to an application server. The term instance is synonymous with application server.
The term central instance refers to the database server. If an application server and database server both reside on the same machine, the term central instance refers to the computer on which both reside.
In the most general terms, an instance is a server. It is a set of R/3 processes providing services to the R/3 system.

Application Server Architecture

All requests that come in from presentation servers are directed first to the dispatcher. The dispatcher writes them first to the dispatcher queue. The dispatcher pulls the requests from the queue on a first-in, first-out basis. Each request is then allocated to the first available work process. A work process handles one request at a time.
To perform any processing for a user's request, a work process needs to address two special memory areas: the user context and the program roll area. The user context is a memory area that contains information about the user, and the roll area is a memory area that contains information about the programs execution.

Understanding a User Context

A user context is memory that is allocated to contain the characteristics of a user that is logged on the R/3 system. It holds information needed by R/3 about the user, such as:
· The user's current settings
· The user's authorizations
· The names of the programs the user is currently running
When a user logs on, a user context is allocated for that logon. When they log off, it is freed. It is used during program processing, and its importance is described further in the following sections.

Understanding a Roll Area

A roll area is memory that is allocated by a work process for an instance of a program. It holds information needed by R/3 about the program's execution, such as:
· The values of the variables
· The dynamic memory allocations
· The current program pointer
Each time a user starts a program, a roll area is created for that instance of the program. If two users run the same program at the same time, two roll areas will exist-one for each user. The roll area is freed when the program ends

NOTE
When speaking to a Basis consultant, you might hear the term roll area used to refer to all roll areas for one user or even all roll areas on one application server. You usually can determine the intended meaning from the context in which it is used.
Both the roll area and the user context play an important part in dialog step processing.

Understanding a Dialog Step

NOTE
A dialog step is used by Basis consultants as the unit of measure for system response time.
A dialog step is the processing needed to get from one screen to the next. It includes all processing that occurs after the user issues a request, up to and including the processing needed to display the next screen. For example, when the user clicks the Enter key on the Change Vendor: Initial Screen, he initiates a dialog step and the hourglass appears, preventing further input. The sapmf02k program retrieves the vendor information and displays it on the Change Vendor: Address screen, and the hourglass disappears. This marks the end of the dialog step and the user is now able to make another request.

There are four ways the user can initiate a dialog step. From the SAPGUI:
· Press Enter.
· Press a function key.
· Click on a button on the screen.
· Choose a menu item.
It is important for an ABAP/4 programmer to know about dialog steps because they form a discrete unit of processing for an ABAP/4 program.

Understanding Roll-In/Roll-Out Processing

An ABAP/4 program only occupies a work process for one dialog step. At the beginning of the dialog step, the roll area and user context are rolled in to the work process. At the end of the dialog step, they are rolled out.

During the roll-in, pointers to the roll area and user context are populated in the work process. This enables the work process to access the data in those areas and so perform processing for that user and that program. Processing continues until the program sends a screen to the user. At that time, both areas are rolled out. Roll-out invalidates the pointers and disassociates these areas from the work process. That work process is now free to perform processing for other requests. The program is now only occupying memory, and not consuming any CPU. The user is looking at the screen that was sent, and will soon send another request.

When the next request is sent from the user to continue processing, the dispatcher allocates that request to the first available work process. It can be the same or a different work process. The user context and roll area for that program are again rolled in to the work process, and processing resumes from the point at which it was left off. Processing continues until the next screen is shown, or until the program terminates. If another screen is sent, the areas are again rolled out. When the program terminates, the roll area is freed. The user context remains allocated until the user logs off.

In a system with many users running many programs, only a few of those programs will be active in work processes at any one time. When they are not occupying a work process, they are rolled out to extended memory and only occupy RAM. This conserves CPU and enables the R/3 system to achieve high transaction throughput.

NOTE

ABAP/4 programs do not have the capability to intercept many common Windows events. The events that generate a lot of messages such as key presses, focus changes, and mouse movements are not passed to ABAP/4 programs. As a result, there is no way of performing some of the functions that are found in other Windows programs. For example, in ABAP/4, you cannot validate the contents of a field when the user presses the Tab key. You must instead wait until the user initiates a dialog step.

All requests pass through the task handler, which then funnels the request to the appropriate part of the work process.

The interpreters interpret the ABAP/4 code. Notice that there are two interpreters: the ABAP/4 interpreter and the screen interpreter. There are actually two dialects of ABAP/4. One is the full-blown ABAP/4 data processing language and the other is a very specialized screen processing language. Each is processed by its own interpreter.

The database interface handles the job of communicating with the database.

Understanding the Types of Work Processes

There are seven types of work processes. Each handles a specific type of request. The type of work processes and the types of requests that they handle are shown in Table 1.2.

Types of Work Processes and the Types of Requests they Handle
WP Type Request Type

D (Dialog) Dialog requests
V (Update) Requests to update data in the database
B (Background) Background jobs
S (Spool) spool requests
E (Enqueue) Logical lock requests
M (Message) Routes messages between application servers within an R/3 system
G (Gateway) Funnels messages into and out of the R/3 system

Understanding the Logon Client

The term logon client has nothing to do with Client/Server-it is completely different.
The number entered here by the user corresponds to a set of rows within each client-dependent table within the database.

Understanding Client-Dependent and Client-Independent Tables

There are two types of tables in an R/3 database: client-dependent and client-independent. A table is client-dependent if the first field is of type CLNT. The length will always be 3, and by convention, this field is always named mandt. If the first field is not of type CLNT, the table is client-independent.

This program selects rows from table lfa1 and writes out lfa1-lifnr. When this program is run, only two rows are selected: only those where mandt equals 800. This happens automatically because the first field in the table is of type CLNT. There are five rows in the table, but the program writes out only those rows where mandt equals 800. If the user were to log on to client 700 and run the same program, three rows of data would be found and written out. If the user were to log on to client 900, only one row of data would be found.

The logon client mechanism divides the rows within a client-dependant table into distinct groups. To access a different set of data, the user logs on and specifies a different client number.

NOTE

The user master records (containing R/3 user IDs) are client-dependent. Therefore, to gain access to a client, the security administrator must create a new user ID for you within that client.
Developers and testers use the logon client mechanism to create and access multiple, independent sets of data within a single table.

For example, assume two typical, asocial programmers are working on an enhancement to the billing system. Jim is modifying the update transaction and Jane is creating a new report to go with Jim's modifications.

Jane sets up data for her test run, executes her report and obtains output. Jim works in the next cubicle, but due to his antisocial tendencies is blissfully unaware that his transaction uses the same tables as Jane's report. He runs his transaction and updates the data. Jim got what he wanted, but Jane then modifies her code and runs her program again. Her output differs from the last run, and the differences many not result from her changes, but rather they may result from Jim's changes. What we have here is a failure to communicate.
If the tables used by Jim and Jane's programs were client-dependent, they could each log in to separate clients, set up independent sets of data, and test their programs without ever talking to each other. They could perform all of their testing in the comfort of their cubicles and in isolation from their coworkers.

To make their tables client-dependant, they only need mandt as the first field and the R/3 system will take care of the rest. When records are added to the table, the system automatically moves the current logon client into the mandt field when the record is send to the database. Their Open SQL select statements will only return rows where the client number in the table is equal to the their current logon client number. The Open SQL database statements insert, update, modify, and delete also provide automatic client handling.

If the tables involved are all client-dependent, there can be more than one group of testers working at a time in one test system. Two teams of testers can test divergent functionality in the same set of programs at the same time provided they log on to different logon clients. The updates done by one team will not change the data belonging to the other team.
A training client could also exist on the test system. The students could log on to one client and the testers could log on to another. Both would run the same set of programs, but the programs would access independent sets of data.

NOTE
The average R/3 installation has three systems: development, test, and production. By default, each system comes with three clients installed: 000, 001, and 066. It is common to have from three to six clients in the development and test systems, but rarely will you see more than one client in production.