The File Receive Adapter doesn’t Process Empty Files

A quick observation for today – interesting to see that the FILE adapter won’t attempt to process empty files (my emphasis):

The FILE receive adapter deleted the empty file “C:CBTMessage_2009-03-26_03-12-50_7c54477f-516c-48c1-9f8b-5450eeff1dd0.xml” without performing any processing.


Interesting Quirk when Formatting Guid’s as Strings….

Originally posted by Nick Heppleston at:

I noticed an interesting quirk last night while trying to format a Guid into a string representation – by default, Guid.ToString() does not return an accurate representation of a GUID with curly braces. Hmmmmmm…..

Consider the following simple test, here we are instantiating a new Guid and before outputting the value to the debugger, we capture its value – note the curly braces at the end of the Guid:


If we let the test run its course, we get the Guid formatted as a string (using the default formatter) written to the debugger, but there are no curly braces:


After much head scratching and Googling, I decided to look at the MSDN documentation for the Guid.ToString() method – low and behold there are several format specifiers that can be provided to the ToString() method which determine the formatting provided to the resultant string. Using the format specifiers:


we get the desired output:


If no format specifier is used (i.e. we just Guid.ToString()), the default format is ‘D’ – no braces.

Next UK SOA/BPM User Group Meeting – 26th May 2009, London

The next UK SOA/BPM User Group Meeting has been announced which will be taking place on Tuesday, 26th May 2009 at Microsoft’s London office between 6pm – 9pm.

The meeting will include a presentation by ISV Ascentn who will provide an overview of the current SOA & BPM product offerings; the developer session is currently open to anyone who would like to do a presentation, so drop your name to Mike if you’re interested. Make sure you register so they can get the right amount of beer and pizza.

Full details can be found at the UK SOA and BPM User Group website.

See you there!

Handling a Web-Service Null Response: The ‘CreateBodyPart’ Pipeline Component

Originally posted by Nick Heppleston at:

Today I’m releasing a small component that addresses an interesting problem I’ve never come across before – a null response from a web-service.

The web-service in question is provided by a third-party and unfortunately cannot be changed. Their WSDL defines the root response element with a maxOccurs=1 and a minOccurs=0, which allows for a null response to be returned. So instead of a result element with no child nodes as I would expect (below in green):

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="..." xmlns:xsd="..." xmlns:xsi="...">
    <PendingSalesOrdersResult xmlns="..." />

we’re receiving an empty response (note the lack of an element between the <GetPendingSalesOrdersResponse> element):

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="..." xmlns:xsd="..." xmlns:xsi="...">

When the SOAP adapter receives this null response, it creates a message but neglects to create a body part – I presume this is because there is nothing to create it from. As a result, the message fails in both an XmlReceive and PassThruReceive pipeline; when using the PassThruReceive pipeline, the XLANG/s engine throws the following error when it tries to read the body part:

The XLANG/s message has no part at index ‘0’.  The total number of parts found in the message is ‘0’. If you expect a multipart message, check that the pipeline supports multipart messages such as MIME.

To address this problem, I’ve created a very simple receive pipeline component which lives on the receive side of the web-service solicit-response port and interrogates a message to determine whether it has a message body. If a message body is not present, it creates one based on the component properties (which mimic the expected – valid – response from the web-service) allowing the response message to be passed into the Message Box without issue. It a message body is present, it passes the message through unchanged.

The CreateBodyPart Pipeline Component

The component lives in the Decode stage of the receive pipeline and simply detects for the presence of a message body. If the body part is null, a new message part is created using the component properties BodyPartName and BodyPartContent and assigned as the body part of the message, before being passed onto the next stage of the pipeline. The BodyPartName and BodyPartContent properties specify the name of the body part and the Xml you want the part to contain – given that the content of the message is likely to be small-ish (i.e. <PendingSalesOrdersResult xmlns=”…” /> in the example above).

There are a few enhancements that I can envisage for this component already, including the ability to specify whether the part should be a body part – you might just want to create extra parts on the fly, not just a body part; and also the ability to specify the encoding and character set being used with your part content. However, I’ll leave these enhancements for a later day.

You can find binaries and source for the component at Codeplex:

As a final note, my client is currently running BizTalk 2006 (not R2) and we are running on the out-of-box SOAP adapter. Does anyone know whether this issue is a problem in the WCF-SOAP adapter or the WSE adapter?

Reblog this post [with Zemanta]

Using Context.Write to *Update* a Context Property Value

Originally posted by Nick Heppleston at:

This one has been done to death, but I am writing a moniker replacement pipeline component and noticed some interesting behaviour when looking to update Context Properties.

If you need to update an existing Context Property value, there is no Update() method defined in the IBaseMessageContext interface. However it is possible to write your new value which will perform an update. So use the following code to update the value in an existing Context Property:

private void WriteContextPropertyValue(IBaseMessage msg, string propName, string propNamespace, string propValue)
    message.Context.Write(propertyName, propertyNamespace, propertyValue);

Using the above code in an NUnit test, we can see that our original SOAP moniker is updated with the correct HTTP moniker with little more than a Context Property write.


FTP Adapter Context Property Oddities

Originally posted by Nick Heppleston at:

Interesting to see that the FTP adapter doesn’t capture the full Uri of the file in its ReceivedFileName context property – instead it simply gives us the filename:


Compare this with the FILE adapter where the full name (incl. the path) of the file is provided:


So, if you need to capture say the folder structure of the FTP server, you need to do a few lines of magic to extract the folder name from the InboundTransportLocation property (shown in green in the first screenshot) and munge it with the ReceivedFileName.

Reblog this post [with Zemanta]