ABAP Development Standards Guidelines Ve

Implementation of SAP
Suite of Applications & Internet

Solutions
“ABAP Development Standards &

Guidelines”
Version 1.2
April 2015
* GAIL Confidential
ABAP Dev Stds & Guidelines GAIL Confidential
Document Control
DOCUMENT INFORMATION
Title ABAP Development Standards & Guidelines

Project Phase Business Blueprint for Phase 1A
Author Priya Gupta, GAIL
File Name ABAP Development Standards & Guidelines _Ver 1.2.doc
Path Deliverables\ABAP Development Standards & Guidelines
Ver 1.2.doc (on File Server)
Created 20th Jan 2004
Last Edited 7th April 2015
Reviewed by Ashok Kumar
REVISION HISTORY
Version
Issue Date Change Details Approved by Authorised by
No.
1.0 16th Feb 2004 New Release Arjun Lahiri, IBM Anuj Jain, IBM
1.1 7th Apr 2015 Updates Priya Gupta,

GAIL Ashok Kumar, GAIL
TARGET READERSHIP
1. Project Manager, GAIL
2. Technical Lead, GAIL
3. Core Project Technical Team Members (GAIL & SAP)
Page 2 of 53
Table of Contents
1.1 Background _______________________________________________________________ 4

1.2 Objective __________________________________________________________________ 4
2. Object Naming Conventions ______________________________________ 5
2.1 Summary __________________________________________________________________ 5
2.2 Program Element __________________________________________________________ 10
2.3 Development Class _________________________________________________________ 11
2.4 ABAP Objects _____________________________________________________________ 12
2.5 Web Dynpro Objects Naming Convention ______________________________________ 20
2.6 ABAP development standards for GAILGAS ____________________________________ 22
2.7 ABAP development standards for SRM related developments in ECC ______________ 22
2.8 Naming convention for objects in SRM ________________________________________ 23
3. Program Specification Document Naming Conventions _______________ 24
3.1 Development Request (DER) IDs _____________________________________________ 24
4. General Guidelines for Programming ______________________________ 25
5. Coding Style __________________________________________________ 26
5.1 Documentation ____________________________________________________________ 28
5.2 Report Standard ___________________________________________________________ 29
5.3 Data Definition ____________________________________________________________ 31
5.4 Online Standard ___________________________________________________________ 32
5.5 Batch Programs / Interface Standards _________________________________________ 33
5.6 Message __________________________________________________________________ 34
5.7 Program Logic ____________________________________________________________ 35
5.8 Data Access ______________________________________________________________ 36
5.9 Index Design ______________________________________________________________ 39
5.10 Internal Table ____________________________________________________________ 40
5.11 String Operation __________________________________________________________ 47
5.12 Hardcoding ______________________________________________________________ 49
6. Appendix _____________________________________________________ 51
6.1 Module IDs ________________________________________________________________ 51
6.2 Program Type ID’s _________________________________________________________ 51
6.3 System Type ID’s __________________________________________________________ 51
6.4 Directory Structure _________________________________________________________ 52
6.5 File Naming Conventions____________________________________________________ 52
Page 3 of 53
1. Introduction
1.1 Background
GAIL (India) Limited (GAIL), a leading Public Sector Enterprise, is the largest gas
processing, transmission and marketing company in India. The company was
established as a wholly owned company of Government of India in August 1984 and
has grown to be ranked among the top ten companies in India.
The activities of company range from the Gas marketing and distribution through
trunk and regional pipelines system, Gas processing for production and marketing of
LPG, liquid hydrocarbons and polymer resin. Transportation of LPG through pipeline
is the latest addition to business activity.
GAIL has recently ventured in Telecommunication Sector, Exploration and

Production of Oil & Gas also.
GAIL wants to establish an integrated Information System architecture to enable its

organization to leverage information for competitive advantage in a deregulated
market scenario.
In order to help define the future information systems architecture and create
alignment around strategic information management, GAIL has planned for
implementation of mySAP suite of applications with e- Business solution, as the
backbone of its Systems architecture.
1.2 Objective
The objective of this document is to define guidelines for SAP technical developers
regarding development standards and naming conventions for GAIL mySAP project .
The document is based on:
 SAP’s Naming Convention for Development Objects
 Previous IBM SAP project implementation standards
Developing these standards prior to construction and adhering to them during

construction is especially helpful when addressing the following:
 Migration into a production environment
 Long-term maintenance of custom development
 Future upgrades
 Facilitating knowledge transfer for future SAP resources
Page 4 of 53
2. OBJECT NAMING CONVENTIONS
2.1 Summary
The following table summarizes the naming conventions described in this document. Each
SAP Object type is described in further detail in following sections. Note that capital letters
represent literals and should not be changed. Lowercase letters represent variable fields
which may take on some range of values described in the appropriate section.
Interface and data conversion programs require either reading of files from
application/presentation server or writing to files in application/presentation server. The file
naming conventions and directory
Structures are elaborated in appendix.
SAP Object Type Length Naming Convention

ABAP Programs 30
Ysacddd_xxxxxxxxxxxxxxxxxxxxxx
s – system id (see appendices)
a - Module Id (see appendices)
c – Program Type Id (see appendices)
ddd – Running Serial No. 001 - 999
x – Open(Can be maximum up to 23 – Should be
descriptive and meaningful )
ABAP Report Include 30
YIsb_xxxxxxxxxxxxxxxxxxxxxxxx
b - Module Id (see appendices)
x - Open(Can be maximum up to 26 – Should be
descriptive and meaningful )
ABAP Report Variant 14
xxxx
x – Open
Transaction Codes 20
Ysac999
999 - number from 001 to 999
ABAP Module Pools 30
SAPxYsannnnnnnnnnnnnnnnnnnnnnnn
x – Type of module pool
M – Screens
L – Function Module
F – Subroutines
D – Dialog
a – Module Id (see appendices)
n – Descriptive Text
ABAP Module Pool 30
xYsannnnnnnnnnnnnnnnnnnnnnnnTOP – Top
Includes
include
xYsannnnnnnnnnnnnnnnnnnnnnnnOyy – PBO
Page 5 of 53

module
xYsannnnnnnnnnnnnnnnnnnnnnnnIyy – PAI
Module
xYsannnnnnnnnnnnnnnnnnnnnnnnFyy -
Subroutines
M – Screens
F – Subroutines
D – Dialog
Dynpros (Screens) 4
9nnn
nnn – Numeric between 000 and 999
Web-dynpro applications 30
YsaWddd_xxxxxxxxxxxxxxxxxxxxxx
W – w signifies it is a web-dynpro application
ddd – Running Serial No. 001 - 999
x – Open(Can be maximum up to 23 – Should
be descriptive and meaningful )
Adobe Forms 30
YsaF_xxxxxxxxxxxxxxxxxxxxxx
F – f signifies it is a adobe form
x – Open(Can be maximum up to 25 – Should
be descriptive and meaningful )
Interface of Adobe form 30 YsaF_xxxxxxxxxxxxxxxxxxxxxx
I – i signifies it is an interface
x – needs to be exactly the same description
as used in the corresponding adobe form of
this interface.
SPA/GPA Parameters 3
Yxx
x – Descriptive Text
Batch Job Requests 32
Y_bb_sa_xxxxxxxxxxxxxxxxxxxxxxxxx
bb – Frequency Indicator
hr - Hourly
Page 6 of 53

da – Daily
wk – Weekly
mn – Monthly
qt – Quarterly
an – Annually
re – On Request
a – Module ID (see appendices)
Batch Input Sessions 12
Ysacddd_SSnn
(BDC Sessions)
ddd – Running Serial No. 000 – 999
(The part Ysacddd should be same as that of the
program which creates the session)
nn – Running Serial No.
Area Menus 20
Ysaxxxxxxxxxxxxxxxxxx
Function Key Codes 4
xxxx
x – Open
GUI Status 4
xxxx
x - Open
Titlebars 3
xxx
x – Open
Tables , Structures 16
Ysab_xxxxxxxxxxxx
b - Table Type
X – Cross Reference Tables(Transparent)
A – ApplicationTables(Transparent)
P - Pooled table
C - Cluster Table
S - Structure
Views 16
Ysab_xxxxxxxxxxxx
a – Module Id. (see appendices)
b - View Type
D - Database View
P - Projection View
M - Maintenance View
Page 7 of 53

