Shell Information Services

ABAP/4 Standard

ABAP/4
Programming
Standards

2.3

Authors : Fienke Huitema

Roy Faber
Revised by :

Eoin Cronan

Jan 2001

Status

First version : Internal Use Only

Open for Discussion

Distributed to :

Discussed with :

Approved by :

27-10-15

Employees of Argus Integrated Solutions

Page 1 of 44

Shell Information Services

ABAP/4 Standard

Version log
Version

Date

Name

Changes

0.1

04-1997

Fienke

Start

0.2

04-1997

Roy

Additions

0.3

23-04-1997

Tony

Few comments

0.4

26-04-1997

Fienke

Additions and merging

several versions

0.5

27-05-1997

Roy

version additions

0.61

11-05-1997

Argus

Comments, IT

1.0

13-06-1997

Fortis/Argus

First publishing

1.1

13-06-1997

Roy

Comments Argus/Fortis

- internal documentation
- versioning

2.0

27-10-00

Shell
Information
Services

Updating document to
4.6C

2.1

06-09-01

Eoin Cronan

Additional Naming
Conventions for ALE
and LSMW

2.4

29-01-2002

Suhaiman
Mohamad-Nawir

Naming Conventions for

Infotype enhancements

2.5

11/07/02

Jalal Ettaoussi

Convention for ABAP

objects modifications

2.6

22/07/02

Jalal Ettaoussi

Naming Conventions for

Report Category

27-10-15

Sent to several Belgian

collegues

Page 2 of 44

Shell Information Services

ABAP/4 Standard

Table of Contents
Version log...................................................................................................................................................1
Version log...................................................................................................................................................2
INTRODUCTION.........................................................................................................4
Document feedback.....................................................................................................................................4
PART I. THE HR NAMING CONVENTION.....................................................................5
Name ranges for Customer Developments.................................................................................................5
Program names...........................................................................................................................................5
Development Class.....................................................................................................................................9
Legacy System Migration Workbench (LSMW) Projects..........................................................................11
ALE Message Types and Segments...........................................................................................................12
Within your ABAP/4 source...................................................................................................................14
Variable Names and Internal Tables........................................................................................................14
PART II. HR GENERAL PROGRAMMING GUIDELINES....................................15
Declarative elements................................................................................................................................15
Event Elements.........................................................................................................................................15
Hard-coding..............................................................................................................................................15
Text elements.............................................................................................................................................16
Access to SAP Application Data:.............................................................................................................17
Modularization..........................................................................................................................................17
Security.....................................................................................................................................................18
Template....................................................................................................................................................18
Object Orientation....................................................................................................................................19
BAPI Programming...................................................................................................................................21
Creating a new BAPI................................................................................................................................21
Controls.....................................................................................................................................................22
Directives Lay-out of reports(print-out) and screens...............................................................................23
SECTION III DOCUMENTATION...............................................................................26
Program Readability.................................................................................................................................26
Support Documentation............................................................................................................................28
Online Documentation..............................................................................................................................28
APPENDIX I SAP DEFINITION OF CUSTOMER NAMING RANGE.................................29
Index customer naming range..................................................................................................................29
APPENDIX II T RANSPORT NAMING CONVENTION....................................................32
Transport Request Naming Standard.......................................................................................................32
APPENDIX III ABAP/4 PROGRAM CHECKLIST........................................................36
APPENDIX IV ABAP/4 PERFORMANCE....................................................................37
SAP Performance Examples.....................................................................................................................37
Internal Table............................................................................................................................................37
Database...................................................................................................................................................37
The amount of processes in the query needs to be kept to a minimum....................................................41
Unburden the SAP/3 database as much as possible................................................................................41
APPENDIX V EXAMPLE LAY-OUT OF AN ABAP/4 PROGRAM...................................43
APPENDIX VI ASAP DOCUMENTATION TEMPLATE ERROR! BOOKMARK NOT DEFINED.
APPENDIX VII USEFUL REPORTS/FUNCTIONS/TABLES...........................................47

27-10-15

Page 3 of 44

Shell Information Services

ABAP/4 Standard

Introduction
Based on the documents and knowledge shared between Shell and ARINSO, this document was
intended to set out a global ABAP/4 Standard. This means that programs in the SAP/3 systems
developed by ABAP/4 programmers should follow the conventions as described here.
The document is divided in three parts:

The HR Naming convention, giving strict rules for naming objects in the data dictionary and
the ABAP/4 programs, and

The HR General Programming Guidelines, delivering sensible guidelines, which are strongly
recommended but are not mandatory.

Documentation Standards, templates to aid in the functional and technical descriptions of

developments.

This document is not meant to be a learning course for programming in ABAP/4. However, it can
be of help to make more structured programs.

Document feedback
This document is always open for discussion. This means that the reader is encouraged to
evaluate the contents of this document and if changes are necessary, please feel free to contact
the author(s).
Eoin Cronan : eoin.e.cronan@si.shell.com

27-10-15

Page 4 of 44

Shell Information Services

ABAP/4 Standard

Part I. The HR Naming Convention

Name ranges for Customer Developments

Customers may only create objects in the SAP environment with names that are not within the
SAP name range. This ensures that customer objects are not overwritten during an upgrade. In
general, SAP has reserved the letters Y and Z as the first letters for names of customer objects.
We propose the prefix Y for Globally developed objects and programs. The prefix Z can be used
for local or country specific developments
Note : in Appendix I a more detailed list of allowed customer name ranges is provided.

Program names
All program names for applications in HR should follow the naming convention as shown below.
The program names take the form:
YGLHMMTTnnn
where :
Y__________

Customer prefix

Y : Globally developed products

Z : Local modifications (e.g. Reports)

_GL________

SAP Country ISO Code

___P______

SAP Module identification

____MM____

Submodule

______TT___

Program type

GL : Global
DE : Germany
NL: Netherlands
US: USA
H : Human resources Planning
P : Human resources Master Data
S : Basis
(F : Finance, etc)
PA : Personnel administration
PT: Time management
PY: Payroll
PE: Training & Events Management
RC: Recruitment
BN: Benefits
PF: Pension Fund
CM: Compensation Management
PD: Personal Development
OS: Organisational Plan
BC: Basis
ES: ESS
MA: Managers Desktop
SP: Shift Planning
EV: Time Evaluation
DM : Data Migration
PU : PU12 Interface
II : Interface in
IN : Include
IO : Interface out
IT : Internal interface
MP : Module pool
RD : Report for download
RR : Report
RU : Report for upload
AL: ALE user exits

________nnn

Sequential program number

27-10-15

Page 5 of 44

Shell Information Services

ABAP/4 Standard

Report category
In program attributes, the pushbutton 'HR Report Category' is set up when a logical database is
used.
To create the report category:
Go to IMG, Personnel Mgmt-->HRIS-->reporting-->Adjusting Standard Selection Screen-->Create
Report Categories.
Please note a new naming convention for report category:
9_______
_XX_____ is the specific number of country grouping (Field Molga ---> T500L-molga )
___XXXXX Sequential report category number start at 00001 to 99999
Different ABAP-source
Note: When copies of other (Standard SAP) sources form the basis of your source, the program
name of the original ABAP-source should be mentioned at the top of your ABAP-source.This
means that the naming convention as stated above will be used for the new program name.
Changing production code
When changing code that is further along the transport route, e.g. in Integration Testing in
Acceptance, then that code may have to be backed out to be fixed on development and retransported to acceptance. To minimise the work lost in this case, a slightly different naming
convention should be adopted. When editing an object that has already been transported, the
object should be copied and the developers initials should be appended at the end. Then when the
program is ready to be released it is renamed back to the original development name.
E.g. Report YGLPPA001 is in QA but needs updating in Development. Developer John Smith
makes a copy of YGLPPA001 to YGLPPA001_JS, makes the necessary changes and when ready
to release to acceptance, moved YGLPPA001_JS to YGLPPA001.

