ABAP Review Check List

This is a work in process. Please feel free to ask questions, make suggestions & correct misinformation!
Siva Kumar at sthiagarajan@unicef.org

Mandatory Checks

I. Documentation

1. Program documentation
2. Function Module documentation
3. Include documentation
4. In source documentation
5. Beginning block of source code documentation

II. Naming Conventions

Variable Names

1. Selection options = s_
2. Internal tables (global) = t_
3. Internal tables (local) = lt_
4. Constants = c_
5. Ranges = r_
6. Form parameter = p_ (Used in the actual form not the Perform statement.)
7. Screen Parameters = a_ or p_

   Program & Function Group Names

8. UNICEF SAP development guidelines Appendix B (You need to log in to Unicef's intranet to get this document)
   

9. ABAP programs (reports), function groups and module pools all use a 2 character application name abbreviation. The list of current UNICEF applications will be maintained in Appendix B.

III. Attributes

1. Authorization Group in attributes - Programs that can be executed by all UNICEF users must be configured using the Authorization Group 'ZOPN2ALL' for Application '*'.
2. Development Class needs to be application specific. This standard is a work in process.

IV. Return Codes

1. Test return codes (sy-subrc) for success and failure after any I/O and calls to function modules (database selects, internal table reads, call transactions, I/O to UNIX or workstation files, etc)

V. Transaction Code assigned to executable programs

Every type "executable program" must have an assigned transaction code which is used to execute the program.

VI. Authorization Checks for HR custom programs

Methods to accomplish authorization checks for HR are illustrated below:

1. Use function module "HR_READ_INFOTYPE" instead of direct SELECT
statements when reading a specific infotype.

2. Use logical database PNP to leverage SAP authorizations (caveat:
performance can be slow)

3. SELECT statements should only be used when the SAP documented data
interfaces which incorporate the SAP authorization checks (Logical
DataBases, function modules, and BAPI's) cannot provide the functionality
required. If it is necessary to use SELECT's, then you must perform your
own AUTHORITY-CHECK on the data selected.

4. Place a strict authorization group at the program (transaction)
level. If a wide variety of data for a large group of individuals is
needed in a single program, then this program must have a very strict
authorization on who can run it (definitely not on any menu path).

VII. Parameter, P_BOUNCED_EMAIL, should be passed to Z_SENDMAIL

In order of preference, please provide one of the following for P_BOUNCED_EMAIL :

1. A mailing list of people from the business process side who can recognize and have the ability to resolve the issue of a bounced mail (e.g. CAO maintains a master email list of cost object approvers).
2. A mailing list of people from an Admin Computing support or project team who can resolve the bounced mail.
3. "sap-bounces.unicef@gmail.com". This mail will go to Siva Kumar, Amina Alavi and Victor Lee for resolution.

VIII. Separate Dialog Program Includes

1. PBO
2. PAI
3. Global data
4. Forms

IX. Standards

1. Development
2. Quality Assurance
3. Change Request

Strongly Recommended Practices

I. Non Database Performance

1. Dead Code (Program -> Check -> Extended Prog. Check) - unused subroutines appear as warnings under PERFORM/FORM interfaces. - unused variables appear as warnings under Field attributes. Transaction code is SLIN. This will also catch literals (section III below).
2. When possible use MOVE instead of MOVE-CORRESPONDING (move bseg to *bseg or move t_prps[] to t_prps2[] if you want to copy entire table or t_prps to t_prps2 if you only want to copy header line.)
3. Code executed more than once should be placed in a form routine.
4. http://docs.google.com/View?docID=dhs6z73_45f5r2q9fd&revision=_latest when possible especially against non-buffered table (Data Dictionary -> Technical Info)
5. SORT tables BY fields
6. Avoid unnecessary moves to table header areas.
7. Subroutine parameters should be typed for efficiency and to help prevent coding and runtime errors.

II. Database Performance

1. Avoid ORDER BY unless there is index on the columns - sort internal table instead
2. SELECT SINGLE when possible
3. SELECT fields FROM database table INTO TABLE t_tab (an internal table) - Lengthy discussion.
4. Views (inner join) are a fast way to access information from multiple tables. Be aware that the result set only includes rows that appear in both tables.
5. Use subqueries when possible.
6. "Sample Code" (outer join) are very fast but keep in the mind the special features and 3 pitfalls of using it.
   (a) Duplicates are removed from the answer set as if you had specified "SELECT DISTINCT"... So unless you intend for duplicates to be deleted include the unique key of the detail line items in your select statement. In the data dictionary (SE11) the fields belonging to the unique key are marked with an "X" in the key column.
   (b) If the "one" table (the table that appears in the clause FOR ALL ENTRIES IN) is empty, all rows in the "many" table (the table that appears in the SELECT INTO clause ) are selected. Therefore make sure you check that the "one" table has rows before issuing a select with the "FOR ALL ENTRIES IN..." clause.
   (c) If the 'one' table (the table that appears in the clause FOR ALL ENTRIES IN) is very large there is performance degradation Steven Buttiglieri created sample code to illustrate this.
7. Where clause should be in order of index See example.
   This is important when there are multiple indexes for a table and you want to make sure a specific index is used. This will change when we convert from a "rules based" Oracle optimizer to a "cost based" Oracle optimizer. You should be aware of a bug in Oracle, lovingly referred to as the "3rd Column Blues". Click here for more information on indexes.
8. Where clause should contain key fields in an appropriate db index or buffered tables. As long as we are using the Oracle Cost Based Optimizer, be aware fo the "Third Column Blues", an Oracle bug.
9. Avoid nested SELECTs (SELECT...ENDSELECT within another SELECT...ENDSELECT). Load data in internal tables instead. See item 3 above.
10. Use SQL statistical functions when possible (max, sum, ...)
11. Delete all rows from a table. A where clause is mandatory. Specifying the client is the most efficient way.
12. Put Check statements into where clause - caveat: Make sure that the index is still being used after you add the additional selection criteria. If the select statement goes from using an index to doing a db scan (reading each row in the database without going through an index) get it out of the where clause and go back to using "Check"!

III. Literals

1. Codes ('MD') should use contants (c_medical)
2. Longer text should use text elements. Sample code is a good example because it uses the text element in conjunction with the hard coded text. This documents the text element and provides for the possibility of multi-language support.

IV. Miscellaneous

1. Use CASE statement instead of IF...ELSEIF when possible (It is only possible in equality tests)
2. Nested If - encounter most likely to fail first (specific to general)
3. And - encounter most likely to fail first (specific to general)
4. OR's - encounter most likely to succeed first (general to specific)
5. Variables should use Like when possible
6. Subroutine usage - don't place decision to execute in the subroutine
7. If not ( t_prps[] is initial ) (instead of describe table t_prps lines sy-tfill, if sy-tfill > 0...)
8. New document types confirmed with the configuration team via UNICEF-ABAP mail list prior to coding a report to access the data.
9. Dates need to be properly formatted using the user's default settings. For the explanation of the BDC example check out the developer's standards.

Function Module documentation

ZFUNCDOC

REPORT ZFUNCDOC.
************************************************************************
*  INSTRUCTIONS FOR COPYING DOCUMENTATION TEMPLATE                     *
************************************************************************
*1) SELECT THE ENTIRE TEMPLATE BY PLACING THE CURSOR IN THE FIRST
*   COLUMN double clicking three times on the Select button.
*
*2) SELECT COPY.
*
*3) GO TO THE FUNCTION YOU ARE DOCUMENTING. SELECT DOCUMENTATION AND
*   CHANGE. PRESS BUTTON 'FUNCTION MOD. DOC F9'.The documentation window
*   appears, showing the SAP default documentation
*
*4) DELETE THE DEFAULT TEXT. PASTE THE TEMPLATE INTO THE WINDOW USING
*   PASTE. The template and text formatting tags appear.
*
***************** TIPS FOR ENTERING INFORMATION ************************
*
* IF YOU WANT TO AVOID ACCIDENTALLY DELETING FORMATTING TAGS, START EACH
* LINE of your documentation on a new line.
*
* At the end of each line you type, press return; otherwise, your text
* will spill into the first column, which is used only for paragraph
* formatting.
*
************************************************************************
*                         END OF INSTRUCTIONS                          *
************************************************************************

 Include  documentation

