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.
Preface
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'. CALL FUNCTION 'ZTEST_NP_SQUARE_AREA' EXPORTING iv_length = lv_len IMPORTING ev_area = lv_area. WRITE: / ' === Square === '. WRITE: / 'Length:', lv_len, / ' Area:' , lv_area. lv_width = '6'. CALL FUNCTION 'ZTEST_NP_RECTANGLE_AREA' EXPORTING iv_length = lv_len iv_width = lv_width IMPORTING 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
CALL FUNCTION 'ZTEST_NP_RECTANGLE_AREA' EXPORTING iv_length = lv_len iv_width = lv_width someother_param = sy-subrc " doesn't exist IMPORTING 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. DO 2 TIMES. 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. ENDCASE. CALL FUNCTION lv_fm_name EXPORTING iv_length = lv_len iv_width = lv_width someother_param = sy-subrc IMPORTING ev_area = lv_area. WRITE: / lv_area. ENDDO.
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?
Loading ...
Hi Naimesh,
have a look at the CALL FUNCTION addition “parameter_tables” to call the function module total dynamically!
Regards
Enno
Demo report taken from SAP help
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!
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
Thanks
Mohinder
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.
Thanks,
Naimesh Patel
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
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
to
Handle Exceptions as OTHERS
Thanks,
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.
Thanks,
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
🙂