LoadGen 2007

Alternative SOAP Transport for LoadGen

EltonStoneman — Wed, 25 Feb 2009 00:33:57 GMT

[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:

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

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

<IsUseIntegratedAuth>False</IsUseIntegratedAuth>

</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 <!CDATA[]> becomes &lt;!CDATA[]&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:

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

</Transport>

…

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

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

<IsUseIntegratedAuth>False</IsUseIntegratedAuth>

</Parameters>

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

Implementing LoadGen.IMessageCreator to Generate Convoy Messages

EltonStoneman — Tue, 16 Sep 2008 00:31:46 GMT

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

As part of the testing for the Dynamic Looping Convoy solution, I wanted performance testing with LoadGen, which proved to need almost as much development as the BizTalk design.

The standard LoadGen message creation from templates, and even the Dynamic Message Creator wouldn't work for my case where I wanted to generate messages in related sets, all of the same type but each only populating part of the schema. So the message id would be the same for a set, but the segment number would dictate what else was populated.

I ended up writing a custom IMessageCreator implementation to generate the convoy messages, which is not complex, but doesn't seem to be too well-trodden a path. Here's the class with the interface methods highlighted:

OptimizeFileSizeLimit lets you specify when streaming comes into play for large message; in my case the message were all small so this is just a get/set of a local field;
CreateNewMessage is where the message generation happens. In the convoy case you need to be wary that LoadGen can operate in multiple threads, so I have static methods to return the current message id and segment number*. The method retrieves the next segment info, selectively populates a segment, and returns it to LoadGen. LoadGen expects a byte array, so the class is serialized to XML and the bytes are passed out:

public Message CreateNewMessage(Message OriginalMessage, string TemplateFilePath, string NewMessageUniqueFileSuffix)

{

//construct the segment:

MessageSegment messageSegment = GetNextSegment();

IncomingSegment segment = new IncomingSegment();

segment.HireId = messageSegment.MessageId;

segment.SegmentNumber = messageSegment.SementNumber;

//add data:

switch (segment.SegmentNumber)

{

case 1:

segment.CustomerId = "CUST_X";

break;

//etc...

}

//retrieve XML as byte array:

byte[] buffer = this.SerializeSegment(segment);

//populate outgoing message:

Message outgoing = new Message();

outgoing.MessageData = buffer;

outgoing.MessageLength = buffer.Length;

outgoing.MessagePath = OriginalMessage.MessagePath;

outgoing.MessageExtension = OriginalMessage.MessageExtension;

return outgoing;

}

* - there are issues with this in any case, as you may have the situation where the thread count is not a multiple of the expected segment count so you'll get incomplete sets generated. Useful if you want to check error handling in your BizTalk solution, but you can stick to a single LoadGen thread if not (although this has its own limitations).

You get the last message created by LoadGen in the OriginalMessage parameter, which you can use to populate the path and extension of the outgoing message – note the path will be ignored in favour of the DstFilePath set in config. The complete Section in config looks like this:

<Assembly>x.y.Test.dll/x.y.Test.LoadGen.ConvoyMessageCreator</Assembly> <TemplateFilePath>x:\Msg100Segment1.xml</TemplateFilePath>

</MessageCreator>

<SrcFilePath>x:\Msg100Segment1.xml</SrcFilePath>

<DstFilePath>x:\x.y\Locations\SegmentReceive</DstFilePath>

</Parameters>

</DstLocation>

</Section>

Note that you need to specify TemplateFilePath and SrcFilePath and they need to exist, even if you don't use them. And I couldn't get Asynchronous mode to work (it would always use the source file path over the message creator config), but Synchronous runs the message creator.