SAP ABAP Coding Guidelines

SAP R/3 SYSTEM

ABAP Development Guideline

Last modified by: Bunty Jain – SAP ABAP, Delhi, India, IT SAP Training [email protected]

Development Guideline 17-01-2012

MODIFICATIONS

Issue Date Modified by Modified pages

Observations

1.0 17-01-2012 Bunty Jain Created

Last modified by: Bunty Jain – SAP ABAP, Delhi, India, IT SAP Training [email protected] 2 of 35


Table of contents

1 Introduction......................................................................................................................41.1 Purpose of this document and target audience..........................................................41.2 Principles of software development and customizing.................................................41.3 Stepwise implementation............................................................................................61.4 Maintenance and validation of software quality..........................................................71.5 Update conventions for this guideline / exceptions / coordination..............................71.6 Basics and further documentations............................................................................7

2 Naming conventions for software objects....................................................................82.1 Naming conventions for dictionary objects.................................................................92.2 Naming conventions for workbench objects.............................................................102.3 Naming conventions for include objects...................................................................112.4 Naming conventions sources internal......................................................................122.5 Miscellaneous...........................................................................................................13

3 Uniform layout / maintenance......................................................................................143.1 Generals...................................................................................................................143.2 Dictionary..................................................................................................................15

3.2.1 Dictionary general.............................................................................................153.2.2 Dictionary – parts of database tables................................................................16

3.3 Programming............................................................................................................183.3.1 Structured Programming...................................................................................183.3.2 Transactions......................................................................................................203.3.3 Programming: design – maintenance – ergonomics........................................213.3.4 Programming Techniques.................................................................................233.3.5 ABAP/4 Security Programming.........................................................................263.3.6 Performance and SQL......................................................................................27

3.4 Checklist for code inspection....................................................................................284 Special guidelines.........................................................................................................29

4.1 user exit administration.............................................................................................294.2 Translation................................................................................................................294.3 Locking: database locking / SAP-object locking.......................................................294.4 Handling of change documents................................................................................304.5 Archiving...................................................................................................................30

5 Documentation...............................................................................................................315.1 Programs / function groups / module pools / function modules................................31

5.1.1 Program User Documentation...........................................................................315.1.2 Commenting......................................................................................................315.1.3 Comments for a change to a program..............................................................32

5.2 Data elements..........................................................................................................326 Approval of developments and rollout........................................................................337 Appendix........................................................................................................................34

7.1 Template of program................................................................................................347.1.1 Report with base and branching list (ALV)........................................................357.1.2 Reports with tree hierarchies............................................................................357.1.3 Module pool with dialogue and lists..................................................................357.1.4 Function groups with dialogue and lists............................................................35

7.2 Template of document..............................................................................................357.2.1 Transaction........................................................................................................357.2.2 Program.............................................................................................................357.2.3 Function group..................................................................................................35



1 Introduction

1.1 Purpose of this document and target audience

This Guideline provides development standards and examples for the Spares SAP R/3 system. Therefore design, style, naming and documentation conventions for an optimised Customizing and Development are defined in here. The document is created for all internal and external employees, which are involved in SAP- development, customizing and maintenance.

All conventions and procedures of this document have to be considered. Objects that does not fulfil the defined standards within this guideline, will not be accepted and not transported from the development instance.

The relevant official SAP-guidelines are the base for all developments and are linked within this document. This document is a further detailed guide for Spares development.

This document should be read in conjunction with further linked documents like the User exit administration P:\ATLAS-enhanced\00_OverallProject\45_ConfigurationManagement\Customer user exit administration_V1.1.doc

The naming convention is mandatory for all new or extensively changed objects and recommended for smaller changes of objects.

Developments have to be proceeded in English, always.

1.2 Principles of software development and customizing

Software has to be correct and stable to achieve low costs at a high service level. Therefore processes of software developments have to be structured and created with a unique logic and naming convention to be reusable.

All transport activities are coordinated and controlled by the Configuration Management.

All data design and development activities are coordinated and controlled by the Development Management.



Overview

The module abbreviations are furthermore used to identify object names (compare topic 3).

Development classes are created and managed only by the system administration.



1.3 Stepwise implementation

All developments which are not classified as local objects (using the ‘$TMP’ development class) can be transported. In general the procedure is carried out in the following steps:

1. Customizing: Client-copy of request (transaction SCC1) from AT1 client 300 to 3032. Transport to quality-assurance-system (AQ1/AQ2/AQ3)3. Testing of development or changes in environment close to production system

o Functional testo Extended syntax check and check of development guideo Documentation

4. Hand over authorisation concept for new reports/transactions !!!5. Transport to production system AP1 under consideration of defined rules

Transports of developments or changes can be divided into two different areas: service and project tasks. Therefore different procedures have to take place.

Service developmentsAll transports of service developments into the production system AP1 are subject to certain rules:

- release procedure, development can only be started if a GDP is opened and released by change board

- transport request is created by Configuration Management- changes have to be copied to AT1 303 (Customizing), transported and tested in AQ1 - for transport to AP1 all involved parties have to check and release changes;

