ISU ABAP Dev handbook Draft 0 1 EN

EGAT Project ABAP Development Handbook

ABAP Development Handbook

document.doc Page 1/30 Printed 7/4/23

EGAT PROJECT ABAP Development handbook

Table of Contents

1 INTRODUCTION........................................................................................................5

2 ABAP REPOSITORY NAMING CONVENTIONS..............................................6

2.1 ABAP REPORTS......................................................................................................62.2 REPORT PAINTER REPORTS......................................................................................62.3 DIALOG PROGRAMS (MODULE POOL PROGRAMS)......................................................72.4 INCLUDES (WITHIN MODULE POOL PROGRAMS)..........................................................72.5 TRANSACTION CODES..............................................................................................72.6 SCREEN PAINTER SCREENS......................................................................................82.7 FUNCTION GROUPS.................................................................................................82.8 FUNCTION MODULES..............................................................................................82.9 MESSAGE CLASSES.................................................................................................92.10 DEVELOPMENT CLASSES.......................................................................................92.11 AREA MENUS......................................................................................................92.12 BDC SESSION NAMES..........................................................................................92.13 TRANSPARENT TABLES.......................................................................................102.14 POOLED TABLES................................................................................................102.15 CLUSTER TABLES...............................................................................................102.16 STRUCTURES.....................................................................................................102.17 VIEWS..............................................................................................................11

2.17.1 Database view.............................................................................................112.17.2 Help view....................................................................................................112.17.3 Maintenance view.......................................................................................112.17.4 Projection views..........................................................................................11

2.18 DOMAINS..........................................................................................................112.19 DATA ELEMENTS...............................................................................................122.20 LOCK OBJECTS...................................................................................................122.21 SEARCH HELPS..................................................................................................122.22 TYPE GROUPS....................................................................................................132.23 VARIANTS.........................................................................................................132.24 LAYOUT SETS....................................................................................................132.25 REPORT PAINTER LIBRARIES...............................................................................132.26 REPORT PAINTER SETS.......................................................................................13

3 ABAP PROGRAMMING NAMING CONVENTIONS.......................................15

3.1 DATA VARIABLES..................................................................................................153.2 GLOBAL VARIABLES...............................................................................................153.3 LOCAL VARIABLES.................................................................................................153.4 CONSTANTS.........................................................................................................153.5 INTERNAL TABLES.................................................................................................153.6 PARAMETERS........................................................................................................163.7 SELECT OPTIONS..................................................................................................163.8 FORMS................................................................................................................163.9 TRANSPORTS........................................................................................................16

4 ABAP PROGRAMMING STANDARDS...........................................................18

4.1 ABAP PROGRAMS.................................................................................................184.1.1 Program header..........................................................................................184.1.2 Report header.............................................................................................194.1.3 Report trailer...............................................................................................19

4.2 PROGRAM FLOW...................................................................................................194.3 INITIALIZATION EVENT..........................................................................................204.4 START OF SELECTION EVENT..................................................................................204.5 END OF SELECTION EVENT....................................................................................20

EGATdocument.doc Page 2/30 Printed 7/4/23


4.6 TOP OF PAGE EVENT.............................................................................................204.7 FORMS................................................................................................................20

5 ABAP STATEMENTS FOR PROCESSING......................................................22

5.1 CASE STATEMENT................................................................................................225.2 CHECK STATEMENT.............................................................................................225.3 COLLECT STATEMENT.........................................................................................225.4 IF STATEMENT.....................................................................................................225.5 LOOP STATEMENT...............................................................................................235.6 SELECT STATEMENT...........................................................................................235.7 SHIFT STATEMENT..............................................................................................235.8 MOVE STATEMENT..............................................................................................245.9 WHILE STATEMENT.............................................................................................24

6 GENERAL GUIDELINES...............................................................................25

6.1 DATA RETRIEVAL WITH GET STATEMENT................................................................256.2 DATA RETRIEVAL WITH SELECT STATEMENT..........................................................256.3 PROGRAM SIZE.....................................................................................................266.4 MESSAGES...........................................................................................................266.5 PROGRAM CHECKS................................................................................................266.6 TABLE UPDATES AND MODIFICATIONS.....................................................................266.7 TEXT ELEMENTS...................................................................................................266.8 SYSTEM FIELDS....................................................................................................276.9 READING TABLES..................................................................................................276.10 BATCH SESSIONS...............................................................................................276.11 DEVELOPMENT WORKBENCH..............................................................................27

7 APPENDIX....................................................................................................28

7.1 LIST OF SAP MODULES.........................................................................................287.2 LIST OF SAP SUBMODULES...................................................................................287.3 LIST OF REPORT TYPES..........................................................................................287.4 FUNCTIONAL MESSAGE CLASSES............................................................................287.5 DEVELOPMENT CLASSES........................................................................................287.6 FUNCTIONAL AREAS FOR REPORT PAINTER LIBRARY.................................................297.7 LIST OF REPORT PAINTER SETS..............................................................................297.8 LIST OF TEAMS.....................................................................................................297.9 LIST OF SUB TEAMS..............................................................................................297.10 Change Request Examples.............................................................................29



