Using WebCenter Content with Low-Cost Object Storage Tiers

Overview

The OCI Object Storage service is an enterprise-scale storage platform that offers reliable and cost-efficient data durability. Oracle WebCenter Content integrates with this platform through the “OCIObjectStorage” storage provider component to facilitate the storage of extensive volumes of content in a scalable manner.

The OCI Object Storage service offers three storage class tiers to store data, enabling customers to select the most cost-effective storage tier for each piece of content based on access patterns.

This document outlines how to take advantage of OCI Object Storage capabilities in WebCenter Content and how to leverage storage tiers to optimize availability and storage costs for your enterprise content.

Prerequisites

To use OCI Object Storage with WebCenter Content and manage content across Standard, Infrequent Access and Archive storage class tiers, make sure that WebCenter Content is properly integrated with the OCI Object Storage service: - The “OCIObjectStorage” component needs to be enabled in WebCenter Content - The “Object Storage Configuration” page in WebCenter Content should provide the required OCI tenancy, compartment and authentication details - Set values for both OCIObjectStorageDefaultBucket (default storage bucket) and OCIObjectStorageTempObjectDefaultBucket (temporary storage bucket), and ensure that these buckets exist in the OCI tenancy.

If you selected Object Storage as the content storage strategy during provisioning of the WebCenter Content on Marketplace stack, this configuration is already completed. If a different content storage strategy was chosen and you need to configure WebCenter Content with the OCI Object Storage service after provisioning, follow the detailed steps in the “Administering Oracle WebCenter Content” guide - “12.4.5 Configuration for OCI Object Storage”.

Terminology

Take a moment to familiarize yourself with the following concepts:

Content Item Renditions

A document in WebCenter Content has one or more revisions or versions. Every single revision consists of a set of metadata and one or more “core” or “basic” renditions:

In addition to “core” renditions, a document revision can also store one or more non-core renditions:

Where and how these renditions are stored is determined by the storage rule set on the document revision.

Storage Rules

The concept of Storage Rules was introduced by the FileStoreProvider component. This component is enabled by default in WebCenter Content and is used to manage where content is stored.

A WebCenter Content Marketplace Stack comes with the following storage rules:

Storage RuleStorage TypeDescription
defaultFile System• Provided for backward compatibility.
• All renditions are stored on the file system in VaultDir (/u01/shared/ucm/cs/vault/) and WebLayoutDir (/u01/shared/ucm/cs/weblayout/) locations.
• Dispersion based on a unique dRevClassID identifier to distribute files over multiple subdirectories.
webassetFile System• Provided for backward compatibility.
• All renditions are stored on the file system in VaultDir (/u01/shared/ucm/cs/vault/) and WebLayoutDir (/u01/shared/ucm/cs/weblayout/) locations.
• No dispersion is used.
DispByContentIdFile System• Default storage rule when “File System” was chosen as content storage strategy.
• All renditions are stored on the file system in VaultDir (/u01/shared/ucm/cs/vault/) and WebLayoutDir (/u01/shared/ucm/cs/weblayout/) locations.
• Dispersion based on the unique dDocName identifier to distribute files over multiple subdirectories.
DispByRevClassIdFile System• All renditions are stored on the file system in VaultDir (/u01/shared/ucm/cs/vault/) and WebLayoutDir (/u01/shared/ucm/cs/weblayout/) locations.
• Dispersion based on a unique dRevClassID identifier to distribute files over multiple subdirectories.
JDBCStorageRuleDatabase• Renditions are stored in the database FILESTORAGE table as BLOBs.
• Operations such as conversion or indexing of content may temporarily cache renditions out to the file system.
OCIObjectStorageRuleOCIObjectStorage• Created by the “OCIObjectStorage” component that extends the FileStoreProvider.
    ◦ enabled if you selected Object Storage as the content storage strategy when provisioning the WebCenter Content on Marketplace stack