signatures of the responsible persons have to be collected by developer on form (- transports can be realized by Spares Base Coordinator, completed form has to be

delivered by developer

Project developmentsAll transports of project developments are coordinated and done by the Configuration Management. This instance creates transport requests for special purposes using classification criteria such as data dictionary, customizing or service transports. Every developer is assigned to a separate task for developments in the specified request, the task will be proposed during saving procedure of development or changes.

1.4 Maintenance and validation of software quality



This document has been created to deliver an overview of all necessary procedures for an optimised development and thereby the set up and maintenance of an efficient and largely error-free system. The handling of lock- and authority objects, naming conventions and the Spares user exit concept is specified in detail.

As Part of approval of a change/project task/ GDP the responsible SPL has to approve that all changed objects provide the development guideline.

Within development coordination, tools and procedures for a continuous inspection of development activities have been set up. Therefore, periodical (daily) runs of programs checking, if actual development / whole customer development follows the guidelines.During export of transports it is checked, if objects of transport follows the guidelines (error list, export abort, …).

1.5 Update conventions for this guideline / exceptions / coordination

During upgrade to a new release of a SAP system, a new suite of standard ABAP objects is supplied. This will certainly overwrite any modifications to SAP standard code, but all customer -specific code that is prefixed with a Z or a Y will not be affected.

Updates of this guideline will be released by SMO42 if necessary.

1.6 Basics and further documentations

Link SAP Style Guide

Link SAP BC Namespaces and naming conventions

Link SAP workbench changing the SAP standard

SAP ergonomics examples Check SE38 Menu ’Environment’ ‘Ergonomics Examples’

SAP performance examples Check SE38 Menu ’Environment’ ‘Performance Examples’

Make sure that computer is connected to Internet and authorization for network folders exist to use links.


http://help.sap.com/saphelp_nw04/helpdata/en/c8/19764143b111d1896f0000e8322d00/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/57/38dec24eb711d182bf0000e829fbfe/frameset.htm

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCDWBERG/BCDWBERG.pdf


2 Naming conventions for software objects

General naming conventions and structuring standards can be found in SAP online documentation. http://help.sap.com/saphelp_46c/helpdata/en/57/38e0ad4eb711d182bf0000e829fbfe/frameset.htm

This section describes the additional naming conventions that will be used for customer own developments.

Test programs:To be able to separate test programs from migratable developments, it will be necessary to distinguish them via naming convention (see below). These objects have to be classified as local objects (assignment to development class $TMP).

Language:All descriptive names or parts of names have to be entitled in English.

General naming rule: Z<Area>_ (<Area> = module, compare topic 1.2)

Wizards:Object names generated by wizards are allowed and should not be changed after generation.

naming conventions:All existing naming conventions that are not included in this document are obsolete.


http://help.sap.com/saphelp_46c/helpdata/en/57/38e0ad4eb711d182bf0000e829fbfe/frameset.htm

http://help.sap.com/saphelp_46c/helpdata/en/57/38e0ad4eb711d182bf0000e829fbfe/frameset.htm


2.1 Naming conventions for dictionary objects

Object Naming convention Lgth. Example

Database Table - transaction data- master data- control data- text data

ZD<Area>T<nn>_<xxxxxx> 16 ZDSDT01_FHS

View - database view- projection view- help view- maintenance view- Viewcluster

ZD<Area>V<nn>_<xxxxxx> 16 ZDSDV01_FHS

Structure - file creation- global structure- local structure- db -access structure- ranges- dynpro structure

ZD<Area>S<nn>_<xxxxxx> 30 ZDSDS01_FHS

Table Appends ZA<xxxxxxx> ZAMARAAppend-/CI-fields ZZ<xxxxxxx>, YY<xxxxxxx> ZZDOMAINData element ZD<Area>A_<xxxxxxx> 30 ZDSDA_WERKSDomain ZD<Area>D_<xxxxxxx> 30 ZDSDD_WERKSTable type ZD<Area>Y_<xxxxxxx> 30 ZDSDY_WERKSSearch help ZD<Area>H_<xxxxxxx> 30 ZDSDH_WERKSLock object EZD<Area>L_<xxxxxxx> 16 EZDSDL_WERKS

First of all please check the existence of the required object. Where possible you should use the standard SAP data elements and domains.

Any changes to the standard SAP tables must be approved by the Configuration/ Development Manager.

If a new object is required, a name that is as meaningful as possible should be given.

The Development Manager is responsible for ensuring that the change is necessary and will discuss changes with responsible Spares colleagues. Changes to standard SAP fields or standard SAP tables should be avoided, appends can be used. SAP objects must not violate the naming conventions.

Note that all database tables should begin with client number defined in the MANDT element.



2.2 Naming conventions for workbench objects

Object Naming convention ExampleTransaction Z<Area><xxxxxx> ZSDCONArea Menus Z<Area><xxxxxx> (s.a.)Message Class Z<Area>_<xxxxxx> (s.a.)Number Range Object Z<Area>_<xxxxxx> (s.a.)Change Document Z<Area>_<xxxxxx> (s.a.)Parameter-ID Z<Area>_<xxxxxx> (s.a.)Testreport, Local object

ZTEST<User>_<xxxxxx> ZTESTSIEG_CONVERT

Report Z<Area><nnn>_<xxxxxx> ZSD001_CONVERTModulpool SAPMZ<Area><nn>_<xxxxxx> SAPMZSD01_CONVERTFunction Group ZG<Area><nn>_<xxxxxx> ZGSD01 _CONVERTFunction Module Z_F<Area><nn>_<xxxx>_<xxxx> Z_FSD01_CONVERT_DATADialog Module Z<Area><nn>_<xxxxxx> ZSD01_CONVERTGUI-Status S<nnnn> S0100GUI-Title T<nnnn> T0100Class ZCL_<Area>_<xxxxxx> ZCL_SD_ CHANGE_DATAInterface ZIF_<Area>_<xxxxxx> ZIF_SD_ CHANGE_DATABADI-Definition (recommended name should be

used)(automatically)

BADI-Implementation Z<Area>_<xxxxxx>Subroutine Pool (like Modulpool)

<Area> = Module area of the module pool (see table 1.2 above )<User> = SAP-User of Developer<xxxxxx> = Free text with any additional information<nn> = 2 character number that uniquely identifies the object (in combination

with other characters if given)<nnn> = 3 character number that uniquely identifies the object (in combination)<nnnn> = 4 character number that uniquely identifies the object (in combination)

function modules used for web portal interface have to consider extended naming convention: Z_F<AREA><nnn>_BAPI_<xxxxxx>.



2.3 Naming conventions for include objects

Object Naming convention Example

Report- Frameprogram- Data-Include- Event-Include- PBO-Include- PAI-Include- Subroutine-Include

Z<Area><nn>_<xxxxxx>Z<Area><nn>_<xxxxxx>TOPZ<Area><nn>_<xxxxxx>EnnZ<Area><nn>_<xxxxxx>OnnZ<Area><nn>_<xxxxxx>InnZ<Area><nn>_<xxxxxx>Fnn

ZSD01_FHSZSD01_FHSTOPZSD01_FHSE01ZSD01_FHSO01ZSD01_FHSI01ZSD01_FHSF01

Modulpool - Frameprogram- Data-Include- Event-Include- PBO-Include- PAI-Include- Subroutine-Include

SAPMZ<Area><nn>_<xxxxxx>MZ<Area><nn>_<xxxxxx>TOPMZ<Area><nn>_<xxxxxx>EnnMZ<Area><nn>_<xxxxxx>OnnMZ<Area><nn>_<xxxxxx>InnMZ<Area><nn>_<xxxxxx>Fnn

SAPMZSD01_FHSMZSD01_FHSTOPMZSD01_FHSE01MZSD01_FHSO01MZSD01_FHSI01MZSD01_FHSF01

Functiongroup- Frameprogram- Data-Include- event-include- PBO-Include- PAI-Include- Subroutine-Include

SAPLZ<Area><nn>_<xxxxxx>LZ<Area><nn>_<xxxxxx>TOPLZ<Area><nn>_<xxxxxx>EnnLZ<Area><nn>_<xxxxxx>OnnLZ<Area><nn>_<xxxxxx>InnLZ<Area><nn>_<xxxxxx>Fnn

SAPLZSD01_FHSLZSD01_FHSTOPLZSD01_FHSE01LZSD01_FHSO01LZSD01_FHSI01LZSD01_FHSF01

To ensure data definition will be as local as possible, PBO– and PAI–Modules should only contain one call of a subroutine (‘PERFORM xxx’).



2.4 Naming conventions sources internal

General naming rule: <local/global ><type>_<description>

Each data object has to be defined as TYPE “Data-Dictionary-reference” or “basic-data-type” whenever possible.

Use Data Dictionary as reference where possible.

Object Naming convention ExampleType <L/G>TY_<descriptive name> LTY_WERKSTabstrip Control <L/G>TS_<descriptive name> LTS_WERKSStrip-Name <L/G>SR_<descriptive name> LSR_WERKSStrip-Functioncode <L/G>SF_<descriptive name> LSF_WERKSTableview Control <L/G>TC_<descriptive name> LTC_WERKSParameter <L/G>P_<field name> (1) LP_WERKSSelect Option SO_<field name> (1) SO_WERKSRange <L/G>R_<descriptive name> LR_WERKSInternal Data Structure <L/G>S_<descriptive name> LS_EKKOInternal Table (Sorted/Index/Hashed/…)

<L/G>T_<descriptive name> LT_EKKO

Field-Symbol <L/G>_<descriptive name> <L_WERKS>Variable <L/G>V_<descriptive name> LV_WERKSConstant <L/G>C_<field name> (1) LC_WERKSMemory-ID M_<descriptive name> M_WERKSField Group FG_<descriptive name> FG_WERKSFunction module interface

Import variable Import structure Export variable Export structure Changing variable Changing structure Table

IV_<descriptive name>IS_<descriptive name>EV_<descriptive name>ES_<descriptive name>CV_<descriptive name>CS_<descriptive name>T_<descriptive name>

IV_WERKSIS_T001WEV_WERKSES_T001WCV_WERKSCS_T001WT_T001W

<L/G> = Validity of object, L = local use only, G = global use in main program

(1) = <field name> TYPE <Data Dictionary field> or TYPE <ABAP type> where <field name> = ‘SAKNR’, ‘BUKRS’, ‘MATNR’, etc.

Where a variable or constant contain a standard SAP field, the name should be as clear as possible to ease documentation and naming clarity. Variable names should be limited to between 15 and 20 characters wherever possible.Use of single letter variable names should be avoided, because it makes code difficult to read.



2.5 Miscellaneous

Object Naming convention ExampleSubroutine <name> ACTIVATE_PROFILEModul Dnnnn<name> D0100_ACTIVATE_PROFILEDynpro/ Subscreen <nnnn> 1000Lists <nnnn> 1000



3 Uniform layout / maintenance

3.1 Generals This section describes guidelines for the best practice approach for design and implementation of ABAP Code.

Development classesThe customer development classes are predetermined by system administration. Development classes are separating the objects for each sap module, for projects or enhancements.Generally development classes are application area specific (only in special cases, objects can be assigned to project specific development classes).Overview of standard development classes: compare topic 1.2.

Status of developmentsSoftware objects have to be all the time in all systems and all clients syntactical correct and executable. Consequence: Enhancements and modifications that are not syntactical correct, will not be executed or transported to avoid affecting productive processes.

Dumps, aborts of update tasks, incorrect update tasks causing system log entries for example are symptoms of invalid system design. The invalid processes have to be corrected / redesigned.

Language and translationDevelopment language is English. Developments have to be translated to German, optional translations (service and warehouse in national languages) are part of development and part of approval. Rollout will be done within the development transport. All developments and data designs have to support translation in different languages (details have to be specified in the requirements).

ModificationsModification of SAP objects can only be realised with permission of Application Manager and Configuration Manager. These instances have to analyse the context within the following areas before the SAP-standard is modified:

- SAP standard- Customizing- SAP-enhancements (Customer exits, BADIs, BTEs...)- Customer development (work around)- Modification: efforts / risks / release upgrade consequence/ rollout)

