Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

Write: / ’authority-check error’(001). Endcase.

Pa_int1 TYPE i, pa_op(1) TYPE c, pa_int2 TYPE i. | DATA result TYPE p DECIMALS 2. | ENDLOOP. ENDIF. | Wa_flight-seatsocc / wa_flight-seatsmax. | INSERT wa_flight INTO TABLE it_flight. | Wa_sbook-loccurkey. | SELECT-OPTIONSname FORdata_object. | MESSAGE e045(bc400) WITH pa_car. ENDIF. | CALL SCREEN 100. | CLEAR wa_sbook. |


Читайте также:
  1. WRITE: / ’Authority-Check Error’(001). ENDCASE.

 

Continued on next page


 

For the solution to task 2, refer to the source code of the program:

 

SAPBC400DDS_AUTHORITY_CHECK_2


 

LessonSummary

You should now be able to:

• Explain the SAP authorization concept

• Implement authorization checks


 

UnitSummary

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

• Explain the SAP authorization concept

• Implement authorization checks

 

Related Information

 

... Refer to the online documentation for the relevant ABAP statement.


 


 

Unit 6

 

171 ToolsforProgramAnalysis

 

 

See the introductory instructors’ note in the lesson

 

Unit Overview

 

Refer to the lesson objectives for an overview of this unit.

 

 

UnitObjectives

After completing this unit, you will be able to:

 

• Explain the purpose of the Runtime Analysis and the Code Inspector.

• List the basic functions of the Runtime Analysis and the Code Inspector.

• Use both tools for the simple analysis of your programs.

 

 

Unit Contents

 

Lesson: Runtime Analysis and Code Inspector............................190


 


Lesson:

172


Runtime Analysis and Code Inspector

 

Lesson Duration: 30 Minutes

 

 

Lesson Overview

 

In this lesson, you will learn about the basic functions and the purpose of the program analysis tools Runtime Analysis and Code Inspector. This is only a brief introduction to the tools. For more information, refer to the appropriate documentation or advanced courses.


 

 

 
Lesson Objectives

 

After completing this lesson, you will be able to:

 

• Explain the purpose of the Runtime Analysis and the Code Inspector.

• List the basic functions of the Runtime Analysis and the Code Inspector.

• Use both tools for the simple analysis of your programs.

 

 

 
This unit provides a brief introduction/demonstration of these two tools in order to inform the participants of the purpose and basic functions. Further details should be avoided for time reasons. If necessary, you should refer to the online documentation or course BC402.

 

Business Example

 

You are to check your programs for performance, typical semantic programming errors, and security gaps.

 

 

The Runtime Analysis

 

The analysis tool runtime analysis provides you with the option of measuring the runtime requirement of your programs in detail. You can use it to localize low performance source code blocks in your programs and “tune” them if necessary.

 

However, always note that the measurement results depend on the current system and network load as well as the current table buffer and dataset. As the runtime analysis is mostly carried out in the development or test system, the results have to be relativized accordingly.


 

 

 

 
Figure 107: Navigation in the Measuring Environment

 

 

 

 

 

Figure 108: Execute Runtime Analysis

 

The above graphic shows the initial screen of the runtime analysis (measuring environment).


 

Enter a short description of your measurement. This gives you the option of selecting specific measurements from those you made and compare them to each other at a later stage.

 

You can measure the runtime of programs and transactions and function modules. Select the required type and enter the name of the measuring object.

 

By entering a variant you can specify which actions are to be measured in which parts of the program. By default, a standard variant supplied by SAP, which is called DEFAULT, is used for measurements. If necessary, you can also create personal variants and specify them for measurements.

 

Execute is used to start the runtime analysis. The generated measurement results are stored in a measurement-related file.

 

 

 

 

Figure 109: Evaluating the Runtime Analysis

 

The Analyse button shows percentage and absolute evaluations of the measurement results. Here, the runtime actions are separated into three areas:

 

ABAP

All ABAP statements except database accesses

 

Database

All database accesses


 

System

Program loading operation, if necessary, generation as well as other system activities

 

