Clean ABAP

Document purpose

The ABAP development guidelines define a uniform and obligatory standard for all SAP developments and related activities. Compliance of these guidelines leads to better readable and interpretable programs. Also the effort for maintenance, revision and adjustment will be minimized. In addition it helps to ensure and increase the quality of programs.

Scope of the document

These development guidelines are mandatory for all new developments and changes of existing objects.

However, in the SAP systems there are many historic development objects which were not developed according to these guidelines. For changes on existing, non-compliant objects the following rule applies:

• If the object is reworked substantially (> 50%), the object must be reworked completely according to the rules of this guideline
• For smaller changes the guideline is only valid for the changes itself

In case of uncertainties clarify with the development responsible and the requestor of the development prior to the implementation.

Differentiation of the document

This document does not describe the following:

• The Change Management process or the specification documents that are needed to define an ABAP development
• The documentation standards for developments (besides inline documentation in ABAP source code)
• The development guidelines for other development languages besides ABAP in the SAP area (e.g. Java, JavaScript)

Furthermore, this document does not claim to be exhaustive and consider all aspects of the ABAP programming area. In case of any questions or uncertainties contact the development responsible (see chapter 1.5).

Also note the link to the official SAP programming guidelines which are strongly recommended:

https://help.sap.com/doc/abapdocu_750_index_htm/7.50/en-US/index.htm

Further documents

• Customer-specific Security standards:

General rules

The following chapter contains general principles that must be applied when doing professional business application programming.

Keep it Simple - KISS

As a general rule, limit the complexity of your programs as far as possible.

This means especially:

• Functional logic is implemented in a straightforward way, as easy as possible.
  Avoid technical specialties or unnecessary sorting, looping, processing
• Avoid unnecessary statements
• Choose the shortest normal form for Boolean expressions
• Avoid dynamic coding; use it only where absolutely needed
• Avoid a high nesting depth due to the use of control structures (branches, loops). A maximum depth of five levels is allowed within a procedure / method. The nesting depth should be minimized.
• Put only one statement per line; line indents have to follow the program logic
• Data declarations must be defined as locally as possible and as globally as required.
• Avoid duplicate coding – move reusable code to reusable objects

Don’t repeat yourself – DRY

If a certain functionality is required more than once, it should be extracted into a separate method/form (preferably a static method of a class). This makes maintenance and bug fixing easier. Designing those methods must follow the rules outlined in 2.3.

Separation of Concerns

Separation of concerns is a principle used in programming to separate an application into units, with minimal overlapping between the functions of the individual units. The separation of concerns is achieved using modularization, encapsulation and arrangement in software layers.

This means especially:

• Avoid monolithic blocks of programs, where UI presentation layer, business logic and persistency logic is mixed up altogether.
• Separate UI logic from application logic and database logic as far as possible and organize different software layers
• Define clear interfaces between the different program units

Correctness and Quality

The developed software must follow certain product standards and must be correct and of a high quality. This means that the following standards must be met:

• Functional Correctness
  The developed software must be functional correct which means it is error free, fulfils the functional requirements and is a stable solution; it must be able to handle also unforeseen situations and data constellations and therefore provide a certain robustness

• Security
  The software must comply with the latest security standards, see Further documents and must be hardened to minimize the risk of security leaks. The software must be auditable.

• Performance
  The developments must provide an acceptable runtime performance and must be scalable.

• Usability
  The developed software should support users to perform their tasks as effectively and efficiently as possible. Therefore, the user interfaces must be as intuitive as possible and consistent throughout the SAP systems.

• Documentation
  The software must be documented in the source code (as inline comments) and also a technical and end user documentation must be provided.

• Globalization
  The software will be used worldwide and must therefore follow the standards for globalization. This means especially that texts must be translatable but also that other globalization aspects like time zones, Unicode, screen display, etc. must be taken into consideration.

Transport management

<Kundenspezifika hinzufügen>

Before any transport to other systems, the checks described in chapter 4.4 must be executed. This also applies to transport of copies.

ABAP specific rules

ABAP Objects

ABAP supports both a procedural and an object oriented programming model. Due to the benefits of ABAP Objects it is recommended to use ABAP Objects wherever possible for new and further developments.

Classical processing blocks should only be created in exceptional cases.

Program types and properties

The following program types can be used for developments:

All other program types (Module pool, Subroutine pool and Type pool) must not be used.

Program attributes

The following attributes for new programs must be set:

• Unicode checks active
• Fixed Point Arithmetic activated
• No assignment to a logical database

Original Language

Original language of a new repository object must be English and translations must be provided at least for English and German.

Obsolete statements

Obsolete statements are language elements that are obsolete (old) or that have been replaced by more elegant, newer or more readable language elements. The use of obsolete ABAP commands is not allowed!

For up to date information about obsolete statements, please refer to SAP’s ABAP documentation.

Exception: FORM routines may still be used in the area of Dynpro development (e.g. called in PAI / PBO modules). However, it should be always considered, if a form is really necessary or can be replaced by a (static) class method.

Checks for correctness

The following analysis tools and procedures allow a static check of correctness of ABAP developments. They should be used frequently during development and are mandatory before any transports to other systems. See also chapter 3.

Syntax check

Developments must always be syntax checked in the development environment. A program must not contain any errors or warnings from the Syntax check.

Extended program check

The extended syntax check (transaction SLIN) performs further checks on ABAP programs. A check must be executed by the developer prior to transporting the development to further systems.

A program must not contain any errors or warnings from the extended syntax checks.

Code Inspector

