This section describes the File Transfer Service (FTS) in IFS Document Management, providing a high-level technical overview of the architecture along with, and more importantly, how developers could use the new APIs and Interfaces/Services provided to upload and download files to IFS Document Management through the FTS.
The IFS File Transfer Service, or FTS for short, is a part of IFS Document Management. While it can be run standalone and used for uploading/downloading files in general, it may not prove to be as useful unless used along with DOCMAN. The FTS is an HTTP service developed using Java Servlet Technology and packaged into a Web Application Archive (WAR). It is bundled and deployed together with the IFS Extended Server as shown below.
During installation the Web Server is configured to forward requests containing /ifsfileservice/ as part of the URL, to the server instance being installed. At runtime this server instance will handle URLs with this context path by invoking (forwarding the request to) the respective servlets in the FTS. The FTS being an HTTP service brings numerous advantages such as being secure, fast and firewall-friendly.
The IFS File Transfer Service will be installed and configured automatically. This is handled by the install_docman.xml Ant script that is run by the IFS Applications Installer for Middle Tier Installations.
For other Web-server/Application-server combinations please follow the guidelines given in Planning Installation.
Files uploaded by the client to the File Transfer Server, or files that are
to be downloaded by the client, are stored in a location that is currently
non-configurable. The location used by the FTS at present in the system's local
TEMP directory, followed by /ifs/filsrv/. For example, on
a Windows system, this root path for file storage would be (the temp path
depends on what account is running the application server):
C:\Documents and Settings\<user>\Local Settings\Temp\ifs\filsrv\
For security reasons, and for keeping files belonging to different users separate, the FTS requires a ticket as part of the HTTP request for an upload or download. This ticket is a cryptographically strong pseudo-random number that is unique for every session and impossible to guess. All files uploaded by the user are then stored in a folder with this ticket name in the root path. Similarly, files to be downloaded must already exist in this ticket directory.
Being an HTTP-based service, the File Transfer Service can be used from any programming language platform such as Java or .Net. That includes an API for .Net-based languages called Ifs.Application.Docman.FileManagement. In future we may also include APIs with a similar design and interface for other languages and platforms like Java and COM-based languages like Visual Basic.
Class | Method Signature | Description |
---|---|---|
FileTransfer | public FileTransfer(string uri) |
Constructor. Takes a single parameter, the uri to the FTS located on the network. This uri should take the form http://<host>:<port>/ifsfileservice/FileTransfer |
FileTransfer | public Boolean UploadFile(string file, string ticket) |
Uploads a file to the FTS. Returns true if the
operation was successful. The parameter file is the full pathname to the
file that is to be uploaded. The ticket parameter is the ticket acquired by
calling one of the Activity methods. See below. |
FileTransfer | public Boolean DownloadFile(string sourcefileName, string
destinationFileName, string ticket) |
Downloads the specified file to the local machine. The
parameter sourcefileName is the name of the file to be
downloaded. Note that as this file resides on the server, the name does not
include a path. For example, you would specify something like Factory
Layout (100-120000-1-A1).doc for this parameter. The second parameter,
destinationFileName , is the full pathname to which the
downloaded file must be written to, e.g. c:\temp\Factory Layout
(100-120000-1-A1).doc. The last parameter is the ticket acquired by
calling one of the Activity methods. See below. |
The following is a description of the steps you would take when Checking In a file into IFS Document Management:
EditDocument.StartCheckIn()
. This
will create a ticket directory in the FTS root path, and return the name of
this ticket to the caller. The file status will be set to
Operation In Progress.UploadFile
passing the full file name and ticket
name as parameters. The FTS will store the file in the ticket directory
created in step 1.EditDocument.FinishCheckIn()
passing the same ticket
as a parameter. This will fetch the files from the ticket directory and
upload them to the repository, sets the file status to
Checked In and finally deletes the ticket
directory.The following is a description of the steps you would take when Checking Out a file from IFS Document Management.
EditDocument.StartCheckOut()
.
This will create a ticket directory in the FTS root path, fetch the files
from the repository to the ticket directory, and return the name of this
ticket to the caller. The file status will be set to
Operation In Progress.DownloadFile
passing the sourceFileName
(which can be obtained from the IN-OUT parameter DocumentRevision
used when calling StartCheckOut )
, the full destination
file name and ticket name as parameters. The FTS will fetch the
corresponding file and stream it down to the client, writing it to the
specified destination.EditDocument.FinishCheckOut()
, passing the same
ticket as a parameter. This will delete the ticket directory and set the
file status to Checked Out.