Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor

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:-


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!

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.

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.

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.


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! :cry:

Labels in this area