How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

[BaerbelWinkler]

Me again, with another question related to my struggles with Eclipse and getting it to work within our processes!

While testing exit-functionality for my other question, I also tested some customer logic applied via the Badi which gets called during creation of transport request: CTS_REQUEST_CHECK~CHECK_BEFORE_CREATION. I have this active in our dev-systems to perform checks on the transport-title content to make sure that the titles contain some required elements. The BADI calls a function module which performs the various checks and uses the function module POPUP_GET_VALUES to ask for missing data. When I tried to create a CTS while activating a program in Eclipse I got the pop-up to specify the transport title and when I entered a wrong one to trigger the logic, I get this message:

This is happening when the function module POPUP_GET_VALUES gets called where this statement then causes the DYNPRO_CALLED_IN_BACKGROUND dump:

CALL SCREEN 300 STARTING AT start_column_100 start_row_100
               ENDING AT end_column_100   end_row_100.

Can I somehow avoid this dump - i.e. do the check and user dialog in Eclipse so that whatever gets "sent" to SAP will not trigger the check? It's however not just a simple check but one which involves a couple of Z-tables with e.g. REGEX terms for the expected content. Or - given the complexitiy of the check - is the only option to create the transport in SE10 in a separate GUI-tab opened from Eclipse?

Thanks for bearing with me!

Cheers

Bärbel

[BaerbelWinkler]

Just thought of something to at least avoid the dumps when coming from Eclipse: instead of asking for user input as the logic currently does via the FM, I could just trigger an error message "Missing component(s) in transport title. Please try again" (or something like that).

But, which SY-field or other information lets me know that the check is done coming from Eclipse instead of from within the SAP-system? I looked through the SY-fields but don't see anything obvious. SY-Batch is already queried before the check is executed, so that cannot be it.

So, is there an indicator for "process triggered from Eclipse" (or at least not from within the system)?

Cheers

Bärbel

[raymond_giuseppi]

Did you try using one of those old tricks to check dynpro availability : e.g. FM GUI_IS_AVAILABLE or method CL_GUI_ALV_GRID=>OFFLINE or CL_SALV_MODEL=>IS_OFFLINE, then raise the error message or call the popup FM.

[BaerbelWinkler]

Thanks, Raymond!

I wasn't even aware that these routines existed, so I obviously didn't try them yet (but will give GUI_IS_AVAILABLE a try).

Cheers

Bärbel

[BaerbelWinkler]

Little update:

FM GUI_IS_AVAILABLE works like a charm and I no longer get an ABEND when the transport title check is not happy when I try to create a transport request from within Eclipse.

I might even be able to restrict it to the Eclipse-context by querying these sy-fields instead (but the general check might be better):

XPROG - SAPLSADT_REST
XFORM - SADT_REST_RFC_ENDPOINT

Lingering issue

However, I'm not able to consistently provide a meaningful error message back to the developers, so that they at least get a hint of what went wrong.

When the check is not happy, an error message gets set in the Badi:

IF sy-subrc NE 0.
  MESSAGE e000(38) WITH 'Incomplete transport title. Please try again'.
  RAISE cancel.
ENDIF.

But, this is not visible in the dialog box in Eclipse:

If the developer has the error-log window open before trying to create a request, the error message may show up there (but didn't do so consistently during my testing):

If - and I think it's pretty big "If" - that window is not yet open before triggering the activity, the developer will not get any clue of what went wrong because the pop-up to select/create the transport request prevents any other activity in Eclipse.

Is there a means to show the error message on top of the pop-up-box or at least open the Error log view if it's not yet open?

[raymond_giuseppi]

When the popup triggered a dump, you were triggering a popup with an error. If you try to use an 'A' abort or 'X' dump message, what is the result in Eclipse?

[BaerbelWinkler]

raymond.giuseppi - "If you try to use an 'A' abort or 'X' dump message, what is the result in Eclipse?"

I'll have to try tomorrow when I'm back in the office, but wouldn't this then always generate a ST22-dump in the backend? That wouldn't make much sense as the error is not really a reason for an ABEND (I think).

Will let you know what happens.

[chaouki_akir]

I would try add ABAP code lines in CTS_REQUEST_CHECK~CHECK_BEFORE_CREATION. These code lines will consist of an infinite loop.

Then, in transaction SM50, i would try to debug the process. From the debugger, I would analyse all given information.

[BaerbelWinkler]

Thanks for the suggestion, Chaouki!

I added an eternal loop but it turned out to not even be necessary to do that! All that was needed to make the debugger stop even when triggered from Eclipse was to set an external breakpoint somewhere in the code.

[chaouki_akir]

This is much more simpler.

Just another question : if you call function 'SYSTEM_CALLSTACK' in your BADI what do you see in the stack ?

(even if function 'SYSTEM_CALLSTACK' is not released to customer)

[chaouki_akir]

8b889d0e8e6f4ed39f6c58e35664518f,

I have implemented BADI CTS_REQUEST_CHECK (method CHECK_BEFORE_CREATION):

  METHOD if_ex_cts_request_check~check_before_creation.
    DATA gui_is_available TYPE abap_bool.

    CALL FUNCTION 'GUI_IS_AVAILABLE'
      IMPORTING
        return = gui_is_available.

    CASE gui_is_available.
      WHEN 'X'.  "SAP GUI available
      WHEN OTHERS. "SAPGU
        MESSAGE e010(sapmtran) WITH 'forbidden from gui external tools' 'like Eclipse' RAISING cancel.
*       & & & &
    ENDCASE.

  ENDMETHOD.<br>

I am sending an error message if the transport order is created from outside SAPGUI : 'forbidden from gui external tools' 'like Eclipse'.

So, when from eclipse, I create an ABAP program and I choose 'Create new Transport Request',

• 

I receive the BADI error message exactly where you expect it :

• 

The BADI message also appears in "Error Log" of Eclipse.

AS ABAP version is 752 (mini SAP).

[BaerbelWinkler]

chaouki.akir

Thanks, Chaouki! I'll give it a try when I'm back in the office tomorrow. What you show is similar to what I tried and if I'm lucky than I'll simply have to add "RAISING cancel" to the error message I already trigger and delete the line with "RAISE cancel". If I'm not lucky, then the difference is the NW version (we are on 7.50 SP8).

I'll let you know which of the two it is as soon as I know!

Cheers

Bärbel

[BaerbelWinkler]

chaouki.akir

Looks as if I'm not lucky 😞

Now I get this message when I try to create a transport with an incomplete title:

Here is my code within the BADI:

    "Only do the check if transport creation happens online and if it's workbench related
    IF sy-batch EQ abap_false AND
       type     EQ 'K'.

      "The first check in the function module will determine if checks are active in the system.
      "This is done by looking for an entry in table ZBC_DEV_USERTYPE
      "USERNAME = '*' AND USERNOTCHECKED = 'X' ==> CHECKS NOT ACTIVE IN SYSTEM
      CALL FUNCTION 'Z_WWXBC14_CTS_CHECK_TITLE'
        EXPORTING
          i_tr_type             = type
          i_username            = sy-uname
          i_tr_text             = text
        IMPORTING
          o_tr_text             = text
        EXCEPTIONS
          incomplete_title      = 1
          error_text_components = 2
          OTHERS                = 3.

      IF sy-subrc NE 0.
        MESSAGE e000(38) WITH 'Incomplete transport title. Please try again' RAISING cancel.
*        RAISE cancel.
      ENDIF.

    ENDIF.

I put a breakpoint in my code and see that the function module gets executed and correctly sets an RC of 1 for "incomplete title" which in turn triggers the error message.

Next I get the pop-up shown in Eclipse and the error log just contains a lot of (to me) gibberish about JAVA-stuff but no message in the transport-creation pop-up itself like you did.

How can I determine if the issue is on the SAP or the Eclipse side of things?

[chaouki_akir]

My Eclipse version: 2018-12

In debug, the ABAP response to Eclipse contains :

[BaerbelWinkler]

chaouki.akir

Thanks for your efforts, Chaouki!

I'll try and take a look in debugging tomorrow - but I'm not too hopeful as I haven't been able to get the "XML browser" view to work for the response-message_body content when I tried last week. I most likely did something wrong!

Cheers

Bärbel

[BaerbelWinkler]

chaouki.akir

Here is the next update with a break-point set where you show it and checking the content of RESPONSE-MESSAGE_BODY with XML View. Not too suprisingly it shows what afterwards gets displayed in Eclipse:

What I don't understand is why this ends up in the MESSAGE_BODY instead of the expected actual error message set as in your example (just with another message text).

Cheers

Bärbel

[BaerbelWinkler]

chaouki.akir

Finally, I can at least report some success!

With the help of debugging I found where my error message got overwritten with the rather generic one.

Values were sy-msgid = 38 and sy-msgno = 000 and this ended up in the ELSE-clause in CL_CTS_ADT_RES_OBJ_RECORD~USER_EXIT_BEFORE_CREATION

*     call BAdI
      call method lr_exit->check_before_creation
        exporting
          type       = new_type_request
          tool_flag  = 'E'   " ABAP in Eclipse
        changing
          text       = request_text
          attributes = tab_attributes
        exceptions
          cancel     = 1.
      if sy-subrc <> 0.
        if sy-msgid is not initial and sy-msgno is not initial.
          message id sy-msgid type 'E' number sy-msgno
                  with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4 raising badi_execution_failure.
        else.
          message e653(tk) raising badi_execution_failure.
        endif.
      endif.
    else.
      message e653(tk) raising badi_execution_failure.
    endif.<br>

When this happened, I updated sy-msgid to sapmtran and sy-msgno to 010 as in your example and used "Goto statement" to repeat the check. Then, my own message was used instead of the generic one.

What I don't understand is why SY-MSGNO is queried for "not initial" as "000" is a valid entry for it in T100 where it's a CHAR3 instead of a NUMC3 field. Should I raise an OSS-message so that SAP corrects this check? MSGNO = 000 is after all used in many message classes - there are more than 7,000 messages in non-Z message classes in T100 in our NW 750 system.

So, now I at least get the expected error-message back which is visible in the RESPONSE XML (note this is another text as I created my own message text in T100):

Click to see attached graphic

What however still doesn't work as I think it should is how the user sees the message in Eclipse where it's still the not well formatted pop-up instead of how I expect to see it as an error message below "Check for Transport Request":

Could this be due to an older Eclipse version?

Eclipse Java EE IDE for Web Developers.
Version: Neon.3 Release (4.6.3)
Build id: 20170314-1500

And will we just have to wait until we get a newer one (can't do that ourselves due to restrictions of what we can install on our company laptops)?

[chaouki_akir]

Your ABAP response to Eclipse seems to be the same as mine. So we can suppose that the problem is coming from your Eclipse version.

To validate this hypothesis, you should try a newer Eclipse version.

As far as I know, you can try a newer Eclipse version without any installation (download and extract a zip file).

[BaerbelWinkler]

chaouki.akir

As soon as we have a newer Eclipse version available, I'll try again to see if that in fact was the reason. As my main issue has been resolved with your help, I'll mark the question as answered now but leave it open for additional discussion.

I also created an incident for SAP to look into the "SY-MSGNO IS NOT INITIAL" statement to see if there's a better way to do this check.

Thanks again for your help with troubleshooting this issue!

Cheers

Bärbel

[matt]

I tested the release check method in Eclipse, and it opens up a gui session with the dialog fine.

[BaerbelWinkler]

matthew.billingham

Hi Matt - thanks for testing but I'm not quite clear what exactly you tested and where? Could you please elaborate a bit? The check I implemented happens in the "before creation" method and it didn't trigger a GUI-seesion when it encountered the screen-logic. It just dumped (before I added the GUI_IS_AVAILABLE FM to the mix).

Thanks and Cheers

Bärbel

[matt]

All I was saying is that method CHECK_BEFORE_RELEASE of the BADI, doesn't dump in Eclipse. So it's surprising that CHECK_BEFORE_CREATE should. However, in my implementation, we don't issue an error message - we just display an ALV grid with the details of the issues, and then stop the release by raising CANCEL

Maybe you could try the same -display the message in an ALV grid, and then raise CANCEL, rather than throw an error message. Might be a workaround.

[BaerbelWinkler]

matthew.billingham

Not sure if you've been following my exchange with Chaouki below, so just in case that not, the issue with the message is down to a fairly trivial issue with an IF-statement in SAP's code! They check for "SY-MSGNO IS NOT INITIAL" and I was using one where MSGNO is "000". Details are here.

Thanks for helping with this!

[matt]

No - I hadn't seen it. And it made me laugh! It's in my 7.50 system.

Yes, it should be raised to SAP as it is a clear bug. In similar situations, I check sy-msgid, but never sy-msgno. That's just daft.

Will it be fixed? Well... sometimes low priority simple issues are easier to get done. So there is hope.

[BaerbelWinkler]

I had an ATC-related low priority incident recently for which I received an OSS-note within about 3 weeks, so I'm fairly hopeful!. I'm trying this one via an expert chat as it's then potentially easier to just show via debugging during the session instead of trying to explain how to reproduce the issue now that I already changed my coding.

The IF-statement seems to have been added via OSS-Note 2489472 from 2017, so the issue could even be considered a side-effect of that (I guess).

[BaerbelWinkler]

Update: I just realised that I never updated this Question with the OSS-Note, so finally - and better late than never - here it is (provided by SAP in April 2019):

2775007 - Handling the exception message from BADI CTS_REQUEST_CHECK call when message no is '000'