• All renditions are stored in the default storage bucket (OCIObjectStorageDefaultBucket)
• Operations such as conversion or indexing of content may temporarily cache renditions out to the file system.
• Supports core renditions in Standard and InfrequentAccess storage tiers (all renditions are always accessible).
• Suppresses duplication: when a new document is uploaded that is identical to an existing document (in terms of content) then core renditions will be stored only once
OCIArchiveEnabledStorageRuleOCIObjectStorage• Created if “Object Storage” was chosen as the content storage strategy when provisioning the WebCenter Content on Marketplace stack.
• Core renditions (native, web and alternate) are stored in the non-default storage bucket specified at the time of provisioning
• Non-core renditions (thumbnail, preview, attachments, …) are stored in the default storage bucket (OCIObjectStorageDefaultBucket)
• Operations such as conversion or indexing of content may temporarily cache renditions out to the file system.
• Supports core renditions in Standard, InfrequentAccess and Archive storage tiers.
    ◦ core renditions in Standard and InfrequentAccess tiers are always accessible
    ◦ core renditions in Archive tier are accessible when restored
• non-core renditions are always accessible
• Supports limited duplication suppression: every document version will store its own set of renditions. If those renditions are identical in terms of content then only one copy will be physically stored

Controlling How Content Items Are Stored

How and where the core renditions for a content item are physically stored is controlled at check-in by setting a Storage Rule metadata value.

Fig. 1: Specifying a Storage Rule during Document Upload

The “Storage Rule” field can be hidden on the UI and configured with a default storage rule value such as OCIObjectStorageRule. This is recommended if you have a uniform storage policy where all content renditions share a similar lifecycle and are stored in the same way. Alternatively, administrators can set up Profiles, (Global) Rules or default Folder metadata to automatically assign the appropriate Storage Rule value based on the Content Type, the folder an item is uploaded to or other chosen criteria.

For example: an administrator may choose to configure

IMPORTANT: The “Storage Rule” attribute applies at the version (revision) level, allowing each document version to have its own storage configuration. This enables organizations to relocate older versions to cheaper storage tiers or storage buckets with archiving lifecycle policies, while keeping active versions readily accessible.

When uploading a new document using the REST API, the storage rule can be specified using the xStorageRule attribute:

### Example document upload setting the OCIObjectStorageRule storage rule
    curl -X POST --location 'https://myWCCservice:16200/documents/wcc/api/v1.1/files/data' \
    --header 'Authorization: ${OAUTH_TOKEN}' \
    --form 'primaryFile=@"/home/oracle/www/index.html"' \
    --form 'metadataValues="{ \"dDocTitle\":\"index.html\",\"dSecurityGroup\":\"Public\",\"dDocType\":\"Document\", \"xStorageRule\":\"OCIObjectStorageRule\" }"'

Modifying the Storage Rule metadata value for an existing content item revision will move renditions to the new storage rule destination. For example: an items’ core renditions stored in the default OCI Object Storage bucket using the OCIObjectStorage rule can be moved to an Archive-storage enabled bucket by updating the value to OCIArchiveEnabledStorageRule. Similarly, propagating the Storage Rule field value on a folder will relocate renditions for all files in that folder to the new storage rule location.

When modifying a document using the REST API, the storage rule can be set using the xStorageRule attribute:

### Example document update to set storage rule value for content item with revision dId 56609733 
    curl -X PUT --location 'https://myWCCservice:16200/documents/wcc/api/v1.1/files/.by.did/56609733' \
    --header 'Authorization: ${OAUTH_TOKEN}' \
    --form 'metadataValues="{ \"xStorageRule\":\"OCIArchiveEnabledStorageRule\" }"'

