# Distributing SAP Systems and Services SAP BASIS

SAP provides the tools needed to configure a distribution to achieve a consistent optimal performance. The system administrator uses these tools to tailor the distribution for the specific needs of clients. For example, the system administrator is able to create logon load balancing that enables the system to automatically select the most efficient instance server based on current operating performance and usage. In this section, you'll learn how to use dynamic load balancing and other tools to make your SAP system and services custom perform for your distribution.

Instance Profiles

A profile in the SAP system is an operating system file containing parameters and configuration information of an instance. Because a SAP system might contain from one to several instances, many profiles may also exist.
Individual setup parameters can be customized to the requirements of each instance. The profiles are an essential part of technical and basis settings of the system, and the values they contain play the most important role when tuning the system. The profiles are used when starting and stopping the system because they are in charge of allocating or deallocating the necessary resources as specified in the profile parameters. These individual parameters let you customize the following:

• The runtime environment of the instance (resources such as main memory size, shared memory, roll size)
• Which services are available for the instance (which work processes and how many)
• Where other services are located (database host, message server, etc.)

The profile files are located under the directory /usr/sap/<SID>/SYS/profile (logically should point to the directory /sapmnt/<SID>/profile), which is shared by all application servers belonging to the same SAP system (same SID). These profile files are text files that are structured in the following ways:

• The comment lines are preceded by a # sign, for example, # Parameters corresponding to dispatcher functions.
• There are lines with parameter value with the syntax parameter = value.

For example, the number of background work processes running in this instance is rdisp/wp_no_btc = 4. Usually, parameters belonging to a group of logically related functions are prefixed by a common root (in the preceding example, the rdisp/prefix controls the group of dispatcher parameters within an instance). All host computers in an SAP R/3 system can access these profiles. It is possible for several Web AS instances to use a single profile simultaneously. Separate profiles are not required for each Web AS instance.

Profiles can be edited and maintained manually using the sappad editor, which can be very useful if the system cannot start because of some error in parameters. However, it is strongly recommended that all profile maintenance be performed from within SAP R/3 using the transaction RZ10 (Edit Profiles), which is part of the Computer Center Management System (CCMS). An edited profile is not active (its values are not considered by the system) until the corresponding instance is restarted.

Profile Types

There are several types of profiles available on the SAP R/3 system for correct setup and configuration. These profiles are as follows:

• The start profile, which defines the SAP R/3 services to start. There might be as many start profiles as instances.
• The default profile, which acts as a common configuration of profile values for instances taking part of the SAP system. There is only one default profile in a SAP system.
• The instance profile, which contains specific instance parameter values. There might be as many as the number of instances.

All the SAP profiles are located under a common directory, /usr/sap/<SID>/SYS/ profile, shared by all instances belonging to the same SID. Before continuing with the profile types, there are a couple of interesting topics common to profiles: how the variables are handled in the profiles and what the actual value assigned to a SAP parameter is, considering that it can either be in the default profile, the instance profile, or no profile.

Variables Substitution in the Profiles

The SAP profiles include some syntax rules used when substituting parameter values using variables. These rules are very similar to the ones used in normal shell script commands. The parameter values in the profiles can include the following variables:

• $(parameter_name) at runtime is substituted by the value of the parameter specified in parentheses. For example, • global_dir_param = '/usr/sap/DD1/SYS/global' • syslog_param =$(global_dir_param)/SLOGJ

Therefore, syslog_param = /usr/sap/DD1/SYS/global/SLOGJ

• $$is replaced by the SAP system number. For example, • rslg/collect_daemon/talk_port = 13$$ and the SAP system number is 00, then rslg/collect_daemon/talk_port = 1300

The profiles might also include some local substitute variables. These variables only have an effect within the profiles and are not used by the SAP programs. The names of the local variables always begin with an underscore (_) sign and are mainly used for setting other parameter values. For example, if

• _EXEDIR = /usr/sap/DD1/SYS/exe/run and
• myparam = _EXEDIR

then

• myparam = /usr/sap/DD1/SYS/exe/run

The Values of the Profile Parameters

The parameter values that influence the way the Web AS system allocates resources or services can be set either in the default profile, in the instances profiles, in both at the same time, or in none of them. The SAP profile parameters are read by the startup program to assign the needed resources to the SAP processes. The parameter values are set by following these rules:

• If a specific parameter appears in the instance profile, this value is the preferred one used by the SAP processes.
• If the parameter is not included in the instance profile, then the system checks whether it is contained in the default profile. If it is there, then the system takes this value for the SAP processes.
• If the parameter is not in any of the profiles, then the default value from the source program code is assumed.

Administrators should ensure that the parameters do not appear in both profiles at the same time on occasions where that's not needed. There are, however, situations where it is convenient to have a particular parameter in the default profile and also in some instance profiles. For example, suppose you want to set the default login language to English in all instances but two, which belong to the Italian subsidiary. In this case, you can set the parameter for the language in the default profile as English and set the system login language parameter to Italian in the two instances to use Italian as the preferred language. To see a list of all profile parameters in a SAP instance, you can run the standard SAP report, RSPARAM or RSPFPAR. To do so, select System | _Services | _Reporting from any Web AS window, enter RSPARAM or RSPFPAR in the program input field, and press the Execute button. You get a long report list, which should be sent to the printer to see it in full because it usually does not fit on the screen.

Start Profile

The start profile is an operating system file that defines which Web AS services are started. The start profile is a parameter file that is read by the startsap program. Among the services that the start profile can initiate are the message server, the gateway, dialog, enqueue, system log collector and log sender programs, or any other locally defined program. The start profile is located under the / usr/sap/ <SID>/ profile directory. These profiles are generated automatically by SAP when the system is first installed. Depending on the release version, the names assigned are either START _<instance _name> or START _<instance _name> _<hostname>; for example, START _DVEBMGS00, START _D01 _copi02, where DVEBMGS00 and D01 are instance names and copi02 is the hostname of instance D01. The start profile includes some general system variables, which are substituted by their real values at runtime, such as the following:

• SAPSYSTEMNAME, which is substituted by the name of the SAP R/3 system. For example, DD1 as shown in the previous listing.
• INSTANCE_NAME is the variable for the name of the SAP R/3 instance. For example, DVEBMGS00.

Besides those general SAP system parameters, the start profile only allows for some specific parameter names and syntax. Those permitted parameters are as follows:

• Execute_xx, where xx can go from 00 to 99. These lines can be used to start operating system programs or commands to prepare the Web AS system for start. For example, this parameter can be used to set up logical links to the executable programs on the UNIX platforms.
• Start_Program_xx, where xx can go from 00 to 99. This parameter is used to start the Web AS instances services in an application server.
• Stop_Program_xx, where xx can go from 00 to 99. Know the meaning of this parameter because the word stop can be confusing. This parameter is used to start an operating system program, command, or SAP program after the Web AS instance is stopped, for example, running the program that stops the saposcol, the saprouter, or the cleaning of shared memory areas that were being used by the Web AS system.

The number xx defines the sequence of execution. The programs specified in Execute lines are the first executed. Then the system starts the programs included in the Start_Program parameters. After the specific SAP instance is stopped, then the programs specified in the Stop_Program parameters are started. To the right of the equal sign in the three preceding parameters, SAP allows for theexecution of local programs (located in the same server) or remote programs (located in a remotely connected server). Programs running on the local server are preceded by the word local in the parameter value. In the previous listing you can see that all the lines are preceded by the local keyword. To run programs on a remote host instead of the local host, the parameter values must be preceded by the remote hostname. For example, Execute_00 = copi01 saposcol, where copi01 is a remote hostname and saposcol the name of the program to execute.

Default Profile

The SAP default profile is an operating system file that contains parameter values used by all application servers from the same SAP system. The name for this profile cannot be changed. It is always called DEFAULT.PFL. The default profile, like all other profiles, is located in the common profile directory of the SAP R/3 system: /usr/sap/<SID>/SYS/profile.

There is always one active default profile. Default profiles are also called system profiles. The profile parameters included in the default profile are meant for those values that either are unique in the system, and therefore are the same for all instances, or to enter global parameters to be shared by all instances. Examples of such parameters are the hostname of the database server, the message server, and so forth.

Figure shows the same parameter file as seen from CCMS. The default profile is generated automatically by the system when this is first installed. It includes the usual parameters.

Default profile as seen from the CCMS utility (Copyright by SAP AG)

System administrators can modify or add to the default profile and include any other SAP parameter from the CCMS tool. For new parameters to have effect, the profile has to be activated and all instances belonging to the same SAP system must be restarted.

Instance Profiles

The instance profiles are the third type of profiles and are very important for providing the SAP instances with lots of parameters that directly affect the configuration and resources for the application servers.
The instance parameters typically define how many and what type of work processes are to be started for an instance. They also define the amount of shared memory, theallocation of buffer space and related pools, the instance default login language, and so forth. Parameters set in the instance profiles have precedence over the same ones defined in the default profile. Instance profiles are automatically generated by the R3 setup utility when an instance (dialog or central) is installed. By default, the name assigned to them has the format <SID> _<instancename> or <SID>_<instancename>_<hostname>, but you can choose any name for them. If you choose a different name than the standard, you should modify accordingly the start profiles to reflect the new names.

