We had a little problem a few days ago when we were reviewing the testing of a B2B solution implemented with BizTalk.
This implementation was basically the collection of a file via FTP and then a splitter pattern which would break up a batch and cascade updates to appropriate systems. The file which was recieved was a moderately complex file containing multiple rows containing different types of positional records.
We had implemented this as per the specification and were moving from testing this internally to test it with the business partner. One of our limitations was that we could not do integration testing as early as we would like due to some external constraints.
Our internal tests were fine, but during integration testing we found some unexpected behaviour from the partners FTP service. A summary of this behaviour is:
- The server would store multiple files with the exact same file name. If the partner uploaded 2 files we could see them as seperate instances with seperate file creation dates, but they would both have the same name.
- When we executed a GET command on a file it would get the file and then mark it as collected and prevent us from downloading the file again. To be able to get a file if transmittion had failed we need the partner to make the file available again
- We are unable to delete files from the server
- If 2 files with the same name can be seen on the remote server, if we execute a get it will actually merge the files together to give us one file locally containing all of the date from both remote files. The data positions the content of the files in date order
We experienced a little problem and became aware of this unexpected behaviour and our first thoughts were that we would need to do some custom coding to deal with this. On closer inspection our problem seemed to be something else and BizTalk was actually dealing with this FTP behaviour in a way that worked well for us. Our setup basically had the FTP adapter polling the remote server when files were downloaded they were streamed through a custom pipeline which contained the FFDasm pipeline component which used a schema based on the partners message specification.
The way BizTalk was dealing with this additional FTP requirements was as follows:
- It didnt matter that BizTalk couldnt delete the file from the remote server because once the file was downloaded it was no longer available anyway.
- When 2 or more files were merged together when downloaded the FFDasm component was recognising this and actually still broke the message up correctly. If 2 files were downloaded and merged together we would actually get 2 disassembled messsages in the messagebox which had been handled correctly by FFDasm
I guess in hindsight this kind of makes sense, but it was nice to come across a situation where something like this happens and you done end up having to pull together some hack to workaround it.
In terms of the partners FTP service we didnt get confirmation on the vendor specific setup but based on some googling (sorry I mean Live searching) I believe that the it could be based on a VAX file system where you can have multiple versions of a fileand the FTP service could be either HP/UX Enterprise Secure FTP or possible an offering from Sterling