Development Standards

Development Standards
=======================================================================================
=
SAP ECC Development Standards

Version 1.0
Page 1 of 37
Friday, March 18, 2016 3:53 PM
=======================================================================================
=
TABLE OF CONTENT
1.
SECTION SUMMARY......................................................................................................................................4
1.1
1.2
1.3
2.
OBJECTIVES.............................................................................................................................................. 4
SCOPE....................................................................................................................................................... 4
SUMMARY................................................................................................................................................. 4
DOCUMENTATION..........................................................................................................................................5
2.1
2.2
EXTERNAL DOCUMENTATION REQUIREMENTS..................................................................................................5

INTERNAL PROGRAM DOCUMENTATION REQUIREMENTS..................................................................................5
3.
TRANSPORT STRATEGY...............................................................................................................................9
4.
NAMING CONVENTIONS.............................................................................................................................10
4.1 IN GENERAL....................................................................................................................................................10
4.2 DEVELOPMENT OBJECTS.................................................................................................................................10
4.3 VARIABLE USE AND NAMING CONVENTIONS.................................................................................................15
4.3.1
Overall requirements:..........................................................................................................................15
4.3.2
Global Definitions:..............................................................................................................................15
5.
ABAP PROGRAMMING RULES..................................................................................................................17

5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
5.17
6.
GENERAL STANDARDS............................................................................................................................. 17
ERROR HANDLING..........................................................................................................................................18
USER EXITS/BADIS/ENHANCEMENT POINTS (UBE)...............................................................................18
AUTHORIZATION CHECKS........................................................................................................................ 19
TABLES................................................................................................................................................... 19
REPORT PROGRAMS................................................................................................................................. 19
FILE ACCESS...................................................................................................................................................20
GUI STATUS............................................................................................................................................ 20
READABILITY.......................................................................................................................................... 21
COMMIT WORK AND ROLLBACK WORK............................................................................................... 21
DESCRIBE........................................................................................................................................... 21
FREE.................................................................................................................................................. 21
SINGLE VALUE STORAGE..................................................................................................................... 21
CHECKING FOR MULTIPLE EXECUTIONS OF A PROGRAM.......................................................................22
NUMBER RANGES............................................................................................................................... 22
DATES ON FORMS............................................................................................................................... 22
MESSAGES.......................................................................................................................................... 22
PERFORMANCE.............................................................................................................................................24
6.1 DATABASE PERFORMANCE....................................................................................................................... 24
6.1.1
EXEC SQL statements are not allowed, Ever......................................................................................24
6.1.2
Logical Databases or not to be used...................................................................................................24
6.1.3
Fields in a select vs. select *...............................................................................................................24
6.1.4
Select into table............................................................................................................................24
6.1.5
Joins.....................................................................................................................................................24
6.1.6
Smaller, static tables............................................................................................................................24
6.1.7
..for all entries.....................................................................................................................................24
6.1.8
Keys and Index.....................................................................................................................................24
6.1.9
Defining new alternate indexes...........................................................................................................25
6.1.10
Nested Select statements.................................................................................................................25
6.1.11
Sort By.........................................................................................................................................25
6.2 ABAP PERFORMANCE.....................................................................................................................................25
6.2.1
Internal Tables.....................................................................................................................................25
Page 2 of 37
=======================================================================================
=
6.2.2
BDC Sessions/Call transaction...........................................................................................................25
6.2.3
Conditions............................................................................................................................................25
6.2.4
Field Assignment..................................................................................................................................25
6.2.5
Check Statement...................................................................................................................................26
6.2.6
Dead Code...........................................................................................................................................26
6.2.7
Commented Code.................................................................................................................................26
7.
DOCUMENTATION........................................................................................................................................27
7.1 CODE DOCUMENTATION..................................................................................................................................27
7.1.1
Constants and Variables.......................................................................................................................27
7.1.2
Form Routines......................................................................................................................................27
7.1.3
Revision History...................................................................................................................................27
7.2 APPLICATION DEVELOPMENT PROJECT DOCUMENTATION..........................................................................28
7.2.1
Review Documentation........................................................................................................................28
7.2.2
Unit Testing..........................................................................................................................................28
7.2.2.1
7.2.3
Page 3 of 37
Overview........................................................................................................................................................ 28
Background Job Definition..................................................................................................................28
=======================================================================================
=
1.
Section Summary
1.1 Objectives
The purpose of this document is to articulate a common set of standards and procedures for the naming,
development, and documentation of custom ABAP solutions in SAP with the goal of maximizing the quality,
value, and maintainability of the custom solution. This document is intended for to be used by everyone that will
be doing development in the SAP ABAP environment.
1.2 Scope
Naming standards for all ABAP related objects.
Guidelines and guiding principles to be followed for development objects.
Performance and optimization principles and requirements.
Documentation requirements.
Requirements for completing development objects.
1.3 Summary
These development standards have been created to promote clear, efficient and maintainable ABAP
development objects. These standards are to be followed by all developers and require adherence before an
object can be moved into a productive environment. The standards have very specific requirements that must
be followed as well as general guidance in how something should be developed. Where something is not
explicitly specified, the same general principle of these standards should be used to make a decision on what
path to take.
The standards are intended to form the basic foundation for development in ABAP and is intended to make
development objects consistent, efficient, and well documented. The Naming Standards are used for better
object administration and faster location of objects. The naming conventions used here are only relevant for the
SAP System and do not necessarily apply to any other systems or applications.
Page 4 of 37
=======================================================================================
=
2.
Documentation.
2.1 External Documentation Requirements

