Changing web service URL without updating the web reference

We all know the problem.  We work and work at it, and there seems to be no explanation or cause for it.  We develop test cases that all seem to work, and then it never works when we do it for real.  We spend hours upon hours on it, testing, scouring Google for answers, writing and rewriting code, and waking up at odd hours with a completely off-the-wall proposed solution to it.

Then we figure it out, and it’s so blazingly simple that we wonder how we ever consider ourselves geeks.

Here’s mine, for the past couple of weeks.

I had a bizarre Web Services problem.  The service uses a strongly-typed parameter:

DoWebServiceStuff(MyType theParameter)

The web service is published to other interested parties for two-way communication; i.e., they build a component to consume our web service and we build a component to consume theirs.  We were having difficulty debugging a new development effort.  The symptoms of the problem were:

  • The parameter never deserialized at the other end.  Every time it was checked, it was null.
  • The XML string for the parameter deserialized to the object with no problems, if we took the string out of the logs and wrote code to deserialize from it.

Our methodology is that the codebase has a reference set to the instance of the web service that we sent.  To send to another system (regardless of whether it was one we developed or not), we use the same reference and set the URL to be the URL of the end system.  If I built a custom reference to the other system, it would work, but not when I used my reference to send to their URL.

Finally, I figured out the problem.  Their web service was built as DoWebServiceStuff(MyType TheParameter).  Notice the difference?  The name of the parameter was different, therefore its SOAP wrapper was different.  When I created a web reference to their service, .NET abstracts the SOAP process away from me so that it’s handled properly, but when I use my web reference to send it, the parameter name is still different.

In programming, we’re so used to thinking that the name of the parameter only matters locally, and focused on what is contained within that parameter.  So, if you’re ever seeing a problem where a web service parameter won’t deserialize, check your parameter spelling and casing between systems.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s