ABAP Objects Reference

titel.fm Seite 3 Freitag, 31.
Januar 2003 2:28 14
Horst Keller, Joachim Jacobitz
ABAP® Objects
Reference
A comprehensive guide to all
ABAP-language elements
in two volumes
Volume I & II
abapEAL.fm Seite 5 Freitag, 31. Januar 2003 12:51 12
Contents at a Glance
Volume I
Part 1 Syntax 29
Part 2 Program Structure 47
Part 3 Declarative Statements 107
Part 4 Generating Objects 193
Part 5 Calling and Exiting Program Units 209
Part 6 Program Flow Control 289
Part 7 Assignments 333
Part 8 Processing Internal Data 363
Volume II
Part 9 User Dialogs 503
Part 10 Processing External Data 699
Part 11 Program Parameters 847
Part 12 Program Processing 863
Part 13 External Programming Interfaces 885
Part 14 Obsolete Statements 907
Part 15 Appendix 987
Content at the Glance 5

abapIVZ.fm Seite 7 Freitag, 31. Januar 2003 12:51 12
Contents
Preface 17
1 Introduction and Overview 19

1.1 Purpose and Objective 19
1.2 Described Releases 19
1.3 SAP Basis and Web Application Server 19
1.4 ABAP and Unicode 20
1.5 Book Structure 22
1.6 Search Options 25
1.7 Syntax Diagrams 26
Part 1 Syntax 29
2 ABAP Syntax 31
2.1 ABAP Statements 31
2.2 ABAP Language Elements 31
2.2.1 Operators 32
2.2.2 Operands 33
2.2.3 Designations for Operands 33
2.2.4 Specifying Operands Statically or Dynamically 39
2.2.5 Data Objects in Operand Positions 40
2.3 Naming Conventions 43
2.4 Chained Statements 44
2.5 Comments 45
Part 2 Program Structure 47
3 Introductory Statements 49
3.1 Overview 49
3.2 Executable Programs 50
3.2.1 Additions for the Basic List of the Program 51
3.2.2 Addition for the Message Class 52
3.2.3 Addition for Defining a Logical Database 53
Contents 7
3.3 Module Pools and Subroutine Pools 53

3.4 Function Groups 54
3.5 Class Pools 54
3.6 Interface Pools 55
3.7 Type Groups 55
4 Modularization Statements 57
4.1 Overview 57
4.2 Procedures 58
4.2.1 Methods 58
4.2.2 Function Modules 59
4.2.3 Subroutines 60
4.3 Dialog Modules 65
4.4 Event Blocks 66
4.4.1 Program Constructor 66
4.4.2 Reporting Events 67
4.4.3 Selection Screen Events 72
4.4.4 List Events 78
4.5 Source Text Modularization 84
4.5.1 Include Programs 84
4.5.2 Macros 85
5 Built-In Types, Data Objects and Functions 89

5.1 Overview 89
5.2 Built-In Data Types 89
5.2.1 Built-In ABAP Types 89
5.2.2 Generic ABAP Types 93
5.2.3 Built-In Types in the ABAP Dictionary 94
5.2.4 Built-In Data Type “Cursor” 97
5.3 Built-In Data Objects 97
5.3.1 The Constant “space” 97
5.3.2 The Self-Reference “me” 98
5.3.3 System Fields 98
5.3.4 The “Screen” Structure 103
5.4 Built-In Functions 103
5.4.1 Mathematical Functions 103
5.4.2 Description Functions 105
8 Contents
Part 3 Declarative Statements 107
6 Declarative Statements for Data Types and Data Objects 109

6.1 Overview 109
6.1.1 Validity and Visibility 109
6.1.2 Data Types 110
6.1.3 Data Objects 110
6.1.4 Absolute Type Names 112
6.1.5 Statements for Declaring Data Types and Data Objects 115
6.2 Including Type Groups 115
6.3 Defining Data Types 116
6.3.1 Type Definitions with Built-In ABAP Types 117
6.3.2 Type Definition Through Reference to Existing Types 118
6.3.3 Defining Reference Types 118
6.3.4 Defining Structured Types 120
6.3.5 Defining Table Types 121
6.3.6 Defining a Range Table Type 124
6.4 Declaring Variables 125
6.4.1 Additions for Data Objects 126
6.4.2 Elementary Data Objects of Built-In ABAP Types 128
6.4.3 Data Objects of Existing Types 128
6.4.4 Declaring Reference Variables 129
6.4.5 Declaring Structures 130
6.4.6 Declaring Internal Tables 131
6.4.7 Defining a Ranges Table 133
6.5 Declaring Static Attributes of Classes 134
6.6 Declaring Constant Data Objects 135
6.7 Declaring Static Data Objects in Procedures 136
6.8 Copying Structure Components 137
6.9 Declaring the Table Work Areas 139
6.9.1 Flat Table Work Area 139
6.9.2 Any Table Work Area 140
6.10 Declaring Field Symbols 142
6.10.1 Typing Field Symbols 143
6.10.2 Casting a Structure 143
6.11 Declaring an Extract Dataset 144
Contents 9
7 Defining Classes and Interfaces 147

7.1 Overview 147
7.2 Defining Classes 147
7.2.1 Declaration Section 148
7.2.2 Implementation Section 155
7.2.3 Declaring Classes 156
7.3 Defining Interfaces 158
7.3.1 Declaration Section 158
7.3.2 Declaring Interfaces 159
7.4 Declaring Components in Classes and Interfaces 160
7.4.1 Methods 160
7.4.2 Events 178
7.4.3 Implementing and Integrating Interfaces 181
8 Typing 187
8.1 Overview 187
8.2 Syntax of Typing 187
8.2.1 Generic Typing 188
8.2.2 Complete Typing 189
8.3 Checking the Typing 190
8.3.1 General Rules 190
8.3.2 Literals as Actual Parameters 190
Part 4 Generating Objects 193
9 Generating Objects and Data Objects 195

9.1 Overview 195
9.2 Generating Data Objects 195
9.2.1 Defining the Data Type Implicitly 196
9.2.2 Defining the Data Type Through Built-In ABAP Types 197
9.2.3 Defining the Data Type Through an Existing Type 199
9.2.4 Generating Reference Variables 200
9.2.5 Generating Internal Tables 201
9.2.6 Treatable Exceptions When Generating Data Objects 203
9.3 Generating Objects in ABAP Objects 203
9.3.1 Defining the Class Implicitly 204
9.3.2 Defining the Class Explicitly 205
9.3.3 Static Parameter Transfer 206
9.3.4 Dynamic Parameter Passing 207
9.3.5 Treatable Exceptions When Generating Objects 208
10 Contents
Part 5 Calling and Exiting Program Units 209
10 Calling ABAP Programs 211

10.1 Overview 211
10.2 Calling Executable Programs 212
10.2.1 Flow of the Program Call 213
10.2.2 Additions for the Selection Screen 215
10.2.3 Additions for the Basic List 224
10.2.4 Additions for Background Processing 228
10.3 Calling Transactions 230
10.3.1 Calling a Transaction and Returning to the Calling Program 230
10.3.2 Calling a Transaction Without Returning to the Calling Program 238
11 Calling Processing Blocks 239

11.1 Overview 239
11.2 Calling Procedures 240
11.2.1 Overview 240
11.2.2 Method Calls 243
11.2.3 Calling Function Modules 255
11.2.4 Subroutine Call 264
11.3 Calling Event Handlers 269
11.3.1 Triggering Events 270
11.3.2 Registering Event Handlers 271
11.4 Calling Event Blocks 274
11.4.1 Triggering Events of a Logical Database 274
11.4.2 Triggering List Events 276
12 Exiting Program Units 279

12.1 Overview 279
12.2 Exiting Programs 279
12.3 Exiting Processing Blocks 280
12.3.1 Procedure for Exiting Processing Blocks 280
12.3.2 Exiting Processing Blocks with RETURN 281
12.3.3 Exiting Processing Blocks with EXIT 282
12.3.4 Exiting Processing Blocks with CHECK 283
12.3.5 Exiting GET Processing Blocks with REJECT 284
12.3.6 Exiting Processing Blocks of Executable Programs with STOP 285
12.4 Exiting Loops 286
12.4.1 Exiting Loops with EXIT 286
12.4.2 Exiting a Loop Pass with CONTINUE 287
12.4.3 Exiting a Loop Pass with CHECK 288
Contents 11
Part 6 Program Flow Control 289
13 Logical Expressions 291

13.1 Overview 291
13.2 Logical Expressions with Relational Operators 291
13.2.1 Relational Operators for All Data Types 291
13.2.2 Relational Operators for Character-Type Data Objects 296
13.2.3 Relational Operators for Byte-Like Data Types 298
13.2.4 Relational Operators for Bit Patterns 299
13.3 Determining the Interval Range 300
13.4 Checking States 300
13.4.1 Checking the Assignment to a Field Symbol 300
13.4.2 Checking the Validity of a Reference 301
13.4.3 Checking a Data Object for the Initial Value 302
13.4.4 Checking Output Parameters for Actual Parameters 303
13.4.5 Checking Formal Parameters for Actual Parameters 303
13.5 Evaluating a Selection Table 304
13.6 Boolean Operators and Parenthetical Expressions 307
13.6.1 Linking Logical Expressions with AND 307
13.6.2 Linking Logical Expressions with OR 307
13.6.3 Negating a Logical Expression with NOT 308
13.6.4 Parenthetical Expressions 308
14 Control Structures 311

14.1 Overview 311
14.2 Branching 311
14.2.1 Branching with IF 312
14.2.2 Branching with CASE 313
14.3 Loops 314
14.3.1 Unconditional Loops with DO 314
14.3.2 Conditional Loops with WHILE 317
15 Exception Handling 319

15.1 Overview 319
15.1.1 Treatable Exceptions Prior to Release 6.10 319
15.1.2 Treatable Exceptions in Release 6.10 and Later 319
15.1.3 Statements for Exceptions 320
15.2 Class-Based Exceptions 320
15.2.1 Exception Classes 320
15.2.2 Triggering Class-Based Exceptions 322
12 Contents
15.2.3 System Response to a Class-Based Exception 322

15.2.4 Handling Class-Based Exceptions 324
15.3 Non-Class-Based Exceptions 327
15.3.1 Defining Non-Class-Based Exceptions 327
15.3.2 Triggering Non-Class-Based Exceptions 327
15.3.3 Handling Non-Class-Based Exceptions 328
15.4 Catchable Runtime Errors 328
15.4.1 Defining Catchable Runtime Errors 328
15.4.2 Triggering Catchable Runtime Errors 329
15.4.3 Handling Catchable Runtime Errors 329
Part 7 Assignments 333
16 Value Assignments 335

16.1 Overview 335
16.2 Assigning Data Objects 336
16.2.1 Assignment with Keyword 336
16.2.2 Assignment with Assignment Operator 336
16.2.3 Multiple Assignments 337
16.3 Assigning Structure Components 338
16.4 Formatted Assignment 339
16.5 Converting Packed Numbers 341
17 Setting References 343

