Understanding File Attachment Storage Locations

PeopleTools supports three types of storage locations: database tables, FTP sites, and HTTP repositories. Except for the CleanAttachments function, all PeopleCode file attachment functions support all three storage locations. The CleanAttachments function operates only on database tables as storage locations.

This section provides an overview of the following:

  • Database storage considerations

  • FTP site considerations

  • HTTP repository considerations

Important:

The following applies to FTP sites and HTTP repositories on Windows only:

When uploading to a Windows file system or downloading files from a Windows file system, remember that Windows processes file names in a case-insensitive manner. So, for example, if a file called FILE1.TXT already exists at a particular location on a Windows file system:

Attempting to download a file called file1.txt from that same location will have the effect of downloading the file FILE1.TXT that is there.

Attempting to upload a file called file1.txt to that same location will have the effect of overwriting the file FILE1.TXT that is there.

Database Storage Considerations

To store file attachments in the database, you must create a target table to store the attachments themselves. The record definition associated with this target table must include the FILE_ATTDET_SBR subrecord and no other fields.

This chapter contains additional information on how to create the target table.

See Application Development Process Overview.

When the storage location is a database table, the URL parameter of the invoked file attachment function can be specified in one of two ways:

  • A URL string in the form of: 

    record://MYRECORD

    In this case, MYRECORD is the record definition associated with the target table.

  • A URL identifier in the form of: 

    URL.URL_ID

    In this case, the URL identifier refers to the URL object named URL_ID.

FTP Site Considerations

When the storage location is an FTP site, the URL can be defined in one of two ways:

  • A URL string in the form of: 

    ftp://FTP_user:FTP_pwd@FTP_site/path

    Important:

    FTPS and SFTP require that a URL object be used and do not support URL strings. This form of URL string is for use with the FTP protocol only.

  • A URL identifier in the form of: 

    URL.URL_ID

    In this case, the URL identifier refers to the URL object named URL_ID.

When specifying a URL for an FTP site, specify the FTP server's name or its IP address. Specify a path on the FTP server relative to the directory specified as the FTP server's home directory.

Note:

For many FTP servers, the FTP server's home directory is specifiable on a per-FTP-user basis. Therefore, if an application will be using multiple FTP user accounts, then care must be take to ensure that files are being stored and accessed in a consistent manner with respect to their absolute location on the FTP server.

The default FTP port is 21. If you want to use a different port, you must specify it in the URL, as part of the FTP server address. For example:

ftp://ftpserver.example.com:6000/

Note:

If the specified subdirectories do not exist the PeopleCode function tries to create them.

The following limitations apply to FTP URLs:

  • The FTP user name to is limited to 30 characters.

  • The FTP password to is limited to 16 characters.

HTTP Repository Considerations

When the storage location is an HTTP repository, the URL parameter of the invoked file attachment function must be specified as a URL identifier in the form of:

URL.URL_ID

In this case, the URL identifier refers to the URL object named URL_ID.

An HTTP repository can reside on a PeopleSoft web server, or on a non-PeopleSoft web server environment. If the HTTP repository resides on a PeopleSoft web server, then the psfiletransfer servlet has been provided to manage the file transfers to and from the storage location. You should specify appropriate URL properties, for example, for the HTTP protocol, you should specify the USER and USEAUTHTOKEN properties. The URL properties specific for each protocol are described in detail in the URL Maintenance topic in the System and Server Administration Guide.

See System and Server Administration: URL Maintenance, Specifying Properties for HTTP URLs and Specifying Properties for HTTPS URLs.

If the HTTP repository resides on a non-PeopleSoft web server, then you need to ensure that the web server can handle file transfer security and requests. Additionally, you should ensure that the repository supports adding attachments (POST method), viewing attachments (GET method), and deleting attachments (DELETE method). If required, you may configure additional URL properties based on your business requirements using the URL maintenance page. For more information on URL properties, see System and Server Administration: URL Maintenance and System and Server Administration: Maintain URL Properties.

When you plan to use the non-PeopleSoft web server as an HTTP repository, check your web server documentation for its capabilities to use with the file-attachment PeopleCode functions.