SAP Implementation and administration guide by bob panic

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 L1 Support Tier-1 Level-1 Support-1
4 L 4Support Tier-4 Level-4 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…
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 can’t Delete,
Drop, Change objects in the system. It is also referred as monitoring Job.
2. 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…..
3. The issues which could not be resolved can be escalated to Level-3
4. Level-3 Support: Recommend the parameters for Tuning, Support Package application,
Scheduling down times, working with SAP, database activities etc….
5. 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.
Security
Performance
Data Base
O/S
Transports
1

Normal BASIS Support
We can also propose to perform all the activities.
Roles and Responsibilities:
Define the Checklist
Working on Tickets/Requests/Cases
Configuring Work Processes
Configuring Buffers
Resolving Runtime Issues
Working with Dialog Process, Update Process, background Process, Message, Spool and
Enqueue Processes
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
Configuring operation modes
Monitoring the log files
Defining and scheduling standard background jobs
2

Monitoring backup regularly
Monitoring DATABASE Standard Jobs
3

Support Architecture:
Offshore Components IBM, HP, WIPRO
CVONNECT Connectivity Landscape
Leased Line/VPN GE, COKE, HP
Work for Customer Connectivity
Directory
NESTLE:
ST02
PFCG
30 Employees
HP:
…….
…….
17 Employees
KODAK:
SM36
SM37
SM50
SM66
12 Employees
4
VIDEOCON
RELIANCE
TVS
PHARMA
OFFSHORE
SAMSUNG
RIGHT
SHORE
CUSTOMER

Connectivity from OFFSHORE to CUSTOMER/CLIENT:
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.
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.
Remote Access Cards (RAC) are used to generate Random Number (Remote
Authentication Key) i.e. generated access key.
User Request Mechanism: User request management tools are utilized for this purpose.
FAX
EMAIL
Ticketing Tool
Phone
When the request is created in the tool the status is NEW.
Status Description
New Raised Problem
5
USER
Request
REMEDY
CLARIFY
HP Overview
Seibel
SAP CRM
SYNERGY
CUSTOMID
EXCEL SHEET
Help Desk (Phone, FAX, Email)

Assigned When the Consultant Accept the Ticket
Work In progress Processing
Temp Fix Temporary Fixed, Job Aborted, Run Temporary
Pending For Approval
Closed/Completed/ Finished Problem is Fixed
Severity of the Problem:
S.No Severity Response Time Closure Time
1 Low/Normal 24 Hrs 72 Hrs
2 Medium 12 Hrs 48Hrs
3 High 8 Hrs 24 Hrs
4 Very High/ Critical 2 Hrs 4 Hrs
5 Diasster 15 Min 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.
6

Parameters for defining the Number of W.P’s:
rdisp/wp_no_dia=  For defining the number of Dialog W.P’s
rdisp/wp_no_btc= For defining the number of Background W.P’s
rdisp/wp_no_vb= Defining the number of update W.P’s
rdisp/wp_no_vb2= Defining the number of update W.P’s (secondary)
rdisp/wp_no_enq=1 Defining the number of enqueue W.P’s
rdisp/wp_no_spo= Defining the number of spool W.P’s
rdisp/max_wprun_time= 600-1800 sec  this defines the maximum time that a (Dialog)W.P can run .
DIAG Protocol Roll In
Dialog Work Process: Roll Out
Handles the user Request interactively
At least Two dialog processes are required
Each Dialog W>P requires around 75MB-150 MB of memory on an average (Memory
varies between the systems)
7
USER
Central
Instance
W0,W1…………………………Wn
Dispatcher QUEUE
U
C
SCREEN
ABAP
SQL
R/3 Buffers
DBCL
DATA BASE

Every Dialog W>P an handle 5 to 10 users 9Depending upon the type of users (Lo,
Medium, High))
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.
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 Transaction’s
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
8

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 can’t handle any user request
5. Reason: The reason for the status.
For running and hold press F1 to display the various reasons
Sleep Mode: It’s waiting for the resources on the target system
Private Mode: It is dedicated to a user. Time out will not work for this process
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 can’t be started to handle the Queue. But it’s 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…
Monitoring:
9

1. SM50: It is used to monitor the status of various W.P’s 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.P’s
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.P’s 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)
Dpmon:
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 can’t kill identify the Project ID and kill at O/S level
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 can’t be used to run the long running, time consuming expensive
programs or Reports.
10

Background Process:
The time consuming, expensive, long running programs can be scheduled in the background
to run during Off Peak hours without user intervention.
Background jobs running in Non Interactive mode and doesn’t require any user inputs
The max work process runtime is not applicable to background W.P i.e. they can run for
any number of hours.
Background process doesn’t handle part of the transaction but in time the complete
transaction is handled by them.
Background jobs are created by using Dialog W.P’s
Background jobs are defined in the transaction SM36.
Go to SM36 Specify Job Name Specify the Job Class Specify the job triggering
mechanism (Immediate/Date & Time/Event/After Job/ At Operation Mode…etc) 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.
Don’t 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 it’s status is released
3. Ready: Ready for the execution and waiting for the resources
4. Active: The job is currently running
5. Completed: the job is completed successfully
11

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
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)
12

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 External command + Type of operating system + (Parameters) + Target host system
o External program + Parameters + Target host system
External Commands and External Programs
Definition
• 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.
13

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 user—any user without background processing
administrator authorization—may run a host system command or program that has been pre-
defined 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.
14

• External programs give an administrator—a 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 ScheduledSpecify 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, Fax…etc
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
15

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 couldn’t 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
16

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:
17

