ABAP DEVELOPMENT GUIDELINES

Request you to follow few simple development steps so we can have risk free
developments.

• Have one FS for each RICEF development (related objects grouped to one RICEF).
• Have a CR (Snow change request) for each RICEF development.
• Try to capture all related objects of the RICEF in one TR
• If the object has dependency, then keep a track of that, It will help us while moving
the changes to Q and Prod.
• Keep TR list in shared folder with the dependency details.
• All Existing DDIC changes should be in separate TR.
• Version Check of the existing objects
• Make sure all previous changes to the existing object are move to Prod.
• If not check with the other developer who is making the changes.
• Code Review should be completed before moving to QC.
• your peer should review the code before sending it to Q
• Review is based on CR, all objects in the TR should be reviewed.
• If its simple minimum code changes to existing object with 1 or 2 objects in the TR,
then self-review is enough
• Technical specification templates should be filled by developer and reviewer and
need to be shared for QC Approval.
• One document for change request and fill all details and sections of the template
based on SCI of the TR.
• UNIT testing in DEV is mandatory if not possible due to non-availability of data, then
proof of DRY run in DV1 is mandatory.
• Dry run will help to fix the unwanted transport and dumps in Q.
• TR will be moved to PROD only after the Roquette technical SME approvals.
• Roquette technical SME approval is mandatory for Prod Import
• Roquette SME review will take place based on the FS-CR-TR-Code review check list
document.
• TS should be updated to the same FS of the RICEF
• Update the version history of the documents with TS update date and user.
 ABAP DEVELOPMENT GUIDELINES

General Development Guideline

• Please follow the standards and process from the document ABAP Application
Development Handbook provided below in this document.
• Use standard FM to update the tables, No BDC should be used.
• Always use Lock object in case of mass updates no lock required.
• No Hardcoding of Object like org, personal area, EE group etc.,
• Use parameter tables or TVARVC for hardcoded values.
• Use as much as inline comments.
• Comments should talk about business logic, data logic or technical logic.
• Keep the code simple and try to use ABAP740 syntax.

ABAP Application Development Handbook

Version Management

• As part of the development process, when you are about to modify an object you are
required to check that the current version in the development system is the version
in the production system. If they are not the same, then the developer should check
with the owner of the current version to ascertain testing and transport dates. If
testing is not complete, then normally the second development should not be
started. This will avoid problems if the current version must be modified further
under the first development.
• The version management and development process mentioned above is also
applicable for Webdynpro & Odata service development objects.
• When part of an ABAP class is being changed, the versions of the three header
sections must be checked as well as the version of the specific object. For example
creating new methods or changing the parameters of an existing method causes a
new version of the relevant header section to be created, so this can result in
parallel development of an object – the Class Header

Transport Request for Data Dictionary objects

Its good practice to create a separate transport request in a project and assign all the Data
dictionary elements like Table, Data Elements and domains in the same common transport
request. This helps us to use the same object in a different ticket in a project.

Date, Currency and Quantity Handling in Programs

 ABAP DEVELOPMENT GUIDELINES

In all our interface and BDC programs, where we get the data as a input from user through a
file The Date conversion as per the user settings should be handled and the Currency and
Quantity should be used with proper conversion as per the Currency Key and unit of
measure respectively. It’s good to define a structure always with Currency Key and unit of
measure for Currency and Quantity fields.

Cloning existing SAP standard programs

Before copying a Z program from a SAP standard program, kindly check whether we can
avoid cloning instead of making the required changes directly in the standard SAP program
by using Enhancement spot, BADI or User Exits.

When copying a Z program from a SAP standard program and planning to make customized
changes, first release the copied version immediately with no changes. Then make the
changes and proceed as normal. In this way you can compare back to the original version
of the program especially after an upgrade when the SAP standard program may have
changed substantially. Do not apply any changes suggested by “extended program check”
if they apply to code from the cloned program. If such changes were to be applied, they
could well be confused with “real” changes when the program is being reviewed during an
upgrade of the R3 version.