Infotypes
Enhancements to Infotypes.
Enhancements to PD Master Data are rare but when they happen the system requires that you
follow a naming convention in building up the maintenance and list screens.

Maintenance screen
List screen
Module Pool
Include Modules:
Data Definition
PBO Module
PAI Module
Subroutines
List Structure

: MPXXXX00-0200
: MPXXXX00-3000
: ZPXXXX00
: ZPXXXX10
: ZPXXXX20
: ZPXXXX30
: ZPXXXX40
: ZPLISXXXX

For other type of Infotypes the standard naming convention applies.

Creating new Infotyes.
When building tables and structures of infotypes the following naming conventions should be
used. There are differences in between several infotypes and it should be taken into account when
designing your infotype. The following most commonly used infotypes are used:-

27-10-15

Page 6 of 44

Shell Information Services

ABAP/4 Standard

When designing an infotype PA Master Data, the following elements are needed:
Table
: PA9999
Structure
: PS9999
Structure used in the ABAP/4 programs
: P9999
When designing an infotype Recruitment Master Data, the following elements are needed:
Table
: PB9999
Structure
: PS9999
Structure used in the ABAP/4 programs
: P9999
When designing an infotype PD Master Data, the following elements are needed:
Table
: HRP9999
Structure
: HRI9999
Structure used in the ABAP/4 programs
: P9999
Sub-structure
: HRPAD99
Sub-structure used in the ABAP/4 programs
: PAD99
Example :

Infotype Recruitment Master Data

Table
: PB9131
Structure
: PS9131
Program structure
: P9131

An infotype consists of several parts where for example the specific tables and structures are
called from. These parts are saved in separate modules and the convention used for these parts
are:-

27-10-15

Page 7 of 44

Shell Information Services

(Module Pool)

ABAP/4 Standard

: MPXXXXYY

MP______

Module Pool Infotype

MP : Module Pool

__X_____
___XXX__
______YY

Infotype number
Infotype number
Infotype part

9 : for Customization
Number of the infotype
00 : Main Module Pool
10 : all data-declarations in the PBO- and PAI-modules
20 : all PBO-modules
30 : all PAI-modules
40 : all Forms of the PBO-/PAI-modules

Interfaces (PU12) : YGLPIOXXXXE0

YGL---------

Interface

Global Interface
Local Interface, (with ISO code)

SAP Module
Interface Out
Interface
Program Type

P for Human Resources Master Data

ZDE-----------X-----------IO-----------XXXX------------E0
-----------L0

4 Alphanumeric digit Interface Name

E0 = Extraction Program
L0 = File Layout Program

Note: The associated includes names should end E1-9, and L1-9.

Convention for common Data Dictionary Objects

Object name

Layout

Meaning:

Domain

YGL-------

Prefix

---+++++++

Freely definable

YGL-------

Prefix

---+------

Application identification

----++++++

Freely definable

Y---

Prefix

-+--

Application identification

--++

Freely definable

YGL-------

Prefix

---+------

Application identification

----++++++

Freely definable

YGL-------

Prefix

---+------

Application identification

----V-----

Always 'V' for View

-----+++++

Freely definable

Y-------

Globally Transaction

Z-------_DE

Local Transaction, ISO

code at end

e.g. _DE for Germany

-+------

SAP Module

e.g. P for Human Resources, F finance

--++----

Submodule

e.g. PY for Payroll

----+---

Type

e.g. R for Report, I for Interface, D for

Dialog, S for ESS screens

-----+++

Sequence

Alphanumerics

Data Element

Matchcode object

Table

View

Transaction

Application identification for SAP-HR:

27-10-15

Bytes
3
<= 30

Description / Remarks
Domain name (up to 30 bytes)
SAP standard domains should be used
wherever possible
Data Element name (up to 30 bytes)

<= 30
Matchcode object (must be 4 bytes)

Table (up to 16 bytes)

<= 16
View (up to 16 bytes)

<=

H : Human resources Planning

Page 8 of 44

Shell Information Services

ABAP/4 Standard

P : Human resources Master Data

S : Basis
Examples:
YUSPPAYDATA

For a table used for a payroll application in USA

YGLHORGAN01

For a globally used data element for a PD application

Note : These conventions for the Data Dictionary form an applied supplement to the Index
customer naming range (see appendix I, page 15).

Development Class
Several development classes have been defined for the Galaxy Project to hold developments. All
ABAP development and Workbench objects should be assigned to these classes depending on the
nature/use of the developments.
The following convention should be adopted
Development

Global/Local

Developments in:

Class

Development

YDEVPA

Global

Personnel Administration

YDEVPT

Global

Time management

YDEVPY

Global

Payroll

YDEVPE

Global

Training & Events Management

YDEVRC

Global

Recruitment

YDEVBN

Global

Benefits

YDEVPF

Global

Pension Fund

YDEVCM

Global

Compensation Management

YDEVPD

Global

Personal Development

YDEVOS

Global

Organisational Plan

YDEVBC

Global

Basis

YDEVES

Global

Employee Self Service

YDEVMA

Global

Managers Desktop

YDEVSP

Global

Shift Planning

YDEVEV

Global

Time Evaluation

YDEVALE

Global

ALE

YDEVPU12

Global

PU12 Interfacing

YDEVWF

Global

Workflow

ZDEVPA_DE

Local

PA Developments for Germany

.
Note: Where developments are Stepping Stone specific, a local development class is created with
same name as the global development class, but with a Z replacing the Y and the ISO country
code at the end. E.g. PA developments for Germany, Global development class is YDEVPA, so
local development class is ZDEVPA_DE.

27-10-15

Page 9 of 44

Shell Information Services

ABAP/4 Standard

Legacy System Migration Workbench (LSMW) Projects

There will be a master LSMW project which will be imported at each Stepping Stone Project. As
you import the LSMW project, you must rename it to the following 1
Project:

Stepping Stone Project Name:(Country Code)

Subproject:

As Imported

Object:

As Imported

Note: Where a project Covers several different Countries the ISO country code should be included
in the Project Title.
Code

Project

Country

Galaxy

Galaxy

Global Project

ANDROM

Andromeda

ASEAN

BOOTES

Bootes

UK

CARINA

Carina

Brunei and Bangladesh

DELPH

Delphinus

USA

ERIDAN

Eridanus

Oceania

FORNAX

Fornax

Benelux

GRUS

Grus

Brazil

HYDRA

Hydra

DACH

INDUS

Indus

France

LACERT

Lacerta

Nigeria

MENSA

Mensa

Scandinavia

OCTANS

Octans

South America

PAVO

Pavo

Caribbean

RETIC

Reticulum

Southern Africa

SAGITTA

Sagitta

Canada

TUCANU

Tucana

NWE Africa

URSA

Ursa

East Mediteranan

VELA

Vela

Northern Asia

APUS

Apus

Condor

CASSIO

Cassiopeia

East Africa

EQUUL

Equuleus

Iberia

GEMINI

Gemini

PDO

HERCUL

Hercules

East Europe

Libra

M.E.S.A.

LIBRA
E.g.
Project:
1

ANDROM:MY

Otherwise it will overwrite the existing LSMW project.

27-10-15

Page 10 of 44

Shell Information Services

Subproject:

HIRE

Object:

DATA

ABAP/4 Standard

Initial Personnel hire data for Malaysia

E.g.
Project:

Bootes

Subproject:

HIRE

Object:

DATA

Initial Personnel hire data for UK.

ALE Message Types and Segments

The Customer ALE name range allows you to utilise both Y* and Z* ranges. Although the system
will still allow you to create Message types and IDOCS in the Y range, if you wish to use change
pointers for your IDOCs you will have to create your segment types in the Z range, as this is
explicitly checked for in the Change Pointer processing logic.

Object name

Layout

Meaning:

Message Type

YGL-------

Bytes

Description / Remarks

Prefix

Globally used Message Type

ZXX-------

Prefix

Locally used Message Type, where

XX is the ISO country code
e.g. ZMY_Finance Malaysia specific
finance message type

IDOC Type

---+++++++

Freely definable

