Skip to Content

Confession: I HATE using the graphical RFC Lookup function!

Ok, ok… maybe that was a little too strong. In general I try to avoid using RFCs wherever possible due to the lack of trace/logging in the called system.

Even though the graphical RFC Lookup function has been available since PI 7.1, it has been tolerable at best, buggy at worst! There must have been countless times where I’ve executed “Display Queue” on the function only to get different results on each occasion even though everything remains the same. It would seem as though there is some cache between supposedly independent calls to the RFC. On other occasions, the input values from the mapping just don’t get transferred to the RFC parameters (viewed while debugging the RFC call) for unknown reasons. I get to the point where once I get the RFC lookup to work correctly, I am very hesitant to make any future changes to that portion of the mapping.

However, one of the nastiest bugs I’ve encountered while using the RFC lookup function is one that causes infinite execution of the RFC. This bug is documented in SAP Note 1674730 with the following description:-

Symptom

Infinite number of calls are being triggered to an RFC from a standard RFC lookup function used in message mapping. This can cause memory issues and increased CPU utilization.

Granted that it is possible to avoid the pre-requisites that trigger this bug, but this is a high-impact bug that can cause one message/interface to bring down an entire system! It is bewildering to me why there is no patch for this, and the solution in SAP note only suggests to prevent the problem from happening.

When this happens, you can see in the workload statistics of the server (via tcode ST03N) that the RFC calls are insanely high!

/wp-content/uploads/2014/05/rfcstats_446497.png

Well, life goes on and we just have to find a workaround to prevent this from happening….

To do this, we first need to know what conditions trigger this bug.

More often than not, this happens when the RFC lookup occurs at the item level of the mapping, and we want to optimize it into a single call instead of multiple calls. Then the bug is triggered if the below condition is met:-

Number of values in Parent node is less than number of contexts in Child nodes

Following is an example using the function module SALERT_CREATE. It has a TABLES parameter IT_CONTAINER which allows unbounded input entries. This structure contains 5 fields.

/wp-content/uploads/2014/05/func_446515.png /wp-content/uploads/2014/05/structure_446516.png

The corresponding structure in the graphical lookup is shown below. Over here, item, ELEMENT and VALUE are configured as input parameters to the lookup function.

/wp-content/uploads/2014/05/param_446517.png

item is the Parent node, and ELEMENT & VALUE are the child nodes.

Therefore, we need to ensure that the number of values in item cannot be less than the number of contexts in ELEMENT & VALUE.

Incorrect Correct
/wp-content/uploads/2014/05/bad_446520.png /wp-content/uploads/2014/05/good_446521.png

Number of values in item = 3

Number of contexts in ELEMENT = 5

Number of contexts in VALUE = 5

Number of values in item = 5

Number of contexts in ELEMENT = 5

Number of contexts in VALUE = 5

The incorrect entry on the left meets the trigger condition for the bug and the SALERT_CREATE RFC will be executed infinitely! 😥

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Abhishek Ranjan

    Hey Eng,

    A very informative blog. It is very much possible to miss on such a concept during build. You elaborated it very nicely. Thank you.

    Regards,

    Abhishek

    (0) 
    1. Eng Swee Yeoh Post author

      Hey Abhishek

      Thanks for the feedback – if only SAP would fix this, then missing this during build won’t cause such a disaster! 😉

      Rgds

      Eng Swee

      (0) 
  2. vinay mittal

    I always prefer RFC look ups for which i can write the code in ABAP in ECC and call them in PI via a UDF i hate the graphical function its unreliable and cannot be controlled and has less visibility thanks for such a informative blog

    (0) 
  3. Sri _PI

    Hello Eng,

    Thanks for the informative blog.

    While running my mapping with the RFC lookup(single stack scenario),I tried looking at ST03N statistics,but couldnt find the parameter ,RFC Function Module(in RFC Server Profile)– in ECC system.

    How to check this in case of single stack scenarios?Can you help me?

    Regards,

    Sri

    (0) 
    1. Eng Swee Yeoh Post author

      Hi Sri

      ST03N is supposed to be executed on the ABAP side of PI, so this is only valid for dual stack system. I am not sure if there is an equivalent in single stack system, maybe you can check if there is anything in NWA.

      Rgds

      Eng Swee

      (0) 

Leave a Reply