integrating your business

The following warning is often seen on servers running Microsoft Host Integration Server:

Log Name:      Application
Source:        SNA Base Service
Date:          date
Event ID:      561
Task Category: None
Level:         Warning
Keywords:      Classic
User:          user
Computer:      computer
Description:
Write to mailslot or socket failed, rc = 64

 EXPLANATION

 A Win32 WriteFile() or winsock sendto() call failed. The return code is shown.

 ACTION

 Provide network support personnel with the event log file(s) related to SNA, and the return code included in this message. For information about SNA log files, see the "Microsoft Host Integration Server Online Books.

 The warning is caused because Host Integration Server tries to communicate with all the servers in a subdomain (and the clients) via broadcasts messages. Host Integration Server does this over all protocols that are selected in the SNA Manager. Not all of these protocols are enabled on your network, if one of them is not enabled this warning will pop up.

To fix this warning unselect the protocol that causes the warning as shown in this screenshot.

Typically you enable TCP/IP and you disable Named Pipes. After adapting the configuration the warning disappears.

Peter Borremans

When adding a Web reference to a BizTalk project, the following message appears:

There is a problem with the WSDL but you don't get any extra information.

The cause was this part in the WSDL:

<port binding="tns:TestServicePortBinding" name="TestServicePort">
          <soap:address location="REPLACE_WITH_ACTUAL_URL"/>
</port>

Apparently a BizTalk project can't handle an invalid location (a Console project doesn't have any problem with this!).

The problem was solved by putting the filepath of the WSDL in the location attribute.

To find this problem i removed part after part of the WSDL untill the import went fine. It's a good practice to identify different kinds of WSDL problems.

For one of our projects, we are receiving unicode messages through a receive pipeline containing only a BTF disassembler (BizTalk Framework). The disassembler has the standard properties and the AllowUnrecognizedMessage set to true.
When we are receiving a UTF16 unicode message (with no byte order mark in the stream!), the disassembler crashes with the known error : No disassemble stage components can recognize the data.
Sending a UTF8 message works.

The BizTalk Xml Disassembler normally tries to detect the message's encoding by executing these steps:

1. If a byte order mark is available in the data, the encoding is extracted from it.
2. If the IBaseMessagePart.Charset property is set, that setting will be used.
3. Xml Declaration will be used, when available
4. If none of the above are met, the default, UTF-8, is used.

The message we received had none of the first 3 conditions, so it was interpreted as UTF8. By setting the Charset property on the IBaseMessage in our custom pipeline component, we were able to pass it through the Xml Disassember.

The BtfDisassembler was raising another error, now. My conclusion (and Tomas Restrepo's too) was that the BtfDisassembler was not able to process Unicode messages.

The solution to this was using our CODit Charset decoder that creates a new stream, with the UTF8 encoding. This was working.

Thanks to Tomas Restrepo, who investigated a lot on this and wrote an entry on his blog : http://www.winterdom.com/weblog/2006/05/19/DecodingUTF16MessagesWithTheBizTalkFrameworkDisassembler.aspx