It is also possible to use the same instance profile to start SAP instances on different computers. In this case, make sure that the hardware resources available are the same or very similar. You cannot allocate more memory in an instance profile than the actual available memory in the server.

Profiles Maintenance

You should only edit the profiles from the SAP R/3 system using the CCMS profile maintenance tool. Figure shows one screen of the maintenance tools in display mode.

Only edit SAP R/3 system profiles using the CCMS profile maintenance tool (Copyright by SAP AG)

User Distribution: Logon Load Balancing and the SAP Logon Utility

SAP provides utilities to configure and efficiently divide the system load among the available servers. The load balancing is provided dynamically. For example, you can define the number of total users allowed to log on in a particular instance and the response time threshold for that instance. With those values the system will decide upon a user logon request which is the bestapplication server for the user to log on. The process of configuring logon balancing involves two tasks:

1. Configuring the logon groups, which is accomplished from the CCMS utilities within the Web AS system
2. Installing and configuring the SAP logon Windows application in every workstation that is going to log on to the Web AS system

Logon Groups Configuration

System administrators can centrally configure several logon groups containing one or more application instances. When users log on in a defined group, the system automatically selects the instance server, according to the best performance and the number of connected users. Configuring logon groups is not only meant to balance the load; when enough instances are defined it is also a good way to provide higher system availability for users. For example, suppose you have a SAP installation with one database server and seven application servers running one SAP instance each. Your installation has 400 concurrent users from the SAP application modules: FI, MM, SD, and CO. Every module has 100 users. However, SAP modules support different transactional loads. It's well known that an average SD transaction can be about three times as demanding as an average FI transaction. If you define the following groups:

• Group FI/CO, pointing to application servers 1, 2, and 3
• Group MM, pointing to application servers 4, 5, and 6
• Group SD, pointing to application servers 4, 5, 6, and 7 you get the following advantages:
• If an application server goes down for any reason (hardware error, maintenance, etc.) users can still connect to the group, which will assign the best application server.
• Setting groups of related applications (MM and SD are related, as well as FI and CO) makes a better use of the instance buffers and shared memory because the probability of having the same called programs or tables in the buffers is high.

In the preceding example, application server 7 is only assigned to SD users because it is the most demanding module among those applications and also because you can configure this server to allow a smaller number of users with the most time-critical work, for instance, printing invoices, getting orders, and so on. Other very demanding SAP application modules are PP (production planning) or PS (project system). To log on to the SAP R/3 system, users only need to know the SID of the R/3 system and the name of the logon group. They don't need to specify the hostname or system numbers of the SAP instances.

To create a logon group, from the main menu, select Tools | _CCMS | Configuration | _Logon Groups. Or enter transaction code SMLG in the command field. This procedure can be done while the SAP R/3 system is running normally; there is no need to stop it. If there are no logon groups defined yet, the system displays a window with just the name of the current instance. If there are groups already set, then it displays a list with the group names, the SAP instances, and the status of the instances. To create or edit a logon group, click the Create Entry button on the application toolbar. The system displays the Create Assignment window, like the one. If you only see the first two fields, press the right arrow button to see the remaining fields.

Creating entry dialog box for logon groups (Copyright by SAP AG)

On this screen, you can enter

• Logon group. Enter a name for the logon group to be defined. Use a name that can be easily understood. For example, for SD users, set something like "SD group," "SD module," or "Sales." If there were previously created groups, you can click on the possible entries arrow to display or select a group.
• Instance. Enter at least one instance for a group. Clicking on the possible entries arrow displays the available SAP instances defined in the system. To get information about a particular logon group, double-click on any line where the group appears. The > button is useful both for editing and displaying the load limit information about a logon group and instance.

The screen is extended showing the response time and number of users limit set for that instance in the logon group. These fields are not mandatory; you can leave them blank if you don't want to set any restriction on that group or instance. But if the response time has been defined for a group in a particular instance, then you have to define a response time limit for every group using the same instance. When all the information is entered, press the Copy button to save your entries. Define at least another instance for the same logon group. Having a single instance in a group does not make much sense from the point of view of load balancing. It would be the same as logging in with the normal SAP GUI pointing to the hostname and instance number.

From the main logon load balancing screen, administrators can monitor the load of the groups and the users connected. To do this, select Goto | Load Distribution from the menu. The system displays a list with an overview of the current load, showing the performance status of the instances assigned to logon groups. Each application server writes its performance statistics to a memory resident table on the message server every five minutes. If you want to refresh the performance status of any application server, just double-click on the line. To see the users currently logged on, select Goto | User List from the menu.

0