Skip to Content

This question is too interesting to just ask in ABAP General

The fucntion SWE_EVENT_CREATE has an obligatory importing parameter OBJKEY that comes inbetween the parameter OBJTYPE and EVENT.

When we call this function on an ECC 5 box from an SCM 5.1 system, we DO NOT EVEN HAVE TO MENTION OBJKEY in the call, and the function works fine. 

 Whereas when we call the function locally on the ECC 5 box, we have the mention the objkey and supply an empty variable of type SWEINSTCOU-OBJKEY.

Why should this be?

What does it tell us about how the RFC interpreter processes parm strings ?

You must be Logged on to comment or reply to a post.
  • Ultimately it’s up to the called function to decide what to do if something isn’t passed. I have always treated the optional/mandatoty flag as a bit of documentation. It helps when using the ABAP editor to build a call structure using the Pattern button and that’s about it.
    • Hi Mike,
      I hope I’m not misunderstanding you completely – but you are aware that leaving out a parameter marked as obligatory in a local function module call leads to a short dump? So once the flag “obligatory” is set, the system acts (and punishes the caller) before the function module’s implementation has a chance to query its state of mind. 😉
      What was new to me was the tolerance the system exerts when the caller is remote – I listed some of it in the other comment.
      Anyway, sorry if I got you wrong and pointed out the totally obvious.
      • Hi Thorsetn
        No, you didn’t misunderstand me, I was wrong. I confused using the SE37 test tool with leaving a parameter out. The test utility is smart enough to pass across missing values and as you poiunt out, using NONE also works OK.
  • Hi David,
    interesting question indeed. I conducted a small experiment to find out what happens here.
    I created an RFC-enabled function module with a number of differently-typed parameters, some optional and some obligatory.
    The function module gives back a table reporting which parameters it saw as supplied, initial, and the values it received.
    Then I tried it calling the module with a number of different parameter sets.
    When calling it locally, it behaved precisely as expected.
    When calling remotely (I simulate this by calling it locally with DESTINATION ‘NONE’), I made the following observations:
    * Any additional, non-matching (by name) parameters given will be simply ignored, not causing an error.
    * Parameters with a matching name but mismatching type behave like a “move”: from correct implicit type conversion (numc10 > string) via garbled results (int > string) up to shortdumps (string > int) anything can happen.
    * Obligatory as well as optional parameters not supplied by the caller will be treated as supplied but initial by the function module.
    • Hi Thorsten –

      I hope they pay you a lot as a software architect – if you’re as conscientious on your job as you are here at SDN, you deserve every penny.

      The part of your answer that actually explains what we saw is, of course, the last line:

      “Obligatory as well as optional parameters not supplied by the caller will be treated as supplied but initial by the function module.”

      But the rest of the answer was equally interesting.

      Best regards

      • So the conclusion is that it’s always safer to call the FMs remote even they are supposed to be used as local (local RFC can be figured out based on logical system of the current client)? 🙂
        • Hi Peter,
          This conclusion would be a bit daring. 🙂 If you call an FM in any destination, even ‘NONE’ (spares you the trouble of looking up the system’s own RFC destination), it is processed in a new internal mode, which means:
          – The new internal mode different instances of every program
          – This means that the state of any function group, static attributes, memories of main programs that may be accessed through external performs is initialized “in a parallel universe” with respect to the caller’s internal mode; this concerns most for example the BAL and the memories of function groups that bundle data for updates IN UPDATE TASK and make them transparently available to callers according to the BAPI programming paradigm.
          – Locks are not inherited
          – Commits and Rollbacks (both at database and LUW level) from the called FM’s internal mode have no effect on the caller’s internal mode and vice versa.

          The last effect is actually quite useful if you know exactly what you’re doing because it allows you to open an independent transaction/LUW that is isolated from the rest of your system state.

          * Suppose you want to create a log entry in update task for a rollback and you want to prevent this very rollback from affecting the log.
          * Or suppose you want to start an error workflow in update task that is not affected by a rollback work.
          * Or suppose you want to call a function module that you know or suspect causes commits or rollbacks which would mess up your own transaction handling (say, because you are working with OO transactions of the ABAP Object Services).
          Hey, I think I should blog about it. It’s probably a topic a lot of people haven’t paid much attention to.

  • Hello David,

    We don’t get the error when we call the RFC FM using the syntax “CALL FUNCTION fm_name destination dest_name”, because System generates one more program with one subrotine when we create the FM as RFC. RFC Framework calls this generated subroutine to call our RFC FM. This subroutine passes all the parameters(including the Obligatory ones) to the FM.

    E.g. I have created a RFC FM as ZTEST_NP_RFC. System created a program LZTEST_NP_RFCV01(Lfm_nameV01) with subroutine ZTEST_NP_RFC (same as the FM name) in the same Function Group.

    Put the breakpoint on your FM and do the System Debugging. In the calls you would be able to see that system calls the subroutine and then calls the FM.

    Naimesh Patel

    • Hi Naimish –

      Thanks for contributing even more information to this thread – your contribution not only amplifies but also explains the result that Thorsten observed in his experiment.  This explanation is exactly what I hoped to get by posting the question.  (BTW, I’m really glad you have the time to do investigations like this … can I work where you’re working?)

      Anyway, I hope that Craig/Mark happen to read this thread, because it’s the perfect example of how SDN multiplies individual expertise by at leaet one order of magnitude

      Very best regards

      • Hi David,
        I do this kind of work during my spare time, at home on my living room sofa. That’s where I am most productive. I only show up at work to make people *think* I produce the occasional result at my desk.
  • Now that we know from Thorsten and Naimish why it happens the way it does in remote calls (as opposed to local calls), the deeper question is whether it SHOULD work this way in RFC’s, i.e. should the generated subroutine supply missing parameters?

    It seems to me a case can be made either way, and I’d love to hear arguments on both sides.

    • I guess the main purpose of this Parameter mapping through the generated Subroutine is for the error handling. If RFC FM is being called from outside of SAP and this parameter missing runtime error CALL_FUNCTION_PARM_MISSING occurs, then it may leave the RFC framework in the error status.

      Naimesh Patel

      • As it well should, Naimesh, as it well should !!!

        I’m just kidding – I can see both points of view.

        BUT – I think that in general, it’s very dangerous for system software to make decisiond about the intentions of applications.  How does the system software know that the missing parameter SHOULDN’T have been supplied ?

        • I have not coded in a while, but this topic created a lot of interest in my mind.

          I think the way it behaves is consistent.
          In local calls, developers and run time have visibility to full interface attributes so it is easier to react if a needed parameter is not supplied.

          In remote calls, the remote system in general does not know the implementation as well as the local system, and hence it is safer to just pass an initial value so that rest of the processes can contiue if possible.

          In any case, the remote function implementation internally should know what to do if a parameter is missing and should send appropriate messages back in export.

          • I agree with Vijay and suspect that the behaviour we are observing serves the robustness of cross-system scenarios.
            If two the releases of systems speaking to each other via RFC differ slightly and the FM’s interface in the remote system has changed a bit, most processes will work better this way:
            The remote function module has the chance to produce a meaningful error message in a BAPIRET2 table if it sees an obligatory parameter as supplied but initial.
            In the local call scenario, you can set much higher standards: Code Inspector and Extended Syntax Check have access to the called FM’s interface and usually it hurts less to have a tight release coupling of two modularization units residing in the same systems. Quite likely, the will belong to the same application or relations that are already tightly coupled.
            In the remote scenario, this tight coupling can not be assumed, so it’s better to allow the two components to “wiggle and waggle” a bit. 🙂
          • Thanks Thorsten – this makes me feel a lot better. I was in fact worried whether some one would post something along the lines of “who let this guy post under an ABAP blog?”.
  • Hey Thorsten, Naimish, Vijay-

    An ex-colleague asked me this exact question today, and I was able to answer it, thanks to your sterling work here 6 years ago …

    • Hi David,

      Thanks for making me revisit this post 6 years later. I had forgotten all about it and didn’t even remember the little research from back then, so I re-learned something today. 🙂