TEN COMMANDMENTS IN ABAP

1.    Thou shall choose the most efficient statement to access the database and minimize the data baggage that is brought back.

          Avoid any en route operations as much as possible.

The key here is

• Reduce database load
• Reduce network load
• Only read necessary data
• No multiple reads
• Application of buffering techniques
• Minimize search effort for the database using indexes.
• Use bundling techniques to fill data packages
• Favor mass accesses.

     Refer this link for the guidelines in database operations which were pulled together from the vast amount of resources available on net and SAP documentation.      Efficient Database Operations - SAP Developer Challenge - SCN Wiki

2.  Thou shall make proficient use of Logical Database

• SAP provides many logical databases for reading records from the database. Logical databases are ABAP programs that decouple Open SQL statements from application programs and have been optimized by SAP for the best database performance. So when reading data from database involves many tables, use logical database.

• Be sure to choose the most suitable logical database. Logical database has a hierarchical structure. So if you want data from a node at the lowest level, avoid using logical database. Use select statement instead or another data where this node is at a higher level.

• If your program uses a logical database, but does not require all fields belonging to a certain GET event, always use the FIELDS addition to reduce the amount of data selected by the logical database

• When using the GET event keyword to retrieve records via a logical database, selection can be restricted by using the CHECK statement (using either CHECK select-option(s) or CHECK condition).
  
  In this case, a CHECK statement that returns a negative result terminates the processing of GET events for subordinate database tables and the associated data is not read. For efficiency reasons, always perform the CHECK at the highest possible level of the database hierarchy.

• When you are creating a custom logical database, bear in mind that the use of very large tables will degrade the performance of a logical database. Also, remember that some tables in SAP are very complex, so they will be problematic in any user-defined logical database.

3.   When creating database tables, thou shall not leave it half done.

   Provide the correct technical settings to enable faster accesses to the tables in the

• Specifying the right data class to the table allocates the table to the most appropriate physical file on the disk on the database server. Tables with similar characteristics, like, those that can grow quickly are all grouped together in that part of disk (table space for Oracle and DB space for Informix) where there is a lot of free space.
  • Master data table can be specified under APPL0 as they are not updated very often and grows slowly – like vendor master
  • Transaction data can be specified APPL1 as they are updated very quickly and will grow very quickly. Like order placedon a vendor.
  • APPL2 data class is mainly assigned for configuration tables like text tables and other check tables whose contents are determined at the size of creation itself and do not change much after that.

• It is also important that you specify the right size category. Here the rule is, 'It is okay to provide an overestimated size of database table but never underestimate.' Cause if you specify a size that is underestimated and the table grows larger than the space initially associated to it, then reorganization is required when the next space (each allocated space is called extent) is allocated. This will tremendously reduce the efficiency of the tables.

• Try to create secondary indexes when there will be frequent accesses on the table for a particular set of fields in where clause. These fields should be mentioned in the where clause of the select statement in the same order as specified in the index. However, don’t create index if it will be rarely used, it will create an unnecessary burden. Also don’t create indexes using the same fields as that of an existing index.

• Whenever you create an index, make sure you include the ‘mandt’ field also in the index if it is a client dependent table.

• It would be better to enable buffering if there is requirement to read database table frequently with no update operations. Buffering would be even more beneficial and reliable if there is only one application server connected to the database server. If buffering is enabled and there is more than one application server, then you will need to use the select statement with the clause bypassing buffer if you require the most updated data in the database.

You can considerably reduce the time required to access data by buffering it in the application server table buffer. Reading a single entry from table T001 can take between 8 and 600 milliseconds, while reading it from the table buffer takes 0.2 - 1 milliseconds.

• Enable log data changes only for table containing very critical data for which every change has to be tracked, since this slows down each update in the table.

4.  Thou shall not be naïve when working with internal tables.

Array Operations

ABAP documentation generally describes this type of processing as block operation. When internal tables are filled from database tables, the INTO TABLE itab keyword causes the SELECT statement to insert the data records en bloc to the internal tables

An array interface is also available for filling internal tables from other internal tables. The corresponding ABAP statements are:

APPEND LINES OF itab1 TO itab2.

