R – How to make WCF talk to this web service

svcutil.exewcfweb serviceswsdl

This is a follow up of this question.

As suggested by @Benjamin here, I am trying to add a service reference for my wsdl now (in stead of a web reference). Here is the url to the wsdl in question:

https://eu.link.fiatauto.com/tsi/DDUWsAut.php?wsdl

The problem is that Visual Studio generates an empty codefile:

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//     Runtime Version:2.0.50727.3603
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

namespace test.ServiceReference1 {

}

When I try to manually generate the code using svcutil, I get the following:

C:\temp>svcutil https://eu.link.fiatauto.com/tsi/DDUWsAut.php?wsdl
Microsoft (R) Service Model Metadata Tool
[Microsoft (R) Windows (R) Communication Foundation, Version 3.0.4506.2152]
Copyright (c) Microsoft Corporation.  All rights reserved.

Attempting to download metadata from 'https://eu.link.fiatauto.com/tsi/DDUWsAut.
php?wsdl' using WS-Metadata Exchange or DISCO.
Error: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.Se
rviceModel.Description.XmlSerializerMessageContractImporter
Error: The ' ' character, hexadecimal value 0x20, cannot be included in a name.
Parameter name: name
XPath to Error Source: //wsdl:definitions[@targetNamespace='urn:ddu']/wsdl:portT
ype[@name='dduPortType']


Error: Cannot import wsdl:binding
Detail: There was an error importing a wsdl:portType that the wsdl:binding is de
pendent on.
XPath to wsdl:portType: //wsdl:definitions[@targetNamespace='urn:ddu']/wsdl:port
Type[@name='dduPortType']
XPath to Error Source: //wsdl:definitions[@targetNamespace='urn:ddu']/wsdl:bindi
ng[@name='dduBinding']


Error: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is depend
ent on.
XPath to wsdl:binding: //wsdl:definitions[@targetNamespace='urn:ddu']/wsdl:bindi
ng[@name='dduBinding']
XPath to Error Source: //wsdl:definitions[@targetNamespace='urn:ddu']/wsdl:servi
ce[@name='ddu']/wsdl:port[@name='dduPort']


Generating files...
Warning: No code was generated.
If you were trying to generate a client, this could be because the metadata docu
ments did not contain any valid contracts or services
or because all contracts/services were discovered to exist in /reference assembl
ies. Verify that you passed all the metadata documents to the tool.

Warning: If you would like to generate data contracts from schemas make sure to
use the /dataContractOnly option.

Maybe this has also something to do with the fact that there are problems when trying to use the service by adding a web reference in stead of a service reference (see my other question)?

I guess there's something wrong with that wsdl, but I can't find what exactly.

As this is a third party service which is already used by others, I don't think they will be willing to change their service, so are there any workarounds to let .NET talk to that web service?

Best Answer

There's a bug in the WSDL. The final part in the dduAbortRequest message has a space at the end of the name. That's probably just a bug. Tell them about it, and they'll fix it, and they'll thank you for telling them.

The WSDL is just plain invalid as-is.

<message name="dduAbortRequest">
    <part name="Ticket" type="xsd:string"/>
    <part name="ServiceId" type="xsd:string"/>
    <part name="LoginId" type="xsd:string"/>
    <part name="DocId " type="xsd:string"/> <!-- Should be "DocId" -->
</message>

Tracking it down

At first I thought this was a coercion bug where null was getting coerced to "null" and a test of "null" == null was passing. It's not. I was close, but so very, very wrong. Sorry about that!

I've since done lots of fiddling on wonderfl.net and tracing through the code in mx.rpc.xml.*. At line 1795 of XMLEncoder (in the 3.5 source), in setValue, all of the XMLEncoding boils down to

currentChild.appendChild(xmlSpecialCharsFilter(Object(value)));

which is essentially the same as:

currentChild.appendChild("null");

This code, according to my original fiddle, returns an empty XML element. But why?

Cause

According to commenter Justin Mclean on bug report FLEX-33664, the following is the culprit (see last two tests in my fiddle which verify this):

var thisIsNotNull:XML = <root>null</root>;
if(thisIsNotNull == null){
    // always branches here, as (thisIsNotNull == null) strangely returns true
    // despite the fact that thisIsNotNull is a valid instance of type XML
}

When currentChild.appendChild is passed the string "null", it first converts it to a root XML element with text null, and then tests that element against the null literal. This is a weak equality test, so either the XML containing null is coerced to the null type, or the null type is coerced to a root xml element containing the string "null", and the test passes where it arguably should fail. One fix might be to always use strict equality tests when checking XML (or anything, really) for "nullness."

Solution

The only reasonable workaround I can think of, short of fixing this bug in every damn version of ActionScript, is to test fields for "null" and escape them as CDATA values.

CDATA values are the most appropriate way to mutate an entire text value that would otherwise cause encoding/decoding problems. Hex encoding, for instance, is meant for individual characters. CDATA values are preferred when you're escaping the entire text of an element. The biggest reason for this is that it maintains human readability.

Best Answer

Related Solutions

Actionscript – How to pass “Null” (a real surname!) to a SOAP web service in ActionScript 3

Tracking it down

Cause

Solution

Related Topic