So, What are user groups and how can we use them?

Transaction SUGR is used for User Groups.

User group can be used for different reasons and in different way.

In the latest versions of SAP, there are two types of usergroups

The authorization user group &
The general user groups

Naturally the main reason of user groups is to categorize user into a common denominator.

The authorization user group is used in conjunction with S_USER_GROUP authorization object. It allows to create security management authorization by user group. e.g. you can have a local security administrator only able to manage users in his groups, Help-Desk to reset password for all users except users in some group.

The general user group can be used in conjunction with SUIM and SU10, to select all the users in a specific group. User can only be member of one authorization user group but several general user group.

One of the Primary uses of user groups is to sort users into logical groups.

This allows users to be categorised in a method that is not dependent on roles and Responsibilities and Profiles.

User Groups also allow segregation of user maintenance, this is especially useful in a large organization as you can control who your user admin team can maintain – an example would be giving a team leader the authority to change passwords for users in their team.

Why, just because we can!

If you want the user to be locked after unsuccessful logon attempts, you can put a parameter in the Instance Profile to prevent them from doing so.

Transaction RZ10–> Instance Profile–> Extended Maintenance

Use the ‘login/fails_to_user_lock’ Parameter.
Defines the number of unsuccessful logon attempts before the system locks the user. By default, the lock applies until midnight.

Default value: 12; permissible values: 1 -99

To remove the lock after midnight :
login/failed_user_auto_unlock: Defines whether user locks due to unsuccessful logon attempts should be automatically removed at midnight.

Default value: 1 (Lock applies only on same day); permissible values: 0, 1

rdisp/vbname: Specifies the name of the update server that is to process the updates if load balancing is deactivated ( rdisp/vb_dispatching = 0 ).

In the standard system, this parameter specifies the name of an update server (set when the update server is created). If rdisp/vb_dispatching is set to 0, the updates are only processed by the server in rdisp/vbname.

rdisp/vb_delete_after_execution:Determines whether update records are deleted automatically after they have been processed successfully.

In the standard system, this is set to 1 (automatic deletion activated).

If set to 2, automatic deletion is deactivated. This value can be used to set the update and database performance. In this case, the report rsm13002 with the parameter DELETE = X should run in the background at least once a day to prevent the update tables from becoming excessively large. See also the section entitled Structure link Background Processing in the CCMS documentation.

rdisp/max_vb_server: Maximum number of update servers permitted in the SAP System. Default = 50 servers.

rdisp/vb_included_server:List of the SAP update servers, which are to be used to process updates in accordance with the load balancing principle. No updates are assigned to update servers that do not appear in the list.

This parameter is empty in the standard system. This means that all active update servers are taken into consideration for the load balancing mechanism. This is generally speaking the optimum value.

rdisp/vbdelete:Specifies the number of days after which the update records are deleted. The parameter is set to 50 days in the standard system.

Once this interval has expired, an update record is deleted irrespective of its status (processed, not processed, error etc.).

If set to 0, automatic deletion is deactivated. This value should only be set temporarily, and only if an incorrect update record is to be kept for further analysis.

You may get the above error when trying to login to ITS or setting up the URL for HTTP Connect – URLAccess

http://<server_name>:8000/sap/bc/gui/sap/its/webgui?sap-client=nnn

Primary problem is that the memory parameter em/global_area_MB has not been set correctly or is not high enough for ITS. Use the following note to calculate it or just set it to 360 to start with.

Note 742048 – Integrated ITS, memory requirement in application server

Complete error message was:
Error when processing your request

What has happened?

The URL http://server:8000/sap/bc/gui/sap/its/webgui was not called due to an error.

Note

* The following error text was processed in the system SID : New session was refused due to memory bottleneck

* The error occurred on the application server server_SID_00 and in the work process 0 .

* The termination type was: ABORT_MESSAGE_STATE

* The ABAP call stack was:
Function: ICF_ATTACH_ITS_PLUGIN of program SAPLHTTP_RUNTIME
Method: EXECUTE_REQUEST of program CL_HTTP_SERVER================CP
Function: HTTP_DISPATCH_REQUEST of program SAPLHTTP_RUNTIME
Module: %_HTTP_START of program SAPMHTTP

What can I do?

* If the termination type was RABAX_STATE, then you can find more information on the cause of the termination in the system SID in transaction ST22.

* If the termination type was ABORT_MESSAGE_STATE, then you can find more information on the cause of the termination on the application server server_SID_00 in transaction SM21.

* If the termination type was ERROR_MESSAGE_STATE, then you can search for more information in the trace file for the work process 0 in transaction ST11 on the application server server_SID_00 . In some situations, you may also need to analyze the trace files of other work processes.

* If you do not yet have a user ID, contact your system administrator.

Error code: ICF-IE-http -c: 300 -u: USER -l: E -s: SID -i: server_SID_00 -w: 0 -d: 20100112 -t: 121110 -v: ABORT_MESSAGE_STATE -e: New session was refused due to memory bottleneck

HTTP 500 – Internal Server Error

Your SAP Internet Communication Framework Team

A quick recap on various types of transports in SAP:

K type: The system owner does not get changed with K type transport. This kind of transport is only allowed to consolidation and production system. After the K type of transport is done no correction is allowed to those objects. Any changes to K type transport objects in consolidation system are called repair.
The repairs can be done to those objects if the change option is selected in SE06 and change option is there in client level selection in T00 table. Generally K type transport is used for stage and production environment.

C type: With the C type transport the ownership of that object is also transferred to the target. After the transport is done, the target system is the owner of the transported objects. The objects will be originals of the target system. These kind of transports are generally done in a four tier architecture, where a bundle of development objects can go from the sandbox environment to development environment or development environment to integration environment and vice versa. SAP recommends doing these transports when the objects should move to another system for further development work.

T type: T type is called a transport of copy. The ownership of the object remains with the source; the target system just gets the copy of the objects. When a sap patch is applied to the development system and transported to other systems, those are perfect example of T type transports.

There are 5 different User types:

1. Dialog
2. System
3. Communication
4. Service
5. Reference

Description about the above User types:

1. Dialog:- For Dialog User GUI Login is possible,Initial password and expiration of password and Multi GUI Logins are checked.
Individual system access (personalized)
It is possible to log on using SAP GUI. The user is therefore capable of interaction through SAP GUI.
The system checks whether the password has expired or is initial.
The user can change his or her password himself or herself.
Multiple dialog logons are checked and, where appropriate, logged.

Purpose of Dialog User is for individual human users.

2. System:- For a System User GUI Login is not possible, Initial password and expiration of password are not checked.
System-related and internal system processes.
It is not possible to log on using SAP GUI. The user is therefore incapable of interaction through SAP GUI.
The password change requirement does not apply to the passwords, that is, they cannot be initial or expired.
Only a user administrator can change the password.
Multiple logons are permissible.

Purpose of System User is for background processing and communication within a system (internal RFC calls) and between multiple systems (external RFC calls).

3. Communication:- For a Communication User login is not possible, Users are allowed to change password through some software in middle tier
Individual system access (personalized)
It is not possible to log on using SAP GUI. The user is therefore incapable of interaction through SAP GUI.
Although the system checks whether the password has expired or is initial, the implementation of the requirement to change the password, which exists in principle, depends on the logon method (interactive or non-interactive).

Purpose of this User is for external RFC calls of individual human users.These are used for login to system through external systems like web application

4. Service:- For a Service User GUI login is possible.Initial password and expiration of password are not checked.Multiple logins are allowed.Users are not allowed to change the password. Only admin can change the password.
Shared system access for a larger, anonymous group of users. Assign only very restricted authorizations for this user type.

Purpose of this User is for anonymous users. This type of users should be given minimum
authorization.After an individual authentication, an anonymous session begun with a service user can be continued as a person-related session with a dialog user.

5. Reference:- For a Reference User GUI login is not possible.Initial password and expiration of password are not checked.
User type for general, non-person related users that allows the assignment of additional identical authorizations, such as for Internet users created with transactions SU01.

Purpose of this Users are special kind of users which are used to give authorization to other users.

Fundamentals of RFC

Communication between applications of different systems in the SAP environment includes connections between SAP systems as well as between SAP systems and non-SAP systems. Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. The RFC calls a function to be executed in a remote system. You can also call a function module in the same system as an RFC; however, RFCs are usually used when the calling and called function modules are running in different systems.

In the SAP system, the RFC interface system provides this function. The RFC interface system allows function calls between two SAP systems or between an SAP system and an external (non-SAP) system.
RFC is an SAP interface protocol that is based on the Common Programming Interface for Communication (CPI-C) and allows cross-host communication between programs. This means that ABAP functions can be called from external applications and tools, and that external applications can be called from the SAP system.

RFC means that the ABAP programmer does not have to write his or her own communication routines. For an RFC call, the RFC interface Converts all parameter data to the format required in the remote system calls the communication routines that are required to communicate with the remote system handles errors that occur during the communication.

Types of RFC (Remote Function Calls)

Synchronous RFC (sRFC)
For communication between different systems and between SAP Web AS and SAP GUI.

Asynchronous RFC (aRFC)
For communication between different systems and for parallel processing of selected tasks.

Transactional RFC (tRFC)
A special form of asynchronous RFC. Transactional RFC ensures transaction-like processing of processing steps that were originally autonomous.

Queue(d) RFC (qRFC)
Queued RFC is an extension of tRFC. It also ensures that individual steps are processed in sequence.

RFC is a superordinate term for various implementation variants. sRFC is the synchronous call of function modules. This means that the client waits until the server has completed its processing. In an SAP system, an RFC can also be performed asynchronously in another work process. This variant is called aRFC.

There is also tRFC, the transactional Remote Function Call. Transactional RFC is asynchronous and ensures that data that is sent more than once due to network problems, can be recognized at the server side, by assigning a Transaction Identifier (TID). This allows you to prevent data being processed more than once, leading to erroneous information in the application. Due to the asynchronous processing, however, parameters can only be transferred from the client to the server in this case. Returning information or status information directly is not possible.

qRFC with Send Queue is an extension of tRFC. It creates a layer between applications and the tRFC and only allows the tRFC to transfer a Logical Unit of Work (LUW) to the target server when its predecessors are no longer in the associated wait queues. After a qRFC LUW is executed, the qRFC manager automatically processes the next waiting qRFC LUW in accordance with the sequence in the wait queue.

Client Concepts and Types of Data in SAP System

Data in an SAP system can be divided into two categories:

1. Client-specific data: Client-specific data such as user master and application data, which affects only one client.
2. Cross-client data: Cross-client data such as cross-client customizing data and all Repository
objects, which affects the whole system environment.

The ABAP Dictionary is a data dictionary that is part of the ABAP Repository. Each piece of the ABAP Dictionary information is entered only once and is then available anywhere in the system at any time. The ABAP Dictionary automatically supplies all new or changed information, thus providing current runtime objects and ensuring data consistency and security.

A client is a self contained unit in technical terms, wit its own master data.

The following are examples of client-specific data:
User master data, such as parameters, authorization, user groups

Customizing data, such as organizational units, assignments, and document types

Application data, such as business transaction data, and material master data

The SAP client concept can integrate several companies or subsidiaries in a single client by using company codes and the SAP authorization concept. Company codes define the smallest corporate organizational units for which a complete self-contained set of accounts can be drawn up for external reporting.
The SAP authorization concept enables the parent company to access all subsidiaries for report purposes, while subsidiary-specific data is protected against access from other subsidiaries through company code definition.

The standard client roles fulfill the optimal minimum requirements of your SAP system.

Client CUST, development and customizing, is the central customizing client where complete adaptation of the SAP system to customer-specific needs takes place. All changes performed in this client are recorded so they can be supplied to the other clients using the Transport Management System.

Client QST, quality assurance, is used to test and verify the new customizing settings in the application.

Client PRD or production is the client for production activities, that is, where your company’s business is carried out. Customizing changes imported into this client have to be first tested carefully in the QST client in order to ensure that production operation is free of disruption.

To start user maintenance you have to use the transaction code SU01. You can create a new user or copy the existing user master. The user master contain all data and setting that are required to log on to a client. In this you can find the following tabs:
Address: Personal info and address
Logon Data: Password and validity period of the user
User Default: Language, Values for printer
Parameters: User specific values for standard fields
Roles and profiles: Roles and profiles assigned to the user
Groups: Grouping users for mass maintenance

Types of User:
Dialog User, Communication User, System User, Service User, Reference User.

User ids allow access to SAP applications. Each user must have a corresponding profile specifically assigned. In many situations, multiple composite profiles can be assigned to a user ID, depending on the roles an individual user is responsible.

Authorizations are the key building blocks of SAP security. Authorization is the process of assigning values to fields present in authorization objects. In SAP, access to all system functionality is achieved through a complex array of authorizations. Sometimes users find that they lack the necessary authorizations to perform a certain function in the system, in which case the message: “You are not authorized…” is displayed at the bottom of the screen

A Profile Generator PFCG is used to automatically generate and assign authorization profiles. The administrator can also create authorization profiles manually.

Default User ids:

User Ids Client Name
SAP* 000 and 001
DDIC 000 and 001
EarlyWatch 066

A user Admin must be fimilar with the tasks and responsibilities of admin for creation, managing and controlling access to the R/3 system and its data, and also various R/3 user types and its data.
Must manage and create new user, groups and profiles using R/3 transaction.
Be fimilar with monitoring active users.
Transport client specific user objects between R/3 system or Clients.