17.1 Overview 343
17.2 Assigning Data Objects to Field Symbols 343
17.2.1 Specifying a Memory Area 344
17.2.2 Specifying the Data Type 350
17.2.3 Specifying the Range Limits 353
17.3 Initializing Field Symbols 356
17.4 Retrieving a Data Reference 356
18 Initializing Data Objects 359

18.1 Overview 359
18.2 Initializing Any Data Objects 359
18.2.1 Initializing with the Initial Value 359
18.2.2 Initializing with Other Contents 360
18.3 Initializing Internal Tables 361
18.4 Releasing Memory 362
Contents 13
Part 8 Processing Internal Data 363
19 Calculation Expressions 365

19.1 Overview 365
19.2 The COMPUTE Statement 365
19.3 Arithmetic Expressions 366
19.3.1 Arithmetic Operators 367
19.3.2 Compounding 367
19.3.3 Priority of Functional Methods 368
19.3.4 Calculation Type 368
19.3.5 Treatable Exceptions in Arithmetic Expressions 370
19.4 Bit Expressions 370
19.4.1 Bit Operators 371
19.4.2 Compounding 372
20 Calculation Statements 373

20.1 Overview 373
20.2 Addition 373
20.3 Subtraction 374
20.4 Multiplication 374
20.5 Division 375
21 Processing Byte/Character Strings 377

21.1 Overview 377
21.1.1 Byte Strings and Character Strings 377
21.1.2 Statements for Processing Byte/Character Strings 377
21.1.3 Operands in Byte/Character String Processing 378
21.1.4 Treating Trailing Blanks During Character String Processing 379
21.2 Concatenating Byte and Character Strings 380
21.3 Searching Byte and Character Strings 381
21.3.1 Searching with FIND 381
21.3.2 Searching with SEARCH 384
21.4 Replacing Byte and Character Strings 388
21.4.1 Position-Based Replacement 389
21.4.2 Pattern-Based Replacement 390
21.5 Shifting Byte and Character Strings 392
21.5.1 Number of Places 393
21.5.2 Shifting Direction 395
21.5.3 Shifting Certain Characters Out of the Field 395
21.6 Splitting Byte and Character Strings 396
14 Contents
21.7 Condensing Character Strings 398

21.8 Converting Character Strings 399
21.9 Overlaying Character Strings 401
21.10 Converting Character Strings 402
21.10.1 Converting Upper/Lowercase 402
21.10.2 Pattern-Based Conversion 403
21.11 Setting and Reading Bits 404
21.11.1 Setting Single Bits in Byte Strings 404
21.11.2 Reading Single Bites from Byte Strings 405
22 Processing Internal Tables 407

22.1 Overview 407
22.2 Reading Internal Tables 408
22.2.1 Reading Single Lines 408
22.2.2 Loop Processing for Internal Tables 418
22.2.3 Control Level Processing 422
22.2.4 Summation in Control Levels 425
22.3 Filling Internal Tables 426
22.3.1 Inserting Lines 426
22.3.2 Inserting Condensed Lines 431
22.3.3 Appending Lines 433
22.4 Processing Table Lines 437
22.4.1 Changing Lines 437
22.4.2 Deleting Lines 442
22.4.3 Sorting 448
22.5 Specifying Components 451
22.6 Reading Attributes of Internal Tables 452
22.7 Searching Internal Tables 454
22.7.1 Search Options 455
22.8 Processing Special Internal Tables 456
22.9 Editing Tables 461
23 Processing Extract Datasets 463

23.1 Introduction 463
23.2 Defining the Row Structure 463
23.3 Filling the Extract Dataset 465
23.4 Sorting the Extract Dataset 466
23.5 Reading the Extract Dataset 468
23.6 Control Level Processing 469
Contents 15
24 Attributes of Data Objects 473

24.1 Overview 473
24.2 Attributes of Any Data Objects 473
24.2.1 Length of the Data Object 474
24.2.2 Output Length 474
24.2.3 Data Type and Number of Components 475
24.2.4 Decimal Places 477
24.2.5 Conversion Routines 477
24.2.6 Help Text 477
24.3 Attributes of Internal Tables 479
24.3.1 Table Type 479
24.3.2 Initial Memory Requirements 480
24.3.3 Number of Rows 480
24.4 Distance Between Data Objects 481
16 Contents
abapIV2.fm Seite 491 Freitag, 31. Januar 2003 12:56 12
Contents
Part 9 User Dialogs 503
25 Dynpros 505
25.1 Overview 505
25.2 Flow Logic Statements 506
25.2.1 Flow Logic Event Blocks 508
25.2.2 Calling Dialog Modules 509
25.2.3 Controlling Data Transfer 511
25.2.4 Processing Chains 514
25.2.5 Table Controls 516
25.2.6 Calling a Subscreen 519
25.3 ABAP Statements for Dynpros 522
25.3.1 Calling Dynpro Sequences 523
25.3.2 Setting the Next Dynpro 524
25.3.3 Setting the GUI Status 524
25.3.4 Determining the GUI Status 526
25.3.5 Setting the GUI Title 528
25.3.6 Determining Attributes of Dynpro Fields 529
25.3.7 Modifying Attributes of Dynpro Fields 531
25.3.8 Setting the Cursor 532
25.3.9 Determining the Cursor Position 535
25.3.10 Declaring a Control 537
25.3.11 Initializing a Control 543
25.3.12 Exiting the Step Loop 543
25.3.13 Holding Field Contents 544
25.3.14 Suppressing the Display 545
25.3.15 Leaving a Dynpro 545
26 Selection Screens 547

26.1 Overview 547
26.1.1 Selection Screens as Dynpros 547
26.1.2 Selection Screen Tasks 547
26.1.3 GUI Status of Selection Screens 547
26.1.4 Selection Screen Events 548
26.1.5 Selection Screens and Logical Databases 548
26.1.6 Statements for Selection Screens 548
26.2 Creating and Laying Out Selection Screens 548
26.2.1 Creating Selection Screens 549
26.2.2 Laying Out Selection Screens 552
26.2.3 Adopting Elements of Other Selection Screens 566
26.2.4 Variants and Additions for Selection Screens of Logical Databases 570
Contents 491
26.3 Defining Parameters 574

26.3.1 Data Type of the Parameter 576
26.3.2 Attributes of Screen Elements 579
26.3.3 Attributes of the Value and the Passing of Values 584
26.3.4 Additions for Selection Screens of Logical Databases 587
26.4 Defining Selection Criteria 590
26.4.1 Data Type of the LOW and HIGH Selection Table Columns 593
26.4.2 Attributes of Screen Elements 595
26.4.3 Attributes of the Value and Passing of Values 598
26.4.4 Additions for Selection Screens of Logical Databases 600
26.4.5 Enabling User-Defined Field Help 600
26.5 Calling Selection Screens 601
26.5.1 Calling Via SUBMIT 602
26.5.2 Calling Via a Report Transaction 602
26.5.3 Calling Via a Dialog Transaction 602
26.5.4 Calling in the Program 602
26.5.5 Selection Screen Processing 604
27 Lists 605
27.1 Overview 605
27.1.1 Lists as Screens 605
27.1.2 Lists in the ABAP Program 605
27.1.3 Basic List 605
27.1.4 Details Lists 605
27.1.5 The Structure of a List 606
27.1.6 Print Lists 607
27.1.7 Lists and ABAP Objects 607
27.1.8 Lists and Unicode 607
27.1.9 Statements for List Processing 608
27.2 Creating Lists 609
27.2.1 Writing Data in Lists 609
27.2.2 Creating Horizontal Lines 634
27.2.3 Formatting Lists Section by Section 635
27.2.4 Displaying Blank Lines 642
27.2.5 Vertical Positioning of the List Cursor 643
27.2.6 Horizontal Positioning of the List Cursor 648
27.2.7 Fixed Areas When Scrolling Horizontally 649
27.2.8 Page Breaks and Print Lists 650
27.2.9 Conditional Page Breaks 658
27.2.10 Saving Variables with List Lines 659
27.2.11 Print List Page Margins 661
27.2.12 Controlling Print Lists 661
27.3 Processing Lists in the List Buffer 665
27.3.1 Reading List Lines 665
27.3.2 Modifying List Lines 668
492 Contents
27.3.3 Scrolling Lists 670

27.3.4 Reading List Attributes 673
27.4 Evaluating the Displayed List at the Cursor Position 676
27.5 Display Attributes of Screen Lists 678
27.5.1 GUI Status of a Screen List 678
27.5.2 Title of a Screen List 680
27.5.3 Setting the Cursor 680
27.5.4 Lists in a Dialog Box 683
27.6 Calling and Exiting List Displays 684
27.6.1 Calling the Basic List Display 685
27.6.2 Exiting the List Display 686
28 Messages 689
28.1 Overview 689
28.1.1 Storing Messages 689
28.1.2 Message Types 689
28.2 Sending Messages 692
28.2.1 Variant 1 692
28.2.2 Variant 2 693
28.2.3 Variant 3 693
28.2.4 Variant 4 694
28.2.5 Addition Options 695
Part 10 Processing External Data 699
29 Open SQL 701

29.1 Overview 701
29.1.1 Scope of Open SQL 701
29.1.2 Database Interface 701
29.1.3 Database Access 701
29.1.4 Client Handling 701
29.1.5 SAP Buffering 701
29.1.6 LUW 702
29.1.7 Open SQL Statements 702
29.2 Reading Data from Database Tables 702
29.2.1 Determining the Structure of the Result Set 704
29.2.2 Specifying Database Tables to Be Read 711
29.2.3 Specifying the Target Area 717
29.2.4 Restricting the Result Set 722
29.2.5 Combining Lines 734
29.2.6 Restricting Combined Lines 735
29.2.7 Sorting Result set Lines 736
Contents 493
29.3 Reading Data from Database Tables Using a Cursor 739

29.3.1 Open Cursor 739
29.3.2 Reading Data Using a Cursor 740
29.3.3 Close Cursor 742
29.4 Inserting Data into Database Tables 743
29.4.1 Specifying the Database Table 744
29.4.2 Specifying the Source 745
29.5 Changing Data in Database Tables 747
29.5.2 Specifying Changes 749
29.6 Inserting or Changing Data in Database Tables 754
29.6.2 Specifying the Source 755
29.7 Deleting Data in Database Tables 756
29.7.2 Specifying Lines 757
29.8 Work Areas in Open SQL Statements 760
29.9 Treatable Exceptions in Open SQL Statements 761
30 Native SQL 763

30.1 Overview 763
30.2 Including Native SQL 763
30.2.1 Host Variables 765
30.2.2 Processing Cursors 766
30.2.3 Calling Database Procedures 768
30.2.4 Defining the Database Connection 769
30.2.5 Implicit Cursor Processing 772
30.3 Leaving Native SQL 773
30.4 Treatable Exceptions in Native SQL 774
31 Data Clusters 775

