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.

13 Comments

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

      1. Former Member

        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. Former Member

    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. Former Member

        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. Former Member

    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. Former Member

    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. Former Member

    I worked on this scenario recently, Below are the possible issues/concerns that you may face,

    1. LIKE keyword is obsolete now. We can use TYPE keyword to declare Internal Table(Table Type in Associated Type)
    2. Getting NULL values in PI/PO error:

    a. To resolve this error, debug the RFC by keeping external break point in the RFC FM and by triggering it from PO RFC lookup – But to do this, you need to use same user ID for logging into SAP system and in the RFC channel that is created for the RFC lookup

     

    b. Usually the condition put in ABAP program above the SELECT query – Internal Table is empty or not – will not work when you call it from PO, but it works when you try to test from SE37, You can ask ABAP team to remove that condition

         Correction to above point:

           IF ITAB IS NOT INITIAL – will not work when you call from PO, but works in SE37

           IF ITAB[] IS NOT INITIAL – will work in both cases mentioned above

     

    c. Using the above two solutions, it should work. If not then you can try to get more authorizations for the User ID that you are using in the channel

     

    (0) 
    1. M Jay

      Hi,

      I have very similar requirement where i need to read data from a custom table i created for LineItems. I would like to see how the Source code for this RFC FM will look like so that i can write mine.

      Thank You.

      (0) 

Leave a Reply