ZDOCUINM

************************************************************************
** INSTRUCTIONS FOR COPYING DOCUMENTATION TEMPLATE **
************************************************************************
* Updated on 05/27/2007. *
************************************************************************
*1- Place cursor beneath the INCLUDE comment.
*2- Click on the Pattern soft button.
*3- Select the "Other pattern" radio button.
*4- Enter ZDOCUINM in the search box beneath this button.
*5- Follow instructions in the pattern copied to your program (below).
************************************************************************
************************************************************************
* Instructions: 1. When inserting this template in your source code,
* please replace only the angle brackets and the text
* between them.
* 2. If it is not applicable simply enter N/A.
* 3. If you need more space, use additional lines starting
* with an asterisk ONLY and kindly indent. Thanks!
* 4. Lastly, remove these instructions from your include
* documentation block. Thanks!
************************************************************************
*^ Written By : <Author>
*^ Date Written : <Date>
*^ Include Name : <Name of the include>
*^ Used in Programs: <Programs referencing this include>
*^ System Name : <System name/application area>
*^ Purpose : <Form routines, PAI/PBO modules, data declarations>
* <Kindly indent subsequent lines>
*^ Other Considerations: <anything else a developer might find helpful>
**--------------------------------------------------------------------**
*^ Maintenance History (latest on top)
*
*^ Date: <MM/DD/YY> Author: <USERID> Transport: <Transport #>
*^ Description of Change:
*
************************************************************************