SAP ABAP DEVELOPER

HANDBOOK

Version: 0.1 Draft

Security Classification: Confidential
DOCUMENT CONTROL
Release History

Version Date Author(s) Comments

0.1 Friday Bryan Ranson, Initial
12/08/2011 Julie Waller

Approval

Approver Role Signature

Ken Saggers SAP Support, Senior Technical Analyst
Andre Muecke Business Applications Manager - SAP

Reviewers

Name Role
Andre Muecke Business Applications Manager - SAP
Ken Saggers SAP Support, Senior Technical Analyst
Giampaolo Lupi Transition Manager - SAP
Satyan Ghumatkar SAP Technical Consultant

SAP ABAP Developer Handbook Page 2 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
TABLE OF CONTENTS

1 INTRODUCTION 7
1.1 Purpose 7

1.2 Scope 7

1.3 Intended Audience 87

1.4 Good Development Practices 87

1.4.1 Do’s 87
1.4.2 Don’ts 8

2 GENERAL PROGRAMMING RULES 8

3 SAP DEVELOPMENT NAMING CONVENTIONS 1211

3.1 Overview 1211
3.1.1 Customer Name Space ID 1211
3.1.2 Process Area/Application ID 1211

3.2 ABAP Dictionary 1312

3.2.1 Transparent Tables 1312
3.2.2 Structures 1413
3.2.3 Table Fields 1413
3.2.4 Views 1514
3.2.5 Domains 1514
3.2.6 Data Elements 1615
3.2.7 Lock Objects 1615
3.2.8 Search Help 1817
3.2.9 Matchcode Objects 1817
3.2.10 Table Types 1817
3.2.11 Type Group 1918

3.3 ABAP Program 2019

3.3.1 Program Naming 2019
3.3.2 Report Variant 2423
3.3.3 Module Pool Names 2423
3.3.4 Dynpros (Screen) 2524
3.3.5 GUI Status & GUI Title 2625
3.3.6 Transaction Codes 2726

3.4 Other Object Types 2827

3.4.1 SAPscript 2827
3.4.2 Smart Forms 2827
3.4.3 ALE/IDOC’s 29
3.4.4 Workflow 32
3.4.5 Packages/Development Classes 32
3.4.6 Area Menus 33
3.4.7 Messages 33
3.4.8 Logical Databases 33

SAP ABAP Developer Handbook Page 3 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
3.5 Background Jobs 35

3.6 Batch Input Sessions 36

3.6.1 File Naming 38

3.7 Layout Sets 38

3.8 Legacy System Migration Workbench (LSMW) 38

3.8.1 Project 38
3.8.2 Subproject 39
3.8.3 Object 39

3.9 Naming Conventions for ABAP Objects 39

3.9.1 Global Conventions 39
3.9.2 Class-local Conventions 39
3.9.3 Exceptions 42

4 REUSABLE DEVELOPMENT OBJECTS REPOSITORY 43

5 SAP ABAP ANALYSIS TOOLS 43

5.1.1 Extended Program Check 43
5.1.2 Activatable Checkpoints 43
5.1.3 Runtime Analysis 43
5.1.4 Performance Analysis 44
5.1.5 Coverage Analyzer 44
5.1.6 Runtime Monitor 44
5.1.7 Memory Inspector 45
5.1.8 Code Inspector 45
5.1.9 ABAP Unit 45

6 PROGRAMMING STANDARDS 46
6.1 General Rules 46

6.2 Documentation 46
6.2.1 General Documentation 46
6.2.2 Documentation on Data and Program Flow 5150
6.2.3 Documenting Form Routines 5352
6.2.4 Documentation in ABAP Objects 5453

6.3 Programming ABAP Objects 5453

6.4 Dialog Program Standards 5453

6.4.1 Table Buffering 5554
6.4.2 SAP List Viewer (ABAP List Viewer- ALV) 5655

6.5 Reporting Standards 5756

6.5.1 Web Reporting 5756
6.5.2 ABAP Reporting 5958
6.5.3 Data Definition 6160
6.5.4 Online Standard 6261
6.5.5 Batch Program / Interface Standards 6362
6.5.6 Message 6463
6.5.7 Program Logic 6463
6.5.8 Database Access 6664
SAP ABAP Developer Handbook Page 4 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
6.5.9 Internal Table 7269
6.5.10 String Operation 7977

6.6 Interface Standards 8179

6.6.1 Web Services 8179
6.6.2 BAPI’s 8280
6.6.3 IDOC’s 8381

6.7 Enhancement Standards 8583

6.7.1 Enhancement Spots 8784
6.7.2 Enhancements to Tables 8785
6.7.3 Modifying SAP database Tables: 8985

7 QUALITY ASSURANCE 8985

7.1 Unit Test 8985

7.2 Code Review 8986

8 SAP NOTES 9087

9 APPENDIX 9087
9.1 New Standards 9087
9.1.1 Shared Objects 9087
9.1.2 Exception Handling 9187
9.1.3 Switch Framework 9187
9.1.4 New BADI’s 9188
9.1.5 Developing Persistence 9188

9.2 Tips and Tricks 9288

9.3 Useful transactions 9288

9.4 Useful Links 9389

SAP ABAP Developer Handbook Page 5 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
1 INTRODUCTION

1.1 Purpose
The purpose of this handbook is to set-outdefine the standards and guidelines for custom ABAP
development common that is that is to be adoptedvalid in both operational (Application Management)
and project related environments. The use of Aa single universal set of standard and guidelines
supports a standardised consistent approach to software development. The benefits of such an approach
are:the build phase (development & unit test) of the delivery model.

 Faciliate Increased ease-of-maintenance for support operations

 Reduce Reduction of development efforts.
 Promote Promotion of synergies in the development process between project initiatives.
 Avoidance of unnecessary rework.

Whilst this handbook is being issued to the Projects, it may not cover all types of development as the
document is currently being created.

1.2 Scope
Standards and guidelines address the quality aspect of custom code created during the build phase
(development & unit test) of the development lifecycle. The definition of custom code in the ABAP
environment covers Enhancements, Modifications, and standalone custom applications.
The creation of new functionality and adaptations to existing functionality are subject to these standards
and guidelines albeit existing functionality is not expected to be adjusted in retrospect to conform.

The following subjects are within scope:

 General Programming Rules.
 Naming conventions for data dictionary (DDIC) objects and programs.
 Coding style and other development standards.
 Code template for various type of programs
 Unit Test and Code Review Guide lines.

The following subjects are excluded from scope:

 JAVA-related development
 BW extractors?
 Transport Naming Conventions?
 Customization undertaken in the IMG.

To develop SAP solutions different techniques and programming languages are at a developer’s
disposal. Architectural standards set-out which techniques and programming languages are permissible
in the SAP development environment. The setting of architectural standards is not the focus of this
document. However, a section on this subject has been included to provide a context.

This document has been written for a SAP NetWeaver 7.0 system release.

1.3 Intended Audience

This document is intended for use by the following groups:
 Corporate SAP support team members
 Project team members

SAP ABAP Developer Handbook Page 6 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
1.4 Application Architectural Standards
 The use of procedural ABAP and ABAP OO programming models are the EDF standard.
 For new development requirements, where a programming language choice exists then the
ABAP option is to be elected. (For example, the selection of ABAP Webdynpro takes
precedence over Java Webdynpro.)
 Java-based solutions are currently deployed in EDF’s Production environment (such as certain
self-service applications). The use of the Java will be limited insofar to maintain their current
state of operations.

1.5 Good Development Practices

1.5.1 Do’s
 Understand the functionality behind the code being developed.
 Make sure the code being developed matches the requirements and stick to the specification /
design, deviations must be confirmed again.
 Endeavour to keep the code as simple as possible.
 Document code
 Ensure that any code written is Unicode Compliant.
 Remove the cause of a problem and not the symptom.
 Think the criticality of the development and pay attention (eg: Number of users involved, data
volume, complexity).
 The ABAP workbench Enhancement Framework makes it possible to enhance SAP standard
program types. When an Enhancement option is not feasible then the repository object(s) in
question should not be modified but copied into a customer name space and the new version
modified to satisfy the business requirement.

1.5.2 Don’ts
 When developing new Webdynpro’s, ABAP should be utilised and not Java
 Start Realization without sign-off of the Functional Specification
 Write complex code unless it is really required.
 Release the development request without proper testing.
 Update the backend database directly.
 Forget to capture the exceptions of all function and method calls.
 Use own naming convention and patterns.

2 GENERAL PROGRAMMING RULES

Key to the “Rule” column:
 X (mandatory rule)
 “ ” (rule is optional - recommendation as a way of improving quality)

General Rules Rule

All names (variables, programs, function modules, classes, and so on) specified in English X
Store all global data Declarations declarations etc in an include for executable programs X
Use meaningful names (for example, use “l_material” not “l_m”) wherever possible,. uUse X
glossary terms (for example, “l_company_code” not “l_bukrs”)
Use underscores (“_”) to separate the different words in compound names X

Write inline comments and documentation in the coding in English X

Write inline comments in the coding “as though you were explaining the program to a X
colleague”
SAP ABAP Developer Handbook Page 7 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
Use a maximum of one statement per program line X
Use the pPretty pPrinter command to format code (if the pretty printer is not available, structure X
manually)
Go to Utilities->Settings->Pretty Printer and set to ‘Keyword Uppercase’

Run enhanced syntax checks (SLIN) X

Run Code Inspector (SCI) X

Program Build with reusability in mind. - ModularisedEncapsulate reusable functionality

module in OO classes and function modules.
Use a maximum of one statement per program line X
Divide largeer function modulesunit of code into Fform routines X
Do not overload coding with technical refinements
 Do not encapsulate if-statements too much
 Keep select statements as simple as possible (for example, do not use overly complex
joins)
Optimize only where it is useful or meaningful to do so
Create types and data definitions only with a DDIC reference  Central changes are possible
(for example, field lengths) and it is better to use TYPE instead of LIKE (constant typing Basis
recommendation)

Use constants instead of hardcoded ‘magic numbers’ (literals) X

Define constants globally (multiple use, simple central modifications!) X

Use TABLES statements only when absolutely necessary X

If you have to use TABLES statements, always use them globally
Allowed, for example, in function groups with database access
Not necessary for select statements of the “SELECT INTO wa ENDSELECT” type
Do not use data structures from TABLES statements directly
Use internal tables without headers X
This also applies, for example, to the transfer of internal tables to function modules
Headers (internal tables as parameters of a function module are always created with headers
within the function module) are also not allowed within the function module
Note: Tables with headers are no longer supported in an ABAP-OO context
If sorted data is required, the tables in which the data is managed must always be stored in
“SORTED TABLES”
Reason: Considerable improvement in performance when accessing data, because binary
searches are possible There is also no need to sort using “SORTED BY” statements
Keep the number of global variables to a minimum. Use local variables wherever possible X
In this context, the following applies for function modules:
 Define variables and structures globally only if several function modules need them to
transfer data or if they function as a memory aid!
 Define locally in the individual function modules any variables that are used by several
function modules independently, but individually are of local importance only
Modules should consist of subprogram calls (PERFORM statements) only, meaning that the
coding should run only in the subprogram
Reason: Variables in modules are always global
Use any modules that are no longer required only in the short term and delete them after an
appropriate amount of time has elapsed
Never make changes to the database directly. Always use update modules that call the update
task.
Function modules must always be used in read accesses (SELECT) to databases
Benefits:
 Enables maintenance to be carried out centrally
 Buffering
SAP ABAP Developer Handbook Page 8 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
Never read function codes, screen numbers, or transaction codes
Reason: Leads to problems with generic functions and makes maintenance difficult
If system variables (sy-repid, for example) are used as parameters, they should always be stored
in local variables
Reason: System variables are reset when other programs or function modules are called, and
could therefore be “incorrect“ in the program that is called
Do not work with the memory (import/export, set/get) X
 Use your own function modules as a memory instead or use ABAP Shared Objects concept
Avoid CALL DIALOG calls X
Reason: A separate roll area is opened, and there is a danger that different roll areas could be
using a different DB status
Do not use macros! They are difficult to maintain and cannot be debugged X
Use the application log to manage messages (warnings, errors, and so on) – see the reuse library
Initialize new DDIC table fields only in exceptional cases, meaning when it is absolutely
necessary Leads to unnecessary type conversions
 Leave new fields with a ZERO value in case an initialization in accordance with the data
type is not explicitly necessary (time during upgrade, memory usage)
Number fixed values consecutively or start with the letter “A” and work through the alphabet
Reference data types not table fields (for example, TYPE MATNR not LIKE MARA-MATNR)
Screens:
Always define screen fields with a DDIC reference
Never use global variables as screen fields
Always define screen texts with a DDIC reference
 Do not modify text in the coding or use screen attributes to modify text
 Text is written and translated in on place
 Use complete text (in field labels and headings)
Store automatically generated maintenance views (maintenance clusters) in separate function
groups unless they are closely related
Modifications to the flow logic of generated maintenance screens should take place only using
the events designed for this purpose in the maintenance views
Separate function groups for read access to customizing objects
Reason: Performance – the maintenance function modules should not be loaded in a read access
(the complete function group is always loaded when a function module is accessed)
Always deal with exceptions! X
If an exception has not been dealt with, the situation must be documented clearly!

Rules for Form Routines and Function Modules Rule

Use a generated header (document header) for a new form X
This header must always be filled out fully (see documentation guidelines),
the parameters must be described (see below), and all accesses to tables and data structures
must be documented
Parameter Transfer X
 Transfer parameters must always be typed (improved syntax check, better readability,
better performance – see Tips&Tricks in transaction SE30)
 Transfer parameters that are not changed must
o always declare with “USING“ and “BY VALUE“ in subprograms (FORMS)
o always declare as “IMPORTING” parameters in function modules
 All transfer parameters must be documented in the header and be classified as import /
export parameters
 Whenever possible, avoid using global variables for hidden parameter transfers! If global
variables are used, they must be documented in the header and classified (READ / WRITE)
 Export parameters must be initialized at the start of the subprogram
The size of form routines and function modules may be restricted to a maximum of 100 lines
for readability purpose.
Store part-functions in their own form routines
Omit form routines to optimize performance only in cases where mass processing is the main
SAP ABAP Developer Handbook Page 9 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
consideration, otherwise the rule is - “maintainability before runtime optimization”
Avoid calling external form routines - call function modules instead whenever possible

Rules for ABAP / Objects Mandatory

Do not declare class static variables as public, because write access is possible
from outside then.
Better: Declare as “private” and provide (public) get-method for reading access.
Then only reading access is possible from outside the class.

SAP ABAP Developer Handbook Page 10 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
3 SAP DEVELOPMENT NAMING CONVENTIONS

3.1 Overview

A naming convention specifies the set of rules used to identify development objects. SAP plays a role
in the setting of the rules insofar it enforces its own recommendations. (See the following the section
called Customer Name Space ID). In the ABAP environment the non-reserved aspect of a custom
repository object name (and the names of any custom internal components) are arbitrary. The overall
responsibility for the enforcement of the naming conventions lies with the individual developers.

What is prescribed in the following sections ensures: (1) a distinction between SAP standard code,
partner code, and customer code and (2) meaningful names for custom developed objects that promote
ease-of-identification.

As part of the delivery process Code Inspector (Transaction code “SCI”) will be used to check whether
programs adhere to naming conventions or not.

3.1.1 Customer Name Space ID

Name space identification is the means SAP uses to segment development objects in the repository.
SAP has reserved name ranges for customer objects and SAP objects. SAP reserves the “Z” and “Y”
repository name spaces for its customers that ensure that objects created in this space are preserved
from patching and upgrades. Other name spaces are reserved for SAP’s own developments and that of
it partners. EFDE Corporate SAP adopts the policy of naming test-related objects in the “Y” name
space and Production-related objects in the “Z” namespace. The customer name space identifier always
occupies the first character in the name of a custom development.

Beware that SAP does deliver a few system objects with names that fall within the customer name
space. These objects are listed in table TDKZ.

3.1.2 Process Area/Application ID

The process area/application ID identifies the relevant business domain for custom development. It is
represented by a two character code which logically groups related development objects together.

Process Area / Application ID Description

FI Financial Accounting
CO Controlling
PP Production Planning
QM Quality Management
MM Materials Management
SD Sales Distribution
TR Treasury
IM Investment Management
PS Project Systems
BA Basis
SEC Security
HR Human Resources
CA Cross Application
TE Test programs
SAP ABAP Developer Handbook Page 11 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
SAP ABAP Developer Handbook Page 12 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
3.2 ABAP Dictionary

Creation of custom data dictionary objects (DDIC) should be kept to minimum to maintain a low cost
of ownership. New DDIC objects should be created when a requirement exists that cannot be met by a
standard DDIC object.

The following general points are to be kept in mind during definition of new data dictionary (DDIC)
object:
 Check whether a suitable DDIC object exists before creating a new one.
 Ensure that Client (MANDT) is utilised when creating a new table
 Foreign keys referencing SAP table primary keys are highly recommended.
 Table maintenance facility (ZSM31) should be implemented by exception for custom tables
that require restricted manual access.
 Documentation at the data element level should make use of the long text facility to make on-
line help effective.
 If appropriate, for master data or transactional tables, the user names of the persons who
created and/or changed data, the date of creation/change should also be stored along with the
reason for change.
 Technical settings should be maintained on all custom tables created (Consult the BASIS team
for assistance with the technical settings).

3.2.1 Transparent Tables

A Transparent table has a 1:1 relationship (field for field) with a corresponding physical table on the
underlying database. Transparent tables are typically used to store master and transaction data.

A DDIC table name may be specified up to 16 characters. The first character should be the standard ‘Z’
for custom objects. The 2ndand 3rd characters should contain the Process Area. The remaining
characters are open.

Format: A BB C DDDDDDDDDDDD
Open (description)
Separator “_”

Process
Area
Customer
space
identifier -
‘Z’

Example: ZHR_REGION

3.2.2 Structures
A structure is defined like a table, but it does not store records in the database – it is typically used as a
reference data definition to ensure consistency between programmes. Structures can be shared by
multiple ABAP programs.

SAP ABAP Developer Handbook Page 13 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
A DDIC structure may be specified up to 30 characters. The first two characters must be specified as
‘ZS’ for custom structure. The 3 rd and 4th characters specify the Process Area. The remaining characters
are open.

Format: AA BB C DDDDDDDDDDDDDDDDDDDDDD
DDD
Open (Description)
Separator “_”

Process
Area

Customer
space
identifier -
‘ZS’

Example: ZSHR_ COUNTRY

3.2.3 Table Fields

Where possible, use the same name as the data element associated with the field. If multiple fields in
the table use the same data element, name these fields in a meaningful manner (e.g. creation date
(CREDAT) and posting date (POSDAT) fields both use DATUM data element). Use only Alpha-
numeric values in table field names.

SAP ABAP Developer Handbook Page 14 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
3.2.4 Views
A view can be used to create virtual tables that do not contain any data, but presents selected columns
of data from one or more database tables. A view is typically used to link database tables using
common fields to provide a combined report output.

A DDIC table name may be specified up to 16 characters. The first two characters of the view must be
specified as ‘ZV’. The 3rd and 4th characters specify the Process Area. The other characters can be
arbitrarily assigned. For clarity purposes, the main table name can be used.

Format: AA BB C DDDDDDDDDDD
Open. Should incorporate the
main table name and be unique

Separator “_”

Process Area

Customer
space
identifier -
‘ZV’

Example: ZVHR_REGION

3.2.5 Domains
A domain is a central object for describing the attributes of a business object. A domain describes the
value set for a field. This set of values is defined by specifying the format attributes, such as external
format, length and type.