YGL-------

Prefix

Globally used IDOC Type

ZXX-------

Prefix

Locally used IDOC, where

<= 30

Provide Info as to the use of the Message

Type

XX is the ISO country code

e.g. ZMY_Finance Malaysia specific
finance IDOC type

Segment

Customer Model

---+++++++

Freely definable

Z---------

Prefix

-+++++++++

Freely definable

YGL--------

Prefix

Global Distribution Model

ZXX--------

Prefix

Local Distribution Model

<= 30
1
<= 24

Provide Info as to the use of the IDOC

Type
Customer Name Range
Should indicate from which table, view or
data source the segment is populated

XX is the ISO country code e.g. DE

ALE Objects

27-10-15

---+------

Direction

----++++++

Freely definable

YGL--------

Prefix

(I)Inbound, (O) Outbound, (X) Bidirectional

Global ALE Object

Page 11 of 44

Shell Information Services

27-10-15

ABAP/4 Standard

ZXX--------

Prefix

---_------

Underscore

---_++++++

Freely definable

26

Local ALE Object

Descriptive Text

Page 12 of 44

Shell Information Services

ABAP/4 Standard

Within your ABAP/4 source.

Variable Names and Internal Tables
Variable names may be up to 30 character long. Apart from the special character ( ) + . , : , SAP
allows any characters including numbers. However, a name should not consist of numbers alone.
The first(two) character(s) of the variable name should be its type followed by an underscore. The
underscore will help to distinguish the variables from SAP data dictionary names. Do not use
hyphens (-) in variable names since they indicate field strings. Make the rest of the name as selfexplanatory as possible. The way the prefixes should be placed in this order:Prefix notation:
<Prefix>

<Fieldname>

Use the following prefixes:

<Prefix>

Description

Example

Global data fields,

W_NUMBER

Constants

C_TAXVALUE

SW

Switch, boolean. Define as "X" = true and " " = false.

SW_SECONDFIGURE

Ranges.

R_DAYS

Fields on the selection screen of a report. For

SELECT-OPTIONS and PARAMETERS.

S_PERNR

Local fields in a Form.

L_SIRNAME

Parameters of a Form (FORM A USING X_REPLY).

X_AMOUNT

ABAP Objects

O_USER

Defined Data Types

T_DATATYPE

Internal tables

I_T512W

<F_xxx>

Field Symbols

<F_symbol>

Parameters in a function-definition.

P_COUNTER_NUMBER

Modularization
Forms

Form name should be separated by underscore only (_). Discourage to use

Hyphen (-).

Includes
Modules

see Program naming convention

When a module pool program contains more than one screen (dynpro), the
name of the modules should contain the related screennumber. For example
S1000_CHECK_INPUT. If a module is used in more than one screen use
NNNN in place of the screen number. E.g. SNNNN_CHECK_INPUT

27-10-15

Page 13 of 44

Shell Information Services

ABAP/4 Standard

Part II. HR GENERAL PROGRAMMING GUIDELINES

Declarative elements
The following lists the declarative elements in the order they should appear in ABAP/4 reports,
immediately after the REPORT statement. At least one empty line should occur between each of
these elements. An element should only be coded if it is used in the ABAP/4 report. Every element
should have a new line. A description of the element must be added as comment. For long
programs the data declarations should be in an include.
The order is:
TYPES (preferably in an INCLUDE)
TABLES
INFOTYPES
CONSTANTS
DATA (internal tables)
DATA (variables and flags)
SELECTION-SCREEN, SELECT-OPTIONS, PARAMETERS
RANGES
FIELD-SYMBOLS

Event Elements
The following are common event elements coded in an ABAP/4 program. These should be coded
in the order below, in order to ease the location of the relevant event within the programming
code. Only those events that are used in the program should be present.
INITIALIZATION
AT SELECTION-SCREEN
LOAD-OF-PROGRAM
START-OF-SELECTION
GET
GET LATE
END-OF-SELECTION
AT LINE-SELECTION
AT PFn
AT USER-COMMAND
TOP-OF-PAGE
TOP-OF-PAGE DURING LINE-SELECTION
END-OF-PAGE

Hard-coding
Do not hardcode fixed texts, conditions etc. in the program. Use any of the following methods
where possible:
1.
2.
3.

pass values from SELECT-OPTIONS or PARAMETERS

pass values from text elements
read values from own defined tables

27-10-15

Page 14 of 44

Shell Information Services

ABAP/4 Standard

Text elements
The text-elements should be used so the program can display the texts in the reports in the
language the user specifies when logging on, if maintained in that language. Instead of using:
WRITE:/ Company,
Name.
or:
WRITE:/ TEXT001,
TEXT002.
you should use:
WRITE:/ Company(001),
Name(002).
The last method is preferred because if the text-element is not maintained in the logon language,
the original text will be displayed. Moreover, it is also more convenient reading the source code
this way.

Convention for ABAP source modifications

The idea is to put in bloc all modifications (Modif/Delet/Add) done by developers who not create
the object between to sentences to specify the start and the end of change.
UsercID,Sydatum,STARTOFmodif/Delet/AddN*,numberof(1,2,3...),
usefuldescription to start, and
UsercID,Sydatum,ENDOFmodif/Delet/AddN*,numberofmodif
(1,2,3...) to terminate.
So for example:
NLJET0,11/07/02StartofMODIFICATIONN*1:Deletethepopupwhen
skillpoolcatalogtransactionistriggered
*
*
*
*

Old Code...
Old Code...
Old Code...
Old Code...
New Code...
New Code...
New Code...
....
NLJET0,11/07/02EndofMODIFICATIONN*1.

27-10-15

Page 15 of 44

Shell Information Services

ABAP/4 Standard

Access to SAP Application Data:

For On-line Reports:
Use Logical Database PNP to access application data wherever possible. You need to activate this
database driver by maintaining the report attributes logical database PN and application P.
Benefits are:
Select statements are coded by the Logical Database program.
Authorization checks are performed.
Selection screen is provided.
The Logical Database is primarily used with on-line reports. They should not be used when a
selection screen is not desired. When you run your report, the logical database loads the
personnel data for each employee into the main memory and makes it available for processing.
The entire history of each infotype is loaded into the main memory, i.e. all infotype records
between the lowest and highest system date. When the next personnel number is selected, the
data of the previous personnel number is deleted.
When you specify 'infotypes' in your report, you must know the following:
These infotypes are read during creation of 'logical database'. If you specify infotypes with
subtypes and the user hasn't access to all subtypes of this infotype, the persons having these nonauthorised subtypes will not be taken into the report for authorization reasons.
E.g. infotype 0014: if a user with only limited access on some wage types in infotype 0014
executes a program specifying 'infotype : 0014', authorization problems will occur. You best use in
these cases read_infotype.
The selection screen allows the user, who runs the report to specify the data selection, matchcode
selection and sorting condition. The sort function key can be used to sort employees according to
name or criteria of organization assignment. You could change the standard selection screen by
changing the reporting class.

Modularization
Forms
Forms should be used to make your program more readable and structured. Use always forms if
this means that you can use the same form several times.
Each FORM must contain one program function.
All FORMs should be physically located at the bottom of the program (outside of the main
processing logic).
Group all Subroutines (SAP Forms) together preferably in an own include. Use a frame, Start of
Forms, to indicate the start of the subroutines.
Likewise for Modules.

27-10-15

Page 16 of 44

Shell Information Services

ABAP/4 Standard

Security
It is important that security be build into reports modeled around data as much HR data can be of
a sensitive nature and its viewing should be restricted to authorised people. Therefore, we need to
include the proper authority checks into the developments.
As mention above, for reporting associating a logical database with a report, will ensure that the
correct authority checks are performed when selecting the data. For dialog programming, where
you are selecting records, always perform authority checks

Template
As an example, a report template has been created in the system, which can be copied and used
as a starting point for new developments. It contains the correct header layout and sections for
tables, infotypes, constants, data and selection-screens. It is stored in the report
Y_ABAP_TEMPLATE.