Earlier versions or WebCenter Content on Marketplace may hide the Storage Rule field on the UI. In such case, the following steps can be used to display the field on the UI:

  1. Access the WebCenter Content native interface (https://:16200/cs) as an Administrator

  2. Navigate to the Administration > Admin Applets page

  3. Start the Configuration Manager applet
    • TIP: download and run the Desktop client administration tool if your client browser prohibits the use of applets

  4. Select the “StorageRule” field

  5. Check “Enable on User Inferface” and click “OK”

  6. Verify that the Storage Rule field is displayed on the UI.     ◦ TIP: refresh the page or clear the browser cache if the field is not displayed

Fig. 2: Editing the StorageRule field in the Configuration Manager applet

Managing Storage Rules

If you selected Object Storage as the content storage strategy during provisioning of the WebCenter Content on Marketplace stack then the following storage rules are available for integration with OCI Object Storage:

Administrators can create additional storage rules to accommodate more complex storage requirements. Each storage rule can be configured to store core document renditions in a separate OCI storage bucket that is equipped with a storage lifecycle policy that moves objects to a lower-cost storage tier after a certain period. A storage rule also dictates the default storage tier to be used for any new document renditions that are stored. This storage rule mechanism provides flexibility for implementing tiered storage strategies, where you can route different document types to appropriate storage configurations based on their expected usage patterns.

Example use case: an HR department needs to store employees contracts" and payslips. Both document types have distinctly different access patterns: contracts are rarely accessed but should be accessible for viewing at all times. Payslips are regularly accessed with peak activity during pay period.

In this scenario, an administrator could configure

Creating a new Storage Rule

  1. Access the WebCenter Content native interface (https://YourWCCServiceHost:16200/cs) as an Administrator

  2. Navigate to the Administration > Object Storage > Object Storage Configuration page

  3. Click “Add storage rule”

Fig. 3: The Object Storage Configuration page

  1. Select “OCI Object Storage” as the storage rule type

  2. Specify storage rule options:

ParameterDescription
Core Renditions Storage Bucket• Identifies the OCI storage bucket that will be used to store core (primary/web/alternate) renditions.
• If you specify a bucket that does not exist then it will be created automatically upon saving the storage rule.
• Falls back to default bucket (OCIObjectStorageDefaultBucket) if blank.
• Buckets names are case sensitive and are limited to 256 characters.
• Valid characters are letters (upper or lowercase), numbers, hyphens, underscores, and periods.
Archive Storage Tier Support• Controls if document core renditions with this rule can move to the Archive storage tier (in addition to Standardand Infreqent Storagetiers)
• Cannot be enabled for storage rules writing to the default bucket (OCIObjectStorageDefaultBucket).
• Cannot be enabled if you have another rule writing to the same Core Renditions Storage Bucket that was created without Archive Storage Tier Support.
• Must be enabled if you have another rule writing to the same Core Renditions Storage Bucket that was created with Archive Storage Tier Support.
Default Storage Tier• Defines the storage tier to use for any new document core renditions checked in with this Storage Rule.
    ◦ (Bucket default): renditions will be stored using the default storage tier configured on the OCI storage bucket
    ◦ Standard or Infrequent Access: renditions will be stored in the respective storage tier.

 

NOTE: The Archive storage tier cannot be set as the default option for storing documents, even when storage rules enable Archive Storage Tier Support. This restriction exists intentionally because newly uploaded documents can require post-upload processing activities like fulltext indexing, conversion and workflow execution that need the physical content to remain accessible in either Standard or Infrequent Access tiers. Documents can only be moved to the Archive tier after processing is complete and they enter RELEASED status, provided their storage rule has Archive Storage Tier Support enabled.

  1. Press “OK” to save the storage rule

The new storage rules will be available immediately in the “Storage Rule” metadata field drop-down. TIP: refresh the page or clear the browser cache if the rule is not displayed

Existing storage rules can be modified as long as they are not actively used to store document revisions.

IMPORTANT: If you have configured the WebCenter Content stack with Cross-Region Disaster Recovery then you will want to create an object storage bucket in the standby region with the same name and configure a bucket replication policy to replicate any changes to the standby region.

Managing Documents in OCI Object Storage Tiers

The OCI Object Storage service offers three storage class tiers to store data, enabling customers to select the most cost-effective storage tier for each piece of content based on access patterns:

TierDescription
Standard Tier• Serves as the default storage class for Object Storage service data
• Optimized for frequently accessed data (“hot” storage)
• Provides immediate data availability
• Supported by OCIObjectStorageRule and OCIArchiveEnabledStorageRule storage rules
Infrequent Access Tier• Designed for data that is accessed less frequently (“cool” storage)
• Offers lower storage cost compared to the Standard tier
• Has minimum retention period and data retrieval fee
• Provides immediate data availability
• Supported by OCIObjectStorageRule and OCIArchiveEnabledStorageRule storage rules
Archive Tier• Intended for long-term historical or rarely accessed data (“cold” storage)
• Provides the lowest storage cost among all storage tiers
• Data is offline and must be restored before it becomes accessible
• Has minimum retention period
• Supported by OCIArchiveEnabledStorageRule storage rule

By default, WebCenter Content provides the “OCIObjectStorageRule” and “OCIArchiveEnabledStorageRule” storage rules for integration with OCI Object Storage. Both these storage rules support storing core renditions for documents in Standard or Infrequent Access Object Storage tiers. A storage rule is configured with a Default Storage Tier value that defines the storage tier for any new document core renditions checked in under this Storage Rule. Only Standard and Infrequent Access are available as default values.

The Storage Rule (xStorageRule) parameter specified at the time of document upload determines the bucket where to core renditions are stored. Within the assigned bucket, the storage rule Default Storage Tier setting determines whether renditions are placed in the Standard or Infrequent Access storage tier. Optionally, you can override the default storage tier configured on the storage rule at check-in by explicitly setting a xStorageTier metadata value.

### Example cURL call uploading a new document using the OCIObjectStorageRule and overriding xStorageTier to InfrequentAccess
    curl -X POST --location 'https://myWCCservice:16200/documents/wcc/api/v1.1/files/data' \
    --header 'Authorization: ${OAUTH_TOKEN}' \
    --form 'primaryFile=@"/home/oracle/www/index.html"' \
    --form 'metadataValues="{ \"dDocTitle\":\"index.html\",\"dSecurityGroup\":\"Public\",\"dDocType\":\"Document\", \"xStorageRule\":\"OCIObjectStorageRule\", \"xStorageTier\":\"InfrequentAccess\" }"'

Retrieving Storage Details for a Document

You can view detailed state and location information for documents core renditions using OCI Object Storage rules by navigating to the document’s “Content Information” page in the native interface:

Fig. 4: Storage Details on the Content Information page

NOTE: “Storage Object”, “Storage Bucket” and “ETag” values are only displayed for users with Administrator role. NOTE: Storage Details and storage content actions are displayed by default on the Content Information page for any revision that is stored in OCI Object Storage. To hide these features on the UI, add “OCIObjectStorageHideStorageUIFeatures=1” to the WebCenter Content config.cfg file.

To retrieve the information using the “Get Document Information (by dID)” REST API, pass getFullInfo=True to return the objectStorageInfo array.

### Example cURL call retrieving objectStorageInfo array for a given document
    curl --location 'https://myWCCservice:16200/documents/wcc/api/v1.1/files/WCCMEETING01?getFullInfo=True&fields=docInfo.dID,docInfo.dDocName,docInfo.xStorageRule,objectStorageInfo.*' --header 'Authorization: ${OAUTH_TOKEN}'

Example output:

{
      "docInfo": {
        "dID": 4614456,
        "dDocName": "WCCMEETING01",
        "xStorageRule": "OCIObjectStorageRule"
      },
      "objectStorageInfo": [
        {
          "renditionId": "primaryFile",
          "objectName": "abbf3d617ff7ce07b647a556a923faab8c364b061e1537ac2d1b29dea541f595-4614455",
          "bucketName": "wcclocal_defaultbucket",
          "size": "22151",
          "storageTier": "InfrequentAccess",
          "archivalState": null,
          "restoredUntil": null,
          "etag": "ac6a503b-1214-4976-9382-93337d3d063b",
          "md5Hash": "ap4xFhA/ya+i3jdToADwUg=="
        },
        {
          "renditionId": "webViewableFile",
          "objectName": "c250f7afa34c63221dce1f376a41a469d4021552407e411b26a98b99a6cdd9b8-4614455",
          "bucketName": "wcclocal_defaultbucket",
          "size": "123981",
          "storageTier": "InfrequentAccess",
          "archivalState": null,
          "restoredUntil": null,
          "etag": "5f43dafd-3788-450a-abfa-c4f8c62f553f",
          "md5Hash": "N+EX8oKtRYUgDtXgeuvB4A=="
        },
        {
          "renditionId": "alternateFile",
          "objectName": "c250f7afa34c63221dce1f376a41a469d4021552407e411b26a98b99a6cdd9b8-4614455",
          "bucketName": "wcclocal_defaultbucket",
          "size": "123981",
          "storageTier": "InfrequentAccess",
          "archivalState": null,
          "restoredUntil": null,
          "etag": "5f43dafd-3788-450a-abfa-c4f8c62f553f",
          "md5Hash": "N+EX8oKtRYUgDtXgeuvB4A=="
        }
      ]
    }

Description of fields in the ObjectStorageInfo array:

Field NameAdmin Role onlyDescription
renditionIdRendition type of the core rendition (primaryFile, webviewableFile or alternateFile)
objectNameXName of the physical object stored in the OCI Object Storage bucket.
The object can be shared by multiple renditions if content is identical.
bucketNameXStorage bucket that holds the object
sizeSize of the object
storageTierStorage tier holding the object (Standard, InfrequentAccess or Archive)
archivalStateArchival state of an object. This field is set only for objects in Archive tier.
restoredUntilTime that the object is returned to the archived state. This field is set only for restored revisions.
etagXThe current entity tag (ETag) for the object
md5HashBase64-encoded MD5 hash of the object data

Moving Documents to a Different Storage Tier

Moving documents to appropriate storage tiers delivers significant cost savings by aligning storage expenses with actual usage patterns - frequently accessed documents remain on the Standard tier for immediate availability, while older or rarely used documents transition to cheaper Infrequent Access and Archive tiers.

Storage tier transitions for document revisions follow these guidelines:

To move an individual revision to a different storage tier from the native ui, access the Content Information page and select the “Move to destination Storage Tier” option in the “Content Actions” drop-down menu.

Moving an individual revision to a different storage tier using the REST API can be done in two ways:

  1. By calling the “Update Storage Tier” API service (OCI_UPDATE_REV_STORAGE_TIER)
### Example cURL call moving the latest version of content item "WCCMEETING01" to Infrequent Access tier
    curl --location --request POST 'https://myWCCservice:16200/documents/wcc/api/v1.1/files/WCCMEETING01/storage/.updateStorageTier?storageTier=InfrequentAccess'  --header 'Authorization: ${OAUTH_TOKEN}'
### Example cURL call moving revision with dID 5000001 to Archive tier
    curl --location --request POST 'https://myWCCservice:16200/documents/wcc/api/v1.1/files/.by.did/5000001/storage/.updateStorageTier?storageTier=Archive'  --header 'Authorization: ${OAUTH_TOKEN}'
  1. By calling the Update Document REST API (UPDATE_DOCINFO) and passing a xStorageTier metadata value.
### Example cURL call moving the latest version of content item "WCCMEETING01" to Storage Rule "OCIArchiveAfter30Days" in storage tier "InfrequentAccess"
    curl --location --request PUT 'http://localhost:16200//documents/wcc/api/v1.1/files/WCCMEETING01' \
    --header 'Authorization: ${OAUTH_TOKEN}' \
    --form 'metadataValues="{ \"xStorageRule\":\"OCIArchiveAfter30Days\", \"xStorageTier\": \"InfrequentAccess\" }"'

Restoring Documents in Archive Storage Tier

Document revisions in the Archive storage tier are subject to these constraints:

To restore a document revision in Archive storage tier from the native UI, access the “Content Information” page and select the “Restore from Archive” option in the “Content Actions” drop-down menu.

Restoring an individual revision in Archive storage using the REST API can be done by calling the “Restore Document” API service (OCI_RESTORE_REV_FROM_ARCHIVE). The hours parameter can be used to limit the restoration window to less than the default 240 hours.

### Example cURL call restoring the latest version of content item "WCCMEETING01" for 48 hours
    curl --location --request POST 'https://myWCCservice:16200/documents/wcc/api/v1.1/files/WCCMEETING01/storage/.restoreFromArchive?hours=48'  --header 'Authorization: ${OAUTH_TOKEN}'
### Example cURL call restoring revision with dID 5000001 for 48 hours
    curl --location --request POST 'https://myWCCservice:16200/documents/wcc/api/v1.1/files/.by.did/5000001/storage/.restoreFromArchive?hours=48'  --header 'Authorization: ${OAUTH_TOKEN}'

Automating Storage Tiering and Archiving using OCI Object Storage Lifecycle Policies

Administrators can automate the transition of rendition objects between storage tiers in OCI Object Storage buckets by configuring either Auto-Tiering or Object Lifecycle Policy rules. The following sections explain how each feature interacts with WebCenter Content:

Auto-Tiering

Auto-Tiering is a built-in OCI Object Storage feature designed to optimize storage costs by automatically shifting data between the Standard and Infrequent Access tiers. When activated at the bucket level, it tracks access patterns for objects larger than 1 MB. If an object is not accessed for 31 days, it automatically transitions to the Infrequent Access tier. Conversely, objects that transitioned to the Infrequent Access tier that experience increased access are automatically promoted back to the Standard tier - without incurring any retrieval and prorated storage fees. Auto-Tiering will not transition objects to the Archive storage tier.

Auto-Tiering is compatible with all buckets used by WebCenter Content, including the default bucket (OCIObjectStorageDefaultBucket). However, it cannot be used in conjunction with a OCI Lifecycle Policy Rule that moves objects to the Infrequent Access tier.

PREREQUISITE: To use Auto-Tiering, you must authorize the OCI Object Storage service to manage objects on your behalf. Please refer to the documentation for specific instructions.

Using OCI Object Lifecycle Policy Rules

Object Lifecycle Policy rules offer granular control over object transitions between storage tiers. WebCenter Content storage rules at the revision-level dictate where various core renditions (primary, web, and alternate) are stored. Lifecycle Policy rules can then be applied to these buckets to move these renditions to Infrequent Access and/or Archive tiers after a predefined number of days.

Object Lifecycle policy rules can manage transitions to both the Infrequent Access and Archive storage tiers. However, rules that move objects to the Archive tier must target only those buckets associated with WebCenter Content storage rules that have Archive Storage Tier Support explicitly enabled.

IMPORTANT GUIDELINES:

PREREQUISITE: To use Object Lifecycle Policies, you must authorize the OCI Object Storage service to manage objects on your behalf. Please refer to the documentation for specific instructions.

Example Use Case: Tiered Storage Strategy with WebCenter Content and OCI Object Storage Lifecycle Policies

Scenario: A telecommunications provider processes millions of electronic invoices monthly for their customer base and must retain them for regulatory compliance. The following configuration illustrates a storage strategy using OCI Object Lifecycle Policies.

Initial Configuration

First, the WebCenter Content administrator sets up the following:

Tiered Storage Lifecycle

Next, the WebCenter Content Administrator implements the following tiered storage strategy:

Fig. 5: Editing a Buckets Lifecycle Policy Rules in OCI Cloud Console

Known Limitations for WebCenter Content Documents in Archive Storage Tier

Certain WebCenter Content features depend on revision accessibility, and transitioning document renditions to the Archive tier can affect the following operations:

References