You are on page 1of 4

ABAP Programming Tips

General
 While declaring variables, always follow the naming conventions through out your
code.
 Your variable names talks a lot about its usage. Make sure your variables are of
the form
o {Prefix1}{Prefix2}_{name} where:
 Prefix1:
 L  Local
 I  Import
 E  Export
 G  Global
 T  Table Type
 Prefix2:
 V  Single Value
 S  Structure
 T  Table
 R  Type ref to Data
 O  Type ref to Object
 E  Type ref to Exception objects

 Name – name of the variable
 Before changing the parameters (type or name), make sure that you run “Where
used”, make a note and change them as well.
 While working on ABAP Classes and Interfaces, Never change a super class of a
framework. It could potentially bring all applications down. Double check to make
sure that the code you change is in your class only.
Here are some of the common data definitions:

Type Name
Import (Single Value Field) IV_{name}
Import (Structure) IS_{name}
Import (Range Structure) IS_{name}_RANGE
Import (Table Type) IT_{name}
Import (Range Table Type) IT_{name}_RANGE
Import (Type Ref to Data) IR_{name}
Import (Type Ref to Object) IO_{name}
Import (Type Ref to Exceptions) IE_{name}

Export (Single Value Field) EV_{name}


Export (Structure) ES_{name}
Export (Range Structure) ES_{name}_RANGE
Export (Table Type) ET_{name}
Export (Range Table Type) ET_{name}_RANGE
Export (Type Ref to Data) ER_{name}
Export (Type Ref to Object) EO_{name}
Export (Type Ref to Exceptions) EE_{name}

Tables (Meant for Import) IT_{name}


Tables (Meant for Export) ET_{name}
Changing Avoid using it unless there is no option
Exceptions Do not declare exceptions in BAPI

Global Field1 (Single Value) GV_{name}


Global Field (Structure) GS_{name}
Global Field (Range Structure) GS_{name}_RANGE
Global Field (Table Type) GT_{name}
Global Field (Range Table Type) GT_{name}_RANGE
Global Field (Type Ref to Data) GR_{name}
Global Field (Type Ref to Object) GO_{name}
Global Field (Type Ref to Exceptions) GE_{name}

Local Field (Single Value) LV_{name}


Local Field (Structure) LS_{name}
Local Field (Range Structure) LS_{name}_RANGE
Local Field (Table Type) TT_{name}
Local Field (Range Table Type) LT_{name}_RANGE
Local Field (Type Ref to Data) LR_{name}
Local Field (Type Ref to Object) LO_{name}
Local Field (Type Ref to Exceptions) LE_{name}

Arguments in perform P_{prefix}_{name} where prefix is LV, LS or LT

Structure Definition TS_{name}


Table Type Definition TT_{name}

1
Data elements declared in the TOP include.
Type Name
Field Symbol Definition (Single Val, Local) <LV_{name}>
Field Symbol Definition (Structure, Local) <LS_{name}>
Field Symbol Definition (Range Structure) <LS_{name}_RANGE>
Field Symbol Definition (Table, Local) <LT_{name}>
Field Symbol Definition (Single Val, Local) <LV_{name}>
Field Symbol Definition (Structure, Local) <LS_{name}>
Field Symbol Definition (Table, Local) <LT_{name}>
Field Symbol Definition (Range Tab, Local) <LT_{name}_RANGE>

Function Modules
Save Function Module (Insert/Update)
 Please ensure that IV_UNAME (SY-UNAME) and IV_LANGUAGE (SY_UNAME) is
mandatory for all modules.
 Create Number Ranges for the Header Tables (and some of the related tables as
required).
 Please create lock objects on the header tables and make sure that you obtain a
lock before changes and release the lock after changes.
 Make sure that you transactions are atomic. Either commit your work after all
changes are successful or Rollback in case of error. If you rollback, make sure
that you have released the locks.
 Concurrent Updates needs to be handled via optimistic locking (soft) only. No
Exclusive locking (pessimistic locking) should be done. One method is to check
that the REVNUM field that is passed is the same as in the database. Along with
that, make sure that the Changed Date and Change time is the same as in the
database. Once verified change the REVNUM by incrementing by 1 and update
the change date/time with current date/time. If you have other ways, feel free to
share it with the team.
 During save, please make sure that entries in all the text (_T_*) tables that
relate to your modules are also saved. If no data exists, treat it as an error. (As a
cross check, you can verify the same by executing the view and making sure that
the data is returned correctly)
 The Function should be RFC Enabled. Never raise an exception. Always return
errors in the ET_RETURN (Type BAPIRET2) structure.
 Never hardcode text strings. Make sure that you use a text element. But use it
with text reference.
o E.g. If you have an error during validating the email, use it as "Email
ID is required"(001) instead of using text-001. This will ensure that
error messages are displayed regardless of user logon language.
 At the end of the function, Always call "get details" and return the values as
export/table values. This will serve the purpose of reflecting the data as-is in the
DB back to the user and will save another round trip to retrieve it again.
 Always update audit fields changed by, changed date, changed time with
IV_UNAME, current date/time.
 Update audit fields created by, created date, created time only during create.
Get Details Function Module
 Please ensure that IV_UNAME (SY-UNAME) and IV_LANGUAGE (SY_UNAME) is
mandatory for all modules. Extract the data for the language specified.
 Ensure that all corresponding text table data is also returned. Never return only
Ids.

You might also like