Input Screens
As a rule, we should always look to have F4 selection helps for the input fields (excluding text
input fields). We should also look to have F1 help provided for the input fields. Where SAP help is
available, we should use that but we should program in F1 help if none is available. We should
ensure that online documentation is available for the screens.
Where input values have an associated text value, then we should also display that text, next to
the input field.

27-10-15

Page 17 of 44

Shell Information Services

ABAP/4 Standard

Object Orientation
Object Orientation is a widely accepted paradigm in the development world, with many OO
languages being utilised e.g. Java, C++. SAP is also looking to move to a completely OO
environment. From release 4.0, SAP has allowed for the creation of ABAP objects. This was
improved in 4.5 with the OO extension and again in 4.6 with the addition of inheritance, nested
interfaces, and dynamic method invocation. In release 5.0 we can expect that ABAP will be
completely object orientated.
Object Orientation allows for better encapsulation, extensibility, and reuse. It also allows for
integration with external object models e.g. DCOM, CORBA. With the use of the Business Objects
Repository (BOR), SAP have provided many Object Types, with their associated methods and
events. If you define your programs accordingly, then you can make use of these standard
Objects.
ABAP Objects is based on classes. Classes are pieces of program code that describe objects by
defining their components. Typical object components are attributes (data), which describe an
objects state, and methods (functions), which describe an objects behavior. Objects are instances
of classes. Many objects can be created from one class, but each object has its own attributes.
ABAP Objects provides a set of new statements that defines classes and handles objects. These
statements can be used in any kind of ABAP program.
Classes, and therefore objects, consist of at least two layersan inner and an outer layer. The
externally visible layer of an object is made up of public components. Public components can be
accessed directly by all users and form an objects external point of contact. Private components
are only visible within objects of the same class. The public section usually contains few attributes.
The state of an object is generally kept in private attributes and manipulated by public methods.
This way an object can ensure its own consistency.
Outside ABAP Objects, the only instances in ABAP are instances of whole ABAP programs such as
reports, module pools, or function groups. Each time a program is executed, a program instance is
implicitly created, which then runs in a separate ABAP process. Calling an external procedure (a
subroutine or a function module) also creates an ABAP program instance, which contains the
procedure. However, repeated calls always use the same one instance. Such program instances
live as long as the application program is running and cannot be handled explicitly.
With ABAP Objects, it is now possible to explicitly handle instances. The instances of classes,
namely objects, are created explicitly with ABAP statements. They have a unique identity
(independent of their attribute values) and are addressed by references. They live only as long as
they are needed.
You can define classes and interfaces in ABAP Objects either globally or locally. You define global
classes and interfaces using the Class Builder (Transaction SE24) in the ABAP Workbench.
These are then stored centrally in the class library within the R/3 Repository. All ABAP programs
in the R/3 System can access global classes and interfaces. You define local classes and
interfaces within an ABAP program. They can only be used in that program. When you use a class
in a program, the system first looks for a local, then for a global class with the specified name.
There is no other distinction in using global and local classes or interfaces.
Example of an Object Orientated program

27-10-15

Page 18 of 44

Shell Information Services

ABAP/4 Standard

REPORT demo_class_counter .
CLASS counter DEFINITION.
PUBLIC SECTION.
METHODS: set IMPORTING value(set_value) TYPE i,
increment,
get EXPORTING value(get_value) TYPE i.
PRIVATE SECTION.
DATA count TYPE i.
ENDCLASS.
CLASS counter IMPLEMENTATION.
METHOD set.
count = set_value.
ENDMETHOD.
METHOD increment.
ADD 1 TO count.
ENDMETHOD.
METHOD get.
get_value = count.
ENDMETHOD.
ENDCLASS.
DATA number TYPE i VALUE 5.
DATA cnt TYPE REF TO counter.
START-OF-SELECTION.
CREATE OBJECT cnt.
CALL METHOD cnt->set EXPORTING set_value = number.
DO 3 TIMES.
CALL METHOD cnt->increment.
ENDDO.
CALL METHOD cnt->get IMPORTING get_value = number.
WRITE number.

27-10-15

Page 19 of 44

Shell Information Services

ABAP/4 Standard

BAPI Programming
Object-oriented technology has been implemented in SAP R/3 by making SAP R/3 processes and
data available as Business Objects. Business Objects can be accessed by external applications
using standardised platform-independent interfaces called Business Application Programing
Interfaces or BAPIs. A BAPI is defined in the SAP Business Object Repository as a method, and is
implemented as a function module. The separation of the definition and the actual implementation
enables a BAPI to be accessed in two ways.
i)
For Windows 95 and Windows NT platforms the BAPI is invoked using the method defined
in the Business Object Repository. The BAPI ActiveX Control provided by SAP is used to invoke
the BAPI methods and allows external applications to access the SAP Business Objects in the
Business Object Repository by invoking BAPIs through OLE Automation.
ii)
For non-Windows platforms, RFC calls are used to access the function module on which a
BAPI is based.

Creating a new BAPI

The creation of a new BAPI for an existing SAP Business Object involves modifying the SAP
Business Object. In order to create a new BAPI it is recommended that a new Business Object
type is created and that the BAPI methods of the new type are extended. New Business Object
types should be created as subtypes for the object type being extended. In this way, the relevant
information, such as key fields, interfaces, attributes, methods, and events are copied to the new
object (sub)type.
For more information on creating new Business Object types refer to the SAP Business Workflow
documentation.
By creating new subtypes from within the ABAP/4 Development Workbench, the underlying
program is automatically created with the coding necessary to support the new object. For the
most part, this program should not require amending. However, if for any reason the program
requires modification then standard SAP macro instructions are available.
The macro instructions are available when the INCLUDE <OBJECT> command is specified as a
report section in the object type program. This instruction is added to each object type program
automatically when maintaining business objects via the ABAP/4 Workbench.
Container
A container is used for storing data and making it available to individual components in the SAP
Business Workflow. Containers may hold:

field values and multiline lists of field values

object references and multiline lists of object references

A container consists of a number of container elements. A data type reference is defined for each
element in a container. The container is named CONTAINER, and exists locally within the object
type program. The elements of the container have the same names as the attributes or
parameters to be stored within them.
Object Program Macro Instructions
The following macro instructions are available for processing a container.

SWC_SET_ELEMENT

write a field value to the container

SWC_SET_TABLE

write a multiline list of values to a container

SWC_GET_ELEMENT

read a field value from the container

SWC_GET_TABLE

read a multiline list of values from a container

SWC_CREATE_OBJECT

assign an object reference to the container

27-10-15

Page 20 of 44

Shell Information Services

ABAP/4 Standard

SWC_GET_OBJECT_TYPE

read an object reference type from container

SWC_GET_OBJECT_KEY

read an object key from the container

The following macro instructions are available for accessing objects in the business object
repository.
Variables which contain references to objects are defined with the type SWC_OBJECT.

SWC_CREATE_OBJECT

create an object reference

The macro SWC_GET_OBJECT_TYPE and SWC_GET_OBJECT_KEY can be used to read the

type and key of the object respectively.

SWC_CALL_METHOD

Example:

call a method of an object

SWC_CALL_METHOD Object Method Container

The result (container element _RESULT) and the export parameters are stored in the container.
The following macros can be used to access attributes or key fields of an object.
SWC_GET_PROPERTY

returns single values

SWC_GET_TABLE_PROPERTY

returns multiline values

Attributes that are references to database fields are only read the first time that they are accessed.
In order to read them again the SWC_REFRESH_OBJECT macro can be used.
Implementation of BAPI Functionality
The creation of a new BAPI requires the creation of the underlying function module. The function
modules that are available for use with BAPIs must have the following characteristics:
-

Support the Remote Function Call (RFC) protocol,

Must be assigned as a method for a SAP Business Object in the Business

Object Repository,
Must be processed without returning any screen dialogs to the calling
application, or make use of the SAP update task. (synchronous processing).

