topic Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse? in Application Development and Automation Discussions

How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

BaerbelWinkler — Thu, 28 Feb 2019 19:35:40 GMT

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

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

BaerbelWinkler — Mon, 04 Mar 2019 15:04:00 GMT

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

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

RaymondGiuseppi — Mon, 04 Mar 2019 15:25:52 GMT

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.

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

BaerbelWinkler — Mon, 04 Mar 2019 15:31:41 GMT

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

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

chaouki_akir — Mon, 04 Mar 2019 22:10:04 GMT

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.

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

BaerbelWinkler — Tue, 05 Mar 2019 08:49:14 GMT

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.

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

BaerbelWinkler — Tue, 05 Mar 2019 09:19:48 GMT

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?

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

RaymondGiuseppi — Tue, 05 Mar 2019 14:40:04 GMT

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?

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

chaouki_akir — Tue, 05 Mar 2019 17:25:05 GMT

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)

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

BaerbelWinkler — Tue, 05 Mar 2019 17:53:02 GMT

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.

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

chaouki_akir — Sun, 17 Mar 2019 17:21:23 GMT

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

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

BaerbelWinkler — Sun, 17 Mar 2019 19:11:45 GMT

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

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

matt — Sun, 17 Mar 2019 20:58:44 GMT

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

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

BaerbelWinkler — Mon, 18 Mar 2019 07:27:30 GMT

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?

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

BaerbelWinkler — Mon, 18 Mar 2019 10:27:22 GMT

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

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

matt — Mon, 18 Mar 2019 10:47:11 GMT

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.

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

chaouki_akir — Mon, 18 Mar 2019 13:37:50 GMT

My Eclipse version: 2018-12

In debug, the ABAP response to Eclipse contains :

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

BaerbelWinkler — Mon, 18 Mar 2019 18:01:48 GMT

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

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

BaerbelWinkler — Tue, 19 Mar 2019 07:34:30 GMT

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

Re: How to avoid DYNPRO_CALLED_IN_BACKGROUND dumps during process triggered from Eclipse?

BaerbelWinkler — Tue, 19 Mar 2019 11:03:58 GMT

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)?