The external documentation that needs to be completed for each delivered object should be as follows:
Functional Specification
Technical Specification
Unit Test Plan
Documented executed Unit Test Plan
Documented performance and coding analysis using SAP tools.
Approval from the Technical Architect.
Approval from peer review.
This is, however, not a definitive list, and any other documentation which will assist in maintaining the program
should also be included.
The templates for Functional Specifications, Technical Specifications, and Unit Test Plans are not included in this
document.
2.2 Internal Program Documentation Requirements.

It is vital that an ABAP program be well documented within the source code itself. Anyone reviewing an object
should be able to understand not only what the object is designed to achieve, but also how it is achieved. To this
end, each developer must document all objects in such a fashion that the content and purpose of each part of
the program is evident. There are several specific documentation items that are required:
Object Header Description:

The object is to be clearly documented at the beginning of the program. The description should be clear
and explain what the program does and what it performs. It should provide an area for documentation
additional changes. The starting template for the header documentation is:
*&---------------------------------------------------------------------*
*& Report ZR_XXXXX.
*
*&---------------------------------------------------------------------*
*& Title
: Full Description of program
*& Item Ref
: RICEWF Number/Ticket Number
*& Date
: MM/DD/YYYY
*& Author
: Developer Name/User ID
*&---------------------------------------------------------------------*
*& M O D I F I C A T I O N L O G
*
*&---------------------------------------------------------------------*
*& Date
Programmer Request # Description
*&---------------------------------------------------------------------*
Page 5 of 37
=======================================================================================
=
*& mm/dd/yyyy Xxxxxxxxxx
XXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXX*
*&---------------------------------------------------------------------*
Program Description:
The program Description should be meaningful and include the Development Object Number in the title
if one exists.
Documentation Option
Program documentation option in ABAP library should be used to provide documentation on the
functionality of the object. For Programs, use the following documentation.
The Purpose section of the text object needs to be entered with a clear description of the program
and what it does
When there is a selection screen; selection screen fields needs to be documented in the program.
The remaining sections should be filled in where applicable.
Page 6 of 37
=======================================================================================
=
Page 7 of 37
=======================================================================================
=
Additional Documentation Requirements:

o
Use in-line comments when necessary to help the reader understand a particular process if it is
complicated.
Comment all subroutines and logical divisions of the program, indicating their purpose.
For call function module statements always use the Pattern button on the editor to add the
function module. Leave any parameters commented out if they are not used, they are not to be
deleted.
It is recommended, when practical, to use the Pattern functionality within the ABAP editor to
format ABAP statements.
Before the first transport of a program, remove all commented out ABAP statements to clean up
the program and to remove any future confusion about the program.
Page 8 of 37
=======================================================================================
=
3.
Transport Strategy
Transports manage the movement of development and customization objects through out the entire SAP
landscape. In order to help manage transports and to keep all instances in the landscape consistent the following
will be observed:.
o
Each RICEWF object is to have its own transport, and all objects related to it will be included in the
single transport if possible.
Each RICEWF object that requires development configuration will have all configuration on a single
customization transport.
Each transport will include the incident number at the beginning of the description.
Transports and Tasks on a transport are never to be deleted.
Objects on a transport task, are never to be deleted from a task. If an object on a task on a transport is
no longer required, the actual object should be deleted, not the line on the task. If configuration or table
entries are not needed, the configuration should be backed out or the table entries should be removed
from the table to fix the transport, it should then be released.
Undo/back out work no longer needed regularly to reduce a build up of unnecessary objects and to
prevent unwanted objects inadvertently being used by other RICEWF development or being moved to a
productive system.
Page 9 of 37
=======================================================================================
=
4. Naming Conventions
The following objects types define the object use.
R
Reports
Interfaces
Conversion
Enhancement
Workflow
Forms
Security
Utilities
Basis
The object use will be used in the naming of certain object types to help identify the purpose of the object.
When the object type is required in the naming of an object, it will be specifically noted.
4.1 In General.
All objects that are intended for a single use such as conversion programs, fix programs, load audit
programs or any other objects intended for a single use will begin with the letter Y.
All objects that are intended to be used after go-live or on a regular basis will start with the letter Z.
4.2 Development Objects.

1. Packages:
Position
1
2n <Component><Name>
Use
Z.
Descriptive Text
Example:
ZC2C package for C2C project
ZFIAA - package for financial asset accounting objects
ZECC_MM - ECC system, Material management application area
ZCRM_BILL CRM Billing application
You can also use area of developments in <NAME>
Page 10 of 37
=======================================================================================
=
For e.g. ZECC_DM Package for ECC data migration objects
ZCRM_IF Package for CRM interface objects
Note: In case of package interfaces please add _IF as suffix.
2. Programs and Reports:

Position
1
2
3
4-5
6 27
28 - 30
Use
Z
Object type
Application area (Ref. Appendix A)
Sub-area (Ref. Appendix A)
Short description of program
Usage: TOP Data Declarations, Tables, etc.

