Category Archives: SAP

There are various ways to do that, two of the quickest ones are
1) Turn the audit log on by using SM19 and SM20 and analyze the audit logs.Put filters while setting up these logs so that you can see the specific data.

2) In ST03N / ST03, you can analyze the transactions run by users by selecting the “User Profile” under the “Analysis Views” section.

Program code that calls an authorization check using the authority-check statement. This will look something like:
authority-check object id field

Authorization fields (corresponding to the in the above code) that define a scope of possible values. Examples of authorization fields would be:

ACTIVITY: defines the type of activity the user is doing with the data. Possible values are
‘DISPLAY’, ‘MODIFY’, ‘DELETE’, etc.

COMPANY_CODE: possible values are any single value, or any range of values, or any combination thereof (such as ‘0438’ and ‘0600’ thru ‘1100’)

Authorization objects that define a group of fields. For example, an authorization object called ‘CO_MDATA’, containing our above fields ACTIVITY and COMPANY_CODE, might used to control access to the company master data tables.

Authorizations, each of which belong to exactly one authorization object, that define authorization values (within the scopes defined by the authorization objects) to be granted to users. Note that an authorization is different from an authorization object!! Extending our previous examples, we might have an authorization, belonging to the authorization object ‘CO_MDATA’, called ‘CO_MDATA_ALL’, that grants all access to all company master data. Then ‘CO_MDATA_ALL’ would have the following values:

FIELD VALUE
ACTIVITY *
COMPANY_CODE *

Profiles, each of which may contain several authorizations or profiles. A simple profile contains a group of authorizations. A composite profile contains a group of profiles (simple or composite). [Profiles can be conceptualized as forming the structure of a tree, in which end nodes (leaves) are authorizations, and all other nodes are profiles. Simple profiles are nodes whose children are all end nodes, and composite profiles are nodes, other than end nodes, who have no end nodes for children.]

Profiles are designed to define set or one or more functions or positions. For example, a functional profile might define all the authorizations that are required for doing a goods receipt, or for making a payment in the AP module. A position profile, on the other hand, might define all of the authorizations that are granted to an accountant, or to a warehouse supervisor. Often, a position profile is a composite profile consisting of several functional profiles.
Users, to whom profiles are assigned. A user is assigned one or more profiles by the system administrator. These profiles define all of the user’s system authorizations. It sounds complicated, but once you start working with authorizations, it’s pretty easy.

Program code that calls an authorization check using the authority-check statement. This will look something like:
authority-check object id field

Authorization fields (corresponding to the in the above code) that define a scope of possible values. Examples of authorization fields would be:

ACTIVITY: defines the type of activity the user is doing with the data. Possible values are
‘DISPLAY’, ‘MODIFY’, ‘DELETE’, etc.

COMPANY_CODE: possible values are any single value, or any range of values, or any combination thereof (such as ‘0438’ and ‘0600’ thru ‘1100’)

Authorization objects that define a group of fields. For example, an authorization object called ‘CO_MDATA’, containing our above fields ACTIVITY and COMPANY_CODE, might used to control access to the company master data tables.

Authorizations, each of which belong to exactly one authorization object, that define authorization values (within the scopes defined by the authorization objects) to be granted to users. Note that an authorization is different from an authorization object!! Extending our previous examples, we might have an authorization, belonging to the authorization object ‘CO_MDATA’, called ‘CO_MDATA_ALL’, that grants all access to all company master data. Then ‘CO_MDATA_ALL’ would have the following values:

FIELD VALUE
ACTIVITY *
COMPANY_CODE *

Profiles, each of which may contain several authorizations or profiles. A simple profile contains a group of authorizations. A composite profile contains a group of profiles (simple or composite). [Profiles can be conceptualized as forming the structure of a tree, in which end nodes (leaves) are authorizations, and all other nodes are profiles. Simple profiles are nodes whose children are all end nodes, and composite profiles are nodes, other than end nodes, who have no end nodes for children.]