Authorizations for Background Processing:
Authorizations for accessing background processing jobs can be set up for two types of users:
administrators and end users.
A user’s jobs are defined and run in the user’s current logon client, regardless of whether the user’s
background processing authorizations are set for user or for administrator.
Setting Up Authorizations
Administrator authorization setup requires the following authorization objects:
Authorization Object Value
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.
Y
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).
01
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.
LIST
S_DEVELOP (ABAP Workbench)
Allows an administrator to capture and debug background jobs by providing access to
ABAP debugging tools
User authorization setup beyond job scheduling and status checking requires the following authorization
objects:
Authorization Object Value(s)
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.
DELE (delete other users’ jobs)
LIST (display spool requests)
PLAN (copy other users’ jobs)
PROT (display anyone’s job log)
SHOW (display job details)
RELE (release other users’ jobs to start; a
user’s own jobs are automatically
released when scheduled.)
S_BTCH_NAM (Batch Processing: Batch User)
Allows a user to specify other users for runtime
authorization for a job.
permissible users
S_LOG_COM (Authorization to Execute Logical
19

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.
20

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
Committed
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:
21
DB
L.U.W
L.U.W
L.U.W
L.U.W
T
E
M
P
T
A
B
L
E

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.
22

Update Mechanism:
Whenever a user wants to update or create a transaction logs into the system using
dialog process
User logs into the Database/ R/3 system using SAPGUI
User request is received by dispatcher and keep in the queue
Whenever a free work process is available dispatcher assign it to the work process
Work process rolls the user context to task handler
Dialog user initiates a update transaction like sales order, purchase order, invoice,
billing. (Let us say modify/ change)
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
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
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
Upon the successful update (Temp Table) a transaction Id is generated
23

Transaction Id is generated form NRIV table (Number range Intervals)_
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 update
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.
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
24

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 Err-1653, 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 (Couldn’t repeat the update)
that means these records can’t 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.
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 can’t be deactivated
25

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: It’s 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
26

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.
27

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.
28
USER
TSKTT
MESSAGE
SERVER
DISPATCHER
U
C
ENQUEU
E
DI

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
Enqueue lock table resides on shared memory of the central instance
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
When the lock table overflow the error message recorded in SM21, ST22
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.
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
Rdisp/wp_no_enq= 0 to 100. Increase the enqueue process on the same server where
the earlier enqueue processes are defined
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).
The following is the procedure for the lock release:
User requires a ticket that he couldn’t update the record
29

Get the detail of the user from SM12 and communicate with the user to release the lock
If the user is not in the office communicate over mobile (Verbal) and send a mail (As per
the conversation in releasing the lock….).
Send the mail cc to project manager, team leader etc..
Get the approval to log off the user session in SM04 and release the lock.
Note: Enqueue and Update work together.
30

Spool Management:
It’s 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 usrsapSIDsysglobal
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
DB (Database) TST01, TST03
G (usrsapsidsysglobal)
31
USER
DIALOG
BTC Jobs
DIALOG
Spool Request

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 it’s 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:
The out of the spool request can be viewed before it is pronted.
Spool process reads Temse and generates out put requests.
Output requests are depends upon the access method. Access Method specifies the
type of access to the printer.
There are various access methods
Access Methods:
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.
Note: The printer can be remote or local
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.
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.
32
Sap R/3

F
It’s 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.
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.
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
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
Note: Specify the group so that only the group assigned can access the printer
Logical Spool Server:
It is defined for fail over and load balancing between printers.
(Logical Server)
33
USER
Printer
USER
LGS1

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
Note: Don’t 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: Don’t 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:
To print the cover page
Author Name
Number of copies
Name of the printer
34
Real Spool
Server
Real Spool
Server

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.
“-“: The request has not been sent to the host system or the output request doesn’t
exist.
“+”: Spool request generated stored in Temse
Waiting: Spool request is waiting to be processed by a spool work process.
In Process: The spool process is generating the output request based on spool request.
Printing: Printer is printing the request. The status will be displayed approximately 1 min
and status sets to either Complete or Error.
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.
Problem: The output request printed but contains mirror errors such as page format,
character set etc….
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:
The printer is not available or locked in the system.
35

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:
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
36
Request
Dialog Dialog
Back
Ground
Spool Request
Spool Server/Spool Process
LGS
Local Access Remote
Access
Front End

Data Transfer:
Interface
SMS FAX Email Printer Internet 90% DB Fill
The data has to be transferred in to SAP system in the following situations.
During implementation to transfer the data from legacy systems to SAP system. To test
with live data.
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.
38
SAP SYSTEM
BW
Old Legacy system

Remote Function Call: There are various types of RFC’s which are used to transfer the data.
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 Id’s 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:
Go to SM59 Click on create Define the RFC destination name.
The name should be able distinguish between the connectivity.
Define the connection Type:
3 for connection to R/3 system
2 for connection to R/2 system
Give description
Go to Technical Settings
Specify the system number
39

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 / Interface
Method C Simulator
Add message type and specify the message type.
40

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.
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. IDOC’s 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 IDOC’s 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 QRFC’s.
41

SMQ1: Is used for out bound queues
SMQ2: Is used for inbound queues
SM58: Is used for monitor the transactional RFC’s based on transaction Id’s
Data Transfer Methods:
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.
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.
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.
Session Method: This also programmed by developer but this can be used for periodic
data transfer. This familiarize with error message handling
Errors during Data Transfer:
Source /target system not available
Document problems (Document is not readable, Junk character, Permissions, document
not found, document is too old)
RFC erros lik t ID. RFC: Error like USERID, Password, USER ID not active
WE05 IDoc expenses.
42