H - Help View
x - Descriptive Text
View description should contain table names .
Table Fields 16
YYxxxxxxxxxxxxxx
xx – Descriptive Text
xxxxxxxxxxxxxxxx (Attached to custom tables)
Data Elements 30
YYxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x- Descriptive Text
Should use the same name in both Domain ,Data
Element and field
Domains 30
x- Descriptive Text
Should use the same name in both Domain ,
Data Element and field
Search Helps 30 Ysab_xxxxxxxxxxxxxxxxx
a Module Id (see appendices)
b Type
E – Elementary
C – Composite
x descriptive text
Lock Objects 16
EY_xxxxxxxxxxxxx
x Primary Table Name (where multiple Lock
Objects are required for the same primary table,
assign a unique digit to the final position )
Function Groups 26
Ysa_xxxxxxxxxxxxxxxxxxxxxxx
a Module ID (see appendices)
x Descriptive text
Function Modules 30
Ysa_xxxxxxxxxxxxxxxxxxxxxxxxxxxx
x descriptive text
Message Classes 4
Ysax
x Running Serial Number
Message Number 3
nnn
nnn – Number Interval 001 – 999
Layout Sets 16
Ysabb_xxxxxxxxxx
(Smartforms)
Page 8 of 53

bb Sub Module Id (see appendices)
x Descriptive text
Standard Texts 32
Ysa_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x descriptive text
Styles 8
Ysa_999
9 Number from 001 to 999
Text Modules 8
Ysa_999
9 Number from 001 to 999
Page 9 of 53
2.2 Program Element
This section talks about the naming standards of elements used within a program.
Program Element Use Syntax

Internal Tables Internal tables: Standard I_*
Internal tables: Sorted IS_*
Internal tables: Hashed IH_*
Copy of database table IY_* or IZ_*
Structures Intermediate Storage X_*
Work Area Work Area WA_*
Screen Elements Radio Buttons RB_*
Push Buttons PB_*
Check Boxes CB_*
Types General TY_*
Constants General C_*
Parameters (all kinds) General P_*
Ranges General R_*
Forms General Open
Select Options General S_*
Variables Global W_*
Local L_*
Flags General FLAG_*
Counters General COUNT_*
Sum General SUM_*
Note: The asterisk in the table above signifies a descriptive name which can be chosen by
the developer. An underscore (_) can be used to connect multi-word variable and multi-world
FORM names.
Page 10 of 53
2.3 Development Class
Development Classes group together development objects (e.g. programs, tables, function
modules) which can be corrected and migrated together across instances. A 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.
All custom development should be assigned to a custom development class. Temporary
objects may be assigned to class ‘$TMP’. Objects defined under $TMP development class
will not be migrated. Objects created under development class $TMP should start with
Z, instead of Y .Rest of the naming conventions remain same . Objects created under any
other development class should start with Y and conform to the naming standards already
specified.
These development classes will be used for any development .All custom developments
should be assigned to the proper development class depending on which module they
belong to.
Class Description
$TMP Local Objects (not
migrated)
YV01 Sales & Distribution
YM01 Materials Management
YF01 Financial Accounting
YH01 Human Resources
YN01 Controlling
YI01 Plant Maintenance
YP01 Production Planning
YC01 Project Systems
YQ01 Quality Management
YX01 Cross Application
YS01 Basis
YB01 BW related objects
Page 11 of 53
2.4 ABAP Objects
ABAP Program
The maximum length of an ABAP program name is 30 characters. SAP requires that the
first character begin with a ‘Z’ or ‘Y’. For all programs in this project the first character will be
always a ‘Y’. The second character signifies the system id. The third character signifies the
module id. The fourth character signifies the program type as explained in the appendix. The
next 3 characters will contain a running serial number .The rest of the characters of the
program name are open for any alphanumeric string. Ideally, they should constitute a
descriptive and meaningful text with underscores separating different words.
Ysacddd_xxxxxxxxxxxxxxxxxxxxxx
s - System ID (see appendices)
c – Program Type ID (see appendices)
ddd – Running Serial Number
x – Open
ABAP Report Include
For all report include programs in this project the first character will be always a ‘Y’. The
second character will be ‘I’. The third character will signify the system Id. The next character
will identify the Application process ID, which comprises of Module ID .The rest of the
characters of the program name are open for any alphanumeric string. Ideally, they should
constitute a descriptive and meaningful text with underscores separating different words.
YIsb_xxxxxxxxxxxxxxxxxxxxxxxx
b – Module Id (see appendices)
x – Open
Report Variant
When an ABAP report is created, some database-specific selections can be generated 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.
The maximum length of an ABAP variant is 14 characters. Report Variants can be any free
text.
Transaction Codes
Transaction Codes are created either through ABAP Development

Workbench/Development/Other Tools/Transactions or if you are developing a module pool,
transaction code can be created there itself. Every transaction in SAP contains a unique
transaction code. Information about all transactions 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.
Page 12 of 53
A transaction code can be up to 20 characters. For GAIL mySAP project , transaction codes
will be limited to a length of 7. The first character will be Y, the second will be the system id,
the next will be module id and the rest three will be a running serial number.
Ysac999
a - Module id (see appendices)
c - Program Type ID (see appendices)
999 – number from 001 to 999
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 can be up to 30
characters long and must begin with ‘SAPxY’ (where x can be ‘M’ for screen modules, ‘D’ for
dialog modules, ‘F’ for subroutine modules and ‘L’ for Function Modules). The next character
represents the System id followed by Module ID and the rest of the positions contain a
descriptive text.
SAPxYsannnnnnnnnnnnnnnnnnnnnnnn
M – Screens
F – Subroutines
D – Dialog
s - System ID
a – Module Id
Example
SAPMYRV01
Module Pool Includes
Naming conventions for Module Pool components must also adhere to SAP standards. A
table below is provided for detailed conventions using the above example.
‘L’ for function modules

‘M’ for screen modules
‘D’ for dialog modules
‘F’ for subroutine modules
s – system id
a – Module Id
(Note: xYsann in conventions below should match xYsann in main Module Pool name).
Module Pool Component Naming convention

Type
Data Definition (Global
xYsannTOP (MYRV01TOP for above example)
Data Include) Module
Process Before Output
xYsannOyy (MYRV01O01 for above example)
(PBO) Module
Process After Input (PAI) xYsannIyy (MYRV01I01 for above example)
Module
Performs (subroutines) xYsannFyy (MYRV01F01 for above example)
Page 13 of 53
Process On Help-Request xYsannHyy (MYRV01H01 for above example)

(POH) Module
Process On Value- xYsannVyy (MYRV01V01 for above example)
Request (POV) Module
Remarks: It is strongly recommended that the ‘SAP Workbench’ is used to construct module
pools. The SAP Workbench is designed to enforce standard naming conventions.
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.
The identification of a screen painter dynpro consists of an ABAP program name and a 4-
digit dynpro number. The number range reserved for dynpros is between 9000 – 9999. The
initial screen number for a given transaction should be 9000 and additional screens numbers
increment by 1. If there are any pop up screens their number should be maintained as an
increment of 1 on the main screen no.
Example
Module Pool: SAPMYRV01
Screen #: 9000
SPA/GPA Parameters
A field can be filled with proposed values from SAP memory using a parameter ID. These
have to be mentioned as field attributes in a module pool program.
Yxx
Batch Job Requests
The maximum length of a batch job request is 32 characters. Batch job requests should
adhere to the following naming convention:
Y_bb_sa_xxxxxxxxxxxxxxxxxxxxxxxxx
bb – Frequency Indicator
hr – Hourly
da – Daily
wk – Weekly
mn – Monthly
qt – Quarterly
an – Annually
re – On Request
a – Module ID
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. ABAP provides a 12 digit field for naming a
batch input session .
Page 14 of 53
Ysacddd_SSnn
ddd – Running Serial Number
nn – Running Serial Number
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 application area can also be
accessed via transaction code S001. The area menu name is the transaction code S001.
The maximum length of an area menu is 30 characters. ( Menu path - Sap menu>
development> other tools> area menu or transaction code SE43N . If modifying standard
area menu keep the standard menu name in ‘enhancement id’ for easy maintenance)
Ysaxxxxxxxxxxxxxxxxxx
a – Module Id
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
For user defined function codes , the following codes have to be used.
xxxx
x – Open
GUI Status
GUI is used to give a name to a GUI status in a report or on-line program.