Intentionally Left Blank



1 Introduction

The purpose of this document is to establish the ABAP development standards and naming conventions for all SAP R/3 repository items likely to be affected in the EGAT project.

It serves as a guideline for all the developers to strictly follow such that a unique standard of custom objects can be maintained throughout the project.

These standards should be followed in order to achieve consistent and high quality programming code.

To enforce the above all custom developments should undergo a final review at the completion of the task to ensure that these standards were applied and adhered to.

The author of this document does not claim to have fully documented every single item and aspect, as some of the repository items are self-explanatory and therefore have no validity for further documentation.

Missing objects that warrant documentation should be added to this document to make it an up-to-date and complete document. This might also be required in the case of a software upgrade containing enhancements, new features and functionality.

This document was written on the basis of a SAP/R3 system release 4.70



2 ABAP repository naming conventions

SAP has a huge number of R/3 repository objects that are either delivered, can be configured or are intended for customer use. The customer repository objects are within a reserved range to allow for a trouble free upgrade of their software at later times.

The resulting naming conventions outlined in this document have been defined to incorporate SAP recommendations and requirements. This will ensure distinction between SAP supplied repositories and customized repositories and will furthermore allow for a consistent approach for all custom development.

SAP supplied objects must not be modified or deleted. If a change to a SAP supplied repository object is required the original object must be copied to a new object using the naming conventions outlined in this document. Only this new object can then be modified. Please consult the appendix E of BC Style Guide for objects inadvertently not covered by this document.

In case of development done base on SAP standard object, then add prefix ‘Z’ to customized object naming. For example, standard form for withholding tax certificate is ‘IDWTCERT_TH_DOM’. Naming for customized form is ‘ZIDWTCERT_TH_DOM’.

2.1 ABAP reports

ABAP reports are developed via the ABAP workbench. In general they are non-interactive and designed to complete a task without continual intervention by the user. The following is the naming convention for ABAP reports that will be promoted to the production environment. ABAP reports that are developed for testing or personal use must start with ‘ZZZZ’. The remaining part of the program name should be constructed in a way that does not interfere with the following naming conventions.

Position

Sample Type Description/Purpose

1 Z Constant ‘Z’ This identifies the report as a custom development.

2-3 FI List Identification of SAP/R3 module the report is developed for. See appendix for a list of valid SAP/R3 modules.

4-5 GL List Identification of SAP/R3 submodule the report is developed for. See appendix for a list of valid SAP/R3 submodules.

6 I List Type of report. See appendix for a list of valid report types.

7-8 17 Range Sequential numbering for programs in the same application/module. Always use the next available number.

9-20 _Cash_Discount

Descriptive character

Description of program if required starting with _

2.2 Report Painter reports

Reports that are developed with the ABAP Report Painter tool will have the following naming conventions.

Positio Sample Type Description/Purpose



n1 Z Constant ‘Z’ This will identify the report as a custom

development.2-3 GS List Identification of SAP module the report

is developed for. See appendix for a list of valid SAP modules.

4-5 C0 Identification of the report painter library. Always use the last two characters of the library name.

6 _ Constant ‘_’ Separator7-8 12 Range Sequential numbering for programs in

the same module/report painter library. Always use the next available number.

2.3 DIALOG programs (module pool programs)

Dialog programs must always be developed via the Repository Browser. By using this development tool SAP will prompt the developer with correctly named Include components (described below). This will allow the developer to perform a syntax check and generate the underlining Includes with the correct naming conventions. This program must only contain Includes and program comments.

Position


1-4 SAPM Constant ‘SAPM’

This will identify the program as a Dialog program.

5 Z Constant ‘Z’ This will identify the Dialog program as a custom development.

6-8 07E Range Any three numbers/characters. Special characters like underscore are not allowed.

2.4 Includes (within module pool programs)

These types of Includes must always be developed via the Repository Browser after the generation of the program name. By using this development tool SAP will prompt the developer with correctly named Include components. This will allow the developer to perform a syntax check and generate the Includes with the correct naming conventions.

Position


1-5 MZ07E Always use position 4 to 8 of the associated Dialog program name.

6-8666

TOPOIF

Constant TOP Use TOP to identify the Include as the depository for the data declarations.OInclude to store PBO (Process before Output) modules.IIncludes to store PAI (Process after Input) modules.FInclude to store subroutines called by



perform statement in PBO and PAI.7-8 05 Range Used to number the Include within the

same Include type. Always use the next available number.

2.5 Transaction codes

Transaction codes can be assigned to programs in order to execute them via the transaction code box or within user menus. The following naming conventions will apply.

Position


1 Z Constant ‘Z’ This will identify the transaction as a custom development.

9-20 PRFORM Descriptive Description of functionality of Tcode

2.6 Screen painter screens

These objects are only ever associated with Module Pool programs except in the case of SAP generated parameter and list report screen, both of which are generated each time the List report is generated and are therefore not changeable. Subsequently the following naming conventions apply.

Position


1-8 SAPMF07E Constant Module pool name the screen is developed in.

