ABAP Programming Best practice for BW
ABAP Programming Best practice for BW
Aesthetics of programming
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 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)
· 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.
· 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.
Really different from other blogs and docs..I liked the commenting part and variable declaration part which most of us ignore.
Thanks for sharing..
Thanks Anshu. Feels great to be appriciated by a SCN Topic leader 🙂 .
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. 🙂
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 Ram, I am glad you find it useful.
Really good to see these days, we are finding so many BI/BW related ABAP docs..
Thanks for sharing.
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.
Thanks Vinod and Venu.
Will add your suggestion to the doc.
Good documentation with clear explanation.
Thank You Anand
Good work Benedict
Thanks for sharing
Thank you Martin. Let me know if you have any suggestions, we will keep the document growing.
Nice Blog for BW consultant 🙂
Naveen, Anshul, thank you very much guys.
Good document Benedict
Nice work Benedict 🙂
good one.. thanks for sharing
Very useful info and well documented. Very easy to understand. Tons of thanks
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.
Thanks Sameer for your nice comments
Good document, thanks for sharing......
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 .
Good points but in my opinion, the comments are the best.
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.
Thanks for sharing, really helpfull!
Nice work Benedict!
Very nice information shared!!! Highly appreciated…
Try below link for more details on ABAP performance tips.
This will also help you in improving your ABAP programming skills. 🙂
Thank you Sonal. There's some good information in that wiki. Hope people who read this doc will visit the wiki too.
Thanks for sharing....helpful info
Really useful doc to all of us. Thanks for sharing 🙂
This is really very useful for ABAP coding standards. Thanks for sharing.. 🙂
Thanks for sharing your knowledge Benedict !!
Allow me to add some additional "best practices":
Thank you Sander for your comments and valuable suggestions.
I will include your points in the document with citation.
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,
Thank you Limbadri. I am happy that you found this document useful.
Good one..Thanks for sharing
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.
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.
Thank you for your feedback Sakthikumar.
Very useful document. And.. it confirms that I was already doing it quite good 🙂
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.
Very useful document.
Thanks & Regards,
Very useful... thank for sharing!
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! 🙂
Thanks for sharing....
Pedro Ponce P.
Very useful document !! Thanks for sharing Benedict 🙂