IFS File Transfer Service

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.

Contents

Architecture

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.

Installation

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.

File Storage

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.

Client-side APIs

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.

 

Example: Checking In a File

The following is a description of the steps you would take when Checking In a file into IFS Document Management:

  1. Invoke activity operation 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.
  2. Invoke 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.
  3. Invoke 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.

Example: Checking Out a File

The following is a description of the steps you would take when Checking Out a file from IFS Document Management.

  1. Invoke activity operation 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.
  2. Invoke 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.
  3. Invoke EditDocument.FinishCheckOut(), passing the same ticket as a parameter. This will delete the ticket directory and set the file status to Checked Out.