ABAP Review Check List

This is a work in process. Please feel free to ask questions, make suggestions & correct misinformation!
Carolyn Fuller fuller@mit.edu

Mandatory Checks

Many of these checks can be done automatically by launching transaction ZUTALORS

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) = GT_
  3. Internal tables (local) = LT_
  4. Constants = GC_
  5. Constants (local) = LC_
  6. Ranges (global) = GR__
  7. Ranges (local) = LR_
  8. Form parameter (Used in the actual form not the Perform statement.)
    • Single value or variable = PV_
    • Single structure or record(however complicated) = PS_
    • Internal table(however complicated the line structure) = PT_
  9. Locally defined classes = LCL_
  10. Locally defined interfaces = LIF_
  11. Screen Parameters = A_ or P_

    Program & Function Group Names

  12. http://web.mit.edu/fss/dev/devstand5.html#ABAP Reports & Appendix B
  13. http://web.mit.edu/fss/dev/devstand5.html#Function Groups & Appendix B
  14. http://web.mit.edu/fss/dev/devstand5.html#Function Modules & Appendix B
  15. http://web.mit.edu/fss/dev/devstand5.html#Module Pools (Dialog Programs)

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

III. Attributes

  1. Authorization Group in attributes - Programs that can be executed by all MIT 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.
  3. Unicode Check Active is check-marked.

IV. Function Modules

  1. Function Module interface parameters
    • The first letter should indicate the direction in which the parameter was passed:
      Input or importing = I
      Output or exporting = E
      Bi-directional or changing = C
    • The second letter should indicate the nature of the formal parameter:
      Single value or variable = V
      Single structure or record(however complicated) = S
      Internal table(however complicated the line structure) = T
  2. Interface tables for a Function module should be defined as TYPE Table.

V. RFC for Web Applications

  1. Names within structures used in an RFC interface and parameter names should be in English and not German. (e.g., COMPANY_CODE not BUKRS)
  2. RFCs that perform searches on descriptive type text (e.g., Names or Description) must implement the IDD team's standard on how such searches should behave. This can be accomplished by utilizing the function module Z_UT_SPLIT_SEARCH_TERMS which builds a range table to be used in the select statement or table to be used in a string comparison. ( The IDD team's standard is documented http://userdocs.mit.edu/portal-nb/insidemitstandards/WebStandards/webSiteLandF/LandFSearch.html )
  3. No special conversions should be done on Date, Time, Integer or Decimal fields. JavaEE can and should handle all data types.
  4. Since SAP centric data rules can change via SAP configuration, data massaging should be done in the RFC and neither the end user nor the JavaEE developer should worry about SAP centric formatting. For instance, before a G/L Account is sent to the web leading zeros should be stripped. When it comes from the web and before it is used to update SAP the leading zeros should be put back. This includes fields that don't always have appropriate SAP exit routines such as Profit Center. Z_CA_CONVERT_PROFITCENTR_INPUT can be used to properly massage Profit Center data entered via web.
  5. When ABAP EXCEPTIONS are raised the default behavior in our web applications is to send the user to a "fail" page where the displayed message will include the EXCEPTION and the EXCEPTION short text. Therefore if a custom MIT RFC implements an EXCEPTION, the name and short text for the EXCEPTION should be informative (e.g., SAFO_AUTHORIZATION_ERROR: You are not authorized for any SAFO report). If the developers do not want the web application to send the user to the "fail" page, the RFC developer should either inform the Java developer that the exception should be handled with an exception handler or the RFC developer should use a BAPIRET2 structure to hold the error, its message and its variables.
  6. Use a table type of BAPIRET2 for building all error message tables (e.g., BAPIRET2_T). If another structure is used and it does not contain the same column names of interest (TYPE, MESSAGE, ID, NUMBER, MESSAGE_V1, MESSAGE_V2, MESSAGE_V3, MESSAGE_V4), the Java developer must be informed and special code will need to be written to handle the different structure.
  7. Since there are times an error message sent from an RFC must be overridden by the web application make sure all these BAPIRET2 fields are appropriately populated (TYPE, MESSAGE, ID, NUMBER, MESSAGE_V1, MESSAGE_V2, MESSAGE_V3, MESSAGE_V4).
  8. Since our web utility tool, mortar 4.10 & higher, will appear in all of our future SAP web applications and it is working with an error table named ET_RETURN, this name is a reserved name for error messages tables.
  9. If a developer uses a name for their errors other than ET_RETURN or ET_MESSAGES, they should tell the JavaEE developer so that the new name can be configured. Then this new name cannot be used for anything other than errors by any other RFC being called by that web application.
  10. If a developer uses the name ET_MESSAGES for anything other than error messages they should tell the JavaEE developer so that this name is removed from the application's default configuration.
  11. For performance reasons, IMPORT/EXPORT or CHANGE parameters should never be defined as TYPE table for RFCs.

VI. 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.)

VII. Transaction Code assigned to executable programs

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

VIII. 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).

IX. 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@mit.edu". This mail will go to Carolyn Fuller, David Rosenberg, Wai-ming Li, and Kevin Lyons for resolution.

X. Separate Dialog Program Includes

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

XI. Application and Database Performance

  1. Check each “select” statement for the use of index. This can be most easily determined using the Code Inspector, transaction SCI, which will report on any “select” statement against large tables not using as index.
  2. Check that there is no assumed sort order after the “select” statement. Do not assume that the data will be returned in primary key order.
  3. Code Inspector, transaction SCI, should be used to spot meaningful errors, but the reviewer should use judgment to filter out meaningless errors.

XII. 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. SORT and READ TABLE t_tab WITH KEY ... BINARY SEARCH 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 Performanc

  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. "FOR ALL ENTRIES IN..." (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 MIT-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.