31.1 Overview 775
31.2 Creating Data Clusters 775
31.2.1 Defining the Data Cluster 776
31.2.2 Defining the Storage Medium 777
31.2.3 Controlling Compression 782
31.2.4 Treatable Exceptions During the Export of Data Clusters 782
31.3 Reading Data Clusters 783
31.3.1 Specifying the Data Objects to Be Read 783
31.3.2 Defining the Storage Medium 785
31.3.3 Conversion Additions 788
494 Contents
31.3.4 Treatable Exceptions During the Import from Data Clusters 795
31.4 Reading the Directory of a Data Cluster 795
31.5 Deleting a Data Cluster 797
31.6 Deleting a Data Cluster in the ABAP Memory 798
32 The ABAP File Interface 799

32.1 Overview 799
32.1.1 Addressing Files 799
32.1.2 Authorizations for Accessing Files 799
32.1.3 Locks 801
32.1.4 The File Interface in Unicode Programs 801
32.1.5 File Size 803
32.1.6 File Interface Statements 803
32.2 Opening a File 803
32.2.1 Defining the Access Type 804
32.2.2 Defining the Storage Type 805
32.2.3 Specifying the Position 810
32.2.4 Operating System-Dependent Additions 811
32.2.5 Error Handling 813
32.2.6 Treatable Exceptions When Opening Files 815
32.3 Writing a File 815
32.3.1 The Influence of Access Type 816
32.3.2 The Influence of Storage Type 816
32.3.3 Restricting the Number of Transferred Characters or Bytes 818
32.3.4 Treatable Exceptions When Writing to Files 818
32.4 Reading a File 819
32.4.1 The Influence of Access Type 820
32.4.2 The Influence of Storage Type 820
32.4.3 Restricting the Number of Imported Characters or Bytes 821
32.4.4 Determining the Number of Imported Characters or Bytes 823
32.4.5 Treatable Exceptions When Reading Files 823
32.5 Determining the Attributes of an Opened File 823
32.5.1 Determining the Position of the File Pointer 824
32.5.2 Determining Other Attributes 825
32.5.3 Treatable Exceptions When Determining File Attributes 827
32.6 Changing the Attributes of an Opened File 827
32.6.1 Defining the Position of the File Pointer 828
32.6.2 Changing Other Attributes 829
32.6.3 Treatable Exceptions When Changing File Attributes 831
32.7 Closing a File 832
32.8 Deleting a File 833
Contents 495
33 Data Consistency 835

33.1 Overview 835
33.2 Database LUW 835
33.2.1 Database Commit 836
33.2.2 Database Rollback 837
33.3 SAP LUW 837
33.3.1 SAP Commit 838
33.3.2 SAP Rollback 840
33.3.3 Local Updating 841
33.4 Database Locks 842
33.5 SAP Locks 842
33.5.1 Imposing SAP Locks 842
33.5.2 Lifting SAP Locks 843
33.6 Authorization Check 844
Part 11 Program Parameters 847
34 Parameters in the SAP Memory 849

34.1 Overview 849
34.2 Setting Parameters 849
34.3 Reading Parameters 850
35 Language Environment 851

35.1 Overview 851
35.2 Setting the Language of Text Elements 851
35.3 Setting the Text Environment 852
35.4 Determining the Text Environment 854
35.5 Setting Country Identification 855
36 Time Stamp 857

36.1 Overview 857
36.2 Current Time Stamp 858
36.3 Processing Time Stamps 858
36.3.1 Expanding Time Stamps 859
36.3.2 Creating Time Stamps 859
36.3.3 Explanation of the Addition Option 859
36.4 Current Time 861
496 Contents
Part 12 Program Processing 863
37 Testing and Checking Programs 865

37.1 Overview 865
37.2 Setting Breakpoints 865
37.3 Measuring Runtime 866
37.3.1 Relative Program Runtime 866
37.3.2 Setting Time Resolution 867
37.3.3 Measuring Section for Runtime Analysis 868
37.4 Avoiding the Extended Program Check 869
38 Generating Programs Dynamically 871

38.1 Overview 871
38.2 Dynamic Subroutine Pool 872
38.3 Reading an ABAP Program 875
38.4 Checking Syntax 876
38.5 Creating an ABAP Program 878
38.6 Reading a Text Pool 881
38.7 Creating a Text Pool 882
38.8 Calling the ABAP Editor 883
Part 13 External Programming Interfaces 885
39 Remote Function Call 887

39.1 Overview 887
39.1.1 Introduction 887
39.1.2 Destination 888
39.1.3 System Fields in RFC 889
39.1.4 Exceptions in RFCs 889
39.1.5 RFC Authorization 889
39.1.6 Inadmissible Actions 890
39.1.7 RFC Interface Statements 890
39.2 Calling Remote Functions 890
39.2.1 Synchronous Remote Function Call 891
39.2.2 Asynchronous Remote Function Call 892
39.2.3 Transactional Remote Function Call 899
Contents 497
40 XSLT Transformations 901

40.1 Overview 901
40.2 Call 901
40.2.1 Specifying the Transformation 902
40.2.2 Transformation Source 902
40.2.3 Transformation Result 903
40.2.4 Explanation of Addition Options 903
Part 14 Obsolete Statements 907
41 Obsolete Statements 909

41.1 Overview 909
41.2 Obsolete Syntax 909
41.3 Obsolete Modularization 910
41.3.1 Obsolete Event Block 910
41.4 Obsolete Declarations 910
41.4.1 Obsolete Interface Work Areas 910
41.4.2 Obsolete Declarations of Internal Standard Tables 913
41.4.3 Obsolete Declarations of Special Internal Tables 915
41.4.4 Obsolete Note for the Extended Program Check 917
41.5 Obsolete Object Creation 918
41.6 Obsolete Program Call 920
41.7 Obsolete Exiting of a Program 922
41.8 Obsolete Flow Control 923
41.8.1 Obsolete Relational Operators 923
41.8.2 Obsolete Branching 924
41.9 Obsolete Assignments 925
41.9.1 Obsolete Assignment of a Percentage Subfield 925
41.9.2 Obsolete Conversion 926
41.9.3 Obsolete Temporary Storage of Data Objects 927
41.10 Obsolete Calculation Statements 928
41.10.1 Addition of Field Sequences in the Memory 928
41.10.2 Adding Component-by-Component 930
41.10.3 Subtracting Component-by-Component 931
41.10.4 Multiplying Component by Component 932
41.10.5 Dividing Component by Component 933
41.10.6 Obsolete Calculations During List Creation 933
41.11 Obsolete Character String Processing 936
41.11.1 Obsolete Translation 936
41.11.2 Obsolete Replacement 938
41.11.3 Complement on Nine of a Date 940
498 Contents
41.12 Obsolete Processing of Internal Tables 941

41.12.1 Obsolete Key Specification When Reading Rows 941
41.12.2 Obsolete Assignment of Table Lines 944
41.12.3 Obsolete Form of the PROVIDE Statement 946
41.13 Contexts 949
41.13.1 Overview 949
41.13.2 Creating Instances of Contexts 950
41.13.3 Providing Contexts with Key Values 950
41.13.4 Querying Contexts 951
41.14 Obsolete Statements in the Flow Logic of Dynpros 953
41.14.1 Checking Values in Flow Logic 953
41.14.2 Processing Step Loops 955
41.15 Obsolete Statements in List Processing 960
41.15.1 Obsolete Formatting Statements 960
41.15.2 Obsolete Print Parameters 961
41.16 Obsolete Database Accesses 963
41.16.1 Obsolete Reading of a Row 963
41.16.2 Obsolete Sequential Reading of Several Rows 966
41.16.3 Obsolete Reading of Several Rows in an Internal Table 967
41.16.4 Obsolete Short Forms in Open SQL 968
41.17 Obsolete External Programming Interfaces 970
41.17.1 CPI-C Interface 970
41.17.2 OLE Interface 977
Part 15 Appendix 987
A Conversion Rules for Assignments 989

A.1 Overview 989
A.2 Conversion Rules for Elementary Data Types 989
A.2.1 Presenting Numeric Values in Character-Like Fields 990
A.2.2 Conversion Table for Source Field Type c 991
A.2.3 Conversion Table for Source Field Type d 992
A.2.4 Conversion Table for Source Field Type f 993
A.2.5 Conversion Table for Source Field of Types i, b, or s 994
A.2.6 Conversion Table for Source Field Type n 996
A.2.7 Conversion Table for Source Field Type p 997
A.2.8 Conversion Table for Source Field Type string 998
A.2.9 Conversion Table for Source Field Type t 999
A.2.10 Conversion Table for Source Field Type x 1000
A.2.11 Conversion Table for Source Field Type xstring 1001
A.3 Conversion Rules for Structures 1001
A.3.1 Conversion Between Flat Structures 1002
A.3.2 Conversion Between Flat Structures and Single Fields 1006
A.4 Conversion Rules for Internal Tables 1007
Contents 499
A.5 Assignments Between Reference Variables 1007

A.5.1 Static and Dynamic Types 1008
A.5.2 Narrowing Cast and Widening Cast 1008
A.5.3 Assignments Between Data Reference Variables 1009
A.5.4 Assignments Between Object Reference Variables 1010
B Low-Level Classes and Interfaces 1013

B.1 Auxiliary Classes 1013
B.2 Run Time Type Identification Classes 1013
B.3 Classes for Converting External Data Formats 1013
B.4 Class for Extreme Values of Data Objects 1014
B.5 Class for the Properties of Characters 1014
B.6 Class for Mathematical Operations 1014
B.7 Class for Time Stamp 1015
B.8 Classes for Data Clusters 1015
B.9 Class for Transactions 1016
B.10 Class for Processing Lists 1016
B.11 Object Services 1016
B.12 JavaScript Integration 1017
C Low-Level Function Modules 1019

C.1 Function Modules for Print Parameters 1019
C.1.1 GET_PRINT_PARAMETERS 1019
C.1.2 SET_PRINT_PARAMETERS 1022
C.2 Function Modules for Files on the Presentation Server 1022
C.3 Function Modules for Calling Logical Databases 1022
D Predefined Treatable Exceptions 1025

D.1 Overview 1025
D.2 Predefined Exception Classes 1025
D.3 Catchable Runtime Errors 1028
D.3.1 Exception Groups for Arithmetic Errors 1028
D.3.2 Exception Group for Conversion Errors 1029
D.3.3 Exception Group for Errors When Creating Data Objects 1030
D.3.4 Exception Group for Errors When Creating Instances of Classes 1030
D.3.5 Exception Group for Errors When Accessing Data Objects 1030
D.3.6 Exception Group for Errors in Dynamic Method Calls 1031
D.3.7 Exception Group for Errors When Accessing Files 1032
D.3.8 Exception Group for Errors When Accessing Data Clusters 1032
500 Contents
D.3.9 Exception Group for Errors in the Language Environment 1033

