Вы находитесь на странице: 1из 330

Support Phase

It is used to provide the support to End Users. There are various types of Supports provided by the partners to the customers. Partner (Partner) is a company which provides support services. Ex: IBM, HP, HCL, TCS, WIPRO, SATYAM 1 2 3 4 L1 Support L2 Support L3 Support L 4Support Tier-1 Tier-2 Tier-3 Tier-4 Level-1 Level-2 Level-3 Level-4 Support-1 Support-2 Support-3 Support-4

1. Level-1 Support: It is a front end support or end user support to Reset the Passwords lock and unlock users. GUI related issues. (Installation, patches, upgrade) performance check list activities etc 2. Note: Very less privileges are assigned to the users there will be no input on the system by this users there will be no input on the system by this users i.e. they cant Delete, Drop, Change objects in the system. It is also referred as monitoring Job. 3. Level-2 Support: The reports from the Level-1 consultants along with recommendations are evaluated and ensure that they are resolved. Level-2 consultant handle assignments of roles, Background Jobs rescheduling, data transfers, notes etc.. 4. The issues which could not be resolved can be escalated to Level-3 5. Level-3 Support: Recommend the parameters for Tuning, Support Package application, Scheduling down times, working with SAP, database activities etc. 6. Level-4 Support (Onsite):The consultant works with data center and knowledge of O/S, R/3, DB etc is required for this. Responsible to Start Up the BOX. Responsible for Backup, Restore, Recovery, DR, Standby, Clustering, Mirroring, H/W migration,. UPS aircom etc. Based on the nature of the company the following activities are also segregated. 7. Security 8. Performance

9. Data Base 10. 11. 12. O/S Transports Normal BASIS Support

We can also propose to perform all the activities.

Roles and Responsibilities: 13. 14. 15. 16. 17. Define the Checklist Working on Tickets/Requests/Cases Configuring Work Processes Configuring Buffers Resolving Runtime Issues

18. Working with Dialog Process, Update Process, background Process, Message, Spool and Enqueue Processes 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. Define Background Jobs and Monitoring Monitoring Critical Update Define the Printers Working with SAP Archiving Creating RFC Destinations Define various methods for data transfer Monitor EDI and IDOC Release change request and import target systems Applying patches notes etc Configuring CCMS and monitoring Configuring logon load balancing

30. 31. 32. 33. 34.

Configuring operation modes Monitoring the log files Defining and scheduling standard background jobs Monitoring backup regularly Monitoring DATABASE Standard Jobs

Support Architecture: Offshore Components






Leased Line/VPN Work for CustomerConnectivity Directory


NESTLE: ST02 PFCG 30 Employees

HP: . . 17 Employees

KODAK: SM36 SM37 SM50 SM66 12 Employees

Connectivity from OFFSHORE to CUSTOMER/CLIENT: 35. Leased Line: If the trust is established between the supporting partner and the customer dedicated leased line can be used. (Trust means the data security of the customer). Each leased line is backed up by dialup or another alternative leased line. 36. VPN: (Virtual Private Network). It is a service which establishes a tunnel between the customer and supporting partner. CISCO VPN is widely used. We need to key in USER-ID and Password and Access Key to logon into the Private Network. 37. Remote Access Cards (RAC) are used to generate Random Number (Remote Authentication Key) i.e. generated access key. 38. User Request Mechanism: User request management tools are utilized for this purpose. 39. 40. 41. 42.


CLARIFY HP Overview Seibel Ticketing Tool SAP CRM SYNERGY Phone CUSTOMID EXCEL Help Desk (Phone, FAX, Email)


When the request is created in the tool the status is NEW.

New Assigned Work In progress Temp Fix Pending Closed/Completed/ Finished Severity of the Problem:

Raised Problem When the Consultant Accept the Ticket Processing Temporary Fixed, Job Aborted, Run Temporary For Approval Problem is Fixed

1 2 3 4 5

Low/Normal Medium High Very High/ Critical Diasster

Response Time
24 Hrs 12 Hrs 8 Hrs 2 Hrs 15 Min

Closure Time
72 Hrs 48Hrs 24 Hrs 4 Hrs 15 MIN

Low/Normal: It can be solved with in 72 Hrs. Tickets such as Password Reset,

User Creation, GUI related issues or user specific problems

Medium: Updates, Background processing, Batch Input processing, Roll

assignment etc

High: Printing, Update, Deactivation, Transport Errors etc Very High: Printers Down, Instance Down, Services are partially inturepted Disaster: Server Down

SLA: Service Level Agreement.

SLA is an agreement between the supporting partner and the company which describes the level of agreement between the parties and the work will be done based on the agreement conditions.

Parameters for defining the Number of W.Ps:

rdisp/wp_no_dia= rdisp/wp_no_btc= For defining the number of Dialog W.Ps For defining the number of Background W.Ps

rdisp/wp_no_vb= Defining the number of update W.Ps rdisp/wp_no_vb2= Defining the number of update W.Ps (secondary) rdisp/wp_no_enq=1 Defining the number of enqueue W.Ps rdisp/wp_no_spo= Defining the number of spool W.Ps rdisp/max_wprun_time= 600-1800 sec this defines the maximum time that a (Dialog)W.P can run . DIAG Protocol Roll In Roll Out

Dialog Work Process:


Central Instance


43. 44.

Handles the user Request interactively At least Two dialog processes are required

45. Each Dialog W>P requires around 75MB-150 MB of memory on an average (Memory varies between the systems)

46. Every Dialog W>P an handle 5 to 10 users 9Depending upon the type of users (Lo, Medium, High)) 47. Each Dialog W.P will be timed out for every 600 eseconds or the time specified by parameter rdisp/max_wprun_time
Note: The parameter rdisp/max_wprun_time is instance specific and will take default value of 600 if not changed. Each request will be handled for 600 seconds. Otherwise the request will be timed out.

48. 49. 50.

Each Dialog W.Pis not restricted to a user session Each process can serve multiple users Each process can serve only a part of a Transaction

Dialog Steps:
It is a part of a transaction. It can be also called as a sub transaction.

Transaction: It consists of multiple dialog steps and it commits as a group or it

can be rolled back. In order to complete a transaction with multiple dialog steps multiple dialog work processes are used.

Monitoring Dialog Work Process:

Work processes are monitored in Transactions

51. 52.

SM50 (Local Instance) SM66 (Global Instance)

Go to SM50 to display the list of processes configured on that instance. It is used to display the following: 1. No: Serial Number of Work Processes (W0, W1, Wn-1) 2. Type: It shows the type of work process. It can be any one of DVEBMGS 3. Process ID: (PID) It represents a process Id at O/S level. This is used to identify the critical process running at O/S level and to take a decision whether to continue or Kill the W.P. 4. Status: It shows the status of the W.P a. Running: The W.P is executing the user task until it complete the task or timed out. It written in the status of running

b. Waiting: It is waiting for the user request they are free t handle the task assigned by the dispatcher c. Holding: The process is on hold. (It is also running) and waiting for the communication from an RFC system. d. Terminated or Stopped: The process is terminated due to an error, time out after 600 seconds, explicitly killed. e. Ended: The W.P is ended i.e. it could not be started and it cant handle any user request 5. Reason: The reason for the status. For running and hold press F1 to display the various reasons


Sleep Mode: Its waiting for the resources on the target system

54. Private Mode: It is dedicated to a user. Time out will not work for this process 55. Enqueue: Communicating with enqueue process.

6. START: It ensures the W.P to start during W.P termination or Restart. It can be change from menu process restart after error Yes or No If it is set to No it cant be started to handle the Queue. But its useful to debug, why the process has been terminated or stopped. 7. Err( Error): Indicates the number of times the process is terminated 8. Semaphore: It indicates the number of the semaphore which blocked the W.P i.e. each W.P needs to work at O/S level and gets blocked for the various resources. There are 55 semaphores which are displayed by pressing F1 9. CPU: Click on CPU to display the time utilized by the W.P while accessing CPU. It is also reffered as CPU time. 10. Time: The time spent by the dialog W.P to execute the current dialog step of a transaction. If it goes beyond 600 seconds it will be terminated automatically. 11. Report: The report which is executed by the process 12. Client: The client NO through which user logged in 13. User: Name of the user who is executing the process

14. Action: Specify the action performed by the W.P. Ex: Logical Read, Sequential Read, Physical read, Roll In, Roll Out etc

1. SM50: It is used to monitor the status of various W.Ps on an instance. 2. SM66: It is used to display the W.P of all instances. It is used to monitor the time consuming W.Ps with respect to users, report, reason for the long running and the type of action on the database along with the time consuming for that dialog step. 3. As part of the checklist you need to identify the total number of work processes with various statistics and mark them with red which are consuming lot of time. The reason for this is also very important. (Sleep Mode, PROID, CPIC.) to identify the expensive W.P. 4. If all the W.Ps are in the status of running we can assume that the system is over loaded due to lack of memory or the users are overloading the system i.e. more than the expected. (The system designed for 200 users but it is being utilized by 300 users) 5. We can also kill the expensive W.P from SM50 (Inform the user before killing the W.P). Select the user W.P Go to Menu Process Cancel with core or Without Core WITH CORE: Means it will generate a trace file at O/S level. WITHOUT CORE: Means no trace file generated. Double click on the W.P to check the details of the W.P SM50 is also used to change the layout. Go to Menu Settings Layout We can customize the layout as per our requirement. Note: Sometimes it may be recommended to end the user session instead of killing user W.P. ./kill -9 (In UNIX)

It is used to monitor the status of W.P at O/S level. If the system is congested and user can not log on to GUI then use dpmon at o/s level. It displays the list similar to SM50. We can select the process which is time consuming and use the option kill with core or without core. If we cant kill identify the Project ID and kill at O/S level 10

Note: Dialog Process is used to handle the user request to schedule the job in the background to update the database to print the requests and to get the logs before updating a record. Disadvantages: Dialog process cant be used to run the long running, time consuming expensive programs or Reports.


Background Process:
56. The time consuming, expensive, long running programs can be scheduled in the background to run during Off Peak hours without user intervention. 57. Background jobs running in Non Interactive mode and doesnt require any user inputs 58. The max work process runtime is not applicable to background W.P i.e. they can run for any number of hours. 59. Background process doesnt handle part of the transaction but in time the complete transaction is handled by them. 60. 61. Background jobs are created by using Dialog W.Ps Background jobs are defined in the transaction SM36.

62. Go to SM36 Specify Job Name Specify the Job Class Specify the job triggering mechanism (Immediate/Date & Time/Event/After Job/ At Operation Modeetc) Save the job definition

Job Class:
Class-A: It is used to define high priority jobs. We need a dedicated process of Type A which is defined in operation mode. Class A job will be executed by only Class A work processes. Dont schedule more Class-A jobs unless it has a dedicated work process at that point of time. Class-B: It is used to handle medium priority jobs i.e. system defined jobs like SAP standard housekeeping jobs which runs periodically at regular intervals. Class-C: It is the default class for all the Jobs. It is used to schedule low priority jobs.

Status of a Background Job:

1. Scheduled: When the job is defined the status is scheduled 2. Released: When you specify the date and time to a scheduled job its status is released 3. Ready: Ready for the execution and waiting for the resources 12

4. Active: The job is currently running 5. Completed: the job is completed successfully 6. Canceled: The job is canceled i.e. an error occurred

Background job Mechanism: When the dialog user defines the run a job in the background it is entered into the tables TBTCT and TBTCS Background processing time scheduled in table ( TBTCS) Compare value for batch job selection TBTCT Background Job Scheduler: SAPMSSY2 is the ABAP program that runs every rdisp/btctime It runs for every 60 seconds or the time specified by the parameter rdisp/btctime= It checks for the jobs in the ready state and brings them into background job queue. It runs in the dialog process. 1. User logon to the system to schedule a report or program in the background mode 2. It is stored in the tables TBTCT, TBTCS 3. A background job scheduler runs for every 60 seconds in the dialog mode to pick the background jobs 4. If the job is picked and ready to execute the status is set to ready 6. When the background process is assigned status is ACTIVE 7. Canceled when the job is not complete. Background Job Steps: Background Job can be defined by using an ABAP program, External Program and External Commands 1. ABAP Program: It is a standard program or custom defined program which will be executed using Variant Variant: It is a program selection criterion to provide the inputs during run time or execution of the program 13

Ex: Delete the background jobs for every two days 9The jobs which are terminated or completed successfully) Delete the old log files for every 3 days or delete the log files which are older than 2 days.

Note: Variants are stored in the table TVARV (Table of variable in selection criteria)
2. External Program: It is used to define the program to trigger on the host wwith the specified parameter Ex: R3trans, SAPstart, SAPEVT,
This type of job step allows you to run programs outside the SAP System. External programs are unrestricted, directly entered commands reserved for system administrators.

3. External Command: These are the commands which are not specific to O/S Ex: brbackup, brrestore, brconnect etc These commands are defined I transaction SM69 and executed through SM49.
This type of job step allows you to run programs outside the SAP System. External commands are predefined, authorization-protected commands for end users. The type of external command and external program is unrestricted, meaning that you can use either compiled programs or scripts. Such programs can be run on any computer that can be reached from the SAP System. Parameter passing to non-SAP programs is completely unrestricted except by the predefinition mechanism for external commands. Output of non-SAP programs, particularly error messages, is included in the job's log file. Specifications required for an external command or program is: o o External command + Type of operating system + (Parameters) + Target host system External program + Parameters + Target host system

External Commands and External Programs

The background processing system makes a distinction between external commands for normal users and external programs for system administrators. You can see this distinction when scheduling a job from Transaction SM36, with separate fields for external commands and external programs.


External commands
External commands are predefined commands for end users. They are operating-system independent and are protected by authorizations, so that normal end users can schedule only those commands that the system administrator permits them to. With an external command, an ordinary end userany user without background processing administrator authorizationmay run a host system command or program that has been predefined by the administrator in the SAP System. The user who schedules the external command must have the authorization required for the external command. External commands let you control what your users do outside the SAP System. End users can run only the commands and arguments that you specify in external command definitions. And you can control access to external commands with SAP authorizations. For additional security, external command definitions are operating-system specific. For example, you can define variants of a command for UNIX and Windows NT hosts. A user who schedules an external command must specify the type of operating system in which the command is to run. The system then automatically selects the correct operating system variant or issues an error if the required variant has not been defined.

External programs
External programs are unrestricted commands that are neither pre-defined or restricted by authorizations. A user with administrator authorization can enter any of these in a job step. With an external program, a system administrator can enter any desired host operating system command or program in a job step. No SAP authorizations test is carried out before executing the command.


External programs give an administratora user with the background processing administration authorization (authorization object S_BTCH_ADM Batch processing: Batch Administrator)the flexibility to run any required host system command without any administrative preparation in the SAP System. The purpose of this distinction is to let system administrators execute any required external program while restricting normal users to authorizations-tested external commands.

Defining Background Job with a Variant:

Ex: Program Name: RSPO1041 Go to SA38 Specify the program Name as RSPO1041 Execute or F8 Specify the inputs Go to Variants and save as variant Specify the Variant name Specify the Description Now Go to SM36 Specify the Job Name Specify the Job Class Status as ScheduledSpecify the server where the Job needs to be executed Click on Job Steps Click on ABAP program Specify the Program Name Specify the Variant Save the Job Steps Click on Start Time (Condition) Specify the time or the start condition for the job execution and save the job definition. Job start condition can be any one of the following: Immediate: To schedule immediately. Date and Time: To specify at later date and time i.e. date and time for the job execution After Job: The success of one job starts the other job. Failure may terminate further steps After Event: Event triggers the job using SAPEVT (SAPEVT is an executable in run directory) At operation Mode: Once the operation mode switch takes place the jobs will get executed We also can define the output using spool list recipient i.e. output can be to a printer, Email, Faxetc when defining the background job. One can use the Job wizard to define your jobs. Housekeeping Jobs: Click on the standard jobs to define the standard housekeeping jobs. Some of the Housekeeping jobs are: 1. RSBCOLL: It is a background job to collect the statistics of all the Jobs 2. RSPO1041 (or) RSPO0041: To delete all old spool requests 3. RSSNAPDL: To delete old ABAP dumps 4. RSBDCRED: To delete the old batch input jobs or files 5. RSBTCDEL: To delete the old background job


6. RSM13003: To delete old update requests Select all the required jobs to schedule or click on Default Scheduling to schedule as per SAP norms.

Background Job Monitoring:

1. Go to SM37 Specify the job name or user name with job status and start data and time. 2. The jobs are displayed with various statuses. Select the job. Click on the job log to display the execution of the background job. 3. Select the job click on spool to check the spool generated by the background job 4. The background job can be deleted ( Including Active jobs) we can also reschedule and repeat the scheduling or move to other dialog instances. 5. We can also apply the job change to the inputs of the job before it becomes active. Purpose of the Background Job: 1. Schedule backup 2. Customize the in house reports such as daily sales, purchases to display the report to the usewr in the PDF form. 3. Run the pay roll and email the pay slips 4. Data Transfer from R/3 system to file system and vice versa. Ex: Manual Time in and Time out entries or schedule to move in to SAP periodically Background Job Problems: 1. File system problems: a. File is not available b. File permission Problem c. File couldnt be opened d. File is corrupted 2. Authorization issues: a. User Id is expired in the system b. The password is expired c. Password is locked due to illegal attempts 3. Database Issues


a. The database space is not enough and results in errors (ora- 1653, 1654, 1631, 1632, 255, 272 .) b. Update process deactivated 4. ABAP dumps due to programmatically errors (S-Note, Support Packages, patches, Kernel upgrade) 5. Third party tools 6. SAP background mechanism is not so intelligent to work based on multiple conditions a. Maestro Toll b. Tidal Tool c. SAP Job Scheduler d. Other IBM products (Tivoli) Note: In order to work with above tools customer provides adequate training to the consultants SM62: It is used to display SAP events which will be triggered in the background by using SAPEVT SM64: To trigger the event in the background Reorganizing Background Jobs: Schedule report RSBTCDEL to delete the old background jobs based on outdated variants Background Job scheduling will be done in the following Way:


Authorizations for Background Processing:


Authorizations for accessing background processing jobs can be set up for two types of users: administrators and end users.
A users jobs are defined and run in the users current logon client, regardless of whether the users background processing authorizations are set for user or for administrator.

Setting Up Authorizations
Administrator authorization setup requires the following authorization objects:

Authorization Object S_BTCH_ADM (Batch Processing: Batch Administrator) Allows all of the activities listed above except for maintaining external command definitions. No default profile with ONLY this authorization is currently shipped with SAP, but the standard SAP_ALL profile contains this authorization. S_RZL_ADM (CC Control Center: System Administration) Allows an administrator to maintain external command definitions and to trigger commands from the external command function (Transactions SM49 and SM69). S_BTCH_JOB (Batch Processing: Operations on Batch Jobs) Allows an administrator to view job-generated spool requests. To protect sensitive data, this authorization is not included in the standard administrator authorization. S_DEVELOP (ABAP Workbench) Allows an administrator to capture and debug background jobs by providing access to ABAP debugging tools

Value Y



User authorization setup beyond job scheduling and status checking requires the following authorization objects:

Authorization Object S_BTCH_JOB (Batch Processing: Operations on Batch Jobs) Allows all of the activities listed above except for maintaining external command definitions. No default profile with ONLY this authorization is currently shipped with SAP, but the standard SAP_ALL profile contains this authorization.

Value(s) DELE (delete other users jobs) LIST (display spool requests) PLAN (copy other users jobs) PROT (display anyones job log) SHOW (display job details) RELE (release other users jobs to start; a users own jobs are automatically released when scheduled.) permissible users

S_BTCH_NAM (Batch Processing: Batch User) Allows a user to specify other users for runtime authorization for a job. S_LOG_COM (Authorization to Execute Logical Operating System Commands) Allows a user to run external commands.


S_ADMI_FCD (System Authorizations) For special functions, such as debugging active jobs. For complete information, see authorization object documentation from Transaction SU21.


SAP Transaction:
A transaction is defined as a sequence of dynpros (sap term for screens) having input and output fields and corresponding processing logic behind them to perform a particular task. Every transaction has a 4 or more character code assigned to it. To invoke the transaction the user needs to enter this transaction code in the command window. This takes the control to the first screen of the transaction.

It consists of multiple transactions which are handled by different dialog W.P. Each transaction is a logical unit of work (L.U.W) in the database. Each L.U.W is a transaction which can be committed or rolled back

T L.U.W L.U.W L.U.W L.U.W E M P T A B L E Not Committed then Roll Back

A logical unit consisting of dialog steps, whose changes are written to the database in a single database LUW is called an SAP LUW. Unlike a database LUW, an SAP LUW can span several dialog steps, and be executed using a series of different work processes. If an SAP LUW contains database changes, you should either write all of them or none at all to the database. To ensure that this happens, you must include a database commit when your transaction has ended successfully, and a database rollback in case the program detects an error. However, since database changes from a database LUW cannot be reversed in a subsequent database LUW, you must make all of the database changes for the SAP LUW in a single database LUW. To maintain data integrity, you must bundle all of you database changes in the final database LUW of the SAP LUW. The following diagram illustrates this principle:




The bundling technique for database changes within an SAP LUW ensures that you can still reverse them. It also means that you can distribute a transaction across more than one work process, and even across more than one R/3 System.


Update Mechanism:
63. Whenever a user wants to update or create a transaction logs into the system using dialog process 64. 65. User logs into the Database/ R/3 system using SAPGUI User request is received by dispatcher and keep in the queue

66. Whenever a free work process is available dispatcher assign it to the work process 67. Work process rolls the user context to task handler

68. Dialog user initiates a update transaction like sales order, purchase order, invoice, billing. (Let us say modify/ change) 69. If the request is related to the update it communicates with Enqueue process to issue lock to update the records. Time= 1 millisecond. If the request is from a Dialog instance, dialog work process communicates with message server in the central instance and message server to communicate with enqueue process to issue the lock. This entire process should be completed within 100 milliseconds 70. As a transaction consist of multiple dialog steps they are updated into temporary tables called as VB* tables. These tables are updated by the dialog work process 71. Update process reads the temporary tables to update the database based on Transaction Id.
Dialog process updates each dialog step task in temporary tables. These tables are called as VB* tables. These are VB* tables and the tables contains: 1. VBHDR: Update header information is stored in this 2. VBMOD: Update module information 3. VBDATA: Data tables of update process


4. VBERR: Errors occurred during the update process 5. VBLOG: Update log files 10. Upon the successful update (Temp Table) a transaction Id is generated 11. Transaction Id is generated form NRIV table (Number range Intervals)_ 12. Update process gets initiated, reads the temporary tables and updates the database synchronously based on Transaction Id. Types of Updates: 1. Local Update 2. Synchronous Update 3. Asynchronous Update 1. Local Update: Dialog process updates the database directly (System tables, direct update tables, users etc) 2. Synchronous Update: Update process reads the temporary tables and updates the database synchronously 3. Asynchronous Update: The process of updating temporary tables by a dialog process is referred as asynchronous update Types of Update Processes: 1. V1 Update 2. V2 update 3. V3 updae V1 Update: It handles the update with high priority V2 update: It handles the update with low priority V3 update: Reserved by SAP Define V1, V2 updates properly to ensure that update mechanism works properly. Note: There should be at least one V1 update to handle the updates There should be at least one V1 update process defined for every 5 Dialog processes. 25

If V2 is not defined then V1 handles the V2 request The V1 and V2 mechanism is defined in the update programs defined by SAP. SAP never recommends custom updates on the standard tables SE12: Display the database tables Note: The update process inherit the locks from dialog process Update Monitoring: Updates are monitored in Transaction SM13 Go to SM13 to display the records based on client, user, from date and To date and status. The records are displayed with the following status: Init: Update is getting initited to update the database Run: Update running Auto: If the update is cancelled due to any reasons it will be set to automatic update once the problem is solved Err: The update process is thrown in to error Update Errors: 1. There is no space on the database (errors are prompted with message Err1653, 1654, 1631, 1632, 255, 272 and so on) 2. there is a problem in the program which can be fixed by applying note or support package 3. Number range problem: Cannot insert duplicate records. During the above problems we can set the system to deactivate the complete update mechanism to keep the system consistent 4. After resolving the above issues we need to manually activate the update mechanism to update the records. The records with errors state will turn into Auto Status 5. There are some records where the error message says that error (Couldnt repeat the update) that means these records cant be updated again 6. If there is no such error we can select the record and repeat the update 7. Do not delete the update records. 26

Use the following transaction to get the granular formation about the update failure SM21, SM37, ST22, SM13, SM50, SM66 SM14: It is used to deactivate and activate the update manually and we can fix problems manually Update Parameters: 1) rdisp/vb_stop_active: Set to 0 so thatupdate can be deactivated. If the value is set to be 1 update cant be deactivated 2) rdisp/vbdelete: This parameter is used to delete the old update requests based on number of days which are older than 50 days it will delete the default 50 days 3) rdisp/vbmail: It is used to send an email if update throws an error which can be viewed in SBWP (SAP busiess work place) based on yuour user. Will be set to either 0 or 1 4) rdisp/vbname: Name of the server where updatesa are processes 5) rdisp/vbreorg: used to delete the incomplete update requests. 1- Delete, 0- No We can also schedule a background job RSM13002. But it will delete the update request which are in completed. Alternatively use rdisp/vbreorg set to 1 so that it will be deleted after restarting. 6) rdisp/vb_delete_after_execution: Its used to delete the delete update requests soon after the execution of the update. Set it o 1 to delete the record or 2 to the record will not be deleted. It is set to 1 the background job RSM13002 is not required, if not schedule periodically daily during the off peak hours. Update Advantages: 1. Database consistency 2. User is not waiting for the status of update in database 3. User updates i.e. dialog updates temp tables asynchronously 4. Update process reads the data from temp tables and update the database synchronously.


Number Assignment: During the implementation number range intervals are defined in the table INRIV. The numbers are buffered and assigned to the transactions when they are committed. The numbers are buffered and assigned to the transactions when they are committed. The update process updates the database with same transaction number. That is the reason we need to monitor updates continuously. Update Problems: 1. Less number of work processes configured 2. The number queue increases and more updates are init state Resolution: Try to find out the status of other back ground job which are updating the data base. The update is consuming more time to update the database, the update queue increases. If it is a generic problem try to resolve it. If it is a regular problem consider increasing update process based on the availability of resources 3. Check if the update mechanism is deactivated (SM14). Go to SM14 check the status of update mechanism if it is deactivated check the system log (SM21) Note: Update can be deactivated and activated manually in SM14 4. Programmatical Errors: There is a programatical for which the update is thrown into error state. Refer the problem to development team, it is a customizing program. If the problem popped up after applying support package and patches refer to sap notes for a consult or else write to SAP. 5. Table Space Overflow: When the table gets overflowed we could not update the database. Increase the table space and rerun the update. Note: Update work with enqueue process to obtain and inherit the locks.


Enqueue Process: It is used to communicate to obtain a lock while updating a record. It is completely different with database locks. Database locks are only at DB level, where as enqueue locks hold the transaction in large.





Enqueue Mechanism: 1. User requests for an update. Dialog process communicates with wnqueue to hold lock on that record. (If the request is to the central instance). 2. If the request is coming from dialog instance dialog process communicates with message server on the central instance and the message server communicates with wenqueue to get the lock and issue to dialog process. 3. The enqueue locks are issued from the shared memory of the central instance which are displayed in transaction SM12 4. The use update the record in temp tables and locks will be inherited to the update process till the final update into permanent tables in the database. 5. The enqueue time will be 1 millisecond to 5 milliseconds on central instance, where as it is 100 milliseconds for the requests that are coming from dialog instance.


6. There will be only one enqueue process in most of the environments. It is also possible to configure more than one enqueue process but ensure that all the processes shares the same lock table. 7. Enqueue locks are monitored in transaction SM12. 8. Enqueue displayed based on table name, client and user name. It displays lock arguments, time and the table. 9. No lock should be older than 24 hrs. If long pending locks are displayed we nedd to evaluate clearly. Enqueue Problems:


Lock table over flow

73. Enqueue lock table resides on shared memory of the central instance 74. The lock table size is configured by parameter enqueue/table_size= 4-100 MB. By default it is 4 MB in size which can be increased up to 100 MB 75. When the lock table overflow the error message recorded in SM21, ST22 76. If the update is processing the records and releasing the records in time. If not the lock table will be filled and you can not issue any locks. We can use the parameters to increase the enqueue size. 77. Enqueue time increases (4 or 100 Milliseconds) i.e. enqueue could not process the locks with in time or in any massive update system, the enqueue process alone cannot serve the reuquests in this scenario. We can increase enqueue work process by using process 78. Rdisp/wp_no_enq= 0 to 100. Increase the enqueue process on the same server where the earlier enqueue processes are defined 79. Dead Locks: If the object required by one user is locked by another user and simultaneously the object required by the other user is locked by this user then there is a dead lock. But mixture of programs and SAP programs makes a way to a deadlock. In a dead lock situation either one of the user has t log off.
Releasing Locks: Rlease the locks only with the permission of the user. Te permission should be in black and white (Email or signed document). 30

The following is the procedure for the lock release:


User requires a ticket that he couldnt update the record

81. Get the detail of the user from SM12 and communicate with the user to release the lock 82. If the user is not in the office communicate over mobile (Verbal) and send a mail (As per the conversation in releasing the lock.). 83. Send the mail cc to project manager, team leader etc..

84. Get the approval to log off the user session in SM04 and release the lock.
Note: Enqueue and Update work together.


Spool Management:
Its only the process which is used to output the documents to the printers, fax. Spool Process work Flow: Dialog process or background process creates a spool request i.e. to print the documents. Ex: Dialog process use to print an individual pay slip, sales order, purchase order invoice etc Background processes use to run the pay roll to generate pay slips for all the employees. To print delivery orders in batch (bunch) invoices etc When the print order is specified by the user or background work process the spool request is stored in database or at O/S level in the global directory. The storage location is specified by the parameter rspo/store_location. This parameter has two values Global-G and database- DB These spool requests are also referred as TEMSE. (Temporary sequential objects). These are stored in the location rspo/store_location parameter. TEMSE is nothing but spool requests. Spool process reads Temse and generates output requests. G- Means it is stored in global directory \usr\sap\SID\sys\global DB: Means it is stored in Database tables TST01 and TST03 TST01: It stores the objects and details of the spool requests such as name of the Author, Number of copies, name of the printer etc.. TST03: It contains spool data to be printed



Spool Request

DB (Database) TST01, TST03

G (\usr\sap\sid\sys\global) TEMSE Parameter G: The Temse resides at O/S level. It will be faster to access than database (DB). When the spool size is small (around 300 MB) and If the spool size increases it will be difficult to locate them to print . O/S memory is used. Dedicated space needs to be taken to store the backup of Temse. Parameter DB: Time consuming to wrote into DB. But with the help of indexes it can be printed out fast. No special care for backup is required because its backed up along with normal database. O/S memory is not required. SA38: RSOSR002 is the report used for deleting the old requests. Advantages of Temse:

85. 86.

The out of the spool request can be viewed before it is pronted. Spool process reads Temse and generates out put requests.

87. Output requests are depends upon the access method. Access Method specifies the type of access to the printer. 88. There are various access methods

Access Methods:

89. Local Access Method: The spool process and the host spool (Printer Spool) reside in the same system. Access method type L is used for unix operating systems. C is used for windows which makes a direct call to the host spooler. 90. Note: The printer can be remote or local

91. Remote Access Method: The spool process host spooler resies on two different machines. Access method U based on unix barkle protocol. User for unix os access method. S sup protocol used for windows. 92. Front End printer: Access Method F. The printers ae connected to end user desktop do not configure too many front end printers because the resources will be blocked by the user.


93. 94.
USER F Printer Sap R/3

Its also not used for scheduling background jobs because the interactive inputs.

Defining a Printer: Go to transaction SPAD (Spool Administration) Click O/P device Click on change Click on create Specify the output device name. Output device name should be meaningful to identify the location and type of printer. Specify the short name Define model, location, and message.

95. Device Type: Specify the type of the output device. Name of manufacturer most of the device types are available in the SAP system. But new printers which are released after the release of SAP component we need to get the new device types.
Go to SPAD Utilities for device types Import.

96. Spool Servers: The server with at least one spool process is called spool server. Spool server can be logical or real server. Spool servers are created in SPAD 97. Go to SPAD Click on Spool Server Click on create Specify the spool server name Specify server class specify device class (Standard printer) Authorization group 98. Note: Specify the group so that only the group assigned can access the printer

Logical Spool Server: 34

It is defined for fail over and load balancing between printers. USER


(Logical Server)

Real Spool Server Click on the Access Method: Host spool access method C for Windows NT L for UNIX C and L are local access methods U and S for remote access method U for UNIX S for Windows NT F for front end printing

Real Spool Server

Note: Dont configure too many front end printers. If configured spool congestion occurs. To avoid spool congestion configure the parameter rdisp/wp_no_spo_fro_max=2 This parameter allows using the work process for the front end printing, let us say if we have 10 processes only 2 can be used for front end. Specify the name of the printer Destination Host: Name of the host where the printers are configured. Check Box: Dont query host spooler for output status. Each work process goes to the printer and gets the status of the printing. If this box is not checked the spool process are busy getting the status. Output Attributes: 35

99. 100. 101. 102.

To print the cover page Author Name Number of copies Name of the printer

103. Process request sequentially. Used to print the documents s sequentially. If numbering is important select this option. If not deselect the check box
Note: If the device types are not available select SWIN a default device type which will run a suplpd (Line print daemon). Suplpd is a protocol to print by default, if the device types are not available.

Spool Monitoring: Go to SP01 Specify the User Name, Date and Time to display the list of spool requests. The following statistics of the spool requests are displayed. 104. -: The request has not been sent to the host system or the output request doesnt exist. 105. +: Spool request generated stored in Temse

106. Waiting: Spool request is waiting to be processed by a spool work process. 107. In Process: The spool process is generating the output request based on spool request. 108. Printing: Printer is printing the request. The status will be displayed approximately 1 min and status sets to either Complete or Error. 109. Completed: The job might be completed but assume that handling over the print job to the printer is completed. The printer might not be printed. 110. Problem: The output request printed but contains mirror errors such as page format, character set etc. 111. Error: The request has not printed.


Handling Spool Requests: Go to SP01 and select the spool requests which are thrown into errors. However we may need to act based on user requests such as the status shown completed but the documents could not be completed. Waiting Status: These requests are waiting in the waiting status for more than one hour Conclusion: Spool process is busy in handling the spool requests or the spool work process is not sufficient to handle the request. User complaints that the spool request could not be generated: 112. The printer is not available or locked in the system.

113. By default SAP allows 32,000 requests to be stored in Temse we can increase that up to 99,000. We cannot increase beyond 99,000 because the maximum spool number is 99,000. Rspo/spool_id/max_number=32,000 to 99,000 Schedule the following background jobs in SA38: RSPO0041 (or) RSPO1041. This above reports deletes the old spool requests based on status. Schedule the reports RSPO0043 or RSPO1043 to check the consistency of the spool periodically. Spool Problems: 114. 115. 116. 117. The printer is not available (Printer power off, No network etc) Paper out. No paper, Paper Jam Cartridge or toner out Printer problem

Go to SP02. This will provide to all the users to display their own spool requests. If the spool request is thrown in to error to a particular printer then select the printer and print select the printer with change parameter


SPIC: Spool installation check. This is used to check the spool device and pending requests along with consolidated problems and warnings. SP12: Temse administration. It is used to check the memory allocation objects and perform the Temse consistency check
Reque st Dialog Dialog

Back Groun d Spool Request

Spool Server/Spool Process


Local Access

Remote Access

Front End




Data Transfer:

Old Legacy system





Printer Internet 90% DB Fill

The data has to be transferred in to SAP system in the following situations. 118. During implementation to transfer the data from legacy systems to SAP system. To test with live data. 119. 120. Migration of legacy system DB to R/3 system Data transfer during parallel run

Parallel Run: It is an activity where both SAP and Non-SAP systems run parallel. The data entered in NON SAP system will be transferred to SAP system periodically during Off Peak hours without any user intervention. Periodic data transfer from suppliers vendors etc. In order to communicate with vendors back end systems we need to define RFC connections.


Remote Function Call: There are various types of RFCs which are used to transfer the data. 121. 122. 123. 124. Asynchronous RFC (ARFC) Synchronous RFC (SRFC) Transactional RFC ( TRFC) Queued RFC (QRFC)

ARFC: Does not check for the acknowledgment from the target system. These are not reliable because there is no confirmation from the target system. SRFC: It communicates synchronously with target system and ensures that data is transferred. During the data transfer the process may go into sleep mode or CPIC mode. CPIC Mode: Common programming interface communication. It is an SAP proprietary protocol to communicate between systems. TRFC: It is similar to asynchronous but a transaction Id is created and is monitored in transaction SM58. A background job RSARFCSE is scheduled for every 60 seconds to check for the transaction Ids in the transaction SM58 QRFC: It is similar to TRFC and it ensures that the transactions are processed in the same sequence they entered in to the queue. Defining a RFC connection: 125. Go to SM59 Click on create Define the RFC destination name. The name should be able distinguish between the connectivity. 126. Define the connection Type: 3 for connection to R/3 system 2 for connection to R/2 system 127. 128. Give description Go to Technical Settings

129. 130. 131. 132. 133. 134. 135. 136.

Specify the system number Specify the system number Specify the Gateway options Gateway host Gate way sapgw<instance number> Click on logon details Save Click on test connection.

If the specified user is a dialog you can click on remote login to check the connectivity. ALE: Application Linking and Enabling It is used to communicate between two loosely coupled systems. Use transaction SALE to define systems.

Logical System: Logical systems are used to identify the client uniquely in the landscape. As client is identified by a number we need to assign logical system between <SID>CLNT000 Ex: DEVCLNT000, QASCLNT000, PRDCLNT000 BAPI: Business Application Programming Interface It is used to communicate between sending system and receiving system based on interface and method. Select the Model View Select the Send Client Select the Receiver/Server OBJ Name Method C / Interface Simulator

Add message type and specify the message type. Note: Most of the data transfer methods are defined by functional consultants during implementation. Ex: Central user administration uses ALE mechanism to transfer the data between clients EDI: Electronic Data Interchange It is used to exchange the data between SAP and NON SAP systems. 137. 138. SAP system needs to understand NON SAP systems. Non SAP systems needs to understand SAP systems language

In order to understand the language between systems IDOCS are implemented. IDOC: Idoc is an intermediate document which is in the understandable format by both the systems. Ex: Customer is having VB_SQL_Server based system. Where as SAP is based on ABAP language Customer sends purchase order through VB system, which is converted into IDOC and sends to SAP system. SAP system sends invoice in the native format which is converted to IDOC and sends to customer VB system. Note: This mechanism is defined by functional and technical consultants. BASIS consultants monitor the flow of the IDOC. IDOCs are monitored through IDOC and WE05 The sending system documents are out bound documents in the sending system. The receiving system documents are inbound documents from the sending system. Go to WE05 select the date and time to display the IDOCs with various statuses 00-49: Out Bound 50 and above: Inbound


