1. General Coding Standards

       ABAP Review Check List

2. Interface: Processing Inbound & Outbound Files

  1. Processing Inbound Files to SAP
    1. SAP DROPBOX for the inbound feeds from the MIT business partners
      The dropbox is the standard method for MIT business partners to automatically deliver files created outside of SAP as feeds into MIT's SAP R/3 environments. Data providers must be registered with the dropbox. These providers FTP data files to the dropbox. Based on a combination of file naming conventions and registered dropbox userids, the files are automatically delivered to the appropriate MIT SAP R/3 environment. For more information on, please read the MIT SAP Dropbox
    2. What SAP application programmers do to process inbound files
      1. Call Z_UT_START_OF_OUTBOUND with the (4-char) provider and the (3-char) feed code to obtain the pathname of your output file.
      2. Call Z_UT_START_OF_INBOUND with the file name (from Z_UT_GET_INPUT_FILE_NAME).
      3. Read & process the input file.
      4. Call Z_UT_END_OF_INBOUND when finished.
      5. For more information on file_mgmt_inbound
    3. Inbound interface file name determinationWhen an inbound interface program is initiated by triggering an SAP event, the filename is sent as an event parameter which should then be read by the interface program. An example of using this triggering and parameter passing method is outlined in program ZDMR0036 (in development system SF2).
  2. Processing Outbound Files to the MIT business partners
    1. What SAP application programmers do to process outbound files
      1. Call Z_UT_START_OF_OUTBOUND with the (4-char) provider and the (3-char) feed code to obtain the pathname of your output file.
      2. Do your processing, write the output file and accummulate control totals.
      3. Call Z_UT_END_OF_OUTBOUND with the key (in the ZJOBRUN2 table) for the output file and the contents of the control record.
      4. For more information on file_mgmt_outbound
  3. Tracking job status using ZJOBRUN2Many programs read input files or produce extracts from the R/3 and require detailed tracking data file names and error statuses (beyond the capability of the standard R/3 job scheduler). Even if the program doesn't need to keep track of file numbers or status, there are other reasons that a program might need to preserve some status information from one run of the program to the next. It also might be necessary to record some status information for easy access by a human being. To provide a common repository for job status, the ZJOBRUN2 table was created. All programs that need to track job status should read / write records to / from this table. New programs must not use text files outside of the R/3 system or other custom tables for this purpose. Programs that currently use methods other than the ZJOBRUN2 table to track status should be modified to use ZJOBRUN2 instead.
    NOTE: ZJOBRUN2 is an new and improved version of the original ZJOBRUN table. The original table is still in use by older programs but should no longer be used for developing new programs.

3. SAP Enhancement Switch Framework & User Exits

     Please use the following reference link for now(this session will be updated):

       Using the Enhancement Builder

4. Making Programs Obsolete

     Steps to make a program obsolete:

  1. Verify that the program is not referenced by any other programs, transactions or dialog modules that are not obsolete in either the production or development environments. If it is, notify the person who requested the program to be made obsolete and stop here.
  2. Reconcile the development version with the production version, and revert development to the same version as production if it is different. (Use the Version Management function to do this). Make sure that the retrieved version can be generated without errors. If there are errors - return back to the original active version.
  3. If you have to go back to the previous version, make sure that any active development of an object in unreleased requests/transports is saved by releasing the request/transport.
  4. If the program is not a function module, go to transaction SE38, and put in the program name which is to be made obsolete.
    1. Click on Attributes, and then click on "Change". Change the title of the program to start with the word "Obsolete".
    2. Change the Authorization Group to "ZINACTV0" (the last character is the digit ZERO), 
    3. Change the Application to "* Cross-Application".
    4. Attempt to change the Development Class to "ZZZ0" (the last character is the digit ZERO). If you have problems changing the development class, go back to the ABAP editor initial screen. Click on "Goto" at the top of the screen, and then click on "Object Directory entry" on the dropdown. Make the change and save.
  5. Send all the information about the program (including by whom & when it was determined that this program is obsolete) to sap-obsolete-progs@mit.edu. Please be sure to send your e-mail before releasing the program from SF2.
  6. Transport the changes made to SF5 and Production.

     Since SAP doesn't let us change the authorization group for one function module, follow the six steps below to make a function module obsolete:

     4a. Under ATTRIBUTES tab, change the short text (i.e. one line description) of the function module to start with the word "Obsolete".

     4b. Use the editor function to make all the source code lines of the function module into comments.

           (On the PC version of the ABAP editor, you can use Control-A to select all the code and Control-< to make all the selected code into comments.

            On the Mac, click on the first line of code, then click on the Select icon, then click on the last line of code, then click on the Select icon to select all the code.

            Then select the menu item

                 Utilities -> Block/buffer -> Insert comment*

            to make all the selected code into comments.)

            * NOTE: you cannot comment out the key lines Function/Endfunction.

      4c. Insert a comment at the top of the function module source code stating that the function module is now obsolete.

      4d. Put the following ABAP statement in the source code in order to force a short dump should someone try to execute the function module:

            MESSAGE ID 'ZZ' TYPE 'X' NUMBER '132' WITH 'Function module'
                '<name of function module>'.

      4e. Use the ABAP Workbench command to mark the function module as obsolete.

            (Go to SE37, type in the function module name and click on the "change" button. Go to the "Attributes" tab. Select the menu item:

            Function module -> Release -> Object obsolete

      Here is an example showing steps 4b, 4c & 4d:

      FUNCTION Z_INSERT_TR_ACCOUNT .
     ****** This function module is OBSOLETE ********

      MESSAGE ID 'ZZ' TYPE 'X' NUMBER '132' WITH
     'Function module' 'Z_INSERT_TR_ACCOUNT'.

*      **"---------------------------------------------------------------------*
     *
     *""Update function module:
     *"*
     *""Local interface:
     *" IMPORTING*
     *" VALUE(TRAV_ACC) LIKE ZTRV1 STRUCTURE ZTRV1*
     *" EXCEPTIONS*
     *" INSERT_ERROR*
     *"---------------------------------------------------------------------*
     *
     *
     * MOVE-CORRESPONDING TRAV_ACC TO ZTRV1.
     * INSERT ZTRV1.
     * IF SY-SUBRC <> 0.
     * RAISE INSERT_ERROR.
     * ENDIF.
     ENDFUNCTION.

  • No labels