ABAP Call FM Dynamically with Mystery Parameters!

By | November 20, 2013 | Tricks | 5,615 | 11

FM can be called with specifying the name as well as passing the name to the variable and calling FM with variable name. Let me show you something interesting when you call the FM dynamically.


Once I was changing the functionality of one of the FM. This FM is dynamically called based on the conditions. The conditions and the FM name is maintained in the table. So, the FM name can be changed dynamically and more than one FM can be called for different conditions.

There were two FMs called based on different conditions. Both of them are called dynamically. So, ideally I needed to make changes in both of them. The change was to add additional Importing parameter. Based on that parameter the FM A should behave differently. So, I added the parameter into FM A only. The output was not expected.

Simple Version

To make it more clear, I have create these two FMs:

  • ZTEST_NP_SQUARE_AREA – Get area for Square
  • ZTEST_NP_RECTANGLE_AREA – Get area for Rectangle

This is simple call for both of them. Note the parameters for both of the FMs.

Demo Program to call FMs Directly

DATA: lv_len    TYPE i.
DATA: lv_width  TYPE i.
DATA: lv_area   TYPE i.
lv_len = '4'.
    iv_length = lv_len
    ev_area   = lv_area.
WRITE: / ' === Square === '.
WRITE: / 'Length:', lv_len,
       /  ' Area:' , lv_area.
lv_width = '6'.
    iv_length = lv_len
    iv_width  = lv_width
    ev_area   = lv_area.
WRITE: / ' === Rectangle === '.
WRITE: / 'Length:', lv_len,
       /  'Width:' , lv_width,
       /  ' Area:' , lv_area.

If I call it like this – I get a dump – CALL_FUNCTION_PARM_UNKNOWN:

Direct FM call with unknown parameter Runtime Error

    iv_length = lv_len
    iv_width  = lv_width
    someother_param = sy-subrc   " doesn't exist
    ev_area   = lv_area.

Dynamic Version

Here is how the simple version of dynamic call. If you notice, I’m passing three parameters when I call the Dynamic FM using the CALL FUNCTION. FM ZTEST_NP_SQUARE_AREA has only one parameter. FM ZTEST_NP_RECTANGLE_AREA has two parameters. The third parameter doesn’t exist in any of the FM. I was expecting the Short-Dump, but no dump.

This how they are called dynamically. Note the parameters.

Dynamic FM call with Mystery Parameters

DATA: lv_len    TYPE i.
DATA: lv_width  TYPE i.
DATA: lv_area   TYPE i.
DATA: lv_fm_name TYPE tfdir-funcname.
  CASE sy-index.
    WHEN 1.
      lv_fm_name = 'ZTEST_NP_SQUARE_AREA'.
      lv_len = 4.
    WHEN 2.
      lv_fm_name = 'ZTEST_NP_RECTANGLE_AREA'.
      lv_len = 4.
      lv_width = 6.
  CALL FUNCTION lv_fm_name
      iv_length       = lv_len
      iv_width        = lv_width
      someother_param = sy-subrc
      ev_area         = lv_area.
  WRITE: / lv_area.

I tried to look for SAP Help for this behavior but didn’t find any.

My thoughts:

I think it was a good idea not to give short-dump on unknown parameters. As I don’t have to make change all the FMs which would be called by that dynamic condition to have this unused parameter. If it is required, it can be simply added in the FM where it is needed. No change required to the place where the FM is called dynamically.

What do you think?

Have you faced this type of scenario before? Or any other interesting behavior with FM calls?

Like It? Share!!

Don't miss an Update

Get notified of the new post, right into your inbox

Naimesh Patel{271 articles}

I'm SAP ABAP Consultant for more than a decade. I like to experiment with ABAP especially OO. I have been SDN Top Contributor.
Follow :

Explore all of his 271 articles.