Controls
New as of 4.6, SAP have introduced SAPGUI controls. These allow you to split up a screen using
docking and splitting controls, which provides greater scope for User Interfaces. These controls
can be used to incorporate web browsers, pictures, drag and drop functionality and integration with
Windows applications such as Office suite into the GUI. These are Object Orientated and can be
utilised by instantiating the relevant control objects.
Examples of these controls can be found in the ABAP Editor (SE38), under Environment
Controls Examples

Directives Lay-out of reports(print-out) and screens

27-10-15

Page 21 of 44

Shell Information Services

ABAP/4 Standard

It is important that the screens of your ABAP/4-program are as user-friendly and clear to the user
as much as possible. That is why the lay-out of your screen needs to be set up properly. This
means that before you start designing your screens, you should start finding the right balance
between the unused and active parts of your screen. The active parts can be adjusted by aligning,
ranging (text) fields and columns on the screen in a proper way.
SAP Provides Ergonomic examples of reports and Dialog screens that can be used as a template
for list processing and Dialog programming. This can be reached through the ABAP Editor
(SE38), under Environment Ergonomic Examples (Lists, Screens).
In addition to these templates the suggestions below will help you designing your user screens:

Information overload
Do not show too much information on one screen. The user should be able to focus on the
relevant information only when using the screen and not get lost in the mass of detail in a
screen. The usage of SELECT-OPTIONS and Report-variants help to increase the usability of
your software;

Dialog steps
Try to minimize the number of dialog steps when navigating towards your target within the
program (say for instance one or two screens deep). Only when the functions become more
complex, the number of dialog steps may increase. By adding screens and thus splitting up
the measure of functionality of the screen, less information is put away in one screen and
decreases the level of complexity;

Checks
Check by user input (PAI), but try to keep these checks to a minimum in between dialog steps.
When designing the order in which the screens will be presented to the user, take into account
that content in previous screens need to be correct for the user to be allowed to continue to
the next screen. This means that when an user made an error some screens ago, he or she do
not has to go back through all the previous screens to correct the problem.

Order of screen check

Check by user input: within the screen check the different fields from up-left to down-right, like
the fields appear in the screen. Phase (within the screen-processlogic) the checks of the fields
and their relationships between the fields as following :1. First

: Field size check

2. Second

: Field contents check

3. Last

: Check on the relations between several fields

Fields check
Check by user input : open, when input errors made by the user are detected, with the
commands CHAIN..ENDSCHAIN only those fields before INPUT, who are necessary to solve
the input error.

Grouping fields
Group all fields, text and text area's logically together. For instance you could use the BOXoption in the screenpainter to group fields.

Fields consistency
Place combinations of input fields exactly the same (consistent) way in other screen instances.
When you use, for example, within screen 1000, transaction ZAAA using the order : 'name1,

27-10-15

Page 22 of 44

Shell Information Services

ABAP/4 Standard

name2, address, city', you also should use the same order for screen 1000 in transaction
ZBBB.

Boolean
For input in a Boolean-way, you can make use of radiobuttons. You can check your input field
more easily with a "IF N_INPUTFIELD NE SPACE' for a "true"-situation.

You should leave enough unused 'space' in your screens. Some instruments for helping you
designing your screens are:1. ULINE

- line

2. SKIP

- blank lines

3. FORMAT INTENSIFIED ON/OFF

- colour intensified

4. FORMAT COLOR

- usage of colours

5. Etc.

In reports which are (very) interactive and where action is done repeatedly, function-keys
should have a consistent meaning throughout the dialog-process.

In conclusion to these guidelines, there is a short example of screen/report stated below.

Example HEADERPAGE:
<Selection fields of Log.DB> or <Your own design>

Example REPORT
DD.MM.YYYY

ZM0000: Overview addresses

9999

--------------------------------------------------------------------Personnel

Name

Street

Cost

Currency

Number
--------------------------------------------------------------------10000000

Smith, P.A.

2300 East drive

4.540,00

FFR

10000001

Johnson, K.

100, Indylane

3.009

BFR

10000003

McGiver, Th.

4 th avenue

7.241

USD

---End List---

Example FOOTER

--------------------------------------------------------------------------------------------------------------------------------<pageno.>

27-10-15

Page 23 of 44

Shell Information Services

Section III

ABAP/4 Standard

Documentation

Documentation in the program

The source code should be documented (in English) so that other programmers can quickly
understand the purpose of the program and its flow. Every program must begin with a
documentation block. This block must contain information about the program, the programmer and
the corrections. The following elements must be present at the top of every program:
Name of the program
Author and company
Date
Correction number and version
Title of program
Short description of the purpose for the program
Details
Construction
Change history (who changed what, when, why)
An example of a documentation block is shown below.
*===================================================================================
* Report : YGLXXXXXX0
* Version: 1.00
* Author : A. Programmer
SHELL
Date
: 21.01.2001
*----------------------------------------------------------------------------------* Title :
* Purpose: .....................................................................
*
* Document: (Name of Technical and/or Functional Spec)
*
* Details: (technical description of the report, how does the program work,)
*
.....................................................................
* Constr.: Assumptions and constraints
*===================================================================================
* Change history
*----------------------------------------------------------------------------------* Correction on version :
* New version
* Author : ... +(initials)
* Date
: ...
* Reason : ...
* Change : ... (description(s) of changes made in the report)
*===================================================================================

Program Readability
Indentation

The ABAP programs should have proper indentation. Always use the PRETTY PRINTER after
editing the programs, when you did not indentation manually.
Use for every command and component a new line. For example, when using the select
statement, each selection criterion is on a new line.

27-10-15

Page 24 of 44

Shell Information Services

ABAP/4 Standard

For example:
SELECT * FROM TABLE1
WHERE FIELDNAME1 = S_PAR1
AND FIELDNAME2 = 400
OR FIELDNAME3 = TABLE2-FIELDNAME4.
WRITE: TABLE1-FIELDNAME1,
TABLE1-FIELDNAME2,
TABLE1-FILEDNAME3.
ENDSELECT.

Comments

The ABAP programs should be well documented with clear and concise comments alongside the
program codes in mixed case. Comments in the program are useful. They should explain what the
code is doing, not how it is doing it. When the complexity of a piece of source is (too) high,
additional comments are needed.
For example:
SET PARAMETER id 'BDC' FIELD LOG."Parameter id needed for
"BDC logging.
"The LOG field is updated
"at when releasing BDC
In addition, the following entities of a program should also be documented:
a)

Table names

b)

Variable names

c)

Function calls

d)

Modules

e)

Forms

Comments when the ABAP/4 source will be changed

When a ABAP/4-source will be changed, the change history block in the documentation header
block need to updated with the changes. In the change history block the functional descriptions of
the changes will be notated. It will also be necessary to add comments per changed line in the
source. You will add the initials and the date of the changes in the comments. In case when an
OSS-note is responsible for the change in the source, make sure you place the OSS-number also
in the line-comment.
For example:
SUBMIT (ZSREPORT) AND RETURN.

"FHU220497

ADD 1 TO W_ALERT.

"OSS NOTE 1234567

27-10-15

external logging

Page 25 of 44

Shell Information Services

ABAP/4 Standard

Support Documentation
In addition to the ABAP source code being well documented, the development should be
supported by Functional & Technical specifications and a well-defined Test Procedure. The ASAP
implementation assistant provides us with a standard template to create a standard look and feel
to the documentation. The ASAP implementation tool helps define requirements for developments
and can also be used to generate some of the functional specification document.
The Documentation template is attached in Appendix V, which should be completed and checked
as part of the User Acceptance Testing.

Online Documentation
Documentation can be copied from functional and technical specifications. Links to the glossary
and hypertext can be used to provide meaningful data and references.
The system provides four standard sections.

Description
This section should contain the following:
1) A description of the business case for the program and what it does from a business
perspective. This portion has the purpose of guiding an end user in the proper application and
operation of the program, consequently this would be written, or copied from the specification
provided, by the person who identified the original functionality gap.
2) A brief functional description of the program; this has the purpose of indicating to a technical
support person what the program does. This would be written by the programmer. NB. This
would not contain how the program works - this should be documented with the program code.

