Switch debug user via ADT shows popup /H_REACTIVATE_EXTD_DBG KIND=USER USER=SAP_WFRT

[Sandra_Rossi]

I'm trying to debug the user SAP_WFRT, in ADT I changed the Debug Properties:

But I get this "error":

Selected function /H_REACTIVATE_EXTD_DBG KIND=USER USER=SAP_WFRT is not (yet) supported.

The detail screen behind the question mark icon says that the message comes from the exception class CX_ST05.

The "exact" things I did:

1. Via Eclipse, I started ST05, activated the SQL trace, stopped it and displayed the trace (main list of SQL statements shown by ALV). I didn't close the SAP GUI tab.
2. I started SAP GUI independently from ADT, I added an external breakpoint via SAP GUI for something else, I had a warning that Eclipse debugs.
3. I switched the user debug via ADT from my own user to SAP_WFRT -> "error" as mentioned above
4. I logged out of the SAP GUI (the one started independently from ADT)
5. I switched the user debug via ADT from my own user to SAP_WFRT -> still the same error
6. I realized that CX_ST05 corresponds to the SQL trace opened in ADT, so I closed the Eclipse tab of ST05, then I switched again the user debug -> no more error.

Clearly, the function code mentioned above was sent to one of my SAP GUI tabs opened via ADT, for an unknown reason.

I had two other SAP GUI tabs opened on transactions SE16 and SICF, so I tried to run manually the function code mentioned above and got a different message, "User mismatch - debugging will not work for current logon session", sent as warning (by RS_ADTDBG_ACTIVATE_BY_OKCODE):

I can't find any information/SAP note about RS_ADTDBG_ACTIVATE_BY_OKCODE and H_REACTIVATE_EXTD_DBG.

Running manually the function code in ST05 (it could be any other invalid function code) displays the popup "selected function..." because ST05 is coded to behave like this.

I switched the debug user again and I realize that the function code mentioned before is sent to all SAP GUI tabs in Eclipse.

Any idea behind this logic and why ST05 doesn't handle it the same discreet way as in other transactions?

Maybe @Armin_Beil can help.

Thanks.

Sandra

My environment: ABAP 7.58 SP 1, Eclipse 2025-06/ADT 3.52.2, S/4HANA On premises 2023 FPS 1.

NB: why the program RS_ADTDBG_ACTIVATE_BY_OKCODE is not called when the transaction is ST05, I don't know. This program is called by kernel, I don't know if it's called or not, it cannot be traced and there's no documentation except the first lines of comment:

report  rs_adtdbg_activate_by_okcode.


" ABAP implementation of OK codes to re-activate ADT debugger when inside
" embedded SAPGui.
"
" The syntax of these OK codes is:
"   /H_REACTIVATE_EXTD_DBG KIND=USER  USER=<username> [IDEID=<ideid>]
"   /H_REACTIVATE_EXTD_DBG KIND=IDEID IDEID=<ideid>   [USER=<username>]
"   /H_REACTIVATE_EXTD_DBG KIND=TID   IDEID=<ideid>   TID=<tid>         [USER=<username>]
"
" OK-Codes are parsed inside kernel and parameters are transferred via rperf
" into form "_activate" (see below).
" The activation itself takes place here.



*** !!! DO NOT MODIYFY !!!
**  This form is called by rperf directly from kernel
*
form _activate.

In case someone wants to check why ST05 doesn't call RS_ADTDBG_ACTIVATE_BY_OKCODE, below is the code triggered for ST05 when the function code is sent:

After RAISE RESUMABLE, the exception is caught and a popup is shown.

But what is important is why RS_ADTDBG_ACTIVATE_BY_OKCODE is not called before all this code.

[Armin_Beil · Accepted solution]

Hi Sandra,

thanks for the excellent problem description and for your analysis. I have the same reproducible behavior in our system, so we can take a look at this. This might take a while because I don't consider the issue as high priority currently. Please correct me if my assumption should be wrong.

In general, it is normal and expected that ADT sends special ok-codes into all currently open embedded GUI windows. The specific code /H_REACTIVATE_EXTD_DBG KIND is intended to inform the GUI windows about the change in the debug settings.

Normally ADT-users should not see these ok-codes at all and also ST05 as a transaction/program should not "see" or handle these codes. We have to check why ST05 shows a different behaviour here.

Regarding the warning "User mismatch - debugging will not work for current logon session.":

As you know, debugging only works if the username that is configured in the debug-settings matches the username of the debuggee (= sy-uname of the to-be-debugged ABAP process). In case of an embedded GUI the debuggee user / sy-uname will be the logon user of your ADT project. The warning informs you if this username does not match the one in your debug settings, which is a useful warning in my personal opinion.

The text "... debugging will not work for current logon session" might be a bit unclear because it is not necessarily clear to the user what "current logon session" means in this case. Maybe this could be improved. However from a purely technical perspective the text is not wrong, because it refers to the ABAP logon session of the embedded GUI window / set of embedded GUI windows.

Best regards,
Armin

[Sandra_Rossi]

Thanks a lot for all the details.

I confirm that it's not urgent at all.

Anyway, if it's not fixed, I have posted this question so that people can find an explanation here.

[Sandra_Rossi]

For information, I have found the SAP note 3616366 - Downport of command %_KEEPALIVE - SAP for Me which handles another special function code, %_KEEPALIVE, dedicated to transactions running in Fiori via SAP GUI for HTML, which is automatically triggered for all open sessions after 15 minutes (the default FLP timeout setting) to handle timeouts (*).

So, it's a little bit like the transactions running in Eclipse when the field command H_REACTIVATE_EXTD_DBG is sent to all of them.

The note does a fix of SAPMSSYD, the general-purpose system program common to all SAP GUI transactions, to handle %_KEEPALIVE and few other % system function codes. Below is the fix of SAPMSSYD. The part in the subroutine KEEP_ALIVE is not interesting, but there's DYNP_SET_STATUS field 4 and 45, maybe it "swallows" the function code after the processing logic, maybe RS_ADTDBG_ACTIVATE_BY_OKCODE could be triggered the same way as %_KEEPALIVE...

  elseif my_ucomm(11) = '%_KEEPALIVE'.
    perform keep_alive.
    call 'DYNP_SET_STATUS' id 'FUNCTION' field 4 id 'VALUE' field 1. "#EC CI_CCALL
    call 'DYNP_SET_STATUS' id 'FUNCTION' field 45 id 'VALUE' field 1. "#EC CI_CCALL

(*) NB: the symptom of the %_KEEPALIVE issue is described in the note 3642150 - SAP GUI for HTML: Support Of FLP's ExtendSession Service - SAP for Me.

[Armin_Beil]

Hello Sandra,

my colleague from the ABAP Kernel team made a correction for this. The special ok-code will be absorbed, so that it does not reach the processing of ST05 (or any other transaction). It is planned to be a part of the next ABAP kernel release. It is also considered for a kernel patch, but currently ranked as low priority. So it is currently not clear whether this correction will be available as a kernel patch or not.

Best regards,
Armin

[Sandra_Rossi]

Hi Armin,

great news, thanks for the fix and for the feedback!

Sandra