D.3.10 Exception Group for Errors with Remote Function Calls 1033
D.3.11 Catchable Runtime Errors That Are Not Assigned to Any Group 1033
E Notes on the CD ROMs 1035
F Glossary 1037
Index 1079
Contents 501
KAP07.fm Seite 147 Freitag, 31. Januar 2003 2:28 14
7 Defining Classes and Interfaces
7.1 Overview
This chapter describes the definition of classes and interfaces, as well as
their components. Classes and interfaces are the foundation of ABAP
Objects, the object-oriented component of the ABAP language. You can
define classes and interfaces in ABAP programs with the following pro-
gram types (see Table 3.1):
왘 In a class pool, you can use the Class Builder in the ABAP Workbench to
define one global class of the class library. This global class can be used
in all other ABAP programs. You can also define local classes and inter-
faces in a class pool, for use in the class pool itself.
왘 In an interface pool, you can use the Class Builder in the ABAP Work-
bench to define one global interface of the class library. This global
interface can be used in all other ABAP programs. You cannot define
local classes or interfaces in an interface pool.
왘 In all other ABAP programs (except type groups), you can define local
classes and interfaces for use in the program itself.
In addition to the declarations described in Chapter 6, you can declare

additional components within classes and interfaces. These components
are also described in this chapter.
The statements for declaring classes and interfaces are:
Statement Section
CLASS 7.2
INTERFACE 7.3
METHODS, CLASS-METHODS 7.4.1
EVENTS, CLASS-EVENTS 7.4.2
INTERFACES, ALIASES 7.4.3
7.2 Defining Classes
CLASS
The full definition of a class consists of a declaration section and an imple-

mentation section, both of which you introduce with CLASS. You define
Defining Classes and Interfaces 147

the properties of a class and declare its components in the declaration

section. You implement the methods of the class in the implementation
section. You use other variants of CLASS to declare classes in a program.
7.2.1 Declaration Section

Defines a class and declares its components.
Syntax
CLASS class DEFINITION [PUBLIC]
[ INHERITING FROM superclass]
[ ABSTRACT]
[ FINAL]
[ CREATE {PUBLIC|PROTECTED|PRIVATE}]
[[ GLOBAL] FRIENDS [classi] [ifaci]].
[PUBLIC SECTION].
[components]
[PROTECTED SECTION].
[components]
[PRIVATE SECTION].
[components]
ENDCLASS.
The statement block CLASS class DEFINITION – ENDCLASS defines a

class. You declare components of the class, components, between
CLASS and ENDCLASS. You have to specify each component after one of
the statements PUBLIC SECTION, PROTECTED SECTION, or PRIVATE
SECTION, and you have to list those in the specified order. A class does
not have to contain all the SECTION statements.
You can use the additions of the CLASS statement to publish a class glo-
bally in the class library, define an inheritance relationship, make the class
abstract or final, define whether it can be instantiated, and offer friendship
to other classes and/or interfaces.
7.2.1.1 Visibility Areas
Public visibility area

Syntax
PUBLIC SECTION.
This statement defines the public visibility area of class class. All class
components that you declare in the area after the PUBLIC SECTION
statement can be addressed from outside the class, from within its sub-
classes, and within the class itself.

Protected visibility area

Syntax
PROTECTED SECTION.
This statement defines the protected visibility area of class class. All
class components that you declare in the area after the PROTECTED SEC-
TION statement can be addressed in the subclasses of the class and within
the class itself.
Private visibility area

Syntax
PRIVATE SECTION.
This statement defines the private visibility area of class class. All class
components that you declare in the area after the PRIVATE SECTION
statement can be addressed only within the class itself.
7.2.1.2 Class Components
Syntax
components.
You define the components of the classes in the visibility areas. The fol-
lowing declaration statements are possible for components:
왘 TYPE-POOLS, TYPES, DATA, CLASS-DATA, and CONSTANTS for data

types and data objects (see Chapter 6)
왘 METHODS, CLASS-METHODS, EVENTS, and CLASS-EVENTS for methods
and events (see Section 7.4)
왘 INTERFACES for implementing interfaces and ALIASES for alias names
of interface components (see Section 7.4)
Note
All the components of a class lie within one namespace. The name of a
component must be unique within a class, regardless of its type (data
type, attribute, method, event, or alias name). The components of an
implemented interface differ from the directly declared components of
the class through prefix ifac~ (name of the interface with the interface
component selector).
Defining Classes 149

7.2.1.3 Global Classes
Syntax
... PUBLIC ...
When you use the addition PUBLIC, the class becomes a global class of
the class library. The addition PUBLIC is possible for only one class of a
class pool and is generated by the Class Builder when you create a global
class. All classes without the addition PUBLIC are local classes of their
program.
Note
You cannot use the TYPES statement to declare separate data types in the
public visibility area of a global class. Moreover, you can use only globally
declared data types there.
7.2.1.4 Defining Subclasses
Syntax
... INHERITING FROM superclass ...
If you use the addition INHERITING FROM, the class is derived from the
superclass superclass through inheritance, and therefore becomes its
direct subclass. The superclass superclass can be any non-final class that
is visible at this point.
Each class can have only one direct superclass, but can have several direct
subclasses (simple inheritance). Any class without the addition INHERIT-
ING FROM implicitly inherits from the predefined empty class object.
Taken together, all the classes in ABAP Objects form an inheritance tree, in
which a clearly defined path exists from each class to the root node,
object.
The class class inherits the components of its superclass superclass

without changing their visibility area. Only the components of the public
and protected visibility areas of the superclass are visible in the subclass.
The attributes of the inherited components cannot be changed. You can
also declare additional components in a subclass and redefine inherited
methods—that is, you can re-implement them without changing the
interface.

Note
The public and protected components of all the classes within a path of
the inheritance tree all lie within the same namespace. New components
in a subclass may not have names that are identical to public or protected
components that were inherited from the superclasses.
7.2.1.5 Abstract Classes
Syntax
... ABSTRACT ...
The addition ABSTRACT defines an abstract class, class. You cannot gen-
erate instances of an abstract class. To use the instance components of an
abstract class, you have to instantiate a non-abstract subclass of the class.
7.2.1.6 Final Classes
Syntax
... FINAL ...
The addition FINAL defines a final class class. You cannot derive sub-
classes of a final class. All methods of a final class are implicitly final, which
means that you cannot explicitly declare them as final.
Note
If a class is both abstract and final, you can use only its static components.
While you can declare instance components, you cannot use them.
Example
In the example below, an abstract class c1 and a final class c2 are defined,
and c2 inherits from c1. c1 is implicitly a subclass of the blank class
object. You can access m1 in c2, but a1.
CLASS c1 DEFINITION ABSTRACT.

PROTECTED SECTION.
METHODS m1.
PRIVATE SECTION.
DATA a1 TYPE string
VALUE `Attribute A1 of class C1`.
ENDCLASS.
CLASS c2 DEFINITION INHERITING FROM c1 FINAL.

PUBLIC SECTION.

METHODS m2.
ENDCLASS.
CLASS c1 IMPLEMENTATION.
METHOD m1.
WRITE / a1.
ENDMETHOD.
ENDCLASS.
METHOD m2.
m1( ).
ENDMETHOD.
ENDCLASS.
...
DATA oref TYPE REF TO c2.
CREATE OBJECT oref.

oref->m2( ).
7.2.1.7 Instantiation
Syntax
... CREATE {PUBLIC|PROTECTED|PRIVATE} ...
The addition CREATE defines the context in which class can be instanti-
ated—that is, where the CREATE OBJECT statement can be executed for
that class.
왘 A class with the addition CREATE PUBLIC can be instantiated wher-

ever that class is visible.
왘 A class with the addition CREATE PROTECTED can be instantiated only
within methods of its subclasses and within the class itself.
왘 A class with the addition CREATE PRIVATE can be instantiated only
within methods the class itself. This means that you cannot instantiate
them as inherited components of subclasses, either.
Whether or not a class can be instantiated also depends on its direct

superclass:
왘 Direct subclasses of object or a class with addition CREATE PUBLIC

implicitly inherit the addition CREATE PUBLIC. You can explicitly spec-
ify any CREATE addition to override the inherited one.

왘 Direct subclasses a class with addition CREATE PROTECTED implicitly

inherit the addition CREATE PROTECTED. You can explicitly specify any
CREATE addition to override the inherited one.
왘 Direct subclasses of a class with addition CREATE PRIVATE that are not
friends of that class are explicitly assigned the addition CREATE NONE.
You cannot instantiate these classes, nor can you specify any explicit
CREATE additions. Direct subclasses that are friends of the class implic-
itly inherit the addition CREATE PRIVATE. You can explicitly specify all
CREATE additions for friends of superclasses that can be instantiated as
private to override the inherited one.
Note
If a class can be instantiated as private, we recommend making it final as
well, as its subclasses cannot be instantiated if they are not friends of the
class.
7.2.1.8 Friends
Syntax
... [GLOBAL] FRIENDS [classi] [ifaci].
The addition FRIENDS makes class class a friend of classes classi and/
or interfaces ifaci. At the same time, all subclasses of classes classi, all
classes that implement one of the interfaces ifaci, and all interfaces that
have one of the interfaces ifaci as a component interface become friends
of class. You have to specify at least one class or interface.
The friends of a class have unrestricted access to the protected and private
components of that class, and can generate unrestricted instances of the
class.
The friends of class are not automatically friends of subclasses of class.

Moreover, the addition FRIENDS does not make class a friend of its
friends.
If you do not use the GLOBAL additions, you can specify all classes and
interfaces for classi and ifaci that are visible at this point. If you define
global classes and interfaces in the class library as friends, please note that
in these objects the local classes of other ABAP programs are not visible.
In such cases, static access to the components of class is not possible.
The addition GLOBAL is allowed only when you use the addition PUBLIC—
for the global class of a class pool—at the same time. You can list other

global classes and interfaces from the class library after GLOBAL FRIENDS.
This addition is generated when the Class Builder creates a global class
and you have specified friends at the corresponding tab page of the Class
Builder.
Example
In the example below, class c2 is a friend of interface i1, and therefore
also of the implementing class c1. It can instantiate these objects and
access their private component a1.
INTERFACE i1.
...
ENDINTERFACE.
CLASS c1 DEFINITION CREATE PRIVATE FRIENDS i1.

PRIVATE SECTION.
DATA a1(10) TYPE c VALUE 'Class 1'.
ENDCLASS.
CLASS c2 DEFINITION.
PUBLIC SECTION.
INTERFACES i1.
METHODS m2.
ENDCLASS.
METHOD m2.
CREATE OBJECT oref.
WRITE oref->a1.
ENDMETHOD.
ENDCLASS.
Local friends of global classes

A separate statement exists for this situation.
Syntax
CLASS class DEFINITION LOCAL FRIENDS [classi] [ifaci].
This statement turns the local classes and interfaces of a class pool,
classi and ifaci, into friends of its global class. You have to specify at
least one class or interface.

