Hello All,
I am having bit of a different requirement for SUBMIT program, please have a look on the below described requirement and please share if you have some other idea about how we can go ahead with it.
An idea about developed reports
I am having two different SE38 executable reports, already developed and working abs. fine. Say report ZREP1 and ZREP2. However-
1. ZREP1 is fetching all the details based on different selection set of parameters than ZREP2.
2. Both the reports are developed in OOPS approach. (Need not to mention as no specific need to say it explicitly).
3. ZREP1 and ZREP2 shares few common includes, which are basically the common business logic. (I mean most of the includes are common).
4. Both reports are showing the ALV list with few different columns. And with the same internal table (say GT_MASTER) only field catalog are different.
New Requirement
I need to create a new report ZREP3 with the common selection screen from ZREP1 and ZREP2 and with the more or less same ALV list.
In the new report's output I may need to add few more columns and delete few from existing one.
Different Solutions
In front of me there are 3 possible solutions as below -
Solution 1: I may start creating the fresh development and use the common includes as core business logic and start filling the GT_MASTER in ZREP3.
====> It may serve a purpose however the development cost would be so high to identify the common business logic as these programs are way too complicated.
Solution 2: I may start creating the fresh development with combined selection screen and passing it to the ZREP1 and ZREP2 based on selection screen and fetch their outputs (ALV) in memory. Here I can use below approach -
1. SUBMIT ZREP1 WITH XXXX EXPORTING LIST TO MEMORY AND RETURN.
OR
1. SUBMIT ZREP2 WITH XXXX EXPORTING LIST TO MEMORY AND RETURN.
2. Get the list output from Function Module LIST_FROM_MEMORY.
3. Converting it to list as an internal table by Function Module LIST_TO_ASCI.
====> By doing this I can get the list output in an internal table without even touching to the developed reports however I need to parse the list output again in ZREP3 as FM LIST_TO_ASCI will give me as string output.
Question: Can I get the LIST_TO_ASCI output as an internal table? I guess it's not possible.
Solution 3: I may start creating the fresh development with combined selection screen and passing it to the ZREP1 and ZREP2 based on selection screen and EXPORT the final internal table(GT_MASTER) to memory and read it in ZREP3 report and then manipulate it according to my requirement again.
1. SUBMIT ZREP1 WITH XXXX AND RETURN. (Here in ZREP1 I will EXPORT final table in memory)
OR
1. SUBMIT ZREP2 WITH XXXX AND RETURN. (Here in ZREP2 I will EXPORT final table in memory)
2. Import the GT_MASTER in ZREP3 and then manipulate it accordingly.
3. FREE memory ID, whatever is set by ZREP1 and ZREP2.
====> By doing this I can get data in an internal table directly however need to touch the existing developed reports.
Apologize for a big question - 
But my question is out of 3 solutions which one would be better to go with?
If there are any other solution on the requirement may possible?
What if the memory export is way too high? I mean the data is larger than expected what could be the performance issue?
If performance issue will arise how we can take care of it while our new development? Precaution is better than cure right 
I guess I have asked whatever I am brainstorming on ....
please suggest if u think of anything on this. Your anyway may lead to perfect solution on this.
thanks and regards,
Ravindra Sonar.