Question

I am connecting to a SOAP 1.1 web service with accepts no parameters and returns a simple string response.

I have generated my xsd files for the complex types using the old .NET 2.0 Add Web Reference which has also generated the port and multi-part message types in Reference.odx

In my Orchestration I use the correct multi-part message under Web Message Types as the type of my request and response message and use an empty Construct Message shape for the request message prior to the Send action.

Despite explicitly constructing the request message with no parameters I can see (in Fiddler) that the request to the service is built correctly but there is no body for the request. I am expecting

    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
                   xmlns:myns="http:myns">
        <soap:Body>
            <myns:ServiceName/>
        </soap:Body>
    </soap:Envelope>

The port and adapter is set up correctly as I can manually insert the expected request body with self-closing request named node and replay the failed request which then succeeds.

I can think of 2 places where I may be going wrong:

  1. Constructing the message in the Orchestration
  2. My port adapter may be ignoring the empty message and not including the SOAP envelope in the request body

How can I force the SOAP envelope to be present even if the body is empty?

Was it helpful?

Solution

My issue was caused by using the auto-generated web-messages in my orchestration directly. I 'solved' my issue by:

  1. Using the .NET 2.0 Add Web Reference to save the wsdl generate xsd for the service
  2. Use Add Generated Items.. > Consume WCF Service, using the wsdl and xsd option and selecting the files generated in 1
  3. Manually alter the generated files to remove some duplicate complex type and invalid imports
  4. Alter the odx, change the modifiers on the message types to public (from internal)
  5. Exclude the web reference from my BizTalk project to avoid duplication

I can then use the generated multi-part messages in my orchestration. Critically, the message for the service taking no parameters was defined with a message part that I can use the message assignment shape to hard-code the message part with no content.

I also get some other side benefits such as Exception types.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top