9-12 9010 Range This will identify the screen number. All custom developed screen should be in the 9000 number range. Always use the next available number. All screens pertaining to correctly named Module Pool programs will be protected from SAP upgrades.

2.7 Function groups

Function groups are used to group together functionally related common routines known as Function Modules. As such the following naming conventions will apply.

Position


1 Z Constant ‘Z’ This will identify the Function Group as a custom development.

2-3 FI List Identifies the SAP module. See appendix for a list of SAP modules.

4 A Any character allowed.

2.8 Function modules

Function Modules are grouped together in a Function Group. All function modules belonging to the same function group are stored in an ABAP program where the name of this program is made up out of the prefix ‘SAPL’ and the function group name (e.g. SAPLZFSA). These programs must never be edited directly. Function modules will be named according to the following naming conventions.



Position


1 Z Constant ‘Z’ This will identify the function module as a custom development.

2 _ Constant ‘_’ Separator3-30 SET_DATE Any meaningful description about the

functionality of the function module. Multiple underscore characters to separate words are allowed. A total length of thirty characters is permitted.

2.9 Message classes

This is another grouping object. Message classes are used to group message texts together. Up to one thousand messages can be stored in one message class. Internally, all messages are stored in SAP table T100. The following naming conventions apply.

Position


1 Z Constant ‘Z’ This will identify the message class as a custom development.

2 F List Functional message class identification. See appendix for a list of valid functional message classes.

2.10 Development classes

A Development Class is used to categorize Development Objects. Only the System Administrator can create Development Classes. The naming conventions are as follows.

Position


1 Z Constant ‘Z’ This identifies the development class as a custom development.

2-3 BC1 List SAP module. See appendix for a list of valid SAP modules.

2.11 Area menus

Area Menus are used to group transactions together for a user- friendly way of executing programs. The naming conventions follow.

Position


1 Z Constant ‘Z’ This identifies the Area Menu as a custom development.

2-4 FIS Any three characters or numbers. Special characters are not permitted.

2.12 BDC session names

BDC sessions are used to mimic SAP/R3 transaction functionality without user intervention. To ensure SAP/R3 authority checks can be carried out, BDC session names will follow the following naming conventions.



Position


1 Z Constant ‘Z’ This identifies the BDC session as a customer generated BDC session.

2 _ Constant ‘_’ Separator3-12 JRNLS Any abbreviated word describing the

functionality of the BDC session. No special characters are permitted.

2.13 Transparent tables

Transparent Tables are used for physical data storage and are precisely mapped in the underlying database system. The SAP R/3 repository table information resides in the DB2 Common Server Database and could therefore potentially be accessed form outside the SAP R/3 system. The following naming conventions apply.

Position


1-2 ZZ Constant ‘ZZ’ This identifies the table as a custom development. SAP/R3 has used the prefix ‘Z’ for some tables. To clearly identify custom developed tables the prefix ‘ZZ’ is to be used.

3-18 VENDTL Use any abbreviated word describing the purpose of the table. If the table will not be maintained via the table maintenance functionality this part of the table name can have up to sixteen characters. For tables where table maintenance functionality will be used the table name must not exceed five characters in total. This is a SAP/R3 restriction.

2.14 Pooled tables

Pooled Tables is a very old concept within SAP/R3 but still in use. An example of this is the ATAB pool. Pooled Tables are multiple tables can co-exist in the same physical database. This type of table will not be used during the EGAT Project. They are only mentioned here for completeness.

2.15 Cluster tables

Cluster Tables are used to store records of varying length (clustered) together. Data is stored and retrieved via the Import/Export ABAP statements. It is not envisaged that this type of table will be used in the EGAT Project but the following naming conventions would apply.

Position


1-2 ZZ Constant ‘ZZ’ This identifies the table as a custom development. SAP/R3 has used the prefix ‘Z’ for some tables. To clearly identify custom developed tables the prefix ‘ZZ’ is to be used.

3-8 FINPERIODS Use any abbreviated word describing the purpose of the table. If the table will not



be maintained via the table maintenance functionality this part of the table name can have up to sixteen characters. For tables where table maintenance functionality will be used the table name must not exceed five characters in total. This is a SAP/R3 restriction.

2.16 Structures

Structures are typically created as a reference to external data storage. Structures represent working storage definitions or copybooks. The following naming conventions apply.

Position


1-2 ZZ Constant ‘ZZ’ This identifies the structure as a custom development. SAP/R3 has used the prefix ‘Z’ for some structures. To clearly identify custom developed structures the prefix ‘ZZ’ is to be used.

3-8 VENDORDT Any abbreviated word describing the data addressed in this structure. Underscores are not permitted in the third and fourth position. This is a SAP restriction.

2.17 Views

Four types of views are available to the developer. The naming conventions shown below will apply to all of them. A brief description of the purpose of each view type follows the naming conventions.

Position


1 Z Constant ‘Z’ This identifies the View as a custom development.

2-18 VENDORVW Any abbreviated word describing the data defined in the view.

2.17.1 Database view

Database Views are typically used to join secondary tables to primary tables via a foreign key. This type of view disallows updates. Database views should be generated when accessing two or more related tables to reduce network traffic.

2.17.2 Help view

