Prefix SOAP XML Instead direct namespace

Question

I am working with one of our partner to integrate our business services. I am using WCF (.Net 3.5) to communicate with partner web service. I think partner web service is written in Java.

Using SVC util I generated proxy class. Instead DataContract serializer, svcutil used xmlserializer. But WSDL provided by partner and the web service response SOAP xml does not match. Since the partner not interested in changing the wsdl, I have changed downloaded WSDL manually to match the response. That issue has been fixed.

Now I am running into different problem. When I send a request to the web service, it always failed. Then I used fiddler to get the SOAP request forwarded to the partner. Partner said the xml namespaces sent by the request does not validate against their systems. They also replied with sample SOAP request.

By comparing the both requests, the namespaces looks correct. But partner xml uses the prefixes to define the namespaces and elements are prefixed. Whereas xml on our side does not have prefixes instead used the namespaces directly in the parent element.

Here is the XML that we sent

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <iL21stCentRq xmlns="http://schemas.WebServiceProvider.com/us/ileads/messages/Servicing">
        <ACORD xmlns="http://schemas.WebServiceProvider.com/us/ileads/types/Servicing">
            <SignonRq xmlns="http://www.ACORD.org/standards/PC_Surety/ACORD1/xml/">
                <SignonPswd>
                    <CustId>
                        <SPName>111</SPName>
                    </CustId>
                </SignonPswd>
            </SignonRq>
        </ACORD>
    </iL21stCentRq>
</s:Body>

Here is the Sample XML that partner expected from us

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:stc="http://schemas.WebServiceProvider.com/us/ileads/messages/Servicing" xmlns:stc1="http://schemas.WebServiceProvider.com/us/ileads/types/Servicing" xmlns:acd="http://www.ACORD.org/standards/PC_Surety/ACORD1/xml/">
<soapenv:Header/>
<soapenv:Body>
    <stc:iL21stCentRq>
        <stc:input>
            <stc1:ACORD>
                <acd:SignonRq>
                    <acd:SignonPswd>
                        <acd:CustId>
                            <acd:SPName>yourcompany.com</acd:SPName>
                        </acd:CustId>
                    </acd:SignonPswd>
                </acd:SignonRq>
            </stc1:ACORD>
        </stc:input>
    </stc:iL21stCentRq>
</soapenv:Body>

If you compare the both XML, the namespace http://www.ACORD.org/standards/PC_Surety/ACORD1/xml/ is prefixed by "acd" in partner xml our does not. Partner wanted us to send in that format.

I think Partner Xml does not follow the standards. This really partner problem. But I had no option left and required to change the Xml on my side.

Though we could customize the serialization in WCF service, I am not sure it is possible to change prefix at this level. Moreover I am not sure that the Partner Xml following the standards of XSD.

If you could guide to modify the WCF serialization to accommodate the above said changes, I would appreciate it.

You should find a partner who understands XML. The prefix doesn't matter in XML - only the namespace. If your partner thinks otherwise, then they are not competent. — John Saunders, Jul 02 '13 at 00:27
The entire purpose of standards is so that people like you don't have to customize your software for each partner you deal with. They should all just follow the standards - and this is not a new standard. There's really no excuse for not supporting it. — John Saunders, Jul 02 '13 at 00:44
These comments aren't really that helpful though. A developer is usually asked to integrate with someone based on what they can offer to your business. And this someone may not be willing to change their stuff to suit your needs if others have managed to work with what they offer. I'm looking for these solutions at the moment because I'm in this situation and I cannot find a different partner. So what should I do? Walk out of the door? — Matthew Grima, Dec 01 '14 at 15:39

Amzath · Accepted Answer · 2013-08-09T15:04:59.223

I fixed proxy class generated by SVC Util. I added a new property that emit the prefix. For example in class SignonRq, I added the following property. That serialized the XML with prefix acd

        [XmlNamespaceDeclarations()]
    public XmlSerializerNamespaces xmlsn
    {
        get
        {
            XmlSerializerNamespaces xsn = new XmlSerializerNamespaces();
            xsn.Add("acd", "http://www.ACORD.org/standards/PC_Surety/ACORD1/xml/");
            return xsn;
        }
        set
        {
            //Just provide an empty setter. 
        }
    }

For example class ACORD, I added the following property. That serialized the XML with prefix stc1.

        [XmlNamespaceDeclarations()]
    public XmlSerializerNamespaces xmlsn
    {
        get
        {
            XmlSerializerNamespaces xsn = new XmlSerializerNamespaces();
            xsn.Add("stc1", "http://schemas.WebServiceProvider.com/us/ileads/types/Servicing");
            return xsn;
        }
        set
        {
            //Just provide an empty setter. 
        }
    }

@JohnSaunders For namespace http://www.ACORD.org/standards/PC_Surety/ACORD1/xml/ they wanted acd prefix. They wanted prefix stc1 for namespace http://schemas.WebServiceProvider.com/us/ileads/types/Servicing. — Amzath, Aug 09 '13 at 15:01
Could you please post the whole class including the attributes you've given it, as I've added this property to my class and nothing has changed. Thanks. — Matthew Grima, Dec 01 '14 at 15:40

Prefix SOAP XML Instead direct namespace

1 Answers1

Linked