Profiles are designed to define set or one or more functions or positions. For example, a functional profile might define all the authorizations that are required for doing a goods receipt, or for making a payment in the AP module. A position profile, on the other hand, might define all of the authorizations that are granted to an accountant, or to a warehouse supervisor. Often, a position profile is a composite profile consisting of several functional profiles.
Users, to whom profiles are assigned. A user is assigned one or more profiles by the system administrator. These profiles define all of the user’s system authorizations. It sounds complicated, but once you start working with authorizations, it’s pretty easy.

As the name indications are derived from already existing roles.
There are two scenarios when we derive roles.

* The role menus are identical but the authorizations for the menu actions are different in the derived role.
* The menu and authorizations of the derived role are identical, but the organizational levels are different in the derived role.

The derived roles inherit the menu structure and functions (including transactions etc…) of the referred role.

The default authorization values of the derived role are that of the inherited role. The organizational values are to be maintained in the derived role.
The organization level data is only copied the first time the authorization data is adjusted for the derived role. If organization level data is maintained in the derived role, it is not overwritten by subsequent adjustments.

Roles derived from another cannot have any additional menu entries. The menu is maintained in the referred role which take effect immediately in all derived roles.

To change the menu of the derived role without changing the menu of referred role you have to break the inheritance relationship. Once the relationship breaks, the derived role is dealt as a normal role and the inheritance relation ship cannot be re established

Composite Roles :
Suppose there is position in your organization in which activites of two positions need to be performs the roles is called composite role.
Take an example. There are two positions like a clerk and auditor. If there is a position in your organization where the individual has to act both as a clerk and an auditor the the role is a composite roles which needs him/her to work both as a clerk and auditor. This is quite common scenario in organizations or companies.
A composite role has many single roles. No authorization data can be maintained in a composite role. You can eneter some menu entries like links to websites, reports only. Tcodes cannot be added. The authorization data has to be maintained only in the single roles.
When you attach a composite roles to an user all the single roles gets attached to him. In the change documents it shows the single profiles that belongs to single roles gets attached to them. Suppose a composite role has 3 single roles. when you attach this composite role to a user then 3 authorizations profiles will get attached to him. The change count in SUIM will be 3.

Role is the way how authorizations are granted in SAP or the activities which are performed by and individual are restricted. A role consists of all the duties performed by an individual in the organization. For e.g., the clerk or the manager or buyer or dispatcher etc.. Two managers of same cader has same type of duties. Technically a roles contains all the items(transactions or tcodes, reports, links) which are needed by an individual in particular position. In a roles-based authorization system the lattice structure of organization is well defined and the activities performed by each individual is defined clearly. In a role-based authorization system the users are assigned to generiuc roles (technical) which contains tcodes necessary for peforming the job. The above description is a single role.

You can quickly run transaction SU01 and see if the “Systems” tab is available. If it is then CUA has been configured. Well there is another way to see whether CUA is used. Run transaction code SCUA to see if there are any distribution models defined. Run transaction code SCUL to see to view logs that are generated by CUA & if you have logged into a child system, then goto transaction code SU01 and see, there will be no CREATE activity.

The tp command doesn’t work. It always shows some error which I don’t understand.