Instance:
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 usrsapsysprofile directory.
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:
login/system_client=999 this determines the default client for all the users
zcsa/system_language= To specify the language during log on
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. It’s naming convention is “default.pfl”.
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. It’s
naming convention will be as follows:
Start_DEVBMGS<nr>_Hostname (Central Instance)
Start_D<nr>_Host name (Dialog instance)
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.
Instance Profile: It start with <SID> of instance
<SID>_DVEBMGS<nr>_<Host Name> (Central Instance)
<SID>_D<nr>_<Host Name> (Dialog instance)
43

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:
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
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:
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.
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.
Table “TPFRT” is used to store the parameter values along with versions.
Administrative Data: Which will gives you the path of each profile. Do not change this
until there is change in path of the profiles
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.
44

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).
Go to RZ11 and get the documentation of the parameter before you make any changes
to the parameters
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.
The existing profile in SYS/Profile will be renamed to “.bak” and profile is copied from
database to O/S level. Restart the server.
45

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:
Defining the Operation Mode: Go to RZ04 Define operation Mode SAP System
name, Operation mode Click on Instance/ Operation Mode
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.
Don’t 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%”
46

Logon Load Balancing
Message Server
Logon Groups: These are used to define load balancing mechanism between the instances.
These are used for logon load balancingfail 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:
47
End
User DB
L
G
1
D.I
D.I
C.I
D.I
L
G
2
D.I

User logon to the system using logon group
System communicated with message server based on sapmsg.ini and communicate with
3600+ instance number through entry in etcservices i.e. you need to maintain all the user
desktops with the above two entries ( sapmsg.ini and etcservices)
Message server keeps the info of favorite server and route the request to that instances
Advantages:
Load balancing
Fail over
Effective utilization of buffers and system resources
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 logon’s, 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
48

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
49

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
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:
50

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

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.
Both Roll in and Roll out time considered as Roll Time.
52

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.
54

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
55

7. Specify name
8. Specify the physical file
9. Specify date format
10. Specify the application area
11. Specify logical path
12. 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.
56

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
57

WORK LOAD OVERVIEW:
20 KB
Front en time or (Dispatcher
GUI TIME Queue)/Wait Time50 m/sec
RFC
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
58
DB
END
USE
R
TSKTT
CI/DI
U
C
SCREEN
ABAP
SQL
R3
Buffers
DBSC
Dispatcher QUEUE

11. Dialog Response Time
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.
4
5
6
1+2+3= CPU Time
4+5+6= Wait Time
Note: AS CPU time is included in processing time so it’s 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.
59
SCREEN
ABAP
SQL0
1
2
3

Generally it should not be more than 200 m/sec. If it exceeds it’s 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
60

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.
61

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
62

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:
1. Frequent transaction of objects
63

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
64

Buffer Synchronization:
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.
65
End
User
End
User
End
USer
DBCI
R/3 Buffers
DI
R/3 Buffers
DI
R/3 Buffers

Memory
It’s 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)
Ztta/roll_area=2 MB
Ztta/roll_first=1 MB
66
Shared Memory Private
Heap Memory
Local Memory
U.C Roll Area
Extended
Memory

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:usrsap<SID>sysprofile
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 CPU’s
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.
67

ST06: It is used for displaying CPU idle time number of CPU’s, 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 usrsap<SID>syswork
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
68

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
69

Motivation to Implement SAP
Manufacturing/ Production (Oracle Apps)
Memory (VB and SQL)
Machinery (Java and Oracle)
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 software’s are out dated then there is no support from the vendor
Proposal to Identify the S/W vendor:
70
SASTRY
GROUP of
Industries

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 On’s. 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 it’s portable across various OS’s and DB’s.
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
71

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.
SOX’s: Single transaction cannot be handled by single person
BASIC PREREQUISITES
1) Installation of IDES system and allow all the functional consultants/ Developers to
work on the system.
2) Solution Manger
72

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
73

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.
74

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.
75

SOLUTION MANAGER
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.
76

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 ID’s
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:
77

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.
78

Note: Sizing is also referred as T-Shirt size.
CPU Size: It can be small, large, medium
SAPS: Sap applications
Ex:
CPU Size No of SAPs Memory in MB Disk Category Disk Size in MB
S 5000 7869 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.
79

 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
80

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

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 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
82

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.
Activity-5:
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 OU’s 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 OU’s, MASTER Data, Business Scenarions (Update documents).
83

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 (MB’s)
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.
84

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 32-Bit 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)
It’s 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
85

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 ORACLE 4.7 EE1, 4.7 EE2, ECC 5.0, ECC 6.0
86

WINDOWS SQL,ORACLE,DB2 4.7 EE1, 4.7 EE2, ECC 5.0, ECC 6.0
LINUX SQL,ORACLE,DB2 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 DVD’s 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
87

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: Don’t use reserved key words like SAP, BIW, SCM,SRM< ERP, All etc…
Provide the entry in host file i.e. etchosts which is located in
windowssystem32driversetchosts
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)
4.7 SR1 SR2
WEBAS 620 (4.6c web functionality became WEBAS 620)
88

ECC 5.0 ECC 6.0
6.40 / 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 BASIS
4.6 C 4.6 C /4.6 D
4.7 620
5.0 640
ECC 6.0 SR1 700
ECC 6.0 SR2 700
SOLMOM 3.2 640
SOLMOM 4.0 700
XI 3.0 640
XI 7.0 700
BIW 3.5 640
89

