This section contains the following topics:
With the release of version 11gR1, Content Server implemented a file store system for data management, replacing the traditional file system for storing and organizing content. The File Store Provider component is installed (enabled) by default with Content Server deployment. File Store Provider exposes the file store functionality in the Content Server interface and allows additional configuration options. For example, you can configure Content Server to use binary large object (BLOB) data types to store content in a database, instead of using a file system. This 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.
Caution:
The File Store Provider component is installed and enabled by default during Content Server deployment. It should not be uninstalled or disabled after the default file store is upgraded. If you have not yet upgraded the default file store, you can disable the component following the procedure in "Enabling and Disabling a Component".This section contains the following topics:
Content Server manages content by tracking the storage of electronic files and their associated metadata. It provides the ability for users to store and access their checked in files, any associated information, and any associated renditions. This section discusses the data management methods historically used by Content Server and how they are addressed with the File Store Provider component.
The first half of data management is storing electronic files checked into Content Server. 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. By using the revision information specified by the content type, security group and account (if used), files and their associated renditions are placed into particular directories within the vault and weblayout directories. For example, the primary and alternate files specified at check in are stored in subdirectories in the vault directory. The specific file location is defined to be the following:
IntradocDir/vault/dDocType/account/dID.dExtension
In this path name, dDocType is the content type chosen by the user on check in, dID is the unique system-generated identification that identifies this revision, and dExtension is the extension of the file checked in. In this hierarchical model, the system uses the dDocType metadata field to distribute the files within the hierarchy established in the vault directory. 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.
This straightforward determination of file storage location is helpful to component and feature writers, helping them understand where files are located and how to manipulate them. However, it also has the effect of limiting storage management. Without careful management of the location metadata, directories can become saturated, causing the system to slow down.
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 Content Server. For users, the retrieval is done by the Content Server, and how and where the file is stored may be completely hidden. For component and feature writers, who may need to generate or manipulate files, the metadata provides a robust means of access.
The traditional file system model historically used by Content Server limits scalability. As data management needs grow, adding extra storage devices to increase storage space is not conducive to easy file sharing through a Web-based interface. Complex, nested file structures could slow performance. Suppressing the creation of a duplicate web-viewable file when the native file format could be used could be difficult. As a consequence of dealing with large systems, for example over 100 million content items, Content Server has shifted to using a file store. This offers the advantages of scalability, flexibility, and manageability.
The File Store Provider component enables you to define data-driven rules to store and access content managed by the 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.
With File Store Provider, checked-in content and associated metadata are examined and assigned a storage rule based on criteria established by a system administrator. Criteria can include metadata, profiles, or other considerations. The storage rule determines how vault and web files are stored by Content Server and how they are accessed by a Web server.
A file store for data management is now used in Content Server instead of the traditional file system for storing and organizing content. Using the File Store Provider component, the system administrator can upgrade the default file store to make use of functionality exposed by the component. After the default file store is upgraded, the web, vault and web URL path expressions can be modified.
Note:
After the default file store is upgraded, the vault path in the default storage rule is set to$PartitionRoot$. A value for $PartitionRoot$ does not exist until you create a partition. Partitions are not required to run Content Server, but any attempt to check in content before creating a partition, changing the vault path root, or creating a new, well-formed storage rule will fail. See "Understanding File Store Provider Storage Principles", including the sections on storage rules and path construction for additional information.Note:
Oracle WebLogic Server does not support configuring its Web server for Content Server to add a new virtual directory and alias to point to the weblayout directory for each partition that is created.While partitions can be used for the vault files, in 11g Release 1 (11.1.1) partitions are not supported for web files.Caution:
Resource files should not be edited directly. Proper modification of resource files should be done within the Content Server user interface or through additional component development. For more information on component development, see Chapter 5, "Working With Components".Three other resource tables are used to define and handle file paths. The defaults for the PathMetaData Table and PathConstruction Table cover most scenarios. The StorageRules Table stores the values specified when a storage rule is defined. These three tables are provider-specific, and as such are defined in the provider.hda file of the defaultfilestore directory. The defaultfilestore directory is located in the IntradocDir/data/providers/ directory. A fourth table, the FileSystemFileStoreAlgorithmFilters Table requires a component along with java code to modify.
This section contains the following topics:
The File Store Provider component makes several modifications to the Content Server database, Content Server metadata fields, and other configuration files, allowing for possible configuration options.
This section contains the following topics:
In some situations, content stored in a database may have to be forced onto a file system. One example would be when Inbound Refinery must have access to a file for conversion. Files forced onto a file system are considered temporary cache. The following configuration values are used to control when the temporarily cached files are to be cleaned up. Note that the system only cleans up files that have an entry in the FileCache Table.
File Store Provider adds several Content Server metadata fields and makes additional options available for use in configuration files.
This section contains the following topics:
Configuring Added Metadata Fields
File Store Provider adds three metadata fields to Content Server:
xPartitionId: This metadata field is used in conjunction with the PartitionList table to determine the root location of the content item files. It is recommended that this field be hidden on the UI, since the partition selection algorithm provides a value.
xWebFlag: This metadata field is used to determine whether a content item has a web-viewable file. Consequently, if the system has content items that have only vault files, then removing this metadata field causes the system to expect the presence of a web-viewable and may cause harm to the system. The metadata field may be specified by the configuration value WebFlagColumn.
xStorageRule: This metadata field is used to track the rule that was used to determine how the file is to be stored. The metadata field may be specified by the configuration value StorageRuleField.
Note:
These metadata fields are added by File Store Provider on startup, and if deleted, are added again when Content Server restarts. If the metadata fields must be permanently deleted, set the configuration variableFsAddExtraMetaFields=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.Setting the Default Storage Directory
A StorageDir parameter may be set equal to a root directory, used for all partitions where the PartitionRoot column value has not been specified. In this case the storage directory and the partition name is used to create the PartitionRoot parameter. The StorageDir parameter is set in the intradoc.cfg file, located in the DomainHome/ucm/cs/bin directory.
Standard File Store Provider Variables
In the provider.hda located in the IntradocDir/data/providers/defaultfilestore directory, the following parameters and classes are standard for a file system store:
ProviderType=FileStore ProviderClass=intradoc.filestore.BaseFileStore IsPrimaryFileStore=true # Configuration information specific to a file system store provider. ProviderConfig=intradoc.filestore.filesystem.FileSystemProviderConfig EventImplementor=intradoc.filestore.filesystem.FileSystemEventImplementor DescriptorImplementor=intradoc.filestore.filesystem.FileSystemDescriptorImplementor AccessImplementor=intradoc.filestore.filesystem.FileSystemAccessImplementor
When the File Store Provider default file store is upgraded, checked-in content and associated metadata are examined and assigned a storage rule based on criteria established by the system administrator. Criteria can include metadata, profiles, or other considerations. The storage rule determines how vault and web files are stored and accessed by Content Server and how they are accessed by a Web server. Files can be stored in a database or placed on one or more file systems or storage media. Partitions can be created to help manage storage location, but are not required.
This section covers the following topics:
The system administrator can upgrade the default file store to make use of functionality exposed by File Store Provider. After the default file store is upgraded, the web, vault and web URL file path expressions can be modified.
Caution:
File Store Provider should not be disabled after the default file store has been upgraded. If you have not yet upgraded the default file store, you can disable the component following the procedure in "Enabling and Disabling a Component".To upgrade the default file store, perform these steps:
Log in to Content Server as a system administrator.
Open the Administration tray and click Providers. The Providers Page is displayed.
Click Info in the Action column next to the DefaultFileStore provider. The FileStore Provider Information Page is displayed.
Click Upgrade. The Edit File Store Provider Page is displayed.
Click Update to submit the change. The Providers Page is displayed.
Note:
Do not navigate away from the Edit File Store page before clicking Update to submit the change. If you do not update, the upgraded file store provider will not be in effect.Restart Content Server.
You can create partitions to define additional root paths to files managed by Content Server but requiring storage in different locations or on different types of media. You create partitions using the Partition Listing Page. When a new partition is created, Content Server modifies the PartitionList resource table in the fsconfig.hda file, located in the IntradocDir/data/filestore/config/ directory.
Note:
Oracle WebLogic Server does not support configuring its Web server for Content Server to add a new virtual directory and alias to point to the weblayout directory for each partition that is created. While partitions can be used for the vault files, in 11g Release 1 (11.1.1) partitions are not supported for web files.To add a partition to Content Server, perform these steps:
Open the Administration tray and click File Store Administration.
If there are no partitions defined, click Add Partition. Otherwise, the Add/Edit Partition Page is displayed.
Enter a partition name. The name must be unique.
Modify the partition root, duplication methods, and any other pertinent parameters. See Add/Edit Partition Page for more information.
Ensure that Is Active is enabled.
Click Update. The Partition Listing Page is displayed.
You may edit the default file store provider at any time. To edit the file store, perform these steps:
Log in to Content Server as a system administrator.
Open the Administration tray and click Providers. The Providers Page is displayed.
Click Info in the Action column next to the DefaultFileStore provider. The FileStore Provider Information Page is displayed.
Click Edit. The Edit File Store Provider Page is displayed.
Make the necessary modifications and click Update to submit the changes. The Providers Page is displayed.
Note:
Do not navigate away from the Edit File Store page before clicking Update to submit the change.Restart Content Server.
You may add multiple storage rules to the file store.
Important:
Storage rules cannot be deleted. Carefully consider each storage rule before you create it.Caution:
Changing a storage rule after content has been checked in to Content Server may cause Content Server to lose track of the content.To add or edit storage rules, perform these steps:
Log in to Content Server as a system administrator.
Open the Administration tray, and click Providers. The Providers Page is displayed.
Click Info in the Action column next to the DefaultFileStore provider. The FileStore Provider Information Page is displayed.
Click Edit. The Edit File Store Provider Page is displayed.
Select Add new rule, or select the name of the rule to edit from the Storage choice list, and click Edit rule. The Add/Edit Storage Rule Page is displayed.
Make the necessary modifications to the storage rule, and click OK. The Edit File Store Provider Page is displayed.
Click Update. The Providers Page is displayed.
Important:
If the Web root used in the web URL file path defined in the storage rule is something other than the default weblayout directory defined for Content Server, you must add an alias or virtual directory in your Web server for the Web root used in the storage rule. Otherwise, Content Server does not know where to access the file. For information on adding virtual directories to your Web server, see the documentation that came with your Web server.When a content item is checked in to Content Server, it consists of metadata, a primary file selected by the user, and potentially 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. 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 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.
Depending on how you set up File Store Provider, you may or may not have a static web URL. By using a dynamic Content Server service request, you can access content when you do not know the specific location. With File Store Provider, the static web URL is defined as the web URL file, and the dynamic access is simply called the web URL. On the File Store Provider user interface, you can configure only the static web URL file path. However, you can decide to have the static web URL done as a Content Server service request, essentially making it dynamic.
This section covers the following topics:
When content is checked in, all versions of the content managed by Content Server are considered renditions. These renditions include the native file, web-viewable file, and any other files that may have been rendered by Inbound Refinery or third-party conversion applications.
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.
The following examples illustrate how storage rules can determine where and how different content items can be stored.
A storage rule is defined as File system only on the Add/Edit Storage Rule Page and the Is Webless File Store is disabled. In this scenario, the system makes a copy of the primary files and places them in the weblayout directory.
This traditional file system storage example typically offers the advantage of faster access time to content when compared with database storage. This advantage diminishes if the file system hierarchy is complex or becomes saturated, or as the quantity of content items increases.
A storage rule is defined as File system only on the Add/Edit Storage Rule Page and the Is Webless File Store is enabled. 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:
The web-less option of FileStoreProvider can specify that no web rendition be created. When this is used in conjunction with Inbound Refinery, a web rendition is always created and stored in either the file system or the database, depending on the storage rule in effect.This traditional file system storage example, like the previous one, offers the advantage of faster access time to content. It also saves on storage space by not copying a version of the content from the vault directory to the weblayout directory. Instead, it redirects web-viewable access to the content in the vault directory. This is useful if most of the native files checked in are in a web-viewable format, or if Content Server is being used to manage content that is not required to be viewed in a browser.
A storage rule is defined as JDBC Storage on the Add/Edit Storage Rule Page and no selection is made from the Renditions choice list. In this scenario, both the vault and web files are stored in the database.
This database storage example offers the advantage of integrating repository management with database management for consistent backup and monitoring processes, and helps overcome limitations associated with directory structure and number of files per directory in a file system approach.
Important:
When necessary, content items stored in a database can be forced onto the file system, for example, during indexing or conversion. The files on the file system are treated as temporary cache and deleted following the parameters specified in the config.cfg file located in the IntradocDir/config directory. For more information on the parameters used, see FileCache Table.A storage rule is defined as JDBC Storage on the Add/Edit Storage Rule Page 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.
This mixed approach of storing native files in a database but web-viewable files on a file system offers the advantages of database storage in the previous example (integrated backup and monitoring, overcoming file system limitations) for the native files, while providing speedy web access to web-viewable renditions. Like the first example, this advantage can be diminished if the file system structure is overly complex, or the quantity of files is extreme.
The path to content stored in Content Server is defined in the PathExpression column of the PathConstruction Table. Paths are made up of pieces, with each piece separated by a slash (/). Each piece can be made of a static string or a sequence of dynamic parts. A dynamic part is encapsulated by a dollar sign ($). A part may be calculated using an algorithm, Idoc Script variable, environment variable or a metadata lookup, and can have the following interpretations:
It may be a field defined in the PathMetaData table. If it is defined in the PathMetaData table, it may be mapped to an algorithm, for example, $dDocType$.
If it has the prefix #env., it is an environment variable, for example, $#env.VaultDir$.
It may be an Idoc Script variable, for example, $HttpWebRoot$.
For example, the standard vault location is defined as
$PartitionRoot$/vault/$dDocType$/$dDocAccount$/$dID$$ExtensionSeparator$$dExtension$
When parsed, the path expression turns into five pieces, interpreted according to the rules specified in the PathMetaData table as follows:
$PartitionRoot$: mapped to the partitionSelection algorithm and uses the xPartitionId as a lookup into the PartitionList table to determine the partition root.
/vault/: a string, so no calculation or substitution
$dDocType$: by the PathMetaData table this is a look up in the file parameters
$dDocAccount$: this is mapped to a documentAccount algorithm which takes dDocAccount and parses it into the standard Content Server account presentation with all the appropriate delimiters
$dID$$ExtensionSeparator$$dExtension$: this piece has three parts:
$dID$: similar to dDocType, this is defined in the file parameters and is a required field
$ExtensionSeparator$: determined by an algorithm and by default it returns '.'
$dExtension$: similar to dDocType
In the standard configuration, the URL contains security and dDocType information as well as the dDocName and extension. The URL and the Web location is constructed as follows:
…/groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/$dDocName$.$dWebExtension$
The groups separator indicates to Content Server that the directories that follow are the name of the security group and account to which the content item belongs. Accounts are optional and consequently computed by an algorithm. After the security information, we have the documents separator, which is immediately followed by the dDocType. The last part of the URL is the dDocName and its format extension.
Because the URL is expected in this format, Content Server can successfully extract metadata from it. More importantly, it can determine the security information for the content item and derive the access privileges for a particular user.
The parsing guidelines have been expanded to allow for dispersion in the Web directory. The groups separator is kept, but the documents separator may be replaced with sg. When the parse encounters the sg separator, it no longer assumes that the remaining part of the URL is /sg/$dDocName$.$dWebExtension$. Instead, the parser looks for the dispersion end marker d. When the d is encountered, the system assumes that the following information contains the dDocName and dWebExtension as before. This means that the system can now successfully parse URLs of the form
../groups/$dSecurityGroup$/$dDocAccount$/sg/<dispersion>/<dispersion>…/d/$dDocName$.$dWebExtension$
This section covers the following topics:
The PartitionList table defines the partitions that are available for the partitionSelection algorithm. The table is defined in the fsconfig.hda file, located in the DomainHome/ucm/cs/data/filestore/config/ directory, and modified using the Add/Edit Partition Page in the Content Server user interface. The columns of the table are used as follows:
The StorageRules table defines the rules used for storing content items. The rule specifies which path expression to use for which storage class, how content items are to be stored.
The table is defined in the provider.hda file, located in the DomainHome/ucm/cs/data/providers/defaultfilestore/ directory, and modified using the Add/Edit Storage Rule Page in the Content Server user interface. The columns of the table are used as follows:
The PathMetaData table defines what metadata is used to determine the location of a file. The metadata may come directly from a content item's metadata, or be calculated using an algorithm. The PathMetaData table is defined in the provider.hda file of the defaultfilestore directory. The defaultfilestore directory is located in the DomainHome/ucm/cs/data/providers/ directory.
The columns of the table are used as follows:
The PathConstruction table maps a file to a path. The PathConstruction table is defined in the provider.hda file of the defaultfilestore directory. The defaultfilestore directory is located in the DomainHome/ucm/cs/data/providers/ directory. For more information, see also "Understanding Path Construction and URL Parsing".
Caution:
The defaults provided in the PathConstruction table should work for most scenarios. This resource file should not be edited directly. Proper modification should be done through additional component development. For more information on component development, see the "Working with Components" chapter in the Oracle Fusion Middleware Developer's Guide for Content Server.The columns of the PathConstruction table are defined as follows:
The FileSystemFileStoreAlgorithmFilters table is used to map an algorithm name to an implementation of the FilterImplementor interface. The algorithm can be referenced in the PathMetaData Table and is used to calculate the desired path field. The class implementing the algorithm must return the required metadata fields it uses for calculation, when the file parameters object is null. Through the ExecutionContext, the doFilter method is passed in information about the field, content item, and file store provider that initiated the call. In particular, for the file system provider, the algorithm will be passed the following information through the ExecutionContext. Bear in mind that other file store providers may choose to pass in more or possibly different information.
Properties fieldProperties = (Properties)
context.getCachedObject("FieldProperties");
Parameters data = (Parameters)
context.getCachedObject("FileParameters");
Map localData = (Map) context.getCachedObject("LocalProperties");
String algorithm = (String) context.getCachedObject("AlgorithmName");
The FileSystemFileStoreAlgorithmFilters table is part of File Store Provider and requires a component along with Java code to modify.
Caution:
The defaults provided in the FileSystemFileStoreAlgorithmFilters table should work for most scenarios. This resource file should not be edited directly. Proper modification should be done with Java code and through additional component development. For more information on component development, see Oracle Fusion Middleware Developer's Guide for Content Server.The FileStorage table is added to the Content Server when File Store Provider is installed. It is used exclusively by the JdbcStorage storage type, when content is stored in a database. The FileStorage table contains the renditions of content items and uses the dID of the content item and rendition to uniquely identify what renditions belong to which content item.
The FileCache table is added to the Content Server when File Store Provider is installed. It is used exclusively by the JdbcStorage storage type to remember which renditions have been placed on a file system. Renditions stored in a database are placed on a file system when required for a specific event, for example indexing or conversion. These files are often temporary and deleted after a specified interval as part of a scheduled event.
In this section, we explicitly list the contents of the tables contained in the provider definition file (provider.hda) for each of the examples. The provider.hda file does not need to be edited manually. Proper modification of the provider.hda file should be done within the Content Server user interface using the Add/Edit Partition Page, or through additional component development. The provided default options for other resource tables, such as PathMetaData Table, PathConstruction Table, and FileSystemFileStoreAlgorithmFilters Table, should have sufficient flexibility for most scenarios.
This section covers the following topics:
In most of the examples, the following PathMetaData Table configuration definitions are used. The table has been trimmed of some it columns not pertinent to the examples for clarity.
@ResultSet PathMetaData
6
FieldName
GenerationAlgorithm
RequiredForStorage
<trimmed columns>
dID
#all
dDocName
#all
dDocAccount
documentAccount
dDocType
#all
dExtension
#all
dWebExtension
weburl
dSecurityGroup
#all
dRevisionID
#all
dReleaseState
#all
dStatus
web
xPartitionId
partitionSelection
ExtensionSeparator
extensionSeparator
xWebFlag
RenditionId
#all
RevisionLabel
revisionLabel
RenditionSpecifier
renditionSpecifier
@end
File Store Provider can be configured to place content on a file system in the standard Content Server locations.
The first step is to define the storage rule. In this case, the storage rule will be of type FileStorage, because all content is to be stored on the file system.
Example:
@ResultSet StorageRules 4 StorageRule StorageType IsWeblessStore RenditionsOnFileSystem default FileStorage @end@
The second step is to define the path construction for each of the storage classes for the rule. In general, the last part of the path should be standard for all usage examples. If not, then Content Server does not work well with hcs* files. However, the root path can be changed without affecting functionality, assuming that changing the web URL file path root is properly acknowledged by the Web server as a Content Server Web root.
In this configuration, the vault, web and web URL storage classes need to be defined in the PathConstruction Table. The path expression for the vault has already been discussed in \"Understanding Path Construction and URL Parsing". So we will only look at the web path expression, which differs from the Web URL only in its root. In other words, the Web path is an absolute path on the file system, while the web URL is a URL served up by a Web server.
Example:
@ResultSet PathConstruction 4 FileStore PathExpression AutoCreateLimit IsWritable StorageRule vault $#env.VaultDir$$dDocType$/$dDocAccount$/$dID$$ExtensionSeparator$$dExtension$ 6 true default weburl $HttpWebRoot$groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/ $dDocName$$RenditionSpecifier$$RevisionLabel$$ExtensionSeparator$ $dWebExtension$ 3 false default web $#env.WeblayoutDir$groups/$dSecurityGroup$/$dDocAccount$/documents/ $dDocType$/$dDocName$$RenditionSpecifier$$RevisionLabel$$ExtensionSeparator$$dWebExtension$ 3 true default @end
The Web path construction is defined to be:
$#env.WeblayoutDir$groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/ $dDocName$$RenditionSpecifier$$RevisionLabel$$ExtensionSeparator$$dWebExtension$
This is parsed into its parts and are as follows:
In this example, the previous example storage rule is configured to have IsWeblessStore set to true and consequently the web-viewable file will not be created by default. However, if the document is processed through Inbound Refinery or WebForms or any other component that requires a web-viewable, the web file will be created. The location of the files is as above in the 'standard' configuration. However, since a file may not have a web rendition, the web URL path must be adjusted. Also, note the use of web URL.file. This is used to compute the URL when the web-viewable actually exists. The metadata field xWebFlag is used to determine how the file is to be served up in the browser.
@ResultSet StorageRules 4 StorageRule StorageType IsWeblessStore RenditionsOnFileSystem default FileStorage true @end@
@ResultSet PathConstruction
4
FileStore
PathExpression
AutoCreateLimit
IsWritable
vault
$#env.VaultDir$$dDocType$/$dDocAccount$/$dID$$ExtensionSeparator$$dExtension$
6
true
default
weburl
$HttpCgiPath$?IdcService=GET_FILE&dID=$dID$
&dDocName=$dDocName$&allowInterrupt=1&noSaveAs=1&fileName=$dOriginalName$
3
false
default
weburl.file
$HttpWebRoot$groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/
$dDocName$$RenditionSpecifier$$RevisionLabel$$ExtensionSeparator$
$dWebExtension$
3
false
default
web
$#env.WeblayoutDir$groups/$dSecurityGroup$/$dDocAccount$/documents/
$dDocType$/$dDocName$$RenditionSpecifier$$RevisionLabel$
$ExtensionSeparator$$dWebExtension$
3
true
default
@end
To store files in the database, we need a storage rule that is of type JdbcStorage. By default, all content items belonging to this rule have their files stored in the database. However, even though the files are stored in the database, there is the presumption of an underlying file system and the system may need to temporarily cache a file on the file system. In particular, this may happen for indexing or for some conversions.
Tech Tip:
A rule can be configured to always store renditions belonging to a given storage class on the file system. This is most useful for systems that store vault files in the database, but web files on the file system.In the default rule below, all files are stored in the database, while the filesInWeb rule stores the vault files in the database and the web files on the file system.
@ResultSet StorageRules 4 StorageRule StorageType IsWeblessStore RenditionsOnFileSystem default JdbcStorage filesInWeb JdbcStorage web @end@
@ResultSet PathConstruction
4
FileStore
PathExpression
AutoCreateLimit
IsWritable
StorageRule
vault
$#env.VaultDir$$dDocType$/$dDocAccount/$dID$$ExtensionSeparator$$dExtension$
6
true
default
weburl.file
$HttpWebRoot$groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/
$dDocName$$RenditionSpecifier$$RevisionLabel$$ExtensionSeparator$
$dWebExtension$
3
false
default
web
$#env.WeblayoutDir$groups/$dSecurityGroup$/$dDocAccount$/documents/
$dDocType$/$dDocName$$RevisionLabel$$RenditionSpecifier$
$ExtensionSeparator$$dWebExtension$
3
true
default
@end
The previous examples have kept the file paths consistent with the standard configuration. For very large implementations, this can result in directory saturation and slow performance. The following examples aid in dispersing files over several storage options.
File Store Provider makes it easy to use partitions to create a sparser directory structure. By default, the xPartitionId metadata field is used and becomes a part of a content item revision's metadata information. It is recommended that this field is disabled on the Content Server user interface, instead letting the partition selection algorithm determine the partition to use. The partition selection algorithm looks at all the active partitions, and as a new content enters the system, the partitions are selected in order. Each partition has an entry in the "PartitionList Table" and can be declared active. The PartitionRoot is calculated from the xPartitionId, where the value is a look up key into the PartitionList table. If no xPartitionId is specified, the system finds the next available and active partition and uses this value for the location calculation. The xPartitionId is then stored as part of the content item's metadata.
To use the partition selection, define the vault storage class in the PathConstruction table as follows:
vault $PartitionRoot$/$dDocType$/$dDocAccount$/$dID$$ExtensionSeparator$$dExtension$ 6 true
Partitions can be deactivated using the "Add/Edit Partition Page" at any time if a system administrator needs to close a partition to contribution, for example if maintenance is required on the storage device.
Another way of dispersing files is to alter the path so that files get partitioned out by the dID of the content item. In the example below, the directories are limited to 10,000 files plus extra files for additional renditions.
If your path expression contains $dID[-12:-10:0]/$dID[-10:-8:0]$/$dID[-8:-4:0]$ and dID is 1234567890, the result is 00/12/3456.
Note the dID[-12:-10:0] in the path expression. This is interpreted as follows:
Get the characters starting at 12 back from the end of the string until you get the character 10 back from the end of the string.
Pad the resulting string to length 2, which 12-10, with 0 characters.