Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Endless loop when using SUBMIT with RM06EPS0 (ME49)

e4rthdog
Explorer
3,307

I am using the following code to get the ALV data into memory from program RM06EPS0 (tcode ME49) and i found out that i am entering in an endless loop when doing so.

Main Code:

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( ).

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.
* build event table
    PERFORM alv_build_event_table USING p_vorgang
                                        lt_events[].

* get reference for output structure / table
    PERFORM alv_get_table_ref USING    p_vorgang
                              CHANGING l_table_ref.

* assign the table reference to the output table
    ASSIGN l_table_ref->* TO <outtab>.

* fill the output table
    PERFORM alv_fill_output_table USING    p_vorgang
                                  CHANGING <outtab>.
* build layout
    PERFORM alv_build_layout USING p_vorgang
                             CHANGING ls_variant
                                      ls_layout
                                      l_grid_settings.

* build fieldcatalog
    PERFORM alv_build_fieldcatalog USING    p_vorgang
                                   CHANGING lt_fieldcat.
    CHECK sy-subrc IS INITIAL.

    l_repid = sy-repid.

* deactivated interface check, as this is not necessary here! "n1068548
* call the ALV Grid
    CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
      EXPORTING
        i_interface_check       = ' '                         "n1068548
        i_callback_program      = l_repid
        is_layout               = ls_layout
        i_grid_title            = l_grid_title
        i_grid_settings         = l_grid_settings
        it_fieldcat             = lt_fieldcat
        i_default               = 'X'
        i_save                  = 'A'
        is_variant              = ls_variant
        it_events               = lt_events
      IMPORTING
        e_exit_caused_by_caller = l_exit_caused_by_caller
        es_exit_caused_by_user  = ls_exit_caused_by_user
      TABLES
        t_outtab                = <outtab>
      EXCEPTIONS
        program_error           = 1
        OTHERS                  = 2.

    IF sy-subrc <> 0.
      MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
              WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
    ENDIF.

    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 unsuccessfull.

Any ideas on how to make it work?

P.S. Stackoverflow question

1 ACCEPTED SOLUTION
Read only

michael_piesche
Active Contributor
2,130

Instead of calling the report via submit (SUBMIT rm06eps0 AND RETURN.), you can also call it via 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. You dont need to fill the batch input table bdc_tab if you dont want to pass any variables to the programm.

" SUBMIT rm06eps0 AND RETURN.  " replace this code

" with this one:
DATA bdc_tab TYPE TABLE OF bdcdata.
CALL TRANSACTION 'ME49' USING bdc_tab. 
" this way, the ABAP System Field Batch Input Processing Active (sy-binpt) is set to 'X'
" sy-binpt is used by the programme to check for an exit reason 
6 REPLIES 6
Read only

michael_piesche
Active Contributor
2,131

Instead of calling the report via submit (SUBMIT rm06eps0 AND RETURN.), you can also call it via 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. You dont need to fill the batch input table bdc_tab if you dont want to pass any variables to the programm.

" SUBMIT rm06eps0 AND RETURN.  " replace this code

" with this one:
DATA bdc_tab TYPE TABLE OF bdcdata.
CALL TRANSACTION 'ME49' USING bdc_tab. 
" this way, the ABAP System Field Batch Input Processing Active (sy-binpt) is set to 'X'
" sy-binpt is used by the programme to check for an exit reason 
Read only

0 Likes
2,130

I need the user to input data on the selection screen.

After i use this way will i be able to capture the ALV data and manipulate the data myself?

Read only

0 Likes
2,130

e4rthdog, if bdc_tab is empty, the two calls lead in general to the same result.

  • The user will be presented the Selection Screen of report 'RM06EPS0'.
  • If both approaches truly behave the same way (except for the exit strategy out of the while loop) and whether you are able to successfully access data from class 'cl_salv_bs_runtime_info' depends on the logic of the report and the class.
  • Test it.
  • I merely gave a solution for being able to exit the while loop within report RM06EPS0.
    As of now, I can not confirm whether your coding and approach will definitly meet all your requirements.
Read only

0 Likes
2,130

My friend, i was so noob that i did not realize that i still could use the cl_salv_bs_runtime.

It works like a charm! I got my data after the call.. Can you explain or direct me to some reading as to which mechanism is behind this and why memory data are still available for reading?

Read only

2,130
Elias Stassinos, cl_salv_bs_runtime is a class with static class methods and attributes that can be accessed publicly. As long as that class is in the sessions memory, you can access it, no matter what programm has called it within the session.
Read only

0 Likes
2,130

Elias Stassinos Both SUBMIT and CALL TRANSACTION run in a separate "Internal Session", so concerning the question, it's no surprise that CL_SALV_BS_RUNTIME works well with CALL TRANSACTION if it works well with SUBMIT. The ALV probably uses the so-called "ABAP memory" ({EXPORT ... TO | IMPORT ... FROM} MEMORY ID ...) which persists across Internal Sessions (in the same External Session). See ABAP documentation for more information.