EDFE Corporate SAP - ABAP Developer Handbook v1.3

SAP ABAP DEVELOPER
HANDBOOK
Version: 1.3
Classification: Protect - Commercial
DOCUMENT CONTROL
Release History
Version Date Author(s) Comments

1.0 Friday Bryan Ranson, Initial
12/08/2011 Julie Waller
1.1 07 Sept 11 J Waller Feedback following discussions with Bryan
Ranson
1.2 Wednesday, 15 Bryan Ranson Added guideline re custom table logging. Refer to
February 2012 section 3.2
1.3 Wednesday, 10 Bryan Ranson Revised Transaction Code naming convention in
October 2012 response to GRC request. Refer to section 3.3.6
Approval
Approver Role Signature

Ken Saggers SAP Technical Manager
Andre Muecke Business Applications Manager – SAP
Reviewers
Name Role
Andre Muecke Business Applications Manager – SAP
Ken Saggers SAP Technical Manager
Giampaolo Lupi Transition Manager – SAP
Satyan Ghumatkar SAP Technical Consultant
SAP ABAP Developer Handbook Page 2 of 92 Version: 1.1

Status: Draft
Confidential 20/01/2024 11 October 2012
TABLE OF CONTENTS
1 INTRODUCTION 7
1.1 Purpose 7
1.2 Scope 7
1.3 Intended Audience 8
1.4 Application Architectural Standards 8
1.5 Good Development Practices 8

1.5.1 Do’s 8
1.5.2 Don’ts 8
2 GENERAL PROGRAMMING RULES 8
3 SAP DEVELOPMENT NAMING CONVENTIONS 12

3.1 Overview 12
3.1.1 Customer Name Space ID 12
3.1.2 Process Area/Application ID 12
3.2 ABAP Dictionary 14

3.2.1 Transparent Tables 14
3.2.2 Structures 15
3.2.3 Table Fields 15
3.2.4 Views 16
3.2.5 Domains 16
3.2.6 Data Elements 17
3.2.7 Lock Objects 17
3.2.8 Search Help 19
3.2.9 Matchcode Objects 19
3.2.10 Table Types 19
3.2.11 Type Group 20
3.3 ABAP Program 21

3.3.1 Program Naming 21
3.3.2 Report Variant 25
3.3.3 Module Pool Names 25
3.3.4 Dynpros (Screen) 26
3.3.5 GUI Status & GUI Title 27
3.3.6 Transaction Codes 28
3.4 Forms 29
3.4.1 SAPscript/Form Painter 29
3.4.2 Smart Forms/Interactive Forms 29
3.4.3 ALE & IDocs 30
3.4.4 Workflow 33
3.4.5 Packages/Development Classes 34
3.4.6 Area Menus 34
3.4.7 Messages 35

Status: Draft
3.4.8 Logical Databases 35
3.5 Background Jobs 37
3.6 Batch Input Sessions 38
3.7 Datasets 38
3.7.1 File Naming 40
3.8 Legacy System Migration Workbench (LSMW) 40

3.8.1 Project 40
3.8.2 Subproject 40
3.8.3 Object 40
3.9 Naming Conventions for ABAP Objects 40

3.9.1 Global Conventions 40
3.9.2 Class-local Conventions 41
3.9.3 Exceptions 44
4 REUSABLE DEVELOPMENT OBJECTS REPOSITORY 45
5 SAP ABAP ANALYSIS TOOLS 45

5.1.1 Extended Program Check 45
5.1.2 Activatable Checkpoints 45
5.1.3 Runtime Analysis 45
5.1.4 Performance Analysis 46
5.1.5 Coverage Analyzer 46
5.1.6 Runtime Monitor 46
5.1.7 Memory Inspector 47
5.1.8 Code Inspector 47
5.1.9 ABAP Unit 47
6 PROGRAMMING STANDARDS 48
6.1 General Rules 48
6.2 Comments & Documentation 48

