SAP ABAP Development Guidelines and Standards

ABAP Object Guidelines and Standards

SAP PI has evolved over time and the platform name has changed over the years since starting out as XI. Our guidelines for object naming incorporate changes up to the current version of SAP PI and are being updated for the newly christened SAP PO (Process Orchestration).

These are intended to be guidelines and instructions on the use of SAP ABAP for programming in a business scenario. Guidelines, as opposed to standards, are intended to guide the user, not dictate the only way to utilize a programming language. There may be cases where development professionals will need to deviate from these guidelines and that decision is left up to the developer.

 

General Naming Convention

The following naming conversion applies throughout the guidelines and should be a general rule for naming any object unless otherwise specified.

  • Create names that are pronounceable.  If you cannot read the name out loud to someone, it’s not a good one. GLacct would not be pronounceable whereas glAccount would be better. Acronyms should be avoided unless their meaning is widely understood. (A good way to consider naming is that we are writing for someone other then ourselves to review.)
  • Use capitalization or underscore for new words.  In the example above, we use glAccount.  The capital letter makes it clear to the reader that these are separate words and makes it more readable than glaccount.  The other alternative would be gl_account. Note: the ABAP class builder forces all attributes to uppercase so it make sense to use “_” instead of capitalization to separate words, at least when using the ABAP language.
  • Avoid digits where possible. We don’t want someone misinterpreting 0 (zero) for O.

SAP ABAP Guidelines and Standards

Packages

(Called development classes in pre-4.6 versions.)

General Rules

Packages are the successors to development classes in older versions. They are closer to alignment with UML packages. Packages are containers used to collect all development types and classify them by their purpose. Packages should describe the functions within a project.  There are some restrictions imposed by SAP itself, as follows:
  • SAP standard objects use package names starting with A-S or U-X. Customer objects cannot be added to these packages.
  • Custom-developed, permanent objects use package names starting with Y or Z.
  • Like other repository objects, packages can belong to a prefix namespace if the relevant namespace is installed in your R/3 system. Packages begin with a namespace prefix enclosed in slashes (/). In a package of this type, you can only create object that belong to the same prefix namespace.
  • Package names can be up to 30 characters long.
Note: packages can be nested, thus allowing a fair amount of classification.

Suggested Naming Standard

 

Package Name  

<Prefix><Application Area><Separator><Description>

 

 

Glossary

 

Prefix Z, Y or namespace

Normal customer-developed objects should be prefixed with Z. Y should only be used when a object is local and will not be transported. When a namespace is involved, that would be used as a prefix, i.e. “/Prefix/FIDEV”.

Application Area FI, PP.MM, etc.

Functional Application Area. Note: it is typical to use SAP’s Application Areas but others work as well.

Separator  “_” use an underscore
Description Description of package data / Project

Examples

A custom package for development of a finance initiative:
ZFI_ARIMP
A package being used for local development that will not be transported: (Note: we do not recommend the use of the Y prefix. Rarely is there a need for a local object.)
YFI_ARIMP
A package being developed in a custom namespace for the Acme company:
/ACME/FI_ARIMP
Note: when using a custom namespace, the Z or Y prefix is no longer needed.

ABAP Programs - Non OOP

General Rules

Processing blocks are important to identify so as programs are modified, the processing blocks can be taken into context.

#”’AT-SELECTION-SCREEN”’
#”’START-OF-SELECTION”’
#”’END-OF-SELECTION”’
#”’AT LINE-SELECTION”’

The leading practice is to specifically identify these blocks within code for easier maintenance, readability and troubleshooting.

*————————————————————————
LOAD-OF-PROGRAM. “Called Once when program is loaded
*————————————————————————

Comments should support the ABAP coding.

Typically, comments can be extracted from functional spec documentation. They also provide the analyst reviewing the code a chance to see the functions supporting the spec.

Care should be taken to ensure that comments are not excessive. Thus, a comment should not be longer then the code it explains.

= Transaction Codes =
Transaction codes in SAP are used to access a transaction quickly. Typically, transaction codes are shorter then the program they are calling, though this is not a rule. Transaction codes also provide a method to verify user authorization for a specific application.

For OO purposes, the transaction code initiates the call to the MAIN class and method.

Transaction codes should follow a similar guideline as programs.

Suggested Naming Standard

ABAP Programs

 

Glossary

 

Example

I am writing a report to review material ATP. Though the program maybe named ZSD_MaterialATP, I use the guidelines above to use a transaction code of ZSDMATATP, which is easier to type in the command box.

Global Classes

Naming conventions for custom classes.

General Rules

 

Suggested Naming Standard

Class Name <Prefix><Class Prefix><Separator><Class Name>

 

Glossary

Prefix Z, Y or namespace. Normal customer-developed objects should be prefixed with Z. Y should only be used when an object is local and will not be transported. When a namespace is involved, that would be used as a prefix, i.e. “/Prefix/FIDEV”.
Class Prefix FI, PP.MM, etc.

Functional Application Area. Note: it is typical to use SAP’s Application Areas but others work as well.

Separator  “_” use an underscore
Class Name Use proper nouns such as COMPANY_CODE GENERAL LEDGER_ACCOUNT, etc.

 

Examples

