This article has been archived. It is offered "as is" and will no longer be updated.
Consider the following scenario:
You have a computer that is running Microsoft BizTalk Server 2009.
You create a receive location that uses the WCF-WSHttp adapter.
On the Messages tab of the WCF-WSHttp Transport Properties page, you specify the Path -- content located by body path option as the source of the incoming BizTalk message body.
You enter a value in the Body path expression field, and then you select String in the Node encoding field.
You receive an XML message that contains a whitespace at the beginning or at the end in the message detail element.
For example, you receive a message that resembles the following:
<ns0:OrderDoc xmlns:ns0="<http://example.com/exampleservices/>"> <MyService><MyServiceRequest><part><MyMsg><InnerDetail> Data after space</InnerDetail></MyMsg></part></MyServiceRequest></MyService> </ns0:OrderDoc>
In this example, the message is suspended because of the whitespace after the opening <InnerDetail> tag, and you receive an error message that resembles the following:
There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=18.104.22.168, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "Pipeline " Receive Port: "<Receive Port>" URI: "<URI>" Reason: An error occurred when parsing the incoming document: "Unexpected end of file has occurred. The following elements are not closed: InnerDetail, MyMsg, part, MyServiceRequest, MyService, ns0:OrderDoc. Line 1, position 149.".
This issue occurs because the WCF-WSHttp adapter truncates the XML message when the message contains a leading whitespace or a trailing whitespace in the message detail element. In the example that is described in the "Symptoms" section, the incoming message is truncated at the whitespace before the "Data after space" string. Specifically, the information that follows this whitespace is not received. Therefore, the received message resembles the following:
For BizTalk Server 2009, the hotfix that resolves this issue is included in Cumulative Update 1 for BizTalk Server 2009.
For more information about how to obtain the cumulative update package, click the following article number to view the article in the Microsoft Knowledge Base:
2429050 Cumulative update package 1 for BizTalk Server 2009
A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article.
If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.
Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:
Note The "Hotfix download available" form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.
You must have BizTalk Server 2009 installed to apply this hotfix.
You do not have to restart the computer after you apply this hotfix.
Hotfix replacement information
This hotfix does not replace other hotfixes.
The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time item in Control Panel.
To work around this issue, use one of the following methods:
Specify the Path -- content located by body path option as the source of the incoming BizTalk message body. Then, select XML in the Node encoding field, and do not select String.
Select the Body -- contents of <soap:Body> element option as the source of the incoming BizTalk message body.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
For more information about how to configure a WCF-WSHttp receive location, visit the following Microsoft Developer Network (MSDN) Web site: