SAP Work Processes

Work Process Type	Description
Dialog	D: Processes real-time information in the foreground.
Background	B: Background processing for long-running processes, reports, and batch jobs.
Synchronous Update	V1: Processes immediate updates to the database.
Asynchronous Update	V2: Processes updates to the database on a lower priority than V1 (that is, when time permits).
Enqueue	E: Manages database locks.
Message	M: Manages communication between application servers.
Spool	S: Manages print jobs (the print spool).
Gateway	G: Communicates with other SAP and non-SAP systems.

SAP System User types (Dialog, system, communications, service, reference )

You can specify the following user types:

●      Dialog (A)

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: for individual human users (including Internet users)

●      System (B)

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: background processing and communication within a system (internal RFC calls) and between multiple systems (external RFC calls). Purpose: for example, RFC users for ALE, workflow, TMS, CUA.

●      Communications (C)

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).

The user can change his or her password himself or herself.

Purpose: external RFC calls of individual human users.

●      Service (S)

Shared system access for a larger, anonymous group of users.  Assign only very restricted authorizations for this user type.

It is possible to log on using SAP GUI. The user is therefore capable of interaction through SAP GUI.

During a log on, the system does not check whether the password has expired or is initial.

Only a user administrator can change the password.

Multiple logons are permissible.

Purpose: Anonymous system access (such as for public Web services). After an individual authentication, an anonymous session begun with a service user can be continued as a person-related session with a dialog user.

●      Reference (L)

It is not possible to log on to the system.

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.

To assign a reference user to a dialog user, specify it when maintaining the dialog user on the Roles tab page. In general, the application controls the assignment of reference users. This assignment is valid for all systems in a Central User Administration (CUA) landscape. If the assigned reference user does not exist in a CUA child system, the assignment is ignored.

You should be very cautious when creating reference users.

■       If you do not implement the reference user concept, you can deactivate this field in accordance with SAP Note 330067.

■       We also recommend that you set the value for the Customizing switch REF_USER_CHECK in table PRGN_CUST to "E". This means that only users of type REFERENCE can then be assigned. Changing the Customizing switch affects only new assignments of reference users. Existing assignments are retained.

■       We further recommend that you place all reference users in one particularly secure user group to protect them from changes to assigned authorizations and deletion.

Can we assign generated profiles to users directly ?

Yes but the best practice is not to assign profile to a user master record instead, assign single role or composite role to the user.

Scum settings - logon data tab.

SCUM SETTINGS - LOGON DATA TAB has the following settings as below:

Global	You can only maintain the data in the central system. The data is then automatically distributed to the child systems. These fields do not accept input in the child systems, but can only be displayed. All other fields that are not set to “global” accept input both in the central and in the child systems and are differentiated only by a different distribution after you have saved.
Proposal	You maintain a default value in the central system that is automatically distributed to the child systems when a user is created. After the distribution, the data is only maintained locally, and is not distributed again, if you change it in the central or child system.
RetVal	You can maintain data both centrally and locally. After every local change to the data, the change is redistributed to the central system and distributed from there to the other child systems.
Local	You can only maintain the data in the child system. Changes are not distributed to other systems.
Everywhere	You can maintain data both centrally and locally. However, only changes made in the central system are distributed to other systems, local changes in the child systems are not distributed.

How to assign a same role to 200 users ?

You can do using PFCG- >  enter the role -> change -> go to  users tab -> paste the users -> click on user comparsion->   complete comparsion -> Save the role - it's done

or

One can also use "Authorization Data" functionality in  transaction SU10 to complete this task.

User have tcode SA38. How to restrict user to execute only report rsusr003

Use SE93 to create customize tcode: 

a) via 'transaction with value' where we use SA38 screen as inheritance. We have option to hide SA38 screen to avoid user running other program.

b) via 'transaction with value' where we use START_REPORT to call program it self.  Or you can change the following object in the role  with tcode SE38 and in authorization object S_DEVELOP the  activities

DEVCLASS '*'           

OBTYPE '*'          

OBNAME  ' RSUSR003'           

p_group '*'           

activity '03'

How to check list of user from table usr02 using SQL Query.

How to check list of user from table usr02 using SQL Query.

1. In Ms SQL Server Management studio.

2. Execute  SELECT BNAME FROM hrs.USR02 WHERE MANDT='310';