468,257 Members | 1,419 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,257 developers. It's quick & easy.

Web services not sending fields in Soap Envelop

We have a web service that is not sending a field in the Soap Envelope.

For example, when we add a web reference, we get something like:

************************************************** *
public class EmployeeTaxServiceService :
System.Web.Services.Protocols.SoapHttpClientProtoc ol {
public EmployeeTaxServiceService() {
this.Url = "http://10.0.0.25:8080/data_connect/services/EmployeeTaxService";

}
[System.Web.Services.Protocols.SoapRpcMethodAttribu te("",
RequestNamespace="http://webservice.fm.com",
ResponseNamespace="http://10.0.0.25:8080/data_connect/services/EmployeeTaxService")]

[return:
System.Xml.Serialization.SoapElementAttribute("rea dEmployeeTaxReturn")]
public EmployeeTaxDataBean readEmployeeTax(string in0, string in1, string
in2, string in3, string in4, string in5) {
object[] results = this.Invoke("readEmployeeTax", new object[] {
in0,
in1,
in2,
in3,
in4,
in5});
return ((EmployeeTaxDataBean)(results[0]));
}
************************************************** ***

This particular Webservice will not send "in1". If I look at the soap
packet being sent, I see <in0>something</in0><in2>something</in2>.

How can that happen?????

What would cause Microsoft to send a different number of variables than is
in the Proxy file?

It's not like I forgot to add a field (I would get a compile error). But
even if I didn't, the xml tag would still be there.

Thanks,

Tom
Mar 30 '06 #1
1 1514
I figured out what was happening.

Apparently, MS does check to see whether the value is valid - it just
doesn't tell you about it. It just doesn't create the field and sends the
soap envelope.

When I was in the debugger, I noticed the value I was putting in (in1 - from
below), it was null. The soap type was string. So MS just moves everything
up (in0,in2,in3 etc in the case below).

When I set the in1 value to "", it worked fine.

Tom
"tshad" <ts**********@ftsolutions.com> wrote in message
news:OF**************@tk2msftngp13.phx.gbl...
We have a web service that is not sending a field in the Soap Envelope.

For example, when we add a web reference, we get something like:

************************************************** *
public class EmployeeTaxServiceService :
System.Web.Services.Protocols.SoapHttpClientProtoc ol {
public EmployeeTaxServiceService() {
this.Url =
"http://10.0.0.25:8080/data_connect/services/EmployeeTaxService";

}
[System.Web.Services.Protocols.SoapRpcMethodAttribu te("",
RequestNamespace="http://webservice.fm.com",
ResponseNamespace="http://10.0.0.25:8080/data_connect/services/EmployeeTaxService")]

[return:
System.Xml.Serialization.SoapElementAttribute("rea dEmployeeTaxReturn")]
public EmployeeTaxDataBean readEmployeeTax(string in0, string in1, string
in2, string in3, string in4, string in5) {
object[] results = this.Invoke("readEmployeeTax", new object[] {
in0,
in1,
in2,
in3,
in4,
in5});
return ((EmployeeTaxDataBean)(results[0]));
}
************************************************** ***

This particular Webservice will not send "in1". If I look at the soap
packet being sent, I see <in0>something</in0><in2>something</in2>.

How can that happen?????

What would cause Microsoft to send a different number of variables than is
in the Proxy file?

It's not like I forgot to add a field (I would get a compile error). But
even if I didn't, the xml tag would still be there.

Thanks,

Tom

Mar 31 '06 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by chr | last post: by
1 post views Thread by Champika Nirosh | last post: by
9 posts views Thread by Phil B | last post: by
4 posts views Thread by =?Utf-8?B?U2NvdHQ=?= | last post: by
reply views Thread by lallous | last post: by
reply views Thread by NPC403 | last post: by
reply views Thread by kermitthefrogpy | last post: by
reply views Thread by zattat | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.