Some of the states is 51 document not posted. 64- IDOC ready to transferred to application . QRFC Monitor: GO to SMQR is used to monitor the QRFCs. SMQ1: Is used for out bound queues SMQ2: Is used for inbound queues SM58: Is used for monitor the transactional RFCs based on transaction Ids Data Transfer Methods: 139. LSMW: Legacy system migration work bench: It is used to transfer the data from NON SAP system to SAP R/3 systems. This is used during implementation and mostly one time activity. 140. Process: Identify the data which needs to be transferred from the legacy systems. Pause truncate and PUDD the data if required i.e. mapping between the source data and receiver data. 141. Ex: Char (50) is source but an receiver char (40) so we may need to truncate the source by 10 characters. If receivers is char(60) se ma need to padd the data. 142. 143. Session Method: This also programmed by developer but this can be used for periodic data transfer. This familiarize with error message handling 144. 145. Errors during Data Transfer: Source /target system not available

146. Document problems (Document is not readable, Junk character, Permissions, document not found, document is too old) 147. RFC erros lik t ID. RFC: Error like USERID, Password, USER ID not active 148. WE05 IDoc expenses.


Instance provides a set of services, work processes, Buffer-Areas to an application instance is controlled by various parameters i.e. start up parameters, instance parameters and default parameters. These parameters describe the characteristics of an instance. Instance mainly depends on memory resources based on available memory. We need to configure the parameters. These parameters reside in usr\sap\sys\profile directory. 149. Default Profile: It provides default parameters for all the instances in the R/3 system. Some of the parameters that can be configured globally are as follows: 150. login/system_client=999 this determines the default client for all the users 151. zcsa/system_language= To specify the language during log on

