Page History

...

1. Processing Inbound Files to SAP
   1. SAP DROPBOX for the inbound data feeds from the MIT business partnersThe dropbox is the standard method for data providers 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.

...