Managing document store

You can manage the document store to manage all incoming and outgoing files, including import feeds, scripts, reports, and specs.

The document store is accessible through the user interface at Collaboration Manager > Document Store. The Documents window provides the following accessible file directories to the files that are stored on your Oracle or DB2® database:
  • archives
  • public_html
  • eventprocessor
  • schedule_logs
  • feed_files
  • scripts
  • FTP
  • tmp
  • params
  • users
The ftp and public_html directories are file system directories that are mounted into the document store and are defined in the docstore_mount.xml configuration file in the $TOP/etc directory. The docstore_mount.xml file provides the location of your file system mount points and uses the ftp_root_dir and supplier_base_dir parameters from the common.properties file:
<mnt doc_path="/public_html/" real_path="$supplier_base_dir/" inbound="yes"/>
<mnt doc_path="/ftp/" real_path="$supplier_ftp_dir/" inbound="yes"/>
For each file in the document store, you can view file details and audit log information of who has accessed the file and when.
  • File details

You can use the document store as a backup engine because every file that goes through your system is copied and stored into the document store.

Complete the following in the document store:
  • Control access to files
  • Compress file size
  • Delete files
  • Defragment the document store

The document store database architecture includes table spaces that are designated for all files that are stored in the document store. When a file is stored in the document store, a new record in the database is created. The database stores the file as a BLOB (binary large object) file. A BLOB file refers to random large blocks of memory bits that are stored in a database and are used to hide specific information about a file. Information is hidden because a BLOB is an object that cannot be interpreted as a specific object type from within the database and so each object is only viewable as an indistinctive BLOB file. The database stores BLOB files within one of the table spaces in the database. The advantage of using BLOB files and table spaces is that the database is able to protect your table data by using database server mechanisms, including back up-and-recovery and security mechanisms.

If you use two application server instances, and share database, you might find some documents to have disappeared. When you upload documents through portal in the public_html folder, the documents seem to disappear from the docstore. From the log files of both the application servers, you are able to see that the files are deleted. The mount manager on either instance periodically polls and synchronizes the database with its file system. When the mount manager on the second instance synchronizes the database with its file system, it removes the docstore entry added by the first instance, since the file does not exist in its file system.

A shared NFS mount is the solution to this problem. The $TOP/public_html file must be NFS-shared for the clustering to work. The docstore_mount.xml file contains mount manager configuration. The attribute inbound in this configuration file should be set to "yes" for the synchronization process to occur.

Table space management is an ongoing task. The document store table grows and shrinks in size that depends on use. You must ensure that sufficient disk space is being used efficiently and that available disk space exists to support large binary files without interruption.

To maintain the performance of the document store, you should regularly defragment the files. Defragmentation chunks all of the files that exist in the document store into one continuous cluster and improves file import duration times.

Restriction: All file names that are uploaded to the document store cannot contain the following special characters: !@$%^&()=+.