You are on page 1of 325

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

1
Data Base

O/S

Transports

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

2
Configuring operation modes

Monitoring the log files

Defining and scheduling standard background jobs

Monitoring backup regularly

Monitoring DATABASE Standard Jobs

3
Support Architecture:

Offshore Components IBM, HP, WIPRO

CVONNECT
VIDEOC
Connectivity Landscape
ON

RELIANC
OFFSHOR RIGHT CUSTOME
E
E SHORE R
TVS

PHARMA Leased Line/VPN


GE, COKE, HP
SAMSUN Work for CustomerConnectivity
G
Directory

NESTLE: HP: KODAK:


ST02 ……. SM36
PFCG ……. SM37
30 Employees 17 Employees SM50
SM66
12 Employees

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

CLARIFY
EMAIL HP
USER Overview
Request Seibel
Ticketing Tool
SAP CRM

SYNERGY
Phone
CUSTOMID

EXCEL

Help Desk (Phone, FAX, Email)

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

5
Status Description
New Raised Problem
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 Closure Time


Time
1 Low/Normal 24 Hrs 72 Hrs
2 Medium 12 Hrs 48Hrs
3 High 8 Hrs 24 Hrs
4 Very High/ Critical 2 Hrs 4 Hrs
5 Diasster 15 Min 15 MIN

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


User Creation, GUI related issues or user specific problems

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


assignment etc…

High: Printing, Update, Deactivation, Transport Errors etc…

Very High: Printers Down, Instance Down, Services are partially inturepted

Disaster: Server Down

SLA: Service Level Agreement.


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

6
Parameters for defining the Number of W.P’s:

rdisp/wp_no_dia=  For defining the number of Dialog W.P’s

rdisp/wp_no_btc= For defining the number of Background W.P’s

rdisp/wp_no_vb= Defining the number of update W.P’s

rdisp/wp_no_vb2= Defining the number of update W.P’s (secondary)

rdisp/wp_no_enq=1 Defining the number of enqueue W.P’s

rdisp/wp_no_spo= Defining the number of spool W.P’s

rdisp/max_wprun_time= 600-1800 sec  this defines the maximum time that a


(Dialog)W.P can run .

DIAG Protocol Roll In

Dialog Work Process: Roll Out

Dispatche QUEU
Central r E
USER W0,W1…………………………
Instance Wn
U SCREEN

C ABAP

SQL
DATA
BASE
R/3
Buffers

DBCL

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

8
b. Waiting: It is waiting for the user request they are free t handle the task
assigned by the dispatcher

c. Holding: The process is on hold. (It is also running) and waiting for the
communication from an RFC system.

d. Terminated or Stopped: The process is terminated due to an error, time


out after 600 seconds, explicitly killed.

e. Ended: The W.P is ended i.e. it could not be started and it 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

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

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

10
Note: Dialog Process is used to handle the user request to schedule the job in the
background to update the database to print the requests and to get the logs before
updating a record.

Disadvantages: Dialog process can’t be used to run the long running, time
consuming expensive programs or Reports.

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

12
4. Active: The job is currently running

5. Completed: the job is completed successfully

6. Canceled: The job is canceled i.e. an error occurred

Background job Mechanism:

When the dialog user defines the run a job in the background it is entered into the
tables “TBTCT” and “TBTCS”

Background processing time scheduled in table (TBTCS)

Compare value for batch job selection TBTCT

Background Job Scheduler: SAPMSSY2 is the ABAP program that runs


every rdisp/btctime

It runs for every 60 seconds or the time specified by the parameter


“rdisp/btctime=”

It checks for the jobs in the ready state and brings them into background job queue.
It runs in the dialog process.

1. User logon to the system to schedule a report or program in the background


mode

2. It is stored in the tables TBTCT, TBTCS

3. A background job scheduler runs for every 60 seconds in the dialog mode to pick
the background jobs

4. If the job is picked and ready to execute the status is set to ready

6. When the background process is assigned status is ACTIVE

7. Canceled when the job is not complete.

Background Job Steps:

Background Job can be defined by using an ABAP program, External Program and
External Commands

1. ABAP Program: It is a standard program or custom defined program which will


be executed using Variant

Variant: It is a program selection criterion to provide the inputs during run


time or execution of the program

13
Ex: Delete the background jobs for every two days 9The jobs which are
terminated or completed successfully)

Delete the old log files for every 3 days or delete the log files which are older
than 2 days.

Note: Variants are stored in the table TVARV (Table of variable in selection criteria)

2. External Program: It is used to define the program to trigger on the host wwith
the specified parameter

Ex: R3trans, SAPstart, SAPEVT,

This type of job step allows you to run programs outside the SAP System. External programs are
unrestricted, directly entered commands reserved for system administrators.

3. External Command: These are the commands which are not specific to O/S

Ex: brbackup, brrestore, brconnect etc…

These commands are defined I transaction SM69 and executed through SM49.

This type of job step allows you to run programs outside the SAP System. External commands are
predefined, authorization-protected commands for end users.

The type of external command and external program is unrestricted, meaning that you can use either
compiled programs or scripts. Such programs can be run on any computer that can be reached from the
SAP System. Parameter passing to non-SAP programs is completely unrestricted except by the
predefinition mechanism for external commands.

Output of non-SAP programs, particularly error messages, is included in the job's log file.

Specifications required for an external command or program is:

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

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

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

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.

16
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

a. The database space is not enough and results in errors (ora- 1653, 1654, 1631, 1632, 255,
272 ….)

b. Update process deactivated

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

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

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 DELE (delete other users’ jobs)
Jobs) LIST (display spool requests)
Allows all of the activities listed above except for PLAN (copy other users’ jobs)
maintaining external command definitions.
PROT (display anyone’s job log)
No default profile with ONLY this authorization is
SHOW (display job details)
currently shipped with SAP, but the standard SAP_ALL
profile contains this authorization. RELE (release other users’ jobs to start; a
user’s own jobs are automatically
released when scheduled.)
S_BTCH_NAM (Batch Processing: Batch User) permissible users
Allows a user to specify other users for runtime
authorization for a job.
S_LOG_COM (Authorization to Execute Logical

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.

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

E
L.U.W
M
L.U.W
P

T
L.U.W DB
A
L.U.W B 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:

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.

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

24
Upon the successful update (Temp Table) a transaction Id is generated

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

25
SE12: Display the database tables

Note: The update process inherit the locks from dialog process

Update Monitoring:

Updates are monitored in Transaction SM13

Go to SM13 to display the records based on client, user, from date and To
date and status.

The records are displayed with the following status:

Init: Update is getting initited to update the database

Run: Update running

Auto: If the update is cancelled due to any reasons it will be set to automatic
update once the problem is solved

Err: The update process is thrown in to error

Update Errors:

1. There is no space on the database (errors are prompted with message 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

26
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

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.

27
Update Problems:

1. Less number of work processes configured

2. The number queue increases and more updates are init state

Resolution: Try to find out the status of other back ground job which are
updating the data base.

The update is consuming more time to update the database, the update queue
increases. If it is a generic problem try to resolve it.

If it is a regular problem consider increasing update process based on the


availability of resources

3. Check if the update mechanism is deactivated (SM14). Go to SM14 check


the status of update mechanism if it is deactivated check the system log
(SM21)

Note: Update can be deactivated and activated manually in SM14

4. Programmatical Errors: There is a programatical for which the update is


thrown into error state. Refer the problem to development team, it is a
customizing program. If the problem popped up after applying support package
and patches refer to sap notes for a consult or else write to SAP.

5. Table Space Overflow: When the table gets overflowed we could not update
the database. Increase the table space and rerun the update.

Note: Update work with enqueue process to obtain and inherit the locks.

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.

DISPATCHER
DI
TSKTT

U
ENQUE
USER
C UE MESSAGE
SERVER

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.

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

30
The following is the procedure for the lock release:

User requires a ticket that he couldn’t update the record

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.

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 \usr\sap\SID\sys\global

DB: Means it is stored in Database tables TST01 and TST03

TST01: It stores the objects and details of the spool requests such as name of the
Author, Number of copies, name of the printer etc..

TST03: It contains spool data to be printed

USER

DIALO
G
DIALOG

BTC
Jobs

DB (Database) TST01, TST03


Spool Request
32
G (\usr\sap\sid\sys\global)

TEMSE

Parameter G: The Temse resides at O/S level. It will be faster to access than
database (DB). When the spool size is small (around 300 MB) and If the spool
size increases it will be difficult to locate them to print . O/S memory is used.

Dedicated space needs to be taken to store the backup of Temse.

Parameter DB: Time consuming to wrote into DB. But with the help of indexes
it can be printed out fast. No special care for backup is required because 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.

Sap R/3

33
USER
F Printer

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.

34
USER

LGS1 (Logical Server)

Real Real
Spool Spool
Server Server
Click on the Access Method:

Host spool access method

C for Windows NT

L for UNIX

C and L are local access methods

U and S for remote access method

U for UNIX

S for Windows NT

F for front end printing

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

35
Author Name

Number of copies

Name of the printer

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:

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

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.

37
SP12: Temse administration. It is used to check the memory allocation
objects and perform the Temse consistency check

Reque
st

Dialog Dialog

Back
Groun
d

Spool Request

Spool Server/Spool Process

LGS

Local Remote Front End


Access Access
L/C U/S F

38
Data Transfer:

Old Legacy
system

Interface

BW
SAP SYSTEM

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.

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

40
Specify the system number

Specify the system number

Specify the Gateway options

Gateway host

Gate way sapgw<instance number>

Click on logon details

Save

Click on test connection.

If the specified user is a dialog you can click on remote login to check the
connectivity.

ALE: Application Linking and Enabling

It is used to communicate between two loosely coupled systems. Use


transaction SALE to define systems.

Logical System: Logical systems are used to identify the client uniquely in
the landscape.

As client is identified by a number we need to assign logical system between


<SID>CLNT000

Ex: DEVCLNT000, QASCLNT000, PRDCLNT000

BAPI: Business Application Programming Interface

It is used to communicate between sending system and receiving system


based on interface and method.

Select the Model View

Select the Send Client

Select the Receiver/Server

OBJ Name / Interface

Method C Simulator

41
Add message type and specify the message type.

Note: Most of the data transfer methods are defined by functional


consultants during implementation.

Ex: Central user administration uses ALE mechanism to transfer the data
between clients

EDI: Electronic Data Interchange

It is used to exchange the data between SAP and NON SAP systems.

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

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

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.

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 usr\sap\sys\profile 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)

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

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

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

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.

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%”

47
Logon Load Balancing

L D.I

G
D.I
1

End
User C.I
DB

L
D.I
G

2
D.I

Message Server

Logon Groups: These are used to define load balancing mechanism


between the instances.

These are used for logon load balancing\fail over between the instances.
These are used for optimal utilization of buffers.

Defining logon Groups:

Go to SMLG Define log on groups and assign instance

Logon groups are defined based on geographical locations based on


application models.

Message server keeps the list of all logon instances and displays the favorite
computer server by calculating answer time and think time.

Mechanism:

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 etc\services
i.e. you need to maintain all the user desktops with the above two entries
( sapmsg.ini and etc\services)

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

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

50
9. Background job errors

10. Number range intervals

Mostly it records all the important activities. We need to look in to the errors
that are displayed in RED color and light Red color

Analysis: Click on the error message. Get the error message. Identify the
uses and check with the user. If any abnormalities are found get the error
message and check out in market place.

ST22: ABAP Dumps

SAP system is built on ABAP language. So it executes based on ABAP


programs. If any one of the program could not be executed it will thrown into
errors and recorded in SM22 and SM21.

The programs can be thrown in to dump under the following circumstances

1. Time out Error: Schedule in the background or fine tune the program
by restarting selection criteria

2. Data Base Errors: ORA 1631, 1632, 1653, 1654, 255, 272, 1555

3. PXA Errors/ Buffers: Space is not enough to store the content

4. Memory Errors: When memory to execute the program is not sufficient


it will be thrown into error

5. Program Bugs: Which can be fixed by applying notes and support


packages

6. Kernel Mismatch: Upgrade Kernel

7. Upgrade errors and background job errors:


SQL_array_cannot_insert_duplicaterecords

8. Too many conditions and indefinite loops throws the custom program
in to dump

Go to ST22 Double click on the dump and read the dump thoroughly and
understand the problem. Thoroughly understand stand the problem. Go to how to
correct error and try to resolve get the error message and resolve by searching in
the market place.

EWZ5: To lock and unlock the users

51
SM04: To display the list of users logged on to the instance. RSUSR006 is the report
we can find all users.

ST11: Developer trace of work directory

SSAA: Transaction help you to know the user has navigated to the transaction or
not. It own all the reports (Monthly, Weekly, Daily)

List of transactions to be monitored:

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

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.

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

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.

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)

56
5. Click on logical file name to move the data

6. Specify the logical file

7. Specify name

8. Specify the physical file

9. Specify date format

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

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

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

59
WORK LOAD OVERVIEW:

20 KB

Front en time or Dispatche QUEUE (Dispatcher

GUI TIME r
TSKTT
Queue)/Wait Time50 m/sec
SCREEN
EN U
D ABAP
US C
ER SQL DB

R3
Buffers

DBSC
RFC
CI/DI

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

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

SCREEN 1 4

ABAP
2
SQL0 5
3
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.

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.

61
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

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

63
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

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

R/3 Buffers: These are stored in the instance and cannot be shared between
the Instances. These buffers are different from database buffers. There are
various types of buffers.

Ex: Program Buffers, table Buffers, Calendar, CUA, Screens etc….

Buffers are stored in the shared memory of the instance.

Buffer Mechanism: User logs into the system to access certain data. The
request is processed and goes to database to fetch the content. If the
content is eligible for buffering it is stored in the instance.

The content should be rolled out into user context before the response is
sent to the user. As the user context is small in size the context I not stored
in user context. But in terms store in R/3 buffers and the pointer to R/3
buffers are stored in user buffers.

Note: User context cannot be shared between users but R/3 buffers are
shared between users.

Buffer Monitoring: Buffers are monitored in ST02. Buffers are organized in


terms of directories and the space in the memory.

ST02: Display the following information

1. Name of the Buffer context

2. Buffer hit ration: The ration should be always greater than 94%

3. SWAPS

We need to look for swaps. Swaps occurs when the allowed space is completely
used or of all the directories used or both utilized.

Basically the ABAP buffer size will be 150 MB by default. We can increase up to 600
MB (Up to 4 times) based on the available memory.

If swaps occur frequently consider increasing either space or directories.

The Reasons for Swapping:

65
1. Frequent transaction of objects

2. The new modules are implemented

3. Buffer memory is not sufficient

4. Number of directories not sufficient

5. Frequent changes to the buffer data

Note: In each company the swaps occurs frequently but look into the number of
swaps. Based on the size of the database we can allow 5000 to 25000 swaps.

They are not effecting the performance of the system i.e. response time.

Double click on the context which has more swaps.

Click on parameters to identify the parameter name and value and to change in
RZ10 before changing any parameter read type. Complete documentation in RZ11.
Miss configuration or improper configuration may not start the SAP engine.

TABLE Buffering: Apart from the repository objects SAP also buffers the table
content based on the table data (content).

There are 4 types o buffering:

1. No Buffering: The table which is large frequently updated rarely


accessed is set to no buffering.

2. Full Buffering: (100 % Buffering) The table which is small, frequently


accessed and rarely changed is eligible for full buffering

3. Single Record Buffering: The table which is relatively large but


frequently accessed is buffered using primary key

4. Generic Key Buffering: The buffering is based on group of keys

Note: For most of the tables SAP define the buffering settings, which can be
modified in SE13.

BY default SAP provides the following options for buffering tables.

1. Buffering Allowed: This tale can be buffered

2. Buffering Allowed but Switched off: This is used for development and
quality systems

3. Buffering Not allowed: Buffering not allowed on this table.

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

Buffer Synchronization: DI

End R/3
User Buffers
CI DB
End R/3
USer Buffers
DI
End R/3
User Buffers

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.

67
68
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)


Shared Memory Private

Heap Memory

Extende
d
Ztta/roll_area=2 MB Local Memory
Memory

U.C Roll Area


69
Ztta/roll_first=1
MB

Once the initial memory is utilized i.e. ztta/roll_first we will assign memory
ztta/roll_extension=512 KB to 2 MB

Based on memlimits of OS.

Memlimits – run command

If the specified value is used completely then the remaining part of the roll
memory is used i.e. (ztta/roll_area) – (ztta/roll_first)

If this value is also not enough it uses private memory i.e. the work process
goes on to private mode. The value ranges from 80 MB to 2 GB. This value
should be lower than abap/heap_area_total (Memory for Dialog and Non
Dialog WP)

If the work process exceeds the limit specified by parameter


abap/heaplimit the work process that can go into private mode as
minimal as possible by using parameter

rdisp/wppriv_max_no=1 0r 2

If the work process goes into private mode the parameter


rdisp/max_wprun_time will not be effective i.e. the program cannot
be timed out.

If too many programs or W.P goes into provate mode the WP congestion
occurs (Hour Glass) and no user can login to system.

Use” dpmon” to kill the expensive work process based on the approval.

dpmon pf= E:\usr\sap\<SID>\sys\profile\

Go to ST02 to monitor the extended memory and Heap Memory.

If the usage of Heap Memory increases the bottle necks on the


system raises gradually.

Go to ST06 to display the amount of physical memory. It is used to display


the number of 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.

70
Reconcile ST03 and ST06 and identify the expensive ABAP program and
recommend to fine time it.

However we can identify the top 10 CPU users, using Detail Analysis menu
Top CPU users.

ST06: It is used for displaying CPU idle time number of 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


\usr\sap\<SID>\sys\work

ST05 and ST01: It is used to trace the following

1. SQL trace

2. Enqueue Trace

3. RFC Trace

4. Buffer Trace

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

71
the SQL Trace. Select SQL trace and activate the trace. Check that
trace with filter and specify the selection criteria. We can also enter
SQL statements and explain the statement about the cost and
estimated rows.

2. Enqueue Trace: When the enqueue time goes behind the threshold
value i.e. more thatn one m/s in Central Instnace and 100 m/s for
dialog instance then

Select Enqueue time and activate the trace and display the trace
similarly.

When RFC+CPIC time increases we need to switch on RFC trace

When buffer swaps occurs and increases gradually in ST02 we may


need to trace using buffer trace.

ST01: It provides kernel and authorization trace in addition to ST05


traces.. In order to check the missing authorization that could not be
traces in SU53 user authorization check trace in ST01

Kernel functions also i.e. kernel executable. When they are calling
certain functions we can also trace their activities

This Page is intentionally Left Blank

72
Motivation to Implement SAP

Manufacturing/ Production (Oracle Apps)

Memory (VB and SQL)

Machinery (Java and Oracle)

Material (Java & Oracle)


SASTRY
HR (People Soft)
GROUP of

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

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

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

1. System landscape strategy

2. Client Strategy

3. Transport Strategy

4. Approval Strategy

5. Backup, Restore and Recovery strategy

6. G0-Live strategy

7. Post implementation strategy

8. Apart from the above the following documents are also included in the
proposal:

a. Company details along with Organizational Structure and Financial


Stability

b. Services offered by the company

c. Planned man hours based on modules at the rate of 168 to 176 hours
per month or weekly 40 hours

d. A detailed project plan along with implementation methodology

e. List of assumptions

f. Risks involved in implementation

Finalizing S/W vendor by external auditors after considering SOW, RFP, RFQ

Based on various credentials the customer identifies the implementation


partner and releases purchase order.

The objective of this whole process is to get qualified implementation.

SOX’s: Single transaction cannot be handled by single person

75
BASIC PREREQUISITES

1) Installation of IDES system and allow all the functional


consultants/ Developers to work on the system.

2) Solution Manger

Project manager and BASIS consultant responsibilities at the time of


implementation:

1. Visit the site of communicate with the data center team

2. Get the details of current infrastructure to plan the H/W resources

3. Perform H/W sizing based on users. to determine the CPU, Memory and
storage required for the system in the landscape (Development,
Quality, Production)

4. Include solution manager system in the sizing along with the SAND BOX
system. (Training or Testing or Standalone)

Note: IDES comes along with Demo Data Company is setup with all
options for Demo Data in IDES.

Production: It can not contain any data. We need to setup


everything in production

76
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

77
(Major Scope) is followed by final configuration (remaining
Scope) which can consist of up to four cycles.

Other key focal areas of this phase are conducting integration


tests and drawing up end user documentation.

4) Final Preparation: In this phase we complete our


preparations including testing end user training, system
management and cut over activities.

We also need to resolve all open issues in this phase. At this stage we
need to ensure that all the prerequisites for our system to go live
have been fulfilled.

5) Go Live and Support: In this phase we move from a pre


production environment to the live system. The most important
elements include setting up production support, monitoring system
transactions and optimizing overall system performance.

78
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

79
connection, e-mail services. Apart from the above the major task is to plan
the hardware to implement SAP.

Project Charter: Consist of a team i.e. responsible for implementation of


SAP project.

Customer Project manager: He is absolute owner of the project and


responsible for implementing the project from customer end.

He needs to track the project status and update the management from time
to time. Based on the status of the project he will release the funds to
implementing partner.

Implementation Project manager: He is used to support the scope of the


project and manages all the resources that are required to implement SAP.

Business Process Owners: These are involved in owning the respective


divisions and responsible for critical decisions in the business.

Each division has one owner who owns the responsibility for the business.

Task 1: SAP recommends performing Hardware sizing to define the


hardware required.

Hardware Sizing: It is an exercise performed by BASIS consultants with the


help of Customer Project Manager, Implementation partner, Project manager
and business process owners i.e. the project charter (group of people who
decide what to do in the project).

Hardware sizing is a SAP proprietary tool to identify the Hardware.

SAP provide quicksizer tool to identify the hardware.

It is accessed by www.service.sap.com/quicksizing.

1. Use the above URL to navigate to sizing tool

2. It will prompt for USER ID and password. It is also referred as SAP USER ID
or SUSER ID

Note: It will be a 10 digit ID that starts with S000XXXXXXX and provided by


SAP to all SAP customers (i.e. the company who purchases SAP software). We
can create as many SUSER ID’s as possible for a single customer.

80
4. Click on the link Quicksizing. It will prompt you to key in your customer
number. It will be a 6 digit number.

5. Provide the customer number; specify the name of the project and click on
create.

6. The project is created and we need to key in the following information:

1) Customer Information:

Name of the Customer, Customer Contact Person, Customer Contact


information like Telephone, Fax, email etc…

This information is required so that Hardware vendors can


communicate with customers to submit Quotation for Hardware.

2) Working Time:

 Normal business time, from what time to what time.

 The peak hours. Specify the business peak hours

 Average working days in the year (210- 250 days) or 365


days.

3) Unplanned Downtime: Should be 0%

4) What O/S is along with versions, what DB is required along with


versions, what type of Backup is required (Offline, online, partial,
incremental). Specify high availability options like mirroring, RAID,
Clustering, stand by, disaster recovery, servers are required

5) Network band width in LAN, WAN etc…

6) Users: Define the number of users based on modules and specify


the (Low, Medium, High) users.

 Low Users: These are the management who uses the


system occasionally i.e. they will try to input 0-480 dialog
steps per week for 40 hours

Dialog Step: It is an input provided by user along


with an enter (Key stroke) or a mouse click.

81
0-480 dialog steps/ 40 hours= 12 hrs (Dialog steps
per day)

For 1 hr it will be 60/15=5 min (dialog steps per 5


min) = 300 sec

I.e. low users will input his data for every 300
seconds.

 Medium User: They will generate 480-4800 dialog steps


per week or per 40 hrs each dialog step is initialized
for every 120 sec

 High User: They will generate 4800-14400 dialog steps per


week or 40 hrs. Each dialog step is initialized for
every 10 seconds

7. Save the project with all the inputs and calculate the result. The result is
displayed as follows.

Note: Sizing is also referred as T-Shirt size.

CPU Size: It can be small, large, medium

SAPS: Sap applications

Ex:

CPU Size No of SAPs Memory in Disk Category Disk Size in


MB 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

82
1. SAP Notes: SAP provides a rich set of knowledge base to resolve
runtime issues information etc..

Ex: Installation problems, Problems during patch application,


resolutions for standard errors. It is accessed by using
www.service.sap.com/notes

2. Downloads: We can download software based on customer license

My SAPERP 2005

Netweaver 2004

Solution Manager

It is accessed by using www.service.sap.com/swdc

3. Hardware Sizing: It is accessed by using www.service.sap.com/sizing


(Quick Sizing Tool). It is used to perform the hardware sizing i.e.
required to implement SAP or upgrade SAP solutions.

4. Create Message: For run time issues Help and Support.

 SAP provides this options to create service message to


resolve the runtime problems

 Earlier it is straight to create a message. But in the current


version of market place it will not allow to create a
message directly. Instead it provides a search criteria to
search the notes and if the error is not resolved then it will
allow to create the message. Go to notes/help and support
 Report a product error customer message

5. Creating License Keys: SAP provides an option to generate license keys


for developers, objects, migration keys.

License Key: It is required for all the instances that are running on
production landscape.

Object Key: By default all the SAP objects are locked. In order to
modify the SAP standard object we need to obtain key for developers
and the object.

83
Click on SCCR key (SAP Software Change registration). Each developer
has to be registered in the website. There is a separate license fee for
developers. SAP designed 15 lakh programs or objects on SAP system.

Migration Keys: Whenever there is change in O/S or DB of SAP system


we required migration keys.

6. Data Administration: It consists of two options

System Data

User Data

System Data is used to maintain the information of all the systems


of the customer landscape

User data is used to create new market place users and assign
passwords.

7. Inst Guides: It is used to download the installation guides and upgrade


guides. www.service.sap.com/instguides

8. Downloading Support Package and Patches: Go to


www.service.sap.com/downloads

Select support packages and patches

9. Quick Links: Quick Links are used to identify the options of market
place. It is also used to provide the URL’s

10. Road Maps: (RMMAIN) It provides series of steps to implement SAP.

84
Solution Manager
1. Generation License keys/ Upgrade Keys

Transaction: solution-Manager or DSWP

2. For Land Scape Creation:

SMSY: To generate license key ot configuration of satelite system

3. Monitoring Alerts

4. Service Desk Configuration

5. Maintenance Optimizer

6. Change management

License Key/ Upgrade Key: It is mandatory to have license key/ Upgrade


Key to continue with the installation. With out this key no installation based
on netweaver (ECC 6.0, EP-7, BI-7, XI-7, CRM 5.0, SRM 5.0) can be continued.

This key is checked during central instance installation.

Go to SMSY Go to Systwem landscape Click on other objects Specify the


System ID or SID Click on generate key installation or upgrade key Specify
system ID, System Number, Message server (Hostname of systme where SAP is
installed) Click on Generatge Key.

Activity-2:

Configuration of Satelite System:

Go to SMSY to create satelite system.

 Satelite systems are SAP systems which can be monitored through sllution
manager.

 Monitoring of SAP system configuration- landscape

 Go to SMSY where we can create satelite systems manually or using


wizard (graphical tool) Start .

Go to SMSY System landscape Landscape Components


Server Database System System components Right click
on system and click on create new system with assistant
Specify system short description SAP product Product
version Installation number Click on continue Instance

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

Activity-3:

Assigning logical component to system in the landscape.

Go to SMSY Go to system groups and logical component Select


the system <SID> and assign the system role to the logical
component. (If this is not performed the addressing will be difficult)

Activity-4:

Creating solutions Go to solution Manger or DSWP to creqte solutions


Click on New Create new solution Povide Soluiton Name, Customer
Number, Original Language Continue to creatge the solution select the
solution (BASIS Group) This solution is used for solutin manitoring
system monitoring, service desk, change management Delivery of SAP
services continuous improvement Maintain solution landscape and
include the logical component defined in SMSY sustem group Go to
solution settings to setup Earlywatch Alerts (EWA) and CCMS monitoring
of EWA.

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.

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

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:

87
SAP does not give you the CPU output directly because the CPU varies based
on different manufacturers.

Ex: 102 GHz, 3.0 GHz, Dual Core, Quad Core

SAPS: SAP provides CPU requirement in SAPS (SAP Application Bench Mark
for performance standards). SAP defined benchmarks based on sales and
distribution module i.e. for every 2000 sales documents 100 SAPs are
required. Depending upon the vendor of CPU it can generate 800 to 2000
SAPs.

Let us say output requires around 5000 SAPs then Hardware vendor may
recommend 4 CPUs.

Ordering the HARDWARE: Once the sizing results are finalized we can call
for the quotations from the H/W vendors. Customer Manger and
Implementation manager work in this task.

Solution Manager can be installed on a 50 GB desktop with 1 GB RAM on 32-


Bit machine. Depending on the usage of Solution Manger we may need to
move to 64-Bit and enhance the RAM.

Ordering the SOFTWARE:

1. O/S Software: License and support

Note: Most of the cases O/S is provided by H/W vendors

2. DATABASE: Software mostly is provided by SAP

3. SAP Software: We need to buy the SAP S/W through channel partners.
There are various types of SAP S/W. Based on customer requirements
SAP has its own release for different components.

SAP Release Strategy:

1. SAP R/2 2.0 on two tier architecture

2. SAPR/3  3.0 ……..3.1g, 3.1 (i) (Released in 1997-1998)

It’s strategy 5-1-2

 First 5 years of release SAP charges 17% of total software cost.

88
 From 6th year 17+2%=19% of total software cost

 From 7th and 8th year 17+4%=21% of total software cost.

1997-1998 up to 3.1 i

1998+5=2003 Normal Maintenance

2003+1= 2004 Extended Maintenance

2004+2 2006 Extended Maintenance

2000 4.6c

DEC 2006 Maintenance of mainstream end

DEC 2007 Additional Maintenance

Dec 2008 Additional Maintenance

2003 4.7 EE (Enterprise Edition)

2009 Maintenance of Main Stream

Solution Manger:

3.0  2005 April

3.2  2006-2007

4.0 2008

2005 ECC 5.0 (SR1, SR2)

2007  ECC 6.0 (SR1, SR2)

2003  4.7 EE (4.70, 4.71 Extension Set-1, 4.72 Extension Set-2)

http://help.sap.com/releasenotes

SAP license is based on Number of Users. Each user cost is different from
country to country, state to state. It is estimated that each user cost varies
from 40,000 to 1,00,000 depending upon the number of users.

89
Note: After the H/W and S/W order it will take 1 Month to 45 Days to release
the Order.

This time where we need to prepare various Documents to Install, Configure,


moving the known Problems of installation, Product Errors, Strategies for
systems, System Landscape, Clients, Transports, User Management,
Authorizations, Back Up and Restore and Day to Day activities.

Installation Pre Requisites:

Download the installation guide from service market place for specific O/S,
DB and Sap R/3 Version.

Ex:

HP UNIX ORACLE 4.7 EE1, 4.7 EE2, ECC 5.0,


ECC 6.0

WINDOWS SQL,ORACLE,DB2 4.7 EE1, 4.7 EE2, ECC 5.0,


ECC 6.0

LINUX SQL,ORACLE,DB2 4.7 EE1, 4.7 EE2, ECC 5.0,


ECC 6.0

Read the documentation and document the following:

1. Required Software to0 install the SAP system

2. Download the required software from SAP market place


www.service.sap.com/swdc

3. If you have the software in DVD’s copy the software into TEMP directory

4. Check the “label.asc” in DVD to identify the version and product

5. Find the required Virtual Memory and assign the memory to the
system.

Virtual Memory: It is the sum of Physical Memory+ The space on the


Disk.

It is also referred as paging memory or memory on the disk.

Note: It is not possible to install the RAM which is required by the system.

90
On 32-Bit machines we can define up to 4 GB. On 64-Bit machine the
minimum SWAP memory will be 20 GB.

As a rule Virtual Memory is calculated as 3 times the size of physical memory


+ 1 GB.

Identify the proper JAVA version and download it from www.sun.java.com. It


should be JRE (Java Runtime Environment) 1.4.12_2

Install the JRE and set the path as defined in the document.

Environment Variables: This provides the run time environment of the S/W
i.e. installed on the system.

WINDOWS: On windows we need to set JAVA_HOME and Java Bin Path in local
variables and Global Variables.

Local Variables: These are specific to the logon user.

Global Variables: These are applicable to all the users

IF the O/S is not WINDOWS then based on the O/S we may need to set profile
parameters in “.bash” profile or “.profile”. We can also use command
“setenv” and “setpath”.

Define the Hostname as per the document and company standards.

Ex: WillERPDEV/WillBIWDEV

The HOST NAME should not be more than 13 characters.

Get the Static IP address from the system administrator which should start
from either 172 or 10, where as 192 is used for Testing and 127 is used for
loop back etc as per the INA (International Network) standards.

Define the System ID (SID). SID is a three character alphanumeric string and
the first characters must be a character and the remaining two can be either
a number or a character.

Ex: R60, DEV, RS1…

There should not be any special characters in the system identifier.

91
There should not be any duplicate SID in the landscape

The SID name should be meaningful to identify the system in the landscape
based on the PRODUCT, LOCATION, Roll in the landscape.

Note: Don’t use reserved key words like SAP, BIW, SCM,SRM< ERP, All etc…

Provide the entry in host file i.e. etc\hosts which is located in


windows\system32\drivers\etc\hosts

Download the known problems related to installation of this particular


component.

Identify the OS version and patches to install.

Identify the DB and patches to install.

R/3 4.6 C

4.6 BASIS (BASIS system)

4.7 SR1 SR2

WEBAS 620 (4.6c web functionality became WEBAS 620)

ECC 5.0 ECC 6.0

6.40 / 7.10

Installation Types:

Installation of SAP up to version 4.6 C is performed by R3 setup.

 R3 Setup: It is not dependent on any other component once the


inputs are keyed we cannot change the inputs and restart from the
scratch. It is not an interactive tool. This tool is used to install BASIS
components only i.e. 4.6 C and below.

 SAPINST is used from version 4.7 Enterprise Edition. But the


