1

The goal is to use class cl_salv_bs_runtime_info to read the ALV data from the report and create my own ALV afterwards.

The original report is creating an ALV: enter image description here

The code to capture the ALV data is the following: (This is standard code that I have used with many ALV reports).

    REPORT zhgirm06eps0.
    
    FIELD-SYMBOLS <lt_data>   TYPE ANY TABLE.
    DATA lr_data              TYPE REF TO data.
    
    cl_salv_bs_runtime_info=>set(
       EXPORTING display  = abap_false
                 metadata = abap_false
                 data     = abap_true ).
    
    SUBMIT RM06EPS0 AND RETURN.
    
    TRY.
        cl_salv_bs_runtime_info=>get_data_ref(
          IMPORTING r_data = lr_data ).
        ASSIGN lr_data->* TO <lt_data>.
      CATCH cx_salv_bs_sc_runtime_info.
        MESSAGE `Unable to retrieve ALV data` TYPE 'E'.
    ENDTRY.
    
    cl_salv_bs_runtime_info=>clear_all( ).
    
    LOOP AT <lt_data> ASSIGNING FIELD-SYMBOL(<line>).
      ...
    ENDLOOP.

After debugging the standard code I found out that everything should work just fine. the standard program is getting the data and also runs REUSE_ALV_GRID_DISPLAY correctly.

BUT right after the ALV grid code there is a condition that creates the problem.

Standard code for the ALV in program FM06IF03:

    WHILE l_leave_sw IS INITIAL.

        ...

        CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
          ...
    
        IF ls_exit_caused_by_user = 'X'  OR              "1094328
           sy-batch = 'X' OR sy-binpt = 'X'.
             l_leave_sw = 'X'.
        ENDIF.
    
      ENDWHILE.

As you can see the whole section is in a WHILE loop. This while loop DOES NOT exit when using the SUBMIT. The reason is that the variable l_leave_sw never becomes true.

When you run the report normally everything works fine and the ALV is displayed.

I tried to set sy-batch or sy-binpt to true in my code but it was unsuccessful.

Any ideas on how to make it work?

Boghyon Hoffmann
  • 17,103
  • 12
  • 72
  • 170
e4rthdog
  • 5,103
  • 4
  • 40
  • 89
  • You don't pass any selection criteria to the program, how many lines should be produced if you run it the classic way? (and how long does it take the classic way to show up all the lines? Just to know...) – Sandra Rossi Oct 02 '20 at 11:21
  • If you dont pass and the selection screen has mandatory fields (which it has) it brings up the selection and then it runs..Which is what happening in this case..I wish it was that :) – e4rthdog Oct 02 '20 at 11:59
  • In fact your table doesn't look like an ALV. What inputs and what manual actions do you perform to reach this "ALV"? NB: `RM06EPS0` corresponds to transaction code `ME49`. – Sandra Rossi Oct 02 '20 at 16:06
  • There is nothing wrong with the code. I found out the reason behind all these and i will edit my question accordingly.Just wait 5 mins. – e4rthdog Oct 02 '20 at 16:32
  • Okay, it's ALV then, no problem. Could you answer the question please so that we can reproduce? (just a matter of debug) – Sandra Rossi Oct 02 '20 at 18:09
  • interesting. I wasn't able to start ME49 from code neither via CALL TRABSACTION not via SUBMIT in ALV mode, only like a list. Do you have user parameter `ME_USE_GRID` set? – Suncatcher Oct 05 '20 at 11:45
  • @Suncatcher There is a parameter p_alv which has been enabled in the program that allows for ALV output. It resides in include FM06ICPS – e4rthdog Oct 05 '20 at 16:43
  • it is about code, and I tell you about [user parameter](https://blogs.sap.com/2013/07/10/setting-default-values-identifying-parameter-id/) ME_USE_GRID. If I set it then the ALV is showed when tcode/prog is started from GUI, however not in code, and I didn't find a cause for such behavior. It is reproducible on many systems – Suncatcher Oct 06 '20 at 07:03

1 Answers1

1

We need to replace the SUBMIT with CALL TRANSACTION with USING bdc_tab option.

This way, the variable sy-binpt will be set to 'X' and the report should exit correctly without an endless loop.

Final Code after just replacing submit:

*&---------------------------------------------------------------------*
*& Report zhgirm06eps0
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT zhgirm06eps0.

FIELD-SYMBOLS <lt_data>   TYPE ANY TABLE.
DATA lr_data              TYPE REF TO data.

TYPES:
  BEGIN OF lr_record,
    icon_rang TYPE mere_icon_rang,
    ebeln     TYPE ebeln,
    ebelp     TYPE ebelp,
    lifnr     TYPE lifnr,
    name1     TYPE name1,
    submi     TYPE submi,
    ptext     TYPE ptext_d,
    matnr     TYPE matnr,
    matkl     TYPE matkl,
    txz01     TYPE txz01,
    menge     TYPE ktmng,
    meins     TYPE meins,
    netpr     TYPE netpr,
    zwert     TYPE netwr,
    waers     TYPE waers,
    rang      TYPE rang,
    proze     TYPE proze,
    gzwert    TYPE netwr,
    grang     TYPE rank_abs,
    gproze    TYPE rank_per,
    infnr     TYPE infnr,
    log1      TYPE merel_info,
    log2      TYPE merel_info,
  END OF lr_record.

DATA: lr_records TYPE TABLE OF lr_record WITH HEADER LINE,
      l_record   TYPE lr_record.

cl_salv_bs_runtime_info=>set(
   EXPORTING display  = abap_false
             metadata = abap_false
             data     = abap_true ).

DATA bdc_tab TYPE TABLE OF bdcdata.
CALL TRANSACTION 'ME49' USING bdc_tab.

TRY.
    cl_salv_bs_runtime_info=>get_data_ref(
      IMPORTING r_data = lr_data ).
    ASSIGN lr_data->* TO <lt_data>.
  CATCH cx_salv_bs_sc_runtime_info.
    MESSAGE `Unable to retrieve ALV data` TYPE 'E'.
ENDTRY.

cl_salv_bs_runtime_info=>clear_all( ).

LOOP AT <lt_data> ASSIGNING FIELD-SYMBOL(<line>).
  MOVE-CORRESPONDING <line> TO lr_records.
  APPEND lr_records.
ENDLOOP.
e4rthdog
  • 5,103
  • 4
  • 40
  • 89