The Code Inspector checks single objects and object sets (programs, function groups, classes, interfaces, DDIC objects) with regard to

• Performance
• Security
• Maintenance capability
• Susceptibility to errors
• Statistical information

The Code Inspector is also used for verification of naming conventions.

To verify compliance with this guideline, the custom check variant <to be added> should be used.

Pragmas and Pseudo comments

If above mentioned analysis tools (SLIN, Code Inspector) are throwing messages for coding that was intentionally designed by the developer in that way, the messages can be suppressed using Pragmas (e.g. ##needed) or Pseudo comments (e.g. #EC NEEDED).

In the case a message is suppressed with a pragma, put a meaningful comment at code line to explain why the check is not valid here.

Example:

Structure and Style

This section covers all aspects of a program that have no direct influence on its functionality. These aspects remain hidden to users when they use the program. However, structure and style are very significant for the traceability of the program flow by a human viewer. The source code must be designed in such a way that a person other than the program developer can work with it properly.

Source Code Formatting

The following rules must be considered when formatting the source code:

• Do not mix uppercase and lowercase in names
• Use only one statement per program line
• Do not use full line width

Pretty Printer

The line indents of a program have to follow the program logic.

This is supported by the SAP tool “Pretty Printer” which must be used to automatically format the source code.

The following settings have to be activated for Pretty Printer:

• Indent
• Convert Uppercase / Lowercase
• Keyword Uppercase

Naming

Please see chapter 10 for the current naming conventions

Comments and inline documentation

This chapter describes the rules for inline documentation of custom ABAP developments

Language

Inline documentation must be done in English to support developers from different nationalities and backgrounds.

Header documentation

The following header documentation must be used per report, per function module, per include and per method.

For new source code objects the pattern for the header must be inserted at the very top of the object (before generated SAP header or REPORT FUNCTION METHOD statement) and filled with the necessary information:

The headers can be found in --> ABAP Workbench --> Pattern --> Other Pattern --> ZEBG_HEADER_V2

If a copy of a SAP standard program is created the header documentation of the program must indicate from which SAP program this copy was created.

In case of changed source code objects the modification history must be added to the header and filled with change information and a meaningful description (e.g):

Inline documentation

For reasons of understandability and ease of maintenance all code must be properly commented.

Inline comments should allow the reader to understand the logic/structure of the code without going through the actual lines of code.

Therefore each processing block must have a comment explaining what is happening here. As a rule of thumb no more than 10-15 lines of code should go without a comment.

These comments should refer to the functional content of the code (rather than the technical)

For example a technical comment

“select VBAP

is much less helpful than a functional one like

“get all sales order items of customer to find corresponding deliveries

Documentation of changes

Changes of existing code objects must be documented by adding a line in the header change history (see above) and also the changed code lines have to be documented with the date, the CR number and the user.

If only single lines were changed, the preferred way to document the change is to add a comment at the end of the changed line, e.g_._ “29.02.2016, ITSCHINDLB2J, CR123456

In case many (more than ~5-10) consecutive lines of code are changed/inserted it is not advisable to mark each and every line of code with the change mark. . In this case use inline change marks

* <<-- <Date> <User> <CR Number> Start

and

* -->> <Date> <User> <CR Number> End

before and after the starting/ending line of modified code.

Additional rules are:

• Do not outcomment obsolete code lines! Delete them instead.
• Remove old change marks, if you are redesigning the entire source code.

In case more lines of code are changed than kept or the adding of change marks would confuse the source code more than explain it, do the changes without change marks and put “redesign” into the modification header.

User documentation

Some development objects support the addition of long text documentation or user documentation. If possible, these features should be used to document the development object for the end user or other developers.

User documentation should be provided at least in English.

User documentation at report

In transaction SE38 an user documentation must be added for each report, especially when the report is executable with a transaction for the end user. The documentation is expected to be sufficient if a user is able to call and use the report without further assistance.

Documentation at function module

Add a documentation of the functionality of the module when creating function modules.

Documentation for classes / interfaces

Add a documentation of the functionality when creating a class.

Modularization and structure

To ensure the rule Separation of Concerns and support the readability of programs, a modular program design must be used. To achieve a modular approach, several techniques are available:

Besides SoC, modularization also reduces the complexity of programs and processing blocks. Large monolithic programs must be avoided and separated into logical components by above modularization techniques.

As a rule of thumb the number of executable ABAP statements within a procedure or method should be reduced to a maximum of 150 statements. Larger entities must be split to different methods. However, the other extreme is also not desirable, a method should not contain only trivial code or become too small;

Procedures should be of a reasonable size that is consistent with the ABAP programming language (modularize instead of atomize).

Modularization of an ABAP report

A new developed ABAP report must be structured by the following rules:

• The uppermost structure of a report is given by the report events. They must be used whenever applicable (so START-OF-SELECTION should always be used and in many cases also END-OF-SELECTION)
• No functional coding or declarations are allowed in the report events. The functional logic must be encapsulated in (local) class methods which are called from the report event.
• The report contents should be structured in includes with below naming conventions (where nn is a 2 digit number 01 – 99):
  • <Reportname>_TOP: TOP Include for Data declarations and local class definition
  • <Reportname>_SEL: Include for Definition of the selection screen
  • <Reportname>_Fnn: Include for Forms
  • <Reportname>_Inn: Include for PAI Modules
  • <Reportname>_Onn: Inlcude for PBO Modules
  • <Reportname>_Cnn: Inlcude for local class implementations

The main structure of the Report should be visible from the main program. See below example for a properly structured report:

Data declarations

Data definitions always appear at the start of a program or subprogram.

Global variables

Global variables may only be used when absolutely necessary, i.e. for data handling on top level of a report or function group.

If global variables need to be used or changed within subprograms (e.g. FORM-routines or local class methods) they must be passed to the routine as parameters. When doing this correct parameter types (IMPORTING, CHANGING, etc.) need to be used.

This way of handling global variables enhances clarity and maintainability of code.

• Clarity and structure of coding is improved since one needs to look only at the main program to see where these variables are used or changed. Also the where-used list of these variables will give a much better overview.
• Maintainability is improved since the impact of changes is much more transparent.

Multiple use of Includes

Includes are only used for structuring and modularization of exactly one master program (e.g. large report or function group). It must not be integrated into multiple different master programs. Also, an include program should only be integrated once within a master program.

To encapsulate reusable code use global classes with (static) methods.

Dialog modules

Dialog modules in Dynpro programming (PBO and PAI modules) must not contain any declarations or functional logic. The logic must be encapsulated in (local) class methods which are called from the dialog module.

Complexity

The aim of program complexity is to keep the source code as clear and readable as possible for the human reader.

To reduce complexity, the following rules apply:

• Limit the complexity of expressions (logical expressions, calculation expressions) to an understandable limit; split complex expressions into multiple expressions
• Restrict the nesting depth of control structures (branches, loops) within a procedure / method to maximum five levels
• Restrict the number of statements in procedures / methods to a maximum of 150 executable statements
• Keep the size of classes and function groups reasonable and avoid a high number of attributes, methods and events
• Remove dead code

Architecture

Object-Oriented Programming

Use object oriented programming where possible for new developments.

Take the following into consideration when developing object oriented:

• Use the benefits of encapsulation and declare the visibility of attributes and methods as needed (keeping the public components of a class as small as possible)
• Declare public attributes only as read-only
• Avoid static classes (a static class consists only of static components); if multiple instantiation should be suppressed, use the singleton pattern
• Avoid deep inheritance hierarchies
• Address interface components using interface reference variables

Error handling

Error handling must be an essential part of the design of every program and must prevent programs for undefined and unexpected cancellations and dumps.

Reaction to error situations

ABAP provides the following concepts that a program can use to properly react to different error situations:

• Exceptions

Exceptions are events in the execution of an ABAP program that interrupt the program when it is not possible for the program to continue in a meaningful way. Exceptions are raised either by the ABAP runtime environment or with ABAP statements (RAISE EXCEPTION) in the program. Exception handling enables a reaction to these events. An exception that is not handled results in a runtime error; that is, the program terminates and outputs a short dump that describes the exception.

• Assertions

Assertions formulate conditions in a program that must be met to ensure a proper continuation of the program. An assertion is defined by an ASSERT statement.

• Messages

Messages are texts that can contain up to four placeholders for value replacements and that can be displayed or otherwise sent using the MESSAGE statement.

The implemented error handling should reflect the most appropriate of the above possibilities to deal with an error situation. Self-defined error handling mechanism like global error flags (e.g. GV_ERROR) or custom return values should be avoided and replaced by proper exceptions.

Exceptions

For handling of exceptions, class based exceptions must be used.

The exception category (abstract global class) must be chosen according to the concrete need:

CX_STATIC_CHECK

Exceptions of this category must be declared explicitly in the interface of a procedure, if they are to be propagated from this interface. The syntax check makes a static check to determine whether all exceptions raised in the procedure with RAISE EXCEPTION or declared in the interfaces of called procedures are either handled with CATCH or explicitly declared in the interface.

This is the mostly recommended way for exception design.

CX_DYNAMIC_CHECK

Exceptions of this category must also be declared explicitly in the interface of a procedure to enable them to be propagated. This is not subject to a static syntax check, however, and is checked dynamically at runtime instead.

This is the recommended way for error situations that can be prevented by the caller by preconditions (e.g. wrong import parameter, wrong usage of the method, etc.). The caller is spared an explicit handling of the exception.

CX_NO_CHECK

Exceptions of this category cannot be declared explicitly in the interface of the procedure. The class CX_NO_CHECK (and consequently its subclasses) is always declared implicitly and the associated exceptions are always propagated.

This is the way for situations that cannot be handled immediately and should only be used rarely.

When describing an error situation, only use exception classes with the correct category and name, the appropriate attributes and texts, and which contain the correct documentation. Do not reuse inappropriate exception classes. Do not use standard exception classes from custom developments, create your own classes instead (maybe inherit from the standard class).

Create suitable exception texts in the exception class and only use these texts.

Exception texts can be created using Message texts (SE91) or texts from the OTR repository.

Before forwarding exceptions to the caller, perform necessary cleanups in the CLEANUP block and close e.g. open database cursors.

Assertions

The ASSERT statement is used to express an assertion in an ABAP program. Such an assertion is either always active or can be activated externally by assignment to a checkpoint group. When the program reaches an active assertion, it evaluates the corresponding condition. If the condition is violated, the following happens, depending on the type of activation:

• The program is terminated with the runtime error ASSERTION_FAILED.
• The program branches to the ABAP Debugger.
• A log entry is generated.

Assertions, together with breakpoints and log points, form the checkpoints of a program; these are not part of the application logic, but are used for development and maintenance support.

Use assertions to check the status of a program for consistency where applicable.

Example:

The programmer expects an internal table always to be filled. To assure this assumption (and document it to the reader) an assertion should be used:

  READ TABLE items INTO current_item INDEX current_index.
ASSERT sy-subrc = 0.

Messages

Messages are used to provide meaningful error descriptions to the end user or to store them in a job log / application log. They are defined in transaction SE91 and are the preferred way to provide error and status messages to the user in dialog and dynpro programming.

The following rules apply:

• Create new messages text with a polite and factual formulation of the error message
• Use the long text of messages for further description of the situation (section “Diagnosis”) and what the user can do now (section “Procedure”)
• Do not reuse SAP standard messages for custom developments, create your own ones (otherwise it is not clear if the error was triggered in SAP standard coding or custom coding)
• Do not define “generic” messages in SE91 consisting mainly of placeholders (e.g. &1 &2 &3 &4)
• Do not use other techniques for message processing (e.g. concatenation of texts, hard coded outputs with MESSAGE <text> TYPE ….
• Be aware that exception classes implementing interface IF_T100_MESSAGE can be processed directly with a message statement (MESSAGE exception_ref TYPE ‘E’….).

User Interface

This chapter focuses on classical user interfaces (dynpros) as these are commonly used still. However, also consider new web technologies (e.g. WebDynpro) for new developments as they are the recommended technology from SAP for new developments in the SAP business suite.

Encapsulating classical dynpros

When developing new user interfaces with classical dynpros, take the rule “Separation of concerns” into consideration and separate business logic from presentation logic.

This means especially:

• Encapsulate classical dynpros and selection screens (create then only in the presentation layer programs provided for this purpose – that are function modules (preferred) or executable programs)
• Encapsulate business logic in global classes
• Encapsulate presentation layer logic in local classes

Lists

Do not use classical lists any more. Use SAP List Viewer (ALV) instead.

User interface consistency

When developing user interfaces using classical dynpros make sure that the Layout and Look and Feel of the new UI is consistent to the established SAP UIs.

This means especially:

• Standard SAP GUI Toolbar buttons (e.g. Back, Exit, Cancel) must be enabled in every UI with appropriate functionality
• Use application toolbar functions (GUI Status) for presenting pushbuttons to the user. Avoid “freely defined” buttons on the dynpro if possible.
• Consider function keys for toolbar functions and use them consistently (e.g. F8 for Execute)
• Use Icons for toolbar functions and use the icons consistently
• Use texts from Data Dictionary where possible (e.g. Selection texts on Selection screen, Field labels, etc.)
• Use F4 helps where possible
• Use SET / GET Parameters on selection screens where applicable
• Provide ALV Lists with typical features such as
  • Sorting
  • Filtering
  • Possibility to change and save own layout
  • Export functionality

Maintenance dialog

For table maintenance (e.g. customizing tables) a maintenance view must be generated with the Table Maintenance Generator (in SE11, SE54). A separate function group must be used for the maintenance dialog which is named the same as the table.

For each maintenance view a transaction has to be created (parameter transaction for SM30 or SM34 that calls the maintenance dialog directly).

Data storage

Persistent data storage

ABAP programs can have both read and write access to data in the following persistent storage media:

• Relational database tables in databases
• Data clusters in special database tables
• Binary files or text files on the application server
• Binary files or text files on the PC if SAP GUI is used

According to the SoC principle, such accesses should be wrapped in service classes of the persistency layer of the application. This must especially considered when writing data to the database, here update function modules should be used as lowest layer to database access.

Database normalization

When new database tables are created in the Data Dictionary the developer must ensure in the database design that all rules for database normalization are considered. The database design and the relations between tables must be specified in the Solution Design prior to development.

For general information regarding database normalization refer to the following link:

https://en.wikipedia.org/wiki/Database_normalization

Redundant data storage must be avoided and is only allowed in special situations (e.g. data aggregation for reporting).

Update of SAP standard tables

The direct update of SAP standard tables with SQL commands from custom programs is not allowed.

For updating SAP tables, the appropriate function (e.g. BAPI, class API or IDocs) must be used.

Native SQL statements

The use of native SQL statements is not allowed.

If there is a requirement which cannot be achieved with OpenSQL, this must be clearly specified in the development specification and well-founded. Approval from Development Manager is needed prior to implementation.

Client handling

Data access to table contents from a different client is not allowed.

Usage of shared Memory

The usage of shared memory is only allowed in exceptional and well-founded cases. A clear design with an explanation of the need for shared memory needs to be provided prior to implementation as well as an approval from the Development Manager.

When performing access to shared memory, the statements EXPORT TO SHARED MEMORY / EXPORT TO SHARED BUFFER (as well as the import statements) are not allowed. A shared memory access must be implemented using shared objects.

Usage of ABAP Memory

Usage of EXPORT TO MEMORY / EXPORT TO DATABASE is allowed only in exceptional cases. If data transfer between program contexts is needed use global classes with static attributes and set / get methods.

Exceptions need to be clearly specified in the development specification and well-founded. Approval from Development Manager is needed prior to implementation.

Locks

When updating data in custom tables, a proper locking mechanism must be implemented according to the available options in SAP.

A database update could consist of the following steps:

• Lock data to be updated
• Read current data from the database
• Process data and write to the database
• Release the lock

It is advisable to encapsulate database write operations in update function modules.

Robust ABAP

For general information, please also refer to the official robust ABAP guidelines:

https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-us/abenrobust_abap_guidl.htm

Data types and Data objects

Declaration of data types and constants

Data types and constants must be declared in the appropriate context, which means for cross-program types ABAP Dictionary or global classes / interfaces and for local program types the global declaration part of the program, global classes / interfaces or within procedures / methods.

New type pools must not be created.

The preferred way for declaring constants is as attributes of a global class or interface.

Declaration of data types in the Data Dictionary

Declaration of data types in the Dictionary is the preferred way for declaring reusable data types.

When declaring data objects (especially structures and tables) in the Data Dictionary the direct declaration using Data type, length, Decimals (predefined types) is not allowed. Always use Data Elements / Components for declaration.

When declaring database tables, consider the following:

• Database tables must be client dependent, with the field client as first key field (MANDT).
• Primary key and indexes, if required, must be defined during creation, furthermore the technical properties of a table must be maintained in accordance with their purpose of use.
• Foreign key dependencies must be maintained.
• Fields must always relate to a data element and not to direct data types
• Pool and cluster tables may not be created
• For language dependent texts, text tables have to be created

Declaration of variables

Variables must be declared in the appropriate context and as local as possible to avoid global variables.

The possible contexts are for cross-program variables the attributes of a global class or interface and for program-local variables the global declaration part of a program, as attributes of global classes or interfaces or in procedures / methods for local variables.

If a variable is dependent of another data object than this variable must be declared with reference to the dependent object using the LIKE statement. This is especially valid for local variables that are dependent of a parameter of a method or for work areas of internal tables.

Example:

DATA: lt_table TYPE SORTED TABLE OF marat WITH UNIQUE KEY matnr,
ls_table LIKE LINE OF lt_table. " dependent variable

The declaration of internal tables with header lines is not allowed.

The statement TABLES is only allowed to define a work area to be displayed on a classical dynpro.

The NODES statement is not allowed.

No hard coded literals

No hard coded literals must be used. Instead, use (global) constants encapsulated in a global class or interface.

Text literals are defined as text elements, SO10 texts or OTR texts (see CL_WD_UTILITIES=> GET_OTR_TEXT_BY_ALIAS for easy access to OTR texts). The text literals should be defined at 50% longer than is actually required in the original language.

For checking truth values, the data type abap_bool and the constatns abap_true and abap_false should be used (rather than SPACE or ‘X’).

System fields

The following rules apply when working with SAP system fields (sy-xxxx fields).

• Do not write to system fields
• Do not use obsolete or internal system fields
• Evaluate system fields in the right position
• Evaluate and check the return value sy-subrc after every ABAP statement that sets the value according to the SAP documentation (especially after SELECT statements, READ TABLE statements and function module calls)
• Do not use system fields as actual parameters (for methods, function modules, etc.)
• Do not use system fields on the user interface

Exiting procedures

In ABAP, procedures / methods are exit usually when the END statement is reached. To exit a procedure earlier, the following options are available:

• RETURN
• EXIT
• CHECK
• Triggering exception

As the statements EXIT and CHECK can also be used within loops, only the statement RETURN is allowed to exit procedures / methods. This increases the readability and clarity of the source code.

EXIT and CHECK can be still used to exit loops.

Dynamic programming

In general, dynamic programming should be kept to a minimum and only used where needed. The need for dynamic programming must be explained and specified in the solution document prior to implementation.

Especially the generation of programs with the statements INSERT REPORT or GENERATE SUBROUTINE POOL is not allowed.

Conversion Routines

For all data conversions of the SAP standard such as units, amounts, currencies, dates, the standard SAP conversion modules have to be used (e.g. CONVERSION_EXIT_ALPHA).

Performance aspects

The following chapter defines rules and guidelines to ensure an acceptable and optimal runtime performance of custom developed ABAP programs.

Performance analysis

Each developer is responsible to use the ABAP Runtime Analysis (SE30) proactively to check runtime of code segments, database access and internal table handling. This should be part of the developer testing prior to release of the development for user testing.

Database access

Consider the following rules for performant database access.

Keep database access to a minimum

• If you want to evaluate selected data records several times, use mass operations instead of individual ones. Transfer the data between database and internal table in one go (e.g. SELECT INTO TABLE)
• If possible avoid several accesses to the same data (for example a SELECT before an UPDATE or DELETE).
• Avoid SELECT statements in Loops. Better use SELECT INTO TABLE and work with internal table from then on.
• Limit the amount of database tables that are joined at one time. As a rule of thumb a maximum number of 3 tables in a join is acceptable.
• Avoid SELECT… ENDSELECT statements
• Avoid nested SELECT loops, use the following alternatives:
  • VIEWS in the ABAP Dictionary
  • JOINS in ABAP OpenSQL
  • SELECT STATEMENTS with FOR ALL ENTRIES

Use the SAP table buffer

The SAP table buffer should be activated for all tables that are often used only with read access (and are not too large), for example Customizing tables. This can increase read performance a lot

The following statements bypass the buffer and should therefore be handled with care:

• SELECT ... BYPASSING BUFFER
• SELECT FOR UPDATE
• SELECT with aggregation function (COUNT, MIN, MAX, SUM, AVG)
• SELECT DISTINCT
• SELECT ... WHERE ... IS NULL
• ORDER BY (with exception of PRIMARY KEY)

Keep selected data set to a minimum

• Keep the quantity of selected data as small as possible, to avoid unnecessary network transports. Always use the appropriate Open SQL statements with the WHERE clause.
• Do not select any unnecessary/additional data only to discard it again (for example via statement CHECK).
• Use the database table indexes for an efficient use of the WHERE clause. The primary key of a table automatically forms its primary index. Additional secondary indexes can be created in the ABAP dictionary.
• Long dynamic WHERE clauses should be avoided, since the system has to divide these into several individual statements for the database system. The internal algorithm can reach the conclusion to execute a FULL TABLE SCAN, which can impact performance.
• If possible, avoid using the logical NOT in WHERE clauses. Use inverted operators instead, since logical NOTs are not supported by database indexes.
• For creating joins over database tables an index should be used at least for the inner table for the fields in the join condition. Alternatively use the “FOR ALL ENTRIES” select statement
• When sorting, think of using “ABAP SORT” instead of “ORDER BY”. The ORDER BY clause is executed on the database server, while the SORT statement is executed on the application server.
• If not really needed avoid the aggregate (Count, Max, Min) functions in the database selection since this will increase runtime considerably and circumvents buffering
• If only one table line has to be read, use SELECT SINGLE with a fully specified key
• If the existence of an entry must be checked use SELECT SINGLE and not SELECT COUNT.

Keep transmitted data to a minimum

Only transfer columns of the database table that are really required. Avoid using SELECT * (only allowed if the majority of field of a table is needed).

Use UPDATE only for the specific columns that are required.

Definition of views

• The largest table should be defined as the primary table in the view, if access here is qualified i.e. with a key that is as complete as possible.
• Never define the JOIN conditions without a client and with as much field agreement as possible so that the database can at least use secondary indexes.
• Specify all key fields in the field list in particular if a view can be used in several programs or more than four tables can be linked

Database index

Each index is a burden on the database because it needs to be maintained whenever records are added or deleted. In addition, too many indexes can mean that the database organizer chooses an incorrect access plan for an access. As a rule of thumb, a table should not contain more than 6 indexes.

Creation of an index should always be the last measure to be taken in case of performance problems. First analyze the code: often ABAP internal changes will solve the problem.

If an index really needs to be adjusted or created this needs to be aligned with the Development Manager.

Internal Tables

SAP supports different internal table types:

• Hash tables work with a hash algorithm that works consistently fast, up to a maximum of 2.147.483.647 table entries. These tables should be used if you want to perform many accesses using the complete key (hash tables are optimized for single record accesses). The key of hash tables must be unique.
• Sorted tables are a special form of standard tables that are sorted. Access is possible using the table index or key. The key of sorted tables can be unique or non-unique. The access speed is reduced logarithmetically depending on the number of entries. These tables are suitable for the mass processing of tables using a partially qualified key.
• Standard tables offer flexible access to table entries. If the table is sorted it can be read using READ BINARY-SEARCH. If such tables are read unsorted the process time increases linearly with the number of entries. During the definition of a standard table a non-unique key cannot be defined. As a result, the line-by-line filling of a standard table can be carried out quickly, because it is not necessary to search for existing entries for every line.

Use the appropriate type for internal tables

The type of an internal table must be chosen according to its need. Here the following rule applies:

Prefer HASHED TABLES over SORTED TABLES over STANDARD TABLE and access tables with TABLE KEY.

Always declare the table type explicitly, TYPE TABLE is not allowed.

Consider also the following:

• Use Hash tables to process large amounts of data (assuming that you access single records only, and that their keys are fully specified)
• Do not use DELETE or SORT for a hashed table since this increases the memory consumption
• If possible, use explicitly defined keys for access to internal tables. READ with TABLE KEY provides better optimization than READ with KEY
• Sort internal tables by fields in the correct order, which is used in a READ TABLE statement using BINARY SEARCH.
• Use sorted tables for range accesses involving the table key or index accesses
• For large internal tables where only some rows are processed, use the SORT and the READ TABLE command to set the index to the first relevant row before looping from that index. Use CHECK or IF…EXIT…ENDIF where appropriate to exit from the loop
• Sort fields and sort order in the SORT statement should be mentioned explicitly (e.g. SORT ITAB BY FLD1 FLD2 ASCENDING)
• Use Field Symbols when looping internal tables
• Use Field Symbols when updating single lines of a internal table
• Use MODIFY ITAB ... TRANSPORTING f1 f2 ... WHERE condition for a set of lines to accelerate the update of an internal table

Avoid sequential search

Sequential search takes place if internal tables with (incomplete) keys need to be accessed and therefore no (explicit or implicit) index can be used.

A sequential search can happen using the statements READ ..., LOOP ... WHERE ..., INSERT ..., MODIFY ..., DELETE ... and will happen in the following cases:

• The key specification in the WHERE or WITH KEY clause is not left-justified with regard to the key
• The key specification in the WHERE or WITH KEY clause also refers to non-key fields
• The WHERE clause (if used) does not only consist of linked equality comparisons using AND

If a sequential search with low performance is detected, use the following options to improve performance:

• In case of standard tables: Convert the table to HASHED or SORTED with appropriate key
• Change the order of the keys or the keys itself
• Introduce a secondary index using a second HASHED or SORTED table

Security

All custom programs must be compliant to the relevant security guidelines. Each developer is responsible to consider security aspects in his developments and minimize the risk of unforeseen and unsecure use of his programs. For further information, refer to chapter 1.4.

Authorization checks

All custom developments must check the authorization of the executing user.

Authorization check: General

A proper authorization check in ABAP is performed by the ABAP statement AUTHORITY-CHECK and a subsequent sy-subrc check. The Authority-Check hast to be performed against a standard or custom development object and also check the appropriate authorization fields.

Custom authorization objects must be approved by the development responsible prior to implementation.

If authorization checks are necessary e.g. for organizational units such as accounting area, plant or the like, then if possible an examination should take place in the selection dialogue (during input of the selection criteria). Is it necessary to check at the level of the data sets (e.g. FI document types or cost centers are not present in the selection screen) the records should be removed with a reference to the lack of authorization prior to the issue.

In the table USORG_DB the organizational units care to be found, which are to be secured at least by authorization checks.

The following is an overview of some common SAP Authorization Objects:

All other pseudo authorization checks are not allowed, this means especially:

• Checks against user name SY-UNAME are not allowed
• Checks against custom defined authorities (e.g. customizing table values) are not allowed
• Direct checks against authorization roles are not allowed

Authorization check for CALL TRANSACTION

When using CALL TRANSACTION, the same authorizations should be checked as for a direct transaction start, which is not automatically performed by the system in that case.

The function module AUTHORITY_CHECK_TCODE should therefore be called up before CALL TRANSACTION. This function module executes exactly the same authorization checks as are executed for a direct start of the transaction.

Authorization check for Table maintenance dialogs

When defining a table maintenance dialog in SE11 or SE54, a proper authorization group must be assigned. The default group &NC& is not allowed.

Security issues

Backdoors

Hard-coded credentials are a “no-go”! Don’t make use of hard-code credentials. Also remove user-based break-points from the program flow.

Check for Directory traversal

Use logical files to avoid directory traversal vulnerabilities. They have been significantly improved in 2010 to include new security features. This is THE solution against directory traversal path attacks. On top of this, they abstract from the actual operating system that the AS runs on.

To prevent path traversal attacks in ABAP programs:

• Do not implement file access functionality that is based on user input, unless there is no other alternative.
• Call FILE_VALIDATE_NAME prior to accessing the file system (for example, with OPEN DATASET) to ensure that the file being accessed is in a valid directory as specified in the logical file name mapping table. Or use the FILE_GET_NAME FM in order to validate the filename against a logical file name.
• Validate the file name again directly before the OPEN DATASET or related statement.

Details of this mitigation strategy are described in Note 1497003 and its attachments (especially SecureProgramming_LogFileNames.pdf)

Check for SQL Injection

Especially when programming dynamic SQL statements, the risk for SQL injection has to be minimized.

Possible strategies are:

• Avoid dynamic SQL programming
• Check dynamic SQL for proper quoting (using cl_abap_dyn_prg=> quote_str and cl_abap_dyn_prg=> quote)

RFC-function modules without proper authority checks

Ensure the following for safe and secure remote callable function modules:

• Include an authorization check in the function module OR
• Ensure that the function module is only called from the same system using function module RFC_WITHIN_SAME_SYSTEM OR
• Remove the flag RFC enabled

Generation of programs

Avoid the dynamic generation of programs with statements GENERATE SUBROUTINE-POOL and CREATE REPORT. If it is necessary nevertheless, consider the following:

• Limit the access to program generation with proper authority checks
• Ensure that the generated coding cannot be manipulated (e.g. by adding dangerous code statements to the generic part)
• Work with white- and black lists for allowed statements

Modification and Enhancements of SAP

Modification of SAP standard objects

Modifications made to the SAP standard system must be evaluated critically for a number of reasons:

• Support by SAP is not provided
• Significantly higher maintenance effort
• Increased complexity and effort during support package installations and upgrades
• Effects on all involved modules must be checked
• The sum of modifications may lead to a system that is out of control

Modifications should only be considered, if all the possibilities of configuration, user exits and business add-ins have been fully exhausted and if the business requirement fulfills a significant business benefit.

Modifications must be clearly specified in the solution document and approved both by the responsible Application Owner and the Development Manager prior to implementation.

The specification requirements and documentation rules must be strictly observed when doing modifications.

When performing a modification in the SAP standard, the use of the modification assistant is obligatory. All coding inserts must be encapsulated in appropriate modules (preferably methods). The aim is to change as few lines as possible in the SAP original object.

Copy of SAP standard programs

The copy of SAP standard programs to customer namespace is some sort of “pseudo” modification and has to be avoided because the original source may be changed during support packages and upgrades which is then not reflected to the customer copy.

Therefore the copy of a SAP standard program is not advisable and can be seen as even more problematic than a modification. If there is nevertheless a need for a copy, it must be approved by the responsible Mater Application Owner and the Development Manager prior to implementation.

In the copy, the standard source program must be clearly referenced in the documentation header.

Extension of SAP standard

The SAP system provides different possibilities for the extension of the standard.

Modification-free extensions are such extensions, which SAP already planned. These do not affect system maintenance and remain also with release changes, patches and upgrades. That includes user exits, customer functions, Badis, Open FI and certain enhancements. In some places, SAP provides extensions for historical reasons in the form of modifications before (e.g. MV45AZZ). This should not be considered as modifications.

However, implicit Enhancements of SAP standard programs (Source-Code Plugins) must be considered as modification even if no registration key is required. This is because implicit enhancements bear similar risks when upgrading systems as modifications.

Therefore, for implicit Enhancements (Source-Code Plugins) the same rules apply as for normal modifications (see chapter 9.1)

User exits

When implementing User Exits and Customer exits, no functional code should be placed in the exit. All functions are to be implemented in a separated enclosed block (method) and to be included via a call of this method in the exit.

User exit control

All user exits must be registered in the User exit control. For details see the referred document for User exit control.

Summary

The following summary gives a guideline how to choose the appropriate enhancement technology and which approvals are required to be allowed to perform the enhancement:

For further information on choosing the best enhancement technology and finding the most stable points for enhancements see below link:

http://scn.sap.com/people/thomas.weiss/blog/2009/01/15/how-to-get-the-most-from-the-enhancement-and-switch-framework-as-a-customer-or-partner--tips-from-the-experts

Naming conventions

The following chapters describe the naming conventions for ABAP developments and therefore the uniform and binding guidelines for naming of software objects (e.g. classes, function modules) and for naming of objects in the source code (e.g. variables).

The goal is to cover each possible type of development object with a corresponding rule in below chapters; however, due to new features in SAP and the evolution of the programming language ABAP there might be objects, which are not covered in the naming conventions yet.

In this case please get in contact with the responsible persons named in chapter 1.5 to clarify the naming of an undefined object prior to naming the object in the repository.

Language

For naming of development and repository objects the language English must be used.

Therefore names of repository objects and local program objects must consist of English words only. If there is a difference in the British and American spelling, use the American spelling.

Namespace

The separation between customer objects and SAP objects can be carried out via the prefixes Y or Z as well as via an own namespace.

Below examples are only provided based on prefix “Z” but are valid for all namespaces. The appropriate namespaces must be clarified before start of the implementation and adhered to. The following rules apply:

Naming conventions for customer repository objects

The following chapter defines naming conventions for all custom repository objects.

The objects are listed in alphabetical order.

Legend

The naming conventions use abbreviations to define variable components of the name. These abbreviations are explained below.

Table 1 Abbreviations

List of Modules:

Table Modules

If a development does not fit one of the modules defined in above table, it must be clarified with the development responsible whether to extend the table or define a different naming.

It is not allowed to define own module interpretations by a developer or put uncertain objects to the Cross-Application Components.

In order to improve readability take the available length of the object name into consideration and avoid too long names where possible.

For separations “_” (underscore) shall be used.

The below tables containing the naming conventions define the allowed length for the name as well as the available length in brackets.

For example, length 30(30) means, that an object name can be technically consist of maximal 30 characters and all 30 characters may be used; length 25(30) means that the technical available length is 30 characters but only 25 are allowed for naming by the developer according to the naming rules.

The reason for restriction of the maximal allowed length is to support predefined suffixes.

Adobe forms - Form

Adobe forms - Interface

Append structure

Append field names

Application log object

The convention is valid for both Log object and sub object.

Append to search help

Area menu

Authorization object classes

Authorization object classes must be approved by the security / authorization team.

Authorization objects

Authorization objects must be approved by the security / authorization team.

BOR object types (internal object names)

BSP Application

This naming convention also applies to other BSP components, e.g. BSP extensions

Business Add-In (BAdI) - Definition

This convention is valid for BAdI Definition in SE18

Business Add-In (BAdI) - Interface for definition

Change document object

Class (ABAP objects)

Normal ABAP classes:

Exception Classes:

Classes for implementing BAdIs

Data elements

Domain

Enhancement Definition

Enhancement Implementation

Enhancement Spot

Enterprise Services

Function group

Function groups for maintenance views must be named the same as the corresponding table / view. Function groups for maintenance views must be generated for each table individually.

Function module

IDoc – Segment type

If the structure of a data base table is to be illustrated, then if possible the name of the data base table is to be added. With a copy of SAP standard segment the name of the segment is to be taken over, e.g. Z1EDK01.

IDoc – Segment name

IDoc – Basis type

IDoc – Extension type

The extension of IDoc types start with Z. Extensions therefore assume the name of the standard IDoc type extended with a version counter (2-digits).

IDoc – Message types

The name of message types should not use the entire length, so linked IDoc types takes over the name and append a version counter.

Include

See chapter “Report / program”

Interfaces (ABAP objects)

Lock object

Menu

Message class

Number range object

Package

Objects of the ABAP workbench that belong together should be grouped within a package. The package describes the work area of an object and defines its transport characteristics by the transport layer. If there is a huge amount of packages it is recommended to create subordinated packages to increase the clarity.

Each project team is itself responsible for the creation and use of packages. As a basic guideline to provide assistance at this point, it should be noted that no more than 300 objects per package are created (to help with clarification).

The created packages must always belong to software component “HOME”. If the component is different all developments are marked as “modifications with the repair flag”.

Report / program

The length of the naming for reports is restricted to maximum 26 characters.

The above naming is for the Report frame. It’s includes must follow the following naming rules in order to identify their contents.

SAP Script forms

Search help

Short texts (SO10)

The maximum text length within the transaction SO10 includes 70 characters. As some applications can only handle 32 characters, the maximum length of this convention is also set to 32.

Short texts text ID(SO10)

Smartforms

Smart styles

Smartforms Text module

SPA / GPA Parameter

Structure

Table

Pool and cluster tables my not be created within customer specific developments.

Text tables are named with a trailing “T” and have the same name as the corresponding main table. Therefore the name of a table should not exceed the length of 15 characters.

For maintenance views, see 10.3.50

Table types

Transaction code

Transformations

Views

View cluster

WebDynpro

This naming convention also applies for all WebDynpro related objects, e.g. WebDynpro Components, WebDynpro Applications, Component Configurations and Application Configurations.

Naming conventions of variables

To ensure readability and clarity of custom developments the following naming conventions must be used for program internal data declarations and definition of parameters.

Declaration of global variables

Use the following conventions for declaration of global variables e.g. in TOP Includes of reports or function groups.

Declaration of local variables

Use the following conventions for declaration of local variables e.g. in method implementations or forms.

Type definition

Use the following conventions for type definitions e.g. in programs or classes.

Field symbols

Use the following conventions for definition of field symbols. As a field symbols refers to another data object, the naming convention reflects the visibility (global, local) and the type of the object

Selection screen

Use the following conventions for definition of selection screen data objects.

Parameters in function modules, subroutines and methods in classes

Use the following conventions for definition of parameters in the signatures of function modules, form routines and class methods.

Internal declarations (constants, types, etc.) in classes or interfaces