Fnn; Subroutines (Forms)
Where nn is a numeric integer between 00 and 99.
The following is an example customer program for the application area C, sub-area PC, and the
appropriate includes:
Program name ZRCPCPROGRAM
Data include
ZIPROGRAMTOP
Form routine include
ZPROGRAMF01
2.1 Naming Conventions for Module Pool and Module Pool Includes:
The purpose of this section is to define the naming conventions to be used for module pools and module
pool includes created in the SAP system. Module Pool names will consist of thirty (30) characters
formatted as follows:
Position:
1-4
SAPM - This is the SAP standard
Z - Indicates a user defined module
Application Area (Ref. Appendix A)
7-8
Application Sub-Area (Ref. Appendix A)
9-30
User-defined; should be meaningful for the application.
Module Pool Include object names consists of thirty three (30) characters formatted as follows:
Position:
1-27
Same as positions 5-30 in Module Pool name
28-30
Usage:
TOP Data Declarations, Tables, etc.
Onn; PBO modules
Inn; PAI modules
Fnn; Subroutines (Forms)
Where nn is a numeric integer between 00 and 99.
The following is an example customer module pool for the application area C, application subarea PC, and the appropriate includes:
Program name
SAPMZCPCPROGR1
Data include
ZCPCPROGR1TOP
Page 11 of 37
=======================================================================================
=
Form routine include
ZCPCPROGR1F01
PBO include
ZCPCPROGR1O01
PAI include
ZCPCPROGR1I01
3. Function Groups:
Position
1
2
3
4..n
Use
Z
Underscore _
Descriptive Text
4. Function Modules:
Position
1
2
3
4-5
6
7-30
Use
Z
Underscore _
Underscore _
Use descriptive words, separated by underscores
5. Tables:
Position
1
2
3
45
6 - 16
Use
Z
T for Table
Description of Table
6. Views:
View names can consist of sixteen (16) characters as follows:
Position
Use
1
Z
2
V For View
3.n
Table name of the SAP primary table
7.
Structures:
Position
1
2
3
4-5
6-30
Use
Z
S for Structure
Description of Domain
8. Data Elements:
Position
1
2
3..n
Page 12 of 37
Use
Z
E for Data Elements
Descriptive Text
=======================================================================================
=
9. Domains:
Position
1
2
3..n
Use
Z
D for Domains
Descriptive Text
10. Types:
Position
1
2
3..n
Use
Z
Y for Types
Descriptive Text
11. Search Help:

Position
1
2
3..n
Use
Z
H for Help
Descriptive Text
12. Lock Objects:

Position
1
2
3..n
Use
E SAP Requirement
Z
Descriptive Text
13. Type Pools

Position
1
2
3..5
Use
Z
P for Type Pool
Descriptive Text
14. Message Class.

Position
1
2
3..n
Use
Z
M for Message
Descriptive Text
15. Transactions:
Position
1
2
3
4-5
6 20
Use
Z
Object Type (RICEWFSUB)
Description
16. IDOC Message Types:

Position
1
2..n
Page 13 of 37
Use
Z
Descriptive Text
=======================================================================================
=
17. IDOC Types:

Position
1
2
3..n
Use
Z
IM for IDOC Type
Descriptive Text
18. IDOC Segments:

Position
1
2
3..n
Use
Z
E for Segment
Descriptive Text
19. Interfaces:
Position
1
2-3
4..n
Use
Z
IF for Class
Descriptive Text
20. Classes:
Position
1
2-3
4
5..n
Use
Z
CL for Class
Underscore _
Descriptive Text
21. SAPscript Form:

Position
1
2
3..n
Use
Z
F for SAPscript Form
Descriptive Text
22. Smart Forms:

Position
1
2
3..n
Use
Z
S for Smart Form
Descriptive Text
23. Interactive Forms:

Position
1
2
3..n
Use
Z
A for InterActive
Descriptive Text
24. Interactive Form Interface:

Position
1
2
3..n
Page 14 of 37
Use
Z
I for Interface
Descriptive Text
=======================================================================================
=
25. Authorization Object:

Position
XXX
Use
This is controlled by the security team.
26. Number Ranges:

Position
1
2
3..n
Use
Z
N for Number Range
Descriptive Text
4.3 Variable Use and Naming Conventions.
4.3.1 Overall requirements:

Definitions are always done at the beginning of a section. If definitions are Global, they must be done
before any other statements occur. Local variables occur at the start of the section they are being
defined in, and must be before any other statements.
4.3.2 Global Definitions:

The following definitions are to be done in the Global Data area of a development object and therefore
must be defined globally, these objects are not to be defined locally.
Types, Table Types
Constants
Ranges
The following are the naming requirements for global definitions.
Page 15 of 37
Definition Type
Prefix
Variables
GV_
Constants
GC_
Types
GTY_
Table Types
GTTY_
Internal tables
GT_
Selection screen Block
Selection screen block text
=======================================================================================
=
Selection screen parameter
P_
Select-options
S_
Ranges
GR_
Field Symbols
<FS_>
Objects
GO_
Class
GCL_
Forms
(Meaningful Name)
Modules
(Meaningful Name last characters must

be underscore and screen number)
The following are the naming requirements for local definitions.
Definition Type
Prefix
Form parameter (using / changing)
FP_
Variables
LV_
Tables
LT_
Objects
LO_
The following are the naming requirements for import and export parameters.
Function Module:
Import
IM_
Export
EX_
Changing
CH_
Table
IT_
Method:
Page 16 of 37
Importing
IM_
Exporting
EX_
Changing
CH_
Returning
RE_
=======================================================================================
=
5.
ABAP Programming Rules
5.1 General Standards
Object Header Description must be included and completed at the start of all objects.
Development objects should be designed and written to allow for restart ability from the beginning of the
program if a failure occurs.
Custom ABAP programs MUST NEVER be used to directly update SAP tables.
Before starting any development work, make sure that no existing functionality satisfies the same
requirements.
If possible, write code that it is re-usable and can be stored in a central library. Function modules and
classes are an example of this approach.
Keep program lengths to a minimum. Each program should handle a discrete problem. The ideal
program would have only one statement in the main section and it would be, Create Object.
One statement per line, and it is advisable that when creating statements that contain multiple options,
that the options be separated by line. Example of this would be the select statement where the SELECT,
FROM, INTO, WHERE, etc should be separated on individual lines to increase clarity when reading the
code. It serves no other purpose but to improve readability.
If a statement continues past one line, indent all subsequent lines.
Skipped lines and indention should be used to promote clarity between sections of code as well as
between file definitions and declarations.
Use the Pretty Printer Automatic formatting function for your programs to ensure uniform indentation of
program code
Use subroutines (FORMS) whenever possible to improve readability and logic flow. Create a subroutine
whenever a block of code is called from multiple places in a program.
SAP Supplies a very large library of function modules and classes that can be used to perform
numerous tasks. Take advantage of these to reduce development and testing time and increase
maintainability.
Common examples include:
CONVERT_TO_LOCAL_CURRENCY for any exchange rate based conversion
UNIT_CONVERSION_SIMPLE, UNIT_SUM when dealing with Units of Measure
RV_DOCUMENT_PRINT_VIEW (Sales Order) to get data from SD documents
RV_DELIVERY_PRINT_VIEW
(Delivery)
RV_BILLING_PRINT_VIEW
(Billing)
Define data structures as types to avoid the use of internal memory and promote readability.
Page 17 of 37
=======================================================================================
=
Always use the type statement when defining variables.
Use the underscore (_) to connect multi-word names for things like variables, Forms, etc, to make
programs easier to read.
Hardcoded values should never be used.
External PERFORM statement should not be used.
The following are never allowed in ABAP programs:
Direct Update of SAP tables.
Import/Export to Memory
Macros
Native SQL statements.
Use of any statement, Function Modules, Class or any other object deemed as obsolete by SAP.
Programs are to be formatted in the following manner.

o
Header comments and description.
Table definition.
Type definition.
Data definition.
Object Method definitions.
Selection screen.
Initialization events.
Selection screen events.
Any other events.
Main processing.
Forms.
5.2 Error Handling
All programs must include proper error handling to avoid undesirable terminations. This means that the
system status (SY-SUBRC) needs to be checked after every event in the program that changes it.
System status (SY-SUBRC) must be checked after a function module call or a select single statement.
Use the CATCH/ENDCATCH statement to trap runtime errors.
Use the TRYENTRY bock when working with objects to correctly catch exceptions with objects.
Whenever possible, use existing, relevant, standard SAP message classes to display errors.
When creating a new custom message class, it is required that the last message (Number 999) contain
four ampersands that are separated by spaces. This generic message can then be used to substitute in
specific message text before displaying.
Page 18 of 37
=======================================================================================
=
Error messages must be meaningful and provide information about the error.
Error levels need to be appropriately set, things to consider is the mode the program is being used such
as batch or dialog, roll-back requirements, severity of the error, etc.
Interface development objects need to have some method designed in it for error handling. The method
used should also take into account the possible options for updating SAP. Commit and Roll-back
processes should also be taken into account.
It is required that error handling be decided and defined before commencing development as this effects
the overall design.
5.3 User Exits/BADIs/Enhancement points (UBE).
User exits, BADIs and Enhancement points are designed to be used to update the process that they are
in and should only be used for that.
Other documents/master data/processes are not to be updated from within a UBE. There are many
issues with commit and roll-back as well as error processing when using UBE to update items outside of
the designed point and are not allowed.
The Commit Work statement is not to be used in UBEs.
UBEs can be used to start a standard SAP process such as a workflow, message process, or call to a
Proxy as these provide their own commit and error strategies.
Enhancement points permeate throughout SAP standard development objects and can now be used
almost anywhere.
Try to use an enhancement point to modify existing output reports instead of copying the SAP supplied
program and modifying the custom version. This will help reduce development effort and will keep
maintenance to a minimum.
Enhancement Points can not be used on SAP supplied dialog programs, interfaces, function modules or
classes without management approval. The risks to SAP processes is very high when doing these type
of enhancements and therefore require prior approval to make the changes to avoid any issues in the
entire process.
5.4 Authorization Checks.
As a rule, authorization checks should be used whenever appropriate to verify the access level of the
user executing the program.
Authorization objects will be created by the security team and used by the development team when
applicable.
5.5 Tables.
Custom tables require approval from the technical architect before they can be created or used.
Page 19 of 37
=======================================================================================
=
The creation of custom tables is controlled and authorization to create a new table must be received
from the technical architect.
All tables must be normalized.
All fields in a table must be defined using data elements from the data dictionary. Free form definition
of fields is not allowed.
Table Enhancement Category must be set.
All custom tables must have the table maintenance generated for it.
All custom tables must have an authorization group in the table maintenance. The authorization group
&NC& is not permitted.
Function Groups for table maintenance are to be named starting with YTM_ for one time objects,
ZTM_ should be used for all other table maintenance.
Data in custom tables that are static and are not dependent on clients, still need to have a field in the
table for client. They also need to be defined with delivery class C for customizing table. All data from
these tables must be transported.
5.6 Report Programs
Reports are always to be written using SAPs ALV controls. If the Object version of ALV is not used, it
must be explained why.
The report structure and definition must be defined as a structure in the data dictionary.
All text that is defined in the program should be done using text elements to support multiple
languages.
The main section of a report program should have very few statements. A good, clear program has very
few commands in the main section of the program, all other code should be defined in Forms or objects
which are called from the main section.
Use the standard function key definitions in these standards to define menus. All menus are to use the
standards menu functions and transaction values.
5.7 File Access.
Accessing filed from the application server is to be done using Logical Files. The basis team is to define
the logical file and set the directly path. The development team is to use the standard SAP Function
Module GET_FILENAME to get the physical file name for the logical file being used. There is never a
reason to use a physical file name on the application server.
5.8 GUI Status.