This section does not introduce a declaration section, and you cannot
complete it with ENDCLASS. You have to specify it in the class pool before
the definition of the local classes and interfaces, classi and ifaci, if you
want them to have access to the private and protected components of the
global class, class.
7.2.2 Implementation Section

Implements the methods of a class.
Syntax
CLASS class IMPLEMENTATION.
...
METHOD ...
...
ENDMETHOD.
...
ENDCLASS.
In the statement block CLASS class IMPLEMENTATION – ENDCLASS, you

have to implement the following methods of a class (in any sequence):
왘 All non-abstract methods that are declared in the declaration section of

the class with METHODS or CLASS-METHODS
왘 All non-abstract methods of interfaces that are declared in the declara-
tion section of the class with the INTERFACES statement
왘 All the methods inherited from superclasses that are listed in the decla-
ration segment of the class with the statement METHODS ... REDEF-
INITION
The implementation of each method corresponds to a METHOD – END-
METHOD processing block (see Section 4.2.1). No statements are allowed
outside of method implementations in the implementation section.
Within a method implementation, you can access all the components in
instance methods and all static components of their own class in static
methods. The component selector is not necessary to address compo-
nents in their own class. An implicitly generated local reference variable
called me is available in the implementation of every instance method. me
points to the current instance of the method.
Note
A class that—in accordance with its declaration section—does not have
to implement any methods has either a blank implementation section or
none at all.

Example
In the following example, three methods of class c2 have to be imple-
mented. Method m1 in c1 is abstract and does not have to be imple-
mented.
INTERFACE i1.
METHODS m1.
ENDINTERFACE.
CLASS c1 DEFINITION ABSTRACT.

PROTECTED SECTION.
METHODS m1 ABSTRACT.
ENDCLASS.
CLASS c2 DEFINITION INHERITING FROM c1.

PUBLIC SECTION.
INTERFACES i1.
METHODS m2.
PROTECTED SECTION.
METHODS m1 REDEFINITION.
ENDCLASS.
METHOD m1.
...
ENDMETHOD.
METHOD m2.
...
ENDMETHOD.
METHOD i1~m1.
...
ENDMETHOD.
ENDCLASS.
7.2.3 Declaring Classes

In some cases, you have to explicitly declare the definition of a class
before you can use it.
Syntax
CLASS class DEFINITION { DEFERRED | LOAD }.

The two variants of the CLASS statement serve to declare a class class in
the program independently of the location of the actual definition. They
do not introduce a declaration section, and you cannot complete them
with ENDCLASS. The additions have the following meanings:
왘 The variant with addition DEFERRED declares a local class before its
actual definition in the program. The program has to have a declaration
section for class later in the program. This statement is required if
you want to refer to a class before it is actually defined. Access to indi-
vidual components is not possible before the actual definition.
왘 The variant with addition LOAD loads a global class from the class
library. This statement is required prior to Release 6.40 if you want to
access one of the static components of class within a program, or if
you want to declare an event handler for class before class is loaded
automatically. All other accesses load class automatically. In Release
6.40 and later, the addition LOAD is required only when the compiling
of an ABAP program fails because it contains recursive accesses to a
global class. In such cases, you may be able to make the program com-
pilable by explicitly loading the class before the recursion.
Example
In the following example, class c1 uses class c2 and vice-versa. As a
result, one of the classes has to be declared before its actual definition. In
addition, global class cl_gui_cfw is loaded explicitly before one of its
static attributes is used.
CLASS c1 DEFINITION DEFERRED.
PUBLIC SECTION.
DATA c1ref TYPE REF TO c1.
ENDCLASS.
PUBLIC SECTION.
DATA c2ref TYPE REF TO c2.
ENDCLASS.
CLASS cl_gui_cfw DEFINITION LOAD.
DATA state LIKE cl_gui_cfw=>system_state.

7.3 Defining Interfaces
INTERFACE
The definition of an interface consists of a declaration section that is

introduced with INTERFACE. In contrast to classes, interfaces do not have
an implementation section. You use other variants of INTERFACE to
declare interfaces in a program.
7.3.1 Declaration Section

Defines an interface and declares its components.
Syntax
INTERFACE ifac.
[components]
ENDINTERFACE.
The statement block INTERFACE – ENDINTERFACE defines an interface

ifac. You declare the components of the interface between INTERFACE
and ENDINTERFACE.
7.3.1.1 Interface Components
Syntax
components
The following declaration statements are possible for components:
왘 TYPE-POOLS, TYPES, DATA, CLASS-DATA, and CONSTANTS for data

types and data objects (see Chapter 6)
왘 METHODS, CLASS-METHODS, EVENTS, and CLASS-EVENTS for methods
and events (see Section 7.4)
왘 INTERFACES for integrating component interfaces and ALIASES for
alias names of their components (see Section 7.4)
Note
All the components of an interface lie within one namespace. The name
of a component must be unique within an interface, regardless of its type
(data type, attribute, method, event, or alias name). The components of
an integrated interface differ from the directly declared components
through prefix ifac~ (name of the interface with the interface compo-
nent selector).

Example
In the following example, an interface, i1, is declared with three interface
components, a1, m1, and e1. Class c1 implements the interface, which
makes the interface components public components of the class that can
be addressed using the interface component selector (~).
INTERFACE i1.
DATA a1 TYPE string.
METHODS m1.
EVENTS e1 EXPORTING value(p1) TYPE string.
ENDINTERFACE.
PUBLIC SECTION.
INTERFACES i1.
ENDCLASS.
METHOD i1~m1.
RAISE EVENT i1~e1 EXPORTING p1 = i1~a1.
ENDMETHOD.
ENDCLASS.
7.3.2 Declaring Interfaces

In some cases, you have to explicitly declare the definition of an interface
before you can use it.
Syntax
INTERFACE ifac { DEFERRED | LOAD }.
The two variants of the INTERFACE statement serve to declare interface

ifac independently of the location of the actual definition in the pro-
gram. They do not introduce a declaration section, and you cannot com-
plete them with ENDINTERFACE. The meanings of the two statements for
interfaces are identical to the meanings of the CLASS statements
described for classes in Section 7.2.3.
Defining Interfaces 159

7.4 Declaring Components in Classes and

Interfaces
You use the declaration section of classes and interfaces to declare the
components of classes and interface that are major components of a
class:
왘 Attributes
왘 Methods
왘 Events
Attributes are the data objects of a class. You can also declare class-spe-
cific data types. You declare attributes and data types with the general
statements TYPE-POOLS, TYPES, DATA, CLASS-DATA, and CONSTANTS,
which—with the exception of CLASS-DATA—can also be used in other
contexts and are described in Chapter 6.
To declare methods and events, you use specific statements that are pos-
sible only in the declaration section of classes and interfaces.
7.4.1 Methods
You use the METHODS and CLASS-METHODS statements to declare meth-
ods. They define how the class responds. You define the interface of a
method in the declaration. Different categories of methods exist for spe-
cific tasks:
왘 General methods
왘 Functional methods
왘 Constructors
왘 Event handlers
Any of these methods can be declared as an instance method or a static

method.
7.4.1.1 Instance Methods
METHODS
The METHODS statement declares instance methods. Instance methods are

tied to objects. To use instance methods, you first have to generate an
object of the class. In instance methods, you can access all components of
the method’s own class without requiring a component selector.

7.4.1.2 General Instance Methods
The most general form of the METHODS statement lets you define instance
methods with any input and output parameters.
Syntax
METHODS meth [ABSTRACT|FINAL]
[IMPORTING {parameteri} [PREFERRED PARAMETER p]]
[EXPORTING {parameteri}]
[CHANGING {parameteri}]
[{RAISING|EXCEPTIONS} {exci}].
This statement declares a general instance method, meth. The additions

ABSTRACT and FINAL make the method abstract and final, respectively.
The other additions define the parameter interface of the method and
define which exceptions the method can propagate and/or trigger.
Parameter interface
The additions IMPORTING, EXPORTING, and CHANGING define the signa-
ture of method meth:
왘 IMPORTING defines input parameters

When you call the method, you have to specify a suitable actual
parameter for each non-optional input parameter. The content of the
actual parameter is passed on to the input parameter during the call.
왘 EXPORTING defines output parameters
When you call the method, you can specify a suitable actual parameter
for each output parameter. The content of the output parameter is
passed on to the actual parameter when the method ends free of
errors.
왘 CHANGING defines input/output parameters
When you call the method, you have to specify a suitable actual
parameter for each non-optional input/output parameter. The content
of the actual parameter is passed on to the input/output parameter
during the call, and the content of the input/parameter is passed on to
the actual parameter when the method ends.
You define the corresponding formal parameters by specify a list, para-

meteri, after each addition.
Declaring Components in Classes and Interfaces 161

Syntax of parameteri
... { {VALUE(pi)}|{REFERENCE(pi)}|{pi} {typing}
[OPTIONAL|{DEFAULT defi}] } ...
VALUE or REFERENCE defines whether a parameter, pi, is passed on as a

value or a reference. The parameter is passed on as a reference by default
only when you specify a name pi. An input parameter that is passed on as
a reference cannot be changed in the method.
You have to use the addition typing to type each formal parameter. The
syntax of typing is described in Section 8.2. When you type a formal
parameter, that typing is checked against the data type of any actual
parameter that is passed on (see Section 8.3). The defined type also
determines the operand positions where the formal parameter(s) can be
used in the method.
You can use OPTIONAL or DEFAULT to define input parameters and input/
output parameters as optional parameters; if you use DEFAULT, you can
also specify a default parameter defi. If a parameter is optional, you do
not have to specify an actual parameter when you call the method. If you
use the addition OPTIONAL, the formal parameter is initialized type-spe-
cifically; if you use DEFAULT, it assumes the value of the default parame-
ter, defi. defi can be any data object with a suitable type that is visible
at this point.
You can use PREFERRED PARAMETER to flag an input parameter p in list

parameteri (after IMPORTING) as the preferred parameter. This addition
makes sense, however, only if all the input parameters are optional. If you
call the method with syntax
[CALL METHOD] meth( a ).
then the actual parameter a is assigned to preferred parameter p.
Note
If a formal parameter is typed as a reference variable and cannot be
changed in the procedure, the type check is performed as it is for a nar-
rowing cast. If it can be changed in the procedure, the actual parameter
must be compatible with the formal parameter.
Example
Method read_spfli_into_table in the following example has one
input parameter and one output parameter, both of which are completely
typed through references to the ABAP Dictionary.

CLASS flights DEFINITION.

PUBLIC SECTION.
METHODS read_spfli_into_table
IMPORTING VALUE(id) TYPE spfli-carrid
EXPORTING flight_tab TYPE spfli_tab.
...
ENDCLASS.
Class-based exceptions
Syntax
... RAISING {exci} ...
You can use the addition RAISING to pass class-based exceptions, exci,
on to the calling program. The exceptions can be subclasses of CX_
STATIC_CHECK and CX_DYNAMIC_CHECK which are triggered in or
propagated into the method of the ABAP runtime environment or with
the RAISE EXCEPTION statement, but are not handled in a TRY block
(see Section 15.2).
exci can equal any exception classes that are subclasses of the above
superclasses and are visible at this point. You have to enter the exception
classes in the ascending order of their inheritance hierarchy.
If an exception of a superclass occurs in the method and is neither han-