xxxx
X – open
Page 15 of 53
Titlebar
Titlebar provides heading to a window. The content can be dynamically changed as per
requirement.
xxx
x – Open
Tables / Views / Structures
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 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 structure is defined like a table, but it does not store records in the database. Structures
can be shared by multiple ABAP programs.
The table and view name can be up to 16 characters long, whereas a structure can be of a
length of 30 characters. All custom created Tables, Views and Structures will be maintained
at length of 16 for this project. The first character should be ‘Y’. The second character
should reflect the System Id and third the Module ID. The fourth character will determine the
table type or view type. The remaining characters are open and should be as descriptive as
possible.
Ysab_xxxxxxxxxxxx
a – Module Id
b - Table Type or View Type
Table Fields
Field names in SAP tables can be up to 16 characters. Whenever a field is added to an SAP
supplied table, the convention followed is to start with ‘YY’ and then add some descriptive
text, whereas for custom defined tables the naming convention is open.
YYxxxxxxxxxxxxxx (Attached to SAP delivered tables)
xxxxxxxxxxxxxxxx (Attached to custom tables)
Data Elements
A data element is a semantic description of a field. It provides a precise description of the

function of a domain in a specific business context for the fields that depend on it. The
maximum length for a data element is 30 characters. The first two characters must be ‘YY’
and the remaining 28 characters can be arbitrarily assigned.
x- Descriptive Text
Should ideally use the same name in both Domain and Data Element which again should be
same as the field .
Domains
Page 16 of 53
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.
The maximum length of a domain is 30 characters. The first two characters must be ‘YY’
and the remaining 28 characters can be arbitrarily assigned.
x- Descriptive Text
Should ideally use the same name in both Domain and Data Element which again
should be same as the field .
Search Helps
As of SAP R/3 release 4.0, Matchcode Objects have been replaced by Search Helps. The
search help concept simplifies and extends the past options for defining an input help
(matchcode). Search Helps must begin with the letters ‘Y’ or ‘Z’ and can be up to 30
characters long.
Note: Search Helps are ABAP dictionary objects and can be created at any point in the
Repository Browser.
Search Helps are linked to data elements, check tables and structure fields. You can also
define default values for input parameters using Search Helps. Search Help Exits are
function modules that allow you to change the appearance and functionality of how the
Search Help appears to the user, however it is recommended by SAP not to overuse Search
Help Exits to preserve the integrity of regular Search Help process.
Note: Several Search Helps can be combined to form a collective Search Help. The user
can then choose between several search options in the input help, as was the case for
matchcodes.
Ysab_xxxxxxxxxxxxxxxxx
s System ID (see appendices)
b type
E – Elementary
C – Composite
x descriptive text
Lock Objects
Lock objects control simultaneous access to a particular table entry by two update users.
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.
Lock object names can be up to 16 characters long and should start with the prefix ‘EY_’.
The remaining characters are open to the developer.
EY_xxxxxxxxxxxxx
x Open (where multiple Lock Objects are required for the same primary table, assign a
unique digit to the final position )
Function Groups
SAP function modules are programs written in ABAP that can be called by any ABAP
program or the function modules themselves. They are managed centrally in the function
library, which provides search, display, maintenance and printing capabilities for all standard
and custom function modules.
Page 17 of 53
Function modules are grouped together using function groups. SAP supplied function
groups should never be assigned to new function modules.
Function group names are 26 characters long and should start with a ‘Y’. The next character
will store the System Id followed by the Module ID. The remaining characters are open.
Ysa_xxxxxxxxxxxxxxxxxxxxxxx
x descriptive text
Function Modules
The function module name can be up to 30 characters long and should begin with ‘Y_’. This
will differentiate custom created function modules from standard SAP function modules. The
remaining characters should reflect the nature of the function. Underscores are used to
separate words.
Ysa_xxxxxxxxxxxxxxxxxxxxxxxxxxx
x descriptive text
Messages Classes and Number
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 20 character message class and a 3 digit message number. The
first character of the message class should be a ‘Y’ and the second character will contain the
the Module ID. The remaining characters are open. The message number is open to any
number between 000 and 999.
For GAIL mySAP project, we will use four digit message classes where the last 2 digits will
be a running serial number . We will have separate message classes for each module .
Message Class:
Ysaxx
x Running serial number .
Message Number:
nnn
nnn – Number Interval 001 – 999
Message Description
Class
YV01 Sales & Distribution
YM01 Materials Management
YF01 Financial Accounting
YH01 Human Resources
YN01 Controlling
YI01 Plant Maintenance
YP01 Production Planning
YC01 Project Systems
YQ01 Quality Management
YX01 Cross Application
YS01 Basis
YB01 BW
Page 18 of 53
Layout Sets
A layout set in SmartForms is used for page layout. The layout set contains various
elements used for layout control. A layout set definition contains the following elements:
Header Data, Paragraphs, Character Strings, Windows, Pages and Page Windows.
The layout set name can be a maximum of 16 characters. It should start with a ‘Y’. This is
followed by the System Id and Module ID. The remaining characters are open to any
alphanumeric combination.
Ysa_xxxxxxxxxxx
x Descriptive text
Standard Texts
x Descriptive text
Styles
A style defines the set of paragraph and character formats that are available for formatting a
document.
A typical style contains, for example, a definition for a standard paragraph, list paragraph
formats, and possibly special-purpose paragraph formats for headings, data in forms, and so
on. A style also usually defines such character formats as boldface, italics, and so on. You
can select from these formats to format your document. If you select a style, this style
provides the character and paragraph formats for your document. Any formats defined in the
form selected for a document are ignored.
Style Names can be up to 8 characters. They must begin with either a ‘Y’ or ‘Z’. For GAIL
mySAP project, the style name will start with a ‘Y’.This is followed by the system id, module
id and then by a running serial number.
Ysa_999
S System ID (see appendices)
Number from 001 to 999
Text Modules
You use Text Modules to centrally store texts in the system that you frequently use in
Smartforms
S System ID (see appendices)
x Descriptive text
Page 19 of 53
2.5 Web Dynpro Objects Naming Convention
Example
Object Type Naming Convention
Web Dynpro Application ZWDA_MyFirstApp

<namespace>WDA_<name>
Web Dynpro Component

<namespace>WDC_<name> ZWDC_MyFirstComp
Web Dynpro Assistance Class <namespace>CL_AST<nam ZCL_AST_Class

e>
Window W_<name>
Popup Window W_POPUP_<name>
View V_<name>
Component Usage U_COMP_<used_comp> U_COMP_SALV_XXX
IP_<name>
Inbound-Plug/Outbound-Plug
OP_<name>
LV_COUNTER
Controller LV_<name> LS_STRUCTURE
LS_<name> LT_TABLE
LT_<name> LO_MSG_MANAGER
Attributes LO_<name> LO_POPUP_XXX
Page 20 of 53
Web Dynpro Application & Component Configuration

(for Floor Plan Manager/FPM)
Example
Application Configuration <namespace>APP_CFG_<na ZAPP_CFG_<name>

me>
OIF Component configuration ZAPP_CFG_<name>_OIF

<namespace>APP_CFG_<na
(Object Instance Floorplan)
me>_OIF
GAF Component
configuration <namespace>APP_CFG_<na
ZAPP_CFG_<name>_GAF
(Guide Activitity Floorplan) me>_GAF
CMP_CFG_<name>_IDR
IDR Component configuration
<namespace>APP_CFG_<na
(Identitification Region) ZAPP_CFG_<name>_IDR
me>_IDR
Web Dynpro View Elements