For all modifications of SAP objects, the usage of modification assistant is mandatory.

Object registrationSSCR object registration will only be done by Spares system administration.

(Check especially Chapter 4)



3.2 Dictionary

3.2.1 Dictionary general

Data model Enhancements of the data model have to be done as close as possible to the SAP data model. That means: - use SAP standard-Features- append attributes to SAP tables (customizing as well as master data tables)- create customer own tablesTo protect SAP-standard data and avoid problems with conversions and rollout, data design has to be coordinated with Development and Configuration Manager.

IMG The enlargement of SAP-IMG with maintenance of customer customizing tables is optional

Languages Multi lingual options: - Text always in separate text tables, language has to be used as key field- Connect text tables by foreign key with option “check required” and text

relation with main table

Performance Inspections of performance critical table accesses are necessary. Therefore, performance can be measured using ST05 in AQ-or AP-system environment. Performance can be optimised e.g. with secondary indexes or optimised select statement

Table types The use of table type Pool or Cluster is forbidden, these types are obsolete. Only transparent tables can be used

Assignment Generated functions and manual created functions never mixe up in one function group. In regard of further release upgrades, table maintenance functions have to be assigned to separate function groups.

Authority groupFor each database table a valid authority group is mandatory. Blank or dummy entry ‘&NC&’ is not acceptable. The authority group can be chosen from overview topic 1.2. Authority groups can also be maintained using view V_DDAT_54 with transaction SM30

