ABAP Development

DDC DEVELOPMENT GUIDE

KU IZRUL HADI BIN KU HILMY

Version 1.0
LAST UPDATED: 26.10.17
DOCUMENT INFORMATION

The contents of this document remain strictly confidential to Rizing – Digital Development Center and its
affiliated companies. All rights to any ideas, inventions, copyright works, designs or any other types of
intellectual property in the contents belong to Rizing.

DOCUMENT REVISION HISTORY

Date Version Description Author

02.10.2017 1.0 Document Creation Ku Izrul Hadi Bin Ku Hilmy

DOCUMENT REVIEWERS
Name Organisation Position
Ruslim Chang Digital Development Center - Rizing Technical Manager

Jhodel Cailan Digital Development Center - Rizing Technical Consultant

Eng Hee Goh Digital Development Center - Rizing Technical Consultant

www.rizing.com 1
TABLE OF CONTENTS

Contents
DOCUMENT INFORMATION ............................................................................................................... 1
TABLE OF CONTENTS ......................................................................................................................... 2
INTRODUCTION ................................................................................................................................. 3
CODING STANDARDS......................................................................................................................... 4
1. Package and Transport Request...........................................................................................................4
2. Object Oriented Methodology .............................................................................................................4
2.1 Why ABAP Objects ........................................................................................................................................................ 4
2.2 Usage Strategy .............................................................................................................................................................. 5

3. ABAP Development Tool Environment.................................................................................................5

4. Shared Memory Object .......................................................................................................................6
4.1 Advantages .................................................................................................................................................................... 6
4.2 Usage Scenarios ............................................................................................................................................................ 6

5. Enhancement......................................................................................................................................8
5.1 Enhancement Framework ............................................................................................................................................. 8
5.2 Business Add-Ins (BAdI)................................................................................................................................................. 9
5.3 Business Transaction Events (BTE) ................................................................................................................................ 9
5.4 Customer Exits / Enhancement ..................................................................................................................................... 9

6. Performance ..................................................................................................................................... 10
6.1 Programming guidelines to achieve scalable programs Objects ................................................................................. 10

7. Naming Convention .......................................................................................................................... 12

7.1 Programming guidelines to achieve scalable programs Objects ................................................................................. 12
7.2 Object Oriented Components ..................................................................................................................................... 14

8. Documentation ................................................................................................................................. 16
8.1 Header Documentation Box ........................................................................................................................................ 16
8.2 Comment Box .............................................................................................................................................................. 17
8.3 Comment Lines ........................................................................................................................................................... 18

APPENDIX ....................................................................................................................................... 19

www.rizing.com 2
INTRODUCTION

The purpose of this document is to have uniform program standards for the Rizing – Digital Development
Center team, and to provide guidelines and useful information for consultants in the SAP environment
pertaining specifically to ABAP development.
Programming standards and guidelines are needed to ensure the quality of custom developments.
Throughout this document the words shall, should, and must are indicative of a need and hence
adherence to such requirements is mandatory.
The words can and may are indicative of a want and so are optional. Non-conformance to such
requirements will not be serious.

www.rizing.com 3
CODING STANDARDS

ABAP (Advanced Business Application Programming) is a programming language for developing

applications for the SAP R/3 system, a widely-installed business application subsystem. The latest
version, ABAP Objects, is object-oriented programming.

1. PACKAGE AND TRANSPORT REQUEST

Packages are designed to help developers modularize, encapsulate, and decouple units in SAP system.
Any major custom development would have a sub-package created. Every technical specification
document should have the package information. Developments will not be started without appropriate
package.

2. OBJECT ORIENTED METHODOLOGY

SAP introduced ABAP objects, the object-oriented extension of ABAP as part of release 4.6C. This
provides the entire required framework for developing programs using Object Oriented methodology.
They provide all the benefits of Object Orient programming and more.
• Data Encapsulation
• Reusability, through inheritance
• Event driven, Applications can be loosely coupled, providing greater flexibility