Some common ones are listed here as references.
Example
Button BTN_<name>
ButtonRow BTR_<name>
Caption CPT_<name>
DropDownByIndex DDI_<name>
DropDownByKey DDK_<name>
Group GRP_<name>
HorizontalGutter HOG_<name>
InputField INP_<name>
Label LBL_<name>
LinkToAction LTA_<name>
Page 21 of 53
LinkToURL LTU_<name>
RadioButton RBT_<name>
RadioButtonGroupByIndex RBI_<name>
RadioButtonGroupByKey RBK_<name>
Table TBL_<name>
TextEdit TXE_<name>
TextView TXV_<name>
TransparentContainer TCO_<name>
Tray TRY_<name>
Tree TRE_<name>
TreeNodeType TNT_<name>
TreeItemType TIT_<name>
ViewContainerUIElement VCU_<name>
Tabstrip TBS_<name>
Tab TAB_<name>
2.6 ABAP development standards for GAILGAS
▪ ALL objects will follow a begin with ‘ZGGL’ .Exclusions are Tcodes and Development Class
▪ ALL Tcode’s and Development class will begin with ‘Z’ instead of ‘Y’ for Gail Gas
▪ All other standards to remain as per GAIL’s naming convention.
2.7 ABAP development standards for SRM related developments in ECC
The use of existing SRM package YSRM to be discontinued. Going forward all SRM related
developments in ECC are to be made in the package YM01 as per MM module naming
conventions.
Page 22 of 53
2.8 Naming convention for objects in SRM
Nomenclature Object Type
YGAIL_SRM Package
YSRMBI_<> Badi Implementation
Enhancement
YSRMEI_<> Implementation
YSRMCL_<> Class
YSRMT_<> Table
YSRMV_<> View
YSRMR_<> Abap Reports
YSRMWD_<> Web Dynpro
YSRMBSP_<> BSP Page
YSRMFG_<> Function Group
YSRMFM_<> Function Module
Page 23 of 53
3. PROGRAM SPECIFICATION DOCUMENT NAMING CONVENTIONS
3.1 Development Request (DER) IDs
For every custom development a program specification document will be created which will
contain the functional as well as the technical details of the custom development.
GAILsacddd
ddd – Running Serial Number from 001 – 999
Page 24 of 53
4. GENERAL GUIDELINES FOR PROGRAMMING
ABAP programs that update master and 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 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.
ABAP programs MUST NEVER be used to update configuration tables.

SAP-delivered ABAP programs, Screens, SAP transactions and Batch programs should
never be changed without the approval of the Development Team Leader (IBM) and Project
Manager (IBM). SAP approval will also generally be required. GAIL Project Manager should
also be informed. If it becomes necessary to modify one of these objects, then, if possible,
the object should be copied to a new name using SAP naming standards, and modifications
should be made to the copied object.
Before writing any code, it should be confirmed that no existing programs or function
modules, either custom or SAP-supplied, satisfy the coding requirements.
If custom coding is necessary and the code extract is accessed by different programs ,it
should be stored in a central library. Function modules are an example of this approach.
When performing modifications and user exits, it is good programming practice to put all new
entries in an include and then call the include from the SAP object. This applies to program
code as well as tables and structures. This technique reduces the disruption to others
working on the system while the programmer is performing the modification. It also makes it
easier to re-implement the work after an upgrade, where the SAP object has been
overwritten.
The use of key-word “CLIENT SPECIFIED” is forbidden under normal circumstances.

In case of special business requirements, an entry needs to be made in the table
“YRHA_CLIENT_SPEC” for the corresponding program where this keyword is used.
The number of licenses for Interactive Adobe Forms is limited. In order to judicially use
these limited licenses of Interactive Adobe forms, setting fillable property of any adobe form
to ‘X’ i.e “fillable = ‘X’” requires an additional entry in the table “YRHA_INT_ADOBE” to
ensure that the developer actually wants to create an interactive adobe form and is not
setting the fillable property by mistake.
Page 25 of 53
5. CODING STYLE
Standard:
ABAP is an event driven programming language. However, proper program structure and
modular coding are still important to maintain readability and efficiency of an ABAP program.
A program should be divided into distinct sections, which are properly documented in the
code. Whenever possible, existing function modules should be used instead of creating
new ones.
Descriptive names should be used for forms (sub routines) like:
FORM INTIALISATION.
FORM MAIN_PROCESSING.FORM ERR_CATCH_NO_NUMBER.
FORM ERR_CATCH_NO_FILE.
FORM LABEL_FETCH.
Note: If a form contains very general functionality that could be used in other programs,
it may be useful to create it as a function module.
When events (e.g. END-OF-SELECTION, TOP-OF-PAGE, etc.) are used in the code, they
should appear in the order in which they are generally executed.
Skipped lines and indention should be used to promote clarity between sections of code as
well as between file definitions and declarations.
For ease of reading code, repetitive commands should be concatenated with a colon as
provided by SAP. All TYPEs, TOs, VALUEs, DEFAULTs, table names, and comments
should be aligned among themselves throughout the code, For example.
WRITE: LFA1_LIFNR,
LFA1_NAME1,
LFA1_ORT01.
Subroutines and FORM paragraphs should be used whenever possible to improve

readability and logic flow. If a block of code is executed more than once, it should be placed
in a subroutine at the bottom of the code.
FORM paragraphs should be placed after all non-subroutine code, after the END-OF-
SELECTION event. FORM paragraphs should be positioned in the order in which they are
called within the program.
Each program should have a data declaration template which should look like the following:
Page 26 of 53
* INCLUDES ------------------------------------------------------------------------*
* TABLES - SAP TABLES-------------------------------------------------------*
* TABLES - CUSTOM TABLES-----------------------------------------------*
* VIEWS------------------------------------------------------------------------------*
* STRUCTURES--------------------------------------------------------------------*
* TYPES------------------------------------------------------------------------------*
* INTERNAL TABLES-----------------------------------------------------------*
* VARIABLES----------------------------------------------------------------------*
* COUNTERS
* FLAGS
* SUMS
* VARIABLES
* CONSTANTS---------------------------------------------------------------------*
The above pattern can be obtained by inserting the pattern ‘Declaration’ into your
source code .( Goto Edit > Pattern choose ‘other pattern’ radio button and choose
‘Declaration’ from the dropdown)
Dead Code should be removed from the program, i.e., the fields, which are never
referenced, and code which can be never logically executed.
Programs should be kept to a reasonable length. Programs should be long enough so that
there is not an excessive amount of data being passed between two related programs, but
should be short enough so that the same program does not perform many discrete functions.
INCLUDE programs can be used for Data Declarations, PBO Dynpro modules, PAI Dynpro
modules, Subroutines, and Individual Event Processing.
Complicated arithmetic expression should be avoided as far as possible. Keywords like
COMPUTE, ADD etc should be avoided , e.g. DATA = DATA + 1 should be used instead of
ADD 1 to DATA.
Page 27 of 53
5.1 Documentation
Every program should be well documented so that the program is legible.

All programs should have functional/technical specification documents.
Every logical division within the program should have descriptive comments immediately
prior to the actual code.
Each program should have a standard header which should look like the following :
*-----------------------------------------------------------------------------------*
* PROGRAM DESCRIPTION:
*
* DEVELOPER:
* CREATION DATE: YYYY-MM-DD
* DER NUMBER:
*-----------------------------------------------------------------------------------*
* REVISION HISTORY-----------------------------------------------------*
*
* REVISION NO: R***
* DEVELOPER: DATE: YYYY-MM-DD
* DESCRIPTION:
*-----------------------------------------------------------------------------------*
The above pattern can be obtained by inserting the pattern ‘Report Header’ into your
source code . ( Goto Edit > Pattern choose ‘other pattern’ radio button and choose
REPORT HEADER from the dropdown)
The piece of code being modified should be enclosed with the following tags :
Start of Change - Revision No. / SOC – Revision No.
Code Modification
End of Change - Revision No. / EOC – Revision No.
All subroutines should have proper comments explaining their purpose. Comments should
explain the business reasons for the code in a particular section and what the code in that
section is accomplishing. Comments should not explain individual ABAP commands. The
ABAP editor should be allowed to generate the comment box, by coding the "PERFORM
<form>" statement and double-clicking on the <form>. The input and output parameters for
the specific form must be documented in the comment box. If parameters are not being used
, then the documentation lines should be removed from the code .
The ABAP editor has a PP (Pretty Printer) command to indent specific lines of code by 2
positions and add subroutine comments. Use Menu Edit>Pretty Ptinter. However, since this
command is CPU intensive, its use should be kept to a minimum. It should be used only
after making a series of changes for a new version of the program, rather than after each
individual change.
Page 28 of 53
5.2 Report Standard
Each report should have a standard report title which should look like the following :
REPORT &TITLE NO STANDARD PAGE HEADING

