Authorization Checks

When a user starts a transaction, the system performs the following checks:

• The system checks in table TSTC whether the transaction code is valid and whether the system administrator has locked the transaction.
•  The system then checks whether the user has authorization to start the transaction. The SAP system performs the authorization checks every time a user starts a transaction from the menu or by entering a command. Indirectly called transactions are not included in this authorization check. For more complex transactions, which call other transactions, there are additional authorization checks.

1. The authorization object S_TCODE (transaction start) contains the field TCD (transaction code). The user must have an authorization with a value for the selected transaction code.
2. If an additional authorization is entered using transaction SE93 for the transaction to be started, the user also requires the suitable defined authorization object (TSTA, table TSTCA).
   If you create a transaction in transaction SE93, you can assign an additional authorization to this transaction. This is useful, if you want to be able to protect a transaction with a separate authorization. If this is not the case, you should consider using other methods to protect the transaction (such as AUTHORITY-CHECK at program level).
   

• The system checks whether the transaction code is assigned an authorization object. If so, a check is made that the user has authorization for this authorization object.

         The check is not performed in the following cases:

1. You have deactivated the check of the authorization objects for the transaction (with transaction SU24) using check indicators, that is, you have removed an authorization object entered using transaction SE93. You cannot deactivate the check for objects from the SAP NetWeaver and HR areas.
2. This can be useful, as a large number of authorization objects are often checked when transactions are executed, since the transaction calls other work areas in the background. In order for these checks to be executed successfully, the user in question must have the appropriate authorizations. This results in some users having more authorization than they strictly need. It also leads to an increased maintenance workload. You can therefore deactivate authorization checks of this type in a targeted manner using transaction SU24.
3. You have globally deactivated authorization objects for all transactions with transaction SU24 or transaction SU25.
   So that the entries that you have made with transactions SU24 and SU25 become effective, you must set the profile parameter AUTH/NO_CHECK_IN_SOME_CASES to "Y" (using transaction RZ10).

All of the above checks must be successful so that the user can start the transaction. Otherwise, the transaction is not called and the system displays an appropriate message.

Checking Assignment of Authorization Groups to Tables
You can also assign authorization groups to tables to avoid users accessing tables using general access tools (such as transaction SE16). A user requires not only authorization to execute the tool, but must also have authorization to be permitted to access tables with the relevant group assignments. For this case, we deliver tables with predefined assignments to authorization groups. The assignments are defined in table TDDAT; the checked authorization object is S_TABU_DIS.

Derived Roles & Composite Roles

 

Derived roles  Derived roles refer to roles that already exist.  The derived roles inherit the menu structure and the functions included (transactions, reports, Web links, and so on) from the role referenced.  A role can only inherit menus and functions if no transaction codes have been assigned to it before. The higher-level role passes on its authorizations to the derived role as default values which can be changed afterwards.  Organizational level definitions are not passed on. They must be created anew in the inheriting role. User assignments are not passed on either. Derived roles are an elegant way of maintaining roles that do not differ in their functionality (identical menus and identical transactions) but have different characteristics with regard to the organizational level. The menus passed on cannot be changed in the derived roles.  Menu maintenance takes place exclusively in the role that passes on its values. Any changes immediately affect all inheriting roles. You can remove the inheritance relationship, but afterwards the inheriting role is treated like any other normal role. Once a relationship is removed, it cannot be established again.   Composite roles A composite role is a container with  several different roles. For reasons of clarity, it does not make sense and is therefore not allowed to add composite roles to composite roles. Composite roles are also called roles. Composite roles do not contain authorization data. If you want to change the authorizations (that are represented by a composite role), you must maintain the data for each role of the composite role. Creating composite roles makes sense if some of your employees need authorizations from several roles. Instead of adding each user separately to each role required, you can set up a composite role and assign the users to that group. The users assigned to a composite role are automatically assigned to the corresponding (elementary) roles during comparison. The menu tree of a composite role is, in the simplest case, a combination of the menus of the roles contained. When you create a new composite role, the initial menu tree is empty at first. You can set up the menu tree by choosing Read menu to add the menus of all roles included. This merging may lead to certain menu items being listed more than once. For example, a transaction or path contained in role 1 and role 2 would appear twice. If the set of roles contained in a composite role changes, the menu tree is also affected. In such a case, you can completely rebuild the menu tree or process only the changes. If you choose the latter option, the Profile Generator removes all items from the menu which are not contained in any of the roles referenced. It is possible (and often necessary) to change the menu of a composite role at any time. You adjust these menus in the same way as the menus for roles

Interface Technologies used in SAP

SAP systems use the following interface technologies that are listed in the above graphic:

. ALE: Application Link Enabling
. BAPI: Business Application Programming Interface
. CPI-C: Common Program Interface Communication
. EDI: Electronic Data Interchange
. HTTP: HyperText Transfer Protocol
. LU 6.2: Logical Unit Type 6.2
. RFC: Remote Function Call
. OLE: Object Linking and Embedding
. SMTP: Simple Mail Transfer Protocol
. SOAP: Simple Object Access Protocol
. TCP/IP: Transmission Control Protocol / Internet Protocol
. XML: Extensible Markup Language

Application Link Enabling (ALE)

Application Link Enabling is a means of creating and operating distributed applications. The basic concept of Application Link Enabling is to ensure operation of a distributed, yet integrated system landscape. This involves business-controlled message exchange using consistent data across loosely linked application systems. The applications are integrated through synchronous and asynchronous communication, not through a central database.

Systems that use ALE to exchange data can be located at the same company, or they may belong to different companies. One of the characteristics of ALE is that different systems are linked in business terms through secure and consistent data transfer.

You could also describe ALE as being composed of the elements: who exchanges
which data when, with whom, and by what means.

Implementing ALE therefore requires that you clarify the following points in detail:
1. Identify the business process and the objects involved
2. Identify the information to be transmitted
3. Specify the format for the data to be transferred
4. Decide on the transfer technology to be used
5. Decide on the transfer type
6. Specify the destination of the data transfer

The data is often identified within the SAP system using a business object and its Business Application Programming Interfaces (BAPIs). A BAPI is a method of a business object, for example, the material master record. A permissible method could be creating or changing the material master data. BAPIs normally enable you to edit all data belonging to the object.

The IDoc format describes the structure of .intermediate documents.. There are various kinds of IDoc formats for different types of data to be exchanged. Alternatively, you can use ALE to transfer data in an agreed XML format.

There are two basic transfer types: synchronous and asynchronous.

Synchronous transfer means that the data is transferred at the time of creation or change. You
can start asynchronous transfers at intervals of your choice.

There are very few restrictions on the systems that can be linked. The systems involved must have the technical capability to receive the communications (RFC-enabled, HTTP-enabled) and interpret the format transferred (IDoc, XML).
SAP systems of different releases can be linked using ALE.

Visit http://ebookssap.blogspot.com & http://ebooks-sap.blogspot.com to download SAP books