Load comments


  • Hi Naimesh,
    have a look at the CALL FUNCTION addition “parameter_tables” to call the function module total dynamically!


    Demo report taken from SAP help

    TYPE-POOLS abap. 
    DATA: line     TYPE c LENGTH 80, 
          text_tab LIKE STANDARD TABLE OF line, 
          filename TYPE string, 
          filetype TYPE c LENGTH 80, 
          fleng    TYPE i. 
    DATA: func TYPE string, 
          ptab TYPE abap_func_parmbind_tab, 
          ptab_line TYPE abap_func_parmbind, 
          etab TYPE abap_func_excpbind_tab, 
          etab_line TYPE abap_func_excpbind. 
    func = 'GUI_DOWNLOAD'. 
    filename = 'c:temptext.txt'. 
    filetype = 'ASC'. 
    ptab_line-name = 'FILENAME'. 
    ptab_line-kind = abap_func_exporting. 
    GET REFERENCE OF filename INTO ptab_line-value. 
    INSERT ptab_line INTO TABLE ptab. 
    ptab_line-name = 'FILETYPE'. 
    ptab_line-kind = abap_func_exporting. 
    GET REFERENCE OF filetype INTO ptab_line-value. 
    INSERT ptab_line INTO TABLE ptab. 
    ptab_line-name = 'DATA_TAB'. 
    ptab_line-kind = abap_func_tables. 
    GET REFERENCE OF text_tab INTO ptab_line-value. 
    INSERT ptab_line INTO TABLE ptab. 
    ptab_line-name = 'FILELENGTH'. 
    ptab_line-kind = abap_func_importing. 
    GET REFERENCE OF fleng INTO ptab_line-value. 
    INSERT ptab_line INTO TABLE ptab. 
    etab_line-name = 'OTHERS'. 
    etab_line-value = 10. 
    INSERT etab_line INTO TABLE etab. 
  • steve oldner

    I’ve seen this in some of the the old ESS code. Didn’t take the time to ponder it thought. This is good to keep in mind!

  • Mohinder Singh Chouhan

    Hi Naimesh,

    Nice demostration of dynamic FM call.

    @ Enno, indeed I checked in firs ABAP POOLs are very own Smartforms, where preiview been called from
    SAP internal program RSTXSFPREVIEW , which takes runtime FM of smartform for preview.
    – code from program RSTXSFPREVIEW

    Zevolving ABAP Syntax Highlighter

        call function l_func
             parameter-table l_para[]
             exception-table l_except[].
      catch cx_sy_dyn_call_error.
        message s085.


  • Hello Enno / Mohinder,

    I’m aware of the fact that we can pass the Parameters dynamically. The point here is to show that when you call FM dynamically, the Runtime Environment doesn’t bother to check if all of the parameters which are sent from the caller are actually available in the FM or not.

    That being said, if you know all the parameters before but you don’t know which are relevant for that FM or not, do you really need to use the PARAMETER table to pass the parameters?

    I agree that PARAMETER-TABLE would be useful when you don’t know the parameter name at design time but you would have it at runtime.

    Naimesh Patel

  • fawcs

    Plus, you can always avoid an unexpected short-dump in the production system if the FM interface changed and someone didn’t test the changes enough ;)

    That’s really usefull, thanks Naimesh!

  • Basically, this behavior is built into Function Modules to support “RFC” calls . We can try calling any RFC function statically with Destination “NONE” and with undefined parameters to check this.

    In the same lines , the FMs have flexibility with respect to Exceptions and their subrc value.
    Either Static or Dynamic, You can also have code under EXCEPTIONS for some undefined exceptions.

    standard RFC exceptions:

               COMMUNICATION_FAILURE = 1
                SYSTEM_FAILURE        = 2 )

    Another case when we want to handle multiple exceptions in a similar way, we can also assign the same return value ,e,g

    exceptions with same return value

      exception1 =  2
      exception2 =  2 .
  • Hello Kesari,

    I don’t agree with the fact that the it is to facilitate the RFC calls. The same flexibility is not there when you have the direct FM call.

    Moreover, when the RFC FM is generated, it would generate this system program which would pass the required parameters to the FM call – as I have mentioned in RFC Calls: Function Module Parameter Passing

    Exception handling it would at the caller. We can set all the exception which we don’t want to handle to OTHERS = 1. This way the caller would deal with that value instead of the individual value. This behavior is different than passing the unkonwn parameter to the FM.

    Handle Exceptions as itself

        filename                      = 'C:temp123.txt'
        data_tab                      = itab
       FILE_OPEN_ERROR               = 1
       FILE_READ_ERROR               = 2
       NO_BATCH                      = 3
       INVALID_TYPE                  = 5
       NO_AUTHORITY                  = 6
       UNKNOWN_ERROR                 = 7
       BAD_DATA_FORMAT               = 8
       HEADER_NOT_ALLOWED            = 9
       SEPARATOR_NOT_ALLOWED         = 10
       HEADER_TOO_LONG               = 11
       UNKNOWN_DP_ERROR              = 12
       ACCESS_DENIED                 = 13
       DP_OUT_OF_MEMORY              = 14
       DISK_FULL                     = 15
       DP_TIMEOUT                    = 16
       OTHERS                        = 17.


    Handle Exceptions as OTHERS

        filename                      = 'C:temp123.txt'
        data_tab                      = itab
       FILE_OPEN_ERROR               = 1
       OTHERS                        = 2.

    Naimesh Patel

  • The topic of exceptions is added just as part of your question “Or any other interesting behavior with FM calls?” . And not necessarily to compare directly with the parameters. Did you try to add any non existing exceptions to check if it throws any error ?

    And my reference about RFC calls , is to to show case the ABAP Runtime interpreter where the definition of any executable component is not readily available. I checked your previous blog on RFC, where in you have shown the generated stubs at the time of call. That doesnt stop us in sending unknown parameters to an RFC function, statically(unlike in the original example) with NONE as the destination. Here i am referring to an RFC proxy where you just have the skeleton.

    But the topic is the behaviour of ABAP runtime ignoring the “unknowns” and i dont think there is any need for the ABAP engine to skip the dump if it is a pure “known” current system. thats why my earlier conclusion.

  • Hello Kesari,

    Clearly, I didn’t see your point for the exception. I was more thinking toward behavior between static call vs dynamic call of the FM.

    Regarding the Dynamic parameters, I agree that it is the same behavior as calling the FM Statically with Destination NONE. I tried to look for the documentation where it is mentioned on SAP help, but couldn’t locate any.

    Naimesh Patel

  • Naimesh , Thanks for sharing interesting topics all the time and i appreciate for giving time and opportunity for discussions in your website.

    The exceptions point which i was referring to is just to answer the below question:

    Q) Say, If i am using a standard SAP function module and handling the exceptions explicitly , and in one of the newer releases SAP has removed one or more exceptions(!) from the definition of the function module.

    Do i have to change all my custom programs ?

    A) No need, as there wont be any syntax or run time errors when your code uses some undefined/non existing exceptions in a “CALL FUNCTION”…

    And basically i believe the behavior of the ABAP runtime environment with respect to dynamic calls is a technical observation rather than a “Feature” initself . So we may not rely these observations for our “Design Decisions”. Hope you agree.

  • Hi there, just because we are talking about function modules…
    Did you know the following syntax??

    Zevolving ABAP Syntax Highlighter

      parameter = field


Comments on this Post are now closed. If you have something important to share, you can always contact me.

You seem to be new here. Subscribe to stay connected.