Skip to Content

Access to local variables in calling procedure

Hi there,

i know there is a trick to access at least global variables of the main program, without knowing them in the current context. This can be done via field symbols as this (actually I am in a BadI within stock determination in EWM):

  field-symbols: <fs> type any.

  ASSIGN ('(nameofprogram)variable') to <fs>

I would like to know, if there is a similar possibility to access also local variables from the calling routines. In my case, if I am in the debugging mode and select the calling routine/function module in the ABAP stack, I have access to it. Thus I believe it somehow must be possible.

Any ideas?

Volker Bock

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

6 Answers

  • Best Answer
    Jul 17, 2015 at 09:54 AM

    Hi Volker,

    I fiddled a bit around and found out that the debugger uses the method IF_TPDA_CONTROL~GET_LOCALS of class CL_TPDA_CONTROL to get local variables.

    Which does internally a C function call.

    If you use this method in a custom program it throws an exception resulting in a shortdump.

    Which indicates some issues in interprocess communication.

    But perhaps someone will find a way to circumvent this obstacle.

    Regards Christian


    Add comment
    10|10000 characters needed characters exceeded

  • Jul 17, 2015 at 06:49 PM

    Local variables would not be visible to outside of that local subroutine, FM, Method etc.

    In my case, if I am in the debugging mode and select the calling routine/function module in the ABAP stack, I have access to it

    As you have noted, the local is only visible if you select that subroutine from the callstack.  To @Christian Guenter's point, local is only visible if you select that program from callstack. Even debugger doesn't show them up if you don't have proper "context".

    For your requirement, if you have access to explicit enhancement points before your BADI, you should be able to read the local variables provided it is already set with the value you are looking for. Create a static variable in your BADI implementation class and set that variable in the explicit enhancement implementation. Use that variable in your BADI implementation and clear it just before existing the BADI method.

    Regards,
    Naimesh Patel

    Add comment
    10|10000 characters needed characters exceeded

    • So, in the beginning implicit - the Variable is unknown  - as it is declared with DATA statement, after the Implicit enhancement.

      Yes, the variable is unknown at compile time. But at runtime you can access it dynamically with another field-symbol trick.

      So something like this is possible.

      This is possible due to the fact that in ABAP local variables are created when a subroutine/method is entered.

      Validity and Visibility

      For me this is just some kind of academic example. One should see this only as a last resort.

      This is a very fragile approach, because at the next upgrade SAP might have refactored (renamed or removed) the lv_local_to_this variable and you would hardly detext this until it leads to logical errors during integration testing. But of course there are ways to detect this in the BADI method...

  • avatar image
    Former Member
    Jul 17, 2015 at 09:12 AM

    Hi Volker,

    Not sure if I understood your scenario correctly.

    But as per me local Variables gets refreshed from Memory when coming out of the context automatically.

    I don't think accessing them is possible and even if you access them those won't be of any use as they won't contain any data in it.

    R

    Add comment
    10|10000 characters needed characters exceeded

  • Jul 17, 2015 at 10:10 AM

    Hi Volker,

    i am not confirm with accessing a local variable, but there is  a Fm which provides field information of declared local structure.

    FM Name:  GET_COMPONENT_LIST.

    If you check the code behind, a C function called to get the Structure Information based on input program name and structure name.

      CALL 'AB_STRUC_INFO'

        ID 'PROGRAM'   FIELD PROGRAM

        ID 'STRUCNAME' FIELD FIELDNAME

        ID 'STRUCINFO' FIELD COMPONENTS-*SYS*.

    Regards,

    Praveer.

    Add comment
    10|10000 characters needed characters exceeded

  • Jul 17, 2015 at 03:32 PM

    Not a real answer, Volker, just possible workaround -- since we have now implicit enhancements (nearly) everywhere, you can...

    1st declare custom global variable in program from which you need the data (enh usually in some TOP include);

    2nd move the local variable to this custom global one (enh where the local var is set);

    3rd access the global variable via field symbols (as usual);

    ...the challenge is then around step no 2, to find the local place for impl.enhancement; but as they are at beginnings/ends of FMs & subroutines, it should be possible most of the time.

    TomT

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Jul 17, 2015 at 05:02 PM

    Hi Volker,

    local variables in methods, form routines and function modules are created just the moment the processing starts.As soon as the END method, form, function is reached, the local variables are freed and returned to the memory stack.

    So the only time you could possibly access the local varaiables is when the code is processed (as you can see in  debugger). So how do you expect to access local variables before or after they exist?

    The only variables that will survive are static variables inside forms or methods. If you are interested in those, there might be a way...

    Regards, Clemens

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Tomas Talpa

      Thanks folks,

      you are right - I was just confused. Now I got it - but no solution at hand. I'm not too familar with the debugger architecture so I don't know what happens in detail when debug environment is created in old debugger. The new debugger controls the whole process and works definitely totally different.

      What ever a solution would be, ist will be primarily of academic interest. Programmatically you may store a reference of a local variable in a container class and access it from wherever you need to.

      Regards, Clemens