Preconditions
A description of what this program expects upon execution. This may need to be both from a
technical and a business perspective.

Output
What the program is expected to produce. Include any special formatting / media notes in this
description, and also the name (if applicable) of any programs that are expected to use the
output.

Examples
If possible, some simple examples of what the program will do are to be included here. This will
mainly be to help an end user and so the examples should be created in conjunction with the
business users.

27-10-15

Page 26 of 44

Shell Information Services

Appendix I

ABAP/4 Standard

SAP definition of customer naming range

Customers may only create objects in the ABAP/4 Dictionary with certain names, which are not
used by SAP. This ensures that customer objects are not overwritten in an upgrade.
The following overview gives the customer name ranges currently specified for objects of the
ABAP/4 Dictionary.
Object

Name length

Customer name range

Example

Domain

30

Y*, Z*

YNAME, Z1234

Data element

30

Y*, Z*

ZNAME, YNAME12

Matchcode object

Y*, Z*

YMCO, ZMCO

Matchcode ID

0 to 9

YMCO1, ZMCO7

Pool/cluster name

10

Y*, Z*

YPOOL, ZCLUSTER

Lock object

10

EY*, EZ*

EYNAME, EZNAME

Structure

16

Y*, Z*, T9*, P9*

YSTRUCT

Transparent table

16

Y*, Z*, T9*, P9*

YTAB1, ZTAB2

Index ID

Y*, Z*

Y12, ZAB

APPENDs

16

Y*, Z*

ZAPPEND

Fields

30

YY*, ZZ*

ZZFIELD

Pooled/cluster table

16

Y*, Z*, T9*, P9*

YPOOL, ZCLUSTER

View

16

Y*, Z*

YVIEW

Help view

10

H_Y*, H_Z*

H_ZVIEW

Customer includes

16

Cl_*

Cl_KUNDE

Index customer naming range

The following index contains all objects with their naming convention and the reference to the
page in the document. It can be used as a quick reference guide or the index.
Legend:
=

must equal to

<=

less than or equal to

<A-ID>

application id (H=Human Resource Planning, F-Finance etc.)

<T>

I for Inquiry, P for Processing/Update

freely definable

Object

Length of name

Customer reserve

Application log

Object

Z*, Y*

Subobject

10

Z*, Y*

27-10-15

Page 27 of 44

Shell Information Services

ABAP/4 Standard

Object

Length of name

Customer reserve

Authorization/Profile

<=12

<A-ID>:*, <A-ID>:*

Authorization object

<=10

Z_*, Y_*

Authorization group for report

<=8

Z<A-ID><T>*,Y<A-ID><T>*

Authorization group for table

=4

Z<A-ID>*, Y<A-ID>*

Batch input session

<=12

<A-ID>-*

Batch job name

<=32

<A-ID><A-ID>***_*

Change document object

10

Z*, Y*

Data element

<=30

ZZ<A-ID>*, YY<A-ID>*

Dialog module

<=30

Z*, Y*

Domain

<=30

ZZ*, YY*

Dynpro number

=4

9000 - 9999

Development class

=4

Z<A-ID>, Y<A-ID>

Form

<=16

Z*, Y*

Function modules

<=30

Z_<A-ID>* ,Y_<A-ID>*

Function group

=4

Z<A-ID>*, Y<A-ID>*

Infotype number

9000 - 9999

Logical database

=2

Z* , Y*

Matchcode ID

=1

0-9

Matchcode object

=4

Z<A-ID>*, Y<A-ID>*

Message ID

=2

Z<A-ID>, Y<A-ID>

Message number

=3

900 - 999

Number range document object

10

Z*, Y*

Pool name/cluster name

10

Z*, Y*

ID of the relation

Z*, Y*

Report

<=30

Z<A-ID>*, Y<A-ID>*

Report class

=4

Z*, Y*

Report variant

globally transportable

14

X*

locally transportable

14

Y*

not transportable

14

Z*

20

Z*, Y*

R/3 Analyzer

Identifiable

SAPscript

Layout set

16

Z<A-ID>*, Y<A-ID>*

Style

<=8

Z*, Y*

Text ID

=4

Z<A-ID>*, Y<A-ID>*

Standard texts name

<=32

Z*, Y*

SPA/GPA parameter

=3

Z<A-ID>*, Y<A-ID>*

Lock object

10

Z*,Y*

Spool

Device type

<=8

Z*, Y*

Font families

<=8

Z*, Y*

System barcodes

<=8

Z*, Y*

Page format

<=8

Z*, Y*

27-10-15

Page 28 of 44

Shell Information Services

ABAP/4 Standard

Object

Length of name

Customer reserve

<=16

Z*, Y*

Format type

SYSLOG messages

=2

Table

(Pool,cluster,transparent)

<=16

(Internal)

<=16

Table field

<=30

Z*, Y*

Table index

<=3

Z*, Y*

Transaction code

<= 20

Z<A-ID>*, Y<A-ID>*

Types

Z*, Y*

View

<=16

Z<A-ID>V*, Y<A-ID>V*

10

H_Z<A-ID>*, H_Y<A-ID>*

Help view

Z<A-ID>*, Y<A-ID>*

View maintenance data

View contents

reserved in TRESC

Table contents

reserved in TRESC

Workflow object types

27-10-15

10

Z*, Y*

Page 29 of 44

Shell Information Services

ABAP/4 Standard

Appendix III ABAP/4 program checklist

Object:__________________ Date:_______ Author:_____________ Tester:_____________
Documentation

Is the English (and/or: local language) Online documentation (in SAP/3) available?

Are the HELP pages, text-elements, etc. available (and translated) ?

Sourcecode

Are comments used in the source in English?

Are all the descriptions used in your ABAP-source easy to read and are the amount of
descriptions ?

Are all declarative/events elements accompanied with the necessary comments?

Are all variables & forms in conformity with the Naming Convention (also from SAP)?

Is the program-description-block implemented and is it correctly filled in at the begin

of the ABAP/4 source code?

Are all SELECT's accompanied with the necessary AUTHORITY-CHECK's?

Have you used MODE N for time infotypes (2000 - 2999)

No PROVIDE statement, join or projection to process time infotypes.

Are all DATA/TABLE/FIELDNAMES-declaratives put on a single line with the

appropriate description?

Are the lines of source grouped logically?

Are the declarative elements/events set in the correct order of appearance?

(see Declarative Elements/Events)?

Is the size of the forms you are using very large? If so, put it in a separate include.

Have you used line indentation in your source code (pretty printer)?

Have you freed the internal table, when no longer used in the program?

Screen/Printer Output

Is a user able to understand the way the output is presented of the screen/printer?

Is the error-messaging clear so the user knows what to do? (check SY-SUBRC-settings)

Are all relevant fields on the screen grouped logically (e.g. using BOX in screenpainter)?

Is the Header/Footer correct?

Are the field-calculations, -colours, -names correct?

Program

After using the advanced debugger, is the program free of bugs?

Have you used the Runtime-analyse and is the performance acceptable e.g. does not exceed
max. on line runtime?

27-10-15

Page 30 of 44

Shell Information Services

ABAP/4 Standard

Appendix IV ABAP/4 Performance

To get the best performance of your ABAP/4 programs, the following rules are recommended when
programming your program: -

SAP Performance Examples

The ABAP workbench contains programming performance examples including SQL examples,
String Manipulations, Internal Tables and Conversions. It is recommended that you incorporate
these examples into your developments. The examples can be accessed via the ABAP Editor
(SE38) under Environment Performance Examples.

Internal Table

When defining the size of the internal table (OCCURS), use the size of the table you are
importing into your internal table as an indication. This means that when the table is
referenced for the first time, the system reserves memory for the internal table. If the table
exceeds the reserved space in memory, usage of memory is less efficient which in turn
reflects on the system's performance;