Help Views are used by SAP/R3 whenever a pull-down on a data dictionary field is done. In most cases this field will be a field generated by Screen Painter or by an ABAP Report. This only applies if no matchcode is defined for the field. Help views are useful as they allow linking to secondary tables via foreign keys.



2.17.3 Maintenance view

Maintenance Views are commonly generated for non-transactional data tables. Multiple tables can be used that are linked via foreign keys. Maintenance views allow the speedy generation of maintenance screens. Due to system restrictions in the locking area, the typical candidates for this type of view are ‘One user at a time’ update tables. Tables containing fairly static data are also prime examples.

2.17.4 Projection views

These types of views are only permissible on one table and selection restrictions are not permitted. They are used to filter data from views. Recommendation is to use Database Views instead.

2.18 Domains

Domains are used to describe data fields. Developers are encouraged to use a SAP equivalent Domain if it is available. Naming conventions for Domains are as follows.

Position


1-2 ZZ Constant ‘ZZ’ This identifies the domain as a custom generated domain. SAP has used the ‘Z’ prefix for some domains. To clearly identify custom developed domains a prefix of ‘ZZ’ is used.

3-8 INT_ID Any meaningful abbreviation describing the inherence of the domain.

2.19 Data elements

Data Elements are used to describe the business definition of a domain. The domain name (if newly created) should be used as the Data Element name. If the data element is to be used on an existing domain, a new data element could be used. Naming conventions are:

Position


1-2 ZZ Constant ‘ZZ’ This identifies the Data Element as a custom developed Domain. SAP has used the ‘Z’ prefix for some Data Elements. Therefore the custom identification will be ‘ZZ’.

3-8 NAME Any meaningful abbreviation describing the data element.

2.20 Lock objects

Lock Objects are used to manage the SAP/R3 ENQUEUE and DEQUEUE locking process. The lock object is defined at the table level and upon generation, two function modules are generated. These function modules are then used by the developer to lock and unlock the objects. The argument list should be well thought out, as this will limit the locking level. The same applies for the Lock Mode. All custom development doing database updates must use the locking concept. No specific naming conventions apply as SAP does automatically name the objects.

Positio Sample Type Description/Purpose



n1-7 ENQUEUE Constant

‘ENQUEUE’This identifies the Lock Object as a locking object. The name is automatically generated by SAP.

8 _ Constant ‘_’ Separator9-17 ZZVENDORS Name of the table the locking process

takes place. This is automatically added to the Lock Object name by SAP.

2.21 Search helps

A search help is an object with which input filed helps can be defined. They are used to define the search paths. The following naming conventions will apply.

Position


1 Z Constant ‘Z’ This identifies the search help as a custom development.

2 ‘_’ Constants ‘_’ Separator3-30 BU_NAME Any meaningful abbreviation describing

the search help.

2.22 Type groups

These objects are global definitions of user defined data types that can be used in ABAP programs. This can give the effect of having field group definitions within other definitions. Effectively it is a powerful way to cut down coding and using complex data definitions in common programs.

Position


1 Z Constant ‘Z’ This identifies the Type Group as a custom developed Type Group.

2-5 TBTY Any four characters are permitted.

2.23 Variants

Variants are used to store default ABAP report parameters. The naming conventions are as follows.

Position


1-14 GL_UPLOAD Any meaningful abbreviation to describe the purpose of the variant. Multiple underscore characters are allowed.

2.24 Layout Sets

Layout Sets are used to store SAPScript forms. The following naming conventions apply.

Position


1 Z Constant ‘Z’ This identifies the layout set as a custom



development.2 _ Constant ‘_’ Separator2-4 FI List This identifies the SAP module. See

appendix for a valid list of SAP modules.5 _ Constant ‘_’ Separator6-13 INVOICE Any meaningful word or description to

indicate what the layout set contains.

2.25 Report Painter libraries

Report Painter libraries are use within the Report Painter module. The following naming conventions apply.

Position


1 Z Constant ‘Z’ Customer library identification.2-3 12 Any sequential number or character.

Always use the next available number or character.

2.26 Report painter sets

Report Painter libraries are use within the Report Painter module. The following naming conventions apply.

Position


1 Z Constant ‘Z’ Denotes customer Set.2 B Set type. See appendix for a list of valid

set types.3-4 CO List SAP module. See appendix for a list of

SAP modules.5 _ Constant ‘_’ Separator6-10 RU_CC Any meaningful description. Underscore

characters are allowed.11-12 01 Any sequential number. Always use the

next available number.



3 ABAP programming naming conventions

This section outlines the adopted programming naming conventions for the EGAT Project. Their usage will not be enforced but developers are encouraged to make use of them as they provide a good guideline to standardized programming code throughout the project. When naming variables, internal tables, parameters etc. the only special character allowed is the underscore character. This is one restriction that which will be enforced.

3.1 Data variables

Each data variable declaration should be placed onto a separate line. This will make the program easier to read and more maintenance friendly. Program Data Variables should start with the character ‘V’ followed by an underscore ‘_’ character. If possible, the program variable should refer to an existing SAP data object with the help of the ‘like’ declaration. Variable names should not exceed 30 characters. For variables referring to existing SAP/R3 data dictionary fields, the prefix 'V_' should be followed by the SAP/R3 data dictionary field name.

