Professional Documents
Culture Documents
ABAP Routine Best Practise
ABAP Routine Best Practise
Intelligence
Applies to:
SAP BI Netweaver 2004s. For more information, visit the Business Intelligence homepage.
Summary
This tutorial will give you a brief understanding of the best practices that should be followed while using
ABAP for BI taking into account the performance
Author:
Mansi Dandavate
Company: Deloitte
Created on: 22 May 2009
Author Bio
Mansi Dandavate is a Netweaver 2004s Certified Consultant with 2.5 years of experience in SAP
BW/BI
Table of Contents
How to decide whether to use Start Routines, End Routines or Individual Update Routines ............................3
Declaring an Internal Table.............................................................................................................................3
Deleting a Record ...........................................................................................................................................3
Database Access using Select .......................................................................................................................4
Example: ......................................................................................................................................................................4
Overview
ABAP for a BI Consultant is usually limited to implementing the logic and making it work out.
Hardly a BI Consultant is concerned about the performance while implementing the Business Logic in Start
Routines.
The consequences of these are faced by the Support Team who doesnt understand why the Data load is
taking so much time in Production.
So for a Successful BI Implementation it is mandatory that we also consider the performance aspect while
writing ABAP Logic. Performance does matter when it comes to loading lakhs of records in the Production
System.
This document gives you an overview of the best practices which should be followed while writing an ABAP
Code considering the performance.
How to decide whether to use Start Routines, End Routines or Individual Update
Routines
Start Routines are preferred when any transformation is needed in the data at package Level
When you need to calculate the value of any field based on any other field which is read from some
other ODS or table, Start Routines can be used.
Individual Routines can be used to read data from the global Internal Table which is populated in the
start routines or to implement any simple formula or a calculation
End Routines are Target Specific. Any fields which you wish to populate which are not present in the
souce but present in the target, can be filled using End Routines. End routine alone can replace start
routines as well as individual routines in some cases.
Also if the internal table is not been used in the Individual routines then declare it in the local part of your
start routine and remember to clear it at the end of the routine with the below statement.
Refresh it_xx.
free it_xx.
<source_fields>.
Not
Preferred
Sometimes you might come across a requirement when you want to delete records for multiple values.
Eg. I would like to delete all records from source_package where F1 = X, and Y.
In that case you can use the SELECT-OPTIONS type.
DATA : TEMP type F1. i.e. the field for which we are creating SELECT-OPTIONS
SELECT-OPTIONS : s_F1 for temp.
DATA : wa like line of s_F1.
wa-sign = 'I'.
wa-option = 'EQ'.
wa-low = 'ABCD'.
append wa to s_F1.
wa-sign = 'I'.
wa-option = 'EQ'.
wa-low = 'EFGH'.
append wa to s_F1.
Delete source_package where F1 in s_f1.
Range tables provide an easier method to either add or remove values we want.
Remember to use FOR ALL ENTRIES IN as used above, this will select only those records which are
relevant for selection.
Imagine there is a delta load going on and source_package contains only 10 records, however the database
table YYY contains 12400 records.
So not using FOR ALL ENTRIES IN would select the entire 12400 records, although we require only the 10
which are relevant, thus affecting the performance badly.
Also if you are using the FOR ALL ENTRIES IN then do remember to check if the internal table is filled, if it
is not then it will select all the records from the internal table.
Loop at source_package.
Select single F1 F2 F3 into wa_xx
where F1 = source_package-F1.
Endloop.
from YYY
Severly affects
Performance
Also while selecting data from active table of an ODS, always base the selections on its key fields. If not
remember to create secondary indexes.
Send Messages to Monitor
Whenever any unexpected conditions occur you can pass messages to the MONITOR to notify about it.
MONITOR-msgid =
MONITOR-msgty =
MONITOR-msgno =
MONITOR-msgv1 =
MONITOR-msgv2 =
APPEND MONITOR.
'YBW'.
'W'.
'000'.
source_package-doc_number.
source_package-s_ord_item.
Use the transaction SE91 to create a Message Class. Define your message there with a message number.
The message type will be Warning.
You can pass any relevant information like Document Number and Item
Value Comparison
Always use IS INITIAL statement instead of is equal to
Because null for a character is but for a integer is 0 and also if you use initial you dont need to handle the
length as well.
Example:
If <source_fields>-F1 is initial.
Endif.
Modifying a Record
Modify a record of an internal table consumes time, because it copies the entire record into a separate work
area. So instead use Field Symbols. It gives about 10 times better performance
Example:
FIELD-SYMBOLS: <SOURCE_FIELDS>
TYPE _ty_s_SC_1.
Loop at source_package assigning <source_fields>.
<source_fields>-F1 = X.
* Since Field Symbol is a pointer the above statement automatically changes the
*value of the record. So no need to modify.
Endloop.
Loop at source_package into wa_xx.
Wa_xx-F1 = X.
Modify source_package.
Endloop.
Severly affects
Performance
Even the following method can be used to do the same thing, but performance wise the above statement is
anytime better.
Loop at it1 into wa1.
Clear wa2.
Move-corresponding wa1 to wa2.
Append wa2 to it2.
Endloop.
Execution takes
more time
So to enhance the performance of the above code, you can write it as follows :
SORT itab2 BY f1 f3.
LOOP AT itab1 INTO wa1.
READ TABLE itab2 WITH KEY f1 = wa1-f1
f3 = wa1-f3 BINARY SEARCH TRANSPORTING NO FIELDS.
IF sy-subrc EQ 0.
v_tabix = sy-tabix.
LOOP AT itab2 INTO wa2 FROM v_tabix.
IF wa2-f1 NE wa1-f1 or wa2-f3 NE wa1-f3. EXIT ENDIF.
*processing or records here
ENDLOOP.
ENDIF.
ENDLOOP.
Sort the internal table 2 with the fields that will be used in the where clause.
Also instead of looping at itab2 directly and checking the value, we first read the index and then start looping
from that index.
As the result the above code will be faster since the number of loop parses will be reduced.
Comment your Code
Last but not the least always develop a habit of commenting your code.
It might be possible that someone else would be maintaining the code written by you.
Comments would make the code more readable for even a layman who doesnt have knowledge of coding.
Sometimes even though you might have written the code and you have a look at it after quite a long time, it
becomes difficult to remember, why was the code written that way.
So in such cases also comments are useful.
Mention your name, Date of Coding and the requirement for the logic.
Related Content
http://help.sap.com/saphelp_nw04s/helpdata/en/44/bd9b5be97c112ce10000000a11466f/content.htm
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e73bfc19-0e01-0010-23bc-ef0ad53f2fab
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/fc61e12d-0a01-0010-2883e2fc63ef729b
For more information, visit the Business Intelligence homepage.
For more information, visit the ABAP homepage.