2.1 Why ABAP Objects

Advantages of using ABAP objects and classes

• ABAP objects are explicit, and therefore simpler to use. (Compared to Logical database, reports)
• ABAP objects offer cleaner syntax and semantic rules. E.g. obsolete and error-prone language
concepts are strictly forbidden inside ABAP object classes.
• Only way to use new technology SAP Control Framework and BSPs are encapsulated in ABAP
object classes.

www.rizing.com 4
2.2 Usage Strategy

Presentation Presentation
Layer Layer

CFW,
DOI, Service
BSPs Classes
CALL
SCREEN
...

Application Service Application

Classes Classes External Classes CALL External
System FUNCTION System
DEST
...

Service
Classes
SELECT
Object ...
Services
SAP Web SAP Web
Application Application
Server ABAP Server ABAP

Persistent Persistent
Data Data

Object-Oriented World Hybrid Model

For all custom developments, first option will be to use Object Oriented programming, unless the OO
programming is an overhead or is not feasible, e.g. like classical dialog programming (using ABAP
Dynpro), customer-exits, form exits which involves simple coding requirement.
Following guidelines will be followed,
• Use of function modules to minimum, e.g. encapsulating classical screens (Dynpros) or
developing RFCs.
• Use methods instead of subroutines.
• Decouple classical screen programming from Application programming using ABAP Objects.

3. ABAP DEVELOPMENT TOOL ENVIRONMENT

Moving forward the recommended and preferred ABAP development is using Eclipse.

www.rizing.com 5
4. SHARED MEMORY OBJECT
From WAS6.40 (which would be used as a platform for ESAP applications), SAP has introduced shared
objects for accessing data across user sessions. Thereby reducing the costly database reads for common
data required across sessions. Transactions SHMA can be used to maintain the Shared Object Area,
and SHMM can be used for monitoring. A root class, with Shared Memory-Enabled attribute checked
needs to be created using Class builder.

SHARED MEMORY – SHM

Database COMMON DATA

USER X USER Y USER Z

SESSION SESSION SESSION

4.1 Advantages

Advantages of using share memory object are

• Reduced memory consumption
o Data is kept only once in the memory
• Reduces runtime costs
o Data is aggregated only once
o Fast access since access to the main memory not the database
o In place aggregation for “arbitrary” data structures including strings, internal tables and
references.
• Reduced maintenance costs due to
o Simplified programming model in contrast to solutions based on import / export.

4.2 Usage Scenarios

An example of usage scenario

www.rizing.com 6
• Shared buffers
o Low update frequency (e.g. once a day to once an hour)
o (Very) costly amount of data
o Many parallel readers, single writer
• Shared buffers
o Access by single writer or reader
o Buffer concept is kept across transactions
• Coarse granularity locking concept
o Only complete buffer can be locked
o Rare updates
o Readers and writers know each other

www.rizing.com 7
 5. ENHANCEMENT

5.1 Enhancement Framework

5.1.1 Enhancement Framework

Principally, there are two types of enhancement options:

• The developer of the corresponding development object must insert the options of one kind into the
coding so that enhancements can be done there at a later time. These preconceived enhancement
possibilities are called explicit enhancement options.
• You can perform enhancements on implicit enhancement options without the developer of the appropriate
compilation unit having to do anything. Enhancement options are always available in programs, global
classes, function modules, and includes.

In other words, the implicit enhancement options are for free, provided by the framework, while the explicit
ones need to be inserted explicitly, as the name indicates. While implicit enhancement options are always
available, one should exhaust all explicit enhancement options first prior to using any implicit
enhancement.

5.1.2 Explicit Enhancement Technologies

There are two types of explicit enhancement options:

• Enhancement points 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 "hooks" 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.

5.1.3 Implicit Enhancement Technologies

Implicit enhancement options are fixed points in compilation units - that is, points that remain intact even
if the code is changed:

• You can always insert source code plug-ins before the first and after the last line of includes, methods,
reports, and function modules.
• You can always add further optional parameters to function modules.
• For global classes, there are different permanent, implicit options for enhancements: You can insert
additional attributes or methods, and you can add optional parameters to existing methods.

www.rizing.com 8
5.2 Business Add-Ins (BAdI)

For each kernel Business Add-In you have one interface and an adapter class that implements this. The
user implements the interface. BADIs can be multi-instance. In which case more than one implementation
can be active at any given moment. Also consider the filter entries, enter ‘*’ if CLIENT field is one of the
filter field.
When there's an overlapping enhancement technology, BAdIs (preferrably Kernel BAdIs) are preferred
over traditional Customer-exits / User exits. In the event that there are no BAdI available but only
Customer-exits / User exits are available, Kernel BAdIs should be created inside the Customer-exits so
that the implementation is encapsulated.
Most of the BADIs can be located through the customizing transaction – SPRO or through a search or
the statement “GET BADI” in the program.
• Transactions
o Definition transaction SE18
o Implementation transaction SE19
• Business
o Data is aggregated only once
o Fast access since access to the main memory not the database
o In place aggregation for “arbitrary” data structures including strings, internal tables and
references.
• Reduced maintenance costs due to
o Simplified programming model in contrast to solutions based on import / export.

5.3 Business Transaction Events (BTE)

BTEs are predecessors of BADI, and available mostly in FI modules. Coding is done in function module
which has fixed interface provide by the SAP. These can be of two types.
• Publish and Subscribe in which case the additional activities could be carried out. The
data cannot be sent back to SAP standard.

• Process This allows sending back data to SAP standard.

BTE’s can be located either by using the transaction FIBF or through a search for statement “OPEN_FI”
in the program. By now BTE should be avoided completely in new development and use existing standard
SAP and do not create new custom BTE.

5.4 Customer Exits / Enhancement

These are one of older enhancements technique available in SAP, and can have function exits,
customizing include, screen exits and menu exits. BADIs should be used instead of customer-exits in
case of overlap of functionality.

www.rizing.com 9
 • Definition transaction SMOD
• Implementation transaction CMOD

6. PERFORMANCE
The strength of multi-tier system is scalability; therefore, a program can be written on a single server
development system with very few users, but could be deployed on multi server production systems
which processes huge volume of data, across continents, with thousands of people using it concurrently.
So, scalability considerations need to be given when developing any program. Also in multi-tier
architecture, the load optimization potential is the largest around 40-60% at the application layer. This
can be achieved through proper process design, applications and customizing.

6.1 Programming guidelines to achieve scalable programs Objects

These are one of older enhancements technique available in SAP, and can have function exits,
customizing include, screen exits and menu exits. BADIs should be used instead of customer-exits in
case of overlap of functionality.
• Database Layer
o Use of appropriate indexes
o Keeping the amount of data read to the minimum.
o Buffers and Caches
• Application Layer
o Parallel Processing enabling
Keep Enqueue locking time in programs to the minimum.

• Other performance guidelines

o Dead code
▪ Dead codes are codes that will never get executed. Avoid introducing dead codes
at all cost. This can be achieved by making sure that the usage of CHECK, EXIT
and RETURN ABAP statements are right where they belong to.
o Subroutine usage
▪ Subroutine is obsolete and therefore should be avoided at all times.
o Nested IF .. ELSE statements
▪ Avoid a deep nested IF .. ELSE statements. This can be avoided by making sure
that the code logic is modularized or by making use of the CHECK statement. If
it’s really difficult to avoid a nested IF .. ELSE statement, up to 3 level deep IF …
ELSE statements is acceptable. A very deep nested IF … ELSE logic is quite
difficult to understand and will likely to cause bugs brought by future modifications.