The following are the standard transaction/key assignments that are to be used in a GUI status if the functionality
is required on the Menu. These are defined on the Standard Tool Bar and only need to be defined if they are
relevant to the screen.
Page 20 of 37
=======================================================================================
=
Description
ICON
Function
Code
Function Text
Function
Key
Setting
Fast Key
Back
ICON_SYSTEM_BAC
K
BACK
Back
Exit Program
ICON_SYSTEM_END
EXIT
Exit
Cancel
ICON_CANCEL
CANC
Cancel
Print
ICON_PRINT
PRNT
Print
Find
ICON_SEARCH
FIND
Find
Repeat Find
ICON_SEARCH_NEX
T
RFND
Repeat Find
Save
ICON_SYSTEM_SAVE
SAVE
Save
Additional GUI status menu options that are to be used to make all GUI status menus consistent, If the value in
the table is blank, there is no specific standard.
Description
ICON
Function
Code
Function Text
Function
Key
Setting
Execute
ICON_EXECUTE_OBJECT
EXEC
Back
F8
Help
ICON_INFORMATION
IHELP
Online Help
Shift-F1
Delete
ICON_DELETE
DELETE
Delete
Shift-F2
Create
ICON_CREATE
NEW
Create
F5
Change
ICON_CHANGE
CHANGE
Change
F6
Copy
ICON_COPY_OBJECT
COPY
Copy
Ctrl-F5
Rename
ICON_RENAME
RENAME
Rename
Ctrl-F6
Display/Chang
e
ICON_TOGGLE_DISPLAY_CHANG
E
TDISCHG
Display/Chang
e
F7
Details
ICON_SELECT_DETAIL
DETAIL
Details
F2
Other Object
ICON_OTHER_OBJECT
TOBJECT
Fast Key
Shift-F5
The Menu Bar should always include all the functions used in the Application Tool Bar and must include any that
are defined to function keys but are not on the Tool Bar. There are no specific requirements on definition of the
menu bar.
Page 21 of 37
=======================================================================================
=
5.9 Readability
Start each new command or clause on a new line. Do not put multiple commands on the same line.
If a statement continues past one line, indent all subsequent lines.
Skipped lines and indention should be used to promote clarity between sections of code as well as
between file definitions and declarations.
Use the Pretty Printer automatic formatting function for your programs to ensure uniform indentation of
program code
Standard Form headings. Add appropriate form description to these headings. Note: Pretty Printer
only creates Form headings if no comment line exists after previous ABAP statement.
5.10
Commit Work and Rollback Work
COMMIT WORK is used when doing database operations. It concludes a logical process and releases
all database locks. SY-SUBRC is set to zero if the COMMIT WORK was successfully performed. Once
a COMMIT WORK statement has been executed, it is not possible to rollback (ROLLBACK WORK) the
previous database operations.
COMMIT WORK is implied when a process concludes, but an explicit commit work should be added at
the end of a logical unit of work.
COMMIT WORK is not allowed in User Exits, Enhancements or BADI as they objects tend to be within a
logical unit of work that already has a commit work elsewhere in the process.
BAPIs are not have any commit work within the BAPI as this is contrary to the concept of using BAPIs
as committing of data should be controlled by the calling process.
5.11
Use the describe statement sparingly. If properly defined, checking for data in a table can be done using
a simple if statement.
5.12
Describe
Free
The Free statement should be used with internal tables if it is necessary to release memory after
processing an internal table. This is needed when dealing with large tables. When a program terminates,
memory is automatically released.
Page 22 of 37
=======================================================================================
=
5.13
Single Value storage.
Sometimes it is necessary to keep track of a single value between executions of a program where the
current execution is dependent on the previous execution. Examples of this might be last date executed
or last time program executed.
When tracking a single value that is needed between execution of the same program, the TVARVC table
should be used to track this information. This is one of the few tables in SAP that can be modified
directly and it should be used in the following way.
o
The Parameter or Selection Option should have be the calling programs name, if a second or
third value is required by the same program, an extension should be used after the program
name such as _1 or _2, etc.
The program should assume that the value exists. The program must not populate the field with
a default if it is missing. Default values should be manually populated before the first execution
of the program. This can also be done by manually adding the entry in the table onto a transport.
5.14 Checking for Multiple Executions of a

