In a SAP system, such as SAP R/3 Enterprise, the client/server architecture is one of the biggest characteristics that allow a system to be scalable and therefore, to grow and adjust to new needs whenever necessary. We can observe three different layers in this architecture, the presentation layer, the application layer and the database layer. This three-tier architecture can be a two-tier architecture or even a central system (one tier). Depending on the level of scalability and the resources that you require, you may choose one or another strategy.
The presentation layer would correspond to the user's PC, laptop, or presentation server. The database layer is where the database server can be found. The application layer consists on one or several application servers in which one or more SAP Instances is (are) installed and available to run ABAP or Java programs and communicate with other instances and systems. We may also install an instance on the database server. Instances are a very important resource in a SAP system and must be tuned for optimal response of a system and must be used and configured properly for optimal performance. In this topic, we will learn how to configure the work processes in the SAP instances, maintain profile parameters and distribute the workload for an efficient use of resources via different options, such as operation modes.
The SAP Instance
An Instance is a set of programs that start of stop at the same time. In the case of SAP R/3, a SAP R/3 Instance consists on programs called Work Processes, which are started and stopped all at the same time by a process named Dispatcher, the process "parent" of all the work process in an instance. There are several types of work processes and the number can be configured via parameter settings in the Instance Profile. Dialog work processes are used for interaction tasks with a user, while Background work processes can be used for batch processing "behind the scenes" without user interaction for longer processing programs to be executed at scheduled times. Any instance must have at least 2 dialog work processes. You can configure an instance with 0 to several background work processes.
Update work processes are dedicated to send update requests to the database in order to save changes in transactional data and spool work processes are in charge of output processing, such as printing or faxing from a SAP system. You may configure 0 to several update and spool work processes in any instance. The Enqueue Work Process allows to lock logically at the SAP level (not at the database level) with lock objects to avoid inconsistency and it is unique, so there is only one in each system in one of the instances. That instance will be called the Central Instance, while the others will be called "dialog" instances. Few exceptions may allow more than one Enqueue work process, but only do so when SAP recommends it and follow SAP's instructions.
It is very common to see the central instance installed in the same server as the database when you do not have a standalone database server and distribute user workload across all the dialog instances, reserving the central instance for only a few administrative tasks without allowing end user access. The maximum number of work process configured in an instance will depend on your resources. Since hardware resources are limited, so the number of work processes is. For advice on how many work process to configure, please check SAP Note 39412.
In addition to the aforementioned work processes, there are two more services that allow communication with other instances and systems: the Message Server (which allows a Dispatcher from one instance to communicate to other dispatchers) and the Gateway (which can be seen as a communication pipe to send requests and calls to other systems and applications). In SAP R/3 Enterprise, with the underlying Web Application Server, there is a new process that allows communication with the Internet, the Internet Communication Manager (ICM). This new service is necessary to ensure proper communication between the SAP system and other Web services, systems, or applications that use HTTP, HTTPS, or SMTP protocols. It can be monitored separately with the ICM Monitor, although it is started by the dispatcher, as all the other services or work processes. And just as the other work processes, the ICM must be configured via parameter settings.
Transaction SM50, the work process monitor, helps you to monitor the work process of every instance separately (running SM50 separately in each instance), whereas SM66 allows you to have a system wide view of the work processes across all instances. If your online users experience wait times or if you observe high average wait time in the Workload Analysis Monitor, it may be due to a lack of work processes. Similarly to the lack of work processes, if the workload for the ICM is too high, you may see that in SMICM the indicator for the threads "peak" is reaching maximum. In addition, statistics on processing times can be seen under Goto | Statistics | Display. For additional troubleshooting of the ICM, remember to review the Online Help documentation.
The parameter settings that control the number and behavior of the work processes and ICM are set in the instance profile. For the ICM you can display the parameters in the ICM Monitor via transaction SMICM and choosing Goto | Parameters | Change. Observe that some parameters can be changed dynamically right there, but the ones that are grayed out cannot be changed dynamically. Finally, each instance has associated a set of R/3 buffers (tables, programs, calendar, screen, CUA objects, etc.) that allow temporary storage for faster data access and program execution. The size and configuration of the SAP buffers are also managed in the instance profile. The buffer configuration is important for optimal performance and distributing the workload efficiently helps to make an efficient use of the available resources.
The SAP Profiles for Parameter Settings
A SAP system needs three files to configure parameter settings related to the SAP Instances and to start them. These are files that can be edited at the operating system level or from the SAP system via transaction RZ10 (menu path Tools | CCMS | Configuration | Profile Maintenance) and you can display individually each parameter with documentation in RZ11. The convention naming is important, and so it is to maintain the values in the appropriate range to avoid problems starting up the instances, for example.
The three files (profiles) to maintain are as follows:
When you change these profiles from transaction RZ10, the system keeps track of all previous versions, so you could always go back to a previous version of the profile, if something went wrong changing a profile and you were unsure of what changes you made. There are three levels of modification:
When modifying a profile, the system will automatically include a comment in the file indicating the date, time, user ID of who did the modification, and what the old value of the parameter was. When finished editing a profile, select Profile | Save or click the Save icon to store the profile in the database. When saving profiles, the system automatically performs a consistency check. If you want the profile parameters of an edited profile to be effective the next time an instance is restarted, you have to transfer the modified profile to the operating system level. You do this by selecting from the menu Profile | Activate, although commonly the system will automatically request you to activate the profile after it has been saved.
At any time, but especially after importing or modifying any of the system profiles, you should check the consistency of the profiles. This check includes from spell checking to verifying all the imposed conditions on parameters. When the SAP system checks a profile it also checks that all profiles are consistent among themselves; for example, it would riot allow two different message servers in different profiles. To check the consistency of any profile, from the main screen, select the profile and version and click on the Check icon, or, from the menu, select Profile | Check.
When an application server is started, the system checks that the profile information stored in the database matches that of the operating system files. If there are differences, the alert monitor will display an alert message. You can always check and compare the profiles against the file on the operating system by entering the profile name in the input field and selecting from the menu Utilities | Check All Profiles | Of Active Server. Or you can compare against the profiles in the operation modes by selecting the menu option Utilities | Check All Profiles | In Operation Modes. Also, you can compare the selected profile in the profile name input field with the active profile by selecting Profile | Comparisons | Profile in Database | With Active Profile.
When a profile has been modified at the operating system level or a new dialog instance has been installed, you should import the new profiles, so that they are modifiable from the SAP system. To do so, enter the name of the profile and click on the Create icon, or select Profile | Create from the menu. The system presents the initial screen for entering the administration data, such as the description, the profile type, the filename (include the whole path), and the reference server. Enter the requested information and save your inputs.
The system transfers the data to the database. Then proceed by selecting Profile | Import on the basic profile maintenance transaction screen. The system displays a dialog box where you have to specify the profile file at the operating system level. To display the available files, click on the possible entries list arrow. The values for the profile will be transferred and checked for errors. You can now edit the profile and save it into the database. You can also use the copy function to make a copy for another profile with similar values.
Finally, you have two options to delete profiles from the database:
The system will remove the entries from the database and will display a dialog box requesting whether you also want to delete the files at the operating system level. Tip To obtain a list of all parameters defined in the system and their values, execute program RSPARAM with transaction SE38.
Working with Workload Distribution
Now that you know how to configure the SAP instances, we will give you some tips and suggestions on workload distribution. It is important to balance the workload in your system to achieve optimal response and system performance. Workload in a system can be defined in many different ways and that is why there are also different tuning mechanisms to balance it. The number and the type of users influence and are part of the workload. The number and type of programs and transactions that are executed online, in background, via RFC, ALE, Web communication, and so on are also workload.
Resources are hardware (memory, CPU, number of servers, network,...) and software (number and type of work processes, memory configuration, system settings,...), and the better the workload is distributed among all the available resources, the better the system's response will be.
Workload Distribution among Application Servers
It is possible to analyze the distribution of the workload in a SAP system by choosing Load Distribution | Instance Comparison from the Workload Analysis Monitor. Moreover, you can also check the users that are logged in an instance with Load Distribution | Users per Instance. That way you can observe if the response time of one application server is very different from another and if one instance is busier and more loaded of users than another. In order to make the most out of your resources, try to balance the workload among all available application servers.
To achieve this, you may use Logon Groups. You can configure Logon Groups with transaction SMLG. However, it is important to consider that if resources are limited (memory, in particular), the way that users are distributed among application servers may influence R/3 buffer utilization. You may encounter many buffer swaps in some of all instances, due to an inefficient distribution of users. This may affect negatively performance is those servers, although the user workload is evenly distributed among all the available application servers.
To avoid this situation, it is best practice to join users that use the same tables and programs in the same logon groups, making the most out of your resources that way. Just as an example, SD and MM users fit well together, because they access the same tables and programs (logistics), due to the integration between modules, and do not compete for resources, as well as FI and CO users (financials).There are other possible workload distribution criteria that could be taken into consideration, such as language, country, company, Internet users, and so on.
Working with Operation Modes
Operation modes are the way the R/3 system allows for flexible configuration of the available work processes across the system for optimal utilization of the system resources. With operation modes, you can define how many work processes of each type will be available in which mode of operation that you define and the system can automatically switch from one to another operation mode at your defined scheduled switch time. When an operation mode switch takes place, there is no need to restart the instances (even though you will see that automatically certain work processes change from one type to another!).
In order to go to the main screen of Operation Modes maintenance, execute transaction RZ04 or follow the menu path Tools | CCMS | Configuration | Operation Modes/ Instances. Operation modes are defined at the instance level, so an instance is assigned to one or several operation modes. To configure an operation mode, the instance profiles must be correctly set up, because the operation modes will use the instance and start profile information for performing their tasks. If you have not defined any operation mode yet, the system shows the <DUMMY> operation mode, which is a nonproductive operation mode.
To create an operation mode, click on the Create icon in the Operation Modes maintenance screen. Enter the name and a short description for the operation mode in the provided input fields. New in SAP R/3 Enterprise, by choosing a Monitoring Properties Variant, you may add this operation mode to the alert monitor. Now you are ready to assign the new operation mode to an instance. If you click the Instances/Profiles button while in the initial screen CCMS: Maintain Operation Modes and Instances, the system shows the instances to which different operation modes are assigned (in the operation mode view). To create a new instance, select Profile | Create New Instance or click on the Create icon.
Enter the server name of the instance, the START and Instance profile name. By selecting Administration User for Start/Stop, you can additionally configure the user data for starting or stopping the instance. Next, click on the Save icon on the standard toolbar, or select Instance | Save. The system will save the instance data and check the configuration. Once the information is confirmed, and only when creating the instance for the first time, the system displays a dialog box CCMS: Maintain Work Process Distribution, where you select an operation mode (for example, Day) to assign the instance and maintain the work process distribution.
Note that you can only use the + and - icons to add or subtract work processes of each type and that when you add a background work process, for example, one less dialog work process will be available and shown in the distribution. The total number of work processes in that instance or across the system cannot be modified, though! You must "play" with the available configure total number of work processes. You can also choose another operation mode by clicking on Other Operation Mode (for example, Night) and repeat the same operation. The system now displays the list of operation modes for every active instance with information about the number and type of work processes assigned to them.
Operation modes and work process distribution in a SAP R/3 system
Note that the total number, under the Sum column, should be the same for a single instance, regardless of the operation mode, because, as mentioned previously, the total number of work processes cannot be changed dynamically. In addition, to assign a different operation mode at any time, click on one of the lines in the list of operation modes, and from the menu select Instance | Maintain Instance | WP Distribution. The system will display a new window to define the work process distribution for the instance, like before. Notice that the system includes the * to indicate operation mode independent.
Finally, notice that the number of spool processes cannot be changed and that the number of update work processes (both V1 and V2) can be increased or decreased as needed but cannot be set to 0. If an instance does have update processes configured, then you cannot make that number 0. 1t would first have to be defined on the instance profile that you do not wish update work processes in that instance by setting the corresponding parameter setting. Enqueue work processes should be left normally unchanged. Only one of the instances offers the enqueue service. If the instance has an enqueue process, it can be changed under certain limitations (1 to n or n to 1) but can never be set to 0. Only modify this value, if instructed by SAP.
The next step is to configure the timetable for operation mode switch. Execute transaction SM63 or follow the menu path Tools | CCMS | Configuration | Operation Mode Calendar. Choose between Normal operation, which defines 24-hour cycles for the operation modes, and the Switches or Exception operation, which allows you to define an exceptional time period for the activation of an operation mode. This mode will only be executed once in the specified date and time interval. By default, the system displays 1- hour intervals, but you can change the intervals to smaller periods from the Edit | Time Period menu when in maintenance mode. You must define the whole 24-hour range and you cannot leave any time period unassigned for operation modes to work.
24-hour Normal operation schedule in a SAP R/3 system
SAP BASIS Related Interview Questions
|SAP CRM Interview Questions||SAP HR Interview Questions|
|SAP ABAP Interview Questions||SAP HANA Interview Questions|
|SAP Crystal Reports Interview Questions||SAP SOLMAN Interview Questions|
|SAP Security Interview Questions||SAP BPC Interview Questions|
|SAP Netweaver Interview Questions||SAP UI5 Interview Questions|
|SAP Smart Forms Interview Questions|
Sap Basis Tutorial
Sap: From Sap R/3 To Sap Netweaver
The Architecture Of The Sap Web Application Server
Sap Netweaver: An Overview
Using Sap Systems
Upgrading To Sap R/3 Enterprise: The First Step Into Sap Netweaver
The Change And Transport System
Development Options With Sap Solutions: Abap Engine
User Management And Security In Sap Environments
Web Application Server System Management
Performance And Troubleshooting With Sap Solutions
Sap For It Managers: Implementation, Planning, Operation, And Support Of Sap Systems
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.