Category: Adapters

A while ago I wrote about different kinds of file transfer protocols that contained the acronym FTP in one way or another, and what they really meant. I mentioned that I had worked with these different protocols. Now the BizTalk Adapter that we used for SFTP has been made available online by Mikael, who was the one responsible for developing it. Considering what the going rate is for BizTalk adapters I’d say that this is highly generous. I know of at least one company that charges several tens of thousands of dollars for their BizTalk SFTP Adapter. Why not save a buck or two for the projects release party? The only thing I have against this adapter is the SharpSsh library it uses, which is a port from Java that has resulted in some C# code that I just don’t like. However I must say that we have been using it in production for some time and it hasn’t failed us yet. As usual though, don’t take my word for it. If you plan to use this adapter test to see that it fits your requirements (as you should with everything in your solution). Read more here.

I’d just like to make a small note about protocol acronyms, and the importance of knowing the correct acronym when naming your BizTalk adapter so that someone planning to (re)use your adapter knows what it’s really about. The case I’d like to highlight refers to FTP, and is something I’ve been forced to drill myself into when working in an environment where several different types of similar sounding acronyms are present.

FTP, the File Transfer Protocol, is used to transfer data from one system to another. The base implementation of this protocol sends all data (including username and password) in clear text through the wire. There are however protocol enhancements for securing this transfer using SSL. This is called FTP over SSL, which is more generally refered to as FTPS (or FTP/SSL). There is also the option of securing your FTP transfer by tunneling it though a SSH session. Though since FTP is a multi channel protocol this in many implementations just protects the control channel (ie the username and password) and sends the data unprotected. However this differs from implementation to implementation, and in some cases both control codes and data is protected. This is refered to as Secure FTP, but is not to be confused with SFTP, which is used when talking about the SSH File Transfer Protocol, which has really nothing to do with FTP. Confusing isn’t it? 😉

Wikipedia har more info. FTP (and FTP over SSH), FTPS, SFTP.

This post is based on something we experienced recently. When we activated some more file receive locations against a machine to which we previously had a bunch of receive locations configured, after a while they began to become disabled, one after the other (but not all). The message in the eventlog states:

The receive location “Xxx Receive Location” with URL “\servershare*.*” is shutting down.
Details:”The FILE receive location \servershare*.* exhausted the network retry attempts.”

The network was up, security settings was unaltered and besides – some of the receive locations still worked. Curious.

Turns out, it’s as much a Windows Server 2003 (and other OS’es) issue as it is a BizTalk issue, and you can just as likely get it in another type of application as in a BizTalk application. The problem is based upon limitations in the number of open requests or commands between two machines. There are limits to both how many connections you are allowed to another computer and how many connection you allow another computer to make to you (ie both outgoing and incomming).

The reason this is more likely to occur in a BizTalk application is that when listening on a share BizTalk registers for change events, and for each receive location one such event will be register. The default limit for the number of active commands is 50. Luckily there is a knowledgebase article (ID:810886) describing how to get around this issue (ie raise the limit). Also for those of you reading the Pro BizTalk 2006 book, there is a section in the book called File Tuning (pages 445-447) that talks about this and also highlights some other issues with the file adapter. The book suggest setting the values to 2048 instead, but doesn’t really say why. The highest possible value is 65000. My suggestion is to set it to a value where you are sure you have covered the number of active receive locations and have room for additional connections used by send port and other type of access using fileshares – only you know what that is. Also for a BizTalk environment, do this to both the BizTalk server and the fileserver you are connecting to. 

Below is the summary of what the knowledgebase describes, in registry file format (valid for Windows 2003 Server machines):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanserverparameters]

“MaxMpxCt”=dword:00002048
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanworkstationparameters]

“MaxCmds”=dword:00002048