Hi,
I analyzed the coding and I see that the package size is correctly used. I don't have a direct explanation why in delta mode it runs into memory problems.
As far as I can understand the logic I see that table VFKP (Shipment Costs: Item Data) is used for the packaging. Here the field KNUMV (Number of the document condition) is read for the selected records and used in a next step to select data from table KONV (Conditions (Transaction Data)) with a FOR ALL ENTRIES IN i_vfkp_data WHERE knumv = i_vfkp_data-knumv.
It might be that here an issue can occur. You have to be very careful with FOR ALL ENTRIES IN. You should only use it with a list of distinct values of KNUMV. I cannot judge if this is the case.
To come to a list of distinct values, you can introduce a second "for all entries" table as a copy of the other internal table. Here you sort the records on KNUMV. Then you delete adjacent duplicates from this "for all entries" table. This "for all entries" table is then used in the SELECT statement on KONV.
Secondly, I cannot judge how the data in table KONV is related to VFKP. I.e. how many KONV records can be expected for one KFKP record. If this is e.g. 10 KONV records for 1 VFKP record, then indirectly you can have a package size with is 10 times higher (10 x 50,000 = 500,000).
As a temporary workaround I suggest to reduce the package size hard-coded as follows:
* Fill parameter buffer for data extraction calls
s_s_if-requnr = i_requnr.
s_s_if-dsource = i_dsource.
* s_s_if-maxsize = i_maxsize. "temporary work-around
s_s_if-maxsize = 10000. "temporary work-around
Now you can check if the delta mode can handle the memory consumption.
Also try debugging in delta mode. I don't know if that can be done using t/code RSA3 or that you have to go for a more difficult background process debugging.
Last but not least, please have a look at document Functional Module Based Delta Enabled Generic Datasource which can perhaps serve as reference material.
Best regards,
Sander