Skip to Content

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.

To report this post you need to login first.

48 Comments

You must be Logged on to comment or reply to a post.

  1. Anshu Lilhori

    Hi,

    Really different from other blogs and docs..I liked the commenting part and variable declaration part which most of us ignore.

    Thanks for sharing..

    Regards,
    AL

    (0) 
      1. Anshu Lilhori

        Thanks Benedict..My pleasure..We all are topic leaders because of the support and encouragement given by you guys..

        So i thank you as well on behalf of other topic leaders of BW space. 🙂

        Regards,

        AL

        (0) 
  2. Raman Korrapati

    This is one of the problematic area for BW consultants who’s are away form ABAP.

    The explanation part which you done so good for us. its easily to understand the code with general words and it will boost us to try out our own to code.

    Really very good doc. Thanks for making and sharing with us.

    Thank you Anshu for conveying our wishes thru BW Forum..

    Thanks

    Raman

    (0) 
  3. vinod bokade

    Thanks for sharing.

    Just to add, always click pretty printer button before saving and activating the code (whenever possible), this will do the proper formatting of code.

    Thank-You.

    Regards,

    VB

    (0) 
  4. Sameer Gokhale

    This is a good document for anyone who is starting out writing ABAP code in BW. Especially adding comments before any code makes the job of anyone debugging it later so much easier.

    (0) 
  5. Amrita Karwadkar

    Its a very helpful document for SAP BI guys  .

    One point to add from my side :

    Sometimes for performance point of view , we do not give many comparisons in the where clause of select statement . Instead we write another line of code to delete data from Internal table where a specific condition does not match .

    (0) 
    1. Benedict Venmani Felix Post author

      Thanks Eduardo. A lot of times when I debug a code which someone has written, I waste a lot of time understanding why some pieces of code are in there 🙂 . Also, it gets frustrating remembering each variable if declared as var1, var2. There are a few debates in the ABAP about this and people dont really care for variable names but for BW consultants like me(who only understand so much in ABAP), thses things make a lot of difference.

      Regards,

      Benedict

      (0) 
  6. Sander van Willigen

    Thanks for sharing your knowledge Benedict !!

    Allow me to add some additional “best practices”:

    • Use field-symbols wherever possible;
    • Use internal table of type hashed if you can read the table with key fields;
    • Encapsulate coding, e.g. in enhancements, BAdI implementations, but also if it concerns reusable coding / building blocks;
    • TYPES declaration using data elements;
    • Use ABAP OO and dynamic coding, especially if you are going to develop reusable coding / building blocks;
    • Avoid SELECT SINGLE within loops;
    • Don’t forget the run the Extended Check and Code Inspector wherever possible;
    • Investigate the reuse of standard SAP coding (e.g. function modules, classes);
    • (Re)initialize your data objects (variables, internal tables).

    Best regards,

    Sander

    (0) 
  7. Limbadri Sabbani

    I am in accordance with Anshu and I liked most is the commenting part – answering Why question was impressive.

    Yes, during coding people do ignore commenting especially when it is attempt to attain new challenging solution. But by answering why question makes life easy and fast.

    Thanks for sharing,

    LS

    (0) 
  8. Mario Tibollo

    hi, nice doc.

    you might want to describe the different types of itabs (standard, sorted, hashed)…

    and as of 7.3 you can define internal tables with multiple keys.

    (0) 
  9. Sakthikumar Jayaraman

    Hi Vasanth,

    Very useful document for BW developers who need help in writting ABAP routine.

    ‘Comment your code’ very valid point,which will helps in future reference by new developer or even for same developer who revisit to the code after long time.

    Regards,

    J.Sakthikumar

    (0) 
    1. Benedict Venmani Felix Post author

      ha..ha…now that you are good at this, I think you should move on to writing confusing code with all those symbols in them ?, ->, # classes, references etc 😛 . I was never able to get a grip on those OO codes.

      Benedict

      (0) 
  10. Mansoor Ahmed

    Nice document and very helpful indeed. I would like to add one thing, I always use these tips specially when it comes to write a code in BW. Thanks for sharing! Bookmarked! 🙂

    (0) 

Leave a Reply