Data browserThe maintenance of tables with the data browser (SE16) is only allowed for developer concerns in the development system. Remove maintenance flags before export because SE16 supports neither checks nor change documents or CTS-interface.



Settings To avoid problems during procedures like client-copy and transports, the delivery class of customer tables should be considered. The following settings are recommended:

Setting Customizing tableMaintenanceLocal | AT1 300

Application tableMaster- | Transact.-Data | Data

Reason

Changes - ‘Log data changes’- ‘Change documents’

(data elements)

X X system audit

X X system audit

Buffering (Technical settings - ‘buffering switched on’ and ‘Fully buffered’)

X XTuning

Data class (Technical settings) USER1 USER1 USER USER

physical separation SAP and customer DB tables

Delivery class (Attributes) A C A A

Delivery

CTS (Change and Transport System) X

Delivery

Further details of Change document creation are delivered in Chapter 4.5 Handling of change documents.

Use of the correction-interface is mandatory for customizing tables that are maintained in development system.

3.2.2 Dictionary – parts of database tables

Columns The Deletion of columns or change of format for existing columns is forbidden. Work around: creation of a new column, manual data conversion and mark old column as obsolete.Otherwise: Wrong processing increases the roll out risk of data conversion error

Fields Field enlargement is allowed

To avoid null values during table conversion, new columns have to be filled initially by a migration-program