BI 7.0 700
EP 6.0 640
EP 7.0 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.
Don’t 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.
90

 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 SID’s 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
91

 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
92

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
93

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.
94

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
95

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 DVD’s
How to load the DATA:
As we can’t 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 get’s the size from “.tpl” file and get’s 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 it’s patches and R/3 and it’s
96

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.
97

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.
98

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. Don’t 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:
99

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)
BASIS LAYERScreens, Programs, Reports, Functional Modules, Menus,
Transactions
(DATABASE LEVEL)
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.
100

Ex: measurements, Country, Currency, Time settings etc…
Support Backup
Template
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 Backup Client
Default Template
DD02L: It is a table which contains all SAP tables.
SM01: List of transactions
SM02: System Message
101
EWA
066 001 000
Cross Client Customizing
Standard Objects or Repository Objects
Client EWA
Strategy 066 001 000
Cross Client Customizing (C.C.C)
Programs, Transactions, Screens,
Menus, Functional Modules

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.
SINGLE SYSTEM LANDSCAPE
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.
102
DEV QAS PRD EWA
066 001 000
DEV QAS EWA
066 001 000
PRD EWA
066 001 000

DEV/QAS Consolidation Root Production (PRD)
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>
Consolidation Root Delivery Root
THREE SYSTEM LANDSCAPE
Multi System Landscape:
103
DEV EWA
066 001 000
Standard Objects or
Repository Objects
QAS EWA
066 001 000
Standard Objects or
Repository Objects
PRD EWA
066 001 000
Standard Objects or
Repository Objects
DEV PRDQAS

OFF SHORE INDIA
US
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
104
DEV QAS
DEV
PRD
QAS
PRD
QASDEV

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 E-mail.
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
105
400 300 200 EWA
066 001 000
Standard Objects or
Repository Objects
400 200 EWA
066 001 000
Standard Objects or
Repository Objects
500 EWA
066 001 000
Standard Objects or
Repository Objects

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 user’s 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-on’s 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.
106

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.
107
500 EWA
066 001 000
Standard Objects or
Repository Objects
500 EWA
066 001 000
Standard Objects or
Repository Objects

QASCLNT000 Client Copy PRDCLNT000
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:
108

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 C.S CCC & REP Protection
CUST ARC YES 0
TEST CWR NO 1
SAND CWRT NO 1
QAS:
Client C.S CCC & REP Protection
CUST NO NO 2
TEST NO NO 2
109

SAND NO NO 2
PRD:
Client CS CCC & REP Protection
PRD NO NO 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: Don’t 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.
110

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 can’t 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.
111

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;
112

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
113

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 usrsaptrans 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 usrsaptranscofiles and RX, RO,
RT files are created in usrsaptransdata directory.
KO, KX,KT are called as cofiles or control files
Ro, RX, RT are called as Data Files
Copy the files using FTPnormal copyDVD into target system usrsaptranscofiles and
usrsaptransdata directories.
Go to STMS. Add the request and Import
Go to SCC7 to perform post client Import activities
Standard Clients
000 (Template) 001 (Backup Client) 066 (Early
watch)
Clients
DEV QAS Migration/ Legacy PRD
CUST TEST SAND BOX QTST TRNG PREPROD PROD
Client Deletion:
SCC4: Delete the entry from table T000.
114

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.
115

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 RZ10Utilities 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.
116

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…)
117

DEVELOPMENT
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.
118

Support Packages, patches and Notes:
Support Packages are provided by SAP to provide the bug fixes, functional enhancements and
resolve run time issues.
Development:
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.
119

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.
120

Customizing Request
DEV QAS
Workbench Request
121
400 300 066 001 000
400 300 066 001 000
400 300 066 001 000

CUSTOMIZING
Create super user. Don’t 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
122

• Please perform client coy using SAP_CUST profile before you start customizing.
• 36687663221261278694 for IDES system SSCR key
123

SAP BASIS Administration Tutorial . 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 backup’s are:
1. Online backup
2. Offline backup
3. Incremental backup
4. Partial backup
1. Online backup: The system continuously work and won’t 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:
125

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
126

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.
127

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
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.
128

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
129

 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:
6. 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
130

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:
131

Output of H/W sizing:
The output f the hardware sizing is the requirements in terms of SAPS.
H/W Sizing:
Disk category SAP’s CPU Category Memory in MB Disk Size
S,M,L,XL,XXL 900 S,ML,XL,XXl 3200 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 CPU’s.
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 CPU’s.
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.
132

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:
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)
3. SAPB1:
It is a product which is specific to particular business
Ex: Textile, Fabrication, Banking
4. SAP ALL IN ONE:
It is a combination of various functionalities. BIW, R3 come together as one product.
Note: SAPB1 is not a part of Netweaver.
133

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 DVD’s 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. Specify the host name and IP address in etc/hosts
11. Install the O/S with relevant patches
12. Install the RDBMS S/W and patches
13. Set the file sharing to the maximum of “NIC”
134

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 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
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.
135
Solution
Manager
BW
XI
CRM
R/3
XI/EP
AP

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
Templates available can be used or templates can be avoided.
2. Business Blue Print Phase: It is configured in “solaro1”. It is used to configure business
scenarios which need to be implemented in the project. Go to SOLAR01 select business
scenarios -> go to structure -> Go to Configure elements -> press F4
136

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
137

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 DVD’s 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 dosen’t 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 DVD’s used for installation are
1. Installation maser DVD
2. Kernel [Release Specific] 6.40 or 7.00 (8.00 will come soon)
3. EXPORT DVD’s. It consists of component specific data such as tables (Everything is stored
in the database)
138