dled nor passed on, this will cause either a syntax error or an exception
that the calling program has to handle, CX_SY_NO_HANDLER
Notes
왘 Exceptions that involve the subclasses of CX_STATIC_CHECK and CX_
DYNAMIC_CHECK have to either be handled within the method or
passed on explicitly with the addition RAISING. This is checked during
the syntax check for CX_STATIC_CHECK, and at runtime for CX_
DYNAMIC_CHECK.
왘 You cannot use the CATCH SYSTEM-EXCEPTIONS statement in a
method that propagates class-based exceptions with addition RAIS-
ING. You have to trap these exceptions in a TRY block instead (see
Chapter 15).
Example
In class math below, method divide_1_by propagates all the exceptions
represented by class CX_SY_ARITHMETIC_ERROR and its subclasses. If an
input parameter, operand, is given a 0 value during a call, for example,

exception CX_SY_ZERODIVIDE is triggered, propagated, and—as illus-

trated in the example—handled by the calling program in a TRY block.
CLASS math DEFINITION.

PUBLIC SECTION.
METHODS divide_1_by
IMPORTING operand TYPE I
EXPORTING result TYPE f
RAISING cx_sy_arithmetic_error.
ENDCLASS.
CLASS math IMPLEMENTATION.

METHOD divide_1_by.
result = 1 / operand.
ENDMETHOD.
ENDCLASS.
...
DATA oref TYPE REF TO math.

DATA exc TYPE REF TO cx_sy_arithmetic_error.
DATA result TYPE f.

DATA text TYPE string.
CREATE OBJECT oref.

TRY.
oref->divide_1_by( EXPORTING operand = ...
IMPORTING result = result ).
text = result.
CATCH cx_sy_arithmetic_error INTO exc.
text = exc->get_text( ).
ENDTRY.
MESSAGE text TYPE 'I'.
Exceptions prior to Release 6.10

Syntax
... EXCEPTIONS {exci} ...
You use the addition EXCEPTIONS to define a list of exceptions, exci,

that can be triggered in the method with the RAISE or MESSAGE RAIS-
ING statements. You can specify any identifier exci for the defined
exceptions; you must specify them directly. Exceptions defined in this

manner are tied to the methods—similar to formal parameters—and can-

not be propagated.
If an exception of this type is triggered in a method and not handled with

the addition EXCEPTIONS in the CALL METHOD statement during the
method call, a runtime error occurs.
Note
You cannot use the additions RAISING and EXCEPTIONS at the same
time. We recommend using class-based exceptions for new develop-
ments in Release 6.10 and later, as they are independent of any specific
method.
Example
In class math below, a separate exception arith_error is defined for
method divide_1_by. This exception is triggered with the RAISE state-
ment when an arithmetic error occurs. For example, if an input parame-
ter, operand, is given a 0 value during a call, exception arith_error is
triggered during the internal-method handling of exception CX_SY_
ZERODIVIDE and is handled during the method call.

PUBLIC SECTION.
METHODS divide_1_by
IMPORTING operand TYPE I
EXPORTING result TYPE f
EXCEPTIONS arith_error.
ENDCLASS.

METHOD divide_1_by.
TRY.
result = 1 / operand.
CATCH cx_sy_arithmetic_error.
RAISE arith_error.
ENDTRY.
ENDMETHOD.
ENDCLASS.
...
DATA result TYPE f.

DATA text TYPE string.

DATA exc TYPE REF TO cx_sy_arithmetic_error.
CREATE OBJECT oref.

oref->divide_1_by( EXPORTING operand = ...
IMPORTING result = result
EXCEPTIONS arith_error = 4 ).
IF sy-subrc = 0.
WRITE result.
ELSE.
WRITE 'Arithmetic error!'.
ENDIF.
Abstract methods
Syntax
... ABSTRACT ...
The addition ABSTRACT is possible only in classes, not in interfaces. The

addition ABSTRACT defines an abstract method, meth. An abstract
method is not implemented in the implementation section of its class,
and can be declared only in abstract classes. To implement an abstract
method, you have to redefine it in a non-abstract subclass with the addi-
tion REDEFINITION.
Note
Although abstract methods can be defined in classes that are both
abstract and final, they cannot be implemented, which means you cannot
use them.
Final methods
Syntax
METHODS ... FINAL ...
The addition FINAL is possible only in classes, not in interfaces. The addi-
tion FINAL defines a final method, meth. A final method cannot be rede-
fined in a subclass. All methods in final classes are automatically final, and
the addition FINAL is not allowed here.
7.4.1.3 Functional Instance Methods
Functional methods can have any number of input parameters, and have
exactly one return value as output parameter.

Syntax
[IMPORTING {parameteri}]
RETURNING VALUE(r) {TYPE type_spec}|{LIKE dobj_spec}
This statement declares a functional instance method, meth. The addi-

tions ABSTRACT, FINAL, IMPORTING, RAISING, and EXCEPTIONS have
the same functions as for general instance methods.
Instead of the additions EXPORTING and CHANGING, a functional method

has one addition, RETURNING, that defines exactly one formal parameter,
r, as a return value. The return value must be passed on with VALUE.
As far as the typing of return value r with typing is concerned, the same
rules apply as for the typing of IMPORTING, EXPORTING, and CHANGING
parameters (see Section 8.2), with the exception that a return value
always has to be completely typed: You cannot specify any of the generic
types from Table 5.3 for typing.
You can use functional methods in the operand positions of statements

where a data object is expected, as described in Section 2.2.5. The com-
plete typing of the return value defines the data type of the operand.
When you execute statements of this type, the functional method is
called, and the content of the return value replaces the content of the
operand.
Notes
왘 When you use a functional method in an operand position, class-based
exceptions that the method propagates with RAISING can be handled
in a TRY block or propagated further, as with the general methods. In
contrast, the exceptions for a functional method that you define with
EXCEPTIONS cannot be handled in operand positions, and will always
cause a runtime error.
왘 If a functional method has the same name as a built-in function (see
Section 5.4), the expression meth( a ) in an operand position always
calls the functional method. This case can occur only in methods of the
class in the functional method, however.
Example
Functional method factorial in the following example has a return
value, fact, with type i. The COMPUTE statement illustrates the method
call in an operand position.


PUBLIC SECTION.
METHODS factorial
IMPORTING n TYPE i
RETURNING value(fact) TYPE i.
ENDCLASS.

METHOD factorial.
fact = 1.
IF n = 0.
RETURN.
ELSE.
DO n TIMES.
fact = fact * sy-index.
ENDDO.
ENDIF.
ENDMETHOD.
ENDCLASS.
...

DATA result TYPE i.
CREATE OBJECT oref.

COMPUTE result = oref->factorial( ... ).
7.4.1.4 Instance Constructors
Instance constructors are methods with the predefined name construc-

tor that are called automatically during the instantiation of their class.
Constructors can have any number of input parameters, but no output
parameters.
Syntax
METHODS constructor [FINAL]
This statement is possible only in the public visibility area of the declara-
tion section of a class. It declares the instance constructor of the class,
constructor.

Each class has a predefined method called constructor in its public vis-
ibility area. You can use the explicit declaration to define the interface of
method constructor class-specifically and to implement its functional-
ity. If you do not declare it explicitly, the instance constructor assumes the
signature from the instance constructor in the direct superclass and calls
it implicitly.
If you implement the instance constructor in a subclass, you have to call

the instance constructor of the superclass explicitly (with the pseudo ref-
erence super->constructor) and supply its interface with data. The
only exceptions to this are the direct subclasses of the root node, object.
Prior to the call of the superclass constructor, an instance constructor can
access only the static components of its class. After the superclass con-
structor is called, it can also access the instance constructors.
You can use the addition IMPORTING to define input parameters, accord-
ing to the same rules as for the general methods. The additions RAISING
and EXCEPTIONS for propagating and defining exceptions also have the
same meaning as under the general methods.
The instance constructor is called once for each instance of a class, with
the CREATE OBJECT statement, directly after the instance is generated. In
the process, actual parameters must be assigned for all non-optional input
parameters, and exceptions can be handled or passed on. A call using
CALL METHOD is not possible, except in the call of the superclass con-
structor with super->constructor in the redefined constructor of a
subclass.
Instance constructors are implicitly final. You can specify the addition
FINAL, but it is not necessary.
Notes
왘 Instance constructors represent an exception to the rule that all public
components along a path in the inheritance tree have to line in the
same namespace. The instance constructor of each class has a separate
interface and a separate implementation. You cannot redefine an
instance constructor.
왘 Instance constructors are declared only in the public visibility area of a
class for technical reasons. You control the actual visibility with the
addition CREATE {PUBLIC|PROTECTED|PRIVATE} of the CLASS
DEFINITION statement.

Example
In the following example, class c2 inherits from class c1. The instance
constructor, constructor, is declared explicitly in both classes. It there-
fore has to be implemented in both classes. In addition, the implementa-
tion in c2 has to contain the call of the superclass constructor.
PUBLIC SECTION.
METHODS constructor IMPORTING p1 TYPE any.
...
ENDCLASS.

PUBLIC SECTION.
METHODS constructor IMPORTING p2 TYPE any.
...
ENDCLASS.
METHOD constructor.
...
ENDMETHOD.
ENDCLASS.
METHOD constructor.
...
super->constructor( p2 ).
...
ENDMETHOD.
ENDCLASS.
7.4.1.5 Event Handlers
Event handlers are methods that can also be called with CALL METHOD,
but which are called primarily by triggering an event of a class or an inter-
face. The only possible formal parameters of an event handler are the
input parameters that are defined as the output parameters of the event.
Syntax
FOR EVENT evt OF {class|ifac}
[IMPORTING {pi} [sender]].

This statement declares the instance method meth as the event handler
evt of class class or interface ifac class. ifac can be any classes or
interfaces that are visible at this point and that contain a visible event evt
as a component.
If event evt is an instance event, event handler meth can handle it for all
objects whose class is class or a subclass of class, or that implement
interface ifac directly or through a superclass. If the event is a static
event, event handler meth can handle it for class and its subclasses, or
for all classes that implement interface ifac.
You can use the additions ABSTRACT and FINAL to make the event han-
dler abstract or final, just like the general methods.
The addition IMPORTING defines the input parameters of the event han-
dler. pi can only be names of formal parameters that you defined as
export parameters of the event with addition EXPORTING for statement
[CLASS-]EVENTS in the declaration of event evt in the class or inter-
face ifac. The additions TYPE/LIKE and OPTIONAL/DEFAULT are not
possible. Any default parameters, the typing of the input parameters, and
whether or not the input parameters are optional are taken from the dec-
laration of the event. You do not have to specify all the output parameters
of the event.
If evt is an instance event, you can also define a formal parameter called
sender as an input parameter of the event handler, in addition to its
explicitly defined output parameters. sender is an implicit output param-
eter of every instance event. It is fully typed as a reference variable that
has class or interface ifac as a static type, as defined in the declaration
of the event handler after EVENT evt OF. If the event handler is called by
an instance event, sender passes on a reference to the triggering object.
Prior to Release 6.10, the static type of formal parameter sender was
determined by the class or interface in which the EVENTS statement
declared the event. In Release 6.10 and later, the event handler deter-
mines the type of its formal parameter itself.
Example
In the example below, class picture contains an event handler handle_
double_click for instance event picture_dblclick of global class
cl_gui_picture. The event handler uses two explicit output parame-
ters of the event, along with the implicit parameter sender, as input
parameters.