The Hit list button takes you to the detail screen. On this screen, all actions are listed individually and each assigned gross or net runtime. Here, the gross value refers to the entire runtime of the respective action whereas the net value only covers that part of the gross time that is not separately disclosed as subaction runtime.

 

You can display the ABAP statement that belongs to an action by selecting the action with the mouse pointer and choosing Display source code.

 

Hint: Choosing Tips & Tricks on the initial screen of the runtime analysis takes you to a demo environment where useful performance hints are explained and illustrated by means of runtime comparisons of various source codes.

 

As a demo, show the runtime analysis of a program that contains database accesses.

 

The Code Inspector

 

The Code Inspector offers you the option of analyzing your programs with regards to performance, security and typical semantic errors. In order to explain these three aspects in more detail, the section below lists some check criteria for each:

 

Performance

Are indexes used for database access?

Are SELECT statements embedded in loops?

 

Security

Is data read from a client other than the login client?

Is the database table or the WHERE clause dynamically specified in the

SELECT statement?

 

Typical semantic errors

Is the sy-subrc field checked after each AUTHORITY-CHECK statement? Is a client actually specified for CLIENT SPECIFIED?

Are several messages of type E (E messages) sent in direct succession?

 

The following graphic illustrates how you can call up the Code Inspector for your program:


 

 

 

 
Figure 110: Calling the Code Inspector

 

 

 

 

Figure 111: Inspection Result


 

As the result of an inspection you receive a list of error and warning messages. The i button that belongs to the message shows a detailed error description as well as improvement suggestions. Double-click on the error text to branch to the corresponding program statement.

 

 

 

 

 

Figure 112: Advanced Code Inspector Check

 

You can use transaction SCI (above graphic) to set up the check individually. To do so, define the following in SCI:

 

• A check variant, used to specify how detailed the check is

• an object set used to specify which objects (for example, all programs of a package) are to be checked, and finally

• an inspection used to specify the defined check variant and set of objects.

 

Hint: You can create check variants, object sets, and inspections either as private or public. To switch between these two categories you can use the pushbutton that is always placed in front of the input field. Note that

only you can use your private objects whereas public objects are available to all users of the system.

 

Execute the created inspection by pressing the appropriate button. The Results

button takes you to the inspection result.

 

The following graphic is an example of a check variant:


 

 

 

 
Figure113:CheckVariant

 

 
First, demonstrate the simple call of the Code Inspector from the Editor. Use the two demo programs SAPD620AW_CISD_SIMPLE_LIST and SAPD620AW_CISD_SIMPLE_LIST_OPT for illustration.

 

Then demonstrate transaction SCI.


 

 
Facilitated Discussion

 

Knowledge consolidation

 

 

Discussion Questions

Use the following questions to engage the participants in the discussion. Feel free to use your own additional questions.

 

Do such analysis tools also exist in other development environments?


 

LessonSummary

You should now be able to:

• Explain the purpose of the Runtime Analysis and the Code Inspector.

• List the basic functions of the Runtime Analysis and the Code Inspector.

• Use both tools for the simple analysis of your programs.

 

Related Information

 

• For more information, refer to the online documentation for the tools of the ABAP Workbench.


 

UnitSummary

You should now be able to:

• Explain the purpose of the Runtime Analysis and the Code Inspector.

• List the basic functions of the Runtime Analysis and the Code Inspector.

• Use both tools for the simple analysis of your programs.

 

Related Information

 

... Refer to the online documentation for the ABAP Workbench.


 


 

Unit 7

 

181 SubroutinesinABAP

 

 

See the introductory instructors’ note in the lesson

 

Unit Overview

 

Refer to the lesson objectives for an overview of this unit.

 

 

UnitObjectives

After completing this unit, you will be able to:

 

• Define subroutines

• Call subroutines

• Analyze the execution of subroutines in debugging mode

 

 

Unit Contents

 

Lesson: Subroutines............................................................202

Exercise 11: Subroutines..................................................215


 


Lesson:

182


Subroutines

 

Lesson Duration: 70 Minutes

 

 

Lesson Overview

 

In this lesson you will learn why subroutines make sense and how you can use them in your ABAP programs. Furthermore, you will learn how the interface of a subroutine is used to pass parameters and how the different transfer types are used.


 

 
Lesson Objectives

 