4. JAVA DVD’s which are required for providing graphic solutions (IGS-Internet 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 DVD’s. By default German & English are installed.
Additional languages are installed using this DVD’s.
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)
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.
139

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 etchost.
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 ID’s (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
140
Host Name HOSTNAME
Central
Instance

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
don’t 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 document-
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.
141
DB
INSTABCE

Specify the kernel directory and transport directory.
Specify the database instance parameters, database id, dbhost, db home (Home Directory of Oracle, db
SCHEMA’s owner of the database, db character set.
Installation log is located in the C:programfilessapinst_instdirSOLMON32WEBAS
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 id’s are instance specific.
16) Specify the path of the kernel DVD
17) 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 etcservices.
18) 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
142

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) Specify thee passwords for sysadm and sapservice<SID>.
11) Specify the location of mirror log files A,B and specify thee location of Origlog A,B and
data files (SAP DATA1, SAP DATA2………SAP 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) Specify passwords for system by default it is manager
14) Specify the password for SCHEMA user (SAP P01).
15) Specify the password for DBA user
“F1 “functional key gives help for all options.
“F4”functional 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.
143

 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.
144

Client/Server Architecture:
Reuest
Response
Client software is required for client system.
Servers are heavily loaded
Response time shoots up
Resources exhaust hour glass occurs
Database
Client software is out from client
Interpretation is done at middle level
Buffering issued frequently and consistently
Accessing is easier.
145
Client Server
Client
Client
software
application
server
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) It’s own memory
2) Buffer Areas
3) Application server specific work processes
4) Database client software.
Application server is also called as an “Instance”.
R/3 Architecture:
146
Client
Application
Server
Application
server
Server

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 IP’s 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)
147

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.
148

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
The application server will contain the following components:
149
USER
DISPATCHER
USER
XXXX
Q

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.
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
150

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 doesn’t have
authorization.
All the Steps are:
1. UR
2. DIAG
3. Dispatcher
4. Queue
5. WP allocation
6. T.H
151

7. Interpretation
8. Reaches DB
9. Shadows process
10. Response to WP
11. Format the response
12. Roll out
13. User context
14. Response to user
Database Layer: It is used to store the data of the customer. Database has its own memory, process
(Work Process), buffer area……etc.
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.
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”
152

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
153

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.
154

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, email…etc. 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.
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.
155

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.
usrsap
usrsaptrans
usrsap<SID>sysexerun
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
Central System
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
The status is Grey – Instance is stopped
156
Presentation
layer
CI+DB
DVEBMGS
A3
A1
A2
A4

Starting of SAP system:
On WINDOWS NT use MMC to start and stop the system.
Start up procedure for SAP
WINDOWS:
Send message via name_pipe
Read
Connect DB
157
Dispatcher
DB(If not
started)
START
SAPDEV_00
(SERVICE)
Msg Server
dev_w0…wn
dev_icm
dev_rd
dev_disp
dev_ms
Alert_Dev.org
sapstart.log
Gateway
ICM
WP’S
DATA BASE
MMC DEV
Startup Profile
Strdbs.cmd
Msg_server.exe
Disp+work.exe
Default
Profile
Instance
Profile

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 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)
158

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
“sapmntSYSprofiledefault.pfl” is read. Profile values already defined in the R/3 kernel are
replaced with the values in the default profile.
The instance profile
“sapmntSYSprofile__” 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.
159

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
160

UNIX:
Send message via name_pipe
Read
start
read
start
Connect DB
161
Dispatcher
SAPOSCOL
Startdb script
sapstart
Msg Server
dev_w0…wn
dev_icm
dev_rd
dev_disp
dev_ms
startdb.log
Gateway
ICM
WP’S
DATA BASE
$startsap
Startup Profile
Strdbs.cmd
Msg_server.exe
Disp+work.exe
Default
Profile
Instance
Profile
alert_dev.log
Kill.sap

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
162

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
163

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.
164

7. On UNIX use the command “ps-ef” to display the services. The service user SAP<SID> runs
the services.
Directory Structure: The only directory installed during installation is usrsap.
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
usrsap<SID>sysexerun
In future the kernel directory is exeUC (or) NUCi386(or) iA64
165

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)
usrsap<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.
usrsaptrans:
This is a directory where transport related information lies.
usrsap<SID>sysprofile:
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
usrsap<SID>sysprofiles
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 msgserver.exe
3. Disp+work.exe
4. Igsgwrd.exe
166

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) don’t require any instance
restart.
RZ11 is also used for displaying documentation for profile parameters.
Don’t 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:
167

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.
8. 1.If the DB is not started check alert<SID>.log in saptracebackground. It gives all the
details fo database directory startup details.
9. 2. If it is not showing any results check LSNRCTL status
10. 3. Check the startdb.log in the work directory usrsap<SID>DVEBMGS00work
168

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
169

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.
170

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 (exerun)
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.
Stderror 0
Stderror 1
Stderror 2
171

These provide DB server logs message server logs, dispatcher logs.
Check DEV_DISP, DEV_MS,DEV_W0……DEV_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
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:
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
172

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. Use parameters missing: recreate the parameters
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.
173

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)
174

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.
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:
SAP system landscape:
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.
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)
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.
175
Single System Landscape
Development
Quality
Production

