PI 7.1 EHP1 RFC Lookup- Issue

[justin_santhanam]

Friends,

I'm seeing one strange issue in RFC Lookup behavior in my PI 7.1 EHP1 . Please give me some ideas for the same

Please see the below image for what I have done and what I'm seeing in the display queue.

http://www.flickr.com/photos/8764045@N06/4642237515/sizes/o/

To make it more simple - When I click on the Display queue on RFC lookup, I can see some 20 values with context changed. I removed my context and passed it to the UDF. When I check the input length in the UDF it's always giving 1, even though the display queue gives me 20 values.

Any ideas?

-Raj.

[Former Member · Accepted solution]

what is your udf code?

[justin_santhanam · Accepted solution]

Sarvesh,

There is no problem with the UDF. Anyways for your reference, see below

Execution Type - All Values of Queue

MappingTrace trace = container.getTrace();
for(int i =0; i<a.length;i++)
{
result.addValue(a<i>);
trace.addInfo("inside loop");
}

If I execute the above code, I'm getting only one output.If you see my image attached in the above thread, I can see only first value as output.

-Raj.

[Former Member · Accepted solution]

If I am not wrong then this is because of the occurrance of the target field. For time being do the same mapping to a node which have 0..unbounded occurrance.

[justin_santhanam · Accepted solution]

Any ideas on this one?

[Former Member · Accepted solution]

Sorry I misunderstood the question.. as you said "When I check the input length in the UDF it's always giving 1" So the problem is in the queue generated by RemoveContext or in the UDF.

Well, I am not 100% sure but, it seems the <null> value in the top of the queue is creating the problem, usually we get "SUPPRESS" in the top and end of the queue. So just to confirm this, create a queue which contains the "Suppress" and then pass it your UDF.

[stefan_grube · Accepted solution]

> If I execute the above code, I'm getting only one output.If you see my image attached in the above thread, I can see only first value as output.

This is really hard to believe. I have use that kind of UDF a lot and it always worked fine.

Could you post a picture with "display queue" of your UDF?

[justin_santhanam · Accepted solution]

Stefan/Sarvesh,

Thanks for your replies . Please see the below snapshots for complete picture.

UDF code & Properties -http://www.flickr.com/photos/8764045@N06/4643880555/sizes/o/

RFC Lookup Properties -http://www.flickr.com/photos/8764045@N06/4643880541/sizes/o/

Display Queues on UDF and RFC Lookup -http://www.flickr.com/photos/8764045@N06/4643883271/sizes/o/

I truly appreciate all your help on this.

-Raj.

[stefan_grube · Accepted solution]

I do not see anything wrong in your UDF.

I have no idea why this does not work.

[Former Member · Accepted solution]

deleted

Edited by: Daniel Rexter on May 28, 2010 12:01 PM

[Former Member · Accepted solution]

deleted

Edited by: Daniel Rexter on May 28, 2010 12:01 PM

[Former Member]

Hi Raj,

there might be an issue because the first value you get is empty (this might be the header line).

Can you check what happens, if you ignore the first line? Something like if (!land1.equals("")){...

I've had a similar issue, altough i used a JCO Lookup in a UDF:

//get Table

JCO.Table valueSetMyTable = function.getTableParameterList().getTable("MY_TABLE");

//ignore the first line

if (!valueSetMyTable.equals("") && !valueSetMyTable.isEmpty()) {

myValue = valueSetMyTable.getField("MYVALUE").getString()

regards,

Daniel

[Former Member]

sorry for posting this several times..something went wrong here...

[justin_santhanam]

Daniel,

Thanks for your reply. As I said earlier, I'm not using any codes for lookup.I'm using the standard Graphical RFC lookup.

-Raj.

[Former Member]

BTW, Raj have you tried with some other source node which have 5 to 10 values and then map that source to the UDF to see if it still shows the same results.

[justin_santhanam]

Hi Sarvesh,

Yes I tried that. This way I'm ruling out there seems to be an issue with UDF. So no problem with UDF (not mine, but in general). The issue seems to be with RFC lookup.

-Raj.

[stefan_grube]

Does the effect occur also in testing the whole mapping?

[justin_santhanam]

YES, Stefan. The issue persists even If I run the whole mapping program.

-Raj.

[Former Member]

Hi Raj,

i know you are not using a UDF, i've just put in my code as an example to show that i had an issue when the first return value is empty. I think even if you use the standard RFC Lookup, there might be an issue in the following function if the first value you lookup is empty / null.

regards,

Daniel

[stefan_grube]

The point is a little complicated.

It has to do with the behaviour of constants.

you assign the function to root node which has occurrance 1..1

on source side you work with constants.

It is hard to say, how the graphical mapping tool workd with constants, but I have noticed, that you always need a trigger from source to have an accurate result.

In your case the target node has occurance 1..1, so only one entry of the queue is processed, even when the RFC returns more values.

I have no solution how you can manage this. Maybe you could add a collapseContext or copyValue at the end, but I have not tried this yet.

[justin_santhanam]

Stefan,

You rock! You are absolutely correct. I tried to give the input from the source xml and the behaviour is completely changed- I'm getting what I expected. So I believe the problem is to do with constants.

Since the values which I've to pass to RFCLookup function is not coming from the source, I'm still stuck up here. I opened up an OSS ticket for the same. Will update you all once I get any response.

-Raj.

[Former Member]

> Since the values which I've to pass to RFCLookup function is not coming from the source, I'm still stuck up here. I opened up an OSS ticket for the same. Will update you all once I get any response.

A temporary solution could be using the small udf instead of constants. Create udf without any arguments and just return the output.

[justin_santhanam]

Sarvesh,

Thanks, it's working if you pass it through UDF instead of constants. I'll keep the thread open and will update my response based on the OSS Ticket.

Stefan/Sarvesh/Daniel - I'm so much thankful to you all in actively participating in the thread to solve the issue. I hope seeing this thread everyone can determine how to use the RFCLookup in PI 7.1 until we get a resolution from SAP.

Best Regards,

Raj.

[justin_santhanam]

Dear All:

SAP has fixed this issue, please see the below comments from SAP.

The patch containing the fix is now released to SMP.
Patch Details:
SAPXIESR04 patch #14 (SP-level #04)
Kindly apply the patch and let us know the result after testing.

Thanks!

[Former Member]

deleted

Edited by: Daniel Rexter on May 28, 2010 12:01 PM

[Former Member]

deleted

Edited by: Daniel Rexter on May 28, 2010 12:01 PM

[Former Member]

deleted

Edited by: Daniel Rexter on May 28, 2010 12:00 PM