After completing this lesson, you will be able to:

 

• Define subroutines

• Call subroutines

• Analyze the execution of subroutines in debugging mode

 

 

 
Participants with programming experience should have no problems with this lesson. But in most cases there is a large number of participants that are not familiar with the concept and advantages of subroutines. Hence, you should clarify at the beginning of this lesson whether a basic introduction makes sense or is required.

 

Business Example

 

You need to structure a comprehensive program and encapsulate source code that is executed several times in a subroutine.


 

Internal Program Modularization with Subroutines

 

 

 

 

 

Figure 114: Using Subroutines (Motivation)

 

A subroutine is a modularization unit within the program where a function

is encapsulated in the form of source code. You page out a part of a program to a subroutine to get a better overview of the main program and to use the corresponding sequence of statements several times (see above graphic).

 

The better overview is a result of your program becoming function-oriented: It structures the overall task in subfunctions, which are the responsibility of corresponding subroutines.

 

Using subroutines also means that your program becomes easier to maintain as changes to functions often only have to be implemented in the subroutine (and not at various points in the main program). Furthermore, you can process a subroutine call “as a unit” in the debugger while executing your program and then look at the result. This usually makes it easier to find the source of the error.


 

 

 

 
Figure 115: Parameter Passing (Motivation 1)

 

 

 

 

 

Figure 116: Parameter Passing (Motivation 2)


 

You can address all (global) variables defined in the main program from a subroutine. But, in order to call up a subroutine for a specific situation with different data objects for each situation, you do not use global variables in the subroutine but placeholders, which are replaced with the required global

variables at the time the subroutine is called. These placeholders are called formal parameters and together they form the interface of the subroutine, which has to be declared when the subroutine is defined.

 

When the subroutine is called, formal parameters must be specialized by means of corresponding global variables (actual parameters), in order to implement the reference of the subroutine processing to real variables. This assignment of actual parameters to formal parameters when calling a subroutine is called parameter passing.

 

 

 

 

 

Figure 117: Ways of Passing Interface Parameters

 

They way these variables of the main program are passed to the formal parameters of the subroutine is called passing type and is specified for each parameter in

the interface of the subroutine. There are three passing types:


 

Call by Value

A copy is made of the actual parameter. This copy is assigned to the formal parameter. If in the subroutine a value is assigned to the corresponding formal parameter, this value will actually be assigned to a copy of the formal parameter and not its original.

You use this pass type, to make the value of a global variable available to the subroutine (in the form of a variable copy) without making it possible to change the respective global variable (protecting the original). Please note, however, that creating copies, especially for large internal tables, can be time-consuming.

 

Call by value and result

With this transfer type, the same applies as for “call by value”. However, at the regular end of the subroutine, the value that was changed to this point is written back to the original. If the program is prematurely terminated through a STOP statement or a user message of type E, the writing back

of the values is suppressed.

You use this pass type to transfer the value of a global variable to the subroutine and to have the fully processed final value of the copy written back to the original. But note that the creation of copies and the writing back of values can be time-consuming, especially for large internal tables.

 

Call by reference

The actual parameter is assigned directly to the formal parameter. This means that value assignments to the formal parameter are executed directly on the actual parameter.

You use this pass type if you want to run the subroutine processing directly on the specified actual parameter. It is popular for avoiding the time-consuming creation of copies for large internal tables.


 

 

 

 
Figure 118: Defining and Calling Subroutines

 

• A subroutine is introduced with FORM.

• The name and the interface of the subroutine are to be specified behind FORM.

• The statements of the subroutine follow.

• The ENDFORM statement concludes the subroutine.

 

In the interface definition you list the formal parameters of the subroutine (here: f1, f2, f3) and type them if necessary. The required pass type has to be specified for each parameter:

 

Call by value

You list each of the formal parameters that is supposed to have the pass type “call by value” (here: f1) with the VALUE prefix in the USING section. (Refer to the above graphic for the syntax.)

 

Call by value and result

You list each of the formal parameters that is supposed to have the pass type “call by value and result” (here: f1) with the VALUE prefix in the CHANGING section. (Refer to the above graphic for the syntax.)


 

Call by reference

