Soap message structure

[ToltingColtAcres]

I am porting an old .net framework app to .net core. This old app uses fedex web services (soap interface) to retrieve tracking information.

Fedex expects a message with the following structure:

<TrackRequest xmlns="http://fedex.com/ws/track/v10">
<WebAuthenticationDetail>
<ParentCredential>
<Key>MY KEY </Key>
[...]
<ProcessingOptions>INCLUDE_DETAILED_SCANS</ProcessingOptions>
</TrackRequest>

Your library generates the following code from a SoapEnvelope.Prepare().Body() call:

<q1:TrackRequest xmlns:q1="http://fedex.com/ws/track/v10">
<q1:WebAuthenticationDetail>
<q1:ParentCredential>
[...]
<q1:ProcessingOptions>INCLUDE_DETAILED_SCANS</q1:ProcessingOptions>
</q1:TrackRequest>

When I attempt to send it to get a reply (via soapclient.send()) Fedex returns the following error:

validation failure for TrackRequest Error:cvc-elt.1: Cannot find the declaration of element 'q1:TrackRequest'.

The message structure appears to be identical with the exception of the q1: prefix...

I can send the upper portion (w/o the q1: prefix) to fedex via a HttpWebRequest and then parse the reply I get, but its a bit of a hack and your library is cleaner.

Is there a way to prevent the SoapEnvelope methods from inserting this q1 prefix so the Body mimicks what fedex expects?

Thanks.

[gravity00]

Hi @ToltingColtAcres not saying this is the cleanest option, but I believe this should work for you (can't give a testing right now):

If you look at SoapEnvelope.Header.Headers it is a collection of XElement instances and the envelope is serialized as one. I believe if you create manually (or using your own serializer) and ensuring the TrackRequest element has a XName without a prefix, the serialization should be as you expect.

This problem is something I want to address in version 3, but as of now, this workaround should suffice.

[ToltingColtAcres]

Thanks for the help. I was able to circumvent the problem with the following code. This changed the soap envelope and eliminated the q1: prefix. Using this code I am able to communicate and get a reply.

Thanks for your work on this library. I was dreading rewriting all the old code generated by .net 3.5 to communicate with Fedex's back-end soap service. They haven't changed their development environment to support .net standard/core yet.

code.txt

[gravity00]

Thanks @ToltingColtAcres! This library emerged from a similar problem while integrating with some legacy HTTP SOAP services. The simpler request pipeline while giving full control of the envelope is typically very useful if you only want to integrate some HTTP SOAP endpoint.

If you any other question, fell free to ask, closing the issue now.