A DDIC data domain may be specified up to 30 characters. SAP does create domains that begin with a
‘Z’, so custom domains should begin with the first two characters ‘ZZ’. The remaining characters can
be arbitrarily assigned but should be a meaningful name.

Format: AA BBBBBBBBBBBBBBBBBBBBBBBBBBBB

Open (Description)

Customer space
identifier -
‘ZZ’

Example: ZZREGION, ZZCOUNTRY

SAP ABAP Developer Handbook Page 15 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
3.2.6 Data Elements
A data element is a semantic domain. It provides a precise description of the function of a domain in a
specific business context for the fields that depend on it. Each new data element defined by the
developer must be linked to a new domain. Existing SAP domains should not be used to define new
data elements.

A DDIC data element may be specified up to 30 characters. The first two characters must be ‘ZZ’ and
the remaining characters can be arbitrarily assigned.

Format: AA BBBBBBBBBBBBBBBBBBBBBBBBBB
BB

Open
Customer space
identifier -
‘ZZ’

Example: ZZREGION, ZZCOUNTRY

3.2.7 Lock Objects

Lock objects control simultaneous access to a particular table/entry by two update users – i.e. ensure
two users are prevented from updating the same data object simultaneously. Locks are set and released
by calling a function module. When a lock object is activated, the system automatically generates the
function modules to be included in an ABAP program.

A DDIC lock object may be specified up to 16 characters. Lock object names should start with the
prefix ‘EZ’ followed by the process area. The remaining characters are open to the developer.
However, the table name should be used if it is less than seven characters.

Format: AA BB C DDDDDDDDDDD

Open (use table name if < 7 characters)

Separator “_”
Process
Area

Customer
space
identifier -
‘EZ’

Example: EZHR_REGION

SAP ABAP Developer Handbook Page 16 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
3.2.8 Search Help
Search help is an object of the ABAP Dictionary with which input helps (F4 helps) can be defined.
Elementary search helps and collective search helps are distinguished. Elementary search helps
implement a search path for determining the possible entries. Collective search helps consist of several
elementary search helps and therefore provide several alternative search paths.

A DDIC Search Help may be specified up to 30 characters. The first two characters must be ‘ZH’
followed by the process area. For clarity purposes, the main table/ view name should be used if
possible.

Format: AA BB C DDDDDDDDDDDDDDDDDDDDDDDDD

Open
Separator
“_”
Process
Area

Customer
space
identifier -
‘ZH’

Example: ZHFI_T001

3.2.9 Matchcode Objects

Matchcode objects are obsolete and have been replaced first by the technology of the help views and
later by search help.

3.2.10 Table Types

A DDIC Table Type may be specified up to 30 characters.

Format: AAA BB C DDDDDDDDDDDDDDDDDDDDDDDD

Open
Separator
“_”
Process
Area

Customer
space
identifier
-
‘ZTT’

Example: ZTTFI_REGUH

SAP ABAP Developer Handbook Page 17 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
3.2.11 Type Group

A DDIC Table Type may be specified up to 5 characters.

Format: A BB CC
Freely assignable characters – Use number
assignment
Process
Area

Customer
space
identifier
-
‘Z’

Example:ZQM01

SAP ABAP Developer Handbook Page 18 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
3.3 ABAP Program
3.3.1 Program Naming
3.3.1.1 Program Names
SAP’s own naming conventions should be followed when creating bespoke objects. Refer to the on-line
help for further details.

The following program IDs are used to describe the type of program:

Program Type ID Description

C Conversion
D Data Dictionary Maintenance
E Enhancement
I Inbound Interfaces
O Outbound Interfaces
R Report
F SAP script/SMARTFORMS
U User Exit/Validation Subroutine Pool
B Business Warehouse
W ABAP WebDynpro
N Workflow

SAP ABAP Developer Handbook Page 19 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
The following approach is to be used:
 Programs should be named using a reference to the functional specification for the descriptive part
which provides traceability of the requirement. Examples:
o Project RICEF ID - EHL0001
 'ZHRI_EHL0001_EMPLOYEE_UPLOAD'
 BAU CR ID - CR147
 'ZSDO_CR147_CS_REPORTING'

Format: A BB C D E F G
Description
from
Functional
Specification
Separator
“_”
WRICEF
Ref #/
CR Ref #/
IR Ref # -
Length of
this sub-
segment
will vary
Separator
“_”
Program
Type
Identifier

App./
Process
Area

‘Z’

 ABAP WebDynpro’s should be named using the standard convention, plus a reference to the
functional specification/task number and then a descriptive part. For Example
‘ZFIW_CNN0127_CFP_Report’
 Module pools should be named using the standard convention, plus a reference to the
functional specification/task number and then a descriptive part. For example
'SAPMZHR1_EHL00001_EXT.
 Transactions should be named in line with the report/program. For example a transaction for
the module pool above would be 'ZHRP01'.

SAP ABAP Developer Handbook Page 20 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
  Enhanced IDocs should be named using the standard name as the basis, where applicable, by
replacing the first letter with 'Z'. Entirely bespoke IDocs should be created using a reference
to the process area. For example 'ZSDI_CR147_DESC'.
 Function groups should be named using the process area. For example 'ZHR01' or
'ZFI_GENERAL'. Function modules may follow any suitable naming convention.
 Enhancements should be named using the standard convention, plus a reference to the
functional specification/task number and then a descriptive part. For Example
‘ZSEE_CNN0127_Security’.

SAP ABAP Developer Handbook Page 21 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
3.3.1.2 Program data definitions and declarations (fields)

Use descriptive names and hyphenate it with “_” underscore. Use the following prefixes:
 New Type definitions should be named starting with ‘T_’.
 Global variables should be named starting with ‘G_’.
 Global constants should be named starting with ‘GC_’.
 Global internal tables should be named starting with ‘GT_’.
 Global structures should be named starting with ‘GS_’.
 Global range tables should be named starting with ‘GR_’.
 Local variables should be named starting with ‘L_’.
 Local constants should be named starting with ‘LC_’.
 Local internal tables should be named starting with ‘LT_’.
 Local structures should be named starting with ‘LS_’.
 Local range tables should be named starting with ‘LR_’.
 Subroutine parameters should be prefixed with a ‘P’
 Field Symbols should be named starting with ‘<FS>.
 Selection-screen Parameters should be named starting with ‘P_’.
 Select-Options should be named starting with ‘S_’.

A type and length should always be specified for a data object.

An explicit type should always be assigned to the formal parameters of a subroutine to improve
performance.

Where possible, use the Parameter ID associated with a data object to enable automatic population.
This will also aid with the passing of data between programs and transactions.

The use of the MOVE-CORRESPONDING statement, though convenient, should be used with care. In
some cases the use of explicit MOVE statements can aid clarity.

SAP ABAP Developer Handbook Page 22 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
3.3.2 Report Variant
When an ABAP report is created, ABAP may generate some database-specific selection parameters on
the selection screen. Additional selection-screen criteria can also be programmed into the report. In
order to execute a report for a specific range of data or selection set, the selection ranges must be
entered on the screen. However, if there is a requirement to run the same report with the same selection
set, especially in batch, a variant can be used to save that selection set. If a variant is used, there is no
need to enter the same selection set again each time the report is executed.

3.3.3 Module Pool Names

3.3.3.1 ABAP module Pools
An ABAP module pool is an ABAP program that checks and processes what a user enters during a
transaction. It is thus part of on-line programming. An ABAP module pool groups together the
modules that process common data. Module pool names must begin with ‘SAPxZ’ (where x can be ‘U’
for update modules, ‘M’ for screen modules, ‘D’ for dialog modules, and ‘F’ for subroutine modules).
The next three characters represent the Process Area and the final two positions contain a numeric
value. For ‘M’ type module pools, the last four characters of the program name should be identical to
the primary transaction code created for that module pool.

Format: AAAAA BB NN + “_” + Description

Numeric Value
Process
Area
Constant
‘SAPxZ’

Example: SAPMZPS01_PROC_CHQ

3.3.3.2 Module Pool Components

Naming conventions for Module Pool components must also adhere to SAP standards. See table below
for detailed conventions using the above example. (Note: xZann in conventions below should match
xZann in main Module Pool name).
x - Module Pool Type
‘U’ for update modules
‘M’ for screen modules
‘D’ for dialog modules
‘F’ for subroutine modules
aa - Process Group
HR – Human Resources
SD – Sales & Distribution
MM – Material Management
nn - Numeric between 00 and 99

Module Pool Component Type Naming convention

Data Definition (Global Data xZaannTOP
Include) Module
Process Before Output (PBO) xZaannOyy
Module
Process After Input (PAI) xZaannIyy
Module
Performs (subroutines) xZaannFyy
Process On Help-Request (POH) xZaannHyy
Module
SAP ABAP Developer Handbook Page 23 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 Process On Value-Request xZaannVyy
(POV) Module
Okcode OKcode<screen number>
Menu painter M<screen no>_<XXXX>
Forms for OKcode functions Form_<Okcode>
Authorisation Objects Consult Basis group

Module pools should be named using the standard convention detailed above, plus a descriptive part.
Example: ‘SAPMZPS01_Project_Systems’.

Remarks: It is mandatory to use the ‘ABAP Workbench’ to construct module pools. The SAP
Workbench is designed to enforce standard naming conventions.

3.3.4 Dynpros (Screen)

SAP screens are referred to as dynpros. Standard SAP components, such as transactions, menus and
tables, contain dynpros and the associated processing logic. A developer may also create customised
dynpros.

The identification of a screen painter dynpro consists of an ABAP program name and a four digit
dynpro number. The number range reserved for customised dynpros should be between 9000 - 9999.
The initial screen number for a given transaction should be 9000 and additional screens numbers
increment by 10.

Format: AAAAAAAA BBBB

Dynpro number from

9000 – 9999

ABAP Module
Pool

SAP ABAP Developer Handbook Page 24 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
Example
Module Pool: SAPMZHR01
Screen #: 9000

3.3.5 GUI Status & GUI Title

3.3.5.1 GUI Status
A GUI status is the main element of the Graphical User Interface. A GUI status can consist of the
following: menu bar, standard toolbar, application toolbar and functions. A GUI status is related to an
ABAP program.

Format: AAAAAAAA

Open

Example
STANDARD

3.3.5.2 Function Key

Function keys are part of the GUI status and are defined in the menu painter along with pushbuttons
and menu items. SAP has certain standard settings for some function keys, listed below:
F1 Help
F2 Choose
F3 Back (one step)
F4 Possible entries
F9 Select
F10 Jump to menu bar
F11 Save/Generate
F12 Cancel
Shift-F1 Print
Shift-F2 Delete
Shift-F5 Open

SAP also uses the following function keys for scrolling:

Shift-F9 First Page
Shift-F10 Previous Page
Shift-F11 Next Page
Shift-F12 Last Page

SAP ABAP Developer Handbook Page 25 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
3.3.5.3 GUI Title

The title bar can be up to 20 characters.

Format: AAAAAAAAAAAAAAAAAAAA

Open

Example
INITIAL

3.3.6 Transaction Codes

Transaction Codes are created either through ABAP Development Workbench. Every transaction in
SAP contains a unique transaction code. Information about all transactions are stored in two standard
SAP tables. Table TSTC contains the attributes of the transaction and table TSTCT contains the short
text associated with the transaction. The entries in tables TSTC and TSTCT are created by SAP when a
transaction code is successfully saved.

A transaction code can not be more than 20 characters. The naming convention for transactions created
by Remote Development developers requires the first character be a ‘Z’. The Process Area is placed in
the next three characters. The remaining two characters are open to the developer.

Format: A BB CCCCCCCCCCCCCCCCCCC

Open (any alphanumeric identifier)

Process Area
Constant ‘Z’

Example
ZHR01

SAP ABAP Developer Handbook Page 26 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
3.4 Other Object TypesForms
3.4.1 SAPscript
The SAPscript form name can be up to 16 characters long and must begin with ‘Z_’. This will
differentiate custom forms from standard SAP forms. The next two characters of the name will contain
the application/process area (i.e. FI or HR). The remaining characters should contain a meaningful
description and incorporate that SAP standard form name where it makes sense.

Format: AA BB C DDDDDDDDDDD

Open (Description) – incorporate original form

name if copied from SAP
Separator
“_”
Applicati
on /
Process
Area
Constant
‘Z_’

Example: Z_FI_CREDITNOTE

3.4.2 Smart Forms

The SAP Form name can be up to 30 characters long and must begin with ‘Z_’. This will differentiate
custom forms from standard SAP forms. The next two characters of the name will contain the
application/process area (i.e. FI or HR). The remaining characters should contain a meaningful
description and incorporate that SAP standard form name where it makes sense.

Format: AA BB C DDDDDDDDDDDDDDDDDDDDDDDD
D
Open (Description) – incorporate original
form name if copied from SAP
Separator
“_”
Applicat
ion/
Process
Area
Consta
nt ‘Z_’

Example: Z_FI_CREDITNOTE

SAP ABAP Developer Handbook Page 27 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
3.4.3 ALE/ & IDOC’s
3.4.3.1 Message Type

The IDOC Message Type can be up to 30 characters long (although compatibility with SAP systems
prior to Release 4.0 requires a name of 6 characters or less). The name must begin with ‘Z’ to
differentiate custom Idocs from standard Idocs. The next two characters of the name will contain the
application/process area. The outstanding characters should contain a meaningful description.

Format A BB C DDDDDDDDDDDDDDDDDDDDDDDDD
: D
Open (Description) – Message type name
Separator
“_”
Application/
Process Area
‘Z
’

Example: ZMM_METREAD

3.4.3.2 Basic Type

The IDOC basic type can be up to 30 characters long (although compatibility with SAP systems prior to
Release 4.0 requires a name of 8 characters or less). The name must begin with ‘Z’ to differentiate
custom Idocs from standard Idocs. The next two characters of the name will contain the
application/process area. The remaining characters should contain a meaningful description that
includes version release number. E.G. ‘01’.

Format: A BB C DDDDDDDDDDDDDDDDDDDDDDD
DDD
Open (Description) – Idoc name
Separator “_”

Application /
Process Area
‘Z’

Example: ZMM_METREAD01

3.4.3.3 Segment Type

The name of the IDOC Segment type can be up to 27 characters long (although compatibility with SAP
systems prior to Release 4.0 requires a name of 7 characters or less). The name must begin with ‘Z’ to
differentiate custom Idoc segments from standard Idoc segments. The next six characters (or more) of
the name will contain a meaningful description.

Format: A BB C DDDDDDDDDDDDDDDDDDDDD
SAP ABAP Developer Handbook Page 28 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 DD
Open (Description) – Idoc segment
name
Separator “_”

Application /
Process Area
‘Z’

Example: ZMM_METREAD

3.4.3.4 Posting Program

The function module used to process incoming IDocs with message type
"ZMM_METREAD" could be "Z_IDOC_INPUT_ ZMMI_METREAD".

3.4.3.5 Logical System

The logical system name will contain 10 characters. The first three characters specify the system id and
the next four will contain the constant ‘CLNT’ to represent the client number. The last three will
contain the client number.

The logical systems should be created as below:

Format: AAA BBBB CCC

Client Number E.G
‘100’ or ‘300’
Constant – ‘CLNT’
System ID
i.e ‘XE1’ or
‘RE1’

3.4.3.6 Distribution Model

The model view technical name will contain 10 characters. The first character specifies a customer
object. The next two characters specify the process area followed by a free text description.

Format: A BB CCCCCCC
Open (Description) – Model view
name
Application/
Process Area
Constant ‘Z’

SAP ABAP Developer Handbook Page 29 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
3.4.4 Workflow
All custom workflow and workflow task will be given an internal number, this is set via configuration
under SAP Menu: Business Workflow -> Development -> Utilities -> Automatic Workflow
Customising –> Maintain prefix Number and Check Number Ranges.

A prefix number needs to be assigned per client / SAP System to allow the differentiation and
verification. This is set automatically but needs to be checked when the system is delivered.

Workflow and Tasks Number Range:

The Number Ranges for workflow and tasks is maintained (Personnel Management –> Organisational
Management –> Basic Settings –> Maintain Number Ranges) which determines the automatic number
assignment for workflow objects and tasks. The objects are WF and TS respectively, which needs to be
set up prior to creation of tasks and workflow.

BOR objects:
BOR object can contain 8 characters long which start with the constant ‘Z’. If a subtype is created, it
should be prefixed by Z to allow easy identification to super type (i.e. EMMACASE – ZEMMACASE)
all subsequent method and events created should be prefixed by z.

3.4.5 Packages/Development Classes

Packages/Development classes group together development objects (e.g. programs, tables, function
modules) which can be corrected and migrated together along a transport path. A
Package/Development class can, for example, consist of a transaction or a group of related transactions
along with programs, DDIC objects, menu painters, screen painters, lock objects, message classes,
match codes, etc.

If a developer believes that a unit of work is significant and deserves its own Package/Development
class, then an additional Package/Development class may be required. The developer should request an
additional Package/Development class from the SAP Custom Development Team Lead.
No objects should be defined under the $TMP development class – prototyping should
only occur in the Sandbox environment.

Packages/Development Classes should adhere to the following naming convention: Where a

development is not part of a Project, the Package/Development class is selected corresponding to the
business process team requesting the development -
 ZHR – Human Resource
 ZFI – Finance
For projects the Package/Development class should incorporate an abridge Project name
 ZFUSION – Fusion Project
 ZCCGT – CCGT Project

3.4.6 Area Menus

An area menu is the first menu that appears when entering an ‘application area’. For example, selecting
Tools  ABAP Workbench will take you to the ABAP Workbench area menu and the ABAP
Workbench application area.

The area menu follows the same naming conventions as transaction codes.
SAP ABAP Developer Handbook Page 30 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 Format: A BB CCC
Open (any
alphanumeric
identifier)
Process
Area
Constant ‘Z’

Example
ZHR001

3.4.7 Messages
Messages are used in ABAP programs to send information to the user. There are six different types of
messages: information, warning, error, abend, exit and success.

A message consists of a 4 character message class and a 3 digit number. The first character of the
message class should be a constant ‘Z’ and the next three characters will contain the Process Area. The
message number is open to any number between 000 and 999.

According to the naming conventions, only one message class can exist for each Process Area. When a
developer needs to create new message numbers, they need to request a number range within a specific
class from the development team lead.

Format: A BB CCC
Message Number between 000 - 999
Process Area
Constant ‘Z’

Example
Message Id ‘ZCO’ Type ‘E’ Number ‘001’.

3.4.8 Logical Databases

A logical database creates a hierarchical view of physical relational tables. Specifically, the developer
has the ability to link database tables which simplifies report programming through standardised read
accesses, authorisation checks and selections.

Due to the strategic importance of logical databases and the potential impact on system performance,
careful consideration should be made before creating any new logical databases. Consequently, only
the DBA will be able to create logical databases.

Logical database names consist of six characters. The first character must begin with a constant ‘Z’.
The next three characters will contain the process area. The last two characters will represent the series
of logical database created in that process area eg 01, 02.

Format: A BB CC
Numbers
(00 - 99)

Process
Area
SAP ABAP Developer Handbook Page 31 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 Constant
‘Z’

Example: ZPS01

SAP ABAP Developer Handbook Page 32 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
3.5 Background Jobs
All background jobs, ABAP programs set-up to run in the background, are client-dependent objects.
They are submitted when the system is active. Background jobs have an assigned starting point and
various selection parameters.
The maximum length of a background job name is 32 characters. The first nine characters will contain
the program name followed by an underscore. The tenth position displays a ‘P’ for Production (Live
run with data saved to SAP database) or a ‘T’ (data presented to screen or spool, but not saved to SAP
database) for Test Job. The eleventh position will show the frequency (see key below). The next
position will show if this background job is ‘Critical’ or ‘Non-Critical’. The following eight positions
hold the requester’s SAP logon. This is followed by an underscore. The last three positions are for a
sequentially assigned number. Developers will only use 25 out of 32 available positions.