Text tables Separate text tables with foreign key to main table (text relation)



Check tablesCheck tables have to be maintained by foreign keys

Namespace Customer appends/ includes at sap tables have to be created considering the ZZ* /YY* namespace



3.3 Programming

This section contains guidelines of programming techniques and has to be used in conjunction with the SAP help.To facilitate further maintenance of ABAP programs, their structuring should be well considered. This section details the requirements for programs regarding their layout and structure, further examples and standard programs are provided in the appendix.

3.3.1 Structured Programming

ABAP Program LayoutThe events ‘START-OF-SELECTION’ and ‘END-OF-SELECTION’ should be utilized. These events mark the main part of the program and should show any programmer the key process of the program.

Templates The usage of program-templates and documentation-templates is mandatory (compare topic 8)The following structure represents a guide to event and section sequencing:

Template of program

Separation in logical and processing modulesABAP reports or dialog modules are structured by events. For every event, 1 up to max. 10 subroutines has to be assigned. On this level only the PERFORM / call function-statements are allowed. Coding is contained in subroutines/function modules.

A subroutine/function module always has one of the following functions:- controlling of the program course- execution of a combined processing block

A source unit has to be structured as follows:- a subroutine/function module may be called only by one subroutine/function

module- the interface is be set up via USING/ CHANGING –statement (function module

analog: exporting, importing…)- within the subroutine/function module, no data outside the USING/ CHANGING

–extent will be accessed (analog function modules..)- all USING/ CHANGING –parameters have to be specified by TYPE –addition

(analog function modules)

Avoiding deep nesting levels

Keep all nesting structures simple. Complex programs has to be divided into e.g. subroutines. Rule: Avoid nesting depth of more that 3 levels.



Design of small manageable source units

Coding has to be separated in subroutines, functions or methods. Every unit contains approx. 30 lines of executable coding.

Usage of literals

Literals, which are language-dependent, have to be defined as text objects (in English) and have to be translated at once. When they are language-independent, they have to be defined as constants (exception: numbers, which are used as numbers, headings of reports and columns, selection field declarations e.g. on selection-screens text elements).Constants are defined without includes.

Usage of messages

Messages are used, to signalise program status to the environment.

Handling of unused coding

Unused coding has to be deleted, not only commented out. To save intermediate results, temporary versions have to be used. Version management supports analysis of all older source versions.

Change management

Maintain change history for every kind of change in source head. The following data are necessary:

- project or change request/GDP, to define the reason of changes- date - name of developer and identifier in the sourcecode- short description with the scope of changes

Standardization

It has to be ensured that all developments are compatible with ABAP Object Standard. This requirement includes that no obsolete statements are contained and all kind of developments have to provide Unicode.



3.3.2 Transactions

All programs that can be run using transactions SA38/SE38 should be set up with a transaction code. This is necessary to fulfil the requirements of security implications (compare topic 4.4.5), to offer the implementation into an area menus and for reasons of conformity with SAP standard.To ensure that transactions can only be accessed by passing an authority-check, checks for organizational units like company code, plant or sales organization have to be implemented. The general authorisation for a specific transaction using the roles assigned to the user master should be an exception and should be well-considered.

General design: An update transaction has to consider the following steps and sequence on the defined sequence:

- lock object- read object- change/ delete/ create object- check object- optional : Implementation of CTS-Interface (Change and Transport System)- save object (optional: by update task)- optional : change documents/ table logging- commit work - unlock object

(integration in archiving concept ?)

For an easier usage it is recommended to keep the transaction names as short as possible, using the R/3 standard method.E.g. Profitability Analysis Report: ZFIPROFIT_ANALYSIS ZFIPROThis, however, could depend on the number of custom programs and customer requirements.



3.3.3 Programming: design – maintenance – ergonomics

3.3.3.1 General

Local ObjectsOnly temporary programs are permitted to be defined as local object (and only in development system). System administration and Configuration-/ Development Management have the right to delete local objects at any time. Inefficient references like local DDIC objects or customizing exits build a high risk for rollout management.

Data definitionsFor internal tables separate work areas should be used.Regarding capsulation, local data definitions should be preferred.

Authority All reports and transactions have to check the authority objects corresponding to the SAP objects

ALV Lists generally have to be displayed via the ABAP List Viewer (ALV)

Menus For every report or transaction screen a menu including standard menu has to be implemented

Restart For functions with more than one update part a restart function is mandatory

Document Report or transaction documentation has to be implemented in menu

Wizards Wizards like tab strips and table controls etc. are a very efficient and useful technology to implement these features. If you need these features please use the wizards.

Step loops Variable step loops are forbidden ( table control)You will find various control examples in the workbench

Separation/ Procedures that have to be processed only for a selection of companies/User exits plants/ sales organisations should use customer/ user exits. These exits are

controlled by own customer exit administration (compare topic 5.1).

