1

This code has been working nicely for several months now:

SUBMIT (IV_REPORT_NAME)
   WITH SELECTION-TABLE selection_table
   USING SELECTION-SET IV_SELECTION_SET_VARIANT
AND RETURN.

DATA          lr_data_descr         TYPE REF TO cl_abap_datadescr.
DATA          lr_data_line_descr    TYPE REF TO cl_abap_datadescr.

cl_salv_bs_runtime_info=>get_data_ref( r_data_descr      = lr_data_descr
                                       r_data_line_descr = lr_data_line_descr ).

IF lr_data_descr IS NOT BOUND.
  ev_result_json = '[]'.
  EXIT.
ENDIF.

But in one of the cases it is called through RFC and throws

lr_data_descr is NOT BOUND

It works fine via SE37, but if executed via RFC throws the error despite I use the very same user (type "service") for RFC and SE37, same input and same code.

Why is there a difference? Is there a way to get some error message?

This would really help, if I could get the reason why it is not bound. I debugged into get_data_ref() and found out this line behaves different:

import t_component to lt_component from memory id
cl_salv_bs_runtime_info=>c_memid_data_def.
if sy-subrc eq 0.

If I test the function module in se37 then sy-subrc is 0, and if I do external debugging with the same user then sy-subrc is 4.

It is an adhoc report, its name is AQZZZMM=========ZME80FN=======

Boghyon Hoffmann
  • 17,103
  • 12
  • 72
  • 170
guettli
  • 25,042
  • 81
  • 346
  • 663
  • 2
    SALV is tightly coupled with dialog processing. If you call the code by RFC, then there is no GUI connected to the server. Maybe this is the reason? – Jagger Apr 25 '19 at 08:57
  • @Jagger. If I test it via se80 it runs non interactively and works. I have two questions: First: How to make debugging via se80 act like running without gui? Second question: Is there a way to provide a virtual GUI to pretend to have a GUI? – guettli Apr 25 '19 at 09:20
  • Could put this function module of yours in a program and then start it in background (F9 instead of F8) to see whether it crashes (or delivers this empty json table)? Then one might be sure that the problem is with the process type dialog vs. background. – Jagger Apr 25 '19 at 11:54
  • Could you try the RFC case by running it via SE37 with the same user and entering the RFC destination `NONE` (screen field above the parameters)? PS: a "service" user is dialog-capable, and the OP said he debugged both cases with the same user so I think it's not a user problem; moreover RFC is GUI-capable provided that you select it when you open the RFC connection (activated by default with SAP) – Sandra Rossi Apr 25 '19 at 13:03
  • @SandraRossi you say that it is possible to active the GUI via RFC. This sounds great. Could you please provide a link to the matching docs. I could not find any official docs about this. – guettli Apr 26 '19 at 08:10
  • @Jagger: I created a programm which calls the function module. I called the programm in background. The result was not empty. This kind of background processing works. Just rfc fails. Strange. – guettli Apr 26 '19 at 08:59
  • @SandraRossi I run se37 and used NONE as rfc destination. Again: it works like this (normal) debugging. But fails with remote debugging. – guettli Apr 26 '19 at 09:02
  • So RFC is not the issue. To analyze the issue, you may use an ABAP trace. First choose a very small set of data so that the trace doesn't fail, start the trace via transaction code SAT, with a variant option "no aggregation", for both cases, and compare by SAT the 2 traces, so that to identify the "culprit" line of ABAP code. You may activate the trace each time an RFC session starts (use it for the 2 "measures", pyRFC and SE37 with NONE), via the "user/service" schedule in SAT. – Sandra Rossi Apr 26 '19 at 09:43
  • @SandraRossi why do you think "So RFC is not the issue." I think it is the issue. Since it works via se37 and it works via background program job. Maybe rfc is not strictly the issue, but the environment which exists in a rfc context. Up to now I failed to create a similar environment without rfc. – guettli Apr 26 '19 at 11:32
  • I mean, you ran it successfully via SE37 both in RFC (NONE means "RFC in same system") and in normal mode, with exactly the same conditions. Let's wait for your analysis with SAT. – Sandra Rossi Apr 26 '19 at 13:17
  • Do the other query programs (AQ...) succeed when called through pyRFC? – Sandra Rossi Apr 29 '19 at 11:39
  • 1
    @SandraRossi other reports/programs work fine via pyRFC. Just these reports starting with AQ and containing a lot of === signs do not work. – guettli Apr 29 '19 at 12:03
  • When I run your code with my own query, there is a popup which asks for the number of lines to extract. Do you have this popup, or how do you ignore it to tell the system to extract all the lines? – Sandra Rossi Apr 29 '19 at 14:21
  • @SandraRossi I don't get a popup. – guettli Apr 29 '19 at 14:33
  • I did a new test, the popup is not displayed anymore if I enter any selection criteria. It works through RFC from my VBS script, whatever I activate the SAP GUI dialog mode or not. I have no explanation why you have an issue. – Sandra Rossi Apr 30 '19 at 07:39
  • It can be easily checked whether it is query-related by putting breakpoint before the `cl_salv_bs_runtime_info=>get_data_ref` and checking if `SUBMIT` returned anything or no through global variables – Suncatcher Dec 17 '19 at 19:09

1 Answers1

3

The only case where r_data_line_descr of cl_salv_bs_runtime_info=>get_data_ref() is not bound is:

  • The ALV is not called

With SAPquery queries, it happens when no data is extracted (in the query program, the variable %runmode-show_on is empty when there's no data, the ALV is not shown, cf screenshot below).

So, your issue is probably due to selection values passed by your pyRFC program which correspond to nothing. When you call the query from SAP, these values are different and return some data (check it by debug to verify which values are different).

enter image description here

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48