In the ‘Flat File Schema Developers Guide’, it is mentioned that sending and receiving flat files can be done in three to four different ways such as file polling, FTP-ing the file to the service, HTTP and email. What would be the considerations what would go into the choosing of one of the options?
Is there a preferred/’best-choice’ method among the options? Would the decision mainly depend on the file size?
“Best” is always a subjective attribute. What is “best” in one case might be less desirable in another.
There are pros and cons to each of the transport methods listed. Each of them works just fine. Which of them fits better for a given situation depends on the details of the situation.
A relatively newer feature of IS is that one can FTP a file to a user directory and on completion of the put, IS will publish a “file received” document that can be subscribed so that the file can be processed.
Typically, many companies choose to have a file FTP’d to a particular directory and use the IS file polling port to pick up the files for processing. This isn’t “best practice.” Just “common practice” and rather a bit “old school.”
I had referred the GEAR documentations but was not able to find any mention of criteria that should be taken into consideration for choosing the method. In some cases, when you have the choice of going with any of the options, it would be good to have some data or best-practice to base the decision on. Don’t think GEAR has anything like this on it.
“A relatively newer feature of IS is that one can FTP a file to a user directory and on completion of the put, IS will publish a “file received” document that can be subscribed so that the file can be processed.”
Rob,could you pls provide technical/docs reference to this newer feature…may be i missed it…Is this part of FTP svc or file polling settings?
It is a part of FTP and isn’t documented very well. In the IS Administrator’s Guide, look at watt.server.userFtpRootDir in Appendix B. Server Configuration Parameters. It describes how IS can behave more like a “real” FTP server, storing the put file to disk and publishing a “putCompletedNotification” rather than invoking a service.