Offsets Offsets must not be used in ABAP-Coding, the work with structures is recommended

Comments Comments in the sources have to be implemented in English. At least every 10 lines of coding a comment line is necessary.When assign-statements are used, an extended inline-documentation is obligatory.Compare Commenting

Control If user has changed data and wants to exit or cancel a screen without saving, a confirmation popup („Lost-of-data”) has to be raised



Hard coding Hard coded control information is strictly prohibited. Customizing tables or constants can be used to assign fixed values

Datasets For handling of data path names, basis customizing “platform independent filenames” has to be done. Only dataset name is changeable for user, never the path.Before opening a dataset open or transfer into it, dataset authority has to be checked to avoid dumps caused by missing authority (implement function AUTHORITY_CHECK_DATASET)

Pretty printer To uniform programs, the ‘Pretty printer’ formatting command has to be used to automatically format code for neatness and readability.Use settings as follows (SE38 or SE80 menu Utilities Settings):

Logical DatabasesAvoid use of logical databases wherever possible - use SELECT statements instead. (Logical databases are good as a reference tool to look up database hierarchies).

Debugging This tool is very useful during the unit testing to ensure programs are executing as desired. For test concerns in the development system, the syntax BREAK <username> is recommended instead of using BREAK-POINT. This will ensure, that the processing stops only if the program runs with the specified username.Before export, all breaks have to be removed or commented out (for further test requires).



3.3.4 Programming Techniques

A number of programming techniques are detailed in the following.

3.3.4.1 Program Attributes

In the following a checklist of fields and options that have to be selected is given:

No. Field/ Option Selection variants / Comment1 Type 1 – Executable program

I – Include programM – Module pool (screen painted transactions)

2 Status K – Customer Production ReportT – Test Report

3.3.4.2 Code Reuse : Subroutines – Function modules

This section describes the different available options for the reuse of code. When designing and coding programs, these options should be kept in mind to reduce further development work and standardize coding.Local used procedures can be separated in subroutines. For global use, you have to create function modules. Generally, function modules should be used wherever possible to avoid rewriting the same code.

Attention: Syntax of a function module can be checked only as check of the function group. Therefore a new function module must not be assigned to a standard SAP or any existing customer own function group without contacting Development Manager.If a syntax error occurs in a function group, it will render the entire function group inactive what will have serious consequences!

3.3.4.3 Include Programs

INCLUDE programs are created to modularise the whole program source code (report / module pool / function pool) and help to enhance the readability and maintainability of the coding.

Whenever possible, the use of INCLUDES should be considered within the design.



3.3.4.4 Program Header

All ABAP programs (copies of SAP standard programs, function modules, own reports and includes) have to use a standard program header (see program template ZBC01_TEMPLATE_GENERAL). The format of this header should be in the format shown in the template. The purpose of the program must be documented within the header.

Furthermore this standard program header can be implemented as predefined pattern using the menu path Edit Pattern Other pattern PGMHEADER

The program header is also used to document changes within the program and to represent a reference point to navigate around the changes. Each additional change should be logged with a transport request number and a unique identifier. In the case of application of OSS notes it is necessary that the concerned OSS Note Number is added to document the changes. This reference will reduce the effort, if the program changes need to be re-implemented during a version upgrade.

************************************************************************** Program : ZBC01_TEMPLATE_GENERAL** Developer : Bunty Jain** Project : <project>** Requested by : Mr. Blockwitz** GDP No./GPP Doc. : <gdp-no./gpp doc>** Created on : dd.mm.yyyy************************************************************************** Functionality : General pattern to create a new company own report****************************************************************************** Change history************************************************************************* Mod Date Changed By Description Chng ID* 10/04/1999 Siegfriedt example... SIEG100499* ----------------------------------------------------------------------* xx/xx/20xx <user> <description> <chg-id>*************************************************************************

3.3.4.5 Other programming techniques

Coding style Keyword RAISE should not be used. Use Statement MESSAGE RAISING, it has the same feature and additional it leaves a detailed error message-ID in sy-msgxx fields. But consider key word MESSAGE ... RAISING (RAISE) is only allowed in function modules, don’t use it either in other contexts.Key word STOP is only allowed in online reports, usage in other contexts are forbidden.

Move-Corresponding When records a and b have the same structure, it is more efficient to MOVE a TO b than to MOVE-CORRESPONDING a TO b



Collect Do not use the COLLECT statement with large internal tables, this operation can be very CPU intensive.

Read table When reading a single record in an internal table, the READ TABLE WITH KEY is not a direct READ on a sorted table. Therefore

- SORT the table and use READ TABLE WITH KEY BINARY SEARCH - use the SORT...BY when sorting internal tables- SORT ITAB BY FLD1 FLD2 is more efficient than SORT ITAB- use internal tables without header line (use separate work areas).



3.3.5 ABAP/4 Security Programming

To set up an efficient security strategy, structure and interaction of the concerned programs, they have to be analysed and considered.