Ex: It is used to setup demo, desk and training systems.
It is a resource minimized setup.
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.
Three System Landscape:
This is the optimized landscape recommened by SAP where development, quality and production
actions are carried out in individual systems (or) boxes.
176
Two System landscape
ProductionDevelopment
and Quality
Three System Landscape
ProductionQualityDevelopment

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
177

5. Specify the description and save
6. Domian controller is created
Defining landscape: As we don’t 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 usrsaptransbin
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
178

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
179

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 doesn’t 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 won’t effect the other clietns.
180

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.
181

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
Menu’s are created in SE41
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
182

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.
183

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.
184

Client Copy: There are 3 types of client copies:
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)
Note: repository objects will not be copied during the client copy (Local or remote)
185

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 profilego 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 won’t be copied into DB in turn it will be copied into transport directory in
terms of “Control Files and Data Files”.
186

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=usrsaptransbintp_domain_<SID>.pfl
tpimport<TR><SID><CLNT> pf=usrsaptransbintp_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 STMSGo 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.
187

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.
SAND TEST CUST QTST Trng Pre Payroll PRD
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 Authorization
USER and PASSWORD
TIN: Tax Identification Number
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
188
Common Transport Directory
400 300 200 400 300 200 900

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.
 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:
189

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.
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.
190

 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.
Change Request Mechanism: The objects can’t 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.
191

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 “R” denoted data file.
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 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.
Either Consolidation (or) development
(or) QAS (or) PRD
Importing a Change request:
192
TASKS
Change Request
Transport Layer
Transport Route
Program
DEV Class

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 SE80
1
Released
DEV/ Functional Consultants
2
3
Table Structure
Table Content
Manual tp:
193
Programs, Functional
Module, Reports,
Transactions
Development
Class
Transport
Layer
Transport
Route
Development WB Request Data Files
Co Files
Buffer
SAP Names
EPS
BIN
TMP
LOGS
C.C.C E070
TASKS
C.B.Customizing CUST Request
Transport of Copies Select the object SAVE Release

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.
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:
194

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.
RDDIMPDP
RDDNEWPDP, RDDMSQL
Documentation tables
R3trans
RDD* Jobs reads all the steps from tables and executes them.
MTP (Move to Protection):
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
195
tp
RDD * Jobs
TRBAT, TRJOB

6. Release key business users to test the functionality. If the functionality works fine, release
other users else revert back with alternatives.
Three system Landscape.
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 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
doesn’t 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.
196
SAND TEST CUST Optional TRNG QTST PRD
DEV QAS PRD
1. Customizing Consolidation Route Delivery Route
2. Development
400 300 200
C.C.C
Repository
400 300 200
C.C.C
Repository
900
C.C.C
Repository

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 it’s 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 SAPKB64003 SAPKB64004
SAPKB64002 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 installable’s.
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. Developers and functional consultants should be around to handle the change with
support packages.
197

j. 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
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…..
198

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. Transepsin.
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 usrsaptransepsin
The files that we will get are .ATT and .PAT
ATT: Attribute file
PAT: Patch file
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:
199

1. Conflict patches are grouped together
2. There are aborted packages
3. SPAM and SAINT are not updated
4. epsin 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-on’s
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 translog
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-on’s.
The following are the phases that include the support package implementation.
200

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.
201

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:
PI_BASIS
/willsys
202
Fabrication
Pharmacy
Textiles
Standard Modules
SD,MM, PP…
Additional

/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-in’s (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-on’s 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
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
203

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.
1. Production information
2. Composite note for support packages
3. Notes for add-on’s
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 developer’s
intervention and SSCR key. Most of the changes are related to Sap standard objects.
204

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 can’t 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.
205

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):
It is used to download support package, installation DVD’s add-on’s, plug-in’s, 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]
206

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]
SSCR Key:
SCREEN SHOT
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.
SCREEN SHOT
207

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 192.168.01.1 3600
Deny D 192.168.01.3 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
208

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.
SCREEN SHOT
The screen shot is an initial screen page for SAP ROUTER of the market place.
209

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
210

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.
End User Training: Before Go-Live the production users are trained on all the processes such as creating
P.O’s, Invoices, Billing, Pay Roll Run and training client of QA system.
211

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.
Go Live 1st
Apr09
SD MM PP HR FI CO
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
212
VB JAVA ORACLE SAP

USERS and SECURITY of SAP System
Name Employee
Code
Department Address Employee
Salary
Appraisal Bonus
Designatio
n
Name Empcode Department Address Emp
Salary
Appraisal Bonus
HR Clerk       
HR
Manager
      
Project
Manager
      
Director       
Employee       
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 can’t 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.
213

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, personalization’s over
assignment.
Roles are defined in transaction PFCG.
214

Composite Role: Group of one or more roles for administrative ease is called as a composite role. It
doesn’t 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, URL’s, 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
 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.
215

 Perform user comparison, so that role will be effective in the user master records.
 The role won’t 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.
Table TACTZ
Up to 10 authorization objects
[SU21/SU22]
(Authorization Field) Authorization object classes
Assigned
in SU24 Assigned
216
Activity
Transaction
Users
Profile/Composite Profile
Role
PFUD/PFCG
PFCG-Time Dependency

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.
217

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 SE38Key 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 Sales Officer Plant In charge Warehouse In charge
Create a material
Create a P.O
Create S.O 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.
218

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
219

Types of users:
1. Dialog User
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.
220

The following table is an example of the role matrix or authorization matrix.
Name of the
Role
MM01 MM02 MM03 ME21 ME22 ME23
Purchase
Officer
     
SALES
OFFICER
     
SALES
MANAGER
     
