Versions Compared

Old Version 16

changes.mady.by.user Carolyn A Fuller

Saved on

compared with

New Version 17

changes.mady.by.user Carolyn A Fuller

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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_

...

  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.

...

  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.

...

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_

Strongly Recommended Practices

...