SAP-R/3 SYSTEM ADMINISTRATION

RELEASE 4.6C
SL. NO. CONTENTS PAGE NO.

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29.

Introduction SAP Industry Solutions SAP-R/3 Architecture SAP R/3 System Landscape SAP R/3 Basis Software Roles of an R/3 System Administrator R/3 System Guidelines SAP Terminologies Client Administration User Administration Starting & Stopping the R/3 System Security Administration Profile Generator SAP-R/3 Online Enhancement Activities Output Management Basic SAP-R/3 System Administration

INTRODUCTION
SAP -> Systems, Applications, and Products in Data Processing SAP is an ERP (Enterprise Resource Planning) package. SAP is designed and developed by SAP AG, Walldorf, German in 1972. It is a standard package, and can be configured in multiple areas and adapted to the specific needs of a company. SAP products are considered excellent but not perfect. The main advantage of using SAP as your company ERP system is that SAP has a very high level of integration among its individual applications, which guarantee consistency of data throughout the system and the company itself. Generally, SAP can be divided into two functionalities:

SAP Technical ABAP (Advanced Business Application Programming) Language Basis Administration SAP Functional Financial FI (Financial Accounting) CO (Controlling) EC (Enterprise Controlling) IM (Capital Investment Management) TR (Treasury) Human Resources PA (Personnel Administration) PD (Personnel Development) Logistics LO (General Logistics) MM (Materials Management) PM (Plant Maintenance) PP (Production Planning) PS (Project System) QM (Quality Management) SD (Sales and Distribution)

SAP INDUSTRY SOLUTIONS

SAP has separate specialize teams for different industries called Industry Business Units (IBUs). These business units are responsible for gathering the market and industry knowledge and developing specific solutions and applications for each of the industry sectors. Generally SAP is providing 18 different industry solutions: SAP High Tech & Electronics SAP Engineering & Construction SAP Oil & Gas SAP Utilities SAP Service Provider SAP Mill Products SAP Consumer Products SAP Insurance SAP Public Sector SAP Telecommunication
Page 2 of 42

SAP-R/3 SYSTEM ADMINISTRATION

SAP Health Care SAP Automotive SAP Media SAP Aeros pace & Defense

SAP Chemicals SAP Pharmaceuticals SAP Retail SAP Banking

While working on these IBUs, SAP was aware that some functional modules are common to different industry sectors and cant be grouped under a specific industry solution. So SAP created 3 Strategic Business Units (SBUs). SAP Supply Chain Management (SCM) SAP Advanced Planner & Optimizer (APO) SAP Business-to-Business (B2B) SAP Product Data Management (PDM) SAP Customer Relationship Management (CRM) SAP Sales SAP Marketing SAP Service SAP Business Intelligence (BI) SAP Business Information Warehouse (BIW) SAP Knowledge Warehouse (KW)

SAP R/3 ARCHITECTURE

SAP R/3 (Real Time 3) has a 3-Tier architecture: The Presentation Layer (Upper Layer) The Application Layer (Middleware Layer) The Database Layer (Lower Layer)
SAP R/3
Financials, Human Resources, Logistics, R/3 Applications Functional Layer PRESENTATION LAYER

ABAP Workbench, CCMS, Administration, Interfaces, Authorizations, Jobs, Batch Input, Data Dictionary, Basis System Middleware Cross Applications APPLICATION LAYER

Operating System Database - Network

DATABASE LAYER

SAP-R/3 SYSTEM ADMINISTRATION

Page 3 of 42

Those SAP R/3 software components that specialize in interacting with end users form the presentation layer. These components reside in Presentation Servers, which are systems capable of providing a graphical interface.

SAP-R/3 SYSTEM ADMINISTRATION

Page 4 of 42

Those SAP R/3 software components that specialize in processing business applications form the application layer. These components reside in Application Servers, which are specialized systems having multiple CPUs and vast amount of RAM. Those SAP R/3 software components that specialize in the management, storage and retrieval of data form the database layer. These components reside in Database Servers, which is a specialized system with fast and large hard drives. Thus, it can be concluded that, the lower layer (Database Layer) is made of the operating system, physical database, and the network. The middleware layer (Application Layer), which is above it, interfaces with the lower one and integrates the SAP R/3 applications on top of it. This middle layer is known as the Basis System or the Kernel, and includes components such as the ABAP development workbench, the system administration tools, batch job handling, authorization and security management, and all cross-application modules. The upper layer (Presentation Layer) is the functional layer, which contains the different business applications, such as Financials, Human Resources and Logistics. The integration of all applications relies on the basis system.

SAP R/3 SYSTEM LANDSCAPE

In a standard SAP project system, the environment is divided into: Development System Quality Assurance System Production System

DEV

QAS

PRD

(DEVELOPMENT SYSTEM)

(QUALITY ASSURANCE SYSTEM)

(PRODUCTION SYSTEM)

The development system is where most of the implementation work takes place. The quality assurance system is where all the final testing is conducted before moving the transports to the production environment. The production system is where all the daily business activities occur.

SAP R/3 BASIS SOFTWARE

The R/3 basis software is a set of programs and tools, which interfaces with the computer operating system, the underlying database, the communication protocols, and the presentation interfaces. This software enables the R/3 applications (Financials, Human Resources, Logistics, etc) to have the same functionality and work exactly the same way no matter what operating system or database the system is installed on. The R/3 basis software is an independent layer that guarantees the integration of all application modules. The R/3 basis system is otherwise known as R/3 common kernel or R/3 Middleware.

SAP-R/3 SYSTEM ADMINISTRATION

Page 5 of 42

ROLES OF AN R/3 SYSTEM ADMINISTRATOR

1. 2. User Administrator Set up and maintain user accounts Security Administrator Create and maintain SAP security profiles Monitor and manage security access and violations System Administrator Maintain the systems health Monitor system performance and logs Transport Administrator Transport changes between systems Manage change requests Batch Scheduler Create and manage the scheduling of batch jobs Backup Operator Schedule, run, and monitor backup jobs of the SAP database and any required operating system level files Disaster Recovery Technical Manager Create, test, and execute the SAP disaster recovery plan Programmer Apply SAPNet R/3 note fixes to programs Data Dictionary (DDIC) Manager Change the Data Dictionary, when required Database Administrator (DBA) Manage Database related jobs

3.

4.

5. 6.

7. 8. 9. 10.

R/3 SYSTEM GUIDELINES When working on an R/3 System:

Protect the system Do not be afraid to ask for help Network with other customers and consultants Keep it short and simple (KISS) Keep proper documentation Use checklists Use the appropriate tool for the job Perform preventive maintenance Do not change what you do not have to Do not make changes to the system during critical periods Do not allow direct database access Keep all non-SAP activity off the SAP servers Minimize single points of failure
Page 6 of 42

SAP-R/3 SYSTEM ADMINISTRATION