Example DATA: V_PAGENO LIKE SY-PAGENO, V_LOOPNO(3) TYPE N.

3.2 Global variables

Global Variables will be prefixed with ‘G_’. A length restriction of no more than 30 characters applies as well.

Example DATA: G_CNT(6) TYPE P NO DECIMALS.

3.3 Local variables

Local variables are defined as local to a subroutine. They will be prefixed with ‘L_’.

Example DATA: L_SWITCH TYPE I.

3.4 Constants

Constants will be prefixed with ‘C_’. A length restriction of 30 characters applies. Constants must be declared with the CONSTANTS statement.

Example CONSTANTS: C_ONE(1) TYPE C VALUE ‘1’.

3.5 Internal tables

Internal tables must be prefix with ‘T_’. Their full name should not exceed thirty characters. If the internal table uses the same structure as an existing SAP/R3 table or structure the same name should be used.

Example DATA: BEGIN OF T_MONTHLY_SUMS OCCURS 0. MONTHS(2) TYPE N, SUM(8) TYPE P DECIMALS 2,



DATA: END OF T_MONTHLY_SUMS.

DATA: BEGIN OF T_T001. INCLUDE STRUCTURE T001.DATA: END OF T_001.

3.6 Parameters

Parameters are restricted to a length of eight characters. They are prefixed with ‘P_’ followed by the data dictionary field it resembles or represents. For parameters with no data dictionary field reference, the name can be freely chosen.

Example PARAMETERS: P_BUKRS LIKE T001-BUKRS.

3.7 Select options

Select options are restricted to a length of eight characters. They are prefixed with ‘S_’ followed by the data dictionary field it resembles or represents. For Select Options with no data dictionary field reference the name can be freely chosen.

Example SELECT-OPTIONS: S_LIFNR FOR LFA1-LIFNR.

3.8 Forms

Forms should be named in such a way that it provides a meaningful description of the functionality of the form. Words should be separated with the underscore character. A maximum length of thirty characters is permissible.

Example

Example

FORM CALCULATE_WEEKLY_AVERAGE. ……… ………ENDFORM.

FORM FIND_FILES_TO_PROCESS. ……… ………ENDFORM.

3.9 Transports

Transports are the SAP/R3 way to promote developments to other systems. This will mainly be transports of objects from the development environment to the test and production environment. The short description of the underlying change request should be entered according to the following naming conventions. (See appendix for examples of change request descriptions).

Position


1-2 FI List This will identify the team. See appendix for a list of valid teams.

3 - Constant ‘-’ Separator



GLCCA

ListList

This will identify the sub team. No positions are provided as the length of this part of the transport description is variable. See appendix for a list of valid teams.

: Constant ‘:’ Separator-60 Interface

Pgm.GL Upload

This will identify the contents of the transport. A meaningful short text must be provided.



4 ABAP programming standards

4.1 ABAP programs

4.1.1 Program header

All Report, Dialog type programs and function modules must have a standard section at the top of the program file describing the program in brief and providing an area to function as a modification log for quick reference. A more detailed description of the program should be created in the documentation part of the program provided by SAP. The following is description of the required elements followed by a sample of a program header in an ABAP report program specifying all required elements.

Element DescriptionProgram Object name of programTitle Title of program. This is the technical name of the programAuthor Name of developer (First and surname)Date Date of development commencement Release SAP/R3 system release the program was originally developed

forModule Name of module and submodule the program was developed

forDescription Short but meaningful functional description of the programAuthority Provide details about explicit authority checks performed in

this program Author First and surname of the developer who applied the

modificationDate Date when the modification was appliedChange Request The SAP/R3 change request the modification was activated

underModifications Brief but meaningful description why the modification was

required and how it was achieved.

Sample

*-----------------------------------------------------------------------* Program : ZBC00000* Title : Interface Initiator* Author : Tarm Techasarin* Date : January 23, 2004* Release : 4.7* Module : FI-GL** Description : This program will search the specified directories* for the presence of interface data files.* For each file found it will then submit the* appropriate interface program to process the file.** Authority : No explicit Authority Check is performed in this* program.*-----------------------------------------------------------------------

*-----------------------------------------------------------------------* Modification History*-----------------------------------------------------------------------* Author :* Date :* Change Request :



* Modifications :*-----------------------------------------------------------------------

4.1.2 Report header

ABAP programs producing report output must have the defined standard header lines. Construction of these lines should be programmed in a function module for easy inclusion. The following is a list of elements and a sample of a header line report output produced by an ABAP program utilizing a function module call.

Element DescriptionProgram Import parameterCorporation Value of text elementDate Value of SAP/R3 system field SY-DATUMSystem Value of SAP/R3 system field SY-SYSID Client Value of SAP/R3 system field SY-MANDTReport Description Value of SAP/R3 system field SY-TITLETime Value of SAP/R3 system field SY-UZEITUser Value of SAP/R3 system field SY-UNAMEPage Value of SAP/R3 system field SY-PAGNO