LINE-SIZE 255
LINE-COUNT 62(4)
MESSAGE-ID <MESSAGE CLASS> .
The above pattern can be obtained by inserting the pattern ‘Report Title’ into your source
code . ( Goto Edit > Pattern choose ‘other pattern’ radio button and choose REPORT
TITLE from the Dropdown)
The include program YIX_REPORT_STANDARD should be included in every report
program which gives a list output . This include has subroutines to generate project standard
header and footer . In the INITIALIZATION event , the following lines should be coded :
W_C_PROG_ID = SY-REPID.
W_D_STDATE = SY-DATUM.
W_T_STTIME = SY-UZEIT.
The above variables should be declared in the data declaration as :
DATA : W_C_PROG_ID LIKE SY-REPID ,
W_D_STDATE LIKE SY-DATUM ,
W_T_STTIME LIKE SY-UZEIT.
At TOP-OF-PAGE event , the following code should be written :

PERFORM REPORT_STANDARD_TITLE.
At END-OF-PAGE event, the following code has to be written :
PERFORM REPORT_STANDARD_FOOTER.
Blank lines (for output) should be specified by using “SKIP TO LINE <nn>” or "SKIP <n>“,
rather than multiple “WRITE /” lines.
For program parameters, Selection Texts should be used 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.
Each report should have an event sequence template which should look like the following :
Page 29 of 53
* INITIALIZATION-------------------------------------------------------*
INITIALIZATION.
* AT SELECTION SCREEN--------------------------------------------------*
AT SELECTION-SCREEN.
* TOP OF PAGE----------------------------------------------------------*
TOP-OF-PAGE.
*End of Page
END-OF-PAGE .
* START OF SELECTION---------------------------------------------------*
START-OF-SELECTION.
* AT LINE SELECTION----------------------------------------------------*
AT LINE-SELECTION.
* AT USER COMMAND------------------------------------------------------*
AT USER-COMMAND.
* END OF SELECTION-----------------------------------------------------*
END-OF-SELECTION.
The above pattern can be obtained by inserting the pattern ‘Report Template’ into
your source code . ( Goto Edit > Pattern choose ‘other pattern’ radio button and
choose ‘Report Template’ from the dropdown)
Hard-coded literals should not be used. Text Elements should be used to handle literal
text that is printed on a report, the advantage being easier maintainability. Text elements
should be defined and used in the WRITE command in addition to a corresponding string
value. This technique ensures accuracy of output by using text elements, while improving
readability of the program.
WRITE: /20 '*'(001),
/30 'COMPANY CODE TOTALS OF VENDORS'(002),
/30 'COMPANY CODE OVERVIEW PER VENDOR'(003),
/30 'AND A CLOSING SHEET.'(004).
There should be no hard-coding of date formats in the programs, The date format of the
users’ default information (SU01) should be used to output any date.
There will be no hard-coding of currency output formats in the programs. The decimal
notation of the users’ default information (SU01) should be used to output any currency
value.
The reports should be so designed that it can fit in stationery size A4 (210*297 mm). That
means that the report will be able to accommodate upto 255 characters. Generally, most of
the reports will be printed from the offices where laser printers are available.
Layout sets will be mostly printed from the terminals where dot matrix printers are available.
Continuous roll of stationery will be used in such cases. The standard for these printers are
yet to be decided. Design of layout sets have to conform to the printer decided for GAIL
mySAP project.
Page 30 of 53
5.3 Data Definition
Standard :
CONSTANTS should be used for variables whose values do not change (Static Data).
CONSTANTS rather than Text Elements should be defined for non-output hard code literals
in the program. For example:
CONSTANTS : C_ONE_THOUSAND TYPE I VALUE 1000,
C_TRUE TYPE C VALUE ‘TRUE’,
C_FALSE TYPE C VALUE ‘FALSE’.
For each field, a comment should be included after the field describing the use or purpose of
the field.
LIKE verb should be used while declaring the fields whenever feasible. For example, when
assigning internal fields that are to hold values from databases, the LIKE option should be
used to ensure that the variables have identical characteristics.
Data length and data type should not be left as default.
Only one table shall be listed on any one line of the program, and the table description
should be added as the end of line comment.
Example:
TABLES: T001, “Company codes
T100, “Messages
TAPLT, “Program applications
TDCT . “Dialog Modules
INCLUDES are created for data declarations and any data structures that will be used in
more than one ABAP program.
Variable names should be descriptive, meaningful and understandable.
"Field symbols" should not be used unless there is no simpler method available. If "field
symbols" are used, their use must be fully explained in program comments at the place were
the symbol is defined and used.
Global variables are minimized by declaring local variables or by passing parameters while
creating internal subroutines.
The ABAP compiler can better optimise the code if the type of field-symbols and formal
parameters are specified in the source code,.
Typed Field-Symbol
Field-Symbol without type
FIELD-SYMBOLS: <F>. FIELD-SYMBOLS: <I> TYPE I.
ASSIGN I1 TO <F>. ASSIGN I1 TO <I>.
I2 = <F>. I2 = <I>.
Page 31 of 53
5.4 Online Standard
Standard :
The screen field with a Format = OK as OK_CODE should be defined. This field is used to
validate the OK Event.
‘Header’ template should be used to insert Development and Revision History in the top
include section.
‘Declaration’ template should be used to define the sequence of table and data declaration.
It has already been mentioned how to insert this pattern.
All global data should be declared in the main program (TOP) module instead of the
PBO/PAI.
Lock entry failure should be handled by invoking 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,
retries should be limited.
When activating buttons or boxes, the associated texts should be associated as well. This
enables the user to click on either the button/box or the text.
AT PFnn command should not be used in programs. Instead the function name can be used
so that any method of invoking the function will have the same effect as the use of the PF-
Key.
Data Dictionary names (short, medium, long) should be used for field text on screens
wherever applicable.
Page 32 of 53
5.5 Batch Programs / Interface Standards
Standard :
Program variant(s) should be documented if a program 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!
Message statements executed in batch programs can be viewed through transaction SM37
via "Job Log". "Success" messages (type 'S') should be used generously to provide an audit
trail of the program's execution.
When BDC Session creation method is being used and any screen in the transaction
has multiple records of the same structure , care has to be taken so that Page Down is
coded after populating all records in the screen. The number of lines visible on a screen
depends on the Windows resolution, that is , it will differ if resolution is changed. When
SAP processes a BDC session, it uses SAP default resolution and font size . Default
resolution is 1024 * 768 and SAP default font is Fixedsys , size 08*15 . The programmer
has to code a page down after n records, where n is the no. of records on screen with
default SAP settings.
When ‘CALL TRANSACTION ‘ method is being used and any screen in the
transaction has multiple records of the same structure, care has to be taken so that
Page Down is coded after populating all records in the screen. When SAP processes ‘CALL
TRANSACTION’, it uses a dialog work process, so the no. of records on screen depends on
the resolution and font size of the machine from where the program is being called . Before
coding for ‘CALL TRANSACTION’,a SAP system variable(SY-SROWS) can be used in the
program to find out the no. Of output lines on the particular machine and then this variable
can be used to code for the number of lines before Page Down.
Page 33 of 53
5.6 Message
SAP-supplied default message Ids should not be used, as these IDs can change from
release to release. Instead, these messages can be copied to customer message IDs.
Messages should be included at appropriate places to indicate illegal operation, no
authorization, no data found, etc.
Do NOT use message ‘& & & &’ in enhancements. Create a separate message .
In reports if no data is found for the initial selection criterion, give appropriate message &
leave the report without going into further processing.
Page 34 of 53
5.7 Program Logic
Standard :
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.
When Coding IF, true testing conditions should be nested, so that the outer conditions are
most frequently true.
CASE statements are clearer for legibility and a little faster than IF-constructions. When
testing fields equal to something one can use either the nested IF or the CASE statement.
CASE statements are clearer and 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 document are just sample measurements; they are measured
on multi-processor environment. They are, however, not runtime measurement benchmarks.
LOOP …. WHERE is faster than LOOP/CHECK because LOOP …. WHERE evaluates the
specific condition internally.
Loop/Where
Loop/Check
LOOP AT ITAB. LOOP AT ITAB WHERE NAME1 =
KVAL.
CHECK ITAB-NAME1 = KVAL. ……….
ENDLOOP. ENDLOOP.
CHECK, EXIT, REJECT, STOP is used to suspend processing or skip unnecessary

