Ben Meijs, Albert Krouwels,

Wouter Heuvelmans, Ron Sommen

Enhancing the Quality of

ABAP Development

Contents
Preface

11

Introduction

13

1.1

The Technical Quality of ABAP Software ....................................................

16

1.1.1
1.1.2

17
19

1.2

Aspects of Technical Quality ..........................................................

Standards and Guidelines ..............................................................

ABAP Objects and Unicode-Enabling ........................................................

19

1.2.1
1.2.2

ABAP Objects ...............................................................................

Unicode-Enabling .........................................................................

20
30

1.3

The Structure of This Book .........................................................................

32

Quality of the Development Organization

2.1

Introduction ...............................................................................................

37

2.1.1
2.1.2

What You Need to Organize to Facilitate ABAP Developments .....

Factors That Complicate the Organization of Developments ..........

37
38

The Impact of Using ERP Functionality ......................................................

39

2.2.1
2.2.2

Testing the Quality in a Complex Environment ..............................

Documenting ABAP Developments ...............................................

40
42

The Impact of a Multi-System SAP Landscape ...........................................

52

2.3.1
2.3.2
2.3.3

52
56
62

2.2

2.3

2.4
2.5

2.6

37

Basics of a Multi-System Landscape ...............................................

Basic Variants of an SAP System Landscape ...................................
Pitfalls of Monitoring Transports ...................................................

The Impact of a Multi-Application Landscape ...........................................

65

2.4.1

Requirements ................................................................................

66

The Impact of Several SAP R/3 Production Systems ..................................

67

2.5.1
2.5.2

Drawbacks of a Roll-Out Scenario .................................................

Recommendations ........................................................................

68
69

Summary ....................................................................................................

71

Contents

Correctness

73

3.1

Typical Correctness Categories ..................................................................

73

3.2

Selecting Data ............................................................................................

3.2.1
Selecting One Unique Row ...........................................................
3.2.2
Complex WHERE Conditions ........................................................
3.2.3
Validity of Selected Data ..............................................................
3.2.4
Selections Based on Database Views .............................................
3.2.5
Authorizations ..............................................................................

74
74
77
78
82
89

3.3

Processing Data ......................................................................................... 91

3.3.1
Processing Quantities and Amounts .............................................. 91
3.3.2
Rounding Problems ...................................................................... 94
3.3.3
Misunderstandings About Control Statements ............................... 98
3.3.4
Misunderstandings About Interactive Reporting ............................ 105

3.4

Managing Data in Memory ........................................................................

3.4.1
Availability of Data Within One Program .......................................
3.4.2
Availability When Calling an External Subroutine ..........................
3.4.3
Shared Availability of Data (TABLES) .............................................
3.4.4
Availability of Data in Module Pools ..............................................
3.4.5
Availability of Data Using Function Modules ................................
3.4.6
Parameter IDs ...............................................................................
3.4.7
Why ABAP Objects Will Improve Management of Data .................

3.5

Inconsistencies in Database Updates ........................................................ 128

3.5.1
Avoiding Simultaneous Database Updates ..................................... 128
3.5.2
Keeping Updates of Several Tables Consistent ............................... 136

3.6

Checking the Unicity of Interface Data ......................................................

3.6.1
An Example of Incorrect Data Exchange ........................................
3.6.2
Quality Levels for Exchanging Data ...............................................
3.6.3
Implementing Data Exchange Scenarios ........................................

Stability

109
109
112
113
116
120
123
124

140
140
140
142

145

4.1

Stability Problems ...................................................................................... 145

4.2

Programming Errors That Promote Instability ............................................ 147

4.2.1
Field Types .................................................................................... 147
4.2.2
Endless Loops ............................................................................... 159

4.3

Risks of Dynamic Programming ................................................................. 165

4.3.1
Dynamic Data ............................................................................... 166
4.3.2
Dynamic Calls ............................................................................... 180

4.4

Changes in an ABAP Programs Environment ............................................

4.4.1
User Authorizations .......................................................................
4.4.2
Native OS commands ...................................................................
4.4.3
Filenames .....................................................................................
4.4.4
Code-Page Use .............................................................................
4.4.5
Client Applications ........................................................................

Contents

189
189
190
191
193
194

4.5

Using an ABAP Program Incorrectly ...........................................................

4.5.1
Restrictions of Dialog Processing ...................................................
4.5.2
Restrictions for the Distribution of Tasks .......................................
4.5.3
Restrictions of Batch Data Communication ....................................
4.5.4
Questions to Ask in Order to Avoid Wrong Program Use ..............

Exceptions and Error Handling

195
196
205
209
217

219

5.1

The Importance of Exception Handling ...................................................... 219

5.2

Implementation of Exception Handling ..................................................... 221

5.2.1
Generating and Intercepting an Exception Signal ........................... 222
5.2.2
Implementing the Actual Exception Handling ................................ 226

5.3

Class-Based Exception Handling ................................................................

5.3.1
Basic Implementation ....................................................................
5.3.2
Exception Classes ..........................................................................
5.3.3
Details of Class-Based Exception Handling ....................................
5.3.4
Making Existing Exception Handling Class-Based ...........................
5.3.5
Creating Your Own Exception Classes ...........................................

5.4

Conclusions ............................................................................................... 243

User-Friendliness

6.1

The Importance of Standardization ............................................................ 245

6.2

Guidelines for The Look-and-Feel and Behavior of Your Programs ............ 247
6.2.1
Things to Be Standardized in The Look-and-Feel of an
ABAP Application .......................................................................... 247
6.2.2
Things to Be Standardized in The Behavior of an ABAP Application 254

6.3

Guidelines for Navigation and Support ......................................................

6.3.1
Assisting Users During Screen Input ..............................................
6.3.2
Limiting Unnecessary Screen Navigation ........................................
6.3.3
Avoiding Unnecessary Repetitions of Input ...................................
6.3.4
Avoiding Unnecessary Messages ....................................................

6.4

Conclusion ................................................................................................. 265

Performance

7.1

Introduction ............................................................................................... 267

7.2

Optimizing Processing on the Database Server: Using Indexes ................. 269

7.2.1
Primary and Secondary Indexes ..................................................... 270
7.2.2
What You Can Do to Prevent the Creation of Extra Indexes .......... 273

231
231
232
233
240
241

245

260
260
261
263
264

267

Contents

7.3

Minimizing Data Traffic Between the Database Server and

the Application Server ...............................................................................
7.3.1
Limiting the Number of Rows Selected .........................................
7.3.2
Limiting the Number of Fields Selected .........................................
7.3.3
Limiting the Number of Times That Data Is Selected .....................

293
295
300
302

7.4

Optimizing Processing on the Application Server ......................................

7.4.1
Performance Issues Related to Internal Table Processing ................
7.4.2
Basics of Internal Table Types ........................................................
7.4.3
How to Use Internal Tables ...........................................................
7.4.4
When to Choose Which Internal Table Type .................................
7.4.5
Semi-Persistent Memory ..............................................................
7.4.6
Parallel Processing .........................................................................

308
309
310
311
319
321
324

7.5

Minimizing Data Traffic Between the Application Server and a Client ...... 327
7.5.1
Uploads and Downloads ............................................................... 327
7.5.2
Control Flushing ........................................................................... 328

7.6

Summary .................................................................................................... 329

