Lookup API - SPRAS value returned is not correct

[Former Member]

Hi All

We are using the lookup API of XI to make a lookup in the SAP system and return values such as LAND1, and SPRAS. SPRAS has 2 kindoff value, one is the display value which is a 2 character value, and then the actual value which is a single character value. Internally a conversion routine takes care of converting this 2 character value to single character. For instance the countrykey of Poland is PL and its display SPRAS value is PL and actual value is L.

While unit testing we get the correct value of 'L', but when we do the integration testing we get the display value of 'PL'. This is a problem we face when we use the Lookup API. But when I use a JCO call to make a lookup, I get the correct value being returned.

This is a weird behavior, I am not sure if I overlooked something while using the lookup API. I even tried changing the function module to return a single char value, but still the wrong value is being returned with the lookup API. Could it be an issue with the Lookup API ??

I used the code given in the following weblog,

/people/francesco.bersani/blog/2007/03/05/data-lookup-optimized

Any suggestion friends.

regards

Sameer

[bhavesh_kantilal · Accepted solution]

My guess is the problem is in the RFC module. Maybe the transportation of the RFC module from your Dev to QA had some issues.

Try exectuing the RFC from SE 38 in your QA 's R3 system.

Also, another quick check would be to make some dummy change on the receiver rfc adapter and activate it so that the RFC Metadata gets loaded when you run your interface the next time. Maybe some issue with the RFC metadata.

Regards

Bhavesh

[Former Member · Accepted solution]

Bhavesh

Thanks for taking time to respond.

I have made the changes in the rfc adapter and also sent a cache notification.This is something that i follow everytime i change the FM. I have tested it at the dev box and qa box and it returns the wrong value in both. But when I use a direct JCO call it works fine, it is only with the SPRAS value, everything else seems ok.

I even executed the FM from SE37. It returns the 2 character display value, but thats fine (when I debug it I can see the correct single character value), because when I call the same FM using a JCO call it returns the correct value.

I do not want to use a JCO lookup just for this single value and lookup API for the rest. But I wanted to exhaust all other possible options before I go ahead with this approach.

regards

Sameer

[bhavesh_kantilal · Accepted solution]

Sameer,

Maybe a problem with the Parsing which parsers and takes the value out of your response? have you checked this as well.

Any clue on where this P in the PL is coming from?

Regards

Bhavesh

[Former Member · Accepted solution]

Basically this value of SPRAS, gets populated in a field called LANGU in the IDOC. And LANGU is of size 1, as a result it truncates the L from PL.

And actually it is nothing to do with P of PL, because L is the internal representation of PL.

If you go and execute the following conversion FM, CONVERSION_EXIT_ISOLA_INPUT and pass in PL as input, it will return L. Similarly if you pass DA as input it will return K.

In the function module, I had declared the export parameter field of type SPRAS, which internally has this conversion routine.

When I unit test the Lookup API, it works fine by returning the correct converted value, but when I do an integration testing, it return PL instead of L.

But the same thing works fine in both unit and integration testing with direct JCO call.

Am I sounding a bit confusing here ?? Apologies if i do so, but please do let me know if you have not understood the problem, and I will try to put it in a better way hopefully

[bhavesh_kantilal · Accepted solution]

Sameer,

I got the issue .

The fact that this works on Dev but doesnt work on QA ( dev returns just L , QA returns PL ) , has to have something to do with the RFC module.

A few check points I would suggest ( guess you would have gone through most of them ),

1. Check the response XML . Check what the field contains. f the Response XML contains PL then it implie that this issue is with the RFC. I know this works with a JCO call, but it has to be an issue with the RFC.

2. Restart the J2EE engine. Maybe the cache is not getting refreshed and so the RFC adapter metatata are not getting refreshed as well.

Regards

Bhavesh

[Former Member · Accepted solution]

Bhavesh, thanks for patiently taking time and answering my queries, I really appreciate your time and effort. Keep up the good job, people like you make SDN a preferred forum for many like us.

Well the finding I made is a bit weird. In my map there are 2 fields for which I should make a lookup. I need the countrykey and languagekey, as both the values are fetched from the same table T001, I wrote a single function module which returns these 2 values as output parameters.

But the lookup fails whenever there is a simulataneous call to the same function module from the same map, the value of the first field is passed to the second field as well.

So i created 2 separate function modules, one to return the country key and other to return the languagekey, and the results are correct. So it had nothing to do with my earlier assumptions, where I felt that the SPRAS was getting converted.

I am a bit surprised at this behavior, does this mean that a generic function module cannot be written or am I doing something wrong. I use separate containers to store the result.

Any inputs in this regard ??

[bhavesh_kantilal · Accepted solution]

Sameer,

Using a single Function Module should not be an issue at all.

Maybe there is some problem with,

A) Either the logic of the Function Module written in R3

B) Logic of your LookUp Code.

It would be very difficult to say why you are facing this issue without looking at the code and the RFC but the way I see look up's if the FM code is valid and the Lookup Code is as per the corresponding Logic there should be no issue at all.

I would suggest that you use the same test data that is causing the issue to test the FM in your R3 system and check what it returns . Is the output as expected. If yes, then time to look into your LookUP code.

Add Trace statements and use this for debugging. Have found that they really help in real time to understand what is going wrong and why.

Regards

Bhavesh

PS : Thanks for those encouraging words . It is also nice to see detailed questions on SDN that make life easy for everyone.