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

                  a). Reserved words in upper case. Variables in lower case

       b).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 VinodBokkade's comment below)

3. Variable Declaration

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

·      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

 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.

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

       lv_<var> - Local Variable

       gv_<var> - gloal variable

       l_s_<structure> - structure definition

       l_t_<table> - internal table

       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 todefine the internal table on the structure of the database table unless you are going to consume all the fields in the table

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

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 thenuse a READ with necessary restriction

·      Avoid using,

SELECT…ENDSELECT

SELECT statements inside LOOPs

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, insteadof 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 tablethat 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 thenumber of records being selected instead of having an open SELECT which would bring all records

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

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 containsonly the needed fields in the right order

5. General

·      Avoid using nested LOOP statements wherever possible

·      Observe the following for READ statement

Always SORT an internal table before you do a READ

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

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

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

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

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. Theadvantage is that,

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

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