Maintainability

8.1

Maintainability of Standard SAP Software ................................................. 332

8.1.1
OSS Notes .................................................................................... 332
8.1.2
Changes Made by the Customer ................................................... 333

8.2

Maintainability of Customized ABAP Software ..........................................

8.2.1
Separating Different Actions ..........................................................
8.2.2
Improving Recognizability .............................................................
8.2.3
Reusing Standard SAP Software .....................................................
8.2.4
Practical Tips .................................................................................

8.3

Enhancing Maintainability with ABAP Objects .......................................... 365

8.3.1
Using Subclasses ........................................................................... 365
8.3.2
Using Interfaces ............................................................................ 372

8.4

Summary .................................................................................................... 377

Checking Robustness and Troubleshooting

9.1

Changes and New Developments ..............................................................

9.1.1
General Guidelines for Testing ......................................................
9.1.2
Colleague Checks ..........................................................................
9.1.3
Checklists for Testing Robustness ..................................................
9.1.4
Tools for Testing and Quality Checks .............................................

379
380
385
390
402

9.2

Troubleshooting Incidents .........................................................................

9.2.1
Basic Incident Analysis ..................................................................
9.2.2
Correctness Incidents ....................................................................
9.2.3
Stability Incidents ..........................................................................
9.2.4
Performance Problems .................................................................

439
439
443
446
449

9.3

Summary .................................................................................................... 455

Contents

331

336
336
337
344
359

379

A Proposal for Naming Standards

457

A.1

Program Internal Data ............................................................................... 457

A.2

Formal Interface Parameters ...................................................................... 458

A.3

ABAP Dictionary Objects ........................................................................... 459

A.4

ABAP Workbench Objects ......................................................................... 459

Example of an Exception Handling Class

461

Template for an ALV Report

473

Bibliography

493

On Performance .........................................................................................
On Unicode-Enabling .................................................................................
On Stability and Correctness .......................................................................
Other Subjects ............................................................................................
Other References ........................................................................................

493
494
494
494
495

Author Portraits

497

Index

499

Contents

Exceptions and Error Handling

One of the best ways to make a program behave more predictably, and thereby,
enhance a programs technical quality, is by implementing proper exception handling. Simply put, good exception handling will result in fewer errors. And,
because one of the goals of exception handling is to make it easier for the user to
respond to any outstanding errors, it will have a positive effect on user acceptance as well.
We broadly define an exception to mean any deviation from the normal program
flow.1 Consider, for example, an implicitly generated returncode not equal to
zero that is returned by a SELECT statement, or an unexpected value of a variable
that is used in an IF condition. You should note that an exception is not the same
thing as a coding error. An exception is an unanticipated situation or event encountered during the execution of program logic.
Exception handling is the way in which deviations are detected, caught, and handled. Dealing with exceptions is directly related to the two previously discussed
main topicscorrectness and stabilitybecause both of these software requirements are directly affected by the following results of sloppy exception handling:
runtime errors (program dumps), obscure error messages, incorrect data on lists
or screens, and even inconsistent database tables. To a certain extent, you could
view adding elegant exception handling as adding the finishing touch to a program in order to support its correctness and stability. You could even argue that
exception handling is actually integral to ensuring technical quality.

5.1

The Importance of Exception Handling

Its hard to predict and anticipate all the possible circumstances in which a program will be used. Which exceptions are actually considered often depends
directly on the context in which a program is used. Its quite difficult to predict all
the exceptional situations that may arise. To a certain extent, a programs context
will be clear, and so will the logic that is applied and the data that is processed.
However, theres always a point at which the developers (and other peoples)
knowledge about the context ends, and particular exceptions need to be taken
into account. Ignoring these types of situations is not an option. Therefore, usually, a developer must deal with the typical details of programming techniques in
general and the ABAP programming language in particular. And most often, these
details arent explicitly included; for example, in the functional specifications for a
new program.
1 Note that an exception is defined more strictly in the second volume of Horst Keller, Joachim
Jacobitz, ABAP Objects: The Official Reference, SAP PRESS 2003.

Exceptions and Error Handling

219

On the other hand, even without knowing the context in which a program is
used, its not really that difficult to address each imaginable deviation from the
normal program flow. All that is required is a proper and unbiased look at the program code (which makes exception handling an excellent topic to be checked
during a peer review (see Section 9.1). Moreover, the ABAP language provides all
the necessary means to conduct this kind of checkto raise exceptions, intercept
them, and take the appropriate action when necessary, in current releases and
those prior to Web AS 6.20.
And yet, its well known that exception handling in most customized ABAP developments is incomplete. We can think of various reasons for this:
1. Because the programmer doesnt know how to implement exception handling.
Imagine, for example, that a piece of program code deep down the Call Stack
of a program causes an error: a subroutine calls a function module; this function
module, in turn, calls another function module; and this last function module
generates an exception. The question then is: Where should the exception be
handled? If its better to wait to give an error message until the main line of the
program is reached again, all the context information about the error must also
be returned through the Call Stack.
2. Because the assumptions of initial development arent expected to become
invalid.
Customized developments are often made to rely on assumptions that, according to the developer, make additional exception handling superfluous. As such,
this may be true. However, this ignores the fact that maintenance may have to
be applied later. At the time of initial development, the assumptions that are
made usually cannot be questioned (This simply cant go wrong. We have only
two material types.). However, this will make the program more fragile. Unfortunately, this usually doesnt become obvious until a small change is implemented (for example, related to the introduction of a new material type). Particularly if the change itself comprises only a few lines of code, no one will
consider it justifiable to reinvestigate all the assumptions made during the initial developmentthis would take much more time than applying the actual
change. Nevertheless, even a small change can introduce exceptions that didnt
exist. Therefore, it isnt that the assumptions are invalid when theyre first
made; the problem is that they can become invalid once the program is
changed.
3. Because it takes too much time.
Like testing and documenting developments, implementing exception handling is hardly the most exciting of all development activities; however, it can

220

Exceptions and Error Handling

require a large amount of the total development time of a program. And, if

there are many exceptions to consider, its easy to predict the following all too
common scenario: every exception that doesnt appear to be essential or critical, or whose exception handling seems difficult to implement, will be ignored.
For programmers, who may look for ways to avoid this activity and get away
with it, skipping exception handling is a way to deliver a program according to
plan and budget.
In this chapter, well address these basic dilemmas. Well discuss which exceptions can be used. Well explain the types of exception handling that are less frequently applied but that can nevertheless be useful for customized ABAP programs. And finally, well show you how to avoid the Call Stack dilemma by using
the so-called class-based exception handling (that is, exception handling using
ABAP Objects).
In Section 5.2, well first provide you with an overview of the basics of exception
handling in an ABAP environment. Next, in Section 5.3, well present the main
characteristics of class-based exception handling, and show you how to combine
class-based with existing exception handling. In Section 5.4, we summarize the
most important conclusions.

5.2

Implementation of Exception Handling

Exception handling distinguishes among three different elements (see Figure 5.1):
Generating or raising the exception event
Noticing or intercepting the exception
Acting on the exception

Figure 5.1 RaiseInterceptAct

The first step in exception handling is raising the exception, that is, giving a signal
that something has gone wrong. On the one hand, there are implicit exceptions;
for example, a returncode that is not equal to zero when using an ABAP command such as SELECT, or a runtime exception such as divide-by-zero. On the

Implementation of Exception Handling

221

other hand, explicit exceptions are the ones caused deliberately by the program
logic itself; for example, by setting a specific flag, or by using the RAISE EXCEPTION TYPE <exception class> command.
Independently of how an exception is raised, it must then be explicitly recognized
(or detected, caught, intercepted) by the program code before anything can be
done with it. Lastly, of course, the appropriate action must be taken. For example,
consider sending a message to the end user. To summarize these steps, think of
them as Raise, Intercept, and Act.
This section discusses the standard possibilities for implementing exception handling in an ABAP environment. In Section 5.2.1, well review the available options
for generating and intercepting the exception signal. Next, in Section 5.2.2, well
discuss the most important ways of implementing the exception handling.

5.2.1

Generating and Intercepting an Exception Signal

In this section, well give you an overview of how to intercept the following types
of exceptions: a returncode; unexpected data in IF and CASE statements; an
interface parameter of a subroutine; an exception generated by a function module; a class-based exception; and a runtime error. For the explicit types of exceptions, well also show you how each of them is generated.
Returncode
The first exception signal that each ABAP developer is likely to think of is a returncode that is not equal to zero (sy-subrc <> 0). The system field sy-subrc is used
by many ABAP commands to indicate whether the execution of the command has
been successful: all SQL commands; internal table commands such as READ and
LOOP AT <itab>; and file-handling commands such as OPEN DATASET. However,
even if programmers know this, they often dont explicitly check the returned
value, especially if they expect that nothing will go wrong.
Note that not every returncode indicates an exception. In most situations, such as
when reading database tables or internal tables, a returncode not equal to zero
represents an exception, even if the result is not immediately disastrous. But,
sometimes, a returncode is checked as part of the program logic. To see the difference, consider the following two pieces of ABAP code. The first piece of code
is an example of the use of a returncode that represents a genuine exception:
OPEN DATASET tp_filename FOR INPUT IN TEXT MODE ENCODING DEFAULT.
IF sy-subrc <> 0.
* Exception Handling here-ENDIF.

222

Exceptions and Error Handling

The second piece of code is an example of a returncode that does not point at an
exceptional situation:
DO.
READ DATASET tp_filename INTO tp_string.
IF sy-subrc <> 0.
* This is no exception but a check whether an end-of-file has been reached
EXIT.
ENDIF.
ENDDO.
CLOSE DATASET tp_filename.

The way in which the returncode is used in the first example represents an exception because the file is expected to be available. Even if the exception was foreseen, not handling it will lead to a dump as soon as the subsequent READ DATASET statement is executed. The second returncode does not represent an
exception: its just a way of establishing an exit-condition for the DO loop for processing the file in order to determine if the end of the file has been reached.
Unexpected Data in Conditions
ABAP programs are often based on assumptions about values of data. The statements IF and CASE are examples of statements that determine the flow of a program on the basis of expected values. For example, consider a program whose
flow is determined by the value of a material type, and that only two material
types are expected: RAW (for raw materials) and SEMI (for semi-finished products). In terms of its exception handling, an incomplete CASE statement would
look like this:
CASE tp_materialtype.
WHEN co_materialtype_raw.
* Handling of material type RAW starts here
WHEN co_materialtype_semi.
* Handling of material type SEMI starts here
ENDCASE.

Consider what would happen if variable tp_materialtype contained a value other

than RAW or SEMI. (The assumption that only these two values would be processed by the program was valid during initial development, but it is no longer
valid.) This situation is not anticipated in the code. Without knowing more about
the context of the code, its nevertheless fairly easy to discern that the result of
the ABAP program could become unpredictable. Perhaps, the rest of the ABAP
code will proceed with incorrect data, or a runtime error will occur. We recommend ensuring that the exception is always caught, in this particular case, by adding a WHEN OTHERS condition, as follows:

Implementation of Exception Handling

223

CASE tp_materialtype.
WHEN co_materialtype_raw.
* Handling of material type RAW starts here
WHEN co_materialtype_semi.
* Handling of material type SEMI starts here
WHEN OTHERS.
* The exception is caught here.
ENDCASE.

By inserting a WHEN OTHERS condition in a CASE statement, unforeseen situations

are always recognized and exceptions can be handled accordingly (the same is
true for IF statements).
Interface Parameters of a Procedure
Explicit interface parameters of procedures (that is, functions, methods, or subroutines) are often used to indicate to the calling ABAP code that an exception
has occurred within the procedure. There are two possibilities: using EXCEPTIONS
for functions and methods, and using EXPORTING, CHANGING, and even TABLES
parameters to return results. An example of the second option is the RETURN
parameter of BAPI function modules. This parameter, which has the structure
BAPIRETURN, contains the result of the BAPI. The same technique is sometimes
used in the interface parameters of routines. The following code is for a subroutine call:
PERFORM routine1 USING tp_input
CHANGING tp_result_ok.
IF tp_result_ok = abap_true.
*
ELSE.
* Exception handling
ENDIF.
FORM routine1 USING utp_input
TYPE c
CHANGING ctp_result_ok TYPE boolean.
* The specific function logic is executed here. As a result a
* corresponding returncode is set.
* ...
IF sy-subrc NE 0.
ctp_result_ok = cofalse.
ELSE.
ctp_result_ok = co_true.
ENDIF.
ENDFORM.

If an exception occurs during the execution of FORM routine1, it isnt handled

there immediately. Instead, its reported back to the calling piece of code via the

224

Exceptions and Error Handling

interface parameter ctp_result_ok. So, immediately after executing the PERFORM statement, the value of the interface parameter will indicate whether an
exception has occurred.
Passing on exceptions to a higher level in the Call Stack allows you to separate the
code that takes action on an exception from the code that merely checks whether
an exception has occurred.
Traditional Exceptions of a Function Module
For function modules, a separate part of their interface (the EXCEPTIONS parameters) is reserved for passing on information about exception situations. The associated kind of exception is deliberately raised in the function module (or method)
by executing the RAISE <exception> command. The following code shows an
example of a corresponding function call:
CALL FUNCTION '/CTAC/FM_WITH_TRAD_EXCEPTIONS'
EXPORTING
itp_input
= tp_input_fm
IMPORTING
etp_export
= tp_output_fm
EXCEPTIONS
not_found
= 1
OTHERS
= 9.
CASE sy-subrc.
WHEN 0.
* Everything is OK...
WHEN 1.
* Action needed here...
WHEN 9.
* Action needed here...
ENDCASE.

If a NOT_FOUND exception is raised by function /ctac/fm_with_trad_

exceptions, system field sy-subrc is automatically made to contain value 1.
This returncode must be checked by the calling ABAP code directly after the
CALL FUNCTION statement.
Class-Based Exceptions
The second type of exception that is raised deliberately is the exception that is
raised via using the RAISE EXCEPTION TYPE <exception class> command.
This is part of the implementation of the class-based exception handling concept
available as of Release 6.20 of the SAP Web Application Server (Web AS). After
the exception has been generated, it is intercepted within a TRY-ENDTRY block
with the command CATCH. The exception itself is an instance of a global exception
class. We have added a basic code example:

Implementation of Exception Handling

225

TRY.
SELECT SINGLE * FROM mara INTO wa_mara
WHERE matnr = pa_matnr.
* ...
IF sy-subrc NE 0.
RAISE EXCEPTION TYPE cx_sql_exception.
ENDIF.
* ...
CATCH cx_sql_exception.
* Include exception handling here
CLEANUP.
* This is always executed whenever an exception occurs
CLEAR wa_mara.
ENDTRY.

Runtime Errors
Runtime errors such as divide-by-zero errors or type-conflicts are clear signals of
exception situations that are implicitly generated by the runtime environment.
For example, lets look at the following code:
TRY.
tp_average = tp_total / tp_count.
CATCH cx_sy_zerodivide.
* Include exception handling here
ENDTRY.

If this code is processed and variable tp_count somehow contains a value of

zero, a runtime error will raise an exception CX_SY_ZERODIVIDE. The exception
can then be intercepted by using the CATCH statement before it can do any harm.
Note that some runtime errors can be intercepted (or caught) using either the

CATCH command (up to Release 4.6C) or the combination of a TRY and CATCH
command (as of Web AS Release 6.20). However, it is not possible to catch all
runtime exceptions (for more information, see Chapter 4).

5.2.2

Implementing the Actual Exception Handling

After an exception signal has been raised and intercepted, you must act on it. You
cannot simply intercept a runtime exception to prevent a dump, and then take no
further action. The same is true for a returncode or any other exception signal. For
example, the following ABAP code and added comment lines make little sense,
but are nevertheless sometimes found in customized ABAP programs:
READ ta_itab INTO wa_itab WITH KEY keyfield1 = tp_value BINARY SEARCH.
IF sy-subrc NE 0.
* Now I dont know what to do. I presume this will never happen
* so this explains why no more actions were taken.
ENDIF.

226

Exceptions and Error Handling

So, doing nothing is not an option. On the other hand, you may need general
guidelines for situations where you dont expect an exception to happen, but
nevertheless must consider the possibility. In such cases, we recommend that you
stop the program immediately: this at least clearly indicates that something went
wrong. Letting the program go its own unpredictable way is always worse.
In this section, we address the proper implementation of the steps to be taken after
an exception has been recognized. The main criteria that determine these steps are:
Should the program send a message?
Should the program execute cleanup actions?
Should the program ask for a correction of data?
Should the program continue after the exception has been handled?

These criteria are shown in Figure 5.2:

Figure 5.2 Exception Handling Flow

Implementation of Exception Handling

227

Lets first discuss some more details of the general exception handling logic: message handling and other important actions, mainly consisting of cleanup actions.
Message Handling
The most common part of exception handling consists of message handling. If a
message needs to be sent, there are three things to be done: compose the content of the message (what); choose the destination of the message (to whom);
and, choose the medium (how). Figure 5.3 shows these three steps:

Figure 5.3 Message Handling Elements

Because most ABAP developers are already familiar with implementing regular
message handling in ABAP (using the MESSAGE command), we wont elaborate
further on that subject. However, we do want to emphasize an attractive ABAP
featureapplication loggingwhich is used less frequently than it warrants. This
way of collecting and reporting exceptions is particularly useful in situations where
the end user cannot directly be involved in the exception handling process. Therefore, programs running in the background will benefit most from this feature.
In principle, the same basic topics (what, to whom, and how) are as relevant for
application logging as they are for message handling. With application logging,
the destination of a message is defined in objects and sub-objects with Transaction
SLG0 (see Figure 5.4).

228

Exceptions and Error Handling

Figure 5.4 Customizing Application Log Objects and Sub-objects with Transaction SLG0

The first advantage of application logging is that its sub-objects enable you to
send different types of exception information to the different people involved.
For example, an administrator may benefit most from knowing the program name
and the exact line number where an exception has occurred, whereas an end user
may be interested primarily in knowing which data was actually skipped during
the processing of a background job.
The second advantage of application logging is that it permits you to add both
help information and free text to a message. Furthermore, messages can either be
stored or displayed immediately. This means that the use of the Application Log is
not limited to only background processing.
The third advantage of application logging is that existing functionality can be
reused. Various standard function modules are available. Up to Release 4.6, this
pertains to function modules whose names start with appl. Since Release 4.6,
however, new function modules whose names start with bal are also provided, but the aforementioned function modules are still supported.
Now, well briefly mention the latest versions of these function modules and their
associated functionality. To create an exception object, use function module bal_
log_create. The interface parameters to be supplied are identifying parameter
values such as object, sub-object, and, possibly, your own extra identifying information (e.g., a document number). To add a message to the Application Log, you

Implementation of Exception Handling

229

use function module bal_log_msg_cumulate. To store the Application Log with

all the messages contained in it in the database, use function module bal_db_
save.
Finally, if the Application Log cannot be viewed immediately in your program,
standard Transaction SLG1 is available for displaying it (see Figure 5.5).

Figure 5.5 Display Application Log Information Using Transaction SLG1

Cleanup Actions
In addition to message-handling activities, the other important thing to consider
is whether the program can continue, and if so, how. You may, for example, be
able to skip an erroneous record in a file and continue as before with the rest of
the data. But, even if you think you can continue, you first need to clean up the
mess. In the first place, this means that you need to ensure that all the intermediate variables used still contain the correct valuesthis could require either initializing data (with a CLEAR or REFRESH command), or resetting data to the value
it contained just before the exception occurred, for example, resetting counter
information. See the following simple example of a CLEAR action:
SELECT SINGLE * FROM mara INTO wa_mara
WHERE matnr = pa_matnr.
IF sy-subrc NE 0.
CLEAR wa_matnr.
ENDIF.

If an update has failed, you should probably execute a ROLLBACK WORK command
in order to restore the proper state of the database. Note that a database rollback
is required regardless of whether the program can continue. Inconsistent database updates must always be reversed.

230

Exceptions and Error Handling

5.3

Class-Based Exception Handling

One of the basic dilemmas, already mentioned briefly in Section 5.1, is that adding appropriate exception handling to ABAP code can be a laborious task. This is
one of the main reasons why adding exception handling code to customized
ABAP programs is frequently avoided if it isnt absolutely necessary. In particular,
there is one basic contradiction that complicates exception handling. On the one
hand, actually executing the handling part of exception handling is not always
appropriate in the exact place where the exception is raised. On the other hand,
you want to have as much detailed context information available about an exception as possible. For example, a function module itself may notice an exception,
but nevertheless have to let the calling program do the associated exception handling.
Letting the calling piece of code (or the piece of code calling that piece of code)
do the exception handling means that it must also have all the available detailed
exception information. Passing all this data along the Call Stack can be particularly
cumbersome, especially if it contains several levels. This is where the advantages
of class-based exception handling come into play. Well discuss these advantages
in the next sections. In Sections 5.3.1 and 5.3.2, well show you a basic implementation of class-based exception handling and discuss the most important
characteristics of an exception class. In Section 5.3.3, well discuss the benefits of
class-based exception handling. Next, in Section 5.3.4, well show you where to
start if you want to add class-based exception handling on top of your current
exception handling. Finally, in 5.3.5, well briefly explain how you can create your
own exception classes.

5.3.1

Basic Implementation

Well start with a basic implementation of (ABAP Objects) class-based exception

handling in the next piece of sample code. The RAISE EXCEPTION TYPE
<exception class> command is used to generate (raise) an exception. The
TRY-ENDTRY block represents the area in which intercepting an exception is possible. The CATCH statement is used to actually intercept an exception and trigger
exception handling. In this particular piece of code, two exceptions are taken into
account: a divide-by-zero exception, and a SQL error:
REPORT /ctac/bk12exchandling_5a.
DATA: tp_average TYPE i,
tp_total
TYPE i.
START-OF-SELECTION.
*
TRY.
* This will raise cx_sy_sqlerror

Class-Based Exception Handling

231

tp_average = tp_total / 0.

"SIGNAL implicit

RAISE EXCEPTION TYPE cx_sy_sql_error."SIGNAL Explicit

CATCH cx_sy_zerodivide.
* Handle exception here
CATCH cx_sy_sql_error .
* Handle exception here
ENDTRY.

5.3.2

"Intercept
"ACT
"Intercept
"ACT

Exception Classes

The fact that an exception is implemented as a class in ABAP Objects implies that it
also has some of the main characteristics of a class: an exception class will always
have one superclass and may have various subclasses. In fact, every exception class
that is created must refer to one of three standard superclasses: CX_STATIC_
CHECK, CX_DYNAMIC_CHECK, or CX_NO_CHECK. These standards all have
class CX_ROOT as their superclass. Other exception classes, including those that
you create yourself, must have a direct or indirect relation with one of the aforementioned three superclasses. An exception class tree may look like the one
shown in Figure 5.6:

Figure 5.6 The Exception Class Tree

232

Exceptions and Error Handling

For example, according to Figure 5.6, class CX_SY_ZERODIVIDE inherits some of

its attributes from CX_SY_ARITHMETIC_ERROR, which in turn inherits some of its
attributes from CX_DYNAMIC_CHECK. It is not possible to inherit attributes
directly from class CX_ROOT. In the next section, well describe the benefits of
class-based exception handling.

5.3.3

Details of Class-Based Exception Handling

The use of class-based exception handling has two basic advantages:

Passing on information about exceptions through the Call Stack is done by pro-

viding a reference to the exception object raised using a RAISING parameter.

Note that (in contrast to traditional exception handling) the details of an
exception dont have to be passed on because theyre already contained in the
exception object.
Exception information can be made as context-specific as you want. If

required, you can add your own context-information.

This means that you can pack all possible detailed information about an error into
the exception object immediately at the moment when the exception occurs. You
dont have to decide exactly what specific information needs to be passed on to
a previous level in the Call Stack. Instead, you need only indicate in which exception object this information is stored.
How this works in real-time is explained most easily by showing various examples.
Well discuss the following: the timing of catching exceptions; the level at which
interception takes place; where to intercept which type of exception; an implementation of context-specific exception information; and finally, an implementation of cleanup actions.
Timing the Interception of a Class-Based Exception
The basic advantages of class-based exception handling imply that intercepting an
exception and executing the associated exception handling can be two independent actions. Hence, you can determine the best moment for actually intercepting an exception yourself. The following code example illustrates this principle:
REPORT /ctac/bk12exchandling_5.
* ...
START-OF-SELECTION.
*
TRY.
CALL FUNCTION '/CTAC/FM_WITH_CLASS_BASED_EXC2'
EXPORTING
itp_input = tp_input_fm

Class-Based Exception Handling

233

IMPORTING
etp_export = tp_output_fm.
CATCH cx_sy_zerodivide.
* Handle exception here
CATCH /ctac/cx_dynamic_check.
* Handle exception here
ENDTRY.

"Intercept
"Act
"Intercept
"Act

FUNCTION /ctac/fm_with_class_based_exc2.
*"---------------------------------------------------------------------*"*"Local interface:
*" IMPORTING
*"
REFERENCE(ITP_INPUT) TYPE CHAR10
*" EXPORTING
*"
REFERENCE(ETP_EXPORT) TYPE CHAR10
*" RAISING
*"
CX_SY_ZERODIVIDE
*"
/CTAC/CX_DYNAMIC_CHECK
*"---------------------------------------------------------------------DATA: ltp_total
TYPE i VALUE 10,
ltp_average TYPE i.
TRY.
* This will lead to a zero divide error
ltp_average = ltp_total / 0.
"Signal implicit
*
RAISE EXCEPTION TYPE /ctac/cx_static_check.
"Signal explicit
*
RAISE EXCEPTION TYPE /ctac/cx_dynamic_check. "Signal explicit
CATCH /ctac/cx_static_check.
* Exception handling here
ENDTRY.
ENDFUNCTION

"INTERCEPT
"ACT

The function module /ctac/fm_with_class_based_exc2 that is called in the

code considers (raises) three possible exceptions. The first exception is an implicitly raised runtime error (CX_SY_ZERODIVIDE). The other two exceptions (/
CTAC/CX_STATIC_CHECK and /CTAC/CX_DYNAMIC_CHECK) are explicitly
raised by a RAISE EXCEPTION TYPE <exception> command. Only one of the
three exceptions mentioned (CX_STATIC_CHECK) is actually intercepted within
the function module itself. The other two (CX_DYNAMIC_CHECK and CX_SY_
ZERODIVIDE are intercepted one level up in the Call Stack by using the CATCH
command. To enable the calling code to do this, the function module passes on
reference information about the last two exceptions in RAISING parameters.
Note that the function module loses its influence on the exception handling by
passing on this information. If the calling code doesnt do anything with the provided reference information, a program dump is generated.

234

Exceptions and Error Handling

The Class Level of the Intercepted Exception

In the sample code above, where we discussed the timing of catching exceptions,
each single exception passed along the Call Stack is also intercepted separately.
However, class-based exception handling allows you to intercept exceptions in a
more general way. Consider the following code:
REPORT /ctac/bk12exchandling_5a.
DATA: tp_average TYPE i,
tp_total
TYPE i.
START-OF-SELECTION.
*
TRY.
* This will raise cx_sy_sql_error
tp_average = tp_total / 0.

"Signal (implicit)

RAISE EXCEPTION TYPE cx_sy_sql_error."Signal (explicit)

CATCH cx_sy_sql_error.
* Handle exception here
CATCH cx_root.
* Handle exception here
ENDTRY.

"Intercept
"Act
"Intercept (cx_sy_zerodivide)
"Act

In this code, two exception signals are possible: an implicit exception (divide-byzero), and an explicitly raised exception (of class CX_SY_SQL_ERROR). Only the
latter exception is intercepted with an explicit reference to the exception class in
the corresponding CATCH statement (CATCH cx_sy_sql_error). The implicit
exception (divide-by-zero), on the other hand, is not referred to; however, it will
be intercepted by the CATCH statement that refers to exception class CX_ROOT
(CATCH cx_root). Recall that CX_ROOT is the superclass for all class-based
exceptions. Therefore, intercepting a CX_ROOT exception implies that all exceptions of subordinate types that are not considered elsewhere will also be caught.
This means that you can use the interception of CX_ROOT exceptions as a kind of
extra safety net (similar to using a WHEN OTHERS condition in a CASE statement).
However, there is one particular disadvantage to intercepting exceptions on the
level of CX_ROOT, namely, you lose the context-specific attributes that would be
available in more specialized exception objects. Therefore, this kind of exception
handling is not appropriate for every kind of exception. In general, it is best suited
for intercepting runtime errors because not all possible runtime errors can be
anticipated in your program.

Class-Based Exception Handling

235

Where to Intercept Which Type of Exception

Each type of exception has its own appropriate place where it can best be intercepted and handled. The three most important subclasses (CX_STATIC_CHECK,
CX_DYNAMIC_CHECK, and CX_NO_CHECK) represent the basic exception
types. The specific type of exception determines what happens when an exception is raised within a procedure and not directly intercepted or passed in the
RAISING part of the procedures interface parameters:
CX_STATIC_CHECK

Exceptions of this type must either be caught directly in the procedure where
they are raised, or passed (propagated) along the Call Stack using the RAISING
option. A syntax error will occur if your code doesnt do one of these two
things. Exception classes of this type are most appropriate for relatively predictable exceptions, since they should be explicitly raised in a procedure; for
example, the static exception CX_SQL_EXCEPTION can be raised after a
SELECT statement.
CX_DYNAMIC_CHECK

Exceptions of this type dont necessarily have to be intercepted immediately or

passed (propagated) along the Call Stack. The syntax check doesnt verify this,
only the runtime environment does. If an (implicitly raised) exception of this
type occurs in a procedure and is not caught there or propagated along the Call
Stack, a new exception of class CX_SY_NO_HANDLER is raised by the system.
Runtime errors, in particular, have this dynamic type. Because neither handling
such exceptions directly in the procedure where they occur, nor propagating
them, is practical, the best option is to catch these exceptions in one central
place in your code. This repository is preferably located somewhere in the main
program.
CX_NO_CHECK

Exceptions of this type cannot be passed along the Call Stack with the RAISING
option. If an exception of this type occurs, the system will jump directly to the
first relevant CATCH statement up the Call Stack and skip all other statements.
Exceptions of this type are severe but highly unpredictable and are often
related to system-wide problems, such as a problem with resources. Note that
the aforementioned exception class CX_SY_NO_HANDLER is based on this
type.
In SAP releases prior to 6.20, the propagating technique is not yet available. You
can simulate it using regular interface parameters, however, the programming
required is quite cumbersome. Therefore, we dont recommend applying this
alternative in older releases.

236

Exceptions and Error Handling

Context-Specific Information About an Exception

The minimal information about a particular class-based exception that is always
available is the name of the program causing the exception; the line where the
exception occurred; the name of the exception; and the exception message that
was generated. However, note that all kinds of additional attributes can be added
on top. Consider the following piece of sample code to see how this works:
REPORT /ctac/bk12exchandling_5b.
DATA: rf_static
rf_root

TYPE REF TO /ctac/cx_static_check,

TYPE REF TO cx_root.

DATA: tp_text
tp_extra_att
tp_program
tp_linnr

TYPE
TYPE
TYPE
TYPE

string,
char10,
syrepid,
i.

START-OF-SELECTION.
*
TRY.
PERFORM do_something.
CATCH /ctac/cx_static_check INTO rf_static. "Intercept
tp_text
= rf_static->get_text( ).
"Act
tp_extra_att = rf_static->extra_attribute. "Act
CALL METHOD rf_static->get_source_position "Act
IMPORTING
program_name = tp_program
source_line = tp_linnr.
ENDTRY.
*
FORM do_something RAISING /ctac/cx_static_check.
RAISE EXCEPTION TYPE /ctac/cx_static_check
EXPORTING extra_attribute = 'Extra Info'(001). "Signal
ENDFORM.

"Do_something

When an exception of class /CTAC/CX_STATIC_CHECK is raised (marked bold at

the end of the code) in FORM do_something, an extra attribute is also passed on
in terms of an EXPORTING parameter (called extra_attribute). When the
exception is intercepted, this extra parameter will automatically become available
in the exception object that is instantiated (or created) by using the INTO addition

Class-Based Exception Handling

237

(see the CATCH statement marked bold). In this case, the exception handling triggered by the CATCH statement consists of, among other things, getting this extra
attribute.
Lets also include a more extensive example. In the following code, class-based
exception handling is combined with the use of application logging discussed earlier:
REPORT /ctac/bk12exchandling_4a
.
* This local class contains the actual functions for the appl. log
INCLUDE /ctac/exchandling_new.2
CONSTANTS

: co_log_object TYPE balobj_d VALUE 'ZOBJ',

co_log_subobj TYPE balsubobj VALUE 'USER',
co_error
TYPE symsgty
VALUE 'E'.
* Reference variable for the exception handler class
DATA:
rf_appl_log
TYPE REF TO lcl_exception_handler.
* Reference variables for exception classes
DATA:
rf_sql_error TYPE REF TO /ctac/cx_sql_error,
rf_log_error TYPE REF TO /ctac/cx_log_error,
rf_root
TYPE REF TO cx_root.
* Variables for the application log
DATA:
tp_nrext
TYPE balnrext.
* Context information
DATA:
tp_subrc
TYPE i,
tp_text
TYPE string,
tp_program
TYPE syrepid,
tp_linno
TYPE i.
DATA:

wa_mara

TYPE mara.

PARAMETERS:

pa_matnr

TYPE matnr OBLIGATORY.

START-OF-SELECTION.
TRY.
SELECT SINGLE * FROM mara INTO wa_mara
WHERE matnr = pa_matnr.
IF sy-subrc NE 0.
tp_subrc = sy-subrc.
RAISE EXCEPTION TYPE /ctac/cx_sql_error
"Signal
EXPORTING sqlcode = tp_subrc
tablename = 'MARA'.
ENDIF.
* Intercept this SQL error
CATCH /ctac/cx_sql_error INTO rf_sql_error.
"Intercept
2 See the appendices for this include.

238

Exceptions and Error Handling

TRY.
* Get the information out of the exception object
tp_text
= rf_sql_error->get_text( ).

"Act

* Create the exception handling object

tp_nrext = pa_matnr.
CREATE OBJECT rf_appl_log
EXPORTING itp_object
= co_log_object
itp_subobject = co_log_subobj
itp_extnumber = tp_nrext.
* Add 1 message to the application log
CALL METHOD rf_appl_log->free_message_to_appl_log
EXPORTING
itp_msgty = co_error
itp_text = tp_text.
* Store the messages in the database
CALL METHOD lcl_exception_handler=>write_to_db.
* Intercepting errors during processing of the logfile
CATCH /ctac/cx_log_error INTO rf_log_error.
* Error handling here
CATCH cx_root
INTO rf_root.
* Error handling here
ENDTRY.
CATCH cx_root
INTO rf_root.
* Error handling here
ENDTRY.

In this code, when selecting data from database table MARA, a SQL error is
detected by checking the associated returncode (sy-subrc). An explicit exception is then raised, intercepted, and retrieved from the exception object, and
finally stored in the Application Log. If exceptions occur, they will become visible
in the Application Log (by using Transaction SLG1).
Executing Cleanup Actions
As discussed earlier, the actual exception handling consists of more than just collecting messages: all kinds of cleanup actions must also be performed such as initializing variables and performing a rollback in the event of erroneous updates. In
class-based exception handling, the cleanup actions that are also part of this process are explicitly separated from the rest of exception handling. The following
code shows how this is implemented:
DATA: ltp_subrc type i.
TRY.
wa_luw_1-key1 = itp_key1.
wa_luw_1-notkey = itp_notkey.
INSERT /ctac/tbk_luw_1 FROM wa_luw_1.

Class-Based Exception Handling

239

IF sy-subrc NE 0.
ltp_subrc = sy-subrc.
RAISE EXCEPTION TYPE cx_sy_sql_error
"Signal
EXPORTING sqlcode = ltp_subrc.
ENDIF.
wa_luw_2-key1 = itp_key1.
wa_luw_2-posnr = itp_posnr.
wa_luw_2-somedata = itp_somedata.
INSERT /ctac/tbk_luw_2 FROM wa_luw_2.
IF sy-subrc NE 0.
ltp_subrc = sy-subrc.
RAISE EXCEPTION TYPE cx_sy_sql_error
"Signal
EXPORTING sqlcode = ltp_subrc.
ENDIF.
CLEANUP.
* The exception is not intercepted, but a rollback is really necessary
ROLLBACK WORK.
ENDTRY.

The code contains INSERT actions on two different database tables. If one of the
two INSERTS is not successful, the other database INSERT must be reversed as
well. Note that the code does not contain any CATCH statement to intercept an
error, whereas it does have a separate CLEANUP section for executing the ROLLBACK WORK. This means that a rollback will always be executed if there is an error
in one of the database inserts, even if the error is not caught immediately within
the TRY-ENDTRY block.

5.3.4

Making Existing Exception Handling Class-Based

Thus far, we have emphasized how to apply class-based exception handling as

such, but we havent explicitly mentioned that it is fairly easy to make existing
exception handling class-based. All you need to do is to convert a traditional
exception signal into a class-based signal (see Figure 5.7).

Figure 5.7 Intercept an Exception and Raise Another One

240

Exceptions and Error Handling

Converting a traditional signal such as a returncode into a class-based signal is

done by inserting the RAISE EXCEPTION TYPE <exception> command at the
place where otherwise traditional exception handling would be triggered. Thats
all you need to do. From then on, you must do things in a class-based way. The
following code shows how a traditional signal is converted into a class-based signal:
TRY.
CALL FUNCTION '/CTAC/FM_WITH_TRAD_EXCEPTIONS'
EXPORTING
itp_input
= tp_input_fm
IMPORTING
etp_export
= tp_output_fm
EXCEPTIONS
not_found
= 1
OTHERS
= 9.
CASE sy-subrc.
WHEN 0.
* Everything is OK.
WHEN 1.
RAISE EXCEPTION TYPE /ctac/cx_notfound.
WHEN 9.
RAISE EXCEPTION TYPE /ctac/cx_others.
ENDCASE.
CATCH /ctac/cx_notfound.
* Action needed here..
CATCH /ctac/cx_others.
* Action needed here..
ENDTRY.

As you can see, instead of doing the follow-up of the exception immediately after
the WHEN conditions are checked, you can raise another kind of exception.

5.3.5

Creating Your Own Exception Classes

In the SAP IDES system Release 6.20, which we used for all the examples of ABAP
code and the screenshots, we found 1002 global exception classes.3 So, you
should be able to find a global exception class that best suits your needs. If necessary, you can always create your own exception classes. This enables you to collect your own exception attributes and documentation.

3 Exception classes all begin with the prefix CX_. The allowed customer names are ZCX_,
`YCX_, or /namespace/CX_.

Class-Based Exception Handling

241

Exception classes are global classes. They must be created with the Class Builder
(Transaction SE24, see Figure 5.8). They inherit the methods get_text, get_
longtext, and get_source_position from the exception class CX_ROOT.

Figure 5.8 Definition of Exception Class /ctac/cx_nodata

In Figure 5.8, you can see how exception class /CTAC/CX_NODATA is defined as
a subclass of CX_STATIC_CHECK, which, in turn, is a subclass of CX_ROOT. The
methods if_message-get_text and if_message-get_longtext are defined
in interface if_message and implemented in exception class CX_ROOT. These
methods provide the error message text that is stored in the exception object. The
method get_source_position is defined and implemented in CX_ROOT; it
supplies information on the name of the program, the include, and the source line
where an exception is raised.
Creating your own exception classes is appropriate when developing your own
functionality with the ABAP Development Workbench. Exceptions that are specific for this new functionality can be raised within your ABAP code, supplying all
the relevant context information.

242

Exceptions and Error Handling

5.4

Conclusions

In this chapter, we discussed the most important aspects of exception handling.

We can summarize these aspects in the form of the following guidelines. First, we
recommend that you always intercept every possible exception and take the
appropriate action. Not knowing how to handle an exception is no excuse: if you
dont expect one to occur, you can always stop the program.
Secondly, we propose that you consider application logging for message handling
because of the standard features it offers.
Third, above all, we recommend implementing class-based exception handling as
soon as you have access to the SAP Web Application Server Release 6.20. This
offers more flexibility and reusability than traditional types of exception handling,
particularly for more complicated situations in which exception information must
be passed on through the Call Stack. Raising, intercepting, and actually handling
exceptions are strictly separate activities. Cleanup actions are fully separated from
other exception handling activities. Its relatively simple to detect exceptions in all
your procedures by adding a TRY (at the beginning) and an ENDTRY command (at
the end). Unforeseen exceptions can always be intercepted in the mainline of
your ABAP programs for exceptions of class CX_ROOT and CX_SY_NO_HANDLER. In short, we strongly urge you to take advantage of all these opportunities.

Conclusions

243

Index
A
ABAP 13
ABAP Dictionary Objects 341, 459
ABAP Documentation 45
ABAP List Viewer 93, 105, 203, 253, 345, 351,
473
ABAP Objects 19, 21
ABAP Unit 383
ABAP Workbench Objects 459
Aggregate Data 307
alternative tables 274
amounts 91
anticipated change 333
ANY 310
APPEND 318
ASCII 30, 193
Assembler 13
ASSIGN 167
AT LINE-SELECTION 106
attributes 20
Authority Check 90
Authorizations 89
Availability of Data 109

B
background task 196
BADIs 334
BAPI 347
Batch Data Communication 196, 209
Batch Input 209
Batch Input Map 213
Best Effort 141
BETWEEN 288
Breakpoint at 426, 444
BT 288
Business Configuration Sets 54
BYPASSING BUFFER 308

C
CALL CUSTOMER-FUNCTION 334
CALL DIALOG 209
CALL FUNCTION 324
CALL TRANSACTION 209, 347

CATCH 235
CATT 381
Changes 379
class 20, 126
Class Data 127
class definition 22
class instance 25
Class-Based Exception Handling 221, 231
Class-Based Exceptions 225
Classes 341
class-method 24
Cleanup Actions 230, 239
CLEAR, REFRESH 110
Client Applications 194
client copy 56
client-dependent data 54
COBOL 14
Code Inspector 408, 438, 444
code-page 193
Code-Page Dependency 193
Complex WHERE Conditions 77
Computer Aided Test Tool 59
constructor method 26
Control Flushing 328
Control Statement 98
Control Technology 203
Correctness 18, 73, 390, 403
Correctness Categories 73
Coverage Analyzer 416, 438, 448, 450
CREATE DATA 171
Create watchpoint 425
Cursor Behavior 254
Custom-Made Dynpros 250
cx_dynamic_check 236
cx_no_check 236
cx_static_check 236

D
Data Exchange 140
Data References 170
Data Synchronization 55
Data Traffic 293, 327
database copy 56
Database Inconsistencies 444

Index

499

database update 128, 297

Database Views 82
Date Format 210
Debugger 420, 438, 443
Debugger Watchpoints 443
Decimal Notation 210
DELETE 272, 319
Delete Flag 81
destructor method 26
Development Organization 37
Dialog Functionality 107
Dialog Processing 196
Division by Zero 147
DO 159
documentation 42
documentation standards 43
Downloads 327
Dumps 446
dynamic call 180
dynamic data 166
Dynamic Field Selections 301
Dynamic Function Module Calls 184
Dynamic Method Calls 189
Dynamic Object Instances 186
Dynamic Open SQL 177
Dynamic patterns 360
Dynamic Program Calls 180
dynamic programming 145, 165
Dynamic Subroutine Calls 181

E
EBCDIC 30, 193
eCATT 381
Endless Loops 159
Enhancements 334
Enjoy Controls 203, 351
Error Messages 448
Exactly Once 141
Exactly Once in Order 141
Exception Class Tree 232
Exception Classes 232
Exception Handling 146, 219, 226, 396
Exception Handling Class 461
Exception Handling Flow 227
Exchanging Data 140

500

Index

exclusive lock 133

EXIT 160
explicit workarea 317
EXPORT TO SHARED BUFFER 322
EXPORT TO SHARED MEMORY 322
Extended Syntax Check 153, 403, 438
External Subroutine 112

F
Field List 300
Field Types 147
Field-Overflow 149
Fields Selected 300
Field-symbols 166
Filenames 191
filter 334
Flow Logic Processing 201
FOR ALL ENTRIES 87, 288, 297
FOR TESTING 385
FREE 110
full table scan 280
Function Code Handling 259
Function Groups 341
Function modules 120, 341
Function Pools 125
functional quality 17

G
garbage collector 26
General Rounding Errors in ABAP 94
GET REFERENCE 174
global classes 22
global data 23
GOTO statement 427
grid 352
GROUP BY 307
GUI Controls 203
guidelines 37
Guidelines for Testing 380

H
HASHED 310
header line 317
hotpackage 336

I
Implicit Selection Conditions 82
implicit workarea 317
IMPORT FROM shared buffer 322
IN UPDATE TASK 207
Incorrect Data 443
INDEX 310
indexes 270
infostructures 283
inheritance 27
Inline documentation 45f.
INNER JOIN 298
inner joins 82
INSERT 272, 318
Instance 20, 126f.
Interactive Reporting 105
Interface Data 140
Interface Parameters 458
Interface Parameters of a Procedure 224
Interfaces 372
intermediate data 321
Internal Table Processing 309
Internal Table Type 319
Internal Tables 311
Internet Transaction Server 337
INTO 317
INTO CORRESPONDING FIELDS 302
INTO TABLE 302, 306
Invalid Data Type 173

J
Java 26
Job Log 447
JOIN 292, 297
Joins 82, 86

L
Legacy System Migration Workbench 59
list 352
local classes 22
local data 23
Lock Objects 130, 133
Locking 130
Logical Unit of Work 136, 138, 444

Logistics Information System 76

LOOP 110
LOOP AT 102

M
Maintainability 18, 331, 401, 403
MAX 307
Memory Concept 125
Menus 251
Message Handling 228
Messages 255, 264
method 126
methods 20, 341
Modal Window Functions 258
Modification Assistant 335
MODIFY 319
MODIFY LINE 202
Module Pool Programs 342
Multi-Application Landscape 65
Multi-System Landscape 52

N
namespace 69
Naming Conventions 337
Naming Standards 457
Native OS commands 190
Navigation 260
Nested Internal Table Processing 312
Nested SELECT 303
New Developments 379
Note Assistant 332
Note Browser 332

O
object 20, 25
object-orientation 20
offline development documentation 49
offset 153
ON CHANGE OF 98
one-system landscape 56
online documentation 47
ORDER BY 292
OSS Notes 332
outer join 83

Index

501

P
PACKAGE SIZE 306
Parallel Processing 324
Parameter IDs 123
Patterns 360
Performance 18, 267, 399
Performance Problems 449
periodical refresh 55
primary index 271
private section 23
Procedures 341
Process After Input 343
Process Before Output 343
Process Monitor 453
Process On Help request 343
Process On Value request 343
Processing Data 91
Processing Data Twice 143
Program Internal Data 338, 457
Programs 342
protected section 23
public section 23

Q
quality 16
Quality Checks 402
quantities 91

R
R/3 13, 39, 52
RAISE EXCEPTION TYPE 225
RANGES 288
RECEIVE 325
Recognizability 337
Recursive Calls 161
reference variable 171
Replace 444
Reports 253, 342
Repository Information System 437
Responsibility for Testing 42
result set 179
Reusable Products 363
Reusable Test Data 381
reuse 345
Reuse Library 362

502

Index

Reusing Standard Authorization Functionality 89

Robustness 16, 379
Rounding Problems 94
Rows Selected 295
Runtime Analysis 429, 438, 450
Runtime Analysis Evaluation 453

S
SAP clients 53
SAP Function Modules 345
SAP Professional Journal 15
SAPscript 354, 435, 440
SAPscript Check 439
Screen Layout Check 433, 439
Screen Navigation 261
Screen Processing Sequence 117
Screen Size Settings 213
SEARCH 437
secondary indexes 272
SELECT 74, 77, 269, 293, 303
SELECT INTO TABLE 303
Selecting Data 74
Selecting One Unique Row 74
Selection-Screen 248
Semi-Persistent Memory 321
shared lock 134
shared memory 322
Shared Objects 323
Single Processing 324
Smart Forms 354, 435, 440
SORTED 310
SPLIT 437
SQL Trace 271, 432, 439, 451
Stability 18, 145, 403
Stability Incidents 446
STANDARD 310
Standard Operating Procedures 61
Standard Test Situations 381
Standardization 245
STARTING NEW TASK 206, 324
static method 24
Static patterns 360
statistics tables 283
status fields 81
STRING 311

Structures 153
Subclasses 365
subroutines 341
SUM 92, 307
Support 260
SUPPRESS DIALOG 164
System Performance 449

T
Table Buffering 307
TABLES 113
technical quality 16
Test Approaches 41
Test Data 37, 41, 55, 380
Testing 40, 380, 402
three-system landscape 60
time-out 165
time-out exception 197
Traditional Exceptions of a Function Module
225
Transactions 342
Transport Management System 54
Transports 55
Tree Control 352
Troubleshooting 379, 439
two-system landscape 58
Type-Conflicts 150

Unicode 19, 30, 153, 193

Unicode Check 415, 438
Unique Identifier 142
UPDATE 272
Update Cancelled 444
Update Task 196, 444
Uploads 327
User Authorizations 189
User Exits 334
User-Friendliness 18, 245, 397

V
Validity of Selected Data 78
value-based variables 170
Version Conflict 62
Version Management 37, 63

W
Watchpoint 426
WHEN OTHERS 223
WHERE 74, 77, 269, 295
Where Used List 437, 439
WHILE 159
workarea 316
Workload Analysis 416, 449

X
XSTRING 311

Unanticipated Changes 335

Unexpected Data in Conditions 223

Index

503