11-03-2010 12:16 PM
Hi Experts,
Initial SItuation in Short:
I have modified the Standard Report RPCEDTX0 to our specifications for outputting an XML Stream (which is later processed to a PDF-Payslip). The Standard SAP List is not modified (also a specification) and is outputted normally. For our ESS scenario class CL_HRXSS_REM Method L_PRODUCE_FORM has been modified --> replaced BAPI_GET_PAYSLIP with a customer Function Module which SUBMITS the reactivates the Conversion to PDF and returns it to the Method L_PRODUCE_FORM.
My "Problem" is:
In my Customer Function Module, the Report RPCEDTX0 is submitted and generates its standard list which must not happen here; because there won't be any user interaction. I figured I could use submit as per
SUBMIT rpcedtd0 USING SELECTION-SET lv_var_name
WITH SELECTION-TABLE lt_rspar
EXPORTING LIST TO MEMORY
AND RETURN.
or as per
SUBMIT rpcedtd0 USING SELECTION-SET lv_var_name
WITH SELECTION-TABLE lt_rspar
TO SAP-SPOOL
WITHOUT SPOOL DYNPRO
AND RETURN.
to evade getting the standard list displayed. But I wonder if it is a problem if I spam the Memory like that or created thousands of spools which I don't need/want, so..
Which is the most elegant way to let that standard List disappear via the "Submit" statement?
regards,
Lukas
11-03-2010 12:23 PM
Hi,
I think the below should be most elegant as the list written to memory will be erased after some time.(Garbage collection)
SUBMIT rpcedtd0 USING SELECTION-SET lv_var_name
WITH SELECTION-TABLE lt_rspar
EXPORTING LIST TO MEMORY
AND RETURN.
Regards,
Srini.
11-03-2010 12:36 PM
Thanks for the quick answer,
I kind of thought so as well. But I'm a little afraid of the memory used, because the pdf I'm creating is the PDF for the ESS-Payslip. Once a months about 25.000 people will say "Oh Jolly, let's have a look at my payslip shall we"; meaning 25.000 times export into memory, probably on the same day/in the same hour in a worst case scenario.
Would there be a way to pointedly delete/free the allocated space of the abap memory?
Regards,
Lukas
02-09-2012 10:44 AM
Just cleaning up my old posts.
The interface is productive now and it didn't raze everything to the ground with a memory overflow. So that approach wasn't as dangerous as I thought in the first place 😛
Cheers, Lukas