What is my problem with Biztalk FTP Adapter?
My problem is BizTalk Ftp Adapter’s inability to run in 64-bit mode… Actually, this is one of the problems of the ftp adapter but I won’t write about it in this entry, I can live with it…. 
- Out-of-the box Ftp Adapter receive location deletes files from the remote ftp site so it requires write permission on the remote ftp directory, but some of our customers don’t want us to delete file after we retrieve it. For example, some of our customers share same file with lots of recipients on their private ftp server and they do not want to give different ftp directories and put the same file for each recipient.
In my company, we solved the problem by writing a simple custom ftp receive adapter for those customers who don’t give write permission on their private ftp server. Our custom FTP adapter keeps track of received file properties (like name, size, file-mask, etc.) on a custom database and before receiving a new file, it checks the database whether the file received previously or not. In addition to this, after the file is picked up,we compare CRC of the current file with previously received files’ CRCs to prevent duplicate message processing.
If you don’t want to write your own custom adapter, You can also look for a third party adapter like /n software Ftp Adapter, which has a “never delete” mode while retrieving files. - We process large files in BizTalk Server 2006 R2. BizTalk retrieves files by using Ftp Receive Location and our customers also put their files to the directory by using ftp. Because of BizTalk Ftp Receive location is not aware of whether file upload is completed or not, sometimes receive location retrieves incomplete files and that cause BizTalk to fail processing those files.
In my opinion, Ftp protocol’s lack of functionality to check whether file upload is completed or not shouldn’t be an excuse for the ftp adapter to retrieve incomplete files.
So, I listed below some of my proposed solutions to handle incomplete file processing:
Solution 1 : We can write a custom FTP adapter. Custom adapter checks file size before retrieving the file and if its size doesn’t change for a certain time (lets’ say 1 minute) then assumes it is uploaded completely and then process otherwise don’t process and try to retrieve file at next polling.
Solution 2 : If the ftp server is in our control we can make customers to upload documents to the customer specific temp directories and a program which runs on the ftp server can move uploaded files from temp directories to the directories where BizTalk receive location is polling. While moving file from a temp directory on FTP server would let us have a lock on the file and so we would get a 550 error when trying to retrieve the file at this time. Receive location tries to retrieve file at next polling. Actually, I didn’t tried the solution but I expect it to work. Even it works, not my favorite.
Solution 3 : Find a third party adapter. /n Software Ftp Adapter may be an option but I don’t know whether it provides a solution to check file completeness or not.
Last but the not least, lack of extension point of adapter framework.
We have to use the adapter as it is or we must find another adapter. We have two options; We can develop our own custom adapter or we can find a third party adapter.
I think, it would be nice if we would not write a whole new adapter and if there were some extension points which we could alter the way of adapter’s processing, by writing something like interceptors. We can intercept the processing flow of the adapter, make some validations and decide whether to let adapter to continue processing or make it stop by throwing an exception or make it skip this time and try to retrieve file at next polling.
Related posts:
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