program.
It is sometimes necessary to verify if a program is currently being executed. If a program needs to do this in
order to prevent duplication of program execution, this should be done using lock entries.
Use the SAP lock entry for the table TRDIR and use the lock argument of the current program
name. As programs should never be edited in production, this lock is never used.
Keep the lock entry active until the program has completed execution.
Always unlock the entry at the end of the program.
In the program that needs to check for duplicate execution, if the lock is not successful, then it is
already executing and should not be executed, the program should end with an information
message in the log. Only if specifically needed, should the program end in a manner than using an
information message.
5.15
Number Ranges
SAP supplies a method for creating custom number ranges. When there is a custom requirement to
keep track of sequential number for an object, the number range functionality should be used. These
number ranges work in the same manner as all other document/master data numbers ranges in SAP.
The transaction to access number ranges is SNRO.
Page 23 of 37
=======================================================================================
=
5.16
Dates on Forms
In order to correctly accommodate for different time zones, all dates must first be written to a character
field variable before being displayed. Dates are not to be printed directly using in a form. Use the
WRITE statement to a character field in order to correctly display a date on a form.
5.17
Messages
In every program a default message class should be specified in the report statement.
Every program should use MESSAGE statements for errors, warnings, and information.
It is important to use the appropriate message types to indicate different execution statuses of the program. The
design has to consider the different effects of each message type (refer to ABAP on-line help).
Type
Description
On-line action
Background action
Informational
Press ENTER to continue
No action. Message in Job Log.
Warning
Correction possible
No action. Message in Job Log.
Error
Correction required
Program terminated, Rollback of work.
Abend
Transaction terminated, Rollback of

work.
Program terminated, Rollback of work.
Success
Message on subsequent screen
No action
When designing messaging for reports executed on-line, it should be considered that the first message
with type E, A or X will cancel the execution of the report and the output will be lost.
When issuing a message from an on-line transaction or report the user should be able to correct the
problem on the current screen to avoid any dead-lock situation.
If a message includes program specific text the following format should be used.
message i999(zz) with YXBLNR insert successful(m05).
This message will use the contents of text-m05 with with, if it exists for sy-langu, else it will use the text
in quotes. This will provide ease of debugging and position the code to work well in multi-lingual
environments. (See Text Handling, above)
When creating new messages, long text for the message should be completed to give a thorough
explanation of the message being displayed. This should always be used when the error is not an
obvious error.
Page 24 of 37
=======================================================================================
=
6.
Performance
6.1 Database Performance.
6.1.1 EXEC SQL statements are not allowed,

Ever.
EXEC SQL statements are database dependent and cause problems during upgrades or changes to
database software and there is very rare occasion that it would ever be needed. The use of EXEC SQL
statements are not permitted.
6.1.2 Logical Databases are not to be used.

Outside of the HR module, the use of Logical databases are never to be used because of their poor
performance.
6.1.3 Fields in a select vs. select *.

Fields needed from a table should be specified in the select statement rather than selecting all fields from a
table. Select * should only be used when selecting from a database view or if most fields are required in a
table.
6.1.4 Select into table

It is more efficient to select multiple rows of data into an internal table than to process them through a loop,
however, large tables cause other performance issues and may not always be the best way to process a
table. For very large tables, try to reduce the data selection using a view and minimize the fields being
extracted to increase performance.
6.1.5 Joins.
Joins are not allowed in an ABAP program. If it is more efficient to do a table join when selecting data,
create the join in the data dictionary as a view. This will enhance performance of the view, help reduce the
number of fields being processed, increase reusability as well as force discipline in correctly defining how
tables are joined. Views, by definition, are much more efficient than a join in a program as the database
generates an index for the view when created it in the data dictionary.
Page 25 of 37
=======================================================================================
=
6.1.6 Smaller, static tables.
Smaller static tables that are reused within a program, or are checked frequently are more efficiently
accessed if stored in a global, internal table. For small static tables its is more efficient to read the internal
table than to call the table, even if the key is used.
6.1.7 ..for all entries....

The option for all entries is not allowed in select statements. This statement is very inefficient, especially
when dealing with a large amount of entries. Proper coding techniques and the use of views removes any
necessity for this statement.
6.1.8 Keys and Index.

Special attention should be paid to keys and indexes when accessing tables. Indexs substantially increases
the performance of database calls, pay attention to them when creating statements and views. Missing the
first field of an index or key, nullifies the indexs use and forces a hard search on a database, always include
at least the first field of the index or alternate index.
6.1.9 Defining new alternate indexes.

There may be times when adding an alternate index will help performance and it is possible to add them,
however, often there is a performance issue elsewhere when creating alternate index. The addition of
alternate indexes are controlled and require proper approval before they can be added.
6.1.10 Nested Select statements.

The performance of nested select statements is very poor, avoid them by either selecting data into tables
and processing the table, or, if possible, use a database view.
6.1.11 Sort By
The database manager is more efficient in sorting tables than ABAP is, try to presort data in internal tables
by using the sort by extension in ABAP SQL to increase performance.
Page 26 of 37
=======================================================================================
=
6.2 ABAP Performance.
6.2.1 Internal Tables.