6.2.1 General Documentation 49
6.2.2 Documentation on Data and Program Flow 51
6.2.3 Documenting Form Routines 53
6.2.4 Documentation in ABAP Objects 54
6.3 Layout and Formatting 54
6.4 Programming ABAP Objects 55
6.5 Dialog Program Standards 55

6.5.1 Table Buffering 56
6.5.2 SAP List Viewer (ABAP List Viewer- ALV) 57
6.6 Reporting Standards 58

6.6.1 Web Reporting 58
6.6.2 ABAP Reporting 60
6.6.3 Data Definition 62
6.6.4 Online Standard 63
Status: Draft
6.6.5 Batch Program / Interface Standards 64
6.6.6 Message 65
6.6.7 Program Logic 65
6.7 Performance Standards 67

6.7.1 Non-Database Access Operations 67
6.7.2 Database Access Operations 67
6.7.3 Internal Table 73
6.7.4 String Operation 81
6.8 Interface Standards 83

6.8.1 Web Services 83
6.8.2 BAPI’s 84
6.8.3 IDOC’s 85
6.8.4 Process Integration (PI) 87
6.9 Enhancements & Modifications 87

6.9.1 Enhancement Spots 89
6.9.2 Enhancements to DDIC objects 90
6.9.3 Modifying SAP database Tables: 91
7 SAP NOTES 91
8 QUALITY ASSURANCE 91
8.1 Unit Test 91
8.2 Code Review 92
9 APPENDIX 93
9.1 New Standards 93
9.1.1 Shared Objects 93
9.1.2 Exception Handling 93
9.1.3 Switch Framework 93
9.1.4 New BADI’s 93
9.1.5 Developing Persistence 94
9.2 Tips and Tricks 94
9.3 Useful transactions 94
9.4 Useful Links 95
9.5 Management of Interface Files 95

9.5.1 Purpose 95
9.5.2 Audience 96
9.5.3 Summary 96
9.5.4 Technical Design Guidance 96
9.5.5 Interface File Location 96
9.5.6 Logical Location 97
9.5.7 Retrieving physical name within custom developments 97
9.5.8 Further processing for local audit 98
9.5.9 Special requirements for manually downloadable outbound files 98

Status: Draft
9.6 Send emails from SAP 99
9.7 Viewing and Maintaining Tables 99

9.7.1 Viewing Tables 99
9.7.2 Maintaining Tables 100
9.8 Customer Name Ranges Summary 102

Status: Draft
1 INTRODUCTION
1.1 Purpose
The purpose of this handbook is to define the standards and guidelines for custom ABAP development
that is valid in both operational (Application Management) and non-operational (Project) related
environments. The use of a universal set of standards and guidelines supports a consistent approach to
software development. The benefits of such an approach are:
 Increased ease-of-maintenance for support operations

 Reduction of development effort.
 Promotion of synergies in the development process between project initiatives and SAP
Support
 Avoidance of unnecessary rework.
Whilst this handbook is being issued to the Projects and SAP Support, 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
 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 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

Status: Draft
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 (e.g.: Number of users involved,
data volume, complexity).
1.5.2 Don’ts
 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 etc in an include for executable programs X
Use meaningful names (for example, use “g_material” not “g_m”) . Use glossary terms (for X
example, “g_company_code” not “g_bukrs”)
Use underscores (“_”) to separate the different words in compound names X
Write inline comments and documentation in English X

Write inline comments “as though you were explaining the program to a colleague” X
Use a maximum of one statement per program line X

Use Pretty Printer 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

Status: Draft
Run Code Inspector (SCI) X
Build with reusability in mind. Encapsulate reusable functionality in OO classes and function
modules.
Divide large unit of code into Form 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 ‘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
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
Status: Draft
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
consideration, otherwise the rule is - “maintainability before runtime optimization”
Avoid calling external form routines - call function modules instead whenever possible

Status: Draft
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.

