Some Tips to avoid potential/hidden bugs in programs.

[Former Member]

Hello All,

Most of the times, bugs, small issues become very critical issues leading to big impact to the business once when a project is gone live or when some change requests are moved to production, once the user starts using the new system. Identifying these hidden bugs,potential bugs sometimes becomes very difficult since some scenarios which needs to be tested are not there in other non-production environment(cannot be replicated) due to various reasons like configurations, necessary test data not available, sometimes all possible testing done in non-production environment and working fine, but when same functionality moved to production and used by user, it results in short-dump, functionality not working as expected, etc. Hence it is very important as an ABAPer, to think on various approaches while coding or implementing the logic using appropriate ABAP statements, understanding the working of different ABAP statements and how the program flow happens or execution flow.

  Hence , I would like to share my knowledge on various things which we need to analyze while implementing the logic in new programs, or any changes to the existing custom and standard programs. This will avoid potential/hidden bugs found in the program at a later stage.Some of them are as follows:

1. Use the language key in WHERE clause in Select Query while picking data from Text tables: When picking up the data from Text tables, for example, while picking up data from database table MAKT for material description, the language key(SPRAS) should be passed in where clause.Most of the times, it is missed when this query is used in many places of a big program. Not passing the language key, results in picking up first entry from table,which is the correct material description,but not in the required language as required by the user.

2. Using of READ TABLE ITAB INTO ...INDEX 1 in a user exit or a generated program or custom include used in the standard program.

This is one of the big mistake done in using the READ statement. The user exit or include where you have written the READ statement with INDEX 1 might be called multiple times and ITAB will have more than one entry getting populated or values getting deleted every time the include is called.Using the INDEX 1, might result in reading the same first record of the table every time and might lead to an issue and logic being not implemented properly. Thus it is very important to analyze and understand how this table is getting populated. Instead of using INDEX 1, try to pass required key field in the READ statement,

i.e. READ TABLE ITAB INTO .. WITH KEY matnr = head-matnr.

3. Usage of correct BAPI in programs: The functionality of a BAPI is similar to a transaction. While using a BAPI in the program, proper analysis should be done to understand the complete functionality of it. Once when the BAPI does the functionality of what is required is achieved, we start using it, which is a big mistake. Some BAPIs will internally call different BAPIs for additional functionalities. These functionalities might be add-ons and need not be required for the user. It can be also the vice-versa, the subset of parent BAPI will alone implement our requirements. Hence, it is not needed to use the parent BAPi instead of using the subset of BAPI. So, analyze and test the functionality in standalone and understand before actually using the BAPI in your program.

4. Use of FMs for date calculations:  Most of the times, date calculations and conversions in programs are done using normal ABAP statements instead of using FMs which are available ready made for date calculations, date conversions, etc. with exception handling. This results in short dump or functionality not working. It might a silly mistake :sad: , but would cost a lot when such changes are moved to production. Hence FMs should be used instead of using statements like CONCATENATE etc.

For example, for calculating the date 2 months before current date, direct subtraction was done using normal ABAP statement:

            Say the current date is 04/02/2013 (sy-datum - 20130204)

          month = sy-datum+4(2) - 0002.                                           " result ----month = 0                                                

          CONCATENATE sy-datum+6(2) '/' month '/' sy-datum+0(4) INTO pdate. 

          Result:  pdate = 04/00/2013 - which is an invalid date.

- will result in date becoming 04/00/2013 - which is invalid date, which when used in next step or later might result in functionality not working, or even run-time error will occur if the date is used in the where clause of Select query.

Instead use FM BKK_ADD_MONTH_TO_DATE for the same, which will give proper result.

CALL FUNCTION 'BKK_ADD_MONTH_TO_DATE'

     EXPORTING

       months  = c_2      "-2

       olddate = sy-datum

     IMPORTING

                               newdate = p_date.          --------------result ---- pdate = 04/12/2012 - which is Valid date.

This is a very simple example, but there might be very complex calculations required for date, day,month,year calculations in some cases,hence it is best to use Function Modules.

5. Use of FMs Conversion alpha exits/ conversions of key fields like material number,sales order number before using in select queries:

Sometimes in module pool programs, when input is provided without preceding zeros, when conversion to internal format is not done before querying to the table, it might result in record not found for fields like material number or sales order number or maybe any field. Hence using the FM Conversion Alpha exit input, the input needs to be converted to internal format, i.e. populate preceding zeros in them and then pass it to select query.

Note : This blog is only for beginners. Most of the sometimes, the beginners forget or don't bother to go through the code inspector or the consistency checks,once the development or code changes are done. Hence  thought of sharing the same.

Thanks!