Tables are to be defined used tables types and a work are can be defined for the table if necessary. The
occurs clause to create an internal table is not to be used. Header lines can not have the same name as
tables.
Sort internal tables only when necessary and explicitly state the fields to be sorted on. If necessary, use
hash tables on internal tables that require frequent sorting.
Read table with key is not a keyed read, it is a sequential read, sort the table before reading.
Use the collect statement correctly, it is intended for summarizing values as a table is being built, it is not
intended to remove duplicates, use the sort and delete duplicates statements to remove duplications.
If tables are properly defined, there is no reason to use the Refresh statement. A Clear statement to refresh
a table is all that is required. The Refresh statement should not be used, if memory needs to be freed, use
the FREE statement.
6.2.2 BDC Sessions/Call transaction.

BDC transactions and call transactions are to be avoided. SAP supplies many different methods for
updating documents including IDOCs, BAPIs, Classes, and Function modules. All these methods for
updating SAP must be tried before a BDC can be considered.
Use of a call transaction or BDC session requires approval from management.
If a call transaction is used, all errors must be saved as a BDC session to allow for manual correction.
6.2.3 Conditions.
When using conditions such as If or Case statements, conditions are processed sequentially so to reduce
execution time, the most common conditions should be listed first.
Always try to use the CASE statement over multiple IF..ELSEIF conditions. The Case statements will be
more efficient over several conditions, and it is much easier to read and maintain.
6.2.4
Field Assignment.
Use field symbols when looping through an internal table, especially ones that needs to be updated. This is
much more efficient than using the into statement on a table. This also makes updating of a table quicker
and easier, reduces memory usage and improves readability of the program.
Page 27 of 37
=======================================================================================
=
6.2.5 Check Statement.
To promote good modularization of programs, the check statement should be avoided. Additionally, rather
than doing a check upon entry to a FORM, use a condition before calling the Form. Dont call a form you
are simply going to leave, determine if the form should be executed before calling the From.
6.2.6 Dead Code.

Remove any unused Data declarations and any code that is never going to be executed. This can be
validated by doing the Extended Program Check.
6.2.7 Commented Code.

The first time a program is being moved, it must have all commented code, statements, variables, etc.
removed from the program before being released. Commenting of code should only be done when
modifying/correcting existing programs that have already been transported. This will help future
maintenance and readability.
Page 28 of 37
=======================================================================================
=
7.
Documentation
7.1 Code Documentation

It is vital that an ABAP program is well documented in the source code itself. Anyone should be able to
understand not only what the program is supposed to achieve but also how this is done. To this end, each
developer must document his/her code in such a fashion that the content and purpose of each part of the
program is evident. There are several kinds of remarks that are required:
Begin each program with a standard header comment (See program template in the Appendices
section)
Use the revision number to identify changes to the program.
Use in-line comments when necessary to help the reader understand a particular process.
Comment all subroutines and logical divisions of the program, indicating their purpose. Using the
Pretty Printer utility provides ready-made heading structures for subroutines.
Include detailed program documentation in the documentation module of the program. Do not
include detailed documentation in the standard program header.
The revision number shall identify every changed program line. (e.g. "R001" for all lines of code
changed during the first revision)
Copied programs shall have a reference to the initial program
Data declarations should be done in the beginning of the program for each data type, as in the
standard program template.
Logical units of code performing discrete tasks should be described
It is desirable to have a comment line written every 15-20 statements, that describes the subsequent
part of the program
7.1.1 Constants and Variables

Constants and variable should use a meaningful name that describes what it should contain.
7.1.2 Form Routines

All form routines should have an initial remarks section where you describe:
What the form routine does
Input/output parameters
Local work files / work tables used
Page 29 of 37
=======================================================================================
=
7.1.3 Revision History
All program revisions (changes) must be well documented according to following rules.
At the beginning of the program revisions should be documented as in the program template
For single line changes; Copy the line and convert the original line to a comment line and note it
with the revision number. Make the changes and then also mark the new line with the revision
number.
For multiple line changes: Add a comment line at the beginning and the end of the block to be
changed, this comment should contain the revision number and Start/End of changes.
The block to be changed should be copied. The original statements should be commented out, then
changes should be made in the copied block of code.
7.2 Application Development Project

Documentation
For each program, the following documentation must be completed:
Functional Specification the Functional Specification should be written jointly by the business owner
and a senior developer in the ABAP development team. The Functional Specification Document needs
to be signed off by the business owner/ report requestor before any development can begin on the
program.
Technical Specification this should be written by the ABAP developer prior to commencing coding.
This must be signed off by the programmers team lead before programming is started.
Quality Assurance Checklist before a program can be transported from the development system, it
must be QAd by the team lead/peer for efficiency of coding and adherence to the development
standards this process includes a peer review.
Unit Test Plan before a program can be transported from the development system, a completed Unit
Test Plan must be signed off by the developer. The testing documentation should consist of a unit test
plan which includes:
Unit Test Conditions
Expected Results
Test Data
Actual Results.
7.2.1 Review Documentation

Before a transport request containing ABAP program can be released and transported into the system test
environment, it must be reviewed and signed off by a designated reviewer.
Page 30 of 37
=======================================================================================
=
7.2.2 Unit Testing

7.2.2.1 Overview
The unit test is performed by the program author and should follow a relevant test case that covers all condition
sets that are possible when executing the program in a production environment. The unit test should verify
proper error handling and error exits using erroneous values. Each logical step within a condition should include:
Test data
Expected results
Actual results (Verification)
Unit testing should be completed in the development environment before any migration to subsequent systems.
Unit testing and the accompanying documentation (completed Unit Test Plan) should be completed, signed off
by the developer, and included in the program folder prior to submitting the program for subsequent testing
activity including System Testing and Migration Testing.
7.2.3 Background Job Definition