CLASS picture DEFINITION.

PUBLIC SECTION.
METHODS handle_double_click
FOR EVENT picture_dblclick OF cl_gui_picture
IMPORTING mouse_pos_x mouse_pos_y sender.
ENDCLASS.
CLASS picture IMPLEMENTATION.

METHOD handle_double_click.
...
ENDMETHOD.
ENDCLASS.
7.4.1.6 Redefining Instance Methods
A method declared in a superclass can be redefined in a subclass, pro-

vided it is not flagged as final in the superclass. Redefinition does not
change the method’s interface.
Syntax
METHODS meth [FINAL] REDEFINITION.
This statement is possible only in subclasses. It redefines an inherited

instance method meth. It forces the redefinition of method meth in the
implementation section of the subclass. The new implementation in the
current class masks the implementation in the superclass. The redefined
method accesses the private components of the redefined class, not the
private components with the same names in the superclass (if any).
Within the redefined method, you can use the pseudo reference super-
>meth to call the implementation of the direct superclass.
With the exception of the instance constructor, meth can be any non-
final instance method that is declared in the public or protected visibility
area of a superclass of the current class. In particular, meth can be an
abstract method of an abstract superclass. The redefinition must take
place within the same visibility area as the declaration of the method. The
interface and type of the method (general or functional instance method,
event handler) are not changed during a redefinition.
The redefinition is valid for the subclasses of the redefined class until it is
redefined again. You can continue to redefine a method along a path in
the inheritance tree until it is made final. If you use the addition FINAL

during redefinition, the method is final from the current class and can no
longer be redefined in its subclasses.
Note
Each object reference that points to an object in a subclass addresses the
redefined methods regardless of its static type. This also applies to the
self-reference me->.
Example
In the example below, method m1 of superclass c1 is redefined in subclass
c2. The original implementation is called with super->m1. Both methods
use the private attribute a1 of the respective class. The redefined method
is executed with reference variable oref, which has static type c1 and
dynamic type c2.
PUBLIC SECTION.
METHODS m1 IMPORTING p1 TYPE string.
PRIVATE SECTION.
DATA a1 TYPE string VALUE `c1: `.
ENDCLASS.

PUBLIC SECTION.
METHODS m1 REDEFINITION.
PRIVATE SECTION.
DATA a1 TYPE string VALUE `c2: `.
ENDCLASS.
METHOD m1.
CONCATENATE a1 p1 INTO a1.
WRITE / a1.
ENDMETHOD.
ENDCLASS.
METHOD m1.
super->m1( p1 ).
CONCATENATE a1 p1 INTO a1.
WRITE / a1.
ENDMETHOD.
ENDCLASS.

...
CREATE OBJECT oref TYPE c2.

oref->m1( `...` ).
7.4.1.7 Static Methods
CLASS-METHODS
The CLASS-METHODS statement declares static methods. You can use

static methods with the class component selector (=>) independently of
objects. In static methods, you can access only the static components of its
own class or its superclasses if you do not use a component selector.
7.4.1.8 General Static Methods
The most general form of the CLASS-METHODS statement lets you define
static methods with any number of input and output parameters.
Syntax
CLASS-METHODS meth
[IMPORTING {parameteri} [PREFERRED PARAMETER p]]
[EXPORTING {parameteri}]
[CHANGING {parameteri}]
This statement declares a general static method, meth. The additions

define the parameter interface of the method and define which excep-
tions the method can propagate and/or trigger. The syntax and meaning
of the additions are the same as for the general instance methods.
Note
Static methods cannot be redefined, and therefore cannot be made
abstract or final either.
7.4.1.9 Functional Static Methods
Functional methods can have any number of input parameters, and have
exactly one return value as output parameter.

Syntax
CLASS-METHODS meth
RETURNING VALUE(r) {TYPE type_spec}|{LIKE dobj_spec}
This statement declares a functional static method, meth. The additions

have exactly the same syntax and meaning as in the functional instance
methods.
Example
The class described below, circle, contains two functional methods,
circumference and area, and the constants pi.
CLASS circle DEFINITION.

PUBLIC SECTION.
CONSTANTS pi TYPE f
VALUE '3.14159265358979324'.
CLASS-METHODS: circumference IMPORTING r TYPE f
RETURNING value(c)
TYPE f,
area IMPORTING r TYPE f
RETURNING value(a)
TYPE f.
ENDCLASS.
CLASS circle IMPLEMENTATION.

METHOD circumference.
c = 2 * pi * r.
ENDMETHOD.
METHOD area.
a = pi * r ** 2.
ENDMETHOD.
ENDCLASS.
...
DATA: circ TYPE f,

area TYPE f,
radius TYPE f.
radius = ...
circ = circle=>circumference( radius ).
area = circle=>area( radius ).

7.4.1.10 Static Constructors
Static constructors are methods with the predefined name class_con-

structor, which are called automatically before the first use of their
class. Static constructors do not have a parameter interface.
Syntax
CLASS-METHODS class_constructor.
This statement is possible only in the public visibility area of the declara-
tion section of a class. It declares the static constructor of the class,
class_constructor.
Each class has a predefined method called class_constructor in its
public visibility area. The explicit declaration enables you to implement its
functionality class-specifically. If you do not declare it explicitly, the static
constructor is blank.
The static constructor is executed once for each class and internal session.
This execution takes place automatically before the first access to the
class. You access a class whenever you generate an instance of that class
or address a static component with the class component selector.
During the first access of a subclass, the system searches for the next-
highest superclass in the inheritance tree whose static constructor has not
been executed yet. The static constructor of the superclass is then exe-
cuted, followed successively by each subsequent subclass down to the
addressed subclass.
Like all static methods, the static constructor can access only the static
components of its class. Furthermore, the static constructor cannot
address its own class explicitly.
Notes
왘 Like instance constructors, static constructors represent another excep-
tion to the rule that all public components along a path in the inherit-
ance tree have to line in the same namespace.
왘 The execution time for the static constructor is indeterminate. The sys-
tem merely guarantees its execution prior to the first access of the
class. The static constructor is usually executed immediately prior to
the access of the class. The static constructor is called at the start of the
respective processing block only if a static attribute of the class is
accessed. We do not recommend writing programs that require the
static constructor to be executed at a specific time.

Example
The static constructor of the class below sets static attribute access_
program to the name of the program of the first internal session that uses
a class during the first access to that class.
CLASS some_class DEFINITION.

PUBLIC SECTION.
CLASS-METHODS class_constructor.
PRIVATE SECTION.
CLASS-DATA access_program TYPE sy-repid.
ENDCLASS.
CLASS some_class IMPLEMENTATION.

METHOD class_constructor.
access_program = sy-repid.
ENDMETHOD.
ENDCLASS.
7.4.1.11 Static Event Handlers
Static event handlers are static methods that are called by an event of a
class or an interface. The only possible formal parameters of an event han-
dler are input parameters that are defined as output parameters of the
event.
CLASS-METHODS meth
FOR EVENT evt OF {class|ifac}
[IMPORTING {pi} [sender]].
This statement declares the static method meth as the event handler evt
of class or interface ifac. The syntax and meaning of the additions are
identical to those in the declaration of instance methods as event han-
dlers.
Static event handlers can be called by event evt independently of an

instance of a class.
Example
In the class described below, dialog_box, a static event handler close_
box is defined for the event. This event is triggered when the user
attempts to close a dialog box of the GUI control framework (CFW).

CLASS dialog_box DEFINITION.

PUBLIC SECTION.
METHODS constructor.
...
PRIVATE SECTION.
CLASS-DATA open_boxes TYPE i.
CLASS-METHODS close_box
FOR EVENT close OF cl_gui_dialogbox_container
IMPORTING sender.
...
ENDCLASS.
CLASS dialog_box IMPLEMENTATION.

METHOD constructor.
... " create a dialogbox
open_boxes = open_boxes + 1.
ENDMETHOD.
METHOD close_box
... " close the dialogbox referred by sender
open_boxes = open_boxes - 1.
ENDMETHOD.
ENDCLASS.
7.4.2 Events
You use the EVENTS and CLASS-EVENTS statements to declare events.
When you declare an event in a class, the methods of that class can trig-
ger the event, which in turn triggers the execution of event handlers. Dur-
ing the declaration, you can define output parameters for an event that
are passed on to the event handler as actual parameters when the event is
triggered.
7.4.2.1 Instance Events
EVENTS
The EVENTS statement declares instance events. Instance events are tied
to objects. They can be triggered only in instance methods of the same
class.

Syntax
EVENTS evt [EXPORTING { VALUE(pi) typing
[ OPTIONAL|{DEFAULT defi}] } ].
This statement declares an instance event, evt, in a class or an interface.

evt can be triggered with the RAISE EVENT statement in all instance
methods of the same class or in any class that implements the interface,
as well as—if visible there—in the instance methods of subclasses.
The addition EXPORTING defines the parameter interface of event evt.

An event has only output parameters, pi, which are passed on as values.
The syntax of the additions VALUE, OPTIONAL, and DEFAULT and the
typing correspond to the definition of formal parameters in method
interfaces with the METHODS statement.
When you trigger an event with the RAISE EVENT statement, you have to
specify suitable actual parameters for all non-optional output parameters.
You can also specify any desired optional parameters. Optional parame-
ters for which no actual parameter is specified are set to their type-spe-
cific initial value or to the default parameter, defi.
When you declare an event handler with the addition FOR EVENT OF in
the [CLASS-]METHODS statement, you can define the output parameters
of the event as the input parameters of the event handler; in this case, the
attributes of the input parameters are copied to the output parameters
defined in EVENTS.
In addition to the output parameters that you define with EXPORTING,

each instance event also has an implicit output parameter, sender. This
output parameter has the type of a reference variable. When you trigger
an event with the RAISE EVENT statement, sender is implicitly assigned
the reference to the triggering object.
Prior to Release 6.10, the static type of implicit parameter sender was
defined by the class or interface where the EVENTS statement was listed.
In Release 6.10 and later, the static type of input parameter sender is
defined by the addition FOR EVENT OF in the [CLASS-]METHODS state-
ment.
Note
The dynamic type of the implicit formal parameter, sender, is always the
class of the object in which the event is triggered.

