Insert wa_flight into table it_flight.

* If you are using standard tables, "APPEND wa_flight TO it_flight."

* would be the same as the above INSERT-statement. ENDSELECT.

IF sy-subrc = 0.

* Sort internal table

SORT it_flight BY percentage.

* Create list

LOOP AT it_flight INTO wa_flight.

WRITE: / wa_flight-carrid, wa_flight-connid, wa_flight-fldate, wa_flight-seatsocc, wa_flight-seatsmax,

Wa_flight-percentage, ’%’.

ENDLOOP.

ELSE.

WRITE: ’No ’, pa_car, ’flights found!’. ENDIF.

LessonSummary

You should now be able to:

• List different methods for searching relevant database tables

• Program read access to specific columns and rows within a particular database table

• List different methods for read accesses to several database tables

Lesson:

157

Authorization Check

Lesson Duration: 60 Minutes

Lesson Overview

In this lesson, you will learn why an authorization check is useful and how to include it in your programs.

 

Lesson Objectives

After completing this lesson, you will be able to:

• Explain the SAP authorization concept

• Implement authorization checks

 

For purposes of teaching the course, this topic has been placed in the context of data retrieval. It is very important that the participants understand the authorization concept and authorization check and can use them in their programs.

You should also point out that implementing an authorization check using the corresponding program attribute is too inflexible and should only be used in simple cases.

As a demo, create an authorization object from which you check the authorization in your program. Use thePATTERN button in the ABAP Editor.

Double-click on the authorization object in the AUTHORITY CHECK statement to show how to find out the permissible activities for an object.

Finally, show how to search for authorization objects in the Repository Information

System.

Business Example

Authorization checks are necessary in your programs to protect the data from unauthorized access.

Authorization Checks

Critical data and parts of the functional scope of the SAP System must be protected from unauthorized access. You have to implement authorization checks in your program so that the user may only access areas for which he or she is authorized. The following graphic illustrates the SAP authorization concept.

 

Figure 101: The SAP Authorization Concept

 

Figure 102: Authorization Objects and Authorizations (Example)

Authorization objects can be defined within object classes. When you define an authorization object, you have to specify appropriate fields (without values). You create an actual authorization by subsequently assigning values to these fields. This authorization can be integrated into the required user master records by means of an authorization profile.

Several different authorizations (for the integration into different user master records) can be created for an authorization object.

 

Figure 103: Authorization Check (Principle)

At runtime, you can use the AUTHORITY-CHECK statement to check whether the actual user has the authorization required for executing the function in his or her user master record. Depending on the check result (sy-subrc), you can continue your program accordingly:

sy-subrc = 0: User has required authorization -> Execute functionality

(e.g. SELECT).

Else: Authorization not available -> Appropriate note to user.

Hint: In addition to the previously described option, programs and transactions can also be protected by means of authorization checks. However, such checks should only be considered as additions to, and not substitutions for, the above-described.

Usually, the definition of an authorization object and the implementation of the authorization check are the responsibility of the developer, whereas subsequent steps such as the authorization and profile definition as well as the design of the user master records are the responsibility of the administrator.

You will learn about the two steps required by the developer in the following section.

 

Figure 104: Creating Authorization Objects

Before you can implement the required authorization check in your program, you must first define the structure (the fields) of the respective authorization concept. An object usually consists of the ACTVT (activity) field and one other field, which specifies the data type to be protected (i.e., material number, airline and so on.) The values of these authorization fields specify what the user is authorized to do.

You can now use transaction SU20 to create the fields. ACTVT is already in the system.

You then use transaction SU21 to first create an object class and then create the authorization object specifying the appropriate fields. If your object contains the ACTVT field, then you must also maintain permitted activities with reference to the object. In doing so, you choose the activities that make sense for your object from all possible activities.

Finally, all that remains to be done is to implement the authorization check in your program. The following graphic illustrates the authorization check.

 

Figure 105: Authorization Check (Syntax Example)

For the authorization check in the program, you specify the authorization that is to be checked in the master record of the current user. The authorization is specified by specifying the authorization object, its fields, as well as the appropriate field values. Refer to the syntax in the above graphic.

In our example, it is checked whether the user has an authorization for the S_CARRID object, in which the field CARRID (airline) contains the airline entered by the user, and the field ACTVT (activity) contains the value '03' (display).

Table TACT contains all possible activity codes including their descriptions. Table TACTZ in contrast contains the activity codes that are permitted for specific objects.

After the AUTHORITY-CHECK statement you should check the return code sy-subrc and control the further processing of your program accordingly.

Hint: If you do not want to carry out a check for a field, either do not enter it in the AUTHORITY-CHECK statement or enter DUMMY as the field value. DUMMY is a predefined description entered without quotation marks.

An example of a suppressed field check: When a change transaction is called, the system is to always check immediately whether the user has any change authorization for any airline. If the check fails, an appropriate message is to be output to the user immediately. Such a check can be implemented with the following syntax:

Дата добавления: 2015-11-16