Debugging File Attachment Problems
This debugging section discusses the following:
Enabling tracing on the web server or application server.
Problems with transfers to and from FTP sites.
Attachments with non-ASCII file names.
Problems uploading files.
Passing error messages to the end user.
The topics in this section are of interest primarily to customers deploying file processing applications, and secondarily to application developers.
This section discusses how to:
Enable tracing on the web server.
Enable PeopleCode tracing on the application server.
Enabling Tracing on the Web Server
To enable web server tracing of file attachment processes:
Select PeopleTools, Web Profile, Web Profile Configuration, and open the current web profile.
Select the Custom Properties page.
Add a new row, and enter these values:
32 (File processing)
Set the .level property of the logging.properties file to ALL.
Restart the web server.
The log files are written to a directory that depends on the java.util.logging.FileHandler.pattern property of the logging.properties file.
More information on IDDA logging is available in the PeopleTools PeopleBooks.
Enabling PeopleCode Tracing on the Application Server
For tracing file attachment issues, set the PeopleCode trace level to 2048 (Statement Tracing, which shows each statement as it's executed). In addition, higher PeopleCode trace settings are recommended whenever CopyAttachments is run. You can enable PeopleCode tracing on the application server in several ways:
For all client sessions by setting TracePC in Configuration Manager.
For a specific client session through the Trace PeopleCode page (select PeopleTools, Utilities, Debug, Trace PeopleCode.
Because PeopleCode tracing can generate a lot of output, setting tracing for a specific client session only is recommended.
Application server log files can be found in the PS_CFG_HOME/appserv/domain/LOGS directory.
The application server log files have names in the form APPSRV_MMDD.LOG (in which MMDD represents the month and date).
The file transfer log file has a name in the form of FILETRANSFERpid.LOG.
The PeopleCode trace file has a name of the form, *.tracesql.
A common reason that a transfer fails is that the FTP server is not accessible from the application server. This error could be due to:
An incorrect password.
An incorrect account name.
An inability of the application server to resolve the FTP server's host name.
The FTP server is down.
Try to ping the FTP server machine from the application server system, and then try to manually transfer a file to the FTP server machine from the application server.
If the FTP site is on Microsoft Windows, the host name for the system might not be associated with a fixed IP address and might not be resolvable using DNS (Domain Name System). If the application server is on a UNIX machine, the application server can resolve the host name using DNS only—or perhaps using NIS (Network Information System) or an /etc/hosts file. However, the application server will be unable to use Windows mechanisms such as WinBeui or WINS. Therefore, the application server will not be able to convert the host name indicated for the Microsoft Windows file server into an IP address and route to it.
If the file transfer fails, you must resolve the problem by either specifying the numeric IP address in the FTP URL or by putting the host name for the FTP site into DNS, NIS, or the hosts file on your application server so that the name can be resolved.
Typically, the URL used for file attachments has the following format:
However, if the domain name cannot be resolved with DNS, then use the numeric IP address. The following example assumes system_name has the IP address of 192.0.2.1:
Note: Use numeric IP addresses only when absolutely necessary.
To successfully upload an attachment with a file name containing non-ASCII characters (such as Japanese), Oracle recommends running the application server with the locale that supports those specific non-ASCII characters—for example, ja_JP.sjis. If the storage location for the attachment is an FTP site or an HTTP repository, Oracle recommends that the storage location also be running in an environment that supports the same language or locale as the file names used. The web server (which serves as an intermediary in the transfer of the file from the browser to the application server and then on to the storage location) can be running either a multi-language environment (for example, UTF-8) or a non-ASCII character language environment.
The uploading of a file attachment involves multiple tiers—for example, the browser on the client, the web server, the application server, the database server, and ultimately the file attachment storage location. To ensure the correct transfer of data and files between these tiers, Oracle recommends configuring each server tier (web server, application server, database server, and file storage location) to use the same character set as follows:
If your PeopleSoft system operates in a multi-language environment, use a UTF-8 character set on each server tier.
If your PeopleSoft system operates in a single language environment, use the native language character set for that language on each server tier.
The Global Technology PeopleBook provides examples of which character set to specify on which tier for three typical configurations—a multi-language environment, a single language environment (Western), and a single language environment (non-Western).
You cannot use a relative path to specify the file that is to be uploaded; you must use a full path. If users experiences problems in uploading files, ensure that they browse to the file they wish to upload rather than attempting to manually enter the full path name of the file.
This problem can manifest itself differently depending on the browser used. For example, with some browser versions, the PeopleSoft page appears to be in an infinite “Processing” state.
The combination of the attachmentExtraWindow web profile property and some of Internet Explorer’s settings can silently interfere with downloading and opening of files with the ViewAttachment function. For more information, see the documentation on the attachmentExtraWindow web profile property.
When working with the attachment functions, if you want the end user to be able to view error messages (such as that the file is too large, that the file was not found, that there is no disk space at the storage location, and so on), then you need to write or clone PeopleCode to interpret function return codes and pass error messages back to the user.
As an example, each of the programs in the FILE_ATTACH_WRK derived/work record includes a parameter that sets the message level, but does not translate these into user terminology. The message levels that can be set are:
0 – Suppress all messages including errors.
1 – Display all messages.
2 – Suppress success messages only, but display error messages.
By default, the message level is 0 for each of these programs. The programs are demonstrated on the PeopleTools Test Utilities page.