Skip to Content
Technical Articles
Author's profile photo Alex Muthu Nadar

Excel Mass Upload in Background Job Using SHMA – Part 1: Create a Custom Shared Memory Area


Intent of this blog post series is to provide a working prototype, ‘to mass upload excel data in SAP in Background/Foreground using SHMA’, which will we covered in 3 Parts.

Business Requirement

To have a Program to upload more than 10k records in SAP using excel file both in Web GUI as well SAP GUI in Background as well as in Foreground. We have a limitation of no access to application server(AL11).


Till now there is no known FM which can be used to upload an Excel File and execute in Background. Since we have a limitation, that we cannot access AL11 Application server to upload files.

To Overcome this limitation. We can use SHMA as an alternative to AL11 Application server.

In this Approach, whenever the Mass Upload Program is performed in Background Mode, we will pull data from Excel file and store it in SHMA and schedule a Background Job, which will read data from SHMA and perform Mass upload.

To carter the above requirement, we will divide the solution in 3 sections which will be covered in 3 blog parts.

  • Part 1: Create a Custom Shared Memory Area.
  • Part 2: Create a ALV Report for Mass Upload Program.
  • Part 3: Demo Foreground/Background upload.

Let proceed with Part 1: Create a Custom Shared Memory Area.

Before proceeding with any section, lets make a custom table which will serve as an example for uploading mass data.

Table for Mass Upload

Section 1

Before creating a custom Shared Memory Area we need to be familiar with Shared Memory & its concepts in ABAP.

we will be creating Shared Memory Area & Class using the following blog post Shared Memory-enabled Classes and Create Data – Area Handle where in all the steps are explained in quite detailed.

Step 1: Creating a Shared Memory Area Class in SE24 and tick the check box “Shared Memory Enabled”.


Class Properties

Step 2: Add interface “IF_SHM_BUILD_INSTANCE” in the interfaces section of class


Class Interface

Step 3: Create a type and table type using the following code, which will be used later.

    TYPES: BEGIN OF gty_mat_upload,
             id          TYPE ymass_upload-id,
             description TYPE ymass_upload-description,
             quantity    TYPE ymass_upload-quantity,
             unit        TYPE ymass_upload-unit,
           END OF gty_mat_upload .

    TYPES: gtt_mat_upload TYPE STANDARD TABLE OF gty_mat_upload.

now your Class will look like this.


Class Types

Step 4: Add the following Class Attributes.


Class Attributes

Step 5: Create Set-Get Methods in the class.


Class Methods


Set Method Signature


Get Method Signature

Step 6: Update Set-Get Methods using below codes, we will update BUILD method once we have created the Shared Memory Area.

  METHOD set_data.
    gv_jobname = iv_jobname.
    gv_jobcount = iv_jobcount.
    gv_file = iv_file.
    gt_mat_upload = it_mat_upload.

  METHOD get_data.
    ev_jobname = gv_jobname.
    ev_jobcount = gv_jobcount.
    ev_file = gv_file.
    et_mat_upload = gt_mat_upload.

Now, are ready with the root class which is required to create the Shared Memory Area.

Step 7: Create Shared Memory Area using T-Code SHMA, Enter suitable name and click on create as shown below.


Create SHMA

Step 8: Update the Root Class & Constructor class as above created class and properties as shown below and save it.


SHMA Attributes 1


SHMA Attributes 2

Now our Shared Memory Area is created, now lets update the BUILD method in the root class.

Step 9: Update method BUILD with the following code lines.

  METHOD if_shm_build_instance~build.
    DATA:lo_area  TYPE REF TO ycl_mass_upload_shma_area,
         lo_root  TYPE REF TO ycl_mass_upload_shma,
         lo_excep TYPE REF TO cx_root.

    DATA:lv_file       TYPE  char200,
         lt_mat_upload TYPE gtt_mat_upload,
         lv_jobname    TYPE tbtcjob-jobname,
         lv_jobcount   TYPE tbtcjob-jobcount.

        lo_area = ycl_mass_upload_shma_area=>attach_for_write( ).

      CATCH cx_shm_error INTO lo_excep.
        RAISE EXCEPTION TYPE cx_shm_build_failed
            previous = lo_excep.

    CREATE OBJECT lo_root AREA HANDLE lo_area.

        iv_jobname    = lv_jobname                      " Background job name
        iv_jobcount   = lv_jobcount                     " Job ID
        iv_file       = lv_file                         " Text field length 200
        it_mat_upload = lt_mat_upload                   " Mat Mass upload Table Type

    lo_area->set_root( lo_root ).

    lo_area->detach_commit( ).

Now, we are ready with the Shared Memory Area.


Part 2: Create a ALV Report for Mass Upload Program

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Matthew Billingham
      Matthew Billingham

      Why do you have no access to the application server?


      Author's profile photo Alex Muthu Nadar
      Alex Muthu Nadar
      Blog Post Author

      Project restriction: not to use application server.

      Author's profile photo Matthew Billingham
      Matthew Billingham

      Wow. In 25 years I've never heard of a project with that restriction.

      Author's profile photo Alex Muthu Nadar
      Alex Muthu Nadar
      Blog Post Author

      That is the main reason I had to look for an alternative & I arrived here, otherwise I myself would have gone with application server.

      Author's profile photo Matthew Billingham
      Matthew Billingham

      Writing to the appserver does seem a more sane approach. But seem my comment on part 3. I think there's a fundemental issue you haven't addressed.

      Author's profile photo Alex Muthu Nadar
      Alex Muthu Nadar
      Blog Post Author

      That issue is already addressed in part 2.

      Author's profile photo Matthew Billingham
      Matthew Billingham

      So it is. I'd still use a database table as my persistance layer.

      Author's profile photo Marc Bernard
      Marc Bernard

      Hi Alex,

      thanks for sharing and explaining your approach. It's a "fancy", technical solution and it sounds like it's working well for your case.

      I have some questions about your requirements. When I read "Mass", I'm thinking at least hundreds or thousands of files and millions of records at a time and several parallel users. You mention "more than 10k records". That hardly qualifies as "Mass". Why do you need background processing or temporarily storing the Excel data?

      If it's really a lot more files, data, or users, then any solution must scale properly. Memory is limited and can be a precious resource for SAP systems (at least set a limit in the SHMA attributes). Why do you need to use memory for keeping this data?

      Shared memory is temporary. What if the app server goes down after files were loaded but not processed yet?

      Clarifying some of these items will help us understand better why you implemented it this way.