by Kyle Benson

Switching File Attachment Storage

In previous posts I have talked about the File Attachment storage options in PeopleSoft. The three basic options are Database, FTP or HTTP. My organization initially went with HTTP, but now we are looking to move to Database storage. The requirement is to move not only future file attachments, but attachments from the past as well. At first I thought this would require a lot of work, including custom conversion AE programs, etc. However, there is a delivered process called Copy File Attachements that does all the heavy lifting for you. There is an online and batch method to run this, but I highly recommend the batch mode. There are a few other steps needed to fully convert all attachments, but it is fairly straight forward. Below are the steps I used in FSCM 9.2.17, PeopleTools 8.54.18.

Create new File Attachment Server

  1. Navigate to Main Menu > Set Up Financials/Supply Chain > Common Defictions > File Attachments > Administer File Attachments
  2. Click Add Database Server
  3. Record Name will default to PV_ATT_DB_SRV. The default is fine, but change if you would like.
  4. Set Pick Active Server to match the ID of your new server.
  5. Save. Future File Attachments will now be stored in your database.

Copy File Attachments

  1. If needed, create new URL for Database storage – PeopleTools > Utilities > Administration > URLs. Values URL Identifier: PSA_ATT_DB, URLID:record://PV_ATT_DB_SRV
  2. Navigate to run control page PeopleTools > Utilities > Administration > Administer File Processing > Copy File Attachments (Batch)
  3. Values Source: URL.PSA_ATT_HTTP, Destination:URL.PSA_ATT_DB
  4. Run the App Engine COPYATTS through Process Scheduler.
  5. This will take a long time to run, possibly hours depending on your attachment count.
  6. After completion, you will want to review the trace file AE_COPYATTS_[PIN].trc file. The AE should produce this automatically.

  7. I used this trick to generate a log of ONLY errors from the trace:

    grep "EvalCopyAttachments: failed getting file" AE_COPYATTS_*.trc > AE_COPYATTS.errors

  8. Take action on any errors that occurred.

Update previous File Attachment URL

  1. These steps point the old HTTP server setup to point to the new DB server.
  2. Navigate to PeopleTools > Utilities > Administration > URLs. Values URL Identifier
  3. Open the URL used for the previous File Attachment Server setup. Example: PSA_ATT_HTTP
  4. Change the URLID value to the new Database server URL values. Example: record://PV_ATT_DB_SRV
  5. I recommend adding comments describing this conversion process – especially if HTTP or FTP is in the URL ID and it now points to the DB. This can help avoid confusion in the future.

After we completed these steps, we decided to keep our old storage location around just in case we found any issues after the fact. We ended up renaming the directory path, just to make sure nothing was still referencing the old location. After a few weeks of no issues, we went ahead and destroyed this old storage location. As mentioned above, this was done in the FSCM application which has its own File Attachment framework built on top of the one Tools delivers. You should be able to take a similar approach with other applications, but the Create new File Attachment Server section above won’t be relevant. Instead, you can simply complete the Update previous File Attachment URL steps after your copy is complete.

by Kyle Benson

Safely Using File Attachments

Allowing users to upload file attachments to multiple types of transactions within PeopleSoft is a very important PeopleTools feature. Adding files like resumes, expense receipts and other types of documents can be a huge win for organizations looking to move away from paper and fully leverage their ERP system. That being said, giving users the option to upload a file into your system has risks. There are plenty of people out there who would love to abuse this functionality.  You could be leaving your systems vulnerable to nasty viruses and malware.  Also, if not properly secured, these repositories of documents could be a data gold mine for people with malicious intent. Thankfully, PeopleTools does give us a few options to protect ourselves from these dangers. These are just a few considerations for safely setting up file attachments.

File Extension List

When we allow a user to upload a file related to a PeopleSoft transaction, we have a general idea what type of file to expect. Common file types would be images, Word documents or PDFs. Something like a .exe or .zip file is something that we would not expect, and should generally not allow. Well, good news! PeopleTools lets us specify what file types are allowed. By utilizing File Extension Lists, we can specify a list of extension types to accept or reject. These lists can then be associated with a URL by specifying the FILE_EXT_LIST property, using the URL Maintenance Page. When the file attachment architecture uses a URL for storage, it will look for this File Extension List and preform validation before a user is allowed to attach a file.

Virus Scanning

Limiting the file extensions of uploads is a good first step, but it really doesn’t get you very far. To really safe guard yourself from malicious file uploads, you need to be actively scanning all files for viruses. PeopleTools delivers a nice hook in the file attachment architecture to accomplish this. Buried in the PIA_HOME you will find the VirusScan.xml file. This can be used to configure virus scanning. Once this is done, all file attachment uploads will be scanned for viruses. If any are found, it will prevent the file from being saved on your system. Oracle doesn’t give us a lot of details on what exact virus scanning software is supported. However, it was built to work with ICAP supported scanners. So, if you own a virus scanner that works with ICAP then you are most likely in luck. There is also some level of configuration in the xml file to deal with different response codes.

Storage Locations

There are three delivered storage locations for file attachments in PeopleTools. All three options have their own pros and cons, so you will have to decide which to use depending on your needs. There will be a few things to consider with each approach to make sure each protocol is used safely.

Database

This is probably the most secure option. Generally the database is already very locked down, since the majority of other application data is stored there. No extra controls are really needed to make sure your files are safe. To be truly safe though, you really want to make sure this data is encrypted in flight and at rest. So if you do your due diligence with the security of your app as a whole, storing with this method takes care of itself.

FTP

This protocol has been around forever, but really has fallen out of favor in most organizations. You should under no circumstances be using plain old unencrypted FTP. PeopleTools does however support both FTPS and SFTP, a more secure option. To use these protocols you must use URL objects, not URL strings, in your PeopleCode. Take care to secure the attachments on the file system the FTP server is pointed to.

HTTP

The final storage option is HTTP. Similar to a Report Repository, this method leverages a PIA servlet(psfiletransfer) to handle the file storage. This setup is explained very well in

MOS Doc ID 1321581.1.  Similar to FTP, you should be using the secure option – HTTPS. To leverage this secure option you will need to make sure certificates are in place and your URL object is configured correctly. Review the MOS Doc ID 1408853.1 for further details. And again, make sure the attachments are secure in the file system.