Sample

PROGRAM: ZBC00000 EGAT Automobile (Thailand) DATE: 23/01/2001SYSTEM : DP1/110 Interface Initiator TIME: 17:36:25USER : THGXS PAGE: 1

4.1.3 Report trailer

ABAP programs producing report output must have the defined standard trailer line. Construction of this line should be programmed in a function module for easy inclusion. The following is a list of elements and a sample of a trailer line report output produced by an ABAP program utilizing a function module call.

Element DescriptionText The first sample is for a report that outputted detail lines.

The second sample is for a report that did not produce detailed output.

Sample

***** END OF REPORT *****

*** NO DATA TO REPORT ***

4.2 Program flow

The EGAT Project will adopt a modular (Top-Down) design methodology when developing ABAP programs. This methodology will breakdown the program in manageable and easy to maintain parts. This will mean to place logical parts of a program into forms. Subroutines should not be generated for code that is performed once only. The use of the SAP/R3 event methodology will help create structured programs as required.



4.3 Initialization event

This SAP event is performed before any other event. It will be used to perform once-off program tasks. It should also be used for authorization and program status checks.

4.4 Start of selection event

The Start of Selection event represents the main flow coding part of the program. This event block should only contain performs to subroutines in a logical sequence.

4.5 End of selection event

Every program should end in the End of Selection event. Typically, this event should produce the report trailer line.

4.6 Top of page event

This SAP/R3 defined event is performed whenever the system encounters a page break during report output processing. Typically, this event should be programmed to execute the function module that generates the standard report header lines.

4.7 Forms

These subroutines must always use the LIKE statement to declare the form’s parameter characteristics. This allows the SAP ABAP generate process to reserve precise dimensions in the generated object. The effect of not having the LIKE statement is that only at run time can ABAP evaluate the size of passed parameters. This has the effect of increasing the program’s buffer size. Constant calls to a FORM with varying parameter sizes can mean constant extensions by the ABAP processor. This can simply be avoided by using the LIKE statement. Use the TYPE ASSIGNMENT facility in SE38 (Utilities Menu). There will be cases where the FORMAL parameter size declared on the FORM routine with the LIKE statement doesn’t match the ACTUAL parameter size due to the fact that more than one parameter type is passed to the same formal parameter field. A program check will determine this. In this case it is permissible to use the TYPE statement.

Forms should be headed by a brief description of the functionality embedded in the form. The input and output parameters should also be described. It is important to distinguish between the input and output parameters in the documentation, as there is no inherent distinction made by SAP ABAP. Any parameters whose values do not change are considered input and any parameters whose value gets set, reset, or changed should be documented as output. The use of directional arrows is a good way to indicate which parameters are input or output. Another way of distinguishing between input and output parameters is to declare those variables, which are changed by the subroutine with the extension “CHANGING”. In actuality this extension does not affect the data in any way (in this particular case), but it used strictly as a distinguishing feature. Also when declaring your FORM you should always put all input parameters first and then all output parameters.

Sample

-----------------------------------------------------------------------------* This routine simply concatenates 2 strings separated by a space and places * them in an output string.-----------------------------------------------------------------------------* Parameters:* --> STR1 - string 1* STR2 - string 2



* <-- O_STRING - output string*----------------------------------------------------------------------------FORM CONCAT_STRINGS USING STR1 LIKE G_CHAR10 STR2 LIKE G_CHAR10

CHANGING O_STRING LIKE G_CHAR10.

DATA: L_LEN1 TYPE I.

L_LEN1 = STRLEN( STR1 ). L_LEN1 = L_LEN1 + 1. O_STRING = STR1. WRITE STR2 TO O_STRING+f_LEN1.

ENDFORM.



5 ABAP statements for processing

This section offers a wide range of programming statements used in the ABAP language of SAP/R3. The information found in this section will be in the form of standards, guidelines, descriptions, examples and programming tips. They are in alphabetical order for quick reference.

5.1 CASE statement

Each nested CASE...WHEN...ENDCASE statement will be consistently aligned and indented. The pretty printer feature of SAP/R3 will do indenting automatically when executed. For program runtime efficiency purposes, the most likely event should be coded first.

Example CASE LFB1-EIKTO. WHEN C_ACCOUNT_1. PERFORM ……. MOVE ………… WHEN C_ACCOUNT_2. CONCATENATE …. WHEN C_ACCOUNT_3. READ …..ENDCASE.

5.2 CHECK statement

This statement should be used whenever possible in preference of the ‘IF’ statement. The ‘IF…ELSEIF…ELSE…ENDIF’ statement can get very deeply nested making it hard to read and modify. Check statement can be of useful for exiting forms.

Example LOOP AT T_ACCOUNTS. ……….. CHECK T_ACCOUNTS-TYPE = C_BS_TYPE.. ………..ENDLOOP.

5.3 COLLECT statement

Even thus time consuming the COLLECT statement can be used efficiently as long as that is the type of operation that is really required. In most cases this will be the summing up of totals. The COLLECT statement should not be used in conjunction with other table manipulating statements like APPEND, MODIFY etc. If the number of records is low (< 1000) the read/insert approach should be used.