Status: Draft
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 “SCII”) will be used to check whether
programs adhere to naming conventions or not. (A Global Variant will be created called
‘SSC_DEFAULT’ to aid the developers.
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. 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

BA Basis
CA Cross Application
CO Controlling
EH Environment, Health & Safety Management
FI Financial Accounting
HR Human Resources
IM Investment Management
MM Materials Management
PM Plant Maintenance
PP Production Planning
PS Project Systems
QM Quality Management
SD Sales & Distribution
SE Security
TE Test programs
TR Treasury
Status: Draft
Status: Draft
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 object:
General
 Check whether a suitable DDIC object already exists before creating a new one.
Data Element Design
 Documentation at the data element level should make use of the long text facility to make on-
line help effective.
Transparent Table Design
 Ensure that Client (MANDT) is utilised when creating a new table.
 Foreign keys referencing SAP table primary keys are highly recommended.
 Technical settings (SE13) should be maintained on all custom tables created (Consult the
BASIS team for assistance with the technical settings).
 The table maintenance dialogue facility (ZSM31) permits a user to maintain data directly in a
Client. Data that is purported to be static and crucial to a process may necessitate the
activation of table logging for audit purposes. An example of such data would be FAL limits.
Each requirement needs to be discussed with the functional owner to determine whether it is
warranted.
 Table logging is a standard SAP feature that records changes to table data. This system
feature is enabled in the EDF Production environment.
o In a table’s technical settings the log data changes indicator is used to enable logging
for that table.
o Logs can be viewed using transaction SCU3.
 Non-dialogue maintained table entries should include at least a stamp for the user and date. A
reason code for the change may also be applicable.
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
Status: Draft
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.
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.

Status: Draft
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

Status: Draft
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.
Open (use table name if < 7 characters)

Separator “_”
Process
Area
Customer
space
identifier -
‘EZ’
Example: EZHR_REGION

Status: Draft
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

Status: Draft
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

Status: Draft
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

Status: Draft
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'.

Status: Draft
 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’.

Status: Draft
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.

Status: Draft
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
Status: Draft
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

Status: Draft
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

Status: Draft
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 via the ABAP Development Workbench. Every online transaction in
SAP is associated with a transaction code. (Information about Transaction Codes is 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. (Table TSTCP contains the attributes for
“Transaction Parameter”).)
A Transaction Code can not be more than 20 characters. The naming convention for bespoke
Transaction Codes is as follows:
 First character is ‘Z’.
 Second and third characters are reserved for the Process Area.
 The fourth character is reserved to indicate Function.
o “D” is to be specified for a display-only function.
o “U” is to be specified for maintenance-related functions. IE create, modify, delete
 The remaining characters are freely assignable.
Format: A BB C DDDDDDDDDDDDDDDD
Open (any alphanumeric identifier)
Function
Process Area
Constant ‘Z’
Example: ZCOD_B2C_SPEND_EVAL - Expenditure List Rpt for B2C Mgrs

Status: Draft
3.4 Forms
3.4.1 SAPscript/Form Painter
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.
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/Interactive 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
3.4.3 ALE & IDocs

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
Status: Draft
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
DD
Open (Description) – Idoc segment
name
Separator “_”
Application /
Process Area
Status: Draft
‘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’

Status: Draft
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.
This area will at a later stage be enhanced.
3.4.4.1 Workflow Template

Example: ZMMWMMCREATE (demotes custom developed master
workflow template for material management
Max Length: 12 Characters
Naming Convention:
Position Usage
1 “Z” Application programs that will be moved to production.
2-3 SAP Functional Area/Module (refer to Appendix B).
4 Workflow type (‘W’ for Master workflows ‘S’ for Sub workflows).
5 - 12 Alphanumeric unique identifier
3.4.4.2 Standard Task

Example: ZMMTMatDisp (denotes a custom developed standard task
under Material Management.)
Max Length: 12 Characters
Naming Convention:
Position Usage
4 Task type (‘T’ for task).
3.4.4.3 Objects (in the BOR)

In R/3, object types are not client specific. Object types developed in one client are
available and useable in all other clients.
Note: whenever possible, objects should be delegated to the super object (with the
super object referenced in the workflow).
Where object is reference to a super object:

If a business object is created as a subtype of an existing object, then the name can be
Zxxxxxxxx where xxxxxxx stands for the standard SAP object name.
For new objects

Status: Draft
Naming Convention:
Position Usage
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.
As general rule a Package/Development class should be created for each new major project.
Notwithstanding this, 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.
Format: A BB CCC
Open (any
alphanumeric
identifier)
Process
Area
Constant ‘Z’
Example
ZHR001
Status: Draft
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
Constant
‘Z’
Example: ZPS01

Status: Draft
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.
Status: Draft
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
3.7 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

Status: Draft
3.7.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.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:
 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
Status: Draft
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
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.
Status: Draft
 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
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>

Status: Draft
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.

Status: Draft
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:
Status: Draft
 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:
 Enter transaction code SCII variant SCC_DEFAUL.T

Status: Draft
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 the ABAP coding standards. The purpose of these standards is to:
 Promote a consistent set of practices among developers. That means developers on the same
project and developers on different projects follow the same set of coding conventions.
 Emphasise the importance of program documentation and style to the overall standard. Programs
should be documented and styled to the extent that another developer can pick 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.
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:

Status: Draft
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”.
 Redundant 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
 Each program type (Programs/Function Modules/BAPI’s/Enhancement types) should have a

header comments block that contains an initial creation section and a revision section.
*&---------------------------------------------------------------------*
*& 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 *

Status: Draft
*& ---- ---- ------ ----------- *
*& 0000 15/08/11 J Waller Initial Implementation *
*& Correction No. : N/A *
*& Transport Request : DEVK900169 *
*&---------------------------------------------------------------------*
Every subsequent correction must be documented in the revision log section of the header comments
block. Not only do these log entries provide auditability but also allows for “at a glance” version
comparisons between different environments rather than via remote comparisons.
An example 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. SAP Standard Version Control will be utilised to keep track of the changes.

Status: Draft
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.
*----------------------------------------------------------------------*
* 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.
IF sy-subrc = 0.
p_layout = tkesk_cons_log-layout.
ENDIF.
*----------------------------------------------------------------------*
* Main program (Main function block)
*----------------------------------------------------------------------*
START-OF-SELECTION.
Status: Draft
* 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'.
...

Status: Draft
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
standards for well-defined variable names. (Local declarations will be identified with
an “l_” prefix.
o Global variables must be visible within the scope of the subroutine. Global variables
may be accessed as actual parameters via the subroutine’s formal interface.
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.
…

Status: Draft
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

Status: Draft
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
Status: Draft
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.
Status: Draft
 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.

Status: Draft
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
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.
Status: Draft
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.
 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.
Status: Draft
 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,

GC_TRUE TYPE C VALUE ‘TRUE’,
GC_FALSE TYPE C VALUE ‘FALSE’.

Status: Draft
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.

Status: Draft
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 GT_TAB OCCURS .X..

END OF GT_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 GT_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-

Status: Draft
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.
E.G: SELECT * FROM PA0000.
…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.

Status: Draft
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 8. PERFORM PV8. PV8.
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 SQL statements are construction within an ABAP program will have an affect on 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 database and application server.
 Minimise the amount of data to be transferred between the database and application server.
 Minimise the workload of the database.

Status: Draft
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.
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.
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.

Status: Draft
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.
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.
Status: Draft
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 clause is restricted to when the primary key is fully
qualified. Otherwise, store the data in an internal table and use the ABAP SORT statement.
Order by with index Order by without index

SELECT * FROM SPFLI ORDER BY SELECT * FROM SPFLI ORDER BY
PRIMARY KEY. AIRPFROM AIRPTO.
ENDSELECT.
6.7.2.2 Changing Data
Use array operations instead of single-row operations to modify 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.
Use column-specified table updates instead of entire row updates.. Network load can then be
considerably less.

Status: Draft
Single-line updates Column update
SELECT * FROM SFLIGHT. UPDATE SFLIGHT
SFLIGHT-SEATSOCC = SET SEATSOCC = SEATSOCC - 1.
SFLIGHT-SEATSOCC - 1.
UPDATE SFLIGHT.
ENDSELECT.
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.
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'
Status: Draft
WHERE SPRSL = 'D' AND ARBGB = '00'
AND ARBGB = '00' AND MSGNR = '999'.
AND MSGNR = '999'.
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.
When loading data into Internal table, INTO TABLE OR APPENDING TABLE is used instead of a
SELECT/APPEND combination.

Status: Draft
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 purposes. MOVE-

CORRESPONDING is used only when two tables have different field structures.
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.
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.

READ TABLE TAB_DEST WITH APPEND TAB_SRC TO TAB_DEST.
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.
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

READ TABLE TAB_DEST WITH COLLECT TAB_SRC INTO TAB_DEST.
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.
Status: Draft
ELSE.
INSERT TAB_SRC INTO TAB_DEST INDEX
SY-TABIX.
ENDIF.
ENDLOOP.

Status: Draft
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.
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.
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.
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
Status: Draft
* 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.
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.

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.
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
Status: Draft
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.
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.
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.
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.

Status: Draft
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.
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.
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 …
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 …
500 bytes 500 bytes
* each, 250 of which match the WHERE condition * each, 250 of which match the WHERE
condition
Status: Draft
LOOP AT TAB_DEST WHERE K = KVAL. DELETE TAB_DEST WHERE K = KVAL.
DELETE TAB_DEST.
ENDLOOP.
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.
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
Status: Draft
IMPORTING
STRING = CLA
EXCEPTIONS
TOO_SMALL = 01.
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.
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.
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.
Status: Draft
"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 ' *'.
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
Status: Draft
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.
Status: Draft
 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.
Status: Draft
 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)
See separate document.
6.9 Enhancements & Modifications

Adaptation of SAP standard is an important concept to understand. Adaptation entails the possibility to
make adjustments in accord with a customer’s requirements and the preservation of those adjustments
during an upgrade. Because there is a range of options available in the SAP system this section 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. Also referred to as Configuration.
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 advent of the new Enhancement concept
(Enhancement Framework) reduces the scope for Modifications.
Custom developments can be realised through various instruments. An overview is given in the
following table.
Table 2: Implementation Possibilities

DESIGN IMPLEMENTATION
POSSIBILITIES POSSIBILITIES
With Without
Enhancement  With standardised interfaces (BAdIs  Without standardised
or Customer Exits) interfaces (implicit
enhancements, explicit
enhancements, user exits)
Modification  With tools that assist the  Without tools that assist
modification the modification
Custom  With reference to SAP objects  Without reference to SAP

Status: Draft
(Clone) in customer namespaces objects (Standard
applications, Composite
applications) in customer
namespaces
The approach to adaptation should be to first exhaust all Customization possibilities. Where
Customization is not flexible enough to satisfy a business requirement then Enhancement options
should be investigated. The use of Modification should be avoided because the total cost of ownership
is higher than that of an Enhancement option.
The enhancement decision can be made based on the following order:
The Enhancement concept provides a framework to enhance core source code without Modification.
The basic mechanism is to offer the enhancement options that function like “hooks” where you can
attach the enhancements.
There are different kinds of technologies that provide 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

Status: Draft
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,
 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 DDIC 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
The Append technique permits the enhancement of a transparent table or structure in a modification-
free manner which 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.
Status: Draft
 SAP may make available one or more pre-define append structures names available for use at
the time of creation.
 Customer Append structures are not permissible for Pool tables and Cluster tables.
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.
The terms “Customer Include” and “Customizing Include” are used synonymously.
6.9.2.1.3 Views
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.
6.9.2.1.4 Domain Fixed Values
Additional values can be added to domains by creating a “Fixed Value Append”.
6.9.3 Modifying SAP database Tables:

Direct updates to SAP standard database tables using INSERT, UPDATE, MODIFY & DELETE are to
be avoided where ever possible through the use of standard/custom built Function Modules or BAPIs.
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, IDcs, 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
A SAP Online Service System (OSS) Note is a published response to a specific issue related to a SAP
product. A “Note” typically provides a source code correction to a standard object but may provide
other information such as answers to frequently asked questions.
Transaction code “SNOTE” automates the process of note download and implementation. A SAP note
should be applied using “SNOTE” when applicable.

Status: Draft
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 Unit test plan should be documented in the Functional/Technical Specification
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)
 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.

Status: Draft
9 APPENDIX
9.1 New Standards

9.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.
http://help.sap.com/saphelp_nwpi71/helpdata/en/14/dafc3e9d3b6927e10000000a114084/frameset.htm
9.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.
http://help.sap.com/saphelp_nwpi71/helpdata/en/cf/f2bbc8142c11d3b93a0000e8353423/frameset.htm
9.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.
http://help.sap.com/saphelp_nwpi71/helpdata/en/83/d2934258a5ca6ae10000000a155106/frameset.htm
9.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.
http://help.sap.com/saphelp_nwpi71/helpdata/en/fc/7e94422760c46ae10000000a155106/frameset.htm
Status: Draft
9.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.
http://help.sap.com/saphelp_nwpi71/helpdata/en/e4/2adbce449911d1949c0000e8353423/frameset.htm
9.2 Tips and Tricks

This section contains general hints.
Transaction / Report Description
SE83 Re-usable library

ABAPDOCU Example Library
SLIN Enhanced syntax check
SCII Code Inspector: Inspection
DWDM Demo Examples
ABAPHELP Keyword Documentation
SE30 and “Tips &Tricks” Performance Tips
Report - SHOWICON ICON List
Report - SHOWCOLO Colors List
Report – BC* Examples
9.3 Useful transactions

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
Status: Draft
BD87 IDOC Status Monitor
BAPI BAPI Explorer
SFP Interactive Forms
9.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
9.5 Management of Interface Files

9.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.
9.5.2 Audience
 Functional Consultants
 Technical Designers
9.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.
9.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
Status: Draft
 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.
9.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/<INTERFACE_NAME>/IN
Outbound files: /INTERFACES/<INTERFACE_NAME>/OUT
Where:
/INTERFACES/ is a mounted file system on the appropriate NFS server
(Development, Test, Production).
<INTERFACE_NAME> is the name of the interface e.g. “thamescard”
9.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_BENEFEX_IN” to the physical location
“/INTERFACES/BENEFEX/IN”
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.
9.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
Status: Draft
logical_filename = G_fname
operating_system = sy-opsys
IMPORTING
file_name = p_fname
EXCEPTIONS
file_not_found = 1
OTHERS = 2.
Where “G_fname” is the logical file location, and

“p_fname” is the return physical file location
Using the previous example if G_fname = “Z_BENEFEX_IN” the function module would return
“/INTERFACES/BENEFEX/IN/” in the ECC6.0 system.
For inbound files “IN/<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
“OUT/<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 ‘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.
9.5.8 Further processing for local audit

When an inbound file has been successfully processed it should be moved from the
“/INTERFACES/XXX/IN” directory to an ARCHIVE sub-directory – for example
“/INTERFACES/XXX/IN/ARCHIVE”.
If an inbound file has not been processed successfully it may be moved from the
“/INTERFACES/XXX/IN” directory to an error sub-directory - “/INTERFACES/XXX/IN/ERROR” -
depending on the functional requirements for error processing.
Note: As part of the inbound functionality, the program should also be developed to include the
functionality to delete any files from the ARCHIVE directory that are older than ‘Y’ Days (as defined
on the selection screen) ,
9.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/”.

Status: Draft
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.
9.6 Send emails from SAP

An example program has been created in CD1 detailing the how to send emails with Word and Excel
attachments. This program is called ZSKELTP07. Table ZHR_RECIPIENT currently holds email
addresses that are utilised by the different programs sending emails.
9.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.
9.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:
1
possibly based on existing EDF Energy program ZFILETRANSFER
Status: Draft
Table screen shot:

Status: Draft
Thus transaction ZSE16_AA will only allow table ANLA to be viewed, transaction ZSE16_MM will
allow tables ADRC, AUFM etc. to be viewed.
9.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
“Zifpcusttables”. 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:

Status: Draft
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.
9.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

Status: Draft
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

Status: Draft
Interface 30 Y* Z*
Class 30 Y* Z*
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
Status: Draft
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* HRT91* HRP91*
HRI91*
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*
Status: Draft
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*

Status: Draft

EDFE Corporate SAP - ABAP Developer Handbook v1.3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EDFE Corporate SAP - ABAP Developer Handbook v1.3

Uploaded by

Copyright:

Available Formats

SAP ABAP DEVELOPER

Version Date Author(s) Comments

Approver Role Signature

SAP ABAP Developer Handbook Page 2 of 92 Version: 1.1

1.3 Intended Audience 8

1.4 Application Architectural Standards 8

1.5 Good Development Practices 8

2 GENERAL PROGRAMMING RULES 8

3 SAP DEVELOPMENT NAMING CONVENTIONS 12

3.2 ABAP Dictionary 14

3.3 ABAP Program 21

SAP ABAP Developer Handbook Page 3 of 92 Version: 1.1

3.5 Background Jobs 37

3.6 Batch Input Sessions 38

3.8 Legacy System Migration Workbench (LSMW) 40

3.9 Naming Conventions for ABAP Objects 40

4 REUSABLE DEVELOPMENT OBJECTS REPOSITORY 45

5 SAP ABAP ANALYSIS TOOLS 45

6.2 Comments & Documentation 48

6.3 Layout and Formatting 54

6.4 Programming ABAP Objects 55

6.5 Dialog Program Standards 55

6.6 Reporting Standards 58

6.7 Performance Standards 67

6.8 Interface Standards 83

6.9 Enhancements & Modifications 87

8.2 Code Review 92

9.2 Tips and Tricks 94

9.3 Useful transactions 94

9.4 Useful Links 95

9.5 Management of Interface Files 95

SAP ABAP Developer Handbook Page 5 of 92 Version: 1.1

9.7 Viewing and Maintaining Tables 99

9.8 Customer Name Ranges Summary 102

SAP ABAP Developer Handbook Page 6 of 92 Version: 1.1

 Increased ease-of-maintenance for support operations

The following subjects are within scope:

The following subjects are excluded from scope:

1.3 Intended Audience

SAP ABAP Developer Handbook Page 7 of 92 Version: 1.1

1.5 Good Development Practices

2 GENERAL PROGRAMMING RULES

General Rules Rule

Write inline comments and documentation in English X

Use a maximum of one statement per program line X

Run enhanced syntax checks (SLIN) X

SAP ABAP Developer Handbook Page 8 of 92 Version: 1.1

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

Use TABLES statements only when absolutely necessary X

Rules for Form Routines and Function Modules Rule

SAP ABAP Developer Handbook Page 10 of 92 Version: 1.1

SAP ABAP Developer Handbook Page 11 of 92 Version: 1.1

3.1.1 Customer Name Space ID

3.1.2 Process Area/Application ID

Process Area / Application ID Description

3.2.1 Transparent Tables

Example: ZSHR_ COUNTRY

3.2.3 Table Fields

SAP ABAP Developer Handbook Page 15 of 92 Version: 1.1

Example: ZZREGION, ZZCOUNTRY

Example: ZZREGION, ZZCOUNTRY

3.2.7 Lock Objects

Open (use table name if < 7 characters)