Introduction:
LOGON groups are used to automatically distribute user logons to individual instances (application servers) or to groups of SAP instances.
The idea behind this is that a user does not logon to a special instance but rather logos on to a so-called LOGON group & is then logged on to the relevant instance with the lowest load (that is, the best average response time).
This procedure are having the following advantages –
- Users are no longer tied down to individual instances which might possibly become overloaded.
- Since users now log on to logical LOGON groups and not to physical instances, instances can be exchanged or created within a group without SAPGuis having to be reconfigured.
LOGON group maintenance
LOGON group maintenance and configuration can be carried out using transaction SMLG (Tools -> Administration -> Computer Center -> Management System -> Configuration -> LOGON Groups).
For a system having 4 or less than 4 instances, a common group may be used for all instances. The LOGON group name can be PUBLIC.
For the system having large number of instances (may be more than 4) it makes sense to distribute users for each specific application to two or more instances depending on the requirement.
For example,
Instance Group
Appl1_PRD_00 FI-Users
Appl2_PRD_00 FI-Users
Appl3_PRD_00 SD-Users
Appl4_PRD_00 SD-Users
Appl5_PRD_00 CO-Users
Appl6_PRD_00 SD-Users
Appl7_PRD_00 MM-Users
One or more logon groups are set up for several instances. Several groups can be allocated to the same instances.
In this case, the users of a LOGON group are distributed in such a way that the load on each of relevant instances is as little as possible. If only a limited of users are to be allowed access to instances, or if a predefined average response time may not be exceeded, then maximum values
can be entered for the number of users or for the average response time. The optional definition of these values guarantees as much as possible that users are only logged on to the instance if the limiting values are not exceeded. However, the definition of limiting values does not prevent users from logging on to the instance directly. It is also possible to log on to an instance with exceeded threshold values if all of the instances available for the LOGON group in question were also defined with limiting values and these were subjected to a relatively greater load.
Example:
Instance Group Max. no. users Max. av. resp. time
app1_PRD_00 FI Users 20 1500
app1_PRD_00 SD Users 20 1500
app1_PRD_00 Administration 20 1500
app2_PRD_00 FI Users
app2_PRD_00 CO Users
app3_PRD_00 SD Users
Note: The definition of limiting values is optional and processed in the background (standard system default). You can carry this out in the foreground via: Group list -> Format -> Enhanced in the overview list. This can be displayed in the input dialog boxes by pressing the key '>>'. Limiting values must always be kept uniformly for each instance (this is regulated automatically by the maintenance transaction SMLG) since the average response time or the number of users can only be calculated globally for each instance and not for user of a specific group. In other words, the limiting values apply to one instance, regardless of group, but at the same time, can be set up differently for the same group for another instance. However, in most cases, it is unnecessary to specify limiting values since the sole aim is to achieve an even distribution of users with regard to system load.
Groups are set up for only one instance, but several groups can be allocated to an instance. The distribution of user logons resulting from this configuration is not dependent on the system load. That is why it does not make sense to define limiting values for user number or average response time either. The disadvantage of this is that if an instance is not available an alternative instance is not automatically provided. The group definition must then be changed so that the logons of the group affected are redirected to other instances.
Example:
Instance Group
app1_PRD_00 FI Users
app2_PRD_00 CO Users
app3_PRD_00 Administration