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.
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 🙂
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:
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;
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;
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.
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