The necessary approaches depend on the requirement, that certain data such as sensitive HR data or prices are accessible for selected users only. The general access for every transaction is checked within the call. Furthermore, authorisation objects are embedded within the coding. The access for those objects and the combination of values for contained authorization fields is realized via roles in the master data of every single user.

For every customer-own development object, the following aspects have to be taken into account regarding secure programming:

Transaction Transaction codes are the easiest way to restrict access for certain functions Codes directly and the most convenient method of securing software. Therefore own

transaction codes for development objects can be created with SE93.In order to further secure the program, ensure that the user is denied access to SE38 and SA38. Transaction codes should be used to prevent access to the program entirely.

Authority Embedding authority checks within programs enables direct control of dataChecks access, in this way it is possible for a whole department to utilise a report but

have data excluded for certain users. Note this method can be used to prevent access to the program code entirely, such as in an exit program.Important for all authority checks is, that the authority group is defined and that the field to be checked is also determined.

AUTHORITY-CHECK OBJECT 'object_id 'ID ’ ’ FIELD ‘ ’

An amount of Authority objects is available within SAP standard, otherwise own objects can be created after consulting ATLAS Basis responsible.

Authorisation The third type of authority check is to utilise the authority group on the Group program attributes. This group setting can be tied in with an authority group Attribute and prevent access to the ABAP program from SE38/SA38.

Lock objects Lock objects should be implemented corresponding to SAP standard. If required object is not defined, own objects can be created (see also Locking: database locking / SAP-Object locking).

Conditional Conditional processing of procedures depending on usernames (sy-uname) is processing allowed only in combination with development system name (sy-sysid + sy-

mandt) and only in Development system. This coding has to be removed before export.



Further documentation is available on link Secure programming

3.3.6 Performance and SQL

For an optimised performance of ABAP code, a number of useful strategies can be used.

SQL Checklist

No. Rule1 Keep the selected dataset small2 Keep the transferred data small3 Keep the number of database accesses small4 Use database buffers5 Create views for table joins instead of using multiple selects.6 Select data only one time where possible (i.e., don’t have multiple

selects against the same table - get the data one time and store it in an internal table).

7 Remove unused indexes from tables.

Tuning Database data traffic on network can be reduced by using array operations, joins and field wise data selection.

Dictionary references for all parameters of every interface are mandatory (function modules, form routines, methods…)

Sorted / hashed table and binary search can be used for accelerate access of internal tables.

SAP Tips & Tricks The SAP Tips & Tricks function is very useful in compare different methods of coding without going to the trouble of coding both and perform own run-time analysis. Select menuSystem Utilities Runtime Analysis Tips & Tricks


https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/37bef2c0-0d01-0010-58ac-d1286bb09b6e


3.4 Checklist for code inspection

No. Question Status1 Does the coding follow the development guideline?2 Is the coding self-explanatory (can it be understand with

reading, not debugging)?3 Can the code be generated without errors? Are there any

warning-messages?4 Do the comments explain the intention and usage?5 Are workarounds and exceptions with reasons and date

separate commented? 6 Do the names meet the naming conventions?7 Are descriptive names used?8 Are all variables defined as local as possible and as global

as necessary?9 Is the length of the implementation of a subroutine/

function/… appropriate?10 Are the possibilities to source coding out sufficiently used?11 Is the nesting structure easy enough? Are there any

complex cases?12 Are unnecessary complex solutions avoided e.g. for IF-

structures?

Periodical checks of all customer software objects will be done by the Configuration-/ Development Management. To allow previews for the Rollout, all software objects under construction will be checked according to their compliance to the development guideline. The software has to be always executable.

Checks will be done before export, in case of any errors the objects will not be transported.



4 Special guidelines

4.1 Translation

Literals should not be used in the source code, text objects or constants for key words are alternatively.

Texts with more than 1 line have to be marked group in the text elements.

Text elements should not be concatenated to build sentences ( different language different grammar).

4.2 Locking: database locking / SAP-object locking

Locking and unlocking will not be done in the database function modules, but in the application program. The principle is: lock at first, then read data.

In the following it has to be considered, that the data has to be read again after the locking within switching from display to change mode.

With using locking function modules, export and import parameters that are initial and contain a blank in the X-parameter, will be locked generically. To solve this problem, the X-parameters can be filled with an ‘X’.

Example:

If the customer ‘000’ is selected, all customers will be locked…ENQUEUE…EXPORTING VP_CUSTAID = VP_CUSTOMER X_VP_CUSTAID = ‘ ‘

To lock only customer ‘000’…ENQUEUE…EXPORTING VP_CUSTAID = VP_CUSTOMER X_VP_CUSTAID = ‘X‘

4.3 Handling of change documents

The SAP documentation for change documentation for DDIC objects is valid and available in the Internet Link SAP standard change document handling


http://help.sap.com/saphelp_46c/helpdata/en/2a/fa019c493111d182b70000e829fbfe/frameset.htm


Maintain change document objectsNew objects can be created or existing customer own objects can be changed using transaction SCDO – Change documents. For new objects the customer namespace (Z*) has to be considered.