processing.
Page 35 of 53
5.8 Data Access
Standard :
Database accesses should be minimised as far as possible. The number of communication
processes between the database and application servers, as well as the transferred dataset
should be kept as small as possible.
The most restrictive calls should be programmed first. For example, to process all materials
with a quantity-on-hand above 50, the tables containing stock quantities should be read
before the material master tables.
In a SELECT statement, only the fields that are needed should be selected in the order that
they reside on the database, thus reducing the network load. The number of fields can be
restricted in two ways using a field list in the SELECT clause of the statement or by using a
view defined in ABAP Dictionary. The usage of view has the advantage of better reusability.
Select with select list
Select *
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
SELECT SINGLE is used instead of SELECT-ENDSELECT loop if full primary key is known.
Otherwise, use up to 1 Rows. SELECT SINGLE requires only one communication with the
database system.
Select Single
Select … Endselect
SELECT * FROM SCARR SELECT SINGLE * FROM SCARR
WHERE CARRID = 'LH'. WHERE CARRID = 'LH'.
ENDSELECT.
The WHERE-clause should always be specified instead of using check-statements, The

database system can then use an index (if possible) and the network load is considerably
less. The conditions should not be checked with the CHECK statement because the
contents of the whole table must be read from the database files into RDBMS cache and
transferred over the network. If the conditions are specified in the where clause , RDBMS
reads exactly the needed data.
Select with Where condition

Select + Check statement
SELECT * FROM SBOOK. SELECT * FROM SBOOK
CHECK: SBOOK-CARRID = 'LH' AND WHERE CARRID = 'LH' AND
SBOOK-CONNID = '0400'. CONNID = '0400'.
ENDSELECT. ENDSELECT.
1,479
Page 36 of 53
A select list with aggregate functions should be used instead of checking and computing,
when trying to find the maximum, minimum, sum, average value or the count of a database
column. This reduces network load.
Select using an aggregate function
Select … Where + Check
C4A = '000'. SELECT MAX( MSGNR ) FROM T100
INTO C4A
SELECT * FROM T100 WHERE SPRSL = 'D' AND
WHERE SPRSL = 'D' AND ARBGB = '00'.
ARBGB = '00'.
CHECK: T100-MSGNR > C4A.
C4A = T100-MSGNR.
ENDSELECT.
Runtime Measure(in microsec): 12,268 Runtime Measure(in microsec): 9,228
Selection into an internal table is always preferred, except when the table will be very large
(i.e., when the internal tables will be greater than 500,000 records). When the number of
records needed is known, “Up to N Rows” should be used.
Select Into Table
Select + Append statement
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
Whenever possible, array operations should be used instead of single-row operations to
modify database tables. The frequent communication between the application program and
database system produces considerable overhead.
Array Insert
Single-line Insert
LOOP AT TAB. INSERT CUSTOMERS FROM TABLE TAB.
INSERT INTO CUSTOMERS VALUES
TAB.
ENDLOOP.
ORDER BY statement is used in SELECT only if it can use an index, else sorting is effective
by reading into an internal table and using the SORT statement in the program.
Order by without index
Order by with index
SELECT * FROM SPFLI ORDER BY SELECT * FROM SPFLI ORDER BY
PRIMARY KEY. AIRPFROM AIRPTO.
ENDSELECT.
Nested Select statements should be avoided. The inner select statement is executed several
times, which might be an overhead. 'Inner Join' and/or 'For all Entries' should be used
instead. 'For all Entries' is used over 'Loop at itab / Select / Endloop’
Page 37 of 53
Inner Joins: In a 1:N relationship between two tables, the table with the 1 relationship is the
preferred driving table. The 1 relationship is the smallest data set as defined by the
header/item relationship and/or the smallest data set as defined by the where clause
restrictions.
No complex WHERE clauses should be used, since complex where clauses are poison for
the statement optimiser in any database system. Instead try to restrict and keep the
sequence of fields of where clause as per the primary/secondary indices of the table.
In a SELECT statement, the HAVING clause specifies a logical condition for the groups in a
GROUP-BY clause. Effective use of the having clause can reduce the set of data
transferred from the database to the application server. When the having clause is used, the
aggregates and groups are constructed in the database instead of the application server,
thereby reducing the resulting set.
Avoid using ‘For all Entries’ along with joins in the same select . When using ‘For all Entries’
always ensure beforehand that the internal table for which ‘For all entires’ is being used is
not empty.
For all frequently used SELECT statements, an index should be used. An index is used if the
index fields (a generic part of) are specified, concatenated with logical ANDs in the Select
statement's WHERE clause..
Select with primary index support
Select without 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): Runtime Measure(in microsec): 28,434
1,959,019
SAP buffering should be used for accessing frequently used, read-only tables. However, in
case of retrieving latest data in multi-user environment, the buffer may have to be bypassed.
Select with buffer support
Select without buffer support
SELECT SINGLE * FROM T100 SELECT SINGLE * FROM T100
BYPASSING BUFFER WHERE SPRSL = 'D'
WHERE SPRSL = 'D' AND ARBGB = '00'
AND ARBGB = '00' AND MSGNR = '999'.
AND MSGNR = '999'.
Whenever possible, column updates should be used instead of single-row updates to update
database tables. Network load can then be considerably less.
Column update
Single-line updates
SELECT * FROM SFLIGHT. UPDATE SFLIGHT
SFLIGHT-SEATSOCC = SET SEATSOCC = SEATSOCC - 1.
SFLIGHT-SEATSOCC - 1.
UPDATE SFLIGHT.
ENDSELECT.
Page 38 of 53
5.9 Index Design
The following are rules for the design of indexes :

First it must be stated that table design is a more logical work while index design is rather
technical. In table design it might make sense to place certain fields (client, company code)
in the beginning. In index design, this is not advisable.
An index contains very selective fields in the beginning. Those are fields like object numbers.
Fields like client , company code cannot be selected.
Indexes should be small (few fields). Some optimisers are able to combine two or more
indexes to execute a query. This is not possible with wide indexes.
Indexes of one table should be disjoint (have few common fields), in order not to confuse the
optimizer which index to use.
Each index slows the inserts into the table down. Updates are only slowed down if indexed
fields are updated. In general, tables where insertion is very frequent ,should have only few
indexes while heavily selected tables might have more. About three indexes on a table
should not be critical.
Page 39 of 53
5.10 Internal Table
Standard :
MOVE should be used instead of MOVE-CORRESPONDING for efficiency purpose..
The sort fields should be specified on the sort statement; the fields should not be left as
default, the more restrictive the sort key is, the faster the program will run.
Sort with sort key specified explicitly
Sort internal table with default sort
key
* Table TAB is filled with 100 entries of 500 * Table TAB is filled with 100 entries of
bytes each 500 bytes each
SORT TAB. SORT TAB BY K.

Header line of internal table should be cleared before moving data into it.
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.
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 … WHERE
Key access with LOOP/CHECK
* Table TAB is filled with 100 entries of 500 * Table TAB is filled with 100 entries of
bytes each, 500 bytes each,
* 5 entries of which match the key * 5 entries of which match the key
condition condition
LOOP AT TAB. LOOP AT TAB WHERE K = KVAL.

