SAP Basis

Date 

Training Center 

Instructors 

Education Website 

ADM100 

SAP Web AS Administration I 

Instructor Handbook 

Course Version: 2003 Q3 

Course Duration: 5 Day(s) 

Material Number: 50062692 

Owner: Sascha Tubbesing (D038680) 

An SAP Compass course - use it to learn, reference it for work

Copyright 

Copyright © 2003 SAP AG. All rights reserved. 

No part of this publication may be reproduced or transmitted in any form or for any 

purpose without the express permission of SAP AG. The information contained herein may 

be changed without prior notice. 

Some software products marketed by SAP AG and its distributors contain proprietary 

software components of other software vendors. 

Trademarks 

• Microsoft ® ,WINDOWS ® ,NT ® ,EXCEL ® ,Word ® , PowerPoint ® and SQL Server ® are 

registered trademarks of Microsoft Corporation. 

• IBM ® ,DB2 ® ,OS/2 ® , DB2/6000 ® , Parallel Sysplex ® ,MVS/ESA ® , RS/6000 ® ,AIX ® , 

S/390 ® , AS/400 ® , OS/390 ® , and OS/400 ® are registered trademarks of IBM 

Corporation. 

• ORACLE ® is a registered trademark of ORACLE Corporation. 

• INFORMIX ® -OnLine for SAP and INFORMIX ® Dynamic ServerTM are registered 

trademarks of Informix Software Incorporated. 

• UNIX ® ,X/Open ® ,OSF/1 ® ,andMotif ® are registered trademarks of the Open Group. 

• Citrix ® ,theCitrixlogo,ICA ® , Program Neighborhood ® ,MetaFrame ® ,WinFrame ® , 

VideoFrame ® ,MultiWin ® and other Citrix product names referenced herein are 

trademarks of Citrix Systems, Inc. 

• HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C ® , 

World Wide Web Consortium, Massachusetts Institute of Technology. 

• JAVA ® is a registered trademark of Sun Microsystems, Inc. 

• JAVASCRIPT ® is a registered trademark of Sun Microsystems, Inc., used under 

license for technology invented and implemented by Netscape. 

• SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, 

WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com 

Logo and mySAP.com are trademarks or registered trademarks of SAP AG in 

Germany and in several other countries all over the world. All other products 

mentioned are trademarks or registered trademarks of their respective companies. 

Disclaimer 

THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP 

EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, 

INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND 

FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS 

AND THE SERVICE, INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER 

MATERIALS AND PRODUCTS CONTAINED HEREIN. IN NO EVENT SHALL SAP BE 

LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, 

OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDING WITHOUT 

LIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM THE 

USE OF THESE MATERIALS OR INCLUDED SOFTWARE COMPONENTS.

About this Handbook 

This handbook is intended to complement theinstructor-led presentation 

of this course, and serve as a source of reference. It is not suitable for 

self-study. 

Typographic Conventions 

American English is the standard used in this handbook. The following 

typographic conventions are also used. 

Type Style Description 

Example text Words or characters that appear on the screen. 

These include field names, screen titles, 

pushbuttons as well as menu names, paths, and 

options. 

Also used for cross-references to other 

documentation both internal (in this 

documentation) and external (in other locations, 

such as SAPNet). 

Example text Emphasized words or phrases in body text, titles 

of graphics, and tables 

EXAMPLE TEXT Names of elements in the system. These include 

report names, program names, transaction codes, 

table names, and individual key words of a 

programming language, when surrounded by 

body text, for example SELECT and INCLUDE. 

Example text Screen output. This includes file and directory 

names and their paths, messages, names of 

variables and parameters, and passages of the 

source text of a program. 

Example text Exact user entry. These are words and characters 

that you enter in the system exactly as they 

appear in the documentation. 

Variable user entry. Pointed brackets indicate 

that you replace these words and characters with 

appropriate entries. 

2003/Q3 © 2003 SAP AG. All rights reserved. iii

About this Handbook ADM100 

IconsinBodyText 

The following icons are used in this handbook. 

Icon Meaning 

For more information, tips, or background 

Note or further explanation of previous point 

Exception or caution 

Procedures 

Indicates that the item is displayed in the 

instructor’s presentation. 

iv © 2003 SAP AG. All rights reserved. 2003/Q3

Contents 

Course Overview.......................................................... ix 

Course Goals........................................................... ix 

Course Objectives ..................................................... xi 

Unit 1: Fundamentals .....................................................1 

What Is an SAP System?..............................................3 

Process of a System Logon ...........................................8 

Configuring SAP Logon.............................................. 13 

Analysis Transactions ................................................ 26 

Unit 2: Starting and Stopping the SAP System................... 39 

System Start: Process ............................................... 41 

System Start: Logs ................................................... 53 

System Shutdown: How and Why?................................. 60 

Appendix - Starting and Stopping with Other Operating 

Systems ............................................................ 69 

Appendix - Database Logs .......................................... 78 

Unit 3: Introduction to System Configuration..................... 89 

How the System Evaluates its Parameters........................ 90 

How to Set System Parameters..................................... 98 

Setting up Operation Modes........................................109 

Unit 4: Access to Help .................................................125 

Configuring the Online Documentation ...........................126 

Unit 5: Fundamentals of Working with the Database...........147 

Architecture of Database Systems ................................149 

Backing Up the Database Contents ...............................153 

Overview: Monitoring the Database...............................164 

Unit 6: Archiving ........................................................173 

Fundamentals of SAP Data Archiving.............................175 

Performing Data Archiving..........................................185 

Accessing Archived Data ...........................................202 

Unit 7: Working with the Transport System.......................217 

Data Structure of SAP Systems and System Landscapes .....218 

2003/Q3 © 2003 SAP AG. All rights reserved. v

Contents ADM100 

Performing and Checking Transports..............................226 

Unit 8: Support Packages, Plug-Ins, and Add-Ons .............247 

Term Definition: Support Packages ...............................249 

Importing Support Packages .......................................255 

Updating the Tools ...................................................279 

Importing SAP Notes................................................287 

Unit 9: Scheduling Background Tasks.............................297 

Fundamentals of Background Processing ........................299 

Time-Based Scheduling of Jobs ...................................312 

Event-Based Scheduling of Jobs ..................................323 

Background Processing: Other Topics............................333 

Job Scheduling: Extending the Standard.........................347 

Unit 10: Including Printers in SAP Systems......................357 

Configuring Printers in SAP Systems .............................358 

Concept of Logical Spool Servers .................................379 

Managing Spool Requests..........................................391 

Unit 11: Basics of User Administration............................403 

User Administration Concept.......................................405 

Authorization Concept...............................................414 

Login Parameters and User Info ...................................431 

Appendix - Advanced User Administration Topics ...............439 

Unit 12: Setting Up Remote Connections.........................449 

Fundamentals and Types of RFC..................................450 

Setting Up RFC Connections.......................................457 

Unit 13: System Monitoring ..........................................471 

Monitoring Architecture..............................................472 

Including Remote Systems .........................................487 

Creating Your Own Monitors........................................495 

Properties Variants and Threshold Values .......................506 

Unit 14: SAP Solution Manager......................................519 

Concept of the SAP Solution Manager............................520 

Unit 15: Structured Troubleshooting...............................533 

Trace Options.........................................................535 

Troubleshooting Procedure .........................................550 

Appendix - Troubleshooting Example .............................555 

vi © 2003 SAP AG. All rights reserved. 2003/Q3

ADM100 Contents 

Unit 16: Introduction to System Security..........................585 

Security in the SAP Environment ..................................586 

Glossary...................................................................607 

Index .......................................................................615 

2003/Q3 © 2003 SAP AG. All rights reserved. vii

Contents ADM100 

viii © 2003 SAP AG. All rights reserved. 2003/Q3

Course Overview 

This SAP course provides a broad insight into the many tasks of SAP 

system administrators and creates a solid foundation for the training 

of SAP system administrators, based on the knowledge acquired in the 

SAPTEC course (SAP NetWeaver: Fundamentals of the Application 

Platform). The focus of this course is on the SAP Web Application Server. 

This course is a required prerequisite for attending many advanced courses 

in the SAP System Administration curriculum. 

Target Audience 

This course is intended for the following audiences: 

• SAP system administrators 

• Technology Consultants 

• Those responsible for IT 

• People involved in the administration of SAP systems 

Course Prerequisites 

Required Knowledge 

• Attendance of the SAPTEC course or knowledge of the content 

addressed in this course 

• Basic operating system and database knowledge 

Course Duration Details 

Unit 1: 

Fundamentals 

What Is an SAP System? 40 minutes 

Process of a System Logon 45 minutes 

Configuring SAP Logon 35 minutes 

Analysis Transactions 30 minutes 

Unit 2: Starting and Stopping the SAP System 

System Start: Process 30 minutes 

System Start: Logs 30 minutes 

System Shutdown: How and Why? 30 minutes 

Appendix - Starting and Stopping with Other 

Operating Systems 0minutes 

Appendix - Database Logs 0minutes 

Unit 3: Introduction to System Configuration 

2003/Q3 © 2003 SAP AG. All rights reserved. ix

Course Overview ADM100 

How the System Evaluates its Parameters 40 minutes 

How to Set System Parameters 40 minutes 

Setting up Operation Modes 40 minutes 

Unit 4: Access to Help 

Configuring the Online Documentation 60 minutes 

Unit 5: Fundamentals of Working with the Database 

Architecture of Database Systems 45 minutes 

Backing Up the Database Contents 30 minutes 

Overview: Monitoring the Database 15 minutes 

Unit 6: Archiving 

Fundamentals of SAP Data Archiving 15 minutes 

Performing Data Archiving 35 minutes 

AccessingArchivedData 25 minutes 

Unit 7: Working with the Transport System 

Data Structure of SAP Systems and System 

Landscapes 45 minutes 

Performing and Checking Transports 60 minutes 

Unit 8: Support Packages, Plug-Ins, and Add-Ons 

Term Definition: Support Packages 30 minutes 

Importing Support Packages 50 minutes 

Updating the Tools 30 minutes 

Importing SAP Notes 20 minutes 

Unit 9: Scheduling Background Tasks 

Fundamentals of Background Processing 45 minutes 

Time-Based Scheduling of Jobs 30 minutes 

Event-Based Scheduling of Jobs 30 minutes 

Background Processing: Other Topics 45 minutes 

Job Scheduling: Extending the Standard 15 minutes 

Unit 10: Including Printers in SAP Systems 

Configuring Printers in SAP Systems 60 minutes 

Concept of Logical Spool Servers 40 minutes 

Managing Spool Requests 60 minutes 

Unit 11: Basics of User Administration 

User Administration Concept 60 minutes 

Authorization Concept 60 minutes 

Login Parameters and User Info 30 minutes 

Appendix - Advanced User Administration Topics 0minutes 

Unit 12: Setting Up Remote Connections 

Fundamentals and Types of RFC 30 minutes 

Setting Up RFC Connections 30 minutes 

Unit 13: System Monitoring 

x © 2003 SAP AG. All rights reserved. 2003/Q3

ADM100 Course Overview 

Monitoring Architecture 45 minutes 

Including Remote Systems 20 minutes 

Creating Your Own Monitors 25 minutes 

Properties Variants and Threshold Values 45 minutes 

Unit 14: SAP Solution Manager 

Concept of the SAP Solution Manager 20 minutes 

Unit 15: Structured Troubleshooting 

Trace Options 45 minutes 

Troubleshooting Procedure 15 minutes 

Appendix - Troubleshooting Example 0minutes 

Unit 16: Introduction to System Security 

Security in the SAP Environment 45 minutes 

Course Goals 

This course will prepare you to: 

• Start and stop SAP systems 

• Configure SAP systems 

• Configure the online documentation 

• Perform periodic, automated work with the database 

• Use basic functions of SAP data archiving 

• Use transport functions in SAP systems 

• Import Support Packages, Plug-Ins, and Add-Ons 

• Use background processing efficiently 

• Define and include printers 

• Perform basic user administration tasks 

• Set up remote connections 

• Set up system monitoring 

• Describe the SAP Solution Manager 

• Perform structured troubleshooting 

• Explain various system security terms in the SAP environment 

Course Objectives 

After completing this course, you will be able to: 


• Set up system parameters 

• Configure help 

• Schedule database backups 

2003/Q3 © 2003 SAP AG. All rights reserved. xi


• Use SAP data archiving 

• Perform and check transports 


• Schedule background tasks 

• Configure printers in the SAP system 

• Create and manage users 


• Monitor the system 



• Use system security terms correctly in the SAP environment 

SAP Software Component Information 

The information in this course pertains to the following SAP Software 

Components and releases: 

SAP Contacts 

• Dr. Sascha Tubbesing, SAP DEUTSCHLAND AG & CO. KG 

• Dr. Georg Becker, SAP DEUTSCHLAND AG & CO. KG 

• Matthias Esch, SAP DEUTSCHLAND AG & CO. KG 

Caution: Since this trainer guide can only be updated at 

release upgrades, a separate area has been set up on the page 

http://intranet.sap.com/epf-adm: Instructor Guides. Current 

trainer notes are collected in a document there. The status of this 

material is the status in April 2003. For current information, see the 

trainer guide extension document on the above page. 

Required Knowledge: Instructor 

We recommend that you attend the following courses: SAPTEC, ADM100, 

and ADM325 (BC325). 

Other, General Information Sources for Preparation 

Theinstructorshouldbeveryfamiliarwiththetrainerguideforthis 

course and have an overview (content-wise) of the SAP Notes mentioned 

in the course. 

Recommended Sections of the Online Documentation 

All sections in the BC* area are relevant. The instructor should obtain 

an overview of what the online documentation provides. The address 

http://help.sap.com is a valuable resource. 

xii © 2003 SAP AG. All rights reserved. 2003/Q3

ADM100 Course Overview 

Tips for Preparing for this Course 

1. Attend the above courses 

2. Read this instructor handbook carefully 

3. Gain additional information using the other specified sources 

4. Work through all exercises and solutions until you are very familiar 

with them 

5. Clarify any remaining questions by contacting other instructors for 

this course 

Caution: This instructor handbook does not replace the instructor’s 

preparation, nor does it provide the required system knowledge. 

The intention of this handbook is to support the instructor 

in preparing to teach this course by providing references to 

information sources and tips for performing demonstrations. 

Training System 

The training systems are set up as follows: A host (such as twdf05##) 

contains two systems, DEV and QAS. Each of these systems has two 

instances, 00 and 01 for DEV and 10 and 11 for QAS. Two participants 

work on a system, meaning that four participants work on a host (such 

as twdf05##). 

The operating system of the training servers is Microsoft Windows 2000. 

They can be accessed using the users adm with the password 

adm. Replace with DEV or QAS, as appropriate. 

SAP DB 7.3 is used for this training course. For more information 

about SAP DB, see the units “Starting and Stopping the SAP System” 

and “Fundamentals of Working with the Database” in the instructor 

handbook. Use the user control with the password control to access 

the database. The “Terminal Server Client” is used to access the servers at 

operating system level. The installation of these clients can be found here: 

\\iwdf8001.wdf.sap-ag.de\NTinst\#WTS_Tools\RDP_client. 

This installation must be prepared by the training center. Alternatively, 

you can use PCAnywhere or Telnet. There are therefore three options for 

accessing the operating system level. A SAP GUI with a release status of 

at least 6.20 is required to access the systems. This GUI can also possibly 

be provided using a Terminal Server. The training system is purely a SAP 

Web AS 6.20. There are therefore no business functions available in the 

system. The TMS is set up so that the system DEV exports to QAS. 

Caution: It is not permitted to access training servers outside the 

assigned time. 

2003/Q3 © 2003 SAP AG. All rights reserved. xiii


User IDs and Passwords 

000 ADM100 patch 

000 DDIC if required: reset the password with user 

ADM100 

000 SAP* if required: reset the password with user 

ADM100 

100 ADM100 100adm 

100 ADM100-## init course users (00-30) 

100 SAP* if required: reset the password with user 

ADM100 

The following users have also been assigned new passwords: 

000 SAPCPIC nimda (admin, backward) 

066 EarlyWatch troppus (support, backward) 

100 SAPCPIC nimda (admin, backward) 

These users exist in all clients that were created by client copy from client 

100: 101, 102 und 8##. This means that no warning messages appear 

in report RSUSR003. 

Technical Notes 

The online documentation (SR13) is deliberately not configured. 

This is configured during an exercise. This exercise is optional, 

depending on the availability of SAP Web AS 6.20 (or newer) 

documentation in the training environment. You can alternatively also 

access http://help.sap.com (not from SR13). To access the systems, 

bothaSAPGUI6.20(orabove) and the RDP client are required: 

\\iwdf8001.wdf.sap-ag.de\NTinst\#WTS_Tools\RDP_client. 

The availability of this address cannot be guaranteed worldwide or 

permanently. 

xiv © 2003 SAP AG. All rights reserved. 2003/Q3

Unit 1 

1 Fundamentals 

This unit acts primarily as a short repetition of the contents of the SAPTEC 

course (the exception to this is the lesson “Configuring SAP Logon”). You 

should go into more or less detail in the individual lessons, depending on 

the participants’ level of knowledge. 

Unit Overview 

Basic terms and processes will be introduced in this unit, as well as the 

structure and architecture of an SAP system. 

In addition to the process of a system logon, you will learn how to set up 

SAP Logon and how to use a range of important analysis transactions. 

Unit Objectives 

After completing this unit, you will be able to: 

• Outline the structure and architecture of an SAP system 

• List the technical components of the SAP Web Application Server 

• Use the terms system and instance correctly 

• Describe the process of a system logon 

• Describe the technology for dialog work process multiplexing 

• Set up the SAP Logon program 

• Explain the use of logon groups 

• Call central administration functions in the system 

Unit Contents 

Lesson: What Is an SAP System?...............................................3 

Lesson: Process of a System Logon ............................................8 

Lesson: Configuring SAP Logon............................................... 13 

Exercise 1: SAP Logon and Logon Groups.............................. 21 

Lesson: Analysis Transactions................................................. 26 

2003/Q3 © 2003 SAP AG. All rights reserved. 1

Unit 1: Fundamentals ADM100 

Exercise 2: Common Administration Transactions...................... 29 

2 © 2003 SAP AG. All rights reserved. 2003/Q3

ADM100 Lesson: What Is an SAP System? 

Lesson: 

2 

What Is an SAP System? 

Lesson Duration: 40 minutes 

Lesson Overview 

In this lesson, you will learn about the structure and architecture of an SAP 

system, and learn how to use the terms system and instance correctly. 

Lesson Objectives 

After completing this lesson, you will be able to: 




The instructor introduces the required elements of a complete SAP system 

here: the database and a central instance. In this context, you should use 

the following description to define the term “central instance”: “Together 

with the database, the central instance of an SAP system forms a runnable 

SAP system”. As some services are only provided once for each system 

(message server), it is logical that there can only be one central instance 

for each system. 

Business Example 

YouwanttolearnaboutthearchitectureofanSAPsystem. 

What Is an SAP System? 

An SAP System consists of the components shown in the graphic: Exactly 

one database and one or more instances. The instance that, together 

with the database, creates a runnable SAP system, is called the “central 

instance”. A central instance should be configured in every SAP system. 

A“central system” exists if the system contains only a single instance, and 

this is running together with “its” database on one host. 



Caution: There are a number of different definitions for the term 

“central instance”. You should emphasize the definition above, as 

it is realized in almost all SAP systems. From the point of view of 

downtime security, distributing the essential processes would be 

equivalent to increasing the probability of system downtime. 

Hint: It is possible to install multiple SAP systems in one database. 

However, this is not usually the case. UsethekeywordMCOD 

(Multiple Components in One Database) to find more information 

about this option. 

Figure 1: The Elements of an SAP System 

It is certainly possible to install two instances of a system or even of 

different systems on one server. When configuring two systems (or their 

databases) on one server, you should ensure that the two systems are 

clearly differentiated, otherwise a conflict situation will eventually occur 

during the use of common resources (such as program libraries), especially 

if one system is to be upgraded while the other is to continue to be used 

with the same release. 

Within a company, no SAP System IDs (SIDs) should be assigned more than 

once. You can only perform a meaningful data exchange with two systems 

with the same SID only with a great deal of effort (renaming the systems). 



What Is an Instance of an SAP System? 

An instance of an SAP system is an administrative unit in which the 

components of an SAP system, that provide one or more services, are 

combined. The services provided are commonly started and stopped. All 

components of an instance are provided with parameters using a common 

instance profile. 

Figure 2: The Composition of an Instance 

These components currently include the dispatcher, the work processes, 

the gateway, the assigned main memory areas, and an Internet 

Communication Manager (ICM), if one is configured. 

An instance always has exactly one dispatcher. The start of an instance 

always begins with the start of the associated dispatcher. An instance 

requires a minimum of two dialog work processes. Otherwise it is not 

possible to start it. Multiple dispatchers can be configured on one host, 

but these must have different system (instance) numbers. The default 

for the instance number of a dispatcher is 00; that is, port 3200 receives 

communication for this dispatcher. If there are two instances on one 

machine, the port numbers 3200 and 3201 are usually assigned, and so on. 

An instance is also called the application server in the software-oriented 

view of the client-server model. The application server provides the 

runtime environment for the business applications of SAP systems. 



Facilitated Discussion 

No moderated discussion. 

Discussion Questions 

Use the following questions to engage the participants in the discussion. 

Feel free to use your own additional questions. 



Lesson Summary 

You should now be able to: 




Related Information 

• SAPTEC - SAP NetWeaver: Fundamentals of the Application 

Platform 

• SAP Library 

• SAP Notes 

– SAP Note 21960: Several instances/systems on one UNIX computer 

(and SAP Notes linked from this message) 

– SAP Note 39412: How many work processes to configure 



Lesson: 

6 

Process of a System Logon 



In this lesson, you will learn about the process of a system logon, and 

about dialog work process multiplexing. 





These two figures show the steps that are processed in an SAP system 

when a user logs on using SAP Logon to then run dialog steps in the 

system. It is important to note here that load balancing is only performed 

by the message server. 


You want to understand the process of a system logon. 

Process of a System Logon 

To be able to create a connection between the front end and an instance of 

an SAP system, the sapgui.exe program requires various information 

in the form of start parameters. This parameter string is normally created 

by the saplogon.exe program using information about the system 

selected for logon. This information comes partly from the configuration 

files of SAP Logon, and partly from a direct request to the message server 

of the selected system (see steps 1 and 2 in the following figure). SAP 

Logon then starts the SAP GUI with these specifications. In this way, an 

instance with good performance is selected for logon in the case of a logon 

using logon groups. 


ADM100 Lesson: Process of a System Logon 

Figure 3: Process of a System Logon 

After the transfer of the logon screen from the dispatcher to the front end 

(notshowninthefigure),SAPGUIsendstheuser’slogondatatothe 

instance (step 3 in the above figure). After the dispatcher has determined 

a free work process to process the logon, it transfers the logon data to 

this work process (step 4). The work process, in turn, checks whether the 

received combination of user ID and password is known to the system 

using a request to the database (steps 5-8). A positive response from the 

database prompts the work process to return the initial screen of the 

system to the front end. 

During a logon session, the assignment of the user to the instance is 

unique. Only during a new logon can the user possibly be assigned to a 

different instance by the message server. 

Dialog Work Process Multiplexing 

The important term work process multiplexing is repeated here. This 

property of the system, which means that successive dialog steps for 

the same user can be processed in different dialog work processes, has 

far-reaching consequences, ultimately including the use of “asynchronous 

updates”. The function of request queues can also be explained here. 



The processing of a transaction that consists of multiple screens is usually 

executed using multiple, different dialog work processes. This distribution 

is called “work process multiplexing”. Work process multiplexing means 

that a system function whose content is logically connected but which 

consists of multiple substeps can be processed by various dialog work 

processes. These steps whose content is connected are described as 

transactions. A transaction that consists of multiple screens, such as screens 

100 and 200 can also be processed by multiple dialog work processes. 

Figure 4: Work Process Multiplexing 

The figure shows two screens of a transaction (100 and 200), for which the 

input is handled by two different dialog work processes. The multiplexing 

procedure is used exclusively for dialog work processes. All other work 

process types process entire functions; that is, complete business processes. 

As dialog work processes may therefore process only parts of transactions 

that are connected from a business point of view; the update procedure 

with the update work process is widely used in SAP systems (see also 

the SAPTEC course). 


ADM100 Lesson: Process of a System Logon 













ADM100 Lesson: Configuring SAP Logon 

Lesson: 

10 

Configuring SAP Logon 



In this lesson, you will learn how to configure the SAP Logon program. 

The concept of logon groups will also be introduced. 





Since the SAP Logon program is required to access the training systems, 

you should also demonstrate setting it up. Transaction SMLG is used in 

the exercises, and should therefore also be demonstrated. 


You want to use logon groups to restrict user logons to certain application 

servers of your system. 

SettingUpSAPLogon 

Most participants will presumably already be familiar with using SAP 

Logon. You can demonstrate, for example, the additional functions 

available under Options here. You could also explain the role of the file 

saplogon.ini and of the program saplgpad.exe in more detail at this point. 

The SAP Logon program provides users with a convenient logon to an 

SAP system with the SAP GUI for Windows (from Windows-based front 

ends). SAP Logon evaluates various configuration files that are stored on 

the front end. These files can also be edited using SAP Logon. 



Figure 5: SAP Logon 

You can make various general settings through the SAP Logon Options 

(see figure above). You can, for example, set the trace level for SAP GUI 

connections in this way. Passwords can also be written to the the trace file 

generated in this way, so you should use this option only with great care; 

the trace files should be deleted afterwards. 

The settings for a connection can be changed using the Properties button, 

such as its name in SAP Logon, and through the Advanced button (on 

the Properties dialog box), you can, for example, restrict the amount of 

data transferred (system to front end), to take account of slow network 

connections (see also SAP Note 161053). 

You can use the Groups... button (for "group selection") to create a new 

connection to a system. This connection uses the logon groups concept, 

meaning that the message server always assigns a new logon to the 

instance with the best performance in the selected logon group. The 

configuration file sapmsg.ini is evaluated to display the systems available 

for selection. The message server of the selected system is queried to 

discover the available logon groups. So that the connection to the message 

server of the system specified in sapmsg.ini works, it is necessary for the 

Microsoft Windows file services to specify the correct message server 

communication port for the selected system ID. A connection is then 

created to the relevant host and the message server running on it using the 

information from sapmsg.ini and services. 

DemonstratesettingupaconnectioninSAPLogonusingGroups..., 

Server..., andNew..., and possibly the settings using Options. 



Figure 6: Setting Up SAP Logon 

The Server... button allows you to create a connection to a specific instance 

of an SAP system. As with the Groups... button, information about the 

instances that are available for selection is collected from the message 

server. 

With the New... button, you can create a connection to an SAP system that 

need not be listed in the sapmsg.ini and services files. Therefore, you enter 

all of the system information that is relevant for a logon here yourself. 

The name of the host on which you want to contact an instance, and its 

system or instance number is essential. The instance number specifies the 

last two digits of the 4 digit port address through which the dispatcher 

of the specified instance can be contacted. The first two digits are fixed, 

and are 32. This means that port numbers between 3200 and 3299 are 

possible. The ports 3298 and 3299 are, however, assigned to the niping and 

saprouter programs by default (although this can be changed). For more 

information about this, see the SAP Library for the SAP Web AS with the 

search term “3298”. 

You can also specify a SAProuter string for new connections to be 

created. Through this connection, a SAProuter is then assigned the task 

of transferring data. SAProuter strings can also be specified using aliases. 

These aliases are decoded using the saproute.ini file. 

Hint: If you do not want to allow users to edit the system entries, 

you can use the SAP Logon Pad program. 

Which files are stored where? The following list shows the files with their 

possible storage locations; in the case of multiple possible locations, the 

search sequence is shown: 



• saplogon.ini, sapmsg.ini, saproute.ini: 

– SAP GUI directory 

– Windows directory 

• services: 

– WINNT → system32 → drivers → etc → Services 

Using Logon Groups 

Logon groups can be used to distribute user groups across server groups. 

This is useful, if restricted memory resources mean that the SAP buffer 

cannot be set to a size that allows the requests of all applications in use 

tobemetonallserversinawaythatprovidesgoodperformance. If, 

however, the range of applications in used on each application server 

(instance) is restricted, better system performance could even be achieved 

with fewer resources. Exactly this can be achieved by using logon groups. 

This is illustrated in the figures using the example of the program buffer. 

You should emphasize that logon groups do not restrict the servers on 

which a user may work, but are rather a restriction that means that a user 

can only log on to certain instances from his or her front end (due to being 

unable to edit saplogon.ini). Therefore, a successful implementation of 

logon groups also requires the use of SAP Logon Pad (saplgpad.exe). 

Hint: It can take up to five minutes after you have saved entries 

in transaction SMLG, before the new entry appears in SAP logon 

when the the message server is accessed using “group logon”. The 

Auto-ABAP responsible runs every five minutes. 

SAP systems sometimes have significantly more than just one or two 

assigned instances. Each of these instances provides buffer areas for 

variousobjects,suchasforprograms,dictionaryobjects,screenstructures, 

and table contents. 

These buffers are filled with data and continuously updated during 

the runtime of an instance; that is, the system attempts, using various 

algorithms, to organize the contents of the buffer so that the frequently 

queried data is in the buffer. Data that is used frequently but changes only 

very rarely is buffered. This means that a cross-section of all programs 

called on this instance is collected, especially in the program buffer (see 

the figure below). 



Figure 7: Program Buffer Without the Use of Logon Groups 

If a large number of different applications are run, old buffer contents 

may be replaced with newly requested contents. This means that the 

next time the older contents are called, they must be requested from the 

database again. This reduces the response time behavior of the system, 

in some circumstances to an appreciable extent. A solution would be to 

create a program buffer that was sufficiently large to contain all requested 

programs. An alternative solution is the logon group concept explained 

in the following text. 

Using logon groups, you can group instances with transaction SMLG 

(Tools CCMS → Configuration → Logon Groups). In the example above, four 

instances are assigned to the logon group SD, and three instances to the 

logon group FI. The message server of the system also has these details 

within five minutes after the new group definitions are saved. From now 

on, you can access these groups using “group selection” in SAP Logon. 



Figure 8: Program Buffer with the Use of Logon Groups 

One instance is not included in the logon groups in the figure. This is the 

central instance. This arrangement is useful, since it means that end users 

cannot log on to the central instance; only the administrators can do this. 

In the example shown above, the definition of the two logon groups has 

the following effects: 

With a logon using a logon group, the SAP Logon program connects to 

the message server of the system, and receives from it the name of the 

currently best performing instance of the selected logon group. SAP Logon 

then starts the SAP GUI program with the connection parameters for the 

selected dispatcher. 

Within a logon group, end users are, for example, only using a particular 

application. In the example, these are the FI and SD applications. 

Therefore, the buffers on the instances of each of the logon groups are 

filled with contents from these applications. This means that the program 

buffer of each of the instances shown contains fewer different programs 

than they would without the use of logon groups. This has two possible 

advantages as a consequence: 

1. The program buffers can be set up more “economically” (smaller). 

2. Less “swapping” is performed for the program buffers, and they 

therefore perform better. 



If it is possible to set up very large program buffers (>1GB), setting up 

logon groups for the purpose described above would no longer provide 

any relevant advantages. This means that a single logon group (with the 

possible exception of the central instance, as implicitly assumed above) is 

the most useful. This has, for example, the name PUBLIC.Bydefault,every 

instance is assigned to the logon group SPACE. For more information, see 

the SAP Notes database, with the search term “SMLG”. 





17 Exercise 1: SAP Logon and Logon Groups 

Exercise Duration: 15 minutes 

Exercise Objectives 

After completing this exercise, you will be able to: 


• Set up logon groups 


You want to use logon groups to restrict user logons to certain application 

servers of your system. 

Task 1 Clear Existing SAP Logon Entries 

This task depends on the setup of your training front end. 

1. As there could already be entries in your local SAP Logon from other 

training courses, choose the following call, if it exists: 

Start → Training → SAPLogon Reset. 

This call edits your local saplogon.ini file so that there are no 

system entries, and perhaps a “dummy” entry in the file. 

Task 2 Set up SAP Logon Using the Groups Button 

1. Choose the Groups... button and create a new entry. Use the data that 

your instructor gives you (system ID, host name) for this entry. 

Task 3 Set Up Logon Groups 

1. Log on to your system using your new entry in SAP Logon (with the 

parameters that your instructor gives you). Call transaction SMLG 

(Tools → CCMS → Configuration → Logon Groups). 

2. Choose the Create Assignment button to create a new logon group 

with any name (such as “DEV_##”, where ## is your group number). 

Assign at least one of the two instances of your system to your new 

logon group. Copy and Save your entries. 

Continued on next page 



Task 4 Using Logon Groups through “Group Selection” 

in SAP Logon 

1. In SAP Logon, choose the Groups... button again to add a new entry. 

If the logon group that you created previously does not yet appear 

in the display, the message server has not yet registered the newly 

created logon group. This is done automatically every five minutes. 

You can therefore generate the list again after a few minutes. 

2. Log on to your system using the new entry in your SAP Logon. 



Solution 1: SAP Logon and Logon Groups 

Task 1 Clear Existing SAP Logon Entries 

This task depends on the setup of your training front end. 

1. As there could already be entries in your local SAP Logon from other 

training courses, choose the following call, if it exists: 

Start → Training → SAPLogon Reset. 

This call edits your local saplogon.ini file so that there are no 

system entries, and perhaps a “dummy” entry in the file. 

a) Follow the exercise instructions. 

Task 2 Set up SAP Logon Using the Groups Button 

1. Choose the Groups... button and create a new entry. Use the data that 

your instructor gives you (system ID, host name) for this entry. 

a) Enter the abbreviation for the system that you have been 

assigned, such as DEV, intheSystem ID input field. Note that 

an entry can already exist for a system in the sapmsg.ini 

file. However, this entry does not point to the training system 

that you are using. Therefore, under Message Server, enterthe 

name of the host on which “your” SAP system is running (such 

as twdf9999). 

b) Choose Generate list. 

c) Select a group (such as SPACE) from the list in the Groups 

field, and then choose Add. Confirm the following window by 

choosing OK. 

Task 3 Set Up Logon Groups 

1. Log on to your system using your new entry in SAP Logon (with the 

parameters that your instructor gives you). Call transaction SMLG 

(Tools → CCMS → Configuration → Logon Groups). 





2. Choose the Create Assignment button to create a new logon group 

with any name (such as “DEV_##”, where ## is your group number). 

Assign at least one of the two instances of your system to your new 

logon group. Copy and Save your entries. 

a) In transaction SMLG, you can see a list of the logon groups that 

exist in the system and the instances assigned to them. 

b) To create a new assignment, choose the Create assignment button. 

In the following dialog box, enter any name for your new logon 

group in the Logon Group field. Use the F4 help for the Instance 

input field to select an instance that you want to assign to the 

new logon group. Then choose Copy. 

c) Save the list of logon groups. 

d) You can now assign additional instances to your new logon 

group, or create new logon groups. To do this, choose the Create 

assignment button again. Remember to Save after making entries. 

Task 4 Using Logon Groups through “Group Selection” 

in SAP Logon 

1. In SAP Logon, choose the Groups... button again to add a new entry. 

If the logon group that you created previously does not yet appear 

in the display, the message server has not yet registered the newly 

created logon group. This is done automatically every five minutes. 

You can therefore generate the list again after a few minutes. 

a) Follow the same procedure as in task 2 and this time, choose the 

logon group that you created in task 3. 

2. Log on to your system using the new entry in your SAP Logon. 










Lesson: 

22 

Analysis Transactions 



In this lesson, you will obtain an overview of a number of frequently used 

analysis transactions for system administration. 




This slide should serve as a “hanger” with which you can bring the 

previous knowledge of participants to as uniform a state as possible with 

regard to the transactions listed. In the ADM100 course, this must not, 

however, lead to a detailed repetition of content from the SAPTEC course, 

as some participants may already know the listed functions from that 

course. You could possibly also take into account the wishes of participants 

here with regard to simple but “exotic” transactions, such as ST22 (in the 

ADM100 course, this function is introduced again later), AL11; and could 

providesimpleviewsofbufferperformance(ST02)anddialogresponse 

times (ST03N). However, these topics are also explained in more detailed 

advanced courses (ADM115/BC315). 


You want to obtain an overview of the transactions that help you to 

perform your daily work as a system administrator. 

Common Administration Tasks 

The transactions shown in the figure below help you to deal with daily 

system administration work. You should already be familiar with the 

usage and interpretation of most of these transactions. 


ADM100 Lesson: Analysis Transactions 

Figure 9: Common Administration Transactions 

You can use transaction SM51 to display the instances of your SAP 

system. From there, it is possible, among other things, to go to the user 

list (transaction SM04) or the work process overview (transaction SM50) 

for a selected instance. 

You can use transactions SM04 and AL08 to obtain an overview of the 

users logged on to the system. Note that only those users that are logged 

on to the instance from which you called this transaction are displayed 

in transaction SM04. You can use transaction AL08 to obtain an overview 

of “all” users logged on to the system. Unlike SM04, transaction AL08 

provides only display functions. 

TransactionSM50providesanoverviewoftheworkprocessesconfigured 

for an instance. There is also a “global” equivalent to this transaction 

(SM66), with which you can display all of the work processes for the entire 

SAP system. Like transaction SM50, transaction SM66 provides other 

functions in addition to purely display functions. 

You can use transaction SM37 to obtain an overview of the background 

jobs in your SAP system. 

You can manage lock entries in the lock table of the enqueue work process 

using transaction SM12. 

Use transaction SM21 to analyze the system log. 

If you want to send all users in your SAP system a message, you can use 

transaction SM02 to send a system message. It is also possible to restrict 

the recipients to users of a certain client, or users that are logged on to a 

particular instance. A system message appears for users when they next 

perform an action. 



You can use transaction RZ20 to monitor the SAP system, or to centrally 

monitor multiple SAP systems. 

Update 

The majority of updates in the SAP system are processed by the update 

work process. It is the task of the administrator to ensure smooth 

processing of the update. You can use transaction SM13 to monitor the 

update requests. 

If an update work process is not able to successfully process an update 

request, by default, the end user that created the affected data receives 

a message from the system. The affected update request is displayed 

in the overview of the update requests with the status canceled. The 

administrator’s task is to determine the cause of the termination, and, if 

necessary, to correct the problem that caused it. 

Use the administration data for an update request to find the cause of the 

termination. You can display this information by choosing the Update 

header button in transaction SM13. 

After you have solved the problem, the end user usually recreates the 

data that was not updated. Only in exceptional cases, and then only in 

agreement with the department concerned should the administrator 

“reupdate” the affected request. 



25 Exercise 2: Common Administration 

Transactions 






You want to obtain an overview of the transactions that help you to 

perform your daily work as a system administrator. 

Task Basic Administrative Transactions 

1. Determine the number of instances available to you in your system 

and their names. 

2. How many work processes does your entire SAP system have? Of 

which types? 

3. How many users are currently logged on to the same instance on 

which you are working? 

4. Call your Own Data (user defaults). In a new session, check the 

currently active locks in your system. Use another new session to 

delete the session holding the locks. There are two options for doing 

this. What happens to the locks? 



Solution 2: Common Administration 

Transactions 

Task Basic Administrative Transactions 

1. Determine the number of instances available to you in your system 

and their names. 

a) To do this, call transaction SM51 (alternatively, choose: Tools → 

Administration → Monitor → System Monitoring → Servers). Your 

system should have two instances, the names of which could be, 

for example, twdf9999_DEV_00 and twdf9999_DEV_01. 

2. How many work processes does your entire SAP system have? Of 

which types? 

a) If you make the correct settings for the Process Selection (ensure 

that you also display waiting processes), transaction SM66 

(menu path, for example: Tools → Administration → Monitor → 

Performance → Exceptions/Users → Active Users → All processes) 

will show you that your system has, for example, eight 

dialog work processes, four spool work processes, and so on. 

Transaction SM66 shows all work processes of a system, unlike 

transaction SM50. 

Hint: In transaction SM66, you can also show the work 

process that is currently processing your user request, 

by choosing Settings and deselecting the option Hide own 

work processes used analysis. 

3. How many users are currently logged on to the same instance on 

which you are working? 

a) Transaction SM04 (or Tools → Administration → Monitor → System 

Monitoring → User Overview) displays the number of users that 

are logged on to the same instance as you. 




4. Call your Own Data (user defaults). In a new session, check the 

currently active locks in your system. Use another new session to 

delete the session holding the locks. There are two options for doing 

this. What happens to the locks? 

a) Choose System → User Profile → Own Data. You can set user 

defaults in a new session that opens automatically. Use the 

call /OSM12 in the command field to display an overview of 

currently active locks in your system. Do not restrict the selection 

of locks. There should be an active locks that is connected to 

changing your user defaults. You can either end the session 

that holds the locks using transaction SM04 (Select the user 

and choose the Sessions button) or obtain an overview of your 

sessions by entering /O, from which you can identify and end 

the session that holds the locks. 







ADM100 Unit Summary 

Unit Summary 











Unit Summary ADM100 


ADM100 Test Your Knowledge 

31 

Test Your Knowledge 

1. The instance that, together with the database, creates a runnable SAP 

system, is called the central instance central instance. 

Fill in the blanks to complete the sentence. 

2. What types of work processes are there in the SAP system? 

Choose the correct answer(s). 

A Update work process 

B Spool work process 

C Dialog work process 

D ICM work process 

E Enqueue work process 

F Instance work process 

3. SAP systems use 

work process multiplexing work process multiplexing technology 

to process user requests. 


4. Which button(s) can you use to create new entries in the SAP Logon 

system list? 


A Properties 

B New 

C Logon 

D Groups 

E Server 

F Create 

5. What possible advantages does the correct use of logon groups offer? 


A The users are automatically logged on to the correct system 

B The program buffers perform better 

C The program buffers can be set up smaller 

D The program buffers may now be larger than 1 GB in size 


Test Your Knowledge ADM100 

6. With which transaction can you obtain an overview of the instances 

of your SAP system? 


A SM50 

B SM51 

C SM52 

D SM04 

7. You can use transaction SM12 SM12 to manage the lock entries of the 

SAP system. Transaction SM13 SM13 is used to manage the update 

requests. 

Fillintheblankstocompletethesentence. 



33 

Answers 

1. The instance that, together with the database, creates a runnable SAP 

system, is called the central instance. 

Answer: central instance 

2. What types of work processes are there in the SAP system? 

Answer: A, B, C, E 

The ICM (Internet Communication Manager) is not a work process, 

but rather a service of the SAP Web Application Server. An instance 

consists of a dispatcher and multiple work processes. The instance 

itself is therefore not a work process. In addition to the correct work 

process types listed above, there are also background work processes. 

3. SAP systems use work process multiplexing technology to process 

user requests. 

Answer: work process multiplexing 

Put differently, this means that there is not a one-to-one assignment of 

user to dialog work process for the entire duration of the logon. 

4. Which button(s) can you use to create new entries in the SAP Logon 

system list? 

Answer: B, D, E 

You can use the Properties button to display the properties of an entry. 

You can use the Logon button to log on the selected system. There is 

no Create button in the SAP Logon program. 

5. What possible advantages does the correct use of logon groups offer? 

Answer: B, C 

The users still need to log on to the system in the normal way after 

logon groups have been configured. Creating logon groups is not a 

prerequisite for setting buffer sizes of above 1 GB. 



6. With which transaction can you obtain an overview of the instances 

of your SAP system? 

Answer: B 

Transaction SM50 lists the work processes of an instance. Transaction 

SM52 does not exist, and transaction SM04 calls the user list for an 

instance. 

7. You can use transaction SM12 to manage the lock entries of the SAP 

system. Transaction SM13 is used to manage the update requests. 

Answer: SM12, SM13 

Transactions SM12 and SM13 are important tools for the system 

administrator. 


Unit 2 

35 Starting and Stopping the SAP System 

Starting and stopping an SAP system will be discussed in this unit. The 

associated starting and stopping of the database is not explained here, 

as the specifics of the individual databases are too different. The most 

important log and trace files that are created by the SAP system, the 

database, or the operating system are also introduced. The sequence of the 

required steps is important: Start services - start database - start the central 

instance - start other dialog instances. The sequence when stopping is 

exactly the reverse. 

Unit Overview 

The topic of this lesson is the starting and stopping of an SAP system. 

These are two of the basic tasks of system administration. You will also 

learn about the available log and trace options, to be able to react correctly 

if an error occurs. 



• Describe the process of the start procedure of an SAP system 

• Start the entire SAP System or individual instances 

• Evaluate start logs to analyze problems 

• Stop the entire SAP System or individual instances 

• Describe the starting and stopping of an SAP system under different 

operating systems 

• Describe the locations of the log files for various databases 

Unit Contents 

Lesson: System Start: Process................................................ 41 

Exercise 3: Starting the SAP System..................................... 49 

Lesson: System Start: Logs.................................................... 53 


Unit 2: Starting and Stopping the SAP System ADM100 

Demonstration: Displaying SAP System Log Files...................... 53 

Lesson: System Shutdown: How and Why? ................................. 60 

Exercise 4: Stopping an SAP System .................................... 65 

Lesson: Appendix - Starting and Stopping with Other Operating 

Systems ........................................................................... 69 

Lesson: Appendix - Database Logs ........................................... 78 


ADM100 Lesson: System Start: Process 

Lesson: 

36 

System Start: Process 



The topic of this lesson is the starting of an SAP system. In addition to the 

actual start sequence, the concept of services under Microsoft Windows is 

discussed in detail. 





In this lesson, an SAP system is started under Microsoft Windows as 

an example. The processes for other operating systems are analogous. 

The start sequence is important: Database services and SAP services, the 

database, the central instance, the other dialog instances. 


As the administrator of SAP systems, you need to stop the systems for 

maintenance purposes or after changing system parameters, and then 

restart them. 

Preparatory Work: TobeabletodemonstratethestartingoftheSAP 

system, you may have to shut it down first. To do this, log on to your 

server with the Terminal Server Client. Use the operating system user 

adm with the password adm to do this. 

Stop your system with the Microsoft Management Console (MMC). 

StartDBMGUIatoperatingsystemlevel(thereisashortcutontheuser 

interface). Register the databases on your server. Open the Register 

Database window by choosing File → Register. Select the two databases 

DEV and QAS and choose Register. The system now requests a database 

user with password for each database. Enter control/control for each 

database. Then choose the Close button in the Register Database window. 

Two databases are now displayed in the DBMGUI. The green selection 

indicates that the databases have been started. Start or stop the relevant 

database and then choose the green (Online) or red (Offline) button. 



Start Process of the SAP System 

The starting of an SAP system is the basic prerequisite for being able 

to work with the system. Restarts of SAP systems are also required 

after maintenance work on the hardware in use and changes to the SAP 

system’s profile. Starting an SAP system is an initial process with which 

every administrator should be familiar. 

You should emphasize at this point which components of an SAP system 

should be started in which sequence. To be able to start the SAP system, 

the database must first be started. This unit deals only with starting and 

stopping the SAP system, and does not discuss starting and stopping the 

individual database systems. 

Figure 10: Start Process of the SAP System 

Starting an SAP System is performed in a number of steps and is the task 

of the operating system user adm. 

Start the database: 

• The underlying element of the entire SAP system is the database. 

Before the SAP instances are started, this must have operational 

status. The database is therefore always started as the first step. 

Start the central instance: 



• Next, the operating system collector SAPOSCOL is started, if it 

is not already active. This is a standalone program that runs in the 

operating system background, independently of SAP instances. It 

collects data about operating system resources and makes this data 

available through the shared memory of all SAP instances. 

• The central instance with the message server and the dispatcher 

and its work processes is then started. Only once the message and 

enqueue servers are active can other instances be started, if desired. 

Start other instances: 

• If the dialog instance is not running on the same host as the central 

instance, the SAPOSCOL operating system collector is first started 

on this host. 

• The dispatcher is then started with its work processes. 

The Services Concept under Microsoft Windows 

Figure 11: Services Concept 

Explain the services concept that is used for starting an SAP system under 

Microsoft Windows. When starting programs in the Microsoft Windows 

environment, you should note that these programs are only active as long 

as the user is logged on to the system. The SAP system therefore uses the 

concept of services to start. These are programs that are automatically 

started and administered by the operating system. Services provide 

support to other programs and run even if there are no users logged on 

to the host. 



When starting programs in the Microsoft Windows environment, you 

should note that these programs are only active as long as the user is 

logged on to the system. When a user logs off, all of his or her programs 

are ended. The SAP system therefore uses the concept of services to start. 

These are programs that are automatically started and administered by the 

operating system. Services provide support to other programs and run 

even if there are no users logged on to the host. 

The Service Control Manager starts the services installed in the registry 

during the startup of Microsoft Windows 2000. All services can be 

configured for automatic startup. 

During the installation of the SAP system, SAP and database services are 

installed in addition to the operating system services. 

SAP Services: 

• SAPOSCOL:CollectsperformancedataforoneormoreSAPinstances 

and runs once for each host. 

• SAP_: Controls the SAP instances and runs once 

for each instance. 

Database Services: 

• Create the connection to the database. 

• Control DB actions 

Starting the SAP System 

Figure 12: Starting the SAP System 



Present the individual steps of starting an SAP system. 

Under Microsoft Windows 2000, you can start and stop the SAP system 

with the Microsoft Management Console (MMC). 

To do this, the administrator logs on totheoperatingsystemasuser 

adm, and opens the Microsoft Management Console. 

Choose the node for the central instance in the tree. Call up the context 

menu with the right mouse button and choose the Start function. The 

system first checks whether the database is active. If not, it is automatically 

started. If the database is active, the central instance (message server and 

dispatcher) is started by SAP Service SAP_. The 

communication between the Microsoft Management Console and the SAP 

Service takes place through a “named pipe”. 

Other instances can then be started. 

The status of the SAP system, individual instances, and the message server 

and dispatcher are displayed in the Microsoft Management Console in 

accordance with the following color legend: 

• gray not running 

• yellow is starting 

• green active 

• red terminated after errors 



Figure 13: Start Sequence of Processes of the SAP System 

Start sequence of the processes: Explain in detail which processes are 

started in which order by the service SAP_ when 

an instance is started. The service SAP_ takes 

information about the properties of the instance (such as instance type and 

the type and number of work processes) from the start profile, and the 

dispatcher from the default and instance profiles. 

System Demo: Log on to your server with the Terminal Server Client. Use 

the operating system user adm with the password adm to do 

this. Display the SAP_ services. 

Open the Microsoft Management Console. Display the entries for the 

training systems and the corresponding instances. Start the central 

instance first and then the dialog instance. You can use the program 

Quickslice (Start → Run → qslice) to show the individual processes that 

are started in parallel. 

The specifications of the instances; that is, the type and number 

of processes, main memory sizes, and other options are 

controlled at the start of the instances using profiles. These are 

files at operating system level that are stored in the directory 

\\\sapmnt\\sys\profile. 



When the instances are started, SAP Service reads which processes 

(message server, dispatcher) are to be started from the instance-specific 

start profile. The start profile can be displayed in the Microsoft 

Management Console by choosing the right mouse button on the entry for 

the instance and selecting the function All tasks → View Start Profile. 

The specification of the configuration of the instances is stored in the 

default profile and in the instance profile. These profiles are read 

by the dispatcher, which starts the work processes and creates the 

instance-specific configuration. 

After the instance has been successfully started, all work processes connect 

to the database. 





41 Exercise 3: Starting the SAP System 




• Start an SAP system 




restart them. 

Task 1 Starting with the Microsoft Management 

Console 

Start the SAP system using Microsoft Management Console. 

1. Start the SAP system using Microsoft Management Console. Monitor 

the start of the processes of your system. 

To do this, log on to the server for your training system using the 

Terminal Server Client. 

2. Which process types are started at operating system level after your 

system is started up? 

3. Check whether your system started correctly. To do this, log on to 

your SAP system and call the process overview. Compare the list 

of processes at operating system level with the process overview 

in the SAP system. 

Task 2 Starting from the Command Line (Optional) 

Start the SAP system using a command call. 

1. Start the SAP instances by entering the command startsap. Startthe 

central instance first and then the dialog instances. 



Solution 3: Starting the SAP System 

Task 1 Starting with the Microsoft Management 

Console 

Start the SAP system using Microsoft Management Console. 

1. Start the SAP system using Microsoft Management Console. Monitor 

the start of the processes of your system. 

To do this, log on to the server for your training system using the 


a) Start the Terminal Server Client and enter the physical host 

name under Server. Choose the display resolution for the remote 

connection on your front end, and choose Connect. Log on to the 

operating system as user adm. 

Start the Microsoft Management Console by double clicking the 

appropriate icon. 

Choose the node for the central instance in the Microsoft 

Management Console tree. Select the desired instance and 

choose the Start function from the context menu (right mouse 

button). Start the dialog instance in the same way. 

Hint: You should always start the central instance first. 

2. Which process types are started at operating system level after your 

system is started up? 

a) You can monitor the processes at operating system level with 

Task Manager or the Quick Slice tool (Start → Run: qslice). 

The following process types are started at operating system level 

after your system is started up: saposcol.exe, msg_server.exe, 

gwrd.exe, icman.exe and multiple disp+work.exe. 

3. Check whether your system started correctly. To do this, log on to 

your SAP system and call the process overview. Compare the list 

of processes at operating system level with the process overview 


a) Log on to your SAP system. The process overview Tools → 

Administration → Monitor → System Monitoring → Process 

Overview, transaction SM50) displays a list of work processes 

for the instance to which you are logged on. The dispatcher 

and all work processes are visible at operating system level as 

disp+work.exe. An assignment can be made using the process ID. 




Task 2 Starting from the Command Line (Optional) 

Start the SAP system using a command call. 

1. Start the SAP instances by entering the command startsap. Startthe 

central instance first and then the dialog instances. 

a) Start the SAP instances by entering the command startsap. 

startsap syntax: 

startsap name= nr= 

SAPDIAHOST= 

Start the central instance first and then the dialog instances. 








ADM100 Lesson: System Start: Logs 

Lesson: 

45 

System Start: Logs 



In this lesson, you will become familiar with the most important log and 

trace files, in which the start of an SAP system is logged. 




The most important log and trace files, in which the starting of the SAP 

system is logged, are introduced in this lesson. 


Problems occurred when starting an SAP system. To correct these 

problems, the administrator analyzes logs and trace files that were 

generated during the system start. 

Messages generated during the start process are logged by the operating 

system and the SAP system. Clarify which information is logged by which 

system. 

Messages from the services and the MMC are logged by the Microsoft 

Event Viewer. 

More detailed information is stored in the SAP system logs in the 

home directory of the adm user. Inform the participants that the 

granularity of the logged information can be set to four levels using the 

profile parameter rdisp/TRACE. 

Demonstration: Displaying SAP System Log Files 

Purpose 

The participants are shown important SAP system trace files. 



System Data 

System: Depends on the setup for your course. 

Client: Depends on the setup for your course. 

User ID: Usually ADM100-00. 

Password: Freely definable, initially set to init. 

Set up instructions: See the information for the exercises. 

1. Show the SAP system log files in the directory 

g:\usr\sap\\instance_no.\work. You should 

also show the contents of the developer traces (dev_ms, dev_disp, 

and dev_wx) at this point. 

Logging the Start Process 

The start process is an especially important phase, which is logged by the 

operating system, the SAP system, and the database. If the SAP system 

does not start up, you can find the relevant error message in the log files. It 

may be that there were problems starting the database, meaning that the 

SAP system could not subsequently be started. 

Figure 14: Logging of the Start Process Under Microsoft Windows 

All messages that are created by services or the Microsoft Management 

Console are recorded at operating system level by an event logging service, 

the Event Manager. This Event Viewer writes an event log which contains 

the following components: 

• System Log: 



Operating system and application messages 

• Application Log: 

List of errors, warnings, and information that is generated by 

application software. 

• Security Log: 

Events such as log ons and log offs and user access to files. 

You can call the event log by choosing Start → Programs → Administrative 

Tools → Event Viewer. Choose the relevant component from the menu bar. 

The system displays a list of errors, warnings, and information that have 

been generated. For detailed information, double click a particular log. 

Figure 15: Logging of the Start Process in the SAP System 

Logs about the start process of the SAP system are stored in the file system. 

If there are problems during the start, these logs can provide useful 

information such as error messages or problem descriptions. These files 

are stored in the home directory (DIR_HOME) of the relevant instance. 

The log files STDERR are created by the SAP service during the start 

process. The starting processes write to the individual files, depending on 

the sequence in which they are listed in the start profile. The contents 

of these log files therefore depends on the individual system setup, and 

could, for example, be as follows: 

• STDERR1: Information about the start process of the database system. 

• STDERR2: Information about the start process of the message server. 



• STDERR3: Information about the start process of the dispatcher. 

You can set the granularity of the logged information to four levels using 

the profile parameter rdisp/TRACE . The possible values for this parameter 

are: 

• 0: Errors only 

• 1: Error messages and warnings (Default) 

• 2: Error messages and a short trace 

• 3: Error messages and a complete trace 

The higher the trace level, the larger the amount of logged information, 

and therefore the larger the size of the files. You should therefore only 

increase the default value for short periods for problem analysis. 

The trace level can be set separately for individual work processes in the 

process overview (transaction SM50). 

Problem Analysis 

Figure 16: Problem Analysis 

Discuss again the procedure to be followed if problems occur when 

starting an instance. 



If the SAP system does not start correctly, this can have a variety of causes. 

To analyze the problem, proceed as follows: 

• Check the error messages and warnings in the Event Viewer. Check 

that the service SAP_ (such as SAPDEV_00) 

wasstarted.Todothis,gototheServiceswindow(Start → Programs 

→ Administrative Tools → Services). 

• Check the status of the respective database system using the error log 

files. For more information about this, see the lesson: “Appendix 

- Database Logs”. 

• Check the start log in the MMC. To do this, select the affected instance 

and choose All Tasks → View Developer Traces in the context menu. 

• Check the error files stderr that were created by SAP Service. 

• Check the trace files of the individual SAP work processes: 

– dev_ms : Developer trace for the message server 

– dev_disp : Developer trace for the dispatcher 

– dev_w (m is the work process number): Developer trace for 

the work process 

If you can still log on to the SAP system, check the system log of the SAP 

system using transaction SM21. 















Lesson: 

50 

System Shutdown: How and Why? 



In this lesson, the stopping of an SAP system is demonstrated, including 

the preparatory activities in the system. Stopping the database is a 

separate process. The sequence in which the SAP instances are shut down 

is important: first the dialog instances, and finally the central instance. 




It is important to describe the sequence in which the instances must be 

stopped. If the SAP system is stopped due to a kernel upgrade, under 

Microsoft Windows the SAP-specific services must also be stopped, as 

the kernel files cannot otherwise be overwritten. You can demonstrate 

stopping the system both with the Microsoft Management Console 

(MMC) and at operating system level. You can deliberately violate the 

recommended stop sequence and show that it is still possible to log on to 

the dialog instances. However, it is not possible to perform meaningful 

work, as central functions of the message and enqueue server are no 

longer available. 




restart them. 

Discuss with the participants what the administrator should consider 

before stopping the SAP system and how he or she can inform the users 

about the stopping of the system. 

Explain which tools (CCMS, MMC) can be used to stop the SAP system. 

Describe how the other components of an SAP system can be stopped. 


ADM100 Lesson: System Shutdown: How and Why? 

System Demo: Stop the SAP system using the MMC. 

You could additionally demonstrate starting and stopping the SAP system 

using a command call with the commands startsap and stopsap. 

Stopping the SAP System 

It can be necessary to stop an SAP system for a variety of reasons, such as 

to restart after permanently changing profile parameters, before installing 

kernel patches, or to allow hardware upgrades to be carried out. 

Figure 17: Before Stopping the SAP System 

Before you stop the system, you should check the status of the system. 

This involves, among other things: 

• Active Users: 

Check which users are logged on using the User List (SM04). 

• Background Processing : 

Check which jobs are active using the Job Overview (SM37). If jobs 

are terminated by the system stop, these must be rescheduled. Jobs 

that are scheduled for the time in which the system is stopped run 

automatically once the system is restarted. 

• Batch Input: 

The transaction Batch Input: Session Overview (SM35) displays 

running batch input jobs. 

• Update: 



Use the Update Overview (SM13) to check whether update processes 

are terminated by the system stop. These update records are rolled 

back during the stop, and these are set to the status “init”. These 

records are then updated again during the restart. 

Before you stop your system, you should inform users using a system 

message (SM02). 

Figure 18: Stopping the SAP System 

The stopping of the SAP system is performed in the opposite order to 

the start. 

Stopping the instances: 

• In the SAP system itself in the CCMS (transaction RZ03) by choosing 

Control → Stop SAP instance. 

• In the Microsoft Management Console, right-click to show the context 

menu and choose the Stop function. Depending on whether you have 

selected an individual instance or the SAP system, the following are 

stopped: 

– A single instance 

– Central instance and all dialog instances 

The SAP service waits for a stop message from the MMC or from the 

CCMS and then stops the SAP system. The service itself is not stopped. 

The services themselves can be stopped and restarted with the Microsoft 

Windows Service Control Manager. 



The database is stopped using the relevant database system tools. 





53 Exercise 4: Stopping an SAP System 




• Stop an SAP system 




restart them. 

Task 1 Stopping with the Microsoft Management 

Console 

Stop the SAP system using Microsoft Management Console. 

1. Before you stop the SAP system, check which users are logged on to 

your system. Send a system message. 

2. Stop the SAP system using the Microsoft Management Console. 

To do this, log on to the server for your training system with the 


Task 2 Stopping from the Command Line (Optional) 

Stop the SAP system using a command call. 

1. Log on to the server with the user adm over a Telnet connection. 

2. Check whether your SAP system is running at operating system level. 

3. Enter the command stopsap to stop an instance. To stop the entire SAP 

system, first stop the dialog instance and then the central instance. 

The command stopsap only stops the selected instance. If the database 

is to be stopped, this must be done using database tools. 



Solution 4: Stopping an SAP System 

Task 1 Stopping with the Microsoft Management 

Console 

Stop the SAP system using Microsoft Management Console. 

1. Before you stop the SAP system, check which users are logged on to 

your system. Send a system message. 

a) You can use the global user overview to display the users logged 

on to your SAP system: Tools → Administration → Monitor → 

Performance → Exceptions/Users → Active Users → Users global 

(transaction AL08). In this transaction, you will find your 

own user more than once. Transaction AL08 collects the user 

information for all instances using RFC connections. This means 

that your own user, which initiates the RFC connections, is 

displayed additionally once per instance. 

To send a system message to the users, choose Tools → 

Administration → Administration → System Messages (Transaction 

SM02). Choose the Create pushbutton, enter the system message 

text, and choose Save. 

2. Stop the SAP system using the Microsoft Management Console. 

To do this, log on to the server for your training system with the 


a) Start the Terminal Server Client and enter the physical host 

name under Server. Choose the display resolution for the remote 

connection on your front end, and choose “Connect”. Log on to 

the operating system as user adm. 

Start the Microsoft Management Console by double clicking 

the appropriate icon. Select the desired instance(s) and choose 

the Stop function from the context menu (right mouse button). 

Depending on whether you have chosen an individual instance 

or the SAP system, either an individual instance or the entire 

SAPsystemisstopped. 

Task 2 Stopping from the Command Line (Optional) 

Stop the SAP system using a command call. 

1. Log on to the server with the user adm over a Telnet connection. 

a) Use the tool specified by the instructor to create a Telnet 

connection to your server. Log on with the user adm and 

password adm. 




2. Check whether your SAP system is running at operating system level. 

a) To do this, run the command tlist /t| more to display an 

overview of operating system processes. 

3. Enter the command stopsap to stop an instance. To stop the entire SAP 

system, first stop the dialog instance and then the central instance. 

The command stopsap only stops the selected instance. If the database 

is to be stopped, this must be done using database tools. 

a) Enter the command stopsap to stop an instance. 

stopsap syntax: 

stopsap name= nr= 

SAPDIAHOST= 

To stop the entire SAP system, first stop the dialog instance and 

then the central instance. 







ADM100 Lesson: Appendix - Starting and Stopping with Other Operating Systems 

Lesson: 

57 

Appendix - Starting and Stopping with Other 

Operating Systems 



In this lesson, you receive information about starting and stopping an SAP 

system under different operating systems. 





This lesson should serve as a reference work for the participants for “their” 

operating system, and should not be discussed during the course. You may 

want to briefly explain starting and stopping the SAP system under UNIX. 


As a system administrator, you need to start and stop the SAP system. 



UNIX 

Figure 19: UNIX: Starting 

Log on in UNIX as a user with SAP administrator authorization 

(adm). 

To start the central instance call the shell script 

startsap__ inthehomedirectoryofthe 

adm user. If there is only one instance for each application server, the 

alias startup points to the script startsap__. 

The script startsap first starts the saposcol process, which collects 

statistical data for the operating system and provides it to the SAP system. 

The next step is a check to see if the database is running. If not, the script 

startdb is called to start the database. 

The final step starts all of the processes for the instance (message server, 

dispatcher, work processes, and so on). 

After the central instance is started, you can optionally start other instances. 

The startsap script can be called with the following options: 

DB: Starts the database system 

R3: Starts the instances and associated processes for the instance 

ALL: Starts the database system and the instance (default setting, can be 

omitted) 



To start the SAP system, the startsap script calls the sapstart process 

with the start profile specified in the script in the variable START_FILES. 

Figure 20: UNIX: Stopping 

When you stop the SAP system, you should first stop all dialog instances 

and then stop the central instance. You have two options for doing this: 

From the SAP system using the CCMS Control Panel. 

Log on under UNIX as the SAP administrator (adm) at operating 

system level and enter the command stopsap from your home directory. 

The stopsap script can be called with the following options: 

DB: Stops the database system with the help of the stopdb script 

R3: Stops the instances of the SAP system 

ALL: Stops the database system and the instance (default setting, can be 

omitted) 

The database can be stopped separately with database tools. 



OS/400 

Figure 21: OS/400: Starting 

LogonontotheAS/400systemwiththeSAPuserprofilefor 

administrators. The authorizations of the group profile OPRGRP are 

requiredforthisuser(suchasuserprofileOFRorOPR). 

Enter the AS/400 command STARTSAP and request parameters with F4. 

Under SAP System ID, enter the name of your system (such as DEV). 

Under R/3 Instance, enter the instance number (such as 00). To start all 

instances on one or more hosts, choose *ALL. 

Under R/3 Instance Host Name, enter the name of the host on which the 

instance is to be started. To start all instances on all hosts, choose *ALL. 

(You must also have selected *ALL under R/3 Instance.) 

Confirm your entries with ENTER. The subsystem R3_nn is then started 

for each started instance ( is the instance number). All associated 

SAP services are started together with the subsystem (such as dispatcher, 

work processes, spool processes). 

Enter the AS/400 command WRKACTJOB SBS(R3_) to check 

whether the SAP system(s) was/were started correctly. 



The system displays a screen with the column Status at the right-hand side. 

If an SAP system was started correctly, the first line of this column should 

contain the value RUN (running), SELW (waiting), or DEQW (waiting for 

completion of unlocking). It can take a few minutes for the file system 

to reach this status. 

Figure 22: OS/400: Stopping 

Logon on to the AS/400 system with the SAP user profile for 

administrators (OFR or OPR). 

Enter the AS/400 command STOPSAP and request parameters with F4. 

Under SAP System ID, enter the name of the SAP system that you want 

to stop. 

Under R/3 Instance, enter the number of the instance that you want to stop, 

such as 90. To stop all instances on one or more hosts, choose *ALL. 

Under R/3 Instance Host Name enter *LOCAL to stop one or more instances 

on the local host. To stop all instances on all hosts, choose *ALL. (Youmust 

also have chosen *ALL under R/3 Instance.) 

If you enter *YES under Wait for instance to end, the command STOPSAP 

waits until the SAP instance is shut down before stopping the SAP system. 

(The instance is regarded as shut down if the number of active instance user 

jobs, other than the SAPOSCOL job, in the instance subsystem is zero.). 



Under Maximum wait time (seconds), you can enter the maximum time that 

the command should wait for the instance to be shut down. The default 

value is 120 (two minutes). If it takes longer than two minutes for the 

instance to be shut down, an exception message is sent. 

Confirm your entries with ENTER. 

OS/390 

Figure 23: OS/390: Starting 

In an OS/390 environment, an S/390 system serves as a database server. 

You can use Microsoft Windows or UNIX systems as application servers. 

You must first start processes that allow the SAP work processes to connect 

to the database. 

Start the DB2 database on the OS/390 system with the appropriate 

operating system commands. 

Start the Recoverable Resource Manager (RRS) to synchronize all resources 

supported by OS/390. 

Instances on non-OS/390 systems require the ICLI servers to allow 

communication with the database. To allow this, start the ICLI server(s) on 

the OS/390 system. Use either the OS/390 JCL operating language or a 

script which uses the OS/390 UNIX system services. 

To start the SAP system, log on as operating system user adm on the 

UNIX or Microsoft Windows application server. 



First, start the central instance. To do this, call the startsap script 

underUNIXorusetheMicrosoftManagement Console under Microsoft 

Windows. If the saposcol process has not yet been started, this is started 

first. The processes of the central instances are then started. 

The work processes then connect to the database. 

Other instances can then optionally be started 

Figure 24: OS/390: Stopping 

You can stop the SAP system using either the CCMS Control Panel or 

operating system resources. At operating system level, under UNIX, run 

the command stopsap r3, or use the Microsoft Management Console 

under Microsoft Windows. 

The ICLI servers and the DB2 database are stopped on the S/390 system. 

Stop the ICLI servers either on the OS/390 system console with the 

command MODIFY BPXINIT, TERM= or by using the OS/390 

UNIX system services with the command kill . 

Check that the ICLI servers have been stopped. 

Stop the database. 
















Lesson: 

65 

Appendix - Database Logs 



This lesson provides information about the log files of various databases. 




This lesson is to act as a reference for the participants for the storage 

locations of the log files for various databases, and is not explained during 

the course. 


If an error occurs, the system administrator needs to access the database 

log files to find the cause of the error. 

SAP DB 

Figure 25: SAP DB 

SAP DB logs system messages and error messages in the directory: 

:\sapdb\data\wrk\. 

The system messages are recorded in the kernel log knldiag. This 

contains the following messages in chronological order: 

• Database start and stop 

• Information about the physical storage areas 


ADM100 Lesson: Appendix - Database Logs 

• User processes 

• System error messages 

The log is run as a circular memory file that is overwritten as soon as it 

reaches a certain size. A new log file is created after every start of the 

database system. A backup copy of the old log (knldiag.old) iscreated 

before a restart of the database system. 

All error and warning messages concerning the database system are 

recorded in the error log (knldiag.err), including the messages for the 

system start and stop. 

MS SQL Server 

Figure 26: MS SQL Server 

The MS SQL Server logs all significant events such as starting 

and stopping the database and error messages in the file 

:\MSSql7\Log\Errlog. A new error log file is written at every 

start of the MS SQL server. Multiple versions of these error log files are 

stored as Errlog.1, Errlog.2, and so on. The oldest available version is 

stored as Errlog.6. AteveryrestartoftheSQLserver,theoldestfileis 

overwritten. If a serious database problem occurs, you should backup the 

oldest file before the restart, so that this information is not lost. 

TheseerrorlogfilescanbedisplayedintheEnterpriseManager. 

Messages of the “SQLServerAgent” service that is required for backups are 

also logged in the above directory in the file Sqlagent.out. Thelastsix 

versions of this log are also retained. 



Oracle 

Figure 27: Oracle 

The Oracle database logs all significant events such as starting and 

stopping the database and error messages in the file 

:\oracle\\saptrace\background\ALRT.LOG. 

Detailed information about errors is logged in the Oracle Trace File: 

:\oracle\\saptrace\usertrace\Ora.trc. 

If the system administrator administers the database with sapdba, this 

writes its own log files in the following directories: 

:\oracle\\sapreorg 

:\oracle\\sapcheck 

:\oracle\\sapbackup 

DB2 (UDB) 

Figure 28: DB2 (UDB) 



The DB2 database logs all significant events in the file db2diag.log. 

The path under which this file is stored is define with the parameter 

Diagnostic Directory Data Path (DIAGPATH). This path is configured 

in the database manager configuration. The default value is 

$DB2INSPROF/DB2INSTANCE. 

The db2diag.log file contains the following information: 

• The place at which the reported error occurred. Application IDs 

allow the comparison of entries that belong to one application in the 

file db2diag.log. 

• A diagnostic message with the reason for the error. The message 

usually begins with “DIA”. 

• All other available data such as SQLCA data structures and pointers 

tootherdumportrapfiles. 

Detailed information about errors is logged in the DB2 trace or dump files, 

which are also stored in the path defined using parameter DIAGPATH. 

These files are only created if a serious internal DB2 error occurs. 

You can access the dump directory by calling transaction DB6COCKPIT 

and choosing Diagnosis → Dump Directory in the navigation box. 

If you want to display the contents of an error log or a trace file, double 

click the file. 

Informix 

Figure 29: Informix 

All significant events, such as starting and stopping the database 

and error messages are logged by the INFORMIX database in the file 

$INFORMIXDIR/online...log. 



Detailed information for individual errors is logged in the trace file 

af.. In certain cases, the contents of the shared memory 

are copied to the files shmem.. The directory in which 

these files are stored is defined using the parameter DUMPDIR. The 

default value of this parameter is /tmp. 

DB2 (OS/390) 

Figure 30: DB2 (OS/390) 

ICLI Server Message Reporting: 

ICLI Server Messages for one or more ICLI servers are written to one or 

more ICLI error log files. The file names follow the naming convention 

ICLI..msg, where is the process ID of the ICLI server 

and identifies multiple error log files of an ICLI server. 

The error log files of the ICLI are either stored in a directory that is 

determined during the start of the ICLI servers using the option -LOGDIR, 

orinthehomedirectoryoftheuserunderwhichtheywerestarted. 

ICLI Client Message Reporting: 

The ICLI servers also send messages to the communication partners of the 

client. These are logged in the developer traces and in the system log of 

the SAP system. 

The DB2 database logs all significant events and errors in the OS/390 

system log. 















Unit Summary 













73 


1. WhichSAPprocessesarestartedwhentheSAPsystemoraninstance 

is started? 


A SAPOSCOL 

B START_SAP_NOW 

C Message Server 

D Gateway Server 

E LAUNCH_DB 

2. Log information for the dispatcher is stored in the file 

dev_disp dev_disp. You can control the granularity of the logged 

information using the profile parameter rdisp/TRACE rdisp/TRACE. 

There are four four trace levels; error messages and warnings are 

displayed, by default, at level 1 1. 


3. You can display the users logged on to the SAP system with 

transactions SM04 SM04 and AL08 AL08. You can obtain an overview 

of the scheduled background jobs with transaction SM37 SM37. You 

can use transaction SM02 SM02 to send a system message to the users 

that are logged on. 




74 

Answers 

1. Which SAP processes are started when the SAP system or an instance 

is started? 

Answer: A, C, D 

SAPOSCOL is an underlying process that should always be running, 

even if the SAP system is shut down. START_SAP_NOW and 

LAUNCH_DB are made up. The message server is started once for 

each SAP system, and the gateway server is started once for each 

instance. 

2. Log information for the dispatcher is stored in the file dev_disp. You 

can control the granularity of the logged information using the profile 

parameter rdisp/TRACE. Therearefour trace levels; error messages 

and warnings are displayed, by default, at level 1. 

Answer: dev_disp, rdisp/TRACE, four,1 

3. You can display the users logged on to the SAP system with 

transactions SM04 and AL08. Youcanobtainanoverviewofthe 

scheduled background jobs with transaction SM37. Youcanuse 

transaction SM02 to send a system message to the users that are 

logged on. 

Answer: SM04, AL08, SM37, SM02 

Transaction SM04 is instance-specific, transaction AL08, on the other 

hand, is cross-instance. In transaction SM37, you can select by client 

and user, among other things. In transaction SM02, you can restrict 

the sending of the message to instances or clients. 


Unit 3 

75 Introduction to System Configuration 

The topic of this unit is the customizing of the system configuration using 

the various profile files and profile parameters. The aim is to use a number 

of examples to explain to the participants the resources with which they 

canconfigure“their”SAPsystem. 

Unit Overview 

In this unit, you will learn how you can use profile parameters to configure 

“your” SAP system. 



• Determine the configuration of system parameters 

• Adjust the system parameters using profiles 

• Set up a dynamic switch of work process types using operation modes 

Unit Contents 

Lesson: How the System Evaluates its Parameters......................... 90 

Exercise 5: Configuring the System Parameters........................ 95 

Lesson: How to Set System Parameters ..................................... 98 

Exercise 6: Maintaining the System Parameters.......................103 

Lesson: Setting up Operation Modes ........................................109 

Exercise 7: Setting up Operation Modes ................................117 


Unit 3: Introduction to System Configuration ADM100 

Lesson: 

76 

How the System Evaluates its Parameters 



This lesson explains how the system evaluates its parameters and where 

these parameters are stored. 




Explain that the system parameters are stored in the kernel of the SAP 

system during installation. This default configuration can be changed 

using entries in the profile files. Explain the sequence in which the 

parameters are imported. 

The profile files are created during the installation. Explain the significance 

of these files when starting the system. 

Describe which information is stored in the individual profile files. 

Explain the options for determining the current values of system 

parameters using transaction RZ11 and report RSPFPAR. 


You want to determine the system parameters for your SAP system. 

Configuring the System Parameters 

The configuration of the individual instances and therefore of the SAP 

system is performed using system parameters. The default values for these 

parametersaredefinedintheprogramcodeofthekernel. 


ADM100 Lesson: How the System Evaluates its Parameters 

Figure 31: Assigning System Parameters 

You can change these default values using the profile files, which are read 

when an instance is started. These profile files are created during the 

installation of the system and can also be edited later. 

As the profile files are only read when the system is started, you must 

restart the instance or the entire system after changing parameters. 

Dynamic switching; that is, while the system is running, is only possible 

for a small number of system parameters. 

Figure 32: Profile Files at Operating System Level 



The profile files are automatically created during installation. After 

installation is complete, the profile files are stored at operating system 

level in the directory: \usr\sap\\SYS\profile. Thisdirectorycanbe 

read by all instances of an SAP system using the share or mount technique. 

The SAP system has three system profiles. These are: 

• Start profile 

• Default profile 

• Instance profile 

In principle, you can change these files with operating system resources 

(editors). In doing so, the user must ensure himself or herself that the 

changes are performed correctly. Incorrectly set parameters can lead to 

the system not starting. It is far more convenient and safer to change the 

profile parameters using the resources in the SAP system. 

Show the profile files at operating system level. To do this, go to the 

directory g:\usr\sap\\SYS\profile in Windows Explorer. 

Make a backup of the profile files. To do this, create a separate directory 

and copy the files there. 

Figure 33: Profile Files: Overview 

The instance-specific start profile (START_), specifies for each instance which processes are to 

be started. These are, for example, the message server and the dispatcher. 



There is only one default profile (DEFAULT.PFL) for each SAP system, and 

it is read by all instances. It contains system-wide settings, such as the 

system name, the name of the database server, the name of the enqueue 

server, or also the default logon client. 

The instance profile (__) 

defines parameters that apply for one instance, such as the number 

and type of work processes, or the definition of the size and allocation 

of the main memory area used by the SAP system, and is therefore 

instance-specific. 

Figure 34: Viewing System Parameters 

Demonstrate how transaction RZ11 can be used to display the values 

and information for the individual system parameters. Execute report 

RSPFPAR and restrict your search to rdisp*. Explain the meanings of the 

System Default Value and User-Defined Value columns. Display the short 

description and details for selected parameters (rdisp/wp_no_dia). 

The current values of the system parameters can be displayed in the 

system. There are two ways to do this. These are: report RSPFPAR and 

transaction RZ11. Both functions display the system parameters for the 

instance to which the user is currently logged on. Report RSPFPAR 

displays a list of all instance-specific system parameters, along with the 

parameters that apply system-wide. You can restrict this list to specific 

parameters. A table displays the system default value for the individual 

parameters, as it is defined in the program code of the kernel, and, if the 

default value has been overridden by a profile parameter, the user-defined 

value. A short description and, if required, documentation for the 

parameters can also be displayed. Transaction RZ11 displays information 



and documentation for individual profile parameters. It also displays 

whether the parameter can be changed while the system is running with 

the Dynamically Switchable indicator. 

Note: In the TPFYPROPTY table, all dynamically switchable profile 

parameters are identified with the Dynamic indicator. You can use 

transaction SE16, for example, to display this table. 

Outside the SAP system, you can display the values of the profile 

parameters at operating system level using the user adm with the 

program sappfpar. You can display the current value of a parameter with 

sappfpar . The command sappfpar all returns a list of all 

parameters. You can check the parameters that are set using sappfpar check. 

The command sappfpar help returns a short overview of possible options. 

You can also specify an instance profile, an instance number, or the SAP 

system name with this command using the options pf=, 

nr=, orname=. 



81 Exercise 5: Configuring the System 

Parameters 






You want to determine the system parameters for your SAP system. 

Task Determine Values of System Parameters 

Determine the values of a number of system parameters. 

1. Determine the values of the following system parameters: 

Name of the application server, number of work processes on the 

central instance (dialog, background, enqueue, update, spool), 

maximum number of sessions permitted per logon 



Solution 5: Configuring the System 

Parameters 

Task Determine Values of System Parameters 

Determine the values of a number of system parameters. 

1. Determine the values of the following system parameters: 

Name of the application server, number of work processes on the 

central instance (dialog, background, enqueue, update, spool), 

maximum number of sessions permitted per logon 

a) You can determine the values of system parameters by running 

the report RSPFPAR. The parameter names are as follows: 

Name of the local application server: rdisp/myname. 

Number of work processes on the central instance: 

Dialog: rdisp/wp_no_dia 

Background: rdisp/wp_no_btc 

Enqueue: rdisp/wp_no_enq 

Update: rdisp/wp_no_vb 

Spool: rdisp/wp_no_spo 

Maximum number of sessions permitted per logon: 

rdisp/max_alt_modes. 








Lesson: 

84 

How to Set System Parameters 



In this lesson, you will learn how you can change the values of system 

parameters. 




Explain that changes to the profile files should not be made at operating 

system level. Present the advantages of maintaining profiles in the SAP 

system using transaction RZ10. 

Explain the individual steps that need to be performed in transaction RZ10 

to maintain the profiles. Emphasize that choosing Activate means that the 

profiles are written from the database to the file system and that changed 

parameters only take effect after a restart of the system. 


As an administrator, you are to adjust the configuration of the system 

parameters. 

Administering and Maintaining Profiles 

If you want to change profile parameters, you can make these changes 

using operating system-specific editors. However, this procedure has 

certain dangers, as the user must ensure himself or herself that the changes 

are performed, and also documented, correctly. Incorrectly set parameters 

can prevent an instance starting. The SAP system therefore provides 

integrated profile administration and parameter maintenance. 


ADM100 Lesson: How to Set System Parameters 

Figure 35: Profile Administration 

Profile administration in the SAP system offers the following advantages 

to the user: 

• Central administration and maintenance of the instances 

• Changes in profiles are checked for consistency 

• Administration of multiple versions of a profile 

• Comparison of the actively used profile and the profile stored in the 

database 

• Immediate activation of selected parameters 



Figure 36: Profile Maintenance 1/2 

After installation, the profile parameters are, at first, only present at file 

level. To be able to use the profile administration of the SAP system, 

theprofilesmustbeimportedintothedatabase. During this import, the 

system performs a consistency check and a check of the way in which the 

parameters interact. Changes to profile parameters can then be performed 

in the SAP system, with the previously mentioned advantages. These are 

then stored in the database, and written back to file level. These changes 

only take effect when they are read by the system; that is, at a restart of 

the system. 

You perform the administration and maintenance of profiles in transaction 

RZ10. In the first step, you import the profiles into the database by 

choosing Utilities → Import Profiles → Of active servers. After selecting the 

profile to edit, you can change individual profile parameters. There are 

three different levels for maintaining theprofiles.Theadministrationdata 

contains the type of profile (start, default, or instance profile), a short 

description, the path of the file, the name of the instance, and the time 

of the last activation. 

You can perform the maintenance of the parameters of the individual 

profiles through either basic maintenance or extended maintenance. 

Basic maintenance allows you to adjust the most important parameters 

and supports the user through the use of logical descriptions. Extended 

maintenance displays the unformatted content of the profile; that is, the 

technical names of the profile parameters. In extended maintenance, you 

can not only change the values of individual parameters, but also add new 

parameters and delete existing parameters. 



The changes are stored in two steps. In the first step, the changes are 

temporarily copied when you choose Copy. The values are permanently 

saved to the database in a second step when you choose Save. Thechanges 

are therefore successfully saved to the database and must now be written 

at operating system level. This is done either automatically during saving 

by confirming the relevant query or manually from the menu by choosing 

Profile → Activate. 

Figure 37: Profile Maintenance 2/2 

Changes to instance-specific profiles take effect after a restart of the 

corresponding instance. Changes to the default profile take effect only 

after a restart of all instances in the entire system. 

Changes to these files are, however, the exception rather than the rule. 

Use transaction RZ10 to import all profiles. Show the differences between 

the different views. Change individual profile parameters in the basic 

maintenance (Caution: increase the number of work processes only by 1 or 

2). Save and activate your changes and restart the system. Log on again 

after the restart and show the changes that have been made in the system. 



Consistency Check 

Describe the additional functions of transaction RZ10, such as the 

consistency check and the comparison of profiles. 

Additional functions available in transaction RZ10 are the consistency 

check and the comparison of profiles. 

Figure 38: Profile Consistency Checks 

During a consistency check, the system checks the syntax and the 

semantics for individual or for all profiles. 

The all profiles option also contains a consistency check between the profiles 

of a type. This means that, for example, the system checks for the start 

profile whether only one message server is being started for each system. 

During the comparison of profiles, the system compares the profile that 

is in active use with the profile stored in the database. This comparison 

is automatically performed when an instance is started. If the system 

identifiesadifferencebetweentheactiveprofileandtheprofilestoredin 

the database, it displays a message in the Alert Monitor. 



89 Exercise 6: Maintaining the System 

Parameters 






As an administrator, you are to adjust the configuration of the system 

parameters. 

Task 1 Save Profile Files 

First back up the profile files. 

1. Save your “runnable” profile files in a backup directory. To do this, 

create a Backup directory under C:\Temp and copy all profile files to 

this directory. 

Task 2 Import and Maintain Profiles 

Use transaction RZ10 (Tools → CCMS → Configuration → Profile 

Maintenance) to perform the following tasks. 

1. Import all profiles into your SAP system. 

2. Change the values of the following parameters: 

i) Set the value for the maximum number of permitted sessions to 7. 

ii) Increase the number of dialog work processes for the dialog 

instance by 2. 

Consider which profiles you are performing changes in. 

Save and activate your changes. 

3. Check your changes in the system. To do this, log on to the system 

again and check the number of work processes in the process 

overview. 

4. i) Check your changes in the profile files at operating system level. 

ii) What must you still do, so that your changes take effect in the 

system? 




Task 3 Activating the Changed Profile Parameters 

Check the changed system parameters after a system restart. 

1. Restart the system so that your changes become active. 

2. Check your changes in the system again. 



Solution 6: Maintaining the System 

Parameters 

Task 1 Save Profile Files 

First back up the profile files. 

1. Save your “runnable” profile files in a backup directory. To do this, 

create a Backup directory under C:\Temp and copy all profile files to 

this directory. 

a) Log on to your server. Copy the profile files from the directory 

\usr\sap\\SYS\profile to the Backup directory. 

Task 2 Import and Maintain Profiles 

Use transaction RZ10 (Tools → CCMS → Configuration → Profile 

Maintenance) to perform the following tasks. 

1. Import all profiles into your SAP system. 

a) All profile files can be imported together by choosing: Utilities 

→ Import Profiles → Of active servers. A check log displays the 

result of the import. 

2. Change the values of the following parameters: 

i) Set the value for the maximum number of permitted sessions to 7. 

ii) Increase the number of dialog work processes for the dialog 

instance by 2. 

Consider which profiles you are performing changes in. 




Save and activate your changes. 

a) To change the values of individual parameters, select the 

corresponding profile (default or instance profile) and change 

this in Extended Maintenance. 

If no Change button is displayed, choose Display Change to 

switch to change mode. Select the desired parameter and choose 

Change or double click the relevant parameter. 

After making your changes, choose Copy and then Save. Then,in 

the list view, choose Copy and then Back. Save the new version 

of the profile and confirm the activation of the profile in the 

dialog box. 

To create a new parameter, choose Create under Extended 

Maintenance. 

The required parameters are listed below: 

• rdisp/max_alt_modes (default profile) 

• rdisp/wp_no_dia (instance profile) 

3. Check your changes in the system. To do this, log on to the system 

again and check the number of work processes in the process 

overview. 

a) Call the logon screen using SAP Logon. Check that your selected 

logon client is entered. Check the number of processes by calling 

the server overview (Tools → Administration → Monitor → System 

Monitoring→ Servers, transaction SM51), selecting the dialog 

instance, and then choosing Processes. 

4. i) Check your changes in the profile files at operating system level. 

ii) What must you still do, so that your changes take effect in the 

system? 

a) Open the profile files at operating system level with an editor 

and use this to view the changes that have been made. 

b) Your changes to profile parameters will only take effect after a 

restart of the affected instance or the entire system. 

Task 3 Activating the Changed Profile Parameters 

Check the changed system parameters after a system restart. 

1. Restart the system so that your changes become active. 

a) Logontoyourserverinthesamewayasyoudidintheexercises 

for the Starting and Stopping unit, and restart the system. 




2. Check your changes in the system again. 

a) Log on to the system after a successful restart. Check the default 

logon client on the logon screen and check the number of work 

processes for the dialog instance. 







ADM100 Lesson: Setting up Operation Modes 

Lesson: 

95 

Setting up Operation Modes 



In this lesson, you will learn about the concept of operation modes. You 

will learn how to set up a dynamic switch of work process types using 

operation modes. 




Present the concept of operation modes. Discuss the fluctuating 

requirements that users have of the system during the course of a day. 

System resources that are available to dialog work processes during the 

dayarenotrequiredduringthenight. 

Clarify that no additional work processes are created with the concept of 

operation modes. There is simply a change in the type and distribution 

of the work process types. The total number of work processes remains 

the same. 

Describe the individual steps for setting up operation modes in transaction 

RZ04. 

Explain that operation modes are scheduled for a period of 24 hours’ 

operation. Exceptions to this rule are possible using exception operation. 


The configuration of the work processes using the profiles usually meets 

the requirements for day operation. The administrator can use operation 

modes to optimize the performance of the system for the different 

requirements during the day and during the night. 

Concept of Operation Modes 

The demands of users on the SAP system vary during the course of the 

day. During the day, a large number of dialog users, who want to be 

served with high performance by the system, are working. Therefore, 

a large number of dialog work processes should be available for users 

during the day. During the night, however, only a small number of these 

dialog work processes are used, and the system can be used to a larger 

extent to process background jobs. 



Figure 39: Concept of Operation Modes 

The type and number of work processes for each instance is defined in the 

profiles. The distribution of work processes in the profiles is optimized 

for fast dialog response times; that is, there are usually lots of dialog work 

processes and a small number of background work processes. This means 

that during the night, system resources, such as the main memory, are tied 

to the dialog work processes, or are not fully utilized by the background 

processes, such as the CPU. It is therefore practical to define different types 

and numbers of work processes for these different demands on the SAP 

system. This is realized through the concept of operation modes. 



Figure 40: Adjusting Instances to the Load Distribution 

Using the operation modes, you can adjust the type and distribution of the 

work processes to the varying load distribution during the day. You can 

also adjust the distribution of the work processes to business requirements 

that only occur once. By defining operation modes, you can change not 

only the total number of work processes defined in the profiles, but also 

thetypeanddistributionoftheindividualworkprocesstypeswithinthis 

total number. The switch between the work process types is performed 

dynamically during the runtime of the SAP system. The switch is triggered 

using a defined schedule. A reserved work process is not immediately 

terminated, but marked for switching. This means that certain delays may 

occur. This type change is logged in the system log. 

During the switch of the operation modes, neither the instance nor the 

affected work processes need to be restarted. This means that the quality of 

the buffer of the SAP system is retained during an operation mode switch, 

and that the request that is currently being processed by a work process is 

completed. The individual work processes retain their process ID after the 

switch, which can be observed in the process overview (SM50). 

Setting Up Operation Modes 

Theoperationmodesaresetupinanumberofsteps. 

• First, the operation modes are created as empty containers in 

transaction RZ04. 



• Next, all active instances of the system are recorded and the work 

processesdefinedintheinstanceprofileareassignedtotheoperation 

modesasdefaultvalues. 

• You can now make allocations for the individual operation modes in 

the total number of work processes taken from the instance profile. 

Theallocationshouldbemadeprimarilybetweenthedialogand 

background work processes. 

• You then specify the periods for which the operation modes are valid 

and when the switch between the operation modes should occur, 

in the time table (SM63). 

Figure 41: Setting Up Operation Modes 

The time table (SM63) differentiates between normal operation and 

exception operation. A general time definition that applies almost all of 

thetimeissetusingnormaloperation. Inrarecases,inwhichaspecial 

distribution of the work processes for unusual system loads is required, 

these are defined using exception operation. 



Figure 42: Scheduling Operation Modes 

If you do not define a timetable for normal operation, no switch of 

operation modes is made. The configuration in the instance profile 

remains active. 

The exception operation can only be defined as a unique event. 

You can trigger an operation mode switch from a program that you have 

written yourself using a function module (RZL_PERFORM_BA_SWITCH). 

In transaction RZ04, create two operation modes, “Day” and “Night”. 

Change the distribution of the work processes of the instances for each of 

the operation modes. Define a timetable (SM63), in accordance with which 

the system is to switch between the operation modes. Demonstrate the 

possibility for scheduling exception operation. 

Monitoring and Consistency Check 

Describe the functions of the Control Panels (RZ03). Manual switching 

between the operation modes and starting and stopping instances. 

Switch between the operation modes manually in the Control Panel. Show 

the switch in the process overview. Stop the dialog instance from the 

Control Panel and then restart it again. 



Discuss the places in the system in which information about the definition 

of the work processes is stored. Explain that this can lead to inconsistencies 

and that in this case, the operation mode is not switched. 

The Control Panel (RZ03) allows you to monitor the instances and the 

operation modes . It provides functions to: 

• Check the status of all instances and of the operation modes 

• Start and stop the instances 

• Manually switch operation mode 

• Display an overview of the work processes 

• Switch to the Alert Monitor 

Figure 43: Control Panel 

You can switch the operation mode either for all instances (Control → 

Switch operation mode → All servers) or for a selected instance (Control → 

Switch operation mode → Selected servers). 

You can first simulate the switch of operation modes (Control → Switch 

operation mode → Simulation); that is, the system checks for which instances 

aswitchcanbeperformed. 

You can display a detailed analysis of the status of the individual instances 

by choosing Monitoring → Status Details. 

You can first simulate the switch of operation modes; that is, the system 

checks for which instances a switch can be performed. If it is not possible 

to switch between operation modes, this is usually due to inconsistencies 

in the SAP system. These inconsistencies can occur if the number of work 



processes is defined differently in different places in the system. These are 

the instance profile at operating system level, the instance profile in the 

database, and the definition of the operation modes themselves. 

Figure 44: Profile Consistency Checks 

If, for example, the number of work processes in the profiles is later 

changed, the system can no longer switch operation modes until after a 

restart of the instance. It is therefore necessary to adjust the configuration 

of the operation modes after a change to the profiles. 





103 Exercise 7: Setting up Operation Modes 






The configuration of the work processes using the profiles usually meets 

the requirements for day operation. The administrator can use operation 

modes to optimize the performance of the system for the different 

requirements during the day and during the night. 

Task 1 Create Operation Modes 

Create operation modes. To do this, use transaction RZ04 to perform the 

following steps. 

1. Create two operation modes, “Day” and “Night”. 

2. Now create a definition for the work process distribution for all 

instances of your system. 

3. Change the distribution of the work processes of your instances for 

each of the operation modes. 

Note that there should be at least two dialog and two background 

work processes in all operation modes. 

Task2ScheduleOperationModes 

Schedule the operation modes that you have created. 

1. Schedule the operation modes that you have created in the timetable 

for normal operation. 

Task 3 Manual Switch of Operation Modes 

1. To observe the change in work process distribution when the 

operation mode is switched, switch to the “Night” operation mode 

manually in the Control Panel. 

2. How can you observe the change of the work process distribution? 



Solution 7: Setting up Operation Modes 

Task 1 Create Operation Modes 

Create operation modes. To do this, use transaction RZ04 to perform the 

following steps. 

1. Create two operation modes, “Day” and “Night”. 

a) You maintain operation modes in transaction RZ04 (Tools → 

CCMS → Configuration → Operation Modes/Instances). 

You can create operation modes by choosing Create operation 

mode. Enter the name of the operation mode and a short 

description and choose Save. 

2. Now create a definition for the work process distribution for all 

instances of your system. 

a) Switch to the Instances/Operation Modes view by choosing 

Instances/Operation Modes. 

You define work process distribution for all instances of your 

system by choosing Settings → Based on current status → New 

instances → Generate. Choose Save. 

3. Change the distribution of the work processes of your instances for 

each of the operation modes. 

Note that there should be at least two dialog and two background 

work processes in all operation modes. 

a) To change the distribution of the work processes for the operation 

modes of the instances, double click the operation modes entries. 

You change and then save the distribution of the work processes 

in the dialog box: CCMS: Work Process Distribution. 

To do this, place the cursor in the column of the work process 

type that you want to change. You can change the number by 

choosing + and -. Then choose Save. 

After you have changed the distribution for all operation modes 

and instances, choose Save. 

Task2ScheduleOperationModes 

Schedule the operation modes that you have created. 




1. Schedule the operation modes that you have created in the timetable 

for normal operation. 

a) You can schedule operation modes using the operation mode 

calendar (Tools → CCMS → Configuration → Operation Mode 

Calendar, transaction SM63). 

Select Normal Operation and then choose Change. 

Select the start and end of the period for operation mode 

“Day” by double clicking the appropriate lines. Choose the 

Assign button and use the F4 help to select the operation mode 

Day. Follow the same procedure to assign the operation mode 

“Night”. After you have assigned the entire 24 hour period to 

your operation modes, choose Save. 

Task 3 Manual Switch of Operation Modes 

1. To observe the change in work process distribution when the 

operation mode is switched, switch to the “Night” operation mode 

manually in the Control Panel. 

a) You can perform a manual switch of the operation modes in the 

Control Panel (Tools → CCMS → Control/Monitoring → Control 

Panel, transactionRZ03). 

As a first step, select the operation mode to which you want to 

switch, by choosing Choose operation mode. Select the operation 

mode and choose Choose. 

The switch is performed in a second step, by choosing Control → 

Switch Operation Mode → All Servers. 

2. How can you observe the change of the work process distribution? 

a) Check the changed distribution of the work processes in the 

process overview (Tools → Administration → Monitor → System 

Monitoring → Process Overview, transaction SM50). 








Unit Summary 









109 


1. In which sequence are the system parameters read from the specified 

locations by the system? 


A 1. Instance profile 2. Default profile 3. Kernel 

B 1. start.ini 2. Kernel 2. Default profile 4. Instance profile 

C 1. Kernel 2. Default profile 3. Instance profile 

D 1. Kernel 2. start.ini 3. Default profile 4. Instance profile 

2. In which profile can you change the number of background work 

processes? 


A Start profile 

B Default profile 

C Background profile 

D Instance profile 

3. You can use transaction RZ10 RZ10 to check the consistency of 

individual profiles. 


4. In which sequence should you perform the listed steps when setting 

up operation modes? 


A 1. Create operation modes 2. Assign instances 3. Distribute 

work processes 4. Maintain time table 

B 1. Create operation modes 2. Maintain time table 3. 

Distribute work processes 4. Assign instances 

C 1. Create operation modes 2. Distribute work processes 3. 

Maintain time table 4. Assign instances 



110 

Answers 

1. In which sequence are the system parameters read from the specified 

locations by the system? 

Answer: C 

There is no file called start.ini involved in this context; it has been 

made up. 

2. In which profile can you change the number of background work 

processes? 

Answer: D 

The instance profile is the correct profile in this case, as settings in 

this profile only apply to the affected instance, and the number of 

work processes for an instance is to be defined here. The start profile 

contains information about the processes to be started during the 

system start. In the default profile, you maintain parameters that 

apply to all instances or for the entire SAP system. The background 

profile does not exist. 

3. You can use transaction RZ10 to check the consistency of individual 

profiles. 

Answer: RZ10 

In addition to the consistency of the individual profiles, you can use 

transactionRZ10tocheckall profiles. In this case, the system also 

checks the consistency between the profiles. 

4. In which sequence should you perform the listed steps when setting 

up operation modes? 

Answer: A 

It is especially important that you follow the correct sequence when 

first setting up the operation modes. 


Unit 4 

111 Access to Help 

The online documentation is the central information source for SAP 

users. You should discuss the different formats. You should demonstrate 

examples of navigating and searching in the SAP Library using the address 

http://help.sap.com. 

Unit Overview 

In this unit, you will learn about the online documentation and the 

SAP Service Marketplace. Both addresses are central starting points for 

obtaining information about SAP. 



• Set up access to the online documentation 

• Use the information provided bytheSAPServiceMarketplace 

Unit Contents 

Lesson: Configuring the Online Documentation............................126 

Exercise 8: Access to Help................................................139 


Unit 4: Access to Help ADM100 

Lesson: 

112 

Configuring the Online Documentation 



In this lesson, the setting up of the online documentation is demonstrated. 

In addition to the work in the system, activities must also be performed 

on the front end computer. The SAP Service Marketplace will also be 

introduced. 




• Use the information provided by the SAP Service Marketplace 

Discuss a case in which a company’s head office and two branches are 

linked by WAN connections, since they are in different locations. If the 

online help was only installed on one server in the head office, every 

request for help would cause load on the expensive leased line. The help 

must therefore also be installed locally in the branch locations. 

It is useful to open the installation guide from one of the documentation 

CDs from the training material before starting this unit, so that you can 

also show excerpts from it during the presentation. 

System demonstrations in this unit: Configuration SR13, calling help, 

location of the file sapdoccd.ini, the SAP Help Portal, and the SAP 

Service Marketplace. 


The administrator has to make the online help available for all users of 

the system. 

Access to the Documentation with the SAP Library 

The SAP Library, which is also known as the online documentation, is 

an important source of information, and contains information about 

all relevant topics in the SAP environment. Installing the online 

documentation locally or company-wide helps users to work more 

effectively with the SAP system. 


ADM100 Lesson: Configuring the Online Documentation 

The SAP Library can be called by choosing Help → SAP Library and 

provides access to the complete online documentation for the system. 

Figure 45: Access to Documentation with the SAP Library 

By choosing SAP Library in the Help menu, you can display the online 

documentation. The terms SAP Library and online documentation are 

often used synonymously. The SAP Library of an SAP system always 

contains the complete online documentation for the system. In this way, 

the SAP Library for an SAP Web Application Server, for example, currently 

offers access to more than 10,000 documents. 

Using the SAP Library, you can easily search the online documentation, 

access a glossary, and call an introduction to using SAP systems (“Getting 

Started”). 

The online documentation is provided in various languages and, if the 

calling of help has been correctly configured (as explained later in this 

lesson), is called up in the user’s logon language. 



The Supported Help Types 

Figure 46: The Supported Help Types 

The Installation Guide describes the different help types and their 

individual properties in great detail. This lesson simply presents the fact 

thatthehelptypeHtmlHelpFileisthedefaulthelptyperecommended 

by SAP, since it has the most functions of any of the help type, a suitable 

search function, and supports printing. 

HtmlHelpFile 

With this help type, the documents are stored in “Compiled HTML” 

format (*.CHM). The files are made available using a file server and 

are displayed with the HTML Help Viewer. “Compiled HTML” 

is a format developed by Microsoft for storing HTML files in 

compressed format. The storage space requirement for CHM files is 

around a tenth of the requirement for uncompressed HTML files 

and is comparable to the requirement for WinHelp files. Microsoft 

introduced the HTML Help Viewer as a successor to WinHelp. It is 

based on Microsoft Internet Explorer. This type of help can only be 

used on Microsoft Windows 32 bit front end platforms. This type of 

help provides a full text search for all documents (global search) or in 

the documents of the current help file (local search), and it is possible 

to print multiple documents concurrently. 



PlainHtmlHttp 

With this help type, the documents are stored in the standard HTML 

format. The documents are made available using a Web server and are 

displayed with a standard Web Browser. This help type can be used 

on all front end platforms and the documentation is displayed using 

a standard Web browser (Microsoft Internet Explorer or Netscape). 

This help provides a full text search in all documents (global search) 

and you can print individual help documents. 

PlainHtmlFile 

This (most simple) help type also stores the documents in standard 

HTML format. The documents are made available using a file server 

and are displayed with a standard Web browser. This help variant 

can be used on all front end platforms except Microsoft Windows 3.1x 

(16 bit), and allows you to print individual help documents. 

DynamicHelp 

DynamicHelp can be used on all front end platforms, uses the 

standard HTML format for its files, and the file access takes place 

using the Knowledge Warehouse server. The documents are 

displayed in a standard Web browser. For more information, see the 

online documentation for the Knowledge Warehouse. 

SetupWorkintheSAPSystem:SR13 

Figure 47: Setting Up the Documentation in the SAP System 

Normally, an end user accesses the online documentation based on the 

SR13 settings. However, if there is a sapdoccd.ini file stored in one 

of the following specified directories on the user’s front end, its settings 

override those from transaction SR13. If, however, no settings have been 



made in transaction SR13, even if there is a sapdoccd.ini file on the 

front end, it is not evaluation, and the message No documentation available 

is displayed. 

With the IMG activity General Settings → Setting variants for help (SAP 

Library), youdefinewhichvariant(s) of the online help are available to 

theusersoftheSAPsystem. 

Caution: Without a corresponding configuration in transaction 

SR13, it is not possible to call help successfully. This is true even 

if there is a correctly maintained local SAPDOCCD.INI file. In 

this case, the system displays the message No documentation 

available. 

As of SAP R/3 4.6C, you no longer need to maintain profile parameters 

for the online help. During an upgrade from SAP Basis 4.x to SAP Web 

Application Server 6.10 or 6.20, the values stored in the profile parameters 

eu/iwb/... for help type, storage location, and language version of the help 

files are read and copied as a settings variant by an XPRA program. Since 

these automatically created settings variants (GENERATED_BY_XPRA 

...) cannot be changed, you must create new settings variants that 

copy the specifications for the storage location of the help files from the 

automatically created entries, as long as they are still valid, and then delete 

the automatically generated settings variants. Use descriptive names when 

creating new settings variants. 



SR13 - Example: The proposed values can be used as an example in the 

training course without any problems. You should note, that different 

input fields are available, depending on the tab page selected in transaction 

SR13. Only the recommended help type HtmlHelpFile is presented in 

more detail here. Read SAP Note 333584 as part of your preparation. 

Note: SR13: An example: 

After selecting the HtmlHelpFile tab page, you could, for example, 

make the following entries: 

• Variant: 

Documentation or a different descriptive text 

• Platform: 

WN32; This setting is also appropriate for Microsoft Windows 

NT front ends, for example (See SAP Note 333584) 

• Area 

Documentation (is automatically replaced by iwbhelp) 

• Path 

For example: \\twdf9999\Doku\620\ (without language 

selection) 

• Language 

E English, selected using the F4 help (this is automatically 

replaced with EN). 

• Default 

Setting this indicator in this example means that the help type 

HtmlHelpFile is the default help in the area “Documentation” 

for WN32 front ends. 

The above example specifies that on Microsoft Windows NT-based 

front ends, the help variant “documentation” determines the help 

that is usually called with its settings. In this case, this means 

that the online documentation is called from a network drive 

\\twdf9999\Doku\620\EN. Note that the language ID was automatically 

added to the path. For front ends of other types (for example, 

non-Windows based), another help type can be called by default. For 

these other front ends, you must also set a separate settings variant as 

the “default”. 



By maintaining and providing multiple settings variants, you can make 

the online help available in various ways. A settings variant specifies 

a configuration of help type, storage location of the help files (server 

and/or path) and the language version of the help files for a particular 

front end platform. If you provide multiple settings variants for a front 

end platform, the users can choose between these variants using the menu 

Help → Settings (Extended Help tab page). 

In every settings variant you must specify the Area for which it applies, 

in addition to the front end platform. The area indicates the application 

area of the SAP Knowledge Warehouse from which the contents to be 

displayed are taken. The area IWBHELP (“documentation”) contains the 

online documentation delivered to all customers. Customers that use the 

SAP Knowledge Warehouse can also define settings variants for the area 

IWBTRAIN (“training”). 

Setup Work at the Front End: The sapdoccd.ini File 

It is very important to emphasize that WITHOUT configuration in 

transaction SR13, even if there is a sapdoccd.ini file on the front end, it 

is NOT evaluated. The default message in this case is: No documentation 

available. 

Transaction SR13 is to be set up in the exercises for this unit so that 

any sapdoccd.ini files that exist on the front ends are evaluated. If 

these do not exist, then the settings from transaction SR13 would be 

used. However, these would not point to a meaningful target, as it 

is not possible to guarantee for all training centers that SAP Web AS 

documentation is available locally. This means that in some circumstances, 

no documentation is available. This problem should then be solved with 

the local IT department. 

A default setting for the selection of online documentation must be made 

in the system for every utilized front end platform. If multiple help types 

are installed, the end user can choose between these variants using the 

menu Help → Settings (Extended Help tab page). 



Figure 48: The sapdoccd.ini File 

If it is necessary to set up special settings for the online documentation on 

certain front ends, the call of the online documentation can be controlled 

on Microsoft Windows front ends with entries in the file sapdoccd.ini 

(possible storage locations for this file are shown in the figure above). 

Hint: Up to SAP GUI 6.10 (inclusive), the possible paths for the 

sapdoccd.ini file, in addition to \WINNT, are:Program Files → 

SAPpc and Program Files → SAPpc → SAPgui 

A possible reason for using this option is, for example, that there is a WAN 

connection between the front end and the storage location defined in the 

system for the online documentation. To avoid increased network load in 

this case, documentation that is available over a local network from the 

front end should be accessed. This locally available online documentation 

can be accessed using the information in the sapdoccd.ini file. If this 

file exists with valid settings, these override the system settings for the 

relevant front end. Possible entries in the sapdoccd.ini file are shown 

in the next figure. 

Hint: The file sapdoccd.ini is only evaluated if settings 

for access to the online documentation exist in the system 

(transaction SR13). Otherwise, the system displays the message 

“No documentation available”. 



Figure 49: Contents of sapdoccd.ini 

The file sapdoccd.ini, described here in more detail, is primarily used 

on front ends that are connected to the SAP system by a WAN connection. 

In this way, it is possible to access local help files, and to avoid network 

load. The initial screen of the online documentation in .chm format is more 

than2MBinsizeduetothelargeinitialnavigationtree. 

Explain the sequence in which possible locations for the sapdoccd.ini 

file are evaluated. There could be a number of these files stored on a 

front end. For detailed information about the content and structure of 

sapdoccd.ini, see SAP Note 94849. 

Explanation of the parameters and possible values: 

• HelpType: PlainHtmlHttp, PlainHtmlFile, HtmlHelpFile, 

DynamicHelp, GetFromR3 

• Server: Name of the Web server on which the files for 

are stored 

• Path-: Path under which the help for 

the logon language is stored: should be 

replaced with a two-character language ID. 

• Path: Path under which the help that is to be displayed 

if the parameter Path- is not defined for the 

current logon language is stored. 



– The help type GetFromR3 does not represent a separate help 

type; it is used to copy the current valid settings variant of 

the SAP system. If GetFromR3 is specified as the help type 

(HelpType=GetFromR3), the settings are copied from the SAP 

system. If the server and/or path to the corresponding help 

type are also specified in the file sapdoccd.ini, these settings 

override the settings from the SAP system. 

SAP Help Portal 

Figure 50: The SAP Help Portal 

Any Internet user can easily access and search the complete SAP 

documentation at the address http://help.sap.com. We strongly 

recommend that you demonstrate the online documentation here; 

participants can access the documentation in this way even during the 

training course, even if there is no current help available in the training 

center. 

The SAP Help Portal provides Internet-based access to the available 

online documentation for SAP software solutions. The Help Portal 

can be accessed from every Web-capable front end without logon. The 

documentationprovidedcanbeaccessedveryefficientlyusingafulltext 

search. 



SAP Service Marketplace 

Figure 51: The SAP Service Marketplace 

Use at least two examples to present the services and information 

provided by the SAP Service Marketplace, such as access to the SAP Notes 

database using the alias /notes and to the installation guides with the 

alias/instguides. There is no longer a “Walldorf” dummy user available 

for this demonstration. You should use your own S user. In principle, 

you can also log on with your D/I user. However, more information may 

then be displayed than for a typical customer user. If you are using a D/I 

user, you should therefore check the demonstration first to ensure that no 

internal information is displayed; the above examples are “harmless” in 

this regard, as long as you do not call up any internal SAP Notes in the 

SAP Notes database. 

The Web site http://www.sap.com provides information about all SAP 

Solutions and about SAP as a company. This information is public and can 

be accessed by anyone. In addition to this, SAP provides various services, 

detailed information, and so on for customers and partners on the SAP 

Service Marketplace at http://service.sap.com. AccesstotheSAPService 

Marketplace (SMP) is free of charge, however it is protected by a user 

name and password logon. There is at least one person with access to the 

SMP at every customer. This person can create additional users and assign 

certain authorizations to those users. 



There are two simple options available to simplify navigation: 

• Personalization of the initial screen 

• Navigation using Quick Links, such as http://service.sap.com/smp. 

Quick Links are simply added to the “basic address” after a “/”. In 

this case: “smp”. 

Important Quick Links: 

• /user-admin User administration on the SMP (for “your” users) 

• /sscr You can obtain “SAP Software Change Registration” keys here 

• /notes The online access to SAP Notes is available using this Quick 

Link 

• /swcenter You can obtain patches, updates, and other software for 

your SAP systems here 

• /message This Quick Link allows you to create a message to SAP 

• /servicecat The service catalog displays a list of the services offered 

by SAP 

• /instguides You can find installation guides for the various SAP 

solutions here 

• /netweaver This Quick Link leads to the newest information about 

SAP NetWeaver 

• /education You can find information about the SAP training courses 

available worldwide in an online catalog here 

Additional Information 

• SAP Library 

• http://help.sap.com 

• http://service.sap.com 


– SAP Note 94849: SAPDOCCD.INI -description 

– SAP Note 95309: SAPDOCCD.LOG -description 

– SAP Note 101481: Collective note: Application help and R/3 library 

– SAP Note 302459: Setting variants for online help 

– SAP Note 333584: Frequent errors in settings of the SAP Library 




Access to the online documentation 




You can work out with the participants how the access to the online 

documentation should be structured, depending on the location of the 

front end in relation to the system location. 



123 Exercise 8: Access to Help 




• Install the online documentation 


The administrator has to make the online help available for all users of 

the system. 

Task 1 Test the Online Documentation (optional) 

It is important that the participants use the example configuration in 

the exercise for transaction SR13. In this way, they should be able to 

access current documentation during the rest of the course. However, 

this access depends on the setup of your training center. You may want 

to test the availability of the online documentation before this unit. If the 

documentation is not available, you can declare this exercise to be optional. 

The exercises for the SAP Service Marketplace should give the participants 

a feel for the functions provided there. If you do not have a SAP Service 

Marketplace user available, you can instead demonstrate registration as 

a new user. 

Unsuccessful call of the online documentation. 

1. Start the call for the online documentation. This should fail. 

Task 2 Set Up the Online Documentation 

Make settings in transaction SR13. 

1. In your system, call the cross-client maintenance of the online 

documentation access. Maintain the settings for the help type 

“HtmlHelpFile” in accordance with the example values in the training 

material (“Note: Transaction SR13: An Example”). 

Note that you cannot specify a “correct” path to the online 

documentation files. The online documentation is not accessible for 

the servers in the training environment for administrative training 

courses. Therefore, the settings in the sapdoccd.ini file on your 

front end take precedence, once you have made settings in SR13. 




Task 3 Call the Online Documentation 

Perform a successful call of the online documentation. 

1. Start the call for the online documentation. Although the settings in 

transaction SR13 do not point to available online documentation, this 

call should still be successful, because there is a local sapdoccd.ini 

file on your front end. This points to help that is available to your 

front end. If there is no SAP Web AS 6.20 online documentation 

available in the training center that you are attending, you can use 

the Internet-based help for the rest of this training course, under 


Task 4 Use the SAP Service Marketplace 

1. Call the URL for the SAP Service Marketplace: http://service.sap.com. 

2. Use your own “S user” (as an SAP customer, you have a user of this 

type) to log on to the SAP Service Marketplace. 



Solution 8: Access to Help 

Task 1 Test the Online Documentation (optional) 

It is important that the participants use the example configuration in 

the exercise for transaction SR13. In this way, they should be able to 

access current documentation during the rest of the course. However, 

this access depends on the setup of your training center. You may want 

to test the availability of the online documentation before this unit. If the 

documentation is not available, you can declare this exercise to be optional. 

The exercises for the SAP Service Marketplace should give the participants 

a feel for the functions provided there. If you do not have a SAP Service 

Marketplace user available, you can instead demonstrate registration as 

a new user. 

Unsuccessful call of the online documentation. 

1. Start the call for the online documentation. This should fail. 

a) Choose Help → SAP Library. The system displays the message 

“No documentation available”. 

Task 2 Set Up the Online Documentation 

Make settings in transaction SR13. 

1. In your system, call the cross-client maintenance of the online 

documentation access. Maintain the settings for the help type 

“HtmlHelpFile” in accordance with the example values in the training 

material (“Note: Transaction SR13: An Example”). 

Note that you cannot specify a “correct” path to the online 

documentation files. The online documentation is not accessible for 

the servers in the training environment for administrative training 

courses. Therefore, the settings in the sapdoccd.ini file on your 

front end take precedence, once you have made settings in SR13. 

a) Start transaction SR13 or follow the path listed in the course 

manual. Then enter the example settings from the training 

material (“Note: Transaction SR13: An Example”)on the 

HtmlHelpFile tab page. Choose New Entries to make the fields 

ready for input, make all of your entries, and then choose Save. 

Task 3 Call the Online Documentation 

Perform a successful call of the online documentation. 




1. Start the call for the online documentation. Although the settings in 

transaction SR13 do not point to available online documentation, this 

call should still be successful, because there is a local sapdoccd.ini 

file on your front end. This points to help that is available to your 

front end. If there is no SAP Web AS 6.20 online documentation 

available in the training center that you are attending, you can use 

the Internet-based help for the rest of this training course, under 



Task 4 Use the SAP Service Marketplace 

1. Call the URL for the SAP Service Marketplace: http://service.sap.com. 

a) Start the browser on your front end and use the specified 

address. Confirm any dialog boxes that appear. 

2. Use your own “S user” (as an SAP customer, you have a user of this 

type) to log on to the SAP Service Marketplace. 

a) Choose the Login Now button on the initial screen of the SAP 

Service Marketplace to display the user name and password 

query. 

Explore the SAP Service Marketplace. 






• Use the information provided bytheSAPServiceMarketplace 



Unit Summary 



• Use the information provided by the SAP Service Marketplace 



129 


1. The SAP Library provides you with information about how you can 

partition your hard disks. 

Determine whether this statement is true or false. 

True 

False 

2. The SAP Library also offers a glossary of important terms. 


True 

False 

3. The SAP Library is only available in the Internet at the URL 



True 

False 

4. The following technical forms of the online help, also known as the 

SAP Library, are available: 


A CompressedHTML(.comphtml) 

B PlainHtmlHttp 

C PlainHtmlFile 

D StaticHelp 

E DynamicHelp 

F SAP HelpKit 

5. The sapdoccd.ini filecanbestoredinthreedifferentplaces. 

In which sequence is the directory tree searched: A) C:\Program 

Files\SAP\FrontEnd\, B)C:\WINNT, and C) C:\Program 

Files\SAP\FrontEnd\SAPgui? 



130 

Answers 

1. The SAP Library provides you with information about how you can 

partition your hard disks. 

Answer: False 

Partitioning hard disks is not part of the SAP Library. 

2. The SAP Library also offers a glossary of important terms. 

Answer: True 

Yes, it does. 

3. The SAP Library is only available in the Internet at the URL 


Answer: False 

The SAP Library can and should also be set up locally, for example on 

afileorWebserver. 

4. The following technical forms of the online help, also known as the 

SAP Library, are available: 

Answer: B, C, E 

Compressed HTML does not exist, although Compiled HTML 

(.chm) does. Compiled HTML is the recommended format for 

32 bit Microsoft Windows front ends. The other help types are 

PlainHtmlHttp, PlainHtmlFile, and DynamicHelp. 

5. The sapdoccd.ini file can be stored in three different places. 

In which sequence is the directory tree searched: A) C:\Program 

Files\SAP\FrontEnd\, B)C:\WINNT, andC)C:\Program 

Files\SAP\FrontEnd\SAPgui? 

Answer: Thesequenceis:B-C-A. 


Unit 5 

131 Fundamentals of Working with the 

Database 

Working correctly with the database can save crucial, precious time in 

crises. Database administrators obtain the required skills to be able to 

do this in database vendor course, which should be complemented by 

a BC5## or ADM5## course from SAP. This introductory course to SAP 

system administration emphasizes the importance of working in the 

correct way with the database and provides basic theoretical knowledge 

about the functions of a database, such as how to work with the central 

transaction for database management in the SAP system, transaction DB13. 

All other knowledge must be obtained in other courses from the database 

vendor and by attending BC5## or ADM5##. That is, ADM100 does NOT 

prepare participants for a role as database administrators. Future database 

administrators can attend SAPTEC, then database vendor courses, and the 

appropriate BC5## or ADM5## course. Thiscourse,ADM100,aimsto 

provide future system administrators with an insight into working with 

the database in this unit. 

Caution: The database used for this course is SAP’s own database: 

SAP DB. For a type of “minimal survival guide” for starting and 

stopping SAP DB, see the instructor notes for the “System Start: 

Process” lesson in the unit Starting and Stopping the SAP System. 

This unit provides an extension to that survival guide, about 

configuring backup devices. 

Unit Overview 

This unit provides basic theoretical information about the architecture and 

functionality of a relational database. Building on this knowledge, basic 

database administrative activities, performed using the database planning 

calendar (transaction DB13), are introduced. 


Unit 5: Fundamentals of Working with the Database ADM100 



• Describe in principle the structure and architecture of database 

systems 

• Back up the contents of the database 

• Check whether your database backups have been successfully 

performed 

• Schedule additional periodic checks of the database 

Unit Contents 

Lesson: Architecture of Database Systems.................................149 

Lesson: Backing Up the Database Contents................................153 

Exercise 9: Back Up the Database Contents ...........................161 

Lesson: Overview: Monitoring the Database ...............................164 

Exercise 10: Overview: Monitor the Database .........................167 


ADM100 Lesson: Architecture of Database Systems 

Lesson: 

132 

Architecture of Database Systems 



This lesson provides basic theoretical information about the architecture 

and functionality of a relational database. 




systems 

You can use this figure to explain in principle the work of a database 

system. All changes that are requested by the SAP system are performed 

by the work processes using assigned database processes. Read accesses 

are always made using the DB buffer. If this does not contain the requested 

data, this data is read from the data tables and stored in the buffer. Access 

to internal DB structure data may be required to find the data in the data 

tables. Changing accesses are always recorded in the database log files, 

usually using the intermediate layer of a “log buffer”. These logs are 

essential to ensure the consistency of the database if a reset is necessary. 


SAP systems store the application data in a relational database. The 

administrator regularly backs up this data. 

Fundamentals of Database Administration 

A database management system (DBMS) includes database processes, a 

buffer in the main memory, data files that contain the data, and log files, in 

which changes to the data are logged. 

At the start of an SAP system, all work processes are linked to a database 

process. Database queries are passed by SAP work processes to their 

dedicated database processes, which perform the query on the database. 

The data is stored in the data files: Access to the data always takes place 

using the buffer in main memory. 

The special database processes are responsible for the exchange of data 

between the buffer and the data files. During this exchange, the data is 

always read and written in complete pages (which usually contain several 

data records). 



Figure 52: Database: Concepts 

If changes are made to the data, these are logged in the log file; that is, the 

log file contains the status changes of the database. Only the changes, and 

not the complete pages, are logged in the log buffer. The entries are written 

from the log buffer to the log file, of which there can be one or more than 

one, depending on the database. For every database, there is a mechanism 

that backs up the log information from the log file to other files or directly 

to a backup medium. This ensures that the log file does not become too 

large. We recommend that you mirror the log file. Some databases provide 

special software mirrors to allow you to do this. 

Caution: This mechanism cannot be deactivated, as otherwise the 

status changes could be lost. This would mean that there was a 

threat of data loss if a hard disk crash occurred. 

A database always also includes structure data that contains essential 

information for the database, such as the number of data files, and so on. 


ADM100 Lesson: Architecture of Database Systems 


Discuss with the participants the process of a SELECT and of an UPDATE 

on the database. 




Which steps run in the SAP system between a request being issued 

(SELECT) by the user at the GUI and the return of the result? 

Which additional steps run in the database in the case of an UPDATE, to 

ensure the consistency of the data? 






systems 


This introductory course to SAP system administration emphasizes the 

importance of working in the correct way with the database and provides 

basic theoretical knowledge about the functions of a database, such as 

how to work with the central transaction for database management in the 

SAP system, transaction DB13. For more detailed information, attend 

database-specific courses run by your database vendor, and/or attend SAP 

course BC5## or ADM5##. 


ADM100 Lesson: Backing Up the Database Contents 

Lesson: 

135 

Backing Up the Database Contents 



This lesson will deal with basic concepts for backing up the database. 

These include regular backups of data and log information. These backups 

are performed with the database planning calendar (transaction DB13). 





performed 

In particular, you should emphasize in this lesson that a successful 

database backup always includes a backup of the log information. If an 

error occurs, it is only with the log information that the database can be 

restored without data loss. 


To protect the SAP system against data loss if an error occurs, the 

administrator regularly performs backups. 

Backup Concept 

A backup concept for the database always includes the regular backup of 

the data files, the structure data, and also the log information. 

The backup of the data files and the log information is performed in 

different steps. All data files and the structure data are backed up in one 

step. In another step, the ongoing log information (this may include the 

structure data) is backed up separately. 



Figure 53: Back Up of the Data and Log Information 

You can schedule both of these steps in the SAP system (except for AS400) 

as regular actions in the database planning calendar (transaction DB13). 

Scenarios for Recovering a Database 

If it is necessary to perform a database reset, the time for which you are 

able to recreate consistency depends not only on the availability of the 

backed up data files, but even more on the availability of the backed up 

log information. If a data backup is lost, a restore can be based on the last 

existing data backup, and the data can be recovered to almost any later 

time, if the log information is available without any gaps. 

Resetting the database (with data loss): 

Ifadiskcrashoccursatapointbetweent1andt2,alldatafromthedata 

backup t1 is imported. If no further action is taken, all data changes that 

were made after t1 are lost. 



Figure 54: Database Recovery 1/2 

Recovering the database (without data loss): 

All data from data backup t1 is imported. Some databases allow you to 

import only the data files that are missing. In this case, the system follows 

all log information written since t1 (22, 23, ...). As a final step, the log file is 

followed. This means that all data is now once again in the same status as 

at the point when the disk crash occurred.Onlyifallloginformationsince 

the data backup is available, with no gaps, will there be no data loss. 

Figure 55: Database Recovery 2/2 



Storingthedataandloginfobackups: 

The backed-up log information is deleted at operating system level so 

that no disk space problems occur. If a disk crash occurs at time t5 and a 

backup medium for the backup t3 is defective, an earlier data backup (in 

this case, t1) must be used. To recover the database without data loss, it is 

absolutely necessary to have all log info backups (in this case: t2 and t4) 

since the data backup t1 and the log information as of 28. It is therefore 

necessary to keep older data and log info backups. 

Other remarks: 

Some databases also require log information to be able to reset the 

database. You should therefore ensure that you perform data and log 

backups regularly. 

Backup Cycle 

There are various variants available for complete daily backup of the 

data files, depending on the database. At least one online backup 

should be made every day, with a subsequent complete backup of the 

log information. The backup media used can be overwritten again after 

28 days. This is a recommendation. Backups may be retained for much 

longer periods in a company. 

We recommend that the duration of a backup cycle is 28 days. This means 

that the backup media for the data and log info backups are overwritten 

after 28 days, at the earliest. 

Figure 56: Recommended Backup Cycle 



We strongly recommend that you perform complete data backups every 

day. 

Some databases offer the option of performing differential or incremental 

data backups that do not backup the complete data of the database (these 

data backups are described in the following as partial data backups). If 

you use a partial data backup as your daily backup, you must perform a 

complete data backup at least once a week. There must be at least four 

complete data backups contained in the backup cycle. 

The log information should be backed up at least once a day. We 

recommend that you always have two different backup media containing 

thesameinformation. 

Perform a data and log info backup with verification of the backup media 

at least once in the backup cycle. 

Scheduling and Monitoring Backups 

In this section, you should demonstrate the described actions using 

transactions DB13 and DB12. You can also show the relevant section of 

theonlinedocumentation.Ifyouarevery familiar with the principles of 

DBMGUI operation, you can also “risk” a view at operating system level. 

In the SAP system, you can schedule and monitor regular database 

backups with transaction DB13. 

Select the data backup procedure for each week day (recommendation: 

the database-specific procedure for complete data backup) and enter the 

repetitionperiod(suchas1).Choosethestarttimeorimmediatestart. 

If a manual medium swap is required, if you are, for example, using a local 

tape station, check which medium is required for the next backup every 

daybychoosingtheVols needed button, and insert this medium before the 

start of the backup. 

Enter the log info backup for every week day in the same way as the data 

backup. 



Figure 57: Scheduling and Monitoring DB Backups 

You can set the display of the planning calendar using the menu path 

Calendar → Calendar Display. 

Check every day whether your backups have been successfully completed. 

In the planning calendar, a successful backup is displayed with green or 

yellow (with warnings) labeling. Red labeling indicates an erroneous (and 

therefore unusable) backup. You can display additional information with 

transaction DB12. 

You can use the central planning calendar (transaction DB13C) to control 

and monitor backups for your entire system landscape. The schedules are 

transferred to the remote systems using an RFC connection. 

Familiarize yourself with transaction DB13 in the training environment 

before presenting this lesson. Explain the typical scheduling tasks for 

production operation, as described here: This is available in the online 

documentation, for example, at http://help.sap.com: Computing Center 

Management System → Database Administration in CCMS → SAPDB-DBA 

in the CCMS → SAP DB (OLTP) - Monitoring and Administration → DBA 

Planning Calendar (SAP DB) → Scheduling Concept. On a completely new 

system, you should certainly perform the following actions: 

1. UseDBMCLItosettheDBADTLflagto1,asdescribedinSAPNote 

431508 

2. Use the DBMGUI to define backup media for data and log backup 

(and possibly also for incremental backup) 



3. Perform a data backup with checkpoint immediately, so that you 

have an unchanged status as a backup. Then follow the instructions 

in the documentation. 

Hint: The database is set to a logging mode that overwrites the 

database log files cyclically. In this mode, it is, of course, not 

possible to successfully back up the database log information. This 

mode is permissible in a system in which you can “play about”, but 

should not be used in any system (DEV, QAS, PRD) in which the 

content “means something” to the system owner. 

You can use DBMGUI or, if the system has the appropriate Support 

Package status, transaction DB13 to check the configuration of the backup 

devices. 

In transaction DB13, you do this by choosing the Backup Media button. You 

can check the configuration and also add new media here. 

When using DBMGUI, follow the procedure below: 

1. Start the DBMGUI using the Terminal Server Client (“Database 

Manager” icon) 

2. Register your database (choose the Register icon in the top left of the 

screen); for more information in ADM100, see the description in 

the instructor note for starting and stopping (lesson: System Start: 

Process). 

3. In the upper right subwindow, select your database with the mouse. 

4. Choose Configuration → Backup Media. The system lists the storage 

locations for data backups here. Toseemoredetailedinformation 

(“Overwrite”, and so on), double click the backup medium. 





141 Exercise 9: Back Up the Database 

Contents 




• Perform a number of basic activities in the database backup and 

database maintenance environment. 


To protect the SAP system against data loss if an error occurs, the 

administrator regularly performs backups. 

Task Back Up the Contents of the Database 

Transaction DB13 is available with appropriate functions for every 

database supported by SAP. For the SAP DB database, SAP Note 431508 

was taken into account in the preparation of this training course. 

Caution: The runtime estimates in the exercises apply only for the 

training systems used here. In production systems, the runtimes 

may be much higher. 

Performabackupofthedatafilesandalogbackup. 

1. Display an overview of the utilized backup media. If you have 

performed a successful backup, what must you then consider before 

you can start the next backup (Hint: “Overwritable”). 

2. Schedule a Complete data backup with checkpoint in transaction DB13. 

Use the device FORDATA as the backup device. If the backup started 

successfully, the label in transaction for the backup run DB13 is yellow 

(process is running). The backup takes around 50 minutes. 

3. Schedule a Log Backup in transaction DB13. Use the device FORLOG 

as the backup device. The backup terminates immediately. Attempt 

todeterminethecauseofthiserrorusingthelogs. 



Solution 9: Back Up the Database 

Contents 

Task Back Up the Contents of the Database 

Transaction DB13 is available with appropriate functions for every 

database supported by SAP. For the SAP DB database, SAP Note 431508 

was taken into account in the preparation of this training course. 

Caution: The runtime estimates in the exercises apply only for the 

training systems used here. In production systems, the runtimes 

may be much higher. 

Perform a backup of the data files and a log backup. 

1. Display an overview of the utilized backup media. If you have 

performed a successful backup, what must you then consider before 

you can start the next backup (Hint: “Overwritable”). 

a) In transaction DB13 (menu path Tools → CCMS → DB 

Administration → Planning Calendar → Local), choose the Backup 

Media button to obtain an overview of the available backup 

media. As the name of the backup file is a fixed assignment, 

you can only start the next backup once the existing backup 

file has been renamed or moved to a different location, due to 

the setting Overwritable = NO. 

2. Schedule a Complete data backup with checkpoint in transaction DB13. 

Use the device FORDATA as the backup device. If the backup started 

successfully, the label in transaction for the backup run DB13 is yellow 

(process is running). The backup takes around 50 minutes. 

a) When you return from your break, the backup should be 

successfully completed, and displayed as green in DB13. If 

the label has not changed to green, check the time of the last 

successful backup using transaction DB12. If the backup that you 

have just performed is shown here, there is a display problem 

in DB13. 

3. Schedule a Log Backup in transaction DB13. Use the device FORLOG 

as the backup device. The backup terminates immediately. Attempt 

to determine the cause of this error using the logs. 

a) The job or action log displays that the database is in a log mode 

that is invalid for this backup type. 







performed 



Lesson: 

144 

Overview: Monitoring the Database 



There may be a large number of periodic checks that need to be performed 

in addition to making backups, depending on the database that you are 

using. 




It may also be necessary to perform other tasks regularly, such as checking 

thedatagrowthwithtransactionDB02,monitoringDB13actionswith 

DB12, and so on. These actions are required with different frequencies 

depending on the database in use. 


To ensure good database performance, and therefore good SAP system 

performance, the administrator performs additional checks of the 

database, which can be regularly scheduled. 

Regular Monitoring of the Database 

In addition to the daily monitoring of the database backups, there are 

a number of other checks that may have to be performed regularly, 

depending on the database. Some of these can be scheduled using the DB 

planning calendar (transaction DB13). 


ADM100 Lesson: Overview: Monitoring the Database 

Figure 58: Database Monitoring 

These checks can, for example, be: 

• Growthofthedatabase(suchasfreespace) 

• Generation of statistical data to ensure good performance when 

accessing data records 

• Check for general database problems or errors 

For more information about these checks, contact your database vendor, 

see the technical literature and documentation, contact an SAP consultant, 

or attend one of our administration courses for the database that you are 

using. 





147 Exercise 10: Overview: Monitor the 

Database 






To ensure good database performance, and therefore good SAP system 

performance, the administrator performs additional checks of the 

database, which can be regularly scheduled. 

Task Update the Statistical Data 

Schedule the generation of current statistical data in transaction DB13. 

1. Check the existing Optimizer statistics 

2. Refresh the existing statistical data 



Solution 10: Overview: Monitor the 

Database 

Task Update the Statistical Data 

Schedule the generation of current statistical data in transaction DB13. 

1. Check the existing Optimizer statistics 

a) Start the Check optimizer statistics action with “Immediate start” 

using transaction DB13. Check its success. Ensure that there are 

no other active DB13 actions. You can display today’s DB13 

actions, for example, by double clicking the “Day line” in the 

scheduling calendar. Estimated runtime: 10 minutes 

2. Refresh the existing statistical data 

a) You can refresh the existing statistical data by choosing Refresh 

optimizer/space statistics. Thisdataisarequirementforan 

efficiently running SAP system. Estimated runtime: 20 seconds 

(this is not a large task in this training system). 








Unit Summary 



systems 



performed 




151 


1. Changes to the data are logged by the database in the log files log files. 

These files also contain the changes in status of the database database. 


2. To minimize the risk of data loss, we strongly recommend a 

daily daily complete data backup. If you use a partial data backup 

as your daily backup, you must perform a complete data backup at 

least once a week week. 




152 

Answers 

1. Changes to the data are logged by the database in the log files. These 

files also contain the changes in status of the database. 

Answer: log files, database 

The log mechanism is essential and must not be deactivated. 

2. To minimize the risk of data loss, we strongly recommend a daily 

complete data backup. If you use a partial data backup as your daily 

backup, you must perform a complete data backup at least once a 

week. 

Answer: daily, week 

In addition to a complete data backup, you should, of course, also 

back up the log information at least once a day. 


Unit 6 

153 Archiving 

In this unit, the participants will obtain an initial insight into the basics of 

SAP data archiving, to make them consider this topic, and in particular 

to define the term data archiving with regard to seemingly related terms, 

such as reorganization. The first lesson of this unit is therefore especially 

important. 

The two following lessons do not focus on discussing technical details, but 

rather on allowing the participants to perform a simple archiving run and 

accessing the archived data “live”. The required Customizing is also really 

a“meanstoanend”here. 

Direct customers who want to learn more about data archiving to SAP 

course BIT660 (“Data Archiving”). 

An employee leave request is archived during this unit. To create the 

process, the workflow was activated in the (master) system. However, it 

has been deactivated for performance reasons in the training systems, 

and can therefore not be re-enacted here. The workflow to be archived 

was created as follows: On January 24 2003, the employee WF-CLERK 

(password welcome) started an employee absence workflow in client 100 

(using the transaction SWXF), which the manager WF-HEAD (client 100, 

password welcome) then rejected in the Business Workplace (transaction 

SBWP). WF-CLERK then revised the request in SBWP, and the request was 

thenfinallyapprovedbyWF-HEAD. WF-CLERK was informed of this by 

express mail. You can display the entire process (and therefore the data 

to be archived) in the training system, by logging on as WF-CLERK and 

setting the display period in transaction SBWP for the right of the screen 

so that it includes January 24 2003, by choosing Work Center WF-CLERK 

→ Outbox → Started Workflows. You can then see the exact course of the 

process either in the lower right area of the Business Workplace or no the 

next screen by double clicking the started workflow and selecting Log. 


Unit 6: Archiving ADM100 

Unit Overview 

You can use data archiving in the context of SAP NetWeaver to securely 

store application data that is no longer required for day-today activities 

outside the database. This stored data is stored in archive files, which 

you can access later. The result is a “slim” database, which can be more 

efficiently and cost-effectively administered in the long-term. 

This unit will provide you with an initial insight into the basics of SAP 

data archiving. You will perform a simple data archiving task and then 

usetheSAPsystemtoaccessthearchiveddata. 



• Define the term data archiving 

• Explain the need for data archiving 

• Outline the technical process of data archiving 

• List individual steps of data archiving 

• Perform basic functions to customize SAP data archiving 

• List different options for accessing archived data 

• Evaluate options of the SAP Archive Information System 

Unit Contents 

Lesson: Fundamentals of SAP Data Archiving .............................175 

Lesson: Performing Data Archiving...........................................185 

Exercise 11: Perform Data Archiving ....................................193 

Lesson: Accessing Archived Data............................................202 

Exercise 12: Access Archived Data......................................209 


ADM100 Lesson: Fundamentals of SAP Data Archiving 

Lesson: 

154 

Fundamentals of SAP Data Archiving 



Data archiving is used to remove large quantities of data from the database 

that is no longer required in the system, but which is to be retained in an 

analyzable format. This lesson will define the term data archiving, and 

you will learn about reasons for implementing an archiving project. The 

process of data archiving will also be outlined. 






This lesson should explain the fundamentals of data archiving to the 

participants. In particular, administrators should be able to explain the 

difference between data archiving and seemingly related terms such 

as reorganization or backup/restore. Describing the process of a data 

archiving project in detail, on the other hand, is not part of this lesson. 


The management team of your company have decided to implement SAP 

data archiving. As a member of the system administration team, you want 

to learn about the fundamentals of data archiving. 

Introduction 

With current database systems, a large data volume can often lead to 

performance bottlenecks, which cause bad performance on the user side, 

and increased resource costs on the administration side. Data that is 

no longer required in the database for applications should therefore be 

removed from the database. However, it is often not possible simply to 

delete the data, as read access to the data is still frequently required. The 

data must therefore be stored outside the database on external storage 

media so that it can later be read again. 



Definition of Data Archiving 

Data archiving means the consistent removal of data objects from database 

tables of the SAP system database, where all table entries that characterize 

adataobjectarewrittentoanarchivefileoutsidethedatabase.Business 

consistency is ensured by SAP archiving programs that store all relevant 

table entries together on the basis of archiving objects. 

You should emphasize, especially if there are database administrators 

among the participants, that the term archive file does not mean the 

database backup files (such as Oracle Offline Redo Log files, which are 

often called archive files). 

The contents of business objects of the SAP system are distributed across 

multiple tables in the database. Archiving objects bundle logically 

connected tables of business objects. This ensures, in the context of data 

archiving, that all information for a business object is stored outside the 

database and therefore deleted. 

The following figure clarifies the connection between database tables, 

business objects, and archiving objects. The application data removed 

from the SAP system database is compressed and stored in a different 

location (such as a file system). 

Hint: From a technical point of view, archived data could be loaded 

back into the database. However, since it is historical data that 

has not been affected by changes to the database and its content 

since it was removed, there is a danger that reloading the data 

could cause inconsistencies. Data must therefore only be reloaded 

into production systems in exceptional circumstances. For more 

information, see SAP Note 53064. 

The data is archived in online mode; that is, you do not need to shutdown 

the system during the archiving. 



Figure 59: What is Data Archiving? 

This figure clarifies the fact that the data that belongs to particular business 

objects can be stored in different database tables. This example shows 

selected tables for sales documents: the header data is in table VBAK, the 

administration data in VBUK, and the business partner data in VBPA. You 

can display the connection between an archiving object and a database 

table in transaction DB15. 

The archiving object in the figure, SD_VBAK, for sales documents, does 

not exist in a pure SAP Web AS system. It is, however, available in an 

SAP R/3 Enterprise system. 

Since the term “archiving” is used in an undifferentiated way in the IT 

world, this section examines a number of other important terms in the data 

archiving environment in order to create a distinction between these terms 

and data archiving. In particular, data archiving is not 

• Reorganization 

• Backup / Restore 

• Document storage (usually using SAP ArchiveLink) 

• Deletion of test data 

The term reorganization has a double meaning within the SAP world 

(historically, due to SAP R/2). On one hand, this can mean the physical 

deletion of application data from the database, on the other - and this is 

the actual meaning - this term means the reorganization of the database. 



During the reorganization of the database, the data is unloaded from the 

database and then reloaded, to optimize the physical data distribution 

on the hard disk. 

A backup is the backing up of the database contents in case of system 

breakdowns. The aim is to restore the database status to as close to 

the status that was current before the breakdown. Backups are usually 

performed at fixed time intervals and follow a fixed procedure. The 

process of reloading the backed up data is called a restore. 

Database backups are independent of the data archiving and should be 

scheduled and performed at regular intervals. 

Document storage means the general electronic storage and management 

of documents on storage systems outside the SAP system. The documents 

are transferred to a document storage system. Only a pointer that links to 

the stored documents and allows access is administered in the SAP system. 

SAP ArchiveLink is a data interface integrated into the SAP Web 

Application Server that controls communication with storage systems. 

Document storage is often also called optical archiving by customers. 

However, this term is misleading; it would be more precise to refer to 

“electronic data storage”. 

Only data from completed business processes can be archived. Test data 

rarely achieves this status. 

Archiving has nothing to do with the DART tool. Here is some background 

information about DART in case participants ask questions about it: 

Due to legal requirements, certain data must be archived in such a way 

that they can be evaluated again at any subsequent point in time. In 

some countries, the financial authorities also require the data to be stored 

transparently, so that the authorities can evaluate the data with their own 

data processing resources. Some data can only be interpreted in connection 

with information about the organizational structure of the company, such 

as the distribution in sales districts. 



The “DART” tool (Data Retention Tool) was developed specifically for 

the data retention and evaluation requirements of the US tax authorities 

(and adjusted for the German tax convention). With this tool, the data is 

stored sequentially and uncompressed in ASCII format, and can also be 

evaluated with external tools. 

Hint: Individual data objects are always stored during archiving. 

However, it is not always possible to interpret this information 

without its original context. DART, on the other hand, extracts all 

context data relevant for tax purposes for each document. 

The context of a document (that is, master data and Customizing) 

can also change if the document still exists in the database, that is, 

it is not archived. It is therefore important to take contemporary 

DART extracts, and also to use data archiving if required. 

Reasons for Data Archiving 

The larger a database is, the higher the cost for database administration 

with regard to recovery or backup. Securing the SAP system services 

requires ever more resources. Upgrades of the system or database also 

become disproportionately more expensive with an increasing database 

size. 

For administrators, it could also be helpful to point out that the recovery 

time also increases with the size of the database. 

For end users, an increasing database size means a higher system load 

for individual database queries; that is, increasing response times for 

reporting and access to individual database records. 

Hint: Full table scans, in particular, are accelerated by data 

archiving, but access using indexes can also be appreciably 

accelerated by data archiving. The main effect in this case is that a 

reduction of the disk requirement for an index improves the quality 

of the database’s data buffer. This effect is especially pronounced 

for indexes that are likely to be accessed using any of their fields. 

This includes all indexes that are not created in a chronologically 

sorted format (such as using the document number). 

The reasons for data archiving are summarized in the list below: 



• Improve response times or ensure good response times 

• Reduce costs for database administration 

• Reduce system downtime for software upgrades, recoveries, and 

(offline) data backups 

• Legal requirements and business requirements must be taken into 

account here, such as: 

– Country-specific retention rules 

– Data must be available to auditors 

– Potential reusability of data 

Data must be archived in a way that means it can be called at any time for 

queries. These queries could, for example, be from tax authorities. There 

are legal data retention requirements in each country. Also, only data from 

completed business processes can be archived. 

With data archiving, data is archived independent of the hardware and 

software release statuses (metadata is stored). In this way, it is still possible 

to call archived data without any problems even after a system upgrade. 

Cooperation Between the System Administration and 

User Departments 

You should begin planning the archiving of application data during the 

implementation of SAP software. The volumeoftransactionandmaster 

data can increase very quickly when live operation is first started. 

The system administration’s aim is to keep the database as small as 

possible; that is, to delete as many data objects as possible to reduce the 

database load. The aim of user departments, on the other hand, is to be 

able to access as many documents as possible online for queries, lists, and 

reporting. 

The process of data archiving is about finding a compromise between these 

two positions that satisfies both sides. The long-term aim must certainly 

be to maintain as constant as possible a volume of data in the database and 

to archive data proactively instead of reactively. 

At this point, you can briefly describe the different tasks of the system 

administration on one hand and the user department on the other in an 

archiving project. The SAP system administration is usually responsible 

for database analysis, SAP ArchiveLink Customizing, setting up and 

connecting archives, general archive Customizing, and configuring the 

SAP system (background server, and so on). The IT department is, in 

particular, also responsible for ensuring that the archived data is safely 

retained for the required period of time. The user department, on the other 



hand, must, among other things, clarify which data can be archived, when 

this archiving should be performed (for example, not before a year end) 

and whether (possibly also how) the archived data is to be accessed. 

Schematic Process of a Data Archiving 

The actual data archiving is a process in three steps: 

1. Creating the archive file(s): In the first step, the write program creates 

one (or more) archive file(s). The data to be archived is then read from 

the database and written to the archive file(s). 

2. Storing the archive file(s): After the write program has completed the 

creation of the archive files, these can be stored. 

Up to SAP Basis 4.6B (inclusive), it is only possible to use the delete 

program to delete data from the database that it was first possible to 

read from the archive file in the File system. As of SAP Basis 4.6C, it 

is also possible to read the data to be deleted from the archive file of 

the storage system; that is, to store the data before the deletion. 

3. Deletingthedata-thedeleteprogramfirstreadsthedatainthe 

archive file and then deletes the corresponding records from the 

database. 

It is possible to run a preprocessing program before the actual archiving. 

Preprocessing programs can, for example, set deletion indicators (such as 

in PPPM/CO), or can also provide information about whether data can 

be archived (SD). 



Figure 60: The Archiving Process 

You must also consider the fact that it is usually not sufficient to write 

the data to be archived to archive files and to delete it from the database. 

The archive files must be stored securely and be managed to ensure that 

they are accessible later if required. 

There are a number of options for the storage of archive files (step 2 above): 

• Hierarchical Storage Management (HSM) systems: If an HSM system 

is used, it is sufficient to maintain the appropriate file path in 

Customizing (transaction FILE). It is left to the HSM system to store 

the files on an appropriate storage medium, depending on frequency 

of access and disk space utilization. 

• Optical archiving: This term refers to electronic storage and 

management of documents on storage systems outside the SAP 

system landscape. These documents are usually physically stored on 

optical media, such as CDs. This is where the name originates. 

• Manual storage: After the deletion program has processed the 

relevant archive file, it can be manually placed on tape. 

We do not recommend manually saving archive files to tape, since there is 

no standardized interface for this in the SAP system. 




Discuss the advantages of data archiving with the participants. 




Who has already taken part in a data archiving project? 

If someone has already taken part in a project of this type: What did 

you learn from the project, or what effects did the archiving have on the 

performance of database queries? 


(Optional): The participants should consider when it is necessary to 

archive data. 




When should data be archived? 

Hint: Application data should only be archived if it will not change 

again, and it will probably only rarely be necessary to display 

it. This also means that documentation requirements should be 

satisfied before application data is archived by creating all of the 

documents required for subsequent audits. 









For more information about data archiving, see: 

• The online documentation, in the Introduction to Data Archiving 

section (CA-ARC) 

• SAP course BIT660 (Data Archiving) 

• On the SAP Service Marketplace under the Quick Links 

/data-archiving and /archivelink 


ADM100 Lesson: Performing Data Archiving 

Lesson: 

160 

Performing Data Archiving 



In this lesson, the main features of the Customizing required to perform a 

data archiving are presented. A simple data archiving is then performed, in 

which the data to be archived is written to a file at operating system level. 





In this lesson, the participants are to make the basic Customizing settings 

and then perform an archiving run. The instructor notes in this lesson refer 

to the fact that there are already work items for archiving in the system. 

There are corresponding work items for an employee leave request in the 

SAP system in the system setup for the ADM100 course. These can be 

archived in the course. If there are no work items to be archived in your 

course setup, you can also use other archiving objects. 


The management team of your company have decided to implement SAP 

data archiving. As a member of the system administration team, you want 

to learn about the process of data archiving. 

The Archiving Object 

A central element of data archiving is the archiving object. It defines 

the smallest unit that can be completely archived and deleted from the 

database, and describes which database objects must be accessed, and 

how, to completely archive a business object. 

An archiving object essentially consists of three components: 

• Data declaration component 

• Customizing settings 

• Programs 

All relevant database objects that characterize an application object are 

described in the data declaration component. 



The archiving object-specific parameters for an archiving run are set using 

the Customizing settings. 

The programs of an archiving object include, among other things: 

• A write program that writes the data objects sequentially to the 

archive files 

• A delete program that deletes all data objects from the database that 

were first successfully read in the archive file 

• A display program that allows the reading of archived data objects 

Optional programs are a preprocessing program (that, for example, 

prepares data objects for the archiving run), a postprocessing program (for 

postprocessing after an archiving run, such as updating statistical data), or 

a reload program that reloads the archived data back into the database. 

Hint: TransactionDB15(menupathTools → CCMS → DB 

Administration → Data Archiving) provides information about which 

database tables are associated with which archiving object (and 

which archiving objects are associated with which database table). 

Archiving objects can be defined using transaction AOBJ . This transaction 

can also be used to make Customizing settings that override the options 

presented in the next section. 

Customizing Settings 

During Archiving Customizing, you set parameters that affect the 

execution of data archiving. Customizing is structured into the following 

areas (examples are given for each): 

• General Customizing (Basis Customizing) 

– Defining logical path and file names 

• Cross-Archiving Object Customizing 

– Define the server group for background processing 

• Archiving Object-Specific Customizing 

– Size of an archive file 

– Settings for the delete program 



You can call the Customizing settings by choosing the Customizing button 

on the initial screen of transaction SARA (Archive Administration, menu 

path Tools → Administration → Administration → Data Archiving). 

In the general Customizing (Basis Customizing, switch to the transaction 

FILE), you first define - if it does not already exist - a logical file path as 

the global path for data archiving and assign a physical path to this logical 

path. The logical path acts only as a placeholder for the physical path 

created at runtime. 

Hint: The physical path assigned to the logical path can be 

maintained separately for each operating system utilized (such as 

\ for Microsoft Windows NT). The 

SAP system automatically identifies which path is actually used 

at runtime. 

You also maintain a logical file name here for naming the archive file for 

the archiving of application data and assign it a physical file name that is 

generated at runtime and used as the file name. 

In the Basis Customizing (reached using transaction SARA, Customizing 

pushbutton, Cross-Client File Names/Paths option), show in the Logical 

File Path Definition area that the logical path ARCHIVE_GLOBAL_PATH 

exists (or create it if it does not exist, and give it a descriptive short 

description such as “Global path for data archiving”). In the Assignment 

of Physical Paths to Logical Path subdirectory, show that, for the operating 

system Windows NT this logical path is assigned the physical path 

\ (double click the operating system 

name to display this information), or maintain the corresponding entry for 

the operating system on which your SAP system is running. The file name 

isgeneratedatruntimebasedonotherCustomizing settings (see below). 

In the Logical File Name Definition, Cross-Client folder, double click 

the logical file name ARCHIVE_DATA_FILE to show 

that the logical file nameARCHIVE_DATA_FILE is assigned the physical file 

name____.ARCHIVE 

, which is replaced at runtime (or maintain this entry correspondingly). In 

the case of work items, is replaced by the application 

component BC, by a sequence letter (or a digit), and 

by the object to be archived WORKITEM. The F1 help for the 

Physical file fieldisveryinformativeandshouldbeshowntothe 

participants. You should also explain that the logical file is also assigned a 

logical path, as illustrated by the following figure. Finally, move back 

to the initial Customizing screen. 



In Cross-Archiving Object Customizing, youcanspecify,among 

other things, whether the data archiving monitor in CCMS monitoring 

(transaction RZ20) should be active, or which server group is selected for 

background processing (this setting is new as of SAP Web Application 

Server 6.10). 

In Archiving Object-Specific Customizing, you maintain a logical file 

name for the specific archiving object and settings for the delete program. 

You can set whether the delete program is to be automatically executed 

after the creation of an archive file. In this area, you also create a variant 

for the test run and a variant for the production run, and specify the 

maximum size of an archive file, among other things. 

In archiving object-specific Customizing for the archiving object 

WORKITEM, define a variant for the test mode, and one for production 

mode, and maintain the process control appropriately. Then maintain the 

attributes of the variants and save the variants. Ensure that the delete job 

is not scheduled. Point out that the archiving object WORKITEM is assigned 

the logical file name ARCHIVE_DATA_FILE (see following figure). Finally, 

move back to the initial Customizing screen and choose Enter there. 

The following figure illustrates the relationship between the name of the 

archiving object and the stored logical and physical file and path name. 

Figure 61: Basis Customizing (transaction FILE) and Application-Specific 

Customizing (transaction SARA) 



The Archiving Run 

The actual archiving run is scheduled and processed as a background job. 

It selects the data objects from the database. When doing this, the integrity 

conditions that characterize a data object are taken into account. The 

system then checks whether each data object can be archived. If it can be 

archived, the data object is written to the archive file. If the Customizing 

settings specify that the delete program is to run automatically, the 

associated deletion run is automatically started, when a file is closed. 

Hint: If the delete program is scheduled in parallel to the write 

program, there should be at least two background work processes 

configured on the SAP system. 

The delete run must be separately scheduled, if the delete program is 

not automatically run by the settings in the archiving object-specific 

Customizing. When doing this, you must also select the archive files, from 

which the data objects are to be read in the current delete run, and then 

deleted from the database. 

An archiving run is scheduled using transaction SARA by choosing the 

Write button. It is divided into four steps: 

• Creating an archiving variant 

• Specifying the execution user 

• Specifying the start time 

• Defining the spool parameters 

The data that is to be archived for the selected archiving object is specified 

in archiving variants. In principle, archiving variants can only be reused 

if the associated jobs are deleted. The definition of the variant must also 

specify whether it is a test run or a production run. 

The user under which the archiving program is started requires at least 

an appropriate authorization for the authorization object S_ARCHIVE. 

S_ARCHIVE is the main authorization object used for data archiving. By 

selecting the corresponding field entries for this authorization object, you 

can restrict the archiving objects to be used. The user also requires the 

relevant authorizations for the application transaction for which data is 

to be archived. As data archiving runs in the background, the user also 

requires authorizations for background processing (authorization object 

S_BTCH_JOB). 

The start times to be specified for archiving jobs are the same as those 

for standard job scheduling. 



Since job logs can become large, it is advisable to set under Spool 

Parameters that the log is not immediately output on the output device. 

The selection options are the same as the standard background printing 

parameters. 

Now demonstrate briefly how an archiving run is scheduled. To do this, 

select, for example, the object name WORKITEM on the initial screen of 

transaction SARA and then choose Write. Create a variant by entering a 

descriptivenameintheVariant field and choose Maintain. IntheProcess 

Control area, choose Archive and Delete. Finally, maintain attributes. Close 

the variant and choose Back. Choose Immediate for the start time. Choose 

the Spool Params. button and then Properties → General Attributes → Time 

of printing, andthenselectSend to SAP Spooler Only for Now. Then choose 

Continue twice. Finally, choose Execute. This schedules your archiving 

write run. 

Monitoring an Archiving Run 

There are various system administration tools available to monitor 

archiving runs: 

• Background processing tools 

– Job logs 

– Spool lists (if created) 

• System monitoring tools 

– Data Archiving Monitor in the CCMS monitor sets 

A log is created during an archiving run. If the application creates a 

specific log, this is used, otherwise the standard log is used. The standard 

logs contains the number of archived data objects, the affected tables, the 

number of processed table entries, and the file sizes. The contents of the 

archiving can be stored to document level in application-specific logs. 

Note: The archiving logs are deleted by the regular cleaning of 

spool jobs. You must therefore consider the destination of these 

logs. You could, for example, store the logs on an external storage 

system. 

You can trace the process of an archiving run with the monitoring of the 

background work processes using the transaction Simple Job Selection 

(transaction code SM37). By choosing Job Overview, you can move directly 

from the initial screen of transaction SARA to transaction SM37. By 



choosing Management (after you have maintained an appropriate archiving 

object on the initial screen of transaction SARA), you can display a short 

log file of an archiving run from transaction SARA. 

Choose the Job Overview buttonontheinitialscreenoftransactionSARAto 

show which jobs have been scheduled and monitor their status. You may 

want to display the job log or the spool list created. 

Then go back to transaction SARA and choose the Management button 

(if necessary, first maintain the archiving object entry). On the resulting 

screen, open the tree structure to the completely written archive file. Select 

this archive file and choose Spool List. The system displays a list of the 

statistics for the written data objects. 

Then return to transaction SARA and choose the Delete button to schedule 

the delete program for work items. On the following screen, choose Archive 

Selection to select the archive that you have just created, and schedule 

the run with the start time Immediate and without changing the spool 

parameters (by choosing Spool Parameters → Continue). If appropriate, 

pointoutthatthedeleteprogramisnowexecutedunderyourownuser 

name. Choose Execute. Finally, return to the job overview and display the 

relevant logs for this job after it has been successfully executed. 

You can optionally also return to the initial screen of transaction SARA and 

choose the Management button, and then expand the tree structure on the 

next screen. Select the executed archiving run and choose Storage System. 

You obtain an overview that shows, for example, that the delete program 

has already completed its run, the file has not yet been stored in a storage 

system, and that the archive file can be accessed. 

In addition, there is a specific data archiving monitor (monitor “Data 

Archiving” in the monitor set “SAP CCMS Monitor Templates”) in 

the CCMS monitor sets (transaction RZ20). It is intended for system 

administrators, so that they can monitor archiving runs in their familiar 

environment, the CCMS monitor. You can use the Data Archiving monitor 

to obtain an overview of the archiving objects in the system for which 

there are already runs. You can use the cross-archiving object Customizing 

to activate or deactivate it. 

The data archiving monitor in transaction RZ20 is available as of SAP Basis 

4.6. You can optionally display this monitor. You can find it in transaction 

RZ20 under SAP CCMS Monitor Templates → Data Archiving. 



If there are a large number of administrators among the participants of 

your course, they will certainly appreciate a discussion of typical causes of 

errors. Causes of errors for data archiving are, for example: 

• Insufficient storage space during the processing of the archiving 

program (recommendation: test run to determine the file sizes) 

• Database error: overrun of the rollback segment before a transaction 

commit 

• There is already an archive file with an identical name 

• The values for profile parameters for storage areas are too small, such 

as the parameters abap/heap_area_nondia or abap/heap_area_total: For 

recommended values for Microsoft Windows NT, see SAP Note 88416. 



165 Exercise 11: Perform Data Archiving 




• Check basic Customizing settings for SAP data archiving 

• Schedule and monitor a simple archiving run 


Your company uses SAP data archiving to reduce the size of the database 

for the SAP system and therefore to be able to ensure good response times 

long-term. As a member of the system administration team, it is your 

task to schedule an archiving run. 

System Data 

System: Dependsonthecoursesetupinuse. AnSAP 

system with SAP Web AS 6.20 is required. 

Client: Dependsonthecoursesetupinuse.Forcourse 

ADM100: client 100. Completed work items that can be archived must 

be available in this client. In the setup for course ADM100, a completed 

employee leave request is available. 

User ID: Depends on the course setup in use. A course 

user with authorization to execute transactions SARA, DB15, FILE, and 

SM37 is required. For course ADM100, the ADM100-## users (where ## 

corresponds to the group number) have the required authorizations. 

Password: Depends on the user used. The ADM100-## users 

have the initial password init. 

Set up instructions: 

1. There must be a work item to be archived available in the client for 

each participant group. In the setup for the ADM100 course, each 

group has a separate SAP system. In this setup, an employee leave 

request can be archived. 

Task 1 Check Archiving Object 

To prepare an archiving run, determine which database tables are 

associated with which archiving object. 

1. Check the tables from which data is archived for the archiving object 

Workitem. 




Task 2 Check Customizing Settings 

Check the Customizing settings for the archiving run. 

1. In Basis Customizing, ensure that a logical path exists as the global 

path for data archiving, note its name, and assign the physical path 

\ to this logical path for the Microsoft 

Windows NT operating system (or assign an appropriate path name if 

your SAP system is not running on a Microsoft Windows NT server). 

2. In Basis Customizing, ensure that the logical file name 

ARCHIVE_DATA_FILE is assigned the physical file name 

____.ARCHIVE 

and the logical path ARCHIVE_GLOBAL_PATH. 

3. In archiving object-specific Customizing for the WORKITEM archiving 

object, define a variant for test mode and a variant for production 

mode (with the names TEST_## and PROD_##, where##isyour 

group number), and maintain the process control appropriately for 

these variants. Then maintain the attributes of the variants and save 

the variants. Ensure that the delete job is not scheduled. You should 

also ensure that the logical file name ARCHIVE_DATA_FILE is 

assigned to the object name workitem. 

Task 3 Start the Write Program 

From the SAP system, generate an archive file for the archiving object 

WORKITEM. To do this, schedule the write program, run it, and monitor its 

processing. 

1. Create a variant for the write program. Name the variant Write_##, 

where ## is your group number. Maintain the process control for 

the variant so that an Archive and Delete is executed. Then schedule 

the write program with the start time Immediate and the predefined 

spool parameters. 

2. Display the spool list and the job log of the archive run. 

3. Check whether an archiving file was created at file system level. 

Task 4 Start Delete Program 

Now delete the objects archived in the previous task from your database. 

To do this, schedule the delete program, run it, and monitor its processing. 




1. Start the delete program from transaction SARA by running it under 

your own user. Maintain the archive selection, the start time, and the 

spool settings so that you select the archive you created in task 3, 

start the delete program immediately, and leave the spool parameters 

unchanged. 

2. Monitor the processing of your delete program by displaying the 

spool list. 



Solution 11: Perform Data Archiving 

Task 1 Check Archiving Object 

To prepare an archiving run, determine which database tables are 

associated with which archiving object. 

1. Check the tables from which data is archived for the archiving object 

Workitem. 

a) Call the transaction Tables and Archiving Objects (transaction 

code DB15, menu path Tools → CCMS → DB Administration → 

Data Archiving). Select the radio button Tables From Which Data 

Is Archived. IntheTables in Object input field, enter WORKITEM 

and choose Enter. 

The system displays the tables (such as SWP_HEADER) from 

which objects are archived. 

Task 2 Check Customizing Settings 

Check the Customizing settings for the archiving run. 

1. In Basis Customizing, ensure that a logical path exists as the global 

path for data archiving, note its name, and assign the physical path 

\ to this logical path for the Microsoft 

Windows NT operating system (or assign an appropriate path name if 

your SAP system is not running on a Microsoft Windows NT server). 

a) Call transaction Archive Administration (transaction SARA, menu 

path Tools → Administration → Administration → Data Archiving) 

and choose Customizing. On the next screen, select the row 

Cross-Client File Names/Paths in Basis Customizing: and then 

choose Execute at the left of the row. Confirm the dialog box. By 

doing so, you call transaction FILE. On the screen Change View 

Logical File Path Definition: Overview, doubleclickLogical File 

Path Definition. Then check on the right of the screen whether 

the entry with the Name Global path for archiving 

exists. The logical file path ARCHIVE_GLOBAL_PATH should be 

defined for this entry. Select this row and, in the tree structure on 

the left of the screen, choose the path Logical File Path Definition 

→ Assignment of Physical Paths to Logical Path, by double clicking 

Assignment of Physical Paths to Logical Path. Thendoubleclick 

WINDOWS NT ontherightofthescreenandensure(ifnecessary, 

by changing the entry) that the Physical path field contains the 

entry \. 




2. In Basis Customizing, ensure that the logical file name 

ARCHIVE_DATA_FILE is assigned the physical file name 

____.ARCHIVE 

and the logical path ARCHIVE_GLOBAL_PATH. 

a) In the left of the screen in transaction FILE, double click the 

folder Logical File Name Definition, Cross-Client. Thendoubleclick 

the entry ARCHIVE_DATA_FILE in the table on the right of the 

screen. On the following screen, check that the logical file 

ARCHIVE_DATA_FILE is assigned the physical file 

____.ARCHIVE 

and the logical path ARCHIVE_GLOBAL_PATH or adjust the 

entries as appropriate. For information about the parameters 

used, display the F1 help for the Physical File input field. 

3. In archiving object-specific Customizing for the WORKITEM archiving 

object, define a variant for test mode and a variant for production 

mode (with the names TEST_## and PROD_##, where##isyour 

group number), and maintain the process control appropriately for 

these variants. Then maintain the attributes of the variants and save 




the variants. Ensure that the delete job is not scheduled. You should 

also ensure that the logical file name ARCHIVE_DATA_FILE is 

assigned to the object name workitem. 

a) On the initial screen of the transaction Archive Administration: 

Initial Screen (transaction SARA), enter the value WORKITEM 

in the Object Name input field and then choose Customizing. 

On the next screen, select the row Technical Settings in Archive 

Object-Specific Customizing: and then choose Execute at the left 

of the row. Ensure that the Logical File Name field contains the 

value ARCHIVE_DATA_FILE. You should also ensure that the 

Not Scheduled radio button is selected in the Delete Jobs group 

box. Enter TEST_## in the Test Mode Variant field, where ## 

is your group number, choose the Variant button associated 

with this field, and choose the Change Values button on the 

next screen. On the following screen, select the Test Run radio 

button and choose Variant Attributes. IntheDescription field on 

the following screen, enter a useful short description of your 

variant and choose Save. Then return to the screen Change View 

Customizing View for Archiving: Details. EnterPROD_## in the 

Production Mode Variant field, where ## is your group number, 

choose the Variant button associated with this field, and choose 

the Change Values button on the next screen. On the following 

screen, Maintain Variant: Report RSWWARCD, Variant PROD_##, 

select the Delete radio button and then choose Variant Attributes. 

In the Description field on the following screen, enter a useful 

short description of your variant and choose Save. Thenreturn 

to the screen Change View Customizing View for Archiving: Details 

and choose Save again. You have now maintained the archiving 

object-specific Customizing settings. On the next screen, select 

an existing Workbench request using Own Requests or, if you 

have not yet created a new Workbench request, create a new 

Workbench request by choosing Create, enter a short description, 

save it, and choose Continue. 

Task 3 Start the Write Program 

From the SAP system, generate an archive file for the archiving object 

WORKITEM. To do this, schedule the write program, run it, and monitor its 

processing. 




1. Create a variant for the write program. Name the variant Write_##, 

where ## is your group number. Maintain the process control for 

the variant so that an Archive and Delete is executed. Then schedule 

the write program with the start time Immediate and the predefined 

spool parameters. 

a) On the initial screen of transaction SARA, enter the value 

WORKITEM in the Object Name field and choose Write. Onthe 

following screen, enter the value Write_## in the Variant field, 

where ## is your group number, and choose Maintain. Confirm 

the dialog box by choosing Continue. On the following screen, 

Maintain Variant: Report RSWWARCA, Variant Write_##, select the 

Archive and Delete radiobuttonintheProcess Control group box. 

Then choose Variant Attributes. Enter a useful short description 

in the Description field and choose Save. Thistakesyoubackto 

the variant maintenance overview screen. Choose Back. Onthe 

initial screen Archive Administration: Create Archive Files, choose 

Start Date. On the following screen, choose Immediate and then 

Save. Simply confirm the spool parameters by choosing Spool 

params. and then Continue on the next screen. Finally, choose 

Execute and return to the initial screen of transaction SARA. 

2. Display the spool list and the job log of the archive run. 

a) On the initial screen of the archive administration transaction 

(SARA), enter the value WORKITEM in the Object Name field and 

choose Job Overview. The system displays an overview of the 

archiving jobs that you have scheduled. Select the row for the 

job ARV_WORKITEM_WRI and choose Display Spool 

List. On the next screen, select the row for the spool list and 

choose Display Contents. Thenreturntothejoboverview,select 

the job, and choose Display Job Log. Among other things, the 

system displays which file is created in which path at operating 

system level. Note the file name and file path. 

3. Check whether an archiving file was created at file system level. 

a) You have already checked in the Customizing settings that 

the archive file is to be written to the directory specified by 

the parameter DIR_GLOBAL. Now call the SAP Directories 

transaction (transaction AL11) and double click the 

DIR_GLOBAL entry. On the following screen, you can check 

whether a file with the name from the last subtask was created. 

Task 4 Start Delete Program 

Now delete the objects archived in the previous task from your database. 

To do this, schedule the delete program, run it, and monitor its processing. 




1. Start the delete program from transaction SARA by running it under 

your own user. Maintain the archive selection, the start time, and the 

spool settings so that you select the archive you created in task 3, 

start the delete program immediately, and leave the spool parameters 

unchanged. 


WORKITEM in the Object Name field and choose Delete. Onthe 

following screen, enter your SAP user name in the User Name 

field, if it is not already entered there. Then choose Select 

Archive Files (Archive Selection button). On the next screen, select 

the displayed file (such as 000001) and choose Continue. You 

return to the initial screen Archive Administration: Execute Delete 

Program. Choose Start Date here. On the following screen, choose 

Immediate and then Save. Simply confirm the spool parameters by 

choosing Spool Parameters and then Continue on the next screen. 

Finally, choose Execute. The system displays the information that 

new delete jobs were scheduled in the status line and returns 

you to the initial screen of transaction SARA. 

2. Monitor the processing of your delete program by displaying the 

spool list. 

a) On the initial screen of the archive administration transaction 

(SARA), enter the name of the archiving object WORKITEM in the 

Object Name field and choose Job Overview. The system displays 

an overview of the archiving jobs that you have scheduled. 

Select the row for the job ARV_WORKITEM_DEL 

and choose Display Spool List. On the next screen, select the row 

for the spool list and choose Display Contents. 








For more information about running SAP data archiving, attend SAP 

course BIT660 (Data Archiving), the SAP Service Marketplace under the 

Quick Link /data-archiving or in the online documentation in the area 

“Introduction to Data Archiving” (area CA-ARC). 



Lesson: 

173 

Accessing Archived Data 



A significant prerequisite for archiving application data is that this data 

belongs to completed business processes or periods and is therefore no 

longer required for current business processes. However, it may be 

necessary to access this data again even after it has been archived, for 

example in the case of a complaint, for evaluations, or for an internal or 

external audit. In this lesson, you will obtain an overview of the options 

for accessing archived data. 





In this short lesson, the users should obtain an overview of how they can 

use transactions SARA and SARI, on the one hand, and specific application 

transactions on the other, to access archived data. 

Caution: It is a prerequisite for the demonstrations described in 

the instructor notes that an archiving run for the object WORKITEM 

has already been successfully completed. This prerequisite is 

fulfilled in the ADM100 course, since the lesson “Performing Data 

Archiving” has been addressed before this lesson. You should 

therefore ensure that you have access to an appropriate archive file 

at this point as part of your preparation. 


The user departments of your company want to access archived data. You 

want to obtain an overview of the ways in which this is possible. 

Access Options 

The Archive Development Kit stores data in such a way that a read access 

to it is possible at any time. The prerequisite for this is the existence of 

appropriate read programs, which are made available by the relevant 


ADM100 Lesson: Accessing Archived Data 

archiving object. They are used to read the archived data objects in 

accordance with the selection criteria and to display it in a suitable format 

for the user. In general, two types of access or display are used: 

• Sequential access 

• Direct access 

Sequential (reading) access is the simplest form of access to archived data. 

With this type of access, the read program first open the archive files from 

an archiving run sequentially, read the contents of all data objects, and lists 

the data that meets the entered selection criteria sequentially. You can use 

this method, for example, to list all data objects for a particular posting 

period or for a particular document number group. 

Direct access to individual archived data objects, such as an order or 

billing document can only be achieved using an index table. The data 

object to be displayed is first selected in the index table using search terms. 

If this is successfully achieved, the archivefilethatcontainsthedataobject 

concerned is localized and opened using the index. The read program 

can now directly access and display the data object for which you have 

searched. This type of direct access is relatively costly from a technical 

point of view, and is therefore only offered by a small number of archiving 

objects, such as FI_DOCUMNT. 

Hint: A simple option for system administrators to obtain read 

access to archived data is to enter the relevant archiving object on 

the initial screen of transaction SARA and to choose Read. 

The SAP Archive Information System provides significantly more 

extensive and easier to use functions for quick direct access to archived 

data objects. 

SAP Archive Information System 

Start point for using the SAP Archive Information System: If a user 

wants to display archived customer order 5000, he or she can display 

it using evaluation programs for the relevant archiving object (in this 

case: SD_VBAK). In this case, the archive data that he or she selects, is 

sequentially searched. There is no solution for displaying the data in the 

original transaction for order data (in this case, comparable to the display 

of FI_DOCUMNT in transaction FB03 in an SAP R/3 system). However, a 

general, generic solution for displaying a document directly is required. 

It was against this background that theSAPArchiveInformationSystem 

was developed. 



The SAP Archive Information System (Archive Information System, SAP 

AS) is a tool for searching in SAP data archives that is fully integrated 

into the archiving environment. It offers you support when searching for 

archived data and provides functions for displaying this data. 

The SAP Archive Information System is a generic tool; that is, the available 

functions can be used for all existing archiving objects. 

The search for data is always based on archive information structures. 

These are transparent database tables that are supplied with data from the 

archive. To search for archived data for an archiving object, there must be 

at least one archive information structure for this archiving object. An 

information structure of this type always includes the structure itself, the 

corresponding transparent database table, and an evaluation program. 

Before an archive information structure can be created, that is, filled with 

data from the archive, it must first be activated. The system generates a 

transparent database table and the evaluation program in the background. 

At the start of the delete run for an archiving object, all of the active 

information structures for this archiving object are filled. 

In addition to this automatic option, it is also possible to explicitly create 

information structures using a special structure creation program. 

Figure 62: Automatic Filling of an Information Structure by the Delete 

Program 

When displaying archived data, the user can usually choose between a 

number of views in which the data objects can be displayed. Examples of 

these views are the technical view and the business view. 



Note: By default, there is a technical view for every archiving 

object. Whether an application-specific view is provided depends 

on whether a view of this type was implemented for this archiving 

object. You can also use the demonstration described in the last 

instructor note in this lesson to differentiate between the technical 

view and application-oriented view. 

At the end of this lesson, you can demonstrate that you can display the 

archived data in different ways: on one hand, directly from transaction 

SARA or transaction SARI , and on the other from an application 

transaction: 

On the initial screen of transaction SARA, enter the object name WORKITEM, 

press Enter, andchooseRead. On the next screen, choose Execute. Then 

select the file to be read, and choose Continue. The system displays a tree 

structure that you can expand. In this way, you can obtain an overview of 

the archived work item for the employee leave request. Note the number 

of an archived work item (such as “0000000001”, the leading numbers are 

also important, as the work item number is always 10 digits in length) and 

the date of the processing of the work item (such as “January 24 2003”). 

You can optionally also choose the Archive Explorer button on the initial 

screen of transaction SARI to demonstrate the display of archived data 

using the SAP Archive Information System. On the next screen, select 

the archiving object WORKITEM and choose a valid entry for the archive 

information structure. Then choose Report. On the next screen, accept the 

default settings and choose Execute. In the list that is displayed, select 

the first entry by double clicking it. The system displays an overview of 

the tables that belong to the selected object. You can optionally also view 

the archived data from a table by clicking the icon next to the relevant 

table name. 

You can obtain a different - application oriented - view of the archived data 

by calling the transaction Read Workflows from Archive (transaction code 

SWW_ARCHIV). In this way, you simulate an end user that is searching 

for a particular workflow. In the Object Type field, enter FORMABSENC (for 

Form: Absence). Use the input help to select an appropriate Object Key (or 

- if this is not possible - enter the number from the previous demo here, 

including the leading zeros), select an appropriate Period (this refers to the 

processing day of the workflow and not the day of archiving, ensure that 

the day noted from the previous demo is included) and choose Execute. 

Then select a file and choose Continue. You may have to select one of the 

IDs on the following screen and choose Copy. As a result, the system 

displays a specific workflow log that has already been archived. 



Additional Background Information about the SAP Archive Information 

System (you do not especially have to discuss the contents with the 

participants, it is simply optional demonstrations in case the participants 

have additional questions about the SAP Archive Information System. 

Alternatively, you can, of course, direct the participants to SAP course 

BIT660.) 

• The SAP Archive Information System can be called from archive 

administration (transaction SARA) or directly using transaction SARI. 

(Transaction SARI cannot be called using a path in the SAP Easy 

Access Menu.) It is structured into the following components (see 

also the following figure): 

– Archive Retrieval Configurator 

– Archive Explorer 

– Status management 

Figure 63: SAP Archive Information System: Overview 

• The Archive Retrieval Configurator (ARC, Customizing button in 

the initial screen of transaction SARI) can be used to created archive 

information structures and to fill them with information from archive 

files. 

An archive information structure serves the same purpose as an 

index. In addition to the actual search fields, it contains additional 

information that is required to access an archived data object. 



This additional information includes the name of the archive file that 

contains the data object and the address of the data object in the 

archive file. You can use this information to access individual data 

objects, that is, to realize a direct access. 

• The Archive Explorer (Archive Explorer buttonontheinitialscreenof 

transaction SARI) allows you to display archived data objects. The 

relationship of the displayed fields is defined by the information 

structure. 

On the selection screen of the Archive Explorer, the user can define 

which data objects are to be read by the Archive Explorer’s evaluation 

program. An object list is displayed fro the set information structure, 

starting from this selection. It is possible to go to individual data 

objectsinthearchivefromthislist. 

• Status management (Status button on the initial screen of transaction 

SARI) provides information about whether an information structure 

was successfully created or deleted. 

The user can also use status management to trigger the creation or 

deletion of activated information structures. If new structures are 

built, the relevant tables in the database are filled with information 

from the archive files in the background. 

Note: The ADK’s cross-application authorization checks 

are checked when the SAP Archive Information System is 

executed or archive files are opened. The authorization object 

is: S_ARCHIVE. 

• You can optionally demonstrate the creation of a new archiving 

structure and its activation for the participants. There is already an 

activated structure for the exercises for this lesson in the setup for 

theADM100course(withthenameFORADM100).This can be used 

in the exercises: 

– To create the archiving structure, choose the Customizing button 

on the initial screen of transaction SARI. Give the structure 

a self-explanatory name and choose Create. Onthedialog 

box that appears, select the archiving object WORKITEM and 

use the F4 help for the Field Catalog field to select the entry 

SAP_WORKITEM001. Choose Create and save the structure as 

a Local Object. Then return to the initial screen of the Archive 

Retrieval Configurator. Choose Activate for the selected archive 

information structure here, and confirm the subsequent message. 

– If you have already successfully archived data, build a structure 

for this archiving object by choosing the Status button on the 

initial screen of transaction SARI. On the following screen, select 

your archiving object (WORKITEM) and choose Status per info 



structure. Select your info structure and choose Create Structure. 

Choose the processing mode Dialog and then expand the list. 

The system displays an overview of the files that belong to this 

archiving object. 



177 Exercise 12: Access Archived Data 




• Access archived data to read it 


Your company uses SAP data archiving. It is necessary to access data that 

has already been archived in the context of an evaluation that you are 

to perform. 

System Data 




ADM100: client 100. Completed work items that can be archived must 

be available in this client. In the setup for course ADM100, a completed 

employee leave request is available. 


user with authorization to execute transactions SARA, SARI, SARJ, and 

SM37 is required. For course ADM100, the ADM100-## users (where ## 

corresponds to the group number) have the required authorizations. 




1. Theremustbeaanarchivedworkitem available in the logon client 

for each participant group. In the setup of the ADM100 course, each 

group has a separate SAP system. In this course, an employee leave 

request was already archived in the previous exercise for the lesson 

“Performing Data Archiving”. This can now be accessed to be read. 

2. There must already be an archive information structure in transaction 

SARJ for the archiving object WORKITEM. This must have been 

activated. In the setup for the ADM100 course, the archive 

information structure FORADM100 is available. 

Task 1 Technical View 

As a member of the system administration team, you want to obtain a 

technical view of data that has been archived (in this case, work items). 




1. Use transaction SARA to start the read program for archiving object 

WORKITEM. Select a suitable archive to read and expand the result of 

the read program. 

Task 2 Business View (Optional) 

As a member of a user department, you want to access archived work 

items to read them. 

In this optional exercise, you must ensure that the participants select the 

correct period on the selection screen and enter the correct object key 

including the leading zeros (the object key has ten digits). The required 

data can be taken from the result of the above task. It is therefore important 

that this task is only performed if it was possible to successfully complete 

task 1 above. 

1. Use transaction SWW_ARCHIV to read work items with an 

appropriate object key and period. Expand the displayed workflow 

log and obtain an overview of the process of the archived workflow. 



Solution 12: Access Archived Data 

Task 1 Technical View 

As a member of the system administration team, you want to obtain a 

technical view of data that has been archived (in this case, work items). 

1. Use transaction SARA to start the read program for archiving object 

WORKITEM. Select a suitable archive to read and expand the result of 

the read program. 


WORKITEM in the Object Name field and then choose Read. On 

the next screen, choose Execute. On the following screen, select 

the displayed file (such as 000001) and choose Continue. The 

Read Program for Work Items (for Archiving) appears. You can 

trace the individual steps of the processing of the work item on 

this screen by expanding the tree structure. If you also want to 

perform the following, optional exercise, note the number of 

the archived work item including the leading zeros (that is, for 

example 0000000001) and the date of the processing (that is, 

for example, January242003). 

Task 2 Business View (Optional) 

As a member of a user department, you want to access archived work 

items to read them. 

In this optional exercise, you must ensure that the participants select the 

correct period on the selection screen and enter the correct object key 

including the leading zeros (the object key has ten digits). The required 

data can be taken from the result of the above task. It is therefore important 

that this task is only performed if it was possible to successfully complete 

task 1 above. 




1. Use transaction SWW_ARCHIV to read work items with an 

appropriate object key and period. Expand the displayed workflow 

log and obtain an overview of the process of the archived workflow. 

a) Call the transaction Read Workflow from Archive (transaction 

SWW_ARCHIV, menu path Tools → Business Workflow 

→ Development →Administration → Workflow Runtime→ 

Reorganization → Display Workflows from Archive). In the Object 

Category field, select BOR Object Type, andintheObject 

Type field, select the entry FORMABSENC. IntheObject Key field, 

enter the number of the work item noted from the previous task 

including the leading zeros (that is, for example, 0000000001). 

In the Period group box, select a period that includes the date 

from the previous tasks (such as 24.01.2003). On the next 

screen, select the displayed file (such as 000001) and choose 

Continue. The system displays the log of the selected work item. 

On this screen, you can use the Processor and Object buttons to 

display different views of the archived workflow and expand 

each of the views. 








For additional information about accessing archived data, attend SAP 

course BIT660 (Data Archiving) or see theSAPServiceMarketplace,under 

the Quick Link /data-archiving. For information about the SAP Archive 

Information System, see the online documentation, section “Archive 

Information System ” in the area “Introduction to Data Archiving” (area 

CA-ARC). 



Unit Summary 











181 


1. Every archiving object in the SAP system is connected 1:1 with the 

content of a single database table. 


True 

False 

2. The names of the archive files are determined at runtime. How are 

these names generally specified for a specific archiving object? 


A By cross-object Customizing settings 

B By maintaining a local path and assigning the logical path 

to a physical path in the Basis Customizing 

C By assigning a physical file name to a logical file name in 

Basis Customizing and assigning a logical file name to an 

archiving object in the archiving object-specific Customizing 

D By the exact time of the archiving run 

3. After data has been archived from the SAP system and deleted it 

from the SAP system’s database, it is no longer possible to access this 

data with read accesses. 


True 

False 



182 

Answers 

1. Every archiving object in the SAP system is connected 1:1 with the 

content of a single database table. 

Answer: False 

Different business objects could belong to each archiving object in the 

SAP system. The data for these business objects could, in turn, be 

distributed across multiple database tables. 

2. The names of the archive files are determined at runtime. How are 

these names generally specified for a specific archiving object? 

Answer: C 

The name of the archive files is determined at runtime by settings in 

the archiving object-specific Customizing (assignment of a logical file 

name for the specific archiving object) and in the Basis Customizing 

(assignment of a physical file name to a logical file name in the 

Basis Customizing and the assignment of a logical file name). 

No specifications about the name of the archive file are made in 

cross-object Customizing. The exact time of the archiving run can 

appear in the name of the archiving file using a parameter, but the 

name is generally not determined by this alone. 

3. After data has been archived from the SAP system and deleted it 

from the SAP system’s database, it is no longer possible to access this 

data with read accesses. 

Answer: False 

It is still possible to access data to read it after it has been stored in 

the archive and deleted from the SAP system’s database. Depending 

on the archiving object concerned, there may be a number of views 

between which the user can choose (such as a technical view and a 

business view). 


Unit 7 

183 Working with the Transport System 

As an introduction, you can use a figure to discuss a structure with two 

clients. Explain that the user data of each client only makes sense in that 

client and should therefore not be copied in the context of a client copy 

- also for data protection reasons. Later, you can show a three-system 

landscape, either using a figure or in the system itself. In the system: Call 

transaction STMS, choose the System Overview button, and the Transport 

Routes button. Other demonstrations include creating a Workbench 

request using transaction SE09, which is used for additional developments 

(transaction SE80). 

Unit Overview 

This unit will introduce the basics of software logistics. The following 

points will be deal with: the data structure of SAP systems, the 

three-system landscape recommended by SAP, upgrades, and transports. 



• Describe the data Structure of an SAP system 

• List the advantages of and requirement for a three-system landscape 

• Create and release transport requests 

• Describe the architecture of the SAP transport system 

• Import transport requests 

Unit Contents 

Lesson: Data Structure of SAP Systems and System Landscapes......218 

Lesson: Performing and Checking Transports ..............................226 

Exercise 13: System Landscapes and Transport Requests ..........237 


Unit 7: Working with the Transport System ADM100 

Lesson: 

184 

Data Structure of SAP Systems and System 

Landscapes 



The data structure of an SAP system will be discussed. Terms such as 

client, object repository, and cross-client Customizing will be introduced. 

Threewaystochangeandcreaterepositoryobjectswillbedescribed. 

The advantages and requirement for a three-system landscape will also 

be presented. 





You should emphasize that the repository and cross-client Customizing 

only exist once for each SAP system. You can illustrate this with a fictional 

example of two different companies mapped in different clients, and 

served by one computer center. You should also emphasize that modifying 

SAP objects should be an absolute exception, since time-consuming 

tasks have to be performed during the modification adjustment. The 

instructor should also introduce the SAP and customer namespace; for 

more information, see the online help, section BC-CTS. 


SAP software is to be adjusted to company-specific requirements in your 

company. How are programs exchanged between SAP systems? As little 

postprocessing as possible should be required in the case of a subsequent 

system upgrade. 

Data Structure of the SAP System 

Knowing the data structure of an SAP system is equally important for 

users, developers, and administrators to understand the way in which 

an SAP system functions. 


ADM100 Lesson: Data Structure of SAP Systems and System Landscapes 

Figure 64: Data Structure of an SAP System 

These figures explain the structure of an SAP system: What data is required 

to create an SAP system? Use examples to reinforce the explanation. You 

should explain the components and the role of a client. NEW since SAP 

Web AS 6.10: there are now only two standard clients, 000 and 066. 

SAP systems have a specific data structure. In addition to business settings 

(Customizing) that are only relevant for certain clients of the SAP system, 

an SAP system also always contains cross-application settings and objects: 

cross-client Customizing and the repository. 

The repository is the central store for all development objects of the 

ABAP Workbench and is cross-client. The repository objects are stored in 

packages. Packages are containers for semantically-linked development 

objects. They replace development classes. A package consists of 

sub-packages and development objects (programs, tables, screens, function 

modules, classes, and so on) that are developed and transported together. 

Packages are characterized by the properties nesting, interfaces, visibility 

and use accesses. Packages are created and managed with the Package 

Builder. The recording and transport of object changes are also controlled 

by the Change and Transport System (CTS) using assignment to a package. 

The settings of an SAP system are described as Customizing. The 

enterprise-neutral and industry-specific business functions that are 

delivered are tailored to the specific requirements of the enterprise in the 

Customizing process. Customizing is obligatory both during the first 

installation and during an upgrade and is performed in the SAP system 

using the Implementation Guide (IMG). 



SAP systems differentiate between client-dependent and cross-client 

Customizing. Cross-client Customizing includes the public holiday 

calendar, or settings for the transport domains and system changeability. 

Figure 65: Client 

SAP systems are divided into business units, in clients. A client is a 

self-contained unit in commercial, organizational, and technical terms in 

an SAP system and consists of business settings (Customizing), its own 

master and transaction data, and its own user data. 

A client’s data is described as client-dependent or cross-client data. 

Client-dependent data types are closely interdependent. Thus, when 

application data is entered, the system checks whether the data matches the 

client’s Customizing settings. If there are inconsistencies, the application 

data is rejected. Application data is therefore only meaningful in business 

terms in the relevant Customizing environment. 

Examples of client-dependent Customizing are company codes and 

business settings such as plants, warehouses, and so on. 

Client-dependent data is data that is only valid in that client. This includes, 

for example, material master records, orders, and invoices. 

User data and authorizations are also client-dependent. 

Various client roles are used in an SAP system. A Customizing client 

is required for the client-dependent Customizing in the development 

system. In test systems, a client is created for test purposes (“Test” role); in 

production systems, a client for productive work. You can use transaction 

SCC4 to assign the roles to the clients. 



Changing the Data Structure 

Figure 66: Adjustments to the Data Structure 

You should discuss the various adjustment options and the need for them 

here. Possible problems that can arise from adjustments should be outlined 

here and described in more detail using the following slides. 

As well as client-specific and cross-client Customizing, you can make 

additional adjustments to the data structure. You can make changes or 

enhancements are possible in the repository. These are not necessarily 

required to use an SAP system. Changes or enhancements to the repository 

are possible in a variety of ways: 

• Extension of the repository through customer developments. In 

the SAP system, it is possible to create your own repository objects 

such as tables, programs, transactions, and so on. All customer 

developments are usually performed in the customer name space; 

that is, all objects created by customers have names from a specified 

namespace, and must begin with the letter “Y” or the letter “Z”. You 

can, however, also request your own namespace that begins and ends 

with “/” free of charge from SAP. This must be a maximum of eight 

characters, including the “/”, such as “/Firm/”. All of the objects 

that you write then have a name beginning with “/Firm”, such as 

“/Firm/GreatProgram”. 



• Adjusting the repository with customer enhancements. In this case, 

customer objects are added to the repository. The SAP standard 

programs can be extended with customer objects at specified points 

in the coding, called “Customer Exits”. 

• Modifications to the standard SAP system: Changes to SAP objects 

(programs, table definitions) are described as modification. The 

repository delivered by SAP is not only extended, but changed. 

Three-System Landscape 

You can explain the need for a three-system landscape using the data 

structure of an SAP system: since the object repository only exists once for 

each system, customers must never develop in the production system. 

You should explain the role of the different systems, and discuss what the 

different clients are required for, and when it would be useful to use them. 

SAP’s recommendation for a three-system landscape is based on the data 

structure of an SAP system, in which the object repository only exists once. 

You must never develop and work productively in the same SAP system. 

Figure 67: The Three-System Landscape 

You can illustrate a three-system landscape at this point, using either the 

figure or the system itself. In the system: Call transaction STMS, choose 

the System Overview button, and the Transport Routes button. 



As the repository objects are cross-client, we recommend that you do not 

develop in a system at the same time as you are working in it productively, 

as this carries a danger of possible data inconsistency. If you are making 

changes to the repository, we recommend that you use at least two, but 

ideally three separate systems. One system for development, a second 

system for tests and quality assurance, and a third system in which you 

work productively: a system landscape of three systems. 

A three-system landscape allows you to use the following, recommended 

procedure: You develop your own programs and perform the required 

Customizing in the development system. The Customizing settings that 

you make and all changes to the repository (developments, corrections, 

modifications) are recorded in the development system and then 

transported to the quality assurance (or “Test”) system, and are checked 

there without influencing production operation. All objects and settings 

imported into the test system can then be transported to one or more 

production systems after a successful test. 

Different clients can be created for different purposes in one system. If 

you perform client-dependent Customizing in a development system that 

you want to check before transporting it to other systems, a test client in 

the development system can be useful. Clients with specified roles are 

usually created in each system: A development client in the development 

system, a client for testing in the quality assurance system, and a client 

for productive work in the production system. The clients should have 

an identical ID, as far as possible, as the following rule applies during 

transporting: Source client = Target client. 




Keine moderierte Diskussion. 












Lesson: 

191 

Performing and Checking Transports 



In this lesson, you will learn how to perform transports between SAP 

systems. Differences between and similarities of workbench and 

Customizing requests will be considered. 

The export and import of transport requests will be explained. 






In this lesson, you should explain in detail how repository objects (tables, 

programs) are transported. You should differentiate clearly between the 

terms change request and task. Explain the different authorizations of the 

developer and the project leader. 

You could also possibly point out that up to SAP Basis 4.6B, transactions 

SE09 and SE10 were separate, and were only combined into the Transport 

Organizer with SAP Basis 4.6C. 


The changes that the developers make in the development system must 

be transported to the quality assurance system for testing, and, after 

successful testing, to the production system. Transporting change requests 

is part of the administrator’s task area. 

Workbench Requests 

Workbench and Customizing requests are both created with the Transport 

Organizer (transaction SE09 or SE10). In the context of a request of this 

type, a project leader defines development or Customizing tasks and 

assigns them to individual employees. After the individual tasks are 

released, the request can also be released. After a successful export, the 

request can be imported into the target system. 


ADM100 Lesson: Performing and Checking Transports 

Figure 68: Structure of Workbench Requests 

Create a workbench request in the Transport Organizer (SE09). Call 

transaction SE09, choose the Create button, select the Workbench request 

radio button on the dialog box and confirm your choice. Enter a short 

description and the transport target, assign the request to other employees 

if desired, and save. 

The system automatically assigns a number to the change requests 

(K9), a task is created for each employee. Each of these 

tasks is also assigned a sequence number. 

When a development project starts, the development project leader creates 

a change request. In doing so, he or she assigns the team members to the 

change request. The Transport Organizer (transaction SE09) assigns a 

number (K9, such as DEVK900050) to the change request. A 

request should contain objects that are logically connected and can only be 

meaningfully executed together. That is, a request allows you to transport 

and administer complete, meaningful, and self-contained developments. 

The Transport Organizer creates a task for every involved employee in the 

request. If an employee assigns a repository object to the change request, 

the repository object is logged in the task of that employee. In this way, all 

repository objects that an employee edits during the development project 

are collected in the task. 



When the development project is completed from the point of view of the 

employee, he or she releases his or her task. This transfers the objects in 

the task to the change request. Once all employees have released their 

tasks, the development project leader can release the change request and, 

in doing so, request the export. A change request therefore combines 

repository objects that have been created or changed during a development 

project. 

Figure 69: Development, Release, and Transport of Repository Objects 

The figure explains the development cycle of a repository objects and 

shows the employees that are involved in it. You should explain the object 

locks. If you have extensive knowledge of the area, you can also discuss 

the topic of versioning. 

System Demo: 

1. Create an object and assign it to a change request. 

In the Object Navigator (SE80), choose the Repository Browser button 

and select the Package entry from the dropdown list. 

Create a package in the customer namespace (Z_Package_...), assign it 

to the software componentHOME, and accept the default transport 

layer Z. 



Assign the newly created object to a workbench request: choose 

the Own Requests button to select the change request created in the 

previous demo and assign the package to this. 

Optional: Create a second object in the customer namespace (an 

ABAPprogramwithSE38oratablewithSE11),assignittothe 

package that you have just created, and add it to the change request. 

2. Test the object and release the task. Release the change request. 

Call the package that you created in the Object Navigator (SE80). 

Display your own change request and its associated tasks in the 

Transport Organizer (SE09), and choose Release Directly. Whenyou 

choose this button, the request is released and exported. 

If a repository object is edited and included in a change request by a 

developer, it is exclusively reserved for processing by this change request. 

Changes to this object can only be made by developers that also have a task 

in this change request. The development or maintenance of development 

objects is locked for all other developers that are not involved in the same 

change request until the change request is released. These developers 

can only display the objects. 

Every employee that is involved in the request that edits the object receives 

a corresponding entry in the object list of his or her task. In this way, it is 

possible to determine which employee actually edited the object. 

The object locks are removed when the change request is released. The 

objects can then be edited by all developers again. Changes to Customizing 

data are also registered in the Transport Organizer, although in the case of 

Customizing, the tables are only locked during the actual editing. 

The Transport Organizer also ensures that the repository objects are 

versioned, allowing both comparisons and access to earlier versions. In 

this way, you can document, and even recreate, the released states before 

and after a change request or development project. A version is created 

when a repository object is changed and when a change request is released. 



Customizing Requests 

Figure 70: Structure of Customizing Requests 

The next two figures should clarify the differences between and similarities 

of workbench and Customizing requests. 

Similarities: same structure (request/task(s)), different employees with 

appropriate authorizations. 

Differences: no assignments of Customizing to packages, object locks only 

during the actual work in the case of Customizing. 

When a Customizing project starts, the Customizing project administrator 

creates a change request for Customizing objects in the Transport 

Organizer (transaction SE09). He or she assigns the employees involved 

to the Customizing request. The Transport Organizer assigns a number 

(K9, such as DEVK900055) to the Customizing request. 

A Customizing request can only contain client-dependent Customizing 

objects. Cross-client Customizing that is to be transported must be 

recorded in a change request of “Workbench” type, as it is dealing with 

settings that apply system-wide. 



The Transport Organizer creates a subtask for every involved employee 

in the request. If an employee assigns a Customizing object to the 

Customizing request, the object is logged in the task of that employee. In 

this way, all Customizing objects that an employee edits during the project 

are collected in the task. 

When the Customizing is completed from the point of view of the 

employee, he or she releases his or her subtask. This transfers the objects 

in the task to the Customizing request. Once all employees have released 

their tasks, the Customizing project leader can release the change request 

and therefore export. 

Figure 71: Execution, Release, and Transport of Customizing 

The structure of Customizing projects is similar to the structure of 

development projects. The involved employees in this case are the 

Customizing project administrator, who creates and releases the 

Customizing requests, and the project team members, who perform the 

Customizing and assign it to a Customizing request. 

Changes to Customizing data are registered in the Transport Organizer, 

although in the case of Customizing, the tables (or table entries) are only 

locked during the actual editing. 



Transports 

Building on the requirement for transports, which should already be clear, 

thetechnicalprocessisexplainedhere.Atransportalwaysconsistsofthe 

steps export and import, and is physically performed using the central 

transport directory /usr/sap/trans. 

The transport of objects is divided into “Export” and “Import” phases: 

Export from the development system, import of the objects into other 

target systems, such as the test system and production system. 

Figure 72: Transports in a Three-System Landscape 

After they have been released, the changed or newly created objects are 

stored in data files in the central transport directory. The successful release 

and export is stored in the transport log of a change request. 

The import into the target system is usually not automatic, but is triggered 

by the transport administrator in the Transport Management System 

(TMS). The import logs can then be checked. 

In technical terms, a copy of the data from the development system 

database is written to the central transport directory during the export of 

the change request. During the import, the change request stored in the 

central transport directory is copied into the database of the target system. 



The central transport directory is physically stored on a server in the 

system landscape (the “transport host”), to which all systems in the system 

landscapemusthaveaccessusingashareormount.Theprofileparameter 

DIR_TRANS specifies for each system where the transport directory to be 

used, which is called /usr/sap/trans, isstored. 

Import 

The transport administrator usually starts the import manually in the 

receiving systems using the Transport Management System, which you 

can call with transaction STMS. 

Figure 73: Working with the Import Queue 

In the receiving system, you can see which change requests are queued for 

import into the system in transaction STMS. From a technical point of 

view, in a three-system landscape, the change request is flagged for import 

into the receiving system (quality assurance system) during the export 

from the development system. You can view this flagging of the change 

request for import into the receiving system in the Transport Management 

System (transaction STMS) by choosing Overview → Imports. This displays 

the import queue for the relevant systems. To display details about the 

queues, choose Import Queue → Display. 

There are a number of methods available to you in the TMS import queue 

for importing requests into the target system. The most important import 

methods are import all requests (import all) and Import Individual 

Requests (single import). You can perform an import in dialog or schedule 

an import in the background with any of the methods. The best import 

method for you to use depends on your system landscape and your 

transport strategy. 



Figure 74: Import 

With the import of single requests, you select and then import a single 

change request in the queue. 

With the import of all requests in the import queue, all requests are 

imported in the sequence in which they were exported; that is, in the order 

in which they are in the import queue. The import steps are performed 

successively for all of the requests. 

In the SAP System, the transport administrator starts imports using 

transaction STMS by displaying the import queue (Overview → Imports), 

selects the system into which he or she wants to import, and then choosing 

Import Queue → Display. After you have decided on an import strategy, 

start the import either by choosing either the Import all requests button, 

or Import request. 

Technically, the operating system executable program tp is used for the 

export and import. The import always uses the data files that were 

generated and stored in the central transport directory /usr/sap/trans 

during the export. 

Demonstrate the import of the transport requests that you created and 

released during the lesson. Follow the procedure in the text. You may 

want to explain the settings at the start of the import. 



Checking Transports 

Figure 75: Checking Transports 

In addition to the actual transport function, the possibility to check all 

transport steps is important. Log files are written in the transport directory 

/usr/sap/trans/log for each transport step. You can display these using the 

Transport Organizer (SE09). 

System Demo: Display your own requests in the Transport Organizer 

(SE09) by choosing the Transports button. Choose Display Log to view the 

log for the export. 

Choose Goto → All Logs to display all previous transport steps. 

During transporting, the transport steps performed in the various 

transport phases are logged. You can use the Transport Organizer to 

control transports: On the right-hand side of the initial screen of the 

Transport Organizer, there is a list of your transports and repairs. 

By choosing the “Transports” button, you display a hierarchical display 

of your released transports and their transport steps, structured by target 

systems. 



You can identify the success or failure of the individual transport steps 

from the colored labeling, the comment, and the return code. In the case of 

erroneous transports, the transport log contains notes about the cause of 

the errors. By double clicking a transport step, you display its transport 

log. 

All import steps are also logged during the import, which is performed 

by the transport administrator in transaction STMS. In this case, it is also 

possible to display the relevant information using the Transport Organizer. 

For more information about the import, call the system log for the system 

to be monitored by choosing Overview → Imports (or directly with the 

Import Overview button) in transaction STMS. To do this, choose the system 

to be checked in the import overview and display the system log by 

choosing Goto → TP System log from the import queue. From here, you can 

perform additional error analysis using other log files. 



201 Exercise 13: System Landscapes and 

Transport Requests 







The changes that the developers make in the development system must 

be transported to the quality assurance system for testing, and, after 

successful testing, to the production system. Transporting change requests 

is part of the administrator’s task area. 

Task 1 The Transport Organizer 

For this exercise, there must be a transport landscape of at least a 

development system DEV and a quality assurance system QAS in the 

system. The corresponding transport routes must have been set up. 

Every group must perform the exercise on the DEV system. The import is 

started in the target system QAS. 

Working with the Transport Organizer 

Hint: You should all log on to the DEV system with your user 

(such as ADM100-##) and perform the tasks below there. 

1. Use the Transport Organizer in system DEV to create a change request 

with the type Workbench Request. You can start the Transport 

Organizer by choosing Tools → ABAP Workbench → Overview → 

Transport Organizer or with transaction code SE09. 

2. Give your change request a meaningful short description and save it. 

3. Display the number of your request and the assigned tasks. 

Task2CreateaRepositoryObject 

Create a repository object 




1. In the DEV system, create a package with the Object Navigator (SE80). 

2. Assign the name “Z_ Package_##” to your package, where “##” is 

your group number. 

3. Assign the necessary attributes to the package: A meaningful short 

description, assignment to the software component HOME, and 

the standard transport layer . ChooseCreate to create your 

package. 

4. The system prompts you to assign your newly created repository 

object to a workbench request. Under the Own Requests button, 

choose the change request that you created in exercise 1 by double 

clicking it, and confirm the selection. 

5. Check the assignment to your request in the Transport Organizer. 

Task 3 Release Request 

Release the change request and the task 

1. Release your task (the package that you created) in the DEV system 

in the Transport Organizer. 

2. Then release your change request. 

Task 4 Import the Request 

Import the request and check the logs. 

1. Import your change request into the system QAS and check the logs. 



Solution 13: System Landscapes and 

Transport Requests 

Task 1 The Transport Organizer 

For this exercise, there must be a transport landscape of at least a 

development system DEV and a quality assurance system QAS in the 

system. The corresponding transport routes must have been set up. 

Every group must perform the exercise on the DEV system. The import is 

started in the target system QAS. 

Working with the Transport Organizer 

Hint: You should all log on to the DEV system with your user 

(such as ADM100-##) and perform the tasks below there. 

1. Use the Transport Organizer in system DEV to create a change request 

with the type Workbench Request. You can start the Transport 

Organizer by choosing Tools → ABAP Workbench → Overview → 

Transport Organizer or with transaction code SE09. 

a) On the initial screen, choose Create. On the next dialog screen, 

choose Workbench request, and then confirm by choosing the 

green checkmark. 

2. Give your change request a meaningful short description and save it. 

a) Enter a meaningful short description for your change request 

and save it by choosing Save. 

3. Display the number of your request and the assigned tasks. 

a) On the next screen, the system displays the (automatically 

generated) number for your transport request (K9) 

and the number(s) of the assigned task(s). 

Task2CreateaRepositoryObject 

Create a repository object 

1. In the DEV system, create a package with the Object Navigator (SE80). 

a) You can also call the Object Navigator by choosing Tools → ABAP 

Workbench → Overview → Object Navigator. On the initial screen 

of the Object Navigator, choose Repository Browser and choose 

the entry Package in the dropdown list below this. 




2. Assign the name “Z_ Package_##” to your package, where “##” is 

your group number. 

a) As your package does not yet exist, the system asks you if you 

want to create it after you choose Enter. Confirm this with Yes. 

3. Assign the necessary attributes to the package: A meaningful short 

description, assignment to the software component HOME, and 

the standard transport layer . ChooseCreate to create your 

package. 

a) Assign the necessary attributes to the package: A meaningful 

short description, assignment to the software component HOME, 

and the standard transport layer . Choose Create to 

create your package. 

4. The system prompts you to assign your newly created repository 


choose the change request that you created in exercise 1 by double 

clicking it, and confirm the selection. 

a) The system prompts you to assign your newly created repository 


choose the change request that you created in exercise 1 by 

double clicking it, and confirm the selection. 

5. Check the assignment to your request in the Transport Organizer. 

a) Display all change requests that you created but that are not 

yet released by choosing Display. There is a task described as 

“Development/Correction” under your change request. 

Task 3 Release Request 

Release the change request and the task 

1. Release your task (the package that you created) in the DEV system 

in the Transport Organizer. 

a) To release your task, switch to your not yet released change 

requests in the Transport Organizer by choosing Display. Select 

the task to be released (the package that you created is below it) 

and release this by choosing the “Release Directly” button. 

2. Then release your change request. 

a) To release the entire change request, select it and choose Release 

Directly. 




Task 4 Import the Request 

Importtherequestandcheckthelogs. 

1. Import your change request into the system QAS and check the logs. 

a) Call transaction STMS and call the import overview by choosing 

Overview → Imports. On the next screen, select the system (QAS), 

in to which you want to import, and display the imports queue 

for the system by choosing (Import Queue → Display). Now 

select your change request and start the import by choosing 

Import Request. The change request is to be imported with 

the predefined default values (immediately start, execute 

asynchronously, and so on). If required, enter the target client 

(such as 100), and perform the import. 

b) To check the logs, call the Transport Organizer (transaction SE09) 

and choose the Transports button on the Global Information tab 

page on the right of the screen. The system now displays the 

change requests that you have released and imported. You can 

displaythelogbychoosingDisplay Log. 










Unit Summary 











209 


1. Which elements are part of the data structure of an SAP system? 


A Registry repository 

B Object repository 

C Client 

D Database server 

E Cross-Client Customizing 

F SAP Kernel 

2. Decide which of the following statements are correct. 


A Entering customer data requires a Customizing request. 

B A change request contains one or more tasks. 

C A task can always be assigned to only one developer. 

D Any Customizing requires a Customizing request. 

3. Which statements are correct? 


A The transport of objects is divided into Export, Storage, 

and Import phases. 

B The import into the target system is performed 

automatically at midnight GreenwichMeanTime. 

C The transport directory is specified by parameter 

DIR_TRANS. 

D When transporting, the following rule applies: The target 

client is the same as the source client, unless otherwise 

specified. 



210 

Answers 

1. Which elements are part of the data structure of an SAP system? 

Answer: B, C, E 

The object repository, cross-client Customizing, and the clients are 

part of the data structure of an SAP system. The database structure is 

not part of the data structure; rather, it contains it. 

2. Decide which of the following statements are correct. 

Answer: B, C 

Entering customer data is not part of Customizing and therefore 

does not require a Customizing request. Only client-dependent 

Customizing requires a Customizing request; cross-client 

Customizing, on the other hand, requires a workbench request. 

A change request contains one or more tasks, each of which are 

assigned to only one developer. 

3. Which statements are correct? 

Answer: C, D 

The transport is divided into only two phases, Export and Import. 

The import into the database of the target system is never performed 

automatically. 


Unit 8 

211 Support Packages, Plug-Ins, and 

Add-Ons 

This unit explains what a Support Package is, what an Industry Solution 

is (as distinct from an Add-On), what a SPAM/SAINT is, and what the 

Note Assistant is. The topics of Support Packages and the SPAM/SAINT 

update are dealt with in more detail; there are exercises for each of these, 

in which the imports are practiced. 

In the theoretical part of the unit, the structure of a SAP Web AS 6.10 (and 

above) is first discussed, and then Support Packages, Industry Solutions, 

and SPAM/SAINT are explained (in that order). This order is useful for 

instructional reasons. However, the exercises deal first with the import 

of the SPAM/SAINT update (“like in real life”), then the import of two 

test Support Packages. Industry Solutions are only addressed in an 

explanatory manner. 

The Note Assistant and inactive import of report sources (see appendix) 

are not discussed in detail. These points should only be addressed briefly. 

Caution: The exercises have two problems. 

1. You must avoid both groups that work on one host performing their 

exercises at the same time, since the programtp cannotruninparallel 

due to the transport directory only existing once. Otherwise, the 

exercises will “hang”. 

2. A real SPAM/SAINT update is imported. This means that the 

instructor must ensure that there is also a newer SPAM/SAINT 

update in the additional files directory on the hosts than those that 

have already been imported into the system. In the worst-case 

scenario, the instructor must download a newer version from the 

SAP Service Marketplace and distribute it to all hosts for the course 

(using PCAnywhere, File Transfer). 


Unit 8: Support Packages, Plug-Ins, and Add-Ons ADM100 

Importing the two Basis Support Packages is not a problems, since they are 

not real Support Packages; that is, they can be imported at any time, since 

they do not have a predecessor relationship (except to each other). 

It is also possible to tell the SAP system that no SPAM/SAINT update 

has been imported yet: Transaction SEPS, Goto → Inbox, then select and 

delete all “SAPKD*” entries (column Subject) with status “N”. Also 

check whether the entries have been deleted from control table PAT03, 

otherwise delete them manually from PAT03. The entries at file system 

level (\usr\sap\trans\EPS\in) are not deleted here, and do not need to 

be deleted. This procedure should, however, not be used, since the title 

bar in transaction SPAM continue to display the actual imported version. 

Under no circumstances can you import an older SPAM/SAINT Update 

than one that was already imported. 

Unit Overview 

Basic terms such as Support Package andIndustrySolutionwillbe 

discussed in this unit. The system tools with which you can “import” 

these software components into the SAP system will also be addressed. 

You will be able to reinforce the knowledge that you have gained using 

practical exercises. 



• List the differences in principle between Support Packages, Plug-Ins, 

and Add-Ons 

• Import Support Packages with transaction SPAM 

• Install and update Industry Solutions with transaction SAINT 

• Update transactions SPAM and SAINT 

• Describe how to use the Note Assistant 

Unit Contents 

Lesson: Term Definition: Support Packages ................................249 

Lesson: Importing Support Packages........................................255 

Exercise 14: Import Support Packages..................................273 

Lesson: Updating the Tools....................................................279 

Exercise 15: SPAM Update ...............................................283 

Lesson: Importing SAP Notes.................................................287 


ADM100 Lesson: Term Definition: Support Packages 

Lesson: 

212 

Term Definition: Support Packages 



This lesson provides an introduction to the topics of Support Packages, 

Plug-Ins, and Add-Ons. 




and Add-Ons 

See the notes in the text 


After the installation of your SAP system, you want to import functional 

enhancements into your system, and correct errors that may occur. SAP 

makes Support Packages available for this purpose. 

Support Packages and Industry Solutions 

An SAP system consists of different software layers, also called software 

components. All of these layers are regularly updated using Support 

Packages; that is, errors are corrected and new functions are provided 

using Support Packages. 

The SAP system should always be kept at the current correction status so 

that errors in the standard release are preventatively removed. 

In addition to the standard functions in an SAP system, additional 

functions are sometimes required from an Industry Solution (IS). 



Figure 76: Which software components have Support Packages? 

If you have not already done so, you should introduce the new structure of 

SAP systems at this point. This is important to understand the different 

Support Packages. You should explain all of the areas illustrated in the 

figure. There are separate Support Packages for each area. Do not allow 

the participants to become confused: it is, of course, not possible to run 

APPL/HR and BW or another SAP solution simultaneously on the same 

SAP Web AS. Participants sometimes ask this, however. 

The following list contains the software components listed in the figure; 

each component has its own release cycle. Industry Solutions, Plug-Ins, 

and Enterprise Extensions are all Add-Ons. 

Enterprise Extension. These extensions of the functionally stabilized 

application components of SAP R/3 Enterprise are delivered as a complete 

set. Enterprise Extensions, Release 1.10, are first delivered with SAP R/3 

Enterprise, Core Release 4.7. “Core 4.7” means the functionally stabilized 

application components of SAP R/3 Enterprise. 

Industry Solution (IS). Industry Solutions are the technical software 

realization of industry-specific requirements. We strongly recommend 

against using multiple Industry Solutions within one SAP system, 

since these modify the SAP system in different ways. You can obtain 

approval from SAP for using two Industry Solutions together in certain 

circumstances. 

Plug-In (PI). An SAP R/3 Plug-In provides interfaces between a mySAP 

component (such as SAP CRM) and a standard SAP R/3 system. 



Core Application (APPL). This area contains software for all non-HR 

application components in SAP R/3. 

Human Resources (HR). This area contains software for HR applications 

in SAP R/3. 

Application Interface (ABA). This is special software for the basis area 

application interface. 

BASIS. ThisissoftwareforthebasisareainthestandardSAPR/3system 

and in the SAP Web Application Server. 

Business Information Warehouse (BW). Thisisupdatedsoftwarefor 

the SAP BW. 

Customer Relationship Management (CRM). Thisisupdatedsoftware 

for SAP CRM. 

Note that it is not possible to run APPL/HR and BW or other main 

components simultaneously on the same SAP Web Application Server 

(which consists of ABA and BASIS layers). 

Each component has its own queue of Support Packages. Explain all of 

these. So that the participants can understand the history, explain the 

Support Packages, Hot Packages, and Legal Change Packages of older 

release: what was the situation before SAP R/3 4.0, and for SAP R/3 

4.0/4.5/4.6? 

What Is a Support Package? 

A Support Package is a quantity of corrected SAP objects. Support 

Packages are required to correct errors in various components. This is done 

by replacing erroneous objects with corrected versions of these objects. 

Each software component has a separate sequence of Support Packages. 

The following list contains the technical names of a number of components 

and the notation for their Support Packages: 

• COP (Component Package): 

– SAP_APPL (SAP R/3 Support Package): SAPKH 

– SAP_BASIS (Basis Support Package): SAPKB 

– SAP_ABA (Application Interface SP): SAPKA 

– SAP_HR (SAP R/3 HR Support Package) : SAPKE 

– SAP_APO (APO Support Package): SAPKY 

– SAP_BW (BW Support Package): SAPKW 

– SAP_CRM (CRM Support Package): SAPKU 

– SAP_SRM (SRM Support Package): SAPKU 



– SAP_SEM (SEM-BW Support Package): SAPGKS 

• CRT (Conflict Resolution Package): Solves conflicts between Support 

Packages and Add-Ons (such as an Industry Solution); can also 

contain corrections for the Add-On. Either for each individual 

Support Package or as a collective CRT for a range of several Support 

Packages. SAPKI*, SAPKJ*, SAPKP*, SAPKG* 

• PAT: Provides new functions for transactions SPAM and SAINT. 

There is only one SPAM/SAINT update for each release, but in 

different versions. SAPKD 

The following no longer exist since SAP R/3 4.6: FFD: Final Delta Patch for 

First Customer Shipment (FCS), HOT: Hot Package, LCP: Legal Change 

Patch for HR, BWP: Business Information Warehouse Patch 




Keine moderierte Diskussion 









and Add-Ons 


ADM100 Lesson: Importing Support Packages 

Lesson: 

216 

Importing Support Packages 



In this lesson, you will learn about the tools with which Support Packages 

can be imported into your systems. These tools are also used to implement 

upgrades and installations of Industry Solutions. 





In this lesson, the transactions SPAM and SAINT are discussed in detail, 

and the former is demonstrated in the system. 


Importing Support Packages is a standard task of every SAP administrator. 

ThenewversionsofSAPobjectsintheSupportPackagesstabilizeand 

extend the functions of your SAP system. 

SPAM and SAINT 

An overview of the two transactions. What are they used for? What are 

the differences between them? Demonstrate both transactions briefly by 

calling them in the system. 

What is an Add-On in terms of transaction SAINT? “Add-On” never 

appears in the figures; rather, the Add-Ons concerned are always named, 

even if the collective term is often used in the notes “Add-On”. “Add-On” 

is the collective term for all bundles of functions that do not belong to the 

standard SAP system, and which can be subsequently installed, such as 

Industry Solutions, Plug-Ins, the SAP Solution Manager, and so on. 

In general, it is not possible to install more than one Industry Solution 

simultaneously, since there can be conflicts between the objects of the 

standard SAP system modified in each case. To use more than one Industry 

Solution simultaneously requires individual approval from SAP. In terms 

of transaction SAINT, installation and upgrade are almost identical. 



Other ways in which Add-Ons are imported “in the real world”: using 

transport requests, as “sealed” Support Packages, and so on. 

Figure 77: SPAM and SAINT 

Transaction SPAM allows you to import Support Packages. This applies 

for Support Packages for the standard SAP system, for Industry Solutions, 

and for CRTs. 

It is also only possible to import a SPAM/SAINT update using transaction 

SPAM. 

Transaction SAINT allows you to install and upgrade an Add-On, such 

as an Industry Solution, from the SAP system. To install or upgrade an 

Add-On, it can be necessary to import Add-On Support Packages and 

CRTs. Transaction SAINT deals with this. 

SPAM - Prerequisites and Settings 

The SAP system supports you when importing Support Packages. Specific 

transactions are used, depending on the software to be update; that is, 

whether it is the standard SAP system or Add-Ons and Industry Solutions. 

In terms of transaction SAINT, an Add-On is everything that does not 

belong to the standard SAP system. This includes, for example, Industry 

Solutions, Software Development Projects (SDPs), and Plug-Ins. 



You must take the following prerequisites and settings into account to 

import Support Packages with transaction SPAM: 

• The required Support Packages must be available. 

• There must be enough space in the file system. 

• The import should be performed during a time of low operation. 

• The newest SPAM/SAINT update is required. 

• TMS/CTS must be configured. 

• No aborted Support Packages in the system. 

• Client 000 for importing; in all other clients only a display function 

is available. 

• Use a user that has system authorizations for transaction SPAM. 

• Only the system administrator should have authorization to 

download and import Support Packages. The same applies for 

confirming successfully imported Support Packages and resetting 

the status of a Support Package. 

Note: You require the authorizations S_TRANSPRT and 

S_CTS_ADMIN to be able to run transaction SPAM. These 

authorizations are part of authorization profile S_A.SYSTEM. 

In the system, check that the transport tool is working correctly by 

choosing Utilities → Check Transport Tool. Ensure that there is enough space 

(size of the OCS files multiplied by 2) in the transport directory (see SAP 

profile parameter DIR_TRANS with transaction AL11 or transaction SA38 

and report RSPFPAR). You should especially ensure that there is enough 

space in the subdirectories trans/EPS/in and trans/data. 

Use the newest SPAM/SAINT update. Check whether the SPAM/SAINT 

update provided in the SAPNet - R/3 Frontend or on the SAP Service 

Marketplace is newer than the update in your system. (The version of the 

SPAM/SAINT update in your system is displayed in the title bar of the 

Support Package Manager.) 

There cannot be any incompletely imported Support Packages in your 

system.Under Directory, selecttheAborted Supp. Packages radio button, and 

choose Display. There must not be any Support Packages displayed. 



Figure 78: SPAM: Loading Support Packages 

Where can you obtain Support Packages? Explain that loading them from 

SAPNet - R/3 Frontend (previously OSS) no longer has any practical 

meaning, as almost all of the Support Packages as of SAP R/3 4.0 are “extra 

large” and therefore cannot be downloaded (they are locked in OSS). 

After the Support Packages have, for example, been loaded from the SAP 

ServiceMarketplace,theymustbeunpackedwithSAPCAR andplacedin 

the directory \usr\sap\trans\EPS\in. 

Thegraphicontherightofthefigureshowsthestepbeingdiscussedin 

chronological order. In the following figures, the section being discussed 

is always highlighted, to provide participants with an overview of the 

process. 

Before you can import Support Packages, you must first load the relevant 

Support Packages. SAP provides Support Packages in the SAPNet - R/3 

Frontend (previously OSS), on the SAP Service Marketplace, and on 

Collection CDs (not always absolutely up-to-date). 

SAPNet – R/3 Frontend: Before loading a Support Package from the 

SAPNet - R/3 Frontend, maintain the network parameters for logging on 

to the SAPNet - R/3 Frontend. Use transaction OSS1 to do this. 

1. Request the desired Support Packages in the SAPNet - R/3 Frontend. 



2. Load the requested Support Packages into your SAP system by 

choosing Support Packages → Load Packages → From SAPNet - R/3 

Frontend. 

Loading a Support Package from the SAP Service Marketplace or from CD: 

1. LoadtheSupportPackagesfromtheSAPServiceMarketplaceor 

from the relevant CD and decompress them. 

2. Now load the Support Packages into your system by choosing Support 

Package → Load Package → From application server. 

If the compressed files are on your front end server and are smaller than 

around 10 MB, you can transfer these files to the application server and 

decompress them directly from the Support Package Manager. 

1. Call the Support Package Manager with transaction code SPAM. 

2. Choose Support Package → Load Packages → From the Front end. 

3. To decompress the files in the archive, choose Decompress. 

Figure 79: SPAM: Settings 

Cover this section only briefly. The test scenario is the important point. 

Explain this in more detailed (experimental import, in particular to identify 

objects from the SPDD/SPAU adjustment in advance of the import). 

Transmission Monitor: Load the Support Packages with graphical 

monitoring. 



Import the the Support Package Queue: The standard scenario is used to 

import Support Packages completely; all steps are performed. In this case, 

as of SAP Web Application Server 6.10, you can select the setting Inactively 

Import Report Source Code in the standard scenario. You can use the test 

scenario to determine before the actual import of the Support Package 

whether a modification adjustment is required or whether conflicts occur 

that must be removed before the import. No data and objects are imported 

during the test scenario. 

Hint: As of SPAM version 6.10/0010 or 6.20/0010, there are new 

functions available for importing a defined queue: 

1. Start in Dialog Immediately or Continue in Dialog Immediately 

2. Start in Background Immediately or Continue in Background 

Immediately 

3. Start in Background Later or Continue in Background Later 

4. Continue Manually (only offered for subsequent steps after 

the step Preparation). 

For more information, choose the Changes button in transaction 

SPAM. The link to the Online Help, in particular, provides extensive 

documentation for the new functions. 

Caution: Ensure that you display the Online Help for the Changes 

at this point. 

Import Queue: Regenerate data file/Delete data file after import: If 

you are operating a multiple system landscape with a shared transport 

directory, it is sensible only to select this option in the first system in to 

which you import the Support Packages. This saves time when importing 

into other systems. 

ABAP/screen generation: Youusethisoptiontodefinewhetherthe 

programs and screens delivered with the Support Packages should be 

generated during the import. You have the following options: 

• Never Execute: With no automatic generation, the programs and 

screens are generated the first time they are called. 

• Always Execute: With this option, screens and programs are always 

generated. Note that generation can last a very long time, and that 

this may cause errors. 



• According to SAP Instructions: In this case, programs and screens are 

only generated if the generation during the import of these Support 

Packages is allowed by SAP. 

Figure 80: SPAM: Define and Import Queue 

Do not import ABA and Basis Support Packages simultaneously. Import as 

fewqueuesaspossible,andthereforequeuesthatareaslongaspossible,to 

minimize the number of required SPDD/SPAU adjustments. The “worst” 

aspect of importing Support Packages for customers is the SPDD/SPAU 

adjustment, and especially the subsequent testing that is required. It is 

therefore much better for the customer to import Support Packages 1 to 10 

in one queue (one adjustment), instead of one after other (10 adjustments). 

The notes must always be taken into account. These could explain, for 

example, that Support Packages of a certain type cannot be import at the 

same time in one queue, since certain problems would otherwise occur. For 

example, the customer wants to import Support Packages of a particular 

type, and to import numbers 10 to 30 there. Unfortunately, there is a note 

that state that importing Support Packages 25 and 26 together causes the 

import to terminate. The customer must therefore create two queues: one 

from 10 to 25, and the other from 26 to 30. This means that the import does 

not terminate, but there are two queues. Alternatively, the customer can 

import packages 10 to 30 in one and correct the problem that causes the 

termination manually. The notes that are displayed in the dialog box when 

importing the queue should be read for every import. 

Importing the Support Packages as a queue (other than during an upgrade 

or a new installation) contradicts, of course, the SAP recommendation to 

import the Support Packages as promptly as possible. In practice, the 



customer will find a compromise between the two approaches: importing 

Support Packages as promptly as possible, but also importing a number of 

packages at once, if possible. 

Explain that the logic of transaction SPAM (with the help of attributes in 

the headers of the Support Packages and using system information (tables 

PAT01, PAT03, AVERS)) means that it is almost impossible to import 

Support Packages in the “wrong” order, or to do something else “wrong”, 

such as “forgetting” individual packages or overlook the fact that there 

are Add-Ons in the system. SPAM is a very “safe” transaction, as far as 

possible operator’s errors are concerned. 

The Support Package Manager ensures that only Support Packages that 

match your system are displayed in the queue. Support Packages that are 

intended for a different release or an Industry Solution that is not installed 

do not appear in the queue, even if you have loaded them into your SAP 

system. 

Alternatively, you can compile a shared queue for all software components 

in the system, by choosing All Components. 

The queue contains the Support Packages available for the selected 

component(s) in your system and any required Conflict Resolution 

Transports (CRTs) and associated Industry Solution (IS) Support Packages. 

If Support Packages in the queue have connections to Support Packages 

for another software component (other predecessor relationship, required 

CRT), the queue is extended with other Support Packages until all 

predecessor relationships are fulfilled. 

Test scenario or standard scenario: To set the desired scenario, choose 

Extras → Settings. 



SPAM - Modification Adjustment 

Figure 81: SPAM: Performing the Modification Adjustment 

Why the modification adjustment is required: To retain customer 

modifications. It works in exactly the same was as during an upgrade. 

What must be adjusted? Regardless of whether the system has an Industry 

Solution or not: always the objects that the customer has modified and for 

which SAP is also delivering changes. 

1. The Support Package Manager stops to allow the modification 

adjustment (The Support Package Manager resumes processing at 

step RUN_SPAU or RUN_SPDD). 

2. So that your developers can perform the modification adjustment, 

create a request in the Transport Organizer and tasks under the 

request for the developers. 

3. Ask the developers to perform the modification adjustment for your 

objects. As long as you have not yet confirmed the installation, 

you can perform a context-sensitive switch to transaction SPDD or 

transaction SPAU from the initial screen of the Support Package 

Manager by choosing Extras → Adjust Modifications. Afterthe 

adjustment is complete, the developers must release the tasks and 

inform you. The adjustment can be performed in any client. 

4. If you left the transaction, call the Support Package Manager 

(transaction SPAM), and choose Support Package → Import Queue. The 

system prompts you again to perform the modification adjustment. 



As it has already been completed, ignore the message and choose 

Continue. The Support Package Manager completes the processing 

and displays the status. 

Figure 82: SPAM: Checking Logs and Confirming a Queue 

The Import logs of the queue function displays logs for steps of the Support 

Package Manager that use the transport control program tp. After the 

queue has been successfully imported, you should always check these 

logs. To jump to the log display, choose Goto → Log → Queue in the initial 

screen of the Support Package Manager. 

Confirm the successful import of the queue into your system. This ensures 

that you can import other Support Packages in future. Without this 

confirmation, it is not possible to import additional Support Packages. If 

you have not yet confirmed successfully imported Support Packages, you 

are prompted to confirm these packages during the upgrade of the system. 

The procedure for importing Support Packages into additional systems 

is described below: 

Prerequisites: 

1. The Support Packages were successfully imported into one system, 

usually the development system. 

2. You have performed the modification adjustment. 

3. The systems have a shared transport directory. 

Procedure: 



1. Load the Support Packages into the next system (quality assurance or 

production system). SPAM → Support Package → Load in the target 

system. 

2. Import the Support Packages in the usual way. 

3. Import the transport request that contains the modification 

adjustment. 

SAINT - Prerequisites and Settings 

Figure 83: What Is an Industry Solution? 

(See also the explanations for the figure “SPAM and SAINT” above). 

Explain the purpose of a CRT: It removes conflicts between standard 

SAP objects and the objects modified by the Add-On (like an automatic 

modification adjustment). 

Add-Ons are imported with transaction SAINT: In terms of transaction 

SAINT, an Add-On is everything that does not belong to the standard SAP 

system. This includes, for example, Industry Solutions, SDPs, IBUs, and 

Plug-Ins. For a complete list of the Industry Solutions currently offered by 

SAP, see http://www.sap.com/solutions/industry. 

A few examples of Industry Solutions: 

• mySAP Aerospace & Defense 

• mySAP Automotive 



• mySAP Banking 

• mySAP Consumer Products 

• mySAP Financial Service Provider 

• mySAP High Tech 

• mySAP Insurance 

• mySAP Mining 

• mySAP Oil & Gas 

• mySAP Pharmaceuticals 

• mySAP Public Sector 

• mySAP Telecommunications 

• mySAP Utilities 

You must take the following prerequisites and settings into account to 

import Add-Ons with transaction SAINT: 

• The required Industry Solutions, Support Packages, and CRTs must 

be available. 

• There must be enough space in the file system. 

• The import should be performed during a time of low operation. 

• The newest SPAM/SAINT update is required. 

• TMS/CTS must be configured. 

• No aborted Support Packages or IS in the system. 

• Use client 000 for importing; only a display function is available in 

all other clients. 

• System authorizations for SAINT. 

This and the following figures are structured in the same way as the 

Support Package figures. The only difference is that in some cases, two 

figures have been combined into one figure. These figures also have a 

figure on the right of the figure. The boxes are not equally distributed 

vertically so that you can see at a glance which steps for importing Support 

Packages do not exist in this context. 

Note: You require the authorizations S_TRANSPRT and 

S_CTS_ADMIN to be able to run SAINT. These authorizations are 

part of authorization profile S_A.SYSTEM. 

Hint: The procedures for an Add-On installation and an Add-On 

upgrade are identical. 



Figure 84: SAINT: Loading an Industry Solution and Settings 

Discuss these figures in the same way as the Support Package figures. 

It is not possible to perform a “test installation” or a “test upgrade”. 

Support Packages and CRTs are automatically imported as part of the 

process (they must, of course, be available at file level). 

No queue is defined. 

The same applies for the modification adjustment as for Support Packages: 

An adjustment is only necessary between customer and SAP modifications. 

The Industry Solution, Support Packages, and CRTs are also delivered 

by SAP. 

The packages are loaded in the same way as in transaction SPAM: 

Installation Package → Load Packages 

Settings are made in the same way as in transaction SPAM: Extras → 

Settings 



Figure 85: SAINT: Importing an Industry Solution 

In principle, transaction SAINT can process two different types of delivery 

packages; Add-On installations and Add-On upgrades. Technically, both 

of these packages are largely identical. They differ only in their import 

prerequisites and in the check for object conflicts with the SAP standard 

system. 

Hint: Ensure that you are working in client 000 and that you 

have loaded the relevant installation/upgrade packages into your 

system. 

SAINT - Modification Adjustment 

Figure 86: SAINT: Performing the Modification Adjustment 



You must only perform the modification adjustment for objects of the 

Add-On and its Support Packages. If you have modified SAP objects 

from the Add-On to be installed, you must adjust these objects during the 

import. (ABAP Dictionary objects are adjusted with transaction SPDD, 

Repository objects with transaction SPAU.) 

Procedure: 

1. Interrupt the import of the installation queue with F12. ((SAINT 

resumes processing at step RUN_SPAU or RUN_SPDD.) 

2. So that your developers can perform the modification adjustment, 

create a request in the Transport Organizer and tasks under the 

request for the developers. 

3. Ask the developers to perform the modification adjustment for your 

objects. As long as you have not yet confirmed the installation, 

you can choose Extras → Adjust Modifications on the initial screen 

of transaction SAINT to perform context-dependent switch to 

transaction SPDD or transaction SPAU. After the adjustment is 

complete, the developers must release the tasks and inform you. The 

adjustment can be performed in any client. 

4. After the adjustment is complete, call transaction SAINT. The system 

automatically displays the screen that was displayed before you 

interrupted the import. 

5. Choose Continue. The system prompts you again to perform the 

modification adjustment. As it has already been completed, ignore 

the message and choose Continue. SAINTcompletestheprocessing 

and displays the status. 

Figure 87: SAINT: Checking the Logs 



The Import Logs function (Goto → Import Logs) displayslogsforSAINT 

steps that use the transport control program tp. After the queue has been 

successfully imported, you should always check these logs. 

Caution: In the later phases of the import process, the database 

contents have already been changed. You should then continue 

the installation from here. 

Inactive Import 

Figure 88: Inactive Import 

Give a brief explanation, starting with: “The technical functionality is 

not especially important for you. Only for those that are interested. The 

resulting reduced “downtime” is more important.” Then briefly outline 

the technology; do not provide an example. 

Due to the size and scope of current Support Packages, importing Support 

Packages requires longer system downtime. The system is not stopped 

and restarted during the import process, but it should also not be used 

productively during this time. This restriction is a disadvantage for 

many production systems. To reduce the downtime during the import of 

Support Packages, an import procedure has been developed that allows 

you to import a large proportion of the objects to be imported during 

production operation. These objects are report sources and report texts. 

ThedowntimecanbesignificantlyreducedifaSupportPackagecontains 

a high proportion of report sources and report texts. (For SAP Basis/SAP 

Web AS and SAP R/3 Support Packages, the proportion is around 70-80%.) 



With the inactive import, the objects are imported into the database in an 

inactive state and are therefore largely "invisible" to the system. You can 

thereforecontinuetousethesystemproductively. 

The procedure is as follows (see also above figure): 

1. Import the report sources and report texts in an inactive state. Old 

versions that are still active and new, inactive versions exist in parallel 

in the database. 

2. Active sources and texts that are to be replaced or deleted are set 

to obsolete. 

3. Inactive sources and texts are set to active. 

Actions2and3mustbeperformedduringdowntime,butusually 

last less than ten minutes. 

4. Deletion of sources and texts markedasobsoletefromthedatabase. 

Actions 1 and 4, which require large data movements in the database, 

andarethereforeruntime-intensive,canbeperformedduringuptime. 





231 Exercise 14: Import Support Packages 






You need to import the most recent Support Packages to update your 

system. 

Task Import Support Packages 

Import two Basis Support Packages. 

This exercise must be performed first by the DEV group and then by the 

QAS group. 

In the first step, the Basis Support Packages 83 and 84 are imported 

in a queue into the SAP system DEV. After this import is successfully 

completed, the Basis Support Packages 83 and 84 are imported into the 

SAP system QAS. 

The files required for the Basis Support Packages have 

already been requested and are on your host in the directory 

G:\Additional_Files\ADM100\SupportPackages. 

1. Check whether Support Packages have already been imported into 

your system. Have these been confirmed? 

2. Unpack the files that contain the Basis Support Packages 83 and 84 

at operating system level. 

Remember that this step must only be performed once for each 

transport directory. 

Caution: On the training systems, these patches are called 

SAPKIXT083 and SAPKIXT084 instead of SAPKA50A83 and 

SAPKA50A84. This is only the case on this training systems 

for technical reasons. The normal naming conventions apply 

in “real” systems. 

3. Log on to the correct client. 




4. Load the Support Packages, that is, inform the SAP system about 

the files. 

5. Check the settings for the import of the Support Packages in 

transaction SPAM. 

6. Define the queue for importing Basis Support Packages 83 and 84 in 


7. Import the queue for Basis Support Packages 83 and 84 into your 

system. Note any possible errors. 

8. Check the log for the import process for errors. 

9. Confirm the imported Support Packages after successful import. 



Solution 14: Import Support Packages 

Task Import Support Packages 

Import two Basis Support Packages. 

This exercise must be performed first by the DEV group and then by the 

QAS group. 

In the first step, the Basis Support Packages 83 and 84 are imported 

in a queue into the SAP system DEV. After this import is successfully 

completed, the Basis Support Packages 83 and 84 are imported into the 

SAP system QAS. 

The files required for the Basis Support Packages have 

already been requested and are on your host in the directory 

G:\Additional_Files\ADM100\SupportPackages. 

1. Check whether Support Packages have already been imported into 

your system. Have these been confirmed? 

a) Transaction SPAM: Select the Imported Support Packages radio 

button and choose Display. 

Result: Support Packages have already been imported. They 

have also already been confirmed. You can tell this, for example, 

from the green traffic light in the bottom right-hand corner of the 

initial screen of transaction SPAM. 

2. Unpack the files that contain the Basis Support Packages 83 and 84 







Caution: On the training systems, these patches are called 

SAPKIXT083 and SAPKIXT084 instead of SAPKA50A83 and 

SAPKA50A84. This is only the case on this training systems 

for technical reasons. The normal naming conventions apply 

in “real” systems. 

a) Go to operating system level. Copy the files 

KIXT083.CAR and KIXT084.CAR from the directory 

G:\Additional_Files\ADM100\SupportPackages to the directory 

\usr\sap\trans. 

Open a Command Prompt at operating system level. Switch 

to the directory \usr\sap\trans and unpack the copied file 

with the commands sapcar -xvf KIXT083.CAR and sapcar -xvf 

KIXT084.CAR. This automatically unpacks the files in the 

directory \usr\sap\trans\EPS\in. 


a) Log on to client 000. It is only possible to import Support 

Packages from client 000. 

4. Load the Support Packages, that is, inform the SAP system about 

the files. 

a) Transaction SPAM: Support Package → Load Packages → From the 

Application Server 

Confirm the dialog box to upload. 

5. Check the settings for the import of the Support Packages in 


a) Transaction SPAM: Extras → Settings 

Leave the settings set to their default values. 

6. Define the queue for importing Basis Support Packages 83 and 84 in 


a) Transaction SPAM: Choose the Display/Define Queue button. 

Click SAP_BASIS, and choose the queue up to Basis Support 

Package 84 (the selection is already correct). 

You can Confirm Queue with Enter. 




7. Import the queue for Basis Support Packages 83 and 84 into your 

system. Note any possible errors. 

a) In transaction SPAM, import the queue by choosing Support 

Package → Import Queue. Confirm the dialog box to import. 

Follow the individual steps of the import process, as far as 

possible, in the status line. 

If errors occur, check these by opening the error log. Repeat 

the import of the Support Package. The import process can be 

repeated. 

Confirm the dialog box informing you that the import was 

successful. 


a) Check the import logs in transaction SPAM by choosing Goto 

→ Log → Queue. 

No returncodes > 8 should be displayed. 

9. Confirm the imported Support Packages after successful import. 

a) Finally, confirm the queue in transaction SPAM by choosing 

Support Package → Confirm 








ADM100 Lesson: Updating the Tools 

Lesson: 

237 

Updating the Tools 



In this lesson, you will learn what must be considered during a 

SPAM/SAINT update. An update of this type may be required before you 

can import new Support Packages. 




Ensure that there are no aborted Support Packages in the system. You 

may have to reset the relevant queue. 


Functional enhancements of the system can affect not only the applications, 

but also the tools with which you import the Support Packages. 

SPAM/SAINT Update 

Figure 89: Importing a SPAM/SAINT Update 



The SPAM/SAINT update is also explained at this point, after SPAM and 

SAINT have been introduced. Only after the participants are familiar 

with these two transactions can they understand why the transactions 

themselves require an update, and why this cannot be contained in a 

“normal” Support Package together with other corrections. This is because 

it would change the mechanism with which the Support Packages are 

imported, which is too dangerous. This also explains why transaction 

SPAM terminates after a SPAM/SAINT update is imported, and must 

be called again: it has replaced itself. Sometimes, it is vital to perform a 

SPAM/SAINT update before importing Support Packages (see notes). 

Why? For example, because a new SPAM is required to read new header 

information from the Support Packages. The SPAM/SAINT update also 

often contains optical changes to the transactions or new functions to make 

them more user-friendly. 

System Demo: Only as of this point can the you give a useful 

demonstration of what you have explained; that is, actually import a 

SPAM/SAINT update. After this, you should also import both of the 

“pseudo” Support Packages. 

Caution: This is the best time to perform the exercises. Note that 

it is not possible for both groups working on a host to perform 

the exercise at the same time. You should perhaps first send the 

QAS groups for a break and let the DEV groups perform the 

exercises, and then send the DEV groups for a break while the QAS 

groups perform the exercises. However, since it is only necessary 

to perform the work at file system level once, the second group 

should watch the first group perform this work before going for 

their break. 

You receive enhancements and improvements for SPAM and SAINT with 

a SPAM/SAINT Update. There is one update for each correction status, 

which is updated over time. You can find out the version from the short 

description, for example: SPAM/SAINT update - version /0001 

A SPAM/SAINT Update always appears first, for example in the SAPNet - 

R/3 Frontend in the Support Package list, that is, before the other Support 

Package types. 

We recommend that you always import the newest version of a 

SPAM/SAINT Update before you importotherSupportPackages. 

You can only import a SPAM/SAINT Update with the transaction SPAM. 



You can only successfully import a SPAM/SAINT Update if there are no 

aborted Support Packages in the system. If there are aborted Support 

Packages, a dialog box informs you of this. You then have two options: 

• You first import the complete queue and then the SPAM/SAINT 

update. 

• You reset the status of the queue, first import the SPAM/SAINT 

Update and then the queue. You can reset the status of the queue by 

choosing Extras → Reset Status → Queue. 

To import the newest SPAM/SAINT Update, choose Support Package 

Import → SPAM/SAINT Update. SPAM/SAINT updates are automatically 

confirmed after a successful import. 





239 Exercise 15: SPAM Update 




• Successfully perform a SPAM update 


Importing Support Packages often first requires an update of the system 

programs used to perform the import, so that all of the control information 

for the new Support Packages can be read. 

Task Import a SPAM Update 

Import a SPAM update 

Caution: This exercise must be performed by the DEV group first 

and then by the QAS group. 

In the first step, a SPAM update is imported into the SAP system DEV. 

After this import has been successfully completed, the SPAM update is 

imported into the SAP system QAS in a second step. 

The files required for the SPAM update have already been requested and are 

on your host in the directory G:\Additional_Files\ADM100\SPAMUpdate. 

1. Check whether a SPAM update has already been imported into your 

system. If yes: which version? 

2. Unpack the file that contains the SPAM update at operating system 

level. 




4. Load the patch using transaction SPAM; that is, inform the SAP 

system about the file. 

5. Import the SPAM update into your system. Note any possible errors. 




Solution 15: SPAM Update 

Task Import a SPAM Update 

Import a SPAM update 

Caution: This exercise must be performed by the DEV group first 

and then by the QAS group. 

In the first step, a SPAM update is imported into the SAP system DEV. 

After this import has been successfully completed, the SPAM update is 

imported into the SAP system QAS in a second step. 

The files required for the SPAM update have already been requested and are 

on your host in the directory G:\Additional_Files\ADM100\SPAMUpdate. 

1. Check whether a SPAM update has already been imported into your 

system. If yes: which version? 

a) Call transaction SPAM. The version of SPAM is displayed in 

the title bar, such as: “Support Package Manager - Version 

6.20/0000” 

To see whether SPAM updates have already been imported, 

select the Imported Support Packages radio button and choose 

Display. The system displays an overview of the previously 

imported SPAM updates. 

2. Unpack the file that contains the SPAM update at operating system 

level. 



a) Go to operating system level. Copy the file KD620.CAR 

from the directory G:\Additional_Files\ADM100\SPAMUpdate 

to the directory \usr\sap\trans. stands for the (newest) 

version of the SPAM update. 

Open a Command Prompt at operating system level. Switch to 

the directory \usr\sap\trans and unpack the copied file with the 

command “sapcar -xvf KD620.CAR”. This unpacks the file 

in the directory \usr\sap\trans\EPS\in. 


a) Logontoclient000. ItisonlypossibletoimporttheSPAM 

update from client 000. 




4. Load the patch using transaction SPAM; that is, inform the SAP 

system about the file. 

a) Transaction SPAM: Choose Support Package → Load Packages → 

From the Application Server. Confirm the dialog box to upload. 

5. Import the SPAM update into your system. Note any possible errors. 

a) In transaction SPAM, choose: Support Package → Import SPAM 

Update. Confirm the dialog box to import. Then call transaction 

SPAM again. This takes some time, as the system must 

regenerate the underlying programs and so on due to the SPAM 

update. 


a) In transaction SPAM, choose: Goto → Log → SPAM Update. No 

errors should be displayed. 







ADM100 Lesson: Importing SAP Notes 

Lesson: 

243 

Importing SAP Notes 



In this lesson, you will learn how to import preliminary corrections from 

SAP Notes using the Note Assistant. 




If you are very familiar with the topic, you can give a basic demonstrate 

SNOTE in the system, otherwise it is sufficient to discuss the figures. 


A current error correction that is not yet included in any Support Package 

is to be imported in accordance with a SAP Note. The administrator 

performs this correction using the Note Assistant. 

SAP Note Assistant 

Figure 90: Introduction to the Note Assistant: Functions 



Introduce the Note Assistant briefly. Biggest advantage: SAP preliminary 

corrections are no longer modifications. This means that no modification 

adjustment is required when importing Support Packages or during an 

upgrade. 

The Note Assistant also supports the user in the downloading from OSS. 

However, since this system is to be shut down shortly, you should not 

mention this fact unless you are asked about it. 

The Note Assistant allows you to automate, control, and document 

imports of SAP Notes from the SAP Service Marketplace. 

NotallSAPNotesaresuitablefortheNoteAssistant.Checkthisforeach 

case, especially for SAP Notes older than April 2001. The SAP Note 

must contain technical labels so that the Note Assistant can recognize the 

beginning and the end of the documentation and the ABAP coding in 

the SAP Note. 

The Note Assistant is also available for older SAP R/3 releases. For more 

information, see the SAP Service Marketplace, Quick Link /noteassistant. 

As of SAP Web AS 6.10, it is contained in the standard SAP system. 

The transaction for the Note Assistant is SNOTE. 

Figure 91: Introduction to the Note Assistant: Process 

The following conditions apply in the system for the Note Assistant: 



• The SSCR query does not apply for installations using the Note 

Assistant 

• The installation of changes is subject to the normal change recording 

• Changes are recorded in the Modification Assistant (only what was 

changed, not “how”) 

• There are two new logical transport objects: R3TR NOTE: SAP Note, 

R3TR CINS: Correction instructions 

• Changes are fully transportable, for example, to the quality assurance 

and production systems. 

Note: SAP Notes may not change DDIC objects. There is therefore 

no SPDD modification adjustment during an upgrade or when 

importing Support Packages. 















Unit Summary 



and Add-Ons 







247 


1. What are Support Packages and Add-Ons used for? 


A To enter user data. 

B To import SAP object to maintain the system with a current 

correction status. 

C To implement additional functions in the system. 

D To transport customer-developed programs. 

E To import preliminary corrections from SAP. 

2. Support Packages can be imported in any order. 


True 

False 

3. All SPAM/SAINT updates must always be imported. 


True 

False 

4. The queue for importing the SPAM update must be manually 

confirmed. 


True 

False 

5. A prerequisite for importing a SPAM/SAINT update is that there are 

no aborted Support Packages in the system. 


True 

False 

6. You use transaction SNOTE SNOTE to import individual SAP Notes. 

Using the Note Assistant means that you are not queried for an 

object key object key in the SAP Service Marketplace. SAP Notes that 

have been imported using the Note Note Assistant do not require a 

modification adjustment with transaction SPAU SPAU. 




248 

Answers 

1. What are Support Packages and Add-Ons used for? 

Answer: B, C 

Support Packages are not used to enter user data. Customer 

developments are transported to other systems using transport 

requests. Preliminary corrections are imported using the SAP Note 

Assistant. 

2. Support Packages can be imported in any order. 

Answer: False 

Support Packages must be imported in ascending order, without 

any gaps. 

3. All SPAM/SAINT updates must always be imported. 

Answer: False 

All associated programs are always upgraded during the 

SPAM/SAINT update. It is therefore not necessary to follow any 

particular order. 

4. ThequeueforimportingtheSPAMupdatemustbemanually 

confirmed. 

Answer: False 

It is not necessary either to define a special queue, nor to confirm 

this non-existent queue. 

5. A prerequisite for importing a SPAM/SAINT update is that there are 

no aborted Support Packages in the system. 

Answer: True 

This is true, there must not be any aborted Support Packages in the 

system. 



6. You use transaction SNOTE to import individual SAP Notes. Using 

the Note Assistant means that you are not queried for an object key in 

the SAP Service Marketplace. SAP Notes that have been imported 

using the Note Assistant do not require a modification adjustment 

with transaction SPAU. 

Answer: SNOTE, object key, Note, SPAU 

SNOTE is used to import individual SAP Notes, the modification 

adjustment is performed with SPAU. It is also not necessary to enter 

an SSCR key. 




Unit 9 

251 Scheduling Background Tasks 

All aspects of background processing are discussed in detail in this unit. 

Caution: The previous successor course BC305 contained a unit 

with advanced background processing topics. This course no 

longer exits. It was replaced by the new course ADM102. However, 

ADM102 does not contain a unit about background processing. 

All advanced background processing topics were integrated into 

ADM100 (in this unit). 

Unit Overview 

Thetopicsthatthisunitwilldealwitharethebasicsofbackground 

processing, and the scheduling and monitoring of jobs. You will also learn 

about special functions and extension options of background processing. 



• Describe the uses of background processing 

• Schedule and monitor jobs 

• Schedule time-dependent jobs 

• Schedule standard jobs 

• Schedule event-dependent jobs 

• Define and trigger events 

• Use additional, special functions of background processing 

• Describe how to extend job scheduling using Application 

Programming Interfaces 


Unit 9: Scheduling Background Tasks ADM100 

Unit Contents 

Lesson: Fundamentals of Background Processing.........................299 

Exercise 16: Fundamentals of Background Processing...............309 

Lesson: Time-Based Scheduling of Jobs....................................312 

Exercise 17: Time-Based Scheduling of Jobs ..........................317 

Lesson: Event-Based Scheduling of Jobs ...................................323 

Exercise 18: Event-Dependent Jobs.....................................327 

Lesson: Background Processing: Other Topics.............................333 

Exercise 19: External Program - External Command .................343 

Lesson: Job Scheduling: Extending the Standard .........................347 


ADM100 Lesson: Fundamentals of Background Processing 

Lesson: 

252 

Fundamentals of Background Processing 



In this lesson, you will learn about the basics of background processing. 





Hint: What is “background processing” actually? You can use this 

question as an introduction to the topic. 

Background processing should essentially separate long-running or 

periodic tasks from user interaction. Long-running tasks which would 

occupy a work process for a long time in dialog can be sequentially 

processed in the background without affecting the dialog performance. An 

important prerequisite for achieving this goal is an appropriate sizing 

of the system; that is, too many background work processes could end 

up competing with dialog work processes for shared resources (main 

memory, CPU). 


Reports to be run regularly and long-running programs are scheduled 

as background jobs in the SAP system. The administrator schedules 

background jobs and monitors the correct process of the system’s 

background processing. 

Basics 

Thefollowingquestionsareansweredinthecourseofthislesson: 

• Why do we need background processing? 

• What is a background job? 

• What can be performed in the background? 

• What start criteria are there? 

• How are jobs scheduled and monitored? 

• What status can a job have? 



Dialog work processes should be able to respond to end users’ requests 

quickly. Dialog resources should therefore not be burdened with 

long-running programs. This can lead to bottlenecks in the dialog response 

time. The system profile parameter rdisp/max_wprun_time exists for this 

reason. It limits the maximum runtime of a dialog step within a dialog 

work process. This should ensure that dialog work processes are not 

blocked by long-running programs, interfering with online operation. 

After the maximum runtime has elapsed, the program is terminated. 

Figure 92: Why Background Processing? 

You can use the background work processes for long-running tasks. These 

are sometimes also called “batch work processes”. 

Normally, background processing is used not only for long-running, but 

also for recurrent tasks. Examples of this type of task are the daily database 

backup or the month end work for financial accounting. 



Figure 93: What Is a Background Job? 

For this figure, it is important that you remember that the process sequence 

of background jobs (for available background work processes) is actually 

determined as follows: 

• Scheduled start time 

• Job class (A-C) 

• Target server specified or not 

If there are no free resources available for background processing at a 

certain time, but jobs are to be executed, jobs with a higher priority are 

processed before jobs with an earlier start time but lower priority. 

A background job consists of one or more steps (job steps). A step can be: 

• An ABAP program 

• An external command 

• An external program 

Every job is processed without interruption by one single background 

work process. 

Background jobs can be scheduled with different priorities: 

• Class A (highest priority) 

• Class B (medium priority) 



• Class C (normal priority) 

If a job should be executed on a particularserverorservergroup,it 

is handled preferentially compared to other jobs with the same class. 

This preference only applies if multiple jobs of various priorities request 

background processing at the same time, for example, because they are 

scheduledforthesametime. 

Hint: You should ensure that a large share of all background 

tasks are normally scheduled as class C without target server 

specification. This share can include 90% (or more) of all tasks. 

“System” background tasks are also executed in this way, such as 

the tasks that you schedule with transaction DB13. 

Figure 94: What Can Be Performed in the Background? 

Explain the differentiation between “external command” and “external 

program” by explaining that it is possible to perform an authorization 

check for external commands for the command name (defined only 

in the SAP system). For external programs, it is only possible to set a 

“permitted”/“not permitted” distinction. 

A step within a job can call one of the three actions shown: 

• EveryABAP program can be scheduled as a step of a job. If the ABAP 

program has one or more selection screens, you must create the input 

required there in advance in the form of a variant. A variant makes it 

possible to run an ABAP program in the background although the 



program requires input. The values stored in the variant are then 

used during the execution of the program. If an ABAP program has 

a screen output as its result, this is directed to a spool list. You can 

specify an (e-mail) recipient for this spool list during the definition of 

the job. This recipient then receives the output of the job by e-mail 

after the job has been run. You must also specify a printer for the 

creation of a spool list, although there is not necessarily any direct 

output to a printer as a result of background processing (this depends 

ontheprinter’saccessmethod).Thismayhavetobeexplicitlystarted 

later. 

• An external command is a call of a predefined script, a command, 

or a program outside the SAP system. With external commands, 

you can “mask” operating system calls and store them in the SAP 

system under a name. The execution of an external command can be 

protected using the SAP authorization concept, so that certain external 

commands can only be accessed by particular users in the system. 

• An external program is any operating system command. The SAP 

authorization concept only specifies whether a user can call external 

programs or not. A more detailed authorization assignment, for 

example at the level of program names, is not provided; use external 

commands for this. 

Figure 95: Start Criteria for a Background Job 

A job can be triggered: 

• By scheduling it on a particular date at a particular time (this includes 

the start time “immediately”, if there are no free background work 

processes available when the job is scheduled). 



• By the occurrence of a particular event defined in the SAP system (this 

includes jobs that are to start after other jobs or at operation mode 

changes, or jobs with “immediate start” if there are free background 

work processes available when the job is scheduled). 

Scheduling and Monitoring 

Demonstrate the scheduling (with immediate start) of a simple job (by all 

means also with a variant, such as the report RSPFPAR) using transaction 

SM36. The Job Wizard generates a problem, if you choose the Back button 

when creating a job with multiple steps. Recommend the Job Wizard only 

for scheduling simple jobs. 

Caution: In SM36, choosing the Save button schedules a job. 

Use the example of the job that you have just created to present transaction 

SM37. You should also mention the options for changing the layout here 

(the normal options for the ALV [SAP List Viewer]). 

Use transaction SM36 to define new jobs. You can also call the Job Wizard 

(transaction SM36WIZ) from here. 

Figure 96: Job Scheduling 

Required specifications when defining a job are: 

• General specifications such as job name,jobpriority(Default:“C”) 

and (optionally) target server (group) 



• Definition of one or more job steps 

• Definition of start conditions (time- or event-controlled) 

The Job Wizard supports you when defining jobs, by leading your through 

the individual steps listed above. 

However, with the Job Wizard - unlike with “classical” scheduling - you 

cannot perform individual steps with different users. 

Figure 97: Job Monitoring 

Use transaction SM37 to monitor jobs. 

You can select jobs using various criteria on the initial screen of this 

transaction. In this way, you can display all jobs that contain a particular 

job step, that have a particular status, or that react to a defined event (for 

this, you must select a particular event or “*”). 

You can navigate to other job-specific views from the job overview shown 

above: 

• The spool list contains the output lists for ABAP programs (if they 

exist). 

• The job details contain, among other information, the job definition, 

duration of the processing of the job, and the start time of the job. You 

can adjust the layout of the displayed list to your requirements by 

adding or removing additional fields. 



• All messages output by a background program are stored in the job 

log. You can display this log to obtain information about a program 

that terminated with errors or to perform a detailed investigation 

about a background processing run. 

Figure 98: Status of a Job 

Explain the different statuses of a job and what its status means with 

regard to the reusability of the job (changing, copying). In particular, 

terminated jobs should be carefully manually analyzed using the job log. 

Explain the importance of document with regard to “actions if a job is 

terminated”. This documentation can only be correctly created by the user 

that creates the job. 

A job can have the following statuses: 

Scheduled 

The steps of which the job consists have already been defined, 

however the start condition must still be defined. 

Released 

The job has been completed defined including its start condition. A job 

cannot be released without a start condition. Only an administrator 

or a user with the relevant authorizations for background processing 

can release a job. This ensures that unauthorized users cannot execute 

jobs without approval. 



Ready 

The start condition of a released job has been fulfilled. A job scheduler 

has placed the job in the wait queue for a free background work 

process. 

Active 

The job is currently being executed and cannot be deleted or changed. 

If an active job does not seem to be running correctly (that is, for 

example, it is running for an exceptionally long time), you can 

terminate it in a background work process in debugging mode, 

analyze it, and then either release it again or completely terminate it. 

To do this, in transaction SM37, choose Job → Capture: active job. 

Hint: To capture a background job, you must be logged on to 

the SAP server on which the job is running. 

Finished 

All steps of this job were successfully completed. 

Canceled 

The job terminated. This can happen in two ways: 

• An administrator deliberately terminates the job in transaction 

SM37 by choosing Job → Cancel active job. 

• A job step is terminated with an error. 

You can still change a job as long as the job still has the status Scheduled 

or Released. 

If the execution of the job has already begun, you can monitor the 

processing in the job log. If the job contains ABAP programs that create 

output lists, these are stored in spool lists. 

You can create a new job by copying an existing job by choosing Job → Copy. 





261 Exercise 16: Fundamentals of Background 

Processing 




• Determine the configuration of your SAP system with regard to 

background processing 


Reports to be run regularly and long-running programs are scheduled as 

background jobs in the system. The administrator schedules background 

jobs and monitors the correct process of the system’s background 

processing. 

Task Checking the Configuration 

Check the configuration of your SAP system with regard to background 

processing 

The following steps will make you familiar with the settings of the SAP 

system that are relevant for background processing: 

1. How many background processes are configured in your SAP system? 

2. What determines the number of available background work 

processes? 

3. How many background jobs can be processed simultaneously? 

4. Find out if background work processes are reserved for class A jobs 

in your system. 

5. Assume that all background work processes in your system are 

currently processing and there are therefore no free resources for 

other jobs. Can you set up additional background work processes 

without restarting the SAP system? 



Solution 16: Fundamentals of Background 

Processing 

Task Checking the Configuration 

Check the configuration of your SAP system with regard to background 

processing 

The following steps will make you familiar with the settings of the SAP 

system that are relevant for background processing: 

1. How many background processes are configured in your SAP system? 

a) Using transaction SM66, check the number of work processes of 

type BTC that you have (To do this, choose Select process and set 

the indicator Status → wait). 

2. What determines the number of available background work 

processes? 

a) The parameter rdisp/wp_no_btc initially specifies the number of 

available background work processes on the current instance. 

You can check the value of the parameter with either transaction 

RZ11 or the report RSPFPAR. 

If you have defined operation modes (transaction RZ04), this 

value can be overwritten. In this case, use the CCMS Control 

Panel (transaction RZ03) to specify the current operation mode. 

3. How many background jobs can be processed simultaneously? 

a) The SAP system process as many jobs concurrently as there are 

background work processes available. 

4. Find out if background work processes are reserved for class A jobs 

in your system. 

a) You can only check whether you have defined background work 

processes for jobs of job class A using transaction RZ04 (Maintain 

Operation Modes and Instances). Choose Instances/Operation 

Modes there and check column BPA. 

5. Assume that all background work processes in your system are 

currently processing and there are therefore no free resources for 

other jobs. Can you set up additional background work processes 

without restarting the SAP system? 

a) Using the concept of operation modes, you can define an 

operationmodewithadditionalbackground work processes in 

transaction RZ04. You can then perform a manual operation 

mode switch using transaction RZ03. You do not need to restart 

your system when doing this. 









– SAP Note 519059: FAQ: Background Processing System 

– SAP Note 25528: Parameter rdisp/max_wprun_time 



Lesson: 

264 

Time-Based Scheduling of Jobs 



In this lesson, you will learn about time-based scheduling of jobs. 





Introduce the parameter rdisp/btctime and its meaning (for example, using 

the report RSPFPAR). You can also use transaction SM36 to provide an 

overview of the different scheduling options for time-dependent starts. 

The time-dependent job scheduler (also known as the batch scheduler) 

becomes active every “btctime” seconds on each instance with at least 

onebackgroundworkprocess.Thisprocessreadsasmanyjobsasthere 

currently are free background work processes “on its instances” from the 

central scheduling table for background tasks. A certain time-dependent 

scheduler may always “reach the scheduling table” earlier than another 

due to a shorter “network route” if the clocks run identically on the 

different servers. This is not a problem. Since each time-dependent 

scheduler only takes the same number of jobs as it currently has free 

background work processes (and this is set by the correct sizing). It 

is therefore not possible for an instance to perform “too much” work. 

However, this does not ensure a proper equal division of the workload 

across the background resources. 

SinceSAPR/34.6C,transactionSM36providesasimpleoptionfor 

scheduling a large number of standard background jobs. It is therefore no 

longer necessary to manually schedule the tasks listed in SAP Note 16084. 


The administrator schedules background jobs and monitors the correct 

process of the system’s background processing. 


ADM100 Lesson: Time-Based Scheduling of Jobs 

Time-Based Scheduling 

Figure 99: Time-Dependent Start of a Job 

Caution: The “immediate” distribution to resources is not 

performed using the time-dependent scheduling table and the 

time-dependent scheduler. The job is entered only entered in the 

time-dependent scheduling table if there are no free background 

work processes available. 

A job can be started in a time- or event-dependent manner. 

In the case of a time-dependent start of a job, you can choose between 

the following options: 

• The job should be executed immediately 

• The job should be executed at a particular date/time 

• The job should be executed on a particular work day 

You can choose to make all time-based start conditions for jobs recurrent. 

This means that the job is executed again after a defined period of time 

has elapsed. You can specify exceptions (such as postponement to the 

following work day in the case of holidays in the factory calendar). 

The job is started at the specified date and time, in accordance with the job 

priority and availability of background work processes. 



You can also specify a time period during which the job should be executed. 

To do this, you specify a time after which the job should no longer be 

executed. With this function, you prevent periodic jobs being executed at 

an undesirable time, among other things. For example, a reorganization 

job that should only be executed at night is delayed. With a start time 

window, you can avoid this job being executed during the day, when the 

dialog users are active and there are fewer system resources available. 

Load Balancing 

The profile parameter rdisp/bctime specifies the time period in which the 

time-dependent job scheduler is active (see the next figure). The execution 

of jobs with the start condition immediate usually avoids the time-based 

scheduler. In this case, the dialog work process of the scheduling user 

performs the job scheduling. Only if no free resources are found, is the job 

concerned scheduled in a time-based way. The scheduled start time then 

corresponds to the time point at which it should have started. 

Figure 100: Scheduling Jobs and Load Balancing 

Background work processes can be configured on every instance of the 

SAP system using the profile parameter rdisp/wp_no_btc. 

The number of background work processes required in the SAP system 

depends on the number of tasks to be performed in the background. If the 

transport system is used, there must be at least two background work 

processes in the system. 



The combination of job ID and job name define the job uniquely in the 

system. 

On every SAP instance on which background work processes are defined, 

the time-dependent job scheduler runs every “rdisp/btctime” seconds 

(Default value: 60 seconds). This is an ABAP program (SAPMSSY2 - an 

“Auto ABAP”) that automatically runs in a dialog work process. 

The time-dependent job scheduler checks the job scheduling table in the 

database for jobs that are waiting for processing. These jobs are transferred 

to free background work processes in the SAP instance, in accordance with 

their priority and execution target. 

• Jobs that are not assigned any particular execution target can be 

executed with any free background work process. This means that 

the workload is automatically distributed between the SAP instances. 

• If a job is explicitly assigned an execution target (such as a selected 

instance or a group of instances), the special properties of the 

execution target can be used (for example, you can ensure that a 

job is performed on a particular operating system, or that the job is 

executed by a background work process that is running on the same 

host as the database). This means, however, that you do not have the 

advantages of automatic load balancing. 

Standard Jobs 

Standard jobs are background jobs that should run regularly in a 

production SAP system. These jobs mainly perform certain “clean up jobs” 

in the system, such as the deletion of obsolete spool requests. 



Figure 101: Scheduling Standard Jobs 

In the job definition transaction (SM36), you can access a selection of 

important standard jobs that you can schedule, monitor and edit by 

choosing Standard Jobs (see above figure). 

• If you want to schedule all standard jobs, choose Default Scheduling. 

All standard jobs that are defined in table REORGJOBS are scheduled 

with the specified variant and period. If other jobs exist that execute 

one of the programs of the standard jobs, the system informs you 

of this. 

• To schedule individual jobs, choose the selected job with the input 

help and specify an execution period. 

• To define an additional standard job that is not yet available in the 

selection (table REORGJOBS), choose Predefine new job. 



269 Exercise 17: Time-Based Scheduling of 

Jobs 








Task 1 Check Profile Parameter 

1. Check the frequency with which the time-dependent job scheduler 

runs. 

Task 2 Creating, Scheduling, and Monitoring a Job 

Schedule jobs and monitor their execution. Check the job results. 

1. Run report RSUSR000 in dialog (transaction SA38).). 

2. Run report RSUSR000 using transaction SA38 in the background 

(start time Execute immediately). 

3. In transaction SM36, define the job SIMPLE_##, where ## is your 

group number. The job should have the following properties: 

Job class C 

Consists of the ABAP program RSUSR000 as the only step 

Immediate start 

4. Check whether your job SIMPLE_## has run successfully. 

Find data that gives details about the start time, steps, and job details 

(such as client and user name). 

Is the spool list automatically printed? 

5. Determine the execution time of your job SIMPLE_## and find out 

whether it was executed with a delay. 




Task 3 Scheduling an ABAP Program with a Variant 

Schedule an ABAP program with a variant. 

1. Define the job DISP_PARA_##, where ## is your group number. The 

job should have the following properties: 

Job class C 

Execution of the report RSPFPAR with the variant DISPATCHER as its 

only step. 

Start in 2 minutes (referring to system time) 

Check whether the job was successfully processed. 



Solution 17: Time-Based Scheduling of 

Jobs 

Task 1 Check Profile Parameter 

1. Check the frequency with which the time-dependent job scheduler 

runs. 

a) Check the parameter rdisp/btctime. This parameter specifies the 

frequency with which the time-dependent job scheduler runs 

on your background server. You can check the value of the 

parameter with either transaction RZ11 or the report RSPFPAR. 

Task 2 Creating, Scheduling, and Monitoring a Job 

Schedule jobs and monitor their execution. Check the job results. 

1. Run report RSUSR000 in dialog (transaction SA38).). 

a) Select the report RSUSR000 on the initial screen of transaction 

SA38, and choose Execute. 

2. Run report RSUSR000 using transaction SA38 in the background 

(start time Execute immediately). 

a) Select the report RSUSR000 in the initial screen of transaction 

SA38 and choose Background. On the next screen, choose Execute 

Immed. To check the job status and the spool list for this job, 

choose Job Overview. The system displays the initial screen of 

transaction SM37, on which you can display the results of your 

job (Execute button). 

3. In transaction SM36, define the job SIMPLE_##, where ## is your 

group number. The job should have the following properties: 

Job class C 

Consists of the ABAP program RSUSR000 as the only step 


a) In transaction SM36, enter the job name SIMPLE_##, selectjob 

class C and leave the Execution target field empty. Choose Step. 

On the following screen, choose ABAP Program and enter the 

ABAP program name RSUSR000. Saveyourstep.Thenchoose 

Start Condition. ChooseImmediately and save the start time 

values. Then save your job. The system displays a message in 

the status line that your job was saved with the status: released. 




4. Check whether your job SIMPLE_## has run successfully. 

Find data that gives details about the start time, steps, and job details 

(such as client and user name). 

Is the spool list automatically printed? 

a) Use transaction SM37 to check the status of your job, and choose 

Execute on the initial screen. To analyze job details, double click 

the job and choose Job Details. The details include, for example, 

the client, the job ID number, the user that scheduled, changed, 

and released the job, and the work process that executed the job. 

To view the individual steps of the job, choose Step. 

Spool lists are only created for job steps that contain ABAP 

programs with output. They are only printed immediately if 

you have made the corresponding setting in the printer settings 

during the definition of the job step or in your user defaults. 

5. Determine the execution time of your job SIMPLE_## and find out 

whether it was executed with a delay. 

a) You can display the duration of your job in transaction SM37 (see 

solution to exercise 4). You can also see here whether your job 

was started with a delay (caused, for example, by a high load 

on your system or due to the fact that the time-dependent job 

scheduler runs periodically). 

Task 3 Scheduling an ABAP Program with a Variant 

Schedule an ABAP program with a variant. 

1. Define the job DISP_PARA_##, where ## is your group number. The 

job should have the following properties: 

Job class C 

Execution of the report RSPFPAR with the variant DISPATCHER as its 

only step. 






a) In transaction SM36, enter the job name DISP_PARA_##, select 

job class C and leave the execution target field empty. 

Choose Step. On the following screen, choose ABAP Program 

and enter the ABAP program name RSPFPAR and the variant 

DISPATCHER. Saveyourstep. 

Return to the initial screen of the transaction and choose 

Start Condition. Choose Date/Time and enter a time that is 

approximately two minutes in the future and save the start time 



Then check in transaction SM37 whether your job was 

successfully processed. 








• For more detailed information about standard jobs, see SAP Note 

16083. 


ADM100 Lesson: Event-Based Scheduling of Jobs 

Lesson: 

275 

Event-Based Scheduling of Jobs 



In this lesson, you will learn about event-based scheduling of jobs. 





Briefly introduce the different event-dependent scheduling options. 

Explain the meaning of the parameter rdisp/btcname, and why it should, if 

possible, point to a high-availability instance, that is, the central instance. 

Demonstrate transactions SM62 and SM64 in the system, and, if 

appropriate, you can also display the listed function modules. Create an 

event with or without parameters, and schedule a job for this event. Trigger 

the event, and use transaction SM37 to check the execution of the job. 




Event-Based Scheduling 

An event is a signal to the background processing system that a particular 

status has been achieved in the SAP system. The background processing 

system receives events and then starts all jobs that are linked to this event. 



Figure 102: Event-Dependent Start of a Job 

An application server is specified for the processing of events that are 

triggered within the SAP system in profile parameter rdisp/btcname. 

An event-dependent job scheduler is started on this server (unlike the 

time-dependent job scheduler, which runs periodically on all background 

servers). This scheduler checks whether a job is waiting for the event 

that has been received. It is therefore important that the parameter 

rdisp/btcname contains the name of an active background server. 

Event-dependent jobs can be scheduled with one of the following three 

start conditions: 

After event 

The job starts after a defined event is received by the SAP system. 

At operation mode 

With this option, you can link a job to the activation of an operation 

mode when scheduling the job. 

After job 

In this way, you can create simple job chains in which the execution 

of the successor job can be made dependent on the status of the 

predecessor job. 



Events 

New events are defined by the system administrator in CCMS (transaction 

SM62). When doing so, the administrator differentiates between system 

events and user events. System events are events predefined by SAP that 

you can neither modify nor trigger. 

Figure 103: Definition and Triggering of Events 

Events can be triggered in various ways: 

• Manually in CCMS for test purposes (transaction SM64) 

• Within an ABAP program (through use of the function module 

BP_EVENT_RAISE) 

• Outside the SAP system at operating system level using the program 

sapevt. 

A parameter can also be transferred when an event is triggered. In this 

way, you can define jobs that wait for the occurrence of the event together 

with the specified parameter. 

The syntax for the program sapevt is: 

sapevt [-p ] [-t] [pf=] 

| [name=] [nr=] 

Name of the event, as defined in the CCMS (required) 

specified parameter (optional) 

-t generates a trace file called dev_evt in the directory from which 

sapevt was called. If sapevt discovers problems, you can find out 

about these in this trace file (optional) 



Path name of the profile (optional) 

If no profile name is specified, the following parameters must be 

specified: 

SAP system name (optional) 

Instance number of the SAP system (optional) 

For example: sapevt MYEVENT name=DEV nr=00. 

To be able to react to external events, the SAP system must be active. 

Otherwise an event triggered by an external program is lost. 



279 Exercise 18: Event-Dependent Jobs 









Task 1 Event-Dependent Jobs 

Define a user-defined event and then schedule a job that starts after this 

event occurs. Trigger the event in the Computing Center Management 

System (CCMS) and from operating system level. 

1. Define the user-defined event MYEVENT_## in the CCMS. 

2. Define a job EVENT_##. The job should have the following properties: 

Job class C 

Step 1 Execution of ABAP program RSUSR000 

Starts after the event MYEVENT_## (event-periodic) 

Display your job in the job overview. 

3. Trigger the event MYEVENT_## in the CCMS in another session and 

refresh the job overview. 

4. Trigger the event MYEVENT_## at operating system level and refresh 

the job overview. 

Task 2 Defining Job Chains (Optional) 

Define a job that depends on the job in exercise 1. 

1. Define the job SUCCESSOR_## (where ## is your group number), 

with the following properties: 

Job class C 

Execution of ABAP program RSUSR000 

Start after the job from exercise 1 has been successfully completed 




Check the job status in the job overview. 

2. What must you do so that the job SUCCESSOR_## is executed? 



Solution 18: Event-Dependent Jobs 

Task 1 Event-Dependent Jobs 

Define a user-defined event and then schedule a job that starts after this 

event occurs. Trigger the event in the Computing Center Management 

System (CCMS) and from operating system level. 

1. Define the user-defined event MYEVENT_## in the CCMS. 

a) In the SAP Easy Access Menu, choose Tools → CCMS → Jobs → 

Maintain Event (transaction SM62). Do not change any System 

events. Choose Maintain under User event names, and choose 

Enter. Choose Create. Enter the event description MYEVENT_## 

(where ## is your group number) and a description of the event, 

and then choose Save. 

2. Define a job EVENT_##. The job should have the following properties: 

Job class C 

Step 1 Execution of ABAP program RSUSR000 

Starts after the event MYEVENT_## (event-periodic) 

Display your job in the job overview. 

a) In transaction SM36, enter the job name EVENT_## (where ## is 

your group number), select job class C and leave the execution 

target empty. 

Choose Step. On the following screen, choose ABAP Program and 

enter the ABAP program name RSUSR000. 

Save your step. 

Choose Start Condition. 

Choose After Event, enter the event MYEVENT_## without other 

parameters, set the flag Periodic job and save the start time values. 

Then save your job. The system displays a message in the status 

line that your job was saved with the status: released. 

Use transaction SM37 to check whether your job was successfully 

processed. To do this, you must make an appropriate selection 

on the initial screen of SM37 under the Job Start Condition in the 

field or after event (such as “*”). 




3. Trigger the event MYEVENT_## in the CCMS in another session and 

refresh the job overview. 

a) In the SAP Easy Access Menu, choose Tools → CCMS → Jobs → 

Trigger Event (transaction SM64). 

Select your event and trigger it without additional parameters. 

If you refresh the job overview in transaction SM37, you can 

see that your job has been processed (status finished) andhas 

scheduled itself again (status released). 

4. Trigger the event MYEVENT_## at operating system level and refresh 

the job overview. 

a) Run the command sapevt MYEVENT_## name= 

nr= at operating system level of your application server. If 

you refresh the job overview in transaction SM37 again, you can 

see that your job has been processed again (status finished) and 

has scheduled itself again (status released). 

Task 2 Defining Job Chains (Optional) 

Define a job that depends on the job in exercise 1. 

1. Define the job SUCCESSOR_## (where ## is your group number), 

with the following properties: 

Job class C 

Execution of ABAP program RSUSR000 

Start after the job from exercise 1 has been successfully completed 




Check the job status in the job overview. 

a) In transaction SM36, enter the job name SUCCESSOR_##, select 

job class C and leave the execution target field empty. 

Choose Step. On the following screen, choose ABAP Program and 

enter the ABAP program name RSURS000 without a variant. 

Save your step. 

Choose Start Condition. ChooseAfter job, enterthepredecessor 

job EVENT_##, and choose Start status-dependent. Saveyour 

start time values. Then save your job. The system displays a 

message in the status line that your job was saved with the 

status: released. 


processed. To ensure that your job is also displayed in the job 

overview, choose Extended Job Selection on the initial screen 

of transaction SM37. On the following screen, select your 

predecessor job (or “*”) in the field or start after job on the Start 

condition tab page and choose Execute. 

2. What must you do so that the job SUCCESSOR_## is executed? 

a) Trigger the event MYEVENT_## in another session, in the 

same way as with exercise 1. Check that your job chain was 

successfully executed by refreshing the job overview. 








ADM100 Lesson: Background Processing: Other Topics 

Lesson: 

284 

Background Processing: Other Topics 



In this lesson, you will learn about other, special functions for background 

processing. 




This lesson addresses “advanced” background processing topics. The 

prerequisite for understanding and using the topics is a good grounding in 

the basics of background processing. 

See the additional notes in the individual sections. 


You want to use the background processing resources more efficiently. 

Reservation for Class “A” Jobs 

Use the example in the training material to explain why the background 

performance of the SAP system can become dramatically worse when 

“reservation” is used. Extreme example: During a 10 hour night, ten 

background work processes of a system should perform work with a scope 

of 70 hours (of which 65 hours are class “C” tasks). This would meant that 

70% of the background resources were used. However, if five of the ten 

background work processes were now reserved for class “A” jobs, there 

wouldonlybe50“classChours”availablefortherequired65“classC 

hours”. The consequence: unprocessed background tasks in the morning. 

In normal operation, every background work process processes jobs of 

every priority. 

You can, however, reserve as many of the configured background work 

processes as desired for high priority jobs; that is, class “A” jobs. The 

reservation of work processes for class “A” jobs does not reserve any 

particular work processes. Rather it ensures that a particular number of 



work processes is always kept free. Jobs of job classes “B” and “C” can 

only be started if the defined number of work processes remains free for 

possible class “A” jobs. 

Figure 104: Reservation for Class “A” Jobs 

To set the number of reserved background work processes for class “A”, 

you can define an operation mode in transaction RZ04 (maintenance of 

operation modes and instances) and maintain the work process allocation 

for this operation mode. When doing so, you have the option of reserving 

work processes. 

If the class “A” workload is small, or bottlenecks rarely occur in 

background processing - in other words, at least one background work 

processisusuallyfree-thereservationofaworkprocessforclass“A”jobs 

probably provides no advantages. In this case, reservation will simply 

mean that a work process is seldom used. 

We strongly recommend that you do not reserve more than one background 

work process for processing class “A” jobs. It is usually sufficient to 

reserve one background work process for processing class “A” jobs. 



Execution Targets 

Together with the participants, work out cases in which assigning a job to 

a specific server or a particular server group (cross-reference: possible to 

map logon groups) can be useful (data that is only available there – at 

operating system level, or for other reasons), and why this restriction can 

lead to reduced background performance, that is, why it is a resource that 

should be used sparingly. 

Only instances with background work processes or a “job server group” 

can be used for the targeted scheduling of a background task. 

A job server group contains one or more instances with available 

background work processes. Groups of this type can be used in the 

same way as logon groups for dialog users. It is also possible to process 

background tasks from different applications on selected instances. 

Figure 105: Execution Targets and Job Server Groups 

You can set up a job server group in transaction SM61 (Path: Tools → CCMS 

→ Jobs → Background Objects). To do this, call the transaction and then 

choose the Job Server Groups. Youcanthendefineyourjobservergroup 

and assign your instances. 



Background Users 

A background user is primarily used if, for example, you want to ensure 

that an employee’s jobs continue to be run, although the employee has 

changed area, and therefore no longer has dialog authorizations to execute 

the tasks scheduled in the background. Authorization checks at the job 

start are performed on the “background user”. Note that the background 

user does not need to be a dialog user, and that a small number of users 

of this type can be sufficient for a user department, for example. These 

are shared. 

With the “classic” definition of jobs using transaction SM36, you can assign 

each step of the job to a user (see the figure). The specified user is used for 

the authorization checks during the execution of the step. By default, the 

name of the logged-on user appears in this field, and your job is performed 

using your authorizations. Enter a different user name, if your job should 

not be performed using your own authorizations. To be able to do this, 

you must, however, have the appropriate authorization (authorization 

S_BTCH_NAM) to enter names other than your own in the User field. 

Figure 106: Background Users 

It is useful to set up “background users” for various work areas that have 

the necessary authorizations for the required activities, and that can be 

used by users with the same authorizations to schedule background tasks 

in this work area (such as for system administration). Background users 

have user master records that are specifically intended for background 

processing authorizations. 



Use the System user type when creating background users. A dialog 

logon with a user of this type is not possible. In the same way, users of 

this type are excepted from the usual settings for the validity period of a 

password. The password can only be changed by user administrators with 

transaction SU01 (User → Change Password). 

The name of the logged-on user is always used for the authorization check 

when a job is defined using the Job Wizard. 

Use of External Programs 

External programs are started using “intermediary program” at operating 

system level, the program sapxpg. This program runs using the 

authorizations of the SAP system operating system user. 

In transaction SM69, demonstrate creating an external command. The 

command ZPING could be a simple command, which simply calls the 

ping command at operating system level. Do not specify any additional 

parameters. Use transaction SM49 to test your external command and 

note the return message from the operating system. Note the appropriate 

parameters and change your external command in such a way that another 

training server receives five pings. View the return message again and 

schedule a job dependent upon a self-defined event. 

The background processing system differentiates between external 

commands for normal users and external programs for system 

administrators. The purpose of this differentiation is to give system 

administrators the ability to run any required external program, while 

normal users are restricted to external commands for which there are 

authorization checks. In both cases, the program sapxpg is called at 

operating system level. sapxpg then starts the relevant program at 

operating system level. 



Figure 107: Using External Programs 

External commands are host system commands or programs predefined in 

the SAP system by an administrator. They are protected by authorizations 

so that normal users can only schedule the commands for which the 

system administrator has assigned them the authorization. You can 

therefore provide functions outside the SAP system, at operating system 

level, for users of the SAP system. 

External programs are unrestricted commands that are neither predefined 

nor restricted by authorizations. A user with administration authorization 

can enter any external program in a job step. No SAP authorization check 

is performed before the execution of the command. External programs 

provide an administrator (user with administration authorization for 

external commands (Authorization object S_RZL_ADM: Background 

Processing: Background Administrator)) the flexibility to run any 

required host system command in the SAP system without administrative 

preparation. 



Figure 108: Definition and Use of External Commands 

The creation of external command requires the following steps: 

1. Call transaction SM69 (Tools → CCMS → Configuration → External 

Commands). 

2. Choose Display/Change and then the Create button. 

3. Enter a name for your command. External commands are uniquely 

identified with a name (beginning with Y or Z) and an operating 

system type. The Type field is filled automatically. 

4. Specify an executable operating system command (if required with 

the complete path) and specify any additional required or optional 

parameters. 

5. Select the Additional parameters allowed fieldifusersmayspecify 

additional parameters when they schedule the command in a 

background job. The additional parameters are added in parameter 

strings specified under Parameters for Operating System Command. 

6. The Trace field should usually be left blank. To follow the execution 

of an external command, use the trace parameter for the function 

module SXPG_COMMAND_EXECUTE. 

7. If you have defined an additional authorization check, enter the 

name of the function module that performs the check under 

Check Module, usually a customer copy of the function module 



SXPG_DUMMY_COMMAND_CHECK. The system automatically 

calls the function module if a user tries to schedule the external 

command in a background job. 

8. Save the external command both in the screen shown above and in 

the initial screen of transaction SM69. 

Control Flags 

When scheduling an external command (such as ZPING), ensure that the 

operating system’s return message is transferred to the job log. A spool 

list can only be created for ABAP programs that generate lists. Use an 

example to explain the effect of the setting Job waiting for ext. termination. 

You do not need to explain the job trace here. For more information, see 

the documentation. 

You can make specifications about the task and other runtime options 

using control flags. You do not normally need to change the default values. 

Figure 109: Control Flags for External Programs/Commands 

You can, for example, specify: 

• Whether the process is to be logged. The output data is written to 

the log as it is output by the external program. The language can 

differ here from your logon language. You can also call additional 

information about the data of an external program in the job log. 

• How the SAP control program should end and whether the external 

program triggers an event. After you have started service programs 

with the background processing system (such as daemons in UNIX 



systems), they remain active after the start. They are not ended and 

do not return to the SAP background processing system, as is the 

case with other programs. If you start a service program, you should 

not use the control flag setting Job waiting for ext. termination when 

scheduling the job. 

You can display additional information about the meaning of the control 

flags using the F1 field help on the Edit Control Flags for External Programs 

screen. 





291 Exercise 19: External Program - External 

Command 




• Schedule external commands and external programs as jobs 


Task 1 Schedule an External Program 

Schedule an external program. 

1. DefinethejobWHOAMI_##,where##isyourgroupnumber.Thejob 

should have the following properties: 

Job class C 

Execution of the external program whoami (check the control flags 

for this) 



Task 2 External Command (Optional) 

Schedule a job that executes an external command as a job step. 

1. Display a list of external commands. What does the command 

ZKERNEL do? 

2. Define a job EXTERNAL_##. The job should have the following 

properties: 

Job class C 

Execution of the external command ZKERNEL. 


Display the job in the job overview and view the job log. 



Solution 19: External Program - External 

Command 

Task 1 Schedule an External Program 

Schedule an external program. 

1. Define the job WHOAMI_##, where ## is your group number. The job 

should have the following properties: 

Job class C 

Execution of the external program whoami (check the control flags 

for this) 



a) In transaction SM36, enter the job name WHOAMI_##, selectjob 

class C and leave the execution target field empty. 

Choose Step. On the next screen, choose External Program and 

enter the program name whoami without parameters. Enter the 

name of your own host as the target host. Check the Control 

flags and save the default values. Save your step. 

Return to the initial screen of the transaction and choose 

Start Condition. ChooseDate/Time and enter a time that is 

approximately two minutes in the future and save the start time 



Check in transaction SM37 whether your job was successfully 

processed. To do this, display the job log for the job. 

Task 2 External Command (Optional) 

Schedule a job that executes an external command as a job step. 

1. Display a list of external commands. What does the command 

ZKERNEL do? 

a) To display a list of external commands, choose Tools → CCMS → 

Jobs → External Commands (transaction SM49) from the SAP Easy 

Access menu. ). To execute a command from this list, select the 

command, and choose Execute. On the following screen, you can 

specify a target host. Choose Execute again. 

The external command ZKERNEL displays information about 

the kernel (disp+work). 




2. Define a job EXTERNAL_##. The job should have the following 

properties: 

Job class C 

Execution of the external command ZKERNEL. 


Display the job in the job overview and view the job log. 

a) In transaction SM36, enter the job name EXTERNAL_## (where 

## is your group number), select job class C and leave the 

execution target empty. 

Choose Step. On the following screen, choose External Command 

and enter the name ZKERNEL with no other parameters. 

Select an operating system using the F4 help and specify your 

own host as the target host. Save your step. 

Choose Start Condition. 

Choose Immediately and save the start time values. Then save 

your job. The system displays a message in the status line that 

your job was saved with the status: released. 


scheduled and executed. 

Display the job log for the job. 








– SAP Note 24092: Distribution of background jobs on application 

server 

– SAP Note 101146: Batch: Authorization object S_BTCH_JOB, 

S_BTCH_NAM 


ADM100 Lesson: Job Scheduling: Extending the Standard 

Lesson: 

295 

Job Scheduling: Extending the Standard 



In this lesson, you learn about the resources with which you can extend 

the standard functions for job scheduling. 





Using the function modules in SAP systems, it is simple to create and 

control even complex background scenarios, such as a job waiting for the 

successful completion of multiple other jobs, scheduling periodic job 

chains, and so on. 

The interface XBP-API is also used by third party products. You can refer 

the participants to the key term SAP “software partners” here. 


You want to extend the standard functions available for background 

processing in the SAP system. 

Extending the Standard 

The job scheduling options described in the previous lessons do not cover 

all possible requirements. You can implement more complex scenarios in 

the following ways: 

The SAP system has various internal function modules that support you 

when defining your own job processes. These function modules are in the 

function groups BTCH and BTC2. You can define any complex scenarios 

with the help of these function modules. 

SAP provides a set of interfaces that allow the connection of other system 

management environments to the SAP Computing Center Management 

System (CCMS): 

• The eXternal Monitoring Interface API (XMI-API) interface logs the 

activities of external users and programs. 

• The eXternal interface for Background Processing (XBP-API) interface 

allows the use of external job scheduling programs. 



With these tools, you can schedule background jobs beyond the boundaries 

of the SAP system and include non-SAP systems. 

Figure 110: Extending the Standard 

For a list of certified solutions, see the the software category Job Scheduling 

in the Software Partner Directory. 


ADM100 Lesson: Job Scheduling: Extending the Standard 














Unit Summary 















299 


1. A background job contains one or more steps steps. AnABAP 

program or an external external command or program can be 

executed in a step step of this type. A job can be triggered at a 

particular time time or when a defined event event occurs. 


2. What status can a job have? 


A Running 

B Released 

C Waiting 

D Finished 

E Error 

F Active 

3. Which of the listed options for time-dependent scheduling of a job 

can be implemented with the standard resources of the SAP system? 


A Daily at 1500 

B The second-last working day of every month 

C Every nine days, but not on Sundays 

D Only tomorrow at 2355 

E Every year on April 1 at 0800 

4. Which of the listed options for event-dependent scheduling of a job 



A Whenever the system switches to the Night operation mode 

B After the job Job1 has run successfully 

C Whenever a particular event has been triggered 

D Whenever the periodic job Job2 has run successfully 



5. If one of the system’s ten background work processes is reserved for 

class A jobs, and jobs are being processed in the other nine work 

processes, the reserved work process remains free even if a class A job 

is waiting for execution. 


True 

False 

6. If a user has authorization to schedule an external program as a step of 

a background job, he or she can run any operating system command. 


True 

False 



301 

Answers 

1. A background job contains one or more steps. An ABAP program or 

an external command or program can be executed in a step of this 

type. A job can be triggered at a particular time or when a defined 

event occurs. 

Answer: steps, external, step, time, event 

After the job is triggered, it is processed without interruption by a 

single background work process. 

2. What status can a job have? 

Answer: B, D, F 

In addition to the three correct answers, a job could have the status 

Scheduled, Ready, orCanceled. 

3. Which of the listed options for time-dependent scheduling of a job 


Answer: A, B, C, D, E 

All of the options listed can be realized by default. 

4. Which of the listed options for event-dependent scheduling of a job 


Answer: A, B, C 

Option D cannot be realized in the standard system. However, 

you can implement this as one of many additional possibilities by 

extending the standard system using function modules. 

5. If one of the system’s ten background work processes is reserved for 

class A jobs, and jobs are being processed in the other nine work 

processes, the reserved work process remains free even if a class A job 

is waiting for execution. 

Answer: False 

The work processes that are reserved for class A jobs process class A 

jobs. The option to reserve work processes for class A jobs should 

only prevent all work processes being occupied with class B or C jobs. 



6. If a user has authorization to schedule an external program as a step of 

a background job, he or she can run any operating system command. 

Answer: True 

If you do not want, as an administrator, to assign this critical 

authorization, but want to enable your users to run a specific 

operating system command, you can define an external command 



Unit 10 

303 Including Printers in SAP Systems 

In this unit, the participants learn about the basics of printer connection 

and the terms device types and logical spool servers. Take the notes in 

the individual lessons into account. 

Unit Overview 

In this unit, you will learn about the output processing architecture in the 

SAP system. You will learn how to define printers and spool servers in the 

system and how to manage spool and output requests. 



• Describe the architecture and data flow of output processing in the 

SAP system 

• Create printers and spool servers in the SAP system 

• List important access methods 

• Manage spool requests 

• Describe the concept of logical spool servers 

• Set up logical spool servers 

• Manage spool and output requests 

Unit Contents 

Lesson: Configuring Printers in SAP Systems..............................358 

Exercise 20: Configure Printers ..........................................371 

Lesson: Concept of Logical Spool Servers..................................379 

Exercise 21: Logical Spool Servers ......................................387 

Lesson: Managing Spool Requests ..........................................391 

Exercise 22: Managing Spool Requests ................................397 


Unit 10: Including Printers in SAP Systems ADM100 

Lesson: 

304 

Configuring Printers in SAP Systems 



In this lesson, you will learn about the output processing architecture. You 

will learn how to set up printers in the SAP system. 








This unit describes the basic work with printers in SAP systems: 

configuration and use. Connection methods for “remote”, “local”, “front 

end”, and “Web/PDF” printing are introduced. The participants also learn 

about working with logical spool servers and which reorganization actions 

have to be performed regularly. 


The administrator sets up printers in the SAP system and monitors the 

output of spool requests. 

Printing from SAP Systems 

There are various document classes in the SAP system (such as report 

lists, SAPscript or SAP Smart Forms documents). Although the way in 

which documents are created may be completely different, the output on 

paper is always performed using the same mechanism in two steps: First a 

spool request is created. The spool request contains device-independent 

print data and includes administrative information (such as author, date, 

number of copies) and the actual print data. Only when the spool request 

is to be output on a particular device is an output request created. The 

device-independent print data from the spool request is converted to the 

printer language that the selected output device understands. 


ADM100 Lesson: Configuring Printers in SAP Systems 

Figure 111: Data Flow During Printing 

Use this figure to explain the route that the data to be printed ultimately 

takes to the printer. In particular, you should explain to the participants 

that a dialog work process is used to generate the spool request (in dialog) 

and that the creation of the spool request does not “mean” printout. When 

a printout is requested, a spool work process (which is “responsible” for 

the selected printer) creates a corresponding output request. This output 

requests is transferred from the spool work process of the SAP system to 

the operating system spool system. The operating system transfers the data 

to the stored printer. A printer to be addressed must therefore be defined 

and addressable both in the SAP system and in the operating system. 

This procedure allows the user to display a spool request before output. 

There can also be several output requests for one spool request. This can 

avoid the user having to recreate (possibly with a great deal of effort) a 

spool request, if, for example, the toner in a printer is exhausted, or the 

wrong paper was in the tray. The user can of course create a spool request 

and an output request at the same time (immediate print) by choosing 

the Print immediately option. 

The actual document content of a spool request is stored in TemSe (for 

temporary sequential objects), for which you define the storage location 

with the profile parameter rspo/store_location. 

• Value db (the default value): Spool requests are stored in database 

table TST03 (Advantage: backup as part of the database). 



• Value G: Stored at operating system level in global directory 

(Advantage: performance). 

Note: You can also specify the storage location individually for the 

output device in transaction SPAD (menu pathEdit → Data Storage). 

SAP Note 20176 contains additional possible values for rspo/store_location. 

The creation of an output request prompts the SAP spool system to send 

a (usually) printer-dependent, completely formatted data stream to a 

printer using an operating system spooler (OS spool). This means that the 

addressed printer model must be known to the SAP system. Definitions of 

this type are described as device types. 

If a printer cannot be controlled at operating system level, it cannot be 

used from the SAP system, either. 

There are many ways in which a spool work process can reach an operating 

system spooler. The most important of these connections, described as 

access methods, are introduced in the following sections. 

Local Printing 

Access methods are used to describe how the spool work process is 

connected to with the operating system spooler. Local printing simply 

means that the spool work process is communicating with a spool system 

on the server on which it is running “itself”. This means that no network 

communication between the spool work process and the operating system 

spooler is required. The local printing access method therefore has NO 

meaning with regard to the location at which the output is printed onto 

paper. The local printing access method is obviously also a very quick type 

of connecting the processes involved. We recommend that you read SAP 

Note 108799 as part of your preparation. 



Figure 112: Local Printing 

Acharacteristicoflocal printing is that the spool work process and 

operating system spool are running on the same host. Itisirrelevant 

whether the printer is directly connected to this host, or is reached over 

a network (and possibly another print server). The spool work process 

passes on its data “locally”, that is on the same host. 

• On UNIX systems, the print data with access method L is output 

using operating system methods (for example, with the commands lp 

or lpr). The specific syntax is stored in profile parameters. 

• Under Microsoft Windows, the data with access method C is passed 

directly to the operating system print API. 

Local printing is the fastest and most reliable connection from the SAP 

system to the operating system. As soon as the spool work process has 

transferred its data, it can deal with new output requests - even if the 

operating system spooler may still be occupied. 

You can configure multiple spool work processes for an SAP instance. 

This has - irrespective of the access method - consequences for the output 

sequence. Differentspoolrequestsforthesameprintermaybeprinted 

in a different order to that in which they were created. If you require 

output in sequence, you can specify this for individual printers. However, 

a setting of this type reduces the ability to process in parallel. For more 

information about this topic, see SAP Note 108799. 



For information about printing to files using command sets, see SAP Notes 

6573 and 161516. 

Remote Printing 

The “remote printing” access method requires communication between 

the spool work process and an operating system spooler over a network. 

We therefore recommend that this access method is only used in local 

networks. A spool work process that is transferring print data does not 

accept any other tasks during the communication. The slower the network, 

the longer the spool work process is blocked and unavailable for other 

tasks. 

With remote printing, the spool work process and operating system 

spooler are running on different hosts. In exactly the same way as with 

local printing, it is irrelevant from the SAP system’s point of view whether 

the printer is directly connected to the remote host, or is reached using 

another network connection. 

Figure 113: Remote Printing 



It is also print using the Microsoft Windows TCP/IP PrintService using 

access method U. In this case, the TCP/IP PrintService can be used as an 

alternative to or in parallel with saplpd. 

Typical scenarios for remote printing are: 

• Network printers provide their own operating system spoolers and 

are directly connected to a computer network. Printers of this type 

are directly addressed from the SAP system using their names (access 

method U). 

• Access method U is also used if the remote host is a UNIX system. 

SAP Note 39405 describes how access method U can be used for the 

various UNIX versions. 

• SAP provides the program saplpd for all hosts with Microsoft 

Windows operating systems. The saplpd transfer program forwards 

the print output from the SAP system to the Microsoft Windows 

output control. 

Note that the hosts must have fixed IP address in this case, since the 

SAP system buffers this. 

Access method S is usually used here (SAP protocol), but access 

method U (UNIX Berkeley protocol) is also supported. 

For performance reasons, you should only use remote printing in a LAN 

environment (not WAN) and should ensure that the operating system 

spoolers are available. 

Front End Printing 

Access method F can be used on Microsoft Windows front ends. If this 

prerequisite is fulfilled, the default front end printer, for example, can be 

addressed. The printer is given a generic name in the SAP system, and is 

assigned to the physical device “__DEFAULT”. Since the models used as 

frontendprinterscanvaryconsiderably,thedevicetype“SWIN”isused. 

When this device type is used, the printer driver of the front end computer 

formats the data to be printed. The front end receives the data from the 

spool work process, which uses saplpd.exe on the front end for this 

communication. saplpd.exe is, if necessary, started using the dialog 

connection between the front end and the SAP system. Front end printing 

can also be used on non-Microsoft Windows front ends such as Unix and 



Apple Macintosh, with certain restrictions (same printer name on all front 

ends and identical control, such as in PostScript format). Learn about the 

parameter rdisp/wp_no_Fro_max as part of your preparation. 

Figure 114: Front End Printing 

SAP users can output documents on their local printers using front end 

printing. These local printers do not need to be individually defined in 

the SAP system. Rather the system administrator only needs to create a 

“representative” output device for each operating system platform. 

The print data stream is transferred to the host on which the user’s SAP 

GUI is running using access method F. This method can be used for front 

end PCs with different operating systems: 

• In the case of Microsoft Windows operating systems, the saplpd 

transferprogramreceivesthedatastreamandforwardsittothe 

default printer of the Microsoft Windows output control (or a different 

printer, if this is configured). If necessary, saplpd is automatically 

started. 

• With other operating systems (UNIX, Apple Macintosh, and so on), 

the data is transferred directly to the operating system spooler. In 

this case, the printer name (identical for all users) must be specified 

in the device definition. 

The processing of front end printing is also performed, as with the other 

output methods, using a spool work process. There can therefore be 

conflicts between regular and front end print requests. You specify 



the maximum number of spool work processes that can be used for 

front end printing for each SAP instance using the profile parameter 

rdisp/wp_no_Fro_max (the default value is 1). 

Front end printing is suitable for output on local printers, however not for 

production or mass printing. 

Of course, front end printing requires a connection to the front end PC. 

This method can therefore not be used for background processing. 

For more information, see SAP Composite Note 114426. SAP Note 351230 

describes front end printing with the SAP ITS when using the SAP GUI for 

HTML. SAP Note 150533 contains information about front end printing 

when using Windows Terminal Server. 

Creating Output Devices 

In addition to the information in the course material, note that a printer 

cannot subsequently be renamed, and that the name of the printer in the 

SAP system is case-sensitive. 

Hint: Emphasize the central functions of transaction SPAD. 

Do not become involved in discussions about connecting 

existing third-party solutions. This topic must be addressed on a 

case-by-case basis in the context of consulting. 

The configuration of the spool system is a system administration task. The 

centraltoolforthisistransactionSPAD(menupathTools → CCMS → 

Spool → Spool Administration). 



Figure 115: Creating Output Devices 

To create an output device, choose Output Devices on the Devices / Servers 

tab page. If there is already a large number of devices in your system, 

you can restrict the output list in the field next to the button (for example 

“PR*”). Important information for a device: 

Output device 

Name, maximum of 30 characters long (case-sensitive). 

Short name 

For internal system purposes (can be automatically generated). 

Device type 

Printer model/family (more information about this below). The 

device type SWIN transfers the SAP system format to the Microsoft 

Windowsprinterdriver.Thisisuseful,forexample,ifvariousprinters 

are used for front end printing in a Microsoft Windows environment. 

Spool server 

SAP application server with spool work processes or logical server. 

Location 

For example, building and room number (so that users can find 

their output). 

Message 

Used to temporarily override the location (such as “Is currently in 

maintenance”). 



Lock printer in SAP system 

Output requests for printers for which this indicator is selected are 

created but not transferred to the printer. The user receives the 

message ...no immediate printing. 

Host spool access method 

How does a spool work process contact the operating system spooler? 

Host printer 

Name of the printer at operating system level. Note that this name 

is case-sensitive. Under Microsoft Windows, there must not be a 

space in the printer name, and network printers are addressed using 

their UNC names (in the format \\R12345\P42). The specification 

__DEFAULT calls the default Microsoft Windows printer (for example, 

for front end printing in a Microsoft Windows environment). 

Host 

Only for local printing, is calculated automatically from the spool 

server. 

Destination hosts 

Only for remote printing. Name of the host on which the operating 

system spooler (such as lpd or saplpd) is running. 

Device Types 

If appropriate, display SAP Note 8928, and explain at this point the central 

importance of a correct device type for a proper printout. SWIN is not a 

“cure-all” and is dependent, for example, on the up-to-dateness of the 

frontendprinterdriverinuse. Also, SWIN cannot be used with local 

access methods, and is slow, since the fonts are sent with the request. 

The SAP system uses a device type to format the output device-specific 

print output. 

Hint: When reference is made to an output device in the SAP 

environment, it does not necessarily mean a printer. An output 

device can also be, for example, an Output Management System 

or an archiving system. 

When the spool work process generates an output request, it uses the 

specifications of the device type. That is, the device type describes how 

print data should be formatted for a particular output device. 

The following figure illustrates how a device type is created. 



Figure 116: What Is a Device Type? 

The following list explains the terms from the above figure. 

Page format 

ApageformatdescribestheformatofaprintablepageintheSAP 

system. A large number of standard page formats are predefined in 

the system. If a device is to be support additional format that are not 

delivered, you can define new formats. Consider when doing so that 

your output device must, of course, be able to use the new format. 

Format type 

A format type describes how output should appear on paper. It 

primarily contains the formatting of the page format. 

Format 

A format is a device-specific implementation of a format type. That is, 

the SAP system can use the description in a format to control a device 

correctly to, for example, perform an output on a page with the Letter 

format. A format type is therefore not device-specific, the format, on 

the other hand, is a device-specific implementation of a format type. 

Character set 

A character set contains the characters that can be output by a 

particular output device. That is, tobeabletouseaparticular 

character set for a selected printer model in the SAP environment, the 

device type assigned to this printer model must contain this character 

set. 



Print control 

Print controls allow the control of particular display options of output 

devices, such as boldface, changing the font size, changing the 

font, and so on. Print controls use device-specific control character 

sequences. That is, to create a new device type, the display options 

offered in the SAP system must be stored with the control character 

sequences that the selected printer model supports. The control 

character sequences to be used can be found in the device vendor’s 

documentation. 

Youcanseethatusingdevicesforwhichnosuitabledevicetypeexistsin 

the SAP system may mean a significant effort. 

You can refer the participants to SAP Remote Consulting as a possible 

source of help for problems when creating device types. 

Figure 117: Selecting an Appropriate Device Type 

How do you assign the correct device type to your printer? 

• In the ideal situation, there is already a device type in your SAP 

system. Note that a separate device type is not required for every 

printer model of a vendor, but just for each model family. 

• SAP Note 8928 contains a list of all printers supported by SAP. There 

is an attachment for this SAP Note containing corresponding device 

types. 



• For many printers, you can use a generic format (such as PostScript) 

for which device types exist. It is also possible that your printer can 

be addressed in the same way as another model that is supported by 

SAP (compatibility mode). 

• There are drivers for the Microsoft Windows operating systems for 

practically all printers on the market. You can use these printers as 

output devices with device type SWIN. The conversion to a print data 

stream is performed by the Microsoft Windows driver in this case. 

• The SAP system contains all of the tools required to create your own 

device types or to adjust copies of existing device types. Detailed 

knowledge of the SAP spool system and the printer control are 

required to do this. You should weigh up the expense against the 

purchase of supported printers. 



315 Exercise 20: Configure Printers 






The administrator sets up printers in the SAP system. 

Task1CheckthePrintEnvironment 

First check the print environment of your system. 

1. How many spool work processes are set up for the application server 

to which you are currently logged on? 

2. How many spool processes are configured in your entire SAP system? 

3. How many spool servers are available in your SAP system? 

4. Make a setting for your SAP user so that an output request is not 

created immediately for a spool request. 

5. Which printers are defined at operating system level of your server? 

Where do they print? 

6. (If possible) Which printers are defined at operating system level of 

your front end PC in the training room? Where do they print? 

Task 2 Create a Local Printer 

1. Create a local printer Local## (## stands for your group number) in 

your SAP system that calls one of the previously determined printers. 

2. Output any list (Suggestion: All profile parameters that begin with 

“rspo”) without immediate printing on the printer Local##. 

Task3CreateaRemotePrinter(Optional) 

You can offer the participants one of the two following options for creating 

aremoteprinter: 

A) Use the participants’ hosts as destination hosts. 

or 




B) Use the instructor’s host as the destination host. In this case, however, 

the participants cannot display the output. 

Caution: saplpd must be started at operating system level on 

the destination host. 

1. Create a remote printer Remote##in the SAP system that calls a 

remote printer that the instructor specifies. 

2. Output any list with immediate printing on the printer Remote##. 

3. Check your output. 

Task 4 Create a Front End Printer (Optional) 

1. Create a front end printer Frontend## in the SAP system that calls the 

default printer of a Microsoft Windows front end PC. 

2. Output any list with immediate printing on the printer Frontend##. 


Task 5 Frontend Printing with the SAP GUI for HTML 

(Optional) 

1. In the SAP system, create a new printer Webgui##by copying the front 

end printer that you have created. Change the device type to “PDF1”. 

2. Call the following URL in your local Web Browser (in the training 

room): 

http://:/scripts/wgate/webgui/! 

For example: 

http://twdf9999.wdf.sap.corp:1081/ scripts/wgate/webgui/! 

Hint: Do not forget the “!” sign at the end. 

3. Log on with your SAP user. Print any list (such as the output from 

transaction AL08) on the printer Webgui##. Observe what happens in 

the new Web browser window. 



Solution 20: Configure Printers 

Task1CheckthePrintEnvironment 

First check the print environment of your system. 

1. How many spool work processes are set up for the application server 

to which you are currently logged on? 

a) Call transaction SM50 and count the number of work processes 

of type SPO. 

2. How many spool processes are configured in your entire SAP system? 

a) This information is provided by transaction SM66. If you do 

not see any work processes at first, check the status wait under 

Select process. 

Hint: The number of spool work processes cannot be 

changed by operation mode switches. 

3. How many spool servers are available in your SAP system? 

a) A (real) spool server is an SAP application server with at least 

one spool work process. You can display this information with 

transaction SM51 more easily than with transaction SM66: All 

application servers that provide the service Spool are spool 

servers. 

4. Make a setting for your SAP user so that an output request is not 

created immediately for a spool request. 

a) To do this, choose System → User Profile → Own Data (transaction 

SU3) and the Defaults tab page there. Ensure that Output 

Immediately is not checked and save your changes, if necessary. 

5. Which printers are defined at operating system level of your server? 

Where do they print? 

a) Call Start → Settings → Printers at operating system level in your 

server. There should be printers (such as Printer1 for the group 

working on the DEV system and Printer2for the group working 

on the QAS system) that print to a file. 

6. (If possible) Which printers are defined at operating system level of 

your front end PC in the training room? Where do they print? 

a) If possible, call Start → Settings → Printers on your front end. 




Task 2 Create a Local Printer 

1. Create a local printer Local## (## stands for your group number) in 

your SAP system that calls one of the previously determined printers. 

a) Call Tools → CCMS → Spool → Spool Administration (transaction 

SPAD). On the Devices/Servers tab page, choose Output Devices 

(leave the field to the right empty). If you cannot find the button 

to Create, choose Change to switch to change mode. Now create 

the printer Local## with the following specifications: 

• Device Attributes tab page: 

– Device Type: Should match the previously determined 

printer (HPLJ4) 

– Spool Server: Any spool server from your system 

– Location: Anytext 

• Host Spool Access Method tab page: 

– Access Method: C for Windows 

– Host Printer: Name of the previously determined 

printer (Printer1 or Printer2) 

Acceptthedefaultvaluesfortheothervaluesandsave.Asyou 

can see, the system specifies the Short Name automatically. 


“rspo”) without immediate printing on the printer Local##. 

a) To create the suggested list, start transaction SA38 enter the 

report RSPFPAR, and execute it. Enter the parameter rspo* 

and choose Execute again. Alternatively, you can also print the 

output of transaction SM51. 

ToPrint,choosetheappropriatebutton.Alternatively,youcan 

choose System → List → Print. ChooseLocal## as the output 

device (enter it directly or select it using the F4 help). Choose 

Continue without making any additional entries. 

Task3CreateaRemotePrinter(Optional) 

You can offer the participants one of the two following options for creating 

a remote printer: 

A) Use the participants’ hosts as destination hosts. 

or 




B) Use the instructor’s host as the destination host. In this case, however, 

the participants cannot display the output. 

Caution: saplpd must be started at operating system level on 

the destination host. 

1. Create a remote printer Remote##in the SAP system that calls a 

remote printer that the instructor specifies. 

a) Theprocedureisthesameasforthepreviousexercise,but 

with different values. Your instructor will give you the exact 

information (host name, printer name, access method). 

2. Output any list with immediate printing on the printer Remote##. 

a) You can change your user defaults by choosing System → User 

Profile → Own Data (transaction SU3). Check the Immediate 

Output field on the Defaults tab page. 


a) Due to the setting made in task 2, print time Output Immediately 

is now the default value. The user can make this (and other) 

settings in the print dialog box by choosing Properties. 

Hint: By choosing Show selected print parameters on initial 

screen on the Properties window, you can maintain some 

parameters directly on the print dialog box in future. 




Task 4 Create a Front End Printer (Optional) 

1. Create a front end printer Frontend## in the SAP system that calls the 

default printer of a Microsoft Windows front end PC. 





the printer Frontend## with the following specifications: 

• Device Attributes tab page: 

– Device Type: SWIN 

– Location: here 

• Host Spool Access Method tab page: 

– Access Method: F 

– Host Printer: __DEFAULT 

Acceptthedefaultvaluesfortheothervaluesandsave.Asyou 

can see, the system specifies the Short Name automatically. 

2. Output any list with immediate printing on the printer Frontend##. 

a) The procedure is the same as for the previous task. If it is 

installed, you should now see saplpd started on your front end 

PC and receiving the print data stream. saplpd then continues 

running to receive additional print data. 


a) Theprocedureisthesameasfortheprevioustask. 

Task 5 Frontend Printing with the SAP GUI for HTML 

(Optional) 

1. In the SAP system, create a new printer Webgui##by copying the front 

end printer that you have created. Change the device type to “PDF1”. 




to copy (Create using Template button), choose Change to switch 

to change mode. Now select the printer Frontend## with the 

mouse and choose Create using Template. 

Call the new printer Webgui## and change the device type to 

PDF1. Leave the other values unchanged and save. 




2. Call the following URL in your local Web Browser (in the training 

room): 

http://:/scripts/wgate/webgui/! 

For example: 

http://twdf9999.wdf.sap.corp:1081/ scripts/wgate/webgui/! 

Hint: Do not forget the “!” sign at the end. 

a) Seeexercisetext. 

TheSAPITSportmaynotbeaccessiblefromyourtrainingroom. 

If this is the case, use the Web browser available on your server. 

3. Log on with your SAP user. Print any list (such as the output from 

transaction AL08) on the printer Webgui##. Observe what happens in 

the new Web browser window. 

a) If you proceed as described in the exercise, a new Web browser 

window appears. A PDF document with the list is displayed in 

this window after some time. This document can now be saved 

to the user’s computer or printed. 

SAP Note 351230 describes the procedure and the exact 

prerequisites for this print scenario. 











• SAP Library: mySAP Technology Components → SAP Web Application 

Server → Computing Center Management System → SAP Printing Guide 

• SAP Service Marketplace, Quick Link /output 


– SAP Note 118057: Flexible Configuration of the Spool Service 

– SAP Note 108799: How many spool work processes for each instance? 

– SAP Note 114426: Front End Printing (Collective Note) 

– SAP Note 8928: List of supported printers/device types 


ADM100 Lesson: Concept of Logical Spool Servers 

Lesson: 

322 

Concept of Logical Spool Servers 



In this lesson, you will learn about the concept of logical spool servers and 

learn how to set up logical spool servers. 





Hint: The advantages of logical spool server are explained in this 

lesson. They simplify the work for the administrator by providing 

the possibility of using descriptive names and making it simple to 

transport the print landscape to other systems. The possibility to 

specify an alternative server and allow load balancing also exists 

for real spool servers. 

If you are running a course in German, ensure that you explain that 

“Spoolserver” and “Aufbereitungsserver” mean the same thing. The two 

terms are used synonymously in the SAP environment. The functions 

provided by a logical spool server are introduced in the following section 

of the course material. 


Concept of Logical Spool Servers 

The previous printing concept envisages a fixed assignment of an output 

device to a spool server. A spool server, on the other hand, can be assigned 

multiple output devices, which raises the risk of this server becoming 

overloaded. It would therefore be desirable to have a mechanisms for 

load balancing across multiple servers. Groups of spool servers are also 

advisable with regard to downtime security. Both aspects are taken into 

account by introducing logical spool servers. 



Figure 118: Spool Servers 

A spool server is an SAP application server with at least one spool work 

process. Every output request is processed on a “real” spool server of 

this type. 

An output device created in the SAP system can be assigned a spool 

server directly. However, there are many advantages associated with an 

additional logical layer between the outputdeviceandthespoolserver. 

You can use logical (spool) servers for this purpose, that stand for a 

hierarchy of other logical servers and/or “real” spool servers. 

You can classify output devices and spool servers, for example, for test 

printing or production printing. 

The SAP system checks the classifications when saving, and displays a 

warning message if there are deviations. For example, the system warns 

youifyouattempttoassignahighvolumeprintertoaproductionprint 

server. 

Creating a Logical Spool Server 

We recommend that you research the topic of “Classification” of spool 

servers, and the consequences of this classification as part of your 

preparation. For detailed information, see the SAP Library under the path 

mySAP Technology Components → SAP Web Application Server → Computing 

Center Management System → SAP Printing Guide. 



You can maintain the spool server in transaction SPAD by choosing Spool 

Servers on the Devices / Servers tab page. Important information for a spool 

server: 

Server Name 

Name of the spool server, maximum of 20 characters long 

(case-sensitive). The field below is intended for a short description. 

Server Class 

Classify the spool server here (for example, for mass printing). 

Logical Server 

Select this field when you create a logical server. 

Mapping 

Name of a real or logical server to which this logical server points. 

Additional information is presented below. 

Figure 119: Creating a Logical Server 

You can define a spool server (real or logical) specifically for front end 

printing by setting the profile parameter rspo/local_print/server to the 

server name. If no spool server is explicitly defined in this way, the local 

application server is used, if this has at least one spool work process. 

Otherwise, one of the spool servers in the system defined in the system 

that has a minimal load is selected for the processing. 



If you expect a significant workload due to front end printing, you should 

configure at least one additional spool work process for each front end 

printing spool server for other tasks. 

As already mentioned, you can classify output devices and spool servers. 

To classify an output device, select it (in transaction SPAD under Output 

Devices) and call the path Edit → Classification in the menu. 

Advantages of Logical Spool Servers 

Hint: It is also possible to specify an alternative server and to allow 

load balancing for real spool servers. 

Using logical spool servers, it is possible to set up downtime security for 

physical spool servers. If the load balancing option is used, the downtime 

security option obviously exists, since no tasks are assigned to a resource 

that is not available. Sequential output processing for a device prevents 

the use of load balancing for the output requests for this device, as noted 

in the course material. An additional feature of using logical spool servers 

is the simplified transport of complete print landscapes. However, it 

is worth mentioning that there is also a simple tool for mass changes to 

output devices (for example, after a transport) available under “Utilities” 

in transaction SPAD. 

Downtime Security 

When creating a spool server (either a logicalserveroraspoolserver),you 

can specify an alternative server. If the normal server is not available, the 

SAP system attempts to use this alternative. 



Figure 120: Breakdown Alternatives 

Youmustensurethatallprintersthatmaybeusedbyadifferentspool 

server can be controlled in the same way by every spool server. For 

example, if the output device Test 1 intheaboveexamplepointsat 

operating system level to a printer P42 that is controlled locally, an 

operating system printer P42 must be available on servers twdf5000 and 

twdf5001. 

You cannot store more than two spool servers for a logical server. Since 

a logical server can itself point to logical servers, extensive spool server 

hierarchies are also possible. You can display hierarchies of this type 

graphically using transaction SPAD. 

Load Balancing 

You can allow load balancing for every spool server with an alternative 

server (to do this, select the field Allow Load Balancing). The load of a spool 

server is calculated from the number of spool work processes, output 

requests, and printed pages. 



Figure 121: Load Balancing 

For an output request for a spool server with load balancing (the setting 

canbemadeforlogicalserversandspoolservers),thesystemdetermines 

the server with the lowest load. The algorithm is recursive: The same 

selection criteria are used on the mapping and the alternative server (both 

could be logical servers themselves). 

Sequential request processing (property of an output device) has priority 

over the load balancing shown here (property of a spool server). This 

means that output requests for an output device with sequential request 

processing would not be distributed in accordance with the current load, 

although assigned to a spool server with load balancing. 

Transporting the Print Landscape 

The concept of logical servers supports you when defining a consistent, 

transportable print landscape. Logical servers can - unlike real spool 

servers - have the same name in various SAP systems. In this way, you can 

defineaconsistentSAPprintarchitectureinthedevelopmentsystemand 

then transport it to other systems. After the transport, you must only adjust 

the mapping of the logical servers to the spool servers of the new system. 



Figure 122: Transporting the Print Landscape 

There are functions for the manual transport of output devices and spool 

servers in transaction SPAD. 





329 Exercise 21: Logical Spool Servers 




• Set up logical spool servers and assign output devices 


Logical spool servers are to be set up in your SAP system for reasons of 

load balancing and downtime security. 

Task Creating a Logical Spool Server 

1. Create a logical server Logical##. If possible, enter two different 

spool servers as mapping and alternative server and activate load 

distribution. Classify Logical## as a test server. 

2. Change the output device Local## so that the logical server Logical## 

is used in the future. Classify Local## as a test printer. 

3. Change the specifications for your SAP user so that an output request 

is created for a spool request by default. 


“rspo”) with immediate printing on the printer Local##. 

5. Check your output. Which real spool server was used? 



Solution 21: Logical Spool Servers 

Task Creating a Logical Spool Server 

1. Create a logical server Logical##. If possible, enter two different 

spool servers as mapping and alternative server and activate load 

distribution. Classify Logical## as a test server. 


SPAD). On the Devices/Servers tab page, choose Spool Servers 



alogicalserverLogical##. 

Choose Logical server and enter at least one spool server for 

Mapping. Enter the other details as described in the exercise 

and choose save. 

2. Change the output device Local## so that the logical server Logical## 

is used in the future. Classify Local## as a test printer. 

a) From transaction SPAD, choose the Output Devices button on 

the Devices / Servers tab page. By double clicking Local##, you 

can edit your printer (switch to change mode if necessary). On 

the Device Attributes tab page, enter the logical spool server 

Logical## as the Spool Server. To classify the output device, 

choose Edit → Classification → Test Print. Choose save. 

3. Change the specifications for your SAP user so that an output request 

iscreatedforaspoolrequestbydefault. 

a) You can change your user defaults by choosing System → User 

Profile → Own Data (transaction SU3). Check the Immediate 

Output field on the Defaults tab page and save. 





“rspo”) with immediate printing on the printer Local##. 

a) Due to the setting made in the previous task, print time Output 

Immediately is now the default value. The user can make this (and 

other) settings in the print dialog box by choosing Properties. 

Hint: By choosing Show selected print parameters on initial 

screen on the Properties window, you can maintain some 

parameters directly on the print dialog box in future. 

To create the suggested list, start transaction SA38 enter the 

report RSPFPAR, and execute it. Enter the parameter rspo* 

and choose Execute again. Alternatively, you can also print the 


To Print, choose the appropriate button. Alternatively, you can 

choose System → List → Print. Choose Local## as the output 

device (enter it directly or select it using the F4 help). Choose 

Continue without making any additional entries. 

5. Check your output. Which real spool server was used? 

a) This time, an output request is created immediately. Transaction 

SP01 displays its status. For the spool server, select your output 

request (not the spool request) and choose Choose Detail. The 

server name is at the bottom of the list. 








• SAP Library: mySAP Technology Components → SAP Web Application 

Server → Computing Center Management System → SAP Printing Guide 



– SAP Note 118057: Flexible Configuration of the Spool Service 


ADM100 Lesson: Managing Spool Requests 

Lesson: 

333 

Managing Spool Requests 



In this lesson, you will learn about managing spool and output requests. 




Familiarize yourself with transactions SP01 and SP02. As part of your 

preparation for this course, test the monitoring of spool requests from 

other systems in transaction SP01. Being able to work with the output 

status is an important skill for evaluating output errors. Demonstrate how 

to use the return messages by manually provoking an error (for example, 

in the case of remote printing, address a host on which saplpd has not 

been started). Take the opportunity (after starting saplpd), to show the 

status “”. Describe the regular deletion of old spool requests and the 

functions of the regular consistency checks of spool data and TemSe. SAP 

Note 98065 describes the chronological process of multiple consistency 

checks and how to handle their results. 


As a spool administrator, you maintain the spool and output requests 

in your SAP system. 

Managing Spool and Output Requests 

To maintain spool and output devices, call the Output Controller 

(transaction SP01 or choose System → Services → Output Controller). If you 

only want to check the status of your own, current spool requests, choose 

System → Own Spool Requests (transaction SP02). 

Transaction SP01 provides many selection criteria for selecting particular 

spool or output requests. Every user can individually and easily define 

the selection criteria that he or she requires using the Further Selection 

Criteria... function. 



Figure 123: Selecting Spool or Output Requests 

It is even possible to monitor spool and output requests on other SAP 

systems. To do this, enter a valid RFC connection in the System Name 

field. If this field remains empty, all systems that were selected for remote 

monitoring using transaction RZ20 (table ALCONSEG) are addressed. 

Figure 124: Monitoring Spool and Output Requests 



The displayed list shows all spool or output requests that match your 

selection criteria. The list is created using the SAP List Viewer (ALV). This 

allows you to change the appearance of the list as you desire. This means 

that you can show and hide columns, sort columns, or create variants. 

The following indicators specify the status of a spool request: 

- 

+ 

Not yet sent to the operating system (no output request exists) 

Spool request is still being created (stored in spool system) 

Waiting 

The output request has not yet been processed by the spool system. 

Proc 

A spool work process is formatting the output request for printing 

Print. 

The output request is being printed by the operating system spooler. 

If the query at the host spooler is not activated, this status is shown 

for around a minute. 

Compl. 

The output request has been printed. If the query at the host spooler 

is not activated, the status changes to Compl. as soon as the output 

request is transferred to the host spooler. 

 

There are output requests with various statuses. 

Problem 

Indicates an error not of a serious nature (such as incomplete 

character set). This request was still printed. 

Error 

Indicatesaseriouserror(suchasanetworkerror). 

Time 

A particular time was specified for the output of the request by the 

request creator. 

If you double click the status of a spool request, the system displays the 

associated output requests. For the output requests of multiple spool 

requests, select these and choose Output Requests (or choose F5). 

For every unsuccessful output request, a log is written that you can use 

for error analysis. 



Figure 125: Maintaining the Spool Database 

Regular deletion of old spool requests and monitoring the consistency of 

the spool database are system administration tasks. 

To delete old spool requests, schedule the ABAP program RSPO1041 with 

an appropriate variant as a periodically running background job. For 

more information about RSPO1041, see SAP Note 130978. 

To check the consistency of the spool database, scheduletheABAP 

program RSPO1043 with an appropriate variant as a daily running 

background job. For more information about RSPO1043, seeSAPNote 

98065. 

The program RSPO1043not only checks for inconsistencies between TemSe 

and Spool, but also corrects these if it is run again. 

In exceptional cases, you can also perform both tasks online from 

transaction SPAD , although with restrictions in comparison to the ABAP 

programs. 

This function will, however, no longer be available as of one of the next 

Support Packages (>19). 

For information about the reorganization of TemSe and spool, see also 

SAP Note 48400. 



Overview: Other Print Scenarios 

In addition to the information in the course material, you should 

investigate “Web Printing” in more detail as part of your preparation, since 

you can present this connection in the course due to the available SAP ITS. 

Printing to PDF is an excellent function of the spool system and should 

certainly be demonstrated. Take into account the information about this 

in SAP Note 351230. 

Here is an overview of other print scenarios: 

Figure 126: Other Print Scenarios 

External Output Management Systems (OMS) can be addressed from 

the SAP system using a defined interface (BC-XOM) (access method E). 

This method is of particular interestifyouhaveaverylargevolume,or 

the output of multiple systems (SAP systems and others) is to be centrally 

controlled and monitored. You can find a list of all certified products 

under http://www.sap.com/spp (Software Partner Program). 

Since SAP Basis 4.0B (as of a particular kernel and Support Package status), 

you can send print output by e-mail to a user (access method M). The 

e-mail is sent using SAPconnect. For more information, see SAP Notes 

311037 and 513352. 



A user can also be connected to an SAP system from a Web browser 

through the SAP GUI for HTML. A connection of this type can be made 

directly through the middleware (Web server and ITS) of the SAP system 

or as part of an enterprise portal (such as the SAP Enterprise Portal). What 

options does this user have for print output? One option is the previously 

described output by e-mail. On the other hand, Web printing does not 

require an e-mail client. You can use Web printing as of SAP Basis 4.6B. To 

do this, the system administrator must provide a printer with device type 

PDF1 and access method F. If the user selects this printer, a PDF document 

appears in a new window. The user can then print this PDF document. 

SAP Note 351230 describes the exact prerequisites and contains additional 

information about Web printing. 



339 Exercise 22: Managing Spool Requests 






Task 

1. Display a spool request. 

2. Create an output request for the spool request. 

3. Check the status of your output request. 

4. (Optional) Display the generated print data. Instead of checking at 

operating system level, you can view the file from the SAP system 

using transaction AL11 (SAP directory C_TEMP). 



Solution 22: Managing Spool Requests 

Task 

1. Display a spool request. 

a) Choose System → Services → Output Control (transaction SP01). 

Restrict the output to your spool requests from today (thisisthe 

default selection). Your spool request should have status “-”. 

2. Create an output request for the spool request. 

a) Choose the Print directly button. 

3. Check the status of your output request. 

a) Refresh the list of spool requests. Does the status change to 

complete? If not, double click the Status field and analyze the log. 

4. (Optional) Display the generated print data. Instead of checking at 

operating system level, you can view the file from the SAP system 

using transaction AL11 (SAP directory C_TEMP). 

a) Both solutions are described here: 

• At operating system level, you can use, for example, 

Notepad (Start → Run, and then enter notepad) todisplay 

the file C:\temp\Print1.prn or C:\temp\Print2.prn. Note 

that Notepad cannot display all printer-specific control 

characters. 

• In the SAP system, call transaction AL11 and double click 

the entry C_TEMP at the end of the list. Double click the file 

name (Printfile1 or Printfile2) displays the file contents. 







• SAP Library: mySAP Technology Components → SAP Web AS → 

Computing Center Management System → SAP Printing Guide 



– SAP Note 130978: RSPO1041 - Deleting old spool requests 

– SAP Note 98065: Spool Consistency Check with RSPO1043 as of 4.0A 

– SAP Note 48400: Reorganization of TemSe and Spool 

– SAP Note 311037: Printing via e-mail 

– SAP Note 351230: Frontend printing with HTML GUI/WebGUI 



Unit Summary 












343 


1. Which of the following access methods exist in the SAP system? 


A Remote printing 

B Front end printing 

C Instance printing 

D Local printing 

2. Which of the listed states can a spool request have? 


A Compl. 

B Canceled 

C Error 

D Waiting 

E Active 

F Print. 



344 

Answers 

1. Which of the following access methods exist in the SAP system? 

Answer: A, B, D 

Instance printing does not exist. 

2. Which of the listed states can a spool request have? 

Answer: A, C, D, F 

The incorrect options canceled and active arepossiblestatusmessages 

from job monitoring. Other possible statuses of a spool request are -, 

+, Proc., , Problem, andTime. 


Unit 11 

345 Basics of User Administration 

This unit will introduce the basics of user administration. The focus is 

on explaining terminology and the possibilities that role maintenance 

provides. The creation of user master records, already familiar from the 

SAPTEC course, is repeated here briefly. 

Unit Overview 

This unit addresses the SAP authorization concept. The focus is on 

explaining important terms and creating roles and authorization profiles. 

System parameters will be used to demonstrate how relevant settings 

canbemadeinthesystem. Theuseofcentraldirectoryservicesisalso 

introduced. 



• Create users 

• Copy, create, and maintain roles 

• Maintain the assignment of roles and users 

• Set system parameters for user logons 

• Locate authorization problems 

• Describe the concept of Central User Administration 

• Describe connection to directory services 

Unit Contents 

Lesson: User Administration Concept........................................405 

Exercise 23: Basics of User Administration.............................411 

Lesson: Authorization Concept ...............................................414 

Exercise 24: Working with Roles.........................................425 

Lesson: Login Parameters and User Info....................................431 


Unit 11: Basics of User Administration ADM100 

Lesson: Appendix - Advanced User Administration Topics................439 


ADM100 Lesson: User Administration Concept 

Lesson: 

346 

User Administration Concept 



This lesson will explore the administration of user master records. 

Creating, copying, and maintaining master records of this type will be 

described in more detail. 




As a demonstration, create a user, “TestAdmin”, in transaction SU01 

and maintain the following settings: Last name, initial password, user 

group, defaults, and the parameter XUS. Then lock and copy the user. 

Demonstrate how the password changes in the copied master record. You 

should know that the user types were changes with SAP Basis 4.6C. For 

more information, see the F1 help for transaction SU01. 

Hint: A dialog box may appear in transaction SU01 when you 

leave the Roles tab page. For information about the terms listed, see 



The users of the SAP system require their own user with appropriate 

authorizations to log on. The administrator sets up a user in the system 

for each user. 

Basics of User Administration 

The concept of the user master record and the authorization concept are 

explained in more detail below. Both of these are important to obtain a 

better understanding of SAP systems. 



Figure 127: Users in the SAP Environment 

The term “user” usually means user ID here. People log on to an operating 

system, a database, or an SAP system using a user/password combination. 

Operating systems, databases, and SAP systems usually have different 

authorization concepts. If a user/password combination is created in an 

SAP system for a person, this does not meanthatitispossibletologonto 

the operating system of a host with the same user/password combination. 

However, it is possible that identical user/password combinations are 

created for SAP systems and operating systems. 

Note: User requests are processed by SAP work processes. These 

work processes all use a shared user to access the database. 

This unit deals exclusively with SAP users, which people use to log on to a 

client of an SAP system. Users and authorization data are client-dependent. 

Access to the operating system level of the SAP Web Application Server 

andthedatabaseservermustbeprotected,asotherwisetheoperationor 

the data of the SAP systems could be threatened. 



Figure 128: Users and Authorizations 

Authorization protection is performed at two levels: 

1. May a transaction be called? 

2. Authorization for actions and data that are used during a transaction. 

A person can log on to a client of an SAP system if they know the 

user/password combination for a user master record. 

In the SAP system, there is an authorization check every time a transaction 

is called. If a user attempts to start a transaction for which he or she is not 

authorized, the system rejects the user with an appropriate error message. 

If the user starts a transaction for which he or she has authorization, the 

system displays the initial screen of this transaction. Depending on the 

transaction called, the user enters data and performs actions on this screen. 

Additional authorization checks are made for data and actions that are 

to be protected. 

Users are assigned authorizations using roles. The authorizations are 

combined in roles and the roles are entered in the user master record. This 

is explained in more detail later in this unit. 



Figure 129: User Master Record 

System Demo: Create a user with transaction SU01 (this is already familiar 

to the participants from SAPTEC; such as TestAdmin), maintain the 

settings such as last name, initial password, user group, defaults, and 

parameters (such as XUS). Lock the user. Copy the user and demonstrate 

changing the password. 

Note the user types and their tasks. These changed as of SAP R/3 4.6C. 

For more information about this, see the F1 help for transaction SU01. 

To start user maintenance (transaction SU01), choose Tools → Administration 

→ User Maintenance → Users. 

You can create a new user master record by copying an existing user 

master record or creating a completely new one. The user master record 

contains all data and settings that are required to log on to a client of the 

SAP system. This data is divided into the following tab pages: 

• Address: Address data 

• Logon Data: Password and validity period of the user 

• Defaults: Default values for a default printer, the logon language, 

and so on. 

• Parameters: User-specific values for standard fields in SAP systems. 

• Roles and Profiles: Roles and profiles that are assigned to the user. 

• Groups: For the grouping of users for mass maintenance 



You must maintain at least the following input fields when creating a 

user: Last name on the Address tab page, initial password and identical 

repetition of password on the Logon Data tab page. 





351 Exercise 23: Basics of User Administration 






As an administrator, you must create new users and lock existing users. 

Task Create Users 

Create a user with the name ADMIN##, where ## is your group number. 

Follow the steps described below: 

1. Create a user (master record) with the name ADMIN##. 

2. Maintain the first and last names of the user. 

3. Assign an initial password to the user (and remember it), and assign 

the user to the SUPER User Group for Authorization Checks. 

4. Enter a default value for the logon language for the user (such as 

EN or DE). 

5. Save the user master record. 



Solution 23: Basics of User Administration 

Task Create Users 

Create a user with the name ADMIN##, where ## is your group number. 

Follow the steps described below: 

1. Create a user (master record) with the name ADMIN##. 

a) Start transaction SU01. Enter the name ADMIN## in the User 

field and choose Create. 

2. Maintain the first and last names of the user. 

a) Choose the Address tab page. Enter the first and last names in 

theappropriatefields. 

3. Assign an initial password to the user (and remember it), and assign 

the user to the SUPER User Group for Authorization Checks. 

a) Choose the Logon Data tab page. In the Initial Password field, 

enter the password and press the tab key to move to the Repeat 

Password field. Enter the password again in this field. Move the 

cursor to the User group for authorization check field and choose 

the group SUPER using the F4 help. 

4. Enter a default value for the logon language for the user (such as 

EN or DE). 

a) Choose the Defaults tab page. In the Logon Language field, enter 

EN for English or DE for German. 

5. Save the user master record. 

a) Choose Save. 








Lesson: 

354 

Authorization Concept 



In this lesson, the terms authorization object, authorization profile, 

authorization check, and role are discussed in a common context. The 

focus here is on role maintenance; that is, on creating a role. 





Participants often do not understand the meaning of the differentiation 

between roles and profiles. A role is primarily a functional description, 

such as HR employee. At this point, there is no consideration of the 

required technical authorizations for editing tables or data. The technical 

realization of the role, in the form of concrete authorizations is achieved 

through the authorization profile associated with the role. If you assign 

a role to a user without performing a user master comparison, the user 

does not have any of the authorizations that belong to this role. You 

would be creating a pseudo-user that was assigned the role but to which 

no profile was assigned. This user can only log on and off the system, but 

cannot perform any actions in the system. 

The advantages of this two-level approach are, on one hand, the 

opportunity to implement a security checking principle requiring at 

least two persons, that is, an administrator is authorized to assign a 

role to users, and another user is authorized to perform a user master 

comparison. On the other hand, it also allows administrators to maintain 

a time dependency for authorizations of a user. 


The authorizations for users are created using roles and profiles. The 

administrator creates the roles, and the system supports him or her in 

creating the associated authorizations. 


ADM100 Lesson: Authorization Concept 

Authorization Objects and Authorization Checks 

Understanding the SAP authorization concept requires knowledge of the 

authorization profile and roles in the user master record. This lesson 

provides you with the necessary knowledge to be able to create your own 

roles and authorizations. 

Figure 130: Authorization Objects 

Explanation: The authorization object “S_USR_Group” mentioned in the 

text belongs to the user group (see the demo for transaction SU01). 

Authorization object as a template for objects that are to be protected. 

Authorization is always associated with the authorization object. It 

specifies the form of protection. 

Object class for grouping/sorting. 

Actions and the access to data are protected by authorization objects in 

the SAP system. The authorization objects are delivered by SAP and are 

in SAP systems. To provide a better overview, authorization objects are 

divided into various object classes. 

Authorization objects allow complex checks that involve multiple 

conditions that allow a user to perform an action. The conditions are 

specified in authorization fields for the authorization objects and are AND 

linked for the check. Authorization objects and their fields have descriptive 

and technical names. In the example in the figure, the authorization object 

“User master maintenance: User Groups” (technical name: S_USER_GRP) 

contains the two fields “Activity” (technical name: ACTVT) and“User 



Group in User Master Record” (technical name: CLASS). The authorization 

object S_USER_GRP protects the user master record. An authorization 

object can include up to ten authorization fields. 

An authorization is always associated with exactly one authorization 

object and contains the value for the fields for the authorization object. 

An authorization is a permission to perform a certain action in the SAP 

system. The action is defined on the basis of the values for the individual 

fields of an authorization object. For example: Authorization B in the 

figure for authorization object S_USER_GRP allows the display of all user 

master records that are not assigned to the user group SUPER. 

There can be multiple authorizations for one authorization object. 

Some authorizations are delivered by SAP, but the majority are created 

specifically for the customer’s requirements. 

Figure 131: Authorization Check 

It is assumed here that the transaction call was successful. Data is entered 

in the transaction. After confirmation, processing takes place in the work 

process and an authorization check is performed, if required also “on this 

data”. 

Check: If the user has an authorization for authorization object XYZwith 

therequiredvalues,theprocessingcontinues. Multiple authorization 

objects are usually checked. 



Authorization, profile, and role changes become active the next time 

the user logs on. If the instructions in SAP Note 452904 are followed 

(auth/new_buffering=4 and the relevant Support Packages are imported), 

changes take effect immediately (as of SAP R/3 4.6B). 

When a user logs on to a client of an SAP system, his or her authorizations 

areloadedintheusercontext.Theusercontextisintheuserbuffer(inthe 

main memory) of the application server. 

When the user calls a transaction, the system checks whether the user 

has an authorization in the user context that allows him or her to call the 

selected transaction. Authorization checks use the authorizations in the 

user context. If the user is assigned new authorizations, he or she must log 

on to the SAP system again to use these. 

If the authorization check for calling a transaction was successful, the 

system displays the initial screen of the transaction. Depending on the 

transaction, the user can create data or select actions. When the user 

completes his or her dialog step, the data is sent to the dispatcher, which 

passes it to a dialog work process for processing. Authority checks 

(AUTHORITY-CHECK) that are checked during runtime in the work 

process are built into the coding by the ABAP developers for data and 

actions that are to be protected. If the user context contains all required 

authorizations for the checks, the data and actions are processed and the 

user receives the next screen. If one authorization is missing, the data 

and actions are not processed and the user receives a message that his or 

her authorizations are insufficient. 

All authorizations are permissions. There are no authorizations for 

prohibiting. Everything that is not explicitly allowed is forbidden. 



Role Maintenance: Menus and Authorizations 

Figure 132: Role Maintenance 

New naming since SAP R/3 4.6C: Role instead of activity group, role 

maintenance instead of profile generator. Advantages of role maintenance: 

• Collection of the authorization objects (that are checked in the 

transactions) and creation of the associated authorizations with the 

necessary values, as long as this is technically possible. 

• Assignment of roles to users 

• Generation of the user menu 

Role Maintenance (transaction PFCG, previously also called Profile 

Generator or activity groups) simplifies the creation of authorizations and 

their assignment to users. In role maintenance, transactions that belong 

together from the company’s point of view are selected. Role maintenance 

creates authorizations with the required field values for the authorization 

objects that are checked in the selected transactions. 

A role can be assigned to various users. Changes to a role therefore have 

an effect on multiple users. Users can be assigned various roles. 

The user menu contains the entries (transactions, URLs, reports, and so on) 

that are assigned to the user through the roles. 



Figure 133: Menu Layout 

Selection of the transaction for the role and layout of the user menu. 

System Demo: Activate the technical names. Assign of the transactions 

that belong to the role (SM50, SM51) from the SAP menu. Call SM04 

directly using the transaction code. Arrange transactions: Create new 

folders, move folders, and so on. 

You can access role maintenance with transaction PFCG or by choosing 

Tools → Administration → User Maintenance → Role Administration → Roles. 

Enter the name of the role and choose the icon for Create or Change. Choose 

the Menu tab page. 

Select and change functions: The menu tree can be adjusted for the 

individual roles as required. 

You can insert transactions into the tree structure or delete them from it. 

By choosing the Report button, you can integrate Reports. Inthiscaserole 

maintenance creates transaction codes with which the reports can be called. 

By choosing the Other button, you can add Internet addresses or links to 

files (such as tables or text files). When integrating files, you must use the 

storage paths instead of URLs. You can also specify BW WebReports, and 

links to external mail systems and Knowledge Warehouse. 



Change menus: You can create, move, delete, and rename directories and 

subdirectories as required. You can use the Drag&Drop function in role 

maintenance. 

Figure 134: Generating Authorization Profiles 

Start by choosing: Change Authorization Data 

Showthedifferentlevelsinthetreeandcomparethemwiththelegend. 

Activate technical names and icons. 

Display the documentation by double clicking the authorization object. 

Explain why PADM is in S_ADMI_FCD. 

Generate (includes save). 

Role maintenance automatically creates the authorizations that are 

associated with the transactions specified in the menu tree. However, all 

authorization values must be manually checked and adjusted if required 

in accordance with the actual requirements and authorities. The system 

administrator is responsible for this task, together with the appropriate 

user department. If you are using organizational levels, this significantly 

simplifies authorization maintenance. 

Choose the Authorizations tab page and choose Change Authorization Data. 

Check the scope and contents of the authorizations. 

In the authorization overview, a green traffic light indicates that the role 

maintenance can automatically create an authorization. A yellow traffic 

light indicates that the authorization must be manually maintained after 

it has been created. Role maintenance does not provide a default value 



for the authorization. The above example deals with access to files. Role 

maintenance cannot “guess” whether data access should only be read 

access, or should be read and write access. 

Some fields appear in many authorizations. A number of important fields 

were therefore combined into organizational levels, such as the company 

code. If you maintain the organizational level, you maintain all fields in 

it. Therefore, a red traffic light indicates an unmaintained organizational 

level. 

Once all authorizations are maintained as required, the authorization 

profilecanbegeneratedbychoosingGenerate. Important: The second 

character of the profile name must not be an underscore (“_”) (see 

SAP Note 16466). After creation, this name cannot be changed. The 

authorizations are combined in profiles. The profiles must be entered in 

the user master record (by the role maintenance) for the authorizations 

to take effect for the user. 

Users and Roles 

Assign users, for example from the demo above: TestAdmin (alternatively, 

you can use the user Admin, to which no roles are assigned), and save. 

Display in transaction SU01 how a role (such as ZPFUD) is assigned here. 

The assignment of users to roles is performed in the role maintenance 

transaction (transaction PFCG) or in the user maintenance transaction 

(transaction SU01). Select the tab page User and the user IDs to be 

maintained there. When selecting user IDs, the system uses the current 

date as the start of the validity period of the assignment; it sets 31.12.9999 

as the end date. You can restrict both values. 



Figure 135: Assigning Roles to Users 

Users can be linked with more than one role. This can be useful if some 

activities (such as printing) are to be permissible across roles. 

The assignment of roles to users does not automatically grant the 

corresponding authorizations to the users. To assign the authorizations, 

you must first perform a user master comparison, duringwhichtherole’s 

profiles are entered in the user master record. 

Figure 136: Comparing User Master Records 



For more information, choose the information button in transaction PFCG 

and the information button in the user master comparison. 

During a complete comparison, obsolete profiles are also removed. In 

expert mode, users can be explicitly excluded from the comparison. For 

this reason, no green traffic lights are displayed in role maintenance after 

this. 

System Demo: Use SU01 to check whether the role and profiles are 

already assigned. Then perform a User comparison, complete comparison 

and check again. 

Additional demos for role maintenance: Transaction PFCG, include 

report RSUSR000 (report from transaction AL08 by choosing Add Report). 

RSPFPAR would be a bad example, as it is also a transaction, and requires 

a variant. Use the Display Other Options button to deactivate the automatic 

generation of transaction codes and enter your own transaction code and 

save. Add an Internet address (such as http://service.sap.com). 

Display organizational levels: In SAP Web AS 6.10, only organizational 

levels from HR are available. If you select transaction PFUD (User 

Master Data Reconciliation) in role maintenance, the system displays 

the organizational level “plan version” and only a small number of 

authorization objects from HR in the authorization data. 

Create roles from a SAP role: For example, from the initial role maintenance 

menu with the copy button or within role maintenance on the Menu tab 

page with the From other role button. 

Additional demo: Demonstrate transaction PFUD. The option 

Schedule or check job for full reconciliation refers to the report 

PFCG_TIME_DEPENDENCY. Perform a Manual selection of profiles for the 

ZPFUD role. You can see here that the user TESTPFUD is assigned the role 

ZPFUD, but is not yet assigned the profile. You can do this here. 

Transaction SU10 for mass changes: You can make a selection of 

authorization data for the user groups of the SU01 tab page here using the 

User Group (General) field (for more information about this, see SAP Note 

395690). You can demonstrate here how mass changes are performed, 

such as adding roles. 

A user master comparison determines whether authorization profiles 

should be added to or removed from the current user on the basis of his 

or her role assignment. During a comparison, profiles are added to a user 



master due to roles that have been added. If role assignments are manually 

or time-dependently removed, the corresponding authorization profiles 

are deleted from the user master record. 

The comparison can be performed for every role individually. Select 

the role in role maintenance. Choose the Users tab page and choose 

User Reconciliation. In the dialog box that the system displays, choose 

Complete Reconciliation. 

If multiple role assignments are to be updated, you can perform a 

corresponding comparison in role maintenance by choosing Utilities 

→ Mass comparison (transaction PFUD). You can individually specify 

the desired roles, or update all assignments by entering the asterisk (*) 

character. 

You can also activate the periodic user master comparison in role 

maintenance by choosing Utilities → Mass Comparison. Choose the option 

Schedule or check job for full reconciliation. The system then displays a search 

window for the background job PFCG_TIME_DEPENDENCY. Ifitdoes 

not find a corresponding job, you can create a new one. The default value 

is that all user masters are compared once every day. 

Caution: Do not insert profiles generated in role maintenance 

directly into the user master using transaction SU01. A user master 

comparison deletes all profiles that are not linked to the user 

master record through the corresponding roles. 



363 Exercise 24: Working with Roles 




• Create, copy, and modify roles and assign them to users 


Thesamescenarioasforthelastlesson. 

Task 1 Copy a Role Template 

Copy a role template and assign a user to it. 

1. Select the delivered single role SAP_BC_ENDUSER and copy this 

completely to your own role ZSAP_BC_ENDUSER. 

2. Check the transactions assigned for the user menu with this role. 

3. Check the authorizations of the role, and maintain open 

authorizations if necessary. 

4. Assign the role to the user ADMIN##. 

5. Perform a user comparison. 

Task 2 Create Your Own Role (Optional) 

Create your own role. 

1. Assign the name ZMONITOR## to the role. 

2. Select transactions SM50, SM51, SM04, and PFUD for the user menu. 





Task 3 Assign a Role with Transaction SU01 

Assign a role to user in transaction SU01. 

1. Check in the user master record ADMIN## which roles and profiles 

are assigned. 




2. Assign the role “ZPFUD” to the user ADMIN## using transaction 

SU01. Note that you are making changes in the user master record. 

Task 4 Check User 

Check the user ADMIN##. 

1. Log on to the SAP System as user ADMIN##, then check if the user 

can execute the transactions you assigned. 



Solution 24: Working with Roles 

Task 1 Copy a Role Template 

Copy a role template and assign a user to it. 

1. Select the delivered single role SAP_BC_ENDUSER and copy this 

completely to your own role ZSAP_BC_ENDUSER. 

a) Start transaction PFCG. Place the cursor on the input field 

for roles. Use the F4 help to select the delivered single role 

SAP_BC_ENDUSER. Choose Copy. In the dialog box that 

appears, enter ZSAP_BC_ENDUSER in the To role field and 

choose Copy All. 

2. Check the transactions assigned for the user menu with this role. 

a) Choose Change in the initial screen of transaction PFCG for the 

role ZSAP_BC_ENDUSER. Switch to the Menu tab page. Switch 

to the display of the transaction codes (choose the magnifying 

glass pushbutton) and open the Functions from Basis folder. 



a) Choose the Authorizations tab page and then choose Change 

Authorization Data. Check the authorizations for the role and 

maintain open authorizations if necessary, by, for example, 

clicking the yellow traffic light icon and confirming the system 

query as to whether full authorization should be assigned with 

Execute. Save your profile settings and confirm the dialog box 

by choosing Execute. ChooseGenerate. LeavetheChange Roles: 

Authorizations screen by choosing Back. 


a) Choose the User tab page and enter ADMIN## in the User ID field. 

If user ADMIN## does not exist, create a user with this name in 

transaction SU01 in a new session. 


a) Choose User Comparison and then choose Complete Reconciliation. 

Task 2 Create Your Own Role (Optional) 

Create your own role. 




1. Assign the name ZMONITOR## to the role. 

a) Start transaction PFCG. Enter the name ZMONITOR## in the 

input field for roles and choose the Create Role button. 

2. Select transactions SM50, SM51, SM04, and PFUD for the user menu. 

a) Choose the Menu tab page. Choose the Transaction button and 

enter transactions SM50, SM51, SM04, and PFUD. Then choose 

Assign Transactions. 



a) Choose the Authorizations tab page and then choose Change 

Authorization Data. Enter the value 01 in the From Value column 

for the Plan Version and save this value. Check the authorizations 

for the role and maintain open authorizations if necessary, by, 

for example, clicking the yellow traffic light icon and confirming 

the system query as to whether full authorization should be 

assigned with Execute. Choose Generate and confirm the query 

by choosing Execute. LeavetheChange Roles: Authorizations 

screen by choosing Back. 


a) Choose the User tab page and enter “Admin##” in the User ID 

field. 


a) Choose User Comparison and then choose Complete Reconciliation. 

Task 3 Assign a Role with Transaction SU01 

Assign a role to user in transaction SU01. 

1. Check in the user master record ADMIN## which roles and profiles 

are assigned. 

a) Start transaction SU01. Enter the name ADMIN## in the User 

field and choose Change. Choose the Roles tab page and check 

whether the role “ZSAP_BC_ENDUSER” is entered. Choose 

the Profiles tab page, and check that the corresponding profile 

is entered. 

2. Assign the role “ZPFUD” to the user ADMIN## using transaction 

SU01. Note that you are making changes in the user master record. 

a) Choose the Roles tab page and enter “ZPFUD” in the Role field 

and confirm with Return. Save your entries. 




Task 4 Check User 

Check the user ADMIN##. 

1. Log on to the SAP System as user ADMIN##, then check if the user 

can execute the transactions you assigned. 

a) LogontotheSAPsystemwithyourADMIN##user.Switchto 

the user menu and run some of the assigned transactions. 








ADM100 Lesson: Login Parameters and User Info 

Lesson: 

369 

Login Parameters and User Info 



In this lesson, you learn about important system parameters that are 

important for user administration, for example, for logon behavior. You 

can use the information system to obtain information about any incorrect 

logon attempts. Failed authorization checks are analyzed with the system 

trace. This lesson will also address using central directory services for 

maintainingusermasterrecord,forexample,theaddressdatacontained 

in the records. 





Use RSPFPAR or transaction RZ11 to display a login/* system parameter 

and its documentation. 


Users are having problems due to missing authorizations. The 

administrator can analyze these using system tools. 

Login Parameters 

ThislessondealswithauthorizationsintheSAPsystemfroman 

administrative point of view. Among other thing, the following questions 

are considered: Which system settings can be used to influence logon 

behavior? How can errors and problems be analyzed? 



Figure 137: System Parameters for User Logons 1/2 

You can set the minimum length for passwords with the parameter 

login/min_password_lng. You specify the minimum number of digits, 

letters, orspecial characters that must be included in passwords using 

the parameters login/min_password_digits, login/min_password_letters, and 

login/min_password_specials. Thevaluerangeis0to8. 

The parameter login/password_expiration_time specifies the number of days 

after which a user must set a new password. If the parameter is set to 0, 

the user does not need to change his or her password. 

There are general rules for passwords that cannot be deactivated. A 

password 

• Mustbedifferentfromthelastfivepasswords 

• Mustbeatleastthreecharacterslong 

• Must not begin with “?”, “!”, or “ ” 

• Must not be “pass” 

• Must not begin with three identical characters 

You can define additional password restrictions in table USR40. 

The parameters login/password_max_new_valid and login/password_max_reset_valid 

specify the length of time for which an initial password or a 

password reset by an administrator is valid. 



Figure 138: System Parameters for User Logons 2/2 

Display the login/* parameters and the associated documentation in 

transaction RZ11. 

Caution: Parameters login/password_max_reset_valid and 

login/password_max_new_valid must not be used for releases 

between SAP Basis 4.6A and SAP Web Application Server 6.20. See 


You can set the number of failed logon attempts after which SAP GUI is 

terminated using the parameter login/fails_to_session_end. If the user wants 

to try again, he or she must restart SAP GUI. 

You can set the number of failed logon attempts after which a user is 

locked in the SAP system using the parameter login/fails_to_user_lock. The 

failed logon counter is reset after a successful logon attempt. The users 

locked by failed logon attempts are automatically unlocked by the system 

at midnight (server time). You can deactivate this automatic unlocking 

with the parameter login/failed_user_auto_unlock= 0. The administrator 

can unlock, lock, or assign a new password to users in user maintenance 

(transaction SU01). 

If the parameter login/disable_multi_gui_login is set to 1, a user cannot 

logon to a client more than once. This can be desirable for system 

security reasons. If the parameter is set to 1, the user has the following 

options when he or she logs on again: “Continue with this logon and 

end any other logons in the system” or “Terminate this logon”. Users 

to whom this should not apply should be specified in the parameter 

login/multi_login_users, separated with commas, and with no spaces. 



Determining User Information 

Figure 139: Information System 

Display which user is assigned the role ZPFUD. Display users with 

incorrect logon attempts and locked users. Display the last logon date 

of users. 

You can call the Information System (transactionSUIM) in the SAP Menu 

by choosing Tools → Administration → User Maintenance → Information 

System or in user maintenance (transaction SU01) by choosing Information 

→ Information System. 

You can obtain an overview of user master records, authorizations, 

profiles, roles, change dates, and so on using the information system. 

You can display lists that answer very varied questions. For example: 

• Which users have been locked in the system by administrators or 

failed logon attempts? 

• When did a user last log on to the system? 

• Which changes were made in the authorization profile of a user? 

• In which roles is a certain transaction contained? 



Figure 140: System Trace for Authorizations 

System Demo: Tools → Administration → Monitor → Traces → System Trace 

(ST01, since SAP Web AS 6.10, it is intuitive to use). Check authorization 

check, if appropriate select Filter. Activate the trace and perform an action 

in a second session. Deactivate the trace and evaluate it. The checked 

values are in the text field. 

You can open a view with a different format by double clicking. On this 

view, there is a button with which you can go to the checkpoint in the 

coding. 

You should discuss transaction SU56 and SU53 at this point. In particular, 

you should address the possibility for an administrator to display the 

failed authorization checks of other users. 

You can display the last failed authorization check (transaction SU53) by 

choosing System → Utilities → Display Authorization Check. The system 

displays the most recently checked authorization object for which the 

authorization check was unsuccessful with the checked values. All 

authorizations that the user has for this authorization object are also 

displayed. If a user authorization is displayed that contains the checked 

values, the user has not logged on again since new authorizations were 

assigned to him or her. 

The system administrator can use transaction SU53 to check which 

authorizations were missing for a user for the execution of his or her last 

(unsuccessful) action. 



You can record authorization checks in your own and other sessions 

using the system trace function Tools → Administration → Monitor → 

Traces → SAP System Trace (transaction ST01). All checked authorization 

objects including the checked values are recorded here. The system trace 

is suited to finding multiple missing authorizations. The system trace is 

activated for the authorization check of a special user who has all required 

authorizations for the actions to be checked. The actions are performed 

with this special user. The trace records all authorization checks. These 

can then be evaluated. 















ADM100 Lesson: Appendix - Advanced User Administration Topics 

Lesson: 

374 

Appendix - Advanced User Administration 

Topics 



In this lesson, you will obtain an overview of Central User Administration 

and connections to directory services. These topics are dealt with in detail 

in SAP course ADM102. 





This lesson is not discussed during the training course. It is simply 

additional information for the participants. The topics addressed are 

presented in detail in SAP course ADM102. 


You want to structure the user administration in your company more 

efficiently by centralizing it. 



Central User Administration 

Figure 141: Central User Administration 

The concept of CUA is explained, and connecting a directory service to 

anSAPsystemisoutlined. 

Directory services are also commonly known as LDAP servers. Strictly 

speaking, this is not correct, since LDAP is only a protocol with which it is 

possible to access directory services. 

Both of these topics are dealt with indetailinSAPcourseADM102. 

If you are operating multiple SAP systems with a number of clients, 

and identical users are created a number of times in different clients, 

you can significantly reduce your administrative effort for user 

administration using Central User Administration (CUA). You can 

perform user maintenance centrally from one client with CUA. This client 

is then described as the “central system”. The clients for which user 

administration is performed from the central system are called “child 

systems”. 

You can specify for every user which clients it can log on to. Using CUA 

does not mean that all users can be used in all clients of the system 

landscape. 



You can also specify which user data can only be maintained centrally 

and which data can also be maintained locally. It is sometimes useful to 

allow data to be locally maintained by the users or by an administrator. 

Local maintenance with distribution to all other clients is also possible (for 

example, in the case of address data being changed). 

The user master data is exchanged using ALE. ALE stands for 

“Application Link Enabling”, and is a technology for setting up and 

operating distributed SAP applications. ALE allows the process-controlled 

exchange of business messages between loosely connected SAP systems. 

Asynchronous processing of the communication ensures that application 

operation is error-free. 

SystemsthatyouwanttoincludeinaCUAmusthaveatleastSAPBasis 

4.5. 

Figure 142: Which Data Can Be Distributed? 

The following data can be distributed using Central User Administration 

(CUA): 

• User master records: Addresses, logon data, user defaults, and user 

parameters 

• Users are assigned the associated single and composite roles and 

profiles for all child systems. Using CUA has the advantage that you 

no longer need to log on to each individual client to maintain these 

assignments locally. 



• Initial password: When users are newly created, an initial password 

is transferred to the child systems. This can be changed in the usual 

way. 

• Lock status: In addition to the familiar lock reasons (failed logon 

attempts or locked by an administrator) there is a new “general lock”. 

This takes effect in all child systems in which the affected user is 

permitted and can be removed either centrally or in an individual 

child system. 

You can assign Single or composite roles and authorization profiles from 

the central system. However, the authorization profiles are maintained 

locally rather than centrally, since different system settings and release 

statuses require local administration of authorization profiles. 

Note: With central role maintenance, you can define the menu 

of a role in an SAP system for a different target system. The 

authorization profiles are always to be maintained in the target 

system. You can implement the CUA and central role maintenance 

concepts together or independently. 

Central User Administration is discussed in detail In SAP course ADM102 

- SAP Web AS Administration II. 

Directory Services 

Figure 143: Connection to Directory Services 



Directory services allow various applications in an IT landscape to access 

shared information at a central location. The information is stored on a 

central directory server that the various systems of your IT landscape can 

access. In this way, the directory server acts as an “IT address book” for 

information that is usually used in common, such as personnel data (name, 

department, organization), user data, and information about system 

resources and system services. You can use directory services to maintain 

information in SAP systems for directory-compatible applications (such as 

user administration or Business Workplace). The standardized Lightweight 

Directory Access Protocol (LDAP) is usually used as the access protocol. 

Directory services provide a central information and administration 

point and therefore simple shared information usage between various 

applications. Your SAP system can exchange data with directory services 

using the LDAP protocol. You specify the synchronization direction for 

each field, that is, whether the SAP system overwrites the data in the 

directory, or the directory overwrites the data in the SAP system. 

The SAP system can exchange data with directory services from various 

vendors. The SAP system may require attributes that are not in the 

standard schemata of the directories. SAP usually provides a schema 

extension for this purpose. 

Note: As of SAP Web AS 6.10, SAP systems can easily connect to a 

directory service. It was possible to connect to a directory service 

before SAP Web AS 6.10, although rather more effort was involved. 

Hint: A connection to a directory service can extend a Central User 

Administration. That is, these two concepts are in no way mutually 

exclusive, but rather work together very well. 

The topic of central directory services/LDAP is dealt with in detail in SAP 

course ADM102 - SAP Web AS Administration II. 















• SAP courses 

– ADM940 (CA940) - SAP Authorization Concept 



Unit Summary 











381 


1. How are authorizations assigned to a user? 


A Users are assigned authorizations using profiles. 

B Users are assigned authorizations using roles. 

C Users are assigned authorizations using user names. 

D Users are assigned authorizations using a Certification 

Authority. 

2. The SAP authorization concept is a positive concept because ... 


A every user automatically receives all authorizations. 

B authorizations must be explicitly assigned. 

C the range of features of the authorization check is so large. 

D the developers programmed it efficiently. 

3. System parameters for the user logon are in the area login login. To 

display user’s incorrect logon attempts, call the Information System 

with transaction SUIM SUIM. The system trace function is called 

using transaction ST01 ST01. 




382 

Answers 

1. How are authorizations assigned to a user? 

Answer: A, B 

Authorizations are combined into profiles. The roles assigned to 

users contain profiles with appropriate authorizations for the role. 

Authorizations are not assigned using user names or a CA. 

2. The SAP authorization concept is a positive concept because ... 

Answer: B 

SAP uses a positive authorization concept. This means that 

everything that is not explicitly allowed is automatically forbidden. 

3. System parameters for the user logon are in the area login. To 

display user’s incorrect logon attempts, call the Information System 

with transaction SUIM. The system trace function is called using 

transaction ST01. 

Answer: login, SUIM, ST01 

User logon settings are implemented using the login/* parameter. 

The Information System is called with transaction SUIM, the system 

tracefunctionwithST01. 


Unit 12 

383 Setting Up Remote Connections 

The participants obtain an overview of the configuration of RFC 

destinations using transaction SM59 and learn about the different types 

of RFC and their use. 

The unit is divided into two parts: A specific part about using transaction 

SM59, in which the aim is to enable participants to successfully create an 

RFC destination. A general part deals with the other possibilities for using 

RFC connections in the SAP environment. 

Unit Overview 

In this unit, you will learn about remote connections, also known as 

Remote Function Calls (RFC). In addition to the different types of RFC, 

you will learn about the technical setting up of connections of this type. 



• Explain the principle of the Remote Function Call 

• List the different types of Remote Function Call 

• Set up an RFC connection 

• Monitor RFC connections 

Unit Contents 

Lesson: Fundamentals and Types of RFC ..................................450 

Lesson: Setting Up RFC Connections .......................................457 

Exercise 25: Set up Remote Connections ..............................461 


Unit 12: Setting Up Remote Connections ADM100 

Lesson: 

384 

Fundamentals and Types of RFC 



This lesson will provide you with an overview of Remote Function Calls. 





The instructor should know that asynchronous RFCs can be used to process 

background jobs in parallel (the application must already be programmed 

in a way that allows this). A report that runs in the background starts a 

processing step in a new work process: a free dialog work process. This 

canbedoneanumberoftimes.However, this is an exceptional situation, 

in which a work process is subordinated or assigned or to another. 


SAP systems can communicate with each other using Remote Function 

Calls. A prerequisite for this is that the administrator has set up the 

relevant interface system. 

RFC Fundamentals 

Remote Function Calls are the technical interface with which SAP and 

non-SAP systems can be networked with each other in the context of 

the “Enterprise Services Architecture”. It is irrelevant whether the data 

exchange it to be synchronous or asynchronous, periodic or aperiodic, or 

transactional. All conceivable variants are supported. 


ADM100 Lesson: Fundamentals and Types of RFC 

Figure 144: The RFC Interface 

Describe at this point how systems exchange data with each other with a 

Remote Function Call (RFC) using standardized communication routines. 

These communication routines are provided using an interface. This 

performs the conversion of the parameter data, calls the communication 

routines, and handles errors. 

A Remote Function Call is a call of a function module that is running in a 

different system to the calling program. You can also call a function module 

in the same system as an RFC; however, RFCs are usually used when the 

calling and called function modules are running in different systems. 

In the SAP system, the RFC interface system provides this function. The 

RFC interface system allows function calls between two SAP systems or 

between an SAP system and an external (non-SAP) system. 

RFC is an SAP interface protocol that is based on CPI-C and allows 

cross-host communication between programs. This means that ABAP 

functions can be called from external applications and tools, and that 

external applications can be called from the SAP system. 

RFC means that the ABAP programmer does not have to write his or her 

own communication routines. For an RFC call, the RFC interface 

• Converts all parameter data to the format required in the remote 

system 



• Calls the communication routines that are required to communicate 

withtheremotesystem 

• Handles errors that occur during the communication 

The RFC interface is easy for the ABAP programmer to use. The 

processing steps for calling external programs are integrated into the 

CALL FUNCTION command. 

Figure 145: RFC Connections 

Demonstrate how the connections to other systems are grouped within 

destinations by connection type in the SAP system. Individual connections 

can be selected using a search function. 

To be able to call a function module on a remote system, you must define 

theremotesystemasadestinationinyour calling system. You also require 

access authorization for the remote system. 

You can administer these remote connections in the calling system. To 

do this, call the Display and Maintain RFC Destinations screen, either 

by choosing the menu path Administration → System Administration → 

Administration → Network → RFC Destinations or by calling transaction 

SM59directly. The connection types and all existing destinations are 

displayed in a tree structure on the initial screen. For details about all 

available connection types, see the documentation. 

There is a search function for destinations that have already been set up. 

To search for a destination, choose Find and enter your selection. The 

system displays a list of all matching entries. You can display all available 

information for each entry. 



To change an existing RFC destination, choose the relevant RFC destination 

inthemenutreeandchooseChange. 

Overview: Types of RFC 

Synchronous RFC (sRFC) 

For communication between different systems and between SAP 

Web AS and SAP GUI 

asynchronous RFC (aRFC) 

For communication between different systems and for parallel 

processing of selected tasks. 

transactional RFC (tRFC) 

A special form of asynchronous RFC. Transactional RFC ensures 

“transaction-like” processing of processing steps that were originally 

autonomous. 

queue(d) RFC (qRFC) 

Queued RFC is an extension of tRFC. It also ensures that individual 

steps are processed in sequence. 

FastRFC 

FastRFC is used for internal server communication between a SAP 

J2EE Engine and an ABAP runtime environment within an instance. 

“RFC” is a superordinate term for various implementation variants. sRFC 

is the synchronous call of function modules. This means that the client 

waits until the server has completed its processing. In an SAP system, 

an RFC can also be performed asynchronously in another work process. 

This variant is called aRFC. 

There is also tRFC, the transactional Remote Function Call. Transactional 

RFC is asynchronous and ensures that data that is sent more than 

once due to network problems can be recognized at the server side, by 

assigning a Transaction Identifier (TID). This allows you to prevent data 

being processed more than once, leading to erroneous information in the 

application. Due to the asynchronous processing, however, parameters 

can only be transferred from the client to the server in this case. Returning 

information or status information directly is not possible. 

qRFC with Send Queue is an extension of tRFC. It creates a layer between 

applications and the tRFC and only allows the tRFC to transfer a Logical 

Unit of Work (LUW) to the target server when its predecessors are no 

longer in the associated wait queues. After a qRFC LUW is executed, the 

qRFC manager automatically processes the next waiting qRFC LUW in 

accordance with the sequence in the wait queue. 



FastRFC, unlike the other communication variants of RFC that have been 

introduced, is not used for communication between different systems, but 

rather for data exchange between the SAP J2EE Engine and the ABAP 

runtime environment of a SAP Web AS. 















ADM100 Lesson: Setting Up RFC Connections 

Lesson: 

389 

Setting Up RFC Connections 



In this lesson, you will learn how to set up a remote connection. 





You should not go into detail in answering questions about trusted RFC, 

unless you are very familiar with the topic. This topic was previously dealt 

with in SAP course BC305, and is now discussed in SAP course ADM960 - 

Security in SAP System Environments. 


Functions from different SAP systems must be linked with each other in 

the context of an e-commerce scenario, so that, for example, additional 

processing is performed on posting documents in another system. 

Remote Connections 

DiscusswiththeparticipantswhichdataisrequiredtosetupanRFC 

connection: connection type, host name of the target system, system 

numbers, and logon data. Emphasize that the target of a remote connection 

is always a single client, and not an entire system. You can therefore 

define twenty connections AB_### from A to B, each of which points to a 

different client. 

To create a new RFC destination, choose the Create button in transaction 

SM59 (Tools → Administration → Administration → Network → RFC 

Destinations). The system displays a new screen with empty fields that 

you must fill out. 



Figure 146: Setting Up an RFC Connection 

The system opens the dialog for creating a new RFC destination. Enter a 

name for the destination, the connection type 3, and a short description. 

Choose Save. The system stores your entries and switches to the technical 

settings screen. 

Enter the target host and the system number of the system and choose 

Save (Control+S). 

For a quicker logon, you can specify a client, user name, and password 

for logon to the target system in the Logon/Security tab page. Do not user 

your own user data here, but rather general user data, as every user (with 

the appropriate RFC authorizations) can use the RFC destination that 

you create. 

For security reasons, you should leave these fields empty, or enter a user 

ofthetype“Communication”withvery specific (that is, adjusted to the 

requirements) authorizations. In the first case, the system displays an 

input prompt for logon when you later create a connection; in the second 

case, dialog logons to the system are not possible, although programs can 

use the connection to communicate. 



Figure 147: Testing RFC Connections 

Explain the options for testing a connection. 

System Demo: Create an RFC connection to the QAS system on your host 

in transaction SM59 and test the connections using both of the methods 

described below. 

You have two options for testing a destination: 

• You can attempt to log on to the remote system. To do this, choose 

Remote Login. A new session is opened for the remote system. Enter 

the client, your user name and your password. If you have stored 

a dialog user with password in the connection, a dialog logon is 

performed. If you have stored a communication user, you can check 

that the specified password is correct with the function Test → 

Authorization in transactionSM59. 

• Withaconnectiontest(Test Connection button), the system attempts 

to create a connection to the target system and displays a table with 

response times. If an error message appears, check your settings. 





393 Exercise 25: Set up Remote Connections 




• Create and monitor a remote connection 


As an administrator, you are to set up remote connections to other systems, 

which are then to be used, for example, in the context of an ALE integrated 

system. 

Task 1 Create a Remote Connection 

Set up a remote connection. 

1. You are to set up a remote connection to the second system on your 

server, to client 100. 

Result 

The group that is using the DEV system sets up a connection to the 

QAS system. 

The group that is using the QAS system sets up a connection to the 

DEV system. 

Todothis,getthedetailsofauserwithpasswordonthetargetsystem 

from your partner group. 

You have created an RFC connection. 

Task 2 Test the Remote Connection 

Test the remote connection that you have created 

1. Test the connection. 

2. Attempt to log on to the remote system. Use the function Test → 

Authorization. 

Result 

The RFC connection that you created works correctly. 




Task 3 Use Load Balancing (Optional) 

Use the load balancing for an RFC connection. 

1. Create an additional RFC connection to your partner group’s system. 

Call this connection _GROUP. Use the option for load balancing, 

by logging on using a logon group, for this connection. To do this, 

you require the name of the logon group that your partner group set. 

Alternatively, you can use the default group SPACE. 

Result 

You can now successfully set up an RFC connection using load 

balancing. 



Solution 25: Set up Remote Connections 

Task 1 Create a Remote Connection 

Set up a remote connection. 

1. You are to set up a remote connection to the second system on your 

server, to client 100. 

Result 

The group that is using the DEV system sets up a connection to the 

QAS system. 

The group that is using the QAS system sets up a connection to the 

DEV system. 

Todothis,getthedetailsofauserwithpasswordonthetargetsystem 

from your partner group. 

a) To set up a remote connection, switch to the window Display and 

Maintain RFC Destinations. To do this, choose Administration → 

Administration → Network → RFC Destination (transaction SM59) 

and choose Create. Enter a name for the destination (such as 

_DATA, the connection type 3, and a short description. 

Choose Save. 

Under Technical Settings, enter the name of the host in the Target 

host field, and the instance number of the target system (your 

partner group’s system) in the System number field. 

On the Logon/Security tab page, enter client 100 and the user for 

the remote system with its password that you received from 

your partner group. 

You have created an RFC connection. 

Task 2 Test the Remote Connection 

Test the remote connection that you have created 

1. Test the connection. 

a) Choose Test Connection. The system attempts to create a 

connection to the remote system, and, if the connection is 

correctly set up and the target system is accessible, displays a 

list of response times. 




2. Attempt to log on to the remote system. Use the function Test → 

Authorization. 

Result 

a) Choose the Remote Login button. The system opens a new session 

for the SAP system, if the connection is correctly set up. If you 

have not defined any user data when setting up the connection, 

enter client, user name and password now. Choose Test → 

Authorization. If you have stored the correct logon data, this test 

is performed without an error message. 

The RFC connection that you created works correctly. 

Task 3 Use Load Balancing (Optional) 

Use the load balancing for an RFC connection. 




1. Create an additional RFC connection to your partner group’s system. 

Call this connection _GROUP. Use the option for load balancing, 

by logging on using a logon group, for this connection. To do this, 

you require the name of the logon group that your partner group set. 

Alternatively, you can use the default group SPACE. 

Result 

a) Call the maintenance transaction for RFC connections (Tools → 

Administration → Administration → Network → RFC Destinations, 

transaction SM59). 

Choose Create. Enter the following values: 

• RFC Destination: _GROUP (replace with the 

of your partner group’s system) 

• Connection type: 3 

• Description: Any documentation. 

• Choose Enter. 

• Select the radio button Load distrib.: Yes 

• Target host: The host of your partner group. 


• Group: Logon group that your partner group set up or the 

default group SPACE. 

On the Logon/Security tab page, enter the logon information that 

you received from your partner group. 

Choose Save. 

You can now successfully set up an RFC connection using load 

balancing. 









Unit Summary 










401 


1. WhichRemoteFunctionCallproceduresdoesanSAPsystem 

provide? 


A synchronous RFC 

B reflexive RFC 

C looped RFC 

D transactional RFC 

E cut-through RFC 

F queued RFC 

2. Which RFC variant can you use to process work steps in parallel? 

3. To connect two SAP systems by RFC, you require an 

RFC interface RFC interface in each system (this automatically exists) 

and a defined RFC connection RFC connection from one system to 

the other. 




402 

Answers 

1. Which Remote Function Call procedures does an SAP system 

provide? 

Answer: A, D, F 

In addition to the three correct answers (synchronous, transactional, 

and queued RFC), the system also provides asynchronous RFC and 

FastRFC. 

2. WhichRFCvariantcanyouusetoprocessworkstepsinparallel? 

Answer: You can use asynchronous RFC to process program steps in 

parallel,aslongasthereareworkprocesses available in the system. 

3. To connect two SAP systems by RFC, you require an RFC interface in 

each system (this automatically exists) and a defined RFC connection 

from one system to the other. 

Answer: RFC interface, RFC connection 

The basic requirement is the RFC interface, which is in the protocol 

stack of every SAP system. You must also set up a connection from 

the calling system to the called system (transaction SM59). 


Unit 13 

403 System Monitoring 

This unit acts as an introduction to system monitoring. The ADM106 

course is useful for preparation and for providing a deeper insight into 

the material. The participants are to learn about the basics of monitoring 

and using transaction RZ20. 

Unit Overview 

This unit acts as an introduction to system monitoring. You will first 

learn about the basics of the monitoring architecture and how to use the 

CCMS Alert Monitor. This unit also deal with creating your own monitors, 

including remote systems, and maintaining threshold values. 



• Explain the concepts of the CCMS Alert Monitoring Infrastructure 

• Use the CCMS Alert Monitor to monitor your system 

• Configure the central monitoring of remote systems 

• Design and create your own monitors 

• Activate threshold values that are suitable for your system 

environment 

Unit Contents 

Lesson: Monitoring Architecture ..............................................472 

Exercise 26: System Monitoring..........................................483 

Lesson: Including Remote Systems..........................................487 

Exercise 27: Include Remote Systems ..................................491 

Lesson: Creating Your Own Monitors ........................................495 

Exercise 28: Create Your Own Monitors.................................501 

Lesson: Properties Variants and Threshold Values ........................506 

Exercise 29: Properties Variants of Monitors ...........................511 


Unit 13: System Monitoring ADM100 

Lesson: 

404 

Monitoring Architecture 



This lesson will provide you with an introduction to monitoring as a 

significant component of the Computing Center Management System 

(CCMS). Terms such as monitoring tree element (MTE), monitoring object, 

and monitoring attribute will be discussed in detail. 





This lesson introduces the participants to the architecture and terminology 

of monitoring. 


You want to ensure good performance for the processing of business 

processes. You therefore regularly monitor the SAP systems, and take 

preventative action if required. 

Basics 

Clarify the reasons for preventative system monitoring with the 

participants. Note that acute performance problems can also be dealt with 

using the monitoring infrastructure. Lead the participants to the desire for 

central monitoring of a complex and extensive system landscape. 

Initial questions about monitoring: 

• Why? 

– To ensure the efficient processing of business processes 

– To ensure system security and stability 

• How? 

– Central and cross-system 


ADM100 Lesson: Monitoring Architecture 

– Withanalertifanerroroccurs 

– With help that provides cross-system detailed information if an 

error occurs 

– With the help of the CCMS Alert Monitoring Infrastructure and 

the special transactions connected to it 

Many components are involved in the processing of a business process 

in the mySAP Business Suite. These components must be monitored, as 

both a gradual reduction in performance and a sudden breakdown of a 

component could susceptibly affect the entire productivity. It is a task of 

the administrator to monitor the system landscape regularly, and not only 

inthecaseoferrors,buttotakepreventativeaction. 

For example: 

A file system in which files of the SAP database are stored is 100% 

full. The database can no longer extend the tables in the files. A user 

performs a business transaction in the context of which a data record 

should be asynchronously added to one of these tables. The insert 

fails due to the space problem in the file system. The database error 

is seen as so serious that the entire asynchronous update process is 

automatically deactivated. All user sessions hang with the display 

of the hour glass. The SAP system hangs. If the fill level of the file 

system had been regularly checked, the administrator could have 

created space in other file systems and avoided the system downtime. 

Monitoring should be organized as efficiently as possible. There is not 

enough time for an administrator to log on to each host component to 

check its status. An efficient monitoring structure should be able to display 

the entire system landscape at a glance centrally. If an error occurs, the 

person responsible is automatically notified. Tools should be provided 

for the analysis of errors that provide cross-system detailed information 

about the problem. 



Figure 148: Central Monitoring 

A central SAP system, which should have as high a release status as 

possible, allows you to easily monitor a large number of components, for 

example, using agent technology (these are not SNMP agents). Note that 

the data for the remote systems is only read by the central RZ20, that is, the 

data is actually stored “on site”. Analysis methods can also be executed 

remotely. 

Hint: The monitoring segment data is stored at file level 

(DIR_LOGGING, AL*) during an instance shutdown (and 

periodically every 30 minutes) and then loaded back into the 

shared memory during a restart. 

The CCMS Alert Monitoring Infrastructure provides you with the 

possibility of monitoring a mySAP Business Suite efficiently and centrally. 

Theinfrastructuremustbeinstalledoneverycomponentthatistobe 

centrally monitored. This is automatically the case for SAP R/3 4.x 

Systems. SAP R/3 3.x Systems and components on which no SAP system 

is active are connected using CCMS agents. 



Each component collects its own monitoring data using the infrastructure 

and stores it locally in the main memory. This part of the main memory 

is called the monitoring segment. You can configure the size of the 

monitoring segment. 

AnSAPsystemisselectedasthecentralmonitoringsystem. Itshould 

have as high a release status as possible (at least SAP R/3 4.6C) and a high 

level of availability. In large system landscapes, we recommend that you 

include a separate system that is used only special tasks such as central 

monitoring, Central User Administration, transport domains controller, 

or the SAP Solution Manager. From a performance point of view, the 

workload of the central monitoring system increases only insignificantly, 

as the collection of monitoring data is usually decentralized. 

The central monitoring system collects the monitoring data for the 

components and displays it in various views. In this way, the administrator 

has a central view of the entire system landscape. If errors occur, the 

administrator can jump directly from the central monitoring system to the 

appropriate component to correct a problem in a detailed analysis. 

Details 

The monitoring segment (in shared memory) is provided with a large 

q uantity of data about the system by different types of data collectors 

(active/passive). You can use either transaction RZ20 or the SAP Solution 

Manager to read and display the data. SAP also provides interfaces that 

allow external tools (such as HP Open View) to access this data. 

Definition of active/passive: An active data collector automatically collects 

data without an external trigger, for example the dispatcher. A passive 

data collector collects data due to a trigger, for example through the report 

SAPMSSY8, which runs every five minutes. 

The CCMS Alert Monitoring Infrastructure consists of three parts: Data 

collection, data storage, and administration. 



Figure 149: CCMS Alert Monitoring Infrastructure in Detail 

At the data collection level, small subareas of the mySAP Business Suite 

are monitored by special programs called data collectors. Data collectors 

can be ABAP, C, or Java programs. There are over 100 data collectors 

in ABAP alone. Each data collector checks its subcomponent at regular 

intervals and stores the collected monitoring data in the main memory of 

its host. 

At the data storage level, the area of the main memory that contains the 

monitoring data from the data collector is called the monitoring segment. 

As the main memory data is always overwritten, it can be permanently 

copied to database tables. You can then analyze the data later. The data 

collection and storage elements must be present on every component that 

is to be centrally monitored. 

The administration level allows the display and evaluation of the data 

from the monitoring segment. SAP provides an expert tool, the CCMS 

Alert Monitor (transaction RZ20) as a display transaction. Alternatively, 

you can use the SAP Solution Manager to display the data in a business 

process-oriented context. If the system identifies a problem, it can execute 

an auto reaction, such as informing the responsible person. The analysis 

method then helps you to investigate the problem. 

The CCMS Alert Monitoring Infrastructure can be extended. You can 

integrate your own components using data collectors that you have written 

yourself. Third-party vendors and partners can export the monitoring data 

from the monitoring segment using various interfaces. 



Figure 150: Monitor Structure 

The monitoring tree consists of monitoring tree elements (MTEs), which 

are divided into “structural” elements (which do not have a “data 

equivalent” in the monitoring segment), monitoring objects (physical 

objects such as CPU or buffer) and their attributes (such as Utilization or 

Hit Rate). Every objects has at least one attribute. Attributes always have a 

(passive or active) data collector, which may have to be explicitly activated 

(for example, for ALE and SAPconnect). 

The CCMS Alert Monitor (transaction RZ20) displays the monitoring data 

from the monitoring segment in a tree structure. The tree structure allows a 

clear display when you are displaying a large number of measured values. 

Any node in the tree is called a Monitoring Tree Element (MTE). 

The measured values that are collected by the data collectors are displayed 

at the lowest level in the leaves of the tree. The leaves are called monitoring 

attributes. 

Threshold values can be stored for a monitoring attribute. SAP delivers 

default threshold values. However, in order to customize the monitor as 

well as possible for your system environment, you should check these 

threshold values, and adjust them if required. 

Monitoring attributes are bundled using monitoring objects at the 

second-lowest level. For example, the monitoring object program buffer 

contains, among others, the attributes hit rate and swap. 

All nodes at higher levels in the tree serve to structure the monitoring 

objects in a logical and clear way, so that you can easily find the monitoring 

attribute that you require. 



A CCMS monitor displays different subareas of the monitoring data. A 

monitor can contain data from multiple SAP systems. 

Figure 151: The CCMS Alert Monitor 

A monitor always provides a view of the data of one or more monitoring 

segments. The same data can be displayed in different monitors. The 

delivered SAP monitors should always be used only as templates. The 

copied monitors are then adjusted to the customer’s requirements. 

The CCMS Alert Monitor is started by calling transaction RZ20. Choose 

Tools → CCMS → Control/Monitoring → Alert Monitor from the SAP Easy 

Access menu. 

SAP delivers the Alert Monitor with preconfigured monitor sets that you 

can use immediately. Every monitor set bundles monitors that display 

various parts of the entire monitoring architecture, by topic area. It is 

therefore easier, for example, to find the “database” area. 

The delivered monitor sets can be different for each system. A mySAP 

CRM system contains, for example, a special set for monitoring the CRM 

scenario. There are, of course, special data collectors connected with this 

that SAP delivers preconfigured with a mySAP CRM System. 



The monitoring data that monitors display can overlap. This means that 

the monitoring attribute hit rate of the program buffer can appear in several 

monitors. If you change, for example, the threshold value for this attribute 

in one of these monitors, it is changed in all monitors. 

Some monitors, such as the monitor Availability: Selected Systems in the 

monitor set SAP CCMS Monitor Templates do not initially display any data. 

This can be due to the fact that special settings are required to start the 

underlying data collectors. 

To begin with, you will use the preconfigured monitors. Later, you can also 

create your own monitors that display exactly the data that you require for 

your daily monitoring work. 

You can open a monitor by double clicking its name. 

Figure 152: Layout of a Monitor 

Every monitor can be displayed in different views: Open Alerts and Current 

Status. Explain the different double click behavior of the attributes and 

demonstrate a few attributes, such as Program Buffer Hit Rate. Demonstrate 

the functions of the Details button. You should also explain the function 

of the F1 help for an attribute. The contents of the F1 help can be edited 

and requires a modification. 



After you have opened a monitor, the corresponding monitoring data is 

displayed in the form of a tree. By clicking the “+” sign beside an MTE, 

you can expand the tree down to its leaves; the monitoring attributes. 

Alert threshold values for triggering yellow and red alerts are assigned to 

monitoring attributes. If the threshold value condition is fulfilled, first a 

yellow, and then, if there is further deterioration, a red alert is triggered. 

The color of the monitoring attribute is propagated to its parent node in 

the tree, where the most sever alert is forwarded (red is more severe than 

yellow). This means that you can determine whether there is an alert in 

thetreefromtherootofthetree. 

Views 

The monitor should support you in your daily work. After you have 

opened the monitor, there are two views available to you: 

• The Current Status view displays the monitor with the newest 

reported data. 

• The Open Alerts view displays the monitor with its history 

information. 

For example, there may have been problems during the previous night 

that are no longer occurring. In the Current Status view, the monitoring 

attribute is green, while it is displayed as red in the Open Alerts view. 

After you have ensured that there are currently no problems, you can 

then investigate problems that have previously occurred. You can see the 

selected view in the upper part of the monitor. You can switch views by 

choosing the Current Status or Open Alerts buttons. 



Figure 153: The Alert Browser 

Demonstrate working with alert messages with an example. Emphasize 

that the completed messages can still be displayed using the Alert History. 

These alerts are no longer stored in the monitoring segment, but rather in a 

database table (ALALERTDB).Thistableshouldberegularlycleanedup 

(report RSALDBRG). 

Caution: Neither the information about this table nor about the 

report necessary belong in this course. You should regard this as 

expert information available to be able to answer specific questions; 

the information comes from SAP course ADM106. 

You can easily process the alerts that occurred in the past in the Open 

Alerts view. By double clicking an MTE in the tree, you open the Alert 

Browser, which displays a list of all alerts for the selected MTEs and all 

alerts below it in the tree. This means that if you double click the root of 

the tree, the system displays a list of all alerts in the tree, sorted by red 

and yellow alerts. 

Select an alert that you want to process. Then choose the Start Analysis 

Method button. This starts the analysis method that is assigned to the MTE. 

The analysis method is a special tool that supports you when investigating 

problems. It can be transactions, or specially programmed function 



modules, or URL calls. You therefore do not need to remember all of the 

special tools, but simply use the CCMS Alert Monitor as a central point 

of entry. 

After you have clarified the problem situation, choose F3 to return to 

the Alert Browser. Then choose Complete Alerts. The processed alert is 

removed from the list and is stored in a database table. 

Proceed in the same way with the remaining alerts, until the list is empty. 

When you next use your monitor, only the newly-occurred alerts are 

displayed. 

If you want to display completed alerts again, choose Show Alert History in 

the Alert Browser. Completed alerts are displayed with the status Done. 



413 Exercise 26: System Monitoring 




• Evaluate and process alerts in the Alert Monitor 


You want to ensure good performance for the processing of business 

processes. You therefore regularly monitor the SAP systems, and take 

preventative action if required. 

Task The CCMS Alert Monitor 

1. Start the CCMS Alert Monitor (transaction RZ20). 

2. Open the Entire System monitor from the SAP CCMS Monitor Templates 

monitor set. 

3. What is the current average dialog response time? 

4. Switch to the Open Alerts view. 

5. Select all alerts that have occurred in the Dialog area. 

6. Process an alert from this list: 

Start the analysis method for an alert. 

Return to the Alert Browser and complete the alert. Does the alert still 

appear in the list? 

How can you display the completed alert again? 



Solution 26: System Monitoring 

Task The CCMS Alert Monitor 

1. Start the CCMS Alert Monitor (transaction RZ20). 

a) Call the CCMS Alert Monitor (Tools → CCMS → 

Control/Monitoring → Alert Monitor, transaction RZ20). 

2. Open the Entire System monitor from the SAP CCMS Monitor Templates 

monitor set. 

a) Expand the SAP CCMS Monitor Templates setbychoosingthe“+” 

sign beside the set. Double click the Entire System set. 

3. What is the current average dialog response time? 

a) You can find the monitoring attribute for the average dialog 

response time by expanding, for example, the branch → 

R/3 Services → Dialog → . Note that the monitor is in 

the Current Status view. 

4. Switch to the Open Alerts view. 

a) Choose Open Alerts. 

5. Select all alerts that have occurred in the Dialog area. 

a) Double click the Dialog MTE. All alerts in this area are displayed 

in the Alert Browser. 

6. Process an alert from this list: 

Start the analysis method for an alert. 

Return to the Alert Browser and complete the alert. Does the alert still 

appear in the list? 




How can you display the completed alert again? 

a) Select an alert in the list. Then choose the Start Analysis Method 

button. The system jumps from the monitor to a function that 

provides you with detailed data about the alert. 

Return to the monitor. Choose Complete Alerts. Thealertis 

removed from the list. 

To display the alert again, choose Show Alert History. Your 

completed alert has the status DONE. 

Hint: It is possible that the system displays other alerts 

with the status AUTO_COMPLETE. These alerts were 

completed automatically by the system to keep the alert 

area free for new alerts. 








ADM100 Lesson: Including Remote Systems 

Lesson: 

417 

Including Remote Systems 



In this lesson, you will learn how to include remote system in alert 

monitoring. 




The participants are to learn how to include and monitor remote systems. 


As an administrator, you want to include remote systems in your alert 

monitoring. 

Including Remote Systems 

The monitors delivered by SAP display more detailed monitoring data 

for the local SAP system. Central monitoring, on the other hand, has the 

advantage that you can monitor the entire system landscape, and not just 

your local system. 

You can monitor all components that have a CCMS Alert Monitoring 

Infrastructure. SAP has delivered the infrastructure since SAP R/3 4.0. 

To be able to include components that do not have an infrastructure, 

you can use the CCMS agent programs SAPCM3X for SAP R/3 3.x and 

SAPCCMSR for non-SAP components. 



Figure 154: Including Remote Systems 

In the context of monitoring, it is possible to read from remote monitoring 

segments. An RFC connection is required to do this. You can specify an 

additional RFC connection to start analysis methods. You can also use a 

non-dialog users of the type System for data collection in the remote system. 

To include an SAP system in a central monitoring architecture, you must 

define an RFC connection over which the monitoring data for the SAP 

system can be transferred to the central monitoring system. The data 

collection is performed independently by the CCMS Alert Monitoring 

Infrastructure on the remote system. 

From a security point of view, it is recommended that you also define 

asecondRFCconnectionbetweenthesystemwithwhichtheanalysis 

methods can be started in the remote system from the central monitoring 

system. If a problem occurs, you can therefore branch directly from the 

central monitor to the remote system to analyze the situation in more detail. 



Figure 155: Including Remote Systems: Transaction RZ21 

You can use transaction RZ21 to specify a connection to the remote system, 

with which you can then display the data in the central RZ20. 

SAP systems are included in the central monitoring system in transaction 

RZ21. You can start the transaction from the SAP Easy Access Menu by 

choosing Tools → CCMS → Configuration → Alert Monitor. 

In RZ21, choose Technical Infrastructure → Create Remote Monitoring Entry. 

Enter the SID of the SAP system to be monitored in the Target System ID 

field. 

Now create the two RFC connections from the central monitoring system 

to the monitored SAP system. Choose Goto → RFC Connections. The system 

displays transaction SM59. Create two RFC connections here. Note that 

theconnectiontypeis“3” (SAPR/3-SAPR/3communication). 

In the RFC connection for the transfer of the monitoring data, you can 

enter a user of the type Communication with a password that is valid in the 

monitored SAP system. This means that when the central monitoring 

system requests monitoring data from the monitored SAP system, it is 

provided without the need for user interaction. 



In the RFC connection that is to be used for the start of the analysis 

method, do not enter a user, but rather check the field Current User. If 

an analysis method is started in the monitored system from the central 

monitoring system if problems occur, the caller must authorize himself 

or herself in the monitored system. 

Return to transaction RZ21 by choosing F3. Enter the RFC connections that 

you created under Target System RFC Destination. ChooseSave. TheSAP 

system can now be centrally monitored. 



421 Exercise 27: Include Remote Systems 




• Include a remote system 


As an administrator, you want to include remote systems in your alert 

monitoring. 

Task Include Remote SAP Systems 

Include remote SAP systems in the central monitoring architecture. 

1. Your SAP system is the central monitoring system as of now. 

Register the SAP system of your partner group in your system. To 

do this, get the details of a valid user with password from your 

partner group. Name the remote connections _DATA and 

_ANALYSIS. 

Where can you see data from your partner group’s SAP system? 



Solution 27: Include Remote Systems 

Task Include Remote SAP Systems 

Include remote SAP systems in the central monitoring architecture. 

1. Your SAP system is the central monitoring system as of now. 

Register the SAP system of your partner group in your system. To 

do this, get the details of a valid user with password from your 

partner group. Name the remote connections _DATA and 

_ANALYSIS. 

Where can you see data from your partner group’s SAP system? 

a) To do this, get the details of a valid user with password from 

your partner group. 

Call the configuration transaction for the CCMS Alert Monitor 

(Tools → CCMS → Configuration → Alert Monitor, transaction 

RZ21). 

Choose Technical Infrastructure → Create remote monitoring entry. 

Under Target System ID, enter the of your partner group’s 

system. Choose Goto → RFC Connections. 

Choose Create. Enter the following values: 

• RFC Destination: _DATA (replace with the 

of your partner group’s system) 

• Connection type: 3 

• Description: Any documentation. 


• Target host: The host of your partner group. 

• System number: The system number of your partner group. 

On the Logon/Security tab page, enter the logon information that 

you received from your partner group. 

Choose Save. 

Choose Test Connection. If the connection test fails, check the data 

for Target Host and System Number with your partner group. 

Choose F3 to go back a step, and choose Create again. 

Call the second RFC connection _ANALYSIS (replace 

with the of your partner group’s system). 

Otherwise, enter the same data as for the RFC connection 




_DATA, with one exception: On the Logon/Security 

tab page, select Current User instead of entering the logon 

information. 

Choose Save. 

Perform a connection test again. 

Return to transaction RZ21 by choosing F3 twice. 

In the Data Collection field, enter the RFC connection 

_DATA. 

In the Analysis Method field, enter the RFC connection 

_ANALYSIS. 

Choose Save. 

The message was entered in ALSYSTEMS informs you that 

the registration of the SAP system was successful. 

You cannot yet see any data for the system of your partner 

group, as all monitors delivered by SAP display only local data. 







ADM100 Lesson: Creating Your Own Monitors 

Lesson: 

425 

Creating Your Own Monitors 



In this lesson, you will learn what has to be considered when designing 

and creating your own monitors. 




More advanced issues about the topic monitoring are discussed in SAP 

course ADM106. 


As an administrator, you want to create a monitor that is specifically 

adjusted to your systems. 

Creating Your Own Monitors 

Remind the participants that the monitors delivered should not be used 

productively, if possible, but should rather be regarded as templates that 

should then be substantially tailored to the local requirements. Rule-based 

monitors are introduced in SAP course ADM106. 

Initial questions about designing your own monitors: 

• Why? 

– To display exactly the values that are important for your daily 

work 

– Cross-system monitoring 

• How? 

– What information do I need? 

– Create own monitor set 

– Create own static monitors 

– Create own rule-based monitors (ADM106) 



• Tips: 

– Create monitors for problems 

– Transfer as little data as possible by RFC 

– Monitor sets can be transported 

We recommend that, for your regular work, you create your own monitors 

that display precisely the cross-system or local data that you require for 

your work. 

The sets and monitors delivered by SAP cannot be changed. You should 

therefore first create your own monitor set. You can then create your own 

static monitors that display the required data. The second technique for 

creating your own monitors, rule-based monitors, is described in detail in 

SAP course ADM106. 

Before you create your own monitor, you should clarify the purpose of the 

monitor. The monitor should display as little data as possible in as clear a 

way as possible. You must make a selection from the many hundreds of 

monitoring attributes that meets your requirements. A system overview 

monitor, for example, should contain the status of the last database 

backup or terminated updates as core indicators, but not details about 

the distribution of the dialog response time. You should create another 

monitor to display the response time. 

Note also, especially if data from the monitored SAP systems is also to be 

displayed, the quantities of data to be transferred quickly become very 

large. A monitor that displays the complete monitoring data for two 

remote systems is unusable, as the data transfer lasts too long, especially 

iftheremotesystemshaveaheavyload. As a global guide value, we 

recommend 10-20 monitoring attributes for each monitored instance in 

the central monitor. 



Creating a Monitor Set 

Figure 156: Creating a Monitor Set 

Activate the maintenance functions and create your own monitor set. 

The CCMS Alert Monitor (transaction RZ20) is usually in display mode, 

inwhichyoucanopenmonitors,butcannotcreateorchangemonitors. 

To activate change mode, choose Extras → Activate maintenance function in 

transaction RZ20. Maintenance functions ON appears in the transaction 

heading. The system displays new pushbuttons for creating and changing 

monitors and sets. Choose the Create button. The system asks whether you 

want to create a monitor set or a monitor. Select Monitor Set and choose 

Copy. Enter a name for your monitor set. Note the naming convention that 

your monitor set should not begin with “SAP”. 

You can choose whether your set can be changed by other users or not. 

You can also choose whether the set is displayed for other users in the 

CCMS Alert Monitor. After you have specified the set attributes, choose 

Enter. You have now created your own monitor set, into which you can 

either create new monitors or copy existing monitors. 

The monitor sets and monitors delivered by SAP cannot be changed. 

However, you can use them as stable templates. You can set whether or 

not an SAP monitor set should appear in the display mode of the CCMS 

Alert Monitor. If you want to hide an SAP monitor set, click on the set 



and then on the Change button. Remove the selection for public. Theset 

can now no longer be seen in the display mode. You can change your 

selectioninthechangemode. 

Figure 157: Static Monitors 

Create your own new, static monitor in the monitor set that you created 

previously.Thisnewmonitorshouldcontainthreeorfourself-explanatory 

attributes. Explain that monitors should display a small number of 

significant values. This first speeds up the access to the relevant monitor, 

and second its performance during creation, and third simplifies its 

evaluation due to its better clarity. 

Now create new monitors or copy existing monitors into your monitor set. 

To create new monitors in your set, select the set and choose Create. The 

system displays a selection screen in which all MTEs for all registered 

systems are displayed. Expand the tree structure and choose the MTEs 

that you want to display in your monitor by checking them. If an MTE is 

checked, all MTEs underneath it are automatically copied to the monitor. 

Take into account considerations about the number of MTEs. 

Choose Save. The system prompts you for a name for the new monitor, 

which you can then start by double clicking it. 

The figure shows a monitor that displays cross-system monitoring data 

from two SAP databases. You use this monitor in exactly the same way as 

the SAP standard monitors (Current Status, Open Alerts, Alert Browser). 



You can organize your monitor more clearly by using virtual nodes when 

selecting the MTEs. Virtual nodes allow you to structure your monitor. 

During the MTE selection, choose Create and then Virtual Node. Youcan 

choose any text for the virtual node. It should be as descriptive as possible. 

Complete your entry by choosing Enter. Your virtual node is inserted. You 

can now select any MTEs for inclusion in the monitor under this node. In 

the final monitor, these MTEs appear under the virtual node. 





429 Exercise 28: Create Your Own Monitors 




• Create your own monitors 


As an administrator, you want to create a monitor that is specifically 

adjusted to your systems. 

Task 1 Creating a Monitor Set 

1. Create your own monitor set, “System Monitoring”. 

Task 2 Create a Monitor 

Create your own cross-system monitor, “Core_information” that displays 

the most important system monitoring data. 

1. First consider which information is important for monitoring, from 

your point of view. Remember that you should not display too many 

values for each SAP system. 

2. Now attempt to create the monitor “Core_information”. The monitor 

should, as far as possible, display the desired data for your system 

and your partner group’s system. 

Task 3 Process Alerts in the Remote System 

1. Open your Core_information monitor. Display all alerts for the entire 

monitor. 

Process an alert from your partner group’s system. 

i) Start the analysis method for an alert. 

ii) Return to the Alert Browser and complete the alert. Does the alert 

still appear in the list? 

iii) How can you display the completed alert again? 

Result 

You have just worked on a cross-system basis with the Alert Monitor. 



Solution 28: Create Your Own Monitors 

Task 1 Creating a Monitor Set 

1. Create your own monitor set, “System Monitoring”. 

a) Call the CCMS Alert Monitor (Tools → CCMS → 

Control/Monitoring → Alert Monitor, transaction RZ20). 

Activate the maintenance function, by choosing Extras → Activate 

Maintenance Function. 

Choose the Create button. New Monitor Set is already selected. 

Choose Copy. 

Enter the name System Monitoring foryourmonitorset. 

Maintain the attributes of your monitor set as you wish. 

Choose Copy. 

Your monitor set is displayed under My Favorites. You can now 

create new monitors in this set. 

Task 2 Create a Monitor 

Create your own cross-system monitor, “Core_information” that displays 

the most important system monitoring data. 

1. First consider which information is important for monitoring, from 

your point of view. Remember that you should not display too many 

values for each SAP system. 

a) Your new monitor, “Core_information”, should contain the most 

important monitoring data for your system landscape. 

It could, for example, contain the following data: 

• Status of the last DB backup 

• Status of the last DB log backup 

• Free space in the log file system (DB-dependent) 

• DB errors 

• Terminated updates 

• Terminated ABAP programs 

• System log 

• Average dialog response time 




2. Now attempt to create the monitor “Core_information”. The monitor 

should, as far as possible, display the desired data for your system 

and your partner group’s system. 

a) In maintenance mode of transaction RZ20, place the cursor on 

your monitor set and choose Create. 

The system displays the currently registered SAP systems. 

Expand the tree and search for monitoring attributes that 

correspond to the data that you require. 

For the proposed monitor from task 1: 

• Status of the last DB backup: Look in the branch → 

→ Backup/Restore. 

• Status of the last DB log backup: Look in the branch 

→ → Backup/Restore. 

• Freespaceinthelogfilesystem(DB-dependent):Look 

in the branch → → OperatingSystem → 

Filesystem 

• DB errors: Look in the branch → → 

Health → Errors. 

• Terminated updates: Look in the branch 

→ → R3Services → Update → Update → 

AbapErrorInUpdate. 

• Terminated ABAP programs: Look in the branch → 

→ R3Abap → Shortdumps. 

• System log: Look in the branch → → 

R3Syslog 

• Average dialog response time: Look in the branch → 

→ R3Services → Dialog → ResponseTime. 

Select the MTEs that you require. 

Choose Save. EnterCore_information asthenameofyour 

monitor. 

Open your monitor by double clicking it. 

Task 3 Process Alerts in the Remote System 

1. Open your Core_information monitor. Display all alerts for the entire 

monitor. 

Process an alert from your partner group’s system. 

i) Start the analysis method for an alert. 




Result 

ii) Return to the Alert Browser and complete the alert. Does the alert 

still appear in the list? 

iii) How can you display the completed alert again? 

a) Open your Core_information monitor by double clicking it. 

Switch to the Open Alerts view. 

Double click an MTE for your partner system. All alerts in this 

area for your partner system are displayed in the Alert Browser. 

Select an alert in the list. Then choose the Start Analysis Method 

button. The logon screen of the partner system appears, as 

Current User is selected for the user data in the RFC connection 

for starting analysis methods. 

Log on to your partner system. 

In the partner system, you jump to an action that provides you 

with detailed data about the alert. 

Return to the monitor. Choose Complete Alerts. The alert is 

removed from the list. 

To display the alert again, choose Show Alert History. Your 

completed alert has the status DONE. 

You have just worked on a cross-system basis with the Alert 

Monitor. 








Lesson: 

434 

Properties Variants and Threshold Values 



You can implement targeted monitoring of your systems using your own 

monitors that you create yourself. For these monitors to be able to work 

optimally, you must adjust the threshold values for the monitoring objects 

and monitoring attributes in the monitors for your system landscape. The 

specific settings can be stored as properties variants. 




environment 

The participants are to learn about the concept of properties variants and 

about maintaining threshold values. 


Alert monitors can only be meaningfully used if the selected threshold 

values for the individual monitoring attributes are set to sensible values. It 

is not possible to recommend values that are generally valid, since different 

values are appropriate depending on the system or operation mode. 

Threshold Values and Properties Variants 

Initial questions: 

• Why? 

– Sothatalertsarenotconstantlyornevertriggered 

– So that the Monitoring Infrastructure is optimized for the 

customer environment 

• How? 

– In the central monitoring system in transaction RZ20 

– Transport from there to the monitored SAP systems 

• Tips: 


ADM100 Lesson: Properties Variants and Threshold Values 

– First create container for threshold values (properties variants) 

and activate 

– Then maintain threshold values for the MTEs in your own 

monitors 

Threshold values determine when the corresponding monitoring attribute 

should trigger a yellow or red alert: Green means that there are “no 

problems”, yellow means “warning”, red means “problem or error”, and 

white means “no data available”. 

The delivered threshold values must be adjusted to local requirements 

before they are used. This adjustment should be recorded in properties 

variants. This means that the settings can be transported to local systems. 

This is very important, since measured values are always interpreted in 

accordance with local threshold values. Explain again that a data collection 

method must be explicitly scheduled and started for some attributes. This 

explains some of the inactive or white attributes. 

Threshold values can be stored for a monitoring attribute. Threshold 

values determine when the monitoring attribute should trigger a yellow 

or a red alert, and when it should become green or yellow again. The 

CCMS Alert Monitoring Infrastructure is delivered preconfigured with 

threshold values recommended by SAP. You should, however, check the 

threshold values, at least for the monitoring attributes that you consider to 

be important and that you have included in your own monitors. In this 

way, you customize the CCMS Alert Monitor optimally to your system 

environment. Otherwise, alerts can be constantly or never triggered, 

depending on whether the threshold value is too low or too high for your 

system environment. 

Thresholdvaluesmustbestoredlocallyineverysystem.However,instead 

of maintaining the same threshold values in every system, we recommend 

that you maintain the values in the central monitoring system and then 

distribute them to the monitored SAP systems using the transport system. 

The prerequisite for transporting the threshold values to other SAP 

systems is that you have stored them in properties variants. 

(Monitoring) properties variants not only allow the transport of sets of 

threshold values, but also different assessment of reported values based 

on the time (of day). For example, some or all monitored values can be 

interpreted differently during the day and during the night in this way 

connection to operation modes, RZ04). 



Before you maintain threshold values in the next demo, specify your own 

properties variants. The customer default variant “*” is in use. 

Properties variants are containers in which CCMS Alert Monitor settings, 

such as threshold values, can be stored. 

You can create as many properties variants as you like and store CCMS 

Alert Monitor settings in them. At any time, exactly one properties variant 

with your settings is active. 

Properties variants have three advantages: 

• You can manually switch from one properties variant to another 

for test purposes or to adjust the monitor to a special situation. 

This means that all monitor settings are automatically changed in 

accordance with the current properties variant. 

• You can connect a properties variant to an operation mode. In this 

way, the threshold value for the dialog response time is set to 1s 

during the day, while the threshold value is automatically increased 

to 10s after the switch to night operation, as there is usually no dialog 

processing during the night. 

• You can transport the contents of properties variants to other SAP 

systems using the transport system. For example, if you create a 

variant for production systems in the central monitoring system, 

and maintain the threshold values that are to apply for production 

systems there, you can then transport the variant to all production 

systems and activate the threshold values there. 

Figure 158: Creating and Activating Properties Variants 



Properties variants are created in transaction RZ21. You can find the 

important functions for properties variants by choosing Properties → 

Variants. 

First, create your own properties variant. Choose Properties → Variants 

→ Create. Enter a name and a description for the properties variant, and 

save it. 

Then choose Properties → Variants → Activate. Select your variant and 

choose Enter. Your properties variant is now active and is displayed on 

the initial screen of transaction RZ21. All threshold value settings that you 

make from now in the CCMS Alert Monitor are saved in the active variant. 

You can organize properties variants hierarchically. You can specify a 

parent variant when you create variants. If you do not specify another 

variant, the variant “*” is implicitly assumed to be the parent variant, 

whose parent variant, is, in turn, SAP-DEFAULT. The threshold values 

recommended by SAP are stored in SAP-DEFAULT. 

If no threshold value is maintained for a monitoring attribute in your 

variant, the system checks the parent variant. If this also has no threshold 

value, its parent variant is checked, and so on. Your properties variant is 

empty after it has been created. Therefore, after activation, the threshold 

values that are stored in the variant “*” or SAP-DEFAULT apply. 

The connection of properties variants to operation modes is performed in 

transaction RZ04. Select the operation mode and choose Operation Mode → 

Change. You can enter the desired properties variant in the field Monitoring 

Properties Variant. Then save your entries. 

Figure 159: Maintain threshold values 



Select the monitor that you created previously, and change the threshold 

value of a (performance) attribute. Explain that threshold values can be 

changed for an individual MTE or for the entire attribute group (path Edit 

→ Properties → Use for Individual MTE, or→ Use from MTE Class/Group.) 

After you have activated your properties variant, you can check the 

threshold values for the monitoring attributes that you regard as important 

and that you have included in your own monitors. 

To do this, open your monitor in the CCMS Alert Monitor (transaction 

RZ20). Select a monitoring attribute and choose Properties. Thecurrenttab 

page displays the valid threshold value definition. 

The thresholds for Change from GREEN to YELLOW and Change from 

YELLOW to GREEN are usually defined to change sooner than the 

thresholds for Change from RED to YELLOW and Change from YELLOW 

to GREEN. In this way, you can avoid your monitor “flickering”, if the 

measuredvalueiswaveringaroundthethresholdvalue.Itisusefultogive 

an “all clear” only once the situation has markedly improved. 

Choose Display → Change. You can now adjust the threshold values to your 

requirements. Save your settings. 

The threshold values are stored in the current properties variant. You 

can copy these settings to a transport request and transport them to other 

SAP systems. To transport the threshold values, choose Properties → 

Variants → Overview of Variants in transaction RZ21. In the overview of 

variants, choose Variant → Transport. By doing this, you create a transport 

request that can be transported to other SAP systems using the transport 

management system (TMS). 



439 Exercise 29: Properties Variants of 

Monitors 




• Create a properties variant 


Alert monitors can only be meaningfully used if the selected threshold 

values for the individual monitoring attributes are set to sensible values. It 

is not possible to recommend values that are generally valid, since different 

values are appropriate depending on the system or operation mode. 

Task1CreateaPropertiesVariant 

1. Create your own properties variant, “TEST”, in your SAP system. 

Activate your properties variant. 

Task 2 Maintain Threshold Values 

1. Maintain the threshold values for a monitoring attribute in your 

monitor. To do this, find a monitoring attribute from your SAP 

system,forwhichyoucanmaintainthethresholdsfor: 

Green to yellow 

Green to red 

Red to yellow 

Yellow to green 

Change these threshold values and save them. 

Hint: These threshold values can only be specified for 

performance monitoring attributes. There are two other 

monitoring attribute types, for which threshold values are 

specified in a different way.) 

Task 3 Switch Properties Variants Manually 

1. Activate the “*” properties variant in transaction RZ21. What has 

happened to the threshold values for the MTE that you set in task 2? 



Solution 29: Properties Variants of 

Monitors 

Task1CreateaPropertiesVariant 

1. Create your own properties variant, “TEST”, in your SAP system. 

Activate your properties variant. 

a) Call the configuration transaction for the CCMS Alert Monitor 


RZ21). 

Choose Properties → Variants → Create. 

Enter TEST as the variant name and enter a short description. 

Choose Save. 

Choose Properties → Variants → Activate. 

Select your variant TEST and choose Enter. TheTEST variant is 

displayed as the active variant in the initial screen of transaction 

RZ21. 

Task 2 Maintain Threshold Values 

1. Maintain the threshold values for a monitoring attribute in your 

monitor. To do this, find a monitoring attribute from your SAP 

system, for which you can maintain the thresholds for: 

Green to yellow 

Green to red 

Red to yellow 

Yellow to green 




Change these threshold values and save them. 

Hint: These threshold values can only be specified for 

performance monitoring attributes. There are two other 

monitoring attribute types, for which threshold values are 

specified in a different way.) 

a) Show a description of the symbols that are used in the monitor 

by choosing Extras → Legend. The icon for a performance 

attributes is a graph. 

Search for a performance attribute for your SAP system in your 

monitor (such as the average dialog response time). Place the 

cursor on a monitoring attribute and choose Properties. 

The current threshold values are displayed on the Performance 

Attribute tab page. Do you consider the threshold values to 

be appropriate? Choose Display Change and change the 

threshold values. 

Choose Save. 

The threshold values are successfully adjusted and are stored in 

your properties variant. 

We recommend that you perform this check for all monitoring 

attributes for your system that are important for you. To activate 

the threshold values in other systems, you can transport your 

properties variant to these systems. 




Task 3 Switch Properties Variants Manually 

1. Activate the “*” properties variant in transaction RZ21. What has 

happened to the threshold values for the MTE that you set in task 2? 

a) Call the configuration transaction for the CCMS Alert Monitor 


RZ21). 

Choose Properties → Variants → Activate. 

Select the variant “*” and choose Enter. The“*” variant is 

displayed as the active variant in the initial screen of transaction 

RZ21. 

Now open the Core_information monitor in transaction RZ20 by 

double clicking it. Search for the monitoring attribute for which 

you changed the threshold values in task 2. 

The threshold values have returned to their original values, 

which are fixed in the “*” properties variant. 

If you reactivated your TEST properties variant in transaction 

RZ21, the changed settings would become active again. 






environment 


For more information about the CCMS Alert Monitoring Infrastructure, 

see: 

• The SAP Service Marketplace: Quick Link /systemmanagement → 

System Monitoring and Alert Management 

• SAP course ADM106 - Advanced System Monitoring. Thiscourse 

focuses, in particular, the configuration of methods (analysis and 

auto-reaction) and the use of rule-based monitors. 



Unit Summary 







environment 



445 


1. What can alert monitoring be used for? 


A Database backup 

B Updating data 

C Monitoring the database and the SAP system 

D Configuring and monitoring the firewall 

2. Why include remote systems in your alert monitoring? 


A To transport program code from system to system. 

B Tocreatealocalconnectiontoadatabasebackupofremote 

systems 

C Tobeabletomonitortheseremotesystemscentrally. 

D To allow file sharing. 

E To connect an LDAP server. 

3. What types of monitors are there in the SAP system? 


A Ruled monitors 

B Statistical monitors 

C Rule-based monitors 

D Static monitors 

E Self-Repairing monitors 

4. Properties variants are used to... 


A Store user master data 

B Customize transport requests 

C Store CCMS alert monitoring settings 

D Store combinations of parameters for calling an ABAP 

report 



446 

Answers 

1. What can alert monitoring be used for? 

Answer: C 

Monitoring objects are only monitored, not administered using alert 

monitoring. The range of monitored is very large, since monitors can 

also be created for “exotic” objects. 

2. Why include remote systems in your alert monitoring? 

Answer: C 

Including remote systems should allow you to monitor these systems 

centrally. 

3. What types of monitors are there in the SAP system? 

Answer: C, D 

Therearestaticandrule-basedmonitors. 

4. Properties variants are used to... 

Answer: C 

CCMS alert monitoring settings are stored with properties variants 


Unit 14 

447 SAP Solution Manager 

This unit should provide an introduction to the SAP Solution Manager for 

the participants. For more detailed information, attend the courses in the 

SAP Solution Manager curriculum. 

Unit Overview 

This unit will provide you with an introduction to the concept and use of 

the SAP Solution Manager. 



• Describe the added value of the SAP Solution Manager in an SAP 

landscape 

Unit Contents 

Lesson: Concept of the SAP Solution Manager ............................520 


Unit 14: SAP Solution Manager ADM100 

Lesson: 

448 

Concept of the SAP Solution Manager 



The SAP Solution Manager is a tool that provides the administrator with a 

large number of functions for administering a complex system landscape. 

This lesson provides an overview of these functions and briefly describes 

the installation and configuration of the SAP Solution Manager. 




landscape 

This lesson provides an introduction to the SAP Solution Manager. It is 

intended to present the possibilities to the participants. The aim here is not 

to explain the operation of the SAP Solution Manager, since training for 

this is provided in a separate curriculum. 


The SAP Solution Manager provides a central service and support portal 

and therefore supports the administrator in his or her daily work. 

Introduction 

These first figures are used to position the SAP Solution Manager. To do 

this, you should briefly outline the functions of the SAP Solution Manager. 

These are presented in more detail later. 

The SAP Solution Manager is a service and support platform for the 

implementation and operation of SAP systems. It provides content, tools, 

and procedures for implementing, operating and supporting SAP systems. 

The SAP Solution Manager supports customers at the start of the 

project, during functional and technical implementation, during running 

operation, and during the optimization of their system landscapes. The 

SAP Solution Manager also makes it possible to communicate with SAP 

and its partners at any time and therefore enhances the extensive on-site 

service. 


ADM100 Lesson: Concept of the SAP Solution Manager 

Figure 160: SAP Solution Manager: Overview 

The SAP Solution Manager provides the following functions for the 

operation of your mySAP Business Suite solution: 

Figure 161: Functions of the SAP Solution Manager 

• Predictive and Proactive Services: EarlyWatch Alert, GoingLive 

Check, and GoingLive Functional Upgrade Check. 

• Continuous Improvement Services: Solution Management Review 

Service (SMR) and Solution Management Optimization Services 

(SMO) 

• Best Practices for the SAP solution that you have implemented: 

Documents and services that are based on SAP’s experience from 

production customer installations. 

• Application and System Monitoring: Technical monitoring of your 

SAP solution including the availability of interfaces, individual 

system components, business process monitoring, Service Level and a 

graphical alert monitor. 



• SAP Support Desk: Central message management for all mySAP 

solutions (including attached files or error contexts), interface to 

SAPNet - R/3 Frontend, SAP Notes database search and automatic 

import of SAP Notes (Notes Assistant), and the customer solution 

database for customer-specific questions and answers. 

• SAP Remote Support: Security solution for Microsoft NetMeeting 

using SAProuter, remote access through Internet connections, end 

user desktop application sharing with SAP experts. 

Installation 

The instructor should clarify that the SAP Solution Manager is imported 

into an SAP Web AS as a normal Add-On using transaction SAINT. A 

standalone system, on which central monitoring is usually also running, 

is best-suited for running the SAP Solution Manager. The SAP Solution 

Managers software is available free of charge. A SAP Web AS can also be 

licensed free of charge in the context of installing a SAP Solution Manager. 

The SAP Solution Manager is also installed on a standalone SAP Web 

Application Server. The release of the SAP Solution Manager depends 

on the release status of the SAP Web AS. For an overview of the release 

strategy and the platform requirements, see the SAP Service Marketplace 

(http://service.sap.com/solutionmanager → Release Strategy). From 

a technical point of view, the SAP Solution Manager is installed as an 

Add-On using transaction SAINT. 



Figure 162: Installing the SAP Solution Manager 

The SAP Solution Manager is available free of charge on CD in the context 

of your maintenance contract. You can order the installation CD through 

theSAPServiceMarketplace(http://service.sap.com/solutionmanager → 

Order Information). After installation, SAP provides you with the Enabling 

Service (also free of charge). SAP Support provides you with support to 

configure the basic functions of the SAP Solution Manager. 

To simplify the implementation of the SAP Solution Managers, SAP offers 

the SAP Solution Manager Starter Pack, which contains on-site training 

tailored to your requirements in addition to implementation. If you take 

advantage of this service, you should order the SAP Solution Manager 

installation CD a week in advance. 

Setting Up a Solution Landscape 

The basic information that the SAP Solution Manager requires is defined 

in the Solution Scope area. In the first step, you can define a new 

system landscape to describe your SAP solution. You can document the 

requirements and the technical implementation using your SAP systems 

in this Solution Landscape. 



Figure 163: Setting Up a Solution Landscape 

All systems to be monitored must be defined. At least one system must be 

defined in this way so that you can use Service Level Reporting. You must 

enter descriptive attributes such as: the SID, the installation number (for 

SAP systems), and the system type (SAP R/3, SAP CRM, SAP BW, and so 

on) for every system. Creating a system has other consequences, including 

the fact that you can schedule weekly EarlyWatch alerts for these systems. 

After setting up the Solution Landscape, the defined systems can access 

the services of the SAP Solution Manager. 

Implementation 

The SAP Solution Manager supports you in performing central activities 

during the implementation. These are, for example: 

• Project management support with which you can manage scheduling 

periods, employees, and other project information. 

• A Business Process Repository, which provides templates for 

mapping processes. These templates are required to define the project 

scope and the central enterprise processes. 

• Tools for implementing the integrated business scenarios. 

• Integrated Implementation Guides that support you during the 

Customizing activities for the business processes. 



Operation 

The Operations Portal area allows you to access various preventative 

and proactive SAP services directly. Variousservicetypesareofferedin 

the three areas: 

• Self services, such as IT reporting, SQL cache analysis, ABAP coding 

analysis, but also Upgrade Guides, Technical Implementation Guides, 

and the operations handbook. 

• Remote services, such as the SAP EarlyWatch Alert Service, SAP 

EarlyWatch service, SAP GoingLive Check, and SAP GoingLive 

Functional Upgrade Check. 

The services are dynamically proposed depending on the configuration 

and status of your solution. The SAP Solution Manager provides an 

overview of all customer-specific service recommendations. 

You can easily order services using the SAP Solution Manager. The process 

of an order is outlined in the figure below. 

Figure 164: Service Ordering and Delivery 

Monitoring 

The monitoring portal provides functions for monitoring individual 

systems and complete business processes. You can also create status 

reports with Service-Level Reporting. 

The monitoring architecture of the SAP Solution Manager is outlined in 

the figure below. The satellite systems automatically collect the actual 

data. The SAP Solution Manager collects this data, aggregates it, evaluates 

it, and displays the result graphically. CCMS Monitoring (RZ20) and the 

Service Data Control Center (SDCC) act as data collectors on the satellite 

system side. 



Figure 165: Monitoring Using Self Services 

System Monitoring 

The SAP Solution Manager’s system monitoring uses the data from CCMS 

monitoring and displays this in a business process-oriented context. You 

can set up central monitoring of all components of your SAP systems 

relevant to operation here, as in CCMS monitoring. 

Business Process Monitoring 

In the context of business process monitoring, core business processes 

are analyzed across different systems and interfaces. Possible warning 

messages are displayed graphically and allow you to identify where a 

problem has occurred. Detailed information and notes and services that 

may help to solve the problem are linked to the warning message. 

Service Level Management 

You can define system status reports yourself using Service Level 

Management. These include the EarlyWatch Alert or the Service Level 

Report, which automatically provide you with regular reports (in HTML 

or Microsoft Word format) about the current status of your mySAP.com 

solution. You only need to schedule these services once. They then 

collect data about your systems regularly, aggregate it, and evaluate it. 

The following figure shows an excerpt from an EarlyWatch Alert Report 

as an example. 



Figure 166: Example of an EarlyWatch Alert Report 

Support 

TheSupportPortaloftheSAPSolutionManagerprovidesacompleteIT 

infrastructure for providing back office support with message handling 

for your mySAP.com solution in your company. The system on which the 

SAP Solution Manager is installed acts as a central collection point for all 

support messages that are created in your SAP systems (see following 

figure). 



Figure 167: SAP Support Desk 

All end users can send a message to your back office from any SAP 

transaction by choosing Help → Create Support Message (see following 

figure). This message is sent directly to the SAP Solution Manager using 

an RFC connection. It is possible to sort the message using components 

and to assign an urgency level to the message. External files can, of course, 

be included. 

Figure 168: End User Message Creation 



The back office department can view and process the messages created 

by the end users in the SAP Solution Manager. To solve any end user 

problems, support has direct access to all SAP Notes, their own customer 

solutions database and other documents and tools that are provided by 

SAP on the SAP Service Marketplace. After a successful search for a 

problem solution, support can send the message back to the user with a 

description of the solution. In urgent cases or for very special problems, 

support can forward the error message to SAP through the SAP Service 

Marketplace. 




Discuss the functions that the SAP Solution Manager provides for 

administrators to administer a complex system landscape. 




Describe the procedure to install the SAP Solution Manager. 

List the functions and services that the SAP Solution Manager provides. 






landscape 


• On the SAP Service Marketplace under http://service.sap.com/solutionmanager 



Unit Summary 



landscape 


• On the SAP Service Marketplace under http://service.sap.com/solutionmanager 

• In SAP courses about the SAP Solution Manager. For information 

about these, see http://service.sap.com/solutionmanager → Training. 


Unit 15 

459 Structured Troubleshooting 

This unit should provide the participants with an overview of procedures 

for troubleshooting. These include various trace options in the SAP 

system. The most important of these should be introduced in detail. If 

appropriate, the instructor can certainly add additional trace possibilities 

with which he or she is familiar. 

The second lesson deals with an actual problem case: the case of front 

end printing not working, which should demonstrate a possible concrete 

process for structured troubleshooting to the participants. 

Unit Overview 

Oneofthetasksofsystemadministratorsistolocalizeandcorrecterrors 

when they occur. This unit will provide youwithanoverviewofdifferent 

trace options in the system and allows you to perform a number of traces. 

A possible process for structured troubleshooting will then be presented 

using a concrete example (errors in front end printing). 



• List various trace options 

• Perform simple traces in the SAP system 

• Develop procedures for structured troubleshooting 

• Perform troubleshooting if problems occur in front end printing 

Unit Contents 

Lesson: Trace Options .........................................................535 

Exercise 30: Trace Options................................................545 

Lesson: Troubleshooting Procedure..........................................550 

Lesson: Appendix - Troubleshooting Example ..............................555 


Unit 15: Structured Troubleshooting ADM100 

Exercise 31: Appendix - Error Analysis for Front End Printing 

(OPTIONAL).................................................................567 


ADM100 Lesson: Trace Options 

Lesson: 

460 

Trace Options 



In this lesson, you will learn about the different trace options in the SAP 

system. You will perform and evaluate a trace yourself. 





The participants are to learn about the most important trace options and 

to be able to use them practically. 


An unexpected, reproducible error situation is occurring in your SAP 

system. As a member of the system administration team, it is your task to 

find the cause of the error. 

Introduction 

You can follow the process of various operations in your SAP system 

with trace functions. This allows you to monitor the system and isolate 

problems that occur. There are two types of trace: the performance trace 

and the system trace. You can also use developer traces and the system log 

to correct problems. The following trace options exist in the system: 

• System log 

• Dump analysis 

• System trace 

• Performance trace 

• Developer trace 

You can use the System Log (transaction SM21) to detect and correct errors 

in your system and its environment. SAP application servers record events 

and problems in system logs. Every SAP application server has a local log 

that contains the messages output by this server. 



If unpredictable errors occur during runtime when you call an ABAP 

program, a runtime error that generates a short dump can occur 

(transaction ST22). 

If you want to record the internal SAP system activities, such as 

authorization checks, database accesses, kernel functions, and RFC calls, 

use the System Trace function (transaction: ST01). 

The Performance Trace(transaction ST05) allows you to record database 

calls, lock management calls, and remote calls of reports and transactions 

in a trace file and to display the logged measurement results as lists. The 

Performance Trace also offers extensive support for a detailed analysis 

of individual trace records. 

Technical information about internal SAP problems is logged in developer 

traces. 

System Log 

Events and problems are recorded locally on each application server and 

displayed in the system log in the SAP system. 

Figure 169: System Log (SM21) 

If you are using the UNIX operating system, you can also work with 

central logging. In this case, each application server copies its local logs to 

a central log. Central logging is not possible on Microsoft Windows NT 



and AS/400 hosts. Technically, the system log is written to a ring buffer. 

If this log file reaches the maximum permitted size, the system begins to 

overwrite the oldest data. 

Hint: The system does not display a message when an old log 

file is replaced. 

To display a log, choose Tools → Administration → Monitor → System Log or 

call transaction SM21. By default, the system reads the log for the last one 

to two hours. You can display system logs for other application servers 

as well as the local system log in transaction SM21. To do this, choose 

the menu path System Log → Choose → All Remote System Logs or System 

Log → Choose →Central System Log. 

By default, central logging is inactive on every application server. 

Before you can activate central logging, you must ensure that the profile 

parameters in the central system and on every instance are identical. The 

system parameters for central logging start with the prefix rslg and can be 

maintained in the instance profile or in the default profile. 

• rslg/collect_daemon/host: Name of the node for the central log 

• rslg/collect_daemon/listen_port: Listen port for the collection process 

(default setting: 14< SAPSYSTEM number>) 

• rslg/collect_daemon/talk_port: Talk port for the collection process 

(default setting: 15< SAPSYSTEM number>) 

• rslg/send_daemon/listen_port: Listen port for the send process (default 

setting: 12< SAPSYSTEM number>) 

• rslg/send_daemon/talk_port: Talkportforthesendprocess(default 

setting: 13< SAPSYSTEM number>) 

• rslg/send_daemon_autostart: Leave the value of this parameter set to 0. 

Note: The listen ports and talk ports must be identical for all 

instances in the SAP system. 

The send process also uses the following system profile parameters. Do 

not change the predefined values of these parameters: 

• rslg/collect_daemon/exe_file: Specifies the executable file for the central 

collection process. 

• rslg/send_daemon/exe_file: Executablefileforthesendprocess 

• rslg/send_daemon/pid_file: Identifies the file that is initialized when 

the send process is started. 

• rslg/send_daemon/status_file: Identifies the send process’s internal 

status file. 



In expert mode (menu path Edit → Expert Mode), you can extend the 

selection criteria so that it is possible to search for entries for a particular 

terminal. To do this, choose the Attributes button. 

In UNIX systems, you can display the status of the send process in the SAP 

system with transaction SM21 or by choosing Environment → Process Status. 

You can define the path and file names for local and central log files with 

the following system profile parameters: 

• rslg/local/file: Filenameforthelocallog(Default:SLOG) 

• rslg/central/file: Filenamefortheactivecentrallog(Default:SLOGJ); 

does not apply for Microsoft Windows NT and AS/400 platforms 

By default, the log files for the local system log are stored in the following 

directory: /usr/sap///log. The central system log is 

stored in /usr/sap//SYS/global 

You can also schedule system logging as a background job. There are two 

ABAP programs provided to do this: 

• RSLG0000: To create the local system log 

• RSLG0001: To create the central system log (not on Microsoft 

Windows NT and AS/400 platforms) 

At this point, you can demonstrate transaction SM21. Display details 

for a message in the system log and jump from SM21 to the profiles: In 

transaction SM21, choose Environment → Display SAPPARAM. 

Dump Analysis 

ABAP programs are checked statically when they are created and 

dynamically when they are running. Error states, which are not statically 

predictable and only occur at runtime are dynamically identified by the 

ABAP runtime environment. States of this type lead to exceptions. If an 

exception is not handled or cannot be handled, a runtime error occurs. 

If a runtime error occurs, the ABAP runtime environment terminates 

the execution of the program, generates a short dump and branches to 

a special screen for analyzing the short dump. You can also find short 

dumps in transaction ST22 or by choosing the menu path Tools → ABAP 

Workbench → Test → Dump Analysis 



A short dump is divided into different sections that document the error. 

The overview shows which other informationisoutputintheshortdump, 

such as contents of data objects, active calls, control structures, and so on. 

You can branch to the ABAP Debugger at the termination point from the 

short dump view. The following different error situations exist: 

• Internal Error 

The kernel identifies an error state. In this case, notify SAP. 

• Installation and Environment/Resource Error 

In this case, an error occurred that was caused by incorrect system 

installation or missing resources (such as the database being 

shutdown). 

• Error in Application Program 

Typicalcausesoferrorsare: 

– Content of a numerical field not in the correct format. 

– Arithmetic overrun. 

– An external procedure is not available. 

– Type conflict when transferring parameters to an external 

procedure. 

By default, short dumps are stored in the system for 14 days. The 

transaction for managing short dumps is ST22. You can delete short dumps 

in accordance with a time specification using the Reorganize function, 

whichyoucancallbychoosingGoto → Reorganize. Youcansaveashort 

dump without a time limit using the Keep function, which you can choose 

under Short Dump → Keep/Release. 

If problems that you cannot solve yourself occur with ABAP programs, 

you can send an extract of the short dump to SAP. A short dump is the 

basis on which the SAP Hotline and remote consulting solve problems. 

• If a runtime error occurs, a short dump is generated. You can use 

transaction ST22 to analyze this short dump. 

• Dump data is stored in the database. 

• Dump data can be reorganized. 

• Individual short dumps can be flagged for retention. 

The short dumps are stored in table SNAP. If there are too many entries 

in table SNAP, problems can occur during the reorganization (see SAP 

Note 11838). There are different options for deleting short dumps from 

table SNAP: 



• Call transaction ST22. Choose Goto → Reorganize. You can now 

specify that all short dumps older than n days old (default 7) are to be 

deleted. If a very large number of records are deleted at once during 

the reorganization, ORACLE error ora1562, failed to extend rollback 

segment ..., can occur. In this case, see SAP Note 6328. 

• Dropping and recreating table SNAP with the database utility 

(transaction SE14): you can use this transaction to drop and recreate 

the table SNAP. This means that all short dumps are deleted. 

• The reorganization program RSSNAPDL deletes old short dumps in 

pieces (to avoid database problems) from table SNAP. It deletes short 

dumps that are not flagged for retention and are older than seven 

days old. Schedule this program at a time of low workload, as large 

changes in the database are to be expected. The program RSNAPJOB 

performs a standard scheduling: it starts the program RSSNAPDL 

every day at 1:00 a.m.. 

• Table SNAP is also automatically reorganized.Ateveryshortdump 

that occurs in dialog (the dump is displayed immediately after it is 

created), a maximum of 20 short dumps that are older than 7 days 

old are deleted from SNAP. This reorganization should be sufficient 

in normal production operation. 

At this point, you can demonstrate transaction ST22. Execute a function 

module that can be used for remote connections in the Function Builder 

(transaction SE37), such as RFC_READ_TABLE for table T000, or 

RFC_SYSTEM_INFO as described in the exercise. Use the RFC connection 

TRACES_ST22. A short dump is generated. You can analyze this in 

transaction ST22. Show the short dump and the options for reorganization 

and retention of messages. 

SAP System Trace 

You can use the system trace to record internal system activities. The 

system trace is primarily used if an authorization trace is to be created. We 

recommend that you use the system log or the developer trace for system 

monitoring and problem analysis. You can call the SAP System Trace using 

transaction ST01 or by choosing the menu path Tools → Administration → 

Monitor → Traces → System Trace. YoucanalsousetransactionST01to 

display the inactive trace file. 

You can use the SAP system trace to monitor the following components: 



• Authorization checks 

• Kernel functions 

• Kernel modules 

• DBaccesses(SQLTrace) 

• Table buffers 

• Lock operations (client-side) 

You select the components to be logged on the initial screen. If the trace is 

activated for the authorization check, all authorization checks performed 

by the system are recorded. During the evaluation, you can identify 

which authorizations the system checked at which times. The following 

detail information is also provided: Date, time, work process number, 

user, authorization object, program, line, number of authorization values, 

authorization values. 

You can use the SQL Trace to follow how the Open SQL commands in 

reports and transactions are converted to standard SQL commands and the 

parameters with which the SQL commands are transferred to the database 

system in use. The results of the SQL command are also logged, such as the 

return code and the number of records found, inserted, or deleted by the 

database. Logging the execution time and the callpoint in the application 

program allows you to perform more advanced evaluations. 

With the enqueue trace, you can follow which lock instructions the SAP 

system performs on which lock objects, and which parameters the system 

uses for these locks. The program that triggered the lock, the owner of the 

lock, and the time that the enqueue server required to release the lock 

again are all also logged in the trace file. 

You can use the RFC trace to follow which remote calls the SAP system 

executes, and the instance on which these calls are executed. You can 

see from the trace which function modules were called remotely by the 

program to be analyzed, and whether the RFC was successfully executed. 

The total time required for the execution of the remote call and the number 

of bytes sent and received during the RFC are also logged in the trace file. 



Figure 170: SAP System Trace (ST01) and Performance Trace (ST05) 

At this point, you could call transaction ST01 and activate an authorization 

trace for all components. To do this, call, for example, transaction 

RZ10, and change a profile file. Deactivate the trace again. Display the 

authorization and enqueue trace in transaction ST01 and evaluate it. 

Performance Trace 

The performance trace provides the following functions: 

• Recording database calls 

• Recording lock management calls 

• Table buffers 

• Recording remote calls of reports and transactions 

• Detailed analysis of individual trace records 

• Analysis of an SQL statement 

At this point, you could call transaction ST05, start a trace of the database 

calls or remote calls, and then evaluate it. To do this, you could, for 

example, start a report (RSPFPAR) or call transaction RZ10, and make 

a change to a profile file. Deactivate the trace again. Display the SQL 

trace in transaction ST05 and evaluate it. Demonstrate the switch to the 

program coding. 



Theperformancetraceprovidessimilartraceoptionstothesystemtrace.It 

allows you to record database calls, calls to lock management, calls to table 

buffers, and remote calls of reports and transactions from the SAP system 

itself in a trace file. You can call the Performance Trace using transaction 

ST05 or by choosing the menu path Tools → Administration → Monitor → 

Traces → Performance Trace. On the initial screen of transaction ST05, you 

can choose the Explain SQL button to analyze an SQL statement without 

branching to a specific trace file. 

The performance trace is integrated into the ABAP Workbench as a test 

tool and can therefore be called there. 

Configuring the Trace File 

You can use system profile parameters to restrict the size of the trace files 

and to specify an appropriate path. 

The SAP System Trace writes the trace data in its trace files. For 

performance reasons, this is not done directly, but rather using a 

process-internal buffer. The profile parameter rstr/buffer_size_kB 

determines the size of the buffer. Since SAP Web AS 6.10, the SAP trace 

stores the data in multiple files, which are written in turn. The parameter 

rstr/filename defines the base name of these files. There is always a 

file with exactly this name. When the file becomes full (parameter 

rstr/max_filesize_MB), the file is renamed and a new file is generated with 

the base name. When the file is renamed, a number between 00 and 99 

is added to the file name. The parameter rstr/max_files determines the 

maximum total number of files. If this value is exceeded, the files are 

overwritten. 

As a demo, display the profile parameters starting with rstr for configuring 

the trace file. Use transaction RZ11 to do this. 

Developer Trace 

Developer traces are recordings that contain technical information and 

thatareusediferrorsoccur.Thistypeofprocesstraceisespeciallyuseful 

to investigate host and internal SAP problems that are affecting your 

SAP system. Developer traces dev_ * are written to files in the directory 

/usr/sap///work of the SAP application server that 

generated the trace. 



Figure 171: Developer Traces 

You can access the developer traces using the operating system, using 

transaction AL11, or from transaction SM50 (Work Process Overview). 

In transaction SM50, you can switch to the individual dev_* traces by 

choosing Process → Trace → Display File. You can display additional details 

in the displayed traces by expanding individual entries. 

As a demo, use transaction AL11 to display any developer trace in the 

directory /usr/sap///work. In addition, you can 

show in transaction SM50 that it is possible to reset trace files from there 

and that the trace level can be changed. Call transaction SM50 and choose 

the menu path Process → Trace. From here, you can switch to the following 

functions: display file, reset, and so on. 



467 Exercise 30: Trace Options 




• Use trace options in the SAP system if errors occur to analyze the 

problem 

• Use the transactions for the various trace functions 


You want to use trace functions in the SAP system to correct errors. 

System Data 




ADM100: client 100. 


user with authorization to execute transactions ST01, ST05, SM21, ST22, 

and AL11 is required. For course ADM100, the ADM100-## users (where 

## corresponds to the group number) have the required authorizations. 




1. The user requires authorizations to execute transactions ST01, ST05, 

SM21, ST22 und AL11. 

Task 1 Traces 

Activate traces in the SAP system and evaluate them. Generate a short 

dump in the system and analyze it. 

1. In transaction ST01, activate the trace for authorization checks, RFC 

calls, and for lock operations for your user. Start the transaction for 

user maintenance SU01 and change the title for your own user. 

2. Deactivate the trace again and evaluate the trace file. 

3. In transaction ST05, activate the SQL trace for your user. Start 

transaction SA38 and run program RSUSR000. Deactivate the trace 

again and evaluate it. 




Task2AnalyzeaShortDump 

Generate a short dump and analyze it. 

1. Use the Function Builder (transaction SE37) to execute the 

remote-capable function module RFC_SYSTEM_INFO with the RFC 

connection TRACES_ST22. Analyze the short dump that occurs when 

you do so. 



Solution 30: Trace Options 

Task 1 Traces 

Activate traces in the SAP system and evaluate them. Generate a short 

dump in the system and analyze it. 

1. In transaction ST01, activate the trace for authorization checks, RFC 

calls, and for lock operations for your user. Start the transaction for 

user maintenance SU01 and change the title for your own user. 

a) Call transaction ST01 and select authorization check, RFC calls, 

and lock operations. In addition, you can choose the General 

Filters button to restrict the trace to your own user. Start the trace 

by choosing the Trace on button. 

b) Call transaction SU01. Select your user and choose the menu 

entry User Names → Change. OntheAddress tab page, change 

the title, and save your change. 

2. Deactivate the trace again and evaluate the trace file. 

a) Call transaction ST01 and choose the Trace off button. 

b) To evaluate the generated trace file from transaction ST01, choose 

Goto → Analysis and select Authorization Check, RFC Calls, and 

Lock Operations. You can now jump directly to the program 

code by double clicking a data record and then choosing the Go 

to ABAP Position button. 

3. In transaction ST05, activate the SQL trace for your user. Start 

transaction SA38 and run program RSUSR000. Deactivate the trace 

again and evaluate it. 

a) Call transaction ST05 and select SQL Trace. Start the trace by 

choosing the Activate Trace with Filter button, and enter your 

user as the selection criterion. 

b) Start program RSUSR000 in transaction SA38 and stop the trace 

in transaction ST05 by choosing Deactivate Trace. 

c) To evaluate the generated trace file, call transaction ST05, choose 

the Display Trace button, and select SQL Trace. You can now 

display the SQL commands in plain text by selecting a data 

record and choosing Explain. 

Task2AnalyzeaShortDump 

Generate a short dump and analyze it. 




1. Use the Function Builder (transaction SE37) to execute the 

remote-capable function module RFC_SYSTEM_INFO with the RFC 

connection TRACES_ST22. Analyze the short dump that occurs when 

you do so. 

a) Call transaction SE37 and enter the remote-capable function 

module RFC_SYSTEM_INFO in the Function Module field. Test 

the function module by choosing Function Module → Test → 

Single Test or F8. On the next screen, enter the following RFC 

connection in the RFC target sys: TRACES_ST22. Now choose 

Function modules → Execute or F8 to start the function module. A 

short dump is generated. 

b) Start transaction ST22 and display the short dumps from today 

by choosing the Today button. Find the relevant entry and display 

the details by double clicking the entry, or by choosing Short 

Dump → DisplayLongText. Read the text in the Error Analysis 

section. The error text partner not reached (host localhost, service 

sapgw23) is displayed, that is, the instance number 23 is entered 

in the RFC connection, although this instance does not exist. 









Lesson: 

471 

Troubleshooting Procedure 



This lesson describes a general procedure for troubleshooting. 




Caution: This lesson is about highlighting a possible 

troubleshooting method. Troubleshooting always involves 

experience, background knowledge, and, of course, intuition. With 

experience, you recognize a number of problems, and may deviate 

from the strategy set out in the following and check familiar error 

sources in a targeted way. If the error is a simple one, it can be 

corrected with a little background knowledge. If the error is more 

complex, more detailed background knowledge is required. You 

should therefore stress the focus on gaining additional knowledge. 

What is a simple error, and what is a more complex error depends 

on the experience of troubleshooter. With background knowledge, 

you usually check the scenario when analyzing problems; that is, 

check whether everything is correctly set up. Unfortunately, errors 

usually occur in unexpected places, and it is therefore only possible 

to describe a rough procedure for troubleshooting. You must 

highlight that finding the error always depends on the intuition 

and experience of the troubleshooter. You must also explain to the 

participants that SAP Notes can be used to achieve quick error 

correction. 


Unexpected problems are occurring during running operation of your SAP 

systems. As a member of the system administration team, you want to 

learn about the procedure for structured troubleshooting. 

General Approach 

It is part of their nature that errors always occur in places that they should 

not occur. It is therefore only possible to present a general approach. Front 

end printing is used to represent possible errors for examples. 


ADM100 Lesson: Troubleshooting Procedure 

You will run through the steps in the figure “Troubleshooting: Approach” 

when troubleshooting. 

Figure 172: Troubleshooting: Approach 

Isolate the problem area: First attempt to isolate the error. Where does it 

occur, when does it occur, and in what context does it occur? “It doesn’t 

print”, would be too imprecise here. “Front end printing on front end xyz 

does not work with any SAP system”, is more exact. If you also know that 

front end printing works on other front ends, you have already isolated 

the problem. 

Problem Analysis: Check the scenario to find out whether all required 

settings, and so on are correct. Check the application logs, the system log, 

and the traces (the developer traces will usually be helpful here), to see 

whether they provide any clues for correcting the error. 

Gain additional knowledge: To interpret the results from the first problem 

analysis, it is, of course, necessary that you are familiar with the processes 

and functions of the area in which the error is occurring. If your experience 

and your previous knowledge are insufficient, you can start a search in the 

SAP Notes and on the SAP Service Marketplace with the keywords from 

the system log or the trace files. You may find a problem solution here, or 

additional information that helps you find and correct the error. If you 

have not found any suitable SAP Notes or suitable search terms, search 

for composite notes for the topic area. In this case, for example, with the 



terms Front end printing and composite note. For additional background 

information for the topic area, see the online documentation and course 

materials. If you still cannot solve the problem with this information, use 

the comparison between the process with errors, and an error-free process. 

Compare error-free and erroneous processes: You can use this to determine 

where there are differences between an erroneous and an error-free 

process. This information helps you to further isolate the problem area 

and may help you to solve the problem or to perform new, more targeted 

problem analyses. If it is not possible to perform another problem analysis, 

create a message for SAP on the SAP Service Marketplace. Enter the 

information from your troubleshooting (such as a trace and/or system log 

information) when doing so. 


ADM100 Lesson: Troubleshooting Procedure 












ADM100 Lesson: Appendix - Troubleshooting Example 

Lesson: 

475 

Appendix - Troubleshooting Example 



This lesson is intended as an appendix to the Troubleshooting Procedure 

lesson. The troubleshooting procedure is shown using an example of 

troubleshooting front end printing. If problems occur with front end 

printing, this lesson will help you to understand front end printing better 

and possible to correct the error. 




Caution: This lesson is an appendix and is not normally 

intended for presentation in the ADM100 course. If necessary, 

the participants can follow this lesson after the course to solve 

problems with front end printing. This lesson requires experience 

of print administration, and in particular of front end printing. The 

instructor can set this lesson as an additional task for especially 

able participants. 

If you want to present this lesson, we recommend that you perform a 

demonstration in the system instead of showing the screenshots. 


Unexpected problems are occurring with front end printing during 

running operation of your SAP systems. As a member of the system 

administration team, you want to learn about the procedure for structured 

troubleshooting for front end printing. 

Troubleshooting Front End Printing 

General Conditions 

We are assuming here that there are problems with front end printing, and 

that we have isolated them as follows: Problems are occurring with front 

end printing for all SAP systems at some front ends. As an example, we 

will now analyze the problems between an SAP system and a front end 

and correct the error. The error correction can then be performed on the 

otherSAPsystemsorfrontendsinthesameway. 



Search for Information about the Error: 

• Checking the system log does not provide any relevant information 

about the error 

• Checking the developer trace does not provide any relevant 

information about the error 

• In transaction SP01, you find the information that SAPLPD cannot 

be started. 

Your search in the SAP Notes Database on the SAP Service Marketplace 

with the keywords frontend printing and SAPLPD provides, among other 

things, SAP Note “379515: Troubleshooting frontend printing”. This 

SAP Note provides additional useful information about the process of 

front end printing and troubleshooting front end printing. The following 

sections “Process of a Front End Print” and “Activating the Trace” contain 

information from this SAP Note that is useful for additional error analysis. 

Process of a Front End Print 

The end user is logged on to an SAP system with SAP GUI. A list is to be 

printed using front end printing (access method F) on the “default” front 

end printer. 

If the end user has selected the output device for front end printing and 

the print time Print immediately, then the first step is processing by a dialog 

work process. It creates a spool request. In the second step, the spool work 

process is given the task of outputting the spool request. If a spool work 

process is running on the application server (on which the user is logged 

on), it processes the spool request. Otherwise, a spool work process on a 

different application server is used. The spool work process creates an 

output request and transfers this to the SAP GUI of the end user in the 

third step. In the fourth step, the SAP GUI uses lprintg.dll to start saplpd 

(if this is not already running), and the data is transferred to this program. 

saplpd receives the data and forwards it to the operating system spooler. 

In the fifth step, the data is transferred from the operating system spooler 

to the printer. See the figure: “Process of Front End Printing 1” 



Figure 173: Process of Front End Printing 1 

During the error analysis, this route is reproduced step by step, and 

checked to find out whether or which errors occur during it. To do this, it 

is necessary to activate the trace options at various points. The following 

procedure has been successfully used in practice: 

Activating the Trace: 

• In transaction SPAD, copy the output device which has problems 

with front end printing and use this new output device for your tests 

during troubleshooting. The new short name helps you to locate 

trace output. 

• Activate the debugger for the front end printer in transaction SPAD, 

by choosing Edit → Test Tool. The system displays a new tab page, on 

which you should activate a level 2 trace. Trace data is now logged 

in the processing dialog work process. In addition, on the tab page, 

you can choose to log the first 10 KB or 100 KB. You can then use 

transaction SP01 to display this data. 

• On the initial screen of transaction SPAD, choose Settings → Spool 

System. OntheFrontend Prnt. tab page, set the Trace level for frontend 

printing to 1. This means that additional trace data is logged for SAP 

GUI communication in the processing spool work process. 



• Check whether you have the newest version of LPRINTG.DLL on the 

front end. To do this, choose the menu entry About SAP Logon in 

SAP Logon and then Loaded DLLs. 

Caution: LPRINTG.DLL is only loaded once you have logged 

on to the SAP system. 

If necessary, install the newest version of LPRINTG.DLL and the 

newest version ofSAPLPD in the SAPgui directory. Use SAP Note 

328252 on the SAP Service Marketplace to do this. You can download 

the dll directly from there, from the Attachments tab page (you may 

have to display additional tab pages first by choosing the double 

arrow). After installing the dll, log off all SAP systems on the front 

end and log on to the SAP system in which you want to solve the 

front end printing problems. 

• Activate the trace for LPRINTG.DLL by setting the environment 

variable DPTRACE to 3. With Microsoft Windows 2000, you set 

environment variables underSystem in the Control Panel. Onthe 

Advanced tab page, choose Environment Variables.... Thesystemthen 

displays a window in which you can set the environment variables 

under System Variables. 

Caution: After setting the environment variable, you must 

close and then restart SAP Logon. 

The trace output is written to the file lprintg.log, which is usually 

in the SAPworkdir directory of your front end. 

Once the environment variable has been set, it must be confirmed 

with OK, otherwise it does not take effect. 



Figure 174: Process of Front End Printing 2 

If all traces are activated, you can perform a test print with the front end 

printer (that you copied for the test) (the figure “Process of Front End 

Printing 2” shows the process of the front end printing and the places in 

which trace information is written). Since errors can, of course, also be 

user-dependent, the test should be performed under the user with which 

theproblemshaveoccurred. 

Inthefirstapproach,wedescribeanerror-freeprintprocess,whichcan 

then be used as a guide for troubleshooting. 

Error-Free Front End Printing 

We perform an error-free front end print with the additional activated 

trace information. We use this trace information when analyzing errors for 

comparison purposes and to isolate the problem. 



Figure 175: SP01 Output Request: 1 

You obtain the first information in transaction SP01, for the output request. 

See the figure “SP01 Output Request: 1”. The status provides a first clue 

about where problems have occurred. You can view the complete status 

information by choosing the Output Request Status button. You obtain more 

information in the dialog box Status Description Request xxx by choosing 

Events. 

Check Developer Traces: 

Figure 176: Dialog Work Process Trace: 1 

You now check the traces in the sequence in which the data is processed. 

The spool request is created by a dialog work process. Therefore, you check 

the developer trace of the dialog work process that processed the request. 

To do this, you can search all of the developer traces of the SAP application 

server on which the user is logged on, or, in a Command Prompt (in the 

caseofUNIX:inashell),switchtotheSAPapplicationserver’swork 

directory. You can use the command qgrep from the Windows Resource 



Kit to search for the trace file here. If the front end printer has the short 

name TFRP, the call is: qgrep -l -e TFRP dev_* . All trace files in 

which TFRP (case-sensitive) appears are displayed. The name of the 

developer trace in which the text was found is displayed at the start of 

each line (with UNIX: use the grep command to perform the equivalent 

function). You can check the trace files from the operating system or from 

transaction SM50 . In Printer Trace in the dialog work process trace 

file, you find the line S Send Message (P) to Spoolserver xxx. 

See also figure “Dialog Work Process Trace: 1”. A spool work process of 

the specified spool server takes over the creation of the output request. 

You also find information in the dialog work process trace about the spool 

number and output request number, which helps you assign the trace data 

to the spool request (or output request). 

Figure 177: Spool Work Process Trace: 1 

In the spool work process trace, searchforthelocationwiththeTCP_OPEN 

entries. Highlighted section 1 in the figure “Spool Work Process Trace: 1” 

shows the spool number and output request number, with which you can 

ensure that you are viewing the correct trace information. Highlighted 

section 2a shows the TCP_OPEN call to the front end. The retcode = 

2 in highlighted section 2b is the return value and means that SAPLPD 

was not started. It is now started (TCP_START). The line in highlighted 

section 3 specifies (retcode = 0), that SAPLPD is running and that 

data can be transferred. The data transfer now takes place. This is the 

TCP_WRITE_BINARY and TCP_READ_BINARY blocks. The S


In the same way, you can find the corresponding information for the 

receiving side on your front end in the lprintg.log file. The highlighted 

sections 2a and 2b in the figure “ Spool Work Process Trace: 1” corresponds 

to the highlighted section in the figure “lprintg.log: 1”. 

Figure 178: lprintg.log: 1 

In the first TCP_OPEN call,itisnotpossibletocreateaconnectionto 

SAPLPD (message: NiRawConnect failed with code=-10), since 

it is not started. SAPLPD is started in the TCP_START block. There 

is then another TCP_OPEN call, which is successfully completed with 

the started SAPLPD. The data transfer now takes place. This is the 

TCP_WRITE_BINARY and TCP_READ_BINARY blocks. The data transfer 

ends at TCP_CLOSE finished. 



Example 1: SAPLPD Could Not Be Started 


You find the first clues to the problem in transaction SP01 (see the figure: 

“SP01 Output Request: 2”). Checking the spool trace produces the result 

that SAPLPD is not started, and an error occurred when an attempt 

wasmadetostartit. ThisisshownintheTCP_START line by msg = 

INTERNAL and retcode = 1 (seethefigure“SpoolWorkProcessTrace: 

2”). 


You find additional information on the front end in the lprintg.log log file 

(see the figure: “lprintg.log: 2”). 




The information in highlighted section 2 indicates that saplpd.exe could 

not be found. The call path for SAPLPD relative to the SAP GUI directory 

is specified in the lines of highlighted section 1. To correct the error, move 

SAPLPD to the specified directory. Another test of the front end printing 

should now run successfully. 

Example 2: Port 515 Is Occupied on the Front End 

You find the first clues to the problem in transaction SP01 (see the figure: 

“SP01 Output Request: 3”). 


Checking the spool trace shows that SAPLPD is already started and that 

data is transferred to it (see highlighted section 1 in the figure: “Spool 

Work Process Trace: 3”). 




However, no SAPLPD was started on the front end. Further down in the 

spool trace (highlighted section 2), you now see that an error is occurred 

during the data transfer (msg = INTERNAL and retcode = 2). The log 

file lprintg.log contains the corresponding entries for the front end side. 

These are shown in the figure “lprintg.log: 3” as highlighted sections 1 and 

2. Highlighted section 2 shows that an error occurred. 


You can make the following conclusion: A program is “listening” at port 

515 at the front end (this is the default port, on which SAPLPD runs). The 

data is transferred to the SAP GUI and forwarded to the port by lprintg.dll. 

This is why there are corresponding entries in the log file lprintg.log. You 

can now configure a different port for the program which is occupying 

port 515, or assign a different, free port to SAPLPD (follow the instructions 

in SAP Note 114426 if doing this). 



You can use the command: netstat-a-n to display the ports on the 

front end. To change the port for SAPLPD, set the environment variable 

LPRINT_PORT on the front end to, for example, 516. You must close 

all SAP GUI windows and SAP Logon for this to take effect. netstat 

-a shows the logical occupancy instead of the numbers of the ports (for 

example, in the case of SAPLPD: printer). 

In SAP Note 114426: Frontend Printing (collective note) describes, among 

other thing, the environment variable LPRINT_PORT. 



485 Exercise 31: Appendix - Error Analysis for 

Front End Printing (OPTIONAL) 




• Set and interpret the required traces to analyze front end printing 


Caution: This exercise should not be performed with the 

participants during the course. It requires a deep understanding of 

the system, and in particular of front end printing. 

It is, like the associated lesson, intended as an extra for experts. 

Errors are occurring with front end printing. It is your task to localize and 

correct these errors. 

System Data 

System: System for ADM100 

Client: 100 

User ID: ADM100-##. 

Password: INIT. 


1. SAP GUI must be set up on the ADM100 server with a release status 

of at least 6.20. 

1. There must be DEV and QAS subdirectories in the SAPgui directory 


1. There must be a saprouter directory containing saprouter.exe and 

saprouttab in the ADM100 directory at operating system level (in the 

ADM100 course: G:\Additional_Files\ADM100). 

2. The programs ZPRINTERROR and ZPRINTSOLUTION must exist 


3. There must be a front end printer with the name “tfrontendprinter” 

and the short name “TFRO”. 



Task 1 Preparing the Analysis 

Caution: You must perform the following task from the operating 

system of your SAP system. This also applies for work that you 

would “normally” perform at the front end. Ensure that you are 

logged on at operating system level as adm. StarttheSAP 

GUIfromtheoperatingsystemoftheSAPsystem. 

This exercise deals with front end printing, which is normally performed 

fromthefrontend. However,sincenoadministrativeauthorizations 

are usually assigned on the front ends in the training rooms in which 

this training course is taking place, it is not possible to set environment 

variables and so on on these front ends. However, you have these rights 

on the servers on which the SAP systems are running. The exercises are 

therefore performed on the SAP system servers using the RDP client. 

Explain this to your course participants. Inform them that the group for 

the DEV systems must be logged on with the user devadm and the group 

for the QAS system must be logged on with the user qasadm, so that the 

groups do not disrupt each other. 

Prepare your system for analyzing front end printing problems. 

1. In transaction SPAD, copy (or use Create Using Template) thefront 

end printer tfrontendprinter to tfrontendprinter2 and assign the 

short name TFRP to this output device. Activate the level 2 trace for 

this output device. 

2. Set the trace level for front end printing to 1. 

3. Activate the trace for your user adm (using an entry in the User 

variables for adm, not in the System variables)forLPRINTG.DLL, 

by creating a new environment variable. 

4. For your user adm, set the environment variable LPRINT_PORT 

depending on your (User variables for adm, not System 

variables). If your =DEV, set the variable to 516. If your 

=QAS, set the variable to 517. 

This sets the port at which SAPLPD listens from the standard value to 

a different free value. This means that it is possible for two SAPLPDs 

to run independently of each other (one for each group). 

5. Close all SAP GUIs and SAP Logon. 




Caution: The environment variables that you have set only 

take effect when you restart SAP Logon and with a new SAP 

GUI. 

Task 2 Perform a Front End Print 

Perform a front end print on the server on which your SAP system is 

running. 

1. Use the front end printer with the short name TFRP to perform a front 

end print. Print the output of transaction SM51 with immediate 

output. 

2. Check whether SAPLPD was started. 

Check the status of the output request in transaction SP01. 

Hint: The processing of the output request is traced 

step-by-step and checked in the following tasks. 

3. Find out which dialog work process generated the spool output. 

4. Use the developer trace of the dialog work process to discover which 

instance generated the output request. 

5. Identify the spool work process that generated the output request. To 

do this, investigate the spool work processes of the instance that you 

identified in the previous task. 

6. Check whether SAPLPD was started in the spool work process trace. 

7. Use the lprintg.log log file to check whether SAPLPD was restarted. 

8. Check the port with which SAPLPD was started in the lprintg.log log 

file. You can find this information in the line: Using port xxx. 

9. End your SAPLPD. 

Caution: Ending SAPLPD is necessary for the next task. Do 

not resetanyofthetracefiles,butratherusetheopportunity 

to compare the trace files for erroneous front end print 

processes with those of an error-free front end print process. 

Task 3 Example 1: SAPLPD 

SAPLPD could not be started. 

1. Start the program ZPRINTERROR in your SAP system. 




2. Perform another front end print with immediate output. Print the 


3. Analyze the error. To do this, compare the trace information and 

the information from transaction SP01 with the information for the 

successful front end print from the previous task. 

4. Correct the error as described in the solution and perform another 

front end print. 



not reset any of the trace files, but rather use the opportunity 



Task 4 Example 2 (Optional): 

Port is occupied. 

1. Switch to the directory g:\Additional_Files\ADM100 .Inthe 

saprouter directory, open a command prompt. Start saprouter with the 

following call for the DEV group: saprouter -r -S 516 or with 

the following call for the QAS group: saprouter -r -S 517 

2. Perform another front end print. 








Solution 31: Appendix - Error Analysis for 

Front End Printing (OPTIONAL) 

Task1PreparingtheAnalysis 

Caution: You must perform the following task from the operating 

system of your SAP system. This also applies for work that you 

would “normally” perform at the front end. Ensurethatyouare 

logged on at operating system level as adm. StarttheSAP 

GUIfromtheoperatingsystemoftheSAPsystem. 

This exercise deals with front end printing, which is normally performed 

from the front end. However, since no administrative authorizations 

are usually assigned on the front ends in the training rooms in which 

this training course is taking place, it is not possible to set environment 

variables and so on on these front ends. However, you have these rights 

on the servers on which the SAP systems are running. The exercises are 

therefore performed on the SAP system servers using the RDP client. 

Explain this to your course participants. Inform them that the group for 

the DEV systems must be logged on with the user devadm and the group 

for the QAS system must be logged on with the user qasadm, sothatthe 

groups do not disrupt each other. 

Prepare your system for analyzing front end printing problems. 

1. In transaction SPAD, copy (or use Create Using Template) thefront 

end printer tfrontendprinter to tfrontendprinter2 and assign the 

short name TFRP to this output device. Activate the level 2 trace for 

this output device. 

a) In transaction SPAD, start output device maintenance and 

switch to change mode. Place the cursor on the output device 

tfrontendprinter and choose Create Using Template. Assign the 

new name tfrontendprinter2 and save the output device. 

Assign the new short name to the output device at this point. 

Select the new output device again for maintenance. Ensure that 

the access method F is set for the new output device. Activate 

debugging by choosing Edit → Test Tool. The system displays a 

new tab page, on which you should activate a level 2 trace. Save 

the output device. For more detailed information, see the lesson, 

section “Activating the Trace”. 




2. Set the trace level for front end printing to 1. 

a) On the initial screen of transaction SPAD, choose Settings → 

Spool System. OntheFrontend Prnt. tab page, set the Trace level 

for frontend printing to 1. For more detailed information, see the 

lesson, section “Activating the Trace” 

3. Activate the trace for your user adm (using an entry in the User 

variables for adm, not in the System variables)forLPRINTG.DLL, 

by creating a new environment variable. 

a) Activate the trace for LPRINTG.DLL by setting the environment 

variable DPTRACE to 3. With Microsoft Windows 2000, you set 

environment variables under Start → Settings → Control Panel 

→ System → Control Panel. OntheAdvanced tab page, choose 

Environment Variables.... Choose New... under User variables and 

enter the above values. After setting the environment variable, 

you must close and then restart SAP Logon. The trace output 

is written to the file lprintg.log, which is usually in the 

SAPworkdir directory of your front end. 

For more detailed information, see the lesson, section “Activating 

the Trace”. 

4. For your user adm, set the environment variable LPRINT_PORT 

depending on your (User variables for adm, not System 

variables). If your =DEV, set the variable to 516. If your 

=QAS, set the variable to 517. 

This sets the port at which SAPLPD listens from the standard value to 

a different free value. This means that it is possible for two SAPLPDs 

to run independently of each other (one for each group). 

a) With Microsoft Windows 2000, you set environment variables 

under Start → Settings → Control Panel → System → Control 

Panel. OntheAdvanced tab page, choose Environment Variables.... 

Choose New... under User variables and enter LPRINT_PORT and 

set the value to 516 if you are administering the DEV system 

or 517 if you are administering the QAS system. After setting 

the environment variable, you must close and then restart SAP 

Logon. 

5. Close all SAP GUIs and SAP Logon. 




Caution: The environment variables that you have set only 

take effect when you restart SAP Logon and with a new SAP 

GUI. 

a) Follow the instructions in the exercise text. 

Task 2 Perform a Front End Print 

Perform a front end print on the server on which your SAP system is 

running. 

1. Use the front end printer with the short name TFRP to perform a front 

end print. Print the output of transaction SM51 with immediate 

output. 

a) If necessary, use transaction SU3 to set the test printer 

tfrontenddruck2 as the default printer for front end printing and 

activate immediate output there. Alternatively, you can choose 

the Properties button in the printer selection window when 

printing to set the print time to Print out immediately. Printthe 

output list from transaction SM51 with these settings. 

2. Check whether SAPLPD was started. 

Check the status of the output request in transaction SP01. 

Hint: The processing of the output request is traced 

step-by-step and checked in the following tasks. 

a) SAPLPD was started. In transaction SP01, the status for the 

output request is Compl.. The other information is similar to that 

infigure“SP01OutputRequest:1”inthelessontext.Thestatus 

gives a clue as to where problems have occurred. You can view 

the complete status information by choosing the Output Request 

Status button. You obtain more information in the dialog box 

Status Description Request xxx by choosing the Events button. 




3. Find out which dialog work process generated the spool output. 

a) To do this, you can search all of the developer traces of the 

SAP application server on which the user is logged on, or, in a 

Command Prompt at operating system level, switch to the SAP 

application server’s work directory. You can search the trace 

file with the command qgrep. If the front end printer has the 

short name TFRP, the call is: qgrep -l -e TFRP dev_* .All 

trace files in which TFRP (case-sensitive) appears are displayed. 

The name of the developer trace in which the text was found is 

displayed at the start of each line. You can check the trace files 

from the operating system or from transaction SM50 . In the 

dialog work process trace file, you find, in Printer Trace, 

the lineS sending frontend job xxxx/y, amongother 

things. xxxx specifies the spool number and y the output request 

number. You can use this information to identify whether 

the checked spool request was processed by this dialog work 

process. 

For more detailed information, see the lesson, section “Error-Free 

Front End Printing”. 

4. Use the developer trace of the dialog work process to discover which 

instance generated the output request. 

a) You can check the trace files from the operating system or from 

transaction SM50 . In Printer Trace in the dialog work 

process trace file, you find the line S Send Message (P) to 

Spoolserver xxx. xxx specifies which instance generated 

the output request. 

Above this, you find the line S sending frontend job 

xxxx/y. xxxx specifies the spool number and y the output 

request number. Use these to ensure that you are analyzing the 

trace information for your output request. 




5. Identify the spool work process that generated the output request. To 

do this, investigate the spool work processes of the instance that you 

identified in the previous task. 

a) To do this, you can search all developer traces of the spool 

work processes of the SAP applications server identified in 

the previous task. Alternatively, open a Command Prompt at 

operating system level in the work directory of the instance. You 

can search the trace file with the command qgrep here. If the 

front end printer has the short name TFRP, the call is: qgrep -l 

-e TFRP dev_* . All trace files in which TFRP (case-sensitive) 

appears are displayed. The name of the developer trace in which 

the text was found is displayed at the start of each line. View 

only the trace files associated with a spool work process. You 

cancheckthetracefilesfromtheoperatingsystemorfrom 

transaction SM50 . In the dialog work process trace file, you find, 

in Printer Trace, the lineS sending frontend job 

xxxx/y, among other things. xxxx specifies the spool number 

and y the output request number. You can use this information 

to ensure that you are analyzing the trace information for your 

output request. 

6. Check whether SAPLPD was started in the spool work process trace. 

a) In the spool work process trace, searchforthelocationwiththe 

TCP_OPEN entries. Ensure (as in the previous steps) that you are 

analyzing the trace information for the output request. 

For the first TCP_OPEN, you find the return value retcode = 

2. This means that SAPLPD was not started. It is now started 

in the line TCP_START. The return value for this is retcode 

= 0. This means that SAPLPD was started. The subsequent 

TCP_OPEN call is now also successful with retcode = 0. 




7. Use the lprintg.log log file to check whether SAPLPD was restarted. 

a) You can find the lprintg.log log file under c:\Documents and 

Settings\adm\SAPworkdir. SAPLPDwasrestarted. 

You find a TCP_OPEN sequence for this, which follows the 

TCP_START sequence. For the DEV system, this should have the 

following appearance: 

TCP_START called 

Trying to start SAPLPD\SAPLPD.EXE -I 

Trying to start SAPLPD\SAPLPD.EXE -I -r516 

Setting lock for SAPLPD 

Releasing lock 

TCP_START finished 

and for the QAS system: 


Trying to start SAPLPD\SAPLPD.EXE -I 

Trying to start SAPLPD\SAPLPD.EXE -I -r517 




8. Check the port with which SAPLPD was started in the lprintg.log log 

file. You can find this information in the line: Using port xxx. 

a) The port must be 516 for the DEV group and 517 for the QAS 

group. 

You can find the lprintg.log log file under c:\Documents and 

Settings\adm\SAPworkdir. 

The Using port xxx information is in approximately the fifth 

lines of the TCP_OPEN sequences. 

The TCP_START sequence for the start of SAPLPD also contains 

the information about the port on which it is started. Port 

516 is specified in the following line:Trying to start 

SAPLPD\SAPLPD.EXE -I -r516 










Task 3 Example 1: SAPLPD 

SAPLPD could not be started. 

1. Start the program ZPRINTERROR in your SAP system. 

a) Start transaction SA38 and enter the program ZPRINTERROR. 

Choose F8 to Execute. 

2. Performanotherfrontendprintwithimmediateoutput. Printthe 


a) This time, SAPLPD should not be started, and no print output 

should be produced. 

The procedure corresponds to task 2.2.. The solution is described 

there in detail. 




a) The report ZPRINTERROR entered in the SAP system that the 

system should look for SAPLPD in the directory under 

the SAPgui directory. That is, SAPLPD is not found. 

The procedure corresponds to tasks 2.3 to 2.6. The solution is 

described there in detail. The only difference is that you find the 

following entry in lprintg.log: 


Trying to start \SAPLPD.EXE -I 

Trying to start \SAPLPD.EXE -I -r51x 




(x=6 for the DEV system (=DEV), x=7 for the QAS system 

(=QAS)). The system is therefore searching for SAPLPD 

in a directory in which it does not exist. 






a) On the initial screen of transaction SPAD, choose Settings 

→ Spool System. Check the entry for SAPLPD start 

command for frontend printing. Enter the default SAPLPD 

path here (SAPLPD\SAPLPD.EXE -I). The system now 

searches for SAPLPD in the directory c:\Program 

Files\SAP\FrontEnd\SAPgui\SAPlpd again. The report 

ZPRINTERROR had (deliberately) entered a path in which there 

was no SAPLPD. 

Front end printing should now work without errors again. 







Task 4 Example 2 (Optional): 

Port is occupied. 

1. Switch to the directory g:\Additional_Files\ADM100 .Inthe 

saprouter directory, open a command prompt. Start saprouter with the 

following call for the DEV group: saprouter -r -S 516 or with 

the following call for the QAS group: saprouter -r -S 517 

a) You are now occupying the port that SAPLPD should use. For 

more detailed information, see the lesson, section “Example 2”. 

2. Perform another front end print. 

a) This time, SAPLPD should not be started, and no print output 

should be produced. 

The procedure corresponds to task 2.2.. The solution is described 

there in detail. 







a) Since the port at which SAPLPD listens is occupied, the system 

assumesthatSAPLPDisrunning.However,thisisnotthecase. 

The procedure corresponds to tasks 2.3 to 2.6. The solution is 

described there in detail. 

The information from transaction SP01 is similar to the figure 

“SP01OutputRequest:3”inthelessontext. Thespooltrace 

information is similar to the figure “Spool Work Process Trace: 

3”. 

No SAPLPD was started on the front end. An error occurred 

during the data transfer in the spool transfer (msg = INTERNAL 

and retcode = 2). In the log file lprintg.log, you also find this 

in the lines TCP_WRITE_BINARY called ... NiRawWrite 

failed with code =-6. 

You can make the following conclusion: A program is “listening” 

at port 51x . The data is transferred to the SAP GUI and 

forwarded to the port by lprintg.dll. Thisiswhythereare 

corresponding entries in the log file lprintg.log. You can now 

configure a different port for the program which is occupying 

port 515, or assign a different, free port to SAPLPD (follow the 

instructions in SAP Note 114426 if doing this). 



a) Switch to the directory g:\Additional_Files\ADM100 . 

Open a Command Prompt in the saprouter directory. Stop the 

running saprouter with the following call for the DEV group: 

saprouter -s -S 516 or the following call for the QAS 

group: saprouter -s -S 517. Frontendprintingshould 

nowbepossibleagain. 

Thisprocedureispossiblehereinthecourse.Inpractice,you 

would, of course, have to check whether you can configure 

the program (which is occupying the port) on another port, or 

configure SAPLPD on another port. 







The following SAP Notes may help you when analyzing front end printing 

errors: 

• SAP Note 379515: Troubleshooting Frontend Printing 

• SAP Note 328252: SAPLPD Patches in SAPNet 

• SAP Note 114426: Frontend Printing (Collective note) 



Unit Summary 










499 


1. With which of the following transactions can you activate a trace for 

SQL statements in the SAP system? 


A Performance trace 

B System log 

C System trace 

D Database performance analysis 

2. Which port does SAPLPD use under Microsoft Windows, by default? 


A 007 

B 515 

C 516 

D 517 

E 815 

F The port defined by profile parameter rspo/port 



500 

Answers 

1. With which of the following transactions can you activate a trace for 

SQL statements in the SAP system? 

Answer: A, C 

You can analyze SQL statements by activating the trace in transaction 

ST01 (system trace) or ST05 (performance trace). Transaction SM21 

(System Log) is the system log and ST04 (Database Performance 

Analysis) is used to analyze database statistics. 

2. Which port does SAPLPD use under Microsoft Windows, by default? 

Answer: B 

Port 515 is used by default. 


Unit 16 

501 Introduction to System Security 

Although this unit has a strong overview character, the instructor should 

be prepared for more detailed questions. If there are appropriate questions, 

the instructor could digress a little, if he or she is familiar with the area. 

However, the intention of this unit is not to replace a security course with 

the basics of cryptography. The instructor can direct participants to the 

more advanced SAP courses in the area of IT security. 

Unit Overview 

This unit will present a number of aspects of system security. Familiar 

concepts of users administration will be briefly repeated with special 

consideration given to the security aspects. Approaches for securing data 

exchange, such as SNC, SSL, and SSF will then be introduced. Topics such 

as SAProuter and digital signatures will complete the unit. 



• Evaluate basic security aspects of an SAP system 

• List system parameters that affect security settings in clients or in 

the system 

• List implementation areas of Secure Network Communication (SNC), 

Secure Socket Layer (SSL), and Secure Store and Forward (SSF) 

• Describe SAProuter in detail 

• Describe a central administration server 

Unit Contents 

Lesson: Security in the SAP Environment...................................586 


Unit 16: Introduction to System Security ADM100 

Lesson: 

502 

Security in the SAP Environment 



Sensitive business data should always be exchanged using only encrypted 

data lines. In this lesson, you will learn about various security measures 

for an SAP system. 





the system 





Explain the importance of security measures in the SAP environment 

in particular, and for IT in general. You may want to refer to actual 

cases, which should be documented in the Internet, that illustrate the 

consequences that a lack of security awareness can have. 


You are to implement a security concept in your company, which is 

to protect your SAP systems against hacker attacks and ensure secure 

operation of an online store using an SAP ITS. 

Clients and Superusers 

Encryption mechanisms, system-side security settings and SAProuter 

software are some of the components that support you in implementing 

your security concept. 


ADM100 Lesson: Security in the SAP Environment 

Figure 185: Users and Clients 

Explain to the participants that, in addition to SAP system users, there 

are also database users and operating system users. Depending on the 

database, database users have their own standard passwords, which 

should be changed after installing an SAP system. Operating system users 

do not have standard passwords to be changes, since they are only created 

with the installation of the SAP system. 

There is also the standard user SAPCPIC in client 000 (of the type 

Communication) with the standard password ADMIN. 

Caution: As an operating system user of a particular user group, it 

is,forexample,possiblewithOracletologontothedatabaseas 

an administrator as internal without a password. In this case, 

it is possible to delete the entry for the user “SAP*” for a client 

from the relevant control table (USR02), to then log on to the SAP 

system with the “SAP*” user stored in the kernel and the familiar 

standard password. The parameter login/no_automatic_user_sapstar 

exists for this reason. 

You should also explain that the client 001 no longer exists as of SAP R/3 

4.6C. Client 001 is, of course, still available for existing systems that have 

been upgraded for an older release status. 

Client 000 cannot be changed and is used as a template for customer 

clients. Client 001 was previously intended for production work. However, 

most customers use a different client, such as client 100. 



You may also want to explain briefly what a client copy is, exactly what 

is copied, and which security risks are involved (users, passwords, and 

authorizations), and so on. 

Clients 000 and 066 are part of a standard SAP system. 

There are two special users in client 000: 

• SAP* for initial access to the system 

• DDIC for working with the Transport Management System (TMS) 

To protect SAP* and DDIC against unwanted access, you should change 

the initial passwords. 

Client 066 is the EarlyWatch client. You should also change the initial 

password for the EarlyWatch user. This user does not have any critical 

authorizations. 

If user SAP* exists in a client, a mechanism coded in the kernel allows you 

to logon with SAP* and the password “pass”. 

Caution: This mechanism also applies if the “proper” SAP* user 

is, for example, deleted from a client using database methods. 

Thatis:AccesstothedatabasemeansaccesstotheSAPsystem. 

This mechanism can be deactivated using the profile parameter 

login/no_automatic_user_sapstar. However, it is then not possible to 

log on to a newly created client, for example to perform a client 

copy. See SAP Note 68048. 

To check the initial passwords, you can also call report RSUSR003. 



System Security and Central User Administration 

Figure 186: User Administration: Central User Administration (CUA) 

The role concept has already been explained in the “Fundamentals of User 

Administration” unit. CUA is presented in detail in SAP course ADM102. 

Outline it again briefly here, and explain it in the context of system security. 

If CUA is active, authorizations should only be maintained centrally in one 

system for the users; you can, however, permit local changes using the 

child systems for addresses or other input fields. 

To simplify the administration of user master records over several logical 

systems, you should use Central User Administration (CUA). In this case, 

a logical system corresponds to a client in an SAP system 

CUA provides an overview of all users, all user groups, defined systems, 

andsystemgroups,anddefinedroles. 

Using the CUA, you can maintain user master records from a single client, 

and distribute this information to all included clients of all systems. In this 

context, there is one logical system that controls the user master records 

of all logical systems. 

Reasons for using CUA: 

• Complex system landscape with multiple clients in different systems 

• The same user works in multiple logical systems 

• The same user name is to represent the same user 



• Synchronizing user data in all of the affected systems would require 

a very large effort 

User Roles 

Figure 187: Roles 

Working with roles simplifies authorization administration, since it is not 

necessary to assign individual authorizations to each user, but rather to 

performthisonceforeachtaskarea.Thisavoidscomplexities. 

A role is a work center description. 

You can assign authorizations to users using role maintenance. You do 

this, for example, by selecting from the SAP menu or by manually inserting 

transactions and URLs. 

Changing a role changes the authorizations of all users assigned this role. 

You must configure role maintenance before you can use it. 

For more information, see online help or the documentation 

“Authorizations Made Easy” from the SAP Simplification Group. 

SAP course ADM940/CA940 also provides additional information about 

administering users in SAP systems. 



Encrypted Data Transfer: SNC 

Figure 188: Secure Network Communication (SNC) 

SAP does not provide encryption itself here, but provides the interface 

to connect encryption tools. 

SNCisusedtoencrypttheDIAGandRFCprotocols,suchasthe 

communication with the SAP GUI or SAPlpd. 

You should explain the three levels of protection in the notes for this figure. 

The explanation of the technologies for this (digital signature, digital 

envelope) is provided later in the lesson. “Authentication” is sometimes 

used, “integrity” is rarely used, but complete encryption is usually used 

for “confidentiality”, such as for online banking or when exchanging 

confidential, person-related data. 

SNC is a software layer in the SAP system architecture that provides an 

interface to an external security product. You can increase the security of 

your SAP system with SNC by implementing additional security functions 

that are not directly provided by SAP systems (such as the use of smart 

cards for user authentication). 

SNC provides security at application level. This means that a secure 

connection is guaranteed between the components of an SAP system 

(for example, between the SAP GUI and the SAP application server, 

irrespective of the communication connection or the transport medium. 

You therefore have access to a secure network connection between two 

communication partners secured with SNC. 



There are three different protection levels for communication connections 

secured with SNC: 

• Authentication only: With authentication, only the identity of the 

communication partner is checked. This is the lowest protection level 

when using SNC. (There is no actual data security.) 

• Integrity protection: If you use the integrity protection, the system 

recognizes changes to the data that have been made during the 

transfer between the sender and the recipient. 

• Confidentiality protection: For the confidentiality protection, the 

transferred messages are encrypted, meaning that eavesdropping is 

pointless. This is the highest SNC protection level. This protection 

level also includes the integrity protection and authentication. 

Figure 189: Secure Network Communication (SNC): Logon 

Outline the Single Sign-On (SSO) process: A user no longer has to 

authenticate himself or herself with the individual SAP systems, but rather 

only once with a security product. After this, when the user attempts to log 

on to a component system, the security product is used to check whether a 

valid logon has already been made. This query is performed, for example, 

using SNC encryption. The user is then given access to the component 

system without having to enter a user name and password. As of SAP Web 

AS 6.10, it is not even necessary to confirm the logon client and language. 

As a final point about SNC, you should explain that there are legal 

regulations about encryption in some countries. 

The steps illustrated in the figure mean the following: 



1. The user logs on to a security product (such as Secude) using Single 

Sign-On 

2. Whentheuserthenlogsontoinvolvedsystems(suchasSAPR/3), 

he or she is not prompted to enter a user name and password 

3. Instead, the system communicates with the security product 

4. The logon string is resolved to the user master record using the Access 

Control List (ACL), allowing the user to access the system. 

The two components of the security product exchange information using 

SNC. 

In some countries, the use of cryptography is legally controlled. If you 

use SNC, you should regularly inform yourself about the effects of these 

laws on your applications, and ensure that you are aware of all further 

developments. 

Encrypted Data Transfer: HTTPS 

Figure 190: Secure Socket Layer (SSL): ICM and HTTPS 

Secure Network Communication (SNC) allows you to encrypt the DIAG 

and RFC protocols (see slides about SNC). Secure Sockets Layer (SSL) 

works in exactly the same way for the HTTP protocol. This creates an 

HTTPS (“S” for “secure”) protocol from the HTTP protocol. In this way, it 

is possible to exchange confidential data, for example over the Internet. 

Among other places, SAP uses SSL: 



• For direct communication between the SAP Web AS and the Internet. 

In this case, the SAP Web AS “speaks” in HTTP. This is possible with 

the Internet Communication Manager (ICM) component, standard 

as of SAP Web AS 6.10. 

• For communication with the Internet using an SAP Internet 

Transaction Server (SAP ITS). In this case, the encryption of the HTTP 

protocol is performed at the Web server which is attached to the 

WGate of the SAP ITS. 

Encrypted Data Storage: SSF 

Figure 191: Secure Store and Forward (SSF) 

This is not an encryption protocol that attaches to an SAP interface, but 

SAPfunctionmodules.Thesecanbeusedbyanapplicationdeveloper,if 

he or she thinks that it is necessary. This is always useful if data leaves the 

protection of the SAP system (diskettes, file system, Internet). These often 

use the technology of digital signatures or digital envelopes. 

SSF ensures that SAP data and documents are secure during and beyond 

dialog transactions. This is the case if 

• Data leaves the system (electronic orders, invoices, information) 

• Data is stored on unsecured media (external database, diskettes, 

archive) 



• Data is transferred using unsecured networks (Internet) 

• Data security relates to people and individuals (digital signatures, 

personal data) 

Aims are therefore: 

• Data security 

• Security of personal data 

• Authentication 

• Non-reproducibility 

This is achieved using digital signatures (see next figure) and digital 

envelopes. Package Key Cryption Standard Number 7 (PCKS#7) is used as 

the standard format. 

Digital Signatures and Envelopes 

Figure 192: Digital Signatures and Envelopes 

Classically, data is authenticated by being signed, for example, in a classic 

paper contract. This is emulated using digital signatures and envelopes. 

A Certification Authority (third person) is required to do this. It assigns 

a private key to each of the two communication partners, and a shared 

public key. The first communication partner can now sign his or her 

documents digitally using both keys (digital signature), or encrypt the 



entire document (digital envelope). The second communication partner 

can now use the public key to identify that the document is “genuine”, but 

cannot copy the encryption. 

This is used, for example, in the contexts of B2B, B2C, HR, and Public 

Sector. 

The ABAP interface for digital signatures and envelopes is SSF (see the 

figure for SSF). 

1. Note for the participants: In general, although it is somewhat 

imprecise and difficult to compare: “It is easier to forge a signature 

than to copy a digital signature.” 

2. The effort required to “crack” a digital signature or a digital envelope 

depends on the encryption procedure used and, above all, on the 

length of the key (in bits). Some countries have restrictions that affect 

the legally allowed key length. Obviously, this ensures that the law 

enforcement agencies can still decode encrypted messages. 

A Certification Authority (CA) issues a certificate and digitizes it. This 

certificate contains, among other things, the name of the holder, the name 

of the issuer, a validity period, and the public key. The certificate can be 

passed on as desired. 

There is a private key that matches the public key, which only the holder 

may know. The private key cannot be calculated from the public key. 

People that do not know each other directly (for example, in the case of a 

query over the Internet) can communicate authentically with each other 

with the help of the CA. 

SAP uses standard technology for the implementation of digital signatures. 

Digitally signed documents are created as PKCS#7 packages. 

Possible applications: Orders (B2C, B2B), applications (Public Sector), 

cross-system processes, ... 

ABAP interface for digital signatures: Secure Store and Forward (SSF). 

Signatures can by made by application servers or by users with the SAP 

GUI or in a Browser. 

For more information, see the SAP Service Marketplace with the Quick 

Link /security. 



SAProuter 

Figure 193: SAProuter 

See SAP Note 30289. 

The firewall system should control access to servers. It is also possible to 

permit only certain protocols. Ideally, the firewall allows access only to 

the SAProuter. This SAProuter allows, in turn, access only to the message 

server or dispatcher, that is, to a certain port of the SAP server. 

Modern firewalls can also implement this. Nevertheless, in some cases 

(such as for SAPNet - R/3 Frontend access), it is necessary to use a 

SAProuter as minimum protection. 

SAProuter is an SAP program for forwarding SAP system connections 

through firewalls. The SAProuter extends the firewall, but does not replace 

it. We recommend that you use SAProuter together with a firewall. 

Caution: Without other security measures (firewall), a SAProuter 

does not protect your SAP system network. 

Hint: You must use a SAProuter for the SAP Remote Services 

(SAPNet - R/3 Frontend). 

You can also use SAProuter to 



• Control and log connections to your SAP system 

• Create an indirect connection, if the programs involved in 

the connection cannot be reached directly due to the network 

configuration 

• Resolve address conflicts when using unregistered IP addresses 

• Improve network security by: 

– Protecting your SAProuter with a password against 

unauthorized external accesses 

– Only allowing access from certain SAProuters 

– Only permitting the user of secure connections from a securely 

authenticated partner (SNC) 

• Improve performance and stability by reducing the SAP system 

workload within a LAN during communication with a WAN 

If you use SAProuter, you only need to open one port on the firewall for 

aconnectionwiththeportontheserveronwhichSAProuterisrunning. 

All SAP GUI, SAPlpd, and RFC connections must pass this port (default 

3299). For more detailed information about the use of SAProuter, see SAP 

Note 30289. 

Central Administration Server 

Figure 194: Central SAP Web AS 6.20 Administration Server 



SAP Solution Manager: See relevant unit. 

SAP recommends using a central SAP Web AS of this type (at least SAP 

Web AS 6.10, but better if it is always the newest system, if possible 

implemented as a standalone system). It is intended that this will become 

mandatory for all customers at some point in the future. 

The centrally administered function is partly backward compatible, 

depending on availability. 

The central SAP Web AS does not need to run on a separate host, although 

this is perhaps advisable for performance reasons. 

We recommend that you set up a separate SAP Web AS for every SAP 

system landscape. This SAP Web AS should have as high a release status as 

possible, but at least SAP Web AS 6.10, and should be used for monitoring, 

alerts, transport organization, and Central User Administration (CUA). 














the system 







– ADM950 - Secure SAP System Management 

– ADM960 - Security in SAP System Environments 



Unit Summary 




the system 







515 


1. Evaluate the following statements. 


A SAP* and DDIC are SAP users with no critical 

authorizations. 

B Bydefault,userDDICexistsonlyinclient000. 

C HTTP, encrypted using SSL, is called HTTPS. 

D The ICM can accept encrypted connections. 



516 

Answers 

1. Evaluate the following statements. 

Answer: B, C, D 

SAP* and DDIC certainly do have critical authorizations. The other 

statements are true. 


ADM100 Course Summary 

Course Summary 



• Set up system parameters 

• Configure help 

• Schedule database backups 

• Use SAP data archiving 

• Perform and check transports 


• Schedule background tasks 

• Configure printers in the SAP system 

• Createandmanageusers 


• Monitor the system 



• Use system security terms correctly in the SAP environment 



– ADM102 - SAP Web AS Administration II 

– ADM106 - Advanced SAP System Monitoring 

– ADM110 - SAP R/3 Enterprise Installation 

– ADM130 - E-Commerce Administration 

– ADM325 (BC325) - Software Logistics 

– ADM326 - SAP R/3 Enterprise Upgrade 

– ADM940 (CA940) - SAP Authorization Concept 

– ADM950 - Secure SAP System Management 

– ADM960 - Security in SAP System Environments 

– BC315 - Workload Analysis 


Course Summary ADM100 


Glossary 

ABAP 

Advanced Business Application Programming. SAP’s programming 

language. 

ABAP Workbench 

Integrated graphical development environment in the SAP system. 

The ABAP Workbench enables you to develop, modify, test, and 

manage client/server applications that are written in ABAP. 

access method 

The access method describes the connection of a spool work process 

to an operating system spooler. 

activation 

Procedure that makes an object available to the runtime environment. 

During activation, runtime objects are generated, which the 

application programs and screen templates access. 

ALE 

Application Link Enabling technology to create and operate 

distributed applications. 

archive information structure 

A central element in the SAP Archive Information System (AS). Using 

data fields, it enables you to find and display archived data. 

archiving object 

Logical object of related business data in the database that can be read 

from the database using a write program and then deleted from the 

database by the associated delete program after successful archiving. 

background job 

A background job describes steps that are to be executed in the system 

without user interaction (in the background). Background jobs are 

processed by background work processes. 

buffer 

Area in the main memory of an instance in which data frequently 

used by applications can be temporarily stored. 

business object 

Representation of a business object in the real world, such as an order. 

SAP business objects describe entire business processes. This type of 

encapsulation reduces the complexity, since the internal structure of 

the business object remains hidden. 


Glossary ADM100 

central system 

A central SAP system consists of a single instance that provides all 

required SAP services and the associated database. In the case of a 

central system, these are usually on the same computer. 

change request 

Information source in the Transport Organizer that records 

and manages all modifications made to repository objects and 

Customizing settings during a development project. 

client 

A client usually corresponds to the mapping of a company in an 

SAP system. That is, multiple companies can be mapped and active 

in parallel in an SAP system with multiple clients. A key field in 

the business tables of the database associated with the SAP system 

corresponds to the client. From a particular client, you can only access 

the data for that client. In this way, clients correspond to separate 

business entities. 

Softwarecomponentthatusesaserver’s service (software-oriented 

view) or a workstation that is provided with resources by the server 

(hardware-oriented view). 

Computing Center Management System (CCMS) 

Integrated tools for monitoring and administering SAP systems and 

independent SAP business components, with which you can, for 

example, automate operations such as resource distribution and the 

management of SAP databases. 

CPI-C 

The Common Programming Interface for Communication describes 

data exchange between different programs. CPI-C can be used to 

transfer “packaged” data with various technical protocols, such as 

TCP/IP or LU6.2. 

Customizing 

Customizing is the entire procedure of setting up one or more SAP 

systems. The procedure aims to adjust the company-neutral and 

industry-specific functions of the SAP system to your company’s 

specific business requirements. Customizing is obligatory both during 

the first installation and during an upgrade and is performed in the 

SAP system using the Implementation Guide (IMG). 

data archiving 

Reading data from the database that is no longer required for online 

operation, and storing this data in an archive file. Archived data is 

usually deleted from the system. Archiving removes load from the 

system, meaning that programs, database accesses, and database 

backups have shorter runtimes due to the lower quantity of data in 

the database. 


ADM100 Glossary 

development object 

Component of an ABAP application. Development objects include: 

Programs such as transactions, reports, subroutines, and function 

modules; program components such as event blocks, screens, and 

menus; and objects, used by several programs (such as database 

fields, field definitions, and program messages). 

DIAG 

Dynamic Information and Action Gateway: Protocol for 

communication between the SAP GUI and the application server (also 

known as the SAP GUI protocol). 

dispatcher 

Central process of an instance. It is responsible, among other things, 

for starting work processes and distributing the transaction workload 

to the work processes. 

Dynpro 

DYNamic PROgram. A dynamic program consists of a screen image 

and its underlying flow logic, programmed in ABAP. 

enqueue server 

Enqueue server is a possible description for the instance of an SAP 

system on which the enqueue work process manages the lock table in 

a distributed SAP system. 

F4 help 

The F4 help provides you with input help for a field that is ready for 

input. 

front end 

Work center computer 

gateway 

Interface that converts one communication protocol into another 

communication protocol. 

HTML 

HyperText Markup Language (HTML): Document description 

language for creating HTML pages in the Internet. HTML documents 

have a uniform format and consist only of ASCII text. They can either 

be stored statically in the file system of the Web server of be generated 

dynamically at runtime by special programs. The Web servers sends 

them to the Web browser, which interprets and displays them. 

HTTP 

Application protocol of the World Wide Web (WWW). The HyperText 

Transfer Protocol (HTTP) controls communication between the Web 

browser (the HTTP client) and the Web server (the HTTP server). 

instance 

Administrative unit that groups components of an SAP system that 

provide one or more services. These services are started and stopped 

at the same time. 



Internet Communication Manager 

The Internet Communication Manager (ICM) is the component in the 

SAP architecture that allows the SAP system to communicate directly 

with the Internet. 

job 

Closedchainofsteps(suchasABAPprograms)thatcanbecontrolled 

successively using certain control commands. 

LDAP 

Lightweight Directory Access Protocol. A protocol for accessing 

address directories, defined in IETF RFC 1777. 

lock table 

The lock table is a table in the main memory of the enqueue server, 

which contains information about which locks currently exist. For 

each lock that it exists, it shows the owner, the lock mode, the name, 

and the fields of the locked table. 

message server 

Standalone program that contains a list of all instances that are part 

of the SAP system. In the case of a logon using logon groups, the 

message server determines the instance that a user logs on to, and 

organizes the communication between the instances. 

mySAP Business Suite 

mySAP Business Suite is a complete package of open, integrated 

solutions for the whole value chain. The functions of the mySAP 

Business Suite bring together customers, employees, suppliers, and 

partner companies. Information, orders, and service requests can be 

efficiently and directly accessed and processed by the appropriate 

person. 

Object Navigator 

Tools for managing development objects. 

, 239 

output request 

An output request contains the data from a spool request in a format 

for a particular printer model. 

package 

Container for semantically connected development objects. A package 

consists of sub-packages and development objects (programs, tables, 

screens, function modules, classes, and so on) that are developed and 

transported together. Packages are characterized by the properties 

nesting, interfaces, visibility and use accesses. Packages are created 

and managed with the Package Builder. They replace development 

classes. 



Quick Link 

Navigation technology for quick access to certain areas of the 

SAP Service Marketplace. To call a Quick Link, add the Quick 

Link directly at the end of the Web address, after a “/” (such as 

http://service.sap.com/smp). 

repository 

Central store for all ABAP Workbench development objects. The 

development objects stored in the repository of the SAP system 

include: Program objects, function group objects, Dictionary objects, 

Business Engineering objects, and other objects. 

RFC 

Remote Function Call (RFC) is an SAP interface protocol based 

on CPI-C. This significantly simplifies the programming of 

communication processes between systems. 

role 

A role is a collection of activities that a person executes to participate 

in one or more business scenarios of an organization. User menus are 

used to access the transactions, reports, Web-based applications, and 

so on in the roles. 

SAP Archive Information System 

Generic tool fully integrated in data archiving for searching SAP 

data archives. The search and display of data is based on archive 

information structures that the user can define and fill with data from 

the archive. 

SAP ArchiveLink 

A service integrated into the SAP system technology that creates 

a connection between stored documents and related application 

documents (business objects) in the SAP system. 

SAP Easy Access 

SAP Easy Access is the standard initial screen in SAP systems. The 

system displays the menu available to you in a tree structure on the left 

of the screen. You can display your own logo on the right of the screen. 

SAP GUI 

SAP Graphical User Interface; software component with which the 

user can exchange information with the computer. With the user 

interface, you can select commands, start programs, display files, and 

choose other options by pressing function keys or pushbuttons or 

selecting menu options. 

SAP GUI for HTML 

SAP GUI that runs in the Web browser, and generates HTML pages 

dynamically based on SAP screen layouts. Requires an SAP Internet 

Transaction Server (SAP ITS). 

SAP GUI for Java 

Platform-independent SAP GUI, requires a Java environment. 



SAP GUI for Windows 

Implementation of SAP GUI in a Microsoft Windows environment. 

SAP Internet Transaction Server (SAP ITS) 

The SAP Internet Transaction Server (SAP ITS) is an interface between 

the SAP system and the Internet. It allows users to communicate 

directly with the SAP system by starting business transactions, 

function modules, and reports from a Web browser. If a user calls an 

application, the request is forwarded to the Web server with which the 

Web browser is connected. The Web server transfers the request to the 

SAP ITS, which creates a connection to the SAP system. SAP ITS then 

controls the communication and the data exchange between the SAP 

system and the Web server. SAP ITS consists of two main components: 

the WGate (Web Gateway) and the AGate (Application Gateway). 

SAP Logon 

When it is started, the SAP Logon program (only available for 

Microsoft Windows) provides a list of SAP systems for which the 

logon process can be started. This list is taken from the information in 

a file on the front end: saplogon.ini. Thisfileisusuallypreconfigured 

centrally and provided to end users. The SAP Logon program also 

allows logon load balancing across the resources available for the 

selected system at logon. 

SAP NetWeaver 

SAP NetWeaveris the comprehensive integration and application 

platform from SAP. SAP NetWeaver allows you to simplify 

and co-ordinate user, information, and business processes across 

technology and organizations. SAP NetWeaver offers full 

compatibility with the Microsoft .NET and J2EE (z.B. IBM 

WebSphere ) standards. SAP NetWeaver is divided into the 

following areas: People Integration, Information Integration, Process 

Integration, and Application Platform. 

SAP Notes 

An SAP Note is text information about a particular issue, problem, or 

system message that can arise in the context of your work with the 

system. All SAP Notes are stored at SAP in a database that is available 

online, and can be called up by customers from there. A possible 

question could be, for example: “Which database versions of database 

XY are released in combination with my SAP system release?” 

SAP Service Marketplace 

Centralportal(URLhttp://service.sap.com) withservices, 

information, and other offerings for SAP customers and partners. 


An SAP system can be, for example, an SAP R/3, SAP BW, or SAP 

CRM system. SAP systems are the central components of the SAP 

solutions in the context of mySAP Business Suite. 



SAP Web Application Server 

SAP Web Application Server provides complete support for 

platform-independent Web services, business Web applications, and 

developments based on key technologies such as J2EE and ABAP. SAP 

Web Application Server provides the infrastructure for many of the 

solutions and components of the mySAP Business Suite, such as SAP 

R/3 Enterprise, or SAP Business Information Warehouse. It is the 

development and runtime environment for all business applications. 

server 

Software component that provides a service (software-oriented 

view) or a central host in a network that provides resources to local 

computers (hardware-oriented view). 

shared memory 

Main memory area that is accessible for all work processes of an 

instance. 

spool request 

A spool request contains information about data to be output, its 

formatting, and the printer model used. 

System log 

Analysis option for errors in the system and its environment. 

table 

Tabular arrangement of data in the ABAP Dictionary. A table consists 

of columns (sets of data values of the same type) and rows (data 

records). Each table row can be uniquely identified using one or more 

fields. 

TemSe 

Abbreviation for Temporary Sequential file; file in which, among 

other things, data for spool requests and for background processing 

job logs is temporarily stored. 

transaction code 

A transaction code (also known as T code) is a character string that 

identifies a transaction in the SAP system. A transaction code can be 

up to 20 characters in length and should always begin with a letter. 

Permitted characters are letters from A to Y, digits form 0 to 9, and the 

underscore. To call a transaction, enter the transaction code in the 

command field and choose enter. 

transport 

Transfer of SAP system components from one system to another. The 

components to be transported are listed in the object list of a transport 

request. Each transport consists of an export and an import process. 

The export process reads the objects from the source system and stores 

them in data files at operating system level. The import process reads 



the objects from the data file and writes them to the database of the 

target system. The system logs all actions of the export and import 

processes. 

user context 

Data that is assigned specifically to one user. If a user starts a 

transaction in the SAP system, the work process processing the request 

requires the user context. The user context contains a user-specific 

area that contains user and authorization data. 

user master record 

The user master record contains the definition of a user in the client. 

Some fields are, for example: Name, first name, initial password, 

telephone number, and so on. The user master record is used to create 

a user context (see this entry) when a user logs on to the system. 

variant 

Preassignment of the input fields of a selection screen for reports, for 

example to enable the execution of the report in the background. 

work process 

Process that processes requests in the SAP system. There are the 

following types of work process: Dialog (for executing dialog 

programs), update (for changing database entries), background 

(for executing background jobs), spool (for print preparation), and 

enqueue (for executing lock operations). 


A 

access method, 360 

Archive Development Kit, 

202 

archive information 

structure, 204 

archiving object, 176, 185 

aRFC, 453 

authorization object, 415 

B 

background users, 336 

backup, 153 

business object, 176 

C 

central instance, 3, 42 

central system, 3 

change request, 226 

client, 220 

CTS, 219 

customer development, 221 

Customizing, 219 

Customizing request, 230 

D 

data archiving, 176 

data collector, 476 

default profile, 92 

developer trace, 536 

development class, see 

package 

device type, 367 

dispatcher, 5 

dump analysis, 536 

DynamicHelp, 129 

E 

enhancement, 222 

external command, 337 

Index 

external program, 337 

F 

FastRFC, 453 

front end printing, 364 

H 

HtmlHelpFile, 128 

I 

import, 233 

import queue, 233 

inactive import, 270 

instance, 5 

instance profile, 92 

J 

job class, 301 

job server group, 335 

Job Wizard, 304 

L 

local printing, 361 

logon groups, 16 

M 

message server, 8, 14, 43, 57 

modification, 222 

modification adjustment 

SAINT, 269 

SPAM, 263 

monitoring segment, 476 

monitoring tree element, 

477 

MTE, seemonitoring tree 

element 

N 

Note Assistant, 287 

O 

operation mode, 110 


Index ADM100 

switch, 114 

output request, 358 

P 

package, 219 

performance trace, 536 

PlainHtmlFile, 129 

PlainHtmlHttp, 129 

profile parameter 

DIR_LOGGING, 474 

DIR_TRANS, 233 

login/disable_multi_gui_login, 

433 

login/failed_user_auto_unlock=0, 

433 

login/fails_to_session_end, 

433 

login/fails_to_user_lock, 

433 

login/min_password_digits, 

432 

login/min_password_letters, 

432 

login/min_password_lng, 

432 

login/min_password_specials, 

432 

login/multi_login_users, 

433 

login/no_automatic_user_sapstar, 

588 

login/password_expiration_time, 

432 

login/password_max_new_valid, 

432 

login/password_max_reset_valid, 

432 

rdisp/btctime, 314 

rdisp/max_alt_modes, 

96 

rdisp/max_wprun_time, 

300 

rdisp/myname, 96 

rdisp/TRACE, 56 

rdisp/wp_no_btc, 96, 

314 

rdisp/wp_no_dia, 96 

rdisp/wp_no_enq, 96 

rdisp/wp_no_Fro_max, 

364 

rdisp/wp_no_spo, 96 

rdisp/wp_no_vb, 96 

rslg/central/file, 538 

rslg/local/file, 538 

rspo/local_print/server, 

381 

rspo/store_location, 

359 

rstr/buffer_size_kB, 

543 

rstr/filename, 543 

rstr/max_files, 543 

rstr/max_filesize_MB, 

543 

Profile Parameter 

rdisp/btcname, 324 

Q 

qRFC, 453 

R 

recovery, 154 

remote printing, 362 

REORGJOBS, see standard 

jobs 

repository, 219 

role maintenance, 418 

S 

SAP Archive Information 

System, 204 

SAP ArchiveLink, 178 

SAP Library, 127 

SAP Service Marketplace, 

136 

SAP Solution Manager, 520 


ADM100 Index 

sapdoccd.ini, 133 

sapevt, 325 

saplpd, 363–364 

SAPOSCOL, 43 

SAProuter, 597 

sapxpg, 337 

SNC, 591 

spool request, 358 

sRFC, 453 

SSF, 594 

SSL, 593 

standard jobs, 315 

start profile, 92 

system log, 535 

system parameter, see 

profile parameter 

system trace, 536 

T 

TemSe, 359 

time table, 112 

tp, 234 

transaction code 

AL08, 27 

DB12, 157 

DB13, 157 

DB13C, 158 

DB15, 186, 196 

FILE, 187 

PFCG, 418 

PFUD, 424 

RSPFPAR, 93 

RZ03, 114 

RZ04, 111, 334 

RZ10, 100 

RZ11, 93 

RZ20, 478 

RZ21, 489, 509 

SA38, 317, 319 

SAINT, 265 

SARA, 187 

SCC4, 220 

SE09, 226 

SM02, 27 

SM04, 27 

SM12, 27 

SM13, 28 

SM21, 27, 535, 537 

SM36, 304 

SM36WIZ, 304 

SM37, 305 

SM49, 344 

SM50, 27 

SM51, 27 

SM59, 457 

SM61, 335 

SM62, 325 

SM63, 112 

SM64, 325 

SM66, 27 

SM69, 339 

SMLG, 17 

SNOTE, 288 

SP01, 391 

SPAD, 365, 557, 572, 578 

SPAM, 256 

SR13, 131 

ST01, 436, 536, 540 

ST05, 536, 543 

ST22, 536 

STMS, 233, 236 

SU01, 408 

SU3, 373 

SU53, 435 

SUIM, 434 

SWW_ARCHIV, 210, 

212 

transport directory, 232 

Transport Organizer, 226 

tRFC, 453 

U 

update, 28 

user master comparison, 

423 

W 

work process multiplexing, 

10 

workbench request, 226 


Index ADM100 


Feedback 

SAP AG has made every effort in the preparation of this course to 

ensure the accuracy and completeness of the materials. If you have any 

corrections or suggestions for improvement, please record them in the 

appropriateplaceinthecourseevaluation.

SAP Basis

Create successful ePaper yourself

Delete template?

Save as template?