SAP R/3 System Management: System Administration
National Education Training Group, Inc.
Copyright © 1999 National Education Training Group, Inc.
All rights reserved. No part of the material protected by this copyright may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, broadcasting, or by any information storage and retrieval system, without permission in writing from National Education Training Group, Inc.
Written consent issued by:
NETG Inc.
1751 West Diehl Road
Naperville
IL, 60563
Table of Contents
Introduction to the R/3 Basis System
Architecture/System Landscape
Client/Server Architecture
R/3 Information Layers
Central and Multi-Tier Configuration
R/3 Directory Structure
System Landscapes
R/3 Services
Application Services
Additional Services
Central and Distributed Instances
Interaction between Work Processes
Work Process Overview
R/3 Networks
Definitions in the R/3 Environment
Computers and Services in the R/3 Network
The SAPROUTER
Basic Administration Principles
Starting and Stopping the R/3 System
Preparatory Measures
What Happens when you Start the R/3 System ?
SAP Service Manager
Starting and Stopping the R/3 System from the Command Prompt
Startup Diagnosis
Installing the Frontends
Installing the SAPGUI
Configuring the SAPLOGON
Group Selection
User Administration
Displaying and Creating Users
Copying, Deleting, and Changing Users
Authorization Profiles
User Overview SM04
Administration Routines
SAP Profiles
Different SAP Profiles
Changing Profiles
Profile Versions
Operation Modes
Purpose
Creating Operation Modes
Work Process Distribution for Operation Modes
Immediate Changeover to a new Operation Mode
Monitoring the Operation Mode Changeover
Printing in the R/3 System
Spool Work Process
Creating a Printer
Changing a Printer
Access Methods
Administration of Spool Requests
Background Jobs
Background Work Process
Scheduling
Checking
Canceling, Changing, Deleting
DB Administration/System Log
Backup Strategy
Scheduling a Backup
Checking Backups
Checking Database Consistency
System Log
Glossary
The lesson on architecture and system landscapes deals with the general principles of system architecture, information levels, directory structures and the different system landscapes of the R/3 System.
The R/3 configuration is based on a server from which information can be accessed by the respective clients. These are connected to the server via a Local Area Network (LAN). The clients usually have a Windows user interface with the SAPGUI at the frontend. The SAPGUI is SAP's own Graphical User Interface.
The R/3 kernel (or in other words, the R/3 System programs) and the R/3 database can both be installed on the server, depending on how this is configured. The R/3 client/server architecture is designed in such a way that the user clients request services from the server via the network. The server provides the services requested and sends the results back to the clients via the network.
From a hardware perspective, the R/3 System makes a distinction between the presentation, application, and database information layers, depending on the task being carried out. These layers can all be implemented on one server but are usually located on separate computers.
The database layer is fully mapped via the Relational Database Management System (RDBMS). This system processes requests and changes for all R/3 data.
The application layer contains components such as the screen interpreter, ABAP dialog processor, dispatcher, and work processes, and provides the platform for running all ABAP programs. The application layer can be assigned to several computers. As a result, the load can be distributed in accordance with the individual application areas.
The presentation layer is located on the clients. A client is usually a graphics-capable PC on which the SAPGUI program has been installed.
There are three types of R/3 configuration: central systems, two-tier configurations, and three-tier configurations. In a central system, the presentation, application, and database layers are located on one computer which then carries out all of the necessary processing tasks. An example of a central system is a UNIX installation for a small number of clients. This configuration is, however, not very practical in a real-life situation. In a two-tier configuration, the presentation layer normally runs separately from the database and application layers. This configuration is usually found in smaller installations.
The other less common variant of a two-tier configuration involves installing powerful desktop systems, for software development for example, on which both the presentation and application layers can run. In this case, the database layer runs on a separate server.
In a three-tier configuration, the presentation, application, and database layers are separate. All levels run on different computers. An important advantage of this configuration is that it optimizes load distribution.
A distinction is made between global and local directories within an R/3 System. The global directories are usually located on the database server. There is only one global directory in each R/3 System.
Each SAP instance has local directories which are located on the R/3 application servers. An instance is an administrative unit in the R/3 System and contains the components that are typical for the application layer. Both directory types have the same basic path \usr\sap\<sapsid>. The SAP System name here is <sapsid> and consists of three characters.
In Windows NT, the global directories have the share name sapmnt. The most important subdirectory here is \<sapsid>\sys\exe\run in which the R/3 program files are stored.
The client structure of an R/3 System forms the basis of the R/3 System landscape. Within the R/3 System, a client is a commercially and organizationally independent unit with its own data environment. In R/3, a distinction is made between the development, quality assurance, and production environments. Each environment can be an independent R/3 System or can be mapped as a client within a single R/3 System. There are also different landscape types in R/3, depending on whether the environments are located on one or several servers. A distinction is made between the one-system, two-system, and three-system landscapes.
In a one-system landscape, the development, quality assurance, and production environments are each individual clients within one R/3 System. The advantages of a one-system landscape are the minimum hardware and administration requirements. The main disadvantage of the one-system landscape is that new cross-client changes and developments have an immediate effect on the production environment. Performance and data security are also impaired. Furthermore, it is not possible to carry out a test run beforehand for an R/3 release change.
In a two-system landscape, the development and quality assurance environments are separate clients within one R/3 System. The production environment is an independent R/3 System located on a separate server. With this type of configuration, the production environment is not affected by the clients in the development and quality assurance environments. The advantage of this is a secure production environment, both with regard to data and performance. One disadvantage of this system landscape is the common database in the development and quality assurance environments. Transport requests to the production environment, with cross-client changes and developments, cannot be tested.
In a three-system landscape, the development, quality assurance, and production environments are located on different servers and in different R/3 Systems. The advantage of a three-system landscape is a more secure production environment. Production data and performance are not affected by the development or quality assurance environments. The development environment is also independent of the other environments and transport requests from here can be tested in the quality assurance environment before they are sent to the production environment. The disadvantage of a three-system landscape is that more hardware is required which, of course, means higher costs. As the advantages clearly show, this system landscape provides the ideal framework for a production system and is, in fact, recommended by SAP.
This lesson looks at the different R/3 services and explains how these interact.
All application services of the R/3 System are made available on the application layer. These services are based on the ABAP programs, which control the R/3 System. The most important element of the application layer is the dispatcher which monitors all R/3 processes. To do so, it manages different work processes to which it distributes the tasks that are pending in the R/3 System.
User requests are assigned to the dialog work process via the dispatcher. The dialog work process executes one dialog step and returns the result to the user after which it is ready to accept the next request. This request can be from the same or from a different user.
The background process is responsible for background processing. This work process executes ABAP programs and reports at predefined times or in response to certain events. Every R/3 System should have at least 2 background work processes.
The spool work process is responsible for transferring data to output devices. A dialog or background work process can initiate a print job for printing lists or forms, for example. The data to be printed is placed in a spool request.
The enqueue work process is in charge of the lock management system. It prevents several employees from changing one data record at the same time. The lock management facility depends on predefined business requirements. Each R/3 System has one enqueue work process.
The update work process is responsible for updating input data in the database. Input data can be updated using the V1 or V2 components. Time-critical processes are updated with the V1 component and the less critical processes with the V2 component.
In a dialog work process, all changes made to a data record are saved temporarily in a log record in the VBLOG table. When the dialog transaction is complete, the dispatcher initiates a free work process to update the database as well. This is also known as an asynchronous update.
In addition to the application services controlled via the dispatcher, the R/3 System offers services such as the message server and gateway server. In a configuration with several application servers, the message server controls communication between the individual servers. As this server acts as a kind of mediator, there is only ever one in each R/3 System. The gateway server is a service within the R/3 System that supports communication with systems outside R/3. The gateway server uses the SAP gateway that is started on every application server. It supports the link between different R/3 Systems, between R/3 and R/2, and between R/3 and external programs. The gateway server manages the CPI-C communication interface. This interface enables different programs to communicate with each other. CPI-C also allows R/3 to communicate with other mainframes or external programs.
An instance is an administrative unit which can be installed in the R/3 System. It consists of a dispatcher and several work processes. The work processes of an instance are started or stopped together. Instances are assigned to the application level.
With a central instance, all of the components of the application and database layers are located on one server. In this case, the R/3 System consists of one single instance and the presentation layer can be on different computers.
With a distributed instance, the components of the application layer are distributed among several servers. The message server is the service that supports central communication between the different application servers. This message server ensures that the different dispatchers are able to communicate with each other. Presentation servers can also log on to one application server via the message server.
The following example illustrates how the individual work processes of the R/3 System interact.
An R/3 user starts a transaction for creating a customer order. Once the required article has been specified, the system performs an availability check. To do so, the dispatcher finds a free dialog process which passes on an appropriate request to the database. At the same time, the enqueue work process locks the data record in question, in order to prevent other users from making any changes. Once the user has received confirmation that the article is available, a new dialog step is initiated. The sale of the article is confirmed, the modified data record is written to the VBLOG table, and a commit with the message Transaction successfully completed is sent to the database. Following this, the dialog work process informs the dispatcher that the update work process can begin. The dispatcher then activates an update work process. As stored in the VBLOG, the database is updated and the update work process sends a commit, with the message Update completed, to the database. An enqueue work process is then activated. This unlocks the processed data record so that it is available again for other users.
You can go straight to the process overview by entering the transaction code SM50 in the R/3 initial screen.
The statuses of the individual work processes are displayed in the Status column. Other columns provide further information on the work processes that are running. If you scroll to the right, you can see the Report column which displays the programs that have been started by the process. The Client column provides information on the client in which the user is working or has been created. The current user of the work process is displayed in the User column.
If you want to carry out an error search, you can display detailed information on an individual work process by clicking the Detail info pushbutton in the lower application toolbar. This contains the same data as the Process Overview. You can find further information in the middle and lower part of the screen. The upper table in the middle of the screen provides information on actions in the database. The lower table displays the actions in the buffers together with their times in microseconds. At the bottom of the screen, you can see a table with information on the development environment.
This lesson takes a look at the R/3 network and explains the terminology used to describe the environment, the R/3 services and the functions performed by the SAPROUTER.
A share is the release name of a directory on Windows NT and is displayed in the Properties dialog box in the Explorer of the R/3 server (right mouse button). Other users and systems can access the released data using this name.
R/3 executables are the R/3 programs which ensure that the system operates correctly and are located in \usr\sap\<sapsid>\sys\exe\run.
The R/3 logs are the R/3 log files. They contain information on system responses. The R/3 logs can be accessed via \usr\sap\<sapsid>\<instance name>\work.
New ABAP programs are created and tested in the R/3 development environment. These are then transported to the quality assurance environment and tested again under real-life conditions.
R/3 users work in the production environment which contains real-life, current data and programs. This environment must not be used to develop new programs. Changes are only allowed via transports from a predecessor system. Developments or modifications are transferred from one environment to another by means of a transport request.
A commit indicates that a transaction has been completed and can consist of several steps.
Within the R/3 System, a client is a commercially and organizationally independent unit with its own data environment. The client names consist of three-figure numbers. With the exception of the default clients (000, 001, and 066), the client names can be freely selected by the user.
Nowadays, TCP/IP is the most commonly used transport protocol for network communication and is, for this reason, also essential for connecting an R/3 server.
A frontend is a computer on which the SAPGUI has been installed. SAPGUI is SAP's own graphical user interface.
SAPOsCOL is an operating system service on a server that collates and forwards data for analyzing performance in the R/3 System.
In a network, you have to maintain the data for all the computers and SAP services. You can do this in the Hosts and Services files. You access these files via the Windows NT Explorer and WINNT\system32\drivers\etc.
The computers in the Hosts file are defined by specifying the TCP/IP address and the network name. The R/3 services are defined and maintained in the Services file. The data is normally entered automatically during installation. Here, the service names are stored with the appropriate numbers and logs. There is also an option for defining alias names. It is important to ensure that the TCP/IP connections are established between the computers in an R/3 network. TCP/IP is the only protocol used in the R/3 System for communicating between database and application servers and for connecting the SAP frontends.
In PC networks, a further communication protocol is often used in addition to TCP/IP. This depends on the network operating system used (Novell Netware requires IPX/SPX for example, Banyan Vines uses VinesIP, whereas IBM and Microsoft use Netbeui).
A SAProuter is a process on the R/3 application layer that forwards SAP data streams from one IP sub-network to another or within the same sub-network. It conceals the local TCP/IP addresses as these are usually only unique within the network in question. A SAProuter does NOT replace a conventional router.
If a SAProuter is connected between a SAPGUI and an application server, there is no direct network connection between the two components. The SAProuter checks the routes and authorizations, as specified in the SAProuter string, and forwards the data to the destination. A SAProuter is used whenever a computer with a SAPGUI (R/3 client) and an application server cannot communicate with each other directly. You also use SAProuters if you need to protect your system or network. A SAProuter is also used if R/3 processes are to be relieved of service tasks in slow WANs. Here, the SAProuter stores all R/3 packets temporarily and handles WAN communication when the data is forwarded.
This lesson shows you how to start and stop the R/3 System and explains how to overcome any problems you may encounter when starting the system.
Certain SAP and database services have to be running on Windows NT before the R/3 System can be started. You can check the status of these services by choosing Start, Settings, and Control Panel. In the Control Panel of Windows NT, you can call up the Windows NT services by double-clicking the Services icon. The Services dialog box displays, among other things, the Windows NT services required by the R/3 System. The Service, Status, and Startup columns provide you with information on these services and their statuses. The SAP service SAPOsCol should be started before the R/3 System is started. This service collects statistical data on the operating system and the R/3 System itself. The SAP service SAP<SAPSID>_<Instance no.> also has to be active. This service is responsible for the executability of the R/3 System.
When you start Windows NT, the services required for R/3, namely SAPOsCol, SAP<SID>_<Instance_No> and DB service(s) are started automatically. Clicking the Start pushbutton in the SAP Service Manager - also referred to as the R/3 Start/Stop console - initiates various start procedures. Firstly, the database, message server, and dispatcher are started with the start profile. The dispatcher also starts the individual work processes. Each work process starts a shadow process on the database that has already been activated. At the end of the start procedure, the dispatcher sends a message to the message server indicating that the connection was successful. The traffic lights in the SAP Service Manager then change to green.
The SAP Service Manager on Windows NT is a user-friendly tool for starting and stopping an R/3 System. You can start the Service Manager directly from the R/3 server by choosing Start, Programs, SAP R3, and SAP Service Manager. The gray traffic lights alongside the processes displayed in the SAP Service Manager dialog box indicate that the R/3 System has not yet been started. The Database is activated first by the start process. After this, the message server and the dispatcher start. Stopping the R/3 System is also very easy using the SAP Service Manager. The Message Server and the Dispatcher are then shut down. The integrated database has to be stopped separately. You can do this at the operating system level or by choosing Start, Programs, and Command Prompt.
As an alternative to the SAP Service Manager, you also have the option of starting and stopping the R/3 System from the Command Prompt using various command strings. To start the R/3 System from the command prompt, you have to enter the command startsap R3 <SAPSID> <HOSTNAME> <STARTPROFILE> and confirm your entry with Return. To stop the system via the command prompt, you have to enter the command stopsap R3 <SAPSID> <HOSTNAME> <INSTANCENAME> and the profile path with the instance profile <PROFPATH + INSTANCEPROFILE> and confirm your entries with Return.
If the R/3 System fails to start, you have to perform a startup diagnosis. In this case, you should first check whether all the required Windows NT services have been started. These services include the SAP<SAPSID>_<Instance_No.> which is responsible for the executability of the R/3 System, and the SAPOSCOL which collects statistical data on the entire R/3 System. In addition to the system services, you also have to start the necessary database services.
Having excluded these error sources, you then have to check the R/3 log files at the operating system level. These log files are located in the work directory which you can open by choosing usr\sap\<SAPSID>\<Instance_name>\. The individual files should be checked in a particular order. The most important files are sapstart.log and sapstart.trc. You can display their contents via the editor by double-clicking the file names.
This lesson describes how the work centers are connected to the R/3 System by installing the frontends.
You will require a presentation CD to install the SAPGUI. The SAP frontend software is stored on this CD in the Gui directory. In addition to the Windows frontend described here, Apple Macintosh, OS/2, and Unix clients are also supported.
Before the actual installation is performed, you will be asked to close any programs that are still running. First of all, you choose the installation type. You then have to specify the destination folder for installing the program files. In the SAP Installation Options dialog box, you can select the groups of components that you would like to install. The components can be installed in different languages. The next step involves copying or defining the working directory. You then specify the path to the documentation CD in which the help files are stored. Next, you define a connection to an R/3 application server. To do so, you have to enter the name of the application server and the system number. You can also set the SAP router string. The frontend installation is complete once you have confirmed the end of the installation procedure. You then have to restart Windows.
SAPLOGON provides a straightforward means of calling up several R/3 Systems using just one tool. SAPLOGON makes it easier for you to work in a multi-system landscape.
To be able to start the SAPLOGON, the SAPGUI must be installed on your PC. You can access the SAPLOGON start file saplogon.exe by opening the directory in which your SAPGUI is located. The SAP Logon dialog box then appears. You can define the connection to a new R/3 System in the New Entry dialog box. To do so, you have to enter the name of the R/3 System in the Description field. You then have to enter the name of the server in the Application Server field. Finally, you enter the system number.
If there are several possible application servers for an R/3 System, you can assign authorizations to certain users so that they can only log onto one particular application server. You can specify this via group selection. Group selection is used, in particular, to distribute the user load among several different application servers. The groups here are formed according to application modules. In addition to optimizing load distribution, group selection also ensures that the R/3 buffers of each application server are only filled with module-specific programs, tables, and menus. This reduces the times required to access the R/3 System.
To create a group selection, you open the Winnt directory in the Explorer and double-click the Sampmsg.ini file. You then have to enter the appropriate message server here. After entering this and saving the file, you close it again. You then have to specify a SAP router string in the Saproute.ini file. Finally, you save the file and close the editor again.
To be able to use group selection, a logon group has to be defined in the R/3 System beforehand. To create a new group selection, you have to choose Start, Programs, SAP Frontend 4.5A, and SAPlogon in the SAP Logon dialog box. To define a logon group, you click the Groups pushbutton. You then have to enter various items of information in the Group Selection dialog box. In the first input field you have to enter the system name. You then have to enter the name of the message server. In the next field, you use the possible entries pushbutton to select the SAP router defined beforehand in the file saproute.ini. By clicking the List pushbutton, you can call up the logon groups in the R/3 System and display them in the Groups field. You choose a group by selecting it and clicking the Add pushbutton. The next dialog box asks you to confirm or change the group description. The procedure for creating a new group is then complete.
This lesson shows you how to create, delete and change users. It also shows you how to assign authorization profiles to users and how to display a current user overview.
To display all the users that are defined in an R/3 System, you call up the User Maintenance: Initial Screen via transaction code /nSU01. You can then display the users in this application. The List Selection Screen dialog box allows you to restrict the users to be listed. You can also create a new user in the User Maintenance: Initial Screen. In this application, you define the new user by entering the name and clicking the Create pushbutton. The name can have up to 12 characters. The SAP naming conventions apply. To create the user correctly, you then have to enter a series of data in the Address, Logon data, Defaults, Task profile, Profiles, and Parameters tabs in the Maintain User screen. It is important here that you make entries in all the required entry fields (which contain question marks).
If you want to copy, delete, or change user data, you have to go to the User Maintenance: Initial Screen. The fastest way of calling up this screen is to use transaction code /nSU01.
To copy the data for the user Nash, for example, you click the Copy icon in the lower application toolbar. You enter the name of the new user in the input field of the Copy Users dialog box. Various default settings can then be changed in the Choose parts field. Before you can finally save your data, you have to enter an initial password twice in the Logon data tab for the user you copied.
To delete a user, you first have to choose or enter the appropriate user name. You can then delete the user by clicking the Delete pushbutton. In the Delete user dialog box, you have to confirm that you want to delete the user. If you want to change the data of a particular user, you call up the User Maintenance: Initial Screen and enter the name of the appropriate user. You then go to the Maintain User application. You can make the necessary changes in the tabs Address, Logon data, Defaults, Task profile, Profiles, and Parameters.
In order to change a user's password, you have to specify the user. You can then change the password by clicking the appropriate pushbutton in the lower application toolbar. You have to enter the new password twice in the input fields.
Users have to be assigned certain authorization profiles so that they can work in the R/3 System. The most extensive authorization profile that can be assigned consists of the profiles SAP_ALL and SAP_NEW. To be able to assign authorization profiles, you first have to go to the User Maintenance: Initial Screen. In this application, you enter the name of the desired user and click the Change pushbutton. To assign authorization profiles, you then have to call up the Profiles tab in the Maintain User application. Next, you have to activate the first input field in the Profile column in the Profiles tab. You can then enter the name of the desired user profile, for example sap_all, and save your entry.
The system administrator can display all the users currently logged onto the R/3 System. User information allows the administrator to display more detailed information. With the help of a session list, the administrator can actively intervene in the work of a particular user. To display all the users logged onto an R/3 System, you first have to go to the user list application. To do so, you can enter the transaction code /nSM04 in the command field of the R/3 initial screen.
The user list provides you with information on the names of all the users currently logged onto the system. It also provides information on the logon client, user terminal, and the last transaction carried out (T code). If you require more detailed information on a particular user, you have to select the appropriate name and click the User info pushbutton. The Users: Detailed Information dialog box provides you with detailed information on the department and extension of the chosen user. If you want to display information on the sessions opened by a user, you select the appropriate user and click the Sessions pushbutton. The Overview of Sessions dialog box then displays the sessions that the user is using at the moment.
This unit provides you with a detailed introduction to the administration routines in the R/3 System.
This lesson looks at the different profiles available in the R/3 System and their respective functions. It also shows you how to change profiles and create different profile versions.
SAP profiles are needed to start the R/3 System. In R/3, a distinction is made between start profiles, default profiles, and instance profiles.
To display the profiles, you enter transaction code /nAL11 in the command field of the initial screen. The path in which all the profiles are stored is displayed alongside the name DIR_PROFILE in the SAP Directories application. By double-clicking this entry, you can display all the profiles stored in this path. The Error Log Files application then provides you with information on the three start files. Here, you can see, for example, when the last changes were made to the parameters for the profiles concerned.
When the R/3 System is started from the SAP service manager, the start profile is first called up from the usr\sap\<SAPSID>\SYS\profile\ directory. This profile contains the instruction for starting the database, message server, and dispatcher in this order. The dispatcher then reads the default profile which contains important profile parameters for all the application servers.
The three profiles will not have been generated when a new R/3 System is installed. For this reason, you first have to call up the Edit Profiles application. The fastest way of doing this is to enter transaction code /nRZ10 in the command field of the R/3 initial screen. In the Edit Profiles application, you can edit profiles according to various criteria such as Administration data, Basic maintenance, or Extended maintenance. When you install a new system, you have to choose Utilities, Import profiles, and Of active servers. The profiles are written to the database from the operating system level so that different profile versions can be created.
If you want to change an SAP profile in the R/3 System and save this as a new version, you have to call up the Edit Profiles application by entering transaction code /nRZ10.
To choose the profile you want to change, you first activate the Profile field. You can then call up the available profiles using the possible entries pushbutton. The Profile name dialog box displays the stored profiles according to name and type. After copying the desired profile, the Edit Profiles application displays the profile name, version number and status of the chosen profile type, for example saved and activated or displayed.
In the Edit Profile Management Data application, you can then change the short description of the profile, the activation path, or the reference server, for example.
If you display the basic maintenance data in change mode, the system calls up the Change Work Process and Buffer Values application. Here, you can make changes to the buffer sizes or to the number of work processes for a profile.
If you display the data for extended maintenance in change mode, you can make concrete changes here to individual profile parameters. If you want to change a parameter value, you first select it and then overwrite it. After entering the new parameter value, you have to copy it by clicking the Copy pushbutton and then save it in the Edit Profiles application. Alongside the version number, the system tells you that the new profile version has the status Not saved. After initiating the save operation, you then have to decide whether you want to activate the new profile and maintain it during the start process. If you do want to do this, you assign the status Active to the new profile. The system then informs you of the new version number of the profile and the new status. To activate the modified profile, you have to restart the R/3 System.
If you have stored several versions of an SAP profile, you can call up another version at any time. This is useful, for example, if the active version contains incorrect values.
To call up a different version, you have to go to the Edit Profiles application. In the Edit Profiles application, you first choose a profile. After you have called up the desired profile, the Edit Profiles application displays the profile name, version number, and status of the chosen profile type (for example saved and activated).
To create a new version, you have to call up an older profile version in the Version field. The Version number dialog box then lists all the available profile versions. If you copy a previous version, the current status of the version - in this case Saved - is displayed next to the input field. The version has, therefore, not yet been activated. To activate it, you have to save the version displayed once again. To activate the version, you have to confirm the prompt that appears. The new version is then saved and activated under the latest number.
This lesson explains the purpose of the different operation modes and introduces you to the methods for creating these. It also shows you how to monitor an operation mode changeover.
Operation modes play an important role in the R/3 System in that they facilitate optimum load distribution of work processes. A distinction is often made here between daytime operation and nighttime operation. Different work processes are assigned to each operation mode. Generally speaking, more dialog work processes are needed during the day and more background work processes at night. The total number of work processes is defined in the R/3 System and cannot be changed.
Operation modes determine which work processes are executed in the system during the day and at night. You can create operation modes in the CCMS: Maintain Operation Modes and Instances application. To call up this application, you enter transaction code /nRZ04 in the command field and confirm your entry with Enter. The CCMS: Maintain Operation Modes and Instances application provides information on the operation modes that are currently active and on the times at which they are executed. This information determines when a changeover is made from one operation mode to another.
In the Operation mode menu, you can create, change, copy, and delete operation modes. When creating a new operation mode, you have to enter data in all the input fields with question marks. You can then make further settings for the new operation mode. In the Operation mode menu, you can also maintain the timetable, for example, for the operation modes. To change data in the timetable, you first have to define the operation mode set, in other words normal or exception operation. In the timetable, you can assign a time interval to a new operation mode. You can select the start and end time of the validity period by double-clicking the appropriate time. The chosen interval then has to be assigned to the operation mode. In the Operation mode input field, you can enter the new operation mode or choose one via the possible entries pushbutton. After you have saved your data, the R/3 System switches the operation modes automatically according to this timetable.
If you have defined or redefined operation modes, you can adjust the number of work processes for the operation modes in the CCMS: Maintain Operation Modes and Instances application. By clicking the Instances/operation modes pushbutton, you can find out which instances are assigned to the individual operation modes.
The individual field groups in the CCMS: Maintain Instance Data application contain important installation data and information on profiles and work processes.
To redistribute the work processes, you first have to select an operation mode. You then choose Instance, Maintain instance and Work process distribution. Here, you can change the number of background work processes by clicking the plus and minus pushbuttons. To do so, the cursor has to be positioned in this field. Reducing the number of background work processes automatically increases the number of dialog work processes. The total number of work processes remains the same. You then have to save your entries.
You can switch operation modes immediately if you do this manually. This enables you to adjust the number of different work processes in accordance with current requirements. Changes to work processes within the operation mode and timetable assignments have to be predefined first, however. To switch the operation mode immediately ( - if you do this automatically, the switchover does not take place until the next day), you have to go to the CCMS Control Panel. To do so, you enter transaction code /nRZ03 in the command field and confirm your entry. The CCMS Control Panel: Display Server Statuses and Alerts screen displays the operation mode which is currently assigned in the timetable. To switch to this new operation mode, you have to activate the instance name of the server. You can switch to the operation mode straight away by choosing Control, Switch, Operation mode and Selected servers. The Operation mode switching dialog box then displays the operation mode that has been assigned to the current time in the timetable. You then switch to the operation mode proposed for the selected server. The manual and immediate switchover to the new operation mode is then complete.
You can check at any time whether and when an operation mode changeover took place in your R/3 System. To do so, you enter transaction code /nSM21 in the command field of the initial screen and confirm your entry. In the System Log application, you can call up the analysis of the instance currently displayed. To do so, you enter a time period in the Selection field group for which all operating status data is to be exported. To start the read process, you click the Reread system log pushbutton. The individual columns of the System Log: Local analysis of HPLXPR02 screen provide information on actions that were carried out along with their respective times. The analysis table also indicates whether a dialog work process was converted to a background work process when the changeover was made to nighttime operation.
This lesson deals with printing in the R/3 System and looks at the spool work process. It also shows you how to create and change a printer in the R/3 System and how to administer spool requests.
In the R/3 System, documents are printed via a spool work process. Spooling refers to the transfer of data to output devices such as printers, fax machines, and so on. In distributed systems, networked administration is necessary for this purpose. The spool mechanism of the R/3 System can supply printers and external spoolers with print requests, both within an LAN and via WAN connections. Spool requests are generated during dialog processing or from background jobs and are placed in the spool database along with data on the printer and output format. The actual data is stored as temporary sequential objects (TemSe). When you want to print a document, a print request is generated for a spool request. This is then processed by a spool work process. After the spool work process has processed the print request, it returns it to the spool system of the appropriate operating system. This operating system spooler then manages the print queue and ensures that the desired data is transferred to the output device. As of Release 4.0A, several spool work processes (S WP) can be defined for each R/3 System. This means that a faster printer can be connected together with a spool work process for urgent printouts of up to three pages.
If you want to create a new printer for an R/3 System, you have to go to the Spool Administration: Initial Screen. To do so, you enter transaction code /nSPAD in the command field. To create a new device, you have to click the Output devices pushbutton in the Spool Administration: Initial Screen. The List of Output Devices application provides you with an overview of the device type, server, and location of all the devices configured up to now.
The Create Output Device screen requires you to enter certain data. You have to enter values in the input fields that contain a question mark. All other inputs are optional. After you have entered or chosen a new printer, you have to assign a name to it. You also have to specify the device class and define an access method for the host spool (default: L).
If you want to know whether the newly installed device is fully operational, you can generate a test printout of the screen list. To do so, you choose System, List, and Print. In the Print Screen List application, you specify the new printer as the output device. The status bar then displays the message Spool request.....created. This means that the generated print request was placed successfully in the print queue and is waiting there to be printed by the printer. In transaction SP01, you can check whether the test printout was completed successfully.
If you want to change the printer definitions for printers defined in the R/3 System, you first have to go to the Spool Administration: Initial Screen. To do so, you enter transaction code /nSPAD in the command field. In the Spool Administration: Initial Screen, you first of all have to switch to change mode. To change a device, you have to choose an output device. You can then change the device configuration data. After you have saved your data, it is made available to the R/3 System.
Access methods in the R/3 System are SAP-specific methods which the spool system uses to forward output data to the host spool system. When you create a printer, you have to choose an access method. A general distinction can be made between the control types local printing, remote printing, and frontend printing. A distinction is also made between the actual access methods in accordance with these control types.
With the local printing access method, the SAP spool work process forwards the processed output requests to the host spool system in the same host system. The data is forwarded from here to the printer which can be connected directly to the server or via the network. Depending on the operating system, a distinction is made between the access methods L and C in the R/3 System for local printing. Access method L can only be used for Unix systems. Here, the spool work process transfers a file to the Unix spool system using the system command Ip or Ipr. The data is then forwarded from here to the printer. Access method C on the other hand is used for Windows NT systems. Here, the Windows NT print manager is addressed directly via operating system calls. The print manager then forwards the data to the desired printer.
Remote printing refers to outputting data via a remote spool system. These access methods are known as U for Unix systems and S for other operating systems such as Windows and OS/2. The SAP spool work process forwards the processed output requests to the remote spool system of a different host system via a network connection. Alternatively, the requests can be forwarded to a network print server.
Access method F (frontend printing) allows you to output data on printers that are not defined in the R/3 System. With this access method, the dialog work process forwards the output requests to the program SAPLPD and then to the local Windows default printer of the frontend via the print manager.
A spool request is created each time data is output from the R/3 System. Information stored with each request can be displayed. You can also reprint or delete a spool request.
To display the data of spool requests, you first have to go to the Spool: Request Screen. To do so, you enter transaction code /nSP01 in the command field. In the Spool: Request Screen, the user name, date, and client have already been entered. If you want to display the spool requests for a certain period of time, you have to enter the start date in the appropriate input field. You then choose Goto and Overview. The Spool: Requests application displays all the spool requests that were created in the chosen period of time. It provides information on the spool number, the generation date and time, the output status, the pages, title, and spool request name.
To display or delete a specific spool request, you have to select the checkbox of the spool request in question. In the Spool request menu, you can choose Display, Print, or Delete.
In the Spool: Output Request application, you can specify various print parameters for the spool request. You change these settings if you want to print on a different output device, for example.
Every spool request that appears in this list can also be deleted. Before you can finally delete the selected spool request, an additional confirmation prompt appears.
This lesson explains what a background job actually is and shows you how to schedule, check, change, delete and cancel a background job.
Background jobs are a collection of one or several ABAP programs, external programs, or external commands. These are defined as individual steps and together represent a background job. Background jobs can run automatically in the background and support asynchronous processing. You can also process external data or mass data at times when the system workload is relatively low. Processing either takes place at certain predefined times or is event driven. Each server with defined background work processes has an integrated active background job scheduler which periodically checks the job scheduling table. Individual background jobs are stored here according to number, name, class, time, and target. The message server in the R/3 System manages a table of all the servers on which background work processes can be defined and background jobs can be processed.
All jobs are processed according to different priorities and are distributed to the individual servers. Priority criteria include the class and a possible target server defined for the job. Class A has the highest priority and class C the lowest. If jobs are in the same class, jobs with a defined target server are given priority over those with no target server.
If you want to schedule a background job in the R/3 System, you first have to go to the Define Background Job screen. To do so, you enter transaction code /nSM36 in the command field and confirm your entry.
In the Define Background Job screen, you can enter the job name, job class, and (if you wish) the target host on which this job is to run. Once you have completed all the fields, you can assign reports to the job, for example, by clicking the Steps pushbutton. In the Create Step 1 application, you can assign an ABAP program, an external command, or an external program to your job.
If you assign an ABAP program, you first have to enter a report in the Name field. If available, you can also choose a variant of the report via the Variant list pushbutton. You can assign a printer for each step. The step is then output on the printer specified. Once you have defined all the steps for a job, you have to call up the Define Background Job application again. Before a job is available in the system, you have to assign a start time to it. In the Start Time application, you can define various start times for the new job using the pushbuttons displayed. You can then save your report.
If you want to check whether a background job was carried out successfully, you have to go to the Select Background Jobs screen. To do so, you have to enter transaction code /nSM37 in the command field. In the Select Background Jobs screen, you can specify exactly which job you want to check for which user. You can also enter details on the start date and status of the chosen job. The next screen lists the background jobs according to the statuses Scheduled, Released, Ready, Active, Finished, or Cancelled. You can also call up the job log by clicking any of the background jobs. This allows you to analyze canceled jobs, for example, in greater detail. The Job Log shows you which steps of the jobs were carried out and when. The Message column displays messages on the various processing steps.
To cancel a released background job, you first have to go to the Select Background Jobs screen. To do so, you have to enter transaction code /nSM37 in the command field.
In the Select Background Jobs application, you can specify which jobs are to be processed for which users and for which period. In the Job Overview: Alphabetic screen, you can cancel a scheduled and released job, for example, or in other words reset it to the status Scheduled. To do so, you have to first select this job. To cancel this job, you choose Job and Schedule job. The status of the chosen job is now only Scheduled. You can also release scheduled jobs. To do so, you select a job and click the Release pushbutton. You then define the desired start date for the job. To delete a job, you have to select it. The job can then be deleted by opening the Job menu and choosing the appropriate option. To change a job, you first select it. You then choose Job and Change. In the Edit Job <Job name> application, you can change the job class for your job, for example.
This lesson explains the importance of backup strategies and shows you how to schedule and monitor backups. It also shows you how to check database consistency and introduces you to the administrative help offered by the system log.
One of the most important responsibilities of the system administrator involves creating regular backups of all company-specific, business-critical data entered in the R/3 System. To be able to do so, you need a carefully thought-out backup strategy. The correct backup strategy ensures that the R/3 System and the database can be stored in the event of a disk or system failure. The correct backup strategy also reduces the time during which data is lost in the R/3 System in the case of a recovery. The backup strategy allows a full backup to be carried out at least once a day, either online (for a database that is running) or offline (for a database that has been shut down). In this case, a backup of the entire database is made on tape. Archive log backups of the transaction log files should also be made once a day. Backups are also made here of the logs of all the changes made to the database since the last transaction log backup.
The backup strategy recommended by SAP is based on a backup cycle of 28 days (for 7 working days). Since each tape should only be used once in each cycle, you will need a total of 56 tapes per cycle. 28 of these are used for online and offline backups and 28 for the log backups. If online backups are performed on a daily basis, a full offline backup has to be made once per cycle. This backup is the only complete correct backup and should be stored in a safe place for one year. For each annual cycle you will require 67 tapes - 55 per cycle plus 12 for full offline backups.
To ensure that the data backups are consistent, you have to schedule various backup runs in the DBA planning calendar application. To do so, you enter transaction code /nDB13 in the command field.
In the DBA planning calendar screen, you can schedule various activities for each day of the week, including Sundays and public holidays. These activities are then performed at the specified time. If you want to schedule an online backup for Monday for example, you double-click a line in the field group of the desired day. In the Create a new action dialog box, you can choose the start time, the period, and an action. You can then determine the start time for the selected backup method. This should be the time taken for a full backup which is performed when the workload of the system is relatively low, in other words at night. You can then specify a period in weeks, after which the backup run is to be repeated. In the Volumes for database backups dialog box, you can define a generic volume name. The system also determines a valid tape automatically via the profile init<sapsid>.sap. The Options for database backup dialog box then proposes a profile for backup scheduling. All the tape names defined are stored in this profile, for example, and are exported from here. Using the procedure described, you can schedule the appropriate backup method for each day of the week.
If you want to check whether a backup was carried out correctly, you have to go to the Backup logs: Overview. To do so, you enter transaction code /nDB12 in the command field.
In the Backup logs: Overview, you can display information on database backups and archive log backups. You can call up information on the last database backup that was carried out successfully by clicking the Last successful database backup pushbutton. To the right of the first line, you can see the most important details on the last backup carried out. Return code: 0000 Success indicates a successful data backup. This overview of all the database backups provides you with information on the type of backup carried out as well as the start and end times.
If you want to display the archive log files for which backups have not yet been made, you click the Status of most recent redo logs pushbutton. The Backup logs: Redo history application contains a list of archive logs. The first line displays the active archive log file being written by the system. Other statuses indicated here are not saved or already saved.
If you require an overview of the archive log backups that were carried out recently, you click the Overview of all redo log backup logs pushbutton. By double-clicking a line in the Backup function column, you can call up the log files for individual backup procedures. The overview then displayed shows you which archive logs have already been saved in this backup run. If you click the Recovery report pushbutton, the system lists all of the database backups and archive log backups that were needed to fully restore the R/3 System after an error occurred.
The database consistency check is a very important part of database administration. Database consistency has a considerable effect on the executability of the R/3 System.
You check the consistency of a database in the Database performance: tables and indices application. You can go straight to this application by entering transaction code /nDB02. The individual field groups of the application you have called up provide you with information on the entire database system, the individual tablespaces as well as the tables and indices. The %-Used column of the View history of the database application provides you with the most important statistical information on the database system. This is where the current and historical used capacity values are displayed. To call up a more detailed overview of the daily changes made in the database, you can display the delta values and total values for the database. To do so, you have to choose the appropriate menu option in the Database history menu. The delta view of the statistical changes made in the database system provides details on how the free memory space, expressed in kilobytes, has changed. The display is summarized according to days, weeks, or months which means that you can detect any memory overflow in good time. To display the memory-critical tablespaces, you click the Freespace statistics pushbutton. The overview you have called up shows the tablespaces that the system has determined as critical objects. If you ignore these, they may cause the system to crash. Here, the next extension (indicated in the column Max next extent/kb) has to be smaller than the maximum contiguous free space available in the tablespace (indicated in the column Freespace Maximum/kb). If this is not the case, the tablespace should be expanded.
All important R/3 activities are recorded in the system log. If the R/3 System is not running correctly, the system log is the first place you should look. This log provides an instant overview of any errors that have occurred in the R/3 System.
The fastest way of calling up the System Log is to enter transaction code /nSM21. This transaction code takes you straight to the System Log initial screen, from which you can display the local analysis of an instance. For the local analyses of the system log, you can set restrictions for a certain period of time, for certain users, or for individual transaction codes, for example. You start the read process for the system log by clicking the Reread system log pushbutton in the lower application toolbar.
The System Log: Local analysis of XY application lists the system information according to time, task ID, client, user, transaction, message number, class ID, and short text. You can display more information on a particular message by double-clicking it. The details overview then lists more information on the development class and the module in question. The information in the problem class category is particularly important here as it helps you identify a system log entry relatively easily in the overview. The different colors used for the problem classes are also helpful: red (for problem classes K and T) indicates a critical situation, yellow (for problem class W) represents a warning, and gray (for problem classes S and X) provides information. Technical details on the messages are displayed as well. The System log menu also contains helpful sort functions with which you can structure the system log. Another very useful function is the string search which you can call up by choosing System log and Find string. Using this function you can search all the listed system log messages for a particular string.
A program written in the ABAP programming language. The two types of ABAP program used are:
Reports
Dialog programs
Connection type which has to be specified when you define a printer in the R/3 System. The access method determines how the spool request is sent to the printer.
This layer runs on a dedicated server and contains components such as the screen interpreter, ABAP dialog processor, dispatcher and work processes.
The update work process carries out changes to the database and is performed after the dialog work process.
An authorization profile is entered in the user master record and can be assigned to any number of users. The following types of authorization profile are supported:
o Single profiles (combination of profiles for a defined application)
o Composite profiles (combination of several single profiles)
A collection of one or several ABAP programs, external programs, or external commands which are executed sequentially without any user intervention.
Background jobs are, as the name suggests, executed in the background. While the data is being processed in the background, other functions are executed simultaneously on the screen.
The background job scheduler checks the job scheduling table at regular intervals. These intervals can be specified in the parameter rdisp/btctime (default setting is 60 seconds).
Process in which the input data for a program is first gathered together and then supplied to the computer so that it can be processed further. The user cannot intervene in this process.
A term used to refer to all the measures and mechanisms for protecting data and data carriers against loss or damage.
Storage area for temporarily storing data between the database and R/3 System. The times for accessing this data are, therefore, shorter and system performance is enhanced.
In commercial, organizational and technical terms, a self-contained unit in an R/3 System with separate master records and its own set of tables.
Link between a client and a server. The workload is divided up among the client and server.
DOS input prompt on Windows at which you can enter DOS and NT commands.
Operation that finally commits all database changes within an LUW (Logical Unit of Work) to the database. In the R/3 System, a database commit is triggered either automatically, by the ABAP keyword COMMIT WORK or the appropriate Native SQL command for the database system.
Ensures that the data in the database is consistent and does not conflict.
During the daytime, a large number of users are logged onto the R/3 System. This means that a sufficiently high number of dialog work processes have to be available (see also Nighttime Operation).
Profile that contains values which apply to all application servers. There is always one active default profile which, like all profiles, is defined in the R/3 global profile directory.
All developments, Customizing settings and system tests take place in the development environment. This environment is the original system for your ABAP Workbench objects and the integration system for your development classes.
Work process in which user requests are processed interactively.
Distributes requests among the work processes.
This work process is responsible for lock management. There is one enqueue work process for each R/3 System.
Work center from which you can access an R/3 System via a SAPGUI.
Service within the R/3 System which enables communication with systems outside R/3.
\usr\sap\ with the release name sapmnt. There is one global directory for each R/3 System. It contains, among other things, the R/3 program files.
Definition of logon groups within the SAPLOGON tool. Used for load distribution purposes in a system environment with several application servers. SAPLOGON is installed at the frontend when the SAPGUI is installed.
See Host Spool System.
Spool system at the operating system level of a server. Responsible for forwarding output data to the output devices.
An administrative unit that groups together components of an R/3 System that provide one or more services. These services are started and stopped at the same time. All components belonging to an instance are specified as parameters in a common instance profile. A central R/3 System consists of a single instance that includes all the necessary SAP services.
The instance profile contains application-server-specific configuration parameters which are used to complete the values of the default profile.
Chain of programs executed chronologically by particular control commands.
Defines priorities in accordance with which jobs are executed. Class A jobs have the highest priority, B jobs normal priority and C jobs the lowest priority.
Released jobs are entered here with a defined starting time. The jobs are then started at the appropriate times in conjunction with the job class and a defined target host.
The local area network is a transport medium used to transfer data between clients and servers at a particular location.
\usr\sap\ is the path for the local directory. On Windows NT, it has the release name saploc and exists once for each instance. The local directory contains instance-specific data and logs.
A term used to refer to the input dialog box for defining new users in the R/3 System.
Handles communication between several application servers. There is one message server for each R/3 System.
When defining operation modes in R/3, you make a general distinction between daytime and nighttime operation. During nighttime operation, there are usually fewer users logged onto the system, which means that the system has more capacity for processing background jobs.
Offline backups of the R/3 database are performed after it has been shut down. The R/3 System does not have to be stopped for this purpose. The database is then complete and consistent as is the offline backup. You cannot work in the R/3 System during an offline backup.
Online backups of the R/3 database are made while it is still running. This means that you can continue working while the backup is being executed. An online backup is only consistent in conjunction with transaction log files written during the backup.
Resource configuration for instances in the R/3 System. An operation mode defines the number of work processes for each service in an instance and the periods during which these services are available. The operation modes in the R/3 System support uninterrupted 24-hour operation and automatic switchover of the work process types.
Distinction between normal and exception operation.
Runs on clients usually in a Windows environment with SAPGUI at the frontend. Also referred to as the user interface of the R/3 System.
Environment in which real business processes of an enterprise are mapped and production data is entered.
Tested, stable development data and the Customizing object parameters are transported from the development/test system to the quality assurance environment at predefined times. This forms the basis for performing the final test in this system.
Directories created when the R/3 System is installed.
All the programs that are necessary for the R/3 System to operate correctly. They are also referred to as R/3 kernels and are located in the global directory in \usr\sap\<SAPSID>\sys\exe\run.
A term used to refer to the presentation, application and database layers from a hardware perspective.
Log files of the R/3 System which supply useful information when you are performing error searches.
Central storage facility for all development objects in the ABAP Workbench.
The R/3 work processes are also referred to collectively as R/3 services. A distinction is made here between application services and other additional services.
Group of all instances with the same SAPSID. Can be located on one or several servers.
The term recovery is used when the R/3 System has to be fully or partially restored.
An RDBMS is a management system based on a relational database. A relational database is a collection of tables which are linked to each other by means of relationships. The data is stored in tables.
A spool system at a remote location (not on the R/3 server).
Input/output fields that are identified by means of a question mark. Screens cannot be processed successfully unless you enter data in all required entry fields. In contrast to required entry fields, you can leave optional fields blank.
The SAPGUI combines the main elements of a graphical user interface. A graphical user interface consists of a menu bar with menu options, a standard toolbar, an application toolbar as well as functions and function key settings.
SAP tool which helps you work in a multi-system landscape. It is installed on the client when the SAPGUI is installed.
Operating system service on a server that collates and forwards data for analyzing performance in the R/3 System.
Software module that acts as part of a firewall system. The SAProuter simplifies network security and the routing of traffic to and from the R/3 System. It also establishes an indirect connection between the R/3 network and external networks. Access to the application layer between client software and the R/3 application server is restricted.
User-friendly tool for starting and stopping the R/3 System.
Screens (in the sense of a 'dynpro' or DYNamic PROgram) control the screen sequence in the R/3 System. The ABAP and screen interpreters together form the basis of the R/3 applications. The screen interpreter converts the source code so that it can be displayed in the appropriate form on the screen. Both interpreters are assigned to all background and dialog work processes.
Data station in a local network that performs particular functions in the network. Depending on the type, a server can:
o grant and withdraw authorizations (domain server)
o manage common data
o manage print outputs on a connected network printer (print server)
o manage all connections to the host (communications server)
Release name in a network under which other users or stations can access available resources.
Record created when information is sent to a printer or other output device. A spool request contains details about the request and a copy of the information.
The spool work process is responsible for buffering data to output devices. The data to be printed is entered in a spool request.
Set of parameter names used to automate startup or shutdown of an R/3 System on a network-wide basis. The start profile contains parameter settings that determine which application servers and associated processes (e.g. spool processes) are to be started when an R/3 System is started. The start profile is generated on the basis of a model profile supplied by SAP and the installer's specifications regarding the size of the host system.
Part of a background job. A step usually contains precisely one program or command.
Print output that takes place within a step.
Specific combination of systems as installed at a customer site. The system landscape could, for example, include a development system, a consolidation system, and a production system.
Log used to record errors and events in the R/3 System. The system log contains the most important information on program terminations, transaction terminations, database errors, and so on.
Monitor that controls the starting and stopping of instances and displays the instance status depending on the operation mode. It can also display the alert status and alert details of instances.
Logical storage area of a database which contains tables and indexes of the R/3 System. An R/3 database contains several tablespaces.
Transmission Control Protocol/Internet Protocol.
A network transport protocol which allows computers within a network to communicate with each other.
Table via which time intervals can be assigned to operation modes.
Logical process in the R/3 System. From the user's point of view, a transaction is a self-contained unit (e.g. generate a list of customers, change the address of a customer, book a flight reservation for a customer, execute a program). From a dialog programming point of view, a transaction is a complex object that consists of a module pool and screens, and can be called by specifying a transaction code. After logon, there are 3 distinct levels in the R/3 System: the main menu level, the application level and the task level. A transaction is a task performed at task level. To execute a transaction starting at main menu level, you either navigate through the menus by choosing the appropriate menu options, or you enter the appropriate 4-character transaction code in the command field and go straight to the task level.
Sequence of four alphanumeric characters that identify a transaction in the R/3 System. To call up a transaction, you enter the transaction code in the command field and press Enter.
Log which records the changes made to the database. Used to restore the database if this has to be recovered.
Part of an ABAP program in which the database is changed.
Creating new versions of objects that are stored in the database.
Communication via a wide area network (WAN). In contrast to an LAN, a WAN covers different locations which can be in different countries. These locations can be connected via cables or satellite.
The application services of the R/3 System handle special processes for:
o Dialog (for executing dialog programs)
o Update (for asynchronous database updates)
o Background (for executing background jobs)
o Enqueue (for executing lock operations)
o Spool (for print formatting)
Work processes can be assigned to dedicated application servers.
|