For any programs (interfaces, reports, etc.) that will be run as background jobs in the production system must
have a background job definition included in the program folder. This documentation is intended to support
monitoring and error recovery for background jobs in the production environment by providing:
job description and functionality overview
potential error conditions
error recovery logic and escalation procedures
contact persons
Page 31 of 37
=======================================================================================
=
Appendix A
Table of Application Area Codes

Description
Area Code
Sub-Area Code
AM - Assets Management
APO-Adv. Planning & Optimizing
DP Demand Planning
SN Supply Network
Planning
PP Production Planning /
Detail Scheduling
GA Global Available to
Promise
CO - Controlling
CRM-Cust. Relationship Mgmt.
Page 32 of 37
I0 Internal Orders
PC Product Costing
IB IBase
=======================================================================================
=
CM Contract Management
PS Professional Services
FS Field Services
IC Interaction Center
SC Service Center (InHouse Repairs)
Page 33 of 37
PL Prod. Lifecycle Mgmt
MW Middleware
BP Business Partner
PR Products
OP Opportunity Mgmt
QT Quotes
SO Sales Orders
PC Pricing
=======================================================================================
=
FI-Financial Accounting
LD Leads
CP Campaigns
AA - Asset Accounting
AP - Accounts Payable
AR Accounts Receivable
F
F
CC Cost Center Accounting
GL General Ledger Acct.
PA Profitability Analysis
PC Profit Center Acct.
SL Special Purpose Ledger
BW Business Warehouse
CA - fica
MM - Materials Management
Page 34 of 37
MR MMR
=======================================================================================
=
WD - Warehousing & Distrib.
HR Payroll/Benefits/PA
Page 35 of 37
ED EDI
IM Inventory Management
PR Purchasing
EN Engineering
CM Common MM
PI Physical Inventory
LE Logistics Execution
EM Export Management
WM Warehouse Mgmt.
TR Transportation
PY Payroll
BN Benefits
OM Organization Mgmt.
=======================================================================================
=
PP - Production Planning
PA Personnel Admin.
BW Business Warehouse
MS Mgr. Self Service
ES Employee Self Service
TM Time Management
PO Production Orders
MR Material Req. Planning
SP Sales & Oper. Planning
PM - Plant Maintenance
QM - Quality Management
QP Quality Planning
QI Quality Inspection
QC Quality Control
QN Quality Notifications
PS - Project System
Page 36 of 37
=======================================================================================
=
SD Sales & Distribution
MD Master Data
PR Pricing
SO Sales & Sales Orders
SH Delivery & Shipping
TP Transportation
BL Billing
ED EDI
SI Sales Information
CS Customer Service
IC Inter-company Sales
RE Returns & Adjustments
Basis
BC Basis Components
Cross Application
ZZ
Page 37 of 37

Development Standards

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Development Standards

Загружено:

Авторское право:

Доступные форматы

Development Standards

SAP ECC Development Standards

Friday, March 18, 2016 3:53 PM

EXTERNAL DOCUMENTATION REQUIREMENTS..................................................................................................5

ABAP PROGRAMMING RULES..................................................................................................................17

Friday, March 18, 2016 3:53 PM

Background Job Definition..................................................................................................................28

Friday, March 18, 2016 3:53 PM

Naming standards for all ABAP related objects.

Guidelines and guiding principles to be followed for development objects.

Performance and optimization principles and requirements.

Requirements for completing development objects.

Friday, March 18, 2016 3:53 PM

2.1 External Documentation Requirements

Unit Test Plan

Documented executed Unit Test Plan

Documented performance and coding analysis using SAP tools.

Approval from the Technical Architect.

Approval from peer review.

2.2 Internal Program Documentation Requirements.

Object Header Description:

Friday, March 18, 2016 3:53 PM

The remaining sections should be filled in where applicable.

Friday, March 18, 2016 3:53 PM

Friday, March 18, 2016 3:53 PM

Additional Documentation Requirements:

Friday, March 18, 2016 3:53 PM

Transports and Tasks on a transport are never to be deleted.

Friday, March 18, 2016 3:53 PM

4.2 Development Objects.

Friday, March 18, 2016 3:53 PM

2. Programs and Reports:

Usage: TOP Data Declarations, Tables, etc.

SAPM - This is the SAP standard

Z - Indicates a user defined module

Application Area (Ref. Appendix A)

Application Sub-Area (Ref. Appendix A)

User-defined; should be meaningful for the application.

Same as positions 5-30 in Module Pool name

Friday, March 18, 2016 3:53 PM

Friday, March 18, 2016 3:53 PM

11. Search Help:

12. Lock Objects:

13. Type Pools

14. Message Class.

16. IDOC Message Types:

Friday, March 18, 2016 3:53 PM

17. IDOC Types:

18. IDOC Segments:

21. SAPscript Form:

22. Smart Forms:

23. Interactive Forms:

24. Interactive Form Interface:

Friday, March 18, 2016 3:53 PM

25. Authorization Object:

26. Number Ranges:

4.3 Variable Use and Naming Conventions.

4.3.1 Overall requirements:

4.3.2 Global Definitions:

Types, Table Types

The following are the naming requirements for global definitions.

Selection screen Block

Selection screen block text

Friday, March 18, 2016 3:53 PM