Example
In the interface below, window, three events are declared, each with an
explicit, non-optional output parameter, status. Class dialog_window
implements interface window. Interface window_handler contains event
handlers that import both the explicit parameter, status, and the
implicit parameter, sender. The static type of input parameter sender is
class dialog_window. Prior to Release 6.10, interface window is the static
type.
INTERFACE window.
EVENTS: minimize EXPORTING VALUE(status) TYPE i,
maximize EXPORTING VALUE(status) TYPE i,
restore EXPORTING VALUE(status) TYPE i.
ENDINTERFACE.
CLASS dialog_window DEFINITION.

PUBLIC SECTION.
INTERFACES window.
ENDCLASS.
INTERFACE window_handler.
METHODS: minimize_window
FOR EVENT window~minimize OF dialog_window
IMPORTING status sender,
maximize_window
FOR EVENT window~maximize OF dialog_window
IMPORTING status sender,
restore
FOR EVENT window~restore OF dialog_window
IMPORTING status sender.
ENDINTERFACE.
7.4.2.2 Static Events
CLASS-EVENTS
The CLASS-EVENTS statement declares static events. Static events are not
tied to objects. They can be triggered in all methods of the same class.
Syntax
CLASS-EVENTS evt [EXPORTING { VALUE(pi) typing
[ OPTIONAL|{DEFAULT defi}] } ].

This statement declares a static event, evt, in a class or an interface. evt

can be triggered with the RAISE EVENT statement in all methods of the
same class and in any class that implements the interface, as well as—if
visible there—in the methods of subclasses.
The addition EXPORTING defines the parameter interface of event evt.

The syntax and meaning of the additions VALUE, OPTIONAL, and DEFAULT
and the typing correspond to the definition of instance events with the
EVENTS statement.
Note
Static events do not have an implicit formal parameter called sender.
7.4.3 Implementing and Integrating Interfaces

Interfaces can be implemented by classes or integrated by other inter-
faces. You can define alias names for interface components.
INTERFACES
The INTERFACES statement is possible in the public visibility area of the

declaration section of classes and in interface declarations.
7.4.3.1 Implementing Interfaces in Classes
Syntax
INTERFACES ifac
{ { [ABSTRACT METHODS {methi}]
[FINAL METHODS {methj}] }
| [ALL METHODS {ABSTRACT|FINAL}] }
[DATA VALUES {attri = vali}].
In the public visibility area of a class, the INTERFACES statement imple-

ments interface ifac in the class. You can also specify additions, which
define the properties of interface components in the class.
ifac can be any local or global interfaces that are visible at this point. The
implementation makes the components of the interfaces public compo-
nents of the class. An interface component named comp has the name
ifac~comp in the class: ifac is the name of the interface and the ~ char-
acter is the interface component selector. A class has to implement all
methods of the interface in its implementation section, provided it is not
declared as abstract.

You can use the additions ABSTRACT METHODS and FINAL METHODS to
make individual instance methods of the interface, methi, abstract or final
in the implementing class. The same rules apply as for the additions
ABSTRACT and FINAL of the METHODS statement. In particular, when you
make an interface method abstract, the entire class has to be abstract,
and you cannot list an interface method after both ABSTRACT METHODS
and FINAL METHODS at the same time. Instead of making individual
instance methods abstract or final in the class, you can use the addition
ALL METHODS {ABSTRACT|FINAL} to make all the interface methods
either abstract or final.
You can use the addition DATA VALUES to assign initial values to the indi-
vidual attributes, attri. This addition has the same function for instance
attributes as the addition VALUE of the DATA statement for internal class
attributes. If you declare a constant with the CONSTANTS statement in the
interface, you cannot list it after the addition DATA VALUES.
Notes
A class can implement any number of different interfaces. All the inter-
faces implemented in a class are equally valid on one level. If an interface
implemented in a class, ifac, is a composite—that is, it contains compo-
nent interfaces—these interfaces are implemented as individual interfaces
in the class, regardless of their nesting hierarchy. As a result, their compo-
nents are not addressed through the name ifac, but instead through the
name of the component interfaces. Multiple use of the interface compo-
nent selector in an identifier (such as ifac1~ifac2~comp) is generally not
supported.
Each interface exists only once in a class, and each interface component
comp can be uniquely addressed with the name ifac~comp. Even a com-
ponent of an interface that is seemingly implemented several times in a
class—because it is an interface component of one or more other inter-
faces, for example—really exists only once.
7.4.3.2 Integrating Interfaces in Interfaces
Syntax
INTERFACES ifac.
Within the declaration of an interface, the INTERFACES statement inte-

grates interface ifac in the declared interface. You cannot specify any
additions. As a result, interface ifac becomes a component interface of a
composite interface.

An interface can be composed of any number of different component

interfaces. All the interfaces are equally valid on one level. If a component
interface itself is a composite—that is, it contains its own component
interfaces—then the nesting hierarchy is irrelevant for the composition of
the interface. It is relevant, however, for accessing the interface compo-
nents.
To access a component comp of a component interface ifac within a

composite interface, you can use the expression ifac~comp with the
interface component selector (~). Multiple use of the interface compo-
nent selector in an identifier (such as ifac1~ifac2~comp) is generally not
supported. Within a composite interface, you can only use the interface
component selector to access interface components of the component
interface that have been integrated with the INTERFACES statement in
that interface. If you have to access components in a composite interface
that cannot be addressed through the one-time use of the interface com-
ponent selector, you can use the ALIASES statement to create alias names
for the interface components.
Notes
Each interface and its components appear only once in a composite inter-
face. Even an interface that is seemingly implemented several times in an
interface, because it is an interface component of one or more other
interfaces, really exists only once.
Because there are no separate namespaces for global and local interfaces,
you have to make sure that composition of local interfaces does not result
in combinations of global and local interfaces with identical names, since
they cannot lie on the same level in their implementation.
Example
The following example illustrates how you can use the INTERFACES state-
ment to compose and implement interfaces. Class c1 implements the
composite interfaces i2 and i3. Although i1 is a component interface of
i2 and i3, it exists only once in class c1. A reference variable iref1 with
static type i1 is used to generate an object class c1 and call method
i1~m1, which is implemented there.
INTERFACE i1.
METHODS m1.
ENDINTERFACE.

INTERFACE i2.
INTERFACES i1.
METHODS m2.
ENDINTERFACE.
INTERFACE i3.
INTERFACES i1.
METHODS m3.
ENDINTERFACE.
PUBLIC SECTION.
INTERFACES: i2, i3.
ENDCLASS.
METHOD i1~m1.
...
ENDMETHOD.
METHOD i2~m2.
...
ENDMETHOD.
METHOD i3~m3.
...
ENDMETHOD.
ENDCLASS.
...
DATA iref1 TYPE REF TO i1.
CREATE OBJECT iref1 TYPE c1.

iref1->m1( ).
7.4.3.3 Alias Names
ALIASES
Declares alias names for interface components.
Syntax
ALIASES alias FOR ifac~comp.

This statement declares an alias name, alias, for a component comp of

interface ifac in the declaration section of a class or an interface. Inter-
face ifac must be implemented in the same class or integrated in the
same interface. You can use the alias name instead of ifac~comp wher-
ever it is visible to access interface component comp.
An alias name belongs to the components of the class and the interface.
It lies within the same namespace as the other components and is inher-
ited to subclasses. You can define an alias name in every visibility area of
a class.
Note
You cannot use the alias name in the implementation of interface meth-
ods in the implementation section of classes. You always have to specify
the complete identifier, ifac~meth, in the METHOD statement.
Example
In the example below, alias names are declared for the methods of the
integrated and implemented interfaces in interfaces i2 and i3 and class
c1. The interface methods are implemented with the interface compo-
nent selector in the METHODS statements in the implementation section
of the class. The alias names of the class can be used within the methods.
INTERFACE i1.
METHODS meth.
ENDINTERFACE.
INTERFACE i2.
INTERFACES i1.
ALIASES m1 FOR i1~meth.
METHODS meth.
ENDINTERFACE.
INTERFACE i3.
INTERFACES i2.
ALIASES: m1 FOR i2~m1,
m2 FOR i2~meth.
METHODS meth.
ENDINTERFACE.
PUBLIC SECTION.
INTERFACES i3.
ALIASES: m1 FOR i3~m1,

m2 FOR i3~m2,
m3 FOR i3~meth.
ENDCLASS.
METHOD i1~meth.
... m2( ) ...
ENDMETHOD.
METHOD i2~meth.
... m3( ) ...
ENDMETHOD.
METHOD i3~meth.
... m1( ) ....
ENDMETHOD.
ENDCLASS.

ABAP Objects Reference

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ABAP Objects Reference

Uploaded by

Copyright:

Available Formats

titel.fm Seite 3 Freitag, 31.

Januar 2003 2:28 14

Horst Keller, Joachim Jacobitz

Part 2 Program Structure 47

Part 3 Declarative Statements 107

Part 4 Generating Objects 193

Part 5 Calling and Exiting Program Units 209

Part 6 Program Flow Control 289

Part 7 Assignments 333

Part 8 Processing Internal Data 363

Part 9 User Dialogs 503

Part 10 Processing External Data 699

Part 11 Program Parameters 847

Part 12 Program Processing 863

Part 13 External Programming Interfaces 885

Part 14 Obsolete Statements 907

Part 15 Appendix 987

Content at the Glance 5

1 Introduction and Overview 19

Part 2 Program Structure 47

3.3 Module Pools and Subroutine Pools 53

5 Built-In Types, Data Objects and Functions 89

Part 3 Declarative Statements 107

6 Declarative Statements for Data Types and Data Objects 109

7 Defining Classes and Interfaces 147

Part 4 Generating Objects 193

9 Generating Objects and Data Objects 195

Part 5 Calling and Exiting Program Units 209

10 Calling ABAP Programs 211

11 Calling Processing Blocks 239

12 Exiting Program Units 279

Part 6 Program Flow Control 289

13 Logical Expressions 291

14 Control Structures 311

15 Exception Handling 319

15.2.3 System Response to a Class-Based Exception 322

Part 7 Assignments 333

16 Value Assignments 335

17 Setting References 343

18 Initializing Data Objects 359

Part 8 Processing Internal Data 363

19 Calculation Expressions 365

20 Calculation Statements 373

21 Processing Byte/Character Strings 377

21.7 Condensing Character Strings 398

22 Processing Internal Tables 407

23 Processing Extract Datasets 463

24 Attributes of Data Objects 473

Part 9 User Dialogs 503

26 Selection Screens 547

26.3 Defining Parameters 574

27.3.3 Scrolling Lists 670

Part 10 Processing External Data 699

29 Open SQL 701

29.3 Reading Data from Database Tables Using a Cursor 739

30 Native SQL 763

31 Data Clusters 775

32 The ABAP File Interface 799

33 Data Consistency 835

Part 11 Program Parameters 847

34 Parameters in the SAP Memory 849

35 Language Environment 851

36 Time Stamp 857