www.rizing.com 10
o CASE versus IF statements
▪ Always use CASE statement for a multiple condition scenario. Avoid using multiple
IF statements because CASE statement is more versatile and resistant to future
changes and highly likely to cause bugs compare to IF statement.
o LOOP statement
▪ Avoid performing LOOP within a LOOP statement
▪ If LOOP within a LOOP is required and cannot be avoided consider using parallel
cursor approach or define secondary key for internal table (recommended
approach)
o Nested SELECT v/s JOIN
▪ Using JOIN when selecting from 2 database tables is preferred over using nested
SELECT statements. However, please note that using JOIN statement bypasses
data that is buffered. If JOIN is used on a buffered database table, unnecessary
database read is executed, thus, the SELECT using JOIN statement results in an
increased database read time. Therefore, when using JOIN statement, always
check if the succeeding database table is a buffered table, and if it is buffered, just
simply use a nested SELECT or use SELECT SINGLE within a LOOP.
o SELECT SINGLE versus SELECT … UP TO 1 ROWS
▪ Use SELECT SINGLE statement when you have a fully qualified primary key of
the database table as a filter criteria (WHERE clause) and you want to retrieve
exactly one record.
▪ Whenever you want to retrieve exactly one record but your filter criteria (WHERE
clause) is not a fully qualified primary key of the database table, you should use
SELECT … UP TO 1 ROWS statement.
o Field symbol
▪ Use field symbol as much as possible
• Append initial line to ITAB assigning <field symbol>
• Loop at ITAB assigning <field symbol>
• Read table ITAB assigning <field symbol>

www.rizing.com 11
7. NAMING CONVENTION

7.1 Programming guidelines to achieve scalable programs Objects

Coding Elements Convention Description

X = Use of data type
T - Type

Types XY_*
Y = Type of data type
T - Table
S - Structure
X = Use of data type
L - Local variable
G - Global variable
Y = Type of data type
V - Variable
T - Table
S - Structure
R - Range
O - Object Reference
Variables XY_*
D - Data Reference
C - Constant
LCL – Local Program Class
Definition/Implementation
LIF – Local Program Interface
E.g. LV_DATE (Local variable called Date)
Other uses in place of XY:
MC = Macros
TC = for Table Control(Screen Elements)
Field Symbols <XY_*> XY_* = as per naming for Variables above
X = Use of data type
I - Import variable
E - Export variable
C - Changing variable
Parameters XY_* Y = Type of data type
V - Variable
T - Table
S - Structure
R - for ranges

www.rizing.com 12
 O - Object Reference
D - Data Reference
Letters for X
P - parameters
R - radio button
Selection screen variables X_* C - checkbox
T - text input
D - dropdown list
S - Select option

DDIC Objects Convention

Table Type ZTT*

Append structures ZA*

Lock objects EZ*

Domain ZDO*
Data Element ZDE*
View ZV*
Structure ZS*
Secondary Index Z*
Table ZT*

IDoc Elements Convention

Segment type Z1*
IDoc Function Modules Z_IDOC_<direction>_<msg_type>
<direction>
I – In
O - Out
Process Code Z*

Others Convention
Function Groups Z*
Function Modules Z_*

www.rizing.com 13
Enhancements Convention
Enhancement Spot Definition ZES_*
Enhancement Implementation ZEI_*
BADI Definition ZDF_*
BADI Implementation ZIM_*
BADI Interface ZIF_EX_*
Implementing Class ZCL_IM_*

7.2 Object Oriented Components

OO Components Convention
Class ZCL_* (Must be a NOUN)
Interface ZIF_*
Interface Constants ZIF_*_C
Exception Class ZCX_*
Method name * (Must start with a VERB)
Events *
Class Attributes
XY_*
Note: Avoid public attribute except for constants.
Access to attributes should instead be via a public eg :
method.

MV_COMPANY_CODE

ST_DELIVERIES
C_TIPTOP_SHPOINT’

Convention
M – Instance
X = Ownership of the attribute S – Static
C – Constant
T – Table
S – Structure
Y = Type of data type
R – Data Reference
O – Object Reference

Class Types (Same as TYPES above) XY_*

Note : Class types can be public or private. There is
no differentiation on the value of the visibility of
eg :
class types. Types shouldn’t be declare locally within
method but within class type tab.

www.rizing.com 14
 TV_COMPANY_CODE
TS_DELIVERY
TT_DELIVERIES

Convention Convention
X = Ownership of the attribute T – Types
T – Table
Y = Type of data type S – Structure
V – View

Methods Convention
Methods that access Attribute SET_<attribute name>, GET_<attribute name>
Event handler methods ON_<event name>
Methods that perform type
CONVERT_<source type>_TO_<target type>
conversions
Methods that return a Boolean
IS_<adjective>
value
These methods may not return any
Recommendation: Use of ABAP_FALSE or ABAP_TRUE
exceptions.
Check methods CHECK_<objective>

Method Parameters Convention Description

X = Type of the Parameter
I – Importing
E – Exporting
C – Changing
R – Returning

Method Parameters XY_*

Y = Parameter data type
T – Table
S – Structure
V – Variable
O – Object
R – Data Reference

www.rizing.com 15
8. DOCUMENTATION
ABAP/4 code is fairly self-documenting. However, it is wise to provide future programmers with
documentation. Explain the purpose at the top of the program. Maintain a history of modification notes,
dated, with the most recent change first. Comment work fields, and fields in work records especially those
used for interfacing. Comments should explain what the code is doing, not how the code is doing it. As
a best practice in writing code, emphasis is given on making the code easier for another developer to
read. If this guideline is followed, you will find that the code doesn't need further comments just to explain
what the code is doing. So now, as a general rule-of-thumb in adding comments, if a chunk of code logic
takes the reader about 5-10 seconds to figure out what the code logic is doing, then this is the opportunity
to put some comments.
A flower box comment can be used for conventional ABAP program while in ABAP class we can use in
line comment and ABAP Doc instead.

8.1 Header Documentation Box

The Header comment box similar to the one below should be coded after the REPORT, or after
FUNCTION MODULE statement of customized ABAP/4 programs both for new and cloned programs.
Cloning of programs (especially procedural programs) should be avoided. If a program needs to be
cloned, then it simply means that it was not coded in an object-oriented way.
The documentation box must be used to list detailed information and also any other program
dependencies (if applicable).
from functional and technical specifications as well as documenting modifications to the program.
A standard comment box can be created and maintained as a pattern via “UtilitiesMore
UtilitiesModeCreateChange pattern” in the ABAP/4 editor. Once set-up the comment box can be
added to the code by entering `IC xxxx` in the command field of the ABAP/4 editor where xxxx is the
comment box identifier.
SAP have this version management feature that can highlight what was changed from version to version
(ADT does the code comparison best).

www.rizing.com 16
8.2 Comment Box

A comment box is used to emphasize a statement or section in a program.

A comment box should be inserted before all for ABAP report program:
• declarative elements
• Events.

Example:

Other comment boxed which must be used are:

Before the declaration of parameters and select-options.

Before the data declaration part.

Before the start of the main program code. Mostly before START-OF-SELECTION.

www.rizing.com 17
8.3 Comment Lines

There are two ways of indicating comments in a report:

• If the whole line is supposed to be a comment, enter an asterisk (*) in the first column. Example
o Example

Comment lines can be inserted anywhere in a report and so this should be used to describe the
function of certain parts of the code.

• If only the latter part of the line is supposed to be a comment ,enter “ before the comment
o Example

The system interpret comments indicated by “ as blank characters. This option should be used to
describe certain lines of code.
A flower box comment can be use for header class while in between class we can use in line
comment instead.

www.rizing.com 18
APPENDIX

1. SAP Help on ABAP Development Guide

2. Best Practices in ABAP Development
3. Best Practice Guidelines for Development

www.rizing.com 19