5.4 IF statement

When coding nested IF statements, no more than three levels should be constructed. This will restrict lengthy control events congesting a program and making it difficult to read. Each level must be consistently aligned and indented. Deeply nested IF statements are not recommended and should be replaced with CASE statements.When coding IF tests, nest the testing conditions so that the outer conditions are those which are most frequently true. For logical expressions with AND, place the most likely



false first and for the OR, place the mostly likely true first. Avoid the use of double negative checks, as this can be difficult to understand and maintain.

Example IF BKPF-BELNR = V_INVNO. PERFORM INVOICE_PROCESS. ELSE. CHECK_DOC_NUMBER.ENDIF.

5.5 LOOP statement

Loop statements should be restricted whenever possibly. A good technique is to position the loop on the first record and then loop and exit the loop. Another possibility is to sort the table beforehand and terminated the loop with an ‘CHECK’ statement.

Example

Example

SORT T_ACCOUNTS BY TYPE.

LOOP AT T_ACCOUNTS. CHECK T_ACCOUNTS-TYPE = C_BS_ACCOUNT. PERFORM … ………ENDLOOP.

READ T_ACCOUNTS WHERE TYPE = C_BS_ACCOUNT.G_TABIX = SY-TABIX.

LOOP AT T_ACCOUNTS FROM G-TABIX . CHECK T_ACCOUNTS-TYPE = C_BS_ACCOUNT. PERFORM ……...ENDIF.

5.6 SELECT statement

Only fields needed for processing should be retrieved during a select. The fields should be selected in the same sequence as they appear in the accessed table. Key fields must be defined in the same sequence as they appear in the table. Always try to nominate as many key fields as possible. If all parts of the table key is known use ‘SELECT SINGLE’ instead of a ‘SELECT…ENDSELECT’. Small tables that are frequently accessed should be loaded into internal tables at program beginning.NEVER use the client-specified extension for the select statement. This statement will allow accessing data from a client other that the one you are currently logged into. This is never necessary and use of it will not be tolerated.

5.7 SHIFT statement

Try to avoid using the ABAP SHIFT statement if you are shifting many times (or many characters). Many shifts can quickly become very inefficient and dramatically slow down your program. Use other means such as the MOVE statement with variable offsets. Obviously avoid the use of SHIFT in a WHILE LOOP if the WHILE condition is checking the contents of the SHIFT field. That would be a good way to create a runaway program.

5.8 MOVE statement

When records involved in a move have the exact same structure, it is more efficient to use ‘MOVE…TO…’ than to use the ‘MOVE-CORRESPONDING…’ statement.



5.9 WHILE statement

WHILE loop processing makes more sense as the condition is stated on the WHILE condition. It is also quicker to execute.

Example WHILE RECORD_FOUND = TRUE. READ DATASET P_FILE INTO V_RECORD IF NOT SY-SUBRC IS INITIAL. RECORD_FOUND = FALSE. ENDIF.ENDWHILE.



6 General guidelines

The following sections are intended to provide general guidelines for ABAP developers in the EGAT Project. The subjects discussed will be familiar to all developers but are reiterated here because of their importance.

6.1 Data retrieval with GET statement

There are two basic techniques in ABAP/R3 to retrieve data from the database. These are the use of the GET statement with logical databases and the use of the SELECT statement with SAP SQL. Both methods offer some advantages and disadvantages as outlined below which should be considered before deciding which data retrieval method will be selected.

Advantages

Automatically retrieves related records from all the superior tables in the logical database defined within the program with the TABLES statement.

Retrieves records in the logical order of the primary key. Usually can provide a complete hierarchy of related tables in an application

area. For example the logical database MSM provides a complete hierarchy for the material master. This can sometimes make programming easier.

Validates user inputs (Selection screen) for completeness, correctness, and logic.

Automatically creates data selection screen for all primary key fields of declared tables in the logical database.

Performs authorization checks for database access. Is ideal for reporting purposes where related data needs to be retrieved. Involves less coding than SELECT.

Disadvantages

If selection criteria other than primary keys needs to be specified the use of logical databases becomes less efficient than the use of SELECT statements.

Logical databases are almost always restricted to one module (application area) within the system.

Since only one logical database can be specified per program, GET cannot be used against a table external to this logical database.

WHERE conditions can be specified only by using the selection screen at run time. Once entered by the user they cannot be changed during the execution of the program.

Statement ORDER BY is not allowed. The automatic retrieval of related records from all superior tables might cause

excessive database I/0 if GET is used at a very deep level in the structure. Data must be accessed in the order defined by the logical database.

6.2 Data retrieval with SELECT statement

The developer should have a complete understanding in the use of the SELECT statement. Information about the proper usage can be obtained via the ABAP HELP ON facility. The biggest processing overhead on any computer system is usually read and write access to the database. Efficient and proper coding of the SELECT statement can greatly improve program performance.