New objects in table appendsData elements that are assigned to SAP standard or existing customer own tables have to be adapted to the corresponding object. If the “Change documents” –option is activated for the other data elements of the table, this attribute has to be set for the new data elements, too.

New independent objectsChange documents for data elements that should not be assigned to existing tables have to be created in coordination with Development-/ Configuration Manager.

Read change documentsReading of the document header will be done with function module CHANGEDOCUMENT_READ_HEADERS, the module CHANGEDOCUMENT_READ_POSITIONS reads the positions/items.The formatting for display change documents has to be done individual.

4.4 Archiving

Link project Archiving concept TBD



5 Documentation

All kinds of documentation have to be created in English.

5.1 Programs / function groups / module pools / function modules

5.1.1 Program User Documentation

Program user documentation is only necessary for online reports/ programs. The purpose is, to document a comprehensive description of the function, usage and execution of the ABAP program.The documentation of programs will be carried out in chapter 4 and 5 of the specific GPP document. In chapter 4 the developer has to describe the program attributes, chapter 5 should contain the functional positive and negative testing.

A program can only be accepted as completed, if the documentation is completed.

After completion of programming and documentation, the SAP Design Dossier has to be stored in Solution Manager by the owner of the relevant SAP module.

5.1.2 Commenting

To support future maintenance of ABAP code, extensive commenting has to be provided. Commenting should explain the complicated structure and should give guidance to the logical ‘flow’ within a program.To decide ‘how much is enough’, the developer should imagine what degree of commenting him- or herself would need to understand a program that someone else has written.

Where the program code can be clearly and concisely explained, in line comments should be used.

In line comments should be spaced out from the right hand side of the statement to a consistent point where they do not interweave with the programming code.

Where this is not possible, the comment should contain a separate line preceding the description.A ‘comment block’ has to be used for longer comments (more than 3 lines).

********************************************************************** WINK100403 Modification to check the currency values etc.



*********************************************************************Code Change…………********************************************************************** end of WINK100403+

FORM statements should always include a comment block to describe the supported function and the parameters passed to and from the routine.

5.1.3 Comments for a change to a program

One of the most important reasons for comments is the change history. It has to be ensured that comments separate the changes from the original program. When adding or removing a large amount of code, it may be necessary to insert a header area with a comment of the content of the changes.The Change ID is a number starting at 001 and incrementing by one for each change.

For example:************************************************************************************************** CHANGE HISTORY * Mod Date Changed By Description Chng ID* 10/04/2003 Bunty Jain Addition of select options WINK100403* Change control 70*************************************************************************************************

SELECT-OPTIONS: s_kunnr for knvp-kunnr " WINK100403 Sold-to Party obligatory, " WINK100403

5.2 Data elements

Documentation for data elements can be implemented within the data dictionary using the “Documentation” –button or the menu path Goto Documentation.

The entered documentation is available using the F1-Help on the object (table-field) within ABAP workbench and object navigator (SE38/ SE80).



6 Approval of developments and rollout

Syntax Extended program check of all developments is mandatory (level „strict” and Check include “check character string” should be chosen).

Approval of development by inspection of development guidelines, test description and documentation should be done by developer.

Approval All objects have to be approved by SPL / Key user in regard of design, ergonomic and security of the coding. Samples will be inspected by Development/ Configuration Manager.

Performance Performance trace under production conditions (AQ1 or AP1) is mandatory.

Risk Special rollout information has to be communicated to Development/ Calculation Configuration Manager in case of rollout specials (risks, conversions,

migrations, authorities..).

Export Before objects can be exported, it should be checked in regard to possible conditions missing references (if all referred objects already in production or in same

transport).List of objects has to be checked (tables with data conversion, violations of developer guideline, information of Development/ Configuration Manager necessary).

Link Transport document TBD



7 Appendix

7.1 Template of program

Use program template ZBC01_TEMPLATE_GENERAL (incl. program header).

For existing programs insert program header by using the standard pattern function in transaction SE38 (compare topic 3.3.4.4 Program Header ).

General structure:

Header Declarations

PROGRAM STATEMENTCOMMENT BLOCKTABLESTYPESCONSTANTSSTRUCTURE DEFINITIONSINTERNAL TABLE DEFINITIONSFIELD-GROUPS and FIELD-SYMBOLSDATA PARAMETERS and SELECT-OPTIONS

Processing Block

INITIALIZATIONAT SELECTION-SCREENSTART-OF-SELECTIONGET (if using logical databases)END-OF-SELECTION

Interactive Events

AT LINE-SELECTIONAT PFnnAT USER-COMMAND

Page Controls

TOP-OF-PAGEEND-OF-PAGE

Subroutines

FORMS



7.1.1 Report with base and branching list (ALV)

TBD

7.1.2 Reports with tree hierarchies

TBD

7.1.3 Module pool with dialogue and lists

TBD

7.1.4 Function groups with dialogue and lists

TBD

7.2 Template of document

7.2.1 Transaction

Template of Document TBD

7.2.2 Program


7.2.3 Function group



Documents

SAP ABAP Coding Guidelines