Jaa

FTP Adapter in BizTalk Server 2010:: The “Interval” and “Redownload Interval” Binding Properties

  • Artikkeli

Typically, after a request message is consumed by BizTalk Server, it is deleted from the target folder. However, if there is no write permission on the FTP server, you will see a warning like this in the event viewer:

The adapter "FTP" raised an error message. Details "Unable to delete the file "RequestInstance.xml" on the FTP server. Inner Exception details: "The remote file could not be opened by the FTP server. ". ".

To work around this limitation, FTP adapter in BizTalk Server 2010 introduces a binding property called Delete After Download. If the FTP server does not provide write permissions, one can set this property to No so that BizTalk Server does not attempt to delete the request message from the FTP server. However, just having this new property does not serve the purpose completely. What happens if the request message on the FTP server is updated after it has been already consumed? Because the original message never got deleted and if the name of the file containing the request message is the same, how does BizTalk Server know that a new message is now available. To tackle this scenario, the FTP adapter introduces a couple of more properties:

  • Enable Timestamp Comparison – As the name suggests, if this property is set to Yes, BizTalk Server downloads the file if the timestamp for the file has changed.
  • Redownload Interval – If this property is configured, BizTalk Server downloads the file at the specified interval.

Both these properties kick in only if Delete After Download is set to No. All sounds good, right? It did to me as well and so I went about using the Redownload Interval property because not all FTP servers support the enable timestamp comparison option. I wanted the FTP receive location to pick the request message every 5 minutes. So, this is how I set the properties on the FTP receive location.

FTP_POST

Now, I go back to the folder where I am expecting the send port to drop the response message and I see the first response message. I know the next response message would appear in another 5 minutes. 5 minutes gone and nothing happens. I wait for few more minutes but no response message yet. What went wrong? After some digging, I figured it out. But before I describe how to fix it, let us first understand how the FTP adapter internally works w.r.t the redownload interval property.

The FTP receive location uses the “Interval” property to poll the FTP server.  Every time it downloads a file, it maintains the filename in a list. At the interval you specify for the “Redownload Interval” property, the FTP adapter invalidates the list, or in other words, erases the list. So, in effect, after every redownload interval, the adapter does not know whether a file on the FTP server was already downloaded and ends up downloading it again. Let us understand this using an example.

Say the name of the request message on the FTP server is abc.xml. When the FTP receive location is enabled, this is how the sequence of events are probably taking place:

  • File abc.xml is downloaded.
  • The list of files downloaded now includes abc.xml.
  • The adapter goes into the polling interval for 60 seconds.
  • After 60 seconds elapse, the adapter polls the FTP server, and finds the file abc.xml.
  • The adapter now compares the list with the list it maintains for the downloaded files. It sees that the file has already been downloaded and ignores the file.
  • The adapter goes into the next polling cycle. This continues for the next four minutes.
  • After the redownload interval of five minutes is hit, the file list maintained by the adapter is invalidated.
  • The adapter now goes into the next polling cycle and notices the file abc.xml again.
  • The adapter compares it with the list it maintains and this time does not find the file in that list.
  • The adapter downloads the file.

Makes perfect and logical sense, right? But our question still remains – why didn’t we see the response message after 5 minutes. Well, here’s the answer: The Unit binding property that we set to minutes applies to both Interval and Redownload Interval binding properties. So, when we set the property to minutes, we actually set the polling interval to 60 minutes and the redownload interval to 5 minutes. So, going by the sequence of events I described earlier, the file might get downloaded every 1 Hr 5 minutes. How to fix this? Easy. Set the intervals for the same unit. So, if you want the redownload interval to be set to 5 minutes, set the Redownload Binding property to 300 and set Units to Seconds. Assuming Interval is already set to 60, the receive location should now function as expected.