AREA
MANAGER
     
MANAGER      
DIRECTOR      
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)
221

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.
222

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
Create users Assign Roles to User and perform User Comparison
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
Create Role
Display Roles
Change Roles
Profile Admin
Create User Assign roles to users and perform user comparison
Prerequisites of CUA:
223
User Admin Profile& Authorization Admin
User Admin
Role Admin
Authorization Admin

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
· 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
224

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.
Proposal 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.
RetVal 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.
Local You can only maintain the data in the child system. Changes are not
distributed to other systems.
Everywhere 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.
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
225

USR02 Logon data
USR04 User master authorization (one row per user)
UST04 User profiles (multiple rows per user)
USR10 Authorisation profiles (i.e. &_SAP_ALL)
UST10C Composit profiles (i.e. profile has sub profile)
USR11 Text for authorisation profiles
USR12 Authorisation values
USR13 Short text for authorisation
USR40 Tabl for illegal passwords
USGRP User groups
USGRPT Text table for USGRP
USH02 Change history for logon data
USR01 User Master (runtime data)
USER_ADDR Address Data for users
AGR_1016 Name of the activity group profile
AGR_1016B Name of the activity group profile
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_DEFINE Role definition
AGR_HIER2 Menu structure information - Customer vers
AGR_HIERT Role menu texts
AGR_OBJ Assignment of Menu Nodes to Role
AGR_PROF Profile name for role
AGR_TCDTXT Assignment of roles to Tcodes
AGR_TEXTS File Structure for Hierarchical Menu - Cus
AGR_TIME Time Stamp for Role: Including profile
AGR_USERS Assignment of roles to users
USOBT Relation transaction to authorization object (SAP)
USOBT_C Relation Transaction to Auth. Object (Customer)
USOBX Check table for table USOBT
USOBXFLAGS Temporary table for storing USOBX/T* chang
226

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:
227

SUPC:
SU03:
SU24:
SU25:
SU99:
SM18:
SM19:
SM20:
SM58:
SM59:
SALE:
BD54:
SCC4:
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.
228

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 Programmer’s 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
229

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.
230

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.
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
won’t 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.
231

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 user’s 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?
232

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.
233

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 non-config 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.
234

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.
235

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 user’s transactions without restricting
to the users is called work process multiplexing.
Dispatcher
The number of dialog work processes can be configured by using the parameter
rdispwp_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
rdispmax_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”
236
User
Communicatio
n
W0,W1-------Wn-1
Task
Handler
Queue
R/3 Buffers
U
C
DB

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 can’t
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
237

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)
238

 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 don’t 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: rdispvbdelete 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.
rdispvbmail: This is used to trigger the mails to users in case of update errors and update
deactivation
rdispvb_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.
239

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 rdispmax_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.
240

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
241

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 rdispbtc_time=60
242

rdispbtc_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
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)
243
User
Community
Dialog Instance
CI
DB
Legacy System
Purchase Order
Text File
Excel File
Text and
Excel File
DB

9. Table space overflow
10. Connectivity with RFC system fails
11. 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
ABAP Program Required
Variant How Often?
SAP_REORG_JOBS
Deletes old background jobs.
RSBTCDEL You must
create a
variant.
Daily
SAP_REORG_SPOOL
Deletes old spool requests.
RSPO0041 You must
create a
variant.
Daily
SAP_REORG_BATCHINPUT
Deletes old batch input sessions.
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.
RSBDCREO You must
create a
variant.
Daily
SAP_REORG_ABAPDUMPS
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
RSSNAPDL You must
create a
variant.
Daily
SAP_REORG_JOBSTATISTIC
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)
RSBPSTDE You must
create a
variant.
Monthly
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
RSM13002 None. Daily
244

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.
SAP_COLLECTOR_FOR_JOBSTATISTIC
Generates runtime statistics for background jobs
RSBPCOLL None. Daily
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
setting up RSCOLL00.
RSCOLL00 None. Hourly
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
245

Background processes can be configured by parameters rdispwp_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:
rdispstore_location=G (or) db
G: Global Directory (O/S level)
DB: Database
DB means it is stored in the table TST01 and TST03
246

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 Advantages Disadvantages
File system Relatively fast: improved performance. 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 TemSe’s object
management in the database.
Database Back-up and restore with
database tools. Consistency is
ensured.
Slower than file system storage. Increased
database load.
247

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 doesn’t 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
248
Logical
System
TA
TAR/3
U
CU
C

LP3 LP3 Dialog Instance
LP2
LP1 R/3 W.P of type Spool
249
R/3

Access Method: Access method specifies the type of printing mechanism (Local or Remote
Front End)
TEMSE
Author, No of Copies, Device and data
UR TEMSE Spool Request
O/S Spooler
Local
Print Server
Print Server: This is a server in the network where the printers are configured
250
DISP
W0,W1…………………Wn-1U
C
T.H
R/3
D.B
User
Request
Global
TST01/TST03
Spool
Request
data
Output Request
O/S Printer

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 rdispwp_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
251

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
252

Configuring of SCOT: (SAP Connector)
It is used t define E-mail server, Fax Server, Internet, SMTP (Simple mail transfer
protocol)
Configuring SMTPClick on internetClick on createSpecify the name of the
nodeDescribe the nodeSelect the RFC nodeContinue 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 SAPconnect.
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
rdispwp_no_spo more than one depending upon resources
253

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.
254

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 settingsPrinters 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 
255

 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 Access Method(Unix) Access Method(Windows)
