Skip to Content

The Requirement:

1. Lookup for a value in ECC and populate the target with the result

2. The input data has the node (that contains the input field to the RFC lookup) with occurrence as Unbounded

3. The target node (that holds the target field) is Unbounded

 

The Ideal Design:

The requirement is fairly easy. You can do a simple lookup per input value and retrieve the data. But when the input field occurrence is more than say 1000, it means there is a huge overhead in terms of having to do that many lookups. (Imagine 1000 RFC calls in one single execution of the mapping)

So the RFC lookup should ideally take multiple values as its input and respond back with multiple values.

 

What we can do:

1. Design a RFC which will have a Table parameter.

image

Note: The structure referred has three fields (optional fields). The first two fields can be used as input and the third field is the corresponding output. In this example, only the postcode field is being filled.

2. Use the RFC in the RFC Lookup function.

The trick here is to design your mapping so as to have a single call initiated instead of multiple calls. In PI Terms, that means you will have to play around with the context. Sounds easy, but we all know playing around with contexts can be a pain and in a way fun 🙂

image

For the RFC to be execute only once, we will have to create the complete RFC request structure (multiple item nodes) at one go, initiate the call, get the response and close the accessor.

So the logic for the mapping would be to replicate the ‘Item’ node of the RFC and provide the input value to each corresponding Postcode field of the Item node.

Display Queue of the RFC lookup Function:

image

What the above means is that there is one call, with 12 Item nodes each containing a Postcode as input.

On execution, with the trace level as ALL you would be able to see the RFC request being build as we expect it to be;

image

 

The complete Log (for the RFC request being build and receiving the response in one single call) can be seen here;

 

RFC Communication channel log:

I executed the mapping 5 times at different intervals. The log only shows 5 RFC calls made;

image

Conclusion:

Designing the RFC lookup to make a single call can improve performance considerably. Thus when you have a scenario which deals with multiple inputs (multiple fields i.e unbounded nodes), the RFC should be developed to have table parameters and the graphical mapping designed to make the right call.

 

Credits:

For the ABAP code for the RFC to work – Kathirvel Balakrishnan, a genius when it comes to code in ABAP

For the graphical mapping – I was too lazy to do that 🙂 Thanks to Madhav Poosarla (one of the most dedicated colleagues I have worked with) for fitting in the pieces

To report this post you need to login first.

11 Comments

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

      1. Sathish V

        I have to pass multiple values to the RFC and get one single output. I have declared my input as a table and exporting parameter as a table type too. RFC alone works fine but the look up in PI failed. It gives me null value.

        (0) 
  1. Abhishek Paul

    Hi Shabarish,

    Could you please mention how are you passing the fields from PI to the RFC, i mean to say are the fields being sent as STRING to ABAP FM?

    Coz in ABAP, I can’t take STRING as table parameters.

    As I am using mass RFC lookup in a intermediate step which is generating String ,so String value going to the FM as input and that does not match. coz my FM’s table parameters are like this:


    CURR FCURR_CURR CUKY 5 0 From currency
    EXCH_RATE CHAR20 CHAR 20 0 Char 20

    my input is CURR and return should be EXCH_RATE. So in response also its not String so its making issue.

    Please suggest how I can avoid this and use RFC Lookup in one go for a queue input.

    (0) 
      1. Abhishek Paul

        Hi Shabarish,

        I need you help. I used the same approach, sent a table as input and expecting the return as table. But I am getting null in return i.e queue of null.

        In RFC communication channel I see that its hitting the RFC function module and its ok.

        Following the report of the RFC channel in RWB:


        30.05.2012 15:31:56 Information RfcAdapter received a synchronous message. Trying to send sRFC for ZEXCHANGE_RATE.
        30.05.2012 15:31:56 Information RfcAdapter received a synchronous message. Trying to send sRFC for PIREPUSER.

        So what you think could go wrong…for which I am getting null as return. But the same values giving proper result when I run that from SE37.

        (0) 
  2. divyesh vasani

    read little late 🙂

    Nice one Shabarish.

    In our last scenario, we used hashmap to make one single call and put in hashmap and retrieve later as on required.

    —Divyesh

    (0) 
  3. Sathish V

    Thanks for the document. I tried this way but my look up does not work fine. I have to pass multiple values to the RFC and get one single output. I have declared my input as a table and exporting parameter as a table type too. RFC alone works fine but the look up in PI failed. It gives me null value.

    (0) 
  4. Bibin VS

    Thats a nice blog. Is Table parameter allowed in ABAP Function Module. Saw in few threads that Table Parameter has become obsolete now.

    (0) 

Leave a Reply