You list each of the formal parameters that is supposed to have the pass type “call by reference” (here: f3) without the VALUE prefix in the CHANGING section. (Refer to the above graphic for the syntax)

Note: A parameter without VALUEprefix, but placed in the USING

section also has the pass type “call by reference”. However, this

declaration syntax only makes sense for formal parameters that are passed to larger internal tables, which are not to be changed in the subroutine (documentation via USING) but are to be passed using “call by reference” in order to avoid making time-consuming copies.

 

When the subroutine is called, the actual parameters to be transferred without VALUE prefix are specified under USING or CHANGING. The order of specification determines their assignment to the formal parameters. In the example in the above graphic, a is passed to f1, b to f2, and c to f3.

 

 

 

 

 

Figure 119: Typing the Interface Parameters

 

A formal parameter is typed generically, if it is typed using TYPE ANY or not typed at all. Actual parameters of any type can be transferred to such a parameter. At runtime, the type of the actual parameter is determined and assigned to the formal parameter (type inheritance) when the subroutine is called. However, if the statements in the subroutine are not suited to the inherited type, a runtime


 

error may occur (type conflict). Hence, generic typing should only be used if the type of the actual parameter is yet to be determined when the program is created or if it can vary at runtime (dynamic programming).

 

You implement the concrete typing of a formal parameter by specifying a global or built-in type in the TYPE addition. In doing so, you specify that only actual parameters of the specified type are to be passed to the subroutine. A violation of the type consistency between formal and actual parameters is already picked up in the syntax check. This increases the stability of your program as type conflicts in statements within the subroutine are prevented.

 

If you type with the standard types P, N, C or X, the missing characteristic “field length” is not inherited from the actual parameter until runtime. You achieve

a complete type assignment with this type (i.e., including the field length) by

defining and specifying locally defined types.

 

 

 

 

Figure 120: Typing the Interface Parameter for Structures and Internal Tables

 

You must type formal parameters for structures and internal tables so that you can access the corresponding components. The components of structure parameters are known in the subroutine, as a result of the assigned type, so that you can address these components with the usual syntax. The typing of table parameters enables you to address these as internal tables using the usual syntax in the subroutine.

 

Hint: Larger internal tables should be transferred by call by reference

in order to avoid time consuming copies.


 

 

 

 
Figure 121: Visibility of Global and Local Data Objects

 

Variables defined in the main program are global data objects. They are visible

(can be addressed) in the entire main program in every subroutine called.

 

Variables defined within a subroutine are called local, as they only exist in the relevant subroutine - just like the formal parameters. The memory for formal parameters and local data objects is only allocated during the subroutine run and released again after execution.

 

The formal parameters and local data objects of a subroutine can not have the same names. If there is a global data object with the same name as a formal parameter or a local data object, then the formal parameter or local data object is addressed within the subroutine and the global data object is addressed outside the subroutine. This is called hiding rule. Within a subroutine the local data objects “hides” the global one with the same name.

 

To clearly label your program-internal objects you could, for example, use the following prefixes:

f_... for “formal parameters” and

l_... for a “local data object”.


 

 

 

 
Figure 122: Syntax Example: Passing an Internal Table

 

In the above syntax example, the internal table it_flightinfo and the global variable carrid are passed by means of call by reference, even though they are not changed in the subroutine. The advantage of this is that no copies have to be made.

 

To loop through the internal table, you need a work area with a compatible line type. This is locally defined in the subroutine with reference to the table parameter f_itab. The reference is possible because f_itab is typed in the interface of the subroutine.


 

 

 
Figure 123: Implementing a Subroutine Call

 

You can have the PERFORM statement for calling a subroutine generated into your source code. First, define the subroutine and then save your main program. The newly-defined subroutine appears in the navigation area. Move it to the required call point in your program by means of drag & drop. All you have to do is replace the formal parameters in the generated source code with corresponding actual parameters.

 

(Alternatively, the call generation can also be implemented using the “Pattern”

pushbutton in the ABAP editor.)

 

The advantage of the call generation is that it is impossible to forget or mix parameters.


 

 

 

 
Figure 124: Subroutines in Debugging Mode

 