If an internal table is no longer needed, use the FREE statement to free system memory
occupied by the table;

For reasons of efficiency use always (if possible) the SORTBY statement rather than SORT,
when sorting an internal table;

When importing data from a table into an internal table and only a few table fields are needed,
use the MOVE-statement instead of the MOVE-CORRESPONDING-statement;

If the entire key of an internal table is known, use the READ TABLE-statement to fetch the
desired table entry. If this key is incomplete, make use of the binary search-statement. E.g.
READ TABLE itab WITH KEY key = key_entry BINARY SEARCH;

Use the COLLECT-statement only if the internal table consists less than 50 entries.

Database
To achieve the best performance of an ABAP/4-program it is necessary to keep the amount of data
handling between the database and the program as low as possible. With other words: try to limit
the amount of data traffic on the network to the client. Stated below there is a list with some
guidelines.
The amount of data traffic between the SAP/3 Database and the application needs to be
kept to a minimum.
When using certain options in the SELECT-line, network traffic between the DBMS and the
application further reduced.
Use your data selectively
When a small number of datafields is necessary, only the datafields, which are needed should be
read.

27-10-15

Page 31 of 44

Shell Information Services

ABAP/4 Standard

Example: instead of..

SELECT * FROM table WHERE condition.
..processes..
ENDSELECT.
Do..
SELECT field1 field2 field3 INTO ( f1, f2 )
FROM table WHERE condition.
..processes..
ENDSELECT.
Use of aggregate functions
Program functions can be used in your SELECT-statement so the DBMS can perform certain
computations when reading the database instead of moving large amounts of data to the
application.
The following program functions are available for this purpose: MAX

Finds the largest value

MIN

Finds the smallest value

AVG

Calculates the average value

SUM

The sum of a column

COUNT ( DISTINCT <f> )

Gives the number of different values of a column (<f>)

COUNT ( * )

Gives the number of lines per (sub)total. When using the GROUPBY option in the SELECT-line, the number of lines per group will be
given.

Example: instead of..

Sum = 0.
SELECT * FROM table WHERE year = 1995.
Sum = sum + tab-amount.
ENDSELECT.
Do..
SELECT SUM( amount ) INTO sum FROM table
WHERE company = 0001
GROUP BY year.
..processes..

27-10-15

Page 32 of 44

Shell Information Services

ABAP/4 Standard

ENDSELECT.
Note : this kind of functions can not be used in pooled- and cluster-tables.
In general it is more efficient to import all data into the memory of the application, instead of
browsing the table several times.
Use Internal Table operations - INSERT
When inserting a set of records into a table, the insert functionality is much faster than the LOOP
AT / INSERT solution
Example: instead of..
LOOP AT itab.
INSERT INTO dbtab VALUES itab.
ENDLOOP.
Do..
INSERT dbtab FROM TABLE itab
ACCEPTING DUPLICATE KEYS.
IF sy-subrc = 4.
..error handling..
ENDIF.
Note: In the above example, duplicate records will be ignored.
Do not update work area's
When performing simple calculations (like incrementing values in a field), it is advisable to write
the directly to the table in the database, instead of performing the calculation in your program. In
the first example (stated below) all records are transported from the DBMS to the application and
back. The second example only a single task is sent to the table (hence it appears that no data is
transported to the application).
Example: instead of..
SELECT * FROM table WHERE condition.
Tab-field = Tab-field + var1.
UPDATE tab.
..processes..
ENDSELECT.
Do..

27-10-15

Page 33 of 44

Shell Information Services

ABAP/4 Standard

UPDATE tab SET field = field + var1

WHERE condition.

Avoid nested SELECT's

Using nested selects is a technique with a low performance. The inner select statements are
executed several times which might be an overhead. In addition more data is transferred in
comparison to other techniques.
To avoid nested loops Implement a join as a view in the ABAP/4 dictionary
Example: instead of..
SELECT * FROM pers WHERE condition.
SELECT * FROM persproj WHERE person = pers-persnr.
..processes..
ENDSELECT.
ENDSELECT.
Do..
* VIEW persjproj_view in ABAP/4 DDIC
SELECT * FROM persjproj_view WHERE condition.

?????check!

..processes..
ENDSELECT.
Narrow down your selection as much as possible
Use as many Constraints in the SELECT-statement as possible, especially on key-fields, the
statement can be executed very fast.
Example:
SELECT * FROM BKPF
WHERE mandt = '001'
AND bukrs = '0002'
AND belnr = '000000005'.
..processes..
ENDSELECT.

27-10-15

Page 34 of 44

Shell Information Services

ABAP/4 Standard

The amount of processes in the query needs to be kept to a minimum

Always try to pecify all known conditions in the WHERE-line to minimize the amount of data
requested. In case there is no WHERE-line in the query specified, the DBMS can not perform any
optimizations.
Example: instead of..
SELECT * FROM table.
CHECK field1 = NAME.
CHECK field2 = STREET.
..processes..
ENDSELECT.
Do..
SELECT * FROM table
WHERE field1 = NAME AND field2 = STREET.
..processes..
ENDSELECT.
Note : In some cases when all data has to be read from a table (for example when reporting on all
companies, Client Copies, Utility function, etc) the WHERE-line can be left out of the query.

Unburden the SAP/3 database as much as possible

The DBMS is a central resource in the R/3 system. It is shared by all users. Everything should
therefor be done to take the load of it.

Tables can be buffered in R/3. Buffering is only recommended for read-only or read-mostly
tables.

Check whether an application reads the same data repeatedly. This is not only a question of
performance. R/3 usually reads the database in uncommitted mode and thus reading a record
twice can lead to a different result;

Performing a SELECT before an UPDATE or DELETE of a record just to check whether the
record exists is superfluous. Check the SY-SUBRC after updating or deleting.

For large batch jobs, the new language element OPEN CURSORWITH HOLD should be
used. Please refer to the documentation

There are two ways to get ordered data. The data can be selected using the addition ORDER
BY in your SELECT-statement from the database. This is advisable for large amounts of data
because the database system us the only component in R/3 with really huge resources.
Ensure that the ORDER BY can use an index. When rather small data is to be done with
ABAP use the SORT statement on your internal table.

SAP Open SQL statements should be minimized to reduce I/O processing. SQL statements
should normally be issued once and stored in work areas for further processing.
Example: instead of..
SELECT * FROM T9XXX WHERE <KEY1> =

27-10-15

Page 35 of 44

Shell Information Services

ABAP/4 Standard

MOVE-CORRESPONDING T9XXX TO <internal database>.

APPEND.
ENDSELECT.
Do..
SELECT * FROM T9XXX INTRO TABLE <internal database>
WHERE <KEY1> = ..

27-10-15

Page 36 of 44

Shell Information Services

ABAP/4 Standard

Appendix V Example Lay-Out of an ABAP/4 Program

<Heading-part, see example mentioned in HR General programming guidelines>

Report ...

USING DATABASE PNP

MESSAGE-ID ZZ
NO STANDARD PAGE HEADING
LINE-SIZE 130

Landscape, default

LINE-SIZE 80

Portrait

LINE-COUNT 62(2).

*----------------------------------------------------------------------------------* TABLES
*-----------------------------------------------------------------------------------

Tables ...

<description per table>

*----------------------------------------------------------------------------------* INFOTYPES
*-----------------------------------------------------------------------------------

Infotypes ...

<description per Infotype>

*----------------------------------------------------------------------------------* DATA: INTERNTAL TABLES

*-----------------------------------------------------------------------------------

DATA: BEGIN OF OCCURS 0,

<description of table>

END OF

<descriptions per field if necessary>

*----------------------------------------------------------------------------------* DATA: CONTSTANTS

*-----------------------------------------------------------------------------------

RP-DEF-BOOLEAN.

Define BOOLEAN, TRUE,

FALSE

CONSTANTS:

B_TEST LIKE BOOLEAN VALUE X,

Switch for test-mode

<description per constant>

*----------------------------------------------------------------------------------* DATA: VARIABLES