Another method that can be used to create an unchanged version of a copied standard SAP
module is to create a ‘temporary version’ of the unchanged object. This can be done by
copying the standard SAP program to the Z program name. Then edit the Z program and
then go to Utilities->Versions->Generate Versions. This might be a preferred method since
you will not have to release any transport and create new transport in order to make
changes to the Z program. This is what you will see in version management once you
activate the unchanged version of the program:

Note: Make sure that you copy all the included modules and function modules utilized in
the program into corresponding z-versions (only if these modules need to be modified) to
prevent problems during an upgrade.
 ABAP DEVELOPMENT GUIDELINES

Texts

Always change SAP standard texts, report texts, GUI’s and parameters when logged on in
the original language in which it was originally coded.

Hard coding of literal values

Hard-coding literal values that can possibly change over a given period of time should be
always avoided. Rather use a Z-table with a rules option.

Creation of Z tables and Maintenance Generator

While creating any Z tables, include the tracer fields like Created by (ERNAM), Created Date
(ERDAT), Created Time (ERZEIT), Changed By(AENAM), Changed Date (AEDAT) and
Changed Time (AEZEIT). If these tracer fields are not available in the spec given by BE,
inform to the concerned BE’s and include these fields

Table Maintenance Generator:

While generating the Table Maintenance for Z table the tracer fields described above
should be automatically populated using the EVENTS in the Table Maintenance Generator
as shown below. The Logic for populating the tracer field values will be written in the
routine 01 SAVE, 05 NEW_ENTRY and 19 READ_ONLY in include and that include will be
called in the function group used for table maintenance generator.

A common include ZN_TABMAINT_COMMNFORMS will be created and all the common

routines like 01 SAVE, 05 NEW_ENTRY and 19 READ_ONLY required for table maintenance
events will be created and the same will be called in all the main program of table
maintenance function group.

Guidelines for Deleting Old / Unused ABAP Code

When maintaining a program, new code is written to replace older code. It is usually a good
idea to comment on the code rather than deleting it entirely. This serves 2 purposes: it
makes the old code readily available in case there is a problem with the new code, and it
serves as documentation of how the old code used to work. After a while, so much
 ABAP DEVELOPMENT GUIDELINES

comment-out code can accumulate that it makes it difficult to read the program - that is,
the accumulated comment-out code can become confusing rather than helpful.

If, in the judgment of the programmer, the commented-out code is confusing rather than
helpful, the old code may be deleted if ALL the following 3 conditions are met:

1. The code to be deleted has been captured in SAP version management as part of a
released transport.
2. The revision history of the program is reasonably complete with good explanations
of what was added or deleted as part of each transport, as well as the functional
consequences of that change (not just a generic comment like "fixed bug" or "added
new features"). A revision history like this should be maintained contemporaneously
with changes to the code. If you acquire maintenance responsibility for a program
that is already in production and has commented-out code which is not described
in the revision history, you don't have to retroactively document the effect of the
comment-out code.

3. (If applicable) When an algorithm or general approach is changed, comments

should be added near the code for the new algorithm or approach describing:
a. How the new approach differs from the old one
b. The most recent released transport with the old approach
c. The range of line numbers containing the code that implemented the old
approach in the version included in the referenced transport

Coding Standards

• As with most other programming languages, ABAP provides for a large variety of
programming styles. By programming style, we mean formal practices that do not
influence the semantics of a program.

• Use the Pretty Printer in the ABAP Editor and use it frequently. It’s good practice to
use the Pretty Printer each time it’s saved. Since Pretty Printer changes lines of
code, these changes will show up in version management when comparing to prior
versions. Try and maintain the same Pretty Printer settings that were in place for the
prior version of the module.
 ABAP DEVELOPMENT GUIDELINES

• Program code must be readable and understandable by everyone who knows ABAP.
If programs or parts of programs are not understandable by reading the source code
itself and its documentation, you must use comments. Comments should be in
English and describe what a program, procedure, or part of a program is doing. If
necessary, you should also comment on how the code produces its results — e.g.,
by including references to literature if you implement general algorithms.

• Since the mixed use of upper- and lower-case characters inside a name is
problematic when the Pretty Printer is used with upper/lower case conversion, it is
recommended that parts of names are delineated using underscores (e.g.,
get_value instead of getValue).

• Since there are different name spaces for data types and data objects, it is
theoretically possible to declare data objects with the names of data types.
However, we are strongly against this, in order to eliminate confusion on the part of
the reader of your code. The section of these standards entitled “Naming
Conventions” also precludes these definitions.

• Always use the most appropriate language elements. When new language elements
have been introduced that serve better the same purpose as existing language
elements, adjust the respective statements. Your goal should be to use identical
language facilities to achieve identical results in different statements.

• Some common examples of where to avoid outdated language elements include the
following:

• Use only the relational operators (=, <>, <, >, <=, >=), which are more
readable than their respective character forms (EQ, NE, LT, GT, LE, GE).
 ABAP DEVELOPMENT GUIDELINES

• If available, use the addition NOT inside predicates of logical expressions

(e.g., dobj IS NOT INITIAL) instead of the Boolean operator NOT in front of
the logical expression (e.g., NOT dobj IS INITIAL). The reason is that you
naturally do the same for comparisons (dobj1 <> dobj2 instead of NOT
dobj1 = dobj2).

• All programs and reports should be written so that the screens and output can be
translated. This can be achieved in most cases using text elements rather than hard
coded text in the source code. Unless otherwise requested in the spec, all
programs should be written with English as the original language and translated into
other languages. If the other language translations are not provided, then the
correct translations can be entered later.

Tables Definition Statement

In general, the TABLES statement should no longer be used, as all table reads should be
read into work fields or into an internal table. However, there are very few occasions when
the TABLES statement has to be used, for example when interfacing to a SAP program that
expects a table work area with the same name as the table.

Reports

Most programs should be written as reports. Any reports, extracts, uploads, downloads,
and BDC's that require a single screen should be written as a report. It should be noted
that since release 4.6 of R/3, it is now possible to create reports with multiple input
screens. For complex screen requirements, tab strips may be used. Take careful note of
how often the initialization section is performed, code in commonly used sections using
the sub screen number in table SYST to ensure that code is not performed unnecessarily.

While writing the new report program use the option “other pattern” “Z_ABAP_STANDARD”
to layout your program.
 ABAP DEVELOPMENT GUIDELINES

All new reports that output to the screen in tabular form should use the ALV approach and
building of ALV report coding should be done in Object Oriented programming (OOPS)
method by using classes and methods not by function modules. Such programs that may
need to be run in background should also output to a print file. The variable SY-BATCH
should be tested to determine which method to use.

A skeleton program Z_ABAP_STANDARD_ALV has been developed in DV1 as a sample for

ALV report using Object Oriented Programming (OOPS) method.

Dialog Programs

Dialog programs should only be written where multiple complex screens are required for
business processes such as packing or goods receipt and where continuous input from the
user is required on additional screens.

User exits (BADIs)

Leave the comment-out example code at the top of the user exit before you start the local
work variables statements. Where there is a performed user exit as well as a BADI use the
BADI in preference.

Database Updates

Under no circumstances should any program directly update SAP-delivered tables using
the INSERT, UPDATE, or DELETE commands. SAP-delivered tables begin with all letters
other than Y and Z, and they should only be updated using a SAP transaction. To automate
updates to SAP tables via a program, you may use the CALL TRANSACTION command (or
optionally create a BDC using SAP supplied functions or use BAPIs).
 ABAP DEVELOPMENT GUIDELINES

Update of Z-tables should be done in the update task of SAP standard processes where
possible. This is to avoid creating orphan records should the process abort before
completion – (including manual exit from the debugger).

Message Classes

New message classes will also be added, these should be used for programs and reports in
the corresponding new development classes. In line with other areas, error messages
should be created with English as their original language and be translated into other
languages. The Message class should be created with “ZXX” at the beginning of the
message class.

XX – Module like SD, QM, PP, MM etc.

Once these new message classes are put in place, additional documentation will be
provided.

While calling a message in the program, please check the message class with message
number exist in E1Q and E1P.

Use of generic messages

The use of a message containing just parameter symbols – for example & & & & is quite
prevalent in the ABAP Coding. This has the advantage that the text for a message can be
longer than 80 characters but the disadvantage that (for example) “where used” on
message 000(ZQM) returns very many uses, so if you are troubleshooting a problem and
you do not know where a message has come from, then “where used” is useless. So use of
generic messages is a legitimate technique, but the use of anyone must be limited so that
“where used” will completely meaningful. In general, each such message should have only
one use. More than one use is permitted only when it is immediately obvious which use has
generated a particular message, and all uses must be in a single Program, Function
Module, etc.
 ABAP DEVELOPMENT GUIDELINES

Source code organization

Source code of ABAP programs can be organized using INCLUDE programs. An INCLUDE
program is an ABAP program that is not generated independently but can be integrated into
one or more other ABAP programs using the INCLUDE statement.

INCLUDE programs should be created to provide for the source code modularization of
exactly one ABAP program only — an INCLUDE program should not be included in several
programs. Especially, do not use INCLUDE programs for reusing Type definitions, Data
declarations, Local classes, Procedure implementations. Use global service classes or
interfaces instead. The reuse of INCLUDE programs in several programs severely
constrains the maintainability of the programs as well as the maintainability of the
INCLUDE program itself. Changes in an INCLUDE program that is reused in several
programs can make programs syntactically incorrect. This can especially be a problem if
INCLUDE programs are reused in systems other than their original system.

Do not distribute functional units, i.e. processing blocks, over several INCLUDE programs.

For large programs, the use of INCLUDE programs is strongly recommended in order to
preserve program readability and maintainability.

For source code organization, use INCLUDE programs instead of macros. For functional
modularization, use procedures (methods) instead of macros.

Macro Usage

Although macros can also be used to organize programs, their use is discouraged for the
following reasons:

• They increase the difficulty of reading code.

• Their implementation in the ABAP language provides only a bare minimum of

functionality.

• You cannot debug into macro-generated code.

 ABAP DEVELOPMENT GUIDELINES

Identifying Changes

The main purpose is to convey information to others coming after you to facilitate their
understanding of the program changes that have been made. Please refer to section
‘Guidelines for Deleting Old/Unused ABAP Code’ in chapter ‘General Standards’ for
guidelines on deleting unused code.

Changes should be clearly marked within the program either by adding the change
reference as a comment at the end of each changed line, or by adding a comment at the
beginning and end of a changed section of code.

Transaction Codes

Transaction codes should begin with ‘Z’ for permanent transactions and ‘Y’ for temporary
transactions, Characters 2-3 should be module like SD, MM, PP and Characters 4 – 8 are
freely assigned but should relate to the program they execute. At any time, the Transaction
codes should not be created longer than 8 Characters.

For example, ZSDLAB – Label Print. Every program that is run directly by a user must have a
transaction code assigned.

Dialog Programs & Module Pools

The main module pool for a dialog program should be named as follows:

Position Description

1-4 ‘SAPM’

5-30 Meaningful additional text describing the purpose of the module pool.

E.g. SAPMZCOM Compliance maintenance

SAPMZDSP Despatch program

 ABAP DEVELOPMENT GUIDELINES

Function Modules

Function modules names should begin ‘ZXX_’ the remaining characters are open and
should be used to provide a useful description of the function of the function module.

XX - Respective modules

Object Classes

The names of global classes should begin with ‘ZCL_’, local classes within programs should
begin ‘ZLCL_’. For a class that can be used in all areas such as BDC input, the name should
start with ZCL_COMMON. Example: ZCL_COMMON_BATCH_INPUT.

A Catalogue of ‘ZCL_’ classes is being created on the Development Documentation

directory. Ensure that you add all new classes to this catalogue along with a brief
description for reusability.

Attributes: Follow the same naming standards as we have defined for all other ABAP
objects

Methods: Start with SET / GET / IS where appropriate.

The SET method will update data in tables / internal tables/ fields

The GET method will retrieve data.

The IS Method will test values and return a true or false value

Besides the above guidelines, methods should have meaningful names.

Interfaces: The names of interfaces should begin with ZIF_

 ABAP DEVELOPMENT GUIDELINES

Data Declarations

If it does not impact on the readability of the code, make these variable names meaningful.

i.e. data: G_CNT_ERR type I. Rather than G_CNT type I.

It is a good idea to define in a comment what data fields / includes contain.

e.g. data: G_CNT_ERR type I. “counter for number of errors in table GT_TAB

The following data types should be prefixed as described below.

Global data types

Constants GC

Work fields GV

Parameters P

Select options S

Internal tables / structures GT

Types GTY

Table work areas GS

Objects GR Local data (in performed routine) or Method

Work fields LV

Table work areas LS

Internal tables/structures LT

Object Reference LR

Field symbols <FS_>

 ABAP DEVELOPMENT GUIDELINES

No Local type/ constants declaration

Program Z_ABAP_STANDARD_DECL has been developed as a sample program to give clear

picture on Data Declaration

Similarly Class ZCL_CLASS_STANDARD has been developed as a sample program for

Parameters and data declaration in creating Classes and Method in ABAP OOPs objects

Import Parameters in Methods & Function Modules (Tables should not be used in Function
Module Interface) :

Tables IT_

Structure IS_

Variable IV_

Return Parameters in Methods & Function Modules:

Tables RT_

Structure RS_

Variable RV_

Changing Parameters in Methods

Tables CT_

Structure CS_

Variable CV_

Exporting Parameters in Function Modules:

Tables ET_

Structure ES_

Variable EV_
 ABAP DEVELOPMENT GUIDELINES

Transport Request

While creating and assigning a Transport request to a object the Transport request
Description should contain Ticket Number with short description of change.

Performance diagnosis

To diagnose performance problems, it is recommended to use the SAP transaction SE30,

ABAP/4 Runtime Analysis. The utility allows statistical analysis of transactions and
programs.

ODATA Development Guidelines

Please follow the guidelines below when creating or maintaining OData services in any of
the SAP development clients of Roquette.

General

• Don’t use underscores in the object names (Exception for Project). Instead
capitalize the name (Pascal case). E.g.: Use ‘countryGroup’ not ‘country_group’.
• Don’t use the same name for a property or navigation property and its enclosing
entity type. Field labels for the different objects are optional.
• Used descriptive names when filled. Use the extension ‘Code’ when it is a code and
‘Desc’ when it is a description (e.g. CountryCode & CountryDesc for Country).
• Implement authorization checks in the methods of the Data Providor Class. Use the
command “AUTHORITY-CHECK ” to do the authorization check on an Authorization
Object and additional fields. Eventually add the activity (ACTVT).

Entity Types

• An Entity Type correlates to a structure in Data Dictionary. Use descriptive names

for the Entity Type. Don’t use the SAP names. E.g. ‘Plant’ not ‘T00W’.
• The use of “Label” is not required. When you fill these fields, don’t use space.
Apparently not all systems that use OData-services can handle this.

Properties

• The properties can be manually entered or generated from a DDIC object. Only
generate from DDIC object (fills the “ABAP Structure Name”), when all or almost all
the fields of the structure are being used in the service. Reason for this is that the
 ABAP DEVELOPMENT GUIDELINES

objects generated will use the structure to pass the data. When you manually
specify the proporties, an internal type will be used with only the fields needed.
• Use descriptive names for the properties. Don’t use SAP names. E.g.: PlantCode not
WERKS. Don’t use HTTP method name (such as GET) as prefix, suffix or infix.
• At least one property should be a key property.
• Reduce the number of properties to reduce the network traffic.
• Assign the right data type.
• Don’t use [Link] for everything.
• Quantities and Values should be of type [Link]. Set Unit Prop. and
Semantics accordingly.
• NUMC-fields should be of type [Link] or [Link]
• Don’t use Binary properties. Also, not for media. It represents the media
as a string which will double the length. Do use media resources and
media link entries.
• If possible, assign a max length. For Decimals assign Precision and Scale.
• Fill the checkboxes ‘Creatable’, ‘Updatable’, ‘Sortable, Nullable’ & ‘Filterable’
accordingly. When the Entity Set has the attribute ‘Requires Filter’ or ‘Addressable’
set, then specify at least on ‘Filterable’ true.
• If the Entity Type contains a media link, you should check the box Media. For more
information see paragraph “Media Links”.
• The “Label” is not required but use descriptive names when you use it.
• Use proper fields names. These field names are the names you will be using in the
methods. Try to use the same name as SAP. E.g. for Country use MVGR1 because
this is the fieldname on the table. This will also be the fieldname in the structure
used in the methods.
• When the properties are changed for an entity type, you will need to update the
definition in the Central NetWeaver Gateway Hub. You do this with the following
steps:
• Double click on Folder “Service Maintenance”. Press button “Maintain”.
• On the next screen press “Load Metadata” to reload the Metadata of the Service.
The changed definitions are now available in Central Hub.

Entity Sets

• An Entity Set correlates to a Internal Table in Data Dictionary. Use the plural of the
Entity Type Name. E.g.: For Entity Type ‘Plant’ use ‘Plants’.
• The use of “Label” is not required. When you fill these fields, don’t use space.
Apperently not all systems that use Odata-services can handle this.
 ABAP DEVELOPMENT GUIDELINES

• Fill the checkboxes ‘Creatable’, ‘Updatable’, ‘Deletable’, ‘Pagable’, ‘Addressable’,

‘Seachable’, ‘Subscribable’ & ‘Requires Filter’ accordingly.

Association

• Use descriptive names for the Associations. Do only provide the associations
needed (that make sense). Within the naming convention, you should identify the
cardinality. Examples of Associations:
• CountryGroupCountries for and association (1:n) between Country Group
and Country.
• CountryCountryGroup for an association (1:1) between Country and
Country Group.
• The Label is optional. There is no need to use it.
• Within the Referential Constraints you specify the field names that should be joined.
Use the search help to select the field names. This is to avoid type errors.

Navigation

• The name should clearly indicate the destination of the navigation (e.g., from
a SalesOrderHeader to its SalesOrderItems).
• Use camel case to improve readability

Return Codes for HTTP

• 200 OK: Successful request with a response body.

• 201 Created: Entity created successfully.

• 202 Accepted: Batch request accepted but processing incomplete (asynchronous).

• 204 No Content: Request successful, but no response body.

• 400 Bad Request: Invalid input, format error, missing required fields, or technical
errors (e.g., invalid JSON).

• 401 Unauthorized: Authentication failed (invalid credentials, tokens).

• 403 Forbidden: Authenticated but lacks permissions for the resource/operation.

• 404 Not Found: Requested URI or resource doesn't exist.

• 405 Method Not Allowed: Unsupported HTTP method for the endpoint.

• 406 Not Acceptable: Unsupported response format (e.g., expecting JSON, got
something else).
 ABAP DEVELOPMENT GUIDELINES

• 500 Internal Server Error: Unexpected technical server error.

Frequently used query parameters in ODATA

$filter Selects a subset of entries by .../Products?$filter=Price lt 20

applying a predicate expression
(e.g., filtering by a specific value
or range).

$select Requests a specific set of .../Users?$select=givenName,surname

properties (columns) for each
entity, reducing the payload size.

$orderby Sorts the result set based on .../Products?$orderby=Rating desc

one or more properties in
ascending (asc) or descending
(desc) order.

$top Specifies the number of items to .../Products?$top=5

return in the result set, used for
paging.

$skip Specifies the number of items to .../Products?$skip=10

skip before returning the results,
used with $top for pagination.

$expand Includes related resources .../Categories?$expand=Products

(linked tables/entities) inline
within a single request, avoiding
multiple round trips to the
server.
 ABAP DEVELOPMENT GUIDELINES

$count Retrieves the total count of .../Users?$count=true (V4 query option)

entries in a collection, often or .../Users/$count (V2 resource path)
included alongside the results
for metadata.

$format Specifies the preferred format .../Products?$format=json

for the response, such
as json or xml.