Make sure the environment is set up properly. See Troubleshooting Server Startup for details.
After releasing my change request, I can’t find the transport files
in the transport directory.
Make sure you released the request, as well as the tasks under it (the request
is the part of the tree directly under the word “Transportable”).
Check the action logs using SE09 for errors. If there were no errors, try re-transporting an object by changing it and creating a new request. Before releasing the task or request, go to SE09 and list the request. If the request is listed under “Local”, it can NOT be transported to another system.
My change request is always local, but I want it to be transportable
The problem lies in either the workbench setup, the development class assigned to the objects you wish to transport, or both. Check the workbench setup with SE06->Display. Is your system set as a productive system? If so, change requests usually are not transportable. Try creating a new development class Z111, and choose any transport layer that the system allows you to choose (if your system does not allow you to choose any transport layers, then the workbench is not set up to allow any changes to be transportable). If it allows you to choose several layers, create on new class for each layer, and a new change request for each class. Then go to SE09 and check if your requests are transportable. If they are transportable, try to release one of the development classes (release the task and the request) and check that the files are created.
The system won’t let me release a request because the the “target system is the same as the source system.”
Click on the request, hit Shift+F6 (Change), and change the target system to a
SID other than the source system. If your system won’t let you change it to a SID that works, you are either trying to transport from the wrong system, or you need to recreate your system landscape.
How do I recreate the transport system landscape?

This should be done by a consultant during installation, and should not be changed after installation. If you really want to do it yourself, release all locked objects, log onto client 000 with DDIC, go to SE06, choose the landscape you want (usually 2- or 3-system group, and press Create. Tell the system which SIDs do which roles, and the rest is set up automatically.

I want to import objects into a system other than the one for which the transport files are targeted.

Use the tp unconditional modes. I have previously posted about the Unconditional modes.

After using the override options, tp won’t let me delete the request from the buffer.

Re-import the request, and then delete it from the buffer. If you cannot re-import (because, for instance, it is a very old request, and you do not know if re-importing will overwrite newer object), you can delete the entries directly from the file /usr/sap/trans/buffer/SID. This of course is not a “real” solution, but it does work (the “real” solution maybe would involve further editing of the E070, E071, or E070C tables).

I have created local objects in both the target system and the source system.
Now I want to organize development and create objects only in the DEV system, and allow no direct changes to the target system. What do I do about the objectsalready created?

They need to be reassigned to a development class before they can be transported.
Create a development class (or use an existing one) and test to make sure its objects can be exported and imported successfully.

How do I delete all the old change request/task clutter from my system.

If none of the tasks in the request have been released, the entire task/request
can be deleted. Before deletion, however, you should check to make sure that the related objects are either changed back to the state they were in before the change that resulted in their being linked to the change request.
The system says that I have to release all locked objects before I can perform a certain task. How do I find out what objects are locked?

Look in the tables TLOCK, E070, E071, and E070C. Sometimes, data in these tables can become orphaned, and may need to be processed manually (this is rarely necessary).

What do I do with all these transport files?

You can backup and delete old transport files every once in a while. Directories to be backed up and deleted in the /usr/sap/trans directory include: data, cofiles, log, olddata, EPS/out, EPS/log, and put/*. Note that SAP-delivered files can be deleted without backup; this includes directories such as put/exe, put/tools, and EPS/in.

Heap Memory stores User Context when Extended Memory allocated to a work process gets exhausted and the work process requires more space to continue. Heap Memory stores contains same type of Data as Extended Memory. Heap Memory is allocated dynamically according to requirement and not during system startup. When the workprocess starts using heap area it enters in to PRIV mode

SAPOSCOL is SAPOperating System Collector is a standalone program that runs in background at OS level. It collects information about operating system resource usage like:

CPU Utilization

Main Memory and Virtual Memory utilization.

Physical Disk and File System utilization.

Resource usage by running processes.

How many instances of SAPOSCOL to be run?
A)Only one instance of SAPOSCOL needed to be run per hardware. Even if there are multiple instances running on a single hardware only one SAPOSCOL
process is needed.

What is the frequency of data collection by SAPOSCOL?
A) Data is collected every ten seconds.

Where is the data collected by SAPOSCOL stored?
A)The data is stored in shared memory and for long & future usage data is stored in tables MONI & OSMON.
Tha data collected by SAPOSCOL copied to tables MONI & OSMON by background job COLLECTOR_FOR_PERFMONITOR

What are the SAP level tcodes to view this data?
A) At SAP level you can view the information collected by SAPOSCOL using tcodes/transactions ST06, OS06 & OS07.