ABAP Programming Best practice for BW

[BenedictV]

ABAP Programming Best practice for BW

Contents

Introduction

Aesthetics of programming

Variable Declaration

SELECT statements

General

1.     Introduction

               This document is intended to cover the basics of good ABAP programming for BW developers, developers who are proficient in BW but not so in

               ABAP and ABAP learners. In a normal BW environment we use ABAP to write a code for doing a look-up in transformation or to code function

               modules to extract data from source systems. This process would generally involve declarations, selection of data, read the selected data to

               manipulate it or to perform calculations. I have taken into consideration only these basic steps for this document.

2.     Aesthetics of programming

·         ALWAYS comment your code

·         Use comment blocks to explain a complete code flow and single line comments for individual statements wherever necessary

·         Your comments should explain the question of “why” and not the “what”. What is happening can be understood from the code

SELECT COMP_CODE GL_ACCOUNT SALES FROM /BIC/AZSALESDSO00 INTO TABLE l_t_zsales WHERE DOC_TYPE = ‘SP’.	* Selecting documents of type ‘SP’ from sales DSO The WHAT is not very useful is it?
	* Only Special Posting documents are selected for a valid look-up

          ·         Maintain a change log at the start of the program with date, user ID and a short description of the change

          ·         Maintain a certain style of format throughout the program

·                            o   Reserved words in upper case. Variables in lower case

o   E.g: SELECT FROM mytable WHERE myfield = field

          ·         Always click pretty printer button before saving and activating the code (whenever possible), this will do the proper formatting of code(Citing Vinod                Bokkade's comment below)

3.     Variable Declaration

          ·        Use only required length when declaring a variable using ‘Elementary Data Types‘

o   Eg: lv_xxx TYPE i; lv_yyy TYPE c length 10

          ·        It is always better to define a variable using ‘TYPE’ and referring to a DDIC object

o   E.g.:  lv_xxx TYPE TABLE-FIELD1.

          ·        Always follow a convention for declaring variable names. This will make it easier to understand the code and a lot easier when you debug the code.

o   E.g.: var1 TYPE c length 4 does NOT say much about the purpose of the variable, but a declaration like “lv_user_date TYPE sy-datum” would imply that the variable is a local variable and it is used to store user date in the system date format of YYYYMMDD

o   lv_<var> - Local Variable

o   gv_<var> - gloal variable

o   l_s_<structure> - structure definition

o   l_t_<table> - internal table

o   wa_<area> - work area

            ·       While declaring an internal table, make sure you define a structure first with the fields that would be needed. It is not recommended to

                define the internal table on the structure of the database table unless you are going to consume all the fields in the table

o   Doing this saves on space allocated for the temporary table and also improves the speed of SELECT’s and READ’s

o   E.g.: l_t_sales TYPE STANDARD TABLE OF /BIC/AZSALESDSO00 would slow down your code. Instead define a structure first,

TYPES: BEGIN OF l_s_sales,

                doc_no TYPE /BIC/AZSALESDSO00-doc_no,

                amount TYPE /BIC/AZSALESDSO00-amount,

                END OF l_s_sales.

DATA: l_t_sales TYPE STANDARD TABLE OF l_s_sales,

            wa_sales TYPE l_s_sales.

4.     SELECT Statements

          ·         Avoid using multiple SELECT statements to the same database table. Instead SELECT all that would be needed, fields to an internal table and then

                use a READ with necessary restriction

          ·         Avoid using,

o   SELECT…ENDSELECT

o   SELECT statements inside LOOPs

o   Non-Key fields as search conditions in SELECT statements

          ·         In the context of choosing records from a database table based on records in different database table, use a JOIN in your SELECT statement, instead

                of executing two separate SELECTs and looping through two internal tables

          ·         Do not use ‘SELECT *’. Instead define a structure with the fields you would be selecting and then ‘SELECT’ only those fields into an internal table

                that uses this structure

          ·         In the context of transformation routines, use ‘FOR ALL ENTRIES’ when selecting records based on source or result package. This would restrict the

                number of records being selected instead of having an open SELECT which would bring all records

o   Make sure you check that the source or result package is not empty before doing a ‘FOR ALL ENTRIES’ based SELECT

o   Also, try to eliminate duplicate entries from the internal table based on which records are selected using FOR ALL ENTRIES

          ·         Using INTO CORRESPONDING FIELDS OF statement in your SELECT does not affect performance, but make sure the target internal table contains

                only the needed fields in the right order

          ·         Use as many 'WHERE' conditions as possible in the 'SELECT' statements instead of having a open select and then deleting the selected entries from                the internal table(citing Amrita Karwadkar's comment below)

5.     General

          ·         Avoid using nested LOOP statements wherever possible

          ·         Observe the following for READ statement

o   Always SORT an internal table before you do a READ

o   It is always recommended to do a BINARY SEARCH in a READ statement as long as the fields used for SORTing are same as the WITH

        KEY fields used when READing

o   A BINARY SEARCH in A READ statement may pick no records if the SORT and READ statements use different fields

o   READ statements must always be followed by a 'IF sy-subrc = 0' check

o   READ with TRANSPORTING NO FIELDS can be used if the fileds are not used for further processing

          ·         Never hard code a break point in a program

o   There is always a chance that the program might get transport with the breakpoint

          ·         In the context of transformations, when there are only one-to-one mapping between the source and target, you might use a simple expert routine. The

                advantage is that,

o   Source package can be directly moved to result package without having to go through individual field routines for each field mapping

o   LOOP AT SOURCE_PACKAGE INTO wa_source_package.

                                MOVE-CORRESPONDING wa_source_package TO wa_result_package.

                                APPEND wa_result_package TO RESULT_PACKAGE.

                         ENDLOOP.

          ·         Call to function modules should be preceded with a 'IF sy-subrc = 0' check

          ·         Remove any un-used code or function module calls, even if it is commented, before transporting to production

I will keep updating this document based on further corrections/suggestions.