Elton Stoneman

[Source: http://geekswithblogs.net/EltonStoneman]

Using LoadGen 2007 to submit messages with a complex SOAP header, I had a strange issue with the standard SOAP transport. The SOAP transport has two parameters for wrapping the input file into a SOAP envelope:

<Parameters>

<URL>http://x/ESB.ItineraryServices.Response/ProcessItinerary.asmx</URL>

<SOAPHeader>SOAPAction: "http://microsoft.practices.esb/Process/SubmitRequestResponse"</SOAPHeader>

<SOAPPrefixEnv>&lt;?xml version=&quot;1.0&quot; …</SOAPPrefixEnv>

<SOAPPostfixEnv>&lt;/Root&gt;&lt;/SubmitRequestResponse&gt…</SOAPPostfixEnv>

<IsUseIntegratedAuth>False</IsUseIntegratedAuth>

<LatencyFileName></LatencyFileName>

<ResponseMsgPath></ResponseMsgPath>

<DstEncoding>utf-8</DstEncoding>

</Parameters>

- note the ellipses above are for brevity and are not in the actual LoadGen config file.

When the transport gets called, it opens an HTTP request and sends the SOAP envelope by writing three sets of byte arrays to the request stream: the value of SOAPEnvPrefix, the contents of the input file, then the value of SOAPEnvPostfix. All the byte arrays are encoded to the value specified by DstEncoding. When I used this configuration to send a message it was being rejected by the endpoint as a bad request. Trapping the request with Wireshark, it looked like this:

It looks as though LoadGen has injected an ellipsis before each part of the message it built – the envelope prefix, the input file contents and the envelope postfix all start with an ellipsis in which is not in the original. The request is malformed and rejected by the service.

Initially I thought this was something strange in how Wireshark was showing the results and wasn't actually part of the message, so I checked further and found that the XML escapes weren't set correctly. The SOAP header is an ESB Guidance itinerary which contains escaped XML for CDATA sections – to enter it as the SOAPEnvPrefix parameter meant escaping the escapes, so &lt;!CDATA[]&gt; becomes &amp;lt;!CDATA[]&amp;gt; in the parameter and is rendered correctly. But the issue remained, and so did the ellipses. Copying the full request into Web Service Studio produced the same result, but cutting out the ellipses meant it processed correctly.

With time accumulating on what should have been a simple task, I checked out the SOAPTransport code and could see nothing that was causing this. Debugging the call didn't show any ellipsis characters being written, and modifying it to produce a single string of the header, body and footer before encoding made no difference. In the end I created a modified transport which takes a full SOAP envelope as the input file, doing away with the envelope parameters altogether.

This worked fine, didn't render any ellipses – although the code is very similar to LoadGen's SOAPTransport class – and was happily processed. It has the advantage that you can capture a full message with Wireshark, save it and use it in LoadGen without having to extract the header. It's on the MSDN Code Gallery here: Sixeyed.Samples (Sixeyed.Samples.LoadGen.Transports.AlternativeSOAPTransport).

Configuration is very similar to the standard transport, just specify the assembly and remove the SOAP envelope parameters:

<Transport Name="SOAP">

<Assembly>Sixeyed.Samples.dll/Sixeyed.Samples.LoadGen.Transports.AlternativeSOAPTransport</Assembly>

</Transport>

…

<Parameters>

<URL>http://x/ESB.ItineraryServices.Response/ProcessItinerary.asmx</URL>

<SOAPHeader>SOAPAction: "http://microsoft.practices.esb/Process/SubmitRequestResponse"</SOAPHeader>

<IsUseIntegratedAuth>False</IsUseIntegratedAuth>

<LatencyFileName></LatencyFileName>

<ResponseMsgPath></ResponseMsgPath>

<DstEncoding>utf-8</DstEncoding>

</Parameters>

But I'm still puzzled about those ellipses from the standard SOAP transport.