CHECK TAB-K = KVAL. " ...
" ... ENDLOOP.
ENDLOOP.
Explicit work area operations are preferred rather than header line where appropriate, since
header line will have unnecessary MOVEs involved.
Table operation via explicit work area
Table operation via header line
* 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.
One-step approach READ/INSERT is preferred. If the amount of data is small (< 20 entries),
or if users need read-access to the internal table while it is being filled, this approach is
suitable. However, if the data amount is larger and you need read-access only to the
Page 40 of 53
completely-filled table, the two-step algorithm APPEND/SORT or three-step approach

APPEND/SORT/DELETE DUPLICATE (for tables without duplicates) is preferable.
Two-step approach: APPEND, then
One-step approach:
SORT
READ/INSERT
* 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 ENDLOOP.
SEARCH.
INSERT TAB_SRC INTO TAB_DEST SORT TAB_DEST BY K.
INDEX SY-TABIX.
ENDLOOP.
Three-steps: copy, sort, delete

One-step approach
duplicates
* TAB_SRC contains 1000 entries, of * TAB_SRC contains 1000 entries, 500
which 500 are different are different
REFRESH TAB_DEST. REFRESH TAB_DEST.

READ TABLE TAB_DEST WITH APPEND TAB_SRC TO TAB_DEST.
SEARCH.
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 READ BINARY/INSERT if number of entries is 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 via COLLECT statement
COLLECT semantics using READ
BINARY
* Table TAB_SRC is filled with 10,000 * Table TAB_SRC is filled with 10,000
entries, 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.
SEARCH.
IF SY-SUBRC = 0. SORT TAB_DEST BY K.
Page 41 of 53
ADD: TAB_SRC-VAL1 TO TAB_DEST-

VAL1,
TAB_SRC-VAL2 TO TAB_DEST-
VAL2.
MODIFY TAB_DEST INDEX SY-TABIX.
ELSE.
INSERT TAB_SRC INTO TAB_DEST
INDEX SY-TABIX.
ENDIF.
ENDLOOP.
116,422
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.
BINARY SEARCH should be used 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 ) ). 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.
Binary search of an internal table
Linear 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.
The key fields should be specified for read access explicitly. READ TABLE WITH KEY k =
‘X’ should be used instead of READ TABLE WITH KEY. Otherwise, the key fields have to be
computed dynamically by the run time system.
Access via key specified explicitly
Access via implicit default key
* Table TAB is filled with 30 entries of 500 * Table TAB is filled with 30 entries of 500
bytes each bytes 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.
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.
Page 42 of 53
If an internal table itab has a header line, the table itself is accessed by itab[].
Let the kernel to do the work …
Pedestrian way to compare internal
tables
* Tables TAB1 & TAB2 are each filled with * Tables TAB1 & TAB2 are each filled with
100 entries 100 entries
* 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.
Parallel cursor should be used instead of joining 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. Binary search is used when parallel
cursor is not feasible and the number of entries in the internal table is greater than 20.
More sophisticated: use parallel

Native join: loop tab1, read tab2
cursor
with key
* Table TAB1 is filled with 1000 entries of * Table TAB1 is filled with 1000 entries of
100 bytes each 100 bytes each
* Table TAB2 is filled with 300 entries of * Table TAB2 is filled with 300 entries of
100 bytes each 100 bytes each
* Table TAB2 is assumed to be sorted by K * Tables TAB1 & TAB2 to be sorted by K
in 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.
Page 43 of 53
More sophisticated loop: parallel

Straight forward nested loop
cursor
* Table TAB1 is filled with 100 entries of * TAB1 is filled with 100 entries of 100
100 bytes each bytes 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.
The MODIFY variant MODIFY itab ... TRANSPORTING f1 f2 ... for single line, and MODIFY
itab ... TRANSPORTING f1 f2 ... WHERE condition for a set of line should be used 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 selected components only
Modifying all components of single
line
* Table TAB is filled with 5000 entries of * Table TAB is filled with 5000 entries of
500 bytes each. 500 bytes each.
* Only the 8 bytes of the component DATE * Only the 8 bytes of the component
are modified. DATE are 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 selected components only

Modifying all components of lines
* Table TAB is filled with 100 entries. A line * Table TAB is filled with 100 entries. A
has two line has two
* components, a FLAG of type C and an * components, a FLAG of type C and an
integer table integer 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.
Page 44 of 53
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.
APPEND LINES OF itab1 TO itab2 and INSERT LINES OF itab1 INTO itab2 INDEX idx
should be used instead of APPEND and INSERT. The task of appending and inserting a
table to another table can thus be transferred to the kernel.
Pedestrian way to append a table
* Table TAB_SRC and TAB_DEST are * Table TAB_SRC and TAB_DEST are
both filled with 500 both 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
* Table TAB_SRC and TAB_DEST are * Table TAB_SRC and TAB_DEST are
both filled with 500 both filled with 500
* entries of 100 bytes each. TAB_SRC is * entries of 100 bytes each. TAB_SRC is
inserted line by inserted 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 TAB_DEST INDEX IDX.
INDEX IDX.
ADD 1 TO IDX.
ENDLOOP.
DELETE ADJACENT DUPLICATES / DELETE itab FROM ... TO ... / DELETE itab [FROM
...] [TO ...] WHERE ... should be used instead of DELETE, to transfer the task of deleting
entries to the kernel.
Pedestrian way to delete
duplicates
* Table TAB_DEST is filled with 1000 * Table TAB_DEST is filled with 1000
entries of 100 bytes entries of 100 bytes
* each and contains 500 pairs of duplicates * each and contains 500 pairs of
duplicates
Page 45 of 53
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
* each, and lines 450 to 550 are to be * each, and lines 450 to 550 are to be
deleted 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
* each, 250 of which match the WHERE * each, 250 of which match the WHERE
condition condition
LOOP AT TAB_DEST WHERE K = KVAL. DELETE TAB_DEST WHERE K = KVAL.

DELETE TAB_DEST.
ENDLOOP.
The performance gain when using 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, a SELECT-ENDSELECT loop is used 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. If the table has a
header line then the tables need to be referenced by square brackets.
Page 46 of 53
ITAB[] = ITAB1[]. LOOP AT ITAB INTO ITAB1.

APPEND ITAB1.
ENDLOOP.
Internal tables should be freed when no longer needed (either by the free command or a
subroutine exit), especially when the tables are large or the program is a batch program.
5.11 String Operation
The special operators CO, CA, CS etc. should be used instead of programming the
operations by the programmer. If ABAP statements are executed per character on long
strings, CPU consumption can rise substantially.
Using the CA operator
DO-Loop with Field-Symbols
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.
The CONCATENATE / SPLIT statement should be used instead of programming a string

concatenation.
Use of the CONCATERNATE
Moving with offset
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 the SPLIT statement

Use of SEARCH and MOVE with
Offset
“CMA contains ‘(410)-45174-66354312’ “CMA contains ‘(410)-45174-66354312’
and shall 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
Page 47 of 53
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 the leading spaces in a string have to be deleted, the ABAP statement SHIFT…LEFT
DELETING LEADING… . should be used. 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!
Using SHIFT … LEFT DELETING
Shifting by SY-FDPOS places.
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 SHIFT CLA LEFT DELETING LEADING
LEFT. SPACE.
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 the CONCATENATE statement
Use of a CONCATENATE function
module
CALL FUNCTION CONCATENATE T100-ARBGB
‘STRING_CONCATENATE_3’
EXPORTING T100-MSGNR
STRING1 = T100-ARBGB T100-TEXT INTO CLA.
STRING2 = T100-MSGNR
STRING3 = T100-TEXT
IMPORTING
STRING = CLA
EXCEPTIONS
TOO_SMALL = 01.
The strlen () function can be used to restrict the DO loop to the relevant part of the field, e.g.
when determining a check-sum.
Page 48 of 53
Get a check-sum with strlen ()