If the current statement is a subroutine call, then you can execute the entire subroutine without stopping by choosing Execute. Processing only stops once the subroutine has been completed.

 

In contrast, you can use Single Step to stop at the first statement of the subroutine and trace its operations in more detail.

 

If the current statement is located in a subroutine, you can execute the rest of the subroutine without it stopping by choosing Return. Processing only stops once the subroutine has been completed.

 

 

 
Use one of your previous programs to perform a demo using PERFORM. The subroutine that you create should have an interface with a structure or table parameter, in order to illustrate the type assignment of interface parameters. The participants can then try this themselves in the exercise.


 


 

 

195 Exercise 11: Subroutines

 

Exercise Duration: 30 Minutes

 

 

Exercise Objectives

 

After completing this exercise, you will be able to:

• Create subroutines

• Use the subroutine interface to pass data

 

 

Business Example

 

Change your program so that the source code for the data output is encapsulated in a subroutine

 

System Data

 

System: Will be assigned Client: Will be assigned User ID: Will be assigned Password: Will be assigned

Set up instructions: No special instructions when using a standard training system

 

Task 1:

 

Create a subroutine with table parameters

 

1. Copy your program ZBC400_##_SELECT_SFLIGHT_ITAB or the corresponding model solution SAPBC400DDS_AUTHORITY_CHECK_2 to the new program ZBC400_##_SUBROUTINE.

 

2. Encapsulate the data output in a subroutine.

 

To do so, define the subroutine (suggested name: WRITE_LIST) and type the interface parameter so that it can be transferred to the internal table designed for the output.

 

3. Display the data from the subroutine using a LOOP. To do this, create the required table work area as a local data object in the subroutine (name proposal: wa).

 

Task 2:

 

Call subroutine

 

1. After the sorting of the internal table, call the subroutine to output the table.

 

2. Execute your program to test the result.


 

Solution 11: Subroutines

 

Task 1:

 

Create a subroutine with table parameters

 

1. Copy your program ZBC400_##_SELECT_SFLIGHT_ITAB or the corresponding model solution SAPBC400DDS_AUTHORITY_CHECK_2 to the new program ZBC400_##_SUBROUTINE.

 

a) Carry out this step as usual.

 

2. Encapsulate the data output in a subroutine.

 

To do so, define the subroutine (suggested name: WRITE_LIST) and type the interface parameter so that it can be transferred to the internal table designed for the output.

 

a) See source code excerpt in the model solution.

 

3. Display the data from the subroutine using a LOOP. To do this, create the required table work area as a local data object in the subroutine (name proposal: wa).

 

a) See source code excerpt in the model solution.

 

Task 2:

 

Call subroutine

 

1. After the sorting of the internal table, call the subroutine to output the table. a) See source code excerpt in the model solution.

2. Execute your program to test the result. a) Carry out this step as usual.

Result

 

Source code excerpt: SAPBC400PBS_SUBROUTINE

 

 

REPORT sapbc400pbs_subroutine.

CONTSTANTS actvt_display TYPE activ_auth VALUE ’03’. DATA: it_flight TYPE sbc400_t_sbc400focc,

wa_flight LIKE LINE OF it_flight. PARAMETERS pa_car TYPE s_carr_id.

 

Continued on next page


 

* Authority Check:

AUTHORITY-CHECK OBJECT ’S_CARRID’ ID ’CARRID’ FIELD pa_car

ID ’ACTVT’ FIELD actvt_display. CASE sy-subrc.

WHEN 0. " User is authorized

 

 

SELECT carrid connid fldate seatsmax seatsocc FROM sflight

INTO CORRESPONDING FIELDS OF wa_flight

WHERE carrid = pa_car.

 

 

wa_flight-percentage =

100 * wa_flight-seatsocc / wa_flight-seatsmax. APPEND wa_flight TO it_flight.

ENDSELECT.

 

 

IF sy-subrc = 0.

SORT it_flight BY percentage.


Дата добавления: 2015-11-16; просмотров: 68 | Нарушение авторских прав


<== предыдущая страница | следующая страница ==>
ID ’ACTVT’ FIELD ’02’.| Wa-percentage, ’%’.

mybiblioteka.su - 2015-2024 год. (0.104 сек.)