Local L C
Remote U U,S
Front-end F
Spool Architecture:
256

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.
257

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 ( ). Shows the list of
output request for the spool request.
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.
258

 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:
- : Not yet sent to the host system
+ : Spool requested being generated
Waiting : 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.
259

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.
Summary
SPAD
SP01
SP02
SP11
SP12
TSP01
TSP02
TST01
TST03
TemSe
260

RSPO0041/RSPO1041
RSPO1043
RSTS0022
Rspo/store_location
Rdisp/wp_no_spo
Rdisp/wp_no_spo_fro_max
Access Methods C L U S F
SAPLPD, SWIN
LP01 default printer
261

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.
R/3 System Landscape
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
262
End
User
Commu
nication
Common Transport Directory
CI
DB1
CI
DB2
D1
D2
CI
+
DB1
D3
D4
D5
D6

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 rdispmax_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 rdispwppriv_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
263

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
2. Table space over flow
264

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
265

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,
supplier’s 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.
266

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 BAPI’s.
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 system’s.
IDOC’s are monitored in transaction IDOC and WE05
RFC Communication: (Remote Function Call)
It is used to define the remote connectivity to the target system. RFC’s are used widely in the following
scenarios:
1. Remote client copy
2. CUA admin
3. Data Migration
267

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 9it’s 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.
RFC’s 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.
268

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 ID’s which are not sent to target systems and tries to
update for every 60 seconds . TRFC’s 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. QRFC’s 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 etcservices 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.
269

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.
270

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
modesdefine 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 usrsap<SID>SYSprofile
Startup Profile: This will not be modified unless there is a change in the instance and instance file
system.
271

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
RFC RFC
RFC
CCMS Agents RFC
Dialog Instance 2
RFC RFC
Config Alerts
272
CI
R/3
B/W
SAP CCMS SR
JAVA WEBAS CRM

Archiving
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)
273

7. Define the logical path Assign physical path (Global Directory)usrsapSIDsysGLOBAL
(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
274

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.P’s 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)
275

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
276

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.
277

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:
278

DATABASE
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
279

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:
280

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?
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?
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?
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.
281

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
282

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 DB’s ,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.
This gives the information about listener port blocked and why it is not starting.
283

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
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
284

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 platform-specific 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
285

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
286

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)
287

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”.
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
288

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).
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.
289

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.
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).
290

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
1. PSAPUNDO
2. PSAPTEMP
3. SYSTEM
4. PSAP<SID>
5. PSAP<SID><Rel No> Rel No: Release Number
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:
291

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
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…
292

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.
293

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 doesn’t 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:
294

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
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  openselect 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.
295

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
296

2. BRCONNECT -f check House Keeping Jobs
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
i. SAPDBA –psap%
ii. 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.
297

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…..)
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:
298

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 don’t 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.
299

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:
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 zttarool_area
Parameter to configure heap memory is abapheap_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 zttzroll_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
zttaroll_extension=
300

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 abapheap_limit, abapheap_area_dia, abapheap_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) EM Roll Area (20 MB) Heap Memory
WP0    
WP1    
WP2    
WP3    
WP4    
WP5    
RFI (Request for Information) can be prepared by 3rd
party agencies like KPMG/IBM
Customer Partner/SAP/Oracle
1. RFI Response
2. Chases S/W
3. Who needs to Implement Satyam, IBM, L&T, Accenture, Wipro
RFP: Request for Proposal RFI (O/S, DB, Components, Windows, IBM)
4. Customer Will send RFI
5. Customer Choose partner based on
(Time material, Fixed bid)
301

NETWEAVER
SAPGUI for WINDOWS
SAP GUI for JAVA
HTTP 8080
SAPGUI for HTML 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
303
4.6 D
4.7 EE SR1
ITS

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 BIW R/3
JAVA Stack ABAP Stack
In order to provide user friendly environment SAP has adapted JAVA as the internet language.
304

Open DB Support O/S Independent
Application Platform
SAP R/3FAX CRM Mobile Interface
BIW
Paging Mail Server
SMS
Non SAP(CSV…) Oracle Applications
PS
P Process Integration with the help of Brokers & Adapters
I Information Integration
P People Integration
A Application Integration
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 numbersapbcITSsapwebguisap clients
305
SAP
P X
.NET A
FRAME A P
WORK P P
I S

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
306

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
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
307
ICO
Work Processes Work Processes
JAVA Dispatcher ABAP Dispatcher
MSG
ENQ
DB DB
MSG
ENQ

5. ICM is instance specific
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 startJ2EE=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 can’t 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)
308

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) usrsapsid
Instance directory is located in usrsapSIDJC01
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
JAVA instance port: By default 50,000 is used as port to access JAVA instance over the internet provided
instance number is 00.
309

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)
310

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 usrsapSIDJC01instance numberSDMremote.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 usrsapsidinstanceJ2EJSPAMgo.bat
Click on go.bat to go to JSPM interface. Patches will be copied to the directory
Transepsin
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.
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.
311

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 httpcache
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:
-XX: Newsize=171M
XX: Max New Size= 171M
3. Permanent Generation Memory:
XX : Perm Size= 256M
XX: max perm size=256M
312

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: usrsapsidEP7JC02J2EEADMIN
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 Services: This is used to configure the log files, no of active users who is used for.
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.
313

JARM: Java Application Response Management: It collects the data for performance.
314

SAP Implementation and administration guide by bob panic

More Related Content

What's hot (20)

Viewers also liked (16)

Similar to SAP Implementation and administration guide by bob panic (20)

Recently uploaded (20)

SAP Implementation and administration guide by bob panic