INSERT LINES OF itab1 INTO TABLE itab2.

• Prefer array operations on internal tables to single record operations (next section) wherever possible because the kernel can process administrative work (for example, memory allocation) more efficiently.

For more SAP recommended guidelines on intelligent operations with internal tables, refer this link

Efficient Database and Internal Table Operations - SAP Developer Challenge - SCN Wiki

5.  Thou shall not try to reinvent the wheel.

Use already existing function modules and operations rather than creating your own logic.

• Many times the function modules exist for accessing the data. Instead of reading directly from the table,use these function modules. If same kind of information is read in various transactions, there is a high probability that a function module exist for reading that information. The run-time analysis or debug can give more information.

• Function modules exist for frequently used actions. You can search for the function module based on some keyword.  For example, if you were searching for a function module for pricing, search the function module giving *pricing*.  If you are searching for conversion exits for formatting data, give *conversion*exit* or for popup functions, try *popup*.

• For string operations, use the various available string operations, rather than implementing your logic for the same. Example:

To find out the length of a field use the string length function.   
FLDLEN = STRLEN (FLD).

• Similarly use the internal table functions available rather than using your own logic for various table operations. Example:

DESCRIBE TABLE ITAB LINES CNTLNS. 

Is more efficient than
LOOP AT ITAB.
CNTLNS = CNTLNS + 1.
ENDLOOP.

6.  Thou shall reflect and proceed wisely when using conditional loops

• Use the most probable cases first.

• When coding IF tests, nest the testing conditions so that the outer conditions are those which are most frequently true. This will ensure minimal code execution.

• Similarly, for logical expressions with ‘AND’, place the most likely false first. For the ‘OR’ operator, place the most likely true first.

• For Case statement, place the most likely case first.

• If and Case structures – The CASE is better for two reasons. It is easier to read and after about five nested IFs the performance of the CASE is more efficient.

• WHILE vs DO – While is faster to execute than do statements.

• Make use of the statements CHECK, EXIT, REJECT, STOP & CONTINUE in loops. This will suspend processing and/or skip remaining unnecessary processing for improved performance. And try to put them as much above in the conditional block as possible.

7.  Thou shall give thoughtful judgment on Modularization of code – subroutines, function modules and methods

• Whenever values need to be passed in a subroutine, have type declarations assigned to the formal parameters. If no specific type declaration is possible then use TYPE ANY. This improves the performance.

• Determine the need to perform  subroutine before you call it.

• Take into account initialization time for local variables

• Use LOCAL rather than TABLES statement in subroutines

• Use STATICS rather than LOCAL variables

• Function Modules - access is slightly more expensive than internal subroutines since you are loading another program.

• Subroutines – Try to pass parameters by reference as much as possible. Specially when you pass internal table, try to pass the reference, unless you really need a copy of the table.

• Use typed formal parameters, i.e parameters whose types are also defined in the subroutine declaration. This requires less CPU memory, reduces possibility of syntax errors and run time errors.

• Calling methods of global classes is faster than calling  function modules

• There is no performance loss when you call local methods compared to  local subroutines

8.  Thou shall know thy data types and use them prudently.

• Use fields of type I for typical integral variables like indices.

• Use numeric literals when you are dealing with type-I variables like sy-subrc instead of character strings.

• Use properly typed constants instead of literals or variables. e.g.

CONSTANTS: PI TYPE F VALUE '3.1415926535897932'.

Instead of

DATA: PI TYPE F.

PI = '3.1415926535897932'.

• Arithmetic : Use type-N fields only for pure digit strings that are not intended for calculations, e.g., telephone numbers or parts of a date or time field. For arithmetic operation, use type P or I.

• Mixed Types

Don’t mix types unless absolutely necessary.

DATA: F1 TYPE I VALUE 2,

       F2 TYPE P DECIMALS 2 VALUE '3.14',

       F3 TYPE F.

F3 = F1 * F2.

Instead use all like data types.

DATA: F1 TYPE F VALUE 2,

       F2 TYPE F            VALUE '3.14',

       F3 TYPE F.

F3 = F1 * F2.

