Ryan Ternier
Ryan Ternier

Reputation: 8804

Generating WCF web service (SOAP) from WSDL to accept/return XML rather than serialized types

I have a large WSDL file that I need to generate a WCF Web service from. I can generate a service using svcutil.exe, however it's not generating what I need.

I need a service that accepts/returns XML, rather than serialized types. The reason for this is if there is an error in the incoming XML it will fail before it hits my code - we can't have this. We need to intercept the XML before any serialization happens to catch it.

Is this possible?

Or is there a way I can modify the generated services so I can work with the raw XML rather than the derived "Message" type?

Effecitvely I want something similar to:

XmlDocument PersonRevised(XmlDocument request);

Current code:

    [ServiceContract(Namespace = "urn:hl7-org:v3")]
        public interface IPRPA_AR101202
        {
            [OperationContract(Name = "PersonRevised", Action = "urn:hl7-org:v3/PRPA_IN101204")]
            PersonRevisedResponse PersonRevised(Message request);
        }


public class PRPA_AR101202 : WCFServiceBase, IPRPA_AR101202
    {
        PersonRevisedResponse IPRPA_AR101202.PersonRevised(Message request)
        {
            PersonRevised  pr = this.ParseMessage<PersonRevised>(request, HL7_XML_NAMESPACE);

            PersonRevisedResult result = new PersonRevisedResult();

            PersonRevisedResponse r = new PersonRevisedResponse(result);

            return r;
        }

    }

update:

Based on the answer I was able to create a WCF service that accepted a string, however now I am getting null on the implemented services that are based off of WSDL contracts( on the input parameter); regardless of whether it's a string or an XmlDocument/XmlNode.

Thoughts?

Upvotes: 2

Views: 669

Answers (1)

tom redfern
tom redfern

Reputation: 31760

I need a service that accepts/returns XML, rather than serialized types

In that case you are better off using POX and not using SOAP/WSDL at all. There are some resources for this here and here.

The reason for this is if there is an error in the incoming XML it will fail before it hits my code - we can't have this.

I kind of know what you're saying here. It is annoying that any serialization exceptions will kill the channel rather than bubble back to the client, however, the whole point of exposing a service metadata endpoint is that clients will always serialize types which are exposed outside the service boundary correctly because that's what the WSDL is supposed to be for.

Effecitvely I want something similar to: XmlDocument PersonRevised(XmlDocument request);

As you are no doubt aware, exposing a XmlDocument type is not equivalent to exposing XML. Exposing XmlDocument will not be pretty.

If you absolutely need full control over the deserialization, you will have to expose your operation as accepting a parameter of type string. Then you can do what you want with it.

public string PersonRevised(string request)
{
    // Deserialize here...
}

Upvotes: 1

Related Questions