Submit report with different requirement

[former_member214878]

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.

[former_member214878]

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.

[Former Member]

Hi Ravindra,

Option 3 is better to use, that will avoid converting the list to internal table and so on. This looks simpler!

[kesavadas_thekkillath]

Few hints from my side,check for the possiblities.

Have a look at

F1 help for "INCLUDE SELECTION SCREEN"

🙂

[former_member214878]

Hello Kesavdas,

That's an amazing solution. I think I would be going with this solution only. As I will need no modification to my any already developed reports at all.

However I just saw those methods, and got to know that I will be getting those into <FIELD-SYMBOLS>, my question is how I can be building an internal table based on the same?

I may need to have metadata = abap_true, but how it will be coded?

do u have any idea on how can I get the internal table?

also even if I know the structure in calling program how can I take a help of cl_salv_bs_runtime_info=>get_data    insted of cl_salv_bs_runtime_info=>get_data_ref.

Please have a look.

Thanks and Regards,

Ravindra Sonar.

[kesavadas_thekkillath]

I am not sure what you exactly need.

You have already mentioned that you only need to add few fields in the new program which do not exists in prg1 and prg2.

Get the data as mentioned in the blog.  "ASSIGN lr_pay_data->* TO <lt_pay_data>.

<lt_pay_data> will be holding the data.

there is also one more parameter in method get_data_ref., it is R_DATA_LINE whichi provides the reference of the line type.

field-symbols:<fs_line> type any.

assign R_DATA_LINE->* to <fs_line>.

loop at <lt_pay_data> assigning <fs_line>

move-corresponding <fs_line> to wa_new.

"Your code for new fields here

append wa_new to it_new.

endloop.

Hope this helps.

If you need the metadata of the ALV displayed then you will have ti use method GET_METADATA, from which you will get the field catalouge, you can also create a dyn table using fcat.

[former_member214878]

Hello Kesavadas,

I think I was not clear enough while explaining my question.

Okay in CALLED program there is an internal table responsible for displaying the ALV list. However there is another ALV is getting displayed on double clicking on any line item.

Say MASTER_TAB is for Main ALV and CHLID_TAB table is for secondary list.

I can easily get the MASTER_TAB by GET_DATA_REF/GET_DATA however the another internal table CHILD_TAB were not.

May be I can understand that by cl_salv_bs_runtime_info I will never be able to get other internal tables used in the programs for say child ALV display or for other purposes.

I just want to know whether I can get a hold on CHILD_TAB by any means? Using any other possible way? As this is already been created in CALLED program???

I hope I am clear now.

Hope to see your reply.

Thanks and Regards,

Ravindra Sonar

[kesavadas_thekkillath]

Well, now this is out of scope 😉

I do not have any idea how to get the secondary list data into the calling program. May be you could incorporate the logic into your program.

[former_member214878]

ha ha ha

Yes, its really not worth to even think of it

the only option is to EXPORT that damn CHILD_TAB into memory.

Anyway, thanks for the new way of implementing it

[Former Member]

Hi Ravindra,

Solution 3 will be a good for this issue.

Reasons :-

• Performance-wise it will be fast
• Can handle both the reports explicitly
• There is no need to change the main reports, You can add up fields on the third report only.

Regards,

Gourav

[guilherme_frisoni]

Hi,

I've already did something like this:

" Vars

DATA: gt_abaplist TYPE TABLE OF abaplist,

      gt_list     TYPE TABLE OF string,

      gt_sflight  TYPE TABLE OF sflight.

START-OF-SELECTION.

  " Call ALV report

  SUBMIT bcalv_grid_01 EXPORTING LIST TO MEMORY

    AND RETURN.

" Get from memory

  CALL FUNCTION 'LIST_FROM_MEMORY'

    TABLES

      listobject = gt_abaplist

    EXCEPTIONS

      not_found  = 1

      OTHERS     = 2.

  CHECK sy-subrc IS INITIAL.

  " Convert to ASCI

  CALL FUNCTION 'LIST_TO_ASCI'

    IMPORTING

      list_string_ascii  = gt_list

    TABLES

      listobject         = gt_abaplist

    EXCEPTIONS

      empty_list         = 1

      list_index_invalid = 2

      OTHERS             = 3.

  CALL FUNCTION 'Z_PROCESS_LIST'

    EXPORTING

      i_structure     = 'SFLIGHT'

      i_string_list   = gt_list

    TABLES

      gen_table       = gt_sflight

    EXCEPTIONS

      structure_error = 1

      OTHERS          = 2.

I'm attaching Z_PROCESS_LIST FM. I've done this one to parse a list to a table.

Hope it helps,

Guilherme Frisoni

[former_member214878]

Hello Guilherme,

I am so glad to see your reply, your FM z_process_list is working amazingly perfect

However I happen to see Kesavadas's post and there wont be actually need to have this big development at all.

Using CL_SALV_BS_RUNTIME_INFO as suggested in
http://scn.sap.com/community/abap/blog/2011/07/07/gain-programmatic-access-to-data-of-sapgui-alv-rep... need no extra coding.

Unfortunately I am not going with "EXPORTING LIST TO MEMORY"  anymore and will never even think of it in future, as CLASS is giving more sophistical way to get a hold on data from CALLED program, with very less development cost to me. 

Can you spare some time on my question asked to Kesavadas to get a hold on other data in a called program. It would be good if you could just spread some light if u can.

Anyway thanks for the help/

Regards,

Ravindra Sonar

[guilherme_frisoni]

Hi Ravindra,

I think CHILD_TAB will always be empty, and when you click in some line you populate only lines that you need in table CHILD_TAB to show in ALV.

So, you can try to find in standard program which internal table has all child lines. Maybe you can include an enhancement in standard program to export this table to memory and import in your program.

Regards,

Guilherme Frisoni