• Unless rounding errors are not avoidable, do not use ‘packed’ data variables.

* Some of the examples here are from the Tips and Tricks provided in the report RSHOWTIM. Refer this report for more details.

9.  Thou shall foresee requirements, plan ahead and be well structured when writing an Object Oriented program.

• In developing ABAP Objects, the ABAP language was cleaned up, in particular in the object-oriented contexts. The obsolete statements hence should not be used in Object oriented programs.

• In object-oriented programming, analysis and design decisions have an even greater effect on implementation than they do in procedural programming. Therefore, you should structure and formally standardize the analysis and design phase. You can use modeling languages like Unified Modeling Language (UML) to do this.

The model has the following advantages:

. Improved software structure and consistency in the development process

. Reduced maintenance effort and less susceptibility to errors

. Better integration of the customer/user into the analysis, design, and

maintenance processes

. Options for extending the software are simpler and more secure

• In classes, you can only use the TYPE addition to refer to data types. You can only use the LIKE reference for local data objects.

• To get the maximum out of data encapsulation advantage of OOPs, try to declare as many attributes as possible as private.

• To save run time, individual attributes are sometimes defined in the public visibility section, but they must then be given the addition READ-ONLY.

• Functional Methods: Methods that have a RETURNING parameter are described as functional methods. They can have neither an EXPORTING nor a CHANGING parameter. The RETURNING parameter must always be passed by VALUE.

• Constructors - Each class can have no more than one (instance) constructor.

                   . The constructor must be defined in the public area.

. The constructor's signature can only have importing parameters and  exceptions.

. When exceptions are raised in the constructor, instances are not created, so no main memory space is occupied.

. You cannot normally call the constructor explicitly.

• There is no destructor in ABAP Objects, that is automatically called from the memory immediately before the object is deleted.

• Changes made to super class at a later stage have an immediate effect on the subclasses; therefore, you must not alter the semantics when you change a super class.

• When you assign a super-class reference to a subclass reference, you should always use widening cast assignment operator ‘?=’, since the subclass may contain more components than super class and hence super class may not be able to access all these components of subclass. When the widening cast operator is used all the components of the subclass can also be accessed, and there will not be a type cast error.

Data : obj_vehicle type ref to cl_vehicle,

            Obj_car type ref to cl_car.

cl_car is a subclass of super class cl_vehicle. It has attributes and methods in addition to the components of super-class cl_vehicles.

create object obj_vehicle.

obj_car ?= obj_vehicle.

Now though super class obj_vehicle is assigned to sub class obj_car, the widening cast operator, allows obj_car to access not only the components of obj_vehicle, but also of obj_car. (Polymorphism)

• This polymorphism, that is, same object behaving differently can also be achieved using interfaces. Interfaces cannot be instantiated; interface reference can only refer to instances of classes that have implemented the interface. Here also, you must use the widening cast operator ‘?=’ when you want to assign a reference to interface to a class reference that has implemented the interface.

10.  Thou shall not be lazy nor shall thou give a tough time to thy fellow programmers in comprehending and enhancing the work of thy hands.

• Write proper Documentation, so that any programmer who reads your program can easily understand what has been done. Insert comments at suitable points.

• Use proper indentation. Make use of the Pretty Printer function to make your code look good.

• Avoid hard coding literals, instead use constants. Will be easier for maintenance.

• Understand the ABAP Debugger and efficiently use it after you are done with the program.
  • Static Analysis (Extended program check)

Example, for PERFORM / FORM

• Checks that the called FORM exists
• Checks that the number of actual and formal parameters matches
• Checks that the parameter categories (USING, CHANGING, TABLES) match
• Checks types
• Checks whether a literal is called in a structured parameter or in the category CHANGING
• Checks whether a FORM is called
• Lists un-typed FORM parameters
• Dynamic Analysis
  • ABAP/4 Run-time analysis
    • Tools-> ABAP/4 workbench ->Test->Runtime analysis (TCODE SE30)
  • Hints and Tips (Execute report RSHOWTIM)
• Database Access
  • SQL (database) trace
    • Tools -> ABAP/4 workbench -> Test -> SQL trace (TCODE ST05)