152. login/* : All the login parameters to control password, user id etc. This can be modified based on requirement by administrators. But it requires a restart of the instance to take effect. Its naming convention is default.pfl. 153. Start Up Profile: It is used to start the instance. It is recommended not to change any parameters in this profile. Your instance may not start if any changes are made to this profile. Changes are allowed only when there is a change in Host names or SID. Its naming convention will be as follows: 154. 155. Start_DEVBMGS<nr>_Hostname (Central Instance) Start_D<nr>_Host name (Dialog instance)

156. Sapcpe.exe : It is used to communicate with database when a dialog instance is installed. It is also initiated when the central instance and database instance installed separately. 157. 158.

Instance Profile: It start with <SID> of instance

<SID>_DVEBMGS<nr>_<Host Name> (Central Instance)


<SID>_D<nr>_<Host Name> (Dialog instance)

160. IT consists of the instance specific parameters like work processes, buffers. Go to the table TPFYPRODTY to display the instance specific properties grouped by dispatcher, ABAP etc. Some of the parameters are as follows: 161. 162. 163. 164. 165. 166. 167. rdisp/wp_no_dia rdisp/wp_no_btc rdisp/wp_no_vb1 rdisp/wp_no_vb2 rdisp/wp_no_spo rdisp/wp_no_enq rdisp/max_wprun_time=600-1800

168. All ST02 transaction like abap/buffersize. If the field dynamic is set to X the parameter can be changed or in RZ11. If there is an option change value we change that parameters dynamically without restarting server.

Profile management:
Go to RZ10 for static profiles and RZ11 for dynamic profiles: 169. 170. Go to RZ10 to import profile from O/S level to database. So that parameters are maintained at Database level and consistency between the required and threshold value is checked. 171. Ex: Work process should not be configured more than 100 where as this is allowed at O/S level but Database level it gives warnings. 172. Table TPFRT is used to store the parameter values along with versions. 173. Administrative Data: Which will gives you the path of each profile. Do not change this until there is change in path of the profiles


174. BASIS Maintenance: This is used by technical team where maintenance is performed without knowing the parameter names. You can toggle between the values by increasing and decreasing the values. It is used to maintain work process buffers, memory management. 175. Extended Maintenance: It is used to change the parameters based on parameter names. It is used by experts and ensures that necessary care is taken while modifying parameters. Note that your instance may not start due to change parameters (Wrong parameter). 176. Go to RZ11 and get the documentation of the parameter before you make any changes to the parameters 177. Go to RZ10 select the profile to be maintained. Let us say instance profile and select Radio Button for extended maintenance. Click on create parameters. Specify the parameter and its value click on copy. Go back and save and activate profile. It will request you to restart the server for the parameter to get effected. 178. The existing profile in SYS/Profile will be renamed to .bak and profile is copied from database to O/S level. Restart the server.


Operation Modes:
Operation modes are used to define system optimally by utilizing the resources during the peak hours and off peak hours. Operation modes toggles between the day mode and Night Mode (Peak and Off peak) by utilizing the work process optimally. Defining the operation mode is done in 2 levels:

179. Defining the Operation Mode: Go to RZ04 Define operation Mode SAP System name, Operation mode Click on Instance/ Operation Mode 180. Assigning the Time interval: Go to SM63 Select the interval and assign the operation modes
Purpose of Operation Modes: Operation modes are used to utilize the dialog process during day time and background process during the off peak hours i.e. we may not require dialog during off peak hours. We may require more BTC during off peak. We can dynamically switch between the processes without restarting the server. When opmode switch occurs it is resulted in SM21. Dont configure too many modes. Note: If a background job is running, during operation mode switch it is allowed to continue t run after completing the job the operation mode switch occurs for this background work process. Select * from SAPDEV table name where paraname like rdisp%


Logon Load Balancing

181. 182.


G 1

End User



L G 2 Message Server



Logon Groups: These are used to define load balancing mechanism between the instances. These are used for logon load balancing\fail over between the instances. These are used for optimal utilization of buffers. Defining logon Groups: Go to SMLG Define log on groups and assign instance Logon groups are defined based on geographical locations based on application models. Message server keeps the list of all logon instances and displays the favorite computer server by calculating answer time and think time. Mechanism:


User logon to the system using logon group

185. System communicated with message server based on sapmsg.ini and communicate with 3600+ instance number through entry in etc\services i.e. you need to maintain all the user desktops with the above two entries ( sapmsg.ini and etc\services) 186. Message server keeps the info of favorite server and route the request to that instances Advantages: 187. 188. 189. Load balancing Fail over Effective utilization of buffers and system resources

190. Performance improvement similarly logon server groups are used for RFC communication RFC Server Groups: These are used by RFC users to identify the least loaded server and route the request. Go to RZ12 Define the server group and assign the instance. We can specify various conditions i.e. number of logons, maximum number of work processes, maximum wait time etc. These are mainly used for background job processing. These are used for optimally utilization of resources so that background processes are utilized effectively


System Monitoring
It is used to monitor system health on a periodic schedule to avoid the last minute surprises and accidental growth or utilization of resources abnormally. SM51: To identify the types of process configured and the status of the instances. As per our checklist we need to count the servers and ensure that all the active servers are running Click on the release notes to identify the R/3 Kernel, DB Kernel, O/S kernel and support package information Select the systems and use option Goto to display various properties of the instance RZ03: Ensure that this transaction is locked in the production system. It is used to stop the instances to toggle between the operation modes. Note: Do not stop the instances using RZ03 SM21: System logs It is used to display the logs based on instance. Go to SM21 display the logs based on Date, Time, User and Transaction Code. The messages are displayed with various colors. SM21 displays error message, warnings and messages 1. Max time out reached 2. Oracle errors (ORA 1631, 1632, 1653, 1654, 255, 273, 1555) 3. Update deactivation 4. Work start up and shut down 5. Operation Mode switch 6. User distribution 7. O/S errors 8. ABAP Dumps

9. Background job errors 10. Number range intervals Mostly it records all the important activities. We need to look in to the errors that are displayed in RED color and light Red color Analysis: Click on the error message. Get the error message. Identify the uses and check with the user. If any abnormalities are found get the error message and check out in market place. ST22: ABAP Dumps SAP system is built on ABAP language. So it executes based on ABAP programs. If any one of the program could not be executed it will thrown into errors and recorded in SM22 and SM21. The programs can be thrown in to dump under the following circumstances 1. Time out Error: Schedule in the background or fine tune the program by restarting selection criteria 2. Data Base Errors: ORA 1631, 1632, 1653, 1654, 255, 272, 1555 3. PXA Errors/ Buffers: Space is not enough to store the content 4. Memory Errors: When memory to execute the program is not sufficient it will be thrown into error 5. Program Bugs: Which can be fixed by applying notes and support packages 6. Kernel Mismatch: Upgrade Kernel 7. Upgrade errors and background job errors: SQL_array_cannot_insert_duplicaterecords 8. Too many conditions and indefinite loops throws the custom program in to dump
Go to ST22 Double click on the dump and read the dump thoroughly and understand the problem. Thoroughly understand stand the problem. Go to how to correct error and try to resolve get the error message and resolve by searching in the market place. EWZ5: To lock and unlock the users 51

SM04: To display the list of users logged on to the instance. RSUSR006 is the report we can find all users. ST11: Developer trace of work directory SSAA: Transaction help you to know the user has navigated to the transaction or not. It own all the reports (Monthly, Weekly, Daily) List of transactions to be monitored:

SJAD: Statistics collection for all systems. Report used to generate STAD is: RSSTAT26


Front End Time (or) GUI Time: The time taken by the user request to reach the dispatcher is refereed as GUI Time or Front End time.

Normally this time should not take more than 200 m/s. If it goes beyond 200 m/sec it is considered as expensive. However it is not going to be the part of Response Time. If GUI time increases consider the following: 1. Problem with network (Check the connectivity between GUI to Server) 2. Check whether it is a generic & Common problem (Remote Desktop) 3. GUI problems (We may need to upgrade or apply patch) 4. Logon through VPN or Firewall and proxy and filters may also be a problem 5. Using Dial Up connectivity
Wait Time: The amount of time the users request waits in the dispatcher queue. Usually it will be 50 m/sec or 10% of response time. If Wait Time is expensive consider the following:

1. Work process congestion 2. Work processes are not sufficiently configured at the rate of ratio 1:5 (5 user, 1 work process) 3. Work process configuration is fine but the processes are held up with expensive user requests 4. The work process might gone into private mode, sleep mode, RFC, CPIC modes Solution: Identify the expensive process and logoff the user session based on
approval. We can also consider increasing of work process or deploying the additional instance based on the load. Alternatively configure logon load balancing. Roll-In-Time: The time taken by the work process to roll the user information into task handler Roll Out Time: The time taken by the work process to roll out the user information into roll area. 53

Both Roll in and Roll out time considered as Roll Time.


Gateway Process:
It is used to provide gateway to the instance i.e. incoming and outgoing connections are performed through gateway. There will be only one gateway process for each instance. Gateway is monitored in SMGW. The RFC connections, The ICM connections are displayed in SMGW The maximum gateway connections that are allowed through gateway is 100. It is configured by process. rdisp/max_gateway=100

Message Server:
There will be only one message server in R/3 system (Irrespective of instances). Message server is monitored through SMMS. It is used to handle all the dispatcher and first process to be started. In the R/3 system the instance on which it is installed is called central instance. It is used to balance the load when groups are configured. When log on load balancing is configured we need to maintain the entries sapmsg.ini, etc/service and define the logon groups in the GUI entry for each user. Alternatively we can copy relative saplogon.ini to the end user desktop.


SAP Archiving: It is the process of moving the old data (which cannot be updated any more but required for data analysis and for statutory auditing requirements). The data cane be moved into global directory. If the archiving is not performed time to time the following issues are cropped up in the data center. 1. Response Time should shoots high 2. Database size grows and hardware must not sufficient in terms of memory, CPU and storage 3. The existing tapes becomes un utilized when the size groups beyond the size of the type 4. Admin costs will be high so it is recommended to archive the data from time to time
Database reorganizations should follow the SAP Data Archiving. There are third party tools available for performing archiving.

1. IXOS 2. Archiving- Archiving Pack 3. Data warehouse solution BIW

Process: Identify the data based on objects and tables i.e. users complain that response modifying certain objects Ex: Material, Sales order, Purchase order etc Go to transaction DB15: It displays objects and tables along with the size of the tables. Go to transaction File: TO define the logical path for archiving and assign logical path to physical path.

1. Click on New entries 2. Specify logical path and name 3. Click on assignment of physical paths 4. Define syntax group (Windows NT)

5. Click on logical file name to move the data 6. Specify the logical file 7. Specify name 8. Specify the physical file 9. Specify date format 10. 11. 12. Specify the application area Specify logical path Click on SAVE

1. Go to SARA (SAP Archiving) Select the object name Click on pre processing to define the variant to schedule archiving in the background by start date and spool parameters specify the start date and spool parameters. 2. Click on Write: To write the data click on delete specify date and parameters Execute 3. Click on delete: Select Archive selection and delete complete archive. GO to again delete and select. 4. Click on Read: we can read document 5. Storage System: We can store files.

Go to SAR1: which is archiving information system to check the status. Go to SF01: File transaction is used for cross client where as SF01 is used for client specific files.


CCMS Monitoring
CCMS: Computer center monitoring system Go to RZ20 Extras menu Activate maintenance function It is used to raise the alerts based on the threshold values which are defined in the system.

RZ20: Display monitor sets Monitors Monitoring trace elements properties methods Variants Monitor Set: It consists of all the monitoring activities Monitor: Specific to a certain function Monitor Tree Elements: Elements to be monitored Method: This is specific to a process or activity
Property: Monitoring category variant is value Go to RZ20 Extras Activate maintenance function It is used to raise the alerts based on the threshold values which are defined in the system Add define your own monitor se from the existing templates:

1. Create: Define elements 2. Copy: include only the monitoring required elements
CCMS displays the elements in color:

1. RED: Problem 2. YELLOW: Warning 3. GREEN: ok 4. WHITE: Information not obtained/ not collected
MTE: Monitoring tree element


Go to RZ21: TO change methods properties and MTE classes if required



20 KB Front en time or Dispatche r GUI TIME TSKTT Queue)/Wait Time50 m/sec U EN D US ER C SCREEN ABAP SQL R3 Buffers DBSC CI/DI RFC DB QUEUE (Dispatcher

Processing Time

1. Front End time or GUI time 2. Wait Time 3. Roll In time 4. Roll out time 5. Processing time 6. CPU time 7. Load and generate time 8. Enqueue time or lock time 9. RFC+ CPIC time 10.

Database Time

11. Time

Dialog Response

Generally each time should not exceed more than 50 m/sec. If it exceeds consider the following:

1. Check the user context and reduce the duplicate authorizations. 2. Advice the user to use the reports by search criteria (Specify user name, date, time, status etc) Processing Time: The amount of time taken by the work process to process the
user request. (ABAP interpretation, screen interpretation, SQL interpretation) and reinterpretation, processing time should not more than 2*CPU time PT < 2* CPU time While processing user request CPU resources are utilized expensive programs, expensive SQL statements, expensive screens are responsible. For expensive/ high processing time

CPU Time: The amount of time consumed by work process in utilizing CPU resources while processing request. SCREEN ABAP SQL0
1 2 3

5 6 1+2+3= CPU Time 4+5+6= Wait Time Note: AS CPU time is included in processing time so its not calculated as part of the response time. CPU time = 40% of (Response time-Wait time)

Load and Generation Time:


The time taken by the work process to load and generate the screens and programs is referred as lad and generation time. Generally it should not be more than 200 m/sec. If it exceeds its not utilizing buffers properly increase the size of the buffers.

Enqueue Time or Lock Time:

The time taken by the dialog process to communicate with Enqueue process to communicate with Enqueue process and obtain the lock while updating a record is referred as Enqueue time. Generally it should be around 1 m/sec to 5 m/sec for the request that are coming from central instance and up to 100 m/sec that are coming from dialog instance through message server.

If Enqueue time increases: 1. The lock table may be overflow 2. Dead Lock 3. The Enqueue congestin which can be avoided by increasing work process

RFC + CPIC Time: The time required to communicate with external system or
calling programs using RFC or CPIC is referred as CPIC time. There is no threshold value but ensure that it should not be a bottleneck o the response time. Ensure that resources are available on the target system. If required configure RFC server groups.

DATABASE Time: The time required to process the user request in the database
is referred a Database time. Generally it should not be more than 40% of (response time- Wait time) Ex: DB Time= 40% (1000-100) 40*900/100= 360 m/sec If it exceeds 360 then consider the following:

1. Missing indexes in DB02


2. DB buffers space is not sufficient 3. Expensive SQL statements 4. Database statistics not up to date Dialog Response Time: The sum of all the above time except (GUI Time + CPU
Time). Generally it should not be more than 1000 m/sec but on an average it should be between 600 m/sec to 1200 m/sec.


Work Load Analysis

Go to Transaction ST03 and identify the Transaction, User and Process which are consuming more than the threshold values. We can schedule a report in background to collect the values into ST03 The reports are displayed differently for Expert Mode, Administrative Mode and Service Engineer


R/3 Buffers
Buffering: The frequently accessed content and rarely changed content is stored
as buffer in the application server which is also referred as R/3 buffers.

R/3 Buffers: These are stored in the instance and cannot be shared between the Instances. These buffers are different from database buffers. There are various types of buffers. Ex: Program Buffers, table Buffers, Calendar, CUA, Screens etc. Buffers are stored in the shared memory of the instance. Buffer Mechanism: User logs into the system to access certain data. The request is processed and goes to database to fetch the content. If the content is eligible for buffering it is stored in the instance. The content should be rolled out into user context before the response is sent to the user. As the user context is small in size the context I not stored in user context. But in terms store in R/3 buffers and the pointer to R/3 buffers are stored in user buffers. Note: User context cannot be shared between users but R/3 buffers are shared between users. Buffer Monitoring: Buffers are monitored in ST02. Buffers are organized in terms of directories and the space in the memory. ST02: Display the following information 1. Name of the Buffer context 2. Buffer hit ration: The ration should be always greater than 94% 3. SWAPS
We need to look for swaps. Swaps occurs when the allowed space is completely used or of all the directories used or both utilized. Basically the ABAP buffer size will be 150 MB by default. We can increase up to 600 MB (Up to 4 times) based on the available memory. If swaps occur frequently consider increasing either space or directories. The Reasons for Swapping: 65

1. Frequent transaction of objects 2. The new modules are implemented 3. Buffer memory is not sufficient 4. Number of directories not sufficient 5. Frequent changes to the buffer data
Note: In each company the swaps occurs frequently but look into the number of swaps. Based on the size of the database we can allow 5000 to 25000 swaps. They are not effecting the performance of the system i.e. response time. Double click on the context which has more swaps. Click on parameters to identify the parameter name and value and to change in RZ10 before changing any parameter read type. Complete documentation in RZ11. Miss configuration or improper configuration may not start the SAP engine. TABLE Buffering: Apart from the repository objects SAP also buffers the table content based on the table data (content). There are 4 types o buffering:

1. No Buffering: The table which is large frequently updated rarely accessed is set to no buffering. 2. Full Buffering: (100 % Buffering) The table which is small, frequently accessed and rarely changed is eligible for full buffering 3. Single Record Buffering: The table which is relatively large but frequently accessed is buffered using primary key 4. Generic Key Buffering: The buffering is based on group of keys
Note: For most of the tables SAP define the buffering settings, which can be modified in SE13. BY default SAP provides the following options for buffering tables.

1. Buffering Allowed: This tale can be buffered 2. Buffering Allowed but Switched off: This is used for development and quality systems 3. Buffering Not allowed: Buffering not allowed on this table.

Exercise: List out at least 5 tables in each of 7 cases. SE13 and SE14

Buffer Synchronization: End User End USer End User

DI R/3 Buffers CI R/3 Buffers DI R/3 Buffers DB

1. When more than one instance is configured we need to synchronize the data between buffers of the instances. If not we will get the old snapshot. 2. When data is fetched by one instance it will keep a log in the table DDLOG 3. Even the content is accessed from buffers it will check the dialog always If there is a difference in time stamp it will fetch the data from database. Mean while we can synchronize the data between instances using the following two parameters: rdisp/buffertime= 60 sec: This parameter will refresh buffers every 60 seconds rdisp/buffermode= send on execute/ send off execute. Due to performance reasons use send off, If only one instance is configured.



Its a temporary work area to perform calculations, Reads the data from the disk. No operations are allowed on the hard disk without memory. 1. Physical Memory: The amount of memory that is installed on the system is called as physical memory. 2. Virtual Memory: As the physical memory is not enough we need to assign space on the disk which is referred as page file. This memory is referred as virtual Memory.
SAP Memory Management: SAP recommends using Zero memory management so that memory automatically managed. Memory Assignment:

When a user is assigned with work process the work process requires memory to roll the user information. In order to roll the user information from ROLL AREA (U.C) into Task Handler work process requires memory. Each work process assigned with a memory called Roll Memory which is defined by parameter ztta/roll_area= 2 MB. By default it is 2 MB, and this is the maximum memory a user can use. But initially when the user request we will assign around 1 MB that is specified by parameter ztta/roll_fiorst= 1 MB

Virtual Memory: (Physical Memory & OS Swaps)

Shared Memory Private Heap Memory

Extende d Ztta/roll_area=2 MB Memory

Local Memory

U.C Roll Area 69

Ztta/roll_first=1 MB

Once the initial memory is utilized i.e. ztta/roll_first we will assign memory ztta/roll_extension=512 KB to 2 MB Based on memlimits of OS. Memlimits run command If the specified value is used completely then the remaining part of the roll memory is used i.e. (ztta/roll_area) (ztta/roll_first) If this value is also not enough it uses private memory i.e. the work process goes on to private mode. The value ranges from 80 MB to 2 GB. This value should be lower than abap/heap_area_total (Memory for Dialog and Non Dialog WP) If the work process exceeds the limit specified by parameter abap/heaplimit the work process that can go into private mode as minimal as possible by using parameter rdisp/wppriv_max_no=1 0r 2 If the work process goes into private mode the parameter rdisp/max_wprun_time will not be effective i.e. the program cannot be timed out. If too many programs or W.P goes into provate mode the WP congestion occurs (Hour Glass) and no user can login to system. Use dpmon to kill the expensive work process based on the approval. dpmon pf= E:\usr\sap\<SID>\sys\profile\ Go to ST02 to monitor the extended memory and Heap Memory. If the usage of Heap Memory increases the bottle necks on the system raises gradually. Go to ST06 to display the amount of physical memory. It is used to display the number of CPUs by using count. It displays CPU utilization for the last 15 minutes. The CPU idle time should always be greater than 30%. If it falls below 30% CPU bottle neck occurs.

Reconcile ST03 and ST06 and identify the expensive ABAP program and recommend to fine time it. However we can identify the top 10 CPU users, using Detail Analysis menu Top CPU users. ST06: It is used for displaying CPU idle time number of CPUs, CPU utilization, Physical memory available and utilized and available memory, swap memory and used. It is also used to start and stop SAPOSCOL service. Click on detailed analysis menu to display the TOP CPU users compare the data based on memory CPU. Click on LAN check by ping to check the number of presentation servers, Application Servers and Database Server. You can ping to the servers or to a specified IP address. ST07: It gives the complete picture of the instances users work process and the load on the applications. It is used to say weather system is optimally configured or not. It is a measuring device to configure load balancing based on usage of application components. It also gives the details of Response Time (Which Instance). It also displays the amount of buffers configured on each instance along with the buffered content. ST11: It is used to display the developer traces of work directory \usr\sap\<SID>\sys\work ST05 and ST01: It is used to trace the following 1. SQL trace 2. Enqueue Trace 3. RFC Trace 4. Buffer Trace

1. SQL Trace: When a user complains with show response times while accessing a report or when the DB time is more contributed in response time i.e. more than 40% of the response time we need to run

the SQL Trace. Select SQL trace and activate the trace. Check that trace with filter and specify the selection criteria. We can also enter SQL statements and explain the statement about the cost and estimated rows. 2. Enqueue Trace: When the enqueue time goes behind the threshold value i.e. more thatn one m/s in Central Instnace and 100 m/s for dialog instance then Select Enqueue time and activate the trace and display the trace similarly. When RFC+CPIC time increases we need to switch on RFC trace When buffer swaps occurs and increases gradually in ST02 we may need to trace using buffer trace. ST01: It provides kernel and authorization trace in addition to ST05 traces.. In order to check the missing authorization that could not be traces in SU53 user authorization check trace in ST01 Kernel functions also i.e. kernel executable. When they are calling certain functions we can also trace their activities
This Page is intentionally Left Blank


Motivation to Implement SAP

Manufacturing/ Production (Oracle Apps) Memory (VB and SQL) Machinery (Java and Oracle)
SASTRY GROUP of Industries

Material (Java & Oracle) HR (People Soft) Marketing (Java & Oracle) Management (Java & Oracle) Customer Service (Sieble) Sales (Wings)

Disadvantages of the above Scenario: 1. Monthly report from various systems 2. Data is not Centralized 3. Different Applications 4. Different Databases 5. Too little integration and correlation 6. Administration costs shoots high in maintaining various H/W and S/W resources, Backup Data centers 7. Some of the softwares are out dated then there is no support from the vendor
Proposal to Identify the S/W vendor:


1. The companies unable to identify the requirements to implement and replace the existing S/W by a single solution 2. Company appoints External Auditors to identify the requirements from the key business process owners. Ex: KPMG, Accenture, Baring Point, PWC (Price Waterhouse Coopers) 3. Based on the auditors document the S/W vendors submit the feasibility of the requirements. 4. External Auditors identify the right vendor with the help of customers. At this point customer decides the S/W vendor based on the advantages
Let us say customer decided to implement SAP ERP solution because it provides functionality of more than 30 modules along with extension to various Add Ons. it has a good track record of 46,100 customer providing 24*7 support and continuous improvements by realizing patches, upgrades etc. It has a compatible GUI both web based and GUI based and its portable across various OSs and DBs. The major advantage of SAP is the automatic integration of Data between modules. Steps:

1. Now customer has to identify the implementation partner to implement SAP 2. External auditors defines SOW (Scope of Work) to implement SAP SOW (Scope of work): It defines the scope of work at macro level and includes the following: 1. It includes the request for Proposal/ Quotation (RFP/RFQ) 2. Modules to be implemented (Ex: SD, HR, MM,FI,CO) in the first phase other modules in the second phase 3. O/S and DB 4. Number of Users 5. High level customizing details based on each module 6. Assumptions etc..


Based on the above document we can submit RFI (Request for Information) to get additional details or clarity on the document. As a BASIS consultant we need to submit the following documents:

1. System landscape strategy 2. Client Strategy 3. Transport Strategy 4. Approval Strategy 5. Backup, Restore and Recovery strategy 6. G0-Live strategy 7. Post implementation strategy 8. Apart from the above the following documents are also included in the proposal: a. Company details along with Organizational Structure and Financial Stability b. Services offered by the company c. Planned man hours based on modules at the rate of 168 to 176 hours per month or weekly 40 hours d. A detailed project plan along with implementation methodology e. List of assumptions f. Risks involved in implementation Finalizing S/W vendor by external auditors after considering SOW, RFP, RFQ Based on various credentials the customer identifies the implementation partner and releases purchase order. The objective of this whole process is to get qualified implementation.

SOXs: Single transaction cannot be handled by single person



1) Installation of IDES system and allow all the functional consultants/ Developers to work on the system. 2) Solution Manger Project manager and BASIS consultant responsibilities at the time of implementation: 1. Visit the site of communicate with the data center team 2. Get the details of current infrastructure to plan the H/W resources 3. Perform H/W sizing based on users. to determine the CPU, Memory and storage required for the system in the landscape (Development, Quality, Production) 4. Include solution manager system in the sizing along with the SAND BOX system. (Training or Testing or Standalone) Note: IDES comes along with Demo Data Company is setup with all options for Demo Data in IDES. Production: It can not contain any data. We need to setup everything in production


Implementation Methodology
Implementation partner uses the traditional process ASAP methodology to implement SAP. ASAP Methodology: (Accelerated SAP). It is a methodology provided by SAP to implement SAP with a predefined series or sequence of steps i.e. what goes first and nest. It consists of 5 steps. 1. Preparation Phase 2. Business Blue Print phase 3. Realization/ Configuration Phase 4. Final Preparation/ Pre Go-Live 5. Go-Live and Support

1) Project Preparation: In this we plan our project and lay the foundation for successful implementation. At this stage that we make the strategic decisions crucial to our project. a) Define project goals and objectives b) Clarify the scope of project implementation c) Define project schedule, budget plan and implementation sequences d) Establish project organization and relevant committees and active resources 2) Business Blue Print: In this phase we create a blue print using the question and answer database (Q & A DB), which documents for enterprise requirements and establishes how our business processes and organizational structure are to be represented in the SAP system. We also define the original project goals and objectives and revise the overall project schedule in this phase. 3) Realization: In this phase we configure the requirements contained in the Business Blue Print. Baseline configuration

(Major Scope) is followed by final configuration (remaining Scope) which can consist of up to four cycles. Other key focal areas of this phase are conducting integration tests and drawing up end user documentation. 4) Final Preparation: In this phase we complete our preparations including testing end user training, system management and cut over activities. We also need to resolve all open issues in this phase. At this stage we need to ensure that all the prerequisites for our system to go live have been fulfilled. 5) Go Live and Support: In this phase we move from a pre production environment to the live system . The most important elements include setting up production support, monitoring system transactions and optimizing overall system performance.


Uses of Solution manager: 1. Maintain the project and its status 2. Documentation of the entire project 3. Generating license keys and upgrade keys 4. Provide the road map for the implementation 5. Configuring satellite systems 6. Early watch alert configuration 7. System monitoring configuration 8. Solution Monitoring 9. Service Desk: To provide customer service 10. Change management 11. It is used to configure, maintenance optimizer to download patches from SAP. Interview Questions: 1. Explain the pre implementation steps 2. Explain the process of Identifying implementation partner at least 20 partners 3. Define SAP implementation methodology in detail 4. Advantages of Solution Manger Roadmap: It is accesses by using transaction rmmain. It provides the complete implementation methodology along with sequence of steps. As a BASIS consultant the first task is to define the hardware infrastructure required for the project such as desktops for the consultants, network band width, software required, remote connectivity (VPN), pc anywhere, internet


connection, e-mail services. Apart from the above the major task is to plan the hardware to implement SAP. Project Charter: Consist of a team i.e. responsible for implementation of SAP project. Customer Project manager: He is absolute owner of the project and responsible for implementing the project from customer end. He needs to track the project status and update the management from time to time. Based on the status of the project he will release the funds to implementing partner. Implementation Project manager: He is used to support the scope of the project and manages all the resources that are required to implement SAP. Business Process Owners: These are involved in owning the respective divisions and responsible for critical decisions in the business. Each division has one owner who owns the responsibility for the business.

Task 1: SAP recommends performing Hardware sizing to define the

hardware required. Hardware Sizing: It is an exercise performed by BASIS consultants with the help of Customer Project Manager, Implementation partner, Project manager and business process owners i.e. the project charter (group of people who decide what to do in the project). Hardware sizing is a SAP proprietary tool to identify the Hardware. SAP provide quicksizer tool to identify the hardware. It is accessed by www.service.sap.com/quicksizing. 1. Use the above URL to navigate to sizing tool 2. It will prompt for USER ID and password. It is also referred as SAP USER ID or SUSER ID Note: It will be a 10 digit ID that starts with S000XXXXXXX and provided by SAP to all SAP customers (i.e. the company who purchases SAP software). We can create as many SUSER IDs as possible for a single customer.


4. Click on the link Quicksizing. It will prompt you to key in your customer number. It will be a 6 digit number. 5. Provide the customer number; specify the name of the project and click on create. 6. The project is created and we need to key in the following information:

1) Customer Information: Name of the Customer, Customer Contact Person, Customer Contact information like Telephone, Fax, email etc This information is required so that Hardware vendors can communicate with customers to submit Quotation for Hardware. 2) Working Time: Normal business time, from what time to what time. The peak hours. Specify the business peak hours Average working days in the year (210- 250 days) or 365 days. 3) Unplanned Downtime: Should be 0% 4) What O/S is along with versions, what DB is required along with versions, what type of Backup is required (Offline, online, partial, incremental). Specify high availability options like mirroring, RAID, Clustering, stand by, disaster recovery, servers are required 5) Network band width in LAN, WAN etc 6) Users: Define the number of users based on modules and specify the (Low, Medium, High) users. Low Users: These are the management who uses the system occasionally i.e. they will try to input 0-480 dialog steps per week for 40 hours Dialog Step: It is an input provided by user along with an enter (Key stroke) or a mouse click.

0-480 dialog steps/ 40 hours= 12 hrs (Dialog steps per day) For 1 hr it will be 60/15=5 min (dialog steps per 5 min) = 300 sec I.e. low users will input his data for every 300 seconds. Medium User: They will generate 480-4800 dialog steps per week or per 40 hrs each dialog step is initialized for every 120 sec High User: They will generate 4800-14400 dialog steps per week or 40 hrs. Each dialog step is initialized for every 10 seconds 7. Save the project with all the inputs and calculate the result. The result is displayed as follows. Note: Sizing is also referred as T-Shirt size. CPU Size: It can be small, large, medium SAPS: Sap applications Ex: CPU Size S No of SAPs 5000 Memory in MB 7869 Disk Category Disk Size in MB XL, S,M,L 586, 889 MB

Note: We need to include the size of legacy system database. SAP Service Market Place: It is an official website of SAP. The URL is www.service.sap.com. It is referred as SAP market place. Official website of SAP targeting various groups of users like Customers, Employees, Partners etc.. It provides various advantages to the customers some of them are

1. SAP Notes: SAP provides a rich set of knowledge base to resolve runtime issues information etc.. Ex: Installation problems, Problems during patch application, resolutions for standard errors. It is accessed by using www.service.sap.com/notes 2. Downloads: We can download software based on customer license My SAPERP 2005 Netweaver 2004 Solution Manager It is accessed by using www.service.sap.com/swdc
3. Hardware Sizing: It is accessed by using www.service.sap.com/sizing

(Quick Sizing Tool). It is used to perform the hardware sizing i.e. required to implement SAP or upgrade SAP solutions. 4. Create Message: For run time issues Help and Support. SAP provides this options to create service message to resolve the runtime problems Earlier it is straight to create a message. But in the current version of market place it will not allow to create a message directly. Instead it provides a search criteria to search the notes and if the error is not resolved then it will allow to create the message. Go to notes/help and support Report a product error customer message 5. Creating License Keys: SAP provides an option to generate license keys for developers, objects, migration keys. License Key: It is required for all the instances that are running on production landscape. Object Key: By default all the SAP objects are locked. In order to modify the SAP standard object we need to obtain key for developers and the object.


Click on SCCR key (SAP Software Change registration). Each developer has to be registered in the website. There is a separate license fee for developers. SAP designed 15 lakh programs or objects on SAP system. Migration Keys: Whenever there is change in O/S or DB of SAP system we required migration keys. 6. Data Administration: It consists of two options System Data User Data System Data is used to maintain the information of all the systems of the customer landscape User data is used to create new market place users and assign passwords.
7. Inst Guides: It is used to download the installation guides and upgrade

guides. www.service.sap.com/instguides
8. Downloading Support Package and Patches: Go to

www.service.sap.com/downloads Select support packages and patches

9. Quick Links: Quick Links are used to identify the options of market place. It is also used to provide the URLs 10. Road Maps: (RMMAIN) It provides series of steps to implement SAP.


Solution Manager
1. Generation License keys/ Upgrade Keys Transaction: solution-Manager or DSWP 2. For Land Scape Creation: SMSY: To generate license key ot configuration of satelite system 3. Monitoring Alerts 4. Service Desk Configuration 5. Maintenance Optimizer 6. Change management License Key/ Upgrade Key: It is mandatory to have license key/ Upgrade

Key to continue with the installation. With out this key no installation based on netweaver (ECC 6.0, EP-7, BI-7, XI-7, CRM 5.0, SRM 5.0) can be continued.
This key is checked during central instance installation. Go to SMSY Go to Systwem landscape Click on other objects Specify the System ID or SID Click on generate key installation or upgrade key Specify system ID, System Number, Message server (Hostname of systme where SAP is installed) Click on Generatge Key. Activity-2: Configuration of Satelite System: Go to SMSY to create satelite system. Satelite systems are SAP systems which can be monitored through sllution manager. Monitoring of SAP system configuration- landscape Go to SMSY where we can create satelite systems manually or using wizard (graphical tool) Start . Go to SMSY System landscape Landscape Components Server Database System System components Right click on system and click on create new system with assistant Specify system short description SAP product Product version Installation number Click on continue Instance 85

Number, Host Name Generate RFC connectivity System Landscape-RFC connectivity(required for each system to be connected) Start select use scenarios Customizing distribution Change request management SAP solmon RFC connection with logon screens Transfer RFC connection outgoing RFC connections Now specify Option, user Id, Pwd Incoming RFC connection Additional RFC connection data RFC connection attributes L:oad balancing Server Group Routing Info Assign RFC connections for system monitoring complete

Activity-3: Assigning logical component to system in the landscape. Go to SMSY Go to system groups and logical component Select the system <SID> and assign the system role to the logical component. (If this is not performed the addressing will be difficult) Activity-4:
Creating solutions Go to solution Manger or DSWP to creqte solutions Click on New Create new solution Povide Soluiton Name, Customer Number, Original Language Continue to creatge the solution select the solution (BASIS Group) This solution is used for solutin manitoring system monitoring, service desk, change management Delivery of SAP services continuous improvement Maintain solution landscape and include the logical component defined in SMSY sustem group Go to solution settings to setup Earlywatch Alerts (EWA) and CCMS monitoring of EWA.

Creating Project: Go to Solar_project_Admin to create a project SAP solmon: Project Administration click on create Provide project Name, Type of Implementation, Landscape: BASIS Group Provide the below details general data scope(Roadmap ASAP ERP) Project team member system landscape milestone OUs Project standards Save the project The above the task done by project manager in preparation phase.


SOLAR01: It is used to create various configuration scenarios that needs to be configured in the project. This is also referred as business blue print. This is used to select the scenarios from the various modules, consultants can upload the docs. Solar1 Business Blue Print change for project Business Blue Print structure BASIS Project OUs, MASTER Data, Business Scenarions (Update documents). SOLAR02: It is used to realise the scenarios that are created in solar1. It is used to configure the scenarios by navigatin to satelite system. SOLAR2: Configuration change for project based Analysing the SIZING Results: The sizing output will provide the memory and storage required directly in megabytes (MBs) considering the growth in transactions values(Business) No.of users and enhancement in modules.We may need to add 30% to 50% to the output results. Apart from the above we also consider the following: 1. Operating System 2. Database 3. Interface to provide connectivity to ohther systems) 4. Printers (Check printing, Barcode to lable printing) Note: We may need to provide the sizing table with various options Note: The sizing will be initially for development system. We need to plan the hardware for production 3 months before going live (To save the maintenenace cost, increase the warranty, Reduce the cost) Note: Always check fo the enhancements and feasibility of the Hardware. Ex: The system should support more memory (Different slots or with multiple slots and HDD) CPU requirement:


SAP does not give you the CPU output directly because the CPU varies based on different manufacturers. Ex: 102 GHz, 3.0 GHz, Dual Core, Quad Core SAPS: SAP provides CPU requirement in SAPS (SAP Application Bench Mark for performance standards). SAP defined benchmarks based on sales and distribution module i.e. for every 2000 sales documents 100 SAPs are required. Depending upon the vendor of CPU it can generate 800 to 2000 SAPs. Let us say output requires around 5000 SAPs then Hardware vendor may recommend 4 CPUs. Ordering the HARDWARE: Once the sizing results are finalized we can call for the quotations from the H/W vendors. Customer Manger and Implementation manager work in this task. Solution Manager can be installed on a 50 GB desktop with 1 GB RAM on 32Bit machine. Depending on the usage of Solution Manger we may need to move to 64-Bit and enhance the RAM. Ordering the SOFTWARE: 1. O/S Software: License and support Note: Most of the cases O/S is provided by H/W vendors 2. DATABASE: Software mostly is provided by SAP 3. SAP Software: We need to buy the SAP S/W through channel partners. There are various types of SAP S/W. Based on customer requirements SAP has its own release for different components. SAP Release Strategy: 1. SAP R/2 2.0 on two tier architecture 2. SAPR/3 3.0 ..3.1g, 3.1 (i) (Released in 1997-1998)

Its strategy 5-1-2 First 5 years of release SAP charges 17% of total software cost.

From 6th year 17+2%=19% of total software cost From 7th and 8th year 17+4%=21% of total software cost. 1997-1998 up to 3.1 i 1998+5=2003 Normal Maintenance 2003+1= 2004 Extended Maintenance 2004+2 2006 Extended Maintenance

2000 4.6c DEC 2006 Maintenance of mainstream end DEC 2007 Additional Maintenance Dec 2008 Additional Maintenance 2003 4.7 EE (Enterprise Edition) 2009 Maintenance of Main Stream Solution Manger: 3.0 2005 April 3.2 2006-2007 4.0 2008 2005 ECC 5.0 (SR1, SR2) 2007 ECC 6.0 (SR1, SR2) 2003 4.7 EE (4.70, 4.71 Extension Set-1, 4.72 Extension Set-2) http://help.sap.com/releasenotes SAP license is based on Number of Users. Each user cost is different from country to country, state to state. It is estimated that each user cost varies from 40,000 to 1,00,000 depending upon the number of users.


Note: After the H/W and S/W order it will take 1 Month to 45 Days to release the Order. This time where we need to prepare various Documents to Install, Configure, moving the known Problems of installation, Product Errors, Strategies for systems, System Landscape, Clients, Transports, User Management, Authorizations, Back Up and Restore and Day to Day activities. Installation Pre Requisites: Download the installation guide from service market place for specific O/S, DB and Sap R/3 Version. Ex: HP UNIX WINDOWS LINUX ORACLE SQL,ORACLE,DB2 SQL,ORACLE,DB2 4.7 EE1, 4.7 EE2, ECC 5.0, ECC 6.0 4.7 EE1, 4.7 EE2, ECC 5.0, ECC 6.0 4.7 EE1, 4.7 EE2, ECC 5.0, ECC 6.0

Read the documentation and document the following: 1. Required Software to0 install the SAP system
2. Download the required software from SAP market place

www.service.sap.com/swdc 3. If you have the software in DVDs copy the software into TEMP directory 4. Check the label.asc in DVD to identify the version and product 5. Find the required Virtual Memory and assign the memory to the system. Virtual Memory: It is the sum of Physical Memory+ The space on the Disk. It is also referred as paging memory or memory on the disk. Note: It is not possible to install the RAM which is required by the system.

On 32-Bit machines we can define up to 4 GB. On 64-Bit machine the minimum SWAP memory will be 20 GB. As a rule Virtual Memory is calculated as 3 times the size of physical memory + 1 GB. Identify the proper JAVA version and download it from www.sun.java.com. It should be JRE (Java Runtime Environment) 1.4.12_2 Install the JRE and set the path as defined in the document. Environment Variables: This provides the run time environment of the S/W i.e. installed on the system. WINDOWS: On windows we need to set JAVA_HOME and Java Bin Path in local variables and Global Variables. Local Variables: These are specific to the logon user. Global Variables: These are applicable to all the users

IF the O/S is not WINDOWS then based on the O/S we may need to set profile parameters in .bash profile or .profile. We can also use command setenv and setpath. Define the Hostname as per the document and company standards. Ex: WillERPDEV/WillBIWDEV The HOST NAME should not be more than 13 characters. Get the Static IP address from the system administrator which should start from either 172 or 10, where as 192 is used for Testing and 127 is used for loop back etc as per the INA (International Network) standards. Define the System ID (SID). SID is a three character alphanumeric string and the first characters must be a character and the remaining two can be either a number or a character. Ex: R60, DEV, RS1 There should not be any special characters in the system identifier.

There should not be any duplicate SID in the landscape The SID name should be meaningful to identify the system in the landscape based on the PRODUCT, LOCATION, Roll in the landscape. Note: Dont use reserved key words like SAP, BIW, SCM,SRM< ERP, All etc Provide the entry in host file i.e. etc\hosts which is located in windows\system32\drivers\etc\hosts Download the known problems related to installation of this particular component. Identify the OS version and patches to install. Identify the DB and patches to install. R/3 4.6 C 4.6 BASIS (BASIS system)




WEBAS 620 (4.6c web functionality became WEBAS 620)

ECC 5.0 6.40 /

ECC 6.0 7.10

Installation Types:
Installation of SAP up to version 4.6 C is performed by R3 setup. R3 Setup: It is not dependent on any other component once the inputs are keyed we cannot change the inputs and restart from the scratch. It is not an interactive tool. This tool is used to install BASIS components only i.e. 4.6 C and below. SAPINST is used from version 4.7 Enterprise Edition. But the components need to be installed separately i.e. Central instance, Database instance, Dialog instance.

SAPINST Requires JRE because the installation executables are programmed using JAVA (SAPINST.CMD). Different passwords for different users are created during installations. There is no provision to change keyed Inputs. This is valid only for WEBAS 620 (4.7 EE, 4.7 EE SR1, 4.7 EE SR2). It is also not interactive. SAPINST.EXE (./sapinst): From 640 version onwards JAVA dependent, color full option to change the inputs at the end single password with minimal inputs. SAP COMPONENT 4.6 C 4.7 5.0 ECC 6.0 SR1 ECC 6.0 SR2 SOLMOM 3.2 SOLMOM 4.0 XI 3.0 XI 7.0 BIW 3.5 BI 7.0 EP 6.0 EP 7.0 BASIS 4.6 C /4.6 D 620 640 700 700 640 700 640 700 640 700 640 700

Installation: Central Instance Installation: It provides a typical installation with minimal inputs where Central Instance and database instance are installed together. INSTANCE: It is an application server which has its own resources or shared resources (Memory, CPU, and HDD)


Distributed Installation: In this installation the Central Instance and Database Instance are installed separately High Availability: It is used to install clustered systems on Node-A and Node-B. Installation Inputs: (Central instance) Select the SAPINST for the specified OS i.e. navigate to the folder i.e. related to your OS Select the component that is going to be installed Ex: SAP ERP 2004, SAP ERP 2005, SRM, CRM\ Select the Database Ex: DB2, SAPDB, MS-SQL Server, Oracle Select the type of installation (Central Instance, Distributed, High Availability) Specify wither typical or custom installation Note: While installing database use SAP customized Batch Files or Script files defined by SAP. Dont use the native setups of database. The advantage of using SAP script is to set the environment variables that are required for SAP. For Oracle use SAPServer.cmd and for Dialog Instance use SAPClient.cmd. For SQL Server use script SQL4SAP.vbs On UNIX environment the Data Base has to be installed during Database Instance Installation or after Central Instance installation. Database is not required for windows operating system. Select either UNICODE or NON UNICODE UNICODE: It supports around 90.000 characters to support all most all available languages in the world. UNICODE consumes 40% more resources than NON UNICODE Select the Central Instance and specify SID

Specify the Instance Number Instance Number: It is a two digit number that varies from 00 to 99 but only 00 to 97 are used, 98 and 99 are used/ reserved for routing purpose Specify the Database ID and Database Host Specify the Amount of RAM i.e. to be used during installation. It used 60% of memory Specify the type of Installation either local or in the domain or in the domain of the user that user has necessary privileges to create users, services, groups and assign to groups Specify the TRANSHOST directory i.e. to install the executable path Specify the Database Home i.e. the oracle executable path Specify the schema Id (database Schema). In earlier versions of DB we need to install DB for each SAP component. The confusion arises while handling multiple homes from ORACLE 9i on wards. (MS SQL 2000) are supporting MCOD i.e. Multiple components on single Database with different SIDs which means that the schema Id should be different for each component. Specify the password for SAP system Administrator (USER ID) i.e. SAPADM (SRMADM, DEVADM). He is the owner for entire R/3 system. Specify the password for SAPServiceAdministrator. The User Id is SAPService<SID> Ex: SAPServiceSRM Specify the path of KERNEl DVD Specify the ports 1. Message Server Port: 3600+ <Instance Number> 2. GateWay port: 3300+ <Instance Number> 3. Dispatcher Port: 3200+<Instance Number>

4. Dispatcher Security Port: 4700+<Instance Number> 5. GateWay Security Port: 4800+<Instance Number> Start The installation

DB Instance Installation:
Once CI is installed select Database Instance to install Select DB instance Specify the SID Select standard installation. Other Options like System Copy is used to setup the system from the existing system Decide on MCOD. Select the option Install SAO system in the DB (first Time) choose the second option if the DB exists Specify the Instnace Number Specify the Memory (RAM). During database installation it take 40% Specify the TRANSHOST directory Specify the Passwords for SIDADM and SAPServiceSID Specify the location for DB server directories Specify the location for Redo log files Specify the path of Kernel directory and Export Directories Specify the path for Data File Note: DB Server directory include the following 1. SAPBACKUP 2. SAP ARCH 3. ORAARCH 4. SAPREORG 5. SAPCHECK

6. SAPTRACE Data Directories Includes the following: 1. SAPDATA1 2. SAPDATA2 3. SAPDATA3 4. SAPDATA4 5. SAPDATA5 6. SAPDATA6 In ECC 6.0 the installation inputs are reduced. 1. Use Installation Master (IM) and click on SAPINST.EXE 2. Select the usage type (ABAP, JAVA, BI, PI, MI, EP etc..) ABAP is mandatory to select 3. Specify SID. Specify installation location (Drive) / oracle 4. Specify the password i.e. master password for all the users that are going to be created during installation 5. Specify the DB instance location 6. Specify Kernel path and database export 7. Specify path to install the data files 8. It displays the lost of inputs to review 9. Review the inputs if required and continue to start the installation Installing the Dialog Instance: Dialog instance is required to handle the additional load on the C.I 1. Click on additional life cycle task. Select Application Server and select the dialog instance 2. Specify the SID and Instance Number 3. Specify the path of profile directory

4. Specify the password 5. Specify the location of Kernel directory and continue to install dialog instance Installation of SAP GUI: SAP recommends the higher version of GUI to be installed to connect to SAP SYSTEM Current version of GUI is 7.10 (700, 640, 620, 4.6 D, 4.6 C etc) Pre Implementation: 1. Feasibility Report 2. RFQ 3. RFI 4. RFP 5. Installation IDES system 6. Solution Manger 7. ASAP Methodology

Installation Logs:
Central Instance: Control.xml: It consists of installation steps that are executed one by one. Keydb.xml: It will give you where the installation steps need to be start (Continue with old installation) Check for environment variables Check for privileges of the user who is going to install the SAP S/W. Contol.xml gets the details from DVD or DUMP and write the installation steps in keydb.xml. When the installation is restarted it

reads from keydb.xml to continue the installation where it is aborted. Set Environment for users Create users (<SID>ADM, SAPService<SID>) Create groups (SAP_localAdmin, SAP_<SID>_Admin, SAP_<SID>_GlobalAdmin, SAP_<SID>_localAdmin) Assign groups to users <SID>ADM: It is the owner of R/3 system (Administrator) SAPService<SID>: It is the owner to run the services when the system is started and ensure that password never expires (Back Ground service user) Groups: SAP_LocalAdmin: To administer the system locally and to own the usr/sap directory SAP_<SID>_Global Admin & SAP_<SID>_LocalAdmin: These groups are created to provide access to instance specific and they are used when multiple <SID> are in one system. Creating usr directory where the SAP profile parameters are installed SAPinst creates shared mounts SAPmnt and SAPloc to access by other systems in the landscape SAPinst extracts executables in to RUN directory. But from ECC 6.0 exe/nuc/NTI386 or exe/uc/NTI386

Create services and run the services SAPoscol and SAP<SID>_<INR> SAPoscol: It is an operating system collector SAP<SID>_<INR> It is an instance specific service to run the SAP. It is based on SAPstartsrv.exe


Database Instance: It checks for the users and passwords of <SID>ADM and SAPService<SID> users Extracts database dependent executable into RUN directory Creates the database Creates the table spaces Loads the data i.e. import data from Export DVDs How to load the DATA: As we cant load the data sequentially (It is time consuming) we will load the data based on table type. SAP Defined: It provides command files that are split based on the version. These command files control the loads. These are nothing but (2 running, 3 Completed, 9 waiting and Failed 0) Each command file is related to a task file i.e. .tsk file. Each task file gets the size from .tpl file and gets the structure from, .str file and table of contents from TOC file. Process of Loading: Each task file consists of the Tables, Index View, Pkey etc to be created. T-table, D-data index, p-primarykey. Each task file when it is going to run state it is copied to a .tsk.bak file. The load happens from .bak file. When the table is created or loaded an entry is made into .tsk file with status (OK). If it could not be loaded then the status will be (err) and we can see if it is failed in SAPint GUI (Failed) Post Installation Activities: Check the consistency of the installation by using transaction SICK. It checks the consistency between O/S and its patches, DB and its patches and R/3 and its patches (Kernel Path). Based on the errors we may need to update OS, DB patches and R/3 patches Lock all the known users and passwords in all the clients

For Sap* login/no_automaticuser_sapstar=1 Create two super users. One should be sealed and kept by the project manger and other one is used by BASIS consultant Initialize Change and Transport system or Correction Transport System (CTS). For this Go to SE06 9System Engineering) and select the standard installation and perform Post Installation Actions. It will prompt to configure TMS. It will reset Transport management System System settings as per role of the system in the landscape we need to set whether it is MODIFIABLE or NOT MODIFIABLE. Go to SE03 and click on system change option. MODIFIABLE: The objects are allowed to modify in the system. Using this option we can modify objects and we can restrict some objects. This is set for Development System only. Occasionally we may set this option for Quality System, but never in the production system. Modifiable means the system is modified in terms of Repository Objects 9SAP standard objects), tables, programs, transactions etc.. NOT MODIFIABLE: This option is set to production and none of the objects are modified. If you change accidentally in the production system it is tracked in the auditing and you will be questions for the reason we may need to pay damages if it is set modifiable without approve from authorized customers. These are called as System Change Options (Modifiable & Non Modifiable) Configuring TMS in Client 000: Transport Strategy: We have to define this strategy to ensure that the objects are developed in one system and moved on to other system for quality testing and finally to production. Configure TMS: The transport strategy has to be configured in 000 client with user i.e. copied from DDIC. Ensure that two Background work processes are defined in the system.

Go to STMS A pop up window is displayed to configure Transport Domain Controlled (TDC) Domain Controller: Commands the other systems in the land scape. TDC: It is a domain controller to control all the systems in the landscape. It is used to manage all the transport parameters in the landscape. In most of the environments there will be only one Domain Controller. POP UP Window: It provides two options one is to configure Transport Domain and other is to configure Member systems. While configuring transport domain provide the name of the transport domain i.e. DOMAIN_SID and description save the transport domain. Include system in Transport Domain: Select the option next to SAVE icon provide HOSTNAME and SYSTEM number to include the system in the landscape Backup Domain Controller: IN case of TDC failure BDC will take over. STMS Overview Select System Select the system that needs to be configured as BDC Go to Communication TAB Specify the BDC system and click on save. Include Systems in the Domain: When you include systems in the diamond a request is sent to Domain Controller. To include in the domain logon to Domain Controller Go to Overview Systems Select the system and click on Approve. RFC destinations are created with a Communication User TMSADM. Create Virtual System: As the other systems of the landscape are not included we are creating Virtual Systems. Virtual Systems are required to address the objects that are created in development system. If the virtual systems are not defined we need to address manually which is a time consuming process.

STMS Overview systems SAP systems create virtual system. Defining the Landscape: Go to STMS Overview Transport Routes Go to Configuration in Change Mode Select standard configuration Save. Landscape Strategy: The arrangement of systems in an order to display the flow of objects in the landscape. System: The system is a physical entity where certain activities are carried in the landscape Development System: It is referred as DEV but one can use their own naming convention. It is used to develop the objects in the landscape. It is only the system where development activities are carried out. The system settings are set to Modified. Quality System: It is used to test the objects for load and stress that are developed in development system. The system settings are set to "Not Modifiable. If the object fails to test it needs to be modified again in the development system is tested again in the development system. Dont move the objects to production system until they are successfully tested. Production System: The objects which are approved in the testing system will be moved to the production system. System settings are set to Not Modifiable. If any object is found fault it has to route from Development System again. Apart from the above we can have the following systems in the landscape 1. SAND BOX 2. PRE PRODUCTION 3. TRAINING 4. PAY ROLL.. Types of Landscapes: 1. Single System Landscape 2. Two System Landscape

3. Three System landscape 4. Multi System Landscape 5. Other Systems in the landscape SYSTEM: It is a physical entity which is installed with the following components The /usr directory The usr directory consists of: 1. TRANS directory 2. Executables Directory exe 3. Profile Directory 4. The system is represented by an Instance. i.e. the Directory DVEBMGS <Instance_Number>.

/usr Directory (OS Level) Screens, Programs, Reports, Functional Modules, Menus, Transactions (DATABASE LEVEL) BASIS LAYER

Repository: Collection of Data (Programs, Transactions, Screens, Menus, Functional Modules) Repository Objects (A-X): The objects with name preceded by any letter of this range are called as standard objects and repository objects and are developed by SAP. All the Repository objects are stored in the table TADIR. SAP recommends not to modify any of the Repository objects. SAP in turn recommends to develop your own objects in customer name space Y-Z alternatively with in defined our own objects using Company Name.


Y-Z: Developer can create their own objects with the name starting with Y-Z and this will not disturb the standard or repository objects.

Cross Client Customizing: Customizing: It is the process of keying entries in to the table without changing the basic structure of the system. Ex: measurements, Country, Currency, Time settings etc Support Backup

EWA 066 001 000


Cross Client Customizing

Standard Objects or Repository

Client: A Client is an independent business entity that represents a company or business. Client has its own User Master Data, Application Data and Customizing Data. Client Specific Customizing
Client 001 Strategy 000 EWA 066

Backup Client



Cross Client Customizing 105 (C.C.C) Programs, Transactions,

DD02L: It is a table which contains all SAP tables. SM01: List of transactions SM02: System Message Functional Module: It is the logic behind the screen. System: It consists of repository Objects, Cross Client Objects, and Client Specific Objects. 9User Master Data, Application Data, Customizing Data).

Single System Landscape: There will be only one system in the

landscape i.e. used for Development, Quality and Production System. It is recommended for Demo purpose and never used for production because the Development, Quality and Production activities takes place in the same system. In Single System landscape the Inconsistency and Conflicts will arise in the objects.
DEV 001 QAS PRD 000 EWA 066

Cross Client Customizing

Standard Objects or Repository


Two System Landscape: It is least recommended landscape by SAP where Development and Quality activities are performed in one system and production activities are on the other system. Disadvantages: The repository and cross client objects still share by development and quality system. So there will be inconsistency and the objects are used either by developers and quality people.

DEV 001

QAS 000

EWA 066

PRD 001 000

EWA 066

Cross Client Customizing

Cross Client Customizing

Standard Objects or Repository


Standard Objects or Repository

Consolidation Root Production

Three System Landscape: This is most optimized landscape recommended by SAP where Development, Quality and Production activities are performed in three different systems. Z<SID>
DEV 001 000 EWA 066 QAS EWA 066 000 001 PRD EWA 066 000 001

Cross Client Customizing Standard Objects or

Cross Client Customizing Standard Objects or

Cross Client Customizing Standard Objects or


Consolidation Root Root THREE SYSTEM LANDSCAPE


Multi System Landscape:















EUROPE In a multi system landscape the development (object) is performed at off sore (Common Development Environment) and the objects are transported


onto different landscapes. Geographically the objects are customized locally according to local customize settings (Measurements, Time Tax etc) Other Systems in Landscape: Apart from the three system landscape SAP also allows to include the following systems in the landscape. 1. Testing 2. Sand Box 3. Training 4. Pre Production System 5 Pay Roll or Migration system

Note: SAP allows 8 systems in the landscape for a single installation number.
Applying License: Each system needs to be applied license so that runtime issues are resolved by SAP. Go to Transaction slicense The license key depends upon Hardware key o f the machine and installation number. In earlier versions where this T-Code is not available use command suplicnese-get to get the hardware key. Note: Hardware varies depending upon the O/S. Ex: 32-Bit, 6t4-Bit O/S and SAP component Go to market place with authorization to generate license keys and click on the tab license keys Click on the option request license key select the installation number provide the following details: 1. System ID 2. Host Name 3. INR (Instance Number) 4. OS 5. H/W key

6. Data Base Now SAVE the information to generate the license key. Normally license generation will take around 1 hour. The license key can be downloaded from the same screen. Alternatively SAP also sends over the Email. The license key is a number of 24 digits but now SAP is sending the license by encrypting in the text format. License can be installed in Two Types: Click on Install New License Specify the Instance Number System Number and Key Click on New License and specify the path of the text file.

User Master Data Application Data Company

400 300 200 EWA 066 001 000

400 200

EWA 066 000 001


EWA 066 000 001

Cross Client Customizing Standard Objects or

Cross Client Customizing Standard Objects or

Cross Client Customizing Standard Objects or

When the system is installed it can be accessed with 000, 001 and 066 clients. Client: A client is an individual business entity or a company having its own User Master data, Application Data and Customizing Data. Client is represented by a Field MANDT in the database. The tables with fields MANDT are called as Client specific tables.

Client field MNADT is a data separator i.e. the users needs to specify the client number to logon to the client specific data. 000 Client: It is a default client or template client which is provided by SAP. No changes are allowed in this client. As this client is SAP client it is commonly updated by applying Support Packages, Patches, Add-ons and languages etc.. It is used to setup Transport Management System (TMS) and run Standard Jobs. No customizing data, Application Data and User Master Data (Except for the Super Users) is allowed. 001 Client: It is a backup client for 000 client as per initial plans of SAP. But 000 is continuously updated where as 001 is not. So the purpose is deviated in the current versions like SOLMON, NETWEAVER systems. 001 is considered as production client. 066 Client: Early watch client. It is used by SAP to logon remotely and generate Early Watch Alerts. As per SLA (Service Level Agreement) SAP sends two early watch reports per annum.

Client Creation: As the standard clients provided by SAP are not used for production use we need to create our own clients and define client roles Clients are displayed, created and modified in the transaction SCC4. Go to SCC4 Click on New Entries Specify the Client Number Add description Save. Client Number: it is a3 digit ID which varies from 000 to 999 which means all together we can create 1000 client s in SAP. Client is represented by Field MANDT in the database. Note: The clients are available in the table T000. This is the only Cross Client Table with the MANDT field. Click on New Entries and specify the name of the clients, specify the client numbers specify the name of the city. Logical System:


This is used to differentiate between clients in the landscape. Logical systems are created in transaction SALE. SALE: System application linking and Enabling. SALE is used to define the logical systems that are used for communicating or transferring data. Systems are using naming convention. Ex: DEVCLNT555, QASCLNT555, PRDCLNT555 Note: Do not try to change the logical system name. Once it is assigned to a client. In order to change logical system i.e. assigned to a client use transaction BDLS. This BDLS transaction is generally used after performing a SYSTEM COPY from production system.


EWA 066 000 001


EWA 066 000 001

Cross Client Customizing Standard Objects or

QASCLNT000 PRDCLNT000 Client Copy

Cross Client Customizing Standard Objects or

PRDCLNT000 to QASCLNT000 (We need to change) Go to SAVE Go to BASIC settings Select logical system Define logical system Click on New Entry Specify logical system name (QASCLNT000) Click on SAVE

It will prompt you to create a change request Specify the logical system name Select the logical system name Select the currency Specify the client Role Client Role: It specifies the role of the client in the landscape. There are various client roles defining the implementation. Development System: In the system landscape development system the first client i.e. going to be created as Master Client, Parent Client, Golden Client. It is represented by CUST i.e. customizing role. This is only the client in the landscape where changes are made. The changes in the landscape will be carry forwarded to other clients in the landscape. No changes are allowed in other clients. Changes and Transport for Client Specific Objects : 1. Changes without automatic recording 2. Automatic Recording of Changes 3. No changes allowed 4. Changes without Automatic Recording, No transports allowed Cross Client Object Changes: 1. Changes to repository and cross client customizing allowed. 2. No changes to cross client customizing objects 3. NO changes to repository objects 4. No changes to repository and cross client customizing Protection Client Copier Tool and Comparison Tool: Protection Level 0: No restriction Protection Level 1: NO over writing Protection Level 2: No over writing and No external availability CATT and eCATT restrictions: eCATT and CATT not allowed


eCATT and CATT allowed eCATT and CATT allowed only for trusted RFC eCATT allowed but FUN/ABAP and CATT not allowed eCATT allowed but FUN/ABAP and CATT only for trusted RFC. Restrictions: Locked due to client copy Protection against SAP upgrade Cross Client Customizing: Changes to Repository and Cross Client customizing allowed: In this particular client the changes made to cross client and repository objects is allowed Changes only to repository Objects: Repository objects only can be modified. DEV: Client CUST TEST SAND QAS: Client CUST TEST SAND C.S NO NO NO CCC & REP NO NO NO Protection 2 2 2 C.S ARC CWR CWRT CCC & REP YES NO NO Protection 0 1 1



Protection 2

CS Client Specific CCC Cross Client Customizing REP Repository Objects Protection Protection Level Protection Level: Level-0: No restriction i.e. no restriction. This client is allowed for over writing and available for client copy Level-1: No overwriting i.e. the client is not allowed to be over written by other client Level-2: This option is provided to not to allow client copy and client comparison Note: Based on requirements we may need to change this protection level and cross client object changes even in the production system. Note: Dont try to change these options of preproduction and production without approval. Changes to these tables are logged with Data and Time along with User Name. Ensure that necessary approvals are obtained from the customer to change the client settings. eCATT and CATT not allowed: It is used to upload the data into the system. We need to specify whether they are allowed or not. Depending upon the requirement we may allow or disallow all the clients. But in production client it should be set to not allowed.

Test Client: It is used to test the scenarios that are configures in CUST client. Changes are moved from CUST to TEST using transaction SCC1. SAND CLIENT: It is used to configure the scenarios based on customer requirement. It will serve as a play ground environment. For the consultants no changes are carry forwarded.


QTST Client: This client issued for integration testing and consolidation testing. Changes that re made in CUST client are transported to QTST client. (Tools like mercury, ecatt are used to test the integration between modules along with stress and load testing). TRNG Client: It is used to training end users before they work on the production system. MIGE and Prep (pay roll): These are optional clients that are created based on requirement. Migration client is used to migrate the data from legacy system. Preproduction client is used to check the behavior of changes before they work. Payroll Client: As we cant run the pay roll on the production system (Test Payroll n-number of times) payroll client is created and it is run at various frequencies. Prod Client: It is used by the end user to perform the business. It is more critical client and no other system in the landscape is allowed to carry the business.


Pre Requisites of Client Copy: 1. Switch off active log files. 2. There should be enough space in the database. For this execute RSSPACECHECK and RS1TABLESIZE to identify the space and memory requirement. 3. Choose 000 client for initial client copies. However business clients are also allowed for client copy based on protection level. 4. To perform client copy always login into Target Client and copy the data from Source Client. 5. Client copy consumes time, so schedule in the background 6. Choose Profile to specify the data to be copied from source client (Application Data, User master Data, Customizing) Ex: SAP_ALL, SAP_USER, SAP_CUST, SAP_APPL 7. Define RFC destination between two systems to perform Remote Client Copy 8. Check the space in TRANS directory to perform client export. 9. Perform a TEST RUN before actual client copy 10. Client copy logs are displayed in Transaction SM37/ SCC3. 11. It is not recommended to login to source client and modify the objects during the client copy. 12. During client copy the number of tables does not increase. Only the entries in the table increases under the entry MANDT. 13. Remote client copy has to be performed between same systems (Same Version, Same Patch Levels) not possible for different R/3 system. If DB tables having field MANDT then these are specific to client. If there is no MANDT field in the tables these are shared tables for all clients. Desc SAPDEV.usr02 (Describe DB tables) Cross Client is shared by all users.

Select MANDT , Count (*) from SAPDEV.usr02 group by mandt; Select count (*) form SAPDEV.usr02; Select count(*) from sapdev.tbdls; Select count (*) from sapdev.tadir; Select BNAME from SAPDEV.usro2 where MANDT=800; Select * from SAPDEV.usr02 where MANDT=789; Select MANDT form DEV.T000; Local Client Copy: It is performed between two clients with in the same system. 1. Create a client (SCC4 for create client) and logon to the target client 2. Go to Transaction SCCL 3. Select Source Client 4. Select Test Run to check the source 5. Select Profile 6. Select start immediately and schedule in background 7. Go to SCC3 to check the logs (To monitor the client copy process) Remote Client Copy: It is performed between two clients with in two different systems in the landscape 1. Create a client 2. Go to SCC9 of the target system 3. Specify the profile 4. Specify the RFC destination 5. Start in the background mode. However we can start immediately Client Export and Import:

It is used to perform the client copy between the systems which are not in the landscape It is performed in 3 steps. 1. Client Export: Use Transaction SCC8 to export the client to O/S level. This process generates transport requests in the \usr\sap\trans directory. 2. Copy the files to target system and import them using FTP and transaction STMS 3. Client Import: Go to Transaction SCC7 and perform client import Based on client export profile KX, KO, KT files are created in \usr\sap\trans\cofiles and RX, RO, RT files are created in \usr\sap\trans\data directory. KO, KX,KT are called as cofiles or control files Ro, RX, RT are called as Data Files Copy the files using FTP\normal copy\DVD into target system \usr\sap\trans\cofiles and \usr\sap\trans\data directories. Go to STMS. Add the request and Import Go to SCC7 to perform post client Import activities Standard Clients

000 (Template) 066 (Early watch)

001 (Backup Client) Clients



Migration/ Legacy






Client Deletion: SCC4: Delete the entry from table T000. SCC5: Permanent Deletion To lock and unlock a client: Go to SE37 Reports: The following reports can be used to lock and unlick the clients. Sccr_lock_client- lock client Sccr_unlock_client- unlock client Note: Profile SAP_CUST is used initially to setup Golden Client but later this golden client can be used as a source client to copy to another client with other peofiles. Client Deletion: Clients are deleted using SCC5. But they cannot leave any space in the Database i.e. by deleting a client we cannot get any free space in the database. We need to reorganize the database. Locking and Unlocking Clients: Use these two reports to lock and unlock the clients. SCCR_LOCK_CLIENT and SCCR_UNLOCK_CLIENT (or) we can manually use tp to lock clients. Use transaction SE37 for lock and unlock clients. Client Comparison: While applying client specific patches i.e. CIN(Country India Version) use transaction SCMP to compare between two clients and to adjust the changes between two clients. Setting up Library: I order to get the screen context help we need to install the library and setup in SR13. Install the library from library DVD. In the shared folder Sap help.

Go to SR13 to set up the library There are four types of libraries available 1. HTML Helo 2. Dynamic Help 3. Plain HTML Help 4. HTML HTTP Help. F1-Field Help F4-Field Possible Value Help HTML Help: It occupies lesser space when compared to other library formats. It is viewed using micro soft help viewer. It is in the compressed format. Plain HTML: It is installed on the file serve and help is displayed in the HTML format. HTML HTTP: It is installed on the web server and requires web browser to execute. Click on New Entries and provide the Following Details: 1. Name of the O/S 2. Variant 3. Training 4. Path of the library up to help data drive directory 5. Specify the language 6. Select the default check box 7. Save the entries

Scheduling House Keeping Background Job: Go to SM36 click on Housekeeping jobs and schedule with default variants


Importing Profiles: RZ10 It is used to set the parameters for Work processes, Memory, Buffers etc Go to RZ10Utilities Select Import Profiles of Active Server DB13: Schedule an offline Backup so that we can test the Backup mechanism Scheduling Database House Keeping Jobs: Select check and verify database optimizer statistics, Adopt extents etc Go to DB13 Select the Date It displays all the above tasks. Select each of them and schedule with different times. Operation Modes: These are used to adjust the Work Process between Dialog and Background work processes. Use transaction RZ04 and SM63 to configure Operation Modes. Note: Ensure that the systems configured to solution Manger to configure the business scenarios as per the project plan. SMSY, Solar1, solar2, Solar_project_admin Applying Support Packages: Go to Transaction SPAM Creating Users: Create users and assign SAP_ALL, SAP_NEW (Take out the critical Transactions like SU01, RZ10, RZ03, PFCG etc)


Customizing: This is a process of modifying the system according to the requirements of the customer. This is performed in the transaction SPRO. (SAP project customizing). This is the process of keying the entries into the table. Customizing consists of the Following: 1. Crating Company 2. Crating Country 3. Crate Currencies, Measurements, Time Settings etc For example below are some of the customizations that we will do indifferent modules: FI: We create Vendors, Customers, Cost Centers, Account Receivables, Payables, banks, Tax, Asset management, Description etc SALES: Sales Organizations, Sales Divisions, Sales Areas, Distribution Channels, Billing, Shipping etc MM: Purchasing, organizations, Inventory, Stores, Plants, Storage locations, Ware Houses, Goods, Invoice etc Exits or User Exits or Customer Enhancements: It provides additional functionality to the SAP system. Exits can be searched. Transaction SMOD (Search Modifications) and CMOD (Create Modifications) are used to create the modifications. There are various types of exits: 1. Field Exit 2. Screen Exit 3. Menu Exit 4. Function Module Exit The exits are identified by Functional consultants and logic is programmed by developers.

Support Packages, patches and Notes: Support Packages are provided by SAP to provide the bug fixes, functional enhancements and resolve run time issues.

If the customer requirements are not satisfied then we may need to develop the Programs, Reports, Transactions, Menus, Screens, Scripts and Functional Modules. Programs and Reports: All the customer objects has to be created in customer name space. /Company name/ (or) Y-Z in order to create programs the developer needs to register in the market place (developer License are charged separately). Create user in SU01 and register this user in the market place. Get developers and key in the registration key before developing or modifying first program. It will not prompt for the key later programs. Programs are created, modified and displayed in Transaction SE38. Transaction: It provides an easy way to navigate to the program. Go to Transaction SE93 and create a transaction using the above created programs. Provide Program Name and Screen Number to define a Transaction in the customer name space. MENU: Menus are defined in Transaction SE41. SCREEN: Screens are designed in the transaction SE51. Scripts or Forms: These are available in SE71 and can be modified by copying in to customer name space. Ex: PO script, Invoice, Delivery Order, Quotation, Sales etc Function Modules: These are used in the programs for modularization i.e. frequently and logis is turned in to functional Modules. Domain: It is the least granular field in database which has its types and property like Data Type and Size. It is created in transaction SE11.

It is used to keep the fields uniquely in the database i.e. all the location follow the same format. It is a field in the database like Location, name, Currency etc It specifies type and Length. Data Element: It is also defined in SE11 but it is specific to a field pointing to a domain. It is nothing but domain with a meaningful name. Ex: District- Location, City- Location, Country-Location, State-Location TABLE: It consists of ROWS and COLUMNS. Columns are Data Elements and ROWS consists of Data. Screen & Menus: SE51, SE64 Transaction: SE93 Program: SE38 Data Element: SE11 Domain: SE11 Table: SE11 Changing the Standard Objects: SAP mostly never recommends modifying the standard objects in the name space A-X. However based on the requirements customer may change the objects by obtaining Access Key from SAP. These Keys are also referred as SCCR key. 9SAP software change registration key) When you modify a standard program in SE38 it will prompt for Developer Key and Access Key. Get the program Id, Object Id and Object Names. Get the above details to generate an access key from the market place Generate the key only based on the approval. As we are changing the standard programs the changes will be lost after an upgrade.

Customizing Requests or Modified Data can be copied from one client to another client, where as workbench requests.

400 000




Cross Client Customizing Standard Objects or Repository Objects

Customizing Request

400 000




400 000




Cross Client Customizing

Cross Client Customizing

Standard Objects or Repository Objects


Standard Objects or Repository Objects



Workbench Request

Create super user. Dont use DDIC to perform any of the following activities 1. Check SCC4 settings client and check whether it is set to ARC (IF it is ARC we can perform client specific customizing and record the changes) 2. Go to SPRO. Click on SAP REFERENCE Img (Implementation) Click on Enterprise Structure Click on Definition Click on Company- Click on New Entry Create a Company Copying one client to another client is a BASIS consultant task. When a client specific entries are Created/ Modified/ Deleted it prompts to assign the changes to a change request of type customizing When a cross client or Repository entries are Created/ Modified/ Deleted it prompts to assign the change to a work bench request of type workbench. Go to SE01 to Create/ Replace change Request. Change Request consists of changes that are recorded during customizing Change request are created by Project Leaders and assigned to Team Members in the form of Task Each change request may consists of one or more tasks Once the task is assigned to a user only that user can work on that task

Change Requests are in the form of <SID>K900000 and start with 1 and subsequently it Will change.

Right Click on change request and click on Add User (Super User, Admin etc..) User has to release o Admin has to release the task Change Request can only be released when all the subsequent tasks are released Please perform client coy using SAP_CUST profile before you start customizing. 36687663221261278694 for IDES system SSCR key




SAP BASIS Administration Tutorial prepared by Shastry. This will help in understanding and answering different questions and asked in different interviews. During the requirements analysis phase the BASIS consultants along with team members (Functional Consultants, Project mangers) visits the customer and gathers the requirements and analyzes the requirements to define the scope of thee work. Scope of Work: (SOW) It is the estimated work which is documented during the requirements analysis phase. It defines the following:

What type of O/S What type of database Reusing the existing infrastructure (Ex: Data Center servers) Analyze the servers and submit the feasibility report (This consists of server details like CPU, RAM, Storage, and Warranty) What kind of backup customer is looking for?
Types of backups are: 1. Online backup 2. Offline backup 3. Incremental backup 4. Partial backup 1. Online backup: The system continuously work and wont be shut down. Users cannot get any interruption while performing backup

What are the production hours & define peak times and off peak hours If it is 7*24*365 then what kind of High Availability customer is looking for?
High Availability: it is defined as the availability of servers in the data center to continue the user accesses without any business interruption. There are 2 types of Availabilities: 130

1) System Availability: The system is available and the server is available but users may not connect to the system or experience very low performance. 2) Business Availability: While planning high availability we need to ensure that business operations continue without any interruption.

2. Offline Backup: Offline backup is a way to store files from a network so that they will be
accessible even when the user is not connected to the network they are stored on. It is a beneficial feature to users who often rely on telecommuting with portable computers or mobile devices and who therefore are not always in direct contact with the network they typically access files from. Offline backup is used as a safety precaution because it is not available for updating, so it remains as an untouched copy of a file at the time it is saved or copied offline. Saving a file or folder into offline backup will ensure that there is a copy of the file that is available for being referenced, should an error occur with the network or if the system were to crash. Because of this, many users depend on offline backup for peace of mind in the home or in the workplace. Many businesses uses offline backup to store files so that they are unchanged and easily referenced.

3. Incremental Backup: Incremental backup provides a faster method of backing up

data than repeatedly running full backups. During an incremental backup only the files changed since the most recent backup are included. That is where it gets its name: each backup is an increment since the most recent backup. The time it takes to execute the backup may be a fraction of the time it takes to perform a full backup . Backup4all uses the information it has recorded in its catalog file (.bkc ) to determine whether each file has changed since the most recent backup. The advantage of lower backup times comes with a price: increased restore time. When restoring from incremental backup, you need the most recent full backup as well as EVERY incremental backup you've made since the last full backup. For example, if you did a full backup on Friday and incrementals on Monday, Tuesday and Wednesday, and the PC crashes Thursday morning, you would need all four backup container files: Friday's full backup plus the incremental backup for Monday, Tuesday and Wednesday. As a comparison, if you had done differential backup on Monday, Tuesday and Wednesday, then to restore on Thursday morning you'd only need Friday's full backup plus Wednesday's differential.


Advantages: 1. Backing up is the fastest 2. The storage space requirements are the lowest Disadvantages: 1. Restore is the slowest

4. Partial backup: A partial backup resembles a full database backup, but a partial backup
does not contain all the filegroups. Instead, a partial backup contains all the data in the primary filegroup, every read/write filegroup, and any optionally-specified read-only files. Partial backups are useful whenever you want to exclude read-only filegroups. A partial backup of a read-only database contains only the primary filegroup.

We need to define the amount of time the business can sustain without the system. This is called as percentage f high availability. High availability options:

1. Clustering 2. Standby servers

High availability options needs to be discussed with the hardware vendor and the customer.

If the customer is asking to implement more & more users: The no of systems to be implemented (R/3 production, test, developing, demo, training, development, sand box, training, pay roll, migration, pre production) The no of interfaces modules to be implemented
The scope of work document will be sent as a draft to the customer manager and project manager. The document will be finalized and signed out by the customer and we can call it as statement of work.


Implementation Methodology: Applications are built is SAP but not customized. In SDLC application are not built. Most of the application are built is SAP. SAP implementation is carried out by using ASAP methodology. ASAP: Accelerated SAP. Using this implementation steps are defined in any organization. Currently Solution Manager is used for defining these steps. ASAP consists of the following steps:

1. Preparation 2. Business Blue Print 3. Realization 4. Pre Go-Live 5. Go-Live and Support
Preparation: once the project is awarded the following preparatory steps are performed. Install solution manager to record all the activities of implementation. Note: Prior to this H/W sizing has to be performed to define the H/W required. Hardware Sizing: it is an exercise which will be carried out at customers place to identify the required infrastructure. This will be defined in the SOW. In order to perform H/W sizing SAP recommends to use Quick Sizer Tool. It is a proprietary tool of SAP. The tool is located at www.sevice.sap.com/sizing

Thumb Rule for SAP Installation: 4.6 40GB/256MB/512MB 4.7EE 80GB/512MB ECC5.0 120GB/1GB 133

ECC6.0 200GB/2GB Legacy systems: These are nothing but the existing system which are to be replaced with new configured system to introduce SAP. In order to perform H/W sizing we need to use the sizing which is available on SAP market place SMP: SAP market place. The Quick Sizer is a tool that is developed by SAP and its H/W partners to help customers get an idea about the sizing . It is free of cost In order to log on to the market place we require USER Id and for performing the H/W sizing we need customer number. Customer Number: It is provided by SAP after sizing the software purchase agreement. SUSER ID: It is a 10 digit number with S provided by SAP to log n to market place. This user id a super administrator and have all the privileges on the market place. We need a SAP user Id called as SUSER ID which start with S followed by 10 digit number Ex: S0001234567


The Customer No field value will be automatically shown. The input values required for the H/W sizing are:

Name of the Project and Customer Number. Project name

Now choose create the project. Specify the customer details:

Specify O/S,DB, Mirroring, RAID High availability required (Clustering/standby server) Online, offline, incremental backup and partial backup What amount of legacy data Working hours & specify off peak and park hours Unplanned down time
There are 3 types of sizing for SAP.

User Based Sizing


Throughput Based Sizing Customer performance Test

1. User based Sizing: 191. This sizing depends upon the no of users, type of users and modules used.
3 Types of users:

1. Normal User: The user who communicates with the system and the requests will be in between (0 to 480 dialog steps/40 hours)2 dialog steps/ Min 2. Power user: These are the one who will create dialog steps in between 480- 4800. For every 30 Sec one dialog step 3. Transactional users: These will create around 4800 to 14400 dialog steps per week. These users will create more load on the system. By activating the transactions at least once per every 10 seconds. These users are also called as concurrent users.
Dialog Step: user request goes to server and comes back to the user. Average response time of a dialog step is 800 m sec to 1200 m sec i.e. 1.2 seconds Now specify the Type of users, No of users and Module users.

2. Object Based Through Put Sizing:

It is not based on users but it is based on users but it is based on transactions. We need to specify the number of objects to be created. Object: Sales order, purchase order, invoices, buildings, shipments delivery It is based on objects and the dialog steps. In order to use this method prior expertise or previous experience is required (Mostly used for upgrade) Specify thee no of users in local area network or WAN, internet users. Apart from the above we need to consider O/S, Db, JDK and other 3rd party tools. Save the details, calculate the result and set to final.

3. Customer performance Test:


Output of H/W sizing: The output f the hardware sizing is the requirements in terms of SAPS. H/W Sizing: Disk category Disk Size S,M,L,XL,XXL 900 SAPs CPU Category S,ML,XL,XXl 3200 Memory in MB 198000 X50

SAPS: SAPS stands for SAP Application Performance Standard While defining SAPS, SAP has considered a most populated module SD as a benchmark. Fir every 2000 sales orders which are created in an hour generated 100 SAPS. SAPS: SAP applications benchmark standard SAPS is a unit which will be used to calculate the amount of CPU resources required. The H/W vendor also provides details of SAPS generated by various CPUs. Ex: IBM P-series. It will generate 1000 SAPS per CPU In the same level I-Series generates around 900 SAPS. It always depends upon the speed of the CPU. Depending upon the no of SAPS we need to recommend the CPU. Ex: If the SAPS required are 3600 we may need to suggest going for multiple CPU. Whereas for 1000 to 2000 steps we can recommend DUAL CPUs. Note: H/W sizing will not give you the exact figure required. It is recommended that 40 to 60 % of the sizing needs to be added to the sizing results. 9 dialog steps are required for one sale. For 2000 sales 100SAPS are considered. 2000 X 9 (for 100 SAPS per hour)= 18000 dialog steps/hour Sizing report can be changed from time to time by modifying the details in the quick sizer tool. Note: The sizing which is planned should cater at least for minimum 3 years. Ensure that H/W is capable of handling the enhancement.


Communication with SAP: Customer communication with SAP to purchase SAP software depends on No Of Users. Currently for 5 users it is charging 14 lakhs. On top of it every year we need to pay 17% as service fees. Once the agreement is signed SAP shifts software to the customer sight. The following products are available in SAP:

1. MYSAP Business Suit 2. SAP NETWEAVER 3. SAP BUSINESS SPECIFIC (SAP B1) 4. SAP ALL IN ONE 1. MYSAP BUSINESS SUITE: 192. It consists of the following modules.

S.C.M: Supply Chain Management C.R.M: Customer relationship Management S.R.M: Supplier Relationship Management P.L.M: Product lifecycle Management mySAP ERP: myERP Financials, muSAP HR, R/3 Enterprise

2. SAP NETWEAVER: SAP NETWEAVER: It provides all the new dimensional components like EP (Enterprise Portal) , XI (Exchange Infrastructure), MDM (master Data Management), PI (Process Integration)

193. 3. SAPB1:
It is a product which is specific to particular business Ex: Textile, Fabrication, Banking


It is a combination of various functionalities. BIW, R3 come together as one product. 138

Note: SAPB1 is not a part of Netweaver.

ASAP Implementation of SAP is as follows

1. Project Preparation Phase:

IDES: Demonstrative Educational or Evaluation software Let the users log in to the system for demos. During this phase S/W and H/W arise. The installation is valid only for 30 days. Check the H/W and S/W. Prerequisites for SAP installation:

1. Ensure that H/W is procured according to the sizing requirements 2. Check and verify the S/W from the market place which is shifted to you. 3. Check the DVDs are existing, check if they are readable 4. Download the installation guides from the marketplace link instguides 5. Check for known-problems for installing SAP components (Known problems while installing Solution Managerr3.2) 6. Install Java runtime environment because they are designed using JAVA 7. Set the environment variables JAVA_HOME and path. 8. Set the virtual memory, currently we can set 3X RAM size from Windows 2003 onwards 9. Communicate with network team and obtain static IP address 10. 11. Specify the host name and IP address in etc/hosts Install the O/S with relevant patches


12. 13.

Install the RDBMS S/W and patches Set the file sharing to the maximum of NIC

14. Dump the S/W into the server, ensure that the directories should not have spaces and special characters 15. The system name should not be more than 13 characters.

Note: From ECC 5.0 onwards the Installation Key is necessary. This is can be generated in Solution Manager. While doing the installation of R/3 at step 3 or 4 it will ask for installation key.




Solution Manager




Solution manager requires 28 GB of space for installation. Solution Manager is used to configure satellite systems R/3, BW, CRM, XI,EP,APO and other WEBAS ABAP and WEBAS JAVA components. Satellite Systems: All the systems which are configured as satellite systems can be monitored through solution manager. Creation of Satellite Systems: Go to transaction SMSY. It is a transaction in solution manager. Create R/3 system, database host, System landscape, and generate RFC destinations with satellite systems. RFC: Remote function call. Generation of Installation KEY or Upgrade Key: Go to SMSY menu -> Go to other object and specify the HOST NAME, SYSTEM ID, INSTANCE NUMBER > click on Generate Installation/Up gradation Key 140

Transaction: It is a shortest way to navigate to the programs in SAP system. There is a command window which will be used to execute the transactions. Transactions are easier to use and cut down the dialog step activity. SAP Based Menu: Easy access menu. It is a standard menu, which is used to navigate to the programs with n no of dialog steps. We can create our own transactions. Transactions are created in T-Code SE93. While defining transactions SAP has followed certain conventions. Transactions that start with SM are used for System monitoring / Sap monitoring Transactions that start with ST are used for system traces Transactions that start with SE are used for sap engineering Transactions that start with SU are used for user administration Transactions that start with VA for sales Transactions that start with ME for material management Transactions that start with AL for alerts. Project Management: Go to T-Code SOLAR_PROJECT_ADMIN It is a transaction where project is created. It is used to define the following:

1. Name of the project 2. Person responsible for the project 3. Name of the consultants 4. Project status 5. Modules to be implemented 6. Mile stone 194. be used or templates can be avoided. 195. 2. Business Blue Print Phase: It is configured in solaro1. It is used to configure business scenarios which need to be implemented in the

Templates available can

project. Go to SOLAR01 select business scenarios -> go to structure -> Go to Configure elements -> press F4 196. When we press F4 it will display the list of the components. Select the component for configuration. 3. Realization (or) Configuration Phase: This is where exact configuration of the system is performed. Go to SOLAR02. Select the business Scenarios which need to be configured. Click on the transactions so that it will be routed to the respective transaction in the transaction system.
Note: To define and Configure Satellite system logical system component should exist Documentation such as screen shots and notes can be uploaded. In order to implement the above steps or phase we can use the road map which is predefined in solution manger. Go to Road Map (RM Main)-> Select the Project and choose the road map which is predefined in solution manger -> Go to Road Map and you can down load the road map. We also have the flexibility to define the consultants for each phase.

4. Pre Go-Live (or) Final preparation Phase: During this phase all the configured components are related and moved on to other systems in the landscape. Some of the key activities are 1. Data Migration from legacy system 2. Quality check for all the programs 3. Pre pay roll run 4. End user training 5. Pre Go-Live check by SAP
5. Go Live and Support: The system goes live on the cutoff date, end user start working, run time problems are identified, patch up work will continue, support the project till SLA ends SLA: Service Level Agreement.


Advantages of Solution Manager:

1. Key Generation 2. Centralization 3. Alerts 4. Service Desk 5. Support package Updates 6. Solution Monitoring 7. Documentation 8. Project Management 9. Reports
Inputs required during Installation : Make sure that Pre requisites are met. (H/W,O/S, Virtual Memory, Environment variables, me JDK,RDBMS) Make sure the availability of Installation master DVD, KERNEL,Export DVD and Instguide. In earlier versions up to 4.6c R/3 setup is used for installation. But from 4.7 onwards SAPINST is used for R/3 installation up to WEBAS version 640 SAPinst tool has independent DVDs for R/3, BIW, CRM, APO. But from 640 onwards master DVD will be used to install ERP, CRM, SRM and other NETWEAVER products. R/3 setup Not GUI Kernel- R/3 Executable Export DVD (If it is component Specific then it is separate for every module) JAVA SAPinst Tool: It is used for installing R/3 components based on ABAP and JAVA. SAPinst tool has its own version. If the tool dosent support the installation we may need to upgrade SAPinst to higher versions. Download the current version of SAPinst executable from the market place www.service.sap.com/swdc The DVDs used for installation are 143

1. Installation maser DVD 2. Kernel [Release Specific] 6.40 or 7.00 (8.00 will come soon) 3. EXPORT DVDs. It consists of component specific data such as tables (Everything is stored in the database) 4. JAVA DVDs which are required for providing graphic solutions (IGSInternet Graphic Service) 5. GUI installation DVD: It is used to install SAP GUI front ends for all the users. 6. RDBMS software (Oracle, MAXDB, Informix, DB2, SQL Server) 7. Language inputs (or) language DVDs. By default German & English are installed. Additional languages are installed using this DVDs. 8. Support Package Collection: It is used to apply the support packages and patches to R/3. 9. Add on components: additional components related to XI, BI and other Netweaver components or other industry specific solutions. 1) Go to Installation Master DVD 2) Select the O/S specific directory 3) SAPinst.exe 4) We need to set the runtime environment JAVA_HOME. 5) SAPinst listener on port 21212. We need to ensure that the port is not blocked. 6) Select the component to be installed say ECC 5.0 7) You need to select the database 8) Select the Unicode or Non-Unicode
Single Code: The database has its code to support the language. Ex: If we have English, German the default code page is 1100. This code page supports only few languages. If we want to access the system with other language which are not supported by current code page we need to install that code page. MDMP: Multiple display multiple processing (Out dated) 144

It is used to support in installing to a language. MDMP has a disadvantage because e have to handle different code pages when upgrading the system. UNICODE: The database reserves 2 bytes to cater to almost all the languages in the world. It supports all the data code pages and no special attention is required during up gradation. Note: We can install non Unicode system but it can be upgraded to Unicode by using SAP export and import tools. Note: Unicode system cannot be converted into non Unicode system.

9) Select Central Instance: Click in next 10) Specify the< SID>: SID is used to identify the system. It should be of 3 characters and can also be alphanumeric. It should start with a character only followed by alphanumeric values.
Note: Do not choose SID from the reserved words SAP, ALL, BIW, ERP. We can use like PR1,P01, D01, D40, P20.. Try to define the naming convention for all the systems in the landscape. Instance Number: This is the port number which will be used to reserve the ports or the instance services and processes. It should be in between 00 t 97.

11) Specify the host name. The name of the system where the installation is performed. This should not be more than 13 characters. Ensure that host name and IP address are entered in etc\host.
MCOD: Multiple components on one database From Oracle 9i onwards multiple components like ERP, BIW, CRM, and SRM can be installed on one database. The databases are differentiated by SCHEMA IDs (Ex: SAP<SID>SAP01). SCHEMA OWNER: It is the owner of database represented by SAP<SID>. Instance number should be unique in the system. Hostname: Name of the software where installation s performed. Specify the host id of database. It will be same as the central instance host.

12) Specify the host ID of database. It will be same as the central instance host.

Central System Installation: If the central instance and the database instance installed on the same physical machine then it is treated as central system installation. Distributed Installation: Database instance and central instance are hosted on two different machines. In case of a distributed installation specify the name of the database host where database is installed.

Central System

Host Name Central Instanc e


Physical Machine Instance: An instance provides executable services. Ex: Database Instance, Central Instance, Dialog Instance Instance has its own instance number it requires own memory configuration. Multiple instances can be installed on a single system.

13) Specify the amount of memory reserved for the instance for installation. By default 60% of the physical memory. 14) Specify the type of installation

Local Installation: It is performed locally using the local user rights. Unless and until it is recommended dont go for any installation except local installation. Ex: For installing DUET local installation is not recommended. Duet Enterprise is a business tool that blends SAP and SharePoint data to increase staff and department productivity, according to the pair. Microsoft SharePoint, also known as Microsoft SharePoint Products and Technologies, is a collection of products and software elements that includes, among a growing selection of components, web browser based collaboration functions, process management modules, search modules and a document146

management platform. SharePoint can be used to host web sites that access shared workspaces, information stores and documents, as well as host defined applications such as wikis and blogs. All users can manipulate proprietary controls called "web parts" or interact with pieces of content such as lists and document libraries. Installation Number: If the installation is carried out in a domain ensure that all privileges are held by the user to install the components. Most of the domains have restrictions for passwords, user creations password expiry. Note: It is recommended to install locally and attach it too domain later. Domain Server: All the systems in landscape are configured with domain server. It is a centralized server. It can give IP address of DHCP. Specify the kernel directory and transport directory. Specify the database instance parameters, database id, dbhost, db home (Home Directory of Oracle, db SCHEMAs owner of the database, db character set. Installation log is located in the C:\programfiles\sapinst_instdir\SOLMON32\WEBAS

15) Specify the passwords, SAP system administratin and SAPserviceadministrator SID<ADM>.
SAP system administrator has the privileges to start and stop the system. He is the administrator for R/3 system. SAPserviceadministrator is used to run the services required for the instance. These user ids are instance specific.

16) 17)

Specify the path of the kernel DVD Specify the port numbers

Message Server Port: 3600 + Instance Number Dispatcher port: 1300 + Instance number Gateway Port: 3300 + Instance Number Dispatcher Security Port: 4700 + Instance Number Gateway security port: 4800 + instance number These port numbers are entered into etc\services.


Specify the location of JAVA DVD IGS


Database Instance Installation:

1) Specify the SID instance number and host name 2) Select whether it is a standard installation or system copy using migration/Backup/standard export & import. 3) Specify whether we need to install SAP system in the db (or) if the db exists add another SAP system. 4) Specify the SID and host name 5) Specify the amount of memory required by default it is 40% of physical memory. 6) Select local installation 7) Specify db kernel file location. It will be the central instance kernel file location. Because kernel for both R/3 and DB should put together on one location 8) Specify the server directories and redo log files, archive log files location. 9) Specify thee kernel dump directory location 10) sapservice<SID>. Specify thee passwords for sysadm and

11) Specify the location of mirror log files A,B and specify thee location of Origlog A,B and data files (SAP DATA1, SAP DATA2SAP DATAn) 12) Specify the load strategy (load strategy should be loaded by the data file). Specify the DB code page. By default it is 1100. No of parallel jobs can be increased based on the availability of memory by default it is 3 13) manager 14) P01). 15) Specify passwords for system by default it is Specify the password for SCHEMA user (SAP Specify the password for DBA user

F1 functional key gives help for all options. F4functional key displays list of components Solution Manager is used to create new solutions. DSWP is also used to configure solution landscape. Roles and Responsibilities:

Generating installation Keys. Monitoring the configured solution through DSWP/Solution Manager. Assisted project manager to create project. Select he business scenarios. Upload the project specific documentation created, satellite system and read the data from them. Create the server, database, systems and logical components. Download the roadmap. Perform H/W sizing. Analyze the sizing results with customer/ H/W vendor. Process of CI installation. Process of DB installation. Install and configure Solution manager. Communicate with the customer to prepare the SOW. Defined feasibility report of the existing landscape. Training to the end users on solution manager. Knowledge on ASAP methodology.


Client/Server Architecture: Reuest Client Server


Client software is required for client system. Servers are heavily loaded Response time shoots up Resources exhaust hour glass occurs


Client software applicatio n server



Client software is out from client Interpretation is done at middle level Buffering issued frequently and consistently Accessing is easier.


Applicatio n Server



Applicatio n server

In a typical client server architecture client request and server responds. The contents of t client are GUI which is programmed using traditional language like C, C++ etc In order to communicate with DB, database client software should be installed in each client. As the clients are directly communicating with DB the DB is heavily loaded. There is no common area where frequently accessed content can be stored. The response times and the database server resources exhaust and users encounter hour glass situation. In view of the above the concept of application server came into picture. The application server handles the load of the client by taking client software from the clients. The interpretation will be done at application server. Frequently accessed content are stored in application server which reduces load on the database. There by increases the performance of the client request. Application Server has the following:

1) Its own memory 2) Buffer Areas 3) Application server specific work processes 4) Database client software.
Application server is also called as an Instance. 151

R/3 Architecture: It consists of 3 layers. They are

1. Presentation Layer 2. Application Layer 3. Database Layer

All the above 3 layers are also termed as servers, because they do some work to serve the clients. Presentation Server: It is an SAP GUI where user interacts with SAP system. There are 3 types of SAP GUI.

1. SAP GUI for windows 2. SAP GUI for Java 3. SAP GUI for HTML
SAP GUI has the following features: Graphical user interface Change the color, font and font colors of GUI Support of all languages One GUI for all the applications (R/3, CRM, BIW, APO..) F1 and F4 help (F1- Field Help, F4- List of possible values) Customized favorites according to user requirements Frequently keyed IPs can be stored as parameters Download compatible higher version can work with older versions With the help of message server it defines the least loaded server and routes the request to that particular server.

Installation of SAP GUI:


Use SAP GUI DVD to install SAP GUI. Use SAPinst to install SAP GUI. Installation on few clients can be performed personally, but the number of users increases we need to automate the tasks.

1. 1 to 10 users in personal (remote desktop (or)net meeting) 2. More than 100 users use login script so that GUI can be installed or updated during the user logon to the system. 3. Install the software on a file server along with installation screen so that user can perform installation on his own screen so that user can perform installation on his own 4. Use 3rd party tools like SMS or Software deployment tools 5. Use SAP GUI installation server to install, update user GUI.


The above screen shot represents the SAP GUI after installation and configuration. GUI Operation: When user clicks on anyone of the options in SAP GUI logon screen one of the following files will be evaluated.

1. SAPlogon.ini 2. SAPmsg.ini 3. SAProute.ini 4. SAPdoccd.ini 5. SAPrfc.ini

SAPlogon.ini: It consists of SAP logon credentials like description of the server, name of the application server, SID and instance number. When user clicks this file is evaluated. SAPmsg.ini: It consists of the message server details like message server name and port number. This file is used when logon groups are configured SAProute.ini: This file is used when users are communicating with servers using routers (The servers in the network) SAPdoccd.ini: It is evaluated when SAP library is initialized. SAPrfc.ini: While communicating with various systems using RFC this file will be evaluated. Uninstalling SAP GUI: For uninstalling SAP GUI use SAP sweep. Presentation server is the only GUI. Application Layer: Application Server is used to handle the user request, whenever a request comes from presentation server it is handled by dispatcher of that instance. DIALOG PROCESS USER USER XXXX DISPATCHER Q


The application server will contain the following components:

1. Client server software to communicate with DB

Ex: Oracle Client, Ms SQL prompt .

2. Buffer Area: The frequently accessed contents from the database need to be stored in the temporary work area.
This is refereed as R/3 buffer. Various Buffers are:

1. Calendar buffer 2. Table buffer 3. Program & Definition Buffer 4. DD: Data Dictionary 3. Memory: In order to process the user request memory is allocated for work process. 4. Interpreter: It interprets user requests by splitting into ABAP codes, Screens, SQL statements
Dialog Step: User logs onto the system by keying USERID and password. diag is the protocol which connects to the application servers. DIAG: Dynamic Information Action gateway. TCP/IP is the basic thing. Dispatcher receives the user request and checks for free work process. If free work processes are not available it will be queued in the dispatcher WAIT QUEUE. Dispatcher Wait Queue: When free work processes are available user requests are served by dispatcher on FIFO Work processes are W0, W1, W2.Wn. 155

Work processes handle the task of user while handling the task. It sets the memory allocated and completion of the task. It contains the following: ABAP interpreter: It interprets the ABAP code which is containing in the task handler. Screen Interpreter: It interprets the screen contained in the task Task: user request SQL Interpreter: It interprets the SQL statements of the task. The work process reaches database but it could not perform any task from the database, because it it specific to application server. The work process hands over the task to the DB SHADOW PROCESS. SHADOW PROCESS processes the request and hands over the response to work process. WORK PROCESSES analyzes the response which is in the native format and screens are designed to respond to the user. Before sending the response to the user the work process rolls out the user related information into user context. USER CONTEXT: It is a temporary memory or temporary work area where user related buffer area stored. When users login user context is created and it is cleared when the user logs off. It consists of logon attributes parameters, the earlier access contents. ROLL OUT: The process of rolling out of the user related information into USER CONTEXT. ROLL IN: The process of rolling the user context information into Work processes buffers. First Dialog Steps: The average dialog response time should be between 800-1200 milli seconds. Second Dialog Step: Create/Modify purchase order Dispatcher assigns the free work processes to the work process. Work process rolls in thee user context information and checks whether the user is authorized to create the Purchase order. IF authorized the process continues else response back to the user saying that user doesnt have authorization. 156

All the Steps are:

1. UR 2. DIAG 3. Dispatcher 4. Queue 5. WP allocation 6. T.H 7. Interpretation 8. Reaches DB 9. Shadows process 10. 11. 12. 13. 14. Response to WP Format the response Roll out User context Response to user

Database Layer: It is used to store the data of the customer. Database has its own memory, process (Work Process), buffer areaetc. R/3 work process hands over the request to the shadow process. The SQL statements are interpreted in the R/3 application servers and converted to native SQL statements. All the ABAP programs consists of open SQL statements. When the request sends to the DB they are interpreted into native SQL statements (T-SQL, PL SQL) T- SQl : Transactional SQL PL-SQL: Programming Language SQL T-SQL and PL/SQL common languages for database-independent applications Shadow Process: When the user request is added over to the shadow process shadow process try to find out the request in the user buffer. If it is not available then it will search in the database. 157

Application Layer: Application layer consists of various instances with various processes. Instance provides the following services

1. It has its own memory, own buffer, own work process. One or more instances can be installed on an application server. Application server is a physical device. It consists of CPU, memory storage. 2. Instance also can be referred as Application Server 3. A group of instances can also referred as application server group of instances can be installed on an application server each instance can be configured up to 89 work processes and each work process requires around 75 MB to 150 MB 4. Each work process need to serve 5 to 10 users 5. Application servers provide the following work processes:
D: dialog WP V: Update WP E: Enqueue WP B: Background WP S: Spool WP M: Message server service G: Gateway Service



The above 2 screen shots are typical windows MMC. (This sacreen shot is taken from Netweaver 2004s flavor of SAP) You can find 3 dialog, 2 update, 1 spool, 2 Background, 1 Enqueue, 1 update, 1 Messaage server and 1 gateway service for this installation. The number of dialog processes and the number of background processes can be increased after the installation is completed by using the transaction code RZ10 (Profile Maintenance). Dialog Work process: It is the only process where users communicate indirectly. There should be at least 2 dialog work processes for each instance. Dialog process is used to create, update requests, transactions, print requests and background tasks. Update Process: It updates the records to the database. There should be at least one update work process for each R/3 system.


Transaction: A transaction consists of one or more dialog steps which will be committed together or rollback. It is also referred as logical unit of work. SAP Transaction: SAP transaction is a bundle of one or more transactions which can be executed together or rolled back. Dialog process updates in temporary tables, update process reads the temporary tables and updates the database synchronously. The dialog WP time is restricted to 600 seconds. These all dialog WP need to complete their task within the maximum runtime. If the task could not be completed within the specified time timeout error occurs and program will be terminated. ENQUEUE Process: Enqueue process is used to provide tasks to the records which are going to be updated. Technically enqueue process is used to lock and unlock records which are being updated. There will be only one enqueue process in any R/3 system and mostly it will reside on the central instance, where message server is installed. Note: More than one enqueue process can be configured based on the frequency of updates. Background process: The tasks which consumes more time are scheduled in the Background mode. The jobs which are long running, expensive, time consuming and non interactive will be scheduled to run in the off peak hours using background process. Expensive means the ABAP code is expensive or the DB records have more records. This should be at least one process for each instance. Message Server: It is used to manage all the instances. That is it controls all the dispatcher when logon load balance is configured. It also helps to procure logs from enqueue process if the requests are coming from dialog instance. There will be only one message server in an R/3 system. Message server always resides on central instance. The instance where message server resides is called as central instance. Enqueue process & message server resides on the same instance and it is not advised to host them in two different instances as it will increase the enqueue time. Gateway Process: it is used to communicate between the instances and systems. Thee will be only one gateway process for each nstance. Spool Process: it is used to output the documents to printers, fax, emailetc. Spool process or print request are created by dialog process and background process. The print requests are stored in the temporary area which are read by spool process to format and print the request. We can configure one spool process for each instance. 161

Dialog Instance: we can configure as many work processes as possible but it limits to 89 per instance. If the load on the instance increases in terms of users we consider displaying additional dialog instances. Central Instance: It is a dialog instance where message server and enqueue process resides. Database Instance: it is an instance where database is hosted. It resides on the database layer. File structure of Application Server: There is a shared mount (or) shared directory which will be created during installation. \\usr\sap \\usr\sap\trans \\usr\sap\<SID>\sys\exe\run Note: the sum of non dialog process should not exceed the sum of dialog process in the dialog instance. Central System: This is the installation where the central instance and the database instance are installed together. Application Layer

Presentatio n layer Central System

A1 A2 A3 A4

CI+DB DVEBMGS Central System

Central System Installation Check: Start MMC Check the status of R/3 system. The status is Green- Installation is proper The status is Yellow Network interface problem 162

The status is Grey Instance is stopped

Starting of SAP system:

On WINDOWS NT use MMC to start and stop the system. Start up procedure for SAP WINDOWS: MMC sapstart.l og
Alert_Dev.or g


Send message via name_pipe START

Startup Profile SAPDEV_00


Strdbs.cmd Msg_server.exe Disp+work.exe


DB(If not


Msg Server Dispatche r Gateway ICM

Default Profile Instance Profile

dev_rd dev_icm

dev_w0 wn



During startup of the operating system Windows NT, the NT Service Control Manager starts all the services in the service list that are configured for automatic startup. The information relevant to these services is stored in the registry and is read by the Service Control Manager during startup. Several services of type SAP_ (the SAP service) and Oracle Service,but only one SAPOsCOL service, can be run on one computer. The SAP service, SAPOsCOL, and OracleService should be configured for automatic startup. To start the Oracle database and the R/3 System, the administrator performs the following steps: Log on to the operating system Windows NT as user adm. To start the R/3 System, open the Microsoft Management Console (MMC) using the SAP R/3 Systems Snap-in. Right-click on the system icon and select Start. The sapstartsrv.exe executable sends a message using a named pipe to the SAP Service, SAP_. The SAP service starts the database by executing an NT script that calls the Oracle Server Manager. The Oracle Server Manager executes an SQL script that starts the database if it is currently not running. Once the database is up and running, the SAP service starts the Message Server (msg_server.exe) and the Central Instance dispatcher (disp+work.exe). The R/3 System has been started successfully when the icon for the central instance changes color to green. The colors displayed in the MMC have the following meanings: red - the process terminated abnormally; yellow - the process is being started; green - the R/3 System has been successfully started; gray - the process is not running, status unknown. You can also start the R/3 System with the NT scheduler called at. For this kind of start, SAP provides the executables startsap and stopsap which are executed 164

locally. Use - startsap name= nr= SAPDIAHOST= to start an R/3 instance and - stopsap name= nr= SAPDIAHOST= to stop an R/3 instance (the executables sapstart.exe, sapsrvkill.exe and sapntwaitforhalt.exe must be in the same directory)

To provide a stable startup procedure, a parameter read sequence (also known as the parameter replace sequence) is defined during startup as follows: R/3 processes read the appropriate parameters from the R/3 kernel, from the NT system environment variables, and from the NT Registry environment variables. The default profile \\\sapmnt\\SYS\profile\default.pfl is read. Profile values already defined in the R/3 kernel are replaced with the values in the default profile. The instance profile \\\sapmnt\\SYS\profile\__ is read. Profile values already defined in the default profile or in the R/3 kernel are replaced with the values defined in the instance profile. This procedure ensures that system parameter values reflect not only the instance profile but also the values in the default profile and the R/3 kernel. The SAP service reads only the start profile and the default profile. The R/3 kernel (disp+work.exe) reads only the default profile and the instance profile. If you change the default profile, you must restart the SAP service (including the R/3 instance). If you only change the instance profile, you only need to restart R/3 using the MMC.


R/3 work directories contain trace files and error files for messages relating to the startup of work processes. Each R/3 instance has a separate work directory containing information that may not be found in the R/3 System log. The work directory files are initialized in chronological order. During startup, the SAP service executable SAPSTARTSRV.EXE writes: Database logs to the file STDERR1 Message server logs to the file STDERR2 Dispatcher logs to the file STDERR3 To define the level of information written to the developer trace files, set the profile parameter rdisp/TRACE in the instance profile. The possible values for this parameter are: 0: Write only errors (no traces) 1: Write error messages and warnings (default) 2: Write error messages and a short trace 3: Write error messages and the complete trace


UNIX: $startsa p Send message via name_pipe SAPOSCO L startdb.lo g

Startdb script

alert_dev.l og Read

Startup Profile Strdbs.cmd Msg_server.exe Disp+work.exe

start Kill.sap dev_ms Msg Server Dispatche r Gateway ICM

dev_w0 wn



Default Profile Instance Profile

dev_rd dev_icm




In UNIX operating system the command startsap command id used for starting the SAP instances. This command will in turn call the SAPOSCOL (If not started). This will in turn calls the startdb script which will start the database. Now the sapstart command is executed which reads the startup profile. Then the message server will be started. Dispatcher (disp+work.exe) will be started which reads the default profile and the Instance profile. Then the dispatcher will start the GATEWAY, ICM, and the Work Processes. There will be different trace files that will be generated while starting the sap system. Alert_dev.log: generated when starting the Database. Startdb.log: Log file for the database start up. Startsap_ZDVEBMGS00.log: log file for the sap start. Dev_ms: Message server trace file Dev_disp: Dispatcher trace file Dev_rd: Gateway process trace file Dev_icm: ICM trace file Dev_w0----Wn: Trace files for the work processes.

In UNIX the commands are used for the starting and stopping of SAP: To start the DB server: $ startsap db To start the sap instance: $ startsap r3 To start all at a time: $ start sap all

The following commands are used in Stopping SAP: To stop sap instance: $ stopsap r3 168

To stop the database: $ stopsap db (The script stopdb is executed when this command is executed) To stop all with a single command $ Stopsap db

In Windows or UNIX or Linux or any other operating system before stopping the SAP check the status for List of user logged in the system. (SM04, AL08) List all active processes: SM50, SM66 Send a message through: SM02 or any other third party tool for the execution. Brief of SAP startup procedure: On windows NT use MMC to start and Stop the system On UNIX use scripts STARTSAP and STOPSAP to start and stop the system. Sequence of START UP: First the database is started. CI is started Dispatcher will be started Gateway will be started ICM will be started While stopping the system: Ensure that Application servers are stopped CI is stopped DB server is stopped


Users created during the installation: <SID>adm to admin the R/3 system SAPservice<SID> is the user to run SAP services. These are the two operating system users during operating system installation. DB users are: When the ORACLE system is installed SYS & SYSTEM are installed On a MS-SQL system and USERID is SA SA-System administrator. DB users created during DB instance installation:

SAP<SID>-SCHEMA owner of the database OPS$<hostname> SIDADM ORASID is the DBA on UNIX platform.
OPS$ Mechanism: This is the mechanism which allows the operating system users to connect to database without prompting password Services: These are various services which are created during installation.

1. SAPOSCOL: It is the O/S collector which will collect the H/W information from the system before starting the instance. If the required resources are not found this service will not be started. Execute SAPOSCOL at command level and clear catche. There will be only one SAPOSCOL service in a machine (SERVER) 2. SAP<SID>_<Instance Number>: It is the service which is required to start the R/3 instance. If it is not started R/3 will not be started. There will be one service for each instance. 3. ORACLE TNS LISTNER: This service is required to start DB. There will be one listener for each DB 4. ORACLE SERVICE SID: This is used to communicate between the DB instance and other instance. All the above services are displayed in

services options else go to My Computer-> Right Click-> Manage -> Computer Management -> Services and Applications.

197. On UNIX use the command ps-ef to display the services. The service user SAP<SID> runs the services. 198.

Directory Structure: The only directory installed during installation is \usr\sap. This directory is a shared directory by default, because it needs to communicate with other systems in the landscape. Communication means to share the folders across the systems. This is for Windows NT. On UNIX SAPinst is created as a soft link pointing to the above directories


1. \\usr\sap\<SID>\sys\exe\run 199. NUC\i386(or) iA64\ In future the kernel directory is \exe\UC (or)

This is the directory where kernel executables are located. Some of the kernel executables are Startsap Stopsap SAPOSCOL MSG_server.exe Dispatcher+Work process (disp+work) \\usr\sap\<SID>\DVEBMGS<instance number> It is the instance directory to display the type of instance installed. For a dialog instance it will be DO7 like that. Under this which consists fo logs and traces of the instance. \\usr\sap\trans: This is a directory where transport related information lies. \\usr\sap\<SID>\sys\profile: This consist of the properties of instances Startup Mechanism: User clicks on strartsap -> saposcol which is already running provides the information of the system. Instance service sapM<sid>_<instance number> is started and this service look into start up profile. Start up profile is used for starting the sap system. This resides in the directory \\usr\sap\<SID>\sys\profiles Start_DVEBMGS<Instance no>_<hostname>.pfl Ex: Start_DVEBMGS00_indiainternat.pfl It consists of the following service statements


1. Start DBS command Strdbs.cmd 2. Message Server 3. Disp+work.exe 4. Igsgwrd.exe 5. Icmon.exe

Default Profile: This profile provides default values for all the instances. It provides details like Message server host Enqueue server host Logon client Login language Startup profile of Dialog instance: (Global Profile) It consists of the following


1. Disp+work.exe 2. Igsgwrd.exe 3. Icmon.exe

Instance Profile: It consists of the following parameters

1. <SID>_D01_<hostname>.pfl Dialog instance 2. DEV-DVEBMGS00_indiainternat.pfl Central instance 3. Work process configuration like Types of WP, No of WP 4. Memory configuration (Role Memory, External Memory) 5. External Areas
Note: The above profiles are maintained in transaction code RZ10, RZ11 The profiles which are changed using RZ10 requires the instance restart. The profiles which are changed using RZ11 (Dynamic Change to parameters) dont require any instance restart. 173

RZ11 is also used for displaying documentation for profile parameters. Dont change start up profile unless there are changes in the directory structure. Note: Default profile parameters are overwritten by instance profile parameters. System shutdown procedure: Reasons for shutdown are as follows

Change parameters Up gradation by the support package Offline backup Migration of H/W or H/W interpretor General (UPS, Air Conditioning, Power) Data Center (Exchange, Domain,)and dependent systems

Process of shutdown: Define and schedule down time. Ex: Sunday 1st Jan 2010 6:00 Am to 2nd Jan 2010 5:00 PM Effective Users: All the R/3 users domain users BIW users.. Purpose of Downtime: _________________________________________________________________ KPR: Key person responsible, Role, contact number Inform all the users well in advance through notification, email, or through TCODE SM02. Problems during SAP startup: Scenario: We have scheduled downtime for our R/# system to update the O/S patches and DB patches. If the system could not be started after applying patches the system has no history of startup problems.

1. Check whether the server is pinging to the right host. Use ipconfig to check the IP address and ping to that server


2. Check SAP<SID>_00 started (Central Instance started or not) 3. Check the DB is stated or not. 200. 1.If the DB is not started check alert<SID>.log in saptrace\background. It gives all the details fo database directory startup details. 201. LSNRCTL status 2. If it is not showing any results check

202. 3. Check the startdb.log in the work directory \\usr\sap\<SID>\DVEBMGS00\work 4. Check all the services 5. Check message server log in work directory 6. Check for the dispatcher log 7. Check for the dispatcher log 8. Check for the ports which are blocked or running. Use command NETSTAT-P 9. Check the environmental variables missing. In that case we need to configure them manually
Environmental Variables: These provide runtime environment for the users, as we cannot restrict the installation directories to be specific to one drive. So we define home directories like HOME_JAVA, ORACE_HOME and define them in the environmental variables pointing to the directory which they are installed. Path: Class path is used to define the location of executables to execute from the command window, irrespective of drive and directory. Ex: cmd, calc There are 2 types of environmental variables:

1. User variables which are specific only to the users and it will not affect the system variables 2. It is specific to the system and use globally by all the users on WINDOWS NT. Go to MY Computer Right Click Properties Advanced Environmental Variables

In UNIX: $ SET JAVA_HOME $ export JAVA_HOME $ set display, $ set Oracle_Home SET command sets the environmental variables only for that user services.

10. Changes in the Parameters: We can change WP configuration, memory, buffers without any additional resources. 11. Changes in the passwords of service users

12. In compatibility of kernel executables with existing O/S patches and DB patches 13. Incompatibility of kernel executables with existing O/S kernel and DB kernel version


When the O/S and DB are patched they look for current versions of R/3 executables. If there is a mismatch with the versions R/3 will not start. In this case we need to perform kernel upgrade. Kernel Upgrade: It is a process of replacing the current run directory i.e. R/3 executables are replaced with the new versions of R/3 executables. Reason for up gradation: While applying the support packages and patches for R/3 system and applying the patches to O/S and DB sap recommends to upade the kernel to resolve the runtime problems either in the future or during the post installation. Process of Kernel Up gradation: Check the kernel version by using disp+work. Patches: it is the missing functionalities or bugs that arise while running the system. Up gradation: Group of patches. Command disp+work Go to market place www.service.sap.com/swdc Go to my application components. Select Kernel for 32 bit/un (or) nuv/download DB independent [sapexe-----.sar] Kernel for 32 b it/ uc (or) nuc/ db dependant [sapexe_db----.sar] Select the newer version than older version Uncar the files using the command sapcar-xvf Trace the uncar foles into new run directory (exe\run) Go to exe new run copy all the uncar files to new run stop the system and services copy existing run directory to old run directory copy executables from new run to run directory [replace]start the services and the system Note: instead of downloading and upgrading entire kernel we can also upgrade each lernel executables independently. But we need to check the dependencies. If we could not find the problem increase the trace level. Use this parameter to trace the start u activities into work directory. The following files are trace files which provide more granular information.

1. Stderror 0

2. Stderror 1 3. Stderror 2
These provide DB server logs message server logs, dispatcher logs. Check DEV_DISP, DEV_MS,DEV_W0DEV_Wn for all the processes. [dev: developer trace] Check event viewer application log and system log. Check syslog in MMC RCA: Route cause analysis

1. MMC sys log 2. Work directory dev_ms 203. 204. 205. 206. 207. 208. 209. Dev_disp Dev_W0.Wn Startsap.log startdb Stderror0 Stderror1 Stderror2

3. Event viewer application system logs 4. Environment variables 5. Network connectivity 6. Check services 7. Check DB logs 8. Check parameter change of DB of R/3 9. Check ports 10. Check password changes

Problems on SAP GUI (or) presentation layer: 178

1. Find the patch level: to find this go to left top corner Click on sap logon select the file version click in options to activate the GUI trace level 2. Message server time out 3. .ini files are missing: take backup of the ini files and store on a file server and restore them 4. GUI could not logon: check the other desktops to check the login problem. Check the network connectivity on desktop. Check the client number which is accessing. Ask the user to send the status bar. Check whether the user exists, check caps lock, check password locks. 5. User Complains of incorrect format: check which format he is looking for and change accordingly 6. Language option: when language other than English is installed them language characters and new screens are not displayed properly. 7. Check whether the GUI is compatible else upgrade GUI (ex: 4.6c, 4.7d, 6.20, 6.40, 7.10) 8. Functionality missing in the GUI: (Junk characters like -, ?, !, #.....) if the probles is related to single user uninstall the GUI on the problematic machine and reinstall GUI. If the problem is generated to all check the relevant patch and upgrade all the GUI. Else write to SAP so that a correction note will be released. 9. Check authorizations 10. parameters Use parameters missing: recreate the

Note: Screen Painter is used to design GUI screens. This is done by ABAP team. SUMMARY: So far we have seen the following topics for installing SAP system:

1. H/W sizing 2. Solution Manager 3. Pre requisites


4. Installation 5. Start up and shut down

Now we are supposed to do the post installation activities to check the installation consistency and defining the other system settings to make the system readily available for utilization. Post installation Activities: These will include:

1. SICK (SAP installation consistency check) 2. SE06 (Performing the post installation activities) 3. SE03 (System change option) 4. Define the landscape 5. STMS (SAP transport management system 6. RZ10 (Importing the profiles the DB) 7. Client Creation and copies 8. Help installation (SM13) 9. License installation (SLICENSE) 10. Support packages and upgrades

The above activities are major tasks and require more analysis and pre planning before the system (SERVER) starts working for the designated work (Development, Testing, Production).

As part of this the following activities are configureda dn checked

1. SICK(SAP installation Consistency Check). Check the consistency of the system by executing transaction SICK and seed for any errors. This cab done by logging in as SAP* with 000 client and pass word 06071992 (Default). This password can be changed during the installation. 2. SE06: It is used for performing the post installaion activities. SE06 has 2 options:


1. Perform installtion activities (Post installtion activities) 2. DB configuration ( this is used to set the change the trapsport sustem or correctin transport sustem)
SE06 enables the CTS (change transport suystem or correction transport)

3. SE03: click on the system change option in SE06. This option is used for setting the system change option i.e either to modifiable or notmodifiable. If the system is set to modifiable then the software component s can be modifiable. This option is se set only to Development and Sand Box systems. 210. If the system is set to not modifiable all the software component are not allowed to change. This options is only set for Quality and Production systems 4. Configuring the Transport management system: 211. 212. SAP system landscape:

213. It defines the flow of objects between the systems. Inorder to achieve the high xonsistency and stability SAP recimmends t use more than one system in the landscape. 214. 215. Single System landscape: In this only one system will be there for the entire landscape which is used for all the purposes(Development, Qualtity and Production) 216. 217. 218. 219. 220. 221.
Quality Production Single System Landscape


222. 223. 224. 225. Disadvantages: The objects which are used by developers will not be allowed to eited by the tester and production users. The system is not consistent either for development quality pr production. No production for single system. 226. systems. 227. 228. 229. Two System landscape: it is the least recommended landscape by SAP where developers and quality activities are performed in one box and production activities are carried out in another box. Production server is consistent but inconsistency between quality and development. 230. 231. 232. 233. 234. 235.
Two System landscape Development

Ex: It is used to setup demo, desk and training It is a resource minimized setup.

Developme nt and Quality

Productio n

Three System Three Landscape: System Landscape

Developm ent

Quality 182


This is the optimized landscape recommened by SAP where development, quality and production actions are carried out in individual systems (or) boxes. Development System: This system is used to develop the objects and customizing activities are carried out. This system is usedd by functional consuoltants, ABAP development team and BASIS team. No end user and production user can logon to the system. Quality system: The objects whch are modified (or) customized in DEV system will be tested in this system. This system is utilized by the qulaity team, training team and BASIS consultants. Production System: The objects which are development modified customized in development boxx (or) system are transported to quality and qullity approved objects are moved to production system. The system is only allowed for end user. The restricted actions can be given to ABAP and functional tools. Each user created in the system are accountable for license. Note: For each system we can configre upto 8 systems in the landscape. 8 different systems in a typical landscape are:

1. Pre production 2. Pay roll 3. Migration 4. Sand box 5. Development 6. Quality 7. Production 8. Training


Transport domain controller: As part of post installation activity (TDC) transport domain controller needs to be configured on a high availability system. As this is only one system I the landscape we will configure development system as TDC. TDC manages all the systems in the landscape. Configuring TDC:

1. Logon to 000 client 2. Goto transaction STMS (SAP transport management system) 3. If STMS is not configured within a domain then a pop up box will be displayed to configure the domain. If the STMS is already configured POP UP BOX will be displayed to create another domain (or) oncluding the domain. 4. Specif the name of the domain 5. Specify the description and save 6. Domian controller is created
Defining landscape: As we dont have quality and production system in the landscape we need to define them as virtual systems. Defining the virtual system:The systems which are going to be deployed in future can be configured as virtual systems. Virtual systes name should be exactly the same as of the real time systems. Including the systems in the domain:

1. Delete the virtual system 2. Logon to the real system which is replacing real virtual sstems. (Logon as client 000) 3. Go to transaction STMS POP UP BOX will be displayed. Select include in the domain specify domain name in the domain sytem 4. A request for inclusion is sent to TDC 5. Logon to the TDC goto STMS selecty systems there will be a system waiting for approval 6. Select the system and approve. Ti si included in the domain


Note: A communication user TMSADM will be created and RFC destinaltion between the TDC and member system is established. Domain.cfg is updated Domain.cfg is stored in \ \usr\sap\trans\bin It consists of domain settings lie details of TDC and members. It is updated whenever there is achange in the landscape. Transport Group: The group of systems which share the same transort directory are said to be in one group. Transport Layer: It is a path defined to transport the objects. SAP transport layer is by default . The name of it is trapsport layer. Transport Routes: Transport routes define the flow of objects between systems. There are two types of routes. They are

1. Consolidation Route: The route between development and quality systems is called as consolidation system 2. Delivery Routes: It is the route between quality and production systems
Development system is also called as Integration sytem Quality system is also called as Consolidation system Production system is also called as Delivery system Defining the Transport Groups: Log in to TDC in client 000 Go to STMS Select transport groups We have the option of defining the routes in 2 ways.

1. Graphical Editor 2. Text Editor

Select the type of the landscape(Single, Two or three sytem landscape) Specify the systems in the landscape sav and activate and distribute the configuration.

5. RZ10:Import profiles of all active servers onto the database. Goto RZ10 select the profile import in to DB


6. Install License: In order to install the license we need to obtain license key from SAP market place. 7. Inputs required to get the license key are 1. Customer Number 2. Installatio Number 3. Host Name 4. SID 5. Instnace number 6. H/W Key
In order to get the H/W key goto transaction SLICENSE (or) at command level saplicense get Get the key from market place and install using slicense transaction. Initial license is valid for 30 days and when license is installed the expiry date DD:MM:YYYY

8. Install Library: Goto SR13 specify the tyoe of HELP (HTML help file, HTML, HTTP< Dynamic Help). The library can be installed on a file server or on a web server. Go to SR13 define language define variant (IWB.Help, Documentation)
Repository Objects: The objects which are shifted by SAP are called as Repository Objects. These are also called as SAP standard objects.

9. Client Creation and Copy:

Client: Client is an independent business entity which represents an organization in SAP R/3 system. Client is represented by field MANDT. It is used as a data seperator i.e. the user will be displayed the data belonging to the client logged on. By default there are three clients 000, 001 and 066 Client 000: It is a template client which consists of all the configurations like company code, cost center, project center, sales, purchase etc. It is continuously updated by applying the support packages, patches etc It is the most updated client. But it is not allowed for any customizing and it is eligible for client copy to set up our company.


Client 001: It is a backup of 000 client. But it is not updated continuously. There is a variation between 000 and 0001 i.e. 0001 is not updated continuously. No 001 for 7.0 version. Client 066: It is an early watch alert client used by SAP to generate early watch alert report to the customer. In client 066 the report serve as recommendation to fine tune the system interms of expensive reports, transactions, SQL statements and users. Need for client copy: In order to adapt SAP systme to the requirements of the customer we need to perform customizing. But customizing is not performed in 000 client as it is a template client and client 001 is a back up client. In order to perform customizing we need to define our own client. When the client is defined it doesnt consists any data, so we need to copy data from the existing clients. Client 000 is eligible for client copy because it is continuously updated. Client dependant data/ client soecific data: The data which is visible only in that client is called as client specific data. Ex: User master Data, Application data, Customizing Data

1. The Purchase Orders whicha re created in a client are not visible in another client. 2. The users which are created in one client cannot login to another client. 3. The application like invoices, delivery notesa are client specific i.e. if you perform customizing in one client it is not visiblw in another client.
Note: The customizing which is performed in one clietn wont effect the other clietns. Client independent data/ cros client data: The data which is visible across all the cliet is called as cross client data (or) client independent data. Ex: Calanders, Measurements, Time Zones, Timings, Currency. If we perform customizing to the above it will be effective in all the clients. CCC: (Cross Client Customizing): The above one is known as cross client customizing. Repository Data:All the SAP standard objects are referred as repository objects (reports, Functional Modules, Programs, Transactions) etc


The changes t repository data will effect the entire R/3 system. Some times it may mall function and the system will be crashed. Because of applying chages, patches etc. Note: While changing the repository objects follow SAP recommendations and most of Repository Objects are locked for editing. If there is a need to modify the repository objects we need to obtain key from SAP. Customizing: It is the process of keying entries to the templates. Ex: Company name and address entries, sales organizations, employee datga applications such as material master data, vendor master data, customer master data. Customizing is performed in SPRO. User Exits/ Customer Enhancements: These provide an additional functionality to the existing structure (SAP objects). There are variou types of exits.

1. Field Objets 2. Menu Exits 3. Screen Exits 4. Functional module exits

Exits are identified in transaction SMOD and exits are created in CMOD CMOD: Create modification SMOD: Search Modification Applying the Support Packages and Patches: I order to fix the bugs (or) to have the enhance functionality support packages, patches are applied from time to time. SPAM is the tcode for applying the support packages. Development: These activities are carried out by ABAP development team. In order to develop our own programs SAP restricts to develop n th ename space Y and Z. The developers who are working in the object needs to be registered I the market place an obtain a developer key. Programs a dn reports are dedveloped I SE38 Transactions are developed in SE93 Screen are developed in SE51 Menus are created in SE41 188

Forms are created in SE71 Functional Modules in SE37 Repository objects like classes packages are created in SE80 These activities are purely done by the ABAP team. Changing the SAP Standard objects: In order to modify SAP standard objects we need to obtain object access keys from market place. These are also referred as SSCR. SSCR: SAP software change registration In order to modify the repository objects we need to get the following

1. Developer Key 2. SSCR key

Client Creation: Clients are created based on the following requirements as a post installation activity to set up demo, testing, tracing, production, quality clients. (SE06, SE16, SM30, SE03) Set up a client simulating production client. Client is created in SCC4. In order to create client we need to specify the following inputs.

1. Client number (Variable in between 000 to 999. Bu it should be used from the SAP reserver numbers. It should be unique in the system. 2. Specify the client number 3. Describe the client 4. Currency of the client 5. Location of the client 6. Roll of the client (Demo, Customizing, Testing, Production) 7. Specify client specific customizing is allowed or not 8. Specify cross client customizing and repository chanes are allowed or not 9. Protection level 0, 1, 2 10. ecatt is allowed or not.

By default from 000 999 total 1000 clients can be created. Logical System: In order to distinguish between various clients of different systems logical systems are defined and assigned to clients. Defining Logical System: Go to SALE Tcode (SALE: SAP Application linking and Enabling) Click on sending & Receiving system for further information click on logical system click on define logical system logical system click on define the logical system click on new entry. Specify the name of the logical system. The naming conventions for logical system are <SID>CLNT<CLINTNO> Ex: DEVCLNT200, QASCLNT200, PRDCLNT200 (Upper Case letters) Client Role: SAP defines client role to be specify the functionality of the client. 1. SAND BOX: It is a play ground where functional consultants will customize the requirements of the customers. It is represented as SAND. The changes which are performed in the system are not carry forwarded. This client is allowed for only client specific customizing. 2. Customizing Client: It is represented by CUST. It is also called as Master Client, Golden Client. This is the only client where client carry forwarded. This is the only client where changes are initiated and carried forward. This is the only client where client specific cross client and repository objects are modified. Note: Other than this client no clients are allowed to modify objects. 3. Testing Client: It is represented by TEST. This client is used for testing the customization which is performed in cust client. Transactions SCC1 is used to copy the change request from CUST client. Note: SCC1 is used to copy transport requests between the clients within the system. This client is used to test the modules which are customized and if the consultants approves it will be released. 4. Quality Testing Client: It is represented by QTST. This client is used to test integration between modules cross client object test and repository object test. It is also assured that all the objects are tested for quality stress etc Testing tools are deployed to test the objects in this client. Note: Each of the objects need an approval to move into production.


5. Training Client: It is represented by TRNG. It is used to train the end users of the company Note: Changes to ATST and TRNG are made by using transport request 6. Production Client: It is represented by PRD. This is the only client where the company data is populated by end users and production operations are carried out. Most critical client and to be secured in the landscape. Most critical client sensitive info (financial, pay roll, client) data migration.pre production client can be created additionally based on customer requirements. Change options available for clients (Client Specific Settings): Recording: It means saving the changes to a change request. 1. Automatic Recording of Changes: The changes which are performed in this client are automatically recorded to a change request. 2. No Changes allowed: changes are not allowed in this client. 3. Change without Automatic Recording: Changes will not be recorded to change request. 4. Changes without automatic recording, no transport allowed: Changes without automatic recording to change request and changes cannot be transported. Cross-Client Object changes: Changes to repository and cross client customizing allowed: The changes are allowed in CUAT client (or) master client (or) Golden Client. Protection Level: 0: No Restrictions. Client is allowed for client copy and client comparison is allowed. Client can be overwritten. Protection Level 1: No overwriting by client copy Protection Level 2: It is neither allowed for a client copy not for comparison between two clients. eCATT & CATT allowed: Restriction: The client should be always protected against upgrade unless we perform an upgrade Note: When the client is created an entry in table T000 is created without any data. We can logon to the client using USERID: SAP* and Password: pass in that particular client for client copy. Client Copy: There are 3 types of client copies: 191

1. Local Client Copy 2. Remote Client Copy 3. Client import and Export Pre Requisites of Client Copy: 1. Users should be working in the source client, reserve at least 2 background processes for client copy. Dialog process can also be used. 2. Logical system name should be defined and assigned to a client 3. There should be enough space in the DB (Table Space and enough disk space) 4. RFC connection should be defined between two clients to perform Remote Client Copy 5. Enough space should be there in Trans Directory to perform client transport 6. The sized of the client can be determined by using report RSSPACECHECK 7. Select the profile determine the type of the data to be copied from source client to target client. 8. Ensure that source and target clients are of in same versions in terms of O/S, DB, R/3. Note: BD48: Changing the logical system name Note: Size of the table can be determined using the reports RSTABLESIZE and RSSPACECHECK. These reports can be executed in SA38 T-Code Local Client Copy: Go to SCCL (SCCL is the tcode used for local client copy) Before client copy we have to create the client. This can be done using the table SCC4. Go to SCC4 from which we can create an entry in the table T000 (List if clients present in the system). Make entry for the client number, description, logical system name, application server and click on save. This will create the client entry i.e. client without any data in it. Now Logon to the Target Client go to SCCL select the profile Profile: It defined the type of data to be copied from the source client. We should use SAP defined profiles that starts with SAP. (Ex: SAP_APPL) 192

Note: repository objects will not be copied during the client copy (Local or remote) Select the source client from which the copy has to be performed. By selecting the Test Run we can perform a resource check. Simulation reads the extra data andif there are any problems with DB like space, and then simulation terminated the copy. Go to SCC3 for detailed log of the client copy.

Remote Client Copy: It is performed in transaction scc9. Select the profilego to profile select the source destination Repository objects can be copied Client specific data is copied RFC connections are defined in SM59. specify the system name Specify the host name Schedule it in the Background mode (or) dialog mode Perform a test run for simulation Then select RFC RCC (RFC) is between 2 systems LCC is between 2 clients Client Export and Import: When there is a necessity to copy a client from one landscape to another landscape client then we will use the export and import of the client. Client Transport is performed in 2 steps: 1. Client Export 2. Client Import


It is performed in SCC8. Client wont be copied into DB in turn it will be copied into transport directory in terms of Control Files and Data Files. Select the profile to define the type of data to be copied or exported. Specify the name of the target system and run it in the background mode. Note: Ensure that transport directory have enough space to host the data files and command files. Copy of the co files and data files to the target system and execute the following commands to import the data into the client or we can use STMS to import the client data. Copy the command files and data files into the target system. tpaddtobuffer <tr> <SID> <CLNT> pf=\usr\sap\trans\bin\tp_domain_<SID>.pfl tpimport<TR><SID><CLNT> pf=\usr\sap\trans\bin\tp_domain_<SID>.pfl tpactive buffer: It is used to add the contents to the target system in order to import any change request. It should be added to the buffer of the target system. During the normal transportation the object follow the transport routes and automatically added to the buffer of the target system. It is also one of the reasons for creating virtual system. Note: In 2 system landscape only consolidated route is there no delivery route. Go to STMSGo to Import select the system go to extras add transport request to import pool select the transport request click on semi loaded truck to import the request Post Processing of client transport: Go to Scc7 select the transport request select the profile name specify the export system <SID> schedule as a background process.

Customizing and Development:


While performing post installation activities the clients are created and populated with 000 template. Create users and assign them complete authorization to configure the system according to the requirements document. Customizing: It is a process of adapting the system according to the requirements without changing SAP standards. It is a process by keying entries into the templates or tables. Ex: Setting of sales organizations, company code, sales areas, plant storage locations, cost centers, profit centers etc. Whenever a change is initiated in the client which is set to automatic recording of changes a change request will be generated or changes will be added to the existing change request.

Common Transport Directory



QTST Trng 400 300 200

Pre Payroll 900


400 300 200

Note: Client copy always rewrites the target system. There is no method for client merging. If there are 1000 users in client 300 and there are 500 users in client 200. If the users in client 200 are to be copied to client 300 then all the 1000 users n client 300 are overwritten by client 200 users. So now there will be only 500 users in client 300. Authentication USER and PASSWORD TIN: Tax Identification Number Authorization What needs to be accessed and what not to be accessed. (Permissions to users)

Change Request: Whenever a change is initiated in the client which is set to automatic recording and change a change request will be assigned to the changes (or) a change request will be prompted to the changes.


No Changes Allowed Production client Automatic Recording of Changes Customizing client Changes without recording SAND, TEST Changes without recording TEST, QTST, TRNG No Transports are allowed Change request s created by project manager, project leader. Each change request created consists of one or more tasks which are in turn assigned to developers, functional consultants. Change requests are created in SE01. Change request can be copied from one client to another client using SCC1. Change Request Mechanism: Change request is created by project leader. Project leader defines tasks under a change request and assign it to developers (or) functional consultants Change Request naming convention will be like: <SID>K900001 <SID>KA00001 Tasks follow the same naming convention. All the tasks are located by developers (or) consultants I.e. the objects which are being assigned activity is completed the developers/consultants will release the task. If the task is released the objects can be used by other people (or) other team members. Change request numbers are stored in table E070 Tasks follow the same naming convention. All the tasks are located by developers (or) consultants i.e. the objects which are being created / modified are locked to that user. Once the assigned activity is completed, the developers / consultants will release the task. If the task is released the objects can be used by other people (or) other team members. Change request numbers are stored in table E070. If one of the tasks is locked y the user and left then change the owner of the tasks based on the approval (or) instruction. Release the task as administrator. 196

A change request has many tasks and each task is assigned to one developer and the developer locks the table. Tasks are released by developers/ consultants in SE01. Once all the tasks are released the change request can be released by the project leader. Types of Change Requests: 1. Customizing Change Requests: This change request is to save the changes related to client specific settings i.e. changes are related to a particular client. These changes needs to be imported subsequently into all the clients in the landscape. Ex: User master data, Sales Area, Company Code, Sales organization, Application Data and Customizing Data. 2. Development: When the customizing does not fulfill the user requirements we need to perform development. Development involves creation of tables, files, reports, programs etc. Field: It is nothing but a column in the table. In SAP table fields are created as domains and data elements. Domain: It defines the technical characteristics of a field or as 1. Type of field (whether it is num, int , char..) 2. The length of the field. Domain helps us to keep the relative fields consistent throughout the system. Data Element: Data element is defined in the table pointing to a domain in precise meaningful name to the domain. Table: Table consists of columns and rows. Columns contain the name of the data elements and rows contains the data. There are 3 types of tables. 1. Transparent Tables 2. Pool table 3. Cluster Table Transparent Table: These represent 1:1 [ABAP dictionary to oracle] to DB. If there is one table in DDIC then there will be one table in DB. 197

Pool Table: A group of related tables pooled into a larger table. Cluster Table: Group of tables clustered together. Tables, Data Elements, and domains are create in transaction SE12. SE System Engineering. They should be created in the namespace of Y and Z only. Screens: Screens are created in transaction SE51 MENU: Menus are defined in SE41 Programs: Programs to read the contents of the screen and consider the activities of the menu. SE38 is the T-Code used to create, modify display the programs. In order to define the programs to take the runtime values and calculate the values functional modules are defined. Functional modules provide reusability of functions. These are defined in SE37. In order to execute the programs use transaction SA38. As it is very hard to remember the programs names, the programs are assigned to transactions. Transactions are created in SE93. Note: Transactions are stored in table TSTC. Cross Client Customizing: The customizing related to the entire system such as currency settings, time zones, calendars etc. These are specific to the entire system. All the above changes need to be imported only once on the target system irrespective of number of clients. Work bench Change Request: The changes related to work bench [development, cross client customizing] are saved to change request of type work bench. Transport of copies: In order to transport a table definition or table content, transport of copies is used. Ex: When we want to retain client settings such as user master data during a client refresh. User master record is saved as transport of copies and imported after a client refresh. Identify the table to be included as transport of copies save it, release the change request. It is exported to TRANS directories. It can be imported into the client again to get the table entries back. Relocation of objects: The objects can be moved from one system to another system with development class (or) without development class. 198

Change Request Mechanism: The objects cant be copied from one system to another system using traditional means because it is difficult to identify what objects are changed and where they are located. That is the reason whenever there is any change it is recorded to change request. Change request consists of the change made to the object. Change Request Release: When the tasks are released in as change request the change request is eligible for release. The change request can be released to another change request. When a change request is released the changes from the objects are bundled into data files. When a change request is released transport protocol tp records the change requests and copy the relevant changes into a data file and move this file into transport directory. The data files also have control files and these files are copied to co files. Data Files: It consists of the changes to the objects. It starts with naming convention as follows. <SID>R900009 Ex: DEVR00009 Command Files: Co files It stores the commands to be created while importing the change request. Its naming conventions is derived from change request no DEVK900009. There will be exactly one command file for one data file. SAP Names: When the change request is released the name of the developers and the change request number is populated into this directory. Log: It will store the logs of export and import. Buffer Directory: When a change request is released based on the routes definition it will be added to the import buffers of the target system. If the routes are not defined we need to explicitly add change requests to the buffer using command tpaddtobuffer. That is the reason we will configure the landscape. Development Class: It is a group of objects such as reports, function modules, programs, transactions etc. Development classes are defined in transaction SE80. While defining a development class we need to assign it to a transport layer. Development class is required to develop the objects. While developing objects such as reports programs, functional modules etc we need to assign them to a development class. Development class should start with either Y or Z. The 199 R denoted data file.


objects which are assigned to $tmp class are saved as local objects and cannot be transported. That is the reason we need to define a valid development class and assign them while developing objects.

Change DEV Class Program Importing a Change request:

Transport Transport Either Consolidation (or) development (or) QAS (or) PRD

The change requests which are released are stored in trans directory in the form of data files and co files. These are available for import into systems in the landscape based on buffer entries. If there are no buffer entries we need to add manually using command tpaddtobuffer. Change request once released are called as transport request. Transport requests are imported using STMS. Importing a transport Request: Go to STMS Select import Queue of the selected system select the transport request request can be imported as a single, mass or a group of change requests. Change requests can be triggered immediately (or) at a later time. Disabling the folly loaded truck: Go to STMS click on the systems select the system go to transport tool change insert row No_Transport_ALL save it. SE38, SE41, SE71 Programs, Functional Module, Reports, Transactions SE80 Developm ent Class Transport Layer Data Files Co Files Transport Route Buffer SAP Names 1 Development C.C.C WB Request E070 200 EPS BIN TMP LOGS

Released TASKS 2 C.B.Customizing 3 Transport of Copies Select the object Table Structure Table Content Manual tp: tp can be called from command line by using executable tp.IN order to execute tp path to kernel directory has t be set in the environment variables. Tp version is displayed using command tp. Type tp help to find out the various options of tp C:\> tp help tpaddtobuffer will add a request to the buffer tpcleanbuffer cleans the buffer tpdelete from buffer deletefrom buffer C:\>tpaddtobuffer tp return code: 0,4,8 o Transport request import is successful 4 Transport request is successful with warning 8 and above Errors Import Errors: 1. Tp error 212 could not connect to DB The objects which are imported into target system could not over write because the ojects are locked. SAV Releas CUST Request DEV/ Functional Consultants


Imports cannot be reverted back. If we want to revert back develop another change request release it and import it into the system. 2. STMS is not configuredTp version is outdated. [Upgrade tp version] 3. In order to check tp connectivity execute command R3trans-d which generates trans.log in the current directory. Trans.log gives codes and the error description 4. RDD*JOBS could not be executed due to lack of background resources. Check background jobs in SM37

tp import mechanism: When a transport request is imported tp is initiated and reads the contents from trans directory and connects to the database tp calls R3trans [R3trans is an executable which performs the transport] to execute the import task, to connect to DB tp documents all the import steps in tables TRBAT and TRJOB tp also triggers RDD* Jobs.

RDD * Jobs


TRBAT, TRJOB Documentation tables tp R3trans

RDD* Jobs reads all the steps from tables and executes them. MTP (Move to Protection): 202

In order to move the transport request t production system we need to schedule down time. The changes which are approved in the quality system are available to move into production. In order to avoid inconsistency between objects these are moved during off peak hours. In major enterprise where there are huge transports, transport strategy is defined like transports will be moved on every Sunday, first week and the last week of the month. During MTP we need to define the escalation table. 1. Valid backup is required to restore incase of problems during transport. 2. Identify the people (Consultants, developer ..) 3. Key persons responsible and assign tasks. 4. Lock all the users except the ID to be involved in transportation 5. Perform transportation of objects 6. Release key business users to test the functionality. If the functionality works fine, release other users else revert back with alternatives.


TEST 300 200

CUST 400

Optional 300 200


QTST 900 C.C.C

C.C.C Repository

C.C.C Repository Repository

DEV 1. Customizing 2. Development Three system Landscape.

QAS Consolidation Route

PRD Delivery Route

QAS: In QAS objects are imported tested for quality integration testing. Imports are also performed subsequently in training client and other optional clients. Testing tools are deployed to test the load on the objects. Simulation of users to check the performance of the objects is performed. If the objects are approved in terms of 203

quality [integration, stress and performance] the approving officers will document a list of transport request along with scheduled date of release and time, into the production system. Training for the users is common in the training client. Next move to production (MTP) is carried out. Note: No transports will be moved without approval. Preliminary Imports: These are emergency transport request which are moved independently without following MTP. Preliminary imports will remain in the queue even after the transport. This transport is again transported during MTP. Approval is required to perform a preliminary import. Current Settings (customizing): Even though system is set to not modifiable and client customizing doesnt allow any changes. In a production system we can change some of the entries like tax, currency information transactions. These changes are carried out on the production system by authorized consultants without any change request. Support Packages and Patches: During the implementation (or) post production support whenever there is a gap in functionality (or) functional consultants request for enhanced functionality support packages are applied. There are various types of support packages and each support package has its own released life cycle. Support packages should be applied in the sequence. Pre Requisites to apply support packages: a. Always apply the support packages in client 000 using user like DDIC. b. Apply the support packages in the sequence of landscape [First in DEV, next in QAS and finally in PRD] c. Apply the support packages in the following order SAP_BASIS, SAP_ABAP, SAP_APPL, SAP_HR d. Always apply the support packages in the sequence such as 1,2 3, 4. Ex: SAPKB64001, SAPKB64002 Download the support package queue i.e. a group of non conflict packages can be applied together. Ex: 1 & 2 can go together SAPKB64001 SAPKB64002 SAPKB64003 SAPKB64004 SAPKB64005


Note: Known problems related to support packages file can be downloaded from the service market place before applying the changes to the system. e. Download the recent notes with search criteria known problems related to support packages of version XXX f. SPAM and SAINT versions should be updated. SPAM and SAINT have their own versions. SAINT SAP add on installation tool. SPAM Support package manager. These tools are used to apply support packages and add on installables. g. There should be enough space in the TRANS/EPS directory. EPS Electronic parcel service. EPS hosts all the support packages h. There should not be any aborted packages. i. j. Developers and functional consultants should be around to handle the change with support packages. SPDD and SPAU are the places where data dictionary (DDIC) and repository chages are made.

k. There should be enough space in the DB l. If the support packages are less than 10 MB apply through presentation server and if it is greater than 10 MB apply through application server.

m. There should be at least two background processes to apply the support packages. n. Ensure that STMS is configured o. Users should be locked and this should be performed in off peak hours p. Ensure that valid backup is available Upgrading the SPAM/SAINT version: 1. GO to SPAM support package manager 620/ 0022 2. Go to SAINT SAP add on installation tool 6.20/0022 3. 6.20 is the ABAP version 0022 is the SPAM & SAINT 4. Go to SAP market place www.service.sap.com/swdc 5. Go to support packages & patches Select SPAM & SAINT versions 205

6. Download the SPAM latest version and SAINT latest version into your desktop. 7. Go to Support Packages Load package from front end specify the path of the download file .car and .sar (Sap Archive) 8. Select the downloaded file. It will load into the system. Note: The package is only loaded but not applied. 9. Now go to support package select import SPAM objects 10.SPAM and SAINT can be applied in arbitrary order. Applying Support Packages: Logon to client 000 using user like DDIC. Download the support packages from market place. The available options are: SAP_BASIS, SAP_APPL, SAP_HR, SAP_ ABAP.. If the support package is less than 10 MB size apply through front end. Load package through front end. Note: If the network connectivity is slow (or) if the support package is more than 10 MB of size then always use application server. Load the support packages. It reduces the time from presentation server to application server. How to apply from application server: Download the .car/.sar files from the market place into trans directory. Trans\eps\in. Use command sapcar xvf SAPKB62026.car (or) sapcar xvf SAPKB62026.sar Note: Earlier the command was only sapcar The file will be uncompressed into the directory \usr\sap\trans\eps\in The files that we will get are .ATT and .PAT ATT: Attribute file PAT: Patch file 206

Select the new support package and display. New support packages which are loaded are displayed. Select the support packages to import. In order o select the support packaged define the queue. For defining the queue click on display queue and click on define Select the support component for which the support packages have to be applied. Queue is displayed select a single packages or a group of packages based on the composite note recommendation. Go to support package and import. Click on import queue to import the support packages. Note: The support packages once applied cannot be reverted back. Before applying the support packages check all the requirements are fulfilled. Problems occurred during applying the support packages: 1. Conflict patches are grouped together 2. There are aborted packages 3. SPAM and SAINT are not updated 4. eps\in directory has not enough space. 5. DB table space out of space (or) table space over flow with errors ORA_1653, ORA_1654 6. DB max extends reached with error ORA_1631 and ORA_1`632 7. There are no enough background processes available. 8. Extended memory is not enough to import the support package 9. tp and R3trans are out dated (We come to know about this when the screen cannot move) 10.Ensure that outdated are not locked by the users 11.Data dictionary activation errors 12.Conflict with the add-ons 13.tp could not connect to the database (Execute R3trans d)


Note: Tables used are PAT01, PAT02. Do not delete entries from these tables unless there is a SAP recommendation. 14.Check the status of the support packages imports in SPAM. Click on import logs. Logs can also be displayed in trans\log 15.Support packages can be re imported from the point where it terminates. SPDD Phase: It is used to update the DDIC elements While applying the support packages it will prompt you to run SPDD. It is decided by functional consultants to keep the existing changes to adapt the new changes which come with new support packages. Do not run SPDD without the concern of development team. SPAU Phase: It is similar to SPDD, but it is related to repository objects. CRI: Conflicts resolution transports. These are released by SAP to resolve the conflicts between SAP support packages and add-ons. The following are the phases that include the support package implementation.
The Support Package Manager informs you of the status of the phase currently being executed in the status bar. If you want to know which phases are executed for which scenario (test or standard scenario), run the program RSSPAM10. The following list provides an overview of all the modules and phases and lists them in the order in which they are executed by the Support Package Manager: Preparation Module

1. PROLOGUE This phase checks whether you are authorized to import Support Packages. 2. CHECK_REQUIREMENTS This phase checks various requirements for importing a Support Package, for example, whether the transport control program tp can log on to your system. 3. DISASSEMBLE This phase unpacks files from the appropriate EPS parcels and saves them to the transport directory. 4. ADD_TO_BUFFER This phase places the queue in the transport buffer of your system. 5. MODIFY_BUFFER This phase prepares the transport buffer for correct processing of the following import phases. 6. TEST_IMPORT This phase performs a test import for the queue with the transport control program tp. The system checks whether there are objects that are in open repairs and that are overwritten during the import, or whether other conditions prevent the import of an object. 7. IMPORT_OBJECT_LIST


This phase imports the object lists for the Support Packages in the queue into the system. 8. OBJECTS_LOCKED_? This phase checks whether there are objects that are overwritten by the import, and that are still in unreleased requests. 9. ADDON_CONFLICTS_? This phase checks whether there are conflicts between objects in the queue and any installed add-ons. 10. SCHEDULE_RDDIMPDP This phase schedules the transport daemon (program RDDIMPDP). Import 1 Module 11. CREATE_VERS_BEFORE This phase generates versions of the objects that are contained in the Support Packages in the queue (if this option is set). 12. SPDD_SPAU_CHECK In this phase, the system checks if a modification adjustment is necessary (transactions SPDD/SPAU). 13. DDIC_IMPORT This phase imports all ABAP Dictionary objects in the queue. 14. AUTO_MOD_SPDD This phase checks whether all modifications to ABAP Dictionary objects can be adjusted automatically. 15. RUN_SPDD_? In this phase, you are asked to adjust your modifications to the ABAP Dictionary objects by calling transaction SPDD. 16. LOCK_EU (only for import mode downtime-minimized) This phase locks the development environment. 17. INACTIVE_IMPORT (only for import mode downtime-minimized) This phase imports program code and program texts in an inactive state. 18. DDIC_ACTIVATION This phase activates the imported ABAP Dictionary objects. Import 2 Module 19. IMPORT_PROPER This phase imports all the Repository objects and table entries if they were not already imported in the INACTIVE_IMPORT phase. This is preceded by actions such as table conversion and activation of the name tabs. 20. PREPARE_XPRA This phase prepares the execution of the XPRAs and after-import methods. 21. UNLOCK_EU (only for import mode downtime-minimized) This phase unlocks the development environment. 22. AUTO_MOD_SPAU This phase checks whether modifications can be adjusted automatically. 23. XPRA_EXECUTION This phase executes the XPRAs and after-import methods. 24. ABAP_GENERATION


This phase generates the runtime objects for the imported Repository objects (ABAP source texts and screens). Clean Up Module 25. RUN_SPAU_? This phase prompts you to adjust your modifications to Repository objects by calling transaction SPAU. 26. CLEAR_OLD_REPORTS (only for import mode downtime-minimized) This phase deletes the obsolete versions of program code and program texts in the database. 27. EPILOGUE This phase completes the import. Among other things, it checks whether the queue has been processed completely.

Applying the Plug-In: Fabrication Pharmacy Textiles Standard Modules SD,MM, PP Additional PI_BASIS /willsys /VIRSA /SATYAM (Third party tools) SAP shifts (or) SAP comes with standard functionality such as MM, SD etc.. In order to provide additional modules such as banking insurance business content (BIW), textile, mining, pharmacy etc. In Order to apply these plug-ins (Solution tools plug in). It is used to provide solution based on CCMS or EWA (early watch alerts).

CCMS: Computing central monitoring system. 1. Download the add-ons from the market place. 2. Download the documentation related to add on 3. Download the installation guide and important notes 4. Document all the steps 210

5. Ensure that all the pre requisites are met. Ex: BIW_BASIS should be of level5 SAP_BASIS should be 16 SAP_ABAP should be 14 STPI and PI_BASIS should be 2003 and 2005 (STPI-Solution tool plug in) 6. Read the note thoroughly and get the password, key word, key from the note to install the add on 7. Pre requisites and problems are same as support packages and patches 8. Download the content onto transport directory 9. Uncar the content using SAPCAR-xvf *****.car 10.Go to SAINT lad the package. Package is displayed on the screen. 11.Select the package (add on package)to install. 12.Click on continue 13.A pop up box is displayed to go through the note and key in the password to continue the add on installation. 14.Continue the add on installation 15.There are chances for conflicts between the existing support packages then it will ask you to configure CRT. 16.Respective CRT need to be downloaded and need to be applied by using tp. (Transport, background jobs, Security) Note: SAP NOTES provides valuable information for resolving eh run time problems. SAP maintain abundant knowledge base of notes. Notes are related to customer problems and solution, break fixes to the standard functionality and minor enhancements. SAP Notes are of 3 types: 1. Informative Note 2. Corrective Note (Manual) 3. Corrective Note (Automatic- using transaction SNOTE) Informative Note: This note provides information to the customers as follows. 211

1. Production information 2. Composite note for support packages 3. Notes for add-ons 4. Query related solution Corrective Note (Manual): SAP recommends changes to be performed on the system during the following scenarios 1. Changes to table entries such as tags, vat etc 2. Changes to wage types 3. Changes related to tables 4. Recommend to resolve the issues (Table space overflow, Max extents list, Archive struck, Work process congestion) Corrective Note (Automatic): (Patches) Up to version 4.6c all the changes to SAP system are performed manually. From 4.6c onwards SNOTE is used to apply the changes automatically without any developers intervention and SSCR key. Most of the changes are related to Sap standard objects. Applying Note: 1. Go to market place (www.service.sap.com/notes) 2. Download the correction in the note onto your desktop 3. Go to SNOTE. Upload the note. (When it is uploaded the status will be new) 4. Select the note to implement. Now the status is in processing 5. When it is implemented status is implemented 6. Some of the notes cant be applied and some of the notes status will be obsolete(Outdated). Note: Notes consists of corrective coed, which will append to the standard programs containing the necessary code, where as support packages overwrite the code. Group of notes and patches are called as support packages. Note: Notes once applied can be reverted back. Notes can be downloaded directly connecting to the market place.


Go to SAP market place. Until SEP 2005 there was not that much significance for market place. Before SEP 2005 we use OSS1 TCODE for downloads. OSS1 is a transaction which is used to perform the following until SEP 2005: 1. Creating customizing 2. Searching the notes 3. Download the notes 4. Download the license keys From SEP 2005 onwards SAP decommissioned using the TCODE OSS1 and recommended to use SAP MARKET PLACE. SAP Market place is built on EP (Enterprise Portal) which is used to connect between employees, customers, partners and users. It requires SUSER ID to login. It consists of 10 digits preceded by S and 2will be like S000123456. Market Place provides the following Services: 1. Notes: This can be searched based on error description. Only SNOTES steps are documented. Notes are always named with numbers. 2. Customer Messages: The runtime problems which could not be resolved can be escalated to SAP Click on customer message.


Select the system for which help message needs to be created. Enter the error message. SAP advices to search and look for the resolution among the display notes. Enter the error message. SAP advices to search and look for the resolution among the display notes. If there is no resolution continue customer message. Upload the relevant screen shot Click on save and send it to SAP Note: We can define the priority of the issue such as normal, medium, high, very high. High and Very High are considered first as the production system is in danger which causes business loss. Software Download (SWDC): 214

It is used to download support package, installation DVDs add-ons, plug-ins, kernel executables, 3rd party tools, DB patches etc

KEYS: There are 4 types of keys which can be generated from the market place. 1. SAP LICENSE 2. DEVELOPER 3. SSCR 4. MIGRATION SAP LICENSE Key: In order to apply license to the SAP system we need to generate license key from market place. Before generating a license key the system needs to be registered with SAP. [The following information needs to be given for registering with SAP: Customer Number, SID, Installation Number, Instance Number, Host name, Hardware Key] 215

The system which needs license needs to be registered. System data has various information such as IP address, system name and router port. Select connection and open it to SAP for specific number of days for remote connections.


Developer Key: [<SID> Developer name]




Migration Key: Whenever we are moving from one operating system to another operating system (or) from one DB to another DB we need the migration key.


Client Comparison: When you install add on packages like country India version(CIV) the changes effect only in that client through which its applied. CIN is an add-on which is used to bring the changes related to taxes, wages etc. It was earlier version. Now it is coming along with standard SAP software. Functional consultants identify the changes related to these functionalities and compare the entries in respective transactions and merge them. Select the entries and merge system prompt to record the changes to a change request. SAP Router: SAP router is a software program which runs on the application server. It runs as a service and maintains access control list in a table SAPROUTETAB. It is a text file which maintains the IP address, permit, deny and port numbers(Not a DB table). Permit P 3600 Deny D 3600

Configuring SAP Router: GO to www.service.sap.com/saprouter and download SAP Router executables into c:\> (drive)and saprouter (folder). SAP ROUTER is an executable present in the run directory and ensures that the version of the SAP router is always updated. Download the files into SAP router directory send the details to SAP to establish the remote connection. encrypt.pse are given to the customer. In that a key is available. Run the encryption and key in the SAP key and get the key to sap. Once the connection is opened we can TELNET to SAP server. In order to start the SAAP the command is Start: saprouter R Stop: saprouter S Create the SAP router, start up as a service using NTSCMGR In UNIX: $PRONJOB, ALL_ACCESS control list. In order to open the connection SAPROUTER must be running.


The screen shot is an initial screen page for SAP ROUTER of the market place.


PRE GO LIVE: Before the system goes live SAP logs into customer system and evaluate customizing and development. Pre Requisites: 1. The system needs to be registered in the market place 2. SAPROUTER is defined and connectivity is established 3. Customer has to send the necessary information to SAP (Name of the company, Name of the persons, Email Id and Phone Number) 4. No of modules configured 5. O/S, DB, R/3 system type There are 3 types of Go LIVE check conducted by SAP 1. GA- Go live analysis 2. GV- Go Live Verification 3. Go- Go live optimization We need to inform SAP preferably 2 months or at least 1 month before Go-LIVE to conduct the above checks. Go Live Analysis: This is the first check conducted by SAP to determine the following: 1. Critical Transactions 2. Expensive Programs 3. CPU utilization 4. Memory Consumption 5. Back Up Configuration 6. Scheduling standard jobs 7. Critical interfaces 8. Utilization of buffers 9. Hard Ware configuration 10.Dialog response time 222

SAP studies all the above and recommends the measures for tuning such as 1. Relocation file structures 2. Configure memory parameters and buffer parameters 3. Work process configuration 4. To create indexes like primary indexes and secondary indexes 5. Run the check optimizer statistic schedule it in the standard background jobs (House Keeping Jobs). 6. Defining the backup 7. Tuning the expensive programs and SQL statements 8. Moving the long running programs into background mode. Note: Large installations should inform 2 months before Go Live (or) at least 1 month. Small installations should inform 1 month or at least 15 days before the Go-Live. SAP recommends the changes to be performed within 15 days. Go Live Verification: This session has to be scheduled after the Go Live analysis session. This will be conducted by SAP technical consultants to verify the changes that are recommended in GLA system. If the changes are related to Hardware it will highlight during this phase. Note: SAP verifies the parameters and recommends further changes on the system configuration on the day off session. Go Live Optimization: This session will be conducted after Go Live (After 1 month of Go live). This is used to analyze the load on the system. (How many users logged on, Critical transactions and critical programs) and recommend further changes to optimize system performance. Parallel Run: Data Migration: Most of the Customers define a migration client to perform data transport from legacy systems. The data is migrated and tested for its quality before moving to production. The data migration, parsing truncating is performed in the migration client. 223

End User Training: Before Go-Live the production users are trained on all the processes such as creating P.Os, Invoices, Billing, Pay Roll Run and training client of QA system. Note: As the users are not habituated to SAP systems, we will uses to work on both the systems (Legacy and R/3 systems). As a company policy it may be allowed to use only fewer modules on the production system and remaining on legacy systems. In the above scenario parallel run of both SAP system and legacy systems are advised. During parallel run legacy system and R/3 system run together, the data from legacy system is transported periodically, hourly, and daily to synchronize the data between two systems. JAVA MM PP ORACLE HR FI SAP CO


Go Live 1 st Apr09

1st May09SD,MM

Daily/Hourly Transfer 1st June 09 PP,HR Modules are run in parallel in both systems

FI/CO (running on SAP)

Now the other modules (SD, MM, PP, HR) are also cancelled in the legacy


Systems. Now the modules run only in SAP system. 1st Jan 2010 All Modules are running only on SAP system from here onwards

USERS and SECURITY of SAP System Name Employe e Code Departm ent Address Employe e Salary Appraisa l Bonus

Designa tion HR Clerk HR Manager Project Manager Director Employe e


Empco de

Departm ent

Addres s

Emp Salary

Apprai sal


Employee can see his own details. But he cannot change any other entry. He can see details of other employees. Director can change create (or) display all the entries in the table. He can see/ change details of all the employees. Project Manger cant create the first four entries (Name, Empcode, Department, and Address). He can only see them. He can create/change the other 3 entries.


Authentication: It is the means of providing access to the system i.e. User ID and Password. Authorization: It is the means of providing access to system functions to the authenticated users. In order to provide various accesses to different people in the organization we need to define Roll Matrix (or) Authorization Matrix. Roll Matrix (or) Authorization Matrix: It is a table which defines the critical transactions, access levels and the rolls. Authorization Field: The data element (or) a field in the table which needs to be protected is called as authorization field. Authorization fields are created in transaction SU20. Ex: Employee Salary, Bonus, Discount, Sales Order Amount, Purchase Order Amount etc. Activities: It is the action that can be performed on an Authorization Field. Activities are as follows: Create, Display Modify/Change

Delete Print Reverse etc Activities which are available in the system are shown in the table TACT. By default there are aroune 170 activities defined in this table. Note: We can create our own activities in table TACT. Authorization Objects: A group of not more than 10 related authorization fields is called as authorization object. Authorization Fields and Activities: The list os possible activities for each authorization objet is defined in the table TACT2


Authorization: Authorization field and its activities are referred as authorizations. It is also referred as field and its value. Authorization Profile: A group of not more than 150 authorizations is called as authorization profile. Note: Up to SAP 4.6 B version profiles are created manually, but from 4.6C onwards profiles are generated while creating roles. Composite Profiles: Group of profiles is called as composite profiles.

Role: A role is a combination of profiles, transactions, reports, menus, personalizations over assignment. Roles are defined in transaction PFCG. Composite Role: Group of one or more roles for administrative ease is called as a composite role. It doesnt provide any additional functionality. Derived Role: The roles derived from a parent role, but differ by organizational levels. These restrict the functionality based on organizational levels. Parent Role: It is a single or generic role which is having authorizations to inherit to child roles/derived roles. Defining a Role: Go to PFCG Specify the name of the role Create, change (or) copy role Authorization field and Authorization objects are cross client objects. Description of the role Go to Transaction to include standard transactions Go to menu to include reports, URLs, create folders etc create click on change, authorization data specify organizational levels such as company code, sales orders, organization sales area, distribution channel Authorization objects, fields, authorizations are displayed 227

Include authorizations objects manually Red means organization levels are missing Yellow means field value activities are missing. Green means totally organized.

Click on the traffic light. Then you will get the complete/full authorization. (Pop up box will be displayed). Provide field values, activities according to SOD matrix. (SOD Segregation of Duties) Save and generate profile Save the role and assign it to users. Perform user comparison, so that role will be effective in the user master records. The role wont be effective until we run user comparison Note: In earlier versions the user has to log off and log in to get the effectiveness of the new role assigned to him. But in the current versions after user comparison the role is effective automatically. Note: Performing user comparison during role creation consumes more time. So perform the user comparison in the background mode during off peak hours. PFUD: This is used to perform user comparison in the background mode (or) schedule a report PFCG_TIME_DEPENDENCY to perform user comparison in the background mode. Initializing Profiles: (Filling the Customer Data) When a client is created we cannot perform role creation without filling the customer tables. The tables used are USOBX and USOBT. Go to SU25 click on initially fill customer table. The relation between the transaction and the authorization object s can be displayed in SU24. SU24 is used to define the relation between transaction and authorization objects.


Authorization check indicators such as unchecked, not maintained, check check and maintain. When a transaction is initiated it will check in the assigned program Authorization objects are created in SU21 Development class> packages SM30 table maintenance if the table maintenance is allowed we can create entries manually. Activity Table TACTZ

Up to 10 authorization objects [SU21/SU22] (Authorization Field)

in SU24

Authorization object classes

Transactio n Role

Assigned Users PFUD/PFCG

Profile/Composite Profile

PFCG-Time PFCG SU01 UMR-User Master Record

Example: Purchase order Activities are: Create, Modify, Delete, Reverse, Approve, Release (These activities are listed in table TACT) Roles are added in table AGR* When the user is logged into the system request goes to the DB and gets the necessary authorizations from the user master record (USR02) and keeps a copy on the user context. This user context is displayed in transactions SU56. When a user executes a transaction it points to the program. Program in turn points to authorization objects inside it. Authorizations are programs busing statements authorization_check_ followed by the authorization object, field value and activity. These are all checked against user buffer (SU56). If they are available user is allowed to perform transactions else user is not authorized to run the transaction.


Missing Authorization: Very frequently help desk receives calls related to missing authorization when a user could not access a program over a transaction. It is referred by the user as Missing Authorization. Missing Authorizations are caused by the following: 1. User is not assigned with authorization 2. User is assigned, but user comparison is not performed 3. User to roll assignment is expired 4. User buffers are old (or) over flown Analyzing Authorizations: Transaction SU53 is used for analyzing missing authorizations of the respective user. Check the missing objects in the user master record. If the role Is already assigned perform user comparison. If the role assignment is expired then send a mail to the business process owner. User raises a ticket of missing authorization ask the user to execute the transaction again and send the screen shot of SU53 screen. Note: In every organization SU53 TCODE is assigned to the every user. If the role is assigned recently and user comparison is not performed then perform user comparison. Note: Use SUIM (SAP User information management. This information transaction gives you all the reports related to SAP security. Some of the reports are user to roles, roles to transactions, user to profiles. Standard password reports, user change documents (last logon date, last password change, list of users locked). Basically SUIM uses (or) calls RSUSR* SA38 is executed. In SE38 all the engineering can be done Go to SE38Key in RSUSR* Press F4 to display the list of possible reports Scenario: Authorization is not assigned to the user User complains of missing authorization


Purchasing officer Create a material Create a P.O

Sales Officer Create S.O

Plant In charge

Warehouse In charge Stack Maintenance distriution

Write to the business process owner to approve the missing authorizations assignments. Wait till get the approval. Note: Always assign only requested authorization to the users. Do not assign excess authorizations. Authorization Objects, Authorization Fields and Field values cannot be assigned directly to a user. Generated profiles can be assigned indirectly by assigning roles. All of the above can be combined in the role and assign it to the user. Role Mitigation: It is performed by using third party tools like VIRSA, BIZRights Role Mitigation is used to mitigate the following 1. What worse will happen by assigning the existing role to the user? After mitigation it will giva report of excessive authorization. Send the list to the Business Process Owner and get approval. Roles consists of many authorizations. Ex: Purchasing Officer Role Create Material, Create P.O etc.. are the authorizations of the role. Now if a user wants authorizations to create a material and if we assign the whole role i.e. purchasing officer to that user, then he will get excess authorizations. 2. Identify the least effected role by mitigating fewer times and assign that object to that role (Save the role, generate the profile, assign it to user, perform user comparison). If both of them are not allowed then write to the manager approval to create a role.


Create Role, assign the authorization object, save and generate profile, assign it to the user and perform user comparison. Barbanes Oxley Procedure: SOX 404 act. It is implemented in most of the public limited companies in the U.S to safeguard the applications. SAP uses the above tools (VIRSA, BIZRights) to mitigate when modifying a role (or) assigning a role to the user. VIRSA has become internal part of SAP and comes as an add-on. Transaction SU99 is used to specify which of the transactions should not be combined. These 3rd party tools are also used for the following : 1. Auditing Purpose: Who has done? What he has done? When e has done? Example: Consider P.O Who has released P.O, Who has created P.O, When is it created, All the details are given in auditing. 2. Mitigating between the Roles and Users 3. Identifying (or) tracing out incoming and outgoing documents Ex: We can get across control to that P.O creations, TIN, bank account number, address, telephone number, fax number, match with P.O receivers. 4. User Management: User Creation: Users are created in transaction SU01. SU01 is used to create, modify, lock, unlock, copy and delete the users. SU01 is used to create single user. SU10 is used to create mass users with some privileges

Types of users: 1. Dialog User 232

2. System User 3. Communication User 4. Service User 5. Reference User Dialog User: Is the on e where interactive logon is possible. These are calculated for license. System User: Is used to communicate within the system in the background mode. No interaction logon is possible. Communication User: It is a non dialog user where interactive login is not possible and used to communicate between 2 systems using RFC connection. Service User: This is anonymous user, which is used by group f people where dialog logon is possible. No password, USER ID Ex: Top view the company targets Reference User: It is used to provide additional rights to interact users. Ex: Users connecting to the system over the browser will have limited authorizations (EP). Once authenticated the rights will be assigned to the reference user. SOD: Segregation of Duties It is an authorization matrix (or) role matrix. Segregation of duties is performed while implementation (or) duing support, business process owners define the key roles in the company along with the activities which are performed in the system. It is a matrix of Roles & Transactions. It is used to define the transactions in the company.

The following table is an example of the role matrix or authorization matrix. 233








Questions: 1. What are the standard roles available in the system. Name some of them along with description (at least 10) 2. Name some of the profiles, composite profiles, authorization objects, authorization fields, composite roles, derived roles. 3. List the users with critical transactions 4. Display all the available users in the system User Creation: Users are created in transaction SU01 SU01 has the following tabs: Address Tab: It provides the details of the users like first name, last name (It is mandatory to provide email and telephone number) Logon Data Tab: It specifies the validity period, specify the type of the user


User Group: These are defined in SUGR. These are used to group the users based on department or division or roles for easy maintenance. By default super group is available in the system. User Group for authentication Check: If we specify a group the user is allowed to be administered by the user of this group only. Super user group admin is allowed to administer the user belonging to all the groups. Specify the password. Default Tab: Specify the start menu Specify the logon Language Specify the printer settings like O/P device, O/P immediately or release after O/P. Time Zone: Decimal notation and date format Parameters: These are frequently used fields which will be popular during the run time of the user Define the run time of the user. Define a parameter Go to the field Press F1 go to technical properties Find the parameter ID Go to SU01 Click on parameters tab specify the parameter and parameter value Roles Tab: These are used to assign authorization to the users. We can delegate additional rights by using reference users. Profiles Tab: These are going to be combined in the roles. There is a specific profile which can be used like SAP_ALL, SAP_NEW needs to be documented. Use only either roles or profiles. Groups Tab: These are created in SUGR used to group the users for administrative purpose. Presentation: It is used to restrict the user access such as time in and time out of the current day. Sales of the day and sales of the week, pay slip of the month.


Personalization Tab:

Personalization is a way to save information that could be common to users, I meant to a user role... E.g. you can create SAP queries and manage authorizations by user groups. Now this information can be stored in the personalization tab of the role. (I supposed that it is a way for SAP to address his ambiguity of its concept of user group and roles: is "usergroup" a grouping of people sharing the same access or is it the role who is the grouping of people sharing the same access?)
EWZ5: To lock and unlock the users 1. Principle of Dual Control: It is controlled by two administrators 1. User Administration 2. Profile and Authorization Administration When there are more systems in the landscape (or) various components SAP (BW,CRM,SRM) are implemented in such a case SAP recommends to use control administration CUA User Admin Profile& Authorization Admin Create users perform User Comparison Assign Roles to User and

2. Principle of Triplet control: The user and authorization administration is segregated into 3 roles 1. User Admin 2. Role/ Profile Admin 3. Authorization Admin This is controlled by 3 admins Role Admin Create Role Display Roles Change Roles User Admin 236 Profile Admin Authorization Admin

Create User comparison Prerequisites of CUA:

Assign roles to users and perform user

1. All the clients are defined with logical system 2. Define RFC connections with logical system names in SM59 3. Go to SALE define the logical system name and assign them to clients

Defining CUA: (Central User Administration) Go to SCUA of the master client or parent client from which we want to monitor users centrally. Specify the name of the CUA, SAVE and include all the logical systems. Save and distribute configuration of all the clients. Identify CUA configuration Systems tab is added in the master client. Systems tab is included in the roles tab User creation is disabled in all the child systems Users can be created only in the master client and maintained in the child client Users can be maintained either globally or logically which will be defined in SCUM While assigning roles click on read text from child client Note: RSDELCUA is used to delete the CUA. (Execute this report in SE38) CUA mechanism: CUA uses ALE mechanism to transfer the data between different clients. Transaction RFC is used to transfer the data between the systems. Go to SUIM (To give global or local users to be monitored) SCUM: If you are using Central User Administration, you can use the distribution parameters in transaction SCUM to determine where individual parts of a user master record are maintained.

In the central system Locally in the child system 237

In the child system with automatic redistribution to the central system and the other CUA child systems Every input field of the user maintenance transaction SU01 has a field attribute that you set once in the central system with transaction SCUM during Customizing. As far as possible, you should then not change the field maintenance indicator at all. If you later change the distribution from Local or Proposal to Global or Redistribution, data inconsistencies can occur SCUM The system displays the User Distribution Field Selection screen, with tab pages of the fields whose distribution parameters you can set. To display additional fields, choose page down. You can select the following options on the tab pages: Global You can only maintain the data in the central system. The data is then automatically distributed to the child systems. These fields do not accept input in the child systems, but can only be displayed. All other fields that are not set to global accept input both in the central and in the child systems and are differentiated only by a different distribution after you have saved. You maintain a default value in the central system that is automatically distributed to the child systems when a user is created. After the distribution, the data is only maintained locally, and is not distributed again, if you change it in the central or child system. You can maintain data both centrally and locally. After every local change to the data, the change is redistributed to the central system and distributed from there to the other child systems. You can only maintain the data in the child system. Changes are not distributed to other systems. You can maintain data both centrally and locally. However, only changes made in the central system are distributed to other systems, local changes in the child systems are not distributed.



Local Everywh ere

SAP R/3 Security Tables: SAP R/3 Security Tables are Tables in SAP R/3 that have relations or direct impact to Logical Access Control, Program Changes Control and Operational Control. Today, the convergence of the Internet within distributed ERP systems is ever-increasing the demands on data and business process security almost exponentially.

Organizations which employ distributed business processes and data systems require surety of both data and its accompanied processes; promising continued support of essential business needs - whilst mitigating unauthorized access to critical information. This is especially true with the introduction of Sarbanes-Oxley and other federally mandated policies and procedures many having direct (read potential fines and/or jail time) responsibility tied to the efficacious employment of recognized security measures.

Below the list of SAP R/3 Security Table that could be used for your references USR02 USR04 UST04 USR10 UST10C USR11 USR12 USR13 USR40 USGRP USGRPT USH02 USR01 Logon data User master authorization (one row per user) User profiles (multiple rows per user) Authorisation profiles (i.e. &_SAP_ALL) Composit profiles (i.e. profile has sub profile) Text for authorisation profiles Authorisation values Short text for authorisation Tabl for illegal passwords User groups Text table for USGRP Change history for logon data User Master (runtime data)

USER_ADD Address Data for users R AGR_1016 Name of the activity group profile AGR_1016 Name of the activity group profile B AGR_1250 Authorization data for the activity group AGR_1251 Authorization data for the activity group AGR_1252 Organizational elements for

authorizations AGR_AGRS Roles in Composite Roles AGR_DEFIN Role definition E AGR_HIER2 Menu structure information - Customer vers Assignment of Menu Nodes to Role

AGR_HIERT Role menu texts AGR_OBJ AGR_PROF Profile name for role AGR_TCDT Assignment of roles to Tcodes XT AGR_TEXT File Structure for Hierarchical Menu S Cus AGR_TIME Time Stamp for Role: Including profile AGR_USER Assignment of roles to users S USOBT USOBT_C USOBX Relation transaction to authorization object (SAP) Relation Transaction to Auth. Object (Customer) Check table for table USOBT

USOBXFLA Temporary table for storing USOBX/T* GS chang USOBX_C Check Table for Table USOBT_C

Types of Security are NW, DB, O/S, R/3 In R/3 application and data to be protected (Invoices, Billing..) In DB OPS$ USER ID , SYS, SYSTEM, SCHEMA ID should be protected In O/S File structure , sapservice<SID>, <SID>ADM should be rotected In N/W firewall should be provided

Some Authorization objects are: 1. S_TCODE (S represents BASIS)


2. Q_TCODE (Q represents Quality) 3. P_TCODE (P represents HR) 4. S_USER_GRP, S_USER_AUTH, S_USER_AGR, S_USER_TCD, S_USER_USR, S_USER_PRO These are user management authorizations for dual control and triplet control 5. S_TABU-DISP : This is an authorization object which provides access through authorization fields, authorization group 6. S_TABU_CLIENT: Cross client object 7. S_PROGRAM, S_DEVELOP, S_SPO_DEV are related to development The following T-Codes are security related activities: SU01: SU10: SUGR: PFCG: EWZ5: SCUM: SCUL: SUPC: SU03: SU24: SU25: SU99: SM18: SM19: SM20: SM58: SM59: 241


Segregation of Duties (SOD): SAP R/3 segregation of duties (SOD) is a basic key internal control that is used to ensure that errors or irregularities are prevented or detected on a timely basis by employees in the normal course of business. Segregation of duties provides two benefits: 1) a deliberate fraud is more difficult because it requires collusion of two or more persons, and 2) it is much more likely that innocent errors will be found. At the most basic level, it means that no single individual should have control over two or more phases of a transaction or operation. Management should assign responsibilities to ensure a crosscheck of duties. There are four general categories of duties or responsibilities which are examined when segregation of duties are discussed: authorization, custody, record keeping and reconciliation. In an ideal system, different employees would perform each of these four major functions. In other words, no one person should have control of two or more of these responsibilities. The more negotiable the asset, the greater the need for proper segregation of duties especially when dealing with cash, negotiable checks and inventories. CPIC: Common programming interface communication : CPIC (Common Programming Interface Communications) is the interface deployed by the ABAP language for program-to-program communication. CPIC was defined and developed by IBM as a standardized communication interface and was later modified and enhanced by the X/Open organization. The CPIC communication interface is useful when setting up communications and data conversion and exchange between programs. Since CPIC is based on a common interface, an additional advantage is the portability of the programs across different hardware platforms. SAP divides the possibilities and the scope of the CPIC interface into two function groups: the CPIC starter set and the advanced function calls. This division is simply meant to guide the user and not to restrict the available functions. For instance, the CPIC starter set would just be used for the basic and minimum set of functions shared by two partner programs, such as

establishing the connection and exchanging data. The advance calls cover more communication functionality, such as converting data, checking the communication, and applying security functions. For more information on these CPIC function groups, refer to the SAP documentation BC SAP Communication: CPI-C Programmers Guide. CPIC communication is always performed using the internal SAP gateway which takes care of converting the CPIC calls to external communication protocols such as TCP/IP

Password Control in SAP Systems

There are two ways in which you can define your choice of user passwords:
You can use the system profile parameters to assign a minimum length for the passwords and define how often the user has to set new passwords. Invalid passwords can be entered in the table of reserved passwords, USR40. This table is maintained with transaction SM30. The entries can also be made generically: - ? denotes one character - * denotes a character string The SAP System also has pre-defined password rules. You can control passwords with profile parameters login* login/min_password_lng - Defines the minimum allowed length of a new password. login/password_expiration_time - Defines the expiration period of the password login/fails_to_user_lock - Locks the user after the specified amount of wrong logon attempts; user is unlocked at midnight if the login/failed_user_auto_unlock parameter is set login/fails_to_session_end - Ends the user.s session after the specified amount of wrong logon attempts login/disable_multiple_gui_login - Refuses multiple logon of users; only users listed in login/multi_login_users are allowed for multiple logon login/min_password_diff - Defines the minimum number of different characters between old and new password including rotation login/password_max_new_valid - Defines the validity period of passwords for newly created users login/password_max_reset_valid - Defines the validity period of passwords reset login/min_password_digits/_letters/_specials - Defines the minimum number of


digits/letters/special characters in the password login/disable_password_logon and login/password_logon_usergroup Controls the deactivation of password-based logon login/disable_cpic -Refuses incoming connections of type, CPIC rdisp/gui_auto_logout - Defines the time for automatic SAPGUI logout login/no_automatic_user_sapstar Controls the SAP* user

Default password, and protecting SAP*

Starting with installations of SAP Web Application Server release 6.10 and higher, the passwords of SAP* and DDIC are selected during the installation process. Use the User Information System or report RSUSR003 to monitor the passwords of all predefined users. If possible, make use of the profile parameter, login/no_automatic_user_sapstar. If you create a new client the default password for SAP* is pass. If you delete SAP* userid, logon is possible with SAP* /pass. The DDIC user maintains the ABAP dictionary and software logistics. The system automatically creates a user master record for user SAP* and DDIC in client 000 when the SAP System is installed. This is the only user who can log on to the SAP System during a release upgrade. Do not delete or lock user DDIC because it is required for certain installation and set-up tasks. User DDIC needs extensive authorization. As a result, the profile SAP_ALL is allocated to it. The users, SAP* and DDIC, should be assigned to user group SUPER to prevent unauthorized users from changing or deleting their user master record. 244

Default clients in an SAP System: Client 000 is used for customizing default settings. SAP imports the customized settings into this client in future SAP System releases during the upgrade process or even with support packages. Client 000 should not be used to customize data input or development. Client 066 is used by the SAP EarlyWatch service and should not be used or deleted by the customers.

Techniques to implement to keep SAP passwords Safe and Secure :

SAP uses a technique called as Hashing to store the passwords in the database. With this technique the system tries to guarantee that if an attacker gets access to the database where passwords are stored, he wont be able to recover the original password string. SAP has implemented different password hashing mechanisms along its history each identified by a Code Version (CODVN From A,B,C,D,E,F,G,H,I). Each version is dependent on different technique like MD5, SHA1. Since release 7.00 SAP introduced a completely re-designed hashing mechanism. This new version CODVN F is based on SHA-1 and allows up to 40 character password, case sensitive and supports the UTF-8 character set. Passwords are stored in different tables in SAP database. USR02: This is the user master table. Contains information such as the User name, user type, lock status, last logon date etc.. This table stores the current password hashes in two fields, depending on the code version being in use. If the code version F is used a 40-character long PASSCODE field is used to store the password hash. Finally if code version is H the HASH is stored I the PWDSALTEDHASH field. It is possible to identify which code version is in use by analyzing the CODVN field.


USH02: This table is known as the change documents table and is updated every time a user is locked, un-locked, its password reset etc When these events take place a partial copy of user master information including BCODE, PASSCODE and PWDSALTEDHASH fields is inserted as a new record in this table. USRPWDHISTORY: In release previous to .00 password history is set to 5 and the last five password hashes are stored in the USR02 tables (Fields OCOD1-OCOD5). From that release onwards, the password, history size is no longer fixed, being configurable through the profile parameter login/password_history_size. Therefore, each time a users password is change a new rec0ord is inserted in this table containing the old hash value. The USR02 table can be retrieved from transaction SE16. The tables USR02, USH02 and USRPWDHISTORY should be protected against direct access through table maintenance tools (TCODES SE16, SE17, SE11). This can be enforced through the proper use of the authorization object S_TABU_DIS which restricts access to critical table authorization groups. Use different passwords for critical users like Sap*, DDIC, Administrator. Disable downwards compatibility (If possible). If there is no need to connect with older systems or special scenarios (e.g. CUA) the login/password_downwards_compatibility parameter should be set to 0 avoiding the generation of weak hashes. If legacy components needs to to connect with a new SAP system then a possible solution needs to be configured having 8-characters long upper case passwords, including special characters. This would keep the hashing procedures strong, while providing a decent level of security for legacy compatibility. Implement a strong password policy. Ex: login/min_password_lng > 8 and login/min_password_lowercase > 0 to demand the use of passwords longer than 8 characters and the use of at least one lower case character.

Frequently Asked Questions on Authorization Role & Profile What is the difference between role and a profile?


Role and profile go hand in hand. Profile is bought in by a role. Role is used as a template, where you can add T-codes, reports..... Profile is one which gives the user authorization. When you create a role, a profile is automatically created. What is the use of role templates? User role templates are predefined activity groups in SAP consisting of transactions, reports and web addresses. What is the different between single role & composite role? A role is a container that collects the transaction and generates the associated profile. A composite role is a container which can collect several different roles What profile versions? Profile versions are nothing but when you modify a profile parameter through a RZ10 and generate a new profile is created with a different version and it is stored in the database. Is it possible to change role template? How? Yes, we can change a user role template. There are exactly three ways in which we can work with user role templates - we can use it as they are delivered in sap - we can modify them as per our needs through pfcg - we can create them from scratch. For all the above specified we have to use pfcg transaction to maintain them. Personalization Tab within PFCG Please explain the personalization tab within a role. Personalization is a way to save information that could be common to users, I meant to a user role... E.g. you can create SAP queries and manage authorizations by user groups. Now this information can be stored in the personalization tab of the role. (I supposed that it is a way for SAP to address his ambiguity of its concept of user group and roles: is "usergroup" a grouping of people sharing the same access or is it the role who is the grouping of people sharing the same access?) How to insert missing authorization? Ways?


su53 is the best transaction with which we can find the missing authorizations and we can insert those missing authorization through pfcg. Table of authorization field settings Is there a table for authorizations where I can quickly see the values entered in a group of fields? In particular I am looking to find the field values for P_ORGIN across a number of authorization profiles, without having to drill down on each profile and authorization. AGR_1251 will give you some reasonable info. Table with deleted users Someone has deleted users in our system, and I am eager to find out who. Is there a table where this is logged? Debug or use RSUSR100 to find the info. Run transaction SUIM and down its Change documents. How can I make T_Code SPRO Read Only I have a requirement to make SPRO read only. As you know it has a tree like structure and to make it read only seems like impossible. You cannot make SPRO 100% display only by ANY setting. The SCC4 option only turns configuration tables to not-modifiable but still allows the nonconfig delivery class tables (or those configured to be changeable) to be modified. It does nothing for the tcodes that are NOT table maintenance and not controlled by S_TABU_DIS. These will still allow configuration. All the tcodes in the SPRO are in several tables CUST_ACTOBJ (spelling?) is one. You only real option is to create a role with all the tcodes in them that are in the SPRO , remove the create and change to display ( generally by changing the last number on the 4 digit tcodes to 3) and removing all the Create and change access in all the activities and allow only the display. PFCG allows you to create a role from a SPRO project so the usermenu will come close to the SPRO menu, which your changes it will be display. Mass Delete of Old Roles How can i do a mass delete of the roles without deleing the new roles.

There is a SAP delivered report that you can copy, remove the system type check and run. To do a landscape with delete, enter the roles to be deleted in a transport, run the delete program or manually delete and then release the transport and import them into all clients and systems. It is called: AGR_DELETE_ALL_ACTIVITY_GROUPS. To used it, you need to tweak/debug & replace the code as it has a check that ensure it is deleting SAP delivered roles only. Once you get past that little bit, it works well.


Dialog Work Process in Multiplexing: SAP transaction consists of multiple transactions which are handled by individual dialog work processes. Dialog work process handles request from various users (It is not restricted to the user) User transactions are handled by various dialog processes (restricting to a process). This mechanism is called as multiplexing. This process of handling various dialog steps of different users transactions without restricting to the users is called work process multiplexing. Dispatcher
User Communica tion W0,W1-------Wn-1 U C Task Handler R/3 Buffers DB Queue

The number of dialog work processes can be configured by using the parameter rdisp\wp_no_dia The maximum run time of a dialog work process is restricted to 600 sec, which can be increased dynamically in RZ11 by using the parameter rdisp\max_wprun_time Configuring this parameter does not require R/3 restart This parameter can be increased and decreased dynamically in the following scenarios: 1. Weekly progress report (or) sales report 2. Month end reports (or) any critical transactions which consumes more time. Dialog work process can be monitored in SM50/ SM60/ SM66

We can also monitor dialog work process using command prompt using the command dpmon Ps ef|grep de * Disp+work Update Process: This process is used to update the database. SAP transactions consist of multiple transactions which are handled by different dialog work processes. Each process cant update the DB, because they are part of the transaction. That is the reason they will update temporary tables, so that rollback is possible. If the entire transaction is committed then the update is written to the database. Users request using dialog process to commit a part of a transaction. If it is written to the Db, it cannot be rolled back. So it is updated in the temporary tables. Temporary Tables: These are the tables which are used by the dialog process to update the data temporarily. Update process reads the committed data from the tables and updates the tables in DB. The temporary tables are VBHDR, VBMOD, VBDATA, VBERR VBHDR: It stores the header information VBMOD: Modules involved in the update (Scripts) VBDATA: Data to be updated VBERROR: Any error information Once all the steps (dialog steps) update temporary tables a COMMIT occurs. Once the transaction is committed update gets initiated. Update process reads the temporary tables and update the DB. Before updating temporary tables dialog process gets a logical lock from enqueue process, if it is on CI (Central Instance). If it is on DI (Dialog Instance) it communicates with message server. Message server in turn communicates with enqueue process to get the lock, so that other users will not modify during transaction.


While updating records from the temporary tables to the DB update inherits the locks Types of Update Work Processes: There are two types of update work processes V1 and V2 Update Process (v1): V1 handles the most critical updates. (User Transactions) Update Process (v2): V2 handles non critical statistical information Update work processes are configured using parameters rdisp/wp_no_vb1 rdisp/wp_no_vb2 Each instance/ SAP system requires at least one V1 process. If v2 updates are not defined they will be handled by v1 update process. Update process Monitoring: Updates are monitored in transaction SM13 Note: When a dialog process commits into temporary tables a transaction number (P.O number, Invoice) will be generated. The number is generated from Number range buffer. Number range buffers are defined in transaction SMRO in the table NRIV. NRIV: Number range interval Monitoring: Go to SM13 select terminated records double click (or) select all to find out the list of updates which are to be updated, which are terminated etc The status of the updates will be followed. The status may be: Init: Update is initialized and waiting for the updation work process. (SAP recommends at least one update work process for 5 dialog work processes) Auto: If the update mechanism is deactivated the work processes will be terminate the update process, upon activation of the update. The update status will go into AUTO. That is no initialization is required Run: Update is running. Update is updating into the DB

Error: Update is terminated Reasons for Update Problems: There is a problem in the program (Very rare) so that we apply support packages, patches and notes Table space overflow (Resize the data file or add data file) Locks are not available Work process congestion (Updates work processes are not available) Update deactivated for each of the problems with update the entire update mechanism will be deactivated Go through SM21 logs and ST22 ABAP dumps thoroughly and fix the issue. The update can be activated in SM14. Note: IF the update could not be initialized automatically, select the record and run the update (if the update is terminated). Types of Update Mechanism: 1. Local 2. Asynchronous 3. Synchronous Local Updates: These are used to update the DB directly Ex: Update is programmed locally and updates DB directly without any intermediate tables temporarily. These are used for small transactions which dont have multiple tables in the DB. It is not monitored and displayed in SM13. Asynchronous Updates: This mechanism is used by dialog work processes. They will update the temporary tables and gets the transaction ID from number range buffers. Dialog work processes never waits for the response from the temporary tables. Ex: User creates a P.O but could not see the P.O in the DB due to deactivation of Update Mechanism. No acknowledgment. Synchronous Mechanism: This mechanism is used by update process. Update process reads the temporary tables and updates DB tables synchronously by obtaining transaction consistency.

Update reorganization: rdisp\vbdelete isused to delete the incomplete update records. It should be set to 1. RSM130002: It is used to delete the update requests based on number of days. rdisp\vbmail: This is used to trigger the mails to users in case of update errors and update deactivation rdisp\vb_stop_active=1: This parameter is used to deactivate the update process in case of programmatic or DB related errors. Enqueue Mechanism:Enqueue is used to the locks to an SAP transaction. This is used to logically lock the tables and the arguments which are involved in the transactions. Enqueue process is only confined to application server level. These are not equal to DB locks (Tables updation locks) but similar to DB locks. ENqueue_Table_Size Enqueue table is stored in main memory of the instance where enqueue is located. Dead Lock: In order to update user requirements enqueue lock to be placed on the table and on its arguments. Let us say if the user has to lock the two arguments. But one of the locks is locked earlier by another user. This user is waiting for lock on the argument which is locked by the current user. This situation is called as Dead Lock. Apart from the above user call regularly raising a message saying that transactions are locked and could not be updated. Note: In order to resolve the above issue release the locks in SM12. Process of Releasing Lock: 1. Users complain of updating request. As part of system help we need to monitor the locks which are older than 24 hours 2. Identify the user who locked the argument and check whether user is still logged onto the system. Note: Do not ever try to delete the locks without user approval. SM04- Users who logged on to the system. Case-1: If the user is not logged on we can release the lock

Case-2: If the user is logged in get the telephone number and E-mail id from SU01 and send a mail to the user about the lock release. Call the user and explain the significance of lock release. Probably we can also involve the consultant who is waiting for lock. Based on verbal approval send a mail to the user saying that As discussed today morning 5 A.M about release of locks we are going ahead to unlock the transaction Thanks for approval Finally release the lock in SM12. Release the one which is approved. Background Processing: The programs, reports, transactions which consumes more than the time specified is rdisp\max_wprun_time=600. After 600 seconds the transactions will get terminated and logged into ABAP dump with an error Time out occur or a program running more than the specified time. SAP recommends to run this sort of long running programs and time consuming programs or expensive programs in the background mode using Batch Process (background Work Process). Background work processes are used to schedule the reports, programs, transactions to run in the background mode during off peak hours without any user intervention. This facility is used by most of the companies for the following purposes. 1. Data transfer from legacy systems 2. On line sales orders, purchase orders to move into SAP 3. Running the weekend reports, monthly reports, pay roll runs Companies like H.P uses for Order Processing. Note: Companies uses 3rd party tools like Maestro, Tidal to trigger the background processes. Triggering background Jobs: This can be triggered based on the background jobs 1. Time-Controlled: Ex: Every day 10 pm Every hour start at 11:55


Every Month Run immediately 2. Event Controlled: These are used to trigger based on events on success of dependant programs Users can trigger some of the events using standard ABAP programs or customizing using functional modules BP_RAISE_EVENT (In earlier versions) or use the external programs and commands using command sapxpg and sapevt. Defining a Background Job: In SM36 background jobs are defined SM36 Specify the name of the job Description of the Job Specify the type or class Spool recipient Different types of classes are Class A: With high priority (background W.P of Type A should be reserved in RZ04) Class B: Medium Priority Class C: Low priority Spool Recipient: Printer, E-mails, fax, intranet, internet [pdf] specify the name of the program along with the variant. Variant: It is a predefined value which will be populated during runtime. These are created in transaction SA38. Variants are stored in tables TVARV Variant s are used to avoid user interactions We also specify external command or program to run in the target system. Specify the time and save. Monitoring Background Jobs: Background jobs are monitored in SM37

Background jobs have the following status: Scheduled: When it is defined status is scheduled Released: When we specify the time to run the status is released Ready: Waiting for the background work process Active: Actively running the job or program Cancelled: Cancelled Completed: Job is successfully completed. User defines dialog process a program/report/transaction to run in the background mode Dialog process updates a table TBTCS and TBTST (scheduled) Scheduler sap message server system (SM61) runs in the dialog mode for every 60 seconds (default) which is specified by parameter rdisp\btc_time=60
Dialog Instance CI

User Communit y


rdisp\btc_time=60 Scheduler reads from the table and keeps the job in queue based on their time of priority Background job gets free work process and runs in the background mode active The job is completed the status is finished (or) completed else it is canclled

Text File Legacy System Purchase Order Excel File Text and Excel File 257 DB

Based on the time IDOC Background Job Errors: 1. File not found 2. File found but could not be opened 3. File permission problems 4. Background work processes are not available 5. Target syste is not available 6. User ID or password changed (or) password expired 7. Users are locked in the target system 8. Objects are locked (SM12) 9. Table space overflow 10. 11. Connectivity with RFC system fails Authorization to the target system fails (Role is expired)

Standard Background Jobs: In order to organize the R/3 DB we will schedule the following as housekeeping jobs.
Periodic Jobs Required for Housekeeping: Job Name SAP_REORG_JOBS Deletes old background jobs. SAP_REORG_SPOOL Deletes old spool requests. SAP_REORG_BATCHINPUT Deletes old batch input sessions. ABAP Program Required Variant RSBTCDEL You must create a variant. You must create a variant. You must create a How Often? Daily






This job may not run at the same time as normal batch input activity. Schedule this job for periods during which no batch input sessions are run. SAP_REORG_ABAPDUMPS RSSNAPDL Deletes old dumps produced by ABAP abnormal terminations. Alternative: To keep from needing to schedule this job, run the ABAP report RSNAPJOB from the ABAP editor instead. This schedules RSSNAPDL as follows: Job name: RSSNAPDL Variant name: DEFAULT (you must create this variant) Start time: 0100 AM Repeat interval: Daily SAP_REORG_JOBSTATISTIC RSBPSTDE Deletes job statistics for jobs not run since the specified date (statistics no longer needed since job was a one-time occurrence or is no longer run) SAP_REORG_UPDATERECORDS Deletes old completed update records (automatic delete deactivated); deletes incomplete update records (automatic delete deactivated) Run this job ONLY if: You have deactivated the default automatic deletion of update records once they have been processed. This function is controlled by the system profile parameter rdisp/vb_delete_after_execution You have deactivated the default automatic deletion of incomplete update records (records that are partially created when an update header is created and saved but the generating transaction then ends abnormally). This function is controlled by system profile parameter rdisp/vbreorg You have deactivated processing of V2 update components after the processing of the associated V1 updates. This function is controlled by system profile parameter rdisp/vb_v2_start. RSBPCOLL RSCOLL00 RSM13002


You must create a variant.


You must create a variant.




SAP_COLLECTOR_FOR_JOBSTATISTIC Generates runtime statistics for background jobs SAP_COLLECTOR_FOR_PERFMONITOR Collects system performance statistics This job was previously called COLLECTOR_FOR_PERFORMANCE_MONITOR. When scheduling this job, be sure to use the new name. RSCOLL00 schedules all reports that need to run for the performance monitor using table TCOLL to determine what to run. See the CCMS Guide for more information on

None. None.

Daily Hourly


setting up RSCOLL00.

Note: Apart from the above we will run the statistics to update tracing transactions (ST03, ST04) External Commands: These commands are used to trigger the jobs in the system. Using commands SAPEVT and SAPXPG (External Programs) Commands are defined in transaction SM49. It can be executed using SM59. Some of the commands are 1. Startsap 2. Stopsap 3. BRBACKUP 4. BRARCHIVE 5. Tp 6. R3trans 7. BRRESTORE Background processes can be configured by parameters rdisp\wp_no_btc Spool Re organization: The tables TST01, TST03 can held upto a limited number of entries 32,000. This can be increased up to 99,000. If this number exceeds the spool mechanism does not work i.e. why spool tables re organized using the standars background jobs. Schedule background jobs RSP0041 to delete this spool requests which are older than 14 days by default Gateway Process: It is used to monitor the gateway connections make to instance (SMGW). Gateway process is used to allow the incoming connections to an instance there will be only one gateway for each instance. From version 6.40 onwards gateway instance can be installed separately on a Standalone instance. SMGW is used o monitor the connections which are coming to RFC, CPIC.


Ex: A service in JAVA system is set to run using a program ID. IN order to check whether the connection is made to R/3 we need to check the program ID in SMGW. Gateway process listens on 3300 (Instance number 00) Spool Process: Spool process is used to print the documents to a printer or a copy as an Email, fax etc.. Spool process is used to generate output request as a device specific request. Spool Process Mechanism: 1. User requests through dialog process to print a document 2. User requests through dialog process and schedules a background job to print documents massively 3. The spool requests are generated by the dialog process (or) background process and updated in the TEMSE. TEMSE: Temporary sequential database These are the spool requests which are generated by dialog (or) background stored in the location defined by the parameter as follows: rdisp\store_location=G (or) db G: Global Directory (O/S level) DB: Database DB means it is stored in the table TST01 and TST03 TST01: It consists of the TEMSE details (Spool request, Name of the author, No of copies, Name of the device) TST03: It consists of the original data to be printed.

Advantages of Global Directory: 1. It is stored at O/S level 2. Easy to access by the O/S spooler Disadvantages of Global Directory:

1. For fewer records access time is good, but if the record size grows it takes longer time to fetch the record from the global directory 2. O/S is not part of the regular back up (printer). If there is any damage to O/S global directory will be lost all our spool request will be lost Advantages of Storing at DB: 1. Spool requests are backed up along with the DB backup 2. DB features redundancy, consistency, indexing Disadvantages of Storing at DB: These are stored in DB. It consumes more time than files stored in O/S level

File or Database Storage for TemSe Objects? Type of Storage File system

Advantages Relatively fast: improved performance.

Disadvantages TemSe data must be backed up and restored using operating system tools, separately from the database. In the event of problems, it can be hard to restore consistency between the data held in files and the TemSes object management in the database.


Back-up and restore with database tools. Consistency is ensured.

Slower than file system storage. Increased database load.

Definition of Printers: Printers are defined by transaction SPAD SPAD stands for spool administration SPAD is used to define the following: 1. O/P devices 2. Spool Devices (Logical and Real)


3. Access Method (Local and Remote) Spool Servers: Go to SPAD Specify the name of the server Specify the server class Server class specifies that instance is designated to handle mass printing, production printing, desktop printing, test printing etc Specify whether the server is real (or) logical server Check on if the server is real (or) logical server Check on if the server is allowed for load balancing Logical spool server is mapped to real spool server Real Spool Server: This is an instance whether at least one spool work process is configured Logical Spool Server: This server doesnt exist but logically defined for load balancing and handle fail over. Each logical spool server should be mapped to at least one real spool server

R/3 LP3 Instance LP2

Logical System


TA R/3

LP3 Dialog

TA R/3

LP1 W.P of type Spool



Access Method: Access method specifies the type of printing mechanism (Local or Remote Front End)

DISP U W0,W1W n-1 T.H C R/3


User Reques t



Spool Request data

Author, No of Copies, Device and data



Spool Request

Output Request

O/S Spooler

O/S Printer


Print Server Print Server: This is a server in the network where the printers are configured Local Access Method: If the output request generated by the spool process is formatted according to the output device and hands over the request to O/S

spoolers. The commands Lp or LPR at O/S will analyze the O/P request and print it local. Protocols L & C will be used to print the document Remote Access Method: If the O/S spooler and the O/P request resides from different hosts, then remote access method is used. Protocol U is used for UNX based interface Protocol S will be used for WINDOWS based interface S is proprietary protocol for SAP Defining O/P devices: Go to SPAD Click on O/P devices Select the device type Authorization Group: It is used to provide additional authorizations to the objects so that the objects are highly protected Ex: S_TABU_DIS, S_TABU_CLI should be in authorization role of the user to provide additional authorizations to the table and client administration Specify the Access Method: Front End Printing (P): The printer is connected to the user desktop to print sensitive document Disadvantages: Spool process is dedicated to the user till the job is completed Print congestion Occur: IF more number of front end printers are configured try to restrict the no of front end using the parameter rdisp\wp_no_spo_max We cannot schedule background printing because the system needs to login Spool Monitoring: Spool processes are monitored in SP01 or can be read as O/S level using command LP status


Go to SP01 Specify * in create Specify the current date Specify the O/P device name It will display the list of spool request The following are the status of the spool request 1. (Minus): No O/P request 2. + (plus): spool request is being generated 3. Waiting: Spool request is not yet processed 4. Inprocess: Spool request is formatted by the spool process generating O/P request 5. Printing: The host is printing 6. Complete: the task is completed. The task with status complete may not be completed because the process waits for the 7. Problem: It monitors the problem related to character formats and margin settings and page settings 8. Error: it is an error status. The printer has been not generated Problems in the Spool Request: 1. Printer pages are not available 2. Print cartridge problem 3. Device problem 4. Incorrect page settings 5. Incorrect character formats 6. SAP scripts, small forms alignment is issued 7. Problem in the report


8. While configuring barcode printers ensure that right drives are installed Configuring of SCOT: (SAP Connector) It is used t define E-mail server, Fax Server, Internet, SMTP (Simple mail transfer protocol) Configuring SMTPClick on internetClick on createSpecify the name of the nodeDescribe the nodeSelect the RFC nodeContinue define the RFC destinations If we select fax, pager, printers (OMS output management system) we need to install respective drivers SAP scripts (or) Smart Forms: These are pre defined print formats provided by SAP. We are customizing according to our requirements ABAP list: There are non interactive reports Define the name of the mail server host on which mail server resides Monitoring SCOT: As part of regular monitoring the no of requests which have been sent out from SAP system. The various statuses of the requests are 1. Waiting: The request is sent to outbound an is in waiting for processing 2. In transit: the requests are processed 3. Completed: The requests are completed 4. Error: The requests are not sent SOST: SOST is used to display and manage all messages sent using
Depending on the selection criteria chosen, the program displays send requests that are sent or have already been sent using SAPconnect. A variety of selection and display options are available to you. For more detailed information about using the send requests overview, see the program documentation in transaction SOST. To do this, call transaction SOST and choose the info button or choose Help Application Help.


Go to SOST Select the status waiting, errors, sent and execute to display the list of transmission requests we can trace error transmission requests upon resolving the error, the transaction request can be resent, spool process is configured using parameter rdisp\wp_no_spo more than one depending upon resources
If a user is only allowed to select send requests of certain users or groups, you can use transaction SOSG for this. This transaction is the same as transaction SOST, however it also performs additional authorization checks. To be able to use this transaction, a user must not have ADMINISTRATOR authorization in authorization object S_OC_ROLE. Authorization to select users or groups in transaction SOSG is controlled through authorization object S_OC_SOSG. For more information, see the documentation for this authorization object. In transaction SOSG, using input help for the Sender field displays only those users or groups for which the current user has display authorization.


Printer Types: Local Printer The printer is directly attached to the host system. Shared Printer The printer resource is shared to other systems. Network Printer The printer is configured in a network (i.e. to a LAN switch) where end users within the network can use the printer resource.

SAP Printing Techniques: Local Printing: The spool server (which contains spool work process) and the host spool system will reside in the same server. Host Spool System: The area which contains the spool data Remote Printing: The spool server & host spool system are on different servers. Front-end Printing: The host spool is in the front-end system itself, the spool data will be stored in the spool directory of the front-end system. For front-end printing users must indicate SWIN device name as output devices, indicating the access method F and the __default as host printer name.

rdisp/wp_no_spo_fro_max=1(default) No. of spool work processes for front-end printing.

Configuring the printer type in the operating system: Click on Start Menu settingsPrinters and Faxes. 1. Click Add Printer. 2. Click Next & specify the printer type (Local/Network) and all related parameters. Configuring the SAP printing type: SPAD


Create output device Specify the name of device according to naming convention of the device Specify the device type Specify the location & describe the printer Choose the access method [local, remote, Front-end] Specify the sequential printing, if we require a sequence in printing. When it is remote printing specify the name of remote host where the printer is hosted. Save and activate The IP address of the printer and the short name described while configuring the printer in SAP must be included in the hosts file. SAP supports only limited number of printers. LP01 is the default printer.

Access Methods: Access method specifies the communication path between SAP spool system and the host spool system i.e., how the SAP spool transfers the data to be printed to the host spool system.

List of Access methods: SAP Printing Type Local Remote Front-end Access Method(Unix) L U Access Method(Windows) C U,S F

Spool Architecture:


Spool Work Process converts the spool request into device specific output stream and sends it to the host spool or SAPLPD. SAP profile parameter that controls the no. of spool work processes per instance is rdisp/wp_no_spo. Having several spool work processes per instance avoids communication problems between spool work process and the printing devices which implements spool load balancing by using server groups called as dynamic spool assignment. Before 4.0 release, the spool server assignment & spool server work process were static that is only one spool work process was allowed.

Spool Request It is for the print job or output job, made up of spool request record (administrative information to manage the print jobs) that is it contains the reference to the spool data, output device and the printing format. SP01 We can see the particular spool request or output request. SP02 shows list of all spool requests.


SP01 Print directly toolbar button (

) creates the output request.

Output Requests are the components of the spool request which actually formats the output data and sends it to the host spool system to be printed. You can submit multiple output requests for a single spool request. SP01 select the spool request and click on output request button ( output request for the spool request. ). Shows the list of

SAP spool system handles spool request and the output request, manages the output device type, device drivers, device formats & the character sets. It converts all types of output data into the required output format.

TemSe DB: Temporarily Sequential Object Database which stores the spool request data, the background processing job logs and other texts that are temporary. Contains two options: 1. TemSe Administration(SP12) 2. TemSe Contents(SP11 or SP12 Go to menu TemSe contents) TemSe DB contains lot of job logs and print data files it is convenient to schedule the report RSPO0041/RSPO1041 (house keeping jobs) periodically as a background job for removing and reorganizing the log files.

TemSe has two main storage options: Rspo/store_location=DB stores spool data in the TemSe database. G stores spool request data in the /usr/sap/<SID>/SYS/global

To check the inconsistency of the TemSe DB SP12 TemSe Data Storage Menu consistency check (checks TST01 and TST03 tables). Or using the report RSPO1043.


To reorganize the TemSe database RSTS0022

Spool printing process: 1. End user requested for printing 2. Dialog work process creates the spool request and stores in the TSP01 table and assigns to the spool work process. 3. Spool work process gets the spool data and stores in the TemSe. The actual data is stored in the TST03 table and the header information is in the TST01 table. These two tables are updated by the dialog work process. 4. Spool work process converts the spool request into device specific output stream. Output request data is stored in the table TSP02. 5. SAP spool system is a uniform interface which sends the output request to the OS spool system or to the SAPLPD program, which communicates between SAP spool system and the host spool system. 6. OS spool system then sends to the printer directly or to the printing sever where this server sends to the printer (local/network/shared). Statuses of a spool output request: + Waiting : Not yet sent to the host system : Spool requested being generated : Output request is not yet processed.

Processing: Request being formatted. Printing : Request being printed by host spooler.

Complete : Request was printed successfully, or transferred to the host spooler. Problem : The request was printed despite a minor problem, but the output probably contain errors. Error : The spool request could not be printed.

Administration Tasks: 1. Checking and monitoring the spool system, both at SAP and at OS level 2. Deleting old spool requests or scheduling the background job which automatically deletes them (RSPO0041/RSPO1041). 3. Defining new printers, device types and other device elements. 273

4. Fine-tuning 5. Trouble shooting Trouble Shooting: 1. Check and monitor the spool work process (SM50), message server working properly and the OS spool. 2. Find which printer is causing the problems (SP01 System services Output Controller). 3. Check network connections for remote printers. 4. If the print job has been printed out but contains unreadable characters, check device type, access method. 5. When nothing is output at the printer and the output controller is in wait status, check the developer trace and the system log and look for time-out messages. 6. If the job has status complete or problem and nothing is output at the physical printer it might be a wrong output device, problem in host spooler, the physical printer or the SAPLPD program 7. If printing is very slow it might be lost indexes in the spool tables, too many spool table entries, slow WAN connections or incorrectly defined access methods.


SPAD SP01 SP02 SP11 SP12


TemSe 274

RSPO0041/RSPO1041 RSPO1043 RSTS0022

Rspo/store_location Rdisp/wp_no_spo Rdisp/wp_no_spo_fro_max

Access Methods C L U S F


LP01 default printer


System Monitoring
System health checks are used to achieve the high availability by forecasting problems and resolving them within the time. The following activities are carried out as part of system monitoring.

End User Comm unicat ion

Common Transport Directory CI DB1 CI DB2


D2 CI + DB1

R/3 System Landscape

D3 D4 D5 D6

Go to SM51 to display the list of active servers. This is to ensure that all the dialog instances are up and running. SM51 has the following status: Active and Passive It is also used to identify describe the type of instance use go to go into the respective transaction of the instance. There is no need to log in to the path instance. There is no need to log on to each instance. Double click on the instance it will navigate to SM50 of the respective transaction. Click on release notes to identify kernel version path number etc. SM50: It is used to display the work process over view of an instance. It displays the following 276

1. Number of work processes 2. Type of work processes 3. Process ID of the work processes 4. Status of the work processes 5. Every work processes has the following status Waiting, Running, Holding, Terminated The reasons for the status: The process is debug mode RFC, Sleep, Priv, none mode Sleep Mode: If the target system is not available the work processes waits until the target system is available till that time it will be in the sleep mode. Private Mode: Each work processes required for certain amount of memory for execute user transactions. Work process consumes the memory from roll area initially, if it is not enough it consumes memory from the extended memory. If this is also not enough it will go into HEAP memory. If all these are not available then it goes into private mode. If the work processes goes into private mode it will be released only when the entire memory is exhausted or transaction is completed. The parameter rdisp\max_wprun_time has no effect on the work processes in private mode. The work process which can go into private mode can be restricted by parameter rdisp\wppriv_max_no If mote number of work processes go into private mode work process congestion occurs, users experience hour glass mode. Go to dpmon in command prompt Go to the option menu Display the statistics Identify the process which is logged in earlier. Inform the project manager about the termination of work processes. Upon approval terminate the work process. Restart mode Yes or No: Error: How many times it went to restart Semaphore: it is a block in O/S level which the work process is waiting 277

CPU: The amount of time work processes spend utilizing C.P.U resources Time: Total time of the report user is executing Client: The name of the client user logged in User: The name of the user logged in Action: The type of action to fetch the records

Insert sequentially read, physically read, generate, loaded on which table the work process accesses. Double click on t he process to find out what statement it is running SM04: It is used to display the list of active users of an instance Select the user go to menu to display the terminal and amount of memory utilized by the users such as roll memory, page memory and private memory Al08: It displays active users of all the instances SM66: it is used to display process of all the instances Select the work process double click on it it displays amount of external memory and heap memory utilized. SM21: It is used to display the logs belonging to an instance. It is used to route cause the problem. It displays the following permissions 1. System start up and shutdown 2. Operation mode switch 3. ABAP dumps 4. Private mode ST22: ABAP dumps SAP is programmed in ABAP language. If ABAP program could not be executed it will be thrown into DUMP. ST22 is used to identify the dumps based on date, time, user, client. Most of the ABAP programs errors are related to the following: 1. DB errors 278

2. Table space over flow 3. Max extends reached 4. Archive strucks 5. DB Memory is not sufficient 6. SNAP Shot too old 7. R/3 Error 8. Programmatical Errors 9. Indefinite loop in the program 10.The ABAP program is expensive which consumes more time and Time Out error occurs 11.When the memory is not sufficient it goes onto dump 12.GUI compatibility


Data Transfer: Data Migration: During the Implementation the data from legacy systems has to migrate into R/3 systems to continue the business transactions. In order to transfer the data, data migration client is created in Quality System. Perform a migration. Performing the Migration: 1. Identify the source data which needs to be transferred (Customer data, material master data, suppliers data, vendor master information, employee master, some amount of transactional data) Master Data: It is basic information which is used to carry out transactions in system. Ex: while creating sales order the customer name is required along with items and descriptions and quantity Data migration can be performed later also. 2. Data needs to be parsed (or) truncated and mapped to the target system fields 3. Convert them into intermediate format (Text file or Excel File) 4. Schedule the data transfer

Data Migration can be performed using the following: 1. LSMW 2. Direct Input 3. BDC 4. Batch Input 1. LSMW: It stands for legacy system migration work bench. It is ued to transfer the legacy system data into R/3 system. It is a transaction 2. Direct input method: These are standard reports which are used to transfer the data into R/3 system as and when we required. 3. Batch Input Session: It is a part of LSMW which can be executed as and when they are required. A session can be created to upload the data using standard transactions. This standard transaction is recorded with inputs and it is executed in the background mode. It is used for transactional data. 280

4. BDC: Batch Data Communication: It is used to define the customer transfer programs based on the requirements. It also used the mechanism similar to Batch input session, but it is customized using the standard function modules. Workstation upload and Work station download There are 2 types of methods: 1. Call Transaction: It is used for 1 time data transfer 2. Session Method: It is used for periodic data transfer ALE: Application Linking and Enabling It is used to transfer the data between two loosely coupled systems i.e. from SAP to SAP systems. In order to work with ALE we need to define the following: 1. Source System (Logical system name) 2. Target system (Logical system name) 3. Define the RFC connections between the two systems (SM51) 4. Identify the interface BAPI BAPI: Business Application Programming Interface BAPI: These are standard interfaces defined in the system to transfer the data from one system to another 5. Go to BD54 or SALE to define sending system, receiving system and define the distribution model by selecting the respective BAPIs. EDI: Electronic Data Interface It is used to transfer the data between SAP and Non SAP systems. IDOC: It is an intermediate document which is understandable by both SAP and NON SAP systems. IDOCs are monitored in transaction IDOC and WE05 RFC Communication: (Remote Function Call) It is used to define the remote connectivity to the target system. RFCs are used widely in the following scenarios: 1. Remote client copy 2. CUA admin 3. Data Migration


4. Transport 5. Satellite systems in solution Manger 6. Configuring email, fax, pager, SMS and external systems 7. Remote monitoring of instances using alert monitor 8. Connectivity between various components of SAP (BW, CRM, SRM,APO) Defining RFC connections: RFC connections are defined in transaction SM59. Go to SM59 Specify the name of the connection specify the description specify the RFC destination (mostly logical system name) specify the type of connection specify the description go to technical settings specify the target host (name of the host or IP address) specify the instance number gateway host and services can be specified optionally click on logon security specify whether it is a clustered system or not specify the authorization and logon details, logon language, USER ID and password go to special options to trace the RFC 9its not required) save the connections click on the test connections (It displays the connectivity and connection time) click on remote logon to check whether the system can login remotely. If the logon details specified in the RFC connections are correct it will connect the remote system and opens the logon screen. Note: Do not give dialog user while defining RFC connections always use either system or communication user Go to menu test to check the authorization of the user. RFCs are of 4 types: 1. ARFC Asynchronous RFC 2. SRFC Synchronous RFC 3. TRFC Transactional RFC 4. QRFC Queud RFC Go to SA38 and use report RSRFCTRC to trace the activities of the RFC connections. 1. Synchronous RFC: If a request is sent from a sending system the target system is available then the data transfer is performed synchronously. If the


target system is not available the work process gets in to sleep mode and waits till the target server is available. 2. Asynchronous RFC: If a request is sent to the target system if the target system is available then it hands over the request to the target system. The request will be executed on the target system. If the target system is not available transaction will be cancelled 3. Transactional RFC: It is similar to asynchronous but a transaction ID is generated for each of the user request, unlike ARFC it will not leave the communication with the target system if the system is not available. A background program RSARFCSE is scheduled in the background for every 60 seconds. This program identifies all the transaction IDs which are not sent to target systems and tries to update for every 60 seconds . TRFCs are monitored in SM58 4. Queud RFC: It ensures that the requests are updated in the target system by following a defined sequence. It is an extension of TRFC. QRFCs are monitored in SMQ1, SMQ2, SMQR

Logon Load Balancing: Instance: It provides executable services and has its own memory, buffers, own processes. When more than one instance is configured the following issues may raise: 1. Users logon to instance of their choice 2. Users logon to different instances, buffers are not effectively utilized. In order to address the above logon load balancing is defined. Definitions of logon load balancing: In order to define logon load balancing we need to identify which the components are widely used in the system. Go to ST07 to identify the mostly used components Identify the components and the no of users using the components Go to SMLG define the group and assign instance to it specify the response time go to SAP GUI click on logo groups specify SID specify the message server host and click on the groups lost of logon groups are displayed select


the logon group save specify the message server entry in etc\services file create an entry in sapmsg.ini files. SMLG provides the computation of message server. Message server always keeps the name of the favorite server so that the request will be routed to that instance.

Advantages of Logon Load Balancing: Buffers are effectively utilized Optional utilization of work process of an instance Logon load balancing Message server identifies the least loaded server in the logon load balancing and directs the connection to that particular server

RFC Server Groups: These are similar to logon groups but used for RFC communications. Go to RZ12 define server group assign the instance The server groups are used while defining RFC connections when a request is sent to the target system which will be sent to the server group. Server group is mapped with all the available instances. This is used by the RFC request to identify the least loaded available server.


Operation Modes: These are used to define switching of W.P during the specified intervals. Ex: During off peak hours there is no need of more dialog work processes which can be converted into background processes. Prerequisites: 1. Profiles are imported 2. Define the instances

Defining operation mode: Go to RZ10 import profiles of all the active instance go to RZ04 define the instance along with profiles (check location) go to RZ04 define operation mode (Day, Night, Peak, Off Peak) Assign the instance and configure the no of W.P for each mode save the operation modesdefine the time schedules of the operation mode in SM63. We can define intervals up to 15 minutes. Default it is 30 minutes. Select the time and assign the operation mode. Note: During the operation mode switch all the active work processes work till they complete the job. As part of regular monitoring we need to check whether operation modes are switched or not. Go to SM37 and click on expensive jobs. If it is business criteria to change the operation modes get the approval from business process owner and manually switch the operation mode. Operation modes are switched manually using RZ03 Maintaining Profiles: By default when the system is installed minimum parameters run the instance are configured. But in order to handle the load configure more memory, configure more processes, increase the size of the buffers, security settings, logon client logon language etc. We need to modify profiles from time to time based on requirements. Profiles: The following are the 3 profiles which are installed by default: The directory that holds the profiles are \usr\sap\<SID>\SYS\profile 285

Startup Profile: This will not be modified unless there is a change in the instance and instance file system. Default Profile: This is modified to set the default value for the users like logon language etc. The parameters which set are applicable to all the instances. This parameters are over written by the instance profile. Instance Profile: These are instance specific parameters like W.P configuration memory configuration

Profile Maintenance: These are maintained in RZ10 transaction code. These profiles needs to be imported into DB after the installation. This will be done in the following way: RZ10 profile import form active server Defining the monitor set: Go to RZ20 Go to Extras Click on active maintenance function (on) Create your monitor set copy from the standard template and adapt the SAP standard values save the monitor set In order to modify the properties, variants threshold values go to RZ21

Dialog Instance 3 Dialog Instance 1 B/W RFC CCMS Agents SAP CCMS Dialog Instance 2 SR RFC JAVA WEBAS Config Alerts CI R/3 RFC CRM RFC RFC RFC


It is a process of moving the old data (based on the age of the data) to a data warehouse solution, to a tape, external device, HSM machines (Hierarchical Storage Machines). Reasons for Archive: 1. Aged Data 2. Response Time increase (R/3 and DB) 3. Admin cost (Maintenance, Tapes) 4. Based on the country specific requirements, the data in the system should be available for a specific period of time for auditing purpose. The old data cannot be deleted because it will be used to correlate the data, analyze the data. It finally helps to forecast the expected business, man power, material, machines, money and management. In INDIA the companies are following Bassel-2 for auditing. Identifying the necessity of Archiving: 1. The database grows abnormally 2. The database fetches are expensive 3. Using indexes is also not suitable to get the optional response 4. The DB requires reorganization The process of Archiving: 1. Identify the archiving objects 2. Go to DB15 specify the archiving object kike financial documents, material numbers etc. Ex: MM_MATNR, FI_DOCUMNT 3. Functional consultants identify the objects based on the modules and inform us to archive 4. Find the size of the table (RSTABLESIZE) 5. Define the archiving path


6. Go to file (FILE_Tcode) 7. Define the logical path Assign physical path (Global Directory)\usr\sap\SID\sys\GLOBAL (Cross Client) 8. For client specific use T-Code SM01 9. Go to SARA identify the object select for archive 10.Define the variant (Name of the variant, time) 11.Status options are Archive, Save, Delete, Write 12.Data reorganization needs to be followed after archiving The third party tools like IXOS, DWB2000, BIW are used for the archiving purpose. As part of regular monitoring we need to monitor the archiving background jobs in SM37


GUI (or) Front End time: It is the time taken by the user request to reach the dispatcher. GUI time is not part of response time. GUI time should generally be around 200 m/second Check the network connectivity to application server Wait Time: The time taken by the user request waiting for Work Process it should be around 500 m/sec i.e. 10% of dialog response time. Reasons is no free work process is available W.Ps are running expensive programs transactions, reports The time taken for roll-in of the user context information by the W.P. The roll in time should be 500 M/sec It is assumed as used context information is expensive. Reduce the no of authorizations parameters and ask the used to restrict the queries. Response Time: The time taken for processing a user request and returning the data to the presentation server. Response time will be continued from the movement when a presentation server request is reached to the dispatcher. Note: GUI time and CPU time are not part of the response time. Process Time: It is the amount of time required to process the user request by interpreting (ABAP, Screens, SQL Statements). If the processing time is more we need to analyze ABAP statements, expensive screens etc Processing time in not measured directly. It should not be more than twice the amount of CPU time Process Time 2* CPU Time CPU Time: It is the amount of time taken by the work process utilizing CPU resources while processing the user request. Generally CPU time should not be greater 40% of (Response Time Wait Time) 289

If CPU time is expensive then ABAP programs are expensive. Tune ABAP programs. Run time analysis of the program The CPU time is expensive because of the following reasons: 1. Expensive programs (Inefficient Coding) 2. Internal tables could not handle the data files 3. Indefinite loops in the program Perform the run time analysis of the ABAP programs. It is done by the developers. Load & Generation time (LG Time): It is the amoun ot time taken to load and generate the programs. Normally it should be 100 or 200 nano seconds. If LG Time is more we can consider the following 1. Buffer areas are configured with small size (Increase the buffer size) 2. Buffers are swapped RFC+CPIC time: CPIC: Common programming interface for communication. It is the amount of the time taken by the work process to communicate with external systems like BW, CRM, SRM etc. Generally the time is not defined because it varies from system to system Enqueue Time: The amount of time taken by the dialog process to communicate with enqueue process to obtain the lock while updating records. Normally it should be 1 m/second in the central instance. It should not be more than 100 m/sec if the request is coming out from dialog instance. "enqu_ tablesize is the parameter which is used to define the size of the enqueue table. Database Time: It is the amount of time taken by the database to process user request. It should not be more than 40% of (Response Time Wait Time). If it is expensive we can conclude the following: 1. Expensive Report: With expensive SQL statements 290

2. Database Statistics are outdated: Run the statistics using DB13 3. DB buffers are not sufficient: Increase the buffer size (ST04) or using he parameter db_block_buffers in initsid.ora file at the O/S level. 4. Missing Indexes: Indexes are missed out which can be traced out in DB02 (Recreate indexes, Create appropriate indexes). One primary index and upto 5 secondary indexes 5. Exclusive Lock waits on the DB: Go to DB01 and find out exclusive lock waits Response Time: It is the sum of all the above mentioned times i.e. Wait Time+ Roll Time+ Roll Out Time + Processing Time + Load and generation Time + Enqueue Time+ (RFC +CPIC ) Time+ DB time

Work Load Analysis

It is used to display the work load on the system based on time. It is also used to display the following: 1. Response times of the processes 2. Response times of the users, reports, transactions etc.. Time profile gives you the time consumption based on each component. In order to populate information into the screen ST03 we need to run standard background jobs. ST01: System trace It is used to trace the following: 1. RFC trace 2. Buffer Trace 3. Authorization Trace 4. SQL Trace 5. Enqueue Trace 6. Kernel Trace


These need to be explicitly switched based on the requirement. Switch off the trace as soon as the tracing is finished else it will populate the log files. ST02: Memory configuration Monitor:

ST03: Work Load Monitor

ST04: DB performance Monitor

ST05: SQL Trace

ST07: Application Monitor It is sued to find the following: 1. No of application servers 2. No of W.P in the entire R/3 system 3. Total no of users created in the system 4. The components and the load on the sytem

ST08: Network Monitor: ST14:


Normalization: It is the process of splitting of larger tables in to smaller table by enacting primary keys, foreign keys and secondary keys relationship. Various DB Vendors are: 1. Oracle 2. SQL Server-Microsoft 3. DB2 IBM 4. MAX DB- SAP 5. Informix- IBM SAP gives an interface to work on above mentioned systems. SAP never recommends working on the DB directly KDB (database), a database server created by Kx Systems for real-time business applications KDB, a Kernel debugger, a type of tool used for debugging the kernel for Linux and Unix

A kernel debugger is a debugger present in some kernels to ease debugging and kernel development by the kernel developers.

The Windows NT family of operating systems contain a kernel debugger. BeOS contain a kernel debugger. DragonFly BSD employs a built-in kernel debugger.

No kernel debugger was included in the mainline Linux kernel tree prior to version 2.6.26-rc1 because Linus Torvalds didn't want a kernel debugger in the kernel KGDB and KDB are two kernel debuggers for the Linux kernel. KGDB requires an additional machine for debugging, whereas KDB allows the kernel to be debugged on the same machine while the kernel is running. The debugger included in Linux is KGDB.


IBM- AIX, HP-AUX are KDB Windows 30-40% KDB Linux- No KDB When the ORACLE DB is installed it is installed by default with the following Users: 1. SYSTEM (user)/MANAGER (Password) 2. SYS (user)/ Change_on_install (password) When R/3 system is installed the following users will be created in the DB. 1. SAP R/3 up to 4.6c 2. SAP<SID> from 4.7 onwards (SAPSID is the schema owner) 3. SAPSR3 DB in new dimensional products like XI, EP. SAPR3, SAP<SID> and SAPR3DB are the schema users of the DB Apart from the above we have 1. Ops$<host name>\ <SID>ADM 2. Ops$<host name>\SAPSERVICE<SID> Query: A normal sql query looks in the following way Selest * from DBA_Users;

Roles: Roles provides authorizations to the users 1. SYSDBA: It provides authorizations for the following activities: system startup, system shutdown, create DB, Modify DB, Create users, roles, tables etc SYSDBA has the entire authorizations from the DB 2. SYSOPER: He is an operator to start the DB and stop the DB Back up, Restore except creating DB
If a user connects as SYSDBA, he becomes SYS, if he connects as SYSOPER, he becomes PUBLIC.


First, we connect sys as sysoper: Connect sys/my_secret_password as sysoper

Who am I? SYS@ora10> show user Same thing, but connecting as sysdba: Connect sys/my_secret_password as sysdba Who am I? SYS@ora10> show user USER is SYS Now, I, being Rene, want to connect as sysdba and then as sysoper. In order to do so, I need to have the sysdba and sysoper privileges: Grant sysdba, sysoper to rene; Now, I can connect as sysdba: Connect rene/another_secret_password as SYSDBA Who am I? SYS@ora10> show user Altough I have connected myself as Rene, giving my (not sys') password, I am sys: USER is SYS As sysoper: Connect rene/ another_secret_password as sysoper Who am I? SYS@ora10> show user USER is PUBLIC

SYSDBA and SYSOPER are administrative privileges required to perform high-level administrative operations such as creating, starting up, shutting down, backing up, or recovering the database. The SYSDBA system privilege is for fully empowered database administrators and the SYSOPER system privilege allows a user to perform basic operational tasks, but without the ability to look at user data. The SYSDBA and SYSOPER system privileges allow access to a database instance even when the database is not open. Control of these privileges is therefore completely outside of the database itself. This enables an administrator who is granted one of these privileges to connect to

the database instance to start the database. You can also think of the SYSDBA and SYSOPER privileges as types of connections that enable you to perform certain database operations for which privileges cannot be granted in any other way. For example, if you have the SYSDBA privilege, then you can connect to the database using AS SYSDBA. The SYS user is automatically granted the SYSDBA privilege upon installation. When you log in as user SYS, you must connect to the database as SYSDBA. Connecting as a SYSDBA user invokes the SYSDBA privilege. Oracle Enterprise Manager Database Control does not permit you to log in as user SYS without connecting as SYSDBA. When you connect with SYSDBA or SYSOPER privileges, you connect with a default schema, not with the schema that is generally associated with your user name. For SYSDBA this schema is SYS; for SYSOPER the schema is PUBLIC.

Two very special and important system privileges are SYSDBA and SYSOPER. Following table describes the power lies beneath these two system privileges.

SYSDBA Create new database Startup, Shut down database Alter database with the OPEN, MOUNT, BACKUP, CHANGE CHARACTER SET, ARCHIVELOG and RECOVER options Create SP file SYSOPER Startup, Shut down database Alter database with the OPEN, MOUNT, BACKUP, ARCHIVELOG and RECOVER options Create SP file Example:

CREATE ROLE hr_emps;

GRANT SELECT, UPDATE ON emp_test TO hr_emps;


GRANT hr_emps In this example we have first created the role hr_emps and next we assign certain privileges to it and finally we have assigned it to all the employees of hr (Human Resources department). After a month, new business rule comes up which says that all the hr employees should only be having SELECT privilege on emp_test table. To implement this rule all you have to do is to revoke the privilege from the role e.g.

REVOKE UPDATE ON emp_test FROM hr_emps;

Database Startup: Database is started and stopped by using the following commands 1. Startdb 2. Stopdb It can be started as a part of SAP Stopdb will stop the database. When the database is started it looks for port 1521. This port is configured for listeners. More DBs ,ore ports. Listner.ora: This file is used to configure the database and the port number. This can be configured by using the SQL net configuration. It reads from file TNSnames.ora to resolve the database. Listner Status: Use command lsnrctl to check the listener status. 1. Go to home directory by logging as <SID>adm. Use command lsnrctl listener control n the command wondow <listener>prompt appears. Type status Listener> status If it is not started give <listener> start listener.log is located in the home directory. 297

This gives the information about listener port blocked and why it is not starting. 2. SQLNET_ORA: It consists of the server details. It is required on dialog instance. Environmental Variables: When the oracle database is started it looks for ORACLE_HOME ORACLE_HOME is the environmental variable which we need to set up as user type in the central instance and all the dialog instances. Path: Path needs to be set up for ORACLE_HOME/bin ORACLE Start Up Process: Oracle is started up in the following modes/phases 1. No mount phase: During this phase initialization files are evaluated. SGA is created. The database is not appended and it is not operational. It is used to build the control files and restore the control files. DB is not mounted. 2. Mount: The DB is mounted. SGA is created but the data files are not opened. It is used to restore the data files. DB is operational only for few users like SYSDBA 3. OPEN MODE: The DB is open. The users can logon to the system. SHUT DOWN the DB: The database can be shut down by using the following. 1. Shutdown normal: When this command is issued no users will be allowed to connect to the DB. Existing users will continue their work. If these users logged off the system will shut down normally. 2. Shutdown immediately: No new users are allowed. Existing transaction will be completed and wither a commit or rollback takes place. In shut down normal the DB will be consistant while restart the DB 3. Shut down abort: The system will shut down without any notification to the users. All the open transactions could not be completed or rolled back. Therefore the system inconsistent. A small process SMON will perform instant recovery during the restart. 4. Shutdown transactionally: Open transactions are allowed to complete and no new transactions are allowed. The DB consistent after restarting DB. OPS$ mechanism: Oracle parallel server 298

It is a mechanism which allows the O/S users to connect to the DB without any password provided that the following parameters are set in init<sid>.ora 1. remote_os_authen= true 2. os_authent_prefix= OPS$ init<sid>.ora: It is a file that contains the DB startup parameters control file location log and SGA [SSA, log, DB_buffers] Modifying this profile requires instance restart. Init<SID>.sap:
The initialization profile init<DBSID>.sap contains parameters that influence how the SAP tools perform various functions. It is usually stored in directory <ORACLE_HOME>/dbs (UNIX) or <ORACLE_HOME>\database (Windows).

This specifies the things like back up type, back up device tape size, tape copy command and mostly related to BRTOOLS for backup and recovery. To configure the SAP tools BRBACKUP, BRARCHIVE, BRRESTORE, and BRCONNECT, you must use the initialization profile init<DBSID>.sap. You can edit the file with a text editor. If you do not make any changes, the SAP tools use the default values for the parameters. Before you use one of the SAP tools, find out exactly which parameters you have to configure. Pay particular attention to parameters without default values and parameters that have device-specific information or require special platformspecific commands. Init<SID>.dba: This is used to look up when users withy DBA privileges is logged on to utilize 1. brtools 2. SAPDBA Modifications to this file are performed by the system, whenever the privileges are modified. Both the Oracle and SAP parameter files are usually found in $ORACLE_HOME/dbs. Work Process Connectivity Mechanism: 1. User starts an instance 2. OPS$ mechanism is used to connect to the DB, without any password (SAPSERVICE<SID>)


3. Service user connects to the DB without password and gets the password for Schema Owner which is residing in the table SAPUSER 4. Sapservice<SID> is the owner of the table sapuser. SAPUSER table consists of only one entry schema user ID and password. In sapuser table password is stored in the encrypted format 5. OPS$ user gets the password from the SAP table and disconnects from the DB 6. Work process reconnects with SCHEMA ID and password. The work processes is connected to the DB. Note: To check the connectivity between work processes and DB use the command R3trans-d. Trans.log is created current directory. Go to AL11 go to Work directory then check dev_w0, dev_w1 7. SAP schema ID password is stored in two tables SAPUSER and dba_users 8. Changing the password at DB level will not work for SAP<SID> because it is stored in two tables. Use SAPDBA tool or brconnect to change the password of SCHEMA ID (AL11, ST11) User requests a report from the database. R/3 work process cannot work on the database. Instead it will assign the task to shadow process of DB. Shadow process checks the following: 1. If the statement was executed earlier 2. If the table is existing or not 3. The fields are existing or not 4. It will check the DB and defines the shared pool size, nearest plan to SQL execution to fetch the data. 5. Based on the execution plan shadow process requests the content form the DB 6. The content is fetched into DB buffers from storage and responded back to the R/3 buffers. 7. If the same request comes again it will fetch from the DB buffers. Update Request: 1. When a user requests to update a transaction work process hands over the request to shadow process


2. Shadow process checks or table definitions and goes to the DB to update the DB buffers and DB records 3. Shadow process fetches the content to be updated onto DB buffers 4. While getting the content it will try to get the lock so that the records will not be modified by others 5. In order to roll back during instance crash, the content is written to undo segments 6. The contents needs to be modified are copied into log buffers 7. User shadow process updated the records in log buffers. Once it is committed it will move to DB buffers and the content is marked as Dirty Buffers. 8. In order to save the transaction it will be updated to log files log writer process (LGWR). 9. After check point interval DB writer reads the contents from th DB buffers and updated the DB and sends a request to process monitor (PMON) to release the locks and undo segments. Data will be released after undo_retention_time (parameter in init<SID>.ora) 10.If the instance is crashed abnormally system monitor (SMON) will read the content from the log files (DISK) and updates the DB. This is called as roll forward mechanism. 11.If the content is not updated in the log files (transaction not committed) PMON performs roll back mechanism and releases the locks.

SAP Directories: SAP Trace: It is used to write the traces by the system alert<SID).log is the file which is populated continuously logged or documenting important activities like log files which changes in the parameters etc SAP Check: This will be populated when the following commands are issued 1. Sapdba-check 2. Brconnect fcheck It logs the following information: 1. File name s and file paths


2. Critical files and their size 3. Table space information SAPARCH: It is used to write the log files generated by BRARCHIVE process ORAARCH: It is used to store the archive files written by ARCH process. The archive logs are coming from origlogA and origlogB to ORAARCH. It should be large enough to avoid archive struck problem SAP BACKUP: It is used by system whileperforming reorgqanization. It should be as big as the size of the exported content. ( Tables ,DB, Table Spaces) Origlog A & B: These are the log directories which are populated by log writer from log buffer. This files are read by t perform role forward mechanism by SMON in case of an instance crash Mirror Log A and Mirror Log B: These are the mirror copies of the above log files SAP data1, data2.datan These are the physical storage locations of the DB. Data files are located in the directories. Control Files: These files are required to restore the DB. These fies are written and updated by the system continuously. Information like database changes made to data file, storage locations, log sequence number, system change number. losing the control files will not allow to restore the system file. So it is recommended to store the control files in six different physical locations To find the six physical location go to init<SID>.ora and add the control file location. DB buffers are used to store the content accessed by the server process (Shadow process) or background server process. DB buffers are configured by parameters db_block _buffers. 302

DB buffers help to reduce the fetches from the database. Log Buffers: It is used to log the changes made to the database content. It only documents the log block which needs to be modified along with the content. Log buffers help to write the changes using fast track mechanism and transactions commit will be configured only after writing to online redo log files .( Original logs) Log Writer: (LGWR) It is the process used to write from log buffers to Online redo log files (origlog files). Log worter triggers under the following circumstances 1. Whenever 1/ of the log buffer is full Note: Log buffer size is determined by log_bufer (20 MB) 2. Whenever the changes reaches !MB of size 3. Whenever commit occurs 4. Before the DB writer writes the DB from DB buffers 5. Log buffers are cclic buffers 6. Log buffers are sequentially written to online redo log files Database Writer (DBW): It writes the contents (dirty buffers) from DB buffers to DB. It is triggered during the following circumstances. 1. Whenever check point occurs Note: check point interval is defined in init<SID>.ora 2. Process scans for space I the DB buffers. If it could not find them it triggers to write the dirty buffers to database 3. Dirty buffers in the DB buffers reach threshold values. It is depending on init<SID>.ora. it happens to every 30 seconds Log Switch: There are two online log files (origlog A and origlog B). These log files are continuously updatd by log writer process from log buffers. If orig logA is full it will be closed for writing and logB will be opened for writing. This mechanism is called log switch. During the log switch log file number is incremented (LSM- Log sequence number). 303

ARCH process: The process of writing online redo log files into ORAARCH directory is called as ARCH process. This is done by ARCH process. In order to have this mechanism to work we need to set paramenter ARCHIVE_log_mode=yes The database administration will set this parameter to YES in all the productive systems. This mode can be set to NO or FALSE in quality and development systems. ARCHIVE_log_mode can be set up in SAPDBA or BRTOOLS. SMON: In case of instance crash it is used to restore the DB from log files(role forward mechanism) and rolls back is committed.

PMON: Process Monitor It is used to rollback the user transactions and the locks held by the users. Data1.datan files: ORACLE database is stored in the hard disk in terms of blocks. Each block can consists of either 4KB or 8KB. SAP uses 8KB. The size of the block is determined by the parameter db_blocksize=8192 bytes (8 KB). Extents: The continuous blocks are allotted in terms of extents. Extends a group of blocks. Extends are assigned in terms of init extents, minimum extents, nest extents and max extents. The extents allocation is stored in tables based on their category of tables TGORA (Tables)& IGORA (Indexes) Segments: Group of tables or indexes (It can be a single table or index or a group of tables) Table Space: It is logically defined to store the tables and indexes. Each table space is pointed to N number of physical data files. But data files can be pointed to only one table space. 304

When table space is created using the statement create tale space we need to specify the size of the data file. If the table space is full the data files are full and the data cannot be inserted or updated. Note: If the table space is full we get an error ora_1653 and or_1654 table space overflow. In this situation we need to alter the table space by using commands SQL> alter tablespace add datafile; SDL>alter tablespace resize datafile; Note: SAP never recommends to use the above commands in turn it recommends to use SAPDBA/BRTOOLS where knowledge on SQL commands is not required. Extents Allocation: For each of the tables extents are allocated based on their category referring to tables TGORA & IGORA. When a table is defined it is assigned wit initial extents. When the assigned extents are reached it will throw an error. max extends reached with an error ora1631 (Related to the tables) & ora 1632 (Related to Indexes). Use SAPDBA/BRTOOLS to extend the extents. Note: All the above errors will be resulted in ABAP dump and logged in SM21 and ST22. Note: For all NETWEAVER 2004 components maintenance optimizer is necessarily installed Table Spaces: There are 2 types of table spaces 1. DMTS: Dictionary managed table space (Up to version 9) 2. LMTS: Locally managed table spaces DMTS: The space cannot be utilized because it cannot be reorganized. But in LMTS unused space can be automatically reorganized. There is no need to adopt next extents (SAPdba_next). In 4.6c we have around 27 table spaces which start by default with PSAP and ends with either data or index LDP Ex: PSAPRABD, PSAPTABI From 4.7 EE we have six table spaces 305

1. PSAPUNDO 2. PSAPTEMP 3. SYSTEM 4. PSAP<SID> 5. PSAP<SID><Rel No> 6. PSAPUSR PSAPUNDO TABLESPACE: It is used to store the before image of a transaction. It should be large enough to hold a complete transaction. PSAPUNDO replaces PSAPROLE and it holds the data until it is full or until the value mentioned in undo_retention_time. PSAPTEMP TABLESPACE: It is used to sort the data. It should be large enough to sort the data. BACK UP: In order to restore the database in case of failures (Media Disasters) media failure means logical errors, disk crash, power crash etc.. In order to restore the DB we require a valid back up. The areas which need to be backed up are 1. USR is required in R/3. 2. Data Files 3. Log Files 4. Control Files Rel No: Release Number

Types of Back Up: 1. Off line backup

2. Online Back Up 3. Incremental Backup 4. Partial Back Up


1. Offline Back Up: The backup will be taken off line, users are disconnected and the R/3 system is shut down. The backup is consistent to restore the database. Note: We do not take regular off line backup (Take during off peak hours). Mostly the companies which are not supporting on line back up. Off line backup can be performed using SAPDBA tool or O/S backup, BRTOOLS, Native database backup and 3rd party tools like VERITAS, BRIGHTSTORE, ARCSERVE, IBMTEVOLI> BRBACKUP can also e scheduled through command window or using crips. Brbackup mt offline, brbackup m dev verification. (mt, m are scripts). 2. Online Backup: In an environment where database shut down is not supported we perform online back up. Online backup is by default is not consistent, but consistent along with the log files. This is also called as consistent online backup. 3. Partial Backup: If the database sizes are very huge we can perform backup individually based on tables, table spaces etc Partial backup is used in this particular case. If we want backup of recent data then also we can do the same thing by using the partial backup. 4. Incremental Backup: IF the DB size is terabytes taking the entire DB backup either offline or online will consume more time. We will take full backup either weekly or monthly (called as Zero Backup) and subsequently everyday perform incremental backup that is only changes made after the zero backup. Backup Life Cycle: General back up life cycle is 30 days. But SAP recommends 7*4=28 backup. Weekly Backup: w1, w2, w3, w4, w5 Monthly Backup: M1, M2, M3, M4, M5 Tapes Management: 1. Ensure that we have enough tapes in the data center 2. Check the consistency of the tapes at least once in the backup life cycle.


3. Allow the tapes to fill only up to 90% 4. Check the tape compression ratio at least once in the backup life cycle. 5. Keep at least 30% tapes in reserve 6. Monitor the DB growth from time to time and plan the capacity of tapes. Optimizer: It defines the execution plan to fetch the data from the DB. There are two optimizers: 1. Cost Based Optimizer 2. Role Based Optimizer SAP uses cost based optimizer which is set by parameter cost based optimizer to true. It is set in init<SID>.ora. SAPDBA & BRTOOLS/ BR GUI: These are character based interface tools where users can work on DB without being a DBA. SAPDBA is applicable up to WEBAS versions 6.20. Functions of SAPDBA: 1. Start and Stop the instance 2. Instance specific information 3. Table space administration 4. Reorganization 5. Users ad Security 6. Backup Restore & Recovery 7. Change the archive log mode 8. Switching logs Regularly We Do (In DB concern): Table space administration:


When you click on SAPDBA or execute from command prompt a black window is displayed. Before displaying it checks init<SID>.dba whether the user has necessary privileges to run SAPDBA tool. If the user doesnt have privileges it will not be displayed. Privileges to the user can be provided by using the following command: Ora_dba_usr.sql in the kernel directory. Select the option c for going to table space administration. It displays all the table spaces along with their allocated space and percentage of space utilized. When the errors ORA1651 & ORA16534 occurs we do this based on the companies threshold values. If its exceeds use DB13 to give SAPDBA check Now select the critical table space and add data file to check the disk space before adding the data files. You are supporting versions earlier than 4.7EE you need to decide the drive and directory where data files belonging data/indexes are added. The above processes is documented and ensure that we read documents completely before performing the above exercise. Table space overflows can be handles by recycling the data files. Select the option D reorganization select the table pace and data file and resize the data User & Security: It is recommended to use SAPDBA tool to change the password of schema owner. Select option M Users & Security and navigate to change the password of schema owner. Note: Do not try to change the password of schema owner using command alter user id identified by password Because the password is stored I sapuser and dba_user BRTOOLS: Backup restore tools: Brtools/brgui(JAVA based GUI) Brtools provide various functionalities similar to sapdba but with extensive privileges like create table space, drop tablespace. Some of the BRTOOLS are 309

1. BRCONNECT 2. BRBACKUP 3. BRRESTORE 4. BRRECOVER 5. BRARCHIVE BRBACKUP: It is used to schedule whole offline backup, online backup etc We can initialize brbackup from the command line or using DB13. Go to DB13 (DBA calendar) select the data right click openselect the option to backup the database Note: Database backup is performed by using brbackup. We can also schedule at command line using SM69 & SM49 or a batch script can be used to schedule the back up. BRARCHIVE: It is used to backup archive log files from ORAARCH directory. BRARCHIVE uses to tape or disk, BRARCHIVE uses various technologies to safeguard the archive log files. We can see ARCHIVE stuck in SM21 & ST22. 1. CDS: (Copy Delete Save) BRARCHIVE process copies to the tapes twice and deletes the log files from the ORAARCH directory. If the BRARCHIVE is not When the archive struck occurs archive process cannot archive on line redo log files. Log switch fails and log buffers also gets filled because log writer could not write to redo log files then the user encounters hour glass problem. Resolving the Archive Struck: Create a dummy file of at least 500 MB in the ORAARCH directory (UNIX).For windows copy dummy file of 500 MB into ORAARCH directory. Whenever the problem occurs delete the temp dummy files, so that users can start working they will stop screening. Schedule BRARCHIVE to copy into ORAARCH in to tape or disk. Note: Do not delete or move the ORAARCH contents manually to any other physical location.


Note: Backup type (off line, on line) back up type2, type 2 copy command. Tape size are configured in init<SID>.sap BRRESTORE: BRRESTORE is used to restore the BACKUP from the database created by BRBACKUP. The tapes should be tagged and released. BRRECOVERY: It is used to recover the database from a Point of Time. Example: I am applying support packages and the system struck/corrupted at 3 P.M on 01/02/2010 Daily: I have a valid back up of last night which was taken at 3:30 PM Hourly: I do have a BRARCHIVE back up which was taken at 2:30 PM 1. BRRESTORE: Getting the system up 3:30 PM 2. BRRECOVERY: restore the system up to 8:30 PM and recover the system until time 2:30 PM (or) specify log file (1:30) to restore from log files. 3. BRCONNECT options: The following are the options available with the BRCONNECT tool.

1. BRCONNECT f next 2. BRCONNECT -f check 3. BRCONNECT f state 4. BRCONNECT f clear old 1. It is used to adapt next extents a SAPDBA 6.20 version next Also close the same function schedule this activity using DB13 at least once in a day. 2. BRCONNECT f check: It is scheduled based on the requirement but at least once in a day. This job populates the directory SAP check with all the data files along with this space utilization. 3. BRCONNECT f status: It is used to perform to two fold jobs. In SAPDBA we used to use House Keeping Jobs


i. ii.

SAPDBA psap% SAPDBA check Earlier Versions

This job identifies the tables whose statistics are outdated and in the next stop it will update all the tables. DBSTATIC: The table which is used to populate the tables whose statastics are outdated. It is scheduled at least in a weal using .dbb, .bat, .chs, .ksh.

4. BRCONNECT f clearold: It is used to clear thr old log files Note: BRCONNECT is also used to change the password of SCHEMA

SAP Reorganization: The data is populated into the DB. As the data grows the query times also degrade. Moreover there are some extents (Which is unused). There will be around 20 to 30% of space which is unused on database to effectively use the unused space. Perform reorganization from time to time. Reorganization will be performed by Export and Import of the DB. Go o SAPDBA Select the option D reorganization select export to export the database to SAP reorg directory Note: SAP reorg directory should have enough space to hold the data. Reorganization can be performed on larger table space and tables. During reorganization we need to schedule down time. SAP standard transactions for DB: DB01: It is used to find out logs. As the regular monitoring activity we need to monitor DB locks. DB02: As the regular monitoring activity we need to display the following. It is used to display the following 1. Statistics 2. Display the current sizes of the table spaces along with used space. 3. It also displays the free space statistics like (Used, Unused space..) 312

4. It will display space critical objects 5. Handling missing indexes Go to DB02 find the missing indexes select the missing indexes click on creating DB(or) go to SE14 DB12: It is used to find the backup logs. It displays over view of the back up and backup os successful or not. It also displays archive directory space. DB15: It is used to select the archiving objects of SAP. DB17: The check conditions can be customized. The same can be done using BRCONNECT f check DB20: It is used to edit the statistics. The statistics will be updated only for transparent table. DB24: Operations log Monitor Whenever the check performed it will log in DB24 Type of O/S: AIX, AS/400, HP-AU (11.11), OS/390-Mainframes, Solaris Communication: Special connection between CI, DI using optical fibers PAM Product Availability Matrix PA-USER-Personal Admin-(Pay check, leave) Pd-USER- personal Development (related to transport) It is the program (portal) which is used to send the change request into multiple systems and multiple clients. ETC is used to point to target groups rather than systems. Buffer Management: Buffers are stored in terms of directories in the memory. When the system is started the buffer areas are allocated based on the profile (Instance Profile). Buffers are built up in respective areas when the users access the content from the DB. Buffers are monitored in ST02. Buffers are managed in to space and the directories and space. If any one of them is full swaps occurs.


The performance of the system could not be gauzed initially because the buffers are not built. System performance will be increased if sufficient buffers are maintained. Do not measure the performance soon after starting the system. Wait for at least 20 to 25000 transactions take place. Buffers Hit Ratio: It should be always greater than 94%. That is out of hundred requests 94 are fetched from buffers. SWAPS: Whenever the objects are changed or buffers space is fully utilized or if directories are not enough swaps occurs. Swaps dont mean a performance issue but try to avoid more no of swaps by configuring enough space and directories. Most of the companies allow 5 to 10,000 swaps normally. Reasons for SWAPS: 1. Frequent transactions of objects will cause swaps 2. Space is full 3. 3. The directories are full 4. When the program changes Table Buffering: By default SAP defines buffering for the pre defined tables. Some of the tables are not allowed for buffering Some of the tables are allowed for buffering but buffering is switched off. For some of the tables buffering is allowed. Go to SE14 Check buffering is allowed or not The tables which are frequently accessed but rarely changed are allowed for buffering. Ex: TACT, T000, calendar tables Go to technical properties of the tables no buffering (For tables which are frequently changed and rarely accessed) Full buffering: The tables which are frequently used but rarely changed Single Record Buffering: 314

The buffering is based on primary key Generic record buffering: It is based on group of fields. Note: Do not change buffering status unless recommended by SAP notes. The elements eligible for buffering are programs, menus, screens, common user attributes, calendars, measurements tables, time settings. ST02 will get the above information. Memory Management: While installing SAP system virtual memory needs to be configured based on available memory. Physical Memory: It is the amount of memory installed on the system (RAM). Phy_mem_size is the parameter that shows the physical memory size. Virtual Memory: It is the sum of the physical memory and space allocated on the disc Extended Memory: It is a part of virtual memory which is utilized by R/3 instance. Roll Memory: The amount of memory required by the work process to roll in and roll out the user context. Heap Memory: It is a private memory part of virtual memory. Local Memory: The memory assigned to work process to handle the user request. It is defined by parameter ztta\rool_area Parameter to configure heap memory is abap\heap_limit Memory allocation to Work Processes: When the user request is assigned to W.P it will utilize an amount of memory which is specified in the parameter zttz\roll_first=20 KB (It is a part of roll area). If the memory is not sufficient it will use external memory up to an extent which is defined in ztta\roll_extension= If this memory is also not enough it will use the remaining part of the roll memory. If this os also not sufficient it will use heap memory (Private memory). If the W.P reaches heap memory it is restricted and time out paremeter will not be applicable to it.


The work process will be released only after completions of the task or heap limit is exhausted. Specified by parameter abap\heap_limit, abap\heap_area_dia, abap\heap_area_nondia If more no of W.P goes into private mode W.P congestion occurs. In order to resolve this use dpmon to identify the expensive process and then kill the process. ST02: It s used to find the amount of roll memory extended memory, roll memory, heap memory Always monitor ST02 for heap memory utilization.

Roll First (KB) WP0 WP1 WP2 WP3 WP4 WP5


Roll Area (20 MB)

Heap Memory

RFI (Request for Information) can be prepared by 3 rd party agencies like KPMG/IBM Customer 1. RFI 2. Chases S/W 3. Who needs to Implement RFP: Request for Proposal 4. Customer Will send RFI 5. Customer Choose partner based on (Time material, Fixed bid) Satyam, IBM, L&T, Accenture, Wipro RFI (O/S, DB, Components, Windows, IBM) Partner/SAP/Oracle Response





HTTP 8080

Up to version 4.6 D R/3 ITS was used to provide web functions to the end users. It consists of two components. Application gate (Agate) and Web gate (Wgate) User Request Flow: 1. User requests using the internet explorer 2. The request is received by web gate which is on the web server and redirect the request to application gate way. 3. Agate in turn sends the request to application server which will be handled by DIAG protocol 4. Server sends the response to the Agate in the DIAG form 5. Agate interprets the request into .CSS (cascading style sheet) and hands over the response to user Note: Wgate must be installed on Web Server Agate and Wgate can be installed together on single host. It is called as singe host installation Agate and Wgate can be installed on to different hosts which is also referred as Dual Host Installation. Monitoring is performed through ITS administration instance It can only process ABAP requests


Note: In order to overcome the above and to provide internet functionality to SA R/3 system ICM was introduced from SAP R/3 version 4.7 Up to version 4.6D it is referred as SAP application Server From 4.7 onwards it is referred as SAP Web Application Server ICM become an internal part of SAP and it is monitored using transactions SMICM. While installing SAP WEB AS J2EE engine is required But as planned it could not provide the internet functionality up to version 6.30 (ITS is required) From 6.40 onwards integrated ITS has become an internal part of R/3. Where R/3 systems can be accessed without ITS. It is used to handle Dynpro based applications The SAP WEB AS version is used to provide Web functionality and formed as a BASIS platform for Sap NETWEAVER SAP WEB AS 6.40 supports both ABAP stack and JAVA Stack. JAVA Stack: ESS: Employee Self Services MSS: Manager Self Services EP XI BI BD APO SRM CRM ABAP Stack BIW R/3

JAVA Stack

In order to provide user friendly environment SAP has adapted JAVA as the internet language.


Open DB Support

O/S Independent

Application Platform



Mobile Interface


Mail Server SMS

Non SAP(CSV) Applications




Process Integration with the help of Brokers & Adapters Information Integration People Integration Application Integration X .NET A FRAME P WORK


Netweaver provides technical infrastructure where applications can be hosted on any platform or any database to integrate the processes across the system to fetch information and display it to the users. How to work with ITS (Internet Transaction Server): Go to SICF (Internet communication frame work) Go to BC (Business Component) Go to GUI Go to ITS Sap WEB GUI Right Click Web Server URL: http\<hostname>:port number\sap\bc\ITS\sap\webgui\sap clients 320

Parameters: 1. ITSP/enable=1 (RZ10) 2. Ms/http_port=8080 (or)8081 Version: 4.7 EE ext set 1.00 (For 6.30) a. EE ext set 2.00

JAVA: 1. Unicode language 2. Platform independent (OS/DB) 3. OOPS (object oriented programming system): Encapsulation, Inheritance, Polymarphism 4. Integrations 5. Multi lingual 6. Robustness, secure network 7. User Friendly GUI

1. JVM: Java Virtual Machine: It is platform dependent and it is used to execute the platform independent byte code deployed in JAVA When java is programmed it ends with .java extension. This program will be compiled to a .class extension. The compiled program is platform independent. In order to interpret the compiled program we require JVM (Java Virtual Machine). 2. JRE: Java Run Time Environment: It provides an environment to run the applications designed in JAVA. It is required to install all the NETWEAVER components. 3. J2SDK: Java tools for Standard development Kit: It provides a platform to develop and deploy JAVA applications 321

Note: Java is used to develop and deploy internet based applications while connecting to SAP and Non SAP systems. Installation Options: WEBAS JAVA can be installed as a standalone engine JAVA and ABAP can be installed together JAVA can be added on to the existing ABAP engine WEB Dispatcher ICM JAVA Dispatcher Work Processes MSG ENQ DB ICO ABAP Dispatcher Work Processes MSG ENQ DB

WEB Dispatcher: 1. User request over the internet explorer 2. The request is handled by Web Dispatcher Web dispatcher is a piece of software which can be installed on any machine which is connected to internet Web dispatcher provides security 3. Web dispatcher communicates with message server to identify least loaded server and direct the request to respective ICM 4. ICM receives the user request and segregates whether it need to be send to ABAP dispatchr or JAVA dispatcher 5. ICM is instance specific 322

6. The request is received by JAVA dispatcher 7. JAVA dispatcher assigns the request to server processes. Server process has threads to handle the user requests 8. This is the only process where user request will be connected to complete transactions 9. Session information will be stored as cookie and passed on to the thread 10.The cookie information will be deleted when the user session is terminated 11.While updating a record it talks to enqueue process and obtains the locks Start Up and Shut Down of WEB AS JAVA: 1. It can be started on its own when it is installed as a standalone engine Commands: Startsap on non windows environment will be used and on windows MMC will be used to start and stop the system 2. When it is plugged with ABAP engine ABAP start up frame work initiates JAVA startup provided that start\J2EE=1 (Located in ABAP engine) 3. It can also be started from transaction SMICM Note: Java is always is add-on to ABAP but ABAP cant be add-on for JAVA engine JAVA startup framework: 1. When JAVA instance is started it looks in to profiles (STARTUP and Default) and start the DB. 2. Jcontrol process is also started and connects to the DB to get the instance properties, updated to O/S leve; 3. Jcontrol: Boot strap process will read the O/S profiles and starts all the services. JControl also starts Jlaunch process and assigns memory to them 4. Jlaunch: Jlaunch start up process is initiated b JCOntrol process. This process ends itself when Jcontol is stopped Note: Startup logs can be found in work directory. Startup Problems: 1. Could not find the JVM. We need to set the path (Enviromental variable)


2. Memory is not enough t start the instance (Increase the memory based on the availability) 3. DB is not started (Check alert,SID>.log, lsntctl, oracle services) 4. JRE is not compatible ( 1.4.9 to 1.4.12)

JAVA Admin Tools: File Structure: SCS-SAP central Services (Msg, Enqueue) \usr\sap\sid\ Instance directory is located in \usr\sap\SID\JC01 Go to work directory dev_Server, dev_disp, dev_Jcontrol, sapstart.log, dev_bootstrap Cluster: It is the combination of dispatcher and server. It is nothing but instance and always reports to the instance Individual server log and dispatcher log can be found as default.trc Go to J2EE click on admin J2E admin directory: it is used to provide admin tools where services are configured Visual Admin Tool: (VAT) Click on go.bat in admin directory to go to visual administrator tool. Config tool directory: This is used to configure the initial settings of JVM> Restart is required. Add server process,memory settings of JVM. Restart is required. Add Server process, Memory Settings and LDAP settings. LDAP (Light weight Directory access Protocol). TELNET Tool: It is used to communicate with JAVA system remotely. JCMON: It is a CLI to monitor the local and cluster configuration. Ports 1: By default message server listens on 3900 for ABAP 3600. Ports 2: Visual Administrator listens on p4 (Port 4). That is the port number ends with 4 324

JAVA instance port: By default 50,000 is used as port to access JAVA instance over the internet provided instance number is 00. The formula to calculate the port number is: 50,000 + (100* instance number) + default number. TELNET listens on port number 8. JVM listens on port number 18. If the port number is 99 calculate the instance number: 59900, 59904, 59908, 59918 Post installation Activities of JAVA instance: 1. Check the installation log to ensure that the installation is performed successfully 2. Install SAP License. Go to Visual Admin Tool It will display the H/W key get the H/W key go to market place and get the license key license will be in the form of text file go the conflicttool.bat go to file add server process select the dispatcher increase the heap size go to umel.data to configure directory server so that domain users can connect to the system without any password select the server process and go to services to configure the services we can increase http cache size in http servers t o 3000-4000 When working on config tool JAVA Web AS is not required of there is any cahgne mode to config tool it will defect the DB. User admin is used to configure run time parameters most of the parameters are effective immediately Ex: RFC destination, Creating Users TELNET Tool: It is used when we could not logon to JAVA instance Applying the patches: On WEB AS JAVA and components installed on it the components which need to be patched are 1. JRE 2. JAVA Engine 3. 3. Composite Application Framework 4. Visual Composer


5. EP STPI: Solution tool plug in (Component)

Patching Tools: Patches can be applied by using the following tools: 1. SAPINST: It is used to apply patches to J2EE engine 2. SDM: Software deployment Manager: it is used to apply patches to all the components SDM s located in the usr\sap\SID\JC01\instance number\SDM\remote.bat (GUI) In order to initiate SDM we require user ID, Password and port number. USER ID is SDM, password is SDM by default, but will be changed during the installation. Port: 50,000+ 100*instance number+ 18 (Default) Only one user can be connected to SDM. While applying patches to SDM, we need to specify the path either DB file system or J2EE SDM can also be initialized t apply the patches either online of offline dsployment JSPM: It is located in usr\sap\sid\instance\J2E\JSPAM\go.bat Click on go.bat to go to JSPM interface. Patches will be copied to the directory Trans\eps\in File types that can be applied as support Packages: The following extensions will be used to apply support packages and patches. 1. .sda: Software development Archive 2. .war : Web Archive 3. .rar: Runtime Archive 4. .ear: Enterprise Archive 5. .jar: Java Archive 6. .sca: Software component Archive Note: We can revert back the packages. We cannot revert back the SPAM. 326

Go to config Toll directory and click on configtool.bat Logon will be performed without any password. Note: If SDM is blocked system hangs or while initializing SDM it says that user 8is already connected to SDM. Hoe to Resolve This: GO to MMC ( IN UNIX use $ps ef|grep SDm to find the process ID) find the process id and stop it and retart it again go to J2EE process list SDM Right Click Restart J2EE engine should be patched before all other patches. GO to COnfig tool click on file go to parameters the configured parameters can be exported go to cluster ID Selece server Select C-ID Security port UME service Go to LDAP Change the configuration data files ADS/write, Specify the server name, Server Port, User Id, Password Elect the instance Select the server process Configure the required services for the following: 1. CAF: Composite application framework 2. User Management services 3. LDAP services 4. Security Services Define http\cache Note: Refer the note thoroughly before making any changes the config tool, ensure that config tool parameter are backed up. Memory Allocation: SAP memory for JAVA engine is allocated as follows: 1. Heap Memory: The total amount of memory which can be utilized to processing 2. Young Generation Memory: Whenever an object is accessed it will be cached into young generation memory Y.G.M is defined by the parameters: 327

-XX: Newsize=171M XX: Max New Size= 171M 3. Permanent Generation Memory: XX : Perm Size= 256M XX: max perm size=256M The objects which are reusable like JAVA Classes, packages, methods will be moved into permanent memory so that requests can access them directly. 4. Old generation or tenure generation or garbage generation: The data which is not eligible to store or cache will be moved to this area. Garbage is cleared from time to time. This memory is defined by using the formula: Heap memory-(sum of young & permanent generation) Heap Memory is defined by parameter XMS1024M Global Dispatcher Configuration: If more than one JAVA instance is configured the parameters and their values can be populated globally using this option. Global Server Configuration: It is used to set the values for the server process. Note: Global Parameters are overwritten by local parameters Working with visual admin: Initializing visual Admin: \usr\sap\sid\EP7\JC02\J2EE\ADMIN Click on the go.bat. It requires password to login. Visual Admin can be used to configure remote systems. Visual Admin is used t configure the following services: 1. Install the license using license adapter 2. Configuring RFC connections using JCORFC Processs 3. Security provider service to configure the user data store to create users and assign roles


Log Configuration Service: it is used to configure the logs which determines with what granularity the logs can be filled only errors, only warnings, only information. Log for. Services: This is used to configure the log files, no of active users who is used

Deploy Service: It is used to deploy the programs Monitor Service: It is used to monitor the performance of the system, such as application monitor, SQL Trace, Single activity trace. JARM: Java Application Response Management: It collects the data for performance.