The MIME Repository – A Consultant's Faithful Assistant

To be fair, it's not just for consultants—but also for developers working alongside them.

The MIME Repository is a standard storage location for different types of files used for various purposes.

See: MIME Repository MIME Repository Purpose The MIME Repository serves as storage for all MIME objects (for example, PDF files, images, ZIP files and so on) in a SAP system. The MIME objects are stored as development objects in the SAP database and are represented in the MIME Repository as a hierarchy of items and folders.

If you've ever developed Web Dynpro or BSP applications, you're likely familiar with the process of adding, for example, custom images to your apps.

See: MIME Repository
Features For each Web Dynpro ABAP or BSP application, the system automatically creates an identically-named folder in the MIME Repository, which stores only application-specific MIME objects. The folder /SAP/PUBLIC contains MIME objects that can be used by multiple software components:

- MIME objects accessible to all BSP applications are available at /SAP/BC/BSP/[namespace]/PUBLIC.

- MIME objects accessible to all Web Dynpro applications are available at /SAP/BC/WebDynpro/[namespace]/PUBLIC

Beyond images and documents, the repository can also store executable files (application/octet-stream).

See also:  Supported MIME Types

Now, imagine you're tasked with integrating your SAP system with some external device—perhaps connected locally to the user's workstation or available via a network resource. You need to fetch some data from this device and save it to the SAP system.

Direct access from SAP might not be possible. But you can use a small external utility. After being downloaded onto the user's local machine from SAP, it performs its task and then quietly exits. Something along those lines.

Here’s a potential implementation of such a scenario.

For this example, I’ll use a basic script written in Python:

You can access the MIME Repository via transaction SE80, under the corresponding section:

Select the directory where you’d like to store the files.

See also: Creating Folders

I’ll use the following path: SAP -> PUBLIC -> zdemo. Right-click the newly created folder and choose Import MIME Objects from the context menu:

Select the file to import and save it into the system. (In my case, I also had to acknowledge that the file type isn’t quite SAP-standard.)

No extra commentary here. Let's assume:

REPORT zmime_demo.
 
CONSTANTS:
  c_filename TYPE string VALUE 'test.py',
  mim_value  TYPE string VALUE 'zdemo'.
 
DATA:
  lo_api      TYPE REF TO if_mr_api,
  lv_mime     TYPE string,
  lv_xdata    TYPE xstring,
  lv_path     TYPE string,
  lv_fpath    TYPE string,
  lv_length   TYPE i,
  lt_file_tab TYPE solix_tab,
  iv_file     TYPE xstring.
 
PARAMETERS: p_run TYPE c1.
 
CASE p_run.
 
  WHEN 'Y'.
    CONCATENATE 'SAP/PUBLIC/zdemo/' c_filename INTO lv_mime.
    lv_path = 'C:\Temp'.
    CONCATENATE lv_path '\' mim_value '\' c_filename INTO lv_path.
 
    IF cl_gui_control=>gui_is_running IS INITIAL.
      " some message here...
      RETURN.
    ENDIF.
 
    lo_api = cl_mime_repository_api=>if_mr_api~get_api( ).
 
    CALL METHOD lo_api->get
      EXPORTING
        i_check_authority  = abap_false
        i_url              = lv_mime
      IMPORTING
        e_content          = lv_xdata
      EXCEPTIONS
        parameter_missing  = 1
        error_occured      = 2
        not_found          = 3
        permission_failure = 4
        OTHERS             = 5.
    IF sy-subrc <> 0.
      " message
      RETURN.
    ENDIF.
 
    iv_file = lv_xdata.
 
    CALL FUNCTION 'SCMS_XSTRING_TO_BINARY'
      EXPORTING
        buffer        = iv_file
      IMPORTING
        output_length = lv_length
      TABLES
        binary_tab    = lt_file_tab.
    IF lt_file_tab IS INITIAL OR lv_length <= 0.
      RETURN.
    ENDIF.
 
    CALL METHOD cl_gui_frontend_services=>gui_download
      EXPORTING
        filename                = lv_path
        filetype                = 'BIN'
        bin_filesize            = lv_length
      CHANGING
        data_tab                = lt_file_tab
      EXCEPTIONS
        file_write_error        = 1
        no_batch                = 2
        gui_refuse_filetransfer = 3
        invalid_type            = 4
        no_authority            = 5
        unknown_error           = 6
        header_not_allowed      = 7
        separator_not_allowed   = 8
        filesize_not_allowed    = 9
        header_too_long         = 10
        dp_error_create         = 11
        dp_error_send           = 12
        dp_error_write          = 13
        unknown_dp_error        = 14
        access_denied           = 15
        dp_out_of_memory        = 16
        disk_full               = 17
        dp_timeout              = 18
        file_not_found          = 19
        dataprovider_exception  = 20
        control_flush_error     = 21
        not_supported_by_gui    = 22
        error_no_gui            = 23
        OTHERS                  = 24.
    IF sy-subrc <> 0.
      RETURN.
    ENDIF.
 
    CALL METHOD cl_gui_frontend_services=>execute
      EXPORTING
        document               = lv_path
      EXCEPTIONS
        cntl_error             = 1
        error_no_gui           = 2
        bad_parameter          = 3
        file_not_found         = 4
        path_not_found         = 5
        file_extension_unknown = 6
        error_execute_failed   = 7
        synchronous_failed     = 8
        not_supported_by_gui   = 9
        OTHERS                 = 10.
    IF sy-subrc <> 0.
      RETURN.
    ENDIF.
  WHEN 'N'.
    WRITE:/ 'No external scripts here'.
 
ENDCASE.

The test consists of a few steps:

• Confirm that the target directory where the script should be downloaded is initially empty.
• Run the ABAP program with a parameter that prevents the script from being downloaded. Verify the behavior.
• Run the ABAP program with a parameter that causes the script to be downloaded and executed. Verify the behavior again.

As always, with love. Hugs, ignatov.