SAP TERMINOLOGIES
# Transaction: A SAP Transaction is a sequence of related steps. These logically related steps are known as Dialog Steps. These dialog steps are screens in which data is introduced causing the generation of other events. Thus, a set of dialog steps makes up a transaction. There is a special transaction monitor, known as the SAP Dispatcher, which takes care of handling the sequence of those steps. The final task of a transaction is to modify the information, which ultimately goes into the database. The database is not updated until a transaction has finished. A transaction usually contains two phases: Interactive Phase Update Phase The interactive phase is responsible for preparing the database records that can update the database. The update phase processes the previously prepared records and updates the database. All the transactions in the R/3 system have an associated Transaction Code. The available transaction codes are held in the table TSTC. # Dialog Step: A dialog step is a SAP R/3 screen, which is represented by a Dynpro, or Dynamic Program. A dynpro consists of a screen and all the associated Processing Logic. The processing logic means that the dynpro controls what has to be done before the screen is displayed (Process Before Output (PBO)) and what has to be done after the user finishes entering information (Process After Input (PAI)). # Client: A Client is defined as a legally and organizationally independent unit within the R/3 system, for example, a company group, a business unit, or a corporation. SAP comes with three standard clients: 000, 001, and 066. Client 000 contains a simple organizational structure of a test company and includes parameters for all applications, standard settings, configurations for the control of standard transactions and examples to be used in many different profiles of the business applications. Client 000 of the R/3 system contains all the client-independent settings. Client 001 is a copy of the client 000, including the test company. If this 001 client is configured or customized, its settings are client-dependent. It does not behave like client 000. It is reserved for the activities of preparing a system for the production environment. SAP customers usually use this client as a source for copying other new clients. Client 066 is reserved for SAP access to its customers systems to perform the Early Watch Service. # Dispatcher: The SAP dispatcher is the control program, which manages the resources of the R/3 applications. The dispatcher manages the information exchange between the presentation services and the work processes, enabling users to share the different work processes available. The main tasks of the dispatcher are: Balanced assignment of the transaction load to the work processes. Buffer management in main memory. Connection with the presentation level. Organization of the communication processes.

SAP-R/3 SYSTEM ADMINISTRATION

Page 7 of 42

SAPGUI

SAPGUI

SAPGUI

Dispatcher

Work Processes

Work Processes

Work Processes

The logical flow of execution of a user request follows: 1. Users enter data through SAPGUI, which is then converted to a SAP format and sent to the dispatcher using a special optimized protocol called DIAG. 2. Initially, the dispatcher keeps the requests in queues, where the dispatcher later processes them one by one. 3. The dispatcher allocates the new requests using the free work processes. The real execution takes place inside the work processes themselves. 4. At the end of execution, the result of the work process task goes back to the SAPGUI through the dispatcher. The dispatcher has a special advanced program-to-program communication (APPC) server built into it, which communicates and responds to requests submitted by the work processes. On each application server there is one dispatcher but multiple work processes. # Work Process: A Work Process is a program in charge of executing the R/3 application tasks. Thus, a group of parallel work processes makes up the R/3 runtime system. A work process consists of: Task Handler Dialog Interpreter (Dynpro Processor) ABAP Processor Database Interface

SAP-R/3 SYSTEM ADMINISTRATION

Work Processes

Database

Page 8 of 42

Task Handler

ABAP Processor

Dialog Interpreter

Database Interface

WORK PROCESS

(WORK PROCESS ARCHITECTURE)

The work processes execute dialog steps for the end users. The activities within a work process are coordinated by the Task Handler. It manages the loading and unloading of the user session context at the beginning and end of each dialog step. It also communicates with the dispatcher and activates the dialog interpreter or the ABAP processor as required to perform its tasks. The Dialog Interpreter (Dialog Processor) is in charge of interpreting and executing the logic of R/3 screens, while the ABAP Processor is in charge of executing the ABAP programs. The Database Interface allows the work processes to establish direct links with the database. Work Processes make use of two special areas: Paging Area Roll Area The Paging Area holds application program data such as internal tables or report listings. The Roll Area holds the user context data entered in previous dialog steps and other control & user information such as authorizations. If there is enough main memory available, then these areas are held in the main memory of application servers. If not, then they are Paged Out or Rolled Out to physical disk files. The R/3 runtime system includes seven types of work processes: Dialog Background Update Enqueue Spool Message Service Gateway 1. Dialog Work Process: The dialog work processes are in charge of the interactive tasks of the R/3 system. A dialog work process performs the dialog steps corresponding to the interactive user sessions. The user inputs from the presentation services of the R/3 system are held by the dispatcher in a request queue. These jobs are assigned to free work processes one by one. The dialog work processes execute just one single dialog step at a time and become immediately free for the next dialog step (user request), which is assigned by the dispatcher. This means that the dialog work processes constantly switches between different user sessions. If works exactly the same as multi-user operating systems. Depending on the type of business transactions the users are working on, a single dialog work process can support from 5 to more than 10 simultaneous users.

SAP-R/3 SYSTEM ADMINISTRATION

Page 9 of 42

2. Background Work Process: The background work processes are in charge of executing ABAP programs submitted for background execution. The ABAP programs submitted for background processing are executed in the planned time by the background work processes. The sequence of program execution is scheduled with batch jobs. Background processing is very useful for submitting programs requiring long processing times, since interactive execution would exceed the allowed processing time and thus abort with a TIME_OUT error. 3. Spool Work Process: The spool work process is in charge of formatting the data for printing and passing it to the host spool system. The spool requests, indicating the printer and the printing format of the spool request, are generated during dialog or background processing and are held on the spool database. The data itself is kept in a special area, known as TemSe (Temporary Sequential) objects. It can be either on the database or on a file. The spool requests are executed by the spool work process. Once the spool work process has edited the data for printing, it sends a print request to the operating system host spool and printing process takes place. 4. Enqueue Work Process: The enqueue work process, also known as the lock work process, is in charge of the lock management system. It allows multiple application servers to synchronize their access to the database and maintain the data consistency. The locks (enqueues) are managed by the enqueue work process using a lock table, which resides in the main memory. When the processes receive a locking request, the enqueue work process verifies whether the requested lock object interferes with other existing entries in the lock table. The locking mechanism uses lock objects. The lock objects are special types of objects defined in the ABAP dictionary. It can be one of the following three: Shared (Type S) Exclusive (Type E) Exclusive but not cumulative (Type X) With the shared mode, several users can access the same data at the same time in display mode. As soon as any user processes the data, the remaining users do not have further access to them. The exclusive locks are used to avoid parallel modification of the data, which means that exclusively locked data can be displayed or modified by only one user. Locks of type exclusive but not cumulative can only be called once. So lock request will be rejected if an exclusive lock already exists. When the lock objects are defined in the dictionary, there are two ABAP function modules automatically generated for them one to lock the object (Enqueue) and another function to unlock it (Dequeue). These functions are called at the beginning and at the end of a transaction, respectively. 5. Update Work Process: The update work process is in charge of executing database changes when requested by the dialog or background work processes. The update is an asynchronous process, which means that the update requests are processed at the moment and in the order they arrive at the work process. If for any reason the update transaction cannot be completely accomplished, the user will get a system message and an express mail. After that the system rolls the update transaction back. An update request can contain a Primary Update Component (V1) and several Secondary Update Components (V2). The time-critical processes are held inside the V1, and the less critical within the V2.
SAP-R/3 SYSTEM ADMINISTRATION Page 10 of 42

