ABAP Trapdoors: R-F-Conversion on a STRING
Welcome back to another ABAP Trapdoors article. It’s been a while – I’ve posted my last article in 2011. In the meantime, I’ve collected a number of interesting topics. If you’re interested in the older articles, you can find the links at the end of this article.
A few weeks ago, I had to code some seemingly simple task: From a SAP Business Workflow running in system ABC, a sub-workflow with several steps had to be started in another system, or even a number of other systems. Since a BPM engine was not available, I decided to use simple RFC-enabled function modules to raise workflow events in the target system. The sub-workflows can then be started via simple object type linkage entries. While this approach works quite well for my simple scenario, I ran into an altogether unexpected issue that took me quite a while to figure out.
There are two function modules to raise the workflow events: SAP_WAPI_CREATE_EVENT and SAP_WAPI_CREATE_EVENT_EXTENDED. In my case, I used the extended function module because I was working with class-based events. So the call basically was
CALL FUNCTION 'SAP_WAPI_CREATE_EVENT_EXTENDED' DESTINATION l_rfcdest EXPORTING catid = 'CL' typeid = 'ZCL_MY_CLASS' instid = l_instid event = 'MY_EVENT' ...
To my surprise, it did not work – the system kept telling me that the event M does not exist. After spending a considerable time debugging and scratching my head, I finally identified the issue. Since it can be tricky to reproduce this particular issue, here is a very simple function module to demonstrate the actual problem:
FUNCTION ztest_rfc_echo. *"---------------------------------------------------------------------- *"*"Lokale Schnittstelle: *" IMPORTING *" VALUE(I_INPUT_VALUE) TYPE STRING *" EXPORTING *" VALUE(E_OUTPUT_VALUE) TYPE STRING *"---------------------------------------------------------------------- e_output_value = i_input_value. ENDFUNCTION.
(If you want to try this for yourself, make sure that the function module is RFC-enabled.)
This is no more than a simple value assignment – Text goes in, text comes out, right? Let’s see. Here is a demo program to check it out:
REPORT ztest_rfc_conversion. DATA: g_value TYPE string. START-OF-SELECTION. CALL FUNCTION 'ZTEST_RFC_ECHO' EXPORTING i_input_value = 'This is a C literal' IMPORTING e_output_value = g_value. WRITE: / '1:', g_value. CALL FUNCTION 'ZTEST_RFC_ECHO' EXPORTING i_input_value = `This is a STRING literal` IMPORTING e_output_value = g_value. WRITE: / '2:', g_value. CALL FUNCTION 'ZTEST_RFC_ECHO' DESTINATION 'NONE' EXPORTING i_input_value = 'This is a C literal' IMPORTING e_output_value = g_value. WRITE: / '3:', g_value. CALL FUNCTION 'ZTEST_RFC_ECHO' DESTINATION 'NONE' EXPORTING i_input_value = `This is a STRING literal` IMPORTING e_output_value = g_value. WRITE: / '4:', g_value.
In this program, the function module is called twice within the same session and twice starting a new session, using both a character literal and a string literal (note the difference between ‘X’ and `X`!). And the output is:
As you can easily see, the character literal is chopped off after the first character, but only if the function module is called via RFC. The same thing happened in my original program since the parameter EVENT of the function module SAP_WAPI_CREATE_EVENT_EXTENDED is of type STRING.
I considered this a bug, especially since neither SLIN nor the code inspector warned about this issue. As a good SAP citizen, I created a SAPnet ticket. After a lengthy discussion, I was told
There is no “implicit conversion” in RFC, therefore application need to adjust(or choose) a proper data types for calling/receiving RFMs.
In the end, this problem is very similar to the one explained by Jerry Wang in his blog a few weeks ago – another trapdoor in the development environment you constantly have to keep in mind when doing RFC programming if you want to avoid being reduced to a single character with a lot of trouble…
Older ABAP Trapdoors articles
Thanks for sharing, didnt know that. Another thing that drives me crazy in this String/Char incompatibilities. A c8 does not fit in an c6, thats clear. But a c6 does fit in a c8, but is not accepted when it comes to function modules/methods parameters. And both fit in a string, but always you do have to do such nasty conversionen with helping variables.(I know theres a small help is available when it comes to methods: csequence/clike, but thats not helpful if it's not your method)
On the other side, floatvar = '1234.5' is accepted without a warning 😡
floatvar = '1234.5' is not only accepted, it's the only (?) way to specify that value because the dot outside of a literal is used as the end-of-statement token.
You're right, its the only way. But there is no complaint when you said decimals 2 and have 3 decimals in the constant 🙂
Thanks for your article - I just had the "pleasure" to meet this phenomenon in our freshly upgraded system. Since this system is on SAPKB74008, only the first letter of the literal 'ressourcen' - the 'r' - is passed to the RFC parameter of type STRING. This is new, it used to work before (I assume that the implicit default data type into which type C literals are moved internally has been minimized from formerly 40 characters or so - to CHAR1).