File attachments Process in PeopleSoft

From Oracle Support
=============
File attachments are supported by using PeopleCode built-ins that implement the transfer of a file to/from a browser via the app server.

Here is the general pathflow:

Browser <---> WebServer <---> App Server <---> File Server

The Browser <--> WebServer transfer is done using a standard HTML form construct. This can
be done securely in an encrypted fashion if the web server uses SSL to speak to the browser.
Once the file is received at the WebServer, it is stored in a temporary directory for transfer to
either the Browser (View operation) or the App Server (Attach operation). After the transfer
is complete, the file is deleted.

The WebServer <--> AppServer transfer is done by using a JOLT service, which is securely encrypted.
Note that since this transfer is done via the standard JOLT mechanism, no additional settings to the
firewall are required. (No need to open additional ports.) On the app server, the file is stored in
a temporary directory (/tmp/PSFTP/A????????? or /tmp/PSFTP/V????????, where the ????? is
a randomly generated transaction number for either Attachments or Viewing.) By using separately
named subdirectories for each attachment, support for the simultaneously transfer of identically
named files is guaranteed, as well as security that attachments won't be mixed up.

The App Server <--> File Server transfer is done using the FTP service, which can be securely
encrypted if required. The ftp service is invoked on the app server by means of a script that
is passed to the ftp binary. This script is in /tmp and is called ftpXXXXX.txt and the output of
invoking that script is called ftpXXXXX.log. Note that the XXXXX is a random number. These
files are left in /tmp for debugging purposes, with the assumption that access to the app server
is restricted and somewhat secure. For top security, a cron job that deletes these files on a weekly
basis would be perhaps worthwhile.


Debugging File Attachment Problems

One of the first issues may be: did the FTP transfer take place successfully? To investigate this, gain
access to the appserver and look at the ftpXXXXX.log file (as well as the ftpXXXXX.txt file).

pt-hp01:$ cat ftp1039.txt
open 216.131.219.51
user ANONYMOUS TEST
bin
lcd /
lcd tmp
lcd PSFTP
lcd V13333
cd /
get "IA_FA_Test.TXT" "IA_FA_Test.TXT"
quit
pt-hp01:$
pt-hp01:$ cat ftp1039.log
about to submit ftp -vin /tmp/ftp1039.txt
Connected to 216.131.219.51.
220 TCARREON052500 Microsoft FTP Service (Version 4.0).
331 Anonymous access allowed, send identity (e-mail name) as password.
230 Anonymous user logged in.
200 Type set to I.
Local directory now /
Local directory now /tmp
Local directory now /tmp/PSFTP
Local directory now /tmp/PSFTP/V13333
250 CWD command successful.
200 PORT command successful.
150 Opening BINARY mode data connection for IA_FA_Test.TXT(72 bytes).
226 Transfer complete.
72 bytes received in 0.06 seconds (1.21 Kbytes/s)
221
File Transfer Successful
pt-hp01:$

Notice that the log file shows that the file transfer was successful. If this was not the case, perhaps the error messages in the log can point out why it wasn't successful. One common case may be that the ftp server was not accessible from the app server due to a wrong password, wrong account name, or perhaps because the app server was unable to resolve the ftp server hostname. Perhaps the ftp server was down and the app server was unable to route to it. Try pinging the ftp server from the app server system, and then try ftp'ing to the ftp server from the app server.
If you have an NT file server, it is possible that the hostname for the NT system is not associated with a fixed IP address and is not resolvable using DNS. If you have the app server running on a Unix box (Solaris, HP-UX, AIX), the app server will only be able to resolve the hostname using DNS (or perhaps NIS or /etc/hosts), but not using WinBeui or WINS. This means that it won't be able to convert the hostname indicated for the the NT file server into an IP address and route to it.
If you suspect this, try the ping test: telnet to the Unix app server box and then try "ping TCARREON052500" or whatever the suspect hostname is. If this fails, then you must resolve the problem by either specifying the IP address in the FTP URL or putting your hostname into DNS/NIS/hosts so that Unix can resolve it.

Configuring Multiple App Servers on the Same Box to Support File Attachments

Note that the /tmp/PSFTP directory is created by the first appserv process to run on your app server computer. The assumption is that all such appserv processes will run with the same user id. While this may be the case for the majority of customers, this is not always the case for the PeopleSoft testers. Frequently, a single box will run appservers with userid testdb2, testsyb, and testora, for example.

For proper security, the default /tmp/PSFTP is created with 711 permissions, or "drwx--x--x". This means only the user who created the directory can read and write to it. If you have multiple users that need to do this, you must change the permissions.

The best way is to have all the users in a single group, as specified by /etc/groups, and then have the person who configured the app server telnet to the Unix box and change the permissions (or create) for /tmp/PSFTP to be "771" or "drwxrwx--x". This only permits the app serv processes to write to that directory.

In cases of a test environment where security is not that significant, the administrator could change the permissions to 777 or "drwxrwxrwx". This would permit all the app server processes to read and write to that directory, but also any user on the system.

What is Application server domain?

An application server domain, is the collection of Server Processes, supporting processes, and resource managers that enable connections to the database.

The sequence of events that takes place in a PeopleSoft Environment

1. The URL in the Web browser address window invokes a PS servlet on the Web server
2. Servlet running in the servlet engine interprets request and comes up with the list of objects required to build the page
3. Request for all required objects sent to the application server in the form of a Jolt Message
4. Tuxedo receives the Jolt Message, and converts it into a service request which it routes to the appropriate PeopleSoft server process
5. PeopleSoft server process converts service request into SQL statement(s)
6. SQL statements sent to the database
7. Data requested is supplied by the database
8. PeopleSoft process constructs HTML page out of object data
9. Tuxedo acknowledges receipt of data and closes connection with the PeopleSoft process
10. Data forwarded by Tuxedo to requesting Java servlet
11. Servlet forwards page requested by the browser
12. When all objects are in place, HTML page forwarded to the Web services
13. Browser views the page

Where did Tuxedo come from?

Bell Labs - 1993

Transactions for
UniX
Extended for
Distributed
Operations