Get a check-sum with field length
“DATA: BEGIN OF STR, LINE TYPE X, “DATA: BEGIN OF STR, LINE TYPE X,
END END
“OF STR, CHECK_SUM TYPE I. “OF STR, CHECK_SUM TYPE I.
“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.
“CLEAR f WITH val” can be used whenever field has to be initialized with a value different
from the field’s type-specific initial value.
Initializing with CLEAR WITH val
Initialising with
CLEAR/TRANSLATE
* STRING is a 255 byte character field * STRING is a 255 byte character field
CLEAR STRING. CLEAR STRING WITH ‘*’.
TRANSLATE STRING USING ‘ *’.
5.12 Hardcoding
Hard coding must be avoided in programs. Hard Coding builds in maintenance problems,
limits our flexibility, and makes assumptions that might not be valid in future.
Examples of Hard Coding :
Select * from MARA where MATNR = ‘M00123’ ….
If VBFA-VBTYP_N = ‘J’ …..
Cases where hard coding may be accepted:
 Programs used only once, e.g. conversion programs
 Defining screen names and numbers for BDC processing
Reasons not to hard code include
 Data values may change or be added
 May not be easy to change in future
 Requires approval to make change
 Client’s business requirement may change
 SAP may change data values in future
Possible alternate solution
 Use parameters or select-option
 Use existing tables
 If none exist, consider creating a custom table.
Page 49 of 53
 Use a function module to determine value needed.
Page 50 of 53
6. APPENDIX
6.1 Module IDs
For all development purposes, the application process ID will be a 1-character field which
acts as an identifier for each program developed. This identifier can be used to group
related programs and development objects together and may be used to give a distinct
signature for interface control logic, reporting, and data file names.
The Application process ID will be the Module ID. The table attached below gives a listing
for the Module IDs:
Application Function Module ID Module Description

Financial Accounting F Financial Accounting
Controlling K Controlling
Production Planning P Production Planning
Project Systems C Project Systems
Quality Management Q Quality Management
Materials Management M Materials Management
Sales & Distribution V Sales & Distribution
Basis S Basis
Human Resources H Human Resources
Plant Maintenance I Plant Maintenance
Cross-Application X Cross-Application
Test/Throw-away T Test/Throw-away
If it appears that a specific development object cannot be appropriately classified by the

current list of Module IDs, a new Module ID should be requested from the Development
Team Leader.
6.2 Program Type ID’s
Type Id Description
C Conversion
G General Functionality/Other
I Inbound Interfaces
O Outbound Interfaces
M System Maintenance/Utility
R Report
F Adobe Forms
S Smartforms
U User Exit/Enhancement
X ** Transaction code for maintaining Custom tables
T Temporary, Demo or Test programs
** for transaction codes only
6.3 System Type ID’s
System Type Description
Page 51 of 53
R SAP R/3
B SAP Business Information Warehouse - BW
6.4 Directory Structure
Basic Structure - /INTERFACE

Under this directory various directories are to be created for each module . These module
directories will again have sub-directories for each interface requirement. The subdirectories
will be identified by interface id and interface type(Inbound/Outbound) . The subdirectories
will again have 4 directories each: -
 File to be processed - CURRENT
 File already processed - OLD
 Storing interface log - LOG
 Storing acknowledgement/error info - ERR
We might be needing other directories like CNTRL for control purposes or RECON to store
reconciliation information depending on process requirement.
Main module and sub module directory structure are given in a tabular format .
(Please refer to the following example which is indicative)
Application Area Module directory Interface Directory Description

Financial Accounting FI
PDI Public Deposit
System
PYI Payroll System
NPO Non-Payroll Payment
Materials MM
Management
CDI Material Codification
IDO Import
Documentation
PDI Platt’s Database
Human Resources HR
ADI Applicant Data
Upload
TDI Time Data Upload
The full directory path for Material Codification interface input files , for example , will be
/INTERFACE/MM/CDI/CURRENT
6.5 File Naming Conventions
A consistent file naming convention has to be followed while reading from input files and
writing to output files. This provides uniformity and transparency to developers/users.
The following file naming convention will be followed:
Page 52 of 53
 Module Name (1 Character) + Interface ID (3 Characters) + Type (I/O) + ‘_’

+YYYYMMDD + ‘.’ + HHMM + ‘.’ + extension
Where YYYYMMDD is the Date of creation of the file and HHMM is the timestamp of
creation of the file.
(Please refer to the following example which is indicative)
Module Name Interface Description Filename

Financial Accounting Public Deposit System
FPDI_YYYYMMDD_HHMM.EXT
Payroll FPYI_YYYYMMDD_HHMM.EXT
Non-Payroll Payment FNPO_YYYYMMDD_HHMM.EXT
Materials Management Material Codification MCDI_YYYYMMDD_HHMM.EXT
Import Documentation MIDO_YYYYMMDD_HHMM.EXT
Platt’s Database MPDI_YYYYMMDD_HHMM.EXT
Human Resources Applicant Data Upload HADI_ YYYYMMDD_HHMM.EXT
Time Data Upload HTDI_ YYYYMMDD_HHMM.EXT
Page 53 of 53

ABAP Development Standards Guidelines Ve

Uploaded by

Copyright:

ABAP Development Standards Guidelines Ve

Uploaded by

Document Information

Original Description:

Copyright

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

ABAP Development Standards Guidelines Ve

Uploaded by

Copyright:

What are the naming conventions described for different ABAP objects?

What are the naming conventions described for different ABAP objects?

What directory structure is suggested for storing interface related objects?

What directory structure is suggested for storing interface related objects?

Implementation of SAP

Suite of Applications & Internet

“ABAP Development Standards &

Title ABAP Development Standards & Guidelines

1.1 7th Apr 2015 Updates Priya Gupta,

1. Project Manager, GAIL

2. Technical Lead, GAIL

3. Core Project Technical Team Members (GAIL & SAP)

1.1 Background _______________________________________________________________ 4

GAIL has recently ventured in Telecommunication Sector, Exploration and

GAIL wants to establish an integrated Information System architecture to enable its

Developing these standards prior to construction and adhering to them during

2. OBJECT NAMING CONVENTIONS

SAP Object Type Length Naming Convention

SAP Object Type Length Naming Convention

SAP Object Type Length Naming Convention

SAP Object Type Length Naming Convention

SAP Object Type Length Naming Convention

2.2 Program Element

Program Element Use Syntax

2.3 Development Class

2.4 ABAP Objects

ABAP Report Include

When an ABAP report is created, some database-specific selections can be generated on

Transaction Codes are created either through ABAP Development

ABAP module Pools

Module Pool Includes

‘L’ for function modules

Module Pool Component Naming convention

Process On Help-Request xYsannHyy (MYRV01H01 for above example)

Batch Job Requests

Batch Input Sessions

GUI is used to give a name to a GUI status in a report or on-line program.

Tables / Views / Structures

A data element is a semantic description of a field. It provides a precise description of the

Messages Classes and Number

2.5 Web Dynpro Objects Naming Convention

Web Dynpro Application ZWDA_MyFirstApp

Web Dynpro Component

Web Dynpro Assistance Class <namespace>CL_AST<nam ZCL_AST_Class

Popup Window W_POPUP_<name>

Component Usage U_COMP_<used_comp> U_COMP_SALV_XXX

Web Dynpro Application & Component Configuration

Application Configuration <namespace>APP_CFG_<na ZAPP_CFG_<name>

OIF Component configuration ZAPP_CFG_<name>_OIF

Web Dynpro View Elements

2.6 ABAP development standards for GAILGAS

2.7 ABAP development standards for SRM related developments in ECC

2.8 Naming convention for objects in SRM

Nomenclature Object Type

3. PROGRAM SPECIFICATION DOCUMENT NAMING CONVENTIONS

3.1 Development Request (DER) IDs

4. GENERAL GUIDELINES FOR PROGRAMMING

ABAP programs MUST NEVER be used to update configuration tables.

The use of key-word “CLIENT SPECIFIED” is forbidden under normal circumstances.

Subroutines and FORM paragraphs should be used whenever possible to improve

Every program should be well documented so that the program is legible.

5.2 Report Standard

REPORT &TITLE NO STANDARD PAGE HEADING