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.
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.
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”.
Step 2: Add interface “IF_SHM_BUILD_INSTANCE” in the interfaces section of class
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.
Step 4: Add the following Class Attributes.
Step 5: Create Set-Get Methods in the class.
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. ENDMETHOD. METHOD get_data. ev_jobname = gv_jobname. ev_jobcount = gv_jobcount. ev_file = gv_file. et_mat_upload = gt_mat_upload. ENDMETHOD.
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.
Step 8: Update the Root Class & Constructor class as above created class and properties as shown below and save it.
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. TRY. lo_area = ycl_mass_upload_shma_area=>attach_for_write( ). CATCH cx_shm_error INTO lo_excep. RAISE EXCEPTION TYPE cx_shm_build_failed EXPORTING previous = lo_excep. ENDTRY. CREATE OBJECT lo_root AREA HANDLE lo_area. lo_root->set_data( EXPORTING 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( ). ENDMETHOD.
Now, we are ready with the Shared Memory Area.
Why do you have no access to the application server?
Project restriction: not to use application server.
Wow. In 25 years I've never heard of a project with that restriction.
That is the main reason I had to look for an alternative & I arrived here, otherwise I myself would have gone with application server.
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.
That issue is already addressed in part 2.
So it is. I'd still use a database table as my persistance layer.