Page History

1. General Coding Standards

       Please follow the ABAP Review Check List

2. Interface: Processing Inbound & Outbound Files

1. Processing Inbound Files to SAP
   1. SAP DROPBOX for the inbound data 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 filename determinationprogram 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.
   

3. BAPI & User Exits

1. 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),
   and
   1.  
   2. Change the Application to "* Cross-Application".
   3. 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.

...