1. 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
2 L2 Support Tier-2 Level-2 Support-2
3 L3 Support Tier-3 Level-3 Support-3
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

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

3. Monitoring backup regularly
Monitoring DATABASE Standard Jobs
3

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

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

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

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

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

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

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

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

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

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

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

15. • 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

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

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

18. 18

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

37. L/C U/S F
37

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

53. 53

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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