| Oracle® Fusion Middleware Oracle WebCenter Contentの管理 11g リリース1 (11.1.1) B72425-03 |
|
 前 |
 次 |
この章では、Oracle WebCenter Content Serverのファイル・ストア・システムを構成する方法と、ファイル・ストア・プロバイダを使用する方法について説明します。
この章の内容は次のとおりです。
|
注意: Oracleでは、WORMオプションが指定されたSun Storage Archive Manager (SAM-QFS)を、コンテンツ・サーバーの標準ファイル・ストア・システムの代替システムとしてサポートしています。詳細は、第12.5項を参照してください。 SAM-QFSを使用するようにコンテンツ・サーバーを構成した後で、標準のファイル・ストア・システムを使用するように戻すことはできません。 |
バージョン11gR1の発売により、コンテンツ・サーバーでは、コンテンツの格納および編成用の従来のファイル・システムにかわり、データ管理用のファイル・ストア・システムが実装されました。FileStoreProviderコンポーネントは、コンテンツ・サーバー・インタフェースでファイル・ストア機能を公開し、追加の構成オプションを許可します。たとえば、コンテンツ・サーバー・インスタンスを、ファイル・システムを使用するかわりに、バイナリ・ラージ・オブジェクト(BLOB)データ型を使用して、コンテンツをデータベースに格納するように構成できます。この機能にはいくつかの利点があります。
一貫したバックアップおよび監視プロセスのために、リポジトリ管理をデータベース管理と統合します。
ファイル・システムの方法での、ディレクトリ構造とディレクトリ当たりのファイル数に関連した制限を克服するのに役立ちます。
システム間でのコンテンツの配布をより簡単にする上で役立ち、コンテンツ・サーバーの拡大縮小が容易になります。
たとえば、コンテンツ・アドレス・ストレージ・システムや、一部のビジネス用に必要な書込み専用デバイスなど、一般にファイル・システムとは関連付けられていない様々なタイプのストレージ・デバイスが使用できます。
データベースで管理するデータの量が大規模な場合にデータベースを実行し続けるための1つのソリューションは、コンテンツ・リポジトリに対してデータベース・パーティションを使用することです。この場合は、注意深く計画する必要があります。詳細は、Oracle Database 11gを使用したWebCenter Content用のパーティション化されたリポジトリのブログを参照してください。
|
注意: FileStoreProviderコンポーネントは、コンテンツ・サーバーのデプロイ時にデフォルトでインストール、有効化およびアップグレードされます。デフォルトのファイル・ストアがアップグレードされた後で、アンインストールまたは無効化を実行しないでください。アップグレードの詳細は、第12.2項を参照してください。 コンテンツ・サーバー・ソフトウェアの旧バージョンを使用していて、デフォルトのファイル・ストアをまだアップグレードしていない場合、第9.2.2項にある手順に従い、そのコンポーネントを無効にできます。 |
この項の内容は次のとおりです。
コンテンツ・サーバーでは、電子ファイルおよびそれらの関連メタデータのストレージを追跡することにより、コンテンツを管理します。その結果、ユーザーはチェックイン・ファイル、すべての関連情報および関連レンディションの格納とアクセスが可能です。この項では、これまでコンテンツ・サーバーで使用されてきたデータ管理方法と、FileStoreProviderコンポーネントでそれらにどのように対処するかについて説明します。
データ管理の前半は、コンテンツ・サーバー・リポジトリにチェックインした電子ファイルの格納です。コンテンツ・サーバーでは、通常、ファイル保存は従来のファイル・システムによって行われ、電子ファイルは、ボールト・ディレクトリおよびWebレイアウト・ディレクトリを含む階層型ディレクトリ構造に格納されます。コンテンツ・タイプ、セキュリティ・グループおよびアカウント(使用されている場合)によって指定されたリビジョン情報を使用して、ファイルおよびそれらの関連レンディションが、ボールト・ディレクトリおよびWebレイアウト・ディレクトリ内の特定のディレクトリに格納されます。たとえば、チェックイン時に指定したプライマリ・ファイルと代替ファイルは、ボールト・ディレクトリのサブディレクトリに格納されます。特定のファイルの場所は、次のように定義します。
IntradocDir/vault/dDocType/account/dID.dExtension
このパス名で、dDocTypeはチェックイン時にユーザーが選択したコンテンツ・タイプ、dIDはこのリビジョンを識別するシステムで生成された一意のID、dExtensionはチェックインされたファイルの拡張子です。この階層モデルでは、dDocTypeメタデータ・フィールドを使用して、ボールト・ディレクトリ内に構築された階層内でファイルが配布されます。同様に、すべてのWebレンディションは、IntradocDir/weblayout/groups/ディレクトリ内の階層全体で配布されます。Webレンディションとは、Webサーバーから供給されたファイルで、従来のファイル・システムの保存方法では、ネイティブ・ファイル、代替ファイル、またはInbound Refineryやその他の変換アプリケーションによって生成されたWeb表示可能ファイルでした。
この簡単なファイルの保存場所の決定は、コンポーネントおよび機能作成者にとっては便利で、ファイルの保存場所やそれらの操作方法を理解するのに役立ちます。ただし、ストレージ管理を制限する影響もあります。位置メタデータの管理を慎重に行わないと、ディレクトリが飽和状態になって、システムの処理速度低下の原因になる可能性があります。
データ管理の後半は、電子ファイルに関連付けられたメタデータの格納です。コンテンツ・サーバーでは、メタデータ管理は通常、主として3つのデータベース表を含むリレーショナル・データベースを使用して行われてきました。メタデータは、ユーザーによるコンテンツのカタログ作成を可能にし、コンテンツ・サーバー・リポジトリ内でファイルを見つけやすくするファイル記述子作成の手段にもなります。ユーザーにとって、取得はコンテンツ・サーバーによって行われ、ファイルの格納方法や場所は完全に非表示にできます。ファイルの生成または操作が必要になる可能性のあるコンポーネントおよび機能作成者にとっては、メタデータはアクセスの強力な手段となります。
コンテンツ・サーバーでこれまで使用されてきた従来のファイル・システム・モデルは、拡張性にかぎりがあります。データ管理の必要が増えるにつれて、記憶領域を増やすために記憶装置を追加すると、Webベースのインタフェースを通して簡単にファイルを共有しにくくなります。ネストされて複雑になったファイル構造は、パフォーマンスを低下させる可能性があります。ネイティブ・ファイル形式が使用される可能性のある場合、重複するWeb表示可能ファイルの作成を抑制することは難しくなります。たとえばコンテンツ・アイテムが1億を超えるような大規模システムに対応するため、コンテンツ・サーバーでは、ファイル・ストアを使用するようになりました。これは、拡張性、柔軟性および管理容易性に効果を発揮します。
FileStoreProviderコンポーネントを使用すれば、コンテンツ・サーバーによって管理されるコンテンツの格納およびアクセスに、データ駆動型のルールを定義できます。ファイル・ストア・プロバイダには、次の機能が用意されています。
ファイルの場所を簡単に移動する機能
Web表示可能ファイルをオプションにする機能
ディレクトリの飽和状態を管理および制御する機能
サード・パーティの記憶装置を統合する機能
様々なストレージの例を使用、拡張および強化するAPI
ファイル・ストア・プロバイダにより、チェックインされたコンテンツおよび関連のメタデータは検査され、システム管理者によって設定された基準に基づきストレージ・ルールが割り当てられます。基準としてはメタデータ、プロファイルまたはその他の考慮事項が含まれます。ストレージ・ルールは、ボールト・ファイルおよびWebファイルをコンテンツ・サーバーで格納する方法、およびWebサーバーによりアクセスする方法を決定します。
コンテンツ・サーバー・インスタンス(ドキュメントなし)の場合、FileStoreProviderコンポーネントはデフォルトでインストール、有効化およびアップグレードが行われます。アップグレードでは、ファイル・ストア・システム(DefaultFileStore)用のデフォルト値の入ったメタデータ・フィールドが作成されます。ドキュメントが含まれる既存のコンテンツ・サーバー・インスタンスがあり、新しいバージョンのコンテンツ・サーバーにファイル・ストア・プロバイダがアップグレードされていない場合、ファイル・ストア・プロバイダのアップグレードは自動的には実行されません。
現在の設定からファイル・ストア・プロバイダをアップグレードしないようにするには、アップグレードのインストールの前に、構成変数FsAutoConfigure=falseをコンテンツ・サーバーのconfig.cfgファイルに追加する必要があります。
|
注意: コンテンツ・サーバー・インスタンスを起動して、「一般構成」ページの「追加の構成変数」フィールドで変数を設定すると、コンテンツ・サーバーにより自動的にファイル・ストア・プロバイダがアップグレードされます。 |
ドキュメントが含まれておらず、FileStoreProviderコンポーネントが自動的にアップグレードされているコンテンツ・サーバー・インスタンスでは、次のDefaultFileStore設定を使用します。設定はコードの単一行で、ここに示すように折り返されてはいません。
ボールト・パス:
$#env.VaultDir$$dDocType$/$dDocAccount$/$dispersion$/$dID$$ExtensionSeparator$ $dExtension$
分散ルール:
$dRevClassID[-9:-6:0:b]/$dRevClassID[-6:-3:0:b]
エンコーディングが不要な場合は、次のように指定します。
$dRevClassID[-9:-6:0]/$dRevClassID[-6:-3:0]
Web表示可能パス:
$#env.WeblayoutDir$groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/ $dispersion$/$edisp$/$dDocName$$RenditionSpecifier$$RevisionLabel$ $ExtensionSeparator$$dWebExtension$
Web URLファイル・パス:
$HttpWebRoot$groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/ $dispersion$/$edisp$/$dDocName$$RenditionSpecifier$$RevisionLabel$ $ExtensionSeparator$$dWebExtension$
分散のフィールドは、ストレージ・ルールのパス情報に追加され、編集できます。「Web表示可能パス」フィールドおよび「Web URLファイル・パス」フィールドは、編集できません。分散ルールは、$dispersion$の位置でWebパスに追加されます。
分散ルールにより、URLのbase 64エンコードの部分に:bを指定できます。たとえば、次の分散ルールは、2つの部分をbase 64にエンコードします。
$dRevClassID[-9:-6:0:b]/$dRevClassID[-6:-3:0:b]
ドキュメントが含まれていて、FileStoreProviderコンポーネントのアップグレードがないコンテンツ・サーバー・インスタンスでは、Revisions表が空ではないため、デフォルトのストレージ・ルールの分散がDefaultFileStoreに設定されていないという情報メッセージが返されます。
ファイル・ストア・システムを使用せずに、旧バージョンのコンテンツ・サーバーを使用し、FileStoreProviderコンポーネントをアップグレードして実装しているサイトの場合、またはFileStoreProviderコンポーネントを完全にアンインストールし、ファイル・ストア・プロバイダにより追加されたメタデータ・フィールドも削除したサイトの場合、ユーザーがドキュメントをチェックインしたとき、そのサイトには関連のストレージ・ルールがない(xStorageRuleフィールドがない)ことになります。このような状況の後でファイル・ストア・プロバイダが実装されると、ファイル・ストア・プロバイダの実装前にチェックインされたドキュメントには空のxStorageRuleフィールドが含まれます。この状況を解消するには、ユーザーはそれらのドキュメントのコンテンツ情報を更新する必要があります。ドキュメントはxStorageRuleフィールドのデフォルト値に更新され、ストレージ・ルールで指定されている場所に移されます。xStorageRuleの詳細は、第12.3.2.2項を参照してください。
コンテンツ・サーバーでは、コンテンツの格納および編成用の従来のファイル・システムのかわりに、データ管理用のファイル・ストアが使用されます。FileStoreProviderコンポーネントは、コンテンツ・サーバーのデプロイ時にデフォルトでインストールされ、有効化されます。FileStoreProviderコンポーネントでは、自動的にデフォルトのファイル・ストア(DefaultFileStore)をアップグレードし、Web、ボールトおよびWeb URLパス式の変更など、コンポーネントで公開される機能を利用できるようにします。
|
注意: コンテンツ・サーバーの実行にはパーティションは必要ありませんが、パーティションの作成前にコンテンツをチェックインしようとすると、ボールト・パス・ルートの変更や、新しい適格なストレージ・ルールの作成に失敗します。詳細は、ストレージ・ルールやパスの構成に関する項が含まれている第12.3.1項を参照してください。 |
|
注意: Oracle WebLogic Serverでは、作成されるパーティションごとに、Webレイアウト・ディレクトリを指す新しい仮想ディレクトおよびエイリアスを追加するように、コンテンツ・サーバー・インスタンス用のWebサーバーは構成されません。パーティションは、ボールト・ファイルに使用でき、Webファイル用にサポートされますが、デフォルトのボールトおよびWebレイアウト・ディレクトリ下にパーティション・ルートが存在している必要があります。 |
|
注意: リソース・ファイルは直接編集しないでください。リソース・ファイルの適切な変更は、コンテンツ・サーバー・ユーザー・インタフェース内で行うか、または追加のコンポーネント開発により行う必要があります。コンポーネント開発の詳細は、第9章を参照してください。 |
ファイル・パスの定義および処理には、3つのリソース表が使用されます。PathMetaData表およびPathConstruction表のデフォルト値で、ほとんどのシナリオに対応できます。StorageRules表には、ストレージ・ルールの定義時に指定する値が格納されます。これら3つの表はプロバイダ固有で、そのことはdefaultfilestore/ディレクトリのprovider.hdaファイルで定義されています。defaultfilestore/ディレクトリは、IntradocDir/data/providers/ディレクトリにあります。4番目の表FileSystemFileStoreAlgorithmFilters表の変更には、Javaコードとともにコンポーネントが必要です。
この項の内容は次のとおりです。
コンテンツ・アイテムがコンテンツ・サーバーにチェックインされるとき、アイテムはメタデータ、ユーザーが選択したプライマリ・ファイルと、場合によっては代替ファイルで構成されています。代替ファイルは、ユーザーによって選択され、チェックインされる場合もあり、Web表示可能ファイルとみなされます。コンテンツ・サーバーへのファイル・システムによるアプローチでは、プライマリ・ファイルはDomainHome/ディレクトリのルートにあるvaultディレクトリに格納され、ネイティブ・ファイルと呼ばれます。代替ファイルがチェックインされると、これもvaultに格納されますが、weblayoutディレクトリにコピーされるか、変換アプリケーション(Inbound Refineryなど)に渡されます。代替ファイルがチェックインされない場合は、vaultディレクトリから2箇所に存在するweblayoutディレクトリへネイティブ・ファイルがコピーされます。代替ファイルがチェックインされず、Inbound Refineryがインストールされている場合、ネイティブ・ファイルのレンディションが作成され、Webレイアウト・ディレクトリに格納されます。
コンテンツ・サーバーへのファイル・システムによるアプローチでは、指定したディレクトリにコンテンツを格納することで、コンテンツへのパスが定義されます。コンテンツが特定の場所にあることを知っている場合は、静的Web URLファイル・パスを使用してブラウザからコンテンツにアクセスでき、場所がわからない場合は、GET_FILEなどの動的なコンテンツ・サーバー・サービス・リクエストを使用してアクセスします。ファイル・ストア・プロバイダでは、コンテンツがファイル・システムに格納されることも、されないこともあります。したがって、新しい方法でコンテンツへのパスを定義する必要があります。
ファイル・ストア・プロバイダの設定の仕方によっては、静的Web URLがある場合も、ない場合もあります。具体的な場所がわからない場合は、動的なコンテンツ・サーバー・サービス・リクエストを使用することで、コンテンツにアクセスできます。ファイル・ストア・プロバイダを使用すると、静的Web URLがWeb URLファイルとして定義され、動的アクセスは単にWeb URLと呼ばれます。ファイル・ストア・プロバイダ・ユーザー・インタフェースを使用すると、静的Web URLファイル・パス以外は構成できません。ただし、静的Web URLを、コンテンツ・サーバー・サービス・リクエストとして実行し、本質的に動的にすることを決定できます。
この項の内容は次のとおりです。
コンテンツがチェックインすると、コンテンツ・サーバーによって管理されているコンテンツのすべてのバージョンがレンディションとみなされます。これらのレンディションには、ネイティブ・ファイル、Web表示可能ファイル、およびInbound Refineryやサードパーティの変換アプリケーションによりレンダリングされた可能性のあるその他のファイルが含まれます。
複数のレンディションは1つのストレージ・クラスにまとめられ、これによりレンディションにアクセスする場所と方法が決まります。複数のストレージ・クラスは1つのストレージ・ルールにまとめられ、これにより1つのストレージ・クラスを経由するボールト、WebおよびWeb URLのパス式が定義されます。さらに、ストレージ・ルールにより、レンディションを、Webレス・ファイル・ストアと同様に格納しないかどうか、またはファイル・システムではなくデータベースなどの別のデバイスに格納するかどうかを決めます。
次の例では、ストレージ・ルールで、様々なコンテンツ・アイテムの格納場所や格納方法をどのように指定できるかを説明しています。
例1
ストレージ・ルールは、「ストレージ・ルール名」ダイアログで「ファイル・システムのみ」として定義され、「Web表示非対応のファイル・ストア」は選択されていません。ここでは、システムによりプライマリ・ファイルのコピーが作成され、Webレイアウト・ディレクトリに置かれます。
この従来のファイル・システム・ストレージの例では、通常、データベース・ストレージと比較すると、コンテンツへのアクセス時間が速くなる利点があります。ファイル・システムの階層が複雑だったり、飽和状態になったりした場合、あるいはコンテンツ・アイテムの量が増えるにつれて、この利点は少なくなります。
例2
ストレージ・ルールは、「ストレージ・ルール名」ダイアログで「ファイル・システムのみ」として定義され、「Web表示非対応のファイル・ストア」が選択されます。ここでは、プライマリ・ファイルのコピーは作成されないため、ネイティブ・ファイルはレンディションのみです。Web表示可能ファイルに対するリクエストは、ボールトに格納されているネイティブ・ファイルに送られます。
|
注意: ファイル・ストア・プロバイダのWebレス・オプションにより、Webレンディションが作成されないように指定できます。これをInbound Refineryとともに使用すると、Webレンディションが常に作成され、有効なストレージ・ルールに応じて、ファイル・システムまたはデータベースのいずれかに格納されます。 |
この従来のファイル・システム・ストレージの例では、前の例と同様に、コンテンツへのアクセス時間が速くなる利点があります。また、コンテンツのバージョンをボールト・ディレクトリからWebレイアウト・ディレクトリにコピーしないことで、記憶領域の節約にもなります。かわりに、Web表示可能のアクセスはボールト・ディレクトリのコンテンツにリダイレクトされます。これは、チェックインされた大部分のネイティブ・ファイルがWeb表示可能フォーマットの場合、またはコンテンツ・サーバーがブラウザで表示する必要のないコンテンツの管理に使用されている場合に役立ちます。
例3
ストレージ・ルールは、「ストレージ・ルール名」ダイアログで「JDBCストレージ」として定義され、「レンディション」選択リストからは選択されません。ここでは、ボールト・ファイルとWebファイルの両方がデータベースに格納されます。
このデータベース記憶域の例では、一貫したバックアップおよびプロセス監視のために、リポジトリ管理とデータベース管理を統合するという利点を提供し、ファイル・システムでのディレクトリ構造やディレクトリ当たりのファイル数に関連した制限の克服に役立ちます。
|
重要: 必要な場合、たとえば索引付けや変換の間、データベースに格納されたコンテンツ・アイテムを強制的にファイル・システムに置くことができます。ファイル・システム上のファイルは、一時キャッシュとして扱われ、 |
例4
ストレージ・ルールは、「ストレージ・ルール名」ダイアログで「JDBCストレージ」として定義され、「レンディション」選択リストから「Webファイル」が選択されます。ここでは、ボールト・ファイルはデータベースに格納され、Webファイルはファイル・システムに永久的に格納されます。
ネイティブ・ファイルはデータベースに、Web表示可能ファイルはファイル・システムに格納するというこの混成アプローチには、前例のネイティブ・ファイルのデータベース記憶域(バックアップと監視を統合し、ファイル・システムの制限を克服)という利点があり、一方でWeb表示可能レンディションへの迅速なWebアクセスを実現します。最初の例と同様に、ファイル・システム構造が複雑すぎる場合や、ファイルの量が極端に多い場合には、この利点は少なくなる可能性があります。
コンテンツ・サーバーに格納されているコンテンツへのパスは、PathConstruction表のPathExpression列で定義されています。パスは複数の要素で構成され、各要素はスラッシュ(/)で区切られています。各要素は、1つの静的文字列または一連の動的部分でできています。動的部分は、ドル記号($)で囲まれています。1つの部分は、アルゴリズム、Idoc Script変数、環境変数、またはメタデータ参照を使用して計算でき、次のような解釈が考えられます。
PathMetaData表で定義されたフィールドである可能性があります。PathMetaData表で定義されている場合、次の例のような1つのアルゴリズムにマップできます。
$dDocType$
接頭辞#env.がある場合は、次のような環境変数です。
$#env.VaultDir$ or $#env.WeblayoutDir$
Idocスクリプト変数(たとえば、$HttpWebRoot$)である可能性があります。たとえば、標準的なボールトの場所は、次のように定義されます。
$PartitionRoot$/vault/$dDocType$/$dDocAccount$/$dID$$ExtensionSeparator$ $dExtension$
解析すると、パス式は5つの要素になり、PathMetaData表で指定されているルールに従い、次のように解釈されます。
$PartitionRoot$: partitionSelectionアルゴリズムにマップされ、パーティション・ルートを確認するために、xPartitionIdをPartitionList表への参照として使用します。
/vault/: 文字列であるため、計算や代入はありません。
$dDocType$: PathMetaData表では、これはファイル・パラメータでの参照です。
$dDocAccount$: これは、dDocAccountを取り込み、すべての適切なデリミタを使用して、標準のコンテンツ・サーバー・アカウント表現に解析するdocumentAccountアルゴリズムにマップされます。
$dID$$ExtensionSeparator$$dExtension$: この要素は次の3つの部分から成ります。
$dID$: dDocTypeと同様、ファイル・パラメータで定義される必須のフィールドです。
$ExtensionSeparator$: アルゴリズムによって決まり、デフォルトでは「.」を返します。
$dExtension$: dDocTypeと同様です。
Web表示可能パスの標準的な構成では、URLに、dDocName、レンディション、拡張子情報はもとより、Web表示可能パスへのパーティション・ルート、セキュリティ、dDocType、分散情報も追加する変数が含まれています。デフォルトでは、FsWeblayoutDirは$#env.WeblayoutDir$を意味します。
$FsWeblayoutDir$groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/$dispersion$/~edisp/$dDocName$$RenditionSpecifier$$RevisionLabel$$ExtensionSeparator$$dWebExtension$
Web URLの標準的な構成では、URLに、dDocName、レンディション、拡張子情報はもとより、Web表示可能パスへのパーティション・ルート、セキュリティ、dDocType、分散情報も追加する変数が含まれています。デフォルトでは、FsHttpWebRootは$HttpWebRoot$を意味します。
$FsHttpWebRoot$groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/$dispersion$/~edisp/$dDocName$$RenditionSpecifier$$RevisionLabel$$ExtensionSeparator$$dWebExtension$
groupsセパレータはコンテンツ・サーバーに対して、後続のディレクトリが、コンテンツ・アイテムの属するセキュリティ・グループおよびアカウントの名前であることを示します。アカウントはオプションで、その結果、アルゴリズムによって計算されます。セキュリティ情報の後はdocumentsセパレータで、その直後にはdDocTypeが続きます。分散はオプションです。URLの最後の部分は、dDocName、そのレンディションおよびリビジョン情報、フォーマットの拡張子です。
URLはこのフォーマットになると予想されるため、コンテンツ・サーバーは、ここからメタデータを正常に抽出できます。さらに重要なことは、これによりコンテンツ・アイテムのセキュリティ情報を指定でき、特定のユーザーのアクセス権限を導出できることです。
解析のガイドラインは、Webディレクトリ内の分散を可能にするために拡張されました。$dRevClass$が出現したら、システムでは分散情報を処理してから、従来どおりdDocNameおよびdWebExtensionの処理を続けます。つまり、システムにより次のフォーマットのURLの解析がうまくできるようになりました。
../groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/$dispersion$/~edisp/$dDocName$$RenditionSpecifier$$RevisionLabel$$ExtensionSeparator$$dWebExtension$
FileStoreProviderコンポーネントは、コンテンツ・サーバー・データベース、コンテンツ・サーバー・メタデータ・フィールドおよびその他の構成ファイルに対して、いくつかの変更を加え、考えられる構成オプションを可能にします。
この項の内容は次のとおりです。
場合によっては、データベースに格納されたコンテンツを、ファイル・システム上に強制的に置くことが必要になります。その1例が、Oracle WebCenter Content: Inbound Refineryで、変換のためにファイルへのアクセス権が必要な場合です。ファイル・システム上に強制的に置かれたファイルは、一時キャッシュとみなされます。次の構成値は、一時的にキャッシュされたファイルをクリーンアップする時期を制御するために使用されます。システムでクリーンアップされるのは、FileCache表にエントリのあるファイルのみです。
| 変数 | 説明 |
|---|---|
|
FsCacheThreshold |
最大キャッシュ・サイズをMBで指定します。デフォルトは |
|
FsCleanUpCacheDuringIndexing |
索引付けのサイクル中にキャッシュを削除するかどうかを指定します。デフォルトは、 |
|
FsCleanUpCacheIndexingMax |
各索引付けサイクルで削除するキャッシュ・ファイルの数を指定し、そのサイクルでのロードを制限します。デフォルトでは、索引付けサイクルのすべての対象キャッシュ・ファイルを削除します。 |
|
FsMaximumFileCacheAge |
ファイルがキャッシュされるまでの最大保持期間を日数で指定します。デフォルトは |
|
FsMinimumFileCacheAge |
キャッシュされたファイルを削除できる最低保有期間を日数で指定します。デフォルトは |
ファイル・ストア・プロバイダによりいくつかのコンテンツ・サーバー・メタデータ・フィールドが追加され、構成ファイルで使用する追加のオプションが利用できるようになります。
ファイル・ストア・プロバイダにより、コンテンツ・サーバー・インスタンスに次の3つのメタデータ・フィールドが追加されます。
xPartitionId: このメタデータ・フィールドは、PartitionList表とともに使用され、コンテンツ・ファイル・アイテムのrootの位置を決定します。パーティション選択アルゴリズムで値が指定されるため、このフィールドはユーザー・インタフェースで非表示にすることをお薦めします。
xWebFlag: このメタデータ・フィールドでは、コンテンツ・アイテムにWeb表示可能ファイルがあるかどうかを判断します。したがって、システムのコンテンツ・アイテムにボールト・ファイルしかない場合、このメタデータ・フィールドを削除すると、システムではWeb表示可能ファイルがあるものと予想し、システムに悪影響が生じる可能性があります。メタデータ・フィールドは、構成値WebFlagColumnによって指定できます。
xStorageRule: このメタデータ・フィールドでは、ファイルをどのように格納するかを指定します。メタデータ・フィールドは、構成値StorageRuleFieldで指定できます。
|
注意: これらのメタデータ・フィールドは、起動時にファイル・ストア・プロバイダによって追加され、削除されている場合は、コンテンツ・サーバー・インスタンスが再起動したときに再び追加されます。メタデータ・フィールドを永久に削除する必要がある場合、 |
StorageDirパラメータは、PartitionRoot列値が指定されていないすべてのパーティションに使用されるルート・ディレクトリと同等のものとして設定できます。この場合、ストレージ・ディレクトリおよびパーティション名がPartitionRootパラメータの作成に使用されます。StorageDirパラメータは、DomainHome/ucm/cs/bin/ディレクトリにあるintradoc.cfgファイルで設定されます。
IntradocDir/data/providers/defaultfilestore/ディレクトリにあるprovider.hdaファイルでは、次のパラメータおよびクラスがファイル・システム・ストアの標準です。
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
この項の内容は次のとおりです。
PartitionList表では、partitionSelectionアルゴリズムに使用可能なパーティションが定義されています。表は、DomainHome/ucm/cs/data/filestore/config/ディレクトリにあるfsconfig.hdaファイルで定義されており、コンテンツ・サーバー・インタフェースの「パーティションの追加」または「パーティションの編集」ページを使用して変更されます。表の列は、次のように使用されます。
| 列 | 説明 |
|---|---|
|
PartitionName |
パーティションの名前を指定します。この名前は、パス式内で参照されます。 |
|
PartitionRoot |
partitionSelectionアルゴリズムに渡された引数。 |
|
IsActive |
パーティションが現在アクティブで、新規ファイルを受け入れるかどうかを確認します。 |
|
CapacityCheckInterval |
使用可能なディスク領域の確認に使用される間隔を秒単位で指定します。これは、すべてのプラットフォームで機能するわけではありません。 |
|
SlackBytes |
パーティションにコンテンツを格納するのに十分な領域があるかどうかを確認します。使用可能な領域が遊びバイトより少ない場合、パーティションは非アクティブになり、コントリビューションには使用されなくなります。 |
|
DuplicationMethods |
Web表示可能レンディションに変換されないネイティブ・ファイルをどのように扱うかを指定します。 コピー(デフォルト): ネイティブ・ファイルをWebパスにコピーします。 リンク: Webパスをボールトのネイティブ・ファイルに解決します。 コピーおよびリンクは、コンテンツ・サーバー・インスタンスがインストールされているオペレーティング・システムの機能に依存します。したがって、すべてのプラットフォームですべてのメソッドが使用可能というわけではありません。 |
StorageRules表では、コンテンツ・アイテムの格納に使用されるルールを定義します。ルールは、どのストレージ・クラスにどのパス式を使用するか、およびコンテンツ・アイテムをどのように格納するかを指定します。
表は、DomainHome/ucm/cs/data/providers/defaultfilestore/ディレクトリにあるprovider.hdaファイルで定義されており、コンテンツ・サーバー・インタフェースの「ストレージ・ルール名」ダイアログを使用して変更できます。表の列は、次のように使用されます。
| 列 | 説明 |
|---|---|
|
StorageRule |
ストレージ・ルールの名前。動的インクルードから計算され、コンテンツ・アイテムの |
|
StorageType |
ストレージの実装を指定します。 FileStorage: ファイルは、ファイル・システムに格納されます。 JdbcStorage: ファイルはデータベースに格納されます。 |
|
IsWeblessStore |
システムでWebレス・ファイルを使用できるかどうかの指定に使用されます。 true: デフォルトでは、新規作成されたコンテンツ・アイテムにWeb表示可能ファイルはありません。ある特定の状況では、Web表示可能ファイルにこだわる必要があります。そのような場合、呼出しコードの引数を使用して、Web表示可能ファイルを作成する必要があることを指定できます。Web表示可能ファイルがあるかどうかに関する情報は、 false: デフォルトでは、新規作成されたコンテンツ・アイテムにWeb表示可能ファイルがあります。 |
|
RenditionsOnFileSystem |
JdbcStorageにより、ファイルがデータベースのかわりにファイル・システムに格納されるかどうかを指定するために使用されます。 |
PathMetaData表では、ファイルの場所を決定するためにどのメタデータが使用されるかを定義します。メタデータは、コンテンツ・アイテムのメタデータから直接得たものか、またはアルゴリズムを使用して計算されます。PathMetaData表は、defaultfilestore/ディレクトリのprovider.hdaファイルで定義されています。defaultfilestore/ディレクトリは、DomainHome/ucm/cs/data/providers/ディレクトリにあります。
表の列は、次の表に示すように使用されます。
| 列 | 説明 |
|---|---|
|
FieldName |
パス式に表示されるフィールドの名前。 |
|
GenerationAlgorithm |
フィールドの値を解決または計算するために使用されるアルゴリズムを指定します。 |
|
RequiredForStorage |
どのストレージ・クラスにメタデータが必要なのかを定義します。 #all: ボールトおよびWeb表示可能の両レンディションで、メタデータが必要です。 web: Web表示可能レンディションにのみメタデータが必要です。 vault: ネイティブ・ファイル・レンディションにのみメタデータが必要です。 指定されていないすべてのレンディションでは、このフィールドはオプションです。したがって、この列が空の場合、すべてのレンディションまたはストレージ・クラスで、メタデータ・フィールドはオプションになります。アルゴリズムが指定されている場合、この値は空です。アルゴリズムでは、必要なフィールドを指定するために、ArgumentFields列で指定されている値を使用します。 |
|
Arguments |
GenerationAlgorithmフィールドで指定されているアルゴリズムに渡されるオプションの引数。 |
|
ArgumentFields |
Arguments列で定義されている引数で必要とされ、その結果GenerationAlgorithmフィールドで指定されているアルゴリズムでも必要となるフィールドのカンマ区切りのリスト。 |
PathConstruction表では、ファイルをパスにマップします。PathConstruction表は、defaultfilestore/ディレクトリのprovider.hdaファイルで定義されています。defaultfilestore/ディレクトリは、DomainHome/ucm/cs/data/providers/ディレクトリにあります。詳細は、第12.3.1.2項を参照してください。
|
注意: PathConstruction表で提供されているデフォルト値は、想定されるたいていの事態に機能します。このリソース・ファイルは直接編集しないでください。追加のコンポーネント開発により、適切な変更を行う必要があります。コンポーネント開発の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentでの開発』のコンポーネントに関する章を参照してください。 |
PathConstruction表の列は、次の表で定義されます。
| 列 | 説明 |
|---|---|
|
FileStore |
計算されるストレージ・パスを指定します。 web: Web表示可能ファイルへのパス。 vault: ネイティブ・ファイルへのパス。 weburl: コンテンツ・サーバーによって生成されます。GET_FILEになる傾向があります。 weburl.file: ブラウザでWeb表示可能レンディションにアクセスするために使用する正しい構成のURL。 dispersion: ファイル・システム上のコンテンツの分散用の変数。 FsWeblayoutDir: Webレイアウト・ディレクトリのWeb表示可能パス用の変数。 FsHttpWebRoot: Webレイアウト・ディレクトリのWeb URLファイル・パス用の変数。 |
|
PathExpression |
パスを定義します。 |
|
AutoCreateLimit |
作成される可能性のあるディレクトリの深さを指定します。 |
|
StorageRule |
このパス構成が属するストレージ・ルールを指定します。 |
FileSystemFileStoreAlgorithmFilters表は、FilterImplementorインタフェースの実装にアルゴリズム名をマップするために使用されます。アルゴリズムは、PathMetaData表で参照でき、希望するパス・フィールドの計算に使用されます。そのアルゴリズムを実装するクラスは、ファイル・パラメータ・オブジェクトがNULLの場合、計算に使用する必須のメタデータ・フィールドを返す必要があります。ExecutionContextにより、doFilterメソッドが、フィールド、コンテンツ・アイテムおよび呼出しを開始したファイル・ストア・プロバイダに関する情報に渡されます。具体的には、ファイル・システム・プロバイダの場合、アルゴリズムにはExecutionContextにより次の情報が渡されます。その他のファイル・ストア・プロバイダが、もっと多くの、または場合によっては異なる情報を渡す選択をする可能性があることを念頭に置いてください。
Properties fieldProperties = (Properties)
context.getCachedObject("FieldProperties");
Parameters data = (Parameters)
context.getCachedObject("FileParameters");
Map localData = (Map) context.getCachedObject("LocalProperties");
String algorithm = (String) context.getCachedObject("AlgorithmName");
FileSystemFileStoreAlgorithmFilters表は、ファイル・ストア・プロバイダの一部で、変更するJavaコードとともにコンポーネントが必要です。
|
注意: FileSystemFileStoreAlgorithmFilters表で提供されているデフォルト値は、想定されるたいていの事態に機能します。このリソース・ファイルは直接編集しないでください。Javaコードと追加のコンポーネント開発により、適切な変更を行う必要があります。コンポーネント開発の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentでの開発』を参照してください。 |
ファイル・ストア・プロバイダがインストールされると、FileStorage表がコンテンツ・サーバーに追加されます。これは、コンテンツがデータベースに格納される場合に、JdbcStorageストレージ・タイプによって排他的に使用されます。FileStorage表には、コンテンツ・アイテムのレンディションが含まれていて、どのレンディションがどのコンテンツ・アイテムに属しているかを一意に識別するために、コンテンツ・アイテムおよびレンディションのdIDが使用されます。
ファイル・ストア・プロバイダがインストールされると、FileCache表がコンテンツ・サーバーに追加されます。これは、どのレンディションがファイル・システム上に置かれているかを記憶するために、JdbcStorageストレージ・タイプによって排他的に使用されます。データベースに格納されているレンディションは、索引付けや変換など、特定のイベントに必要な場合、ファイル・システムに置かれます。これらのファイルは一時的であることが多く、スケジュールされたイベントの一部として、指定した間隔の後に削除されます。
ファイル・ストア・プロバイダのデフォルト・ファイル・ストアがアップグレードされると、チェックインされたコンテンツおよび関連のメタデータが検査され、システム管理者によって設定された基準に基づきストレージ・ルールが割り当てられます。基準としてはメタデータ、プロファイルまたはその他の考慮事項が含まれます。ストレージ・ルールは、ボールト・ファイルおよびWebファイルをコンテンツ・サーバーで格納およびアクセスする方法、およびWebサーバーによりアクセスする方法を決定します。ファイルは、データベースに格納することも、1つ以上のファイル・システムまたは記憶媒体に格納することもできます。パーティションは、格納場所の管理に役立てるために作成できますが、必須ではありません。
|
注意: FileStoreProviderコンポーネントは、いったんコンテンツ・サーバーで使用されると、無効にすることはできません。 |
この項の項目は次のとおりです。
パーティションを作成すると、コンテンツ・サーバーにより管理されるファイルへの追加のルート・パスを定義できますが、異なる場所や、異なるタイプの媒体への格納が必要です。パーティションは、パーティション・リスト・ページを使用して作成します。新規パーティションが作成されると、コンテンツ・サーバーにより、IntradocDir/data/filestore/config/ディレクトリにあるfsconfig.hdaファイルでPartitionListリソース表が変更されます。
|
注意: Oracle WebLogic Serverでは、作成されるパーティションごとに、Webレイアウト・ディレクトリを指す新しい仮想ディレクトおよびエイリアスを追加するように、コンテンツ・サーバー・インスタンス用のWebサーバーは構成されません。パーティションは、ボールト・ファイルに使用でき、Webファイル用にサポートされます。 |
コンテンツ・サーバー・インスタンスにパーティションを追加するには:
コンテンツ・サーバー・インスタンスにシステム管理者としてログインします。
「管理」→「ファイル・ストアの管理」を選択します。
パーティションが定義されていない場合、「パーティションの追加」をクリックします。それ以外の場合は、「パーティションの追加/編集」ページが開きます。
パーティション名を入力します。名前を一意にする必要があります。
パーティション・ルート、重複メソッドおよびその他の関連パラメータを変更します。
「アクティブ」が有効であることを確認します。
「更新」をクリックします。
ファイル・ストア・プロバイダはいつでも編集できます。プロバイダを編集するには:
コンテンツ・サーバー・インスタンスにシステム管理者としてログインします。
「管理」→「プロバイダ」を選択します。
「プロバイダ」ページで、DefaultFileStoreプロバイダの隣にある「アクション」列の「情報」をクリックします。
「ファイル・ストア・プロバイダ情報」ページで、「編集」をクリックします。
「ファイル・ストア・プロバイダの編集」ページで、必要な変更を加え、「更新」をクリックして、変更を送信します。
|
注意: 「更新」をクリックして変更を送信する前に、「ファイル・ストア・プロバイダの編集」ページから離れないでください。 |
コンテンツ・サーバー・インスタンスを再起動します。
複数のストレージ・ルールをファイル・ストアに追加できます。
|
重要: ストレージ・ルールは削除できません。各ストレージ・ルールについては、作成する前に慎重に検討してください。 |
|
注意: コンテンツがコンテンツ・サーバー・リポジトリにチェックインされた後でストレージ・ルールを変更すると、コンテンツ・サーバーでコンテンツを見失うことになる可能性があります。 |
ストレージ・ルールを追加または編集するには、次のようにします。
コンテンツ・サーバー・インスタンスにシステム管理者としてログインします。
「管理」→「プロバイダ」を選択します。
「プロバイダ」ページで、DefaultFileStoreプロバイダの隣にある「アクション」列の「情報」をクリックします。
「ファイル・ストア・プロバイダ情報」ページで、「編集」をクリックします。
「ファイル・ストア・プロバイダの編集」ページで、「新規ルールの追加」をクリックするか、ストレージ選択リストから編集するルール名を選択し、「ルールの編集」をクリックします。
「ストレージ・ルール名」ダイアログで、ストレージ・ルールに必要な変更を加え、「OK」をクリックします。
|
注意: 編集中のストレージ・ルールに関連付けられたレコードがある場合、 |
「ファイル・ストア・プロバイダの編集」ページで、「更新」をクリックします。
|
重要: 記憶域ルール内に定義されているWeb URLファイル・パスで使用されているWebルートが、コンテンツ・サーバーに定義されているデフォルトのweblayoutディレクトリ以外にある場合は、記憶域ルール内に使用されているWebルートのWebサーバーに別名または仮想ディレクトリを追加する必要があります。そうしない場合、コンテンツ・サーバーによりファイルへのアクセス場所が認識されません。仮想ディレクトリをWebサーバーに追加する手順の詳細は、Webサーバーに付属のドキュメントを参照してください。 |
この項では、例ごとに、プロバイダ定義ファイル(provider.hda)に含まれている表のコンテンツを示します。provider.hdaファイルは、手動で編集する必要がありません。provider.hdaファイルの適切な変更は、「パーティションの追加」または「パーティションの編集」ページを使用してコンテンツ・サーバー・インタフェース内で行うか、または追加のコンポーネント開発により行う必要があります。その他のリソース表(PathMetaData表、PathConstruction表およびFileSystemFileStoreAlgorithmFilters表など)に提供されているデフォルト・オプションで、想定されるたいての事態に十分柔軟に対応できます。
この項の項目は次のとおりです。
大部分の例では、次のPathMetaData表の構成定義が使用されます。表では、理解しやすいように、例に該当しない一部の列は省略されいます。
@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
ファイル・ストア・プロバイダは、標準的なコンテンツ・サーバーの場所にあるファイル・システムに、コンテンツを格納するように構成できます。
まず最初にストレージ・ルールを定義します。この例では、すべてのコンテンツがファイル・システムに格納されるので、ストレージ・ルールはFileStorageタイプのものになります。
例:
@ResultSet StorageRules 4 StorageRule StorageType IsWeblessStore RenditionsOnFileSystem default FileStorage @end@
次に、ルールのストレージ・クラスごとに、パス構成を定義します。一般に、パスの最後の部分は、すべての使用例にとって標準的なものにする必要があります。そうでないと、コンテンツ・サーバーで正しくhcs*ファイルを使用できません。ただし、Web URLファイル・パス・ルートの変更が、Webサーバーでコンテンツ・サーバーWebルートとして正しく認識されると仮定すれば、ルート・パスは機能に影響を与えることなく変更できます。
この構成では、ボールト、WebおよびWeb URLストレージ・クラスは、PathConstruction表で定義する必要があります。ボールトのパス式は、すでに第12.3.1.2項で述べています。$dispersion$により、ファイル・システム上のコンテンツの分散が実装されます。呼出し側は、ストレージ・ルール・ページでこの分散を指定できます。
この設定では、Webパス式のみを見ていますが、Web URLと異なるのはルートのみです。すなわち、Webパスがファイル・システム上の絶対パスであるのに対して、Web URLはWebサーバーのサービスを受けるURLです。
例:
@ResultSet PathConstruction
4
FileStore
PathExpression
AutoCreateLimit
IsWritable
StorageRule
vault
$#env.VaultDir$$dDocType$/$dDocAccount$/$dispersion$/$dID$$ExtensionSeparator$
$dExtension$
6
true
default
weburl
$FsHttpWebRoot$groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/
$dispersion$/~edisp/$dDocName$$RenditionSpecifier$$RevisionLabel$
$ExtensionSeparator$$dWebExtension$
3
false
default
web
$FsWeblayoutDir$groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/
$dispersion$/~edisp/$dDocName$$RenditionSpecifier$$RevisionLabel$
$ExtensionSeparator$$dWebExtension$
3
true
default
@end
Webパス構成は、次のように定義されます。
$FsWeblayoutDir$groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/ $dispersion$/~edisp/$dDocName$$RenditionSpecifier$$RevisionLabel$ $ExtensionSeparator$$dWebExtension$
これは、次の表に示すようにパーツに解析されます。
| パス・セグメント | 説明 |
|---|---|
|
$FsWeblayoutDir$ |
Webレイアウト・ディレクトリのWeb表示可能パスの変数。 |
|
$FsHttpWebRoot$ |
Web URLの代替Idoc Script変数。 |
|
/groups/ |
文字列。 |
|
$dSecurityGroup$ |
PathMetaData表により使用されます。これは必須フィールドであり、そのため呼出し側または記述子の作成者により指定される必要があります。これは、コンテンツ・アイテムのメタデータ情報の一部です。 |
|
$dDocAccount$ |
これは、dDocAccountを取り込み、すべての適切なデリミタを使用して、標準のコンテンツ・サーバー・アカウント表現に解析するdocumentAccountアルゴリズムにマップされます。 |
|
/documents/ |
文字列。 |
|
$dDocType$ |
PathMetaData表により使用されます。これは必須フィールドであり、そのため呼出し側または記述子の作成者により指定される必要があります。これは、コンテンツ・アイテムのメタデータ情報の一部です。 |
|
$dispersion$ |
ファイル・システム上のコンテンツの分散を実装します。 |
|
!edisp |
このマーカーが指定された箇所で分散が終了したことを示します。たとえ分散が空であっても、~edispマーカーが指定されます。 |
|
$dDocName$ |
PathMetaData表により使用されます。これは必須フィールドであり、そのため呼出し側または記述子の作成者により指定される必要があります。これは、コンテンツ・アイテムのメタデータ情報の一部です。 |
|
$RenditionSpecifier$ |
これは、renditionSpecifierによって指定され、システムでサムネールなどの追加のレンディションを作成中の場合のみ必要です。それ以外の場合は、空の文字列を返します。 |
|
$RevisionLabel$ |
リビジョン・ラベルは、revisionLabelアルゴリズムによって指定され、コンテンツ・アイテムのステータスに応じて、パスに「~dRevLabel」が追加されます。 |
|
$ExtensionSeparator$ |
ここではextensionSeparatorアルゴリズムが使用され、デフォルトでは「.」を返します。 |
|
$dWebExtension$ |
dWebExtensionは、WebおよびWeb URLストレージ・クラスの必須フィールドで、ファイル・パラメータにより渡されます。 |
この例では、前の例のストレージ・ルールが、IsWeblessStoreをtrueに設定し、その結果、Web表示可能ファイルがデフォルトで作成されないように構成されます。ただし、ドキュメントが、Web表示可能ファイルを必要とするInbound RefineryやWebForms、またはその他のコンポーネントで処理される場合は、Webファイルが作成されます。ファイルの場所は、前述の標準構成どおりです。しかし、ファイルにはWebレンディションのない場合があるため、Web URLパスを調整する必要があります。また、weburl.fileの使用にも注意してください。これは、Web表示可能ファイルが実際に存在する場合に、そのURLを計算するために使用されます。ブラウザでそのファイルがどのように提供されるかを決定するために、メタデータ・フィールドxWebFlagが使用されます。
@ResultSet StorageRules 4 StorageRule StorageType IsWeblessStore RenditionsOnFileSystem default FileStorage true @end@
@ResultSet PathConstruction
4
FileStore
PathExpression
AutoCreateLimit
IsWritable
vault
$#env.VaultDir$$dDocType$/$dDocAccount$/$dispersion$/$dID$$ExtensionSeparator$
$dExtension$
6
true
default
weburl
$HttpCgiPath$?IdcService=GET_FILE&dID=$dRevClassID$
&dDocName=$dDocName$&allowInterrupt=1&noSaveAs=1&fileName=$dOriginalName$
3
false
default
weburl.file
$FsHttpWebRoot$groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/
$dispersion$/~edisp/$dDocName$$RenditionSpecifier$$RevisionLabel$
$ExtensionSeparator$$dWebExtension$
3
false
default
web
$FsWeblayoutDir$groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/
$dispersion$/~edisp/$dDocName$$RenditionSpecifier$$RevisionLabel$
$ExtensionSeparator$$dWebExtension$
3
true
default
@end
データベースにファイルを格納するには、JdbcStorageタイプのストレージ・ルールが必要です。デフォルトでは、このルールに属するすべてのコンテンツ・アイテムは、ファイルがデータベースに格納されています。しかし、たとえファイルがデータベースに格納されていても、ファイル・システムが基礎となることが考えられ、システムではファイルを一時的にファイル・システムにキャッシュすることが必要になる場合があります。特に、索引付けや一部の変換でこれが発生する可能性があります。
|
技術的ヒント: 指定したストレージ・クラスに属するレンディションが、常にファイル・システム上に格納されるように、ルールを構成できます。これは、ボールト・ファイルをデータベースに格納する一方、Webファイルはファイル・システムに格納するシステムの場合、非常に便利です。 |
前述の例では、ファイル・パスを標準構成に合せています。非常に大きな実装の場合、これではディレクトリが飽和状態になり、パフォーマンスが低下する可能性があります。次の例は、複数の選択肢がある記憶域でファイルを分散させる際に役立ちます。
ファイル・ストア・プロバイダでは、よりすっきりしたディレクトリ構造を作成するために、パーティションを使用しやすくなります。デフォルトでは、xPartitionIdメタデータが使用され、コンテンツ・アイテム・リビジョンのメタデータ情報の一部になります。このフィールドをコンテンツ・サーバー・インタフェースで無効にし、かわりにパーティション選択アルゴリズムで使用するパーティションを決定することをお薦めします。パーティション選択アルゴリズムでは、すべてのアクティブ・パーティションを調べ、新規のコンテンツがシステムに入ってくると、それらのパーティションが順番に選択されます。各パーティションは、PartitionList表にエントリがあり、アクティブであることを宣言できます。PartitionRootは、xPartitionIdから計算され、ここで値はPartitionList表への参照キーとなります。xPartitionIdが指定されていない場合、システムでは、次の使用可能でアクティブなパーティションを見つけ、この値を場所の計算に使用します。xPartitionIdは、その後コンテンツ・アイテムのメタデータの一部として格納されます。
パーティション選択を使用するには、PathConstruction表で次のようにボールト・ストレージ・クラスを定義します。
vault $PartitionRoot$/$dDocType$/$dDocAccount$/$dRevClassID$$ExtensionSeparator$$dExtension$ 6 true
システム管理者があるパーティションをコントリビューションに対して閉じる必要がある場合(たとえば、ストレージ・デバイスでメンテナンスが必要な場合など)、パーティションの追加/編集ページを使用して、パーティションをいつでも非アクティブ化できます。
この例では、ボールトおよびWebレイアウトの両ディレクトリをパーティション化し、有効なWeb URLファイル・パスも保持する方法を説明します。
Web表示可能パスおよびWeb URLファイル・パスにパーティション・ルートを追加し、変数$FsWeblayoutDir$および$FsHttpWebRoot$を「ストレージ・ルール名」ダイアログで編集します。
$FsWeblayoutDir$は$PartitionRoot$/weblayoutを表します。$FsHttpWebRoot$は$HttpWebRoot$/$xPartitionId$/weblayout/を表します。
partitionRootをパーティションの追加/編集ページで次のように定義します。
| パーティション名 | パーティション・ルート |
|---|---|
|
|
|
|
|
|
Web URLファイル・パスをWebレイアウト・ディレクトリ内のWeb表示可能パスと一致させるために、変数xPartitionIdが使用され、Web URLファイル・パスの作成時に、partition1またはpartition2が正しく置換されます。
Web表示可能パスおよびWeb URLファイル・パスが、同じパスに評価されることを確認してください。
$FsWeblayoutDir$は、$PartitionRoot$/weblayout/を表します。partition1の場合、$#env.WeblayoutDir$/partition1/weblayout/に評価されます。partition2の場合、$#env.WeblayoutDir$/partition2/weblayout/に評価されます。
$FsHttpWebRoot$は、$HttpWebRoot$/$xPartitionId$/weblayout/を表します。partition1の場合、$HttpWebRoot$/partition1/weblayout/に評価されます。partition2の場合、$HttpWebRoot$/partition2/weblayout/に評価されます。
$#env.VaultDir$/partition1および$#env.VaultDir$/partition2のパーティション・ルートを$#env.WeblayoutDir$および$HttpWebRoot$設定のかわりに使用するように、パーティション(partition1およびpartition2)を設定する場合、Webレイアウト・ファイルがボールト・ディレクトリに格納されることになります。これにより、ボールト・ファイルのパーティション化にのみ使用できます。
ファイル分散のもう1つの方法は、パスを変更して、コンテンツ・アイテムのdRevClassIDによってファイルを分割することです。次の例では、ディレクトリは、最大10,000ファイル、プラス追加レンディション用の追加ファイルに制限されます。
パス式に$RevClassID[-12:-10:0]/$dRevClassID[-10:-8:0]$/$dRevClassID[-8:-4:0]$が含まれていて、$dRevClassIDが1234567890の場合、結果は00/12/3456です。
パス式内の$dRevClassID[-12:-10:0]に注意してください。これは、次のように解釈されます。
文字列の末尾から12文字戻ったところから始まる文字を、文字列の末尾から10文字戻った文字まで取得します。
結果の文字列を長さ2 (12-10)まで0の文字を埋め込みます。
この項では、Sun Storage Archive Manager (SAM-QFS)製品を紹介し、SAM-QFSを使用するようにコンテンツ・サーバーを構成する方法について説明します。
Sun Storage Archive Manager (SAM-QFS)は、Oracle Solarisオペレーティング・システムで実行される階層型ファイル・ストレージ・システムです。WORM (Write Once Read Many)オプションを指定して構成すると、ファイル・システム・データのアーカイブがサポートされ、ユーザーにはデータの読取りのみが許可されるようになります。SAM-QFS環境には、ストレージおよびアーカイブ・マネージャに加え、Sun QFSファイル・システム・ソフトウェアが含まれます。SAM-QFSは、コンテンツ・サーバー・マシンによるNFSマウントおよび追加のコンテンツ・サーバー構成で使用できます。
SAM-QFSは、次の2つの製品で構成されます。
Quick File System (QFS)は、カーネル・レベルのファイル・システムで、Oracle SolarisおよびSPARCプラットフォームにインストールできます。この製品ではWORM機能および保存マネージャ機能が提供され、コンテンツ・サーバーでこれらを使用できます。
|
注意: WORMを使用してWebレイアウトを保存することはできません。 |
Storage Archive Manager (SAM)には、最初にQFSにファイリングされたファイルをアーカイブしたり、オンデマンドでファイルを取得したり、領域を解放してアーカイブを管理するためにユーザー領域で実行されるいくつかのプログラムが含まれます。
アーカイバ・プログラムには、ファイルが変更される際に前もって通知されるため、ファイル・システムのポーリングによってではなく、イベント駆動型の方法でファイルがアーカイブされます。必要に応じて、アーカイブの管理やバックアップ・コピーの作成も行われます。
リリーサ・プログラムは、アーカイバによってすべてのコピーが作成されたことを確認した後、プライマリ・ストレージからコンテンツを解放します。
ステージャ・プログラムは、データを(アーカイブ・ディスクまたはアーカイブ・テープ上にある)アーカイブ・コピーからプライマリ・ストレージにロードまたはステージングして、QFSからユーザーがデータを取得できるようにします。このアクティビティは、要求時またはポリシーに従って実行されるように構成できます。
リサイクラ・プログラムは、削除されたファイルをセカンダリ・ストレージからパージして、領域を解放して再使用できるようにします。
ファイルはTARユーティリティ・フォーマットで格納されるため、ファイル・システム・メタデータも実際のファイルとともに保持されます。効率化のため、同じTARに複数のファイルを格納できます。
SAM-QFSを実装する前に、次の点を考慮してください。
SAM-QFSにより、WORM (Write Once Read Many)機能とともに、WORM制約が解除された後の保存期間を指定する機能が提供されます。
ファイルは自動的にテープにアーカイブできます。SAM-QFSでは、透過的なリストアを含む、統合されたシームレスなバックアップ・ソリューションが提供されます。
アーカイブされたファイルのリサイクルがSAM-QFSでスケジュールされた場合、ドキュメントのリビジョンは、メタデータ・バックアップのスナップショットを保持し、必要に応じてそれらをマウントすることにより取得できます。
コンテンツ・アイテムは削除できません。削除操作は失敗し、エラー・メッセージが生成されます。
ワークフロー・ステップでユーザーが現在のリビジョンを編集(置換)できるオプションが使用されている場合、そのステップでは、WORMが有効なストレージ・ルールを使用してチェックインされたコンテンツを編集できなくなります。ワークフロー・ステップでこのオプションが使用されている場合、ファイルのボールト・レンディションが置換されます(読取り専用ファイル・システムではこれは行えません)。
ネイティブ・ファイル・パスは、ストレージ・ルールのボールト・パス・フィールドによって異なります。ネイティブ・ファイル・パスの値にパスの一部としてメタデータ・フィールドが含まれている場合、メタデータ・フィールドは更新できません。これは、更新操作によりファイル・システム・パスが変更されるためです(読取り専用システムでは変更されません)。メタデータ属性を変更しようとすると失敗し、エラー・メッセージが生成されます。ネイティブ・ファイル・パスを後から変更する可能性がある場合、WORMが有効なストレージ・ルールでは、ネイティブ・ファイル・パスにメタデータ・フィールドを含めないように設定することをお薦めします。
Oracle SolarisシステムにSAM-QFSをインストールしてWORMを有効化する方法の詳細は、https://wikis.oracle.com/display/SAMQFS/Homeで、Sun QFSおよびSun Storage Archive Manager (SAM-QFS) wikiを参照してください。SUNWsamfswmパッケージにはSAM-QFS 5.2ダウンロード・バージョンは付属しないため、このパッケージについては、SAM-QFSグループにお問い合せください。
SAM-QFSを使用するには、特定の構成を設定する必要があります。デフォルトのストレージ・ルールでWORMを有効にするには、コンテンツ・サーバー・ファイル・ストア・プロバイダでデフォルト・ルール(DispByContentId)を変更する必要があります。その他のストレージ・ルールも、必要に応じてWORMを有効にするように変更できます。
ボールト・パスを構成するには:
コンテンツ・サーバー・インスタンスで、「管理」→「管理サーバー」→「一般構成」を選択します。
「追加の構成変数」フィールドに、環境変数IsVaultFileSystemWorm=trueを入力します。
DomainHome/ucm/cs/bin/intradoc.cfgファイルを編集して、VaultDirパラメータをSAM-QFSの場所のボールト・ファイル・パスに設定します。
SAM-QFSマウント・ポイントから開始し、chmod -R 4000 directoryNameをvault/~tempディレクトリのサブディレクトリexceptに適用します。vault/~tempディレクトリではWORMを有効にしないでください。
最上位のレベルから下に向かって操作を行います。WORMトリガーは、親ディレクトリでWORMトリガーが有効になっている場合にのみ適用できます。
Solaris /etc/vfstabファイルを編集して、デフォルトの保存期間を指定します。
ボールト・ファイルでWORMが有効になるようにファイル・ストア・プロバイダを構成するには:
コンテンツ・サーバー・インスタンスで、「管理」→「プロバイダ」を選択します。
プロバイダ・リストのDefaultFileStore行から、「アクション」列の「情報」をクリックします。
「ファイル・ストア・プロバイダ情報」ページで、「編集」をクリックします。
「ファイル・ストア・プロバイダ」ページの「ストレージ・ルール」の行で、「ルールの編集」をクリックします。
「ストレージ・ルール名」ページで、「ファイル・システムのみ」が選択されていることを確認します。
「WORM/保存を許可する(SAM/QFSのみ)」を選択します。
保存期間を設定する必要がある場合は、「ボールト・ファイルのデフォルトの保存期間を設定します。」を選択し、保存する年数と月数を入力します。
SAM-QFSファイル・システムが32ビットであるか、コンテンツ・サーバーが実行されているオペレーティング・システムが32ビットである場合、このオプションの上限は2038になります。より長い保存期間が必要な場合は、このコンテンツ・サーバー・オプションを選択するかわりに、SAM-QFSのmountオプション・パラメータを使用してデフォルトの保存期間を設定してください。
