You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

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 & Interface Parameter & 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. Simple variables (global) = GV_
  9. Simple variables (local) = LV_
  10. Structures (global) = GS_
  11. Structures (local) = LS_
  12. Object references (global) = GO_
  13. Object references (local) = LO_
  14. Exception class reference (global) = GX_
  15. Exception class reference (local) = LX_
  16. 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_
    • Object reference = PO_
    • Exception class reference = PX_
  17. Class Method, Web Dynpro Method or Function Module parameters
    • Import simple variable = IV_
    • Import structure = IS_
    • Import table = IT_
    • Import object reference = IO_
    • Import exception class reference = IX_
    • Export simple variable = EV_
    • Export structure = ES_
    • Export table = ET_
    • Export object reference = EO_
    • Export exception class reference = EX_
    • Changing simple variable = CV_
    • Changing structure = CS_
    • Changing table = CT_
    • Changing object reference = CO_
    • Changing exception class reference = CX_
    • Returning simple variable = RV_
    • Returning structure = RS_
    • Returning table = RT_
    • Returning object reference = RO_
    • Returning exception class reference = RX_
  18. Locally defined classes = LCL_
  19. Locally defined interfaces = LIF_
  20. Locally defined exception classes = LCX_
  21. Screen Parameters = A_ or P_

Program & Function Group Names

Below XX is the application area found in the custom table, ZCA_ABBR
  1. Report Programs, Web Dynpro Components, Enhancements, Function Groups = ZXX (if one time program YXX)
  2. Function Modules = Z_XX
  3. Module Pools = SAPMZXXn (n = sequential number 0 - 9)
  4. Web Dynpro Application = ZXX<name>_APP
  5. Class = ZCL_XX
  6. Exception Class = ZCX_XX
  7. Assistance Class = ZCL_XX<name>_ASSIST
  8. Interface = ZIF_XX

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 the custom table ZCA_ABBR..

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. 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://mv.ezproxy.com.ezproxyberklee.flo.org/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.

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

VI. Transaction Code assigned to executable programs

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

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

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

IX. Separate Dialog Program Includes

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

X. 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.

XI. Standards

  1. Development
  2. Quality Assurance
  3. Change Request

XII. Naning Conventions - Webdynpro View UI Elements in Layout

  1. button BTN_
  2. caption CAPTION_
  3. checkBox CB_
  4. checkBoxGroup CBG_
  5. dropDownByIndex DDBI_
  6. dropDownByKey DDBY_
  7. fileDownload FD_
  8. fileUpload FU_
  9. group GR_
  10. inputField IF_
  11. inputField readOnly IFR_
  12. itemListBox ILB_
  13. image IMG_
  14. label LB_
  15. pageHeader PH_
  16. radioButton RB_
  17. radioButtonIndex RBGI_
  18. radioButtonKey RBGK_
  19. tab T_
  20. table TBL_
  21. tablePopin TBLP_
  22. tableColumn TBLC_
  23. tableCellEditor TBLCE_
  24. tablePopinToggleCell TBLPTC_
  25. treeItemType TIT_
  26. treeItemNode TNT_
  27. tree TR_
  28. tabStrip TS_
  29. triStateCheckBox TSCB_
  30. textView TV_
  31. Tray TRAY_
  32. LinkToURL URL_
  33. viewContainerUIElement VC_

XIII. Naming Conventions - Webdynpro - other objects

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 andREAD 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. SELECTSINGLE when possible
  3. SELECTfieldsFROMdatabase table INTO TABLE t_tab (an internaltable) - 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 containkeyfields in an appropriatedb index or bufferedtables. 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. PutCheckstatements 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.
  • No labels