*-----------------------------------------------------------------------------------

DATA: WU_POS_PAGE_NO
WI_TEST_REC_COUNT

LIKE SY-PAGNO, Position

TYPE I,

of page-no

Record counter for test

<description per constant>

*----------------------------------------------------------------------------------* SELECTION-SCREEN
*-----------------------------------------------------------------------------------

SELECTION-SCREEN BEGIN OF BLOCK FRAME_1 WITH FRAME

27-10-15

Page 37 of 44

Shell Information Services

ABAP/4 Standard

TITLE Overview(001).
SELECTION-SCREEN END OF BLOCK FRAME_1.
*----------------------------------------------------------------------------------* INITIALIZATION
* Note: initialization of variables and any other action you want to run
*

before the actual program starts, for example authority-check.

For complilation-reasons AFTER selection-screen.

*-----------------------------------------------------------------------------------

INITIALIZATION.
* AUTHORITY-CHECK object
* Initialization of variables
CLEAR: WU_POS_PAGE_NO,
WU_TEST_REC_COUNT,

*----------------------------------------------------------------------------------* AT SELECTION-SCREEN ON <field>

* note: field specific checks can be performed here, for example check whether an
entered country exists, if an entered number is valid, etc.
*-----------------------------------------------------------------------------------

*----------------------------------------------------------------------------------* AT SELECTION-SCREEN
* note: relations between fields can be checked at this event.
*-----------------------------------------------------------------------------------

*-----------------------------------------------------------------------------------

START-OF-SELECTION.

*----------------------------------------------------------------------------------* <describe initial actions before first record of LDB is read.>

*-----------------------------------------------------------------------------------

PERFORM FIRST_PAGE.

Print first page with parameters and

select-options.

*-----------------------------------------------------------------------------------

GET PERNR.
* <describe processing of record>
*-----------------------------------------------------------------------------------

* If in test-mode: quit after 100 records and goto end-of-selection.

27-10-15

Page 38 of 44

Shell Information Services

ABAP/4 Standard

* Check whether the selected person is valid.

RP-PROVIDE-FROM-LAST p0002 SPACE PN/BEGDA PN/ENDDA.

*-----------------------------------------------------------------------------------

GET PERNR.
* <describe processing of record>
*-----------------------------------------------------------------------------------

* If in test-mode: quit after 100 records and goto end-of-selection.

IF B_TEST = TRUE.

* Check whether the selected person is valid.

RP-PROVIDE-FROM-LAST p0002 SPACE PN/BEGDA PN/ENDDA.

*-----------------------------------------------------------------------------------

END-OF-SELECTION.
* <describe processing of record>
* Example: read internal table and process it.
*-----------------------------------------------------------------------------------

LOOP AT
AT NEW
*

Go to end-of-page section (command NEW-PAGE skips this section)

ENDAT.

Write data to report.

WRITE: /()

*-------AT END OF

ENDAT.
*-------AT FIRST

ATEND.
*-------AT LAST

ATEND.
*-------ENDLOOP.

27-10-15

Page 39 of 44

Shell Information Services

ABAP/4 Standard

* Marking of End of list

SKIP 2.
FORMAT COLOR COL BACKGROUND INTENSIFIED OFF.
WRITE AT 10 --- End of List ---(r01).
* Go to end-of-page section (command NEW-PAGE skips this section)
*-----------------------------------------------------------------------------------

TOP-OF-PAGE.
*-----------------------------------------------------------------------------------

*-----------------------------------------------------------------------------------

END-OF-PAGE.
*----------------------------------------------------------------------------------

27-10-15

Page 40 of 44

Shell Information Services

ABAP/4 Standard

Appendix VI Useful Reports/Functions/Tables

Included below are some useful reports.
Report Program Name

Description

SAPMSABAPDEMOS_TREE Displays ABAP documentation & examples (Transaction ABAPDOCU)

RSHOWTIM

Displays tips and tricks for ABAP Programming

RSANAL00

Program analysis

RSABAPIV

Lists all ABAP commands

RSTXTRAN

Transfer text between clients with transport number

RSBDCSUB

Initiates Batch input sessions to run automatically when scheduled

RSDYNL10

List all DYNPROs which belong to a specific ABAP

RSTXSCRP

Transports SAPscript without transport number

RSTXR3TR

Transports SAPscript with transport number

RSTXFINF

List information about a SAPscript form

RSTXFCON

Conversion of paper format for SAPscript forms

RSTXFCOM

Compares two SAPscript forms

Useful Functions
Below is a list of useful functions you may use in your own programs. SAP provides several which
you should use as much as possible to avoid redundant code. The functions themselves can be
accessed via the Object Repository or the function builder (transaction SE37).
Batch Input Sessions (BDCs)

BDC_OPEN_GROUP
Creates a new batch input session
BDC_INSERT
Creates a record in a batch input session
BDC_CLOSE_GROUP
Closes the batch input session
BDC_DELETE_SESSION
Deletes the batch input session
Text Processing

READ_TEXT
Reads text from the specified object into an internal table

27-10-15

Page 41 of 44

Shell Information Services

ABAP/4 Standard

READ_STDTEXT
Reads standard text into an internal table
Date Processing

DATE_COMPUTE_DAY
Determines the weekday as a numeric value (1-7) from a date specified
DATE_CONVERT_TO_FACTORYDATE
Determines the factory calender date from a date specified
DATE_GET_WEEK
Determines the week of the year given a specified date
EASTER_GET_DATE
Determines the Eastern date given a specified date
FACTORY_CONVERT_TO_DATE
Determines date given a factory calender date
HOLIDAY_CHECK_AND_GET_INFO
Determines if a given date is a holiday and if so, gives information
WEEK_GET_FIRST_DAY
Determines the first day of the week for the week a specified date falls upon
Popup Windows

POPUP_TO_CONFIRM_LOSS_OF_DATA
Displays a pop-up window asking the user for a decision on loss of data
POPUP_TO_DECIDE
Displays a pop-up window asking the user for a decision on customizable information
POPUP_TO_CONFIRM_STEP
Displays a pop-ip window to confirm further processing
POPUP_TO_FILL_COMMAND_LINE
Displays a pop-ip window for user command input

Useful Dictionary Tables and Structures

The following are tables that are useful in custom developed programs for reference and/or
validation purposes.
Table Name
DD03L

27-10-15

Table Type
Trans. Table

Use
All tables in the data dictionary and their fields

Page 42 of 44

Shell Information Services

ABAP/4 Standard

NRIV

Trans. Table

Number Ranges

BDCDATA

Structure

Structure of table for batch input processing

BDCMSGCOL
Structure
L

structure of table to hold all system messages during a CALL

TRANSACTION command

T000

Trans. Table

Client Codes

T100

Trans. Table

System Messages

TADIR

Trans. Table

Directory of transportable developments

TDCT

Trans. Table

Directory of dialog modules

TDEVC

Trans. Table

Development classes

TFDIR

Trans. Table

Directory of function modules

TLIBG

Trans. Table

Function groups

TFLIBT

Trans. Table

Fuction groups short text

TRCL

Trans. Table

ABAP report classes

TRCLT

Trans. Table

ABAP report classes texts

TRDIR

Trans. Table

Directory of reports

TRESE

Trans. Table

Reserved words

TSTC

Trans. Table

Transaction codes

TSTCT

Trans. Table

Transaction code texts

TVARV

Trans. Table

Select variables for ABAP variants

TVDIR

Trans. Table

Directory of table views

Structure

Internal table filled by SAP during runtime. A developer can reference the
runtime environment for their program through the fields of this structure
using the "SY-" prefix before the structure field name. There are several
useful fields, but the most commonly used is "subrc" in "sy-subrc"
statements which gives the return value of processes.

Structure

Internal table filled by SAP during runtime. Attributes of the current

screen-fields may then be accessed. Screen-field contents, however, can
only be accessed and changed within a "LOOP AT
SCREEN....ENDLOOP" statement.

SYST

SCREEN

27-10-15

Page 43 of 44