alternateplanet

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.

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.

The Following are the transaction codes used for the System Monitoring:
SM12:
This Traction is used for Check for Lock Entries. There may be old locks still in place from transactions that did not release, or from when the user was cut off from the Network. If any lock entries are exist then we have to check since how long this lock existing. If, this lock existing from more than one day then we should check that particular User is available or not (By using the Transaction Code AL08). If he is not available then Delete that lock. Otherwise we should wait 1 or 2 Days.

SM13 :
This Transaction is used for Check for any Errors in Update Records. A failed or “Update Terminate” is an update to the failed database. These failed Updates occurs when a user entry or transaction is not entered or Updated in database. And we should check Whether Update is ACTIVE or not. And also we should check any Update Records are terminated.

SM21 :
This Transaction is used to check System Logs. After hitting the traction we should goto System log–> Chooseà All Remote System logs, and set Date and time to before the Last log review. And we should check whether any Errors, Warnings, Security Messages, Database, Abends, Any other different Events are there.The log is important because unexpected or unknown warnings and errors could indicate a serious problem.

SM51 :
This Transaction is used to check that all Application Servers are UP. And also This transaction is a central transaction from which you can select the instance to be monitor.

SM50 :
This Transaction is used to check Work Process Overview and for Systems with out Servers. Here all work processes with a “Running” or “Waiting” State. If Batch Jobs are not Running, If all the work processes are in use, this transaction provide a hint of this problem.

ST01 :
This Transaction is used for System Trace. By this transaction we can trace that what are the operations performed on particular file by particular user on which dates.

ST02 :
This transaction is used for Buffer tuning or Buffer Statistics. And it is used to tune Buffer perameters of R/3. The Buffer is important because significant buffer swaping reduces performance. Look under “Swaps” for Red Entries. Regularly check these entries to establish trends and get a feel of the Buffer behaviour. And in this transaction we should Maintain “Hit Ratio” is in between 90 – 100% for all , and “Heap Memory” allocated should be “0” , and “Swaps” is 0.

ST03 :
This Transaction is used to Check Work Load Analysis of . Workload Analysis is used to determine System performance. Check Statistics and Record Trends to get a feel for the System’s Behaviour and Performance. Understanding the System when it is running well helps us to determine what changes may need to be made when it is not.

ST04 :
This Transaction is used for Database Performance Analysis. This transaction provides the ability to Monitor the Database in related to 1) In Shared Pool “SQL Area Get Ratio” should be 90 – 95% 2) In Log Buffer Allocation Retries / Entries <1% 3) In Data Buffer “Quality” should be in 90 – 95% 4) In Sorts Disk / Memory <1% 5) In Table Scan & Fetches “Long Table Scans” should maintain as minimum as possible. And we should check Detailed Analysis then we should hit “Detailed Analysis menu” Button in this screen. In that we can check Database Overview like “Exclusive Lock Waits” , “Wait Events”, “Buffer Busy Waits”, “ File System Request”, “ Database Message logs”, “ SQL Requests”, Summery Report for all activities, etc

ST22 :
This Transaction is used to Analyse ABAP Dumps or Short Dumps. This transaction is also used for Analyse and Determine why the error occurred and take corrective action. It looks for an excessive number of dumps, and also dumps of an unusual nature. A ABAP dump is generated when a report or transaction terminates as a result of a serious error. The system records in the System Log(SM21) and writes a snapshot of the program terminate to a special table.

DB02 :
This transaction is used to check all table Spaces and Indexes. Here we should check table spaces sizes. If any table used space is =>99 then we should increase add the space for particular table space. And this transaction is provides a way to examine database allocation. And this transaction is allows us to monitor items such as: a) DB Space History b) DB Analysis By this transaction we can view Database history by Dates and Times.

DB12 :
This Transaction is used to check database Backups. And in this we should we see successful Backups and Unsuccessful Backups list

AL08 :
This transaction is used to Check the users on the System. This transaction displays User Ids and Terminal Names who are currently logged on the system.

SM37 :
This transaction is used for Monitoring Background Jobs. Background are batch jobs scheduled to run at specific time during the day. Here we should check for cancelled jobs. Here If we want to check particular job then,we should enter the Job Name and enter User name in User name field or ‘*’ and hit execute Button. And verify that all critical jobs are successful.

Export SAP Users and Authorizations:

1) Logon to the target SAP system in the client you want to save and go to transaction SCC8.

2) Select the SAP_USER profile and the Target System,

3) Click the Schedule as Background Job button and then check Immediately.

4) Click the Schedule Job button, click Continue.
If this system has more than 1 server, set Background Server to the Central Instance Server

5) Make a note of the KT transport number shown on the next window. The KT transport is for transporting client specific data.

6) The status of the export can be found using transaction SCC3.

7) After the export completes in SCC3, check the transport logs for the KT transport in SE01. The export is not finished until the “export” step shows completed successfully.

For systems with more than one client, you will need to follow the above steps on each client to create a transport of the users for each client.

Import SAP Users and Authorizations:

Note: This procedure assumes the Users were exported and Transport created before the client copy

1) Import the appropriate user Transport for each Client (i.e. 100, 900, 910 etc) from CMD Prompt .
Import needs to be done from CMD prompt (Not STMS), and while import is running, log off of the system as all IDs will be deleted and recreated with the import.

In the examples below a full system was assumed. If you are only importing users from a Client Copy there will only be one transport.

For All R3 Systems

tp addtobuffer xxxKT0aaaa u1 pf=

tp addtobuffer xxxKT0bbbb u1 pf=

tp addtobuffer xxxKT0cccc u1 pf=

tp addtobuffer xxxKT0dddd u1 pf=

tp import xxxKT0aaaa client pf=
tp import xxxKT0bbbb client pf=

tp import xxxKT0cccc client pf=

tp import xxxKT0dddd client pf=

2) After the import is complete, Logon to the SAP GUI for each Client as SAP*

Execute Transaction: SCC7

If a message pops up that this is a Production Client and protected from Client Copies

Go into SM31 and table T000 and change Client to “Test”

Ensure the Transport that is displayed is the Transport you imported in previous step

Select “Execute in Background”

Monitor to completion in Transaction: SCC3

Repeat this process for each Client Transport Exported/Imported

Change Target Client back to “Production” – If necessary