The developer should endeavor to retrieve the data in one operation. This can be achieved with the INTO TABLE addition to the SELECT statement. This form of coding will reduce the network traffic between the SAP/R3 work process and the database thread assigned to the work process. Using the SELECT statement in this form can bring other potential processing time savings as well in the areas of reduced input/output due to the fact the database buffers could store all results after the input/output operation without having it flushed due to other thread requests by competing programs.The usage of views instead of nested SELECT statements will also improve program performance for the same reasons as stated above.

6.3 Program size

All data retrieved into a program needs to be stored by SAP/R3 into the work process roll area. A busy application server can have lots of context switching if the SAP/R3 dispatcher has lots of requests. Therefore it is essential to reduce program runtime size. Use of explicit fields required on a SELECT statement helps achieve this. Not declaring internal tables too big can also achieve this. The best practice of OCCURS size specification is to leave it at 0 if the optimal size cannot be established. This is particularly true if the table is filled in one operation by use of the INTO TABLE addition on the SELECT statement. If the OCCURS size is known then it should be specified as the program size for that table will be reserved at generation time. This will reduce program extensions. Extensions will occur if the program stores additional rows. Once the program no longer requires the internal table the space taken up by the table should explicitly be handed back to the processor. This can be achieved through the use of the FREE statement.

6.4 Messages

The EGAT Project will try to use existing SAP/R3 messages whenever possible. This way the messages are not duplicated within the system and the user will not get different messages depending on in which part of the system he or she operates in.

6.5 Program checks

After completion the developed program should be checked via the extended program check functionality provided by the SAP/R3 ABAP Workbench. Runtime analysis should be undertaken with the Runtime Analysis tool.

6.6 Table updates and modifications

No direct updating of SAP/R3 tables via ABAP reports, dialog programs or in any other fashion is allowed. The only way to update tables will be with the use of the Call Transaction technique. Direct updates of SAP/R3 tables by the customer will void SAP warranty for the system. One exception is when SAP provided patches would have direct table updates.

Customer defined tables can be updated but this must be done by putting the code that updates the table in a function module and then calling it with the extension ‘IN UPDATE TASK’. This enables complete logging of the updates and will allow to rollback or roll-forward these changes if necessary. This will also allow the system administrators to monitor any updates and thus will be better able to troubleshoot problems. The other major reason is that it will reduce the Dialog time, so end-users will not have to wait as long. A message indicating that the update will take place must be relayed to the end-user.



6.7 Text elements

It is essential to store text that is written to a screen into text elements. No ABAP program should have any so called hard coding of texts. This makes it easier for future changes to these texts, as they are all contained in one place. This is also a SAP/R3 prerequisite if these texts have to be translated into other languages.

6.8 System fields

Language and currency codes must not be hard coded. The current system language should be determined from SY-LANGU and the currency code should be passed as a parameter.

6.9 Reading tables

Avoid reading large tables via non-key fields. If an alternative table cannot be found, then the creation of additional indices on transparent tables can overcome the problem of non-key table access.

6.10 Batch sessions

When writing out dates in batch input session they must be written out in the eventual user’s default format. This will ensure the batch session will not fail due to the fact that the batch session contains a different date format to the user’s date format. This can be accomplished by moving the date variable to a character variable using the WRITE statement with the DD/MM/YYYY extension.

6.11 Development Workbench

Developers are encouraged to use the development workbench for development work. It is a very good organisational tool that will greatly assist in developing programs.



7 Appendix

7.1 List of SAP modules

Module DescriptionFI FinancialsCO ControllingMM Material ManagementBC BASIS

7.2 List of SAP Submodules

Module DescriptionGL General LedgerAR Accounts ReceivableAP Accounts PayableSL Special LedgerPA Profitability AnalysisCC Cost Center AccountingIO Internal OrderIM Inventory ManagementPUR PurchasingZZ Unspecified

7.3 List of report types

Report Type

Description

C ConversionI InterfaceR ReportE EnhancementF Form (Layout)X Include for report type programs

7.4 Functional message classes

Message Class

Description

F Financial AccountingK ControllingM Material ManagementS Basis

7.5 Development classes

Message Class

Description

ZBC BasisZCO Controlling



ZFI FinancialsZMM Material

7.6 Functional areas for Report Painter library

Message Class

Description

A Asset ManagementF Financial AccountingK ControllingO Special LedgerS Basis

7.7 List of Report Painter sets

Set DescriptionB BasicS SingleM MultipleD DatasetS Basis

7.8 List of teams

Team DescriptionFI Financial TeamCO Financial Controlling TeamMM Material Management TeamBC Basis Team

7.9 List of sub teams

Sub Team DescriptionGL General LedgerAP Accounts PayableAR Accounts ReceivableSL Special LedgerCCA Cost Center AccountingPA Profitability AnalysisOPA Internal OrdersPUR PurchasingIM Inventory ManagementABAP ABAP DevelopmentsSEC Security

7.10 Change Request Examples

OSS:160380:FI:Message RW022 Balance in transaction currency

FI-AP:Customizing the Accounts Payable Module

BC-CUS:Create Logical System for DP1 100/110

CO-CCA:Activate integrate in Planning Version



FI-GL:ABAP Account Master Listing

FI-AP:SAPscript Accounts Payable Invoice


Documents

ISU ABAP Dev handbook Draft 0 1 EN