on 06-23-2006 1:39 AM
Hi,
I am running into a strange problem invoking a custom RFC from a .NET application. I would appreciate it if someone has any insight into it.
The steps to call the RFC are straightforward:
1. Open the connection to SAP server
2. Make the call
3. Close the connection
As you can imagine, the code is also quite simple.
In my simulation program, I have a button on a UI form that one can click and execute the above steps.
The problem I am running into is that, on multiple calls, sometimes the parameter values that show up on the SAP side are not right. When the input parameter (a structure) is viewed in the ABAP debugger, the field values are all getting exchanged. For example, first name field contains values for the last name. Also, some fields that are supposed to have values do not have any.
Just before the RFC call is made, when we look at the structures on the .NET side, the field values are the way they are supposed to be.
I have not been able to establish a pattern. Sometimes, it takes two clicks to reproduce this problem. Sometimes it takes five.
One of the team members thinks that this starts occurring right after one call fails for some valid reasons. However, I am not yet convinced.
Having written many custom .NET applications using RFCs an BAPIs, I am fairly conversant with the technology. However, this one just baffles me. It appears something is getting messed up at the RFC layer itself. Does anyone have any idea on what could be happening?
Thank you in advance for your help.
Pradeep
We have seen this effect in .NET Frameworks 2.0 in conjuction with using reflection. Does this also apply to you?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Indeed this is interesting .
The problem is caused by an incompatible change from .NET Framework 1.1 to 2.0. Howerver, the documentation on the 1.1. API was not clear enough to decide if the incompatible change was adequate or not. Now in detail:
NCo runtime uses the reflection API Type.GetProperties to read and cache all properties of a Proxy structure. NCo assumes that the order of the returned properties is the same on each call and especially that it is the order of the properties as they appear in source code. This was the behavior in .NET 1.1. It has changed in 2.0, see e.g. the internet forum discussion in http://www.thescripts.com/forum/thread455492.html .
Calling Type.GetProperty(<PropertyName>) or Type.SetProperty(<PropertyName>) in your code moves the mentioned properties up in the list returned by Type.GetProperties() later inside of NCo.
We found the following work-arroud:
When using late-binding, call a dummy Type.GetProperties() before any GetProperty or SetProperty.
User | Count |
---|---|
83 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.