Sanae BEKKAR – My Blog –

Managing a File Store System

We see how to configure the Oracle WebCenter Content Server file store system and use the File Store Provider :

The FileStoreProvider component exposes the file store functionality in the Content Server interface and allows additional configuration options.

For example, you can configure the Content Server instance to use binary large object (BLOB) data types to store content in a database, instead of using a file system. This functionality offers several advantages:
■Integrates repository management with database management for consistent backup and monitoring processes.
■Helps overcome limitations associated with directory structure and number of files per directory in a file system approach.
■Aids in distributing content more easily across systems, for better scaling of Content Server.
■Allows for different types of storage devices not commonly associated with a file system, for example, content addressed storage systems and write-only devices necessary in some business uses.

File Management
The first half of data management is storing electronic files checked in to a Content Server repository.

With Content Server, file storage has typically been done with a traditional file system, storing electronic files in a hierarchical directory structure that includes vault and weblayout directories.

Files and their associated renditions are placed into particular directories within the vault and weblayout directories.

Similarly, any web rendition is distributed across the hierarchy within the IntradocDir/weblayout/groups/ directory.

The web rendition is the file served out of a web server, and in the historical file system storage method, could be the native file, the alternate file, or a web-viewable file generated by Inbound Refinery or some other conversion application.

Metadata Management
The second half of data management is storing metadata associated with an electronic file.

With Content Server, metadata management has typically been done using a relational database, primarily involving three database tables.

Metadata enables users to catalogue content and provides a means for creating file descriptors to facilitate finding it within the Content Server repository.

The FileStoreProvider component enables you to define data-driven rules to store and access content managed by Content Server.

File Store Provider offers the following features:
■The ability to relocate files easily
■The ability to have the web-viewable file be optional
■The ability to manage and control directory saturation
■The ability to integrate with third-party storage devices
■An API to use, extend, and enhance different storage paradigms.

The storage rule determines how vault and web files are stored by Content Server and how they are accessed by a web server.

The FileStoreProvider component is installed, enabled, and upgraded by default for a Content Server instance with no documents in it.

NOTE – If you do not want to upgrade File Store Provider from your current settings, prior to upgrade installation you must add the configuration variable FsAutoConfigure=false in the Content Server config.cfg file.

A file store for data management is used in Content Server instead of the traditional file system for storing and organizing content.

The FileStoreProvider component is installed and enabled by default during Content Server deployment.

The FileStoreProvider component automatically upgrades the default file store (DefaultFileStore) to make use of functionality exposed by the component, including modifying the web, vault, and web URL path expressions.

Note:
Oracle WebLogic Server does not support configuring its web server for the Content Server instance to add a new virtual directory and alias to point to the weblayout directory for each partition that is created.

Partitions can be used for the vault files, and partitions are supported for web files, but the partition root must exist under the default vault and weblayout directories.

In a file system approach to Content Server, the primary file is stored in the vault directory at the root of the DomainHome/ directory and is called the native file.

If an alternate file[The alternate file may also be selected and checked in by the user, and is presumed to be a web-viewable file.] is checked in, it is also stored in the vault, but is copied to the weblayout directory or passed to a conversion application, such as Inbound Refinery.

If no alternate file is checked in, then the native file is copied from the vault directory to the weblayout directory, existing in two places.

If no alternate file is checked in and Inbound Refinery is installed, a rendition of the native file could be created and stored in weblayout directory.

In a file system approach to Content Server, storing content in specified directories defines a path to the content.

You can access content from a browser by using a static web URL file path, when you know the content is in a specific location, or using a dynamic Content Server service request, such as GET_FILE, when you do not.

With File Store Provider, content may or may not be stored in a file system. Consequently, a new approach to defining paths to the content must be taken.

Renditions are grouped together into a storage class, which determines where and how a rendition is accessed.

Storage classes are grouped together into a storage rule, which defines the vault, web, and web URL path expressions, through a storage class.

Additionally, a storage rule determines if a rendition is not stored, as in a web-less file store, or if it is stored in a different device, such as a database rather than a file system.

Example – 1 –
A storage rule is defined as JDBC Storage on the Storage Rule Name dialog and Web Files is selected from the Renditions choice list. In this scenario, the vault files are stored in the database and the web files are permanently stored on the file system.

Example – 2 –
A storage rule is defined as JDBC Storage on the Storage Rule Name dialog and no selection is made from the Renditions choice list. In this scenario, both the vault and web files are stored in the database.

Example – 3 –                                                                                                                                              A storage rule is defined as File system only on the Storage Rule Name dialog and Is Webless File Store is selected. In this scenario, no copy is made of the primary files and so the native files are the only renditions. Requests for web-viewable files are routed to the native files stored in the vault.

Note:
These metadata fields are added by File Store Provider on startup and if deleted are added again when the Content Server instance restarts.

If the metadata fields must be permanently deleted, set the configuration variable FsAddExtraMetaFields=false in the intradoc.cfg file to disable the automatic creation of the fields. The intradoc.cfg file is located in the DomainHome/ucm/cs/bin/ directory.