A class should be named after the object it represents. For example, a master data class to maintain a vendor using the naming convention above could be ZCL_Vendor. A class to define a customer could be ZCL_CUSTOMER. There can any type of variations.

 

 

 

Persistent Classes

General Rules

Suggested Naming Standard

Persistent classes utilize the persistent services and provide an abstraction layer of the database tables.  Because they differ from standard classes, a leading practice is to identify them differently, so we recommend a separate naming guideline.

 

Glossary

 

Examples

A class that manages the persistence to a table called ZTAB would be named ZCL_PERS_ZTAB.

Class Attributes

General Rules

A class attribute similar to a variable in a regular program is a reference to a memory location where you can store data. An attribute of a class when instantiated is a block of memory reserved for an instance.

 

Suggested Naming Standard

Since they are isolated to the instance, attributes provide a little more flexibility in naming, and so naming should be descriptive of the attribute.  An attribute should use the following naming convention.

Attribute Name <Descriptive name>

 

Glossary

<Descriptive Name> Descriptive attribute name that identifies the value being captured, note Pascal case. When using multiple works, the first letter is capitalized.

 

Examples

An attribute for a country code could be CountryCode.
An attribute for a bool type identifying whether a document has been printed could be HasPrinted.
An attribute for a general ledger account could be generalLedgerAccount. Note: we do not use the acronym GLaccount (though we could), because it is less descriptive and the full name is very clear.
Remember that the length of the name has no impact on performance. It is only important for code clarity, so use as many characters as you need for clarity.

Note about self reference when referencing attributes within a method of a class. The use of me-> to reference the attributes is not required by ABAP itself but is, as a rule, a best practice to emphasize the distinction between local variables and class attributes that may be already available.

Object-Oriented Class Development

Global Classes

Naming conventions for custom classes.

General Rules

 

Suggested Naming Standard

Class Name <Prefix><Class Prefix><Separator><Class Name>

 

Glossary

Prefix Z, Y or namespace. Normal customer-developed objects should be prefixed with Z. Y should only be used when an object is local and will not be transported. When a namespace is involved, that would be used as a prefix, i.e. “/Prefix/FIDEV”.
Class Prefix FI, PP.MM, etc.

Functional Application Area. Note: it is typical to use SAP’s Application Areas but others work as well.

Separator  “_” use an underscore
Class Name Use proper nouns such as COMPANY_CODE GENERAL LEDGER_ACCOUNT, etc.

 

Examples

A class should be named after the object it represents. For example, a master data class to maintain a vendor using the naming convention above could be ZCL_Vendor. A class to define a customer could be ZCL_CUSTOMER. There can any type of variations.

Methods

General Rules

 

Suggested Naming Standard

Method Name

 

Glossary

Method Name Method name. Use clear verbs to describe what the method does, i.e. PRINT.

 

Examples

Method Parameters

General Rules

 

Suggested Naming Standard

Method Parameter <Type>_<Parameter description>

 

Glossary

Method Name Type of parameter. E = Exporting , I = Importing, etc.
<Parameter Description> Descriptive name for the parameter being passed.

 

Examples

A general ledger account class has server parameters identified for the constructor method. They are:

I_generalLedgerAccount
I_companyCode

Class Attributes

General Rules

A class attribute similar to a variable in a regular program is a reference to a memory location where you can store data. An attribute of a class when instantiated is a block of memory reserved for an instance.

 

Suggested Naming Standard

Since they are isolated to the instance, attributes provide a little more flexibility in naming, and so naming should be descriptive of the attribute.  An attribute should use the following naming convention.

Attribute Name <Descriptive name>

 

Glossary

<Descriptive Name> Descriptive attribute name that identifies the value being captured, note Pascal case. When using multiple works, the first letter is capitalized.

 

Examples

An attribute for a country code could be CountryCode.
An attribute for a bool type identifying whether a document has been printed could be HasPrinted.
An attribute for a general ledger account could be generalLedgerAccount. Note: we do not use the acronym GLaccount (though we could), because it is less descriptive and the full name is very clear.
Remember that the length of the name has no impact on performance. It is only important for code clarity, so use as many characters as you need for clarity.

Note about self reference when referencing attributes within a method of a class. The use of me-> to reference the attributes is not required by ABAP itself but is, as a rule, a best practice to emphasize the distinction between local variables and class attributes that may be already available.

Persistent Classes

General Rules

Suggested Naming Standard

Persistent classes utilize the persistent services and provide an abstraction layer of the database tables.  Because they differ from standard classes, a leading practice is to identify them differently, so we recommend a separate naming guideline.

 

Glossary

 

Examples

A class that manages the persistence to a table called ZTAB would be named ZCL_PERS_ZTAB.

 

Error Classes

General Rules

Error classes are classes specifically designed to trap errors from a class.

Suggested Naming Standard

Prefix ZCX_object name

Glossary

 

Examples

Preferably, the object name is the same as the class object name that it is linked to, so furthering out the example, the ZCL_generalLedgerAccount class has an Error Class called ZCX_generalLedgerAccount.

= Variable Naming =

Global vs. Local Objects
In ABAP objects, it is possible to isolate variables within the class instance. In standard procedural code, it is up to the developer to ensure they limit the variables available to only the modules that need access to it. Thus, all variables should be local to a module unless the variable will be used across modules.

Ready To Get Started?

Pin It on Pinterest