Inbound FTP - Wildcard Specification

9 views
Skip to first unread message

Jim Dolson

unread,
Sep 12, 2008, 10:31:15 AM9/12/08
to ensemble-in...@googlegroups.com
Good morning all.

I have an inbound FTP business service.  It is supposed to grab a file from a FileZilla FTP server wher ethe filename is of the form dcexportYYYYMMDD (ex: dcexport20080912). 

The FileSpec that I'm using is "dcexport%Y%m%d", but it's not working.  Checking the FileZilla logs shows that Ensemble is requesting a directory listing for files of the form "dcexport%Y%m%d" instead of relplacing the %Y with 2008, %m with 09 and %d with 12.  I would have expected Enemble to request a directory listing for files of the form dcexport20080912.

Any suggestions?  This works fine running on our eGate server with the same filespec of "dcexport%Y%m%d".  Also, our outbound file business operations use this same filespec and they create files with the correct year, month, and day in the filename as expected.

Thanks!

Jim Dolson
Holland Hospital
Holland, MI

James

unread,
Sep 12, 2008, 10:57:48 AM9/12/08
to InterSystems: Ensemble in Healthcare
Hi Jim

Thanks for the post. I'm afraid the SQL Inbound Adapter just takes
what is entered in the setting and passes to the ftp server's LIST
command in the OnTask() method. It does not parse the filespec entered
for conversion as the outbound adapter does. Therefore without
extending the adapter one can only use the masks available for the
particular ftp server. I'll follow up with our development department.

Best wishes

James

Jim Dolson

unread,
Sep 12, 2008, 11:33:10 AM9/12/08
to Ensemble-in...@googlegroups.com
Hi James.

That's interesting.  Why doesn't it support the "Time Stamps in Filenames" format listed on page 25 in the "Developing Ensemble Productions"?  Seems like that would be the consistant thing to do.

During our migration off eGate we've been saving most of our FTP's for last.  Most of the FTP's involve picking up (and sending) files that have the YYYYMMDD built into the filename.  This is a bummer big-time if we can't do this and means that we'll have to keep relying on eGate for those interfaces.

Thanks for talking to development!

Jim
Reply all
Reply to author
Forward
0 new messages