Frequency: D - Daily
W - Weekly
M - Monthly
Q - Quarterly
R - On Request

Format: AAAAAA B C DD EEEEEEEE FFF

AAA E

Sequenti
ally
assigned
number
Requester’s
SAP Logon
& ‘_’

Critical/
Non-
Critical &
‘_’
Frequency
Flag

Live/Test
Run Flag

Program
Name &
‘_‘

Example ZMOPARI001_PMC_DS_001

3.6 Batch Input Sessions

Batch input sessions are a collection of batch input data used as input to one or more update
transactions. External data can be transferred into the SAP system through a batch input session. They
are stored on the batch input queue until submission to the transaction processing. In order to guarantee
data consistency, all data is subject to the same validations performed in the on-line transaction.
SAP ABAP Developer Handbook Page 33 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
Batch input session names can be up to 13 characters long. The first 9 characters will be the name of
the primary program that created the session. The remaining 4 characters should match the last four
digits of the dataset.

Format: AAAAAAAAA B CC
Sequential number
matching last 2
digits of dataset
serial number (for
interfaces).
<or> Open (for
non-interfaces
Underscore “_”
<or> Open (for
non-interfaces)
Name of main
program that
created the session

Example: ZPRPI001_01

Datasets

It is important that SAP-specific dataset naming conventions be adhered since external systems will be
interfacing with SAP. Please note that the following naming convention will be confirmed and
amended accordingly after the details of interface control mechanism have been confirmed.
The file structure for all sap related datasets will be:

/INTERFACES

/<Process Area>

/IN /OUT

SAP ABAP Developer Handbook Page 34 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
3.6.1 File Naming
For Inbound/Outbound Interfaces unless the file name is determined by the system producing the file
then the following should be utilised.
If a date and time stamp is required then this should be in the following format.

XXXXXXXX_ YYYYMMDDHHMMSS where XXXX is the base name of the file.

3.7 Layout Sets

A layout set in SAPscript is used for page layout. The layout set contains various elements used for
layout control. A layout set definition contains the following elements: Header Data, Paragraphs,
Character Strings, Windows, Pages and Page Windows.
The layout set name can be a maximum of sixteen characters. It should start with the prefix ‘ZZ_’.
This is followed by the process area and ‘_’. The remaining nine characters are open to any
alphanumeric combination.

Format: AAA BBB C DDDDDDDDD

Open

Underscore (_)

Process
Area
Constant
‘ZZ_’

Example: ZZ_PRP_LAYOUTSET

3.8 Legacy System Migration Workbench (LSMW)

The LSMW is an ERP-based tool that supports user to transfer data from legacy systems to the SAP
ERP system. The following sections describe the structure and naming convention to be used within
LSMW to classify all the conversion objects in this project.

3.8.1 Project
Project ID is the highest level of the conversion object repository however individual objects needs to
be transported independently. Hence a new project will be created for each object.
i.e FUSION – FOR Fusion Project
SAPSUPPORT – For SAP Support Team

3.8.2 Subproject
This should equate to the Process Area as defined in Section 3.1

3.8.3 Object
Object ID is used to identify the conversion objects created under each Subproject, Ensure that it is
named in such a way that a user can easily understand what the LSMW has been created for.
Example:
SAP ABAP Developer Handbook Page 35 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
  IT0001 – Organisation Assignment
 FBD2 – Change re-occurring Payments

3.9 Naming Conventions for ABAP Objects

The following additional conventions apply to the use of ABAP-OO:
Legend: In the following text <Z> is representing the constant, <CU> is representing the process area
like CO, MM, FI etc.

3.9.1 Global Conventions

Classes and interfaces in the class library must start with the constant ‘Z’ followed by process area.

Object Naming Convention + Example

Class in the class library <Z><CU>CL_<<WRICEF Ref>>_<<class name>

The class name must consist of nouns and always be singular.
<Z><CU>CL_CR147_COMPANY_CODE,
<Z><CU>CL_IFI0001_GENERAL_LEDGER_ACCOUNT

Interface in class library <Z><CU>IF_<interface name>

The same naming conventions are used for interfaces as are used for
classes
<Z><CU>IF_STATUS_MANAGEMANT, <Z><CU>IF_CHECKER
Program-local class LCL_<class name>
The class name must consist of nouns and always be singular.
LCL_TREE_MANAGEMENT
Program-local interface LIF_<interface name>
The same naming conventions are used for interfaces as are used for
classes
LIF_PRINTER

3.9.2 Class-local Conventions

Object Naming convention + Example

Method name <method name>

The method name must start with a verb.
GET_STATUS, CREATE_ORDER, DETERMINE_PRICE
Event <event name>
Event names must be assigned as follows: <Noun>_<Verb in past
tense>.
BUTTON_PUSHED, COMPANY_CODE_CHANGED,
BUSINESS_PARTNER_PRINTED
Class-local type definitions ZV/S/T_<type name>
ZV_INTERNAL_TYPE, ZS_STRUCTURE, ZT_TABLE

Data definition (constant) C_<constant name>

C_MAX_LINE
SAP ABAP Developer Handbook Page 36 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
Data definitions (variables)
Visibility of data in classes has 2 dimensions:
 Public / Private / Protected
 Instance / Static
To meet these dimensions the following conventions are recommended:
Instance Static

Public GIV/GIS/GIT_<variable name> GSV/GSS/GST_<variable name>

gis_mara TYPE mara gsv_matnr TYPE matnr

Private LIV/LIS/LIT_<variable name> LSV/LSS/LST_<variable name>

lis_mara TYPE mara lsv_matnr TYPE matnr

Protected SIV/SIS/SIT_<variable name> SSV/SSS/SST_<variable name>

sis_mara TYPE mara ssv_matnr TYPE matnr

Notes:
 Always use the ‘V’ in the prefix for definition of variables to avoid misunderstanding. In
normal ABAP GS_<variable_name> represents a global structure.
 Avoid using verbs at the start of names for variables in a class (CLASS-DATA, DATA),
because they will conflict with method names.
 Protected data definitions start with an ‘S’ in accordance to the ‘super’ statement for the access
from a subclass to these data.

Object Naming convention + Example

Attribute access SET_<attribute name>, GET_<attribute name>

Attribute accesses for every kind of attribute must have the prefix
GET_ or. SET_
GET_STATUS, SET_USE_COUNT

Methods that deal with an event ON_<event name>

Methods that deal with an event must start with ON, and the name
must include the event that they deal with.
ON_BUTTON_PUSHED, ON_BUSINESS_PARTNER_PRINTED

Methods that carry out type AS_<new type>

conversions
AS_STRING, AS_ISOCODE

Methods that deliver a Boolean IS_<adjective>

value
IS_OPEN, IS_EMPTY, IS_ACTIVE
These methods must not return any EXCEPTIONs
Recommendation: The Boolean value should be represented by the
values SPACE/’X’ for false/true

SAP ABAP Developer Handbook Page 37 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
Check methods CHECK_<objective>
CHECK_AUTHORIZATION, CHECK_PROCESS_DATE
These methods are different from the “IS_<adjective>“ – methods in
that they include the option of returning EXCEPTIONS.

The parameters are seen from the point of view of the method that implements them:

Type Value

IMPORTING-Parameter IV/S/T_<parameter name>

EXPORTING-Parameter EV/S/T_<parameter name>
CHANGING-Parameter XV/S/T_<parameter name>
RESULT RV/S/T_<result>

SAP ABAP Developer Handbook Page 38 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
3.9.3 Exceptions
The following table contains meaningful EXCEPTIONS that can also be used generically. (Example:
NOT_FOUND could be changed to DATE_NOT_FOUND).
EXCEPTION Meaning

ACTION_NOT_SUPPORTED The requested action or OK code is not supported.

CANCELLED This EXCEPTION can be used if a dialog in a method has determined

what is to be done (example: selection list) and the user chooses
“Cancel”.

EXISTING An object that you want to create exists on the database already.

FAILED The method was not able to carry out its task, due to the current
environment situation. This exception is intended in particular for
situations where the environment is temporarily in a constellation that
makes it impossible to carry out task of the method.

..._FAILED A sub-function of the method could not be carried out, due to the current
environment situation. (OPEN_FAILED, CLOSE_FAILED,
SELECTION_FAILED, AUTHORIZATION_FAILED)

FOREIGN_LOCK Data is locked by another user.

INCONSISTENT Object data on the database is inconsistent.

..._INCONSISTENT The sub-object data of an object on the database is inconsistent.

INVALID The specified object data is incorrect. (For example, company code not
available) ( as opposed to NOT_QUALIFIED)

..._INVALID The specified sub-object data of an object is incorrect. (As opposed to

NOT_QUALIFIED)

INTERNAL_ERROR The last resort. Use this EXCEPTION when all else fails and the error
can not be narrowed down any further.

NOT_AUTHORIZED The user is not authorized for the action.

NOT_CUSTOMIZED The requested object has been customized incorrectly.

..._NOT_CUSTOMIZED The sub-object of the requested object has been customized incorrectly.
NOT_FOUND The requested object had not been found.
..._NOT_FOUND The sub-object of the requested object has not been found.
NOT_QUALIFIED The combination of the input parameters is insufficient to trigger the
function of the method. (As opposed to INVALID)
..._NOT_QUALIFIED A particular parameter of the method is not qualified.
NUMBER_ERROR Error in the numbering.
SYSTEM_ERROR This EXCEPTION can be set when the Basis system returns an
unexpected error code.

SAP ABAP Developer Handbook Page 39 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
4 REUSABLE DEVELOPMENT OBJECTS REPOSITORY
To maximise developer’s productivity, an online repository is maintained to capture the reusable
development objects. Whenever a common routine is developed, make sure you maintain the details in
the following file which will be shared with other team members. At the same time, before you
develop a new common functionality, make sure that it doesn’t exist already.

Path: TBC

File Name: TBC

5 SAP ABAP ANALYSIS TOOLS

4.3.1 Extended Program Check

Use this function to perform static checks, which are too time consuming for the normal syntax check.
The extended program check returns both errors and warnings and it is possible to run either individual
specialized tests or one whole standard check. Ensure that minimal errors/warning exist.

4.3.2 Activatable Checkpoints

Use the activatable checkpoints tool (transaction SAAB) to maintain checkpoint groups, their
respective activation variants, and the corresponding activation settings.
Checkpoints are used for test and control purposes. An ABAP program can contain the following types
of checkpoints:
 Breakpoints
 Logpoints
 Assertions

4.3.3 Runtime Analysis

The runtime analysis allows you to examine the performance of ABAP programs such as reports,
subroutines, function modules, or classes.
The runtime analysis tips and tricks contain a series of source code examples intended to illustrate
efficient programming. For each problem, they present two possible solutions, and compare their
respective runtimes. The results enable you to see which solution is more efficient.
To start the Runtime Analysis, perform one of the following:
 From the SAP Easy Access screen, choose System ® Utilities ® Runtime Analysis ®
Execute.
 Enter transaction code SE30.

To open the tips and tricks, on the initial screen, choose Tips & Tricks.

4.3.4 Performance Analysis

The various trace functions of a SAP system are grouped together in the test tool Performance Trace;
you can use it to monitor and analyze system behaviour during database calls, lock management calls,
remote calls of reports and transactions, and calls of the table buffer administration.
To use the Performance Trace, you need authorization to start Transaction ST05 and the system
authorizations "Change trace switches" (authorization STOM for authorization object S_ADMI_FCD)
and "Analyze traces" (authorization STOR, also for authorization object S_ADMI_FCD).
To start the Performance Analysis, perform one of the following:
SAP ABAP Developer Handbook Page 40 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
  From the SAP Easy Access screen, choose System ® Utilities ® Performance Traces
® Execute.
 Enter transaction code ST05.

4.3.5 Coverage Analyzer

The Coverage Analyzer is a tool for software testing and quality assurance.
You use it to monitor the system-wide execution of ABAP programs on statement level. The Coverage
Analyzer counts the number of executions and runtime errors for processing blocks and statements
separated according to periods, test groups, and functional areas. You can use it to:
 Determine the test coverage (even for single test runs)
 Find areas of a program not covered by tests and to create additional ones in order to increase
the test coverage
 Determine unused code

To start the Coverage Analyzer, perform one of the following:

 From the SAP Easy Access screen, choose SAP Menu ® Test ® Coverage
Analyzer.
 Enter transaction code SCOV.

4.3.6 Runtime Monitor

The Runtime Monitor allows you to collect information during program execution. This is done
through a set of test cases. A test case can either be a built-in test in the ABAP runtime environment, or
it can be implemented by the ABAP developer. When you switch on a test, information is collected that
is initially stored in the main memory and then transferred to the database at regular intervals, where it
can be evaluated asynchronously.
To start the Runtime Monitor, perform one of the following:
 Enter transaction code SRTM.
 From the SAP Easy Access screen, choose SAP Menu ® Tools ® ABAP Workbench
® Test ® Runtime Monitor.

4.3.7 Memory Inspector

The Memory Inspector is a tool for analyzing memory snapshots that are saved on the application
server. You use it both to display individual memory snapshots and to compare two snapshots.
To start the Memory Inspector, perform one of the following:
 Enter transaction code S_MEMORY_INSPECTOR.
 Choose System ® Utilities ® Memory Analysis ® Compare Memory Snapshots.

4.3.8 Code Inspector

The Code Inspector is a generic tool that you use to check SAP repository objects. You use it to define
inspections which examine object sets with the help of check variants. It checks the performance,
security, syntax, and adherence to naming conventions of individual or sets of repository objects. You
also use it to retrieve statistical information or to search for certain ABAP tokens. As a result of an
inspection, you receive information, warning, and error messages about the different properties of the
examined objects.
To start the Code Inspector, perform one of the following:
 Choose SAP Menu ® Tools ® ABAP Workbench ® Test ® Code Inspector.
 Enter transaction code SCI.

SAP ABAP Developer Handbook Page 41 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
4.3.9 ABAP Unit
Automated tests could help to recognize such changes which break the existing code. Unit testing is a
technique that enables testing during development. Dedicated test classes invoke the tested program and
compare the result with the expectation. ABAP Unit implements this technique. ABAP Unit is
integrated both in the ABAP runtime and in the ABAP Workbench, which facilitates the writing of
tests.
The key features of ABAP Unit are the following:
 Tests are written in ABAP itself. You do not have to use additional tools or scripting
languages.
 The program being developed can be checked from within the editor.
 The integrated coverage analysis helps to identify code which is not tested.
 An adapter that is embedded in the Code Inspector allows you to execute multiple tests.

Find below the link from SAP Help for reference.

http://help.sap.com/saphelp_nw70/helpdata/EN/14/a794422760c46ae10000000a155106/frameset.htm

6 PROGRAMMING STANDARDS
This section contains a list ofthe ABAP coding standards, as well as some efficiencycoding standards.
The purpose of these standards is is toto:
 Encourage Promote a consistent set of practices among programmersdevelopers: . That means
Pdevelopers on the same project and developers on different projectsrograms coded by different
people should follow the same set of standard cocoding conventions.
 Emphasise the importance of program Provide internal documentation and style to the overall
standard.: Programs should be documented and styled to the extent that another programmer
developer couldcan follow the logic of the code.
 Improve readability: Programs should follow a format that makes the code easy to readpick up the
code and immediately start to understand it.

6.1 General Rules

Write programs for people first, Computers second. This means an emphasis on code readability.
Readability has a positive effect on all these aspects of a program:
 Comprehensibility
 Reviewability
 Debugging
 Modifiability (for the original author and other editors)
 Development time – a consequence of all the above factors
 Quality - a consequence of all the above factors

ABAP programs that update master and/or transactional data MUST ALWAYS use SAP transaction
codes (where transaction codes are available) by utilizing BDC or ‘call transaction’ utilities. The only
exception to this would be the use of a BAPI or "direct input" program or Class Methods provided by
SAP. These methods ensure that logical units of work, rollback, locking operations and edits are
performed.

SAP-supplied tables MUST NEVER be updated directly by custom programs – always use standard
Function Modules/BAPI’s. ABAP programs MUST NEVER be used to update configuration tables.

SAP ABAP Developer Handbook Page 42 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
Before writing any code, make sure that no existing programs or function modules, either custom or
SAP-supplied, satisfy the coding requirements. If custom coding is necessary, attempt to write the
module so that it is re-usable and can be stored in a central library. Function modules are an example of
this approach.

Find below the link for SAP standard function library:

http://help.sap.com/saphelp_nwpi71/helpdata/en/2a/f9ff44493111d182b70000e829fbfe/frameset.htm

6.2 Comments & Documentation

Internal and external documentation (design documents etc) must exist for a program. Because internal
documentation is bundled with the source code it is important that it remains reflective of the code
through-out its life.

 The purpose of comments should be to say things about the code that the code cannot say about its
self. Good comments don’t repeat the code or explain it. Goods comments summarise the code and
clarify its intent. Comments should be written to explain at a higher level of abstraction than the
code what the developer has attempted to achieve. The following description of comment
classifications clarifies the distinctions between helpful and unhelpful comments:

 Kinds of unhelpful comments:

 Repeat of the code. A repetitious comment restates what the code does in different words.
These types of comments provide the reader with more to read without providing any
additional information.

 Explanation of the code. Explanatory comments are used to explain complicated units of
code. Whilst these comments maybe useful it is because the code causes is not clear. If
the code is so complicated that is needs explanation, a better approach would be to
improve the code.

 Kinds of helpful comments:

 Intent Comments. Explains the purpose of the code. These types of comments operate
more at the level of the problem than the solution. That is, they explain “why” more than
the “how”.

 Dead Code should be removed from the program, i.e. the fields which are never referenced and
code which can never logically executed.

 Internal online documentation (Documentation sub-object of a program) must be maintained for all
ABAP reports. This provides reference information for both developers and end-users.

6.2.1 General Documentation


 The ABAP editor has a PP (Pretty Printer) command to indent specific lines of code by 2 positions
and add subroutine comments.
SAP ABAP Developer Handbook Page 43 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 Menu path: program/pretty printer in ABAP Editor.
Skipped lines and indention should be used to promote clarity between sections of code as well as
between file definitions and declarations.
For ease of reading code, concatenate repetitive commands with a colon as provided by SAP. All
TYPEs, TOs, VALUEs, DEFAULTs, table names, and comments should be aligned among themselves
throughout the code, For example.

SAP ABAP Developer Handbook Page 44 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
WRITE: L_CUST_NO, “Customer
L_CUST_NAME, “Customer Name
L_CUST_STREET. “Street

INCLUDE programs should be used for Data Declarations, PBO Dynpro modules, PAI Dynpro
modules, Subroutines, and Individual Event Processing.
Use subroutines and FORM paragraphs whenever possible to improve readability and logic flow. If a
block of code is executed more than once, it should be placed in a subroutine at the bottom of the code.
 FORM paragraphs should be placed after all non-subroutine code, after the END-OF-
SELECTION event. FORM paragraphs should generally be positioned in the order in which
they are called within the program.
 Every logical division within the program should have descriptive comments immediately prior to
the actual code.
 Each program type (Programs/Function Modules/BAPI’s/Enhancement types) shhould have a
header comments box or report headerlock that contains an initial creation section and a revision
section.
When a “REPORT” statement is used, insert the header comments before the “REPORT”
statement and is shown below:
o
*&---------------------------------------------------------------------*
*& Program Name : ZSKELTP01 *
*& Title : Basic ABAP List Report *
*& Module Name : Process Area *
*& Sub-Module : - *
*& Author : Waller (Change Author Name) *
*& Create Date : 15/08/2011 *
*& Logical DB : None *
*& Program Type : Report/Interface *
*& SIR/ CR No. : WRICEF Reference/CR/IR No *
*& SAP Release : ECC6.0 *
*& Description : This is a program template for Basic ABAP List *
*& Report. *
*&---------------------------------------------------------------------*
*& REVISION LOG *
*& *
*& LOG# DATE AUTHOR DESCRIPTION *
*& ---- ---- ------ ----------- *
*& 0000 15/08/11 J Waller Initial Implementation *
*& Correction No. : N/A *
*& Transport Request : DEVK900169 *
*&---------------------------------------------------------------------*

This header should also be utilised when creating Function Modules/BAPI’s/BADI’s/Enhancement

Implementations and any area where ABAP Development is carried out.
Every modificationsubsequent correction, no matter how insignificant, mustshould be documented in
the change revision log section that is a partof the of the report header comments block. Not only do
these log entries This provides an easy audit trail of the program’s history,auditability andbut also
allows for “at a glance” version comparisons of versions in dibetween different environments “at a
glance” rather than via remote comparisons.

SAP ABAP Developer Handbook Page 45 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
An exampleThe modification comment box is shown below of a revision entry:

*&---------------------------------------------------------------------*
*& REVISION LOG *
*& *
*& LOG# DATE AUTHOR DESCRIPTION *
*& ---- ---- ------ ----------- *
*& 0001 16/08/11 J Waller Why it is being changed *
*& Correction No. : N/A *
*& Transport Request : DEVK900169 *
*&---------------------------------------------------------------------*
REPORT Z….

When modifying existing custom code delete all redundant code. That is, - don’t comment-out code and
mark with the change reference. Version Management will be utilised to identify changes. This will aid
readability of the code.

When a custom ABAP is modified, the information must be appended to the original Program
Specification. It must also contain the Change Tracking number that was raised in relation to the
required changes.
This header should also be utilised when creating Function Modules/BAPI’s/BADI’s.
When modifying existing non SAP Standard code, delete all redundant code. Version Management will
be utilised to identify changes. This will aid readability of the code.

When a standard SAP ABAP code is modified, add the following line at the top of the code:

00010 * <OSS No> : <Change Tracking No> / <by> / <date>

The tracking number must also be placed next to the changed code.

Examples:
Short code Addition
Before After
20 ….code…. 20 ….code….
30 ….code…. 25 ….new code …. “ 441+
30 ….code….
Short code Deletion
Before After
20 ….code…. 20 ….code….
30 ….code…. 30 *….code…. “ 442-
Short code Modification
Before After
20 ….code…. 20 ….code….
SAP ABAP Developer Handbook Page 46 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 30 ….code…. 30 *….code…. “ 443-
35 ….new code …. “ 443+
Long code Addition
Before After
20 ….code…. 20 ….code….
30 ….code…. 21 * { 444++
22 ….new code….
23 ….new code….
24 ….new code….
25 ….new code….
26 * } 444++
30 ….code….

Long code Deletion

Before After
20 ….code…. 20 ….code….
22 ….code…. 21 * { 445--
23 ….code…. 22 *….code….
24 ….code…. 23 *….code….
25 ….code…. 24 *….code….
30 ….code…. 25 *….code….
26 * } 445--
30 ….code….
Long code Modification
Before After
Use the long code Deletion & Addition
formats

Strict adhererence to these formats will allow easy reversal of any modifications. It is critical that these
are followed.

SAP ABAP Developer Handbook Page 47 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
6.2.2 Documentation on Data and Program Flow

Every logical section within the program should have descriptive comments immediately prior to the
actual code. End of line comments should be minimised.

Comment all subroutines with their purpose. Comments should explain the business reasons for the
code in a particular section and what the code in that section is accomplishing. Comments should not
explain individual ABAP commands. Allow the ABAP editor to generate the comment box, by coding
the "PERFORM <form>" statement and double-clicking on the <form>. Be sure to document the input
and output parameters for the specific form in the comment box.
Dead Code should be removed from the program, i.e. the fields which are never referenced and code
which can never logically executed.

Describe data and functions or function blocks in a program

*----------------------------------------------------------------------*
* Data declaration (<- Main function block)
*----------------------------------------------------------------------*
* data for storing formulas for analysis (<- Description of the data)
data: gt_work type yt_log_formulas,
gt_formula_listing type cfftb occurs 0.

* data for logging consolidation process (<- Description of the data)

data: gt_log_cons type yt_log_cons.

* global variables for buffering receiving market (<- Description of the data)
* and step level during navigation
data: g_rcv like tkesk_lk01-eeinheit,
g_co_step type rkesk_konsstufe.

* type for assignment of additional handles of planning versions

types: begin of ys_versi_handle,
...
*----------------------------------------------------------------------*
* Initialization (<-Main function block)
*----------------------------------------------------------------------*
INITIALIZATION.
* get global parameters (<- Intermediate commentary)
CALL FUNCTION 'RKE_SK_GLOBAL_PARAM_GET'
IMPORTING
e_erkrs = p_erkrs
e_kvers = p_csvrs
e_year = p_gjahr
e_perid = p_perid
EXCEPTIONS
parameters_created = 1
canceled = 2.

IF sy-subrc = 2.
STOP.
ENDIF.

* get layout for cons.log (<- Intermediate commentary)

SELECT SINGLE * FROM tkesk_cons_log WHERE erkrs = p_erkrs.
SAP ABAP Developer Handbook Page 48 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 IF sy-subrc = 0.
p_layout = tkesk_cons_log-layout.
ENDIF.
*----------------------------------------------------------------------*
* Main program (Main function block)
*----------------------------------------------------------------------*

START-OF-SELECTION.

* check transaction (<- Intermediate commentary)

IF ( sy-tcode(4) NE 'KESK' ) AND
( sy-batch IS INITIAL ).
MESSAGE ID 'KESK' TYPE 'E' NUMBER '311'
WITH sy-tcode.
ENDIF.

IF NOT sy-batch IS INITIAL.

* mark batch mode in memory (<- Intermediate commentary)
PERFORM mark_memory_batch.
ENDIF.

* initialize (<- Intermediate commentary)

CLEAR: g_error_occured.

* set flag for consolidation in function group KESK_02 (<- Intermediate commentary)
CALL FUNCTION 'RKE_SK_CONS_LOG'
EXPORTING
i_action = 'K'.
...

SAP ABAP Developer Handbook Page 49 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
6.2.3 Documenting Form Routines

 Allow the ABAP editor to generate the comments box. Construct the "PERFORM <form>"
statement and double-clicking on the <form>.

 Provide a description of the subroutine’s purpose.

 Describe each parameter declared in the parameter list.
o Each parameter must be prefixed with a “p_” and named in accord with EDF’s
conventionstandards for well-defined variable names. (Local declarations will be
identified with an “l_” prefix.
o All variable must be local in scope. That is, Gglobal variables must be visible within
the scope of the subroutine. Global variables may be accessed as actual parameters
via the subroutine’s formal interfacepassed as parameters only.

*&---------------------------------------------------------------------*
*& Form Form name
*&---------------------------------------------------------------------*
* Function description/flow
*----------------------------------------------------------------------*
* -->I+_Import-Parameter Description
* <->X+_Changing-Parameter Description
* <--E+_Export-Parameter Description
*----------------------------------------------------------------------*
form ….

Example:
*&---------------------------------------------------------------------*
*& Form fc_tr_objects_append
*&---------------------------------------------------------------------*
* Append field cat. objects for transport interface
*----------------------------------------------------------------------*
* --> PV_OBJNAME name of object
* --> PV_TABKEY key of entry for object
* --> PV_OBJFUNC object function
* <->PT_E071 table with objects
* <->PT_E071K table with keys
* <-- PV_SUBRC returncode (= 0 if successful)
*----------------------------------------------------------------------*

form fc_tr_objects_append using pv_objname type tabname

pv_tabkey type trobj_name
pv_objfunc type objfunc
changing pt_e071 type yt_e071
pt_e071k type yt_e071k
pv_subrc type sy-subrc.

* first initialize exporting parameters

clear pv_subrc.
…

SAP ABAP Developer Handbook Page 50 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
6.2.4 Documentation in ABAP Objects
You use the documentation options available in the class builder:
 Documenting classes and methods
 Describing parameters

6.3 Layout and Formatting

Layout and formatting are features of a programming style. The use of these features aid the reduction
in a program’s complexity by highlighting the logical organisation of the code making it easier to read
and understand. Good layout can be achieved by using the following:

 One statement per line. Although the ABAP intepretator does allow more than one statement per
line use of this style is to be avioded.

 White Space. Use ‘white space’ to enhance readability.

 Indentation. Use indentation to show the logical structure of code. As a rule statements should be
indented under the statement to which they are logically sub-ordinate.

o The PRETTY PRINTER command uniformly indents each nested command structure by
2 positions. Use the convert Keyword to Upper Case option.

 Alignment. Align elements that belong together. Alignment of code reinforces the idea that a group
of statements belong together. All TYPEs, TOs, VALUEs, DEFAULTs, table names, and
comments should be aligned among themselves throughout the code, For example.

WRITE: L_CUST_NO, “Customer

L_CUST_NAME, “Customer Name
L_CUST_STREET. “Street

 Modularise code. Dividing code into partitions is a technique to improve the readability of the
overall logic structure.

 INCLUDE programs should be used to contain:

o Global data declarations; and
o PBO Dynpro modules and PAI Dynpro modules; and
o Subroutines; and
o Individual Event Processing.

 Subroutines (PERFORM statements) may be used to also conceal units of single-executed

code where it simplifies a program’s overall structure. For example, large units of code
inserted after the main program’s processing events blocks (START-OF_SELECTION event,
END-OF-SELECTION event) are to be avoided.
o A.

6.4 Programming ABAP Objects

Program as defensively as possible: Access to the elements of classes should be as restrictive as
possible and exceptions should only be made in individual, justified cases. The less code you expose to

SAP ABAP Developer Handbook Page 51 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
the outside, the more freedom you have for adapting or optimizing the implementation of your classes
to suit your needs.
 Declare classes as FINAL.
 If working with public attributes, declare them as READ-ONLY.
 Keep the number of public attributes to a minimum.
 Any methods that can be private should also be declared as such.
 For internal services, use local classes in class pools. In the case of self-contained services, this
is preferable to private methods of a global class.
 Use inheritance sparingly. If you are unsure, use interfaces to achieve polymorphism.
 It is better to use instance methods in local singletons than class methods: In this way, you can
control instantiation and lifetime.
 If you require loose coupling, use events. Do not try to implement it yourself.
 Limit the lifetime of your variables, as much as the relevant program allows. Local variables
have a shorter lifetime than instance variables, which in turn are more short-lived than class
variables.

6.5 Dialog Program Standards

 Use Data Dictionary names (short, medium, long) for field text on screens where applicable;
 Always define the field with a Format = OK as OK_CODE. This field is used to validate the
OK Event;
 Screen and program field names should generally be identical;
 Define all global data in the main program (TOP) module instead of the PBO/PAI;
 To handle a lock entry failure, invoke an error message (type E) to prevent any further
progress but leaving the user on the current screen. The user can then take an alternative action
or continue to try to lock the object. To minimize the impact on users, limit retries;
 When activating buttons or boxes, activate the associated text as well. This enables the user to
click on either the button/box or the text;
 Do not use AT PFnn in programs. Instead use the function name so that any method of
invoking the function will have the same effect as the use of the PF-Key.

Data type conversion:

External Data Type ABAP Data Type Description

ACCP N(6) Posting period YYYYMM
CHAR n C(n) Character strings
CLNT C(3) Client
CUKY C(5) Currency key, referenced by CURR fields
CURR n, m, s P((n+2)/2) DECIMAL m Currency field, stored as DEC
DEC n, m, s P((n+2)/2) DECIMAL m Counter or amount field w/ comma & sign
DATS D(8) Date field (YYYYMMDD) stored as
char(8)
FLTP F(8) Floating point number, accurate to 8 bytes
INT1 I 1-byte integer
INT2 I 2-byte integer
INT4 I 4-byte integer
SAP ABAP Developer Handbook Page 52 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 LANG C(1) Language key
LRAW X(n) Uninterpreted sequence of bytes
LCHR C(n) Long character string, requires preceding
INT2 field
NUMC n N(n) Character field with only digits
QUAN n, m, s P((n+2)/2) DECIMAL m Quantity field, points to a unit field with
format UNIT
RAW n X(n) Long byte string needs preceding INT2
field
TIM T(6) Time field (hhmmss), stored as char(6)
UNIT C(n) Unit key for QUAN fields
n: no. of places m: number of decimal places. s: sign flag

6.5.1 Table Buffering

Database tables can be stored locally on each application server. Performance time may be improved
because reading from the buffer avoids directly accessing the database. Within SAP, only POOLED
and TRANSPARENT tables allow buffering.
Considerations:
 Only buffer a table that has read-only accesses made against it and is referenced frequently.
 Only buffer tables that are modifiable, if write access occurs infrequently. Changes to buffered
tables get automatically logged in the database and are transferred to the application servers at
regular intervals. If buffered tables are modified frequently, the additional processing needed
may cancel any performance gains attained by buffering.
Native SQL commands always bypass the buffer and access the database directly. If native SQL was to
update a buffered table directly, the buffer status is not changed; this could result in inconsistencies
between data in the buffer and the database.

6.5.2 SAP List Viewer (ABAP List Viewer- ALV)

 The order of preference for the development of ALV grid reports is to use the ALV object
model primarily. Where a developer is unfamiliar with the object oriented nature of this ALV
model then it may be allowable to use the List Viewer Class (LVC) functions to implement
and ABAP list views. The older style SLIS ALV reports should not be used unless it is to
maintain compatibility with an existing development.
 Classes using the latest ALV object models may be found using wildcard searches on classes
and functions using the SALV* or *SALV* parameters. Example and demo programs exist
that may be used as a reference. These are available within transactions SE80 and SE38.
 Field catalogues for ALV reports are to be generated from dictionary based structures using
ALV field catalogue merge function modules. Manual fields may be added when a suitable
structure does not exist and less than 5 fields are required. Reference dictionary structures are
used to provide long text help, correct field formatting and column headings. Refer to
function LVC_FIELDCATALOG_MERGE
 Column headings must not be hard coded. The column headings may be created using text
elements in instances where fields are added manually to the field catalogue.
 Reference fields in ALV field catalogues should point to structure / fieldname combinations
wherever possible. (i.e. do not use direct reference of data types such as CHAR).
 Fields not intended for display or field catalogue selection are to have the technical value set to
TRUE (X) to ensure they are not displayed.
SAP ABAP Developer Handbook Page 53 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
  ALV field catalogue maintenance authority should default to own user maintenance by default
unless other specified by the technical script. Default Global layouts may be created in the
development client and transported to other clients if required.
 ALV layouts should also include the grouping and sorting internal tables passed to the
functions as a default to allow the groups and sorting to be retained.
 ALV fields that are editable or require F4 lookup help should not have hotspot (hyperlink)
function enabled as this will override the Enter or F4 functionality in the field.
 Standard ALV functions such as Excel export should be retained unless the Specification
specifically excludes the requirement.
Generally ALV performance is good however in certain situations degradation may occur if too many
round trips caused by statements that flush data between the front
end (PC) and backend systems (SAP). Therefore any design that uses large datasets must consider the
performance over a wide area network (WAN) and not just the local network.

6.6 Reporting Standards

There are two ways to develop reports in SAP; the technical lead will decide the best option based on
the requirements and feasibility.

6.6.1 Web Reporting

6.6.1.1 Webdynpro
ABAP Web Dynpro is the EDF standard for developing custom Web Dynpro’s, Only where an
existing Web Dynpro has been previously developed in JAVA should JAVA be utilised.

Web Dynpro ABAP is the SAP standard UI technology for developing Web applications in the ABAP
environment. It consists of a runtime environment and a graphical development environment with
special Web Dynpro tools that are integrated in the ABAP Workbench (SE80). Web Dynpro offers the
following advantages:
 The use of declarative and graphical tools significantly reduces the implementation effort
 Web Dynpro supports a structured design process
 Strict separation between layout and business data
 Reuse and better maintainability by using components
 The layout and navigation is easily changed using the Web Dynpro tools
 Stateful applications are supported – that is, if the page is changed and the required data
remains intact so that you can access it at any time throughout the entire application context.
 Note that stateless applications are not possible.
 Automatic data transport using data binding
 Automatic input check
 User interface accessibility is supported
 Full integration in the reliable ABAP development environment
 UI objects are created using drag and drop of UI elements which fastens overall development
time.
 supports both JAVA and ABAP development

While designing the UI layout, it should follow any one of the pattern which is shown below.

SAP ABAP Developer Handbook Page 54 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
Self Service Floor Plan:
Guide the user through an activity with multiple, sequential task steps.

Object Instance Floor Plan:

View / Edit properties of a business object, execute actions related to it.

Quick Activity Floor Plan:

Complete the immediate task in one screen, with most important attributes of respective business
object(s) and related functionality.

Parallel Activity Floor Plan:

Guide the user through a phased process which may involve several other users.

All activity windows must comply with the following conditions:

 Only the title bar and frame of the window is displayed. (No menu bar, no tool bars, no status
bar)
 Inner window size: 1012 x 709 pixel (The size of the content area, without counting the
browser frame and title bar) (This is the value that programmers need to use to specify the
window size!)
[Resulting outer window size: 1024 x 740 pixel (fits on a 1024x768 pixel screen with visible
task bar)]
 Windows are always resizable.
 Window positioning: Do not specify the window position, i.e. it is determined by the browser
(this should result in the window being completely visible on the screen, if at all possible, and
not totally covering the previous window)
 Windows never start up in full screen mode.

A form pane shall not have a white background color. With all SAP-branded background colors, the
white input fields appear slightly highlighted and the blueish disabled or read-only fields are down
SAP ABAP Developer Handbook Page 55 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
lighted. This guides the user to the editable parts of the screen. A form pane can only have max 2
“columns” of label-field combinations.

6.6.1.2 BSP (Business Server Pages)

The SAP Web Application Server provides a page-based programming model with server-side scripting
as well as server page technology for developing, designing and implementing Web applications:
Business Server Pages (BSP). Server-side scripting enables direct access to all elements in the
application server (such as function modules, database tables, ABAP Objects, and so on.).
 Flexible for web oriented development since it mixes ABAP, HTML, HTMLB and JavaScript.
 Only supports ABAP development

6.6.2 ABAP Reporting

Common guidelines to follow while developing ABAP report:

 The reports should be coded with "NO STANDARD PAGE-HEADING" specified in the
"REPORT" statement.
 Example template programs can be found in CD1
o ZSKELTP01 - Basic ABAP List Report
o ZSKELTP02 – Interactive ABAP List Report
o ZSKELTP03 – Create sequential Data Set
o ZSKELTP04 - Read Sequential Data set and create DBC
o ZSKELTP05 – Call Transaction Using Technique
o ZSKELTP06 – general Subroutines
 An Include program should contain all the global variables required by the program.
 Were classes are defined as part of the program, ensure that they exist in their own include
program
 A program should be commented in English to aid supportability
 Where possible – future proof the program by including variables on the Selection Screen
 Ensure that any FORM routines are meaningfully named.
 Ensure that all programs have a transaction created.

 Always ensure that the on line documentation exists

 Specify blank lines (for output) by using “SKIP TO LINE <nn>” or "SKIP <n>“, rather than
multiple “WRITE /” lines.
 For program parameters, use Selection Texts to specify literals that will appear on the screen
via editing Text Elements of the program. This will enable the literal to be implemented in
multiple languages.
SAP ABAP Developer Handbook Page 56 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
  All numeric fields that may contain a negative value should be displayed or printed with a
trailing minus sign (SAP standard).
 Conversion/Interface Reports: number of records read, number of records processed, number
of records written, date/time, transactions posted, etc.
 Do not use hard-coded literals. Use Text Elements to handle literal text that is printed on a
report, the advantage is easier maintainability.

WRITE: / TEXT-001. “Writes error message

There should be no hard-coding of date formats in the programs, the date format of the users’ default
information (SU50) should be used to output any date. When creating a BDC session the ABAP should
use the user default date format when formatting the record for the screen. We can’t make assumptions
about the date format of the user executing the program.
There will be no hard-coding of currency output formats in our programs. The decimal notation of the
users’ default information (SU50) should be used to output any currency value.
SAP currently does not support multiple time zones, so the time used in the system is the time that the
database server is set to. The system field SY-TZONE indicates the time difference in seconds to GMT
time.
Basic event such as START-OF-SELECTION, END-OF-SELECTION should be included in the
program to improve the readability of the program.

6.6.3 Data Definition

Variable names should be descriptive, meaningful and understandable.

Use CONSTANTS for these variables whose value does not change (Static Data).
Define CONSTANTS rather than Text Elements for these non-output hard code literals in the program.
For example:

CONSTANTS : GC_ONE_THOUSAND TYPE I VALUE 1000,

SAP ABAP Developer Handbook Page 57 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 GC_TRUE TYPE C VALUE ‘TRUE’,
GC_FALSE TYPE C VALUE ‘FALSE’.

For each field, include a comment (after the field) describing the use or purpose of the field.
INCLUDES are created for data declarations and any data structures that will be used in more than one
ABAP program.
Global variables are minimized by declaring local variables or by passing parameters while creating
internal subroutines.
Specify the type of field-symbols and formal parameters in source code, the ABAP compiler can better
optimize the code.

Field-Symbol without type Typed Field-Symbol

FIELD-SYMBOLS: <FS>. FIELD-SYMBOLS: <FS_I> TYPE I.

ASSIGN I1 TO <FS>. ASSIGN I1 TO <FS_I>.

I2 = <F>. I2 = <FS_I>.
I3 = <F>. I3 = <FS_I>.
I4 = <F>. I4 = <FS_I>.

6.6.4 Online Standard

Use Data Dictionary names (short, medium, long) for field text on screens where applicable. Always
define the field with a Format = OK as OK_CODE. This field is used to validate the OK Event.
Screen and program field names should generally be identical. Define all global data in the main
program (TOP) module instead of the PBO/PAI.
To handle a lock entry failure, invoke an error message (type E) to prevent any further progress but
leaving the user on the current screen. The user can then take an alternative action or continue to try to
lock the object. To minimize the impact on users, limit retries.
While activating buttons or boxes, activate the associated text as well. This enables the user to click on
either the button/box or the text.
Do not use AT PFnn in programs. Instead use the function name so that any method of invoking the
function will have the same effect as the use of the PF-Key.

SAP ABAP Developer Handbook Page 58 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
6.6.5 Batch Program / Interface Standards
Message statements executed in batch programs are output to the txn SM37 "Job Log". "Success"
messages (type 'S') should be used generously to provide an audit trail of the program's execution.
Include record counts to indicate the number of records read and processed. Write out exceptions to a
report. Document the program variant(s) if it needs to run with special parameters.
An ABAP program that reads from or writes to a sequential dataset should always OPEN the dataset
before the read/write operation, and after file processing it should CLOSE the file. Although these
statements are not mandatory, it is good practice to include them. Also, without an OPEN DATASET
statement, a file will always be opened in BINARY mode. This may not be the mode required. Define
Logic filename as parameters.

Example:

DATA: G_PDSNME LIKE FILENAME-FILEEXTERN. "Physical Dataset

Name.

DATA: BEGIN OF I_TAB OCCURS ...

END OF I_TAB.

PARAMETERS: P_LDSNME LIKE FILENAME-FILEINTERN "Logical Dataset Name

DEFAULT 'CUSTOMER_FILE'.

AT SELECTION-SCREEN.
CALL FUNCTION 'FILE_GET_NAME'
EXPORTING
LOGICAL_FILENAME = P_LDSNME
IMPORTING
FILE_NAME = G_PDSNAME
EXCEPTIONS
FILE_NOT_FOUND = 01.

IF SY-SUBRC <> 0.
*-------No physical filename can be determined for &
MESSAGE E016(MG)WITH P_LDSNME.
ENDIF.

START-OF-SELECTION.

OPEN DATASET G_PDSNME FOR OUTPUT IN TEXT MODE.

IF SY-SUBRC <> 0.
* Insert error processing here.
ENDIF.

TRANSFER I_TAB TO G_PDSNME.

CLOSE DATASET G_PDSNAME.

6.6.6 Message

Messages are included at appropriate places to indicate illegal operation like no authorization, no data
found, etc. Although consistency with SAP-supplied messages is highly encouraged, do not use SAP-

SAP ABAP Developer Handbook Page 59 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
supplied default message IDs, as these IDs can change from release to release. Instead, copy these
messages to customer message IDs.

6.6.7 Program Logic

6.6.7.1 System Return Code (SY-SUBRC)

A program should test the system return code field (SY-SUBRC) after any statements that could
potentially change its value unless the outcome of the statement is not important for subsequent
processing.

The return code should always be checked after any database table read/update statements or READ
statements.
For egE.G: SELECT * FROM TABNA.
…DO Processing
ENDSELECT.
IF SY-SUBRC = 0.
WRITE: / ‘ ‘
ENDIF.

6.6.7.2 Authorisation Checks

Authorization should be performed to handle the security of the program.

6.6.7.3 CHECK Statement

CHECK is used instead of IF/ENDIF whenever possible

CHECK, EXIT, REJECT, STOP is used to suspend processing or skip unnecessary processing.

6.6.7.4 IF versus CASE Statements

For IF statements, nest true testing conditions so that the outer conditions are most frequently true.

CASE statements are clearer for legibility and slightly faster than IF-constructions. After about five
nested Ifs the performance of the CASE is more efficient.

WHILE is used instead of a DO+EXIT-construction, because WHILE is easier to understand and faster
to execute.

Do While
I1 = 0. I1 = 0.
DO. WHILE C1A = SPACE.
IF C1A NE SPACE. EXIT. ENDIF. ADD 1 TO I1.
ADD 1 TO I1. IF I1 GT 10. C1A = 'X'. ENDIF.
IF I1 GT 10. C1A = 'X'. ENDIF. ENDWHILE.
ENDDO.
Runtime Measure(in microsec): 5 Runtime Measure(in microsec): 3

Notes: The runtimes depicted in this manual are just sample measurement, they are measured on multi-
processor environment, and they are, however, not runtime measurement benchmarks.

SAP ABAP Developer Handbook Page 60 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
Use PERFORM i OF statement when calling a certain routine based on a given index, instead of using
CASE…WHEN/PERFORM, since the first statement is fast to execute.

Case Perform i Of …
* (I1 = 5 in this test) * (I1 = 5 in this test)
CASE I1. PERFORM I1 OF
WHEN 1. PERFORM PV1. PV1
WHEN 2. PERFORM PV2. PV2
WHEN 3. PERFORM PV3. PV3
WHEN 4. PERFORM PV4. PV4
WHEN 5. PERFORM PV5. PV5
WHEN 6. PERFORM PV6. PV6
WHEN 7. PERFORM PV7. PV7
WHEN 8. PERFORM PV8. PV8.
Runtime Measure(in microsec): 5 Runtime Measure(in microsec): 2

LOOP …. WHERE is faster than LOOP/CHECK because LOOP …. WHERE evaluates the specific
condition internally.

Loop/Check Loop/Where
LOOP AT ITAB. LOOP AT ITAB WHERE NAME1 = KVAL.
CHECK ITAB-NAME1 = KVAL. ……….
ENDLOOP. ENDLOOP.

6.7 Performance Standards

6.7.1 Non-Database Access Operations

6.7.1.1 “Dead” code

Eliminate "dead" code - variables that are not referenced and statements that are not executed. Use
Extended Syntax Check (SLIN) to identify variables not referenced statically.

6.7.1.2 MOVE-CORRESPONDING Statement

Avoid the use of this statement. The expressed use of “MOVE” is recommended.

6.7.2 Database Access Operations

The way construction of SQL statements are construction within an ABAP program will have an affect
ons its overall runtime performance. The developer’s role should be to build programs that access the
database in the most efficient manner. Awareness of the following rules during the design phase will
aid the decision-making process:

 Minimise the number of transfers between the databases and application server.
 Minimise the amount of data to be transferred between the databases and application server.
 Minimise the workload of the database.

SAP ABAP Developer Handbook Page 61 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
6.7.2.1 Reading Data

6.7.2.1.1 SELECT Clause

Aim to retrieve only the database table columns required. That is, limit the usage of the Select All fields
(Select *) statement to scenarios which dictate the need to transfer all the table’s columns from the
database to the program. The number of columns retrieved may be restricted in two ways:
 Specification of a field list within the SELECT clause; or
 Use of a DDIC table view projection. (A DDIC view has the added advantage of being
reusable).

SELECT statement that specifies all fields SELECT statement with a field list
specified
SELECT * FROM DD01L SELECT DOMNAME FROM DD01L
WHERE DOMNAME LIKE 'CHAR%' INTO DD01L-DOMNAME
AND AS4LOCAL = 'A'. WHERE DOMNAME LIKE 'CHAR%'
ENDSELECT. AND AS4LOCAL = 'A'.
ENDSELECT.
Runtime Measure(in microsec): 42,880 Runtime Measure(in microsec): 11,402

6.7.2.1.1.1 Aggregate Functions

Use a select list with aggregate functions instead of checking and computing, when try to find the
maximum, minimum, sum and average value or the count of a database column, thus network load is
considerably less.

Select … Where + Check Select using an aggregate function

C4A = '000'. SELECT MAX( MSGNR ) FROM T100 INTO C4A
SELECT * FROM T100 WHERE SPRSL = 'D' AND
WHERE SPRSL = 'D' AND ARBGB = '00'.
ARBGB = '00'.
CHECK: T100-MSGNR > C4A.
C4A = T100-MSGNR.
ENDSELECT.
Runtime Measure(in microsec): 12,268 Runtime Measure(in microsec): 9,228

6.7.2.1.2 WHERE Clause

Aim to minimise the number of database table rows retrieved. The specification of the WHERE-clause
avoids the need to retrieve each row of a database table to determine whether it is valid or not for
further processing.

SELECT statement (Without WHERE-clause) SELECT statement with WHERE-clause

+ Check statement specified
SELECT * FROM SBOOK. SELECT * FROM SBOOK
CHECK: SBOOK-CARRID = 'LH' AND WHERE CARRID = 'LH' AND
SBOOK-CONNID = '0400'. CONNID = '0400'.
ENDSELECT. ENDSELECT.
Runtime Measure(in microsec): 2,509 Runtime Measure(in microsec): 1,479

A justification to omit the WHERE-clause is when the entire contents of the database table are required.
The once-only read of a reference value table would fit this criterion.

SAP ABAP Developer Handbook Page 62 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
Use the DISTINCT addition in the SELECT-clause when it is expected that the WHERE-clause will
result in a large number of duplicate entries.

6.7.2.1.2.1 WHERE-clause formulation

A WHERE-clause should be formulated to employ a database table index. Each SAP database table has
a primary key (UNIQUE index) and maybe one or more secondary keys defined that supports efficient
searches of its content. Avoid the use of unsupported SELECT statements that result in expensive
searches.

Select without index support Select with primary index support

SELECT * FROM T100 SELECT * FROM T002.
WHERE ARBGB = '00' SELECT * FROM T100
AND MSGNR = '999'. WHERE SPRSL = T002-SPRAS
ENDSELECT. AND ARBGB = '00'
AND MSGNR = '999'.
ENDSELECT.
ENDSELECT.
Runtime Measure(in microsec): 1,959,019 Runtime Measure(in microsec): 28,434

When the primary key can be fully qualified make use of the SELECT SINGLE option instead of
SELECT-ENDSELECT. SELECT SINGLE requires one communication with the database system
whereas SELECT-ENDSELECT needs two.

Select … Endselect Select Single

SELECT * FROM SCARR SELECT SINGLE * FROM SCARR
WHERE CARRID = 'LH'. WHERE CARRID = 'LH'.
ENDSELECT.
Runtime Measure(in microsec): 861 Runtime Measure(in microsec): 741

In the scenario where the available primary or secondary keys defined for a table cannot be fully
qualified then consider the following options:
 Evaluate the source of data being used and identify whether an alternative table exists (that
contains the desired data) that can be accessed more efficiently. For example, an unsupported
read on a large (CLUSTER) table like BSEG should be replaced with a read on one of the
accounting secondary indexed tables (BSAD, BSID, BSIS, BSAS, BSAK, BSIK).
 Create a new secondary index for the target table in the DDIC.
 Make use of the “UP TO N ROWS” option in the FROM-clause to restrict the number of table
rows returned.

6.7.2.1.2.1.1 Index Optimisation

Index utilisation is part of the “Minimize the Amount of Data Transferred” objective. To ensure that the
actual table search is optimal developers heed the following factors:
 Satisfy as much of the chosen index definition as possible. The database optimiser can still
make use of an index even though the query does not make use of all of the columns specified
in its definition. In this case the sequence of the columns in the index is important as a column
can only be used if all of the columns preceding it in the index’s definition have also been
specified as part of the condition.
 Phrase each condition within the query to be positive where possible. Use of negative
operators such as “Not Equal” or “Not Exist” or “Not Like” disables the database optimizer
from using a table index.
 The use of equality (EQ) checks and conjunctions (AND) are the most efficient expressions.
 “OR” expressions may prevent the database optimiser making use of the full index. This
means that the index columns involved in the “OR” expression may not be included in the
index search. An exception to this are “OR” expressions at the outside of conditions.
SAP ABAP Developer Handbook Page 63 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
6.7.2.1.3 INTO Clause

The statement “SELECT…ENDSELECT” results in numerous accesses to the database. An array-

orientated SELECT operation is the recommended approach because it encourages: (1) the selection of
required data only once and (2) the avoidance of nested SELECT statements.

Use the “INTO TABLE” OR “APPENDING TABLE” options rather than Append each record one at a
time.

Select + Append statement Select Into Table

REFRESH X006. SELECT * FROM T006 INTO TABLE X006.
SELECT * FROM T006 INTO X006.
APPEND X006.
ENDSELECT.
Runtime Measure(in microsec): 2,888 Runtime Measure(in microsec): 920

Limit the usage of “INTO CORRESPONDING FIELDS OF TABLE” or “APPENDING

CORRESPONDING FIELDS OF TABLE” to large result-sets (characterised by a large number of
columns and rows). These variants of the “INTO TABLE” OR “APPENDING TABLE” options carry
additional overheads because the columns need to be mapped from the database to the program’s
structure fields. The recommended approach is use “INTO TABLE” OR “APPENDING TABLE”
options, ensuring that the columns are specified in the SELECT-clause and target the internal table
structure is defined to match the sequence of columns.

6.7.2.1.4 ORDER BY clause

It is recommended that the use of the ORDER BY clausestatement should be used in SELECT if we use
the is restricted to when the primary indexkey is fully qualified. else sorting is effective by Otherwise,
readingstore the data intoin an internal table and use the ABAP SORT statement in the program.

Order by with index Order by without index

SELECT * FROM SPFLI ORDER BY SELECT * FROM SPFLI ORDER BY
PRIMARY KEY. AIRPFROM AIRPTO.
ENDSELECT.
Runtime Measure(in microsec): 3,138 Runtime Measure(in microsec): 3,959

6.7.2.2 Changing Data

Whenever possible, uUse array operations instead of single-row operations to modify your database
tables. The frequent communication between the application program and database system produces
considerable overhead.

Single-line Insert Array Insert

LOOP AT TAB. INSERT CUSTOMERS FROM TABLE TAB.
INSERT INTO CUSTOMERS VALUES
TAB.
ENDLOOP.
Runtime Measure(in microsec): 12 Runtime Measure(in microsec): 12

Whenever possible, uUse column-specified table updates instead of single-rowentire row updates. to
update your database tables. Network load can then be considerably less.

Single-line updates Column update

SAP ABAP Developer Handbook Page 64 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
 SELECT * FROM SFLIGHT. UPDATE SFLIGHT
SFLIGHT-SEATSOCC = SET SEATSOCC = SEATSOCC - 1.
SFLIGHT-SEATSOCC - 1.
UPDATE SFLIGHT.
ENDSELECT.
Runtime Measure(in microsec): 6,054 Runtime Measure(in microsec): 1,517

6.7.2.3 Nested SELECT statements

Avoid the use of nested select statements. Instead use one of the following options:
 Table join statement,
 DDIC view,
 Sub-query select statement
 “For All Entries” statement.
o Ensure that the internal table contains at least one entry; and
o Sort internal table by the fields to be used in the WHERE-clause.

Nested Select statements Select with view

SELECT * FROM DD01L SELECT * FROM DD01V
WHERE DOMNAME LIKE 'CHAR%' WHERE DOMNAME LIKE 'CHAR%'
AND AS4LOCAL = 'A'. AND DDLANGUAGE = SY-LANGU.
SELECT SINGLE * FROM DD01T ENDSELECT.
WHERE DOMNAME = DD01L-
DOMNAME
AND AS4LOCAL = 'A'
AND AS4VERS = DD01L-AS4VERS
AND DDLANGUAGE = SY-LANGU.
ENDSELECT.
Runtime Measure(in microsec): 250,731 Runtime Measure(in microsec): 39,971

6.7.2.4 Minimise the Database workload

6.7.2.4.1 Avoid Repeated Access

Aim to read a given set of data once. Repeated reads of the same data increases the number of database
accesses and increases the load on the database. An example of a repeated read is SELECT before an
UPDATE.

6.7.2.4.2 Sort Data in ABAP Programs

6.7.2.4.3 Table Buffering

Table buffering on the application server for accessing frequently used, read-only tables, network load
can be considerably less. However, in case of retrieving latest data in multi-user environment, you may
need to bypass the buffer.

Select without buffer support Select with buffer support

SELECT SINGLE * FROM T100 SELECT SINGLE * FROM T100
BYPASSING BUFFER WHERE SPRSL = 'D'
WHERE SPRSL = 'D' AND ARBGB = '00'
SAP ABAP Developer Handbook Page 65 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 AND ARBGB = '00' AND MSGNR = '999'.
AND MSGNR = '999'.
Runtime Measure(in microsec): 775 Runtime Measure(in microsec): 87

For a buffered table do not to use any Open SQL statements that bypass the buffer. The SELECT
statement will bypass the table buffer when any of the following options are used:

 The BYPASSING BUFFER addition in the FROM clause

 The DISTINCT addition in the SELECT clause
 Aggregate expressions in the SELECT clause
 Joins in the FROM clause
 The IS NULL condition in the WHERE clause
 Sub-queries in the WHERE clause
 The ORDER BY clause
 The GROUP BY clause
 The FOR UPDATE addition

6.7.2.4.4 Logical Databases

The use of a logical database is an option supplied by SAP to limit the database workload. A logical
database executes authorization checking for data access, but even if you just access one table, you will
still need to access all the tables above the current hierarchy level in logical database, which creates
data access inefficiency.

6.7.3 Internal Table

Internal table access can be done more efficiently with the right use of the table type. See
documentation on ABAP keyword TABKIND for the different table types:

 any
 index
 standard
 sorted
 hashed

Apart from performance advantages that can be obtained, the different table types can have a different
syntax for table operations. Please refer to the online help for more details.
Especially with large amounts of data, internal table access can take a lot of time if the wrong table type
is used.

Internal table with header line is obsolete in SAP ECC versions.

Always use work area to move data from internal table.

Table operation via header line Table operation via explicit work area
* The line width of table TAB is 500 bytes * The line width of table TAB is 500 bytes

TAB = TAB_WA. APPEND TAB_WA TO TAB.

APPEND TAB.
Runtime Measure(in microsec): 4 Runtime Measure(in microsec): 3

When loading data into Internal table, INTO TABLE OR APPENDING TABLE is used instead of a
SELECT/APPEND combination.

SAP ABAP Developer Handbook Page 66 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
Internal table is defined with ‘OCCURS 0’ if the maximum size of the table is potentially >=8K. If the
data to be read is estimated to be under 8K, then specifying the number of lines in the OCCURS
statement (e.g. itab1 occurs 10) is effective.

Use MOVE instead of MOVE-CORRESPONDING for efficiency purpose, MOVE-

CORRESPONDING is used only when two tables have same field structure.

Use one-step approach READ/INSERT, If the amount of data is small (< 20 entries), or if users need
read-access to the internal table while it is being filled, however, if the data amount is larger and you
need read-access only to the completely-filled table, the two-step algorithm APPEND/SORT or three-
step approach APPEND/SORT/DELETE DUPLICATE (for tables without duplicates) is preferable.

One-step approach: READ/INSERT Two-step approach: APPEND, then SORT

* TAB_DEST is filled with 1000 entries * TAB_DEST is filled with 1000 entries

REFRESH TAB_DEST. REFRESH TAB_DEST.

LOOP AT TAB_SRC. LOOP AT TAB_SRC.
READ TABLE TAB_DEST WITH APPEND TAB_SRC TO TAB_DEST.
KEY K = TAB_SRC-K BINARY SEARCH. ENDLOOP.
INSERT TAB_SRC INTO TAB_DEST INDEX SORT TAB_DEST BY K.
SY-TABIX.
ENDLOOP.
Runtime Measure(in microsec): 41,760 Runtime Measure(in microsec): 11,557
One-step approach Three-steps: copy, sort, delete duplicates
* TAB_SRC contains 1000 entries, of which 500 * TAB_SRC contains 1000 entries, 500 are
are different different

REFRESH TAB_DEST. REFRESH TAB_DEST.

LOOP AT TAB_SRC. LOOP AT TAB_SRC.
READ TABLE TAB_DEST WITH APPEND TAB_SRC TO TAB_DEST.
KEY K = TAB_SRC-K BINARY SEARCH. ENDLOOP.
IF SY-SUBRC <> 0. SORT TAB_DEST BY K.
INSERT TAB_SRC INTO TAB_DEST DELETE ADJACENT DUPLICATES FROM
INDEX SY-TABIX. TAB_DEST COMPARING K.
ENDIF.
ENDLOOP.
Runtime Measure(in microsec): 22,663 Runtime Measure(in microsec): 14,888

COLLECT is used instead of READBINARY/INSERT If number of entries greater than 1000. READ
BINARY runs in O(log2 (n)) time, and the internal table's index must be adjusted with each INSERT,
however, COLLECT uses a hash algorithm and is therefore independent of the number of entries and
does not need to maintain a table index. If the amount of data is small, the READ/INSERT approach
isn't bad, but for large amounts of data (> 1000), COLLECT is much faster.

COLLECT semantics using READ BINARY Collect via COLLECT statement

* Table TAB_SRC is filled with 10,000 entries, * Table TAB_SRC is filled with 10,000 entries,
* 5,000 of which have different keys * 5,000 of which have different keys

LOOP AT TAB_SRC. LOOP AT TAB_SRC.

READ TABLE TAB_DEST WITH COLLECT TAB_SRC INTO TAB_DEST.
KEY K = TAB_SRC-K BINARY SEARCH. ENDLOOP.
IF SY-SUBRC = 0. SORT TAB_DEST BY K.
ADD: TAB_SRC-VAL1 TO TAB_DEST-
VAL1,
TAB_SRC-VAL2 TO TAB_DEST-VAL2.
MODIFY TAB_DEST INDEX SY-TABIX.
SAP ABAP Developer Handbook Page 67 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 ELSE.
INSERT TAB_SRC INTO TAB_DEST INDEX
SY-TABIX.
ENDIF.
ENDLOOP.
Runtime Measure(in microsec): 709,306 Runtime Measure(in microsec): 116,422

SAP ABAP Developer Handbook Page 68 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
COLLECT is not used with the combination of APPEND, INSERT and/or MODIFY when filling in the
internal table. If COLLECT is mixed with the other statements, it cannot use its hash algorithm. In this
case, COLLECT resorts to a normal linear search, which is dramatically slower.

Use BINARY SEARCH instead of linear search when internal table has more than 20 entries. If TAB
has n entries, linear search runs in O(n) time, whereas binary search takes only O(log2 (n)). And also
when reading a single record in an internal table, the READ TABLE WITH KEY is not a direct READ.
Therefore, SORT the table and use READ TABLE WITH KEY BINARY SEARCH.

Linear search of an internal table Binary search of an internal table

* Table TAB is filled with 1000 entries * Table TAB is filled with 1000 entries of 100
bytes each
* The READ ends with SY-SUBRC=4 * The READ ends with SY-SUBRC=4

READ TABLE TAB WITH KEY K = 'X'. READ TABLE TAB WITH KEY K = 'X'
BINARY SEARCH.
Runtime Measure(in microsec): 875 Runtime Measure(in microsec): 11

Specify the key fields for read access explicitly, use READ TABLE WITH KEY k = ‘X’ instead of
READ TABLE WITH KEY. Otherwise, the key fields have to be computed dynamically by the run
time system.

Access via implicit default key Access via key specified explicitly
* Table TAB is filled with 30 entries of 500 bytes * Table TAB is filled with 30 entries of 500 bytes
each each
* The READ ends with SY-SUBRC=4 * The READ ends with SY-SUBRC=4

MOVE SPACE TO TAB. READ TABLE TAB WITH KEY K = 'X'

BINARY SEARCH.
TAB-K = 'X'.
READ TABLE TAB BINARY SEARCH.
Runtime Measure(in microsec): 15 Runtime Measure(in microsec): 7

LOOP ... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified
condition internally. The performance can be further enhanced if LOOP ... WHERE is combined with
FROM i1 and/or TO i2, if possible.

Key access with LOOP/CHECK Key access with LOOP … WHERE

* Table TAB is filled with 100 entries of 500 bytes * Table TAB is filled with 100 entries of 500
each, bytes each,
* 5 entries of which match the key condition * 5 entries of which match the key condition

LOOP AT TAB. LOOP AT TAB WHERE K = KVAL.

CHECK TAB-K = KVAL. " ...
" ... ENDLOOP.
ENDLOOP.
Runtime Measure(in microsec): 610 Runtime Measure(in microsec): 182

Internal tables can be compared, copied in logical expressions just like other data objects. Two internal
tables are equal if
- They have the same number of lines and
- Each pair of corresponding lines is equal.

Pedestrian way to compare internal tables Let the kernel to do the work …
* Tables TAB1 & TAB2 are each filled with 100 * Tables TAB1 & TAB2 are each filled with 100
entries entries
SAP ABAP Developer Handbook Page 69 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 * of 100 Bytes each. * of 100 Bytes each.

DESCRIBE TABLE: TAB1 LINES L1, IF TAB1 = TAB2.

TAB2 LINES L2. " ...
ENDIF.
IF L1 <> L2.
TAB_DIFFERENT = 'X'.
ELSE.
TAB_DIFFERENT = SPACE.
LOOP AT TAB1.
READ TABLE TAB2 INDEX SY-TABIX.
IF TAB1 <> TAB2.
TAB_DIFFERENT = 'X'. EXIT.
ENDIF.
ENDLOOP.
ENDIF.

IF TAB_DIFFERENT = SPACE.
" ...
ENDIF.
Runtime Measure(in microsec): 741 Runtime Measure(in microsec): 152

Specify the sort fields on the sort statement, not leave the fields as default, the more restrictively you
specify the sort key, the faster the program will run.

Sort internal table with default sort key Sort with sort key specified explicitly
* Table TAB is filled with 100 entries of 500 bytes * Table TAB is filled with 100 entries of 500
each bytes each

SORT TAB. SORT TAB BY K.

Runtime Measure(in microsec): 503 Runtime Measure(in microsec): 357

Use parallel cursor instead of join two tables or nested loop. If TAB1 has n1 entries and TAB2 has n2
entries, the time needed for joining TAB1 and TAB2 with the straightforward algorithm is O( n1 *
log2( n2 ) ), nested loop is O( n1 * n2 ), whereas the parallel cursor approach takes only O( n1 + n2 )
time.

Native join: loop tab1, read tab2 with key More sophisticated: use parallel cursor
* Table TAB1 is filled with 1000 entries of 100 * Table TAB1 is filled with 1000 entries of 100
bytes each bytes each
* Table TAB2 is filled with 300 entries of 100 * Table TAB2 is filled with 300 entries of 100
bytes each bytes each
* Table TAB2 is assumed to be sorted by K in * Tables TAB1 & TAB2 to be sorted by K
ascending ascending
* order
I2 = 1.
LOOP AT TAB1. LOOP AT TAB1.
READ TABLE TAB2 WITH KEY READ TABLE TAB2 INDEX I2.
K = TAB1-K BINARY SEARCH. IF SY-SUBRC <> 0. EXIT. ENDIF.
IF SY-SUBRC = 0. IF TAB2-K = TAB1-K.
" ... " ...
ENDIF. ADD 1 TO I2.
ENDLOOP. ENDIF.
ENDLOOP.
Runtime Measure(in microsec): 16,723 Runtime Measure(in microsec): 6,228
Straight forward nested loop More sophisticated loop: parallel cursor
* Table TAB1 is filled with 100 entries of 100 * TAB1 is filled with 100 entries of 100 bytes
SAP ABAP Developer Handbook Page 70 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 bytes each each
* Table TAB2 is filled with 10 * 100 = 1000 * TAB2 is filled with 10 * 100 = 1000 entries of
entries of 100 bytes each
* 100 bytes each * TAB1 & TAB2 assumed to be sorted by K in
ascending order

LOOP AT TAB1. I2 = 1.
LOOP AT TAB2 WHERE K = TAB1-K. LOOP AT TAB1.
“… LOOP AT TAB2 FROM I2.
ENDLOOP. IF TAB2-K <> TAB1-K.
ENDLOOP. I2 = SY-TABIX.
EXIT.
ENDIF.
“…
ENDLOOP.
ENDLOOP.
Runtime Measure(in microsec): 180,472 Runtime Measure(in microsec): 8,839

Use the MODIFY variant “MODIFY itab ... TRANSPORTING f1 f2 ...” for single line, and
“MODIFY itab ... TRANSPORTING f1 f2 ...” WHERE condition for a set of line, to accelerate the
updating of internal table. The longer the table line is, the larger the speed-up is. The effect increases
for tables with complex structured line types.

Modifying all components of single line Modifying selected components only

* Table TAB is filled with 5000 entries of 500 * Table TAB is filled with 5000 entries of 500
bytes each. bytes each.
* Only the 8 bytes of the component DATE are * Only the 8 bytes of the component DATE are
modified. modified.

LOOP AT TAB. WA-DATE = SY-DATUM.

TAB-DATE = SY-DATUM. LOOP AT TAB.
MODIFY TAB. MODIFY TAB FROM WA TRANSPORTING
DATE.
ENDLOOP. ENDLOOP.
Runtime Measure(in microsec): 56,642 Runtime Measure(in microsec): 53,849
Modifying all components of lines Modifying selected components only
* Table TAB is filled with 100 entries. A line has * Table TAB is filled with 100 entries. A line has
two two
* components, a FLAG of typ C and an integer * components, a FLAG of typ C and an integer
table table
* INTTAB with 20 entries each. * INTTAB with 20 entries each.
* The Flag is switched on for all 100 lines. * The Flag is switched on for all 100 lines.

LOOP AT TAB. TAB-FLAG = 'X'.

IF TAB-FLAG IS INITIAL. MODIFY TAB TRANSPORTING FLAG
TAB-FLAG = 'X'. WHERE FLAG IS INITIAL.
ENDIF.
MODIFY TAB.
ENDLOOP.
Runtime Measure(in microsec): 6,190 Runtime Measure(in microsec): 235

Use APPEND LINES OF itab1 TO itab2 and INSERT LINES OF itab1 INTO itab2 INDEX idx instead
of APPEND and INSERT. And thus the task of appending and insert a table to another table can be
transferred to the kernel.

SAP ABAP Developer Handbook Page 71 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
 Pedestrian way to append a table Let the kernel to do the work …
* Table TAB_SRC and TAB_DEST are both filled * Table TAB_SRC and TAB_DEST are both
with 500 filled with 500
* entries of 100 bytes each. TAB_SRC is * entries of 100 bytes each. TAB_SRC is
appended line by appended in a
* line to TAB_DEST. * single step to TAB_DEST.

LOOP AT TAB_SRC. APPEND LINES OF TAB_SRC TO

TAB_DEST.
APPEND TAB_SRC TO TAB_DEST.
ENDLOOP.
Runtime Measure(in microsec): 3,716 Runtime Measure(in microsec): 791
Pedestrian way to insert a table Let the kernel to do the work …
* Table TAB_SRC and TAB_DEST are both filled * Table TAB_SRC and TAB_DEST are both
with 500 filled with 500
* entries of 100 bytes each. TAB_SRC is inserted * entries of 100 bytes each. TAB_SRC is inserted
line by in a
* line to TAB_DEST at index IDX. * single step to TAB_DEST at index IDX.

IDX = 250. IDX = 250.

LOOP AT TAB_SRC. INSERT LINES OF TAB_SRC INTO
INSERT TAB_SRC INTO TAB_DEST INDEX TAB_DEST INDEX IDX.
IDX.
ADD 1 TO IDX.
ENDLOOP.
Runtime Measure(in microsec): 16,121 Runtime Measure(in microsec): 845

Use DELETE ADJACENT DUPLICATES / DELETE itab FROM ... TO ... / DELETE itab [FROM ...]
[TO ...] WHERE ... instead of DELETE, to transfer the task of deleting entries to the kernel.

Pedestrian way to delete duplicates Let the kernel to do the work …

* Table TAB_DEST is filled with 1000 entries of * Table TAB_DEST is filled with 1000 entries of
100 bytes 100 bytes
* each and contains 500 pairs of duplicates * each and contains 500 pairs of duplicates

READ TABLE TAB_DEST INDEX 1 INTO DELETE ADJACENT DUPLICATES FROM

PREV_LINE. TAB_DEST COMPARING K.
LOOP AT TAB_DEST FROM 2.
IF TAB_DEST = PREV_LINE.
DELETE TAB_DEST.
ELSE.
PREV_LINE = TAB_DEST.
ENDIF.
ENDLOOP.
Pedestrian way to delete a sequence of lines Let the kernel to do the work …
* Table TAB_DEST is filled with 1000 entries of * Table TAB_DEST is filled with 1000 entries of
500 bytes 500 bytes
* each, and lines 450 to 550 are to be deleted * each, and lines 450 to 550 are to be deleted

DO 101 TIMES. DELETE TAB_DEST FROM 450 TO 550.

DELETE TAB_DEST INDEX 450.
ENDDO.
Pedestrian way to delete a set of lines Let the kernel to do the work …
* Table TAB_DEST is filled with 1000 entries of * Table TAB_DEST is filled with 1000 entries of
500 bytes 500 bytes
* each, 250 of which match the WHERE condition * each, 250 of which match the WHERE
condition
SAP ABAP Developer Handbook Page 72 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 LOOP AT TAB_DEST WHERE K = KVAL. DELETE TAB_DEST WHERE K = KVAL.
DELETE TAB_DEST.
ENDLOOP.
Runtime Measure(in microsec): 4,813 Runtime Measure(in microsec): 3,771

Use “DELETE itab WHERE ...” instead of “LOOP AT itab WHERE ... DELETE itab. ENDLOOP.”
increases with the number of entries the internal table contains and the number of lines to be deleted.

If the data is processed only once, use a SELECT-ENDSELECT loop instead of collecting data in
an internal table with SELECT ….INTO TABLE because the Internal table handling takes up much
more space.

SELECT * FROM <TABLE> SELECT * FROM <TABLE>

INTO TABLE <INT-TAB> ENDSELECT
LOOP AT <INT-TAB>.
…………..
ENDLOOP.

Internal tables can be copied by move just like any other data object.

ITAB = ITAB1. LOOP AT ITAB INTO ITAB1.

APPEND ITAB1.
ENDLOOP.

6.7.4 String Operation

Use the special operators CO, CA, CS, instead of programming the operations yourself. If ABAP
statements are executed per character on long strings, CPU consumption can rise substantially.

DO-Loop with Field-Symbols Using the CA operator

ASSIGN CHA(1) TO <C>. IF CHA(200) CA '()'.
"...any actions
DO 200 TIMES. ENDIF.
IF <C> = '(' OR <C> = ')'.
"...any actions
EXIT.
ENDIF.
ASSIGN <C>+1 TO <C>.
ENDDO.
Runtime Measure(in microsec): 563 Runtime Measure(in microsec): 20

Some function modules for string manipulation have become obsolete and should be replaced by ABAP
statements or functions:
STRING_CONCATENATE... -> CONCATENATE,
STRING_SPLIT... -> SPLIT,
STRING_LENGTH -> strlen(),
STRING_CENTER -> WRITE...TO...CENTERED,
STRING_MOVE_RIGHT -> WRITE...TO...RIGHT-JUSTIFIED,

Use of a CONCATERNATE function module Use of the CONCATERNATE statement

CALL FUNCTION CONCATENATE T100-ARBGB
'STRING_CONCATENATE_3'
EXPORTING T100-MSGNR
STRING1 = T100-ARBGB T100-TEXT INTO CLA.
STRING2 = T100-MSGNR
STRING3 = T100-TEXT
SAP ABAP Developer Handbook Page 73 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 IMPORTING
STRING = CLA
EXCEPTIONS
TOO_SMALL = 01.
Runtime Measure(in microsec): 67 Runtime Measure(in microsec): 3

Use the CONCATENATE / SPLIT statement instead of programming a string concatenation of your
own.

Moving with offset Use of the CONCATERNATE statement

" MOVE 'Jane' TO CMA. " MOVE 'Jane' TO CMA.
" MOVE 'Miller' TO CMB. " MOVE 'Miller' TO CMB.
" MOVE 'New York City' TO CMC. " MOVE 'New York City' TO CMC.

I1 = STRLEN( CMA ). I2 = STRLEN( CMB ). CONCATENATE

MOVE 'Mrs. ' TO CHA. 'Mrs.' CMA CMB 'from' CMC INTO CHA
MOVE CMA TO CHA+5. I1 = I1 + 6. SEPARATED BY SPACE.
MOVE CMB TO CHA+I1. I1 = I1 + I2 +
MOVE 'from ' TO CHA+I1. I1 = I1 + 5.
MOVE CMC TO CHA+I1.

"Mrs. Jane Miller from New York City" I "Mrs. Jane Miller from New York City" i
Use of SEARCH and MOVE with Offset Use of the SPLIT statement
"CMA contains '(410)-45174-66354312' and shall "CMA contains '(410)-45174-66354312' and shall
"be split into AREA_CODE, "be splitted into AREA_CODE,
" TEL_NO1, " TEL_NO1,
" TEL_NO2. " TEL_NO2.
SEARCH CMA FOR '-'.
MOVE CMA(SY-FDPOS) TO AREA_CODE.
I1 = SY-FDPOS + 2. SPLIT CMA AT '-' INTO AREA_CODE
SEARCH CMA FOR '-' STARTING AT I1. TEL_NO1
I1 = I1 - 1. TEL_NO2.
MOVE CMA+I1(SY-FDPOS) TO TEL_NO1.
I1 = I1 + SY-FDPOS + 1.
MOVE CMA+I1 TO TEL_NO2.
Runtime Measure(in microsec): 27 Runtime Measure(in microsec): 4

If you want to delete the leading spaces in a string, use the ABAP statement SHIFT...LEFT
DELETING LEADING.... Other constructions (with CN and SHIFT...BY SY-FDPOS PLACES, with
CONDENSE if possible, with CN and ASSIGN CLA+SY-FDPOS (LEN) ...) are not as fast. In any
case, avoid using SHIFT inside a WHILE-loop!

Shifting by SY-FDPOS places. Using SHIFT … LEFT DELETING

LEADING …
" CLA contains the string " CLA contains the string
"' "Editor line n'. "' "Editor line n'.
IF CLA CN SPACE. ENDIF.
SHIFT CLA BY SY-FDPOS PLACES LEFT. SHIFT CLA LEFT DELETING LEADING
SPACE.
Runtime Measure(in microsec): 5 Runtime Measure(in microsec): 3

Use the STRLEN( ) function to restrict the DO loop to the relevant part of the field, e.g. when
determining a check-sum.

Get a check-sum with field length Get a check-sum with strlen()

"DATA: BEGIN OF STR, LINE TYPE X, END "DATA: BEGIN OF STR, LINE TYPE X, END
"OF STR, CHECK_SUM TYPE I. "OF STR, CHECK_SUM TYPE I.
SAP ABAP Developer Handbook Page 74 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 "MOVE 'KALEBVPQDSCFG' TO CLA. "MOVE 'KALEBVPQDSCFG' TO CLA.

I1 = STRLEN( CLA ).
DO 64 TIMES VARYING STR FROM CLA DO I1 TIMES VARYING STR FROM CLA
NEXT CLA+1. NEXT CLA+1.
CHECK STR NE SPACE. CHECK STR NE SPACE.
ADD STR-LINE TO CHECK_SUM. ADD STR-LINE TO CHECK_SUM.
ENDDO. ENDDO.

Use "CLEAR f WITH val" whenever you want to initialize a field with a value different from the field's
type-specific initial value.

Initializing with CLEAR/TRANSLATE Initializing with CLEAR WITH val

* STRING is a 255 byte character field * STRING is a 255 byte character field
CLEAR STRING. CLEAR STRING WITH '*'.
TRANSLATE STRING USING ' *'.
Runtime Measure(in microsec): 11 Runtime Measure(in microsec): 1

6.8 Interface Standards

SAP recommends using global standards i.e Web Services rather than SAP specific interface objects
like IDOC’s and BAPI’s. The decision can be made based on the Sender/Receiver system capabilities,
development time and scope.

6.8.1 Web Services

Web services represent a communications strategy to be used within SAP Net Weaver as well as a
strategy to or from an external source. This integration technology is based on open standards. With it,
you can include existing functions – irrespective of whether they are implemented. You can also
provide new functions as a service and then access them from other systems.
For more information, check out the following link.
http://help.sap.com/saphelp_nw70/helpdata/EN/9b/dad1ae3908ee44a5caf57e10918be9/frameset.htm

6.8.2 BAPI’s

It is difficult to formalize the contents and functional scope of a BAPI. Every BAPI has a different
functional content, even those that perform similar functions, for example, the standardized BAPIs. The
differences are mainly due to the different characteristics of SAP business object types and their
contents.

Minimize interface complexity. Supply the BAPI with the minimum of data and group the data from a
business perspective. Structure your BAPI in the most efficient way. BAPIs must not invoke COMMIT
WORK commands. In the case of exceptions: If the BAPI contains a COMMIT WORK command; this
must be documented.

BAPIs must not contain the following commands:

 CALL TRANSACTION
 SUBMIT REPORT
 SUBMIT REPORT AND RETURN

INCLUDE structures must not be used in BAPI structures. Database changes can only be made through
updates. The global memory must not be used to transfer values. Due to transparency it is strongly
recommended not to use Set and Get. If required every BAPI must be able to carry out its own
SAP ABAP Developer Handbook Page 75 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
authorization checks. Values relevant for Customizing are not allowed to be changed. Language-
dependent values cannot be used as interface parameters.

BAPIs must not produce any screen output. This means that lists, queries and dialog boxes must not be
returned to the calling program. This is true for the BAPI itself and for any function module that may be
indirectly called by the BAPI.

BAPIs must not cause program terminations, they can only return a message (type A: termination
message) in the return parameter. Messages of type E (error) and A (termination) cannot be output in
the program.

Standardized parameters must be implemented consistently. Each BAPI must have a return parameter
for returning messages to the calling application. All quantity and amount fields must be assigned
quantity unit fields. All currency amount fields must be assigned currency IDs. All key fields in
GetDetail() and GetList() BAPIs must be displayed as text fields. Whenever possible, F4 input help for
fields in BAPI parameters must be made available

Only the internal data format can be used in BAPIs

Except for:

 Currency amount fields

 Quantity fields
 ISO codes
 Fields that have an internal key
 Specific fields in address structures

You must always use a period for the decimal point. Currency amounts with decimal points must be
formatted with a decimal point in the interface. For example, the value "10.12" must be formatted as
"10.12" and not as "1012".

The following conventions apply to BAPI methods:

 If the BAPI to be implemented is a standardized BAPI, use the generic names, for example,
GetList, GetDetail. You should particularly note the difference between reading and writing
methods and between simple and multiple methods.
 The individual components of a BAPI name are separated by the use of upper and lower case.
Example: GetList
 Underscores ("_") are not allowed in BAPI names.
 Each BAPI has a return parameter that is either an export parameter or an export table.
 Customers can enhance BAPIs, each BAPI must have an ExtensionIn and an ExtensionOut
parameter.

The following conventions apply to BAPI parameters:

 Obligatory parameters should be checked to see if they can become optional in the future. This
is important to avoid possible incompatible changes to the interface and to guarantee the
stability of the interface.
 If standardized parameters are used, you have to use the names specified for standardized
parameters.
 BAPI parameter names should be as meaningful as possible.
 The components of a parameter name in the BOR are separated by upper and lower case letters
to make them easier to read. Example : FlightList.
 Values that belong to each other semantically should be grouped together in one structured
parameter, instead of using several scalar parameters.
SAP ABAP Developer Handbook Page 76 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
  For ISO-relevant fields (country, language, unit of measure, currency), additional fields for
ISO codes are provided.
 Unit of measure fields must accompany all quantity fields and currency identifiers must
accompany currency amount fields

6.8.3 IDOC’s

Below are some of the design guidelines and formatting rules for creating new segments and IDOC
types,
 Do not re-invent the wheel. Before you create a new segment, check whether your
requirements can be met by an existing segment.
 Group your data in a meaningful manner. Business data is contained in segment fields. Data
which belongs together from a logical point of view should be combined to form a segment.
Segments which belong together from a logical point of view should be combined to form a
segment group. For example, the materials in a purchase order could be contained in one
segment. Together with other segments (information about the partner, taxes and terms of
payment), this segment can then form part of the "Items" segment group.
 Create universal segments. You can use segments which you have already created in other
IDoc types. Check whether a segment can be used for different messages. An example of a
universal segment is one which contains general address data.
 Create clearly arranged segments and segment groups. Position the required fields as close as
possible to the start of the segment. Two segments which always occur together should be
combined in one segment. Consider whether the use of qualifiers can be avoided. Qualifiers
indicate how a segment is used and are difficult to document and interpret. Qualifiers are not
usually defined on a cross-application basis, with the result that these segments are not
universal.
 Don’t waste space. The maximum length of all the fields in a segment is 1000 characters. The
larger the segment, the better the ratio of useful data to administration data. A certain amount
of space should be reserved in segments to allow for additional fields in the future.
 Document your segments. Use the documentation options provided by the segment editor. You
can store an additional data element for each field to provide information about how the field
is used in the application. You can also document a segment to explain the attributes and
structure of the entire segment. When documenting segments, remember that the segment
fields are used in both inbound and outbound processing.
 Remember that conversion to EDI standards may be necessary.
 The segment fields may only contain alphanumeric data. You can make sure that this is the
case by using data elements which contain characters in the segment fields.
 No distinction is made between upper case and lower case letters.
 The fields are maintained in such a way that the values are left-justified.
 The standard date representation (without qualifiers) is YYYYMMDD. February 28, 1996 is
therefore represented as 19960228.
 The standard time representation (without qualifiers) is HHMMSS. 8.35pm is therefore
represented as 203500.
 Values with a fixed decimal point are represented with a decimal point only - there is no
thousand delimiters. Negative values are indicated by a minus sign after the value. The number
-2,097,152.64 is represented as 2097152.64-.
 Floating point numbers are represented with a decimal point - there is no thousand delimiters.
Negative values are indicated via a minus sign after the value and the exponent is always
specified. The number -23.4 is represented as -2.34E+01.

The following rules may be useful if your IDocs are to be converted to other EDI standards (EDIFACT,
ANSI X12):

 If possible, segment fields in the IDoc should be represented directly by EDI data elements.
Avoid splitting or combining fields or other changes which could lead to problems with
automatic conversion.
SAP ABAP Developer Handbook Page 77 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
  The field length should be equal to the maximum length of the SAP application or relevant
EDI standard (depending on which is longer), so that all the existing information can always
be transferred.
 The required segment fields in the EDI standard must be present in the IDoc segment, to
ensure that the IDocs can be converted correctly.

6.8.4 Process Integration (PI)

6.9 Enhancements & StandardsModifications

Adaptations to SAP standard functionality are an important concept to understand. Hence, this sections
starts with an introduction to some basic terminology.

Table 1: SAP Adaption terminology

Concept Definition
Standard Functionality delivered by SAP is referred to as “Standard”. It is also referred to as
“Core”. The best practice principle is that standard functionality is not to be modified.
The disadvantages:
 Modified objects (e.g. reports) are not supported by SAP.
 When OSS notes, support packages, enhancement packs, or release upgrades
are applied the modified objects must be evaluated with (new) standard
versions of these objects. This can be a time consuming and therefore
expensive work.
Customization The concept of Customization means the definition of system behavior in response to
a customer’s requirement without the need for coding. Customization is achieved
through a set of system configurations.
Custom The concept of Custom Development means the construction of a solution from
Development scratch or the enhancement to the Standard. Custom Development becomes
applicable when Customization is not able to go far enough in addressing a
customer’s specific needs (or even an Industry’s specific needs).
Modification A Modification is a custom development to adapt a Standard development object that
constitutes a repair. Modification Assistant is an aid recommended by SAP to be used
to support the Modification process.
Enhancement An Enhancement is a custom development to adapt a Standard development object
without the need for a Modification. The advert of the new Enhancement concept
(Enhancement Framework) reduces the scope for Modifications.

The following guidelines should be adhered to:

 Stay near to Standard as possible.

 Avoid Modifications. Investigate Enhancement options instead because the total costs of
ownership are lower. When an Enhancement option is not feasible then assess whether the
repository object(s) in question can be copied into a customer name space and the new version
modified to satisfy the business requirement.
 Modifications to Basis objects and the deletion or renaming of standard objects is not
permitted.
 Enhancements and Modifications must be documented adequately (inline comments, technical
documentation etc).

During the design phase, the enhancements that are needed are going to be decided, at the least at a
higher level. During the development of code phase, developer finds out some more areas where the

SAP ABAP Developer Handbook Page 78 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
enhancements are needed. These have to be discussed in detail with the Technical Lead/Architect
before the enhancements begin.

The enhancement options that exist in the standard must be checked first before a formal proposal for
modification is requested. The enhancement decision can be made based on the following order,:

The Enhancement concept provides a Fframework to provides a technology for enhanceding core
source code units without modifying Modificationthem. The basic mechanism is to offer the so-called
enhancement options in development objects. These enhancement options function like “hooks” where
you can attach the enhancements.

There are different kinds of technologies that provide enhancement Enhancement options:
 Source code enhancements – enhancement points are positions in the source code where you
can attach source code plug-ins which enhance the source code at these positions. While a
source code plug-in at an enhancement point is processed in addition to the original code, the
code of an enhancement section is substituted by the respective source code plug-in. Program-
bound enhancement implementations in a multiple-use include can only be displayed when the
related main programs are generated. The programs, function groups, classes, and so on can be
generated within the respective editors. Alternatively, transaction SGEN can be used to
perform a mass generation in a system.
 Function group enhancements – you can enhance the interface of a function module by
additional parameters using function group enhancements.
 Class enhancements – you can add additional methods, optional parameters, pre- and post-
methods to existing methods.
 BAdIs – object-oriented enhancement options. The BAdI defines an interface that can be
implemented by classes that are transport objects of their own. The new BAdI is fully
integrated into the Enhancement Framework. Within the Enhancement Framework, a BAdI is
an enhancement option or an anchor point for an object plug-in.
 Web Dynpro Enhancements
 Enhancements in the Switch Framework

If you are developing an application which can be used more frequently and by used large number of
users, add enhancement into your custom built program.
It helps user to add something at later stage without modifying the custom code.
There are two ways to implement the same,

SAP ABAP Developer Handbook Page 79 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
  Explicit enhancement options of the enhancement point type allow you to insert source code
plug-ins. These are additional code lines that, if they exist, are executed there additionally.
Explicit enhancement options of the type Enhancement Section behave in the same way – the
only difference being that the source code plug-in replaces the section in the original code.
 Business Add-Ins (BAdIs) are “hangers” for object plug-ins. A BAdI definition comprises an
interface with methods. BAdIs are enhanced by classes that implement the BAdI interface. If
you instantiate a BAdI and then call its methods, you can, among other things, specify which
method implementations are to be carried out on the basis of filter values. In other words, a
BAdI method call is a dynamic method call with a specified interface, for which it is not
determined until runtime which method implementations are to take place.

For more information check out the following link:

http://help.sap.com/saphelp_nwpi71/helpdata/en/35/f9934257a5c86ae10000000a155106/frameset.htm

6.9.1 Enhancement Spots

Enhancement spots are used to manage explicit enhancement options. Enhancement spots carry
information about the positions at which enhancement options were created. The enhancement spot is a
similar concept to a ‘SAP Enhancement’ and the enhancement options corresponds to a user exit within
a ‘SAP Enhancement’.

You create an explicit enhancement option when processing a Repository object with the relevant tool
by creating an enhancement spot element definition at a point where this is possible. This enhancement
option can then be called at different points using enhancement spot element calls. The enhancement
spot element definition and the corresponding enhancement spot element calls make up the definition of
an enhancement option. For example, when editing an ABAP program with the ABAP Editor, you can
define explicit enhancement options in the form of the ENHANCEMENT-POINT statement, which
also represents the element definition and element call.
Where enhancement spots exist in SAP these should be used to provide custom modifications.
Transaction SE18 can be used to view Enhancement Spots.

6.9.2 Enhancements to TablesDDIC objects

6.9.2.1 Tables & Structures
 SAP specifies whether or not a table or structure is allowed to be enhanced and the extent of
the enhancement. The setting of Enhancement Category attribute should be one that permits
the addition of customer fields. That is,-Enhancement Category should not be set to “Cannot
be enhanced”.

6.9.2.1.1 Append Structures

Standard tables may be enhanced using theThe Append technique permits the enhancement of a
transparent table or structure APPEND Structures. This allows you to enhance tables without making
any in a modification-free manners and it is not overwritten the next time the table object is transported
from the standard systemwhich is protected from SAP updates. An Append structure can only be
assigned to exactly one table or structure albeit a table or structure can have many Append statements.

 Append Structures follow the naming pattern as Z* or Y*. Underscores ‘_’ are not allowed in
the name at 2nd &3rd character.
 The fields in the append structure must also reside in the customer namespace. That is, - a field
name should begin with ZZ or YY.
 SAP may make available one or more pre-define append structures names available for use at
the time of creation. This structure can be added to the standard table as an appended structure.
 Customer Append structures are not permissible for Pool tables and Cluster tables.
SAP ABAP Developer Handbook Page 80 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
6.9.2.1.2 Customer/Customizing Include

Some SAP standard tables contain a reserved part for enhancements occupied by a special structure
called a Customer or Customizing Include. These special structures can be identified in the DDIC with
the prefix “CI_”. Like the Append technique a customer’s changes are protected from SAP updates.

 The fields in the Customer/Customizing Include must reside in the customer namespace. That
is, - a field name should begin with ZZ or YY.
 A Customer/Customizing Include may be reused in multiple tables or structures. If APPEND
structure is already added, we may add a customer include. There are customer includes that
include structures with the prefix “CI_”. These enhancements cannot be lost when upgrading.
If a table or structure of the standard system is enhanced with customer fields using a
customizing include, these customer fields are automatically inserted in the new delivered
table or structure definition during an upgrade.


The terms “Customer Include” and “Customizing Include” are used synonymously.

6.9.2.1.3 Views

Note:
1. An APPEND structure can only ever be added to one table, because it contains a reference to this
table.
2. APPEND structures cannot be added to pool tables or cluster tables, such as table BSEG.
3. If there are views (projection views, help views, and maintenance views) of tables that have been
enhanced using APPENDs or INCLUDEs, these views usually need to be enhanced accordingly and
regenerated if you want the new fields to appear in them.
4. When tables are enhanced using APPENDs or INCLUDEs the number of fields in the corresponding
physical database tables increases. There is usually an upper limit to the number of fields that are
permitted. Be aware of that limit.

6.9.2.1.4 Domain Fixed Values

Additional values can be added to domains by creating a “Fixed Value Append”.

6.9.3 Modification Assistant

The Modification Assistant is a tool that makes it easier to reconcile Modified objects with their
respected upgrade versions. The Modification Assistant is integrated into the ABAP Development
Workbench and logs all changes that are made to standard objects.

The use of Modification Assistant is compulsory within EDF Energy. An exception is this rule is when
a change is made to a custom object that is foreign to that system. This change will be recorded in a
change request with a task typed as a repair. EDF Energy operates two transport routes (one for
Production and another for Projects) custom development objects imported from the Projects route into
the Production route will be identified as copies because they are not original to the Production route.

6.9.4 Modifying SAP database Tables:

Direct updates to SAP database tables using INSERT, UPDATE, MODIFY & DELETE are to be
avoided through the use of standard/custom built Function Modules or BAPIs.
SAP ABAP Developer Handbook Page 81 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
There are three steps to modify SAP standard tables:
 Find a standard way of modifying/inserting the data (BAPI, class method, regular function
modules with all the application logic/validations, standard SAP programs, Idocs, etc).
 If no standard mechanism found, then BDC.
 In case of custom table, create custom Function module which contains Lock Objects while
updating table.

7 SAP NOTES

All SAP notes should be done using transaction code SNOTE.

8 QUALITY ASSURANCE

This section focuses on aspects of quality assurance. Development efforts that include quality
assurance activities produce better deliverables than those that do not. Two techniques used
to improve quality are unit testing and technical reviews.

8.1 Unit Test

The scope of the testing covered here is for Unit test only. In cases where the modifications to standard
code happen, the testing is more of scenario/integration testing. But in RICEFW developments, where
there are multiple new technical objects involved, developers are expected to thoroughly test the
individual objects (new programs, function modules, tables with table maintenance dialogs, new
classes/methods etc.,) before the Integration/Product testing takes place.

A good Unit Test plan is always helpful in putting together the conditions and various inputs that the
individual objects have to be tested with. The following template can be used to write this test plan.
During the actual testing, it serves as a check list. It is also important to collect the results in the form of
Remarks/Comments in this document to ensure completeness.

The template for creating a unit test plan for each object to be tested is linked below.

8.2 Code Review

Pay attention to the following points during Code Review,

 Select where the most problems/errors occur.

 Select where we did make the most changes.
 Select areas which are completely new.
 Select critical areas.
 Select where do errors have a particularly negative effect. (for example, during posting)

SAP ABAP Developer Handbook Page 82 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
  Select which program parts are used particularly often.
 Integrate external developers if necessary.
You might also consider the following elements when selecting code to be checked:
 Areas that are difficult technologically: for example, performance/database access (SQL
Commands)
 New programming technologies and technological 'new ground' i.e Web Services,
Enhancement Framework
 Difficult task functions i.e interfaces between applications, data exchange
 General potential for improvement i.e Enhancement to core objects

Find attached the Code Review checklist and Design review checklist which should be completed by
the Reviewer during the Code Review Phase.

9 SAP NOTES

All SAP notes should be done using transaction code SNOTE.

10 APPENDIX

10.1 New Standards

10.1.1 Shared Objects
There is a better solution to the problem of how to make the same data available to multiple internal
sessions within the SAP NW Application Server efficiently: shared objects. This enables you to load
the data directly from a data source – for example, the database or RFC – into the shared objects
memory and aggregate it there at a central location. The data can then be used by different users
without them first having to load and aggregate it or copy it from the cross-transaction application
buffer of the shared memory into their internal sessions.
For more information check out the following link:
http://help.sap.com/saphelp_nwpi71/helpdata/en/14/dafc3e9d3b6927e10000000a114084/frameset.htm

10.1.2 Exception Handling

ABAP features a class-based exception concept. It is similar to the corresponding concept in Java, but
offers the user more flexibility in a number of aspects. When you write new code, you should only use
the new class-based exceptions for error handling.

SAP ABAP Developer Handbook Page 83 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
For more information check out the following link:
http://help.sap.com/saphelp_nwpi71/helpdata/en/cf/f2bbc8142c11d3b93a0000e8353423/frameset.htm

10.1.3 Switch Framework

With the Switch Framework, you can control the visibility of Repository objects. Among other things,
this enables you to have all SAP industry solutions in one system and only activate the desired
solutions. The fact that the enhancement implementations of the Enhancement Framework can be
switched is an important aspect of the Switch Framework. Therefore, the Enhancement Framework and
the Switch Framework are closely coordinated and complement one another in their functions.
For more information check out the following link:
http://help.sap.com/saphelp_nwpi71/helpdata/en/83/d2934258a5ca6ae10000000a155106/frameset.htm

10.1.4 New BADI’s

Unlike source code enhancements, in which user-defined code is inserted, BAdIs enable enhancements
for which the developer of the code unit to be enhanced defines an enhancement option, but also
specifies the interface for this enhancement. Developers thus have more control over enhancements.
For this reason, BAdIs are a better restructured enhancement option.
For more information check out the following link:
http://help.sap.com/saphelp_nwpi71/helpdata/en/fc/7e94422760c46ae10000000a155106/frameset.htm

10.1.5 Developing Persistence

For transactions, lock management, and authorization checks, the SAP NW Application Server has
separate solutions, since the relevant services of the database do not meet flexibility requirements.
For more information check out the following link:
http://help.sap.com/saphelp_nwpi71/helpdata/en/e4/2adbce449911d1949c0000e8353423/frameset.htm

10.2 Tips and Tricks

This section contains general hints.
Transaction / Report Description

SE83 Re-usable library

ABAPDOCU Example Library
SLIN Enhanced syntax check
DWDM Demo Examples
ABAPHELP Keyword Documentation
SE30 and “Tips&Tricks” Performance Tips
Report - SHOWICON ICON List
Report - SHOWCOLO Colors List
Report – BC* Examples

10.3 Useful transactions

SAP ABAP Developer Handbook Page 84 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
This section contains general useful transactions.
Transaction Description

SM12 Lock Entries

SM14 Update Program Administration
SE10 Transport Organizer
SE84 Information System
SHMA Shared Objects Area Administration
SHMM Shared Objects Monitor
SLG1 Application Log
SE54 Table maintenance
SE18 BADI Definition
SE19 Business Add-Ins: Implementations
SE20 Enhancements
WE02 Display IDOC
WE20 Partner Profiles
BD87 IDOC Status Monitor
BAPI BAPI Explorer
SFP Interactive Forms

10.4 Useful Links

This section contains general useful links.
Description Link

ABAP http://help.sap.com/saphelp_nwpi71/helpdata/en/
43/55509bf8a75f6be10000000a1553f6/frameset.htm
Function Library http://help.sap.com/saphelp_nwpi71/helpdata/en/2a/
f9ff44493111d182b70000e829fbfe/frameset.htm
SDN - ABAP https://www.sdn.sap.com/irj/sdn/abap

SDN - Web Services https://www.sdn.sap.com/irj/sdn/webservices?rid=/

webcontent/uuid/83b7ec4d-0a01-0010-03a9-e5a3b42522b8

10.5 Management of Interface Files

10.5.1 Purpose
The aim of this appendix is to provide technical design guidance to developers in the management of
interface files and scheduled background reports in their custom developments.

The objective is to ensure that a consistent approach is adopted across the Orchard Programme which is
robust, flexible and consistent across all Orchard SAP systems and environments.

SAP ABAP Developer Handbook Page 85 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
10.5.2 Audience
 Functional Consultants
 Technical Designers

10.5.3 Summary
 Interface files will be delivered to and retrieved from a consistent location on all SAP systems
 Logical file names / file paths will be used within custom developments rather than hard
coding or the use of input parameters.
 Mapping of logical file names / file paths to physical file names / file paths will be done using
the SAP Standard Transaction “FILE”.
 Manual retrieval of Interface Files or Background Scheduled Reports will use a standard
approach.

10.5.4 Technical Design Guidance

This guidance applies only to Files which are used to pass data to and from the following SAP
Applications:

In this context an Interface File is either:

 a set of related records (either written or electronic) kept together which is used to
pass data between SAP applications or between a SAP application and a non-SAP
application or another party. In the latter case the file may be sent directly or as an
email attachment
 the output from a report (usually in csv format) which has been scheduled as a
background report to be retrieved at a later time.

It does not apply where idocs or ALE are used as the means of passing data

Note: Although specifically intended for SAP systems the same physical directories could be used
on non SAP systems if required.

10.5.5 Interface File Location

Interface files will be delivered to or retrieved from a common directory structure on each SAP instance
which will fully visible to all servers (application and database) supporting that instance.

The directory structures will have the following physical location formats:

Inbound files: /interfaces/<SYSID>/<INTERFACE_NAME>/inbound

Outbound files: /interfaces/<SYSID>/<INTERFACE_NAME>/outbound

Where:
/interfaces/ is a mounted file system on the appropriate NFS server
(Development, Test, Production).
<SYSID> is the SAP system identifier e.g. SD1 for the Retail IS-U
Development system
<INTERFACE_NAME> is the name of the interface e.g. “thamescard”

10.5.6 Logical Location

The root of the above physical locations will be mapped to a logical location using the standard SAP
transaction “FILE”. The root excludes sub-directories below the <INTERFACE_NAME> level i.e. the
inbound and outbound sub-directories

For example the following screen shot (from EDF Energy Corporate SAP system) shows the mapping
of the Logical File Name “Z_BACS” to the physical location
“/interfaces/<SYSID>/bacs/”
SAP ABAP Developer Handbook Page 86 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
Custom developments must not contain hardcoded physical locations, but must use Logical Names as
described in the next section.

Note: The FILE transaction can be used to map a logical name to a fully qualified physical file name
or to all or part of the physical path as proposed in this document.

10.5.7 Retrieving physical name within custom developments

To retrieve the physical location developers should use the standard SAP Function Module
“FILE_GET_NAME” knowing the required logical file name. In its simplest form it has the following
parameters:

CALL FUNCTION 'FILE_GET_NAME'

EXPORTING
client = sy-mandt
logical_filename = l_fname
operating_system = sy-opsys
IMPORTING
file_name = p_fname
EXCEPTIONS
file_not_found = 1
OTHERS = 2.

Where “l_fname” is the logical file location, and

“p_fname” is the return physical file location

Using the previous example if l_fname = “Z_BACS” the function module would return
“/interfaces/SD1/bacs/” in the SD1 system.

For inbound files “inbound/<FILE_NAME>” would have to be appended to the returned physical
location in order to generate the fully qualified filename for the required inbound file. Similarly for
outbound files “outbound/<FILE_NAME>” would have to be appended to the returned physical
location in order generate the fully qualified filename for the required outbound file.

Note: <FILE_NAME> should normally follow the convention specified in section 3.6.1 of the
Orchard SAP ABAP Developer Handbook.

Note: Where a custom development is used to process only a single file type then the appropriate
Logical File Name should be hardcoded into the development as a parameter (so that it can
easily be amended if required)

If a custom development can be used to process more than one file type then it is suggested
that the Logical File Name be included as an input parameter so that for a particular variant the
program will process the appropriate files.

SAP ABAP Developer Handbook Page 87 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
10.5.8 Further processing for local audit
When an inbound file has been successfully processed it should be moved from the
“/interfaces/<SYSID>/<INTERFACE_NAME>/inbound/” directory to a processed sub-directory -
“/interfaces/<SYSID>/<INTERFACE_NAME>/inbound/processed”.

If an inbound file has not been processed successfully it may be moved from the
“/interfaces/<SYSID>/<INTERFACE_NAME>/inbound/” directory to an error sub-directory -
“/interfaces/<SYSID>/<INTERFACE_NAME>/inbound/error” - depending on the functional
requirements for error processing.

Note: A UNIX script will be run on a regular basis to deleted old files form the
/interfaces/<SYSID>/<INTERFACE_NAME>/inbound/processed directories as part of routine system
housekeeping.

10.5.9 Special requirements for manually downloadable outbound files

Where a report needs to be downloaded manually, e.g. a background scheduled report, then the
following approach should be adopted.

Step 1. On the report selection screen, if a file download option is selected, the user should be
asked to provide a unique identifier which will be used as part of the file name e.g.
“MPAN20080106”
Step 2. The users id “SY_USERID” is used as a prefix to the identifier in step 1 to create the
full filename. Thus if the logged on user’s ID is “white1p” then the created file name
is “white1p_MPAN20080106.csv”
Step 3. The physical file path is obtained as described earlier in this document using the
Logical File Name “Z_MANUAL_DOWNLOAD”. E.g. in system SD1 the return
physical file path might be “/interfaces/SD1/manualdownloads/”.
Step 4. The outbound file would be created with the name from step 2 in the physical
directory from step 3. I.e.
“/interfaces/SD1/manualdownloads/ white1p_MPAN20080106.csv”

To retrieve the file manually the user would be allowed to run transaction Z_REPORT_DOWNLOAD
which would run a custom program1 which would allow the user to browse the physical directory
corresponding to the Logical File Name “Z_MANUAL_DOWNLOAD” and a select file beginning
with their own user Id (SY-USERID). The selected file will then be downloaded to the file on their PC
the user has specified in the download program selection screen

For manual file downloads other than reports then a refinement of this approach may be adopted.

10.6 Send emails from SAP - function module

This function module should be used where a program needs to send emails e.g. to advise of errors or
send a report. Function Module ZEDF_SEND_MAIL
 Import Parameters
o SUBJECT – this line contains the text that is displayed in the SUBJECT line of an
email.
o RECIPIENTS – This is the table that holds the list of recipients that the email is to be
sent to. This table has 2 columns PROGRAMM and EMAIL.
 PROGRAMM is the key to the table and usually will hold the name of the
program

1
possibly based on existing EDF Energy program ZFILETRANSFER
SAP ABAP Developer Handbook Page 88 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
  EMAIL is the email address that you wish to send this report to
o RECIPIENT_KEY. This is the name of the PROGRAMM that you want to get the
recipient list for.
o DOC_TYPE. This is the type of document that you are sending. This is optional
 INT Text
 XLS Excel format. NB you will need to add Tab delimiters ‘09’ and for
Carriage return ‘OD’.
 DOC MS Word document
 Tables
o MAIN_TEXT – This is a table that has a record length of up to 255 characters length.
The data stored in this table will be placed in the main body of the email.
o ATTACHMENT_DATA – this is a table that has a record length of up to 255
characters length. Any data that is held in this table will be sent to email as a Text
File. Any data written into this file will need to be formatted.
 Exceptions
o TOO_MANY_RECEIVERS
o DOCUMENT_NOT_SENT
o NO_RECIPIENTS_FOUND
 Coding Logic
o Create the subject line
 The OBJ_Name field is defaulted to EMAIL
 The Obj_DESCR is filled with the data held in the subject line
o Create the Main text – this is populated from the contents of Table MAIN_TEXT.
o Create the Attachment – this is populated from the contents of table
ATTACHMENT_DATA
o Build the Recipient list
 Check to see if the table passed in the field RECIPIENTS exists in DD0L. If
it doesn’t, output an error message to state that no recipients have been
found.
 Using RECIPIENT_KEY read that table held in RECIPIENTS and extract
the Recipients email addresses. IF there are no recipient email addresses
output an error message to state that no recipients have been found.
o Pass the parameters to Function Module SO_NEW_DOCUMENT_ATT_SEND_API1
 If the return code doesn’t equal 0. Output an error message stating that the
Document has not been sent. (This could be due to the fact that the RFC
connection for Outlook has not been configured)

Example Table Layout for holding Email Addresses

SAP ABAP Developer Handbook Page 89 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
Example table contents:

10.7 Viewing and Maintaining Tables

Within EDF Energy Corporate SAP two custom developments are available to provide users with
restricted access to view tables or to maintain tables. This process ensures that the security and audit
requirements for table maintenance access are fully complied with.

10.7.1 Viewing Tables

Custom program ZSE16_MM_TABLES can be called by a number of different transactions. Each
transaction allows viewing of those tables which are linked to that transaction in associated table
“zse16_mm_tables”. No other tables can be viewed using that transaction.

Program screen shot:

SAP ABAP Developer Handbook Page 90 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
Table screen shot:

SAP ABAP Developer Handbook Page 91 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
Thus transaction ZSE16_AA will only allow table ANLA to be viewed, transaction ZSE16_MM will
allow tables ADRC, AUFM etc. to be viewed.

10.7.2 Maintaining Tables

Custom program ZAPMSVMA2 can be called by a number of different transactions. Each transaction
allows maintenance of those tables which are linked to that transaction in associated table
“ifpcusttables”. No other tables can be maintained using that transaction. An SM31 maintenance
session must be created in the data dictionary for each table which is to be maintainable.

Program screen shot:

Table screen shot:

SAP ABAP Developer Handbook Page 92 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
Thus transaction ZIMTABLES will only allow tables ZIIM001/002/003/004/005 to be maintained,
transaction ZWMTABLES will allow tables /SUP/MB1A and ZSDSH_TNT to be maintained.

10.8 Customer Name Ranges Summary

This section contains a summary of customer name ranges set by SAP. This table shows:
 Name lengths
 Standard naming conventions

Object Length Customer name range

Change document object 10 Y* Z*
Application log
Object 20 Y* Z*
Subobject 20 Y* Z*

Authorization/authorization profile 12 No “_” as the second character

Authorization object 10 Y* Z*
Authorization object class 4 Y* Z*
CATT procedure 30 Y* Z*
Code page 4 9000-9999

SAP ABAP Developer Handbook Page 93 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
 Code page segments 5 Y* Z* 9*
Context 20 Y* Z*
(Underscore allowed)
Data element only 30 Y* Z*
Dialog module 30 Y* Z* RP_9*
RH_INFOTYP_P9*
Documentation modules
General text (TX) 28 Y* Z*
Authorization object 10 Like object name
12 Like object name
Authorization profile
20 Y* Z*
Document: Description of a test run
20 Y* Z*
Main chapter of a structure (BOOK) 20 Y* Z*
Chapter of the Implementation Guide 20 Y* Z*
Chapter of a structure (CHAP) 26 Y* Z*
20 Y* Z*
Note on a chapter of a structure (NOTE)
28 Y* Z*
Release information
Text in dialog

Domain 30 Y* Z*
Printer macro - Y* Z* 9*
Dynpro 4 9000-9999
If the screen does not belong
to a module pool in the
customer name range.
Package 30 Y* Z*
Enhancement 8 Y* Z*
Enhancement project 8 *
Function Builder
Function module 30 Y_* Z_*
Function group 26 Y* Z*
26 XZ*
User exit function module
26 *
User exit function module (customer-
specific)

IDOC development
Segment Type 27 Z1*
Segment Name 30 Z2*
30 Y* Z*
Basis IDOC type
30 *
Enhancement type
30 *
Logical message

Info type number 4 9000-9999

SAP ABAP Developer Handbook Page 94 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011
 Interface 30 Y* Z*
(Underscore allowed)
Class 30 Y* Z*
(Underscore allowed)
Customer roles 30 Everything apart from "SAP_"
LIS
Event 2 Y* Z*
Unit 2 Y* Z*

Logical database 20 Y* Z*
Menu 20 Y* Z* +*
Module pool
Module pool for dialog 30 SAPDY* SAPDZ*
INCLUDES 30 DY* DZ*
30 SAPMY* SAPMZ*
Module pool for screens
30 MY* MZ*
INCLUDES
30 MP9*
Module pool for info types 30 MP9*
INCLUDES 30 SAPFY* SAPFZ*
Module pool for subroutines 30 FY* FZ*
30 SAPUY* SAPUZ*
INCLUDES
30 UY* UZ*
Module pool for update programs
INCLUDES

Message
Message ID 20 Y* Z*
Message number 3 900-999

Number range document object 10 Y* Z*

Maintenance and transport object 31 Y* Z*
Pool name/cluster name 10 Y* Z*
Relation ID/Cluster ID 2 See SAP Note 212246
Report 30 Y* Z*
Report category 8 0*-9*
Report variant
Transportable, global 14 X* CUS&*
Transportable, local 14 Y*
14 Z*
Not transportable

Report Writer
Report 8 1. First character not numeric
Report group 4 1. First character not numeric
3 1. First character not numeric
Library
7 1. First character not numeric
SAP ABAP Developer Handbook Page 95 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 Standard layout

R/3 analyzer: Identifier 20 Y* Z*

SAPscript
Form 16 Y* Z*
Standard text ID 4 Y* Z*
32 Y* Z*
Standard text name
8 Y* Z*
Style

Set 12 1. First character not numeric

SPA/GPA parameter 20 Y* Z*
Lock object 16 EY* EZ*
Spool
Format Type 16 Y* Z*
Font group 8 Y* Z*
8 Y* Z*
Device type
8 Y* Z*
Page Format
8 Y* Z*
System Bar Code

Standard task 8 9*
Standard role 8 9*
Search help 30 Y* Z*
SYSLOG message ID 2 Y* Z*
Table
Pooled tables and cluster tables 10 Y* Z* T9* P9* PA9* PB9*
PS9* PT9* HRT9* HRP9*
HRI9*
YY* ZZ* (in the append
Transparent tables 16 structure, if possible)
If included using the append
structure: YY* ZZ*
16
Table field

Transaction code 20 Y* Z* +*
Types in the ABAP Dictionary (Underscore allowed)
Data element 30 Y* Z*
Structure 30 Y* Z*
30 Y* Z*
Table type

EDM
Data model 10 Y* Z*
Entity 10 Y* Z*
View
Database view, projection view, 16 Y* Z*
maintenance view 16 H_Y* H_Z*
SAP ABAP Developer Handbook Page 96 of 97 Version: 0.1
Status: Draft
Confidential 20/01/2024 06 September 2011
 Help view

View cluster 16 Y* Z*
View maintenance data
View content - reserved in TRESC
Table contents - reserved in TRESC

Workflow object type 10 Y* Z*

SAP ABAP Developer Handbook Page 97 of 97 Version: 0.1

Status: Draft
Confidential 20/01/2024 06 September 2011