components need to be installed separately i.e. Central instance,
Database instance, Dialog instance.

92
SAPINST Requires JRE because the installation executables are
programmed using JAVA (SAPINST.CMD). Different passwords for
different users are created during installations. There is no provision
to change keyed Inputs. This is valid only for WEBAS 620 (4.7 EE,
4.7 EE SR1, 4.7 EE SR2). It is also not interactive.

 SAPINST.EXE (./sapinst): From 640 version onwards JAVA dependent,


color full option to change the inputs at the end single password
with minimal inputs.

SAP COMPONENT BASIS

4.6 C 4.6 C /4.6 D

4.7 620

5.0 640

ECC 6.0 SR1 700

ECC 6.0 SR2 700

SOLMOM 3.2 640

SOLMOM 4.0 700

XI 3.0 640

XI 7.0 700

BIW 3.5 640

BI 7.0 700

EP 6.0 640

EP 7.0 700

Installation:

Central Instance Installation: It provides a typical installation with minimal


inputs where Central Instance and database instance are installed together.

INSTANCE: It is an application server which has its own resources or shared


resources (Memory, CPU, and HDD)

93
Distributed Installation: In this installation the Central Instance and
Database Instance are installed separately

High Availability: It is used to install clustered systems on Node-A and


Node-B.

Installation Inputs: (Central instance)

 Select the SAPINST for the specified OS i.e. navigate to the folder i.e.
related to your OS

 Select the component that is going to be installed

Ex: SAP ERP 2004, SAP ERP 2005, SRM, CRM\

 Select the Database

Ex: DB2, SAPDB, MS-SQL Server, Oracle

 Select the type of installation

(Central Instance, Distributed, High Availability)

 Specify wither typical or custom installation

Note: While installing database use SAP customized Batch Files or Script files
defined by SAP. Don’t use the native setups of database. The advantage of
using SAP script is to set the environment variables that are required for SAP.

 For Oracle use SAPServer.cmd and for Dialog Instance use


SAPClient.cmd.

 For SQL Server use script SQL4SAP.vbs

 On UNIX environment the Data Base has to be installed during


Database Instance Installation or after Central Instance installation.
Database is not required for windows operating system.

 Select either UNICODE or NON UNICODE

UNICODE: It supports around 90.000 characters to support all most


all available languages in the world. UNICODE consumes 40% more
resources than NON UNICODE

 Select the Central Instance and specify SID

94
 Specify the Instance Number

Instance Number: It is a two digit number that varies from 00 to 99


but only 00 to 97 are used, 98 and 99 are used/ reserved for routing
purpose

 Specify the Database ID and Database Host

 Specify the Amount of RAM i.e. to be used during installation. It used


60% of memory

 Specify the type of Installation either local or in the domain or in the


domain of the user that user has necessary privileges to create
users, services, groups and assign to groups

 Specify the TRANSHOST directory i.e. to install the executable path

 Specify the Database Home i.e. the oracle executable path

 Specify the schema Id (database Schema). In earlier versions of DB


we need to install DB for each SAP component. The confusion arises
while handling multiple homes from ORACLE 9i on wards. (MS SQL
2000) are supporting MCOD i.e. Multiple components on single
Database with different SID’s which means that the schema Id
should be different for each component.

 Specify the password for SAP system Administrator (USER ID) i.e.
SAPADM (SRMADM, DEVADM). He is the owner for entire R/3
system.

 Specify the password for SAPServiceAdministrator. The User Id is


SAPService<SID>

Ex: SAPServiceSRM

 Specify the path of KERNEl DVD

 Specify the ports

1. Message Server Port: 3600+ <Instance Number>

2. GateWay port: 3300+ <Instance Number>

3. Dispatcher Port: 3200+<Instance Number>

95
4. Dispatcher Security Port: 4700+<Instance Number>

5. GateWay Security Port: 4800+<Instance Number>

 Start The installation

DB Instance Installation:

 Once CI is installed select Database Instance to install

 Select DB instance

 Specify the SID

 Select standard installation. Other Options like System Copy is used


to setup the system from the existing system

 Decide on MCOD. Select the option Install SAO system in the DB


(first Time) choose the second option if the DB exists

 Specify the Instnace Number

 Specify the Memory (RAM). During database installation it take 40%

 Specify the TRANSHOST directory

 Specify the Passwords for “SIDADM” and “SAPServiceSID”

 Specify the location for DB server directories

 Specify the location for Redo log files

 Specify the path of Kernel directory and Export Directories

 Specify the path for Data File

Note: DB Server directory include the following

1. SAPBACKUP

2. SAP ARCH

3. ORAARCH

4. SAPREORG

5. SAPCHECK

96
6. SAPTRACE

Data Directories Includes the following:

1. SAPDATA1

2. SAPDATA2

3. SAPDATA3

4. SAPDATA4

5. SAPDATA5

6. SAPDATA6

In ECC 6.0 the installation inputs are reduced.

1. Use Installation Master (IM) and click on SAPINST.EXE

2. Select the usage type (ABAP, JAVA, BI, PI, MI, EP etc..) ABAP is
mandatory to select

3. Specify SID. Specify installation location (Drive) / oracle

4. Specify the password i.e. master password for all the users that are
going to be created during installation

5. Specify the DB instance location

6. Specify Kernel path and database export

7. Specify path to install the data files

8. It displays the lost of inputs to review

9. Review the inputs if required and continue to start the installation

Installing the Dialog Instance:

Dialog instance is required to handle the additional load on the C.I

1. Click on additional life cycle task. Select Application Server and select the
dialog instance

2. Specify the SID and Instance Number

3. Specify the path of profile directory

97
4. Specify the password

5. Specify the location of Kernel directory and continue to install dialog


instance

Installation of SAP GUI:

SAP recommends the higher version of GUI to be installed to connect to SAP


SYSTEM

Current version of GUI is 7.10 (700, 640, 620, 4.6 D, 4.6 C etc…)

Pre Implementation:

1. Feasibility Report

2. RFQ

3. RFI

4. RFP

5. Installation IDES system

6. Solution Manger

7. ASAP Methodology

Installation Logs:

Central Instance:

Control.xml: It consists of installation steps that are executed one by one.

Keydb.xml: It will give you where the installation steps need to be start
(Continue with old installation)

 Check for environment variables

 Check for privileges of the user who is going to install the SAP S/W.

Contol.xml gets the details from DVD or DUMP and write the
installation steps in keydb.xml. When the installation is restarted it

98
reads from keydb.xml to continue the installation where it is
aborted.

 Set Environment for users

 Create users (<SID>ADM, SAPService<SID>)

 Create groups (SAP_localAdmin, SAP_<SID>_Admin,


SAP_<SID>_GlobalAdmin, SAP_<SID>_localAdmin)

 Assign groups to users

<SID>ADM: It is the owner of R/3 system (Administrator)

SAPService<SID>: It is the owner to run the services when the system is


started and ensure that password never expires (Back Ground service user)

Groups:

SAP_LocalAdmin: To administer the system locally and to own the usr/sap


directory

SAP_<SID>_Global Admin & SAP_<SID>_LocalAdmin: These groups are


created to provide access to instance specific and they are used when
multiple <SID> are in one system.

Creating usr directory where the SAP profile parameters are installed

SAPinst creates shared mounts SAPmnt and SAPloc to access by other


systems in the landscape

SAPinst extracts executables in to RUN directory. But from ECC 6.0


exe/nuc/NTI386 or exe/uc/NTI386

Create services and run the services

SAPoscol and SAP<SID>_<INR>

SAPoscol: It is an operating system collector

SAP<SID>_<INR> It is an instance specific service to run the SAP. It is based


on SAPstartsrv.exe

99
Database Instance:

It checks for the users and passwords of <SID>ADM and SAPService<SID>


users

Extracts database dependent executable into RUN directory

Creates the database

Creates the table spaces

Loads the data i.e. import data from Export DVD’s

How to load the DATA:

As we can’t load the data sequentially (It is time consuming) we will load the
data based on table type.

SAP Defined: It provides command files that are split based on the version.
These command files control the loads.

These are nothing but (2 running, 3 Completed, 9 waiting and Failed 0)

Each command file is related to a task file i.e. “.tsk” file.

Each task file get’s the size from “.tpl” file and get’s the structure from,
“.str” file and table of contents from TOC file.

Process of Loading: Each task file consists of the Tables, Index View, Pkey etc
to be created.

T-table, D-data index, p-primarykey.

Each task file when it is going to run state it is copied to a “.tsk.bak” file.
The load happens from .bak file. When the table is created or loaded an
entry is made into .tsk file with status (OK). If it could not be loaded then the
status will be (err) and we can see if it is failed in SAPint GUI (Failed)

Post Installation Activities:

 Check the consistency of the installation by using transaction


“SICK”. It checks the consistency between O/S and its patches, DB
and it’s patches and R/3 and it’s patches (Kernel Path). Based on
the errors we may need to update OS, DB patches and R/3 patches

 Lock all the known users and passwords in all the clients

100
For Sap*  login/no_automaticuser_sapstar=1

 Create two super users. One should be sealed and kept by the
project manger and other one is used by BASIS consultant

 Initialize Change and Transport system or Correction Transport


System (CTS). For this Go to SE06 9System Engineering) and select
the standard installation and perform Post Installation Actions. It will
prompt to configure TMS. It will reset ‘Transport management
System”

 System settings as per role of the system in the landscape we need


to set whether it is MODIFIABLE or NOT MODIFIABLE.

Go to SE03 and click on system change option.

MODIFIABLE: The objects are allowed to modify in the system.


Using this option we can modify objects and we can restrict some
objects. This is set for Development System only. Occasionally we
may set this option for Quality System, but never in the production
system. Modifiable means the system is modified in terms of
Repository Objects 9SAP standard objects), tables, programs,
transactions etc..

NOT MODIFIABLE: This option is set to production and none of the


objects are modified. If you change accidentally in the production
system it is tracked in the auditing and you will be questions for the
reason we may need to pay damages if it is set modifiable without
approve from authorized customers.

These are called as System Change Options (Modifiable &


Non Modifiable)

 Configuring TMS in Client 000:

Transport Strategy: We have to define this strategy to ensure that


the objects are developed in one system and moved on to other
system for quality testing and finally to production.

Configure TMS: The transport strategy has to be configured in 000


client with user i.e. copied from “DDIC”.

Ensure that two Background work processes are defined in the


system.

101
Go to STMS

A pop up window is displayed to configure “Transport Domain


Controlled” (TDC)

Domain Controller: Commands the other systems in the land


scape.

TDC: It is a domain controller to control all the systems in the


landscape. It is used to manage all the transport parameters in the
landscape. In most of the environments there will be only one
Domain Controller.

POP UP Window: It provides two options one is to configure


Transport Domain and other is to configure Member systems.

While configuring transport domain provide the name of the


transport domain i.e. DOMAIN_SID and description save the
transport domain.

Include system in Transport Domain: Select the option next to SAVE


icon provide HOSTNAME and SYSTEM number to include the system
in the landscape

Backup Domain Controller: IN case of “TDC” failure ‘BDC” will


take over.

STMS Overview Select System Select the system that needs


to be configured as BDC Go to Communication TAB Specify the
BDC system and click on save.

Include Systems in the Domain: When you include systems in


the diamond a request is sent to Domain Controller. To include in
the domain logon to “Domain Controller” Go to Overview
Systems Select the system and click on Approve. RFC destinations
are created with a Communication User “TMSADM”.

Create Virtual System: As the other systems of the landscape are


not included we are creating “Virtual Systems”. Virtual Systems are
required to address the objects that are created in development
system.

If the virtual systems are not defined we need to address manually


which is a time consuming process.

102
STMS Overview systems SAP systems create virtual system.

Defining the Landscape: Go to STMS Overview Transport


Routes Go to Configuration in Change Mode Select standard
configuration Save.

Landscape Strategy: The arrangement of systems in an order to


display the flow of objects in the landscape.

System: The system is a physical entity where certain activities are


carried in the landscape

Development System: It is referred as DEV but one can use their


own naming convention. It is used to develop the objects in the
landscape. It is only the system where development activities are
carried out. The system settings are set to “Modified”.

Quality System: It is used to test the objects for load and stress
that are developed in development system. The system settings are
set to "Not Modifiable”. If the object fails to test it needs to be
modified again in the development system is tested again in the
development system. Don’t move the objects to production system
until they are successfully tested.

Production System: The objects which are approved in the testing


system will be moved to the production system. System settings are
set to Not Modifiable. If any object is found fault it has to route from
Development System again.

Apart from the above we can have the following systems in the
landscape

1. SAND BOX

2. PRE PRODUCTION

3. TRAINING

4. PAY ROLL……..

Types of Landscapes:

1. Single System Landscape

2. Two System Landscape

103
3. Three System landscape

4. Multi System Landscape

5. Other Systems in the landscape

SYSTEM: It is a physical entity which is installed with the following


components

The /usr directory

The usr directory consists of:

1. TRANS directory

2. Executables Directory exe

3. Profile Directory

4. The system is represented by an Instance. i.e. the Directory

DVEBMGS <Instance_Number>.

/usr Directory (OS Level)

Screens, Programs, Reports, Functional BASIS LAYER


Modules, Menus, Transactions

(DATABASE LEVEL)

Repository: Collection of Data (Programs, Transactions, Screens, Menus,


Functional Modules)

Repository Objects (A-X): The objects with name preceded by any letter of
this range are called as standard objects and repository objects and are
developed by SAP.

All the Repository objects are stored in the table TADIR. SAP recommends
not to modify any of the Repository objects. SAP in turn recommends to
develop your own objects in customer name space Y-Z alternatively with in
defined our own objects using Company Name.

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

Cross Client Customizing:

Customizing: It is the process of keying entries in to the table without


changing the basic structure of the system.

Ex: measurements, Country, Currency, Time settings etc…

Support Backup

EWA

066 Template
001 000

Cross Client Customizing

Standard Objects or Repository

Client: A Client is an independent business entity that represents a company


or business. Client has its own User Master Data, Application Data and
Customizing Data.

Client Specific Customizing Backup Client


Client EWA

Strategy 066
Default
001 000
Template

Cross Client Customizing


105
(C.C.C)

Programs, Transactions,
DD02L: It is a table which contains all SAP tables.

SM01: List of transactions

SM02: System Message

Functional Module: It is the logic behind the screen.

System: It consists of repository Objects, Cross Client Objects, and Client


Specific Objects. 9User Master Data, Application Data, Customizing Data).

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


landscape i.e. used for Development, Quality and Production System.

It is recommended for Demo purpose and never used for production because
the Development, Quality and Production activities takes place in the same
system.

In Single System landscape the Inconsistency and Conflicts will arise in the
objects.

DEV QAS PRD EWA

066
001 000

Cross Client Customizing

Standard Objects or Repository


SINGLE SYSTEM LANDSCAPE

106
Two System Landscape:

It is least recommended landscape by SAP where Development and Quality


activities are performed in one system and production activities are on the
other system.

Disadvantages: The repository and cross client objects still share by


development and quality system. So there will be inconsistency and the
objects are used either by developers and quality people.

DEV QAS EWA PRD EWA

066 066
001 000 001 000

Cross Client Customizing Cross Client Customizing

Standard Objects or Repository Standard Objects or Repository


DEV/QAS Consolidation Root Production
(PRD)

Three System Landscape: This is most optimized landscape recommended


by SAP where Development, Quality and Production activities are performed
in three different systems.

Z<SID>

DEV EWA QAS EWA PRD EWA

066 066 001 066 001


001 000 000 000

Cross Client Cross Client Cross Client


Customizing Customizing Customizing

Standard Objects or Standard Objects or Standard Objects or

107
Consolidation Root Delivery
Root

THREE SYSTEM LANDSCAPE

Multi System Landscape:

DEV QAS PRD

OFF SHORE INDIA

DEV QAS
DEV QAS PRD

US

DEV QAS PRD

EUROPE

In a multi system landscape the development (object) is performed at off


sore (Common Development Environment) and the objects are transported

108
onto different landscapes. Geographically the objects are customized locally
according to local customize settings (Measurements, Time Tax etc…)

Other Systems in Landscape: Apart from the three system landscape SAP
also allows to include the following systems in the landscape.

1. Testing

2. Sand Box

3. Training

4. Pre Production System

5 Pay Roll or Migration system

Note: SAP allows 8 systems in the landscape for a single installation


number.

 Applying License: Each system needs to be applied license so that


runtime issues are resolved by SAP.

Go to Transaction slicense

The license key depends upon Hardware key o f the machine and installation
number.

In earlier versions where this T-Code is not available use command


“suplicnese-get” to get the hardware key.

Note: Hardware varies depending upon the O/S. Ex: 32-Bit, 6t4-Bit O/S and
SAP component

Go to market place with authorization to generate license keys and click on


the tab license keys Click on the option request license key select the
installation number provide the following details:

1. System ID

2. Host Name

3. INR (Instance Number)

4. OS

5. H/W key

109
6. Data Base

Now SAVE the information to generate the license key.

Normally license generation will take around 1 hour. The license key can be
downloaded from the same screen. Alternatively SAP also sends over the E-
mail.

The license key is a number of 24 digits but now SAP is sending the license
by encrypting in the text format.

License can be installed in Two Types:

Click on Install New License Specify the Instance Number System


Number and Key

Click on New License and specify the path of the text file.

User Master Data Application Data Company

400 300 200 EWA 400 200 EWA 500 EWA


066 066 001 066 001
001 000 000 000

Cross Client Cross Client Cross Client


Customizing Customizing Customizing
Standard Objects or Standard Objects or Standard Objects or

When the system is installed it can be accessed with 000, 001 and 066
clients.

Client: A client is an individual business entity or a company having its own


User Master data, Application Data and Customizing Data.

Client is represented by a Field MANDT in the database.

The tables with fields MANDT are called as Client specific tables.

110
Client field MNADT is a data separator i.e. the user’s needs to specify the
client number to logon to the client specific data.

000 Client: It is a default client or template client which is provided by SAP.


No changes are allowed in this client. As this client is SAP client it is
commonly updated by applying Support Packages, Patches, Add-on’s and
languages etc…..

It is used to setup Transport Management System (TMS) and run Standard


Jobs. No customizing data, Application Data and User Master Data (Except for
the Super Users) is allowed.

001 Client: It is a backup client for 000 client as per initial plans of SAP. But
000 is continuously updated where as 001 is not. So the purpose is deviated
in the current versions like SOLMON, NETWEAVER systems. 001 is considered
as production client.

066 Client: Early watch client. It is used by SAP to logon remotely and
generate Early Watch Alerts. As per “SLA” (Service Level Agreement) SAP
sends two early watch reports per annum.

Client Creation: As the standard clients provided by SAP are not used for
production use we need to create our own clients and define client roles

Clients are displayed, created and modified in the transaction SCC4.

Go to SCC4 Click on New Entries Specify the Client Number Add


description Save.

Client Number: it is a3 digit ID which varies from 000 to 999 which means all
together we can create 1000 client s in SAP.

Client is represented by Field MANDT in the database.

Note: The clients are available in the table “T000”. This is the only Cross
Client Table with the MANDT field.

Click on New Entries and specify the name of the clients, specify the client
numbers specify the name of the city.

Logical System:

111
This is used to differentiate between clients in the landscape. Logical
systems are created in transaction SALE.

SALE: System application linking and Enabling.

SALE is used to define the logical systems that are used for communicating
or transferring data.

Systems are using naming convention.

Ex: DEVCLNT555, QASCLNT555, PRDCLNT555

Note: Do not try to change the logical system name. Once it is assigned to a
client. In order to change logical system i.e. assigned to a client use
transaction BDLS.

This BDLS transaction is generally used after performing a SYSTEM COPY


from production system.

500 EWA 500 EWA

066 001 066 001


000 000

Cross Client Cross Client


Customizing Customizing

Standard Objects or Standard Objects or


QASCLNT000 Client Copy
PRDCLNT000

PRDCLNT000 to QASCLNT000 (We need to change)

Go to SAVE Go to BASIC settings Select logical system Define logical


system Click on New Entry Specify logical system name (QASCLNT000)
Click on SAVE

112
It will prompt you to create a change request Specify the logical system
name Select the logical system name Select the currency Specify the
client Role

Client Role: It specifies the role of the client in the landscape. There are
various client roles defining the implementation.

Development System: In the system landscape development system the first


client i.e. going to be created as Master Client, Parent Client, Golden Client. It
is represented by CUST i.e. customizing role.

This is only the client in the landscape where changes are made. The
changes in the landscape will be carry forwarded to other clients in the
landscape. No changes are allowed in other clients.

Changes and Transport for Client Specific Objects:

1. Changes without automatic recording

2. Automatic Recording of Changes

3. No changes allowed

4. Changes without Automatic Recording, No transports allowed

Cross Client Object Changes:

1. Changes to repository and cross client customizing allowed.

2. No changes to cross client customizing objects

3. NO changes to repository objects

4. No changes to repository and cross client customizing

Protection Client Copier Tool and Comparison Tool:

Protection Level 0: No restriction

Protection Level 1: NO over writing

Protection Level 2: No over writing and No external availability

CATT and eCATT restrictions:

eCATT and CATT not allowed

113
eCATT and CATT allowed

eCATT and CATT allowed only for trusted RFC

eCATT allowed but FUN/ABAP and CATT not allowed

eCATT allowed but FUN/ABAP and CATT only for trusted RFC.

Restrictions:

Locked due to client copy

Protection against SAP upgrade

Cross Client Customizing:

Changes to Repository and Cross Client customizing allowed: In this


particular client the changes made to cross client and repository objects is
allowed

Changes only to repository Objects: Repository objects only can be modified.

DEV:

Client C.S CCC & REP Protection

CUST ARC YES 0

TEST CWR NO 1

SAND CWRT NO 1

QAS:

Client C.S CCC & REP Protection

CUST NO NO 2

TEST NO NO 2

SAND NO NO 2

PRD:

Client CS CCC & REP Protection

PRD NO NO 2

114
CS Client Specific

CCC Cross Client Customizing

REP Repository Objects

Protection Protection Level

Protection Level:

Level-0: No restriction i.e. no restriction. This client is allowed for over writing
and available for client copy

Level-1: No overwriting i.e. the client is not allowed to be over written by


other client

Level-2: This option is provided to not to allow client copy and client
comparison

Note: Based on requirements we may need to change this protection level


and cross client object changes even in the production system.

Note: Don’t try to change these options of preproduction and production


without approval. Changes to these tables are logged with Data and Time
along with User Name.

Ensure that necessary approvals are obtained from the customer to change
the client settings.

eCATT and CATT not allowed: It is used to upload the data into the system.
We need to specify whether they are allowed or not. Depending upon the
requirement we may allow or disallow all the clients. But in production client
it should be set to not allowed.

Test Client: It is used to test the scenarios that are configures in CUST
client. Changes are moved from CUST to TEST using transaction SCC1.

SAND CLIENT: It is used to configure the scenarios based on customer


requirement. It will serve as a play ground environment. For the consultants
no changes are carry forwarded.

115
QTST Client: This client issued for integration testing and consolidation
testing. Changes that re made in CUST client are transported to QTST client.
(Tools like mercury, ecatt are used to test the integration between modules
along with stress and load testing).

TRNG Client: It is used to training end users before they work on the
production system.

MIGE and Prep (pay roll): These are optional clients that are created
based on requirement. Migration client is used to migrate the data from
legacy system. Preproduction client is used to check the behavior of changes
before they work.

Payroll Client: As we can’t run the pay roll on the production system (Test
Payroll n-number of times) payroll client is created and it is run at various
frequencies.

Prod Client: It is used by the end user to perform the business. It is more
critical client and no other system in the landscape is allowed to carry the
business.

116
Pre Requisites of Client Copy:

1. Switch off active log files.

2. There should be enough space in the database. For this execute


RSSPACECHECK and RS1TABLESIZE to identify the space and memory
requirement.

3. Choose 000 client for initial client copies. However business clients are
also allowed for client copy based on protection level.

4. To perform client copy always login into Target Client and copy the data
from Source Client.

5. Client copy consumes time, so schedule in the background

6. Choose Profile to specify the data to be copied from source client


(Application Data, User master Data, Customizing)

Ex: SAP_ALL, SAP_USER, SAP_CUST, SAP_APPL

7. Define RFC destination between two systems to perform Remote Client


Copy

8. Check the space in TRANS directory to perform client export.

9. Perform a TEST RUN before actual client copy

10. Client copy logs are displayed in Transaction SM37/ SCC3.

11. It is not recommended to login to source client and modify the objects
during the client copy.

12. During client copy the number of tables does not increase. Only the
entries in the table increases under the entry “MANDT”.

13. Remote client copy has to be performed between same systems (Same
Version, Same Patch Levels) not possible for different R/3 system.

If DB tables having field MANDT then these are specific to client.

If there is no MANDT field in the tables these are shared tables for all clients.

Desc SAPDEV.usr02 (Describe DB tables)

Cross Client is shared by all users.

117
Select MANDT , Count (*) from SAPDEV.usr02 group by mandt;

Select count (*) form SAPDEV.usr02;

Select count(*) from sapdev.tbdls;

Select count (*) from sapdev.tadir;

Select BNAME from SAPDEV.usro2 where MANDT=’800’;

Select * from SAPDEV.usr02 where MANDT=”789”;

Select MANDT form DEV.T000;

Local Client Copy:

It is performed between two clients with in the same system.

1. Create a client (SCC4 for create client) and logon to the target client

2. Go to Transaction SCCL

3. Select Source Client

4. Select Test Run to check the source

5. Select Profile

6. Select start immediately and schedule in background

7. Go to SCC3 to check the logs (To monitor the client copy process)

Remote Client Copy:

It is performed between two clients with in two different systems in the


landscape

1. Create a client

2. Go to SCC9 of the target system

3. Specify the profile

4. Specify the RFC destination

5. Start in the background mode. However we can start immediately

Client Export and Import:

118
It is used to perform the client copy between the systems which are not in
the landscape

It is performed in 3 steps.

1. Client Export: Use Transaction SCC8 to export the client to O/S level. This
process generates transport requests in the \usr\sap\trans directory.

2. Copy the files to target system and import them using FTP and transaction
STMS

3. Client Import: Go to Transaction SCC7 and perform client import

Based on client export profile KX, KO, KT files are created in


\usr\sap\trans\cofiles and RX, RO, RT files are created in \usr\sap\trans\data
directory.

KO, KX,KT are called as cofiles or control files

Ro, RX, RT are called as Data Files

Copy the files using FTP\normal copy\DVD into target system


\usr\sap\trans\cofiles and \usr\sap\trans\data directories.

Go to STMS. Add the request and Import

Go to SCC7 to perform post client Import activities

Standard Clients

000 (Template) 001 (Backup Client)


066 (Early watch)

Clients

DEV QAS Migration/ Legacy


PRD

119
CUST TEST SAND BOX QTST TRNG PREPROD
PROD

Client Deletion:

SCC4: Delete the entry from table T000.

SCC5: Permanent Deletion

To lock and unlock a client:

Go to SE37

Reports: The following reports can be used to lock and unlick the clients.

Sccr_lock_client- lock client

Sccr_unlock_client- unlock client

Note: Profile SAP_CUST is used initially to setup Golden Client but later this
golden client can be used as a source client to copy to another client with
other peofiles.

Client Deletion: Clients are deleted using SCC5. But they cannot leave any
space in the Database i.e. by deleting a client we cannot get any free space
in the database. We need to reorganize the database.

Locking and Unlocking Clients: Use these two reports to lock and unlock the
clients.

SCCR_LOCK_CLIENT and SCCR_UNLOCK_CLIENT


(or) we can manually use tp to lock clients. Use transaction SE37 for lock and
unlock clients.

Client Comparison: While applying client specific patches i.e. CIN(Country


India Version) use transaction SCMP to compare between two clients and to
adjust the changes between two clients.

Setting up Library:

I order to get the screen context help we need to install the library and setup
in SR13.

Install the library from library DVD. In the shared folder Sap help.

120
Go to SR13 to set up the library

There are four types of libraries available

1. HTML Helo

2. Dynamic Help

3. Plain HTML Help

4. HTML HTTP Help.

F1-Field Help

F4-Field Possible Value Help

HTML Help: It occupies lesser space when compared to other library


formats. It is viewed using micro soft help viewer. It is in the compressed
format.

Plain HTML: It is installed on the file serve and help is displayed in the HTML
format.

HTML HTTP: It is installed on the web server and requires web browser to
execute.

Click on New Entries and provide the Following Details:

1. Name of the O/S

2. Variant

3. Training

4. Path of the library up to help data drive directory

5. Specify the language

6. Select the default check box

7. Save the entries

Scheduling House Keeping Background Job:

Go to SM36  click on Housekeeping jobs and schedule with default variants

121
Importing Profiles:

RZ10 It is used to set the parameters for Work processes, Memory, Buffers
etc…

Go to RZ10Utilities Select Import Profiles of Active Server

DB13: Schedule an offline Backup so that we can test the Backup


mechanism

Scheduling Database House Keeping Jobs:

Select check and verify database optimizer statistics, Adopt extents etc…

Go to DB13 Select the Date It displays all the above tasks. Select each of
them and schedule with different times.

Operation Modes: These are used to adjust the Work Process between Dialog
and Background work processes.

Use transaction RZ04 and SM63 to configure Operation Modes.

Note: Ensure that the systems configured to solution Manger to configure


the business scenarios as per the project plan.

SMSY, Solar1, solar2, Solar_project_admin

Applying Support Packages:

Go to Transaction SPAM

Creating Users: Create users and assign SAP_ALL, SAP_NEW (Take out the
critical Transactions like SU01, RZ10, RZ03, PFCG etc…)

122
DEVELOPMENT
Customizing: This is a process of modifying the system according to the
requirements of the customer.

This is performed in the transaction SPRO. (SAP project customizing). This is


the process of keying the entries into the table.

Customizing consists of the Following:

1. Crating Company

2. Crating Country

3. Crate Currencies, Measurements, Time Settings etc…

For example below are some of the customizations that we will do indifferent
modules:

FI: We create Vendors, Customers, Cost Centers, Account Receivables,


Payables, banks, Tax, Asset management, Description etc…

SALES: Sales Organizations, Sales Divisions, Sales Areas, Distribution


Channels, Billing, Shipping etc…

MM: Purchasing, organizations, Inventory, Stores, Plants, Storage locations,


Ware Houses, Goods, Invoice etc…

Exits or User Exits or Customer Enhancements:

It provides additional functionality to the SAP system. Exits can be searched.

Transaction SMOD (Search Modifications) and CMOD (Create Modifications)


are used to create the modifications.

There are various types of exits:

1. Field Exit

2. Screen Exit

3. Menu Exit

4. Function Module Exit

The exits are identified by Functional consultants and logic is programmed


by developers.

123
Support Packages, patches and Notes:

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

Development:
If the customer requirements are not satisfied then we may need to develop
the Programs, Reports, Transactions, Menus, Screens, Scripts and Functional
Modules.

Programs and Reports: All the customer objects has to be created in


customer name space. /Company name/ (or) Y-Z in order to create programs
the developer needs to register in the market place (developer License are
charged separately).

Create user in SU01 and register this user in the market place.

Get developers and key in the registration key before developing or


modifying first program.

It will not prompt for the key later programs.

• Programs are created, modified and displayed in Transaction SE38.

Transaction: It provides an easy way to navigate to the program.

Go to Transaction SE93 and create a transaction using the above created


programs. Provide Program Name and Screen Number to define a
Transaction in the customer name space.

MENU: Menus are defined in Transaction SE41.

SCREEN: Screens are designed in the transaction SE51.

Scripts or Forms: These are available in SE71 and can be modified by


copying in to customer name space.

Ex: PO script, Invoice, Delivery Order, Quotation, Sales etc…

Function Modules: These are used in the programs for modularization i.e.
frequently and logis is turned in to functional Modules.

Domain: It is the least granular field in database which has its types and
property like Data Type and Size. It is created in transaction SE11.

124
It is used to keep the fields uniquely in the database i.e. all the location
follow the same format.

It is a field in the database like Location, name, Currency etc… It specifies


type and Length.

Data Element: It is also defined in SE11 but it is specific to a field pointing


to a domain. It is nothing but domain with a meaningful name.

Ex: District- Location, City- Location, Country-Location, State-Location

TABLE: It consists of ROWS and COLUMNS.

Columns are Data Elements and ROWS consists of Data.

Screen & Menus: SE51, SE64

Transaction: SE93

Program: SE38

Data Element: SE11

Domain: SE11

Table: SE11

Changing the Standard Objects:

SAP mostly never recommends modifying the standard objects in the name
space A-X. However based on the requirements customer may change the
objects by obtaining Access Key from SAP.

These Keys are also referred as SCCR key. 9SAP software change registration
key)

When you modify a standard program in SE38 it will prompt for Developer
Key and Access Key.

Get the program Id, Object Id and Object Names.

Get the above details to generate an access key from the market place

Generate the key only based on the approval.

• As we are changing the standard programs the changes will be lost after
an upgrade.

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

400 300 066 001


000

Cross Client Customizing

Standard Objects or Repository


Objects

Customizing Request

400 300 066 001 400 300 066 001


000 000

Cross Client Customizing Cross Client Customizing

Standard Objects or Repository Standard Objects or Repository


Objects Objects

126
DEV QAS

Workbench Request

CUSTOMIZING
Create super user. Don’t use DDIC to perform any of the following activities

1. Check SCC4 settings client and check whether it is set to ARC (IF it is ARC
we can perform client specific customizing and record the changes)

2. Go to SPRO. Click on SAP REFERENCE Img (Implementation)

Click on Enterprise Structure

Click on Definition

Click on Company- Click on New Entry

Create a Company

• Copying one client to another client is a BASIS consultant task.

• When a client specific entries are Created/ Modified/ Deleted it prompts


to assign the changes to a change request of type customizing

• When a cross client or Repository entries are Created/ Modified/


Deleted it prompts to assign the change to a work bench request of
type workbench.

• Go to SE01 to Create/ Replace change Request.

• Change Request consists of changes that are recorded during


customizing

• Change request are created by Project Leaders and assigned to Team


Members in the form of Task

• Each change request may consists of one or more tasks

• Once the task is assigned to a user only that user can work on that
task

127
• Change Requests are in the form of <SID>K900000 and start with 1
and subsequently it

Will change.

• Right Click on change request and click on Add User (Super User,
Admin etc..)

• User has to release o Admin has to release the task

• Change Request can only be released when all the subsequent tasks
are released

• Please perform client coy using SAP_CUST profile before you start
customizing.

• 36687663221261278694 for IDES system SSCR key

128
CHANGE MANAGEMENT

129
SAP BASIS Administration Tutorial . This will help in understanding and
answering different questions and asked in different interviews.

During the requirements analysis phase the BASIS consultants along with team
members (Functional Consultants, Project mangers) visits the customer and gathers
the requirements and analyzes the requirements to define the scope of thee work.

Scope of Work: (SOW)

It is the estimated work which is documented during the requirements analysis


phase.

It defines the following:

 What type of O/S

 What type of database

 Reusing the existing infrastructure (Ex: Data Center servers)

 Analyze the servers and submit the feasibility report (This consists of
server details like CPU, RAM, Storage, and Warranty)

 What kind of backup customer is looking for?

Types of backup’s are:

1. Online backup

2. Offline backup

3. Incremental backup

4. Partial backup

1. Online backup: The system continuously work and won’t be shut down. Users
cannot get any interruption while performing backup

 What are the production hours & define peak times and off peak hours

 If it is 7*24*365 then what kind of High Availability customer is


looking for?

High Availability: it is defined as the availability of servers in the data center to


continue the user accesses without any business interruption.

There are 2 types of Availabilities:

130
1) System Availability: The system is available and the server is available
but users may not connect to the system or experience very low
performance.

2) Business Availability: While planning high availability we need to


ensure that business operations continue without any interruption.

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

Because of this, many users depend on offline backup for peace of mind in the home or in the
workplace. Many businesses uses offline backup to store files so that they are unchanged and
easily referenced.

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


data than repeatedly running full

backups. During an incremental backup only the files changed since the most recent backup
are included. That is where it gets its name: each backup is an increment since the most recent
backup.

The time it takes to execute the backup may be a fraction of the time it takes to perform a full
backup . Backup4all uses the information it has recorded in its catalog file (.bkc ) to determine
whether each file has changed since the most recent backup.

The advantage of lower backup times comes with a price: increased restore time. When restoring
from incremental backup, you need the most recent full backup as well as EVERY
incremental backup you've made since the last full backup.

For example, if you did a full backup on Friday and incrementals on Monday, Tuesday and
Wednesday, and the PC crashes Thursday morning, you would need all four backup container
files: Friday's full backup plus the incremental backup for Monday, Tuesday and Wednesday.
As a comparison, if you had done differential backup on Monday, Tuesday and Wednesday,
then to restore on Thursday morning you'd only need Friday's full backup plus Wednesday's
differential.

131
Advantages:

1. Backing up is the fastest


2. The storage space requirements are the lowest

Disadvantages:

1. Restore is the slowest

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

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

High availability options:

1. Clustering

2. Standby servers

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

 If the customer is asking to implement more & more users:

 The no of systems to be implemented (R/3 production, test,


developing, demo, training, development, sand box, training, pay roll,
migration, pre production)

 The no of interfaces modules to be implemented

The scope of work document will be sent as a draft to the customer manager and
project manager.

The document will be finalized and signed out by the customer and we can call it as
statement of work.

132
Implementation Methodology:

Applications are built is SAP but not customized.

In SDLC application are not built.

Most of the application are built is SAP.

SAP implementation is carried out by using ASAP methodology.

ASAP: Accelerated SAP.

Using this implementation steps are defined in any organization.

Currently Solution Manager is used for defining these steps.

ASAP consists of the following steps:

1. Preparation

2. Business Blue Print

3. Realization

4. Pre Go-Live

5. Go-Live and Support

Preparation: once the project is awarded the following preparatory steps are
performed.

Install solution manager to record all the activities of implementation.

Note: Prior to this H/W sizing has to be performed to define the H/W required.

Hardware Sizing: it is an exercise which will be carried out at customers place to


identify the required infrastructure. This will be defined in the SOW.

In order to perform H/W sizing SAP recommends to use “Quick Sizer Tool”.

It is a proprietary tool of SAP. The tool is located at www.sevice.sap.com/sizing

Thumb Rule for SAP Installation:

4.6 – 40GB/256MB/512MB

4.7EE – 80GB/512MB

ECC5.0 – 120GB/1GB

133
ECC6.0 – 200GB/2GB

Legacy systems: These are nothing but the existing system which are to be
replaced with new configured system to introduce SAP.

In order to perform H/W sizing we need to use the sizing which is available on SAP
market place

SMP: SAP market place.

The Quick Sizer is a tool that is developed by SAP and its H/W partners to help
customers get an idea about the sizing . It is free of cost

In order to log on to the market place we require USER Id and for performing the
H/W sizing we need customer number.

Customer Number: It is provided by SAP after sizing the software purchase


agreement.

SUSER ID: It is a 10 digit number with S provided by SAP to log n to market place.
This user id a super administrator and have all the privileges on the market place.

We need a SAP user Id called as SUSER ID which start with S followed by 10 digit
number

Ex: S0001234567

134
The Customer No field value will be automatically shown.

The input values required for the H/W sizing are:

 Name of the Project and Customer Number.

 Project name

Now choose create the project. Specify the customer details:

 Specify O/S,DB, Mirroring, RAID

 High availability required (Clustering/standby server)

 Online, offline, incremental backup and partial backup

 What amount of legacy data

 Working hours & specify off peak and park hours

 Unplanned down time

There are 3 types of sizing for SAP.

 User Based Sizing

 Throughput Based Sizing

 Customer performance Test

1. User based Sizing:

6. This sizing depends upon the no of users, type of users and modules
used.

3 Types of users:

1. Normal User: The user who communicates with the system and the
requests will be in between (0 to 480 dialog steps/40 hours)2 dialog
steps/ Min

2. Power user: These are the one who will create dialog steps in between
480- 4800. For every 30 Sec one dialog step

135
3. Transactional users: These will create around 4800 to 14400 dialog
steps per week. These users will create more load on the system. By
activating the transactions at least once per every 10 seconds. These
users are also called as concurrent users.

Dialog Step: user request goes to server and comes back to the user. Average
response time of a dialog step is 800 m sec to 1200 m sec i.e. 1.2 seconds

Now specify the Type of users, No of users and Module users.

2. Object Based Through Put Sizing:

It is not based on users but it is based on users but it is based on


transactions. We need to specify the number of objects to be created.

Object: Sales order, purchase order, invoices, buildings, shipments delivery

It is based on objects and the dialog steps. In order to use this method prior
expertise or previous experience is required (Mostly used for upgrade)

Specify thee no of users in local area network or WAN, internet users.

Apart from the above we need to consider O/S, Db, JDK and other 3rd party
tools.

Save the details, calculate the result and set to final.

3. Customer performance Test:

136
Output of H/W sizing:

The output f the hardware sizing is the requirements in terms of SAPS.

H/W Sizing:

Disk category SAP’s CPU Category Memory in MB


Disk Size

S,M,L,XL,XXL 900 S,ML,XL,XXl 3200 198000 X50

SAPS: SAPS stands for “SAP Application Performance Standard”

While defining SAPS, SAP has considered a most populated module SD as a


benchmark.

Fir every 2000 sales orders which are created in an hour generated 100 SAPS.

SAPS: SAP applications benchmark standard

SAPS is a unit which will be used to calculate the amount of CPU resources
required. The H/W vendor also provides details of SAPS generated by various CPU’s.

Ex: IBM P-series.

It will generate 1000 SAPS per CPU

In the same level I-Series generates around 900 SAPS. It always depends upon the
speed of the CPU. Depending upon the no of SAPS we need to recommend the CPU.

Ex: If the SAPS required are 3600 we may need to suggest going for multiple CPU.
Whereas for 1000 to 2000 steps we can recommend DUAL CPU’s.

Note: H/W sizing will not give you the exact figure required. It is recommended that
40 to 60 % of the sizing needs to be added to the sizing results.

9 dialog steps are required for one sale.

For 2000 sales 100SAPS are considered.

2000 X 9 (for 100 SAPS per hour)= 18000 dialog steps/hour

Sizing report can be changed from time to time by modifying the details in the quick
sizer tool.

Note: The sizing which is planned should cater at least for minimum 3 years.

Ensure that H/W is capable of handling the enhancement.

137
Communication with SAP: Customer communication with SAP to purchase SAP
software depends on No Of Users. Currently for 5 users it is charging 14 lakhs. On
top of it every year we need to pay 17% as service fees.

Once the agreement is signed SAP shifts software to the customer sight.

The following products are available in SAP:

1. MYSAP Business Suit

2. SAP NETWEAVER

3. SAP BUSINESS SPECIFIC (SAP B1)

4. SAP ALL IN ONE

1. MYSAP BUSINESS SUITE:

It consists of the following modules.

S.C.M: Supply Chain Management

C.R.M: Customer relationship Management

S.R.M: Supplier Relationship Management

P.L.M: Product lifecycle Management

mySAP ERP: myERP Financials, muSAP HR, R/3 Enterprise

2. SAP NETWEAVER:

SAP NETWEAVER: It provides all the new dimensional components like EP


(Enterprise Portal) , XI (Exchange Infrastructure), MDM (master Data Management),
PI (Process Integration)

3. SAPB1:

It is a product which is specific to particular business

Ex: Textile, Fabrication, Banking

4. SAP ALL IN ONE:

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

Note: SAPB1 is not a part of Netweaver.

ASAP Implementation of SAP is as follows

1. Project Preparation Phase:

IDES: Demonstrative Educational or Evaluation software

Let the users log in to the system for demos. During this phase S/W and H/W
arise. The installation is valid only for 30 days.

Check the H/W and S/W.

Prerequisites for SAP installation:

1. Ensure that H/W is procured according to the sizing requirements

2. Check and verify the S/W from the market place which is shifted to
you.

3. Check the DVD’s are existing, check if they are readable

4. Download the installation guides from the marketplace link


“instguides”

5. Check for known-problems for installing SAP components (Known


problems while installing Solution Managerr3.2)

6. Install Java runtime environment because they are designed using JAVA

7. Set the environment variables JAVA_HOME and path.

8. Set the virtual memory, currently we can set 3X RAM size from
Windows 2003 onwards

9. Communicate with network team and obtain static IP address

10. Specify the host name and IP address in etc/hosts

139
11. Install the O/S with relevant patches

12. Install the RDBMS S/W and patches

13. Set the file sharing to the maximum of “NIC”

14. Dump the S/W into the server, ensure that the directories should
not have spaces and special characters

15. The system name should not be more than 13 characters.

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

XI
BW CR
M
Solution
Manager

R/3 AP
XI/EP

Solution manager requires 28 GB of space for installation.

Solution Manager is used to configure satellite systems R/3, BW, CRM, XI,EP,APO
and other WEBAS ABAP and WEBAS JAVA components.

Satellite Systems: All the systems which are configured as satellite systems can be
monitored through solution manager.

Creation of Satellite Systems:

Go to transaction SMSY. It is a transaction in solution manager. Create R/3 system,


database host, System landscape, and generate RFC destinations with satellite
systems.

RFC: Remote function call.

Generation of Installation KEY or Upgrade Key:

140
Go to SMSY menu -> Go to other object and specify the HOST NAME, SYSTEM ID,
INSTANCE NUMBER –> click on Generate Installation/Up gradation Key

Transaction: It is a shortest way to navigate to the programs in SAP system. There


is a command window which will be used to execute the transactions. Transactions
are easier to use and cut down the dialog step activity.

SAP Based Menu: Easy access menu. It is a standard menu, which is used to
navigate to the programs with “n” no of dialog steps.

We can create our own transactions. Transactions are created in T-Code SE93.
While defining transactions SAP has followed certain conventions.

Transactions that start with SM are used for System monitoring / Sap monitoring

Transactions that start with ST are used for system traces

Transactions that start with SE are used for sap engineering

Transactions that start with SU are used for user administration

Transactions that start with VA for sales

Transactions that start with ME for material management

Transactions that start with AL for alerts…………………….

Project Management:

Go to T-Code ” SOLAR_PROJECT_ADMIN”

It is a transaction where project is created. It is used to define the following:

1. Name of the project

2. Person responsible for the project

3. Name of the consultants

4. Project status

5. Modules to be implemented

6. Mile stone

Templates available can be used or templates can be avoided.

141
2. Business Blue Print Phase: It is configured in “solaro1”. It is used
to configure business scenarios which need to be implemented in the
project. Go to SOLAR01 select business scenarios -> go to structure ->
Go to Configure elements -> press F4

When we press F4 it will display the list of the components. Select the
component for configuration.

3. Realization (or) Configuration Phase: This is where exact


configuration of the system is performed. Go to SOLAR02. Select the
business Scenarios which need to be configured. Click on the
transactions so that it will be routed to the respective transaction in
the transaction system.

Note: To define and Configure Satellite system logical system component should
exist

Documentation such as screen shots and notes can be uploaded.

In order to implement the above steps or phase we can use the road map which is
predefined in solution manger.

Go to Road Map (RM Main)-> Select the Project and choose the road map which is
predefined in solution manger -> Go to Road Map and you can down load the road
map. We also have the flexibility to define the consultants for each phase.

4. Pre Go-Live (or) Final preparation Phase: During this phase all the
configured components are related and moved on to other systems in
the landscape. Some of the key activities are

1. Data Migration from legacy system

2. Quality check for all the programs

3. Pre pay roll run

4. End user training

5. Pre Go-Live check by SAP

5. Go Live and Support: The system goes live on the cutoff date, end user
start working, run time problems are identified, patch up work will continue,
support the project till SLA ends

SLA: Service Level Agreement.

142
Advantages of Solution Manager:

1. Key Generation

2. Centralization

3. Alerts

4. Service Desk

5. Support package Updates

6. Solution Monitoring

7. Documentation

8. Project Management

9. Reports

Inputs required during Installation:

Make sure that Pre requisites are met. (H/W,O/S, Virtual Memory, Environment
variables, me JDK,RDBMS)

Make sure the availability of Installation master DVD, KERNEL,Export DVD and
Instguide.

In earlier versions up to 4.6c R/3 setup is used for installation. But from 4.7 onwards
SAPINST is used for R/3 installation up to WEBAS version 640 SAPinst tool has
independent DVD’s for R/3, BIW, CRM, APO. But from 640 onwards master DVD will
be used to install ERP, CRM, SRM and other NETWEAVER products.

R/3 setup –Not GUI

Kernel- R/3 Executable

Export DVD (If it is component Specific then it is separate for every module)

JAVA

SAPinst Tool: It is used for installing R/3 components based on ABAP and JAVA.
SAPinst tool has its own version. If the tool dosen’t support the installation we may
need to upgrade SAPinst to higher versions.

Download the current version of SAPinst executable from the market place
www.service.sap.com/swdc

The DVD’s used for installation are

143
1. Installation maser DVD

2. Kernel [Release Specific] 6.40 or 7.00 (8.00 will come soon)

3. EXPORT DVD’s. It consists of component specific data such as tables


(Everything is stored in the database)

4. JAVA DVD’s which are required for providing graphic solutions (IGS-
Internet Graphic Service)

5. GUI installation DVD: It is used to install SAP GUI front ends for all the
users.

6. RDBMS software (Oracle, MAXDB, Informix, DB2, SQL Server)

7. Language inputs (or) language DVD’s. By default German & English are
installed. Additional languages are installed using this DVD’s.

8. Support Package Collection: It is used to apply the support packages


and patches to R/3.

9. Add on components: additional components related to XI, BI and other


Netweaver components or other industry specific solutions.

1) Go to Installation Master DVD

2) Select the O/S specific directory

3) SAPinst.exe

4) We need to set the runtime environment JAVA_HOME.

5) SAPinst listener on port 21212. We need to ensure that the port is not
blocked.

6) Select the component to be installed say ECC 5.0

7) You need to select the database

8) Select the Unicode or Non-Unicode

Single Code: The database has its code to support the language.

Ex: If we have English, German the default code page is 1100. This code page
supports only few languages. If we want to access the system with other language
which are not supported by current code page we need to install that code page.

MDMP: Multiple display multiple processing (Out dated)

144
It is used to support in installing to a language. MDMP has a disadvantage because
e have to handle different code pages when upgrading the system.

UNICODE: The database reserves 2 bytes to cater to almost all the languages in the
world. It supports all the data code pages and no special attention is required during
up gradation.

Note: We can install non Unicode system but it can be upgraded to Unicode by
using SAP export and import tools.

Note: Unicode system cannot be converted into non Unicode system.

9) Select Central Instance: Click in next

10) Specify the< SID>: SID is used to identify the system. It should be of
3 characters and can also be alphanumeric. It should start with a
character only followed by alphanumeric values.

Note: Do not choose SID from the reserved words SAP, ALL, BIW, ERP. We can
use like PR1,P01, D01, D40, P20…..

Try to define the naming convention for all the systems in the landscape.

Instance Number: This is the port number which will be used to reserve the ports
or the instance services and processes. It should be in between 00 t 97.

11) Specify the host name. The name of the system where the installation
is performed. This should not be more than 13 characters. Ensure that
host name and IP address are entered in etc\host.

MCOD: Multiple components on one database

From Oracle 9i onwards multiple components like ERP, BIW, CRM, and SRM can
be installed on one database. The databases are differentiated by SCHEMA ID’s
(Ex: SAP<SID>SAP01).

SCHEMA OWNER: It is the owner of database represented by SAP<SID>.

Instance number should be unique in the system.

Hostname: Name of the software where installation s performed.

Specify the host id of database. It will be same as the central instance host.

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

145
Central System Installation: If the central instance and the database instance
installed on the same physical machine then it is treated as central system
installation.

Distributed Installation: Database instance and central instance are hosted on


two different machines. In case of a distributed installation specify the name of the
database host where database is installed.

Central System

Host Name HOSTNAME

DB
Central
INSTAB
Instanc
CE
e

Physical Machine

Instance: An instance provides executable services.

Ex: Database Instance, Central Instance, Dialog Instance

Instance has its own instance number it requires own memory configuration.
Multiple instances can be installed on a single system.

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

14) Specify the type of installation

Local Installation: It is performed locally using the local user rights. Unless and
until it is recommended don’t go for any installation except local installation.

Ex: For installing DUET local installation is not recommended.

Duet Enterprise is a business tool that blends SAP and SharePoint data to increase
staff and department productivity, according to the pair.

Microsoft SharePoint, also known as Microsoft SharePoint Products and


Technologies, is a collection of products and software elements that includes,
among a growing selection of components, web browser based collaboration
functions, process management modules, search modules and a document-

146
management platform. SharePoint can be used to host web sites that access shared
workspaces, information stores and documents, as well as host defined applications
such as wikis and blogs. All users can manipulate proprietary controls called "web
parts" or interact with pieces of content such as lists and document libraries.

Installation Number: If the installation is carried out in a domain ensure that all
privileges are held by the user to install the components. Most of the domains have
restrictions for passwords, user creations password expiry.

Note: It is recommended to install locally and attach it too domain later.

Domain Server: All the systems in landscape are configured with domain server. It is
a centralized server. It can give IP address of DHCP.

Specify the kernel directory and transport directory.

Specify the database instance parameters, database id, dbhost, db home (Home
Directory of Oracle, db SCHEMA’s owner of the database, db character set.

Installation log is located in the C:\programfiles\sapinst_instdir\SOLMON32\WEBAS

15) Specify the passwords, SAP system administratin and


SAPserviceadministrator SID<ADM>.

SAP system administrator has the privileges to start and stop the system. He is the
administrator for R/3 system.

SAPserviceadministrator is used to run the services required for the instance.

These user id’s are instance specific.

16) Specify the path of the kernel DVD

17) Specify the port numbers

Message Server Port: 3600 + Instance Number

Dispatcher port: 1300 + Instance number

Gateway Port: 3300 + Instance Number

Dispatcher Security Port: 4700 + Instance Number

Gateway security port: 4800 + instance number

These port numbers are entered into etc\services.

18) Specify the location of JAVA DVD – IGS

147
Database Instance Installation:

1) Specify the SID instance number and host name

2) Select whether it is a standard installation or system copy using


migration/Backup/standard export & import.

3) Specify whether we need to install SAP system in the db (or) if the db


exists add another SAP system.

4) Specify the SID and host name

5) Specify the amount of memory required by default it is 40% of


physical memory.

6) Select local installation

7) Specify db kernel file location. It will be the central instance kernel file
location. Because kernel for both R/3 and DB should put together on
one location

8) Specify the server directories and redo log files, archive log files
location.

9) Specify thee kernel dump directory location

10) Specify thee passwords for sysadm and sapservice<SID>.

11) Specify the location of mirror log files A,B and specify thee location of
Origlog A,B and data files (SAP DATA1, SAP DATA2………SAP DATAn)

12) Specify the load strategy (load strategy should be loaded by the data
file). Specify the DB code page. By default it is 1100. No of parallel jobs
can be increased based on the availability of memory by default it is
“3”

13) Specify passwords for system by default it is manager

14) Specify the password for SCHEMA user (SAP P01).

15) Specify the password for DBA user

“F1 “functional key gives help for all options.

“F4”functional key displays list of components

148
Solution Manager is used to create new solutions. “DSWP” is also used to
configure solution landscape.

Roles and Responsibilities:

 Generating installation Keys.

 Monitoring the configured solution through DSWP/Solution Manager.

 Assisted project manager to create project.

 Select he business scenarios.

 Upload the project specific documentation created, satellite system and


read the data from them.

 Create the server, database, systems and logical components.

 Download the roadmap.

 Perform H/W sizing.

 Analyze the sizing results with customer/ H/W vendor.

 Process of CI installation.

 Process of DB installation.

 Install and configure Solution manager.

 Communicate with the customer to prepare the SOW.

 Defined feasibility report of the existing landscape.

 Training to the end users on solution manager.

 Knowledge on ASAP methodology.

149
Client/Server Architecture:

Reuest

Client Server
Response

Client software is required for client system.

Servers are heavily loaded

Response time shoots up

Resources exhaust hour glass occurs

Client
software
Client applicatio server
n server

Database

Client software is out from client

Interpretation is done at middle level

Buffering issued frequently and consistently

Accessing is easier.

150
Applicatio
n Server

Client Server

Applicatio
n server

In a typical client server architecture client request and server responds. The
contents of t client are GUI which is programmed using traditional language like C,
C++ etc…

In order to communicate with DB, database client software should be installed in


each client. As the clients are directly communicating with DB the DB is heavily
loaded. There is no common area where frequently accessed content can be stored.
The response times and the database server resources exhaust and users
encounter “hour glass” situation.

In view of the above the concept of application server came into picture.

The application server handles the load of the client by taking client software from
the clients. The interpretation will be done at application server. Frequently
accessed content are stored in application server which reduces load on the
database. There by increases the performance of the client request.

Application Server has the following:

1) It’s own memory

2) Buffer Areas

3) Application server specific work processes

4) Database client software.

Application server is also called as an “Instance”.

151
R/3 Architecture:

It consists of 3 layers. They are

1. Presentation Layer

2. Application Layer

3. Database Layer

All the above 3 layers are also termed as servers, because they do some work to
serve the clients.

Presentation Server:

It is an SAP GUI where user interacts with SAP system. There are 3 types of SAP GUI.

1. SAP GUI for windows

2. SAP GUI for Java

3. SAP GUI for HTML

SAP GUI has the following features:

Graphical user interface

Change the color, font and font colors of GUI

Support of all languages

One GUI for all the applications (R/3, CRM, BIW, APO…..)

F1 and F4 help (F1- Field Help, F4- List of possible values)

Customized favorites according to user requirements

Frequently keyed IP’s can be stored as parameters

Download compatible higher version can work with older versions

With the help of message server it defines the least loaded server and routes the
request to that particular server.

Installation of SAP GUI:

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

1. 1 to 10 users in personal (remote desktop (or)net meeting)

2. More than 100 users use login script so that GUI can be installed or
updated during the user logon to the system.

3. Install the software on a file server along with installation screen so


that user can perform installation on his own screen so that user can
perform installation on his own

4. Use 3rd party tools like SMS or Software deployment tools

5. Use SAP GUI installation server to install, update user GUI.

153
The above screen shot represents the SAP GUI after installation and configuration.

GUI Operation:

When user clicks on anyone of the options in SAP GUI logon screen one of the
following files will be evaluated.

1. SAPlogon.ini

2. SAPmsg.ini

3. SAProute.ini

4. SAPdoccd.ini

5. SAPrfc.ini

SAPlogon.ini: It consists of SAP logon credentials like description of the server, name
of the application server, SID and instance number. When user clicks this file is
evaluated.

SAPmsg.ini: It consists of the message server details like message server name and
port number. This file is used when logon groups are configured

SAProute.ini: This file is used when users are communicating with servers using
routers (The servers in the network)

SAPdoccd.ini: It is evaluated when SAP library is initialized.

SAPrfc.ini: While communicating with various systems using RFC this file will be
evaluated.

Uninstalling SAP GUI: For uninstalling SAP GUI use” SAP sweep”. Presentation server
is the only GUI.

Application Layer:

Application Server is used to handle the user request, whenever a request comes
from presentation server it is handled by dispatcher of that instance.

DIALOG PROCESS

USER
USER DISPATCHER Q
XXXX

154
The application server will contain the following components:

1. Client server software to communicate with DB

Ex: Oracle Client, Ms SQL prompt …….

2. Buffer Area: The frequently accessed contents from the database need
to be stored in the temporary work area.

This is refereed as R/3 buffer.

Various Buffers are:

1. Calendar buffer

2. Table buffer

3. Program & Definition Buffer

4. DD: Data Dictionary

3. Memory: In order to process the user request memory is allocated for


work process.

4. Interpreter: It interprets user requests by splitting into ABAP codes,


Screens, SQL statements

Dialog Step: User logs onto the system by keying USERID and password. “diag” is
the protocol which connects to the application servers.

DIAG: Dynamic Information Action gateway.

TCP/IP is the basic thing.

Dispatcher receives the user request and checks for free work process. If free work
processes are not available it will be queued in the dispatcher “WAIT QUEUE”.

Dispatcher Wait Queue: When free work processes are available user requests are
served by dispatcher on “FIFO”

Work processes are W0, W1, W2…….Wn.

155
Work processes handle the task of user while handling the task. It sets the memory
allocated and completion of the task.

It contains the following:

ABAP interpreter: It interprets the ABAP code which is containing in the task
handler.

Screen Interpreter: It interprets the screen contained in the task

Task: user request

SQL Interpreter: It interprets the SQL statements of the task.

The work process reaches database but it could not perform any task from the
database, because it it specific to application server.

The work process hands over the task to the “DB SHADOW PROCESS”. “SHADOW
PROCESS” processes the request and hands over the response to work process.

WORK PROCESSES analyzes the response which is in the native format and screens
are designed to respond to the user.

Before sending the response to the user the work process rolls out the user related
information into user context.

USER CONTEXT: It is a temporary memory or temporary work area where user


related buffer area stored. When users login user context is created and it is cleared
when the user logs off.

It consists of logon attributes parameters, the earlier access contents.

ROLL OUT: The process of rolling out of the user related information into USER
CONTEXT.

ROLL IN: The process of rolling the user context information into Work processes
buffers.

First Dialog Steps: The average dialog response time should be between 800-1200
milli seconds.

Second Dialog Step: Create/Modify purchase order

Dispatcher assigns the free work processes to the work process. Work process rolls
in thee user context information and checks whether the user is authorized to
create the Purchase order.

IF authorized the process continues else response back to the user saying that user
doesn’t have authorization.

156
All the Steps are:

1. UR

2. DIAG

3. Dispatcher

4. Queue

5. WP allocation

6. T.H

7. Interpretation

8. Reaches DB

9. Shadows process

10. Response to WP

11. Format the response

12. Roll out

13. User context

14. Response to user

Database Layer: It is used to store the data of the customer. Database has its own
memory, process (Work Process), buffer area……etc.

R/3 work process hands over the request to the shadow process. The SQL
statements are interpreted in the R/3 application servers and converted to native
SQL statements. All the ABAP programs consists of open SQL statements. When the
request sends to the DB they are interpreted into native SQL statements (T-SQL, PL
SQL)

T- SQl : Transactional SQL

PL-SQL: Programming Language SQL

T-SQL and PL/SQL common languages for database-independent applications

Shadow Process: When the user request is added over to the shadow process
shadow process try to find out the request in the user buffer. If it is not available
then it will search in the database.

157
Application Layer:

Application layer consists of various instances with various processes. Instance


provides the following services

1. It has its own memory, own buffer, own work process. One or more
instances can be installed on an application server. Application server
is a physical device. It consists of CPU, memory storage.

2. Instance also can be referred as “Application Server”

3. A group of instances can also referred as application server group of


instances can be installed on an application server each instance can
be configured up to 89 work processes and each work process requires
around 75 MB to 150 MB

4. Each work process need to serve 5 to 10 users

5. Application servers provide the following work processes:

D: dialog WP

V: Update WP

E: Enqueue WP

B: Background WP

S: Spool WP

M: Message server service

G: Gateway Service

158
159
The above 2 screen shots are typical windows MMC. (This sacreen shot is taken
from Netweaver 2004s flavor of SAP)

You can find 3 dialog, 2 update, 1 spool, 2 Background, 1 Enqueue, 1 update, 1


Messaage server and 1 gateway service for this installation.

The number of dialog processes and the number of background processes can be
increased after the installation is completed by using the transaction code RZ10
(Profile Maintenance).

Dialog Work process:

It is the only process where users communicate indirectly. There should be at least
2 dialog work processes for each instance. Dialog process is used to create, update
requests, transactions, print requests and background tasks.

Update Process: It updates the records to the database. There should be at least
one update work process for each R/3 system.

160
Transaction: A transaction consists of one or more dialog steps which will be
committed together or rollback. It is also referred as logical unit of work.

SAP Transaction: SAP transaction is a bundle of one or more transactions which can
be executed together or rolled back. Dialog process updates in temporary tables,
update process reads the temporary tables and updates the database
synchronously. The dialog WP time is restricted to 600 seconds. These all dialog WP
need to complete their task within the maximum runtime. If the task could not be
completed within the specified time timeout error occurs and program will be
terminated.

ENQUEUE Process: Enqueue process is used to provide tasks to the records which
are going to be updated. Technically enqueue process is used to lock and unlock
records which are being updated.

There will be only one enqueue process in any R/3 system and mostly it will reside
on the central instance, where message server is installed.

Note: More than one enqueue process can be configured based on the frequency of
updates.

Background process: The tasks which consumes more time are scheduled in the
Background mode. The jobs which are long running, expensive, time consuming and
non interactive will be scheduled to run in the off peak hours using background
process. Expensive means the ABAP code is expensive or the DB records have more
records. This should be at least one process for each instance.

Message Server: It is used to manage all the instances. That is it controls all the
dispatcher when logon load balance is configured. It also helps to procure logs from
enqueue process if the requests are coming from dialog instance.

There will be only one message server in an R/3 system. Message server always
resides on central instance.

The instance where message server resides is called as central instance.

Enqueue process & message server resides on the same instance and it is not
advised to host them in two different instances as it will increase the enqueue time.

Gateway Process: it is used to communicate between the instances and systems.


Thee will be only one gateway process for each nstance.

Spool Process: it is used to output the documents to printers, fax, email…etc. Spool
process or print request are created by dialog process and background process. The
print requests are stored in the temporary area which are read by spool process to
format and print the request.

We can configure one spool process for each instance.

161
Dialog Instance: we can configure as many work processes as possible but it limits
to 89 per instance. If the load on the instance increases in terms of users we
consider displaying additional dialog instances.

Central Instance: It is a dialog instance where message server and enqueue process
resides.

Database Instance: it is an instance where database is hosted. It resides on the


database layer.

File structure of Application Server:

There is a shared mount (or) shared directory which will be created during
installation.

\\usr\sap

\\usr\sap\trans

\\usr\sap\<SID>\sys\exe\run

Note: the sum of non dialog process should not exceed the sum of dialog process in
the dialog instance.

Central System: This is the installation where the central instance and the database
instance are installed together.

Application Layer

A1
Presentatio CI+DB
n layer A2 Central System
DVEBMGS
Central A3

System A4

Central System

Installation Check:

Start MMC – Check the status of R/3 system.

The status is Green- Installation is proper

The status is Yellow – Network interface problem

162
The status is Grey – Instance is stopped

Starting of SAP system:

On WINDOWS NT use MMC to start and stop the system.

Start up procedure for SAP

WINDOWS:

MMC DEV Send message via name_pipe

sapstart.l START Startup Profile


og
Strdbs.cmd
SAPDEV_00 Read
Alert_Dev.or Msg_server.exe
g (SERVICE)
Disp+work.exe

dev_ms DB(If not


started)

Msg
dev_disp Server Default
Profile
Dispatche
dev_rd Instance
r
Profile

dev_icm Gateway

ICM

dev_w0… WP’S
wn
Connect DB
DATA
BASE

163
During startup of the operating system Windows NT, the NT Service Control
Manager starts all the services in the service list that are configured for automatic
startup.
The information relevant to these services is stored in the registry and is read by
the Service Control Manager during startup.
Several services of type “SAP_” (the SAP service) and “Oracle Service”,but only
one SAPOsCOL service, can be run on one computer.
The SAP service, SAPOsCOL, and OracleService should be configured for
automatic startup.

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

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

To provide a stable startup procedure, a parameter read sequence (also known as


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

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

166
UNIX:

$startsa Send message via name_pipe


p

SAPOSCO Startup Profile


L alert_dev.l
og Strdbs.cmd
Startdb Read
startdb.lo Msg_server.exe
script
g Disp+work.exe

start
Kill.sap
dev_ms

Msg
dev_disp Server Default
Profile
read
Dispatche
dev_rd Instance
r
Profile
Gateway start
dev_icm
ICM

dev_w0… WP’S
wn
Connect DB
DATA
BASE

167
In UNIX operating system the command startsap command id used for starting the
SAP instances. This command will in turn call the SAPOSCOL (If not started). This will
in turn calls the startdb script which will start the database.

Now the sapstart command is executed which reads the startup profile. Then the
message server will be started. Dispatcher (disp+work.exe) will be started which
reads the default profile and the Instance profile. Then the dispatcher will start the
GATEWAY, ICM, and the Work Processes.

There will be different trace files that will be generated while starting the sap
system.

Alert_dev.log: generated when starting the Database.

Startdb.log: Log file for the database start up.

Startsap_ZDVEBMGS00.log: log file for the sap start.

Dev_ms: Message server trace file

Dev_disp: Dispatcher trace file

Dev_rd: Gateway process trace file

Dev_icm: ICM trace file

Dev_w0----Wn: Trace files for the work processes.

In UNIX the commands are used for the starting and stopping of SAP:

To start the DB server:

$ startsap db

To start the sap instance:

$ startsap r3

To start all at a time:

$ start sap all

The following commands are used in Stopping SAP:

To stop sap instance:

$ stopsap r3

168
To stop the database:

$ stopsap db (The script stopdb is executed when this command is


executed)

To stop all with a single command

$ Stopsap db

In Windows or UNIX or Linux or any other operating system before


stopping the SAP check the status for

List of user logged in the system. (SM04, AL08)

List all active processes: SM50, SM66

Send a message through: SM02 or any other third party tool for the
execution.

Brief of SAP startup procedure:

On windows NT use MMC to start and Stop the system

On UNIX use scripts STARTSAP and STOPSAP to start and stop the system.

Sequence of START UP:

First the database is started.

CI is started

Dispatcher will be started

Gateway will be started

ICM will be started

While stopping the system:

Ensure that

Application servers are stopped

CI is stopped

DB server is stopped

169
Users created during the installation:

“<SID>adm” to admin the R/3 system

“SAPservice<SID>” is the user to run SAP services.

These are the two operating system users during operating system installation.

DB users are:

When the ORACLE system is installed SYS & SYSTEM are installed

On a MS-SQL system and USERID is SA

SA-System administrator.

DB users created during DB instance installation:

 SAP<SID>-SCHEMA owner of the database

 OPS$<hostname> SIDADM

 ORASID is the DBA on UNIX platform.

OPS$ Mechanism: This is the mechanism which allows the operating system users
to connect to database without prompting password

Services: These are various services which are created during installation.

1. SAPOSCOL: It is the O/S collector which will collect the H/W information
from the system before starting the instance. If the required resources
are not found this service will not be started. Execute SAPOSCOL at
command level and clear catche. There will be only one SAPOSCOL
service in a machine (SERVER)

2. SAP<SID>_<Instance Number>: It is the service which is required to


start the R/3 instance. If it is not started R/3 will not be started. There
will be one service for each instance.

3. ORACLE TNS LISTNER: This service is required to start DB. There will be
one listener for each DB

4. ORACLE SERVICE SID: This is used to communicate between the DB


instance and other instance. All the above services are displayed in

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

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

Directory Structure: The only directory installed during installation is \usr\sap.

This directory is a shared directory by default, because it needs to communicate


with other systems in the landscape.

Communication means to share the folders across the systems. This is for Windows
NT.

On UNIX SAPinst is created as a soft link pointing to the above directories

171
\\usr\sap\<SID>\sys\exe\run

In future the kernel directory is \exe\UC (or) NUC\i386(or) iA64\

This is the directory where kernel executables are located. Some of the kernel
executables are

Startsap

Stopsap

SAPOSCOL

MSG_server.exe

Dispatcher+Work process (disp+work)

\\usr\sap\<SID>\DVEBMGS<instance number>

It is the instance directory to display the type of instance installed.

For a dialog instance it will be “DO7” like that. Under this which consists fo “logs”
and “traces” of the instance.

\\usr\sap\trans:

This is a directory where transport related information lies.

\\usr\sap\<SID>\sys\profile:

This consist of the properties of instances

Startup Mechanism:

User clicks on strartsap -> saposcol which is already running provides the
information of the system.

Instance service sapM<sid>_<instance number> is started and this service look


into start up profile.

Start up profile is used for starting the sap system. This resides in the directory
\\usr\sap\<SID>\sys\profiles

Start_DVEBMGS<Instance no>_<hostname>.pfl

Ex: Start_DVEBMGS00_indiainternat.pfl

It consists of the following service statements

1. Start DBS command Strdbs.cmd

172
2. Message Server msgserver.exe

3. Disp+work.exe

4. Igsgwrd.exe

5. Icmon.exe

Default Profile: This profile provides default values for all the instances. It provides
details like

Message server host

Enqueue server host

Logon client

Login language

Startup profile of Dialog instance: (Global Profile)

It consists of the following

1. Disp+work.exe

2. Igsgwrd.exe

3. Icmon.exe

Instance Profile: It consists of the following parameters

1. <SID>_D01_<hostname>.pfl  Dialog instance

2. DEV-DVEBMGS00_indiainternat.pfl  Central instance

3. Work process configuration like Types of WP, No of WP…

4. Memory configuration (Role Memory, External Memory)

5. External Areas

Note: The above profiles are maintained in transaction code RZ10, RZ11

The profiles which are changed using RZ10 requires the instance restart.

The profiles which are changed using RZ11 (Dynamic Change to parameters) don’t
require any instance restart.

RZ11 is also used for displaying documentation for profile parameters.

173
Don’t change start up profile unless there are changes in the directory structure.

Note: Default profile parameters are overwritten by instance profile parameters.

System shutdown procedure:

Reasons for shutdown are as follows

• Change parameters

• Up gradation by the support package

• Offline backup

• Migration of H/W or H/W interpretor

• General (UPS, Air Conditioning, Power…)

• Data Center (Exchange, Domain,…)and dependent systems

Process of shutdown:

Define and schedule down time.

Ex: Sunday 1st Jan 2010 6:00 Am to 2nd Jan 2010 5:00 PM

Effective Users: All the R/3 users domain users BIW users…..

Purpose of Downtime: -
_________________________________________________________________

KPR: Key person responsible, Role, contact number

Inform all the users well in advance through notification, email, or through TCODE
SM02.

Problems during SAP startup:

Scenario: We have scheduled downtime for our R/# system to update the O/S
patches and DB patches. If the system could not be started after applying patches
the system has no history of startup problems.

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

2. Check SAP<SID>_00 started (Central Instance started or not)

174
3. Check the DB is stated or not.

8. 1.If the DB is not started check alert<SID>.log in saptrace\background.


It gives all the details fo database directory startup details.

9. 2. If it is not showing any results check LSNRCTL status

10. 3. Check the startdb.log in the work directory


\\usr\sap\<SID>\DVEBMGS00\work

4. Check all the services

5. Check message server log in work directory

6. Check for the dispatcher log

7. Check for the dispatcher log

8. Check for the ports which are blocked or running. Use command
NETSTAT-P

9. Check the environmental variables missing. In that case we need to


configure them manually

Environmental Variables: These provide runtime environment for the users,


as we cannot restrict the installation directories to be specific to one drive. So we
define home directories like HOME_JAVA, ORACE_HOME and define them in the
environmental variables pointing to the directory which they are installed.

Path: Class path is used to define the location of executables to execute from the
command window, irrespective of drive and directory.

Ex: cmd, calc

There are 2 types of environmental variables:

1. User variables which are specific only to the users and it will not affect
the system variables

2. It is specific to the system and use globally by all the users on


WINDOWS NT. Go to MY Computer  Right Click  Properties 
Advanced  Environmental Variables

175
In UNIX:

$ SET JAVA_HOME

$ export JAVA_HOME

$ set display, $ set Oracle_Home

SET command sets the environmental variables only for that user services.

10. Changes in the Parameters: We can change WP configuration,


memory, buffers without any additional resources.

11. Changes in the passwords of service users

12. In compatibility of kernel executables with existing O/S patches and


DB patches

13. Incompatibility of kernel executables with existing O/S kernel and DB


kernel version

176
When the O/S and DB are patched they look for current versions of R/3 executables.
If there is a mismatch with the versions R/3 will not start. In this case we need to
perform kernel upgrade.

Kernel Upgrade: It is a process of replacing the current run directory i.e. R/3
executables are replaced with the new versions of R/3 executables.

Reason for up gradation: While applying the support packages and patches for R/3
system and applying the patches to O/S and DB sap recommends to upade the
kernel to resolve the runtime problems either in the future or during the post
installation.

Process of Kernel Up gradation: Check the kernel version by using disp+work.

Patches: it is the missing functionalities or bugs that arise while running the system.

Up gradation: Group of patches.

Command disp+work

Go to market place www.service.sap.com/swdc

Go to my application components.

Select

Kernel for 32 bit/un (or) nuv/download DB independent [sapexe-----.sar]

Kernel for 32 b it/ uc (or) nuc/ db dependant [sapexe_db----.sar]

Select the newer version than older version

Uncar the files using the command sapcar-xvf

Trace the uncar foles into new run directory (exe\run)

Go to exe new run  copy all the uncar files to new run stop the system and
services copy existing run directory to old run directory copy executables from
new run to run directory [replace]start the services and the system

Note: instead of downloading and upgrading entire kernel we can also upgrade each
lernel executables independently. But we need to check the dependencies.

If we could not find the problem increase the trace level.

Use this parameter to trace the start u activities into work directory. The following
files are trace files which provide more granular information.

Stderror 0

177
Stderror 1

Stderror 2

These provide DB server logs message server logs, dispatcher logs.

Check DEV_DISP, DEV_MS,DEV_W0……DEV_Wn for all the processes. [dev:


developer trace]

Check event viewer application log and system log.

Check syslog in MMC

RCA: Route cause analysis

1. MMC sys log

2. Work directory dev_ms

Dev_disp

Dev_W0….Wn

Startsap.log

startdb

Stderror0

Stderror1

Stderror2

3. Event viewer application system logs

4. Environment variables

5. Network connectivity

6. Check services

7. Check DB logs

8. Check parameter change of DB of R/3

9. Check ports

10. Check password changes

Problems on SAP GUI (or) presentation layer:

178
1. Find the patch level: to find this go to left top corner Click on sap
logon select the file version click in options to activate the GUI
trace level

2. Message server time out

3. “.ini” files are missing: take backup of the ini files and store on a file
server and restore them

4. GUI could not logon: check the other desktops to check the login
problem. Check the network connectivity on desktop. Check the client
number which is accessing. Ask the user to send the status bar. Check
whether the user exists, check caps lock, check password locks.

5. User Complains of incorrect format: check which format he is looking


for and change accordingly

6. Language option: when language other than English is installed them


language characters and new screens are not displayed properly.

7. Check whether the GUI is compatible else upgrade GUI (ex: 4.6c, 4.7d,
6.20, 6.40, 7.10)

8. Functionality missing in the GUI: (Junk characters like -, ?, !, #.....) if the


probles is related to single user uninstall the GUI on the problematic
machine and reinstall GUI. If the problem is generated to all check the
relevant patch and upgrade all the GUI. Else write to SAP so that a
correction note will be released.

9. Check authorizations

10. Use parameters missing: recreate the parameters

Note: Screen Painter is used to design GUI screens. This is done by ABAP team.

SUMMARY:

So far we have seen the following topics for installing SAP system:

1. H/W sizing

2. Solution Manager

3. Pre requisites

4. Installation

179
5. Start up and shut down

Now we are supposed to do the post installation activities to check the installation
consistency and defining the other system settings to make the system readily
available for utilization.

Post installation Activities:

These will include:

1. SICK (SAP installation consistency check)

2. SE06 (Performing the post installation activities)

3. SE03 (System change option)

4. Define the landscape

5. STMS (SAP transport management system

6. RZ10 (Importing the profiles the DB)

7. Client Creation and copies

8. Help installation (SM13)

9. License installation (SLICENSE)

10. Support packages and upgrades

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

As part of this the following activities are configureda dn checked

1. SICK(SAP installation Consistency Check). Check the consistency of the


system by executing transaction SICK and seed for any errors. This cab
done by logging in as SAP* with 000 client and pass word 06071992
(Default). This password can be changed during the installation.

2. SE06: It is used for performing the post installaion activities. SE06 has 2
options:

1. Perform installtion activities (Post installtion activities)

180
2. DB configuration ( this is used to set the change the trapsport sustem
or correctin transport sustem)

SE06 enables the CTS (change transport suystem or correction transport)

3. SE03: click on the system change option in SE06. This option is used for
setting the system change option i.e either to modifiable or
notmodifiable. If the system is set to modifiable then the software
component s can be modifiable. This option is se set only to
Development and Sand Box systems.

If the system is set to not modifiable all the software component are
not allowed to change. This options is only set for Quality and
Production systems

4. Configuring the Transport management system:

SAP system landscape:

It defines the flow of objects between the systems. Inorder to


achieve the high xonsistency and stability SAP recimmends t use
more than one system in the landscape.

Single System landscape: In this only one system will be there for
the entire landscape which is used for all the
purposes(Development, Qualtity and Production)

Single System
Landscape

Production

Quality

Development

181
Disadvantages: The objects which are used by developers will not
be allowed to eited by the tester and production users. The system
is not consistent either for development quality pr production. No
production for single system.

Ex: It is used to setup demo, desk and training systems.

It is a resource minimized setup.

Two System landscape: it is the least recommended landscape by


SAP where developers and quality activities are performed in one
box and production activities are carried out in another box.
Production server is consistent but inconsistency between quality
and development.

Two System landscape

Developme Productio
nt and n
Quality

Three System Landscape:

Three System Landscape

Developm Quality Production


ent
182
This is the optimized landscape recommened by SAP where development, quality
and production actions are carried out in individual systems (or) boxes.

Development System: This system is used to develop the objects and customizing
activities are carried out. This system is usedd by functional consuoltants, ABAP
development team and BASIS team. No end user and production user can logon to
the system.

Quality system: The objects whch are modified (or) customized in DEV system will
be tested in this system. This system is utilized by the qulaity team, training team
and BASIS consultants.

Production System: The objects which are development modified customized in


development boxx (or) system are transported to quality and qullity approved
objects are moved to production system. The system is only allowed for end user.
The restricted actions can be given to ABAP and functional tools. Each user created
in the system are accountable for license.

Note: For each system we can configre upto 8 systems in the landscape.

8 different systems in a typical landscape are:

1. Pre production

2. Pay roll

3. Migration

4. Sand box

5. Development

6. Quality

7. Production

8. Training

Transport domain controller: As part of post installation activity (TDC) transport


domain controller needs to be configured on a high availability system. As this is
only one system I the landscape we will configure development system as TDC. TDC
manages all the systems in the landscape.

183
Configuring TDC:

1. Logon to 000 client

2. Goto transaction STMS (SAP transport management system)

3. If STMS is not configured within a domain then a pop up box will be


displayed to configure the domain. If the STMS is already configured
POP UP BOX will be displayed to create another domain (or) oncluding
the domain.

4. Specif the name of the domain

5. Specify the description and save

6. Domian controller is created

Defining landscape: As we don’t have quality and production system in the


landscape we need to define them as virtual systems.

Defining the virtual system:The systems which are going to be deployed in future
can be configured as virtual systems. Virtual systes name should be exactly the
same as of the real time systems.

Including the systems in the domain:

1. Delete the virtual system

2. Logon to the real system which is replacing real virtual sstems. (Logon
as client 000)

3. Go to transaction “STMS” POP UP BOX will be displayed. Select “include


in the domain” specify domain name in the domain sytem

4. A request for inclusion is sent to TDC

5. Logon to the TDC goto STMS selecty systems there will be a


system waiting for approval

6. Select the system and approve. Ti si included in the domain

Note: A communication user TMSADM will be created and RFC destinaltion between
the TDC and member system is established.

Domain.cfg is updated

Domain.cfg is stored in \ \usr\sap\trans\bin

184
It consists of domain settings lie details of TDC and members. It is updated
whenever there is achange in the landscape.

Transport Group: The group of systems which share the same transort directory are
said to be in one group.

Transport Layer: It is a path defined to transport the objects. SAP transport layer is
by default . The name of it is trapsport layer.

Transport Routes: Transport routes define the flow of objects between systems.
There are two types of routes. They are

1. Consolidation Route: The route between development and quality


systems is called as consolidation system

2. Delivery Routes: It is the route between quality and production systems

Development system is also called as Integration sytem

Quality system is also called as Consolidation system

Production system is also called as Delivery system

Defining the Transport Groups:

Log in to TDC in client 000 Go to STMS Select transport groups

We have the option of defining the routes in 2 ways.

1. Graphical Editor

2. Text Editor

Select the type of the landscape(Single, Two or three sytem landscape)

Specify the systems in the landscape sav and activate and distribute the
configuration.

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

6. Install License: In order to install the license we need to obtain license


key from SAP market place.

7. Inputs required to get the license key are

1. Customer Number

185
2. Installatio Number

3. Host Name

4. SID

5. Instnace number

6. H/W Key

In order to get the H/W key goto transaction SLICENSE (or) at command level
saplicense –get

Get the key from market place and install using slicense transaction. Initial license
is valid for 30 days and when license is installed the expiry date DD:MM:YYYY

8. Install Library: Goto SR13  specify the tyoe of HELP (HTML help file,
HTML, HTTP< Dynamic Help). The library can be installed on a file
server or on a web server. Go to SR13  define language  define
variant (IWB.Help, Documentation)

Repository Objects: The objects which are shifted by SAP are called as Repository
Objects. These are also called as “SAP standard objects”.

9. Client Creation and Copy:

Client: Client is an independent business entity which represents an organization in


SAP R/3 system. Client is represented by field MANDT. It is used as a data seperator
i.e. the user will be displayed the data belonging to the client logged on.

By default there are three clients 000, 001 and 066

Client 000: It is a template client which consists of all the configurations like
company code, cost center, project center, sales, purchase etc. It is continuously
updated by applying the support packages, patches etc… It is the most updated
client. But it is not allowed for any customizing and it is eligible for client copy to
set up our company.

Client 001: It is a backup of 000 client. But it is not updated continuously. There is a
variation between 000 and 0001 i.e. 0001 is not updated continuously. No 001 for
7.0 version.

Client 066: It is an early watch alert client used by SAP to generate early watch alert
report to the customer.

In client 066 the report serve as recommendation to fine tune the system interms of
expensive reports, transactions, SQL statements and users.

186
Need for client copy: In order to adapt SAP systme to the requirements of the
customer we need to perform customizing. But customizing is not performed in 000
client as it is a template client and client 001 is a back up client. In order to perform
customizing we need to define our own client. When the client is defined it doesn’t
consists any data, so we need to copy data from the existing clients. Client 000 is
eligible for client copy because it is continuously updated.

Client dependant data/ client soecific data: The data which is visible only in that
client is called as client specific data. Ex: User master Data, Application data,
Customizing Data

1. The Purchase Orders whicha re created in a client are not visible in


another client.

2. The users which are created in one client cannot login to another client.

3. The application like invoices, delivery notesa are client specific i.e. if
you perform customizing in one client it is not visiblw in another client.

Note: The customizing which is performed in one clietn won’t effect the other
clietns.

Client independent data/ cros client data: The data which is visible across all the
cliet is called as cross client data (or) client independent data.

Ex: Calanders, Measurements, Time Zones, Timings, Currency.

If we perform customizing to the above it will be effective in all the clients.

CCC: (Cross Client Customizing): The above one is known as cross client
customizing.

Repository Data:All the SAP standard objects are referred as repository objects
(reports, Functional Modules, Programs, Transactions) etc…

The changes t repository data will effect the entire R/3 system. Some times it
may mall function and the system will be crashed. Because of applying chages,
patches etc.

Note: While changing the repository objects follow SAP recommendations and
most of “Repository Objects” are locked for editing. If there is a need to modify
the repository objects we need to obtain key from SAP.

Customizing: It is the process of keying entries to the templates.

Ex: Company name and address entries, sales organizations, employee datga
applications such as material master data, vendor master data, customer master
data.

187
Customizing is performed in “SPRO”.

User Exits/ Customer Enhancements: These provide an additional functionality to


the existing structure (SAP objects). There are variou types of exits.

1. Field Objets

2. Menu Exits

3. Screen Exits

4. Functional module exits

Exits are identified in transaction” SMOD” and exits are created in “CMOD”

CMOD: Create modification

SMOD: Search Modification

Applying the Support Packages and Patches: I order to fix the bugs (or) to have
the enhance functionality support packages, patches are applied from time to
time. SPAM is the tcode for applying the support packages.

Development: These activities are carried out by ABAP development team. In


order to develop our own programs SAP restricts to develop n th ename space”
Y” and “Z”. The developers who are working in the object needs to be registered
I the market place an obtain a developer key.

Programs a dn reports are dedveloped I SE38

Transactions are developed in SE93

Screen are developed in SE51

Menu’s are created in SE41

Forms are created in SE71

Functional Modules in SE37

Repository objects like classes packages are created in SE80

These activities are purely done by the ABAP team.

Changing the SAP Standard objects: In order to modify SAP standard objects we
need to obtain object access keys from market place. These are also referred as
SSCR.

SSCR: SAP software change registration

188
In order to modify the repository objects we need to get the following

1. Developer Key

2. SSCR key

Client Creation: Clients are created based on the following requirements as a post
installation activity to set up demo, testing, tracing, production, quality clients.
(SE06, SE16, SM30, SE03)

Set up a client simulating production client. Client is created in SCC4. In order to


create client we need to specify the following inputs.

1. Client number (Variable in between 000 to 999. Bu it should be used


from the SAP reserver numbers. It should be unique in the system.

2. Specify the client number

3. Describe the client

4. Currency of the client

5. Location of the client

6. Roll of the client (Demo, Customizing, Testing, Production…)

7. Specify client specific customizing is allowed or not

8. Specify cross client customizing and repository chanes are allowed or


not

9. Protection level 0, 1, 2

10. ecatt is allowed or not.

By default from 000 999 total 1000 clients can be created.

Logical System: In order to distinguish between various clients of different systems


logical systems are defined and assigned to clients.

Defining Logical System:

Go to SALE Tcode (SALE: SAP Application linking and Enabling) Click on sending &
Receiving system for further information click on  logical system click on
define logical system logical system click on define the logical system click on
new entry.

189
Specify the name of the logical system. The naming conventions for logical system
are <SID>CLNT<CLINTNO>

Ex: DEVCLNT200, QASCLNT200, PRDCLNT200 (Upper Case letters)

Client Role: SAP defines client role to be specify the functionality of the client.

1. SAND BOX: It is a play ground where functional consultants will customize


the requirements of the customers. It is represented as “SAND”. The
changes which are performed in the system are not carry forwarded. This
client is allowed for only client specific customizing.

2. Customizing Client: It is represented by CUST. It is also called as Master


Client, Golden Client. This is the only client where client carry forwarded.
This is the only client where changes are initiated and carried forward.
This is the only client where client specific cross client and repository
objects are modified.

Note: Other than this client no clients are allowed to modify objects.

3. Testing Client: It is represented by TEST. This client is used for testing the
customization which is performed in cust client. Transactions SCC1 is used
to copy the change request from CUST client.

Note: SCC1 is used to copy transport requests between the clients within
the system. This client is used to test the modules which are customized
and if the consultants approves it will be released.

4. Quality Testing Client: It is represented by QTST. This client is used to test


integration between modules cross client object test and repository object
test. It is also assured that all the objects are tested for quality stress
etc… Testing tools are deployed to test the objects in this client.

Note: Each of the objects need an approval to move into production.

5. Training Client: It is represented by TRNG. It is used to train the end users


of the company

Note: Changes to ATST and TRNG are made by using transport request

6. Production Client: It is represented by PRD. This is the only client where


the company data is populated by end users and production operations
are carried out. Most critical client and to be secured in the landscape.
Most critical client sensitive info (financial, pay roll, client) data
migration.pre production client can be created additionally based on
customer requirements.

Change options available for clients (Client Specific Settings):

190
Recording: It means saving the changes to a change request.

1. Automatic Recording of Changes: The changes which are performed in this


client are automatically recorded to a change request.

2. No Changes allowed: changes are not allowed in this client.

3. Change without Automatic Recording: Changes will not be recorded to


change request.

4. Changes without automatic recording, no transport allowed: Changes without


automatic recording to change request and changes cannot be transported.

Cross-Client Object changes: Changes to repository and cross client customizing


allowed: The changes are allowed in CUAT client (or) master client (or) Golden
Client.

Protection Level: 0: No Restrictions. Client is allowed for client copy and client
comparison is allowed. Client can be overwritten.

Protection Level 1: No overwriting by client copy

Protection Level 2: It is neither allowed for a client copy not for comparison between
two clients.

eCATT & CATT allowed:

Restriction: The client should be always protected against upgrade unless we


perform an upgrade

Note: When the client is created an entry in table T000 is created without any data.
We can logon to the client using USERID: SAP* and Password: pass in that particular
client for client copy.

Client Copy: There are 3 types of client copies:

1. Local Client Copy

2. Remote Client Copy

3. Client import and Export

Pre Requisites of Client Copy:

1. Users should be working in the source client, reserve at least 2 background


processes for client copy. Dialog process can also be used.

2. Logical system name should be defined and assigned to a client

191
3. There should be enough space in the DB (Table Space and enough disk
space)

4. RFC connection should be defined between two clients to perform “Remote


Client Copy”

5. Enough space should be there in “Trans Directory” to perform client transport

6. The sized of the client can be determined by using report “RSSPACECHECK”

7. Select the profile determine the type of the data to be copied from source
client to target client.

8. Ensure that source and target clients are of in same versions in terms of O/S,
DB, R/3.

Note: BD48: Changing the logical system name

Note: Size of the table can be determined using the reports RSTABLESIZE and
RSSPACECHECK. These reports can be executed in SA38 T-Code

Local Client Copy:

Go to SCCL (SCCL is the tcode used for local client copy)

Before client copy we have to create the client. This can be done using the table
SCC4.

Go to SCC4 from which we can create an entry in the table “T000” (List if clients
present in the system). Make entry for the client number, description, logical
system name, application server… and click on save. This will create the client entry
i.e. client without any data in it.

Now Logon to the “Target Client” go to SCCL  select the profile

Profile: It defined the type of data to be copied from the source client. We should
use SAP defined profiles that starts with “SAP”. (Ex: SAP_APPL)

Note: repository objects will not be copied during the client copy (Local or remote)

Select the source client from which the copy has to be performed.

By selecting the “Test Run” we can perform a resource check. Simulation reads the
extra data andif there are any problems with DB like space, and then simulation
terminated the copy.

Go to SCC3 for detailed log of the client copy.

192
Remote Client Copy:

It is performed in transaction scc9.

Select the profilego to profile select the source destination

 Repository objects can be copied

 Client specific data is copied

RFC connections are defined in SM59.

 specify the system name

 Specify the host name

 Schedule it in the Background mode (or) dialog mode

 Perform a test run for simulation

Then select RFC

RCC (RFC) is between 2 systems

LCC is between 2 clients

Client Export and Import:

When there is a necessity to copy a client from one landscape to another landscape
client then we will use the export and import of the client.

Client Transport is performed in 2 steps:

1. Client Export

2. Client Import

It is performed in SCC8. Client won’t be copied into DB in turn it will be copied into
transport directory in terms of “Control Files and Data Files”.

Select the profile to define the type of data to be copied or exported.

Specify the name of the target system and run it in the background mode.

Note: Ensure that transport directory have enough space to host the data files and
command files.

Copy of the co files and data files to the target system and execute the following
commands to import the data into the client or we can use STMS to import the
client data.

193
Copy the command files and data files into the target system.

tpaddtobuffer <tr> <SID> <CLNT> pf=\usr\sap\trans\bin\tp_domain_<SID>.pfl

tpimport<TR><SID><CLNT> pf=\usr\sap\trans\bin\tp_domain_<SID>.pfl

tpactive buffer: It is used to add the contents to the target system in order to import
any change request. It should be added to the buffer of the target system. During
the normal transportation the object follow the transport routes and automatically
added to the buffer of the target system. It is also one of the reasons for creating
virtual system.

Note: In 2 system landscape only consolidated route is there no delivery route.

Go to STMSGo to Import select the system go to extras add transport


request to import pool select the transport request click on semi loaded truck to
import the request

Post Processing of client transport:

Go to Scc7 select the transport request select the profile name specify the
export system <SID> schedule as a background process.

Customizing and Development:

While performing post installation activities the clients are created and populated
with 000 template. Create users and assign them complete authorization to
configure the system according to the requirements document.

Customizing: It is a process of adapting the system according to the requirements


without changing SAP standards. It is a process by keying entries into the templates
or tables.

Ex: Setting of sales organizations, company code, sales areas, plant storage
locations, cost centers, profit centers etc.

Whenever a change is initiated in the client which is set to automatic recording of


changes a change request will be generated or changes will be added to the
existing change request.

Common Transport Directory


194
SAND TEST CUST QTST Trng Pre Payroll PRD

400 300 400 300 900


200 200

Note: Client copy always rewrites the target system. There is no method for client
merging. If there are 1000 users in client 300 and there are 500 users in client 200.
If the users in client 200 are to be copied to client 300 then all the 1000 users n
client 300 are overwritten by client 200 users. So now there will be only 500 users
in client 300.

Authentication Authorization

USER and PASSWORD What needs to be accessed and what not


TIN: Tax Identification Number to be accessed. (Permissions to users)

Change Request: Whenever a change is initiated in the client which is set to


automatic recording and change a change request will be assigned to the changes
(or) a change request will be prompted to the changes.

No Changes Allowed  Production client

Automatic Recording of Changes Customizing client

Changes without recording SAND, TEST

Changes without recording TEST, QTST, TRNG

No Transports are allowed

Change request s created by project manager, project leader.

Each change request created consists of one or more tasks which are in turn
assigned to developers, functional consultants.

Change requests are created in SE01. Change request can be copied from one client
to another client using SCC1.

195
Change Request Mechanism:

 Change request is created by project leader. Project leader defines tasks


under a change request and assign it to developers (or) functional
consultants

 Change Request naming convention will be like:

<SID>K900001

<SID>KA00001

 Tasks follow the same naming convention. All the tasks are located by
developers (or) consultants I.e. the objects which are being assigned activity
is completed the developers/consultants will release the task. If the task is
released the objects can be used by other people (or) other team members.

 Change request numbers are stored in table E070

 Tasks follow the same naming convention. All the tasks are located by
developers (or) consultants i.e. the objects which are being created /
modified are locked to that user. Once the assigned activity is completed, the
developers / consultants will release the task. If the task is released the
objects can be used by other people (or) other team members.

 Change request numbers are stored in table E070.

 If one of the tasks is locked y the user and left then change the owner of the
tasks based on the approval (or) instruction. Release the task as
administrator.

 A change request has many tasks and each task is assigned to one developer
and the developer locks the table.

 Tasks are released by developers/ consultants in SE01.

 Once all the tasks are released the change request can be released by the
project leader.

Types of Change Requests:

1. Customizing Change Requests: This change request is to save the changes


related to client specific settings i.e. changes are related to a particular
client. These changes needs to be imported subsequently into all the clients
in the landscape.

Ex: User master data, Sales Area, Company Code, Sales organization,
Application Data and Customizing Data.

196
2. Development: When the customizing does not fulfill the user requirements
we need to perform development. Development involves creation of tables,
files, reports, programs etc.

Field: It is nothing but a column in the table. In SAP table fields are created as
domains and data elements.

Domain: It defines the technical characteristics of a field or as

1. Type of field (whether it is num, int , char..)

2. The length of the field.

Domain helps us to keep the relative fields consistent throughout the system.

Data Element: Data element is defined in the table pointing to a domain in


precise meaningful name to the domain.

Table: Table consists of columns and rows. Columns contain the name of the
data elements and rows contains the data.

There are 3 types of tables.

1. Transparent Tables

2. Pool table

3. Cluster Table

Transparent Table: These represent 1:1 [ABAP dictionary to oracle] to DB. If


there is one table in DDIC then there will be one table in DB.

Pool Table: A group of related tables pooled into a larger table.

Cluster Table: Group of tables clustered together.

 Tables, Data Elements, and domains are create in transaction SE12.

SE System Engineering.

They should be created in the namespace of Y and Z only.

 Screens: Screens are created in transaction SE51

 MENU: Menus are defined in SE41

 Programs: Programs to read the contents of the screen and consider


the activities of the menu. SE38 is the T-Code used to create, modify
display the programs.

197
 In order to define the programs to take the runtime values and
calculate the values functional modules are defined. Functional
modules provide reusability of functions. These are defined in SE37.

 In order to execute the programs use transaction SA38.

 As it is very hard to remember the programs names, the programs are


assigned to transactions. Transactions are created in SE93.

Note: Transactions are stored in table TSTC.

Cross Client Customizing: The customizing related to the entire system such as
currency settings, time zones, calendars etc. These are specific to the entire
system. All the above changes need to be imported only once on the target system
irrespective of number of clients.

Work bench Change Request: The changes related to work bench [development,
cross client customizing] are saved to change request of type work bench.

Transport of copies: In order to transport a table definition or table content,


transport of copies is used.

Ex: When we want to retain client settings such as user master data during a client
refresh. User master record is saved as transport of copies and imported after a
client refresh. Identify the table to be included as transport of copies save it, release
the change request. It is exported to TRANS directories. It can be imported into the
client again to get the table entries back.

Relocation of objects: The objects can be moved from one system to another
system with development class (or) without development class.

Change Request Mechanism: The objects can’t be copied from one system to
another system using traditional means because it is difficult to identify what
objects are changed and where they are located. That is the reason whenever there
is any change it is recorded to change request. Change request consists of the
change made to the object.

Change Request Release: When the tasks are released in as change request the
change request is eligible for release. The change request can be released to
another change request.

When a change request is released the changes from the objects are bundled into
data files.

When a change request is released transport protocol tp records the change


requests and copy the relevant changes into a data file and move this file into

198
transport directory. The data files also have control files and these files are copied
to co files.

Data Files: It consists of the changes to the objects. It starts with naming convention
as follows.

<SID>R900009 “R” denoted data file.

Ex: DEVR00009

Command Files: Co files It stores the commands to be created while importing the
change request. Its naming conventions is derived from change request no
DEVK900009.

There will be exactly one command file for one data file.

SAP Names: When the change request is released the name of the developers and
the change request number is populated into this directory.

Log: It will store the logs of export and import.

Buffer Directory: When a change request is released based on the routes definition
it will be added to the import buffers of the target system. If the routes are not
defined we need to explicitly add change requests to the buffer using command
“tpaddtobuffer”. That is the reason we will configure the landscape.

Development Class: It is a group of objects such as reports, function modules,


programs, transactions etc. Development classes are defined in transaction SE80.
While defining a development class we need to assign it to a transport layer.
Development class is required to develop the objects. While developing objects
such as reports programs, functional modules etc we need to assign them to a
development class. Development class should start with either “Y” or “Z”. The
objects which are assigned to $tmp class are saved as local objects and cannot be
transported. That is the reason we need to define a valid development class and
assign them while developing objects.
TASKS

Change Transport

DEV Class Transport


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

199
Importing a Change request:

The change requests which are released are stored in trans directory in the form of
data files and co files. These are available for import into systems in the landscape
based on buffer entries. If there are no buffer entries we need to add manually
using command tpaddtobuffer.

Change request once released are called as transport request. Transport requests
are imported using STMS.

Importing a transport Request:

Go to STMS Select import Queue of the selected system select the transport
request request can be imported as a single, mass or a group of change requests.

Change requests can be triggered immediately (or) at a later time.

Disabling the folly loaded truck:

Go to STMS click on the systems select the system go to transport tool


change insert row No_Transport_ALL save it.

SE38, SE41, SE71 SE80


Programs, Functional Developm Transport Transport
Module, Reports, ent Class Layer Route
Transactions

1 Development WB Request Data Files

Co Files
C.C.C E070
Released Buffer

TASKS DEV/ Functional Consultants SAP


Names
2
C.B.Customizing CUST EPS
Request
BIN
3
TMP
Transport of Select the SAV Releas
Copies object LOGS
Table Structure

Table Content

200
Manual tp:

tp can be called from command line by using executable tp.IN order to execute tp
path to kernel directory has t be set in the environment variables.

Tp version is displayed using command tp. Type tp help to find out the various
options of tp

C:\> tp help

tpaddtobuffer will add a request to the buffer

tpcleanbuffer cleans the buffer

tpdelete from buffer deletefrom buffer

C:\>tpaddtobuffer

tp return code: 0,4,8

“o” Transport request import is successful

“4” Transport request is successful with warning

“8 and above” Errors

Import Errors:

1. Tp error 212 could not connect to DB

The objects which are imported into target system could not over write
because the ojects are locked.

Imports cannot be reverted back. If we want to revert back develop another


change request release it and import it into the system.

2. STMS is not configuredTp version is outdated. [Upgrade tp version]

3. In order to check tp connectivity execute command R3trans-d which


generates trans.log in the current directory.

Trans.log gives codes and the error description

4. RDD*JOBS could not be executed due to lack of background resources.


Check background jobs in SM37

201
tp import mechanism:

When a transport request is imported

 tp is initiated and reads the contents from trans directory and connects to the
database

 tp calls R3trans [R3trans is an executable which performs the transport] to


execute the import task, to connect to DB

 tp documents all the import steps in tables “TRBAT” and “TRJOB”

 tp also triggers RDD* Jobs.

RDD * Jobs
RDDIMPDP

RDDNEWPDP, RDDMSQL

TRBAT, TRJOB

Documentation tables
tp

R3trans

RDD* Jobs reads all the steps from tables and executes them.

MTP (Move to Protection):

In order to move the transport request t production system we need to schedule


down time. The changes which are approved in the quality system are available to
move into production. In order to avoid inconsistency between objects these are
moved during off peak hours. In major enterprise where there are huge transports,
transport strategy is defined like transports will be moved on every Sunday, first
week and the last week of the month.

During MTP we need to define the escalation table.

1. Valid backup is required to restore incase of problems during transport.

2. Identify the people (Consultants, developer ..)

3. Key persons responsible and assign tasks.

4. Lock all the users except the ID to be involved in transportation

202
5. Perform transportation of objects

6. Release key business users to test the functionality. If the functionality


works fine, release other users else revert back with alternatives.

SAND TEST CUST Optional TRNG QTST


PRD
400 300 400 300 900
200 200
C.C.C

C.C.C C.C.C
Repository
Repository Repository

DEV QAS PRD

1. Customizing Consolidation Route Delivery Route

2. Development

Three system Landscape.

QAS: In QAS objects are imported tested for quality integration testing. Imports are
also performed subsequently in training client and other optional clients. Testing
tools are deployed to test the load on the objects. Simulation of users to check the
performance of the objects is performed. If the objects are approved in terms of
quality [integration, stress and performance] the approving officers will document a
list of transport request along with scheduled date of release and time, into the
production system. Training for the users is common in the training client.

Next move to production (MTP) is carried out.

Note: No transports will be moved without approval.

Preliminary Imports: These are emergency transport request which are moved
independently without following MTP. Preliminary imports will remain in the queue
even after the transport. This transport is again transported during MTP. Approval is
required to perform a preliminary import.

Current Settings (customizing): Even though system is set to not modifiable and
client customizing doesn’t allow any changes. In a production system we can
change some of the entries like tax, currency information transactions. These

203
changes are carried out on the production system by authorized consultants without
any change request.

Support Packages and Patches: During the implementation (or) post production
support whenever there is a gap in functionality (or) functional consultants request
for enhanced functionality support packages are applied. There are various types of
support packages and each support package has it’s own released life cycle.
Support packages should be applied in the sequence.

Pre Requisites to apply support packages:

a. Always apply the support packages in client 000 using user like DDIC.

b. Apply the support packages in the sequence of landscape [First in DEV,


next in QAS and finally in PRD]

c. Apply the support packages in the following order SAP_BASIS,


SAP_ABAP, SAP_APPL, SAP_HR

d. Always apply the support packages in the sequence such as 1,2 3, 4….

Ex: SAPKB64001, SAPKB64002…

Download the support package queue i.e. a group of non conflict


packages can be applied together.

Ex: 1 & 2 can go together

SAPKB64001 SAPKB64003 SAPKB64004

SAPKB64002 SAPKB64005

Note: Known problems related to support packages file can be


downloaded from the service market place before applying the
changes to the system.

e. Download the recent notes with search criteria “known problems


related to support packages of version XXX

f. SPAM and SAINT versions should be updated. SPAM and SAINT have
their own versions. SAINT SAP add on installation tool. SPAM
Support package manager. These tools are used to apply support
packages and add on installable’s.

g. There should be enough space in the TRANS/EPS directory. EPS


Electronic parcel service. EPS hosts all the support packages

h. There should not be any aborted packages.

204
i. Developers and functional consultants should be around to handle the
change with support packages.

j. SPDD and SPAU are the places where data dictionary (DDIC) and
repository chages are made.

k. There should be enough space in the DB

l. If the support packages are less than 10 MB apply through


presentation server and if it is greater than 10 MB apply through
application server.

m. There should be at least two background processes to apply the


support packages.

n. Ensure that STMS is configured

o. Users should be locked and this should be performed in off peak hours

p. Ensure that valid backup is available

Upgrading the SPAM/SAINT version:

1. GO to SPAM support package manager 620/ 0022

2. Go to SAINT SAP add on installation tool 6.20/0022

3. 6.20 is the ABAP version 0022 is the SPAM & SAINT

4. Go to SAP market place www.service.sap.com/swdc

5. Go to support packages & patches Select SPAM & SAINT versions

6. Download the SPAM latest version and SAINT latest version into your desktop.

7. Go to Support Packages Load package from front end  specify the path of
the download file .car and .sar (Sap Archive)

8. Select the downloaded file. It will load into the system.

Note: The package is only loaded but not applied.

9. Now go to support package select import SPAM objects

10.SPAM and SAINT can be applied in arbitrary order.

Applying Support Packages:

Logon to client 000 using user like DDIC.

205
Download the support packages from market place.

The available options are: SAP_BASIS, SAP_APPL, SAP_HR, SAP_ ABAP…..

If the support package is less than 10 MB size apply through front end.

Load package through front end.

Note: If the network connectivity is slow (or) if the support package is more than 10
MB of size then always use application server.

Load the support packages. It reduces the time from presentation server to
application server.

How to apply from application server:

Download the .car/.sar files from the market place into trans directory.
Trans\eps\in.

Use command

sapcar –xvf SAPKB62026.car (or)

sapcar –xvf SAPKB62026.sar

Note: Earlier the command was only sapcar

The file will be uncompressed into the directory \usr\sap\trans\eps\in

The files that we will get are .ATT and .PAT

ATT: Attribute file

PAT: Patch file

Select the new support package and display. New support packages which are
loaded are displayed.

Select the support packages to import.

In order o select the support packaged define the queue.

For defining the queue click on display queue and click on define

Select the support component for which the support packages have to be applied.

Queue is displayed select a single packages or a group of packages based on the


composite note recommendation.

Go to support package and import.

206
Click on import queue to import the support packages.

Note: The support packages once applied cannot be reverted back. Before applying
the support packages check all the requirements are fulfilled.

Problems occurred during applying the support packages:

1. Conflict patches are grouped together

2. There are aborted packages

3. SPAM and SAINT are not updated

4. eps\in directory has not enough space.

5. DB table space out of space (or) table space over flow with errors ORA_1653,
ORA_1654

6. DB max extends reached with error ORA_1631 and ORA_1`632

7. There are no enough background processes available.

8. Extended memory is not enough to import the support package

9. tp and R3trans are out dated (We come to know about this when the screen
cannot move)

10.Ensure that outdated are not locked by the users

11.Data dictionary activation errors

12.Conflict with the add-on’s

13.tp could not connect to the database (Execute R3trans –d)

Note: Tables used are PAT01, PAT02. Do not delete entries from these tables unless
there is a SAP recommendation.

14.Check the status of the support packages imports in SPAM. Click on import
logs. Logs can also be displayed in trans\log

15.Support packages can be re imported from the point where it terminates.

SPDD Phase: It is used to update the DDIC elements

While applying the support packages it will prompt you to run SPDD. It is decided by
functional consultants to keep the existing changes to adapt the new changes which
come with new support packages. Do not run SPDD without the concern of
development team.

207
SPAU Phase: It is similar to SPDD, but it is related to repository objects.

CRI: Conflicts resolution transports. These are released by SAP to resolve the
conflicts between SAP support packages and add-on’s.

The following are the phases that include the support package implementation.

The Support Package Manager informs you of the status of the phase currently being
executed in the status bar. If you want to know which phases are executed for which
scenario (test or standard scenario), run the program RSSPAM10.
The following list provides an overview of all the modules and phases and lists them in the
order in which they are executed by the Support Package Manager:

Preparation Module
...

1. PROLOGUE
This phase checks whether you are authorized to import Support Packages.
2. CHECK_REQUIREMENTS
This phase checks various requirements for importing a Support Package, for example,
whether the transport control program tp can log on to your system.
3. DISASSEMBLE
This phase unpacks files from the appropriate EPS parcels and saves them to the
transport directory.
4. ADD_TO_BUFFER
This phase places the queue in the transport buffer of your system.
5. MODIFY_BUFFER
This phase prepares the transport buffer for correct processing of the following import
phases.
6. TEST_IMPORT
This phase performs a test import for the queue with the transport control program tp.
The system checks whether there are objects that are in open repairs and that are
overwritten during the import, or whether other conditions prevent the import of an
object.
7. IMPORT_OBJECT_LIST
This phase imports the object lists for the Support Packages in the queue into the
system.
8. OBJECTS_LOCKED_?
This phase checks whether there are objects that are overwritten by the import, and
that are still in unreleased requests.
9. ADDON_CONFLICTS_?
This phase checks whether there are conflicts between objects in the queue and any
installed add-ons.
10. SCHEDULE_RDDIMPDP
This phase schedules the transport daemon (program RDDIMPDP).
Import 1 Module
11. CREATE_VERS_BEFORE
This phase generates versions of the objects that are contained in the Support
Packages in the queue (if this option is set).

208
12. SPDD_SPAU_CHECK
In this phase, the system checks if a modification adjustment is necessary
(transactions SPDD/SPAU).
13. DDIC_IMPORT
This phase imports all ABAP Dictionary objects in the queue.
14. AUTO_MOD_SPDD
This phase checks whether all modifications to ABAP Dictionary objects can be
adjusted automatically.
15. RUN_SPDD_?
In this phase, you are asked to adjust your modifications to the ABAP Dictionary
objects by calling transaction SPDD.
16. LOCK_EU (only for import mode downtime-minimized)
This phase locks the development environment.
17. INACTIVE_IMPORT (only for import mode downtime-minimized)
This phase imports program code and program texts in an inactive state.
18. DDIC_ACTIVATION
This phase activates the imported ABAP Dictionary objects.
Import 2 Module
19. IMPORT_PROPER
This phase imports all the Repository objects and table entries if they were not already
imported in the INACTIVE_IMPORT phase. This is preceded by actions such as table
conversion and activation of the name tabs.
20. PREPARE_XPRA
This phase prepares the execution of the XPRAs and after-import methods.
21. UNLOCK_EU (only for import mode downtime-minimized)
This phase unlocks the development environment.
22. AUTO_MOD_SPAU
This phase checks whether modifications can be adjusted automatically.
23. XPRA_EXECUTION
This phase executes the XPRAs and after-import methods.
24. ABAP_GENERATION
This phase generates the runtime objects for the imported Repository objects (ABAP
source texts and screens).
Clean Up Module
25. RUN_SPAU_?
This phase prompts you to adjust your modifications to Repository objects by calling
transaction SPAU.
26. CLEAR_OLD_REPORTS (only for import mode downtime-minimized)
This phase deletes the obsolete versions of program code and program texts in the
database.
27. EPILOGUE
This phase completes the import. Among other things, it checks whether the queue
has been processed completely.

209
Applying the Plug-In:

Fabrication

Pharmacy
PI_BASIS
Textiles
/willsys
Standard Modules Additional
/VIRSA
SD,MM, PP…
/SATYAM

(Third party tools)

SAP shifts (or) SAP comes with standard functionality such as MM, SD etc.. In order
to provide additional modules such as banking insurance business content (BIW),
textile, mining, pharmacy etc. In Order to apply these plug-in’s (Solution tools plug
in). It is used to provide solution based on CCMS or EWA (early watch alerts).

CCMS: Computing central monitoring system.

1. Download the add-on’s from the market place.

2. Download the documentation related to add on

3. Download the installation guide and important notes

4. Document all the steps

5. Ensure that all the pre requisites are met.

Ex: BIW_BASIS should be of level5

SAP_BASIS should be 16

SAP_ABAP should be 14

STPI and PI_BASIS should be 2003 and 2005 (STPI-Solution tool plug in)

6. Read the note thoroughly and get the password, key word, key from the note
to install the add on

7. Pre requisites and problems are same as support packages and patches

8. Download the content onto transport directory

210
9. Uncar the content using SAPCAR-xvf *****.car

10.Go to SAINT lad the package. Package is displayed on the screen.

11.Select the package (add on package)to install.

12.Click on continue

13.A pop up box is displayed to go through the note and key in the password to
continue the add on installation.

14.Continue the add on installation

15.There are chances for conflicts between the existing support packages then it
will ask you to configure CRT.

16.Respective CRT need to be downloaded and need to be applied by using “tp”.


(Transport, background jobs, Security)

Note: SAP NOTES provides valuable information for resolving eh run time problems.
SAP maintain abundant knowledge base of notes. Notes are related to customer
problems and solution, break fixes to the standard functionality and minor
enhancements.

SAP Notes are of 3 types:

1. Informative Note

2. Corrective Note (Manual)

3. Corrective Note (Automatic- using transaction SNOTE)

Informative Note: This note provides information to the customers as follows.

1. Production information

2. Composite note for support packages

3. Notes for add-on’s

4. Query related solution

Corrective Note (Manual): SAP recommends changes to be performed on the system


during the following scenarios

1. Changes to table entries such as tags, vat etc…

2. Changes to wage types

3. Changes related to tables

211
4. Recommend to resolve the issues (Table space overflow, Max extents list,
Archive struck, Work process congestion)

Corrective Note (Automatic): (Patches) Up to version 4.6c all the changes to SAP
system are performed manually. From 4.6c onwards SNOTE is used to apply the
changes automatically without any developer’s intervention and SSCR key. Most of
the changes are related to Sap standard objects.

Applying Note:

1. Go to market place (www.service.sap.com/notes)

2. Download the correction in the note onto your desktop

3. Go to SNOTE. Upload the note. (When it is uploaded the status will be new)

4. Select the note to implement. Now the status is in processing

5. When it is implemented status is implemented

6. Some of the notes can’t be applied and some of the notes status will be
obsolete(Outdated).

Note: Notes consists of corrective coed, which will append to the standard
programs containing the necessary code, where as support packages overwrite
the code.

Group of notes and patches are called as support packages.

Note: Notes once applied can be reverted back.

Notes can be downloaded directly connecting to the market place.

Go to SAP market place.

Until SEP 2005 there was not that much significance for market place. Before SEP
2005 we use OSS1 TCODE for downloads.

OSS1 is a transaction which is used to perform the following until SEP 2005:

1. Creating customizing

2. Searching the notes

3. Download the notes

4. Download the license keys

From SEP 2005 onwards SAP decommissioned using the TCODE OSS1 and
recommended to use “SAP MARKET PLACE”. SAP Market place is built on EP

212
(Enterprise Portal) which is used to connect between employees, customers,
partners and users.

It requires SUSER ID to login. It consists of 10 digits preceded by S and 2will be like


“S000123456”.

Market Place provides the following Services:

1. Notes: This can be searched based on error description. Only SNOTES steps are
documented. Notes are always named with numbers.

2. Customer Messages: The runtime problems which could not be resolved can be
escalated to SAP

Click on  customer message.

Select the system for which help message needs to be created.

Enter the error message. SAP advices to search and look for the resolution among
the display notes.

Enter the error message. SAP advices to search and look for the resolution among
the display notes.

If there is no resolution continue customer message.

Upload the relevant screen shot

Click on save and send it to SAP

Note: We can define the priority of the issue such as normal, medium, high, very
high.

High and Very High are considered first as the production system is in danger which
causes business loss.

Software Download (SWDC):

It is used to download support package, installation DVD’s add-on’s, plug-in’s,


kernel executables, 3rd party tools, DB patches etc……

KEYS:

There are 4 types of keys which can be generated from the market place.

1. SAP LICENSE

213
2. DEVELOPER

3. SSCR

4. MIGRATION

SAP LICENSE Key: In order to apply license to the SAP system we need to generate
license key from market place. Before generating a license key the system needs to
be registered with SAP.

[The following information needs to be given for registering with SAP: Customer
Number, SID, Installation Number, Instance Number, Host name, Hardware Key]

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

Developer Key:

[<SID> Developer name]

SSCR Key:

SCREEN SHOT

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

SCREEN SHOT

Client Comparison: When you install add on packages like country India version(CIV)
the changes effect only in that client through which its applied. CIN is an add-on
which is used to bring the changes related to taxes, wages etc. It was earlier
version. Now it is coming along with standard SAP software.

Functional consultants identify the changes related to these functionalities and


compare the entries in respective transactions and merge them.

Select the entries and merge system prompt to record the changes to a change
request.

SAP Router: SAP router is a software program which runs on the application server.
It runs as a service and maintains access control list in a table SAPROUTETAB. It is a
text file which maintains the IP address, permit, deny and port numbers(Not a DB
table).

Permit P 192.168.01.1 3600

Deny D 192.168.01.3 3600

Configuring SAP Router:

215
GO to www.service.sap.com/saprouter and download SAP Router executables into
c:\> (drive)and saprouter (folder). SAP ROUTER is an executable present in the run
directory and ensures that the version of the SAP router is always updated.
Download the files into SAP router directory send the details to SAP to establish
the remote connection.

” encrypt.pse” are given to the customer. In that a key is available.

Run the encryption and key in the SAP key and get the key to sap. Once the
connection is opened we can TELNET to SAP server. In order to start the SAAP the
command is

Start: saprouter –R

Stop: saprouter –S

Create the SAP router, start up as a service using NTSCMGR

In UNIX: $PRONJOB, ALL_ACCESS control list.

In order to open the connection SAPROUTER must be running.

SCREEN SHOT

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

216
PRE GO LIVE:

Before the system goes live SAP logs into customer system and evaluate
customizing and development.

Pre Requisites:

1. The system needs to be registered in the market place

2. SAPROUTER is defined and connectivity is established

3. Customer has to send the necessary information to SAP (Name of the


company, Name of the persons, Email Id and Phone Number)

4. No of modules configured

5. O/S, DB, R/3 system type

There are 3 types of Go LIVE check conducted by SAP

1. GA- Go live analysis

2. GV- Go Live Verification

3. Go- Go live optimization

We need to inform SAP preferably 2 months or at least 1 month before Go-LIVE to


conduct the above checks.

Go Live Analysis: This is the first check conducted by SAP to determine the
following:

1. Critical Transactions

2. Expensive Programs

3. CPU utilization

4. Memory Consumption

5. Back Up Configuration

6. Scheduling standard jobs

7. Critical interfaces

8. Utilization of buffers

9. Hard Ware configuration

10.Dialog response time

217
SAP studies all the above and recommends the measures for tuning such as

1. Relocation file structures

2. Configure memory parameters and buffer parameters

3. Work process configuration

4. To create indexes like primary indexes and secondary indexes

5. Run the check optimizer statistic schedule it in the standard background jobs
(House Keeping Jobs).

6. Defining the backup

7. Tuning the expensive programs and SQL statements

8. Moving the long running programs into background mode.

Note: Large installations should inform 2 months before Go Live (or) at least 1
month.

Small installations should inform 1 month or at least 15 days before the Go-Live.

SAP recommends the changes to be performed within 15 days.

Go Live Verification:

This session has to be scheduled after the Go Live analysis session. This will be
conducted by SAP technical consultants to verify the changes that are
recommended in GLA system. If the changes are related to Hardware it will
highlight during this phase.

Note: SAP verifies the parameters and recommends further changes on the system
configuration on the day off session.

Go Live Optimization:

This session will be conducted after Go Live (After 1 month of Go live). This is used
to analyze the load on the system. (How many users logged on, Critical transactions
and critical programs) and recommend further changes to optimize system
performance.

Parallel Run:

Data Migration: Most of the Customers define a migration client to perform data
transport from legacy systems. The data is migrated and tested for its quality
before moving to production. The data migration, parsing truncating is performed in
the migration client.

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

Note: As the users are not habituated to SAP systems, we will uses to work on both
the systems (Legacy and R/3 systems). As a company policy it may be allowed to
use only fewer modules on the production system and remaining on legacy
systems.

In the above scenario parallel run of both SAP system and legacy systems are
advised.

During parallel run legacy system and R/3 system run together, the data from
legacy system is transported periodically, hourly, and daily to synchronize the data
between two systems.

VB JAVA ORACLE SAP


Go Live 1st Apr09

SD MM PP HR FI CO

1st May09SD,MM

Daily/Hourly Transfer

1st June 09
PP,HR

Modules are run in parallel

in both systems

FI/CO (running on
SAP)

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

219
Systems. Now the modules run only in SAP system.
1st Jan 2010

All Modules are


running only on
SAP system from
here onwards

USERS and SECURITY of SAP System

Name Employe Departm Address Employe Appraisa Bonus


e Code ent e Salary l

Designa Name Empco Departm Addres Emp Apprai Bonus


tion de ent s Salary sal

HR Clerk       

HR       
Manager

Project       
Manager

Director       

Employe       
e

Employee can see his own details. But he cannot change any other entry. He can
see details of other employees.

Director can change create (or) display all the entries in the table. He can see/
change details of all the employees.

Project Manger can’t create the first four entries (Name, Empcode, Department, and
Address). He can only see them. He can create/change the other 3 entries.

220
Authentication: It is the means of providing access to the system i.e. User ID and
Password.

Authorization: It is the means of providing access to system functions to the


authenticated users.

In order to provide various accesses to different people in the


organization we need to define

Roll Matrix (or) Authorization Matrix.

Roll Matrix (or) Authorization Matrix: It is a table which defines the critical
transactions, access levels and the rolls.

Authorization Field: The data element (or) a field in the table which needs to be
protected is called as authorization field. Authorization fields are created in
transaction SU20.

Ex: Employee Salary, Bonus, Discount, Sales Order Amount, Purchase Order Amount
etc….

Activities: It is the action that can be performed on an Authorization Field.

Activities are as follows:

 Create,

 Display

 Modify/Change

 Delete

 Print

 Reverse etc…

Activities which are available in the system are shown in the table TACT. By default
there are aroune 170 activities defined in this table.

Note: We can create our own activities in table TACT.

Authorization Objects: A group of not more than 10 related authorization fields is


called as authorization object.

Authorization Fields and Activities: The list os possible activities for each
authorization objet is defined in the table TACT2

221
Authorization: Authorization field and its activities are referred as authorizations. It
is also referred as field and its value.

Authorization Profile: A group of not more than 150 authorizations is called as


authorization profile.

Note: Up to SAP 4.6 B version profiles are created manually, but from 4.6C onwards
profiles are generated while creating roles.

Composite Profiles: Group of profiles is called as composite profiles.

Role: A role is a combination of profiles, transactions, reports, menus,


personalization’s over assignment.

Roles are defined in transaction PFCG.

Composite Role: Group of one or more roles for administrative ease is called as a
composite role. It doesn’t provide any additional functionality.

Derived Role: The roles derived from a parent role, but differ by organizational
levels. These restrict the functionality based on organizational levels.

Parent Role: It is a single or generic role which is having authorizations to inherit to


child roles/derived roles.

Defining a Role:

Go to PFCG

Specify the name of the role

Create, change (or) copy role

Authorization field and Authorization objects are cross client objects.

 Description of the role

 Go to Transaction to include standard transactions

 Go to menu to include reports, URL’s, create folders etc…

 create click on change, authorization data

 specify organizational levels such as company code, sales orders,


organization sales area, distribution channel

 Authorization objects, fields, authorizations are displayed

222
 Include authorizations objects manually

 Red means organization levels are missing

 Yellow means field value activities are missing.

 Green means totally organized.

 Click on the traffic light. Then you will get the complete/full authorization.
(Pop up box will be displayed).

 Provide field values, activities according to SOD matrix. (SOD Segregation


of Duties)

 Save and generate profile

 Save the role and assign it to users.

 Perform user comparison, so that role will be effective in the user master
records.

 The role won’t be effective until we run user comparison

Note: In earlier versions the user has to log off and log in to get the effectiveness of
the new role assigned to him. But in the current versions after user comparison the
role is effective automatically.

Note: Performing user comparison during role creation consumes more time. So
perform the user comparison in the background mode during off peak hours.

PFUD: This is used to perform user comparison in the background mode (or)
schedule a report “PFCG_TIME_DEPENDENCY” to perform user comparison in the
background mode.

Initializing Profiles: (Filling the Customer Data)

When a client is created we cannot perform role creation without filling the
customer tables.

The tables used are USOBX and USOBT.

Go to SU25 click on initially fill customer table.

The relation between the transaction and the authorization object s can be
displayed in SU24.

SU24 is used to define the relation between transaction and authorization objects.

223
Authorization check indicators such as unchecked, not maintained, check check and
maintain.

When a transaction is initiated it will check in the assigned program

Authorization objects are created in SU21

Development class—> packages

SM30 table maintenance if the table maintenance is allowed we can create entries
manually.

Table TACTZ
Activity
Up to 10 authorization objects

[SU21/SU22]

(Authorization Field) Authorization object classes

Assigned Transactio
n
in SU24 Assigned
Users
Role

PFUD/PFCG

Profile/Composite PFCG-Time
Profile PFCG SU01

UMR-User Master Record

Example: Purchase order

Activities are: Create, Modify, Delete, Reverse, Approve, Release (These activities
are listed in table TACT)

Roles are added in table AGR*

When the user is logged into the system request goes to the DB and gets the
necessary authorizations from the user master record (USR02) and keeps a copy on
the user context. This user context is displayed in transactions SU56.

When a user executes a transaction it points to the program. Program in turn points
to authorization objects inside it. Authorizations are programs busing statements
“authorization_check_” followed by the authorization object, field value and activity.
These are all checked against user buffer (SU56). If they are available user is
allowed to perform transactions else user is not authorized to run the transaction.

224
Missing Authorization: Very frequently help desk receives calls related to missing
authorization when a user could not access a program over a transaction. It is
referred by the user as Missing Authorization.

Missing Authorizations are caused by the following:

1. User is not assigned with authorization

2. User is assigned, but user comparison is not performed

3. User to roll assignment is expired

4. User buffers are old (or) over flown

Analyzing Authorizations:

Transaction SU53 is used for analyzing missing authorizations of the respective


user.

Check the missing objects in the user master record.

If the role Is already assigned perform user comparison.

If the role assignment is expired then send a mail to the business process owner.

User raises a ticket of missing authorization ask the user to execute the transaction
again and send the screen shot of SU53 screen.

Note: In every organization SU53 TCODE is assigned to the every user.

If the role is assigned recently and user comparison is not performed then perform
user comparison.

Note: Use SUIM (SAP User information management. This information transaction
gives you all the reports related to SAP security. Some of the reports are user to
roles, roles to transactions, user to profiles. Standard password reports, user change
documents (last logon date, last password change, list of users locked).

Basically SUIM uses (or) calls RSUSR*

SA38 is executed.

In SE38 all the engineering can be done

Go to SE38Key in RSUSR* Press F4 to display the list of possible reports

Scenario: Authorization is not assigned to the user

User complains of missing authorization

225
Purchasing officer Sales Officer Plant In charge Warehouse In
charge

Create a material Create S.O Stack Maintenance


distriution
Create a P.O

Write to the business process owner to approve the missing authorizations


assignments.

Wait till get the approval.

Note: Always assign only requested authorization to the users. Do not assign excess
authorizations.

Authorization Objects, Authorization Fields and Field values cannot be assigned


directly to a user.

Generated profiles can be assigned indirectly by assigning roles.

All of the above can be combined in the role and assign it to the user.

Role Mitigation:

It is performed by using third party tools like VIRSA, BIZRights

Role Mitigation is used to mitigate the following

1. What worse will happen by assigning the existing role to the user? After
mitigation it will giva report of excessive authorization. Send the list to the
Business Process Owner and get approval.

Roles consists of many authorizations.

Ex: Purchasing Officer Role

Create Material, Create P.O etc.. are the authorizations of the role.

Now if a user wants authorizations to create a material and if we assign the


whole role i.e. purchasing officer to that user, then he will get excess
authorizations.

2. Identify the least effected role by mitigating fewer times and assign that
object to that role (Save the role, generate the profile, assign it to user,
perform user comparison).

If both of them are not allowed then write to the manager approval to create
a role.

226
Create Role, assign the authorization object, save and generate profile,
assign it to the user and perform user comparison.

Barbanes Oxley Procedure:

SOX 404 act. It is implemented in most of the public limited companies in the U.S to
safeguard the applications. SAP uses the above tools (VIRSA, BIZRights) to mitigate
when modifying a role (or) assigning a role to the user. VIRSA has become internal
part of SAP and comes as an add-on.

Transaction SU99 is used to specify which of the transactions should not be


combined.

These 3rd party tools are also used for the following:

1. Auditing Purpose:

Who has done?

What he has done?

When e has done?

Example: Consider P.O

Who has released P.O, Who has created P.O, When is it created, All the
details are given in auditing.

2. Mitigating between the Roles and Users

3. Identifying (or) tracing out incoming and outgoing documents

Ex: We can get across control to that P.O creations, TIN, bank account
number, address, telephone number, fax number, match with P.O
receivers.

4. User Management:

User Creation: Users are created in transaction SU01. SU01 is used to


create, modify, lock, unlock, copy and delete the users.

SU01 is used to create single user.

SU10 is used to create mass users with some privileges

Types of users:

1. Dialog User

227
2. System User

3. Communication User

4. Service User

5. Reference User

Dialog User: Is the on e where interactive logon is possible. These are calculated for
license.

System User: Is used to communicate within the system in the background mode.
No interaction logon is possible.

Communication User: It is a non dialog user where interactive login is not possible
and used to communicate between 2 systems using RFC connection.

Service User: This is anonymous user, which is used by group f people where dialog
logon is possible. No password, USER ID

Ex: Top view the company targets

Reference User: It is used to provide additional rights to interact users.

Ex: Users connecting to the system over the browser will have limited
authorizations (EP). Once authenticated the rights will be assigned to the reference
user.

SOD: Segregation of Duties

It is an authorization matrix (or) role matrix.

Segregation of duties is performed while implementation (or) duing support,


business process owners define the key roles in the company along with the
activities which are performed in the system.

It is a matrix of Roles & Transactions. It is used to define the transactions in the


company.

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

228
Name of MM01 MM02 MM03 ME21 ME22 ME23
the Role

Purchase      
Officer

SALES      
OFFICER

SALES      
MANAGER

AREA      
MANAGER

MANAGER      

DIRECTOR      

Questions:

1. What are the standard roles available in the system. Name some of them
along with description (at least 10)

2. Name some of the profiles, composite profiles, authorization objects,


authorization fields, composite roles, derived roles.

3. List the users with critical transactions

4. Display all the available users in the system

User Creation:

Users are created in transaction SU01

SU01 has the following tabs:

Address Tab:

It provides the details of the users like first name, last name (It is mandatory to
provide email and telephone number)

Logon Data Tab:

It specifies the validity period, specify the type of the user

229
User Group: These are defined in SUGR. These are used to group the users based on
department or division or roles for easy maintenance. By default super group is
available in the system.

User Group for authentication Check: If we specify a group the user is allowed to be
administered by the user of this group only.

Super user group admin is allowed to administer the user belonging to all the
groups.

Specify the password.

Default Tab:

Specify the start menu

Specify the logon Language

Specify the printer settings like O/P device, O/P immediately or release after O/P.

Time Zone: Decimal notation and date format

Parameters: These are frequently used fields which will be popular during the run
time of the user

Define the run time of the user.

Define a parameter Go to the field Press F1 go to technical properties Find


the parameter ID Go to SU01 Click on parameters tab specify the parameter
and parameter value

Roles Tab:

These are used to assign authorization to the users. We can delegate additional
rights by using reference users.

Profiles Tab:

These are going to be combined in the roles. There is a specific profile which can be
used like SAP_ALL, SAP_NEW needs to be documented. Use only either roles or
profiles.

Groups Tab: These are created in SUGR used to group the users for administrative
purpose.

Presentation: It is used to restrict the user access such as time in and time out of
the current day. Sales of the day and sales of the week, pay slip of the month.

230
Personalization Tab:

Personalization is a way to save information that could be common to users, I


meant to a user role... E.g. you can create SAP queries and manage
authorizations by user groups. Now this information can be stored in the
personalization tab of the role. (I supposed that it is a way for SAP to
address his ambiguity of its concept of user group and roles: is "usergroup" a
grouping of people sharing the same access or is it the role who is the
grouping of people sharing the same access?)

EWZ5: To lock and unlock the users

1. Principle of Dual Control: It is controlled by two administrators

1. User Administration

2. Profile and Authorization Administration

When there are more systems in the landscape (or) various components SAP
(BW,CRM,SRM) are implemented in such a case SAP recommends to use control
administration  CUA
User Admin Profile& Authorization
Admin

Create users Assign Roles to User and


perform User Comparison

2. Principle of Triplet control: The user and authorization administration is


segregated into 3 roles

1. User Admin

2. Role/ Profile Admin

3. Authorization Admin

This is controlled by 3 admins

Role Admin

Create Role

Display Roles

Change Roles

Profile Admin
User Admin Authorization Admin

231
Create User Assign roles to users and perform user
comparison

Prerequisites of CUA:

1. All the clients are defined with logical system

2. Define RFC connections with logical system names in SM59

3. Go to SALE define the logical system name and assign them to clients

Defining CUA: (Central User Administration)

Go to SCUA of the master client or parent client from which we want to monitor
users centrally.

Specify the name of the CUA, SAVE and include all the logical systems.

Save and distribute configuration of all the clients.

Identify CUA configuration

Systems tab is added in the master client.

Systems tab is included in the roles tab

User creation is disabled in all the child systems

Users can be created only in the master client and maintained in the child client

Users can be maintained either globally or logically which will be defined in SCUM

While assigning roles click on “read text from child client”

Note: RSDELCUA is used to delete the CUA. (Execute this report in SE38)

CUA mechanism: CUA uses ALE mechanism to transfer the data between different
clients. Transaction RFC is used to transfer the data between the systems.

Go to SUIM (To give global or local users to be monitored)

SCUM: If you are using Central User Administration, you can use the distribution
parameters in transaction SCUM to determine where individual parts of a user
master record are maintained.

· In the central system


· Locally in the child system

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

SAP R/3 Security Tables:

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

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

Below the list of SAP R/3 Security Table that could be used for your
references

USR02 Logon data


User master authorization (one row per
USR04
user)
UST04 User profiles (multiple rows per user)
USR10 Authorisation profiles (i.e. &_SAP_ALL)
Composit profiles (i.e. profile has sub
UST10C
profile)
USR11 Text for authorisation profiles
USR12 Authorisation values
USR13 Short text for authorisation
USR40 Tabl for illegal passwords
USGRP User groups
USGRPT Text table for USGRP
USH02 Change history for logon data
USR01 User Master (runtime data)
USER_ADD
Address Data for users
R
AGR_1016 Name of the activity group profile
AGR_1016
Name of the activity group profile
B
AGR_1250 Authorization data for the activity group
AGR_1251 Authorization data for the activity group
Organizational elements for
AGR_1252
authorizations

234
AGR_AGRS Roles in Composite Roles
AGR_DEFIN
Role definition
E
Menu structure information - Customer
AGR_HIER2
vers
AGR_HIERT Role menu texts
AGR_OBJ Assignment of Menu Nodes to Role
AGR_PROF Profile name for role
AGR_TCDT
Assignment of roles to Tcodes
XT
AGR_TEXT
File Structure for Hierarchical Menu - Cus
S
AGR_TIME Time Stamp for Role: Including profile
AGR_USER
Assignment of roles to users
S
Relation transaction to authorization
USOBT
object (SAP)
Relation Transaction to Auth. Object
USOBT_C
(Customer)
USOBX Check table for table USOBT
USOBXFLA Temporary table for storing USOBX/T*
GS chang
USOBX_C Check Table for Table USOBT_C

Types of Security are NW, DB, O/S, R/3

In R/3 application and data to be protected (Invoices, Billing..)

In DB “OPS$” USER ID , SYS, SYSTEM, SCHEMA ID should be protected

In O/S File structure , sapservice<SID>, <SID>ADM should be rotected

In N/W firewall should be provided

Some Authorization objects are:

1. S_TCODE (S represents BASIS)

2. Q_TCODE (Q represents Quality)

3. P_TCODE (P represents HR)

235
4. S_USER_GRP, S_USER_AUTH, S_USER_AGR, S_USER_TCD, S_USER_USR,
S_USER_PRO

These are user management authorizations for dual control and triplet control

5. S_TABU-DISP : This is an authorization object which provides access through


authorization fields, authorization group

6. S_TABU_CLIENT: Cross client object

7. S_PROGRAM, S_DEVELOP, S_SPO_DEV are related to development

The following T-Codes are security related activities:

SU01:

SU10:

SUGR:

PFCG:

EWZ5:

SCUM:

SCUL:

SUPC:

SU03:

SU24:

SU25:

SU99:

SM18:

SM19:

SM20:

SM58:

SM59:

SALE:

BD54:

236
SCC4:

Segregation of Duties (SOD):

SAP R/3 segregation of duties (SOD) is a basic key internal control that is
used to ensure that errors or irregularities are prevented or detected on a
timely basis by employees in the normal course of business.

Segregation of duties provides two benefits:


1) a deliberate fraud is more difficult because it requires collusion of two or
more persons, and
2) it is much more likely that innocent errors will be found. At the most basic
level, it means that no single individual should have control over two or more
phases of a transaction or operation. Management should assign
responsibilities to ensure a crosscheck of duties.

There are four general categories of duties or responsibilities which are


examined when segregation of duties are discussed: authorization, custody,
record keeping and reconciliation. In an ideal system, different employees
would perform each of these four major functions. In other words, no one
person should have control of two or more of these responsibilities. The more
negotiable the asset, the greater the need for proper segregation of duties -
especially when dealing with cash, negotiable checks and inventories.

CPIC: Common programming interface communication:

CPIC (Common Programming Interface Communications) is the interface


deployed by the ABAP language for program-to-program communication.
CPIC was defined and developed by IBM as a standardized communication
interface and was later modified and enhanced by the X/Open organization.
The CPIC communication interface is useful when setting up communications
and data conversion and exchange between programs. Since CPIC is based
on a common interface, an additional advantage is the portability of the
programs across different hardware platforms.

SAP divides the possibilities and the scope of the CPIC interface into two
function groups: the CPIC starter set and the advanced function calls. This
division is simply meant to guide the user and not to restrict the available
functions. For instance, the CPIC starter set would just be used for the basic
and minimum set of functions shared by two partner programs, such as
establishing the connection and exchanging data. The advance calls cover
more communication functionality, such as converting data, checking the
communication, and applying security functions. For more information on

237
these CPIC function groups, refer to the SAP documentation BC SAP
Communication: CPI-C Programmer’s Guide.

CPIC communication is always performed using the internal SAP gateway


which takes care of converting the CPIC calls to external communication
protocols such as TCP/IP

Password Control in SAP Systems


There are two ways in which you can define your choice of user passwords:

• You can use the system profile parameters to assign a minimum length for
the passwords and define how often the user has to set new passwords.
• Invalid passwords can be entered in the table of reserved passwords,
USR40. This table is maintained with transaction SM30. The entries can also
be made generically:

- ? denotes one character


- * denotes a character string

The SAP System also has pre-defined password rules. You can control passwords
with profile parameters login*

login/min_password_lng - Defines the minimum allowed length of a new


password.

login/password_expiration_time - Defines the expiration period of the password

login/fails_to_user_lock - Locks the user after the specified amount of wrong


logon attempts; user is unlocked at midnight if the login/failed_user_auto_unlock
parameter is set

login/fails_to_session_end - Ends the user.s session after the specified amount


of wrong logon attempts

login/disable_multiple_gui_login - Refuses multiple logon of users; only users


listed in login/multi_login_users are allowed for multiple logon

login/min_password_diff - Defines the minimum number of different characters


between old and new password including rotation

login/password_max_new_valid - Defines the validity period of passwords for


newly created users

login/password_max_reset_valid - Defines the validity period of passwords reset

login/min_password_digits/_letters/_specials - Defines the minimum number of


digits/letters/special characters in the password

login/disable_password_logon and login/password_logon_usergroup

238
Controls the deactivation of password-based logon

login/disable_cpic -Refuses incoming connections of type, CPIC

rdisp/gui_auto_logout - Defines the time for automatic SAPGUI logout

login/no_automatic_user_sapstar Controls the SAP* user

Default password, and protecting SAP*

Starting with installations of SAP Web Application Server release 6.10 and
higher, the passwords of SAP* and DDIC are selected during the installation
process.

Use the User Information System or report RSUSR003 to monitor the


passwords of all
predefined users.

If possible, make use of the profile parameter,


login/no_automatic_user_sapstar.

If you create a new client the default password for SAP* is pass. If you
delete SAP* userid, logon is possible with SAP* /pass.

The DDIC user maintains the ABAP dictionary and software logistics. The
system automatically creates a user master record for user SAP* and DDIC
in client 000 when
the SAP System is installed. This is the only user who can log on to the SAP
System
during a release upgrade.

Do not delete or lock user DDIC because it is required for certain installation
and set-up tasks. User DDIC needs extensive authorization. As a result, the
profile SAP_ALL is allocated to it. The users, SAP* and DDIC, should be
assigned to user group SUPER to prevent unauthorized users from changing
or deleting their user master record.

Default clients in an SAP System:

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

Techniques to implement to keep SAP passwords Safe and Secure:

SAP uses a technique called as Hashing to store the passwords in the database.
With this technique the system tries to guarantee that if an attacker gets access to
the database where passwords are stored, he won’t be able to recover the original
password string.

SAP has implemented different password hashing mechanisms along its history
each identified by a Code Version (CODVN From A,B,C,D,E,F,G,H,I).

Each version is dependent on different technique like MD5, SHA1….

Since release 7.00 SAP introduced a completely re-designed hashing mechanism.


This new version CODVN F is based on SHA-1 and allows up to 40 character
password, case sensitive and supports the UTF-8 character set.

Passwords are stored in different tables in SAP database.

USR02: This is the user master table. Contains information such as the User name,
user type, lock status, last logon date etc..

This table stores the current password hashes in two fields, depending on the code
version being in use. If the code version F is used a 40-character long PASSCODE
field is used to store the password hash.

Finally if code version is H the HASH is stored I the PWDSALTEDHASH field. It is


possible to identify which code version is in use by analyzing the CODVN field.

USH02: This table is known as the change documents table and is updated every
time a user is locked, un-locked, its password reset etc… When these events take

240
place a partial copy of user master information including BCODE, PASSCODE and
PWDSALTEDHASH fields is inserted as a new record in this table.

USRPWDHISTORY: In release previous to .00 password history is set to 5 and the


last five password hashes are stored in the USR02 tables (Fields OCOD1-OCOD5).
From that release onwards, the password, history size is no longer fixed, being
configurable through the profile parameter login/password_history_size.

Therefore, each time a user’s password is change a new rec0ord is inserted in this
table containing the old hash value.

The USR02 table can be retrieved from transaction SE16.

The tables USR02, USH02 and USRPWDHISTORY should be protected against direct
access through table maintenance tools (TCODES SE16, SE17, SE11…). This can be
enforced through the proper use of the authorization object S_TABU_DIS which
restricts access to critical table authorization groups.

Use different passwords for critical users like Sap*, DDIC, Administrator….

Disable downwards compatibility (If possible). If there is no need to connect with


older systems or special scenarios (e.g. CUA) the”
login/password_downwards_compatibility” parameter should be set to “0” avoiding
the generation of weak hashes.

If legacy components needs to to connect with a new SAP system then a possible
solution needs to be configured having 8-characters long upper case passwords,
including special characters. This would keep the hashing procedures strong, while
providing a decent level of security for legacy compatibility.

Implement a strong password policy.

Ex: login/min_password_lng > 8 and login/min_password_lowercase > 0 to demand


the use of passwords longer than 8 characters and the use of at least one lower
case character.

Frequently Asked Questions on Authorization

Role & Profile

What is the difference between role and a profile?

Role and profile go hand in hand. Profile is bought in by a role. Role is used
as a template, where you can add T-codes, reports..... Profile is one which

241
gives the user authorization. When you create a role, a profile is
automatically created.

What is the use of role templates?

User role templates are predefined activity groups in SAP consisting of


transactions, reports and web addresses.

What is the different between single role & composite role?

A role is a container that collects the transaction and generates the


associated profile. A composite role is a container which can collect several
different roles

What profile versions?

Profile versions are nothing but when you modify a profile parameter through
a RZ10 and generate a new profile is created with a different version and it is
stored in the database.

Is it possible to change role template? How?

Yes, we can change a user role template. There are exactly three ways in
which we can work with user role templates
- we can use it as they are delivered in sap
- we can modify them as per our needs through pfcg
- we can create them from scratch.
For all the above specified we have to use pfcg transaction to maintain them.

Personalization Tab within PFCG

Please explain the personalization tab within a role.

Personalization is a way to save information that could be common to users, I


meant to a user role... E.g. you can create SAP queries and manage
authorizations by user groups. Now this information can be stored in the
personalization tab of the role. (I supposed that it is a way for SAP to
address his ambiguity of its concept of user group and roles: is "usergroup" a
grouping of people sharing the same access or is it the role who is the
grouping of people sharing the same access?)

How to insert missing authorization? Ways?

su53 is the best transaction with which we can find the missing
authorizations and we can insert those missing authorization through pfcg.

242
Table of authorization field settings

Is there a table for authorizations where I can quickly see the values entered
in a group of fields?
In particular I am looking to find the field values for P_ORGIN across a
number of authorization profiles, without having to drill down on each profile
and authorization.

AGR_1251 will give you some reasonable info.

Table with deleted users

Someone has deleted users in our system, and I am eager to find out who. Is
there a table where this is logged?

Debug or use RSUSR100 to find the info.

Run transaction SUIM and down its Change documents.

How can I make T_Code SPRO Read Only

I have a requirement to make SPRO read only. As you know it has a tree like
structure and to make it read only seems like impossible.

You cannot make SPRO 100% display only by ANY setting. The SCC4 option
only turns configuration tables to not-modifiable but still allows the non-
config delivery class tables (or those configured to be changeable) to be
modified. It does nothing for the tcodes that are NOT table maintenance and
not controlled by S_TABU_DIS. These will still allow configuration. All the
tcodes in the SPRO are in several tables CUST_ACTOBJ (spelling?) is one.

You only real option is to create a role with all the tcodes in them that are in
the SPRO , remove the create and change to display ( generally by changing
the last number on the 4 digit tcodes to 3) and removing all the Create and
change access in all the activities and allow only the display.

PFCG allows you to create a role from a SPRO project so the usermenu will
come close to the SPRO menu, which your changes it will be display.

Mass Delete of Old Roles

How can i do a mass delete of the roles without deleing the new roles.

There is a SAP delivered report that you can copy, remove the system type
check and run. To do a landscape with delete, enter the roles to be deleted

243
in a transport, run the delete program or manually delete and then release
the transport and import them into all clients and systems.

It is called: AGR_DELETE_ALL_ACTIVITY_GROUPS.

To used it, you need to tweak/debug & replace the code as it has a check
that ensure it is deleting SAP delivered roles only. Once you get past that
little bit, it works well.

244
Dialog Work Process in Multiplexing:

SAP transaction consists of multiple transactions which are handled by


individual dialog work processes. Dialog work process handles request from
various users (It is not restricted to the user)

User transactions are handled by various dialog processes (restricting to a


process). This mechanism is called as multiplexing.

This process of handling various dialog steps of different user’s transactions


without restricting to the users is called work process multiplexing.

Dispatcher
User
Communica
tion W0,W1-------Wn-1 Queue
U

C Task
Handler

R/3 Buffers
DB

The number of dialog work processes can be configured by using the


parameter

rdisp\wp_no_dia

The maximum run time of a dialog work process is restricted to 600 sec,
which can be increased dynamically in RZ11 by using the parameter

rdisp\max_wprun_time

Configuring this parameter does not require R/3 restart

This parameter can be increased and decreased dynamically in the following


scenarios:

1. Weekly progress report (or) sales report


2. Month end reports (or) any critical transactions which consumes more
time.

Dialog work process can be monitored in SM50/ SM60/ SM66

245
We can also monitor dialog work process using command prompt using the
command “dpmon”

Ps –ef|grep de *

Disp+work

Update Process: This process is used to update the database. SAP


transactions consist of multiple transactions which are handled by different
dialog work processes. Each process can’t update the DB, because they are
part of the transaction.

That is the reason they will update temporary tables, so that rollback is
possible. If the entire transaction is committed then the update is written to
the database.

Users request using dialog process to commit a part of a transaction. If it is


written to the Db, it cannot be rolled back. So it is updated in the temporary
tables.

Temporary Tables:

These are the tables which are used by the dialog process to update the data
temporarily. Update process reads the committed data from the tables and
updates the tables in DB.

The temporary tables are VBHDR, VBMOD, VBDATA, VBERR

VBHDR: It stores the header information

VBMOD: Modules involved in the update (Scripts)

VBDATA: Data to be updated

VBERROR: Any error information

Once all the steps (dialog steps) update temporary tables a COMMIT occurs.
Once the transaction is committed update gets initiated. Update process
reads the temporary tables and update the DB. Before updating temporary
tables dialog process gets a logical lock from enqueue process, if it is on CI
(Central Instance). If it is on DI (Dialog Instance) it communicates with
message server. Message server in turn communicates with enqueue
process to get the lock, so that other users will not modify during
transaction.

246
While updating records from the temporary tables to the DB update inherits
the locks

Types of Update Work Processes: There are two types of update work
processes V1 and V2

Update Process (v1): V1 handles the most critical updates. (User Transactions)

Update Process (v2): V2 handles non critical statistical information

Update work processes are configured using parameters

rdisp/wp_no_vb1

rdisp/wp_no_vb2

Each instance/ SAP system requires at least one V1 process. If v2 updates are
not defined they will be handled by v1 update process.

Update process Monitoring:

Updates are monitored in transaction SM13

Note: When a dialog process commits into temporary tables a transaction


number (P.O number, Invoice) will be generated. The number is generated
from “Number range buffer”. Number range buffers are defined in
transaction SMRO in the table “NRIV”.

NRIV: Number range interval

Monitoring: Go to SM13 select terminated records double click (or) select


all to find out the list of updates which are to be updated, which are
terminated etc…

The status of the updates will be followed.

The status may be:

 Init: Update is initialized and waiting for the updation work process.
(SAP recommends at least one update work process for 5 dialog work
processes)
 Auto: If the update mechanism is deactivated the work processes will
be terminate the update process, upon activation of the update. The
update status will go into AUTO. That is no initialization is required
 Run: Update is running. Update is updating into the DB

247
 Error: Update is terminated

Reasons for Update Problems:

 There is a problem in the program (Very rare) so that we apply support


packages, patches and notes
 Table space overflow (Resize the data file or add data file)
 Locks are not available
 Work process congestion (Updates work processes are not available)
 Update deactivated for each of the problems with update the entire
update mechanism will be deactivated

Go through SM21 logs and ST22 ABAP dumps thoroughly and fix the issue.
The update can be activated in SM14.

Note: IF the update could not be initialized automatically, select the record
and run the update (if the update is terminated).

Types of Update Mechanism:

1. Local
2. Asynchronous
3. Synchronous

Local Updates: These are used to update the DB directly

Ex: Update is programmed locally and updates DB directly without any


intermediate tables temporarily. These are used for small transactions which
don’t have multiple tables in the DB. It is not monitored and displayed in
SM13.

Asynchronous Updates: This mechanism is used by dialog work processes.


They will update the temporary tables and gets the transaction ID from
number range buffers. Dialog work processes never waits for the response
from the temporary tables.

Ex: User creates a P.O but could not see the P.O in the DB due to
deactivation of Update Mechanism. No acknowledgment.

Synchronous Mechanism: This mechanism is used by update process. Update


process reads the temporary tables and updates DB tables synchronously by
obtaining transaction consistency.

Update reorganization: rdisp\vbdelete isused to delete the incomplete


update records. It should be set to 1.

248
RSM130002: It is used to delete the update requests based on number of
days.

rdisp\vbmail: This is used to trigger the mails to users in case of update


errors and update deactivation

rdisp\vb_stop_active=1: This parameter is used to deactivate the update


process in case of programmatic or DB related errors.

Enqueue Mechanism:Enqueue is used to the locks to an SAP transaction. This


is used to logically lock the tables and the arguments which are involved in
the transactions.

Enqueue process is only confined to application server level. These are not
equal to DB locks (Tables updation locks) but similar to DB locks.
ENqueue_Table_Size

Enqueue table is stored in main memory of the instance where enqueue is


located.

Dead Lock: In order to update user requirements enqueue lock to be placed


on the table and on its arguments. Let us say if the user has to lock the two
arguments. But one of the locks is locked earlier by another user. This user is
waiting for lock on the argument which is locked by the current user. This
situation is called as Dead Lock.

Apart from the above user call regularly raising a message saying that
transactions are locked and could not be updated.

Note: In order to resolve the above issue release the locks in SM12.

Process of Releasing Lock:

1. Users complain of updating request. As part of system help we need to


monitor the locks which are older than 24 hours
2. Identify the user who locked the argument and check whether user is
still logged onto the system.

Note: Do not ever try to delete the locks without user approval.

SM04- Users who logged on to the system.

Case-1: If the user is not logged on we can release the lock

Case-2: If the user is logged in get the telephone number and E-mail id from
SU01 and send a mail to the user about the lock release. Call the user and

249
explain the significance of lock release. Probably we can also involve the
consultant who is waiting for lock. Based on verbal approval send a mail to
the user saying that “ As discussed today morning 5 A.M about release of
locks we are going ahead to unlock the transaction”

Thanks for approval

Finally release the lock in SM12. Release the one which is approved.

Background Processing: The programs, reports, transactions which consumes


more than the time specified is rdisp\max_wprun_time=600.

After 600 seconds the transactions will get terminated and logged into ABAP
dump with an error “Time out occur” or a program running more than the
specified time.

SAP recommends to run this sort of long running programs and time
consuming programs or expensive programs in the background mode using
“Batch Process” (background Work Process).

Background work processes are used to schedule the reports, programs,


transactions to run in the background mode during off peak hours without
any user intervention. This facility is used by most of the companies for the
following purposes.

1. Data transfer from legacy systems


2. On line sales orders, purchase orders to move into SAP
3. Running the weekend reports, monthly reports, pay roll runs

Companies like H.P uses for Order Processing.

Note: Companies uses 3rd party tools like “Maestro”, “Tidal” to trigger the
background processes.

Triggering background Jobs: This can be triggered based on the background


jobs

1. Time-Controlled:

Ex: Every day 10 pm

Every hour start at 11:55

Every Month

Run immediately

250
2. Event Controlled: These are used to trigger based on events on
success of dependant programs

Users can trigger some of the events using standard ABAP programs or
customizing using functional modules

BP_RAISE_EVENT (In earlier versions) or use the external programs and


commands using command “sapxpg” and “sapevt”.

Defining a Background Job:

In SM36 background jobs are defined

SM36 Specify the name of the job Description of the Job Specify the
type or class Spool recipient

Different types of classes are

Class A: With high priority (background W.P of Type A should be reserved in


RZ04)

Class B: Medium Priority

Class C: Low priority

Spool Recipient: Printer, E-mails, fax, intranet, internet [pdf] specify the
name of the program along with the variant.

Variant: It is a predefined value which will be populated during runtime.


These are created in transaction SA38.

Variants are stored in tables TVARV

Variant s are used to avoid user interactions

We also specify external command or program to run in the target system.

Specify the time and save.

Monitoring Background Jobs:

Background jobs are monitored in SM37

Background jobs have the following status:

251
 Scheduled: When it is defined status is scheduled
 Released: When we specify the time to run the status is released
 Ready: Waiting for the background work process
 Active: Actively running the job or program
 Cancelled: Cancelled
 Completed: Job is successfully completed.

User defines dialog process a program/report/transaction to run in the


background mode

Dialog process updates a table TBTCS and TBTST (scheduled)

Scheduler sap message server system (SM61) runs in the dialog mode for
every 60 seconds (default) which is specified by parameter
rdisp\btc_time=60

Dialog Instance
User
Communit
y CI
DB

rdisp\btc_time=60

Scheduler reads from the table and keeps the job in queue based on their
time of priority

Background job gets free work process and runs in the background mode
active

The job is completed the status is finished (or) completed else it is canclled

Text File

Excel File
Legacy
System Text and DB
Purchase Excel File
Order

252
Based on the time IDOC

Background Job Errors:

1. File not found

2. File found but could not be opened

3. File permission problems

4. Background work processes are not available

5. Target syste is not available

6. User ID or password changed (or) password expired

7. Users are locked in the target system

8. Objects are locked (SM12)

9. Table space overflow

10. Connectivity with RFC system fails

11. Authorization to the target system fails (Role is expired)

Standard Background Jobs:

In order to organize the R/3 DB we will schedule the following as


housekeeping jobs.

Periodic Jobs Required for Housekeeping:

ABAP Program Required


Job Name Variant How Often?
SAP_REORG_JOBS RSBTCDEL You must Daily
Deletes old background jobs. create a
variant.
SAP_REORG_SPOOL RSPO0041 You must Daily
Deletes old spool requests. create a
variant.
SAP_REORG_BATCHINPUT RSBDCREO You must Daily
Deletes old batch input sessions. create a
This job may not run at the same time as normal batch variant.
input activity. Schedule this job for periods during which no
batch input sessions are run.
SAP_REORG_ABAPDUMPS RSSNAPDL You must Daily

253
Deletes old dumps produced by ABAP abnormal create a
terminations. variant.
Alternative: To keep from needing to schedule this job, run
the ABAP report RSNAPJOB from the ABAP editor
instead. This schedules RSSNAPDL as follows:
Job name: RSSNAPDL
Variant name: DEFAULT (you must create this variant)
Start time: 0100 AM
Repeat interval: Daily
SAP_REORG_JOBSTATISTIC RSBPSTDE You must Monthly
Deletes job statistics for jobs not run since the specified create a
date (statistics no longer needed since job was a one-time variant.
occurrence or is no longer run)

SAP_REORG_UPDATERECORDS RSM13002 None. Daily


Deletes old completed update records (automatic delete
deactivated); deletes incomplete update records
(automatic delete deactivated)

Run this job ONLY if:


• You have deactivated the default automatic deletion of
update records once they have been processed. This
function is controlled by the system profile parameter
rdisp/vb_delete_after_execution
• You have deactivated the default automatic deletion of
incomplete update records (records that are partially
created when an update header is created and saved but
the generating transaction then ends abnormally). This
function is controlled by system profile parameter
rdisp/vbreorg
• You have deactivated processing of V2 update components
after the processing of the associated V1 updates. This
function is controlled by system profile parameter
rdisp/vb_v2_start.
SAP_COLLECTOR_FOR_JOBSTATISTIC RSBPCOLL None. Daily
Generates runtime statistics for background jobs
SAP_COLLECTOR_FOR_PERFMONITOR RSCOLL00 None. Hourly
Collects system performance statistics

This job was previously called


COLLECTOR_FOR_PERFORMANCE_MONITOR. When
scheduling this job, be sure to use the new name.
RSCOLL00 schedules all reports that need to run for the
performance monitor using table TCOLL to determine what
to run. See the CCMS Guide for more information on
setting up RSCOLL00.

254
Note: Apart from the above we will run the statistics to update tracing
transactions (ST03, ST04)

External Commands: These commands are used to trigger the jobs in the
system. Using commands SAPEVT and SAPXPG (External Programs)

Commands are defined in transaction SM49. It can be executed using SM59.


Some of the commands are

1. Startsap

2. Stopsap

3. BRBACKUP

4. BRARCHIVE

5. Tp

6. R3trans

7. BRRESTORE

Background processes can be configured by parameters rdisp\wp_no_btc

Spool Re organization: The tables TST01, TST03 can held upto a limited
number of entries 32,000. This can be increased up to 99,000. If this number
exceeds the spool mechanism does not work i.e. why spool tables re
organized using the standars background jobs. Schedule background jobs
RSP0041 to delete this spool requests which are older than 14 days by
default

Gateway Process: It is used to monitor the gateway connections make to


instance (SMGW). Gateway process is used to allow the incoming
connections to an instance there will be only one gateway for each instance.
From version 6.40 onwards gateway instance can be installed separately on
a Standalone instance.

SMGW is used o monitor the connections which are coming to RFC, CPIC.

Ex: A service in JAVA system is set to run using a program ID. IN order to
check whether the connection is made to R/3 we need to check the program
ID in SMGW. Gateway process listens on 3300 (Instance number 00)

Spool Process: Spool process is used to print the documents to a printer or a


copy as an Email, fax etc..

255
Spool process is used to generate output request as a device specific
request.

Spool Process Mechanism:

1. User requests through dialog process to print a document

2. User requests through dialog process and schedules a background job


to print documents massively

3. The spool requests are generated by the dialog process (or)


background process and updated in the TEMSE.

TEMSE: Temporary sequential database

These are the spool requests which are generated by dialog (or)
background stored in the location defined by the parameter as follows:

rdisp\store_location=G (or) db

G: Global Directory (O/S level)

DB: Database

DB means it is stored in the table TST01 and TST03

TST01: It consists of the TEMSE details (Spool request, Name of the


author, No of copies, Name of the device)

TST03: It consists of the original data to be printed.

Advantages of Global Directory:

1. It is stored at O/S level

2. Easy to access by the O/S spooler

Disadvantages of Global Directory:

1. For fewer records access time is good, but if the record size grows it
takes longer time to fetch the record from the global directory

2. O/S is not part of the regular back up (printer). If there is any damage
to O/S global directory will be lost all our spool request will be lost

256
Advantages of Storing at DB:

1. Spool requests are backed up along with the DB backup

2. DB features redundancy, consistency, indexing

Disadvantages of Storing at DB:

These are stored in DB. It consumes more time than files stored in O/S
level

File or Database Storage for TemSe Objects?

Type of
Storage Advantages Disadvantages
File system Relatively fast: improved performance. TemSe data must be backed up and
restored using operating system tools,
separately from the database.

In the event of problems, it can be hard to


restore consistency between the data held
in files and the TemSe’s object
management in the database.
Database Back-up and restore with Slower than file system storage. Increased
database tools. Consistency is database load.
ensured.

Definition of Printers:

Printers are defined by transaction SPAD

SPAD stands for spool administration

SPAD is used to define the following:

1. O/P devices

2. Spool Devices (Logical and Real)

3. Access Method (Local and Remote)

Spool Servers:

Go to SPAD

Specify the name of the server

257
Specify the server class

Server class specifies that instance is designated to handle mass printing,


production printing, desktop printing, test printing etc…

Specify whether the server is real (or) logical server

Check on if the server is real (or) logical server

Check on if the server is allowed for load balancing

Logical spool server is mapped to real spool server

Real Spool Server: This is an instance whether at least one spool work
process is configured

Logical Spool Server: This server doesn’t exist but logically defined for load
balancing and handle fail over.

Each logical spool server should be mapped to at least one real spool server

R/3 U TA

LP3 C R/3 LP3 Dialog


Instance
Logical
LP2 System
U TA

LP1 R/3 C
W.P of type Spool R/3

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

DISP

U W0,W1………………
…Wn-1 T.H
C
D.B
R/3

Global Spool
User
Request
Reques TEMSE
data
t TST01/TST03

Author, No of Copies, Device and data

UR TEMSE Spool Request

Output Request
O/S Spooler

Local
O/S Printer
Print Server

Print Server: This is a server in the network where the printers are configured

Local Access Method: If the output request generated by the spool process is
formatted according to the output device and hands over the request to O/S

259
spoolers. The commands Lp or LPR at O/S will analyze the O/P request and
print it local.

Protocols L & C will be used to print the document

Remote Access Method: If the O/S spooler and the O/P request resides from
different hosts, then remote access method is used.

Protocol U is used for UNX based interface

Protocol S will be used for WINDOWS based interface

S is proprietary protocol for SAP

Defining O/P devices:

Go to SPAD

Click on O/P devices

Select the device type

Authorization Group:

It is used to provide additional authorizations to the objects so that the


objects are highly protected

Ex: S_TABU_DIS, S_TABU_CLI should be in authorization role of the user to


provide additional authorizations to the table and client administration

Specify the Access Method:

Front End Printing (P): The printer is connected to the user desktop to print
sensitive document

Disadvantages:

Spool process is dedicated to the user till the job is completed

Print congestion Occur: IF more number of front end printers are configured
try to restrict the no of front end using the parameter rdisp\wp_no_spo_max

We cannot schedule background printing because the system needs to login

Spool Monitoring: Spool processes are monitored in SP01 or can be read as


O/S level using command LP status

260
Go to SP01

Specify * in create

Specify the current date

Specify the O/P device name

It will display the list of spool request

The following are the status of the spool request

1. “–“ (Minus): No O/P request

2. “+” (plus): spool request is being generated

3. Waiting: Spool request is not yet processed

4. Inprocess: Spool request is formatted by the spool process


generating O/P request

5. Printing: The host is printing

6. Complete: the task is completed. The task with status complete


may not be completed because the process waits for the

7. Problem: It monitors the problem related to character formats and


margin settings and page settings

8. Error: it is an error status. The printer has been not generated

Problems in the Spool Request:

1. Printer pages are not available

2. Print cartridge problem

3. Device problem

4. Incorrect page settings

5. Incorrect character formats

6. SAP scripts, small forms alignment is issued

7. Problem in the report

261
8. While configuring barcode printers ensure that right drives are
installed

Configuring of SCOT: (SAP Connector)

It is used t define E-mail server, Fax Server, Internet, SMTP (Simple


mail transfer protocol)

Configuring SMTPClick on internetClick on createSpecify the


name of the nodeDescribe the nodeSelect the RFC
nodeContinue define the RFC destinations

If we select fax, pager, printers (OMS output management system)


we need to install respective drivers

SAP scripts (or) Smart Forms:

These are pre defined print formats provided by SAP. We are


customizing according to our requirements

ABAP list: There are non interactive reports

Define the name of the mail server host on which mail server resides

Monitoring SCOT: As part of regular monitoring the no of requests


which have been sent out from SAP system. The various statuses of
the requests are

1. Waiting: The request is sent to outbound an is in waiting for


processing

2. In transit: the requests are processed

3. Completed: The requests are completed

4. Error: The requests are not sent

SOST: SOST is used to display and manage all messages sent using
SAPconnect.

Depending on the selection criteria chosen, the program displays send requests that are sent or have
already been sent using SAPconnect. A variety of selection and display options are available to you.
For more detailed information about using the send requests overview, see the program documentation in
transaction SOST. To do this, call transaction SOST and choose the info button or choose Help →
Application Help.

262
Go to SOST Select the status waiting, errors, sent and execute to display
the list of transmission requests we can trace error transmission requests
upon resolving the error, the transaction request can be resent, spool
process is configured using parameter

rdisp\wp_no_spo more than one depending upon resources

If a user is only allowed to select send requests of certain users or groups, you can
use transaction SOSG for this. This transaction is the same as transaction SOST,
however it also performs additional authorization checks. To be able to use this
transaction, a user must not have ADMINISTRATOR authorization in authorization
object S_OC_ROLE. Authorization to select users or groups in transaction SOSG is
controlled through authorization object S_OC_SOSG. For more information, see the
documentation for this authorization object. In transaction SOSG, using input help
for the Sender field displays only those users or groups for which the current user
has display authorization.

263
Printer Types:

• Local Printer  The printer is directly attached to the host system.


• Shared Printer  The printer resource is shared to other systems.
• Network Printer The printer is configured in a network (i.e. to a LAN switch) where end users
within the network can use the printer resource.

SAP Printing Techniques:

• Local Printing: The spool server (which contains spool work process) and the host spool system
will reside in the same server.
Host Spool System: The area which contains the spool data

• Remote Printing: The spool server & host spool system are on different servers.
• Front-end Printing: The host spool is in the front-end system itself, the spool data will be stored
in the spool directory of the front-end system.
For front-end printing users must indicate SWIN device name as output devices, indicating the
access method F and the __default as host printer name.

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

Configuring the printer type in the operating system:

Click on Start Menu settingsPrinters and Faxes.

1. Click Add Printer.


2. Click Next & specify the printer type (Local/Network) and all related parameters.

Configuring the SAP printing type:

SPAD 

 Create output device

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

SAP supports only limited number of printers. LP01 is the default printer.

Access Methods:

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

List of Access methods:

SAP Printing Type Access Method(Unix) Access Method(Windows)

Local L C

Remote U U,S

Front-end F

Spool Architecture:

265
Spool Work Process converts the spool request into device specific output stream and sends it to
the host spool or SAPLPD.

SAP profile parameter that controls the no. of spool work processes per instance is
rdisp/wp_no_spo.

Having several spool work processes per instance avoids communication problems between
spool work process and the printing devices which implements spool load balancing by using server
groups called as dynamic spool assignment. Before 4.0 release, the spool server assignment &
spool server work process were static that is only one spool work process was allowed.

Spool Request It is for the print job or output job, made up of spool request record (administrative
information to manage the print jobs) that is it contains the reference to the spool data, output
device and the printing format.

SP01We can see the particular spool request or output request.

SP02 shows list of all spool requests.

266
SP01 Print directly toolbar button ( ) creates the output request.

Output Requests are the components of the spool request which actually formats the output data
and sends it to the host spool system to be printed. You can submit multiple output requests for a
single spool request.

SP01  select the spool request and click on output request button ( ). Shows the list of
output request for the spool request.

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

TemSe DB:

Temporarily Sequential Object Database which stores the spool request data, the
background processing job logs and other texts that are temporary.

Contains two options:

1. TemSe Administration(SP12)
2. TemSe Contents(SP11 or SP12  Go to menu  TemSe contents)

 TemSe DB contains lot of job logs and print data files it is convenient to schedule
the report RSPO0041/RSPO1041 (house keeping jobs) periodically as a

background job for removing and reorganizing the log files.

 TemSe has two main storage options:


Rspo/store_location=DB  stores spool data in the TemSe database.

G  stores spool request data in the /usr/sap/<SID>/SYS/global

 To check the inconsistency of the TemSe DB


SP12  TemSe Data Storage Menu  consistency check (checks TST01 and

TST03 tables). Or using the report RSPO1043.

267
 To reorganize the TemSe database RSTS0022

Spool printing process:

1. End user requested for printing


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

Statuses of a spool output request:

- : Not yet sent to the host system

+ : Spool requested being generated

Waiting : Output request is not yet processed.

Processing: Request being formatted.

Printing : Request being printed by host spooler.

Complete : Request was printed successfully, or transferred to the host spooler.

Problem : The request was printed despite a minor problem, but the output

probably contain errors.

Error : The spool request could not be printed.

Administration Tasks:

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

268
4. Fine-tuning
5. Trouble shooting

Trouble Shooting:

1. Check and monitor the spool work process (SM50), message server working properly and
the OS spool.
2. Find which printer is causing the problems
(SP01  SystemservicesOutput Controller).

3. Check network connections for remote printers.


4. If the print job has been printed out but contains unreadable characters, check device type,
access method.
5. When nothing is output at the printer and the output controller is in wait status, check the
developer trace and the system log and look for time-out messages.
6. If the job has status complete or problem and nothing is output at the physical printer it
might be a wrong output device, problem in host spooler, the physical printer or the SAPLPD
program
7. If printing is very slow it might be lost indexes in the spool tables, too many spool table
entries, slow WAN connections or incorrectly defined access methods.

Summary

SPAD

SP01

SP02

SP11

SP12

TSP01

TSP02

TST01

TST03

TemSe

269
RSPO0041/RSPO1041

RSPO1043

RSTS0022

Rspo/store_location

Rdisp/wp_no_spo

Rdisp/wp_no_spo_fro_max

Access Methods C L U S F

SAPLPD, SWIN

LP01 default printer

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

Common Transport
End
Directory D1
User
Comm
CI CI
unicat D2
ion DB1 DB2

R/3 System Landscape CI

DB1

D3

D4

D5

D6

Go to SM51 to display the list of active servers. This is to ensure that all the
dialog instances are up and running.

SM51 has the following status:

Active and Passive

It is also used to identify describe the type of instance use go to go into the
respective transaction of the instance. There is no need to log in to the path
instance. There is no need to log on to each instance. Double click on the instance it
will navigate to SM50 of the respective transaction.

Click on release notes to identify kernel version path number etc….

SM50: It is used to display the work process over view of an instance. It


displays the following

271
1. Number of work processes

2. Type of work processes

3. Process ID of the work processes

4. Status of the work processes

5. Every work processes has the following status

Waiting, Running, Holding, Terminated

The reasons for the status:

The process is debug mode RFC, Sleep, Priv, none mode

Sleep Mode: If the target system is not available the work processes waits until the
target system is available till that time it will be in the sleep mode.

Private Mode: Each work processes required for certain amount of memory for
execute user transactions. Work process consumes the memory from roll area
initially, if it is not enough it consumes memory from the extended memory. If this
is also not enough it will go into HEAP memory. If all these are not available then it
goes into private mode.

If the work processes goes into private mode it will be released only when the entire
memory is exhausted or transaction is completed.

The parameter rdisp\max_wprun_time has no effect on the work processes in


private mode. The work process which can go into private mode can be restricted
by parameter rdisp\wppriv_max_no

If mote number of work processes go into private mode work process congestion
occurs, users experience hour glass mode.

 Go to dpmon in command prompt

 Go to the option menu

 Display the statistics

Identify the process which is logged in earlier. Inform the project manager about
the termination of work processes. Upon approval terminate the work process.

Restart mode Yes or No:

Error: How many times it went to restart

Semaphore: it is a block in O/S level which the work process is waiting

272
CPU: The amount of time work processes spend utilizing C.P.U resources

Time: Total time of the report user is executing

Client: The name of the client user logged in

User: The name of the user logged in

Action: The type of action to fetch the records

Insert sequentially read, physically read, generate, loaded on which table the
work process accesses.

Double click on t he process to find out what statement it is running

SM04: It is used to display the list of active users of an instance  Select the
user go to menu to display the terminal and amount of memory utilized by the
users such as roll memory, page memory and private memory

Al08: It displays active users of all the instances

SM66: it is used to display process of all the instances

Select the work process double click on it it displays amount of external
memory and heap memory utilized.

SM21: It is used to display the logs belonging to an instance. It is used to route


cause the problem.

It displays the following permissions

1. System start up and shutdown

2. Operation mode switch

3. ABAP dumps

4. Private mode

ST22: ABAP dumps

SAP is programmed in ABAP language. If ABAP program could not be executed it will
be thrown into DUMP. ST22 is used to identify the dumps based on date, time, user,
client.

Most of the ABAP programs errors are related to the following:

1. DB errors

273
2. Table space over flow

3. Max extends reached

4. Archive strucks

5. DB Memory is not sufficient

6. SNAP Shot too old

7. R/3 Error

8. Programmatical Errors

9. Indefinite loop in the program

10.The ABAP program is expensive which consumes more time and Time Out
error occurs

11.When the memory is not sufficient it goes onto dump

12.GUI compatibility

274
Data Transfer:

Data Migration: During the Implementation the data from legacy systems has to
migrate into R/3 systems to continue the business transactions. In order to transfer
the data, data migration client is created in Quality System. Perform a migration.

Performing the Migration:

1. Identify the source data which needs to be transferred (Customer data,


material master data, supplier’s data, vendor master information, employee
master, some amount of transactional data)

Master Data:
It is basic information which is used to carry out transactions in system.

Ex: while creating sales order the customer name is required along with items
and descriptions and quantity

Data migration can be performed later also.

2. Data needs to be parsed (or) truncated and mapped to the target system
fields

3. Convert them into intermediate format (Text file or Excel File)

4. Schedule the data transfer

Data Migration can be performed using the following:

1. LSMW

2. Direct Input

3. BDC

4. Batch Input

1. LSMW: It stands for legacy system migration work bench. It is ued to transfer
the legacy system data into R/3 system. It is a transaction

2. Direct input method: These are standard reports which are used to transfer
the data into R/3 system as and when we required.

3. Batch Input Session: It is a part of LSMW which can be executed as and when
they are required. A session can be created to upload the data using
standard transactions. This standard transaction is recorded with inputs and
it is executed in the background mode. It is used for transactional data.

275
4. BDC: Batch Data Communication: It is used to define the customer transfer
programs based on the requirements. It also used the mechanism similar to
Batch input session, but it is customized using the standard function
modules. Workstation upload and Work station download

There are 2 types of methods:

1. Call Transaction: It is used for 1 time data transfer

2. Session Method: It is used for periodic data transfer

ALE: Application Linking and Enabling

It is used to transfer the data between two loosely coupled systems i.e. from SAP to
SAP systems. In order to work with ALE we need to define the following:

1. Source System (Logical system name)

2. Target system (Logical system name)

3. Define the RFC connections between the two systems (SM51)

4. Identify the interface BAPI

BAPI: Business Application Programming Interface

BAPI: These are standard interfaces defined in the system to transfer the
data from one system to another

5. Go to BD54 or SALE to define sending system, receiving system and define


the distribution model by selecting the respective BAPI’s.

EDI: Electronic Data Interface

It is used to transfer the data between SAP and Non SAP systems.

IDOC: It is an intermediate document which is understandable by both SAP and NON


SAP system’s. IDOC’s are monitored in transaction IDOC and WE05

RFC Communication: (Remote Function Call)

It is used to define the remote connectivity to the target system. RFC’s are used
widely in the following scenarios:

1. Remote client copy

2. CUA admin

3. Data Migration

276
4. Transport

5. Satellite systems in solution Manger

6. Configuring email, fax, pager, SMS and external systems

7. Remote monitoring of instances using alert monitor

8. Connectivity between various components of SAP (BW, CRM, SRM,APO)

Defining RFC connections:

RFC connections are defined in transaction SM59.

Go to SM59 Specify the name of the connection specify the description specify
the RFC destination (mostly logical system name) specify the type of connection
specify the description go to technical settings specify the target host (name of
the host or IP address) specify the instance number gateway host and services
can be specified optionally click on logon security specify whether it is a
clustered system or not specify the authorization and logon details, logon
language, USER ID and password go to special options to trace the RFC 9it’s not
required) save the connections click on the test connections (It displays the
connectivity and connection time) click on remote logon to check whether the
system can login remotely.

If the logon details specified in the RFC connections are correct it will connect the
remote system and opens the logon screen.

Note: Do not give dialog user while defining RFC connections always use either
system or communication user

Go to menu test to check the authorization of the user.

RFC’s are of 4 types:

1. ARFC Asynchronous RFC

2. SRFC Synchronous RFC

3. TRFC Transactional RFC

4. QRFC Queud RFC

Go to SA38 and use report RSRFCTRC to trace the activities of the RFC connections.

1. Synchronous RFC: If a request is sent from a sending system the target


system is available then the data transfer is performed synchronously. If the

277
target system is not available the work process gets in to sleep mode and
waits till the target server is available.

2. Asynchronous RFC: If a request is sent to the target system if the target


system is available then it hands over the request to the target system. The
request will be executed on the target system. If the target system is not
available transaction will be cancelled

3. Transactional RFC: It is similar to asynchronous but a transaction ID is


generated for each of the user request, unlike ARFC it will not leave the
communication with the target system if the system is not available.

A background program RSARFCSE is scheduled in the background for every


60 seconds.

This program identifies all the transaction ID’s which are not sent to target
systems and tries to update for every 60 seconds . TRFC’s are monitored in
SM58

4. Queud RFC: It ensures that the requests are updated in the target system by
following a defined sequence. It is an extension of TRFC. QRFC’s are
monitored in SMQ1, SMQ2, SMQR

Logon Load Balancing:

Instance: It provides executable services and has its own memory, buffers, own
processes.

When more than one instance is configured the following issues may raise:

1. Users logon to instance of their choice

2. Users logon to different instances, buffers are not effectively utilized. In order
to address the above logon load balancing is defined.

Definitions of logon load balancing: In order to define logon load balancing we


need to identify which the components are widely used in the system.

Go to ST07 to identify the mostly used components

Identify the components and the no of users using the components

Go to SMLG define the group and assign instance to it specify the response
time go to SAP GUI click on logo groups specify SID specify the message
server host and click on the groups lost of logon groups are displayed select

278
the logon group save specify the message server entry in etc\services file
create an entry in “sapmsg.ini” files.

SMLG provides the computation of message server. Message server always


keeps the name of the favorite server so that the request will be routed to that
instance.

Advantages of Logon Load Balancing:

Buffers are effectively utilized

Optional utilization of work process of an instance

Logon load balancing

Message server identifies the least loaded server in the logon load balancing and
directs the connection to that particular server

RFC Server Groups: These are similar to logon groups but used for RFC
communications.

Go to RZ12 define server group assign the instance

The server groups are used while defining RFC connections when a request is
sent to the target system which will be sent to the server group. Server group is
mapped with all the available instances. This is used by the RFC request to
identify the least loaded available server.

279
Operation Modes: These are used to define switching of W.P during the
specified intervals.

Ex: During off peak hours there is no need of more dialog work processes which
can be converted into background processes.

Prerequisites:

1. Profiles are imported

2. Define the instances

Defining operation mode:

Go to RZ10 import profiles of all the active instance go to RZ04 define the
instance along with profiles (check location) go to RZ04 define operation
mode (Day, Night, Peak, Off Peak) Assign the instance and configure the no of
W.P for each mode save the operation modesdefine the time schedules of
the operation mode in SM63.

We can define intervals up to 15 minutes. Default it is 30 minutes.

Select the time and assign the operation mode.

Note: During the operation mode switch all the active work processes work till
they complete the job. As part of regular monitoring we need to check whether
operation modes are switched or not.

Go to SM37 and click on expensive jobs. If it is business criteria to change the


operation modes get the approval from business process owner and manually
switch the operation mode.

Operation modes are switched manually using RZ03

Maintaining Profiles:

By default when the system is installed minimum parameters run the instance
are configured. But in order to handle the load configure more memory,
configure more processes, increase the size of the buffers, security settings,
logon client logon language etc. We need to modify profiles from time to time
based on requirements.

Profiles:

The following are the 3 profiles which are installed by default:

The directory that holds the profiles are \usr\sap\<SID>\SYS\profile

280
Startup Profile: This will not be modified unless there is a change in the instance
and instance file system.

Default Profile: This is modified to set the default value for the users like logon
language etc. The parameters which set are applicable to all the instances. This
parameters are over written by the instance profile.

Instance Profile: These are instance specific parameters like W.P configuration
memory configuration

Profile Maintenance: These are maintained in RZ10 transaction code. These profiles
needs to be imported into DB after the installation. This will be done in the following
way:

RZ10 profile import form active server

Defining the monitor set:

Go to RZ20 Go to Extras Click on active maintenance function (on)

Create your monitor set copy from the standard template and adapt the SAP
standard values save the monitor set

In order to modify the properties, variants threshold values  go to RZ21

Dialog Instance 3

Dialog Instance 1

RFC RFC
B/W
RFC

CCMS Agents RFC


CI
SAP CCMS
Dialog Instance 2 R/3
SR
RFC RFC
JAVA
WEBAS CRM

Config Alerts

281
Archiving
It is a process of moving the old data (based on the age of the data) to a data
warehouse solution, to a tape, external device, HSM machines (Hierarchical Storage
Machines).

Reasons for Archive:

1. Aged Data

2. Response Time increase (R/3 and DB)

3. Admin cost (Maintenance, Tapes…)

4. Based on the country specific requirements, the data in the system should be
available for a specific period of time for auditing purpose.

The old data cannot be deleted because it will be used to correlate the data,
analyze the data. It finally helps to forecast the expected business, man power,
material, machines, money and management.

In INDIA the companies are following Bassel-2 for auditing.

Identifying the necessity of Archiving:

1. The database grows abnormally

2. The database fetches are expensive

3. Using indexes is also not suitable to get the optional response

4. The DB requires reorganization

The process of Archiving:

1. Identify the archiving objects

2. Go to DB15 specify the archiving object kike financial documents, material


numbers etc….

Ex: MM_MATNR, FI_DOCUMNT

3. Functional consultants identify the objects based on the modules and inform
us to archive

4. Find the size of the table (RSTABLESIZE)

5. Define the archiving path

282
6. Go to file (FILE_Tcode)

7. Define the logical path Assign physical path (Global


Directory)\usr\sap\SID\sys\GLOBAL (Cross Client)

8. For client specific use T-Code SM01

9. Go to SARA identify the object select for archive

10.Define the variant (Name of the variant, time)

11.Status options are Archive, Save, Delete, Write

12.Data reorganization needs to be followed after archiving

The third party tools like IXOS, DWB2000, BIW are used for the archiving purpose.

As part of regular monitoring we need to monitor the archiving background jobs in


SM37

283
GUI (or) Front End time:

It is the time taken by the user request to reach the dispatcher. GUI time is not part
of response time. GUI time should generally be around 200 m/second

Check the network connectivity to application server

Wait Time:

The time taken by the user request waiting for Work Process it should be around
500 m/sec i.e. 10% of dialog response time.

Reasons is no free work process is available

W.P’s are running expensive programs transactions, reports………

The time taken for roll-in of the user context information by the W.P.

The roll in time should be 500 M/sec

It is assumed as used context information is expensive. Reduce the no of


authorizations parameters and ask the used to restrict the queries.

Response Time:

The time taken for processing a user request and returning the data to the
presentation server. Response time will be continued from the movement when a
presentation server request is reached to the dispatcher.

Note: GUI time and CPU time are not part of the response time.

Process Time:

It is the amount of time required to process the user request by interpreting (ABAP,
Screens, SQL Statements).

If the processing time is more we need to analyze ABAP statements, expensive


screens etc…

Processing time in not measured directly. It should not be more than twice the
amount of CPU time

Process Time ≤ 2* CPU Time

CPU Time:

It is the amount of time taken by the work process utilizing CPU resources while
processing the user request.

Generally CPU time should not be greater 40% of (Response Time – Wait Time)

284
If CPU time is expensive then ABAP programs are expensive. Tune ABAP programs.

Run time analysis of the program

The CPU time is expensive because of the following reasons:

1. Expensive programs (Inefficient Coding)

2. Internal tables could not handle the data files

3. Indefinite loops in the program

Perform the run time analysis of the ABAP programs. It is done by the developers.

Load & Generation time (LG Time):

It is the amoun ot time taken to load and generate the programs. Normally it should
be 100 or 200 nano seconds. If LG Time is more we can consider the following

1. Buffer areas are configured with small size (Increase the buffer size)

2. Buffers are swapped

RFC+CPIC time:

CPIC: Common programming interface for communication.

It is the amount of the time taken by the work process to communicate with
external systems like BW, CRM, SRM etc….

Generally the time is not defined because it varies from system to system

Enqueue Time:

The amount of time taken by the dialog process to communicate with enqueue
process to obtain the lock while updating records. Normally it should be 1 m/second
in the central instance.

It should not be more than 100 m/sec if the request is coming out from dialog
instance. "enqu_ tablesize” is the parameter which is used to define the size of the
enqueue table.

Database Time:

It is the amount of time taken by the database to process user request. It should not
be more than 40% of (Response Time – Wait Time).

If it is expensive we can conclude the following:

1. Expensive Report: With expensive SQL statements

285
2. Database Statistics are outdated: Run the statistics using DB13

3. DB buffers are not sufficient: Increase the buffer size (ST04) or using he
parameter

“db_block_buffers” in initsid.ora file at the O/S level.

4. Missing Indexes: Indexes are missed out which can be traced out in DB02
(Recreate indexes, Create appropriate indexes). One primary index and upto
5 secondary indexes

5. Exclusive Lock waits on the DB: Go to DB01 and find out exclusive lock waits

Response Time:

It is the sum of all the above mentioned times i.e. Wait Time+ Roll Time+ Roll Out
Time + Processing Time + Load and generation Time + Enqueue Time+ (RFC +CPIC
) Time+ DB time

Work Load Analysis


It is used to display the work load on the system based on time.

It is also used to display the following:

1. Response times of the processes

2. Response times of the users, reports, transactions etc…..

Time profile gives you the time consumption based on each component.

In order to populate information into the screen ST03 we need to run standard
background jobs.

ST01: System trace

It is used to trace the following:

1. RFC trace

2. Buffer Trace

3. Authorization Trace

4. SQL Trace

5. Enqueue Trace

6. Kernel Trace

286
These need to be explicitly switched based on the requirement.

Switch off the trace as soon as the tracing is finished else it will populate the log
files.

ST02: Memory configuration Monitor:

ST03: Work Load Monitor

ST04: DB performance Monitor

ST05: SQL Trace

ST07: Application Monitor

It is sued to find the following:

1. No of application servers

2. No of W.P in the entire R/3 system

3. Total no of users created in the system

4. The components and the load on the sytem

ST08: Network Monitor:

ST14:

287
DATABASE
Normalization:

It is the process of splitting of larger tables in to smaller table by enacting primary


keys, foreign keys and secondary keys relationship.

Various DB Vendors are:

1. Oracle

2. SQL Server-Microsoft

3. DB2 – IBM

4. MAX DB- SAP

5. Informix- IBM

SAP gives an interface to work on above mentioned systems.

SAP never recommends working on the DB directly

KDB (database), a database server created by Kx Systems for real-time business


applications

KDB, a Kernel debugger, a type of tool used for debugging the kernel for Linux and
Unix

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

• The Windows NT family of operating systems contain a kernel debugger.


• BeOS contain a kernel debugger.
• DragonFly BSD employs a built-in kernel debugger.

No kernel debugger was included in the mainline Linux kernel tree prior to version 2.6.26-rc1
because Linus Torvalds didn't want a kernel debugger in the kernel

KGDB and KDB are two kernel debuggers for the Linux kernel. KGDB requires an additional
machine for debugging, whereas KDB allows the kernel to be debugged on the same machine
while the kernel is running. The debugger included in Linux is KGDB.

IBM- AIX, HP-AUX are KDB

288
Windows 30-40% KDB

Linux- No KDB

When the ORACLE DB is installed it is installed by default with the following Users:

1. SYSTEM (user)/MANAGER (Password)

2. SYS (user)/ Change_on_install (password)

When R/3 system is installed the following users will be created in the DB.

1. SAP R/3 up to 4.6c

2. SAP<SID> from 4.7 onwards (SAPSID is the schema owner)

3. SAPSR3 DB in new dimensional products like XI, EP….

SAPR3, SAP<SID> and SAPR3DB are the schema users of the DB

Apart from the above we have

1. Ops$<host name>\ <SID>ADM

2. Ops$<host name>\SAPSERVICE<SID>

Query:

A normal sql query looks in the following way

Selest * from DBA_Users;

Roles:

Roles provides authorizations to the users

1. SYSDBA:

It provides authorizations for the following activities: system startup, system


shutdown, create DB, Modify DB, Create users, roles, tables etc……

SYSDBA has the entire authorizations from the DB

2. SYSOPER: He is an operator to start the DB and stop the DB Back up, Restore
except creating DB

If a user connects as SYSDBA, he becomes SYS, if he connects as SYSOPER, he becomes PUBLIC.

First, we connect sys as sysoper:

289
Connect sys/my_secret_password as sysoper

Who am I?

SYS@ora10> show user

Same thing, but connecting as sysdba:

Connect sys/my_secret_password as sysdba

Who am I?

SYS@ora10> show user

USER is “SYS”

Now, I, being Rene, want to connect as sysdba and then as sysoper. In order to do so, I need to have
the sysdba and sysoper privileges:

Grant sysdba, sysoper to rene;

Now, I can connect as sysdba:

Connect rene/another_secret_password as SYSDBA

Who am I?

SYS@ora10> show user

Altough I have connected myself as Rene, giving my (not sys') password, I am sys:

USER is “SYS”

As sysoper:

Connect rene/ another_secret_password as sysoper

Who am I?

SYS@ora10> show user

USER is “PUBLIC”

SYSDBA and SYSOPER are administrative privileges required to perform high-level


administrative operations such as creating, starting up, shutting down, backing up, or recovering
the database. The SYSDBA system privilege is for fully empowered database administrators and
the SYSOPER system privilege allows a user to perform basic operational tasks, but without the
ability to look at user data.

The SYSDBA and SYSOPER system privileges allow access to a database instance even when
the database is not open. Control of these privileges is therefore completely outside of the
database itself. This enables an administrator who is granted one of these privileges to connect to
the database instance to start the database.

290
You can also think of the SYSDBA and SYSOPER privileges as types of connections that enable
you to perform certain database operations for which privileges cannot be granted in any other
way. For example, if you have the SYSDBA privilege, then you can connect to the database
using AS SYSDBA.

The SYS user is automatically granted the SYSDBA privilege upon installation. When you log
in as user SYS, you must connect to the database as SYSDBA. Connecting as a SYSDBA user
invokes the SYSDBA privilege. Oracle Enterprise Manager Database Control does not permit
you to log in as user SYS without connecting as SYSDBA.

When you connect with SYSDBA or SYSOPER privileges, you connect with a default schema,
not with the schema that is generally associated with your user name. For SYSDBA this schema
is SYS; for SYSOPER the schema is PUBLIC.

Two very special and important system privileges are SYSDBA and SYSOPER. Following table describes the

power lies beneath these two system privileges.

SYSDBA

Create new database

Startup, Shut down database

Alter database with the OPEN, MOUNT, BACKUP, CHANGE CHARACTER SET, ARCHIVELOG and

RECOVER options

Create SP file

SYSOPER

Startup, Shut down database

Alter database with the OPEN, MOUNT, BACKUP, ARCHIVELOG and RECOVER options

Create SP file

Example:

CREATE ROLE hr_emps;

GRANT SELECT, UPDATE

ON emp_test

TO hr_emps;

GRANT hr_emps

291
In this example we have first created the role hr_emps and next we assign certain privileges to it and finally

we have assigned it to all the employees of hr (Human Resources department). After a month, new business

rule comes up which says that all the hr employees should only be having SELECT privilege on emp_test

table. To implement this rule all you have to do is to revoke the privilege from the role e.g.

REVOKE UPDATE

ON emp_test

FROM hr_emps;

Database Startup:

Database is started and stopped by using the following commands

1. Startdb

2. Stopdb

It can be started as a part of SAP

“Stopdb” will stop the database.

When the database is started it looks for port 1521.

This port is configured for listeners. More DB’s ,ore ports.

Listner.ora: This file is used to configure the database and the port number. This
can be configured by using the SQL net configuration. It reads from file
“TNSnames.ora” to resolve the database.

Listner Status:

Use command “lsnrctl” to check the listener status.

1. Go to home directory by logging as <SID>adm. Use command “lsnrctl”


listener control n the command wondow

<listener>prompt appears. Type status

Listener> status

If it is not started give <listener> start

“listener.log” is located in the home directory.

292
This gives the information about listener port blocked and why it is not
starting.

2. SQLNET_ORA: It consists of the server details. It is required on dialog


instance.

Environmental Variables: When the oracle database is started it looks for


ORACLE_HOME

ORACLE_HOME is the environmental variable which we need to set up as user type


in the central instance and all the dialog instances.

Path: Path needs to be set up for ORACLE_HOME/bin

ORACLE Start Up Process:

Oracle is started up in the following modes/phases

1. No mount phase: During this phase initialization files are evaluated. SGA is
created. The database is not appended and it is not operational. It is used to
build the control files and restore the control files. DB is not mounted.

2. Mount: The DB is mounted. SGA is created but the data files are not opened.
It is used to restore the data files. DB is operational only for few users like
SYSDBA

3. OPEN MODE: The DB is open. The users can logon to the system.

SHUT DOWN the DB:

The database can be shut down by using the following.

1. Shutdown normal: When this command is issued no users will be allowed to


connect to the DB. Existing users will continue their work. If these users
logged off the system will shut down normally.

2. Shutdown immediately: No new users are allowed. Existing transaction will be


completed and wither a commit or rollback takes place. In shut down normal
the DB will be consistant while restart the DB

3. Shut down abort: The system will shut down without any notification to the
users. All the open transactions could not be completed or rolled back.
Therefore the system inconsistent. A small process SMON will perform instant
recovery during the restart.

4. Shutdown transactionally: Open transactions are allowed to complete and no


new transactions are allowed. The DB consistent after restarting DB.

OPS$ mechanism: Oracle parallel server

293
It is a mechanism which allows the O/S users to connect to the DB without any
password provided that the following parameters are set in init<sid>.ora

1. remote_os_authen= true

2. os_authent_prefix= OPS$

init<sid>.ora: It is a file that contains the DB startup parameters control file


location log and SGA [SSA, log, DB_buffers]

Modifying this profile requires instance restart.

Init<SID>.sap:

The initialization profile init<DBSID>.sap contains parameters that influence how the SAP tools
perform various functions. It is usually stored in directory <ORACLE_HOME>/dbs (UNIX) or
<ORACLE_HOME>\database (Windows).
This specifies the things like back up type, back up device tape size, tape copy
command and mostly related to BRTOOLS for backup and recovery.

To configure the SAP tools BRBACKUP, BRARCHIVE, BRRESTORE, and BRCONNECT,


you must use the initialization profile init<DBSID>.sap. You can edit the file with a
text editor. If you do not make any changes, the SAP tools use the default values for
the parameters.

Before you use one of the SAP tools, find out exactly which parameters you have to
configure. Pay particular attention to parameters without default values and
parameters that have device-specific information or require special platform-
specific commands.

Init<SID>.dba: This is used to look up when users withy DBA privileges is logged
on to utilize

1. brtools

2. SAPDBA

Modifications to this file are performed by the system, whenever the privileges are
modified.

Both the Oracle and SAP parameter files are usually found in $ORACLE_HOME/dbs.

Work Process Connectivity Mechanism:

1. User starts an instance

2. OPS$ mechanism is used to connect to the DB, without any password


(SAPSERVICE<SID>)

294
3. Service user connects to the DB without password and gets the password for
Schema Owner which is residing in the table SAPUSER

4. Sapservice<SID> is the owner of the table sapuser. SAPUSER table consists


of only one entry schema user ID and password. In sapuser table password is
stored in the encrypted format

5. OPS$ user gets the password from the SAP table and disconnects from the DB

6. Work process reconnects with SCHEMA ID and password. The work processes
is connected to the DB.

Note: To check the connectivity between work processes and DB use the command
R3trans-d. Trans.log is created current directory. Go to AL11 go to Work directory
then check dev_w0, dev_w1……

7. SAP schema ID password is stored in two tables “SAPUSER” and “dba_users”

8. Changing the password at DB level will not work for SAP<SID> because it is
stored in two tables. Use SAPDBA tool or brconnect to change the password
of SCHEMA ID (AL11, ST11)

User requests a report from the database. R/3 work process cannot work on the
database. Instead it will assign the task to shadow process of DB.

Shadow process checks the following:

1. If the statement was executed earlier

2. If the table is existing or not

3. The fields are existing or not

4. It will check the DB and defines the shared pool size, nearest plan to SQL
execution to fetch the data.

5. Based on the execution plan shadow process requests the content form the
DB

6. The content is fetched into DB buffers from storage and responded back to
the R/3 buffers.

7. If the same request comes again it will fetch from the DB buffers.

Update Request:

1. When a user requests to update a transaction work process hands over the
request to shadow process

295
2. Shadow process checks or table definitions and goes to the DB to update the
DB buffers and DB records

3. Shadow process fetches the content to be updated onto DB buffers

4. While getting the content it will try to get the lock so that the records will not
be modified by others

5. In order to roll back during instance crash, the content is written to undo
segments

6. The contents needs to be modified are copied into log buffers

7. User shadow process updated the records in log buffers. Once it is committed
it will move to DB buffers and the content is marked as Dirty Buffers.

8. In order to save the transaction it will be updated to log files log writer
process (LGWR).

9. After check point interval DB writer reads the contents from th DB buffers
and updated the DB and sends a request to process monitor (PMON) to
release the locks and undo segments. Data will be released after
undo_retention_time (parameter in init<SID>.ora)

10.If the instance is crashed abnormally system monitor (SMON) will read the
content from the log files (DISK) and updates the DB. This is called as roll
forward mechanism.

11.If the content is not updated in the log files (transaction not committed)
PMON performs roll back mechanism and releases the locks.

SAP Directories:

SAP Trace: It is used to write the traces by the system “alert<SID).log is the file
which is populated continuously logged or documenting important activities like log
files which changes in the parameters etc…

SAP Check: This will be populated when the following commands are issued

1. Sapdba-check

2. Brconnect fcheck

It logs the following information:

1. File name s and file paths

296
2. Critical files and their size

3. Table space information

SAPARCH:

It is used to write the log files generated by BRARCHIVE process

ORAARCH:

It is used to store the archive files written by ARCH process. The archive logs are
coming from origlogA and origlogB to ORAARCH. It should be large enough to avoid
archive struck problem

SAP BACKUP: It is used by system whileperforming reorgqanization. It should be as


big as the size of the exported content. ( Tables ,DB, Table Spaces)

Origlog A & B:

These are the log directories which are populated by log writer from log buffer. This
files are read by t perform “role forward mechanism” by SMON in case of an
instance crash

Mirror Log A and Mirror Log B:

These are the mirror copies of the above log files

SAP data1, data2….datan

These are the physical storage locations of the DB. Data files are located in the
directories.

Control Files:

These files are required to restore the DB. These fies are written and updated by the
system continuously.

Information like database changes made to data file, storage locations, log
sequence number, system change number.

losing the control files will not allow to restore the system file. So it is recommended
to store the control files in six different physical locations

To find the six physical location go to init<SID>.ora and add the control file
location.

DB buffers are used to store the content accessed by the server process (Shadow
process) or background server process.

DB buffers are configured by parameters “db_block _buffers”.

297
DB buffers help to reduce the fetches from the database.

Log Buffers:

It is used to log the changes made to the database content. It only documents the
log block which needs to be modified along with the content. Log buffers help to
write the changes using fast track mechanism and transactions commit will be
configured only after writing to “online redo log files “.( Original logs)

Log Writer: (LGWR)

It is the process used to write from log buffers to “Online redo log files” (origlog
files). Log worter triggers under the following circumstances

1. Whenever 1/ of the log buffer is full

Note: Log buffer size is determined by log_bufer (20 MB)

2. Whenever the changes reaches !MB of size

3. Whenever commit occurs

4. Before the DB writer writes the DB from DB buffers

5. Log buffers are cclic buffers

6. Log buffers are sequentially written to online redo log files

Database Writer (DBW):

It writes the contents (dirty buffers) from DB buffers to DB. It is triggered during the
following circumstances.

1. Whenever check point occurs

Note: check point interval is defined in init<SID>.ora

2. Process scans for space I the DB buffers. If it could not find them it triggers to
write the dirty buffers to database

3. Dirty buffers in the DB buffers reach threshold values. It is depending on


init<SID>.ora. it happens to every 30 seconds

Log Switch:

There are two online log files (origlog A and origlog B). These log files are
continuously updatd by log writer process from log buffers. If orig logA is full it will
be closed for writing and logB will be opened for writing. This mechanism is called
log switch. During the log switch log file number is incremented (LSM- Log sequence
number).

298
ARCH process:

The process of writing online redo log files into “ORAARCH” directory is called as
“ARCH process”. This is done by ARCH process.

In order to have this mechanism to work we need to set paramenter


ARCHIVE_log_mode=yes”

The database administration will set this parameter to YES in all the productive
systems. This mode can be set to NO or FALSE in quality and development systems.

ARCHIVE_log_mode can be set up in SAPDBA or BRTOOLS.

SMON:

In case of instance crash it is used to restore the DB from log files(role forward
mechanism) and rolls back is committed.

PMON: Process Monitor

It is used to rollback the user transactions and the locks held by the users.

Data1….datan files:

ORACLE database is stored in the hard disk in terms of blocks. Each block can
consists of either 4KB or 8KB. SAP uses 8KB.

The size of the block is determined by the parameter db_blocksize=8192 bytes (8


KB).

Extents:

The continuous blocks are allotted in terms of extents. Extends a group of blocks.
Extends are assigned in terms of init extents, minimum extents, nest extents and
max extents.

The extents allocation is stored in tables based on their category of tables TGORA
(Tables)& IGORA (Indexes)

Segments:

Group of tables or indexes (It can be a single table or index or a group of tables)

Table Space:

It is logically defined to store the tables and indexes. Each table space is pointed to
N number of physical data files. But data files can be pointed to only one table
space.

299
When table space is created using the statement create tale space we need to
specify the size of the data file. If the table space is full the data files are full and
the data cannot be inserted or updated.

Note: If the table space is full we get an error ora_1653 and or_1654 table space
overflow. In this situation we need to alter the table space by using commands

SQL> alter tablespace add datafile;

SDL>alter tablespace resize datafile;

Note: SAP never recommends to use the above commands in turn it recommends to
use SAPDBA/BRTOOLS where knowledge on SQL commands is not required.

Extents Allocation:

For each of the tables extents are allocated based on their category referring to
tables TGORA & IGORA.

When a table is defined it is assigned wit initial extents. When the assigned extents
are reached it will throw an error. “max extends reached” with an error ora1631
(Related to the tables) & ora 1632 (Related to Indexes).

Use SAPDBA/BRTOOLS to extend the extents.

Note: All the above errors will be resulted in ABAP dump and logged in SM21 and
ST22.

Note: For all NETWEAVER 2004 components maintenance optimizer is necessarily


installed

Table Spaces:

There are 2 types of table spaces

1. DMTS: Dictionary managed table space (Up to version 9)

2. LMTS: Locally managed table spaces

DMTS: The space cannot be utilized because it cannot be reorganized. But in LMTS
unused space can be automatically reorganized. There is no need to adopt next
extents (SAPdba_next).

In 4.6c we have around 27 table spaces which start by default with PSAP and ends
with either data or index LDP

Ex: PSAPRABD, PSAPTABI

From 4.7 EE we have six table spaces

300
1. PSAPUNDO

2. PSAPTEMP

3. SYSTEM

4. PSAP<SID>

5. PSAP<SID><Rel No> Rel No: Release Number

6. PSAPUSR

PSAPUNDO TABLESPACE:

It is used to store the before image of a transaction. It should be large enough to


hold a complete transaction. PSAPUNDO replaces PSAPROLE and it holds the data
until it is full or until the value mentioned in undo_retention_time.

PSAPTEMP TABLESPACE:

It is used to sort the data. It should be large enough to sort the data.

BACK UP:

In order to restore the database in case of failures (Media Disasters) media failure
means logical errors, disk crash, power crash etc…..

In order to restore the DB we require a valid back up. The areas which need to be
backed up are

1. USR is required in R/3.

2. Data Files

3. Log Files

4. Control Files

Types of Back Up:

1. Off line backup

2. Online Back Up

3. Incremental Backup

4. Partial Back Up

301
1. Offline Back Up: The backup will be taken off line, users are disconnected and
the R/3 system is shut down. The backup is consistent to restore the
database.

Note: We do not take regular off line backup (Take during off peak hours).
Mostly the companies which are not supporting on line back up.

Off line backup can be performed using SAPDBA tool or O/S backup,
BRTOOLS, Native database backup and 3rd party tools like VERITAS,
BRIGHTSTORE, ARCSERVE, IBMTEVOLI>

BRBACKUP can also e scheduled through command window or using crips.

Brbackup –mt offline, brbackup –m dev verification. (mt, m are scripts).

2. Online Backup:

In an environment where database shut down is not supported we perform


online back up. Online backup is by default is not consistent, but consistent
along with the log files. This is also called as “consistent online backup”.

3. Partial Backup:

If the database sizes are very huge we can perform backup individually based
on tables, table spaces etc…

Partial backup is used in this particular case. If we want backup of recent


data then also we can do the same thing by using the partial backup.

4. Incremental Backup: IF the DB size is terabytes taking the entire DB backup


either offline or online will consume more time. We will take full backup either
weekly or monthly (called as Zero Backup) and subsequently everyday
perform incremental backup that is only changes made after the zero
backup.

Backup Life Cycle:

General back up life cycle is 30 days. But SAP recommends 7*4=28 backup.

Weekly Backup: w1, w2, w3, w4, w5

Monthly Backup: M1, M2, M3, M4, M5

Tapes Management:

1. Ensure that we have enough tapes in the data center

2. Check the consistency of the tapes at least once in the backup life cycle.

302
3. Allow the tapes to fill only up to 90%

4. Check the tape compression ratio at least once in the backup life cycle.

5. Keep at least 30% tapes in reserve

6. Monitor the DB growth from time to time and plan the capacity of tapes.

Optimizer:

It defines the execution plan to fetch the data from the DB.

There are two optimizers:

1. Cost Based Optimizer

2. Role Based Optimizer

SAP uses cost based optimizer which is set by parameter cost based optimizer to
true. It is set in init<SID>.ora.

SAPDBA & BRTOOLS/ BR GUI:

These are character based interface tools where users can work on DB without
being a DBA.

SAPDBA is applicable up to WEBAS versions 6.20.

Functions of SAPDBA:

1. Start and Stop the instance

2. Instance specific information

3. Table space administration’

4. Reorganization

5. Users ad Security

6. Backup Restore & Recovery

7. Change the archive log mode

8. Switching logs

Regularly We Do (In DB concern):

Table space administration:

303
When you click on SAPDBA or execute from command prompt a black window is
displayed. Before displaying it checks init<SID>.dba whether the user has
necessary privileges to run SAPDBA tool. If the user doesn’t have privileges it will
not be displayed.

Privileges to the user can be provided by using the following command:

Ora_dba_usr.sql in the kernel directory.

Select the option c for going to table space administration. It displays all the table
spaces along with their allocated space and percentage of space utilized.

When the errors ORA1651 & ORA16534 occurs we do this based on the companies
threshold values. If its exceeds use DB13 to give SAPDBA –check

Now select the critical table space and add data file to check the disk space before
adding the data files. You are supporting versions earlier than 4.7EE you need to
decide the drive and directory where data files belonging data/indexes are added.

The above processes is documented and ensure that we read documents


completely before performing the above exercise.

Table space overflows can be handles by recycling the data files.

Select the option D reorganization select the table pace and data file and resize
the data

User & Security:

It is recommended to use SAPDBA tool to change the password of schema owner.

Select option M “Users & Security” and navigate to change the password of
schema owner.

Note: Do not try to change the password of schema owner using command alter
user id identified by password

Because the password is stored I sapuser and dba_user

BRTOOLS:

Backup restore tools:

Brtools/brgui(JAVA based GUI)

Brtools provide various functionalities similar to sapdba but with extensive


privileges like create table space, drop tablespace.

Some of the BRTOOLS are

304
1. BRCONNECT

2. BRBACKUP

3. BRRESTORE

4. BRRECOVER

5. BRARCHIVE

BRBACKUP:

It is used to schedule whole offline backup, online backup etc…

We can initialize brbackup from the command line or using DB13.

Go to DB13 (DBA calendar) select the data right click  openselect the option
to backup the database

Note: Database backup is performed by using brbackup.

We can also schedule at command line using SM69 & SM49 or a batch script can be
used to schedule the back up.

BRARCHIVE:

It is used to backup archive log files from ORAARCH directory. BRARCHIVE uses to
tape or disk, BRARCHIVE uses various technologies to safeguard the archive log
files.

We can see ARCHIVE stuck in SM21 & ST22.

1. CDS: (Copy Delete Save) BRARCHIVE process copies to the tapes twice and
deletes the log files from the ORAARCH directory. If the BRARCHIVE is not

When the archive struck occurs archive process cannot archive on line redo log
files. Log switch fails and log buffers also gets filled because log writer could not
write to redo log files then the user encounters hour glass problem.

Resolving the Archive Struck:

Create a dummy file of at least 500 MB in the ORAARCH directory (UNIX).For


windows copy dummy file of 500 MB into ORAARCH directory. Whenever the
problem occurs delete the temp dummy files, so that users can start working they
will stop screening. Schedule BRARCHIVE to copy into ORAARCH in to tape or disk.

Note: Do not delete or move the ORAARCH contents manually to any other physical
location.

305
Note: Backup type (off line, on line) back up type2, type 2 copy command. Tape
size… are configured in init<SID>.sap

BRRESTORE:

BRRESTORE is used to restore the BACKUP from the database created by


BRBACKUP. The tapes should be tagged and released.

BRRECOVERY:

It is used to recover the database from a Point of Time.

Example: I am applying support packages and the system struck/corrupted at 3 P.M


on 01/02/2010

Daily: I have a valid back up of last night which was taken at 3:30 PM

Hourly: I do have a BRARCHIVE back up which was taken at 2:30 PM

1. BRRESTORE: Getting the system up 3:30 PM

2. BRRECOVERY: restore the system up to 8:30 PM and recover the system until
time 2:30 PM (or) specify log file (1:30) to restore from log files.

3. BRCONNECT options:

The following are the options available with the BRCONNECT tool.

1. BRCONNECT –f next

2. BRCONNECT -f check House Keeping Jobs

3. BRCONNECT –f state

4. BRCONNECT –f clear old

1. It is used to adapt next extents a SAPDBA 6.20 version next

Also close the same function schedule this activity using DB13 at least
once in a day.

2. BRCONNECT –f check: It is scheduled based on the requirement but at


least once in a day. This job populates the directory SAP check with all the
data files along with this space utilization.

3. BRCONNECT –f status: It is used to perform to two fold jobs. In SAPDBA we


used to use

306
i. SAPDBA –psap%

ii. SAPDBA – check  Earlier Versions

This job identifies the tables whose statistics are outdated and in the
next stop it will update all the tables.

DBSTATIC: The table which is used to populate the tables whose


statastics are outdated. It is scheduled at least in a weal using ” .dbb”,
“.bat”, “.chs”, “.ksh”.

4. BRCONNECT –f clearold: It is used to clear thr old log files

Note: BRCONNECT is also used to change the password of SCHEMA

SAP Reorganization:

The data is populated into the DB. As the data grows the query times also degrade.
Moreover there are some extents (Which is unused). There will be around 20 to 30%
of space which is unused on database to effectively use the unused space. Perform
reorganization from time to time.

Reorganization will be performed by Export and Import of the DB.

 Go o SAPDBA Select the option “D” reorganization select export to export


the database to SAP “reorg” directory

Note: SAP reorg directory should have enough space to hold the data.

Reorganization can be performed on larger table space and tables. During


reorganization we need to schedule down time.

SAP standard transactions for DB:

DB01: It is used to find out logs. As the regular monitoring activity we need
to monitor DB locks.

DB02: As the regular monitoring activity we need to display the following. It


is used to display the following

1. Statistics

2. Display the current sizes of the table spaces along with used space.

3. It also displays the free space statistics like (Used, Unused space…..)

307
4. It will display space critical objects

5. Handling missing indexes

Go to DB02 find the missing indexes select the missing indexes click
on creating DB(or) go to SE14

DB12: It is used to find the backup logs. It displays over view of the back up
and backup os successful or not. It also displays archive directory space.

DB15: It is used to select the archiving objects of SAP.

DB17: The check conditions can be customized. The same can be done using
BRCONNECT –f check

DB20: It is used to edit the statistics. The statistics will be updated only for
transparent table.

DB24: Operations log Monitor

Whenever the check performed it will log in DB24

Type of O/S: AIX, AS/400, HP-AU (11.11), OS/390-Mainframes, Solaris

Communication: Special connection between CI, DI using optical fibers

PAM  Product Availability Matrix

PA-USER-Personal Admin-(Pay check, leave)

Pd-USER- personal Development (related to transport)

It is the program (portal) which is used to send the change request into multiple
systems and multiple clients. ETC is used to point to target groups rather than
systems.

Buffer Management:

Buffers are stored in terms of directories in the memory. When the system is started
the buffer areas are allocated based on the profile (Instance Profile).

Buffers are built up in respective areas when the users access the content from the
DB.

Buffers are monitored in ST02.

Buffers are managed in to space and the directories and space. If any one of them
is full swaps occurs.

308
The performance of the system could not be gauzed initially because the buffers are
not built.

System performance will be increased if sufficient buffers are maintained.

Do not measure the performance soon after starting the system. Wait for at least 20
to 25000 transactions take place.

Buffers Hit Ratio: It should be always greater than 94%. That is out of hundred
requests 94 are fetched from buffers.

SWAPS: Whenever the objects are changed or buffers space is fully utilized or if
directories are not enough swaps occurs. Swaps don’t mean a performance issue
but try to avoid more no of swaps by configuring enough space and directories.

Most of the companies allow 5 to 10,000 swaps normally.

Reasons for SWAPS:

1. Frequent transactions of objects will cause swaps

2. Space is full

3. 3. The directories are full

4. When the program changes

Table Buffering:

By default SAP defines buffering for the pre defined tables.

Some of the tables are not allowed for buffering

Some of the tables are allowed for buffering but buffering is switched off.

For some of the tables buffering is allowed.

Go to SE14 Check buffering is allowed or not

The tables which are frequently accessed but rarely changed are allowed for
buffering.

Ex: TACT, T000, calendar tables

 Go to technical properties of the tables  no buffering (For tables which are


frequently changed and rarely accessed)

 Full buffering: The tables which are frequently used but rarely changed

Single Record Buffering:

309
The buffering is based on primary key

Generic record buffering:

It is based on group of fields.

Note: Do not change buffering status unless recommended by SAP notes.

The elements eligible for buffering are programs, menus, screens, common user
attributes, calendars, measurements tables, time settings.

ST02 will get the above information.

Memory Management:

While installing SAP system virtual memory needs to be configured based on


available memory.

Physical Memory: It is the amount of memory installed on the system (RAM).

Phy_mem_size is the parameter that shows the physical memory size.

Virtual Memory: It is the sum of the physical memory and space allocated on the
disc

Extended Memory: It is a part of virtual memory which is utilized by R/3 instance.

Roll Memory: The amount of memory required by the work process to roll in and roll
out the user context.

Heap Memory: It is a private memory part of virtual memory.

Local Memory: The memory assigned to work process to handle the user request. It
is defined by parameter ztta\rool_area

Parameter to configure heap memory is abap\heap_limit

Memory allocation to Work Processes: When the user request is assigned to W.P it
will utilize an amount of memory which is specified in the parameter
zttz\roll_first=20 KB (It is a part of roll area).

If the memory is not sufficient it will use external memory up to an extent which is
defined in ztta\roll_extension=

If this memory is also not enough it will use the remaining part of the roll memory. If
this os also not sufficient it will use heap memory (Private memory). If the W.P
reaches heap memory it is restricted and time out paremeter will not be applicable
to it.

310
The work process will be released only after completions of the task or heap limit is
exhausted. Specified by parameter abap\heap_limit, abap\heap_area_dia,
abap\heap_area_nondia

If more no of W.P goes into private mode W.P congestion occurs. In order to resolve
this use “dpmon” to identify the expensive process and then kill the process.

ST02: It s used to find the amount of roll memory extended memory, roll memory,
heap memory

Always monitor ST02 for heap memory utilization.

Roll First (KB) EM Roll Area (20 Heap Memory


MB)

WP0    

WP1    

WP2    

WP3    

WP4    

WP5    

RFI (Request for Information) can be prepared by 3rd party agencies like KPMG/IBM

Customer Partner/SAP/Oracle

1. RFI Response

2. Chases S/W

3. Who needs to Implement Satyam, IBM, L&T, Accenture, Wipro

RFP: Request for Proposal RFI (O/S, DB, Components, Windows,


IBM)

4. Customer Will send RFI

5. Customer Choose partner based on

(Time material, Fixed bid)

311
312
NETWEAVER

SAPGUI for WINDOWS

SAP GUI for JAVA


4.6 D
HTTP 8080
4.7 EE SR1
ITS

SAPGUI for HTML HTTP 8080

Up to version 4.6 D R/3 ITS was used to provide web functions to the end users. It
consists of two components.

Application gate (Agate) and Web gate (Wgate)

User Request Flow:

1. User requests using the internet explorer

2. The request is received by web gate which is on the web server and redirect the
request to application gate way.

3. Agate in turn sends the request to application server which will be handled by
DIAG protocol

4. Server sends the response to the Agate in the DIAG form

5. Agate interprets the request into .CSS (cascading style sheet) and hands over the
response to user

Note: Wgate must be installed on Web Server

Agate and Wgate can be installed together on single host. It is called as singe host
installation

Agate and Wgate can be installed on to different hosts which is also referred as
Dual Host Installation.

Monitoring is performed through ITS administration instance

It can only process ABAP requests

313
Note: In order to overcome the above and to provide internet functionality to SA R/3
system ICM was introduced from SAP R/3 version 4.7

Up to version 4.6D it is referred as SAP application Server

From 4.7 onwards it is referred as SAP Web Application Server

ICM become an internal part of SAP and it is monitored using transactions SMICM.
While installing SAP WEB AS J2EE engine is required

But as planned it could not provide the internet functionality up to version 6.30 (ITS
is required)

From 6.40 onwards integrated ITS has become an internal part of R/3. Where R/3
systems can be accessed without ITS. It is used to handle Dynpro based
applications

The SAP WEB AS version is used to provide Web functionality and formed as a BASIS
platform for Sap NETWEAVER

SAP WEB AS 6.40 supports both ABAP stack and JAVA Stack.

JAVA Stack:

ESS: Employee Self Services

MSS: Manager Self Services

EP XI BI BD APO SRM CRM BIW R/3

JAVA Stack ABAP Stack

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

314
Open DB Support O/S Independent

Application Platform

SAP R/3 FAX CRM Mobile Interface

BIW

Paging Mail Server

SMS

Non SAP(CSV…) Oracle


Applications SAP

PS

P Process Integration with the help of Brokers & Adapters


P
I Information Integration X

P People Integration .NET


A
A Application Integration
FRAME A
P

WORK P

Netweaver provides technical infrastructure where applications can be hosted on


any platform or any database to integrate the processes across the system to fetch
information and display it to the users.

How to work with ITS (Internet Transaction Server):

Go to SICF (Internet communication frame work)

Go to BC (Business Component) Go to GUI Go to ITS Sap WEB GUI Right


Click Web Server

URL: http\<hostname>:port number\sap\bc\ITS\sap\webgui\sap clients

315
Parameters:

1. ITSP/enable=1 (RZ10)

2. Ms/http_port=8080 (or)8081

Version: 4.7 EE ext set 1.00 (For 6.30)

a. EE ext set 2.00

JAVA:

1. Unicode language

2. Platform independent (OS/DB)

3. OOPS (object oriented programming system): Encapsulation, Inheritance,


Polymarphism

4. Integrations

5. Multi lingual

6. Robustness, secure network

7. User Friendly GUI

1. JVM: Java Virtual Machine:

It is platform dependent and it is used to execute the platform independent


byte code deployed in JAVA

When java is programmed it ends with .java extension. This program will be
compiled to a .class extension. The compiled program is platform
independent. In order to interpret the compiled program we require JVM (Java
Virtual Machine).

2. JRE: Java Run Time Environment:

It provides an environment to run the applications designed in JAVA. It is


required to install all the NETWEAVER components.

3. J2SDK: Java tools for Standard development Kit:

It provides a platform to develop and deploy JAVA applications

316
Note: Java is used to develop and deploy internet based applications while
connecting to SAP and Non SAP systems.

Installation Options:

 WEBAS JAVA can be installed as a standalone engine

 JAVA and ABAP can be installed together

 JAVA can be added on to the existing ABAP engine

WEB Dispatcher

ICM

JAVA ABAP
Dispatcher Dispatcher
Work Processes Work Processes

MSG MSG
DB DB
ENQ ENQ
ICO

WEB Dispatcher:

1. User request over the internet explorer

2. The request is handled by Web Dispatcher

Web dispatcher is a piece of software which can be installed on any machine


which is connected to internet

Web dispatcher provides security

3. Web dispatcher communicates with message server to identify least loaded


server and direct the request to respective ICM

4. ICM receives the user request and segregates whether it need to be send to
ABAP dispatchr or JAVA dispatcher

5. ICM is instance specific

317
6. The request is received by JAVA dispatcher

7. JAVA dispatcher assigns the request to server processes. Server process has
threads to handle the user requests

8. This is the only process where user request will be connected to complete
transactions

9. Session information will be stored as cookie and passed on to the thread

10.The cookie information will be deleted when the user session is terminated

11.While updating a record it talks to enqueue process and obtains the locks

Start Up and Shut Down of WEB AS JAVA:

1. It can be started on its own when it is installed as a standalone engine

Commands: Startsap on non windows environment will be used and on


windows MMC will be used to start and stop the system

2. When it is plugged with ABAP engine ABAP start up frame work initiates JAVA
startup provided that start\J2EE=1 (Located in ABAP engine)

3. It can also be started from transaction SMICM

Note: Java is always is add-on to ABAP but ABAP can’t be add-on for JAVA
engine

JAVA startup framework:

1. When JAVA instance is started it looks in to profiles (STARTUP and Default)


and start the DB.

2. Jcontrol process is also started and connects to the DB to get the instance
properties, updated to O/S leve;

3. Jcontrol: Boot strap process will read the O/S profiles and starts all the
services. JControl also starts Jlaunch process and assigns memory to them

4. Jlaunch: Jlaunch start up process is initiated b JCOntrol process. This process


ends itself when Jcontol is stopped

Note: Startup logs can be found in work directory.

Startup Problems:

1. Could not find the JVM. We need to set the path (Enviromental variable)

318
2. Memory is not enough t start the instance (Increase the memory based on
the availability)

3. DB is not started (Check alert,SID>.log, lsntctl, oracle services)

4. JRE is not compatible ( 1.4.9 to 1.4.12)

JAVA Admin Tools:

File Structure: SCS-SAP central Services (Msg, Enqueue) \usr\sap\sid\

Instance directory is located in \usr\sap\SID\JC01

Go to work directory dev_Server, dev_disp, dev_Jcontrol, sapstart.log,


dev_bootstrap

Cluster:

It is the combination of dispatcher and server. It is nothing but instance and always
reports to the instance

Individual server log and dispatcher log can be found as default.trc

Go to J2EE click on admin

J2E admin directory: it is used to provide admin tools where services are configured

Visual Admin Tool: (VAT)

Click on go.bat in admin directory to go to visual administrator tool.

Config tool directory:

This is used to configure the initial settings of JVM> Restart is required. Add server
process,memory settings of JVM. Restart is required.

Add Server process, Memory Settings and LDAP settings. LDAP (Light weight
Directory access Protocol).

TELNET Tool:

It is used to communicate with JAVA system remotely.

JCMON: It is a CLI to monitor the local and cluster configuration.

Ports 1: By default message server listens on 3900 for ABAP 3600.

Ports 2: Visual Administrator listens on p4 (Port 4). That is the port number ends
with 4

319
JAVA instance port: By default 50,000 is used as port to access JAVA instance over
the internet provided instance number is 00.

The formula to calculate the port number is:

50,000 + (100* instance number) + default number.

TELNET listens on port number 8.

JVM listens on port number 18.

If the port number is 99 calculate the instance number:

59900, 59904, 59908, 59918

Post installation Activities of JAVA instance:

1. Check the installation log to ensure that the installation is performed


successfully

2. Install SAP License. Go to Visual Admin Tool It will display the H/W key get
the H/W key go to market place and get the license key license will be in
the form of text file go the conflicttool.bat go to file add server process
select the dispatcher increase the heap size go to umel.data to configure
directory server so that domain users can connect to the system without any
password select the server process and go to services to configure the
services we can increase http cache size in http servers t o 3000-4000

When working on config tool JAVA Web AS is not required of there is any cahgne
mode to config tool it will defect the DB.

User admin is used to configure run time parameters most of the parameters are
effective immediately

Ex: RFC destination, Creating Users…

TELNET Tool: It is used when we could not logon to JAVA instance

Applying the patches: On WEB AS JAVA and components installed on it the


components which need to be patched are

1. JRE

2. JAVA Engine

3. 3. Composite Application Framework

4. Visual Composer

320
5. EP…

STPI: Solution tool plug in (Component)

Patching Tools:

Patches can be applied by using the following tools:

1. SAPINST: It is used to apply patches to J2EE engine

2. SDM: Software deployment Manager: it is used to apply patches to all the


components

SDM s located in the usr\sap\SID\JC01\instance number\SDM\remote.bat (GUI)

In order to initiate SDM we require user ID, Password and port number. USER
ID is SDM, password is SDM by default, but will be changed during the
installation.

Port: 50,000+ 100*instance number+ 18 (Default)

Only one user can be connected to SDM. While applying patches to SDM, we need
to specify the path either DB file system or J2EE

SDM can also be initialized t apply the patches either online of offline dsployment

JSPM: It is located in usr\sap\sid\instance\J2E\JSPAM\go.bat

Click on go.bat to go to JSPM interface. Patches will be copied to the directory

Trans\eps\in

File types that can be applied as support Packages:

The following extensions will be used to apply support packages and patches.

1. “.sda”: Software development Archive

2. “.war” : Web Archive

3. “.rar”: Runtime Archive

4. “.ear””: Enterprise Archive

5. “.jar”: Java Archive

6. “.sca”: Software component Archive

Note: We can revert back the packages. We cannot revert back the SPAM.

321
Go to config Toll directory and click on configtool.bat

Logon will be performed without any password.

Note: If SDM is blocked system hangs or while initializing SDM it says that user 8is
already connected to SDM.

Hoe to Resolve This: GO to MMC ( IN UNIX use $ps –ef|grep SDm to find the process
ID) find the process id and stop it and retart it again go to J2EE process list
SDM Right Click Restart

J2EE engine should be patched before all other patches.

GO to COnfig tool click on file go to parameters the configured parameters


can be exported go to cluster ID Selece server Select C-ID Security port UME
service Go to LDAP

Change the configuration data files ADS/write,

Specify the server name, Server Port, User Id, Password

Elect the instance  Select the server process

Configure the required services for the following:

1. CAF: Composite application framework

2. User Management services

3. LDAP services

4. Security Services

Define http\cache

Note: Refer the note thoroughly before making any changes the config tool, ensure
that config tool parameter are backed up.

Memory Allocation:

SAP memory for JAVA engine is allocated as follows:

1. Heap Memory: The total amount of memory which can be utilized to


processing

2. Young Generation Memory: Whenever an object is accessed it will be cached


into young generation memory

Y.G.M is defined by the parameters:

322
-XX: Newsize=171M

XX: Max New Size= 171M

3. Permanent Generation Memory:

XX : Perm Size= 256M

XX: max perm size=256M

The objects which are reusable like JAVA Classes, packages, methods will be
moved into permanent memory so that requests can access them directly.

4. Old generation or tenure generation or garbage generation:

The data which is not eligible to store or cache will be moved to this area.
Garbage is cleared from time to time. This memory is defined by using the
formula:

Heap memory-(sum of young & permanent generation)

Heap Memory is defined by parameter XMS1024M

Global Dispatcher Configuration:

If more than one JAVA instance is configured the parameters and their values can
be populated globally using this option.

Global Server Configuration: It is used to set the values for the server process.

Note: Global Parameters are overwritten by local parameters

Working with visual admin:

Initializing visual Admin: \usr\sap\sid\EP7\JC02\J2EE\ADMIN

Click on the go.bat. It requires password to login.

Visual Admin can be used to configure remote systems.

Visual Admin is used t configure the following services:

1. Install the license using license adapter

2. Configuring RFC connections using JCORFC Processs

3. Security provider service to configure the user data store to create users and
assign roles

323
Log Configuration Service: it is used to configure the logs which determines with
what granularity the logs can be filled only errors, only warnings, only information.

Log Services: This is used to configure the log files, no of active users who is used
for.

Deploy Service: It is used to deploy the programs

Monitor Service: It is used to monitor the performance of the system, such as


application monitor, SQL Trace, Single activity trace.

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

324
325

You might also like