Critical updates of the database are the most usual, including posting financial documents, receiving sales orders, launching a production order, and so on. Secondary updates are lower priority changes such as calculating totals or preparing statistical information. 6. Message Server: The message server is a service used by the different application servers to exchange data and internal messages. This server does not have the structure of the typical work processes. However, it acts like a service. 7. Gateway Server: The gateway service allows the communication between R/3 and external applications. This service is a CPIC (Common Programming Interface Communications) handler, which implements the CPIC protocol for communication. This is commonly known as a SAP gateway. The function of the SAP gateway is to exchange larger amounts of data (application data) between application servers, in contrast to the message server, which only exchanges brief internal and control messages. # SAP Instance: An instance is an administrative entity that groups together R/3 components, which offer one or several services. These offered services are started or stopped together. All instance components are configured using a common instance profile. A centralized SAP R/3 system is made of a unique instance. A central system can be further configured to a distributed system, creating additional instances offering additional services. SAP distinguishes between central instances and dialog instances. Every SAP system has just one central instance, which contains all basic services (such as the dialog, background, spool, update, enqueue, gateway and message server) right from installation. But dialog instances only contain a set of basic services such as dialog and background work processes from the time of installation. # SAP System SID: The SAP system ID is a three character alphanumeric name, which remains the same for all the instances within that SAP system. Do not use any of the following names as the SAP system names: ADD, ALL, AND, ANY, ASC, COM, DBA, END, EPS, FOR, GID, INT, KEY, LOG, MON, NOT, OFF, RAW, ROW, SAP, SET, SGA, SH0, SID, UID, VAR.

SAP-R/3 SYSTEM ADMINISTRATION

Page 11 of 42

CLIENT ADMINISTRATION
T. CODE TASK

SCC4 SCCL SCC9 SCC5 SCC1 SCC8 SCC7 SCC3

Display attributes of an existing client. Change attributes of an existing client. Create a new client. Local client copy. Remote client copy. Delete a client. Copy as per transport request. Transporting clients between two SAP systems (Client Export). Post process import. Display client copy log.

# Local Client Copy: Copying a client in the same system requires the following steps: 1. Define a new client (T. Code: SCC4). 2. Log on to the new client with user: SAP* and password: PASS. 3. Select a copy profile and a source client and then launch the client copy operation (T. Code: SCCL). 4. Check the client copy log (T. Code: SCC3). # Remote Client Copy: Copying a client to a different system requires the following steps: 1. In the target system, setup the RFC (Remote Function Call) destination for the source system using the T. Code: SM59. 2. Define a new client in the target system. (T. Code: SCC4). 3. Log on to the new client in the target with user: SAP* and password: PASS. 4. Select a copy profile and a source client RFC destination and then launch the client copy operation (T. Code: SCC9). 5. Check the client copy log (T. Code: SCC3). # Delete Client: Deleting a client requires the following steps: 1. Log on to the client to be deleted with user: SAP* and ensure that no users are logged on to this client. 2. Launch the client delete operation (T. Code: SCC5). (The entry from the client table: T000 can also be deleted using this function). 3. Check the client delete log (T. Code: SCC3). Clients can also be deleted using the R3trans program, which can be the fastest way. Suppose a client 111 has to be deleted from the SAP system MAT. Using R3trans to delete a client requires the following steps: 1. Log on at the operating system level as user MATADM. 2. Go to the directory: D:\usr\sap\trans\bin 3. Using a standard text editor create a control file: delete_client.ctl, with the following text:
clientremove

SAP-R/3 SYSTEM ADMINISTRATION

Page 12 of 42

client=111 select *

Save the file. 4. Execute the command:

R3trans w delete_client.log u 1 delete_client.ctl

After deleting a client, the space is not automatically freed from the database, although a new client being created and then copied can reuse these free areas. To immediately restore the free space after a client delete, one should perform a database reorganization. # Client Export: The client export process requires the following steps: 1. Suppose, you want to export a client 800 from the source system S11 (Development System) to the target system T11 (Production System). The target client can be 800 or any other client. Say, 800 in this case. 2. Log on to the target system T11 in any existing client and define a new client. (T. Code: SCC4). 3. Log on in the source system S11 in the client 800 and execute the T. Code: SCC8. Select a copy profile and execute the export process. 4. When the export is finished, the following files are created in the transport directory: Data files: \usr\sap\trans\data\ROnnnnnn.S11 \usr\sap\trans\data\RTnnnnnn.S11 \usr\sap\trans\data\RXnnnnnn.S11 Control files: \usr\sap\trans\data\KOnnnnnn.S11 (Client-independent objects) \usr\sap\trans\data\KTnnnnnn.S11 (Client-dependent tables) \usr\sap\trans\data\KXnnnnnn.S11 (Client-dependent long texts) (Where <nnnnnn> is a system generated transport number. 5. Now to import these transport files manually using the tp transport control program, log on at the operating system level as user T11ADM in the target system T11. 6. From the command prompt execute the following commands:
tp pf=\\<T11_host>\sapmnt\trans\bin\TP_<domain>.PFL addtobuffer S11KOnnnnnn T11 tp pf=\\<T11_host>\sapmnt\trans\bin\TP_<domain>.PFL import S11KOnnnnnn T11 client800 tp pf=\\<T11_host>\sapmnt\trans\bin\TP_<domain>.PFL addtobuffer S11KTnnnnnn T11 tp pf=\\<T11_host>\sapmnt\trans\bin\TP_<domain>.PFL import S11KTnnnnnn T11 client800

7. After import process is successful, log on to the client 800 in the target system T11 with user: SAP* and password: PASS. 8. Execute the T. Code: SCC7. In this import post processing process, the text files are automatically imported. 9. Check the client copy log (T. Code: SCC3).

SAP-R/3 SYSTEM ADMINISTRATION

Page 13 of 42

SAP-R/3 SYSTEM ADMINISTRATION

Page 14 of 42

STARTING & STOPPING THE R/3 SYSTEM

# Start the R/3 System: Follow the following steps to start the R/3 System in a productive environment: 1. Start the operating system (if required). 2. Check the operating system logs to verify a good start. 3. Start the database (Use SAPDBA). This step is optional because starting the R/3 System also starts the database. However, manually starting the database allows you to review the database log before starting the R/3 System. 4. Check the database logs to verify a good start. 5. Start R/3 on the central instance using the SAP Management Console. 6. Check the R/3 System log (T. Code: SM21) to verify a good start. Problems at this point may require you to cycle (stop & start) the system. 7. Start R/3 on the application instances. 8. Check the R/3 System log (T. Code: SM21). # Stop the R/3 System: Follow the following steps to stop the R/3 System in a productive environment: 1. Create a system message announcing the planned shutdown (T. Code: SM02). 2. Check that there are no active users on the system (T. Code: SM04 and T. Code: AL08). 3. Check that there are no active background jobs running (T. Code: SM37). 4. Check for active processes (T. Code: SM50 & SM51). 5. Check for active external interfaces. 6. If there are application servers in the system, stop the instance on the application server(s). 7. Stop the instance on the database server, using the SAP Management Console. 8. If needed, stop the database. The database must be stopped separately. Unlike the start process, stopping the system does not also stop the database. Use SAPDBA to stop the database. 9. If needed, stop the operating system.

SAP-R/3 SYSTEM ADMINISTRATION

Page 15 of 42

SECURITY ADMINISTRATION
T. CODE TASK

PFCG SECR SM20 SM19 SM18 SM01

Profile Generator. Audit Information System. Security Audit Log: Local Analysis. Security Audit: Administer Audit Profile. Delete Old Audit Logs. Transaction Codes: Lock/Unlock

Responsibilities of the R/3 system administrator for security: Protecting the R/3 system Preparing for a computer security audit
Access Security Operational Security Data Security

The Three major layers of security are: 1. Access Security Physical Security Network Security Application Security Profile Generator (T. Code: PFCG). Audit Information System (T. Code: SECR). Security Audit Log Analysis (T. Code: SM20). Set Security Audit Log Parameters (T. Code: SM19). Delete Old Audit Logs (T. Code: SM18). 2. Operational Security Segregation of duties. Preventing sharing of user Ids. Password standards. Log off when away from the computer. 3. Data Security Protection from hardware failure, mirrored drives, RAID, fail-over. Backup and recovery procedures. Protecting the production system from unauthorized changes. Locking dangerous transactions.

SAP-R/3 SYSTEM ADMINISTRATION

Page 16 of 42

# Audit Information System (AIS) (T. Code: SECR): The Audit Information System (AIS) is designed for two types of audits, namely: The System Audit The Business Audit AIS is requested to be run by internal or external auditors. It puts into one place many of the R/3 security tools. The center of the AIS is the Audit Report Tree. AIS uses standard R/3 reports and transactions to conduct the review. AIS also provides an interface to export data to an external auditing system that analyzes financial statements. Auditors examine the results of automated and manual financial and system procedures to ensure that there is a checks-and-balances infrastructure to prevent fraud, security lapses, etc. AIS enables auditors to test transactions and run reports during the inspection. # Security Audit Log Analysis (T. Code: SM20): The security Audit Log records the securityrelated activities of users in the system. These activities include: Dialog logon attempts Report and transaction starts RFC/CPIC logons Locked transactions or users Changed or deleted: Authorizations Authorization profiles User master records Changes to the audit configuration The Security Audit Logs are created each day. The old logs are neither deleted nor overwritten. For this reason, the log files can become numerous and large. It is recommended that the logs be periodically archived. A Security Audit Analysis report can be generated from the audit logs. The procedure assumes that the audit has been running for some time and the audit logs have already been created. A local server, a remote server, or all servers in an R/3 system can be analyzed with these audit analysis reports. To start a security audit, one of the following two methods can be adopted: Set the profile parameter rsau/enable to 1. Dynamically start it using T. Code: SM19. The size of the security audit logs can be defined by one of the following methods: Set the maximum space for the security audit log file in the profile parameter rsau/max_diskspace/local. When the limit is reached, the logging will end. Define the size of an individual security log file in the profile parameter rsau/max_diskspace/per_file, and the maximum size per file is 2 GB. That means, system produces several log files each day and these files can be archived periodically into any archiving media, like CDs. # Setting Security Audit Log Parameters (T. Code: SM19): The security audit log parameters are the criteria used to write the types of audit messages into the audit log file. The parameters are grouped into audit profiles that can be activated at the next system startup or can be activated dynamically.
SAP-R/3 SYSTEM ADMINISTRATION Page 17 of 42

Security audit profiles need to be first created before audit logs can be written. These profiles limit the amount and type of data written into the security audit files, which makes the subsequent security reports more meaningful to the administrator. If the audit configuration is permanently stored at the database level, then all application servers use the identical criteria to save events in the audit log. The settings take effect at the next application server start. If the audit configuration is configured dynamically, then it is set to individual application servers and distributed to the entire system. The new criteria will remain in effect until the server is brought down. The profile parameter rsau/selection_slots defines the number of selection criteria or filters that can be set as security audit parameters. A maximum of 5 sets of filters can be defined. The default value is 2. # Prevent Multiple User Logins: This process prevents users from logging onto the system multiple times, that means; this process prevents several users from sharing a single user ID. If several people share a user ID, then the user who created a problem remains unknown. Also this situation is an audit security issue. T. Code: RZ10 along with the following two profile parameters are used to prevent such a situation: login/disable_multi_gui_login: Disable several users sharing a single user ID. login/multi_login_users: Allow specific users to logon multiple times by entering their user Ids separated by commas and no spaces. # Setting Password Standards: T. Code: RZ10 along with the following three profile parameters are used to set password standards: login/min_password_lng: Set the minimum password length. A longer password is more difficult to break or guess. login/password_expiration_time: Set the password expiration time. This time period is the limit before users must change their password. login/fails_to_user_lock: This parameter locks out users who, after a specified number of times, try to logon with an incorrect password. There are certain easy-to-guess or well-known passwords. These passwords are prevented from being used by loading them into a table USR40. When a user attempts to save a new password, the system checks the table USR40 and prevents the use of the restricted password. Changes are made to the table USR40 using the T. Code: SM31. # Preventing Changes in the Production System: The production system should be set to Not Modifiable. Locks should be set on the production system so that configuration changes (clientindependent and client-dependent) cant be made directly into the system. Adapt the following procedure to implement any configuration changes in the system. Changes should be: Made in the development system. Tested in the development system. Transported from the development system to the test system. Tested in the test system. Transported from the test system to the production system.
SAP-R/3 SYSTEM ADMINISTRATION Page 18 of 42

The above procedure ensures that changes are properly tested and applied to the systems in the pipeline. (A pipeline is the environment where configuration changes are moved from the development system to the quality assurance system, and finally to the production system.) The main goal of the above procedure is to protect the production system from changes, without the changes being properly tested and to preserve the integrity of the pipeline. The following two transactions are used to set the production system to Not Modifiable: SE03 (Transport Organizer Tools) SCC4 (Client Maintenance) # Verifying that Dangerous Transactions are locked: There are 48,000 English transaction codes in the R/3 system. Among these, there are some transaction codes, which are dangerous in nature. Dangerous Transactions could: Damage or corrupt the system. Present a security risk. Adversely impact performance. Access to dangerous transactions is more critical in the production system than the development or test systems. The following two transaction codes deals with the locking of transactions: SM01 (Transaction Codes: Lock/Unlock) SECR (Audit Info System: Display Blocked/Unblocked Transactions)

PROFILE GENERATOR (PG)

The Profile Generator is a tool used to simplify the creation and maintenance of SAP security. PROFILES AUTHORIZATIONS ROLES GROUPS ACTIVITY GROUPS

SAP-R/3 SYSTEM ADMINISTRATION

Page 19 of 42

SAP-R/3 ONLINE ENHANCEMENT ACTIVITIES

T. CODE TASK

SM51 -> Release Information Menu: System -> Status SPAM OSS1

Display SAP-R/3 kernel patch level. Support package details. SPAM (Support Package Manager) update. Log on to SAP Net- R/3.

# Basic Activities: The following types of activities are performed under SAP-R/3 Online Enhancement: Update SPAM (Support Package Manager) Download R/3 Support Packages (Hot Packages). It includes various patches for: R/3 System Database SAP GUI Download Legal Change Packages LCP (R/3 HR Support Packages) Upgrade R/3 system kernel. Register Developers / Objects (Get Access Key) through SSCR (SAP Software Change Registration) Search for SAP Notes. # Connect To SAP: The options available to get connected with SAP are: SAP Net R/3 Front-end (Online Service System OSS) SAP Net Web Front-end (SAP Net Web)
SAP Net-R/3 SAP Net-Web

Log on through OSS1. Supports Online Correction Support (OCS). Downloads only small-sized patches. Registers Developers/Objects. Search for SAP Notes is possible. Supports Customer Messages function. Opens a service connection to perform Early Watch session.

Log on through www.sapnet.sap.com. Downloads both small and large-sized patches. No such facility.

# SPAM / Support Package: A Support Package is a collection of corrections that address serious errors in the ABAP repository. These corrections affect the Basis and Functional areas. There are defined rules about what kind of fixes should be (and are) included in a Support Package. Some rules are technical while other rules are policy. The basic purpose of a Support Package is to fix problems before they become problems. Before any Support Package is applied to the R/3 system, make sure that you have the latest version of SPAM (Support Package Manager); since some Support Package changes require the latest SPAM program to properly update the R/3 system.

SAP-R/3 SYSTEM ADMINISTRATION

Page 20 of 42

# SPAM Update / Support Package Application through SAP Net R/3 Front-end: The steps are: 1. Determine the current SPAM Update and Support Package level of your system. (T. Code: SPAM or, Menu: System -> Status) 2. Connect to SAP through SAP Net R/3 Front-end and a valid logon & password. (T. Code: OSS1) 3. Get and review the notes for the SPAM / Support Packages that are currently available in SAP Net R/3. 4. Determine if the SPAM / Support Package should be or needs to be applied. 5. Request the SPAM / Support Package from SAP Net R/3. 6. Once requested and the patch request has been generated, download the SPAM / Support Package. This option is size-limited, which means large files cannot be downloaded via SAP Net R/3. To download, follow the following steps: Logon to Client: 000, under any user that has the SAP*-equivalent authorization (not SAP*). Execute the T. Code: SPAM. Select the new SPAM / Support Package that has been obtained through the request from SAP Net R/3. Choose download to get the *.ATT or *.PAT files to \usr\sap\trans\EPS\in subdirectory. 7. Upload the SPAM update / Support Package from the Operating System into R/3 using the T. Code: SPAM and then Menu: Patch -> Upload. 8. If a SPAM update is available, apply it before any Support Packages, since some Support Package changes require the new SPAM program to properly update the system. To update SPAM, follow the following steps: Shut down all application servers and check that no users are logged on and no jobs are running on the R/3 system. Logon to Client: 000, under any user that has the SAP*-equivalent authorization (not SAP*). Execute the T. Code: SPAM and then Menu: Patch -> Import SPAM update. After applying the SPAM update, restart Transaction: SPAM to use the latest version. 9. To apply the Support Package, follow the following steps: Shut down all application servers and check that no users are logged on and no jobs are running on the R/3 system. Logon to Client: 000, under any user that has the SAP*-equivalent authorization (not SAP*). Execute the T. Code: SPAM and then Menu: Patch -> Upload. Define a patch queue. Apply the patch queue. Check the patch log. (Review the return codes; values greater than 4 indicate a failure.) Perform a regression test on the applied Support Package. When the regression test is successful, confirm the patch. The next Support Package cannot be applied until the previous one is confirmed. (If several patches are going in as a group, the option is to confirm them after applying and then perform the regression test.)
SAP-R/3 SYSTEM ADMINISTRATION Page 21 of 42

 Verify the patch application.

SAP-R/3 SYSTEM ADMINISTRATION

Page 22 of 42

# SPAM Update / Support Package Application through SAP Net Web Front-end: The steps are: 1. Determine the current SPAM Update and Support Package level of your system. (T. Code: SPAM or, Menu: System -> Status) 2. Connect to SAP through SAP Net Web Front-end (www.sapnet.sap.com) and a valid logon & password. 3. Get and review the notes for the SPAM / Support Packages that are currently available. 4. Determine if the SPAM / Support Package should be or needs to be applied. 5. Choose the appropriate SPAM / Support Package, download the file (*.CAR), and save it to disk. 6. Create an unpacking directory and unpack the *.CAR files by using the command: car xvf <file-name> (car.exe can be found in \usr\sap\<sid>\sys\exe\run) Transfer the resulting *.ATT or *.PAT files to \usr\sap\trans\EPS\in subdirectory. 7. Upload the SPAM update / Support Package from the Operating System into R/3 using the T. Code: SPAM and then Menu: Patch -> Upload. 8. If a SPAM update is available, apply it before any Support Packages, since some Support Package changes require the new SPAM program to properly update the system. To update SPAM, follow the following steps: Shut down all application servers and check that no users are logged on and no jobs are running on the R/3 system. Logon to Client: 000, under any user that has the SAP*-equivalent authorization (not SAP*). Execute the T. Code: SPAM and then Menu: Patch -> Import SPAM update. After applying the SPAM update, restart Transaction: SPAM to use the latest version. 9. To apply the Support Package, follow the following steps: Shut down all application servers and check that no users are logged on and no jobs are running on the R/3 system. Logon to Client: 000, under any user that has the SAP*-equivalent authorization (not SAP*). Execute the T. Code: SPAM and then Menu: Patch -> Upload. Define a patch queue. Apply the patch queue. Check the patch log. (Review the return codes; values greater than 4 indicate a failure.) Perform a regression test on the applied Support Package. When the regression test is successful, confirm the patch. The next Support Package cannot be applied until the previous one is confirmed. (If several patches are going in as a group, the option is to confirm them after applying and then perform the regression test.) Verify the patch application.

SAP-R/3 SYSTEM ADMINISTRATION

Page 23 of 42

# Kernel Upgrade: The kernel upgrade process is the replacing of operating system level files (the kernel files) with updated versions of these files. The kernel is backward compatible, which means that a user could be running a Release 4.6C with a 4.6D kernel. The kernel upgrade steps are: 1. Determine the current R/3 Kernel Release and Kernel Patch Level of your system (T. Code: SM51 -> Release Information). 2. Connect to SAPSERV using, either Command Prompt, Windows FTP GUI Client, or Internet Browser. (SAPSERV is a series of servers that contain updates to the R/3 System Kernel). 3. Get and review the file dw.info, which contains the patch level of the kernel that is currently available in SAPSERV. 4. Determine if the Kernel Patch should be or needs to be applied. 5. Download the kernel files: dw1_nnn.car dw2_nnn.car (where nnn is the patch level) 6. Create an unpacking directory and unpack the *.CAR files by using the command: car xvf <file-name> (car.exe can be found in \usr\sap\<sid>\sys\exe\run) 7. Backup the system at the database and operating system levels. 8. Stop the R/3 system. 9. Backup the kernel directory: \usr\sap\<sid>\sys\exe\run, i.e. copy the current kernel files to a backup directory, to be prepared in the event that you need to restore back to the old version if a problem occurs with the new version. 10. Copy the new kernel files into the kernel directory. This replaces the old programs with the new program. 11. Restart the server and start the R/3 system. # Early Watch: Early Watch analysis is done in five areas: R/3 Configuration R/3 Application Server Workload Database Early Watch applies only to the production system, not to the development system. Early Watchs primary function is to improve the online performance of the production system. During an Early Watch session, performance experts log on to the system into Client-066.

SAP-R/3 SYSTEM ADMINISTRATION

Page 24 of 42

# SAP Spool System: Handling print requests in a SAP system basically involves the following two types of requests: Spool: Formatting the data according to the specified print parameters and for a specific device type. Output: Sending the formatted data for output to the host spool system where the printing device is connected. When user sends a print job request, they are actually sending the request to the SAP spool system. This process is known as generating a spool request. These spool requests can either be sent to the host spool system immediately, or they can be held in the SAP spool system for later printing. The host spool system is the ultimate component in charge of sending the print job to the physical printer. Printing in a SAP system can be of three categories: Local Printing Remote Printing PC Printing If the SAP application server where the spool work process is running, and the host system are actually the same server, then this is considered Local Printing; when these systems are different, then it is considered Remote Printing. A special type of remote printing is when the host system is a presentation server running the SAPLPD transfer program; this type of printing is known as PC Printing.

SAP-R/3 SYSTEM ADMINISTRATION

Page 25 of 42

# SAP Access Methods: The SAP access method specifies the communication path between the SAP spool system and the host spool system. Access methods are used for defining the type of printing local, remote, or PC printing. The following access methods are available in a SAP system: C (Direct operating system call): This access method is commonly used for local printing, and is suitable for Windows systems. E (External output management system): This access method is designed for output requests that are sent to an Output Management System (OMS), which is compatible with R/3 printing commands. F (Printing on front-end computer): This access method is designed for those end users who require printing on their locally attached printer, which has not been defined on the R/3 system as an output device. In these cases, the R/3 dialog work process handling the user request sends the formatted request to the SAPLPD process, which is then automatically started on the users PC. I (Archive service): This access method is for defining an output device to be used as an archiving system. L (Print locally using LP/LPR): This access method is commonly used for local printing, and is suitable for UNIX systems. P (Device pool): This special access method is used for defining device pools. With device pools, output requests can be sent to more than one printer at a time, and also they can be used for defining several printers to perform automatic print load balancing. S (Print using SAP protocol): This access method is used both for remote printing and PC printing. It uses a special SAP communication protocol. U (Print using Berkeley protocol): This access method is used for both remote printing and PC printing. This method is not recommended for slow WAN connections, since there is the possibility of printing large volume jobs, which might slow down the processing of other print requests. X (SAPcomm): This access method is used for devices which are managed by the SAP spool system and handled by the SAP communication server, such as FAX, Telex, and EDI.

# The TemSe (Temporary Sequential) Objects Database: The spool system uses the TemSe (Temporary Sequential) objects database to store print data. The TemSe database is also used for storing background processing job logs and other sequential text objects that are temporary in nature. Since the TemSe database can hold a lot of job logs or print data files, the report RSPO0041 is scheduled periodically as a background job for removing and reorganizing the log files. If deleted manually, the background processing system or the spool system might issue some error messages when trying to display or delete log files. TemSe has two main storage options. Spool request data can be stored either in the R/3 database or in the file system of the operating system of the host. This can be customized with the profile parameter: rspo/store_location. When file storage is used, by default data is stored in the R/3 global directory - \usr\sap\<sid>\sys\global.

SAP-R/3 SYSTEM ADMINISTRATION

Page 26 of 42

. # Configuring Operation Modes: The configuration requires the following steps: 1. First define a new operation mode. To do this, execute the T. Code: RZ04. Then choose Menu: Operation mode -> Create. Fill up the required fields and save the entries. To define multiple operation modes, repeat this step. 2. Then define or create a new CCMS instance. To do this, execute the T. Code: RZ04. Choose Instances/operation modes from the application toolbar. Then finally choose Menu: Instance -> Create new instance. Fill up the required fields and save the entries. 3. Now assign the instance to newly defined operation modes. When you save the entries in step 2, the CCMS: Maintain Work Process Distribution dialog box automatically pops up. Enter the operation mode in the required input field and increase or decrease the number of work processes as needed by your new operation mode. Then save the entry. Repeat this procedure for multiple operation modes. 4. Finally execute the T. Code: SM63 and assign operation modes to the timetable for 24-hour cycle.

SAP-R/3 SYSTEM ADMINISTRATION

Page 27 of 42

ALERT MONITORS
T. CODE TASK

RZ20 RZ21 SSAA

CCMS Central Alert Monitor. Configure batch job to collect performance history data. System administration assistant.

# System Monitoring Tools: The two major system-monitoring tools are: CCMS (Computer Center Management System) Central Alert Monitor System Administration Assistant (SAA)

# CCMS Central Alert Monitor: The CCMS Central Alert Monitor is primarily an alert monitor, through which you can monitor the servers in your landscape, such as Development, Quality Analysis, Production, etc. You no longer have to individually log into each system to search for alerts. An alert indicates a potentially serious problem that should be quickly resolved; if not contained, these problems could deteriorate into a disaster. CCMS Central Alert Monitor can do the following tasks: Current view and Alert view. Table and Graphical display for any alert. View Performance History data. View and analyze the alert. Acknowledge the alert. View System Configuration Information. Maintain the Alert Thresholds. Modify (Hide / Create a new / Add to existing) SAP standard Monitor Sets. # System Administration Assistant: The SAA is a control panel from which you can directly access the specific monitoring tools and be notified of any alerts. The SAA lists all the R/3 administrative tasks and tracks tasks that need to be done. It also provides documentation on each task and displays critical, and non-critical alerts. # Failed Updates: An update terminate (or failed update) is an update to the database that failed. These terminates occur when a user entry or transaction is not entered or updated in the database.

SAP-R/3 SYSTEM ADMINISTRATION

Page 28 of 42

R/3 PERFORMANCE TUNING

TRANSACTION TECHNICAL NAME TASK

ST03 ST02 OS07 ST04 DB02

Workload analysis. R/3 buffer performance statistics. Operating system monitor. Database activity. Database tables / indexes.

SAP-R/3 SYSTEM ADMINISTRATION

Page 29 of 42

CHANGE AND TRANSPORT MANAGEMENT

T. CODE TASK

STMS STMS_IMPORT SE06 SE01 SE09 SE10 SE03

Transport Management System. Import Queue: System <SID>. Post-Installation Methods for Transport Organizer. Transport Organizer (Extended View). Transport Organizer (Workbench Organizer). Transport Organizer (Customizing Organizer). Transport Organizer Tools.

The Change and Transport System (CTS) consists of the following components: Change and Transport Organizers (CTO) Transport Management System (TMS) Transport tools at the operating system level.
Change and Transport System (CTS)

Change and Transport Organizers (CTO) R/3 Level Workbench Organizer SE09 Customizing Organizer SE10 Transport Organizer SE01 Transport Management System (TMS) STMS

OS Level

Transport Tools: tp, R3trans

The Change and Transport Organizer (CTO) is composed of T. Codes: SE01 (Transport Organizer), SE09 (Workbench Organizer), and SE10 (Customizing Organizer), which are user for registering the modifications done on repository and customizing objects. In a distributed SAP system environment, the CTO use the Transport Management System (TMS) for managing, controlling, copying, or moving, in an orderly manner, the development objects or customization settings among different SAP systems. A transport starts in the development system, is transported to the quality assurance system where is tested, and finally into the production system. The transport process consists in exporting objects out of the source R/3 system and importing them into the R/3 target system. The actual transport process is performed at the operating system level using the transport tools like tp and R3trans. The TMS is linked to these programs so that R/3 allows transports (exports and imports) to be performed within the system using RFC calls.

SAP-R/3 SYSTEM ADMINISTRATION

Page 30 of 42

# Configuring the TMS and Transport Routes: The configuration of the Transport Management System (TMS) for a two-system landscape design (Development > Production), involves the following steps: 1. Log on in client: 000 in the SAP system that you want to configure as the Transport Domain Controller. (The transport domain controller should normally be configured in a production system or quality assurance system.) 2. Initialize the change and transport organizer (CTO) by using T. Code: SE06 and then execute Post-Installation Processing. 3. Execute the T. Code: STMS. Enter the name and a short description of the transport domain in the dialog box TMS: Configure Transport Domain. Save the entries. The following actions are performed automatically in the SAP system: The user TMSADM is created. The RFC destinations required for R/3 communications is generated. The file DOMAIN.CFG is created in the bin directory of the common transport directory. 4. Once you have configured an SAP system as the transport domain controller, you can include all additional systems in the transport domain. Log on in client: 000 in the SAP system that you want to include in the transport domain. 5. Initialize the change and transport organizer (CTO) by using T. Code: SE06 and then execute Post-Installation Processing. 6. Execute the T. Code: STMS. Click the command button Other Configuration in the dialog box TMS: Configure Transport Domain. Enter the target host and the system number of the transport domain controller. Save the entries. 7. To confirm the inclusion of the system in the transport domain, log on in client: 000 in the SAP system that functions as the transport domain controller. 8. Execute the T. Code: STMS. Choose Menu: Overview -> Systems. Position the cursor on the additional SAP system and choose Menu: SAP system -> Approve. Lastly choose Menu: Extras -> Distribute and activate configuration. 9. Once the systems are configured, set up the transport route. Execute the T. Code: STMS. Choose Menu: Overview -> Transport routes and then Menu: Configuration -> Standard configuration. Now set the Extended Transport Control function. With this function, you can specify a client for the transport target. To do this, select a transport layer in the transport route editor and choose Menu: Edit -> Transport layer -> Change. Then on the dialog box Change Transport Route, choose the command button Extended Transport Control. Specify the target client for the consolidation system. Save the entries. Repeat this procedure for any other defined transport layer. Finally save the transport route settings and distribute and activate the configuration across all systems. # Additional TMS Configuration Settings: The TMS allows the definition of a backup domain controller that can take over the functions of the transport domain controller in case of failures. To define a backup domain controller, log on in client: 000 of the SAP system functioning as the transport domain controller and execute the T. Code: STMS. Choose Menu: Overview -> Systems. Position the cursor on the domain controller. Choose Menu: SAP system -> Change. Under the Communication tab, enter the system to be used as backup domain controller of the transport domain. Save the entries and distribute the configuration change.
SAP-R/3 SYSTEM ADMINISTRATION Page 31 of 42

 To delete a TMS configuration, execute the T. Code: STMS. Choose Menu: Overview -> Systems. Finally choose Menu: Extras -> Delete TMS configuration. Delete the transport route and the transport configuration file from the bin directory. The TMS includes the functionality of adding virtual systems for the purpose of defining R/3 systems that have not yet been installed or are not yet available. To define a virtual system, log on in client: 000 of the SAP system functioning as the transport domain controller and execute the T. Code: STMS. Choose Menu: Overview -> Systems. Finally choose Menu: SAP system -> Create -> Virtual system. Enter the system ID and description and save the entries. The TMS includes two types of editors for defining and configuring transport routes: (1) A hierarchical list editor, and (2) A graphical editor. To choose the type of editor execute the T. Code: STMS. Then choose Menu: Extras -> Settings -> Transport routes. To check the RFC connection between all the R/3 systems in the transport domain, execute the T. Code: STMS. Then choose Menu: Monitor -> RFC connections. To check whether the transport control program tp and the TPPARAM file are correctly configured, execute the T. Code: STMS. Then choose Menu: Overview -> Systems. Finally choose Menu: SAP System -> Check -> Transport tool. To verify the availability of the transport directories in all systems within the transport domain, execute the T. Code: STMS. Then choose Menu: Overview -> Systems. Finally choose Menu: SAP System -> Check -> Transport directory. If you modify an object in a system in which it was not created, then you are making a repair task. If you modify an object in a system in which the object was created, then you are making a correction task. In order to transport corrections / repairs applied on any type of objects, you have to set the Global Setting of the System Change Option to Modifiable. Execute the T. Code: SE03. Then execute the Set System Change Option from the Administration folder. Edit the components to Modifiable, Restricted Modifiability, or Not Modifiable. Save the entries. There are two types of transport routes Consolidation Routes and Delivery Routes. First set up the consolidation routes, and then set up the delivery routes. The development system is set as the transport source and the quality assurance system is set as the transport target of the consolidation routes. In a two-system landscape, the production system is set as the transport target. The quality assurance system is set as the transport source and the production system is set as the transport target of the delivery routes. During setting up a delivery route, make sure that all change requests that are imported into the routes source system are automatically flagged for import into the routes target system. # Performing Transports with the TMS: 1. When new developments, corrections, or customizing work is complete, release the tasks and requests. To do this, execute T. Code: SE09/SE10. As request types, select the Customizing requests and the Workbench requests check boxes and deselect other options. As request status select the Modifiable check box. Then click the Display button. The system will display a list with the change requests that have not yet been released. To list the tasks, open up the change requests by clicking the + sign on the folder signs. Position the cursor on the task to be released and click on the Release button on the application toolbar. When all of the tasks under a request have been released, then the request itself can be released. If the release is normal, an export run takes place, exporting the object data to operating system files in which the import to the target system takes place.
SAP-R/3 SYSTEM ADMINISTRATION Page 32 of 42

2. Log on to the target client in the target system. All the transportable change requests that have been released are now displayed in the import queues of the target client of the target system. To access the import queues, execute the T. Code: STMS_IMPORT. The system will display the import queue. To begin the transport process select the Start import function, which will request the target client and start importing the queue in the order in which the change requests were previously released. # Configuring the Transport Control Program, tp: The transport control program tp is a utility for controlling transports between SAP systems and for upgrading SAP releases. When tp is used, during an export, the objects to be transported are extracted from the database of the source system and stored in files of the operating system. During the import, the objects are added to the database of the target system. To prepare the SAP system for tp, do the following steps: 1. Ensure that all SAP systems have unique names. Transport is possible only between SAP systems that have different names. 2. Ensure that the source system (for exports) and the target system (for imports) have minimum two background work processes. 3. Configure the transport management system (TMS) and the transport routes as per requirements. 4. Initialize the transport dispatcher. To do this, start the program RDDNEWPP once in every SAP system by executing the T. Code: SA38. Do this as user DDIC in client 000 and in all clients that are used as the source or target for a transport. Then only can tp start the background job RDDIMPDP in every SAP system if it is needed to perform a transport (export / import). 5. The transport directory must be installed. The transport directory is described by the following parameters: SAPTRANSHOST Name of the host configured as the central transport host on the domain name server. SAPGLOBALHOST Name of the host on which the central system is installed. sapmnt Global share that point to the \usr\sap file tree on the central instance. 6. The central transport profile must be up to date. The transport profile is a global parameter file for the program tp and is administrated by the SAP System using the Transport Management System (TMS). The profile resides in the transport directory \usr\sap\trans\bin. The profile is named as TP_<domain>.PFL, where <domain> is the name of the transport domain configured in TMS. # Additional tp Configuration Settings:
tp pf=\\<host>\sapmnt\trans\bin\TP_<domain>.PFL <command> <sid>

The program tp is controlled using the transport profile. Each time tp is started; it must know the location of the global parameter file. The location can be specified with the pf= option. If the transport profile is not specified in this way, tp searches for the transport profile in the current directory.
tp help

The above command displays the general syntax information for tp calls. It also displays a list of all tp commands.
tp <command>
Page 33 of 42

SAP-R/3 SYSTEM ADMINISTRATION

The above command displays the description of the syntax of a tp command function.
tp explainrc <rc> tp showparams <sid>

The above command displays the meaning of a particular tp return code. This tp function displays which values the individual parameters of the transport profile have for the current SAP System.
tp showbuffer <sid> tp cleanbuffer <sid> tp addtobuffer <request> <sid> tp delfrombuffer <request> <sid>

The above tp commands are executed to work with the buffer of the SAP system. # Performing Transports with the Transport Control Program, tp: 1. The transport of a request begins when the owner of the request releases it. So from the source SAP system release the transport request using the Transport Organizer (T. Code: SE09/SE10). The request is then unlocked and the data is exported at the operating system level. Tp controls the export and registers that the request has to be imported into the target system. 2. Log on as <SID>ADM in the target SAP system. 3. Test your connection to the target system with the following command:
tp connect <target_sid

4. Open the command prompt and go to the drive where the SAP system resides. Then execute the following commands:
cd \usr\sap\trans\bin tp pf=\\<host>\sapmnt\trans\bin\TP_<domain>.PFL import <request> <target_sid> client=<nnn>

Or
tp pf=\\<host>\sapmnt\trans\bin\TP_<domain>.PFL import all <target_sid> client=<nnn>

5. If you get error messages during any phase of the import, tp will stop any further actions. After looking at the log files and finding the cause for the error and solving the problem, you normally can start the import process again.

SAP-R/3 SYSTEM ADMINISTRATION

Page 34 of 42

SCHEDULED DAILY TASKS

TRANSACTION TECHNICAL NAME TASK

Critical Tasks: DB12 The R/3 System: SM51 RZ20 SM50 * SM13 * SM21 * SM37 SM12 * SM04/AL08 SP01 SM35 ST22 ST03 ST02 Database: AL02 ST04 Operating System: AL16 OS06 OS Alerts OS Monitor Review system logs for problems. Review system logs for problems. Database (DB) Alert DB Performance Analysis Review error log for problems. Review error log for problems. SAP Servers CCMS Monitor Process Overview Update Records System Log. Select Background Jobs Lock Entry Lists. Users Spool: Request Screen Batch Input: Initial Screen ABAP Dump Analysis Workload: Analysis of <SID> Tune Summary Check that all application servers are up. Check the CCMS alert monitor. Check work processes. Look for any failed updates. Check system log. Review for cancelled jobs. Check for old locks. Check for users on the system. Check for spool problems. Check job log. Review and resolve dumps. Review workload statistics. Review buffer statistics. Backup Logs: Overview Check that daily backups executed without errors.

* These tasks are done several times a day.

SAP-R/3 SYSTEM ADMINISTRATION

Page 35 of 42

USEFUL SYSTEM PROFILE PARAMETERS

PARAMETER NAME DESCRIPTION

rdisp/wp_no_dia rdisp/max_wprun_time rdisp/wp_no_btc rdisp/wp_no_spo rdisp/wp_no_enq rdisp/enqname = <instance_name> rdisp/wp_no_vb rdisp/wp_no_vb2 rdisp/vbname = <instance_name> rdisp/mshost = <host_name> rdisp/autoabaptime

This parameter controls the number of interactive dialog work processes per instance. This parameter sets the maximum allowed time for interactive execution of a dialog step. This parameter controls the number of background work processes per instance. This parameter controls the number of spool work processes per instance. This parameter controls the number of enqueue work processes per instance. This parameter specifies the name of the SAP instance running the enqueue service. This parameter controls the number of update work processes per instance for V1. This parameter controls the number of update work processes per instance for V2. This parameter specifies the name of the SAP instance running the update service. This parameter specifies the name of the host running the message server. This parameter specifies the time interval to run ABAP program SAPMSSY6 cyclically, which is in charge of switching the operation mode of a system for the first time. Disable several users sharing a single user ID by setting the parameter value to 1. Allow specific users to logon multiple times by entering their user Ids separated by commas and no spaces. Turn off the special status of SAP* by setting the parameter value to a value greater than zero. Set the minimum password length. A longer password is more difficult to break or guess. Set the password expiration time. This time period is the limit before users must change their password. This parameter locks out users who, after a specified number of times, try to logon with an incorrect password.

login/disable_multi_gui_login login/multi_login_users login/no_automatic_user_sapstar login/min_password_lng login/password_expiration_time login/fails_to_user_lock

SAP-R/3 SYSTEM ADMINISTRATION

Page 36 of 42

rsau/enable rsau/max_diskspace/local rsau/max_diskspace/per_file rsau/selection_slots

Start security audit log by setting the parameter value to 1. Set the maximum space for the security audit file. When the limit is reached, the logging will end. Set the size of an individual security log file. The maximum size per file is 2 GB. This parameter defines the number of selection criteria or filters for Security Audit Logs. The maximum value is 5. This parameter specifies where the TemSe stores the R/3 spool data. The operating system dependant commands, lp or, lpr for printing, are set in this parameter This parameter specifies the maximum allowed size for a local R/3 system log file. This parameter specifies the maximum allowed size for a central R/3 system log. This parameter specifies the absolute path name for the trace files. This parameter specifies the maximum amount of disk space in bytes, which can be allocated to the trace files.

rspo/store_location rspo/host_spool/print

rslg/max_diskspace/local rslg/max_diskspace/central

rstr/file rstr/max_diskspace

SAP-R/3 SYSTEM ADMINISTRATION

Page 37 of 42

USEFUL TABLES
TABLE NAME DESCRIPTION

USR40 T000 SUKRI T100 TSTC TADIR TDEVC

Display View Table for illegal passwords. Display View Clients. Display View Transaction combinations critical for security. Message Maintenance: Initial Screen. Maintain Transaction. Change Object Directory Entries. Development Classes.

SAP-R/3 SYSTEM ADMINISTRATION

Page 38 of 42

USEFUL REPORTS
REPORT NAME Users and Authorizations DESCRIPTION

RSUSR003 RSUSR005 RSUSR006 RSUSR007 RSUSR008 RSUSR009 RSUSR100 RSUSR101 RSUSR102

Spool Administration

Checks the passwords of users SAP* and DDIC in all clients. List of users with critical authorizations. List of user master records locked due to incorrect logon. List of users whose address data is incomplete. List of users with critical combinations of authorizations at transaction start. List of users with critical authorizations. Lists change documents for users. Lists change documents for profiles. Lists change documents for authorizations. Delete old spool requests. TemSe: Data consistency check. Spool data consistency check in background. Copy/delete specific tables form a client. Copy client-specific tables from a client. Copy variants between clients. List of system log messages. Background scheduler to initialize the transport dispatcher. Display Profile Parameters. Display Profile Parameters with short description.

RSPO0041 RSTS0020 RSPO1043

Client Administration

RSCLXCOP RSCLCCOP RSDBVCOP

System Logging

RSLG0011 RDDNEWPP
Profile Parameters

Transport Management System

RSPARAM RSPFPAR

SAP-R/3 SYSTEM ADMINISTRATION

Page 39 of 42

USEFUL LOGGING PATHS

Client Copy Logs CAR files Audit Logs (T. Code: SM19, Menu: Environment -> Profile Parameter) System Profiles EXE files Transport Requests: Client Export Transports System logs Trace files: \usr\sap\MAT\DVEBMGS00\log\TRACE000.Log Transport profile path: \\SERVER\sapmnt\trans\bin\TP_Domain_MAT.pfl

RSPARAM RSPFPAR

SAP-R/3 SYSTEM ADMINISTRATION

Page 40 of 42

USEFUL SAP SITES

SITE DESCRIPTION

SAP-R/3 SYSTEM ADMINISTRATION

Page 41 of 42

TRANSACTION CODE SUMMERY

T. CODE Client Administration TECHNICAL NAME

Miscellaneous

/n /o /nex SM59 SM31 / SM30 SGEN SLG2 SE93 SE16 SE51 SE41 SU02 SU03 SE38 SA38 SE80 RZ03 SE14 SAINT ST05 ST11

Open Session. Create Session. End Session. Display and maintain RFC destination. Table Maintenance. SAP Load Generator. Application Log: Delete obsolete logs. Maintain transaction. Data Browser: Initial screen. Screen Painter: Initial screen. Menu Painter: Initial screen. Profiles: Initial screen. Maintain Authorizations: Object classes. ABAP Editor: Initial screen. ABAP: Execute program. Object Navigator. CCMS Control Panel: Display Server Statuses and Alerts. ABAP Dictionary: Database Utility. SAP Add-On Installation Tool. Performance Trace. Developer Traces.

SAP-R/3 SYSTEM ADMINISTRATION

Page 42 of 42