| Oracle® Fusion Middleware Content Serverシステム管理者ガイド 11g リリース1(11.1.1) B65037-01 |
|
 前 |
 次 |
この章では、Oracle Content Serverのシステム設定を継続的に管理するための概念および作業について説明します。次の項目について説明します。
この項の内容は次のとおりです。
システム・プロパティはシステム全体にわたる設定で、Oracle Content Serverを特定の要件に合うように調整できます。システム・プロパティは、インストール時に設定され、ユーザーおよびコンテンツのメンテナンスのためにより定期的に使用される他の管理ツールとは異なり、通常、ときどきまたは必要に応じて更新されます。
|
重要: システム・プロパティをどの方法で変更したかに関係なく、構成の変更内容を反映するには、Oracle Content Serverインスタンスを再起動する必要があります。 |
システム・プロパティとの情報のやりとりには、いくつかの方法があります。
管理サーバーを使用すれば、単一のOracle Content Serverインスタンスを構成できます。システム・コンポーネントを有効または無効にすることもできます。管理サーバーには、Webブラウザを使用して「管理」リンクを選択すればアクセスできます。
システム・プロパティ・アプリケーションを使用すれば、特定のOracle Content Serverインスタンスを、そのインスタンスがデプロイされているシステムから構成できます。システム・プロパティ・ユーティリティへのアクセスの詳細は、3.4.2項「スタンドアロン・モードでの管理アプリケーションの実行」を参照してください。
大部分のシステム・プロパティ設定は、次の構成ファイルのいずれかにある構成変数に対応しています。
IntradocDir/config/config.cfg
DomainHome/ucm/short-product-id/bin/intradoc.cfg
IntradocDir/search/search.cfg
これらのファイルへの変更は、管理サーバーまたはシステム・プロパティ・アプリケーションを使用して、設定が正しく入力されるようにすることをお薦めします。テキスト・エディタを使用してこれらのファイルを直接編集することもできますが、誤りが生じる可能性があります。構成変数の詳細は、『Oracle Fusion Middleware Idocスクリプト・リファレンス・ガイド』を参照してください。
|
注意: システム・プロパティ・ユーティリティは、Oracle WebLogic ServerインスタンスでOracle Content Serverインスタンス用のスタンドアロン・アプリケーションとして実行されるため、追加の構成が必要です。3.4.2.1項「スタンドアロン・モード用のSystemDatabaseプロバイダの構成」を参照してください。 |
Oracle Content Serverのパフォーマンスを最適化するには、いろいろな方法があります。あるタイプのチューニングでは、核となるOracle Content Serverのパフォーマンスに影響を与えるデフォルトのパラメータやソフトウェア設定に変更が必要になります。システムの最適化やパフォーマンス・チューニングは、多くの場合、システム設定や構成変数の調整、あるいはデータベースや索引などのリソースのチューニングによって行われます。
たとえば、Oracle Content Serverインスタンス内のコンテンツが増えるにつれて、使用可能な領域が不足する可能性があります。この場合、ボールト、Webレイアウトおよび検索索引ディレクトリをもっと領域のある別のドライブに移動すると、不足の問題を軽減できます。これらのディレクトリを移動するには、DomainHome/ucm/cs/bin/intradoc.cfgファイルにエントリを追加する必要があります。
システム・プロパティ・アプリケーションへのアクセスには、システム管理者としてログインする必要はありません。Oracle Content Serverインスタンスがインストールされているローカル・コンピュータにアクセスするのみです。
「システム・プロパティ」: 「オプション」タブまたは管理サーバー: 一般構成ページで、一般的なオプションを設定できます。構成の変更内容を反映するには、Oracle Content Serverインスタンスを再起動する必要があります。
バッチ・ローダー・ユーティリティを使用して、Oracle Content Serverシステムで大量のファイルを同時に更新および挿入することを計画している場合は、バッチ・ロード・ファイルを作成する必要があります。バッチ・ロード・ファイルに含めることのできるオプション・パラメータの2つは、primaryOverrideFormatとalternateOverrideFormatです。ただし、これらのオプションは、IsOverrideFormat構成変数を有効にすると、バッチ・ロード・ファイルのパラメータとしてのみ動作します。この変数は、システム・プロパティ・アプリケーションを使用して設定できます。
「リビジョン」というメタデータ・フィールドには、1、2、3、4、5などのデフォルトのリビジョン番号シーケンスが入っています。この番号は、ドキュメントが改訂されるごとに自動的に増えます。
「リビジョン」のデフォルト値は、そのリビジョンのラベルの定義を変更することでオーバーライドできます。リビジョンのラベルは、メジャーおよびマイナーの2つのリビジョン・シーケンスの部分で構成されます。メジャー・リビジョンのラベル・シーケンスは最初の数字または文字で、その後にマイナー・リビジョンのラベル・シーケンスが続きます。たとえば、1a、1b、1c、2a、2b、2c、3a、3b、3cなどのリビジョン・シーケンスでは、数字1、2、3がメジャー・リビジョン・シーケンスで、a、b、cがマイナー・リビジョン・シーケンスです。
メジャーおよびマイナーのリビジョン・シーケンスは、どちらも数字または文字の範囲として定義されます。メジャー・シーケンスには複数の範囲を定義できるのに対し、マイナー・シーケンスでは1つの範囲のみです。
範囲の定義には次の制限があります。
数字または文字を使用できますが、両方を使用することはできません。たとえば、1-10は有効な範囲ですが、A-10は無効な範囲です。
文字の範囲で定義できるのは1文字のみです。たとえば、A-Zは有効な範囲ですが、AA-ZZは無効な範囲です。
次に示すのは、異なるリビジョン・シーケンスの例と、config.cfgファイルでのメジャーおよびマイナーのリビジョン・エントリの定義方法です。
例1
MajorRevSeq=A-D,1-99
リビジョン・シーケンスは、A、B、C、D、1、2、3、4などです。
例2
MajorRevSeq=1-99
MinorRevSeq=a-c
リビジョン・シーケンスは、1a、1b、1c、2a、2b、2c、3a、3b、3cなどです。
IntradocDir/config/config.cfgファイルでデフォルトのリビジョン・シーケンスを手動で変更するには、次の名前/値のペアを入力します。
MajorRevSeq=range1,range2,range3...
MinorRevSeq=range
range1,range2,range3...およびrangeは、定義された範囲のシーケンスです。
Oracle Content Serverのチャンク化機能は、データを複数のチャンクに分割し、一度に1チャンクずつ転送することにより、大量のデータ転送の失敗を防ぎます。転送に失敗した場合、失敗前にOracle Content Serverインスタンスに転送されたチャンクはすべて保存され、転送は失敗した時点から再開できます。
|
注意: チャンク化機能を使用するクライアント・セッションが、タイムアウトまたはクライアント・ブラウザを閉じることで中断された場合、転送は失敗します。 |
チャンク化機能は、アップロード・アプレットで使用できます。
アップロード・アプレットまたはHTTPプロバイダを有効にします。4.1.2項「一般オプションの構成」を参照してください。
アップロード・アプレットを有効にするには、4.1.2項「一般オプションの構成」を参照してください。
HTTPプロバイダを作成するには、5.8項「追加のOracle Contentセキュリティ接続」を参照してください。
「管理サーバー」: 「一般構成」ページの「追加の構成変数」ボックスで、次の構成設定を設定します。
DisableHttpUploadChunking=false AppletChunkThreshold=size in bytesAppletChunkSize=size in bytes
AppletChunkSize設定は、個々のチャンクのサイズを設定します。AppletChunkThreshold設定は、チャンク化機能を使用する最小ファイル・サイズを設定します。これらの値はどちらもデフォルトでは1Mです。
チャンク化機能をデバッグするには、ChunkedRequestTrace=trueを設定します。
この設定により、チャンク化されたリクエストを管理サーバーの出力ページで表示できます。
変更内容を保存します。
Oracle Content Serverインスタンスを再起動します。
「システム・プロパティ」: 「コンテンツ・セキュリティ」タブまたは「管理サーバー」: コンテンツ・セキュリティのページでは、Oracle Content Serverのコンテンツ・セキュリティ・オプションを設定できます。
構成の変更内容を反映するには、Oracle Content Serverインスタンスを再起動する必要があります。
「システム・プロパティ」: 「インターネット」タブまたは「管理サーバー」: 「インターネットの構成」ページでは、Oracle Content Serverのインターネット・オプションを設定できます。
構成の変更内容を反映するには、Oracle Content Serverインスタンスを再起動する必要があります。
Oracle Content Serverシステムでは、Oracle WebLogic Serverデータ・ソースを使用して、メタデータおよびその他の情報が格納されているシステム・リレーショナル・データベースと通信します。システム・リレーショナル・データベースのデータベース接続情報の管理には、Oracle WebLogic Server管理コンソールを使用する必要があるため、JDBCユーザー名およびパスワード情報は、IntradocDir/config/config.cfgファイルには格納されず、SystemPropertiesユーティリティにでは管理されません。
|
注意: Oracle WebLogic Serverドメインのデータベース接続情報をOracle Content ServerのSystemPropertiesユーティリティを使用して設定する場合、JDBCユーザー名およびパスワードは暗号化されて不特定の場所に格納されます。 |
サポートされているデータベースの詳細は、次のURLのOracle Technology Networkの「Oracle Fusion Middleware Supported System Configurations」ページで、自分の製品のシステム要件およびサポートされるプラットフォームのドキュメントを参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
スタンドアロン・アプリケーションを実行しているOracle Content Serverシステムのデータベース接続の構成の詳細は、3.4.2.1項「スタンドアロン・モード用のSystemDatabaseプロバイダの構成」、3.4.2.2項「スタンドアロン・モード用のJDBCデータベース・ドライバの構成」および3.4.2.3項「スタンドアロン・モード用の外部データベース・プロバイダの構成」を参照してください。
IBM DB2データベース検索用のOracle Content Serverの構成
IBM DB2データベースでは、検索問合せでキーワードCONTAINSがサポートされていません。Oracle Content ServerインスタンスをIBM DB2検索問合せ用に正しく構成するには、フラグSSUseContains=false変数を追加する必要があります。Oracle Content Serverインスタンスを構成するには、次のようにします。
新規のブラウザ・ウィンドウを開き、システム管理者としてOracle Content Serverインスタンスにログインします。
ナビゲーション・ツリーで、「管理」→「管理サーバー」を選択します。
Oracle Content Serverインスタンスのオプション・リストで、「一般構成」を選択します。
「一般構成」ページが表示されます。
「追加の構成変数」領域に次の行を追加します。
SSUseContains=false
「保存」をクリックします。
Oracle Content Serverインスタンスを再起動します。
「システム・プロパティ」: 「サーバー」タブでは、Oracle Content Serverのオプションを設定できます。セキュリティ上の理由から、管理サーバーはこれらのオプションの構成に使用できません。Oracle Content Serverのオプションを構成するには、スタンドアロン・アプリケーションを使用する必要があります。スタンドアロン・アプリケーション使用の詳細は、3.4.2項「スタンドアロン・モードでの管理アプリケーションの実行」を参照してください。
一部のOracle Content Server構成オプションは、Oracle Enterprise Manager Fusion Middleware Controlを使用して設定します。詳細は、第2章「Oracle Universal Content Managementを管理するためのFusion Middleware Controlの使用」を参照してください。
構成の変更内容を反映するには、Oracle Content Serverインスタンスを再起動する必要があります。
|
注意: ホスト名フィルタ、IPアドレス・フィルタまたはその他のネットワークベースのセキュリティを使用しないと、Oracle Content Serverインスタンスにセキュリティ・ホールが生じます。たとえば、システムについての深い知識を持つユーザーならば、ログインしなくても、他のユーザーをシステム管理者のアクセス権限を持つように作成または変更することができます。 |
ホスト名フィルタまたはIPアドレス・フィルタの値は、次のような状況でOracle Content Serverインスタンスと通信できるように設定する必要があります。
Inbound RefineryおよびPDF Converterの実行時(Oracle Content Serverインスタンスと同じ物理コンピュータ上の場合でも)。
コンピュータ間でのOracle Content Serverアーカイブの転送時。
WebサーバーとOracle Content Serverインスタンスが異なるシステムにある場合の構成。
EJB拡張機能の操作。
Oracle Content Serverインスタンスとは別のシステムでIdcCommandまたはIdcCommandXユーティリティの使用時。(デフォルト値を変更し、WebサーバーのIPアドレスを指定する必要があります。)
「システム・プロパティ」: 「ローカライズ」タブを使用すれば、日付/時間のフォーマット、デフォルトのタイムゾーン、ソート順序、およびデフォルトのインタフェース言語などの言語特有の問題を変更できます。ローカライズの詳細は、『Oracle Fusion Middleware Content Serverアプリケーション管理者ガイド』を参照してください。
デフォルトのEnglish-USロケールでは、年は2桁(yy)で表現され、1969年から2068年の間のものとして解釈されます。つまり、65は1965年ではなく、2065年とみなされます。English-USロケールで1969年より前の年が正しく解釈されるようにするには、そのロケールのデフォルトの日付フォーマットを、年が4桁(yyyy)で表されるように変更する必要があります。
この問題は、すでに年の表現に4桁を使用しているEnglish-UKロケールには当てはまりません。
デフォルトのEnglish-US日付フォーマットを変更するには、次のようにします。
システム・プロパティ・アプレットを起動します。
Windowsオペレーティング・システムの場合:
「スタート」→「すべてのプログラム」→「Oracle Content Server」→[インスタンス名]→「ユーティリティ」→「システム・プロパティ」を選択します。
UNIXオペレーティング・システムの場合:
SystemPropertiesユーティリティは、Oracle Content Serverインストール・ディレクトリの/binサブディレクトリにあります。
「ローカライズ」タブを開きます。
ロケールのリストでEnglish-USエントリを選択し、「編集」をクリックします。
「ロケールの構成」ダイアログが表示されます。
日付フォーマットを2桁(yy)ではなく4桁(yyyy)を使用して年を表すように修正します。
編集が終了したら、「OK」をクリックして「ロケールの構成」ダイアログを閉じます。
「OK」をクリックして変更を適用し、「システム・プロパティ」を終了します。
Oracle Content Serverインスタンスを停止して再起動し、構成の変更内容を反映します。
Oracle Content Serverシステムのデフォルトのインタフェース言語は、いくつかの方法で指定できます。
4.1.7.1項「日付フォーマット」で説明されているのと同じ基本手順で、システム・プロパティ・ユーティリティの「ローカライズ」タブでデフォルトの言語を選択します。
Oracle Content Serverナビゲーション・ポータルを使用して、「管理」→「ローカライズ」を選択します。「ローカライゼーション管理」ページの「有効なロケール」のリストから、デフォルト言語のチェックボックスを選択します。
「システム・プロパティ」: 「パス」タブでは、ヘルプ・ブラウザの場所、Javaクラスパスおよび共有ディレクトリ・パスを変更できます。セキュリティ上の理由から、管理サーバーはパス・オプションの構成に使用できません。この構成には、スタンドアロン・アプリケーションを使用する必要があります。
構成の変更内容を反映するには、Oracle Content Serverインスタンスを再起動する必要があります。
この項の内容は次のとおりです。
Oracle Content Serverは、商用検索エンジンやデータベースなどの検索付けツールと接続して一緒に機能します。使用する検索付けツールは、Oracle Content Serverシステムが機能する目的や環境に基づいて、インストール前に選択されます。
各索引付けツールには、フルテキストの索引付けとメタデータのみの索引付け機能があります。フルテキストの索引付けでは、ファイル内のメタデータのみでなく、すべての語に索引が付けられます。フルテキストの索引付けは、メタデータの索引付けより時間がかかりますが、より包括的な結果セットが得られます。メタデータのみの索引付けでは、格納されたコンテンツ情報のすべての語に索引が付けられます。メタデータのみの索引付けは、フルテキストの索引付けよりも高速です。デフォルトでは、Oracle Content Serverインスタンスは、メタデータのみの索引付けを使用するように構成されます。
この項には、次の項目が含まれます。
リポジトリ・マネージャ・ユーティリティには、管理者が検索索引に対してアクションを実行するために使用できる「インデクサ」タブがあります。
リポジトリ・マネージャにアクセスするには、「管理」トレイで「管理アプレット」→「リポジトリ・マネージャ」をクリックします。リポジトリ・マネージャには、スタンドアロン・アプリケーションとしてアクセスすることもできます。詳細は、3.4.2項「スタンドアロン・モードでの管理アプリケーションの実行」を参照してください。
リポジトリ・マネージャ画面の「インデクサ」タブでは、管理者が次のアクションを実行できます。
検索索引の更新: 索引データベースを追加的に更新します。索引はサーバーにより約5分ごとに自動的に更新されるため、これは通常必要ありません。
コレクションの再構築: 検索索引が完全に再構築され、古い索引コレクションは新しい索引コレクションに置き換えられます。
更新または再構築の一時停止: 更新または再構築を一時的に停止します。適切な「開始」ボタンをクリックすることで、プロセスを再開できます。
検索更新の取消し: 索引の更新プロセスが終了し、その時点までに処理されたファイルのみが検索エンジンでアクセス可能になります。
コレクション再構築の取消し: 索引再構築プロセスが終了し、前の索引データベースが引き続き検索エンジンによって使用されます。
リポジトリの管理の詳細は、『Oracle Fusion Middleware Content Serverアプリケーション管理者ガイド』を参照してください。
リポジトリ・マネージャ画面で、「インデクサ」タブをクリックします。
「コレクション再構築サイクル」領域で「開始」をクリックします。
|
注意: OracleTextSearchには高速再構築機能があり、サイトでOracleTextSearch機能を使用する場合、リポジトリ・マネージャのインデクサ機能から使用できます。詳細は、7.1.3.2項「高速再構築」を参照してください。 |
検索索引の更新またはコレクションの再構築のためのパラメータを設定するには、次のようにします。
リポジトリ・マネージャ画面で、「インデクサ」タブをクリックします。
画面の「自動更新サイクル」領域または「コレクション再構築サイクル」領域のいずれかで、「構成」をクリックします。
「自動更新サイクル」画面または「コレクション再構築サイクル」画面が表示されます。
インデクサ・バッチ当たりのコンテンツ・アイテム(ファイル)数を指定します。これは、検索索引で同時に処理されるファイルの最大数です。
チェックポイント当たりのコンテンツ・アイテム(ファイル)数を指定します。これは、関連するすべての索引付け状態を一度に通過するファイルの数です。チェックポイントごとに、複数のファイル・バッチを索引付けできます。
インデクサのデバッグ・レベルを指定します。これは、サーバー・ウィンドウで表示する各ファイルの関連情報の量です。
「OK」をクリックします。
索引付けエンジンとしてDATABASE.FULLTEXTまたはORACLETEXTSEARCHを使用するようにOracle Content Serverインスタンスを構成した場合、Oracle Content Serverシステムでは、Outside Inコンテンツ・アクセス・モジュールを使用して、チェックイン時にコンテンツをテキスト・ファイルにエクスポートします。その後、テキスト・ファイルは、全文索引付けのためにフルテキスト・インデクサに渡されます。
|
注意: Outside Inコンテンツ・アクセス・モジュールでPostScriptファイルを変換する際、変換プロセスで余分な文字を含むテキストが生成されます。残念ながらこれにより、全文索引付けされてもフルテキスト検索ができないファイルが作成されます。 |
DATABASE.FULLTEXTを使用する場合、フルテキスト検索は、大きなドキュメントでは問題になる可能性があります。デフォルトでは、索引付けされる最大のドキュメント・サイズは10MBです。これは、Oracle Content ServerリポジトリでMaxIndexableFileSize構成変数を設定すれば変更できます。デフォルトはMaxIndexableFileSize=10485760です。それより大きなドキュメントで全文索引付けが必要な場合は、MaxIndexableFileSizeの値を増やす必要があります。
たとえば、ファイル・スペースを節約したり、特定のコンテンツ・タイプにフルテキスト検索が不要な場合などには、全文索引付けを無効にできます。全文索引付けを無効にしても、メタデータには索引が付けられます。
特定のファイルに対して全文索引付けを無効にするには、次のようにします。
アプリケーション/索引なしという構成マネージャ画面で、フォーマットを定義します。
「チェックイン時にフォーマットの上書きを許可」設定を有効にします。4.1.2項「一般オプションの構成」を参照してください。
ユーザーは、索引付けが不要なファイルをチェックインする際、アプリケーション/索引なしフォーマットを選択する必要があります。標準ファイル、バッチ・ロードおよびアーカイブされたリビジョンがこれに当てはまります。
検索索引では、索引付けにデフォルトでWebレイアウト・ファイルを使用します。状況によっては、Webレイアウト・ファイルのかわりに、デフォルトでネイティブ・ファイルに索引を付ける方が便利な場合があります。たとえば、処理上の問題のために、変換されたPDFファイルを抽出して索引付けできない場合、ネイティブのWordドキュメントまたはかわりのタイプのドキュメントを抽出して、索引を付けることができます。あるいは、プライマリ・ファイルが.exeファイルであるために索引付けできなくても、かわりの.txtファイルがある場合、そのファイルに索引付けができます。
検索索引で、ネイティブ・ファイルをデフォルトで索引付けに使用できるようにするには、Oracle Content Serverインスタンスで次のパラメータを設定します。
UseNativeFormatInIndex=true
Oracle Content Serverソフトウェアでは、電子メールおよび添付ファイル(元のファイルやzipファイルなど)の索引付けがサポートされています。電子メールのメッセージはデフォルトで索引付けされ、メッセージに添付ファイルが含まれる場合は、それも抽出され、全文として検索付けされます。検索結果で返されるものには変わりはなく、検索によりドキュメント内に情報が見つかった場合、そのドキュメントのメタデータが返されます。Outside Inテクノロジでサポートされている電子メールの添付ファイルはすべて、検索索引でサポートされます。
この項で説明する機能は、データベース検索の「次を含む」演算子機能をインストールし、有効にしてある場合にのみ使用可能です。
|
注意: この機能は、OracleTextSearchコンポーネントでは必要ありません。 |
この項には、次の項目が含まれます。
データベース検索の「次を含む」演算子を使用すると、SQLサーバーおよびOracleでデータベースおよびデータベース・フルテキスト検索を実行する際、テキスト・フィールドの検索に「次を含む」検索演算子を使用できます。まず、「次を含む」検索演算子を使用して問合せができるテキスト・フィールドを有効にする必要があります。これらのテキスト・フィールドは、ゾーン・テキスト・フィールドと呼ばれます。
テキスト・フィールドがゾーン・テキスト・フィールドとして追加されると、そのフィールド内のテキストは解析され、データベースにフィールドの全文索引が作成されます。データベースにより索引作成の全作業が実行され、そのテキスト・フィールドがゾーン・テキスト・フィールドとして無効になると、索引はデータベースから削除されます。したがって、テキスト・フィールドをゾーン・テキスト・フィールドとして有効または無効にした後で、コレクションを再構築する必要はありません。
|
重要: テキスト・フィールドをゾーン・テキスト・フィールドに変更すると、非常に時間がかかる場合があります。この処理で、テキストを解析し、全文索引を作成するのに要する時間は、Oracle Content Serverリポジトリにあるコンテンツ・アイテムの数と、テキスト・フィールドに格納されているテキストの量によって異なります。ただし、テキスト・フィールドに索引が付いていると、コンテンツ・アイテムの更新および追加時に、パフォーマンスが大幅に低下することはありません。 |
テキスト・フィールドがゾーン・テキスト・フィールドとして有効になっていると、「拡張検索」ページでそのテキスト・フィールドに対して「次を含む」検索演算子を使用できます。それは、そのテキスト・フィールドの隣のリストに、「語を含む」オプションとして表示されます。
ゾーン・テキスト・フィールドを有効または無効にするには、次の手順を完了します。
Oracle Content Serverインスタンスに管理者としてログインします。
「管理」メニューまたは「管理アプレット」ページから「ゾーン・フィールドの構成」を選択します。ゾーン・フィールドの構成ページが表示されます。
リストから検索エンジンを選択します。
テキスト・フィールドをゾーン・テキスト・フィールドとして有効にするには、次の手順を完了します。
「テキスト・フィールド」リストでテキスト・フィールドを選択します。キーボードの[Ctrl]キーおよび[Shift]キーを使用して、複数のフィールドを選択できます。
デフォルトでは、フィールド長が20文字以下のテキスト・フィールドは「テキスト・フィールド」リストに掲載されません。この設定を変更するには、 MinFullTextFieldLength 構成変数を変更します。詳細は、4.2.3.3項「MinTextFullFieldLength変数の変更」を参照してください。
左矢印ボタンをクリックして、テキスト・フィールドを「ゾーン・テキスト・フィールド」リストに移動します。
「更新」をクリックします。
|
重要: テキスト・フィールドをゾーン・テキスト・フィールドに変更すると、非常に時間がかかる場合があります。この処理で、テキストを解析し、全文索引を作成するのに要する時間は、Oracle Content Serverリポジトリにあるコンテンツ・アイテムの数と、テキスト・フィールドに格納されているテキストの量によって異なります。ただし、テキスト・フィールドに索引が付けられている場合は、コンテンツ・アイテムを更新および追加するとき、パフォーマンスが大幅に低下することはありません。 |
ゾーン・テキスト・フィールドを無効にするには、次の手順を完了します。
「ゾーン・テキスト・フィールド」リストでゾーン・テキスト・フィールドを選択します。キーボードの[Ctrl]キーおよび[Shift]キーを使用して、複数のフィールドを選択できます。
右矢印ボタンをクリックして、テキスト・フィールドを「テキスト・フィールド」リストに移動します。
「更新」をクリックします。
ゾーン・テキスト・フィールドを有効または無効にする際、次のことを考慮してください。
リストの変更開始後に、最後に保存したリストに戻る場合は、「リセット」をクリックします。
カスタム・テキスト・フィールド(「コメント」テキスト・フィールドおよびカスタマ作成のテキスト・フィールド)がデータベース検索エンジンとデータベース・フルテキスト検索エンジンとの間で共有されるため、一方の検索エンジンでこれらのテキスト・フィールドのステータスを変更すると、その変更がもう一方の検索エンジンにも適用されます。
標準テキスト・フィールド(作成者、コンテンツID、コンテンツ・タイプ、タイトルなど)は、検索エンジンごとに有効化または無効化できます。
データベースにより索引作成の全作業が実行され、そのテキスト・フィールドがゾーン・テキスト・フィールドとして無効になると、索引はデータベースから削除されます。したがって、テキスト・フィールドをゾーン・テキスト・フィールドとして有効または無効にした後で、コレクションを再構築する必要はありません。
ゾーン・テキスト・フィールドは、無効にしなければ、構成マネージャを使用してOracle Content Serverインスタンスから削除できません。有効なテキスト・フィールドを構成マネージャを使用して削除し、「データベース設計の更新」をクリックすると、エラーが発生します。
ゾーン・テキスト・フィールドを無効にすることで、そのフィールドの索引がデータベースから削除され、フィールドをデータベースから削除できます。ゾーン・テキスト・フィールドを無効にするかわりに、データベースにログインし、フィールドの索引を削除するコマンドを発行して、フィールドを削除することもできます。
すべてのゾーン・テキスト・フィールドを無効する場合は、機能をアンインストールする前に行います。そうしないと、手動でゾーン・テキスト・フィールドを無効にするか、またはゾーン・テキスト・フィールドの索引をデータベースから削除する機能を再インストールしないかぎり、ゾーン・テキスト・フィールドをOracle Content Serverインスタンスから削除することはできません。
デフォルトでは、フィールド長が20文字以下のテキスト・フィールドは「テキスト・フィールド」リストに掲載されません。この設定を変更するには、 MinFullTextFieldLength 構成変数を変更します。この変数を変更するには、次の手順を完了します。
テキスト・エディタを使用して、IntradocDir/config/ディレクトリにあるconfig.cfgファイルを開きます。
MinFullTextFieldLength構成変数を追加し、その値を設定します(デフォルト値は21です)。例:
MinFullTextFieldLength=16
config.cfgファイルへの変更内容を保存します。
Oracle Content Serverインスタンスを再起動します。
機能を無効にする前に、すべてのゾーン・テキスト・フィールドを無効にします。データベースには、有効なゾーン・テキスト・フィールドごとに索引が保存されています(索引は、ゾーン・テキスト・フィールドが無効になると削除されます)。データベースにフィールドの索引が保存されている場合、構成マネージャを使用してそのフィールドをOracle Content Serverインスタンスから削除することはできません。詳細は、4.2.3.2項「ゾーン・テキスト・フィールドの有効化および無効化」を参照してください。
機能を無効にした後で、ゾーン・テキスト・フィールドとして有効なフィールドを削除する場合は、次のいずれかの方法があります。
機能を再インストールし、ゾーン・テキスト・フィールドを無効にして、構成マネージャでフィールドを削除してから、機能をアンインストールします。
データベースにログインし、フィールドの索引を削除するコマンドを発行してから、構成マネージャを使用してフィールドを削除します。
システムが、データベースによる索引付けおよび検索機能を使用できるよに設定されているとすれば、担当のシステム・インテグレータがIntradocDir/config/config.cfgファイルに次のいずれかの行を追加しているものと考えられます。
メタデータ検索のみ:
SearchIndexerEngineName=DATABASE.METADATA
Oracle Fusion Middleware 11g リリース1(11.1.1)でサポートされているすべてのデータベースで、DATABASE.METADATAがサポートされます。
フルテキスト検索:
SearchIndexerEngineName=ORACLETEXTSEARCH
Oracle Databaseリリース11.1.0.7以上では、ORACLETEXTSEARCHがサポートされます。
フルテキスト検索:
SearchIndexerEngineName=DATABASE.FULLTEXT
SQL ServerおよびOracle Database(サポートされている全リリース)で、DATABASE.FULLTEXTがサポートされます。
サポートされているデータベースに適したdbfulltextsearchスクリプトが実行されます。
デフォルトでは、全文索引付けは、変換されたすべてのファイルに適用されます。
デフォルトでは、次のいずれかのフォーマットを経た、またはそのフォーマットに変換されたファイルに、Oracle Content Serverは全文索引を付けます。
Oracleでサポートされているフォーマット
html
htm
xls
hcsp
text
txt
doc
rtf
ppt
MS SQLでサポートされているフォーマット
text
txt
htm
html
doc
msword
ms-word
ms-powerpoint
ppt
ms-excel
xls
たとえば、Microsoft Word(.doc)ファイルをPDFのかわりにテキスト・ファイルに変換する場合、構成マネージャでこれを指定できます。つまり、「ファイル・フォーマット」オプションを使用して、.docファイル拡張子をテキスト・フォーマットにマップすると、これによってそのファイルがどのようにWeb表示可能フォーマットに変換されるかが定義されます。この場合、テキスト・ファイルは、Webサイトに渡される前に完全に索引付けされます。
構成マネージャの「ファイル・フォーマット」オプションの詳細は、『Oracle Fusion Middleware Content Serverアプリケーション管理者ガイド』を参照してください。
システム・プロパティでフォーマット・オーバーライド機能を有効にすれば、コントリビュータがファイルの全文索引付けをするかどうかを指定できるようにすることができます。4.1.2項「一般オプションの構成」を参照してください。
たとえば、構成マネージャの「ファイル・フォーマット」オプションを使用して、Corel WordPerfect(.wpd)ファイルをtextフォーマットが使用できるようにマップしている場合、コントリビュータがチェックイン・ページの「フォーマット」フィールドで「デフォルトの使用」オプションを選択すると、ファイルはテキストに変換され、全文索引が付けられます。コントリビュータが「Corel WordPerfectドキュメント」を選択した場合、ファイルはネイティブ・フォーマットで渡され、全文索引付けは行われません。
構成マネージャの「ファイル・フォーマット」オプションの詳細は、『Oracle Fusion Middleware Content Serverアプリケーション管理者ガイド』を参照してください。
フルテキスト検索を使用する場合、メタデータ検索では大文字と小文字が区別され、フルテキスト検索では区別されません。ただし、コンテンツIDの場合、小文字が大文字に変換されるため、小文字では検索できません。
ファイル・フォーマットをネイティブ・フォーマットでPASSTHRUに定義し、そのフォーマット名に前述のリストにあるタイプの1つが含まれている場合(application/ms-excel.nativeなど)、通過するネイティブ・ファイルにはデフォルトで全文索引が作成されます。
または、構成変数を使用して、ドキュメントに全文索引を作成するかどうかを制御することもできます。特定のドキュメント・フォーマット・タイプの全文索引付けおよび検索を管理するには、IntradocDir/config/config.cfgに該当するエントリを追加し、ファイルを保存します。全文索引付け構成変数には、次のものがあります。
FormatMap構成変数は、フルテキスト検索索引に特定のフォーマットを含めるべきかどうかを制御します。これは、全文索引付けの対象となるすべてのフォーマットのカンマ区切りのリストです。ファイルに割り当てられたMIMEタイプを取得し、MIMEタイプをスラッシュ(/)またはピリオド(.)で分割し、その値がFormatMapリストにあるかどうかを調べることで決定します。
たとえば、application/vnd.mswordは、次の3項目のリストになります。
application
vnd
msword
FormatMapのリストにmswordがある場合、インデクサ・エンジンではファイルに全文索引付けが試みられ、比較テストでは大文字と小文字は区別されません。
Oracle Query Optimizerコンポーネントは、デフォルトではOracle Content Serverシステムによってインストール(有効化)されます。この機能は、Oracleデータベースでのみ機能します。
この項には、次の項目が含まれます。
Oracleデータベースでは、一部のタイプのユーザー問合せに対して、最良の実行計画が自動的に選択されません。これに対処するため、Oracle Query Optimizerにより、Oracleデータベースで検索がより効率的に実行されるようにするヒントを問合せに追加します。
ヒントは、Oracle Content Serverの表データ配布およびその索引選択性の本質的な知識に基づいています。この知識を利用するために、Oracle Query Optimizerでは、事前定義のヒント・ルール表を使用して、データベース問合せを分析し、その問合せに適切なヒントを追加します。その結果、追加されたヒントにより、Oracleの検索パフォーマンスが改善されます。
Oracle Query Optimizerでは、Content Serverのデータベース表でのデータ配布と、その索引選択プリファレンスを利用します。これらの特性に基づき、Oracle Query Optimizer付属のヒント・ルール表には、事前定義のルールが含まれています。この機能では、これらのルールを使用してデータベース問合せを分析し、検索パフォーマンスを最適化するための1つ以上の適切なヒントを追加します。
数百万のコンテンツ・アイテムを含む非常に大きなコレクションでは、通常、Oracle Content Serverソフトウェアは、簡単な問合せを解決する場合でも、適切な最適化方法をなかなか選択できません。この問題に対処するために、Oracle Query Optimizerでは、発行された問合せを検査し、その分析に基づいて、検索プロセスを最適化する適切なヒントを追加することで、問合せを再フォーマットします。この機能では、ヒントを追加するために、Oracle Content Serverのヒント、ヒント・ルール表およびヒント・キャッシュが使用されます。
最適化プロセスのステージは、次の順序で完了します。
発行された問合せは、1つ以上のヒントが含まれているかどうかを確認し、含まれる場合は、ヒントのタイプ判断するために分析されます。「ステージ1: 問合せ分析」を参照してください。
問合せのWHERE句にヒントが含まれていない場合、最適化機能によりWHERE句を解析する必要があります。「ステージ2: 解析」を参照してください。
解析後、問合せのWHERE句の各条件が、ヒント・ルール表に照合して評価され、条件の修飾および正規化が試みられます。「ステージ3: 正規化」を参照してください。
WHERE句の条件が修飾され、問合せが正規化されると、ヒントが選択されるか、ヒント・キャッシュから取得されます。「ステージ4: ヒントの選択」を参照してください。
選択したヒントを使用して、問合せが再フォーマットされます。「ステージ5: 問合せの再フォーマット」を参照してください。
このステージでは、Oracle(ネイティブ)とコンテンツ・サーバーの両方のヒントがないか、問合せをチェックします。これは、ヒント構文に基づいて判断されます。「問合せヒント構文」を参照してください。Oracleヒントが含まれる問合せは通過します。コンテンツ・サーバーのヒントが含まれる問合せは、ステージ2: 解析およびステージ3: 正規化を迂回して先に進みます。問合せに複数のコンテンツ・サーバーのヒントが含まれる場合、最良のヒントが選択されます。ヒントが含まれていない問合せは、解析と正規化化が必要です。
このステージでは、ヒントが含まれていない問合せが問合せパーサーを通して送られ、WHERE句が解析されます。WHERE句は、ANDまたはORのいずれかの接続詞で接続された1つ以上の条件で構成されています。条件ごとに、フィールド名、演算子およびフィールド値が抽出されます。句のANDまたはOR接続詞は残されますが、カッコは削除されます。条件には次のフォーマットを使用する必要があります。
fieldnameoperatorvalue
たとえば、正しいフォーマットの条件はdID = 3となります。3 = dIDは間違った条件です。
このステージでは、正規化により条件を単純化し、問合せ演算子を確定して、追加の手順のためにWHERE句の表示を安定させます。正規化プロセスの結果は、キャッシュ・キーと、ヒント検索に使用するフィールドのリストを生成するための基礎となります。
|
注意: どのデータベース表や列に索引を付けるかを設定するために、ヒント・ルール表がコンテンツ・サーバー・リソースおよび実行中のシステムで定義されます。 |
WHERE句内の各条件は、ヒント・ルール表に照合してチェックされます。条件のフィールド名がヒント・ルール表に含まれている場合、それが修飾され、正規のものとみなされます。条件には、その表の名前とエイリアスが含まれます。次に、正規化された条件は、同じセットの条件が常に一貫してリストに表示されるようにソートされます。
正規化時に、次の条件は不適切とみなされて、その後の処理から除外されます。
結合条件。
副問合せを含む条件。
フィールド名にヒント・ルール表内のエントリが含まれておらず、修飾できない条件。
複数のフィールドを含むOR条件。例:
(dSecurityGroup = 'Secure' or dDocAccount LIKE 'prj%')
値がワイルドカードで始まるLIKE演算子を含む条件。
正規化の手順で、問合せ条件は、複雑な問合せ条件をまとめるために書き換えられます。OR条件は、次のように再評価されます。
すべてのフィールドが同じで、すべての演算子が等しい(またはすべての演算子がLIKEで、ワイルドカードで始まる値がない)場合、条件は結合され、1つのIN問合せに変更されます。
フィールドは同じでも、演算子が異なる場合、条件は結合され、汎用演算子が割り当てられます。
フィールドが異なる場合、条件は削除されます。
たとえば、正規化中に、次の条件は再フォーマットされます。
(dReleaseState = 'Y' OR dReleaseState = 'O")
これは次のように再フォーマットされます。
dReleaseState IN ('Y', 'O')
解析した問合せは、使用可能な範囲問合せがないか分析され、それらは正規化のプロセスでまとめられます。たとえば、条件dIndate > date1およびdInDate < date2は、range演算子を使用して1つの条件にまとめられます。
このステージでは、正規化された条件が、ヒント・キャッシュに照合してチェックされます。1つ以上の条件で、キャッシュ内に適用可能なヒントが見つかった場合、それらは含まれます。キャッシュで適用可能なヒントが見つからない場合、条件は分析され、考えられる最良のヒントを決めるために、優先順位が比較されます。
このステージでは、選択したヒントを付け加えることで、問合せが再フォーマットされます。検索の最適化に役立つヒントで問合せを再フォーマットする方法の詳細と、再フォーマットされた問合せのいくつかの例は、4.2.5.3項「再フォーマットされた問合せによる検索の最適化」を参照してください。
Oracle Content Serverインスタンス内の大部分の問合せは、対象となるコンテンツ・アイテム・セットが小さいか、返す行が最大でも100行です。Oracle Content Serverソフトウェアは、簡単に数百万のコンテンツ・アイテムに対応できます。ただし、1000万のコンテンツ・アイテムを含むコレクションを持つOracleデータベースでテストを行うと、Oracleで選択される実行計画が最も効率のよいものではないことがわかります。Oracleでは通常、多数の問合せを、一部取るに足りないものがあっても、解決するのに最良の最適化方法が選択されません。次の例は、この問題を説明しています。
前述の環境では、Oracleにより次の問合せができるだけ効率的に解決されることはありません。
SELECT *
FROM Revisions, Documents, DocMeta
WHERE Revisions.dID = Documents.dID
AND Revisions.dID = DocMeta.dID
AND Revisions.dRevClassID = 333
Order By Revisions.dID
かなり選択性の高い索引が使用可能であるため(Revisions.dRevClassID用のdRevClassID_2)、この問合せはdRevClassID_2にアクセスし、dRevClassIDに一致する行に対してソートを実行する必要があります。ただし、この問合せの例では、OracleはRevisions.dID索引の使用を選択します。
この選択では、全索引スキャンを実行し、行ごとにdRevClassIDを取得しに表にアクセスするため、実際にはRevisions表で全表スキャンを実行するより効率が悪くなります。コンテンツ・アイテムが1000万を超えるOracle Content Serverリポジトリの場合、この実行計画を使用して問合せを解決しようとしてもうまくいかないのは明らかです。この場合、結果を返すのに約500秒かかります。
しかし、次のようなヒントを1つ追加して問合せを変更すると、パフォーマンスは劇的に向上します。
SELECT /*+ INDEX(Revisions dRevClassID_2)*/ *
FROM Revisions, Documents, DocMeta
WHERE Revisions.dID = Documents.dID
AND Revisions.dID = DocMeta.dID
AND Revisions.dRevClassID = 333
Order By Revisions.dID
問合せは、SELECT句に次のヒントを加えて変更されています。
/*+ INDEX(Revisions dRevClassID_2)*/
これにより、Oracleデータベースでは、Revisions.dID用の索引ではなく、dRevClassID_2索引が強制的に選択されます。この例では、dRevClassIDを共有するコンテンツ・アイテムがわずかなので、変更された問合せは即時に結果を返します。
標準的なOracle Content Serverインスタンスでは、大部分のドキュメントは、現在の日付より前のdInDateで、dReleaseStateのステータスが「Y」(リリース済)になっています。ただし、わずかながら、dReleaseStateのステータスが「N」(新規、また索引なし)のドキュメントがあります。次の問合せでは、まだリリースされていないコンテンツ・アイテムを検索します。
SELECT dID
FROM Revisions
WHERE Revisions.dReleaseState = N'N' AND Revisions.dStatus in
(N'DONE', N'RELEASED', N'DELETED')
AND Revisions.dInDate<={ts '2005-02-23 17:46:38.321'}
問合せの最適化された結果では、dReleaseStateの索引を使用します。
SELECT/*+ LEADING(Revisions) INDEX (Revisions dReleaseState)*/
dID
FROM Revisions
WHERE Revisions.dReleaseState = N'N' AND Revisions.dStatus in
(N'DONE', N'RELEASED', N'DELETED')
AND Revisions.dInDate<={ts '2005-02-23 17:46:38.321'}
Oracle Content Server問合せは、様々なリソースで定義されている静的問合せ、動的WHERE句が追加されているデータ・ソース、および臨時のまたはアーカイバなどのアプリケーションで定義されている動的問合せのいずれかです。静的問合せは、Oracleデータベースのヒントによって更新される場合があります。ただし、臨時の問合せや動的WHERE句のヒントを事前に定義することは、ほとんど不可能です。
コンテンツ・サーバーのヒントでは、同じ問合せ内で複数のヒントをサポートする、データベースを選ばないヒント構文が使用されます。Oracle Content Serverのヒントは、どの問合せ、データ・ソースおよびWHERE句でも使用できます。ただし、Oracleデータベースのヒントとは結合できません。1つの問合せに両方のタイプのヒントが含まれている場合、Oracle Query Optimizerでは、Oracleデータベースのヒントが保持され、コンテンツ・サーバーのヒントは無視されます。
最適化処理の各ステージで、Oracle Query Optimizerでは、両方のタイプのヒントの異なった構文を認識し、それに応じて発行された問合せを処理します。詳細は、4.2.5.2項「問合せの最適化プロセス」を参照してください。
Oracle Content Serverヒントの構文は、データベースを選ばず、同じ問合せの中で複数のOracle Content Serverヒントをサポートできます。最適化プロセス中に、Oracle Content Serverヒントは、評価され、最適のヒントが再フォーマットされて、元の問合せに追加されます。
最適化のプロセスでは、1つ以上のOracle Content Serverヒントを含む問合せは解析されません。Oracle Content Serverのヒントのみが、索引選択時に検討されます。
Oracle Content Serverヒントの構文:
問合せが最適化プロセスを経ると、次の構文を使用して、再フォーマットされた問合せにOracle Content Serverのヒントが追加されます。
/*$tableName[aliasName]:columnName[:operator [:<value>]][, …]*/
説明:
山カッコに囲まれた値(<value>)は必須です。
角カッコに囲まれた値([value])はオプションです。
省略符(…)は、前の表現の繰り返しを示します。
最適化プロセス前の問合せ:
SELECT * FROM Revisions, DocTypes, RoleDefinition WHERE /*$Revisions:dStatus*/(Revisions.dStatus<>'DELETED' AND Revisions.dStatus<>'EXPIRED' AND Revisions.dStatus<>'RELEASED') AND Revisions.dDocType = DocTypes.dDocType AND /*$Revisions:dReleaseState*/Revisions.dReleaseState<>'E' AND (Revisions.dSecurityGroup = RoleDefinition.dGroupName AND RoleDefinition.dRoleName = ? AND RoleDefinition.dPrivilege > 0)
Oracle Content Serverのヒントを追加して再フォーマットされた問合せ:
問合せが最適化プロセスを経ると、両方の索引が使用され、ネイティブ索引に追加されます。
SELECT/*+ LEADING(revisions) INDEX (revisions dStatus dReleaseState)*/ * FROM Revisions, DocTypes, RoleDefinition WHERE (Revisions.dStatus<>'DELETED' AND Revisions.dStatus<>'EXPIRED' AND Revisions.dStatus<>'RELEASED') AND Revisions.dDocType = DocTypes.dDocType AND Revisions.dReleaseState<>'E' AND (Revisions.dSecurityGroup = RoleDefinition.dGroupName AND RoleDefinition.dRoleName = ? AND RoleDefinition.dPrivilege > 0)
検索問合せ句でOracleソート構造体を使用すると、問合せを実行する際のユーザーの自由度が向上します。ソート構造体は、複数の表で抽出、ソートおよび結合される行データを指定します。基本的に、ソート構造体は、返される行数を制限する目的に役立ちます。Oracle Query Optimizerでは、次のソート構造体が認識されます。
ヒント・ルール表には、最適化機能で、最適化プロセス中に動的問合せやデータ・ソースに追加する適切なヒントを決めるために使用されるルールが含まれています。「ヒント・ルール・フォームの編集」を使用すれば、特定のフィールドや演算子に対して、ヒント・ルールを定義できます。ヒント・ルールは、値や日付/数の範囲に基づいて定義することもできます。ヒント・ルール表は、他のコンポーネントによって拡張可能で、Oracle Content Serverインスタンスの実行中に更新できます。
Oracle Query Optimizerに含まれているデフォルトのヒント・ルールの一部については、この後説明します。表の列の詳細は、4.2.5.8項「ヒント・ルール表の列の説明」を参照してください。ヒント・ルール表の内容は、「管理」トレイからアクセスする「ヒント・ルールの構成」ページを見ればわかります。
ヒント・ルール表は、毎晩、およびルールが追加または変更されるたびに、再ロードするようにスケジュールされています。ヒント値は、再ロードのたびに再計算されます。
|
重要: ヒント・ルール表には、複数の索引を相互に使用できる列がありますが、Oracleではbitmap索引のみが結合可能です。これは、ヒント・ルール表が核となるコンテンツ・サーバー機能用に設計されているためです。したがって、追加の表を作成したり、追加のメタデータ・フィールドを追加したり、あるいはその両方を行うコンポーネントを持つシステムには、不十分かもしれません。しかし、ヒント・ルール表は、追加の表、索引およびフィールドの知識を提供するために、他のコンポーネントによって拡張や上書きができます。 |
第1のヒント・ルールの説明:
このルールでは、WHERE句に次の条件が含まれている場合、PK_Revisions索引が使用され、最適化された問合せにヒントとして追加されます。
Revisions.dID = some_value
第2のヒント・ルールの説明:
このルールでは、WHERE句に次のいずれかの条件が含まれている場合、dDocName索引が使用され、最適化された問合せにヒントとして追加されます。
Revisions.dDocName = some_value Revisions.dDocName LIKE 'some_value'
第3のヒント・ルールの説明:
このルールでは、WHERE句に次の条件が含まれている場合、この条件は要件を満たさないため、修飾できません。
dStatus = 'DONE'
ただし、WHERE句に次の条件が含まれている場合、dStatus索引が使用され、最適化された問合せにヒントとして追加されます。
dStatus = 'RELEASED'
この項では、ヒント・ルール表の次の列について説明します。
この列には、ルールを識別する一意の名前が含まれています。コンポーネントは、一意のキーを使用して、特定のルールを上書きできます。同じデータベース・スキーマ内では索引名は一意であるため、このキーは通常その索引名と同一です。
デフォルトでは、OracleはB+ Tree(バイナリ・ツリー)を索引構造として使用し、論理レコードへのアクセスを効率化します。B+ Tree索引は、結果の行数が少ない問合せや、ユーザーが変化する基準(等価条件および範囲条件など)を使用して問合せを実行する必要のある場合に、最も便利です。B+ Tree索引には索引の付いたデータ値が格納されるため、リクエストされた値が格納されている値である場合、データの便利なソースとなります。
しかし、ビットマップ索引は、デフォルトのB+ Tree索引と比べて、最小限のストレージ・コストで、大幅にパフォーマンスを向上させます。ビットマップ索引は、異なる値がほとんどないために選択性の低い列の検索に特に効果的です。また、ビットマップは、NULL値を含め(つまりNULLに索引が付けられる)、値ごとに作成されます。全般的に、索引参照プロセスはビットレベルの操作であり、複数の索引へのアクセスが可能であるため、ビットマップ索引の使用は非常に効率的です。
|
注意: ヒント・ルールは上書きできるため、Oracle Query Optimizerでは、既存のキーを使用してヒント・ルールを追加することはできません。したがって、一意のキーを割り当てる列にビットマップ索引を作成している場合、これは重要です。 |
次のリストに示した表の列にはビットマップ索引を使用し、索引名は対応する列名に設定することをお薦めします。
Revisions表:
dIndexerState
dReleaseState
dProcessingState
dIsCheckedOut
dSecurityGroup
dStatus
WorkflowDocuments表:
dWfDocState
この列は、許容演算子のカンマ区切りリストです。有効な演算子オプションの詳細は、「演算子」フィールドおよび「ヒント・ルールの構成」ページのメニューを参照してください。ヒント・ルールの演算子は、ヒント・ルールを条件に適用するかどうかを決定する際に重要です。
たとえば、WHERE句に次の条件が含まれている場合、PK_Revisions索引を使用すると、最適化された問合せに含める非常に貴重なヒントになります。
Revisions.dID = 3
ただし、WHERE句に次の条件が含まれている場合、PK_Revisions索引を使用しても役に立ちません。
Revisions.dID > 3
この列には、ヒント・ルール表にルールが記載されている場合に使用される優先順位が含まれています。問合せで最上位のルールは、どのヒントを使用するかを決める際に優先されます。
順序には次の値があります。
5: この値は、指定した索引が一意か、どの値に対しても一致する行が50行以下であることを示します。たとえば、Revisions、DocumentsまたはDocMeta表でdIDを指定します。
4: この値は、指定した索引の選択性がいくぶん低いことを示します。指定した値は、通常、数行、多くてもせいぜい数百行と一致します。たとえば、Revisions表でdDocTitleを指定します。
3: この値は、指定した索引が1000行未満の行と一致することを示します。たとえば、dInDateまたはdOutDateを指定します。
2: この値は、指定した索引が1万行未満の行と一致することを示します。
1: この値は、指定した索引が1万行を超える行と一致することを示します。
この列は、Idocスクリプト作成可能です。この列は、「演算子」列値が次のいずれかであるときにしか定義できません。
inまたはnotIn: これらの演算子のいずれかを使用する場合、値をカッコで囲まれたカンマ区切りのリストにします。
range: この演算子を使用する場合、値は次のいずれかのフォーマットを使用する必要があります。
フォーマット1:
([<lowValue>],range[,<highDateValue>])
指定可能な値の例は、次のとおりです。
('Y', 'O')
(,7d)
({ts '2004-12-11 12:03:23.000'}, 2d, <$dateCurrent()$>)
フォーマット2:
#[d|h]
たとえば、5日の範囲は5d、7時間は7hです。
|
ヒント: 演算子inまたはnotInは、それぞれ、対応する値とともに、演算子equalおよびnotEqualのかわり使用できます。演算子オプションの詳細は、「演算子」フィールドおよび「ヒント・ルール・フォームの編集」のメニューを参照してください。 |
次の使用例は、この列がどのようにヒント・ルールにさらなる柔軟性をもたらすかを示しています。
使用例1: 表の「状態」または「ステータス」列
dReleaseStateまたはdStatusなどの状態またはステータスを示す表の列は、完成した状態に関して偏りがあります。たとえば、dReleaseStateは、「Y」(リリース済)または「O」(旧バージョン)になる傾向があります。同様に、dStatusはRELEASEDになる傾向があります。したがって、WHERE句では、dReleaseState = YまたはdStatus = RELEASEDなどの条件は、Revisions表の大部分の行と一致します。このように、これら2列はほとんど役に立ちません。逆に、条件dReleaseState = N(新規、索引なし)は、わずかの行にしか一致しません。したがって、この列の索引は非常に役に立ちます。
使用例2: 表の「日付」または「数」列
日付または数を示す表の列は、状態またはステータスと同様の動作を示します。たとえば、条件dInDate < <$dateCurrent()$>は、大部分の表の行と一致し、このフィールドの索引は無意味になります。ただし、結合した条件dInDate < <$dateCurrent()$> AND dInDate > <$dateCurrent(-1)$>は通常、少量の行とのみ一致し、対応する索引をヒントとして使用するのが有益です。
この列は、ヒント・ルールが無効になっているかどうかを示します。表内のどのルールも、有効か無効のいずれかです。ヒント・ルールを無効にすると、「Y」の値が表示されます。既存のルールを無効にして、コンテンツ・サーバーの現在の状態に合せることができます。
たとえば、コンテンツ・サーバー・インスタンスに、異なるrevClassがわずかしかなくても、各revClassに数千のリビジョンがある場合があります。その結果、dRevClass_2索引は、あまり効果的ではありません。この場合、これに対応するヒント・ルールは無効にして、異なる優先順位を持つ1つ以上の新しいルールを追加する必要があります。
|
注意: 表内のすべてのルールは有効化または無効化できますが、削除できるのは「ヒント・ルール・フォームの編集」を使用して追加されたルールのみです。Oracle問合せ最適化機能に含まれるデフォルトのヒント・ルールは無効化のみ可能で、削除はできません。 |
「ヒント・ルール・フォームの編集」を使用すると、「ヒント・ルールの構成」ページでルールの追加、削除、有効化または無効化ができます。新しいルールを追加して、新しい表と索引を反映できます。既存のルールを削除または無効化して、コンテンツ・サーバーの現在の状態に合せることができます。ヒント・ルール表からヒント・ルールを選択した場合は、該当する値が「ヒント・ルール・フォームの編集」の各フィールドに自動的に移入されます。
「ヒント・ルール・フォームの編集」は、「ヒント・ルールの構成」ページのヒント・ルール構成表の隣に表示されます。
ヒント・ルール構成表は、毎晩、および新しいルールが追加されるか既存のルールが変更されるたびに、再ロードするようにスケジュールされています。ヒント値は、再ロードのたびに再計算されます。
表内のすべてのルールは有効または無効にできますが、削除できるのは「ヒント・ルール・フォームの編集」を通じて追加されたルールのみです。Oracle Query Optimizerコンポーネントに含まれるデフォルトのヒント・ルールは無効化のみ可能です。これらのルールは削除できません。
Oracle Query Optimizerには、動的に生成されるヒントを格納するためのヒント・キャッシュも含まれます。たとえば、解析された問合せまたはデータ・ソースから導出されたヒントは、持続性を維持するためにキャッシュされます。このようにして、ヒント・キャッシュは、問合せやデータ・ソースを安定したものにします。
ヒント・キャッシュは、最適化プロセスで、Oracleまたはコンテンツ・サーバーのヒントが含まれていない問合せにヒントを選択するために使用されます。ヒント・キャッシュは、問合せヒントを微調整するメカニズムを提供します。さらに、管理者は実行時に、キャッシュのチェックまたは編集、および問合せのヒントの変更ができます。
ヒント・キャッシュは、2時間ごとにディスクに格納され、Oracle Content Serverインスタンスの起動時に再ロードされます。
ヒント・キャッシュには次の特性があります。
同じ問合せは、新しい値がヒント・ルールの条件を満たさない場合を除いて、その値に関係なく、同じキャッシュ・エントリに一致します。次の2つの例では、同じヒント・キャッシュ・エントリが、複数の問合せにどのように使用できるか、できないかを説明しています。
例1: 類似のヒント・キャッシュ・エントリの使用
次の2つの問合せでは、両方の問合せがヒント・ルールの要件に一致するため、同じヒント・キャッシュ・エントリが使用されています。
問合せA:
SELECT *
FROM Revisions
WHERE dDocName = 'name1'
問合せB:
SELECT *
FROM Revisions
WHERE dDocName = 'name2'
例2: 異なるヒント・キャッシュ・エントリの使用
次の2つの問合せでは、問合せBがdReleaseStateヒント・ルールの要件に違反しているため、同じヒント・キャッシュ・エントリを使用できません。dReleaseStateヒント・ルールでは、dReleaseStateの値がY(リリース済)でもO(旧リビジョン)でもないことが必要です。
問合せA:
SELECT * FROM Revisions WHERE dReleaseState = 'U' AND dStatus = 'DONE'
問合せB:
SELECT * FROM Revisions WHERE dReleaseState = 'Y' AND dStatus = 'DONE'
ヒント・キャッシュでは、「ヒント・キャッシュ更新機能」ページを使用して、新規エントリの追加、既存エントリの編集または削除を行えます。ヒント・キャッシュ・エントリの追加または編集の際には、Oracle Content Serverのヒント構文を使用する必要があります。ヒント・キャッシュの管理機能は、問合せヒントの微調整に非常に役立ちます。次の例は、ヒント・キャッシュ・エントリの微調整の利点を示しています。
例: 索引のないコンテンツのバッチロード
100KBのコンテンツ・アイテムをコンテンツ・サーバーにバッチロードしたばかりで、まだ索引を付けていない場合、先ほど(「例2: 異なるヒント・キャッシュ・エントリの使用」)使用した索引ベースの問合せは、バッチロードされたすべてのドキュメントに一致します。
問合せA:
バッチロードされたドキュメントの大部分にまだ索引が付いていない場合、この問合せで使用されるdReleaseState索引は最良の選択ではありません。この場合で最良の結果を得るには、ヒント・キャッシュ・エントリでdReleaseState索引とdStatus索引の両方を使用するように微調整する必要があります。ヒント・キャッシュ・エントリを更新するには、「ヒント・キャッシュ更新機能」ページを使用してください。
SELECT dID
FROM Revisions
WHERE Revisions.dReleaseState = N'N' AND Revisions.dStatus in (N'DONE', N'RELEASED', N'DELETED') AND Revisions.dInDate<={ts '2005-02-23 17:46:38.321'}
問合せB:
ヒント・キャッシュ・エントリの更新後、新たに最適化された問合せは、次のとおりです。
SELECT/*+ LEADING(revisions) INDEX (revisions dReleaseState dStatus)*/ dID
FROM Revisions
WHERE Revisions.dReleaseState = N'N' AND Revisions.dStatus in (N'DONE', N'RELEASED', N'DELETED') AND Revisions.dInDate<={ts '2005-02-23 17:46:38.321'}
デフォルトでは、ヒント・キャッシュの最大容量は1000ヒントです。ヒント・キャッシュでは、OracleおよびmySQLで使用されるのと同様の中央挿入最小使用頻度(LRU)アルゴリズムが使用されます。新規エントリはキューの中央に挿入され、副問合せを実行するごとに、エントリは1つ上に上昇します。
キャッシュ内のヒント数が最大容量を超えると、キューの一番下のエントリがキャッシュから削除されます。こうして、LRUアルゴリズムにより、最後に実行された問合せヒントは必ずキューの上位に残るようになります。
ヒント・キャッシュ・キーは、正規化された問合せから生成されます。4.2.5.2.3項「ステージ3: 正規化」を参照してください。これは、修飾済の列(表またはエイリアス名で修飾された列)と、ヒント・ルールが定義された列から成ります。キャッシュ・キーにより、結合または副問合せを含む条件は除外されます。
次の例では、キャッシュ・キーがどのように指定の問合せから生成されるかを示しています。
SELECT DocMeta.*, Documents.*, Revisions.* FROM DocMeta, Documents, Revisions WHERE DocMeta.dID = Revisions.dID AND Revisions.dID=Documents.dID AND Revisions.dDocName='abc' AND Revisions.dStatus<>'DELETED' AND (Revisions.dReleaseState='U' OR Revisions.dReleaseState='I' OR Revisions.dReleaseState='Y') AND Documents.dIsPrimary<>0
生成されたキャッシュ・キーは次のようになります。
documents.disprimary:notequal:documents|revisions.ddocname:equal:revisions|revisions.dreleasestate:in:revisions|revisions.dstatus:notequal:revisions
「ヒント・ルール・フォームの編集」にアクセスするには、次のようにします。
「管理」トレイを開きます。
「Oracle Query Optimizer」→「ヒント・ルールの構成」をクリックします。
「ヒント・ルール・フォームの編集」が含まれる「ヒント・ルールの構成」ページが表示されます。
ヒント・ルール表に新規ルールを追加するには、次のようにします。
「管理」トレイを開きます。
「Oracle Query Optimizer」→「ヒント・ルールの構成」をクリックします。
「ヒント・ルール・フォームの編集」で、すべてのフィールドに入力します。各フィールドの詳細は、4.2.5.7項「ヒント・ルール表」およびA.1.3.8項「ヒント・ルールの構成ページ」を参照してください。
「追加」ボタンをクリックします。
新規のヒント・ルールが、「ヒント・ルール表」に追加され、ただちに有効になります。
「ヒント・ルール表」の既存のヒント・ルールを編集するには、次のようにします。
「管理」トレイを開きます。
「Oracle Query Optimizer」→「ヒント・ルールの構成」をクリックします。
「ヒント・ルールの構成」ページの「ヒント・ルール表」で必要なヒント・ルールを選択します。
「ヒント・ルール・フォームの編集」の該当するすべてのフィールドに、ヒント・ルールの値が移入されます。
希望どおりにフィールドを編集します。各フィールドの詳細は、4.2.5.7項「ヒント・ルール表」およびA.1.3.8項「ヒント・ルールの構成ページ」を参照してください。
キーを変更します。
「追加」ボタンをクリックします。
「ヒント・ルール表」がリフレッシュされ、新規のヒント・ルールが追加されます。変更はただちに有効になります。
古いヒント・ルールを削除します。
表内のすべてのルールは有効化および無効化できますが、削除できるのは「ヒント・ルールの構成」ページを通じて追加されたルールのみです。Oracle問合せ最適化機能に含まれるデフォルトのヒント・ルールは無効化のみ可能で、削除はできません。
「ヒント・ルール表」のヒント・ルールを無効にするには、次のようにします。
「管理」トレイを開きます。
「Oracle Query Optimizer」→「ヒント・ルールの構成」をクリックします。
「ヒント・ルールの構成」ページの「ヒント・ルール表」で必要なヒント・ルールを選択します。
「ヒント・ルール・フォームの編集」の該当するすべてのフィールドに、ヒント・ルールの値が移入されます。
「無効化」ボタンをクリックします。
「ヒント・ルール表」がリフレッシュされ、「無効」列にそのヒント・ルールが無効化されたことを示す「Y」が表示されます。
表内のすべてのルールは有効化および無効化できますが、削除できるのは「ヒント・ルールの構成」ページを通じて追加されたルールのみです。Oracle問合せ最適化機能に含まれるデフォルトのヒント・ルールは無効化のみ可能で、削除はできません。
「ヒント・ルール表」で無効のヒント・ルールを有効にするには、次のようにします。
「管理」トレイを開きます。
「Oracle Query Optimizer」→「ヒント・ルールの構成」をクリックします。
「ヒント・ルールの構成」ページの「ヒント・ルール表」で必要なヒント・ルールを選択します。
「ヒント・ルール・フォームの編集」の該当するすべてのフィールドに、ヒント・ルールの値が移入されます。
「有効化」ボタンをクリックします。
「ヒント・ルール表」がリフレッシュされ、「無効」列がクリアされて、そのヒント・ルールが再び有効になったことを示します。
表内のすべてのルールは有効化および無効化できますが、削除できるのは「ヒント・ルールの構成」ページを通じて追加されたルールのみです。Oracle問合せ最適化機能に含まれるデフォルトのヒント・ルールは無効化のみ可能で、削除はできません。
「ヒント・ルール表」からヒント・ルールを削除するには、次のようにします。
「管理」トレイを開きます。
「Oracle Query Optimizer」→「ヒント・ルールの構成」をクリックします。
「ヒント・ルールの構成」ページの「ヒント・ルール表」で必要なヒント・ルールを選択します。
「ヒント・ルール・フォームの編集」の該当するすべてのフィールドに、ヒント・ルールの値が移入されます。
ヒント・ルールが有効になっていることを確認します。ヒント・ルールが無効の場合は、削除できません。無効なヒント・ルールを再び有効にするには、4.2.5.11.4項「ヒント・ルールの有効化」を参照してください。
「削除」ボタンをクリックします。
「ヒント・ルール表」がリフレッシュされ、選択したヒント・ルールが削除されます。
「問合せコンバータ」ページにアクセスするには、「管理」→「Oracle Query Optimizer」→「問合せコンバータ」を選択します。「問合せコンバータ」ページが表示されます。
問合せコンバータを使用する際には、次の作業が必要です。
データ・ソース問合せを変換するには、次のようにします。
該当する場合、「データ・ソースの使用」を選択します。
「問合せコンバータ」ページにデータ・ソース関連のフィールドが表示されます。
「DS名」メニューから希望するデータ・ソースを選択します。
「DS名」フィールドの下にデータ・ソース問合せが表示されます。
追加のパラメータおよびWHERE句の適切な情報を入力します。
「問合せの変換」をクリックします。
データ・ソースが変換され、結果が「データ・ソースの使用」チェックボックスの上のテキスト領域に表示されます。変換されたデータ・ソース問合せの例は、図4-4を参照してください。
問合せを変換するには、次のようにします。
該当する場合は、「データ・ソースの使用」を選択解除します。
「問合せコンバータ」ページのデータ・ソース関連のフィールドが非表示になります。
問合せの適切な情報を入力します。
「問合せの変換」をクリックします。
問合せが変換され、結果が「データ・ソースの使用」チェックボックスの上のテキスト領域に表示されます。変換済問合せの例は、図4-5を参照してください。
データ・ソースまたは問合せが変換されると、「データ・ソースの使用」チェックボックスの上に結果が表示されます。変換プロセスによりフィールドがクリアされるため、変換済問合せはフィールドに新しい情報を入力しないと変更できません。データ・ソースまたは問合せの情報を編集するには、4.2.5.12.1項「データ・ソースの変換」で該当する項を参照してください。
ヒント・キャッシュを更新する際には、次の作業が必要です。
「ヒント・キャッシュ更新機能」ページにアクセスするには、「管理」→「Oracle Query Optimizer」→「ヒント・キャッシュ更新機能」を選択します。
データ・ソースを使用してヒント・キャッシュをチェックするには、次のようにします。
「ヒント・キャッシュ更新機能」ページで、「データ・ソースの使用」を選択します。
「ヒント・キャッシュ更新機能」ページにデータ・ソース関連のフィールドが表示されます。
「DS名」メニューから希望するデータ・ソースを選択します。
「DS名」フィールドの下にデータ・ソース問合せが表示されます。
追加のパラメータ、WHERE句およびヒントの適切な情報を入力します。
「キャッシュのチェック」をクリックします。
「データ・ソースの使用」チェックボックスの上に結果が表示されます。失敗したヒント検索の例は、図4-6を参照してください。
問合せを使用してヒント・キャッシュをチェックするには、次のようにします。
データ・ソースを使用してヒント・キャッシュ問合せを変更するには、次のようにします。
「ヒント・キャッシュ更新機能」ページで、「データ・ソースの使用」を選択します。
「ヒント・キャッシュ更新機能」ページにデータ・ソース関連のフィールドが表示されます。
「DS名」メニューから希望するデータ・ソースを選択します。
「DS名」フィールドの下にデータ・ソース問合せが表示されます。
追加のパラメータ、WHERE句およびヒントの適切な情報を入力します。
「キャッシュの更新」をクリックして、前のヒント・キャッシュを上書きします。
「データ・ソースの使用」チェックボックスの上にあるテキスト・ボックスに結果が表示されます。問合せへの新規ヒントの追加とヒント・キャッシュの更新に成功した例は、この項にあるスクリーン・キャプチャを参照してください。
問合せを使用してヒント・キャッシュを変更するには、次のようにします。
「ヒント・キャッシュ更新機能」ページで、「データ・ソースの使用」チェックボックスが選択解除になっていることを確認します。
「問合せコンバータ」ページのデータ・ソース関連のフィールドが非表示になります。
適切な情報を入力します。
「キャッシュの更新」をクリックして、前のヒント・キャッシュを上書きします。
「データ・ソースの使用」チェックボックスの上に結果が表示されます。スクリーン・キャプチャでは、新規のヒントが追加され、ヒント・キャッシュが更新されていることに注意してください。
ヒント・キャッシュ・データ・ソース・エントリを削除するには、次のようにします。
「ヒント・キャッシュ更新機能」ページで、「データ・ソースの使用」を選択します。
「ヒント・キャッシュ更新機能」ページにデータ・ソース関連のフィールドが表示されます。
「DS名」メニューから希望するデータ・ソースを選択します。
データ・ソース問合せは、「DS名」フィールドの下に表示されます。
追加のパラメータ、WHERE句およびヒントの適切な情報を入力します。
「削除」をクリックします。
フィールドに入力された情報が削除されます。問合せからの削除に成功したヒントとヒント・キャッシュの例は、この項のスクリーン・キャプチャを参照してください。
ヒント・キャッシュ問合せを削除するには、次のようにします。
「ヒント・キャッシュ更新機能」ページで、「データ・ソースの使用」チェックボックスが選択解除になっていることを確認します。
「問合せコンバータ」ページのデータ・ソース関連のフィールドが非表示になります。
問合せおよびヒントの適切な情報を入力します。
「削除」をクリックします。
「データ・ソースの使用」チェックボックスの上に結果が表示されます。スクリーン・キャプチャでは、以前に追加されたヒントが、問合せおよびヒント・キャッシュから削除されたことに注意してください。
この項で説明する項目は、次のとおりです。
バージョン11gリリース1の発売により、Oracle Content Serverシステムでは、コンテンツの格納および編成用の従来のファイル・システムにかわり、データ管理用のファイル・ストア・システムが実装されました。FileStoreProviderコンポーネントは、Oracle Content Serverインタフェースでファイル・ストア機能を果たし、追加の構成オプションが可能です。たとえば、Oracle Content Serverインスタンスを、ファイル・システムを使用するかわりに、バイナリ・ラージ・オブジェクト(BLOB)データ型を使用して、コンテンツをデータベースに格納するように構成できます。この機能にはいくつかの利点があります。
一貫したバックアップおよび監視プロセスのために、リポジトリ管理をデータベース管理と統合します。
ファイル・システムの方法での、ディレクトリ構造とディレクトリ当たりのファイル数に関連した制限を克服するのに役立ちます。
システム間でのコンテンツの配布をより簡単にする上で役立ち、Oracle Content Serverシステムの拡大縮小が容易になります。
たとえば、コンテンツ・アドレス・ストレージ・システムや、一部のビジネス用に必要な書込み専用デバイスなど、一般にファイル・システムとは関連付けられていない様々なタイプのストレージ・デバイスが使用できます。
|
注意: FileStoreProviderコンポーネントは、Oracle Content Serverのデプロイ時にデフォルトでインストール、有効化およびアップグレードされます。デフォルトのファイル・ストアがアップグレードされた後で、アンインストールまたは無効化を実行しないでください。詳細は、4.3.2項「FileStoreProviderのアップグレード」を参照してください。Oracle Content Serverソフトウェアの旧バージョンを使用していて、デフォルトのファイル・ストアをまだアップグレードしていない場合、6.3.3.3項「コンポーネントの有効化と無効化」にある手順に従い、そのコンポーネントを無効にできます。 |
この項の内容は次のとおりです。
Oracle Content Serverシステムでは、電子ファイルおよびそれらの関連メタデータのストレージを追跡することにより、コンテンツを管理します。その結果、ユーザーはチェックイン・ファイル、すべての関連情報および関連レンディションの格納とアクセスが可能です。この項では、これまでOracle Content Serverシステムで使用されてきたデータ管理方法と、FileStoreProviderコンポーネントでそれらにどのように対処するかについて説明します。
データ管理の前半は、Oracle Content Serverリポジトリにチェックインした電子ファイルの格納です。Oracle Content Serverシステムでは、通常、ファイル保存は従来のファイル・システムによって行われ、電子ファイルは、ボールト・ディレクトリおよびWebレイアウト・ディレクトリを含む階層型ディレクトリ構造に格納されます。コンテンツ・タイプ、セキュリティ・グループおよびアカウント(使用されている場合)によって指定されたリビジョン情報を使用して、ファイルおよびそれらの関連レンディションが、ボールト・ディレクトリおよびWebレイアウト・ディレクトリ内の特定のディレクトリに格納されます。たとえば、チェックイン時に指定したプライマリ・ファイルと代替ファイルは、ボールト・ディレクトリのサブディレクトリに格納されます。特定のファイルの場所は、次のように定義します。
IntradocDir/vault/dDocType/account/dID.dExtension
このパス名で、dDocTypeはチェックイン時にユーザーが選択したコンテンツ・タイプ、dIDはこのリビジョンを識別するシステムで生成された一意のID、dExtensionはチェックインされたファイルの拡張子です。この階層モデルでは、dDocTypeメタデータ・フィールドを使用して、ボールト・ディレクトリ内に構築された階層内でファイルが配布されます。同様に、すべてのWebレンディションは、IntradocDir/weblayout/groupsディレクトリ内の階層全体で配布されます。Webレンディションとは、Webサーバーから供給されたファイルで、従来のファイル・システムの保存方法では、ネイティブ・ファイル、代替ファイル、またはInbound Refineryやその他の変換アプリケーションによって生成されたWeb表示可能ファイルでした。
この簡単なファイルの保存場所の決定は、コンポーネントおよび機能作成者にとっては便利で、ファイルの保存場所やそれらの操作方法を理解するのに役立ちます。ただし、ストレージ管理を制限する影響もあります。位置メタデータの管理を慎重に行わないと、ディレクトリが飽和状態になって、システムの処理速度低下の原因になる可能性があります。
データ管理の後半は、電子ファイルに関連付けられたメタデータの格納です。Oracle Content Serverシステムでは、メタデータ管理は通常、主として3つのデータベース表を含むリレーショナル・データベースを使用して行われてきました。メタデータは、ユーザーによるコンテンツのカタログ作成を可能にし、Oracle Content Serverリポジトリ内でファイルを見つけやすくするファイル記述子作成の手段にもなります。ユーザーにとって、取得はOracle Content Serverシステムによって行われ、ファイルの格納方法や場所は完全に非表示にできます。ファイルの生成または操作が必要になる可能性のあるコンポーネントおよび機能作成者にとっては、メタデータはアクセスの強力な手段となります。
Oracle Content Serverシステムでこれまで使用されてきた従来のファイル・システム・モデルは、拡張性に限りがあります。データ管理の必要が増えるにつれて、記憶領域を増やすために記憶装置を追加すると、Webベースのインタフェースを通して簡単にファイルを共有しにくくなります。ネストされて複雑になったファイル構造は、パフォーマンスを低下させる可能性があります。ネイティブ・ファイル・フォーマットが使用される可能性のある場合、重複するWeb表示可能ファイルの作成を抑制することは難しくなります。たとえばコンテンツ・アイテムが1000万を超えるような大規模システムに対応するため、Oracle Content Serverシステムでは、ファイル・ストアを使用するようになりました。これは、拡張性、柔軟性および管理容易性に効果を発揮します。
FileStoreProviderコンポーネントを使用すれば、Oracle Content Serverシステムによって管理されるコンテンツの格納およびアクセスに、データ駆動型のルールを定義できます。FileStoreProviderには、次の機能があります。
ファイルの場所を簡単に移動する機能。
Web表示可能ファイルをオプションにする機能。
ディレクトリの飽和状態を管理および制御する機能。
サードパーティの記憶装置を統合する機能。
様々なストレージの例を使用、拡張および強化するAPI。
FileStoreProviderにより、チェックインされたコンテンツおよび関連のメタデータは検査され、システム管理者によって設定された基準に基づきストレージ・ルールが割り当てられます。基準としてはメタデータ、プロファイルまたはその他の考慮事項が含まれます。ストレージ・ルールは、ボールト・ファイルおよびWebファイルをOracle Content Serverシステムで格納する方法、およびWebサーバーによりアクセスする方法を決定します。
新規のOracle Content Serverインスタンス(ドキュメントなし)の場合、FileStoreProviderコンポーネントはデフォルトでインストール、有効化およびアップグレードが行われます。アップグレードでは、ファイル・ストア・システム(DefaultFileStore)用のデフォルト値の入ったメタデータ・フィールドが作成されます。Oracle Content Serverソフトウェアの旧バージョンでは、ファイル・ストア・システムが自動的にアップグレードされず、サイトではファイル・ストア・システムを使用しないこと、FileStoreProviderを使用するためにアップグレードしないこと、FileStoreProviderコンポーネントおよびメタデータ・フィールドをアンインストールすることを選択できました。
現在の設定からFileStoreProviderをアップグレードしない場合は、インストールの前に、構成変数FsAutoConfigure=falseを、Oracle Content Serverの「管理サーバー」ページの「一般構成」ページにある「追加の構成変数」フィールドに入力する必要があります。
ドキュメントが含まれておらず、FileStoreProviderコンポーネントが自動的にアップグレードされているOracle Content Serverシステムでは、次のDefaultFileStore設定を使用します。
ボールト・パス:
$#env.VaultDir$$dDocType$/$dDocAccount$/$dispersion$/$dID$$ExtensionSeparator$ $dExtension$
分散ルール:
$dRevClassID[-9:-6:0:b]/$dRevClassID[-6:-3:0:b]
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コンポーネントのアップグレードがないOracle Content Serverシステムでは、Revisions表が空ではないため、デフォルトのストレージ・ルールの分散がDefaultFileStoreに設定されていないという情報メッセージが返されます。
ファイル・ストア・システムを使用せずに、旧バージョンのOracle Content Serverシステムを使用し、FileStoreProviderコンポーネントをアップグレードして実装しているサイトの場合、またはFileStoreProviderコンポーネントを完全にアンインストールし、FileStoreProviderにより追加されたメタデータ・フィールドも削除したサイトの場合、ユーザーがドキュメントをチェックインしたとき、そのサイトには関連のストレージ・ルールがない(xStorageRuleフィールドがない)ことになります。このような状況の後でFileStoreProviderが実装された場合、ユーザーは、FileStoreProviderの実装前にチェックインしたドキュメントのxStorageRuleフィールドが空であることに気づきます。この状況を解消するには、ユーザーはそれらのドキュメントのコンテンツ情報を更新する必要があります。ドキュメントはxStorageRuleフィールドのデフォルト値に更新され、ストレージ・ルールで指定されている場所に移されます。xStorageRuleの詳細は、4.3.3.1.2項「Oracle Content Serverのメタデータ・フィールド」を参照してください。
Oracle Content Serverシステムでは、コンテンツの格納および編成用の従来のファイル・システムのかわりに、データ管理用のファイル・ストアが使用されます。FileStoreProviderコンポーネントは、Oracle Content Serverのデプロイ時にデフォルトでインストールされ、有効化されます。FileStoreProviderコンポーネントでは、自動的にデフォルトのファイル・ストア(DefaultFileStore)をアップグレードし、Web、ボールトおよびWeb URLパス式の変更など、コンポーネントで公開される機能を利用できるようにします。
|
注意: Oracle Content Serverシステムの実行にはパーティションは必要ありませんが、パーティションの作成前にコンテンツをチェックインしようとすると、ボールト・パス・ルートの変更や、新しい適格なストレージ・ルールの作成に失敗します。詳細は、ストレージ・ルールおよびパス構成に関する項を含む、4.3.3.3項「FileStoreProviderストレージの原則」を参照してください。 |
|
注意: Oracle WebLogic Serverでは、作成されるパーティションごとに、Webレイアウト・ディレクトリを指す新しい仮想ディレクトおよびエイリアスを追加するように、Oracle Content Serverインスタンス用のWebサーバーは構成されません。パーティションは、ボールト・ファイルに使用でき、Webファイル用にサポートされます。 |
|
注意: リソース・ファイルは直接編集しないでください。リソース・ファイルの適切な変更は、Oracle Content Serverユーザー・インタフェース内で行うか、または追加のコンポーネント開発により行う必要があります。コンポーネント開発の詳細は、第6章「コンポーネントの管理」を参照してください。 |
ファイル・パスの定義および処理には、3つのリソース表が使用されます。PathMetaData表およびPathConstruction表のデフォルト値で、ほとんどのシナリオに対応できます。StorageRules表には、ストレージ・ルールの定義時に指定する値が格納されます。これら3つの表はプロバイダ固有で、そのことはdefaultfilestoreディレクトリのprovider.hdaファイルで定義されています。defaultfilestoreディレクトリは、IntradocDir/data/providersディレクトリにあります。4番目の表FileSystemFileStoreAlgorithmFilters表の変更には、Javaコードとともにコンポーネントが必要です。
この項の内容は次のとおりです。
FileStoreProviderコンポーネントは、Oracle Content Serverデータベース、Oracle Content Serverメタデータ・フィールドおよびその他の構成ファイルに対して、いくつかの変更を加え、考えられる構成オプションを可能にします。
この項の内容は次のとおりです。
場合によっては、データベースに格納されたコンテンツを、ファイル・システム上に強制的に置くことが必要になります。その1例が、Oracle Inbound Refineryで、変換のためにファイルへのアクセス権が必要な場合です。ファイル・システム上に強制的に置かれたファイルは、一時キャッシュとみなされます。次の構成値は、一時的にキャッシュされたファイルをクリーンアップする時期を制御するために使用されます。システムでクリーンアップされるのは、FileCache表にエントリのあるファイルのみです。
FileStoreProviderによりいくつかのOracle Content Serverメタデータ・フィールドが追加され、構成ファイルで使用する追加のオプションが利用できるようになります。
この項の内容は次のとおりです。
メタデータ・フィールドの構成
FileStoreProviderにより、Oracle Content Serverインスタンスに3つのメタデータ・フィールドが追加されます。
xPartitionId: このメタデータ・フィールドは、PartitionList表とともに使用され、コンテンツ・ファイル・アイテムのrootの位置を決定します。パーティション選択アルゴリズムで値が指定されるため、このフィールドはユーザー・インタフェースで非表示にすることをお薦めします。
xWebFlag: このメタデータ・フィールドでは、コンテンツ・アイテムにWeb表示可能ファイルがあるかどうかを判断します。したがって、システムのコンテンツ・アイテムにボールト・ファイルしかない場合、このメタデータ・フィールドを削除すると、システムではWeb表示可能ファイルがあるものと予想し、システムに悪影響が生じる可能性があります。メタデータ・フィールドは、構成値WebFlagColumnによって指定できます。
xStorageRule: このメタデータ・フィールドでは、ファイルをどのように格納するかを指定します。メタデータ・フィールドは、構成値StorageRuleFieldで指定できます。
|
注意: これらのメタデータ・フィールドは、起動時にFileStoreProviderによって追加され、削除されている場合は、Oracle Content Serverインスタンスが再起動したときに再び追加されます。メタデータ・フィールドを永久に削除する必要がある場合、intradoc.cfgファイルにある構成変数FsAddExtraMetaFields=falseを設定して、フィールドの自動作成を無効にします。intradoc.cfgファイルは、DomainHome/ucm/cs/binディレクトリにあります。 |
StorageDirパラメータは、PartitionRoot列値が指定されていないすべてのパーティションに使用されるルート・ディレクトリと同等のものとして設定できます。この場合、ストレージ・ディレクトリおよびパーティション名がPartitionRootパラメータの作成に使用されます。StorageDirパラメータは、 DomainHome/ucm/cs/binディレクトリにあるintradoc.cfgファイルで設定されます。
標準のFileStoreProvider変数
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
FileStoreProviderデフォルト・ファイル・ストアがアップグレードされると、チェックインされたコンテンツおよび関連のメタデータは検査され、システム管理者によって設定された基準に基づきストレージ・ルールが割り当てられます。基準としてはメタデータ、プロファイルまたはその他の考慮事項が含まれます。ストレージ・ルールは、ボールト・ファイルおよびWebファイルをOracle Content Serverソフトウェアで格納およびアクセスする方法、およびWebサーバーによりアクセスする方法を決定します。ファイルは、データベースに格納することも、1つ以上のファイル・システムまたは記憶媒体に格納することもできます。パーティションは、格納場所の管理に役立てるために作成できますが、必須ではありません。
|
注意: FileStoreProviderコンポーネントは、いったんOracle Content Serverシステムで使用されると、無効にすることはできません。 |
この項の内容は次のとおりです。
パーティションを作成すると、Oracle Content Serverシステムにより管理されるファイルへの追加のルート・パスを定義できますが、異なる場所や、異なるタイプの媒体への格納が必要です。パーティションは、パーティション・リスト・ページを使用して作成します。新規パーティションが作成されると、Oracle Content Serverシステムにより、IntradocDir/data/filestore/config/ディレクトリにあるfsconfig.hdaファイルでPartitionListリソース表が変更されます。
|
注意: Oracle WebLogic Serverでは、作成されるパーティションごとに、Webレイアウト・ディレクトリを指す新しい仮想ディレクトおよびエイリアスを追加するように、Oracle Content Serverインスタンス用のWebサーバーは構成されません。パーティションは、ボールト・ファイルに使用でき、Webファイル用にサポートされます。 |
Oracle Content Serverインスタンスにパーティションを追加するには、次の手順を実行します。
Oracle Content Serverインスタンスにシステム管理者としてログインします。
「管理」トレイを開き、「ファイル・ストアの管理」を選択します。
パーティションが定義されていない場合、「パーティションの追加」をクリックします。それ以外の場合は、「パーティションの追加/編集」ページが表示されます。
パーティション名を入力します。名前を一意にする必要があります。
パーティション・ルート、重複メソッドおよびその他の関連パラメータを変更します。詳細は、「パーティションの追加/編集」ページを参照してください。
「アクティブ」が有効であることを確認します。
「更新」をクリックします。パーティション・リスト・ページが表示されます。
FileStoreProviderはいつでも編集できます。プロバイダを編集するには、次の手順を実行します。
Oracle Content Serverインスタンスにシステム管理者としてログインします。
「管理」トレイを開き、「プロバイダ」を選択します。「プロバイダ」ページが表示されます。
DefaultFileStoreプロバイダの隣にある「アクション」列の「情報」をクリックします。「ファイル・ストア・プロバイダ情報」ページが表示されます。
「編集」をクリックします。 「ファイル・ストア・プロバイダの編集」ページが表示されます。
必要な変更を加え、「更新」をクリックして、変更を送信します。「プロバイダ」ページが表示されます。
|
注意: 「更新」をクリックして変更を送信する前に、「ファイル・ストア・プロバイダの編集」ページから離れないでください。 |
Oracle Content Serverインスタンスを再起動します。
|
重要: ストレージ・ルールは削除できません。各ストレージ・ルールについては、作成する前に慎重に検討してください。 |
|
注意: コンテンツがOracle Content Serverリポジトリにチェックインされた後でストレージ・ルールを変更すると、Oracle Content Serverシステムでコンテンツを見失うことになる可能性があります。 |
ストレージ・ルールを追加または編集するには、次のようにします。
Oracle Content Serverインスタンスにシステム管理者としてログインします。
「管理」トレイを開き、「プロバイダ」を選択します。「プロバイダ」ページが表示されます。
DefaultFileStoreプロバイダの隣にある「アクション」列の「情報」をクリックします。「ファイル・ストア・プロバイダ情報」ページが表示されます。
「編集」をクリックします。 「ファイル・ストア・プロバイダの編集」ページが表示されます。
「新規ルールの追加」をクリックするか、ストレージ選択リストから編集するルール名を選択し、「ルールの編集」をクリックします。「ストレージ・ルール名」ダイアログが表示されます。
ストレージ・ルールに必要な変更を加え、「OK」をクリックします。 「ファイル・ストア・プロバイダの編集」ページが表示されます。
|
注意: 編集中のストレージ・ルールに関連付けられたレコードがある場合、FsWeblayoutDir(Webレイアウト・ディレクトリ)およびFsHttpWebRoot(HttpWebRootおよびURL接頭辞)の2つのルールは変更できません。 |
「更新」をクリックします。「プロバイダ」ページが表示されます。
|
重要: ストレージ・ルール内で定義されているWeb URLファイル・パスで使用されるWebルートが、Oracle Content Serverシステムに定義されているデフォルトのWebレイアウト・ディレクトリ以外にある場合は、ストレージ・ルールで使用されているWebルートのWebサーバーにエイリアスまたは仮想ディレクトリを追加する必要があります。そうしないと、Oracle Content Serverシステムによりファイルへのアクセス場所が認識されません。仮想ディレクトリをWebサーバーに追加する手順の詳細は、Webサーバーに付属のドキュメントを参照してください。 |
コンテンツ・アイテムがOracle Content Serverシステムにチェックインされるとき、アイテムはメタデータ、ユーザーが選択したプライマリ・ファイルと、場合によっては代替ファイルで構成されています。代替ファイルは、ユーザーによって選択され、チェックインされる場合もあり、Web表示可能ファイルとみなされます。Oracle Content Serverシステムへのファイル・システムによるアプローチでは、プライマリ・ファイルはDomainHomeディレクトリのルートにあるボールト・ディレクトリに格納され、ネイティブ・ファイルと呼ばれます。代替ファイルがチェックインされると、これもボールトに格納されますが、Webレイアウト・ディレクトリにコピーされるか、変換アプリケーション(Oracle Inbound Refineryなど)に渡されます。代替ファイルがチェックインされない場合は、ボールト・ディレクトリから2箇所に存在するWebレイアウト・ディレクトリへネイティブ・ファイルがコピーされます。代替ファイルがチェックインされず、Oracle Inbound Refineryがインストールされている場合、ネイティブ・ファイルのレンディションが作成され、Webレイアウト・ディレクトリに格納されます。
Oracle Content Serverシステムへのファイル・システムによるアプローチでは、指定したディレクトリにコンテンツを格納することで、コンテンツへのパスが定義されます。コンテンツが特定の場所にあることを知っている場合は、静的Web URLファイル・パスを使用してブラウザからコンテンツにアクセスでき、場所がわからない場合は、GET_FILEなどの動的なOracle Content Serverサービス・リクエストを使用してアクセスします。FileStoreProviderでは、コンテンツがファイル・システムに格納されることも、されないこともあります。したがって、新しい方法でコンテンツへのパスを定義する必要があります。
FileStoreProviderの設定の仕方によっては、静的Web URLがある場合も、ない場合もあります。具体的な場所がわからない場合は、動的なOracle Content Serverサービス・リクエストを使用することで、コンテンツにアクセスできます。FileStoreProviderを使用すると、静的Web URLがWeb URLファイルとして定義され、動的アクセスは単にWeb URLと呼ばれます。FileStoreProviderユーザー・インタフェースを使用すると、静的Web URLファイル・パスしか構成できません。ただし、静的Web URLを、Oracle Content Serverサービス・リクエストとして実行し、本質的に動的にすることを決定できます。
この項の内容は次のとおりです。
コンテンツがチェックインされると、Oracle Content Serverシステムで管理されるそのコンテンツのすべてのバージョンは、レンディションとみなされます。これらのレンディションには、ネイティブ・ファイル、Web表示可能ファイル、およびInbound Refineryやサードパーティの変換アプリケーションによりレンダリングされた可能性のあるその他のファイルが含まれます。
複数のレンディションは1つのストレージ・クラスにまとめられ、これによりレンディションにアクセスする場所と方法が決まります。複数のストレージ・クラスは1つのストレージ・ルールにまとめられ、これにより1つのストレージ・クラスを経由するボールト、WebおよびWeb URLのパス式が定義されます。さらに、ストレージ・ルールにより、レンディションを、Webレス・ファイル・ストアと同様に格納しないかどうか、またはファイル・システムではなくデータベースなどの別のデバイスに格納するかどうかを決めます。
次の例では、ストレージ・ルールで、様々なコンテンツ・アイテムの格納場所や格納方法をどのように指定できるかを説明しています。
例1
ストレージ・ルールは、 「ストレージ・ルール名」ダイアログで「ファイル・システムのみ」として定義され、「Web表示非対応のファイル・ストア」が選択されます。ここでは、システムによりプライマリ・ファイルのコピーが作成され、Webレイアウト・ディレクトリに置かれます。
この従来のファイル・システム・ストレージの例では、通常、データベース・ストレージと比較すると、コンテンツへのアクセス時間が速くなる利点があります。ファイル・システムの階層が複雑だったり、飽和状態になったりした場合、あるいはコンテンツ・アイテムの量が増えるにつれて、この利点は少なくなります。
例2
ストレージ・ルールは、 「ストレージ・ルール名」ダイアログで「ファイル・システムのみ」として定義され、「Web表示非対応のファイル・ストア」が選択されます。ここでは、プライマリ・ファイルのコピーは作成されないため、ネイティブ・ファイルはレンディションのみです。Web表示可能ファイルに対するリクエストは、ボールトに格納されているネイティブ・ファイルに送られます。
|
注意: FileStoreProviderのWebレス・オプションにより、Webレンディションが作成されないように指定できます。これをInbound Refineryとともに使用すると、Webレンディションが常に作成され、有効なストレージ・ルールに応じて、ファイル・システムまたはデータベースのいずれかに格納されます。 |
この従来のファイル・システム・ストレージの例では、前の例と同様に、コンテンツへのアクセス時間が速くなる利点があります。また、コンテンツのバージョンをボールト・ディレクトリからWebレイアウト・ディレクトリにコピーしないことで、記憶領域の節約にもなります。かわりに、Web表示可能のアクセスはボールト・ディレクトリのコンテンツにリダイレクトされます。これは、チェックインされた大部分のネイティブ・ファイルがWeb表示可能フォーマットの場合、またはOracle Content Serverシステムがブラウザで表示する必要のないコンテンツの管理に使用されている場合に役立ちます。
例3
ストレージ・ルールは、 「ストレージ・ルール名」ダイアログで「JDBCストレージ」として定義され、「レンディション」選択リストからは選択されません。ここでは、ボールト・ファイルとWebファイルの両方がデータベースに格納されます。
このデータベース記憶域の例では、一貫したバックアップおよびプロセス監視のために、リポジトリ管理とデータベース管理を統合するという利点を提供し、ファイル・システムでのディレクトリ構造やディレクトリ当たりのファイル数に関連した制限の克服に役立ちます。
|
重要: 必要な場合、たとえば索引付けや変換の間、データベースに格納されたコンテンツ・アイテムを強制的にファイル・システムに置くことができます。ファイル・システム上のファイルは、一時キャッシュとして扱われ、IntradocDir/configディレクトリにあるconfig.cfgファイルで指定されているパラメータに続いて削除されます。使用されるパラメータの詳細は、4.3.4.7項「FileCache表」を参照してください。 |
例4
ストレージ・ルールは、「ストレージ・ルール名」ダイアログで「JDBCストレージ」として定義され、「レンディション」選択リストから「Webファイル」が選択されます。ここでは、ボールト・ファイルはデータベースに格納され、Webファイルはファイル・システムに永久的に格納されます。
ネイティブ・ファイルはデータベースに、Web表示可能ファイルはファイル・システムに格納するというこの混成アプローチには、前例のネイティブ・ファイルのデータベース記憶域(バックアップと監視を統合し、ファイル・システムの制限を克服)という利点があり、一方でWeb表示可能レンディションへの迅速なWebアクセスを実現します。最初の例と同様に、ファイル・システム構造が複雑すぎる場合や、ファイルの量が極端に多い場合には、この利点は少なくなる可能性があります。
Oracle Content Serverシステムに格納されているコンテンツへのパスは、PathConstruction表のPathExpression列で定義されています。パスは複数の要素で構成され、各要素はスラッシュ(/)で区切られています。各要素は、1つの静的文字列または一連の動的部分でできています。動的部分は、ドル記号($)で囲まれています。1つの部分は、アルゴリズム、Idoc Scrip変数、環境変数、またはメタデータ参照を使用して計算でき、次のような解釈が考えられます。
PathMetaData表で定義されたフィールドである可能性があります。PathMetaData表で定義されている場合、1つのアルゴリズム(たとえば、$dDocType$)にマップできます。
接頭辞#env.が付いている場合、これは環境変数(たとえば、$#env.VaultDir$または$#env.WeblayoutDir$)です。
Idocスクリプト変数(たとえば、$HttpWebRoot$)である可能性があります。
たとえば、標準的なボールトの場所は、次のように定義されます。
$PartitionRoot$/vault/$dDocType$/$dDocAccount$/$dID$$ExtensionSeparator$$dExtension$
解析すると、パス式は5つの要素になり、PathMetaData表で指定されているルールに従い、次のように解釈されます。
$PartitionRoot$: partitionSelectionアルゴリズムにマップされ、パーティション・ルートを確認するために、xPartitionIdをPartitionList表への参照として使用します。
/vault/: 文字列であるため、計算や代入はありません。
$dDocType$: PathMetaData表では、これはファイル・パラメータでの参照です。
$dDocAccount$: これは、dDocAccountを取り込み、すべての適切なデリミタを使用して、標準のOracle Content Serverアカウント表現に解析する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セパレータはOracle Content Serverシステムに対して、後続のディレクトリが、コンテンツ・アイテムの属するセキュリティ・グループおよびアカウントの名前であることを示します。アカウントはオプションで、その結果、アルゴリズムによって計算されます。セキュリティ情報の後はdocumentsセパレータで、その直後にはdDocTypeが続きます。分散はオプションです。URLの最後の部分は、dDocName、そのレンディションおよびリビジョン情報、フォーマットの拡張子です。
URLはこのフォーマットになると予想されるため、Oracle Content Serverシステムは、ここからメタデータを正常に抽出できます。さらに重要なことは、これによりコンテンツ・アイテムのセキュリティ情報を指定でき、特定のユーザーのアクセス権限を導出できることです。
解析のガイドラインは、Webディレクトリ内の分散を可能にするために拡張されました。$dRevClass$が出現したら、システムでは分散情報を処理してから、従来どおりdDocNameおよびdWebExtensionの処理を続けます。つまり、システムにより次のフォーマットのURLの解析がうまくできるようになりました。
../groups/$dSecurityGroup$/$dDocAccount$/documents/$dDocType$/$dispersion$/~edisp/$dDocName$$RenditionSpecifier$$RevisionLabel$$ExtensionSeparator$$dWebExtension$
この項の内容は次のとおりです。
PartitionList表では、partitionSelectionアルゴリズムに使用可能なパーティションが定義されています。表は、DomainHome/ucm/cs/data/filestore/config/ディレクトリにあるfsconfig.hdaファイルで定義されており、Oracle Content Serverユーザー・インタフェースの「パーティションの追加/編集」ページを使用して変更されます。表の列は、次のように使用されます。
StorageRules表では、コンテンツ・アイテムの格納に使用されるルールを定義します。ルールは、どのストレージ・クラスにどのパス式を使用するか、およびコンテンツ・アイテムをどのように格納するかを指定します。
表は、DomainHome/ucm/cs/data/providers/defaultfilestoreディレクトリにあるprovider.hdaファイルで定義されており、Oracle Content Serverユーザー・インタフェースの「ストレージ・ルール名」ダイアログを使用して変更できます。表の列は、次のように使用されます。
PathMetaData表では、ファイルの場所を決定するためにどのメタデータが使用されるかを定義します。メタデータは、コンテンツ・アイテムのメタデータから直接得たものか、またはアルゴリズムを使用して計算されます。PathMetaData表は、defaultfilestoreディレクトリのprovider.hdaファイルで定義されています。defaultfilestoreディレクトリは、DomainHome/ucm/cs/data/providers/ディレクトリにあります。
表の列は、次のように使用されます。
PathConstruction表では、ファイルをパスにマップします。PathConstruction表は、defaultfilestoreディレクトリのprovider.hdaファイルで定義されています。defaultfilestoreディレクトリは、DomainHome/ucm/cs/data/providers/ディレクトリにあります。詳細は、4.3.3.3.2項「パスの構成およびURLの解析」も参照してください。
|
注意: PathConstruction表で提供されているデフォルト値は、想定されるたいていの事態に機能します。このリソース・ファイルは直接編集しないでください。追加のコンポーネント開発により、適切な変更を行う必要があります。コンポーネント開発の詳細は、『Oracle Fusion Middleware Oracle Universal Content Management開発者ガイド』のコンポーネントに関する章を参照してください。 |
PathConstruction表の列は、次のように定義されています。
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表は、FileStoreProviderの一部で、変更するJavaコードとともにコンポーネントが必要です。
|
注意: FileSystemFileStoreAlgorithmFilters表で提供されているデフォルト値は、想定されるたいていの事態に機能します。このリソース・ファイルは直接編集しないでください。Javaコードと追加のコンポーネント開発により、適切な変更を行う必要があります。.コンポーネント開発の詳細は、『Oracle Fusion Middleware Oracle Universal Content Management開発者ガイド』を参照してください。 |
FileStoreProviderがインストールされると、FileStorage表がOracle Content Serverシステムに追加されます。これは、コンテンツがデータベースに格納される場合に、JdbcStorageストレージ・タイプによって排他的に使用されます。FileStorage表には、コンテンツ・アイテムのレンディションが含まれていて、どのレンディションがどのコンテンツ・アイテムに属しているかを一意に識別するために、コンテンツ・アイテムおよびレンディションのdIDが使用されます。
この項では、例ごとに、プロバイダ定義ファイル(provider.hda)に含まれている表のコンテンツを示します。provider.hdaファイルは、手動で編集する必要がありません。provider.hdaファイルの適切な変更は、「パーティションの追加/編集」ページを使用してOracle Content Serverユーザー・インタフェース内で行うか、または追加のコンポーネント開発により行う必要があります。その他のリソース表(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
FileStoreProviderは、標準的なOracle Content Serverの場所にあるファイル・システムに、コンテンツを格納するように構成できます。
まず最初にストレージ・ルールを定義します。この例では、すべてのコンテンツがファイル・システムに格納されるので、ストレージ・ルールはFileStorageタイプのものになります。
例:
@ResultSet StorageRules 4 StorageRule StorageType IsWeblessStore RenditionsOnFileSystem default FileStorage @end@
次に、ルールのストレージ・クラスごとに、パス構成を定義します。一般に、パスの最後の部分は、すべての使用例にとって標準的なものにする必要があります。そうでないと、Oracle Content Serverシステムでうまくhcs*ファイルを使用できません。ただし、Web URLファイル・パス・ルートの変更が、WebサーバーでOracle Content Server Webルートとして正しく認識されると仮定すれば、ルート・パスは機能に影響を与えることなく変更できます。
この構成では、ボールト、WebおよびWeb URLストレージ・クラスは、PathConstruction表で定義する必要があります。ボールトのパス式は、すでに4.3.3.3.2項「パスの構成およびURLの解析」で述べています。$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$
これは次のような部分に解析されます。
この例では、前の例のストレージ・ルールが、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ファイルはファイル・システムに格納するシステムの場合、非常に便利です。 |
次のdefaultルールでは、すべてのファイルがデータベースに格納されますが、filesInWebルールでは、ボールト・ファイルはデータベースに、Webファイルはファイル・システムに格納されます。
@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$/$dispersion$/$dID$$ExtensionSeparator$
$dExtension$
6
true
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$$RevisionLabel$$RenditionSpecifier$
$ExtensionSeparator$$dWebExtension$
3
true
default
@end
前述の例では、ファイル・パスを標準構成に合せています。非常に大きな実装の場合、これではディレクトリが飽和状態になり、パフォーマンスが低下する可能性があります。次の例は、複数の選択肢がある記憶域でファイルを分散させる際に役立ちます。
FileStoreProviderでは、よりすっきりしたディレクトリ構造を作成するために、パーティションを使用しやすくなります。デフォルトでは、xPartitionIdメタデータが使用され、コンテンツ・アイテム・リビジョンのメタデータ情報の一部になります。このフィールドをOracle Content Serverユーザー・インタフェースで無効にし、かわりにパーティション選択アルゴリズムで使用するパーティションを決めることをお薦めします。パーティション選択アルゴリズムでは、すべてのアクティブ・パーティションを調べ、新規のコンテンツがシステムに入ってくると、それらのパーティションが順番に選択されます。各パーティションは、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を「パーティションの追加/編集」ページで次のように定義します。
| パーティション名 | パーティション・ルート |
|---|---|
partition1 |
$#env.WeblayoutDir$/partition1/ |
partition2 |
$#env.WeblayoutDir$/partition2/ |
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の文字を埋め込みます。
Oracle Content Serverシステムでは、ビルトインのWebサーバーを持つOracle WebLogicサーバーを使用して、Webブラウザを通してページをフィルタ処理します。ユーザー・リクエストは、Oracle WebLogicサーバー・ユーザー・ストアにより認証され、Oracle Content Serverシステムと通信します。
WebUrlMapPluginコンポーネントを使用すると、短縮形のURLを、マッピング用の置換スクリプトを使用して、他のURLにg] でマップでき、これによって、長いURLを短縮形にマップすることもできます。WebUrlMapPluginコンポーネントは、デフォルトではOracle Content Serverインスタンスによりインストール(有効化)されます。
この項には、次の項目が含まれます。
作成できる短縮形のURLでは、一般に次のフォーマットを使用します。
http://myhostname.com/prefix/suffix
実際のマッピング・プロセスは、ホスト名の部分に続くURLの部分に基づきます。短縮形のURLを解決するため、Oracle Content Serverインスタンスでは、接頭辞を定義済のWebUrlMapPluginエントリのリストのものと比較します。一致するものがある場合、Oracle Content Serverインスタンスでは、一致する接頭辞に対応するマップ・スクリプトを使用して、該当するドキュメントまたはOracle Content Serverページを表示します。接尾辞の詳細は、4.4.2項「参照用にサポートされている変数」を参照してください。
「Web URLマップ」画面を使用してURLマッピング・エントリを構成するには、接頭辞を確定し、対応するマップを定義する必要があります。
接頭辞
マッピング・エントリの接頭辞の部分は、特定の形のURLを識別するために使用する任意の短縮形です。たとえば、短縮形のURLでドキュメントの動的変換が返されるようにする場合、idcを自分の接頭辞として使用できます(たとえば、dynamic converterの短縮形)。
Oracle Content Serverインスタンスでは、接頭辞テストの実行前に、受信したURLから最初のスラッシュが削除されるため、接頭辞を作成する際には、先頭にスラッシュ(/)文字を入力しないでください。
|
注意: URLマップの接頭辞の最後には、スラッシュ(/)を含めてください。そうしないと、マッピングが適用されるURLが増えて、標準的なOracle Content Serverの操作の妨げになる可能性があります。 |
マップ
マッピング・エントリのマップの部分は、Oracle Content Serverインスタンスで短縮形のURLを解決するために使用されるIdocスクリプト・コードです。マップの部分では、置換タグ(<!--$variable-->)を使用できます。たとえば、次のものがあります。
<!--$cgipath-->
<!--$internetuser-->
<!--$suffix-->
これらの置換タグは、URLの該当するパラメータを参照する変数です。
単純なif構造体もサポートされています。たとえば、次のスクリプト・セグメントは、値が存在し、空でないかどうかを確認するためのテストを実行します。
<!--$if myconfigvar-->something<!--$endif-->
URLマッピング・エントリのマップ部分では、参照用の次の標準変数が使用されます。
CGIパス
これは、Oracle WebLogic Server Webサーバー・フィルタの構成済Oracle Content Serverインスタンスの現在のCGIパスです。Webサーバー・フィルタは、このOracle Content Serverインスタンスのための通信とセキュリティの両方を提供するように構成されます。典型的な例は、/idcm1/idcplgです。
suffixパラメータ
接尾辞変数(<!--$suffix-->)の値は、URLで先行するマッピング接頭辞の後に続き、疑問符(?)の前にある部分から導出されます。接尾辞の先頭にあるスラッシュ(/)は、この変数に代入される前に削除されます。たとえば、次のURLでは、dcがマッピング接頭辞で、後に接尾辞が続きます。
http://myhostname.com/dc/mydocumentname
スラッシュを削除した後、mydocumentnameが、マッピング・エントリのマップ部分で置換タグとして使用される接尾辞変数の値として使用されます。また、接尾辞変数には、CGIパラメータは含まれません。したがって、次のURLでは、mydocumentnameがそのまま接尾辞変数の値として使用されています。
http://myhostname.com/dc/mydocumentname?a=1
接頭辞と接尾辞の間をスラッシュで強制的に区切るには、接頭辞の短縮形の最後にスラッシュを追加します。
任意のプラグイン変数
たとえば、現在ログインしているユーザーのユーザーIDと置換するために、構造体<!--$internetuser-->を使用できます。
任意のCGIパラメータ
URLマッピング・エントリを追加または編集するには、次のようにします。
「管理」トレイを選択し、「WebUrlMapPlugin」をクリックします。
「Web URLマップ」画面が表示されます。
「接頭辞」フィールドと「マップ」フィールドに適切な値を入力して、既存のマッピング・エントリを編集するか、新規のエントリを定義するか、またはその両方を行います。
「更新」をクリックします。
画面がリフレッシュされ、「接頭辞」フィールドと「マップ」フィールドの値が保存されます。表示されたすべてのフィールドに値が入っている場合、画面の再表示後に追加の「接頭辞」と「マップ」のフィールドのペアが2つ表示されます。
|
重要: WebUrlMapPlugin機能は、数百のマッピング・エントリをサポートするように設計されています。ただし、マッピング・エントリが数千に及ぶと、Webサーバーのパフォーマンスに影響が出るので注意してください。 |
既存のコンテンツ・アイテムに情報更新フォームを生成するために、短縮形のURLを作成できるようにするWeb URLマッピング・スクリプトを定義できます。ユーザーが特定のドキュメントに任意の識別変数を入力できるように、マッピング・スクリプトを作成できます。たとえば、次のフォーマットのURLがあるとします。
http://myhostname.com/u/mydoc_parameter
このURLは、次のURLにマップできます。
http://myhostname.com/idcm1//idcplg?IdcService=GET_UPDATE_FORM&dDocName=mydocumentname
URLをマップするには、「Web URLマップ」画面を使用して、次のWeb URLマップ・エントリを定義します。
接頭辞:
u/
マップ:
<!--$cgipath-->?IdcService=GET_UPDATE_FORM<!--$suffix-->&myparam=<!--$myparam-->
このURLマッピング例を機能させるには、Dynamic Converterをインストールする必要があります。
ドキュメントの様々な動的変換に短縮形のURLを作成できるようにするWeb URLマッピング・スクリプトを定義できます。たとえば、次のフォーマットのURLがあるとします。
http://myhostname.com/dc/mydocumentname
このURLは、次のURLにマップできます。
http://myhostname.com/idcm1/idcplg?IdcService=GET_DYNAMIC_CONVERSION&dDocName=mydocumentname&RevisionSelectionMethod=LatestReleased
URLをマップするには、「Web URLマップ」画面を使用して、次のWeb URLマップ・エントリを定義します。
接頭辞:
dc/
マップ:
<!--$cgipath-->?IdcService=GET_DYNAMIC_CONVERSION&dDocName=<!--$suffix-->&RevisionSelectionMethod=LatestReleased
CGIパラメータを直接参照することもできます。たとえば、次のフォーマットのURLがあるとします。
http://myhostname.com/dcp/mydocumentname?myparam=myvalue
このURLは、次のURLにマップできます。
http://myhostname.com/idcm1/idcplg?IdcService=GET_DYNAMIC_CONVERSION&dDocName=mydocumentname&RevisionSelectionMethod=LatestReleased&myparam=myvalue
URLをマップするには、「Web URLマップ」画面を使用して、次のWeb URLマップ・エントリを定義します。
接頭辞:
dcp/
マップ:
<!--$cgipath-->?IdcService=GET_DYNAMIC_CONVERSION&dDocName=<!--$suffix-->&RevisionSelectionMethod=LatestReleased&myparam=<!--$myparam-->
この項には、次の項目が含まれます。
プロバイダとは、Oracle Content Serverインスタンスと外部エンティティ間の接続を確立するアプリケーション・プログラミング・インタフェース(API)です。これらのエンティティは、次のものが考えられます。
Oracle WebLogic Server
LDAPサーバー
データベース
サーバー・ソケット
ファイル・ストア・システム
Inbound Refinery
デフォルトでは、Oracle Content Serverインスタンスには、3つのシステム・プロバイダがあります。
さらに、次のタイプのプロバイダを作成できます。
送信: 外部エンティティに対して開始された接続。このタイプを使用して、Oracle Content Serverインスタンス間の通信ができます。送信プロバイダでSSLを使用する場合は、4.5.1.3項「セキュリティ・プロバイダ」で詳細を参照してください。
データベース: 接続および通信用のAPIを提供する情報リポジトリ・サーバー。これは、情報を取得し、情報をデータベースで変更できるようにします。このタイプの例は、システム・データベースです。
受信: :ブラウザまたはクライアント・アプリケーションのような、外部エンティティから開始された接続。プロバイダは、受信接続を認識するために、指定されたポート上でリスニングを行います。受信プロバイダでSSLを使用する場合は、4.5.1.3項「セキュリティ・プロバイダ」で詳細を参照してください。
プレビュー: : Oracle Content Publisherへの出力プロバイダ接続で、オプションのHTML Preview機能とともに使用します。
LDAP: LDAP(ライトウェイト・ディレクトリ・アクセス・プロトコル)サーバーに対して開始される接続で、Oracle Content Serverインスタンスに対する外部ユーザー・アクセスを管理します。このタイプのプロバイダは、ActiveDirectoryLdapコンポーネントによってサポートされており、これはデフォルトではOracle Content Serverインストール時にインストール(無効化)されます。11g リリース1(11.1.1)以後、この機能はほとんどの場合(特にネストされたグループのサポートの場合)、JpsUserProviderがかわりに使用されています。
HTTP :HTTPプロトコルを使用して、Oracle Content Serverインスタンス間の通信を可能にする接続。このタイプのプロバイダには、Proxy Credentials Extensionコンポーネントが必要で、これはデフォルトではOracle Content Serverインストール時にインストール(有効化)されます。
JpsUserProvider: Oracle WebLogic Serverインスタンスに対する接続。このプロバイダでは、Java Platform Security (JPS)を使用して、Oracle WebLogic Serverインスタンスを介したユーザー認証、ユーザー認可、およびユーザー・メタデータの取得を実行します。このタイプのプロバイダは、JpsUserProviderコンポーネントによってサポートされており、これはデフォルトではOracle Content Serverインスタンスとともにインストール(有効化)されます。
前項で説明した様々なタイプのプロバイダは、特定の状況の下で、その他の各種Oracle製品およびユーティリティとともに使用するために追加されます。この後の各項では、それらの状況と、各状況で追加する必要のある特定のプロバイダのタイプについて説明します。
送信プロバイダは、Oracle Content Server ArchiverユーティリティおよびInbound Refineryを使用するために追加されます。送信プロバイダでSSLを使用するか、キープアライブにする場合、4.5.1.3項「セキュリティ・プロバイダ」の詳細を参照してください。
アーカイバ・ユーティリティ(Oracle Content Server): アーカイバは、核となるOracle Content Server製品内のユーティリティで、システム管理者がコンテンツをコピーおよび削除し、今後の使用のために格納できるようにします。ユーザーは、Oracle Content Serverインスタンスに一連のコンテンツを問い合せ、それをアーカイブにエクスポートできます。アーカイブはその他のOracle Content Serverインスタンスにインポートすることも、メタデータ・フィールドを変更した元のインスタンスにインポートすることもできます。
送信プロバイダは、ファイアウォールを越えて、あるいは1つのファイル・システムを共有していない2つのシステム間で、コンテンツをアーカイブするために使用されるアーカイバ転送機能を使用する際に必要です。転送機能、各種の転送および送信プロバイダの要件の詳細は、移行の管理に関する章を参照してください。
送信プロバイダおよび特定の各フィールドについての追加参照情報は、A.1.6.4項「送信ソケット・プロバイダ・ページ」を参照してください。
Inbound Refinery: Inbound Refineryサーバーでは、Oracle Content Serverにチェックインされたコンテンツを処理し、それを指定されたフォーマットに変換します。Inbound Refineryサーバーへの送信接続は、Oracle Content Serverとの通信に必要です。詳細は、Oracle Fusion Middleware Conversion管理者ガイドを参照してください。
データベース・プロバイダは、外部データベースを使用するために追加されます。
デフォルトのOracle Content Serverデータベースではないデータベースでデータベース問合せを実行する場合に、望ましい、または必要になることがしばしばあります。この場合、カスタマイズされたデータベース・プロバイダを作成して、データを処理しているデータベース管理システムに関係なく、任意のアプリケーションから任意のデータにアクセスできるようにすることが可能です。カスタマイズされたデータベース・プロバイダを使用して、外部データベースをOracle Content Serverシステムに統合すると、1つの検索画面で検索結果を結合して表示できます。さらに、これらの外部データベース・ソースからデータをインポートできます。
管理者は、次の2つの方法のいずれかで、データベース・プロバイダを作成できます。
Oracle WebLogic Serverの管理コンソールを使用して、データベースにOracle WebLogic Serverデータ・ソースを作成し、Oracle Content Serverデータベース・プロバイダでそのデータ・ソースが使用できるように構成します。詳細は、Oracle Fusion Middleware Oracle Application Development Framework開発者ガイドの「WebLogicドメイン・サーバー用JDBCデータ・ソースの作成」の章を参照してください。
Oracle Content Serverデータベース・プロバイダを作成して、Oracle WebLogic Serverデータ・ソースを使用せずに、JDBC接続を介してデータベースに直接接続します。このモードは、構成内に事前に接続が存在するインスタンス用に提供されています。
Oracle Content Serverデータベース・プロバイダと特定の各フィールドに関する追加の参考情報は、A.1.6.5項「データベース・プロバイダ・ページ」を参照してください。
受信プロバイダは、WebDAVサポートおよびOracle Content Serverアーカイバ・ユーティリティを使用するために追加されます。受信プロバイダでSSLを使用するか、キープ・アライブにする場合、4.5.1.3項「セキュリティ・プロバイダ」の詳細を参照してください。
Oracle WebDAVサポート: Oracle Content Serverのリリース6.2では、受信プロバイダとOracle Content Serverに統合されたTomcatサーブレット・エンジンを使用して、WebDAV (Webベース分散オーサリングおよびバージョニング)を実装できます。ただし、Oracle Content Serverリリース7.0以上では、WebDAVのサポートはカスタム機能によって提供されるため、プロバイダおよびサーブレット・エンジンは不要になりました。
詳細は、『Oracle Fusion Middleware Content Serverアプリケーション管理者ガイド』を参照してください。
アーカイバ・ユーティリティ(Oracle Content Server): アーカイバは、核となるOracle Content Server製品内のユーティリティで、システム管理者がコンテンツをコピーおよび削除し、今後の使用のために格納できるようにします。ユーザーは、Oracle Content Serverインスタンスに一連のコンテンツを問い合せ、それを別のインスタンスにエクスポート、インポートまたはレプリケートしたり、メタデータ・フィールドを変更したりできます。システム内で最も頻繁に実行されるタスクは、情報の転送、バックアップおよび再編成です。
一般に、データまたはコンテンツ・アイテムが1つのリポジトリから別のリポジトリに移されると、アーカイバ・ユーティリティではプッシュ・テクノロジを使用してファイルを移動します。ただし、システムではファイルのプッシュよりプルが必要になることがあります。この場合、受信プロバイダを作成する必要があります。受信プロバイダと特定の各フィールドに関する追加の参考情報は、A.1.6.6項「受信プロバイダ・ページ」を参照してください。
この操作を実行するには、コンサルティング・サービスが必要です。
プレビュー・プロバイダは、HTMLプレビューおよびContent Categorizerを使用するために追加されます。
HTMLプレビュー: HTMLプレビューは、公開Webサイトでユーザーのコンテンツがどのように表示されるのかのフィードバックを、即時にユーザーに提供する機能です。この機能によりユーザーは、コンテンツが実際にチェックインされる前に、元のコンテンツを変更できます。HTMLプレビューは、正しいメタデータがコンテンツに割り当てられていることをユーザーが確認するのにも役立ちます。プレビュー・プロバイダは、インストール・プロセス中に作成する必要があります。HTMLプレビューに関する追加の概要およびインストール情報は、『Oracle Fusion Middleware Content Serverアプリケーション管理者ガイド』を参照してください。
Content Categorizer: Content Categorizerでは、Oracle Content Serverにチェックインするドキュメントや、メタデータを再適用する必要がある既存のドキュメントに対して、メタデータ値を提案します。Content Categorizerでドキュメントの構造上のプロパティが認識されるには、ファイルをXMLに変換する必要があります。
必要なXML変換プロセス用のテンプレートを設定するためにコンテンツ・パブリッシャを使用する場合、HTMLプレビュー機能をプレビュー・プロバイダとして構成する必要があります。(HTMLプレビューは、ユーザーが自分のコンテンツをプレビューし、コンテンツ・パブリッシャからの変換済出力がどのように見えるかを確認できる機能です。)
Content Categorizerの詳細は、『Oracle Fusion Middleware Content Serverアプリケーション管理者ガイド』を参照してください。このマニュアルでは、必須またはオプションの追加製品の関連情報を提供しています。プレビュー・プロバイダと特定の各フィールドについての追加の参考情報は、A.1.6.7項「プレビュー・プロバイダ・ページ」を参照してください。
Lightweight Directory Access Protocol (LDAP)は、TCP/IPで実行されるディレクトリ・サービス・プロトコルです。これは、ネットワーク内のリソース管理の高度な機能性を提供し、Oracle Content Serverとともに使用して、セキュリティおよびユーザー認証を管理します。LDAPディレクトリ・サービス・モデルは、属性のコレクションに基づいており、情報ディレクトリに格納されている情報へのアクセスに使用されます。このように、LDAPは、ユーザー名およびパスワード資格証明のセットを認証ソースに照合して検証するために使用されます。このプロセスにより、ユーザーにはWebリソースにアクセスする権限が付与されます。
LDAPサーバーには、Oracle Content Serverやその他のOracle製品のモジュールなどのアプリケーションからアクセスできるユーザー関連情報のソースが1つあります。Oracle Content Serverインスタンス内でユーザー情報をメンテナンスするかわりに、ユーザー資格証明を認証するためのLDAPディレクトリをOracle Content Serverインスタンスに統合できます。
|
注意: 11g リリース1(11.1.1)以後、LDAPプロバイダ機能のかわりにJpsUserProviderが使用されています。LDAPプロバイダの使用はお薦めできません。4.5.1.2.6項「JpsUserProviderの編集が必要な状況」"を参照してください。 |
LDAPサーバー(Oracle Content Serverインスタンスと直接統合できるActive Directory以外)の使用を決定する場合、Oracle Content ServerインスタンスとLDAPサーバー間の通信を設定するために、LDAPプロバイダを設定する必要があります。正しく構成されている場合、LDAPプロバイダでは、ロールの割当ておよびアカウント権限(Ldapプロバイダ・ページで定義)にリンクするマッピング・プロパティを通じて、外部ユーザーが認可されます。
LDAPプロバイダと特定の各フィールドに関する追加の参考情報は、A.1.6.8項「LDAPプロバイダ・ページ」を参照してください。
必須ではありませんが、コンサルティング・サービスを利用して、LDAPセキュリティ・モデルを作成し、LDAP統合をデプロイすることをお薦めします。詳細は、営業担当者にご連絡ください。
次のコンテンツ管理製品およびアーキテクチャとのLDAP統合も便利です。
WebSphere上のポートレット: WebSphereユーザーは、Oracle Content Integration Suiteを介してOracle Content Serverにアクセスできます。このポータル・インタフェースにより、ユーザーや開発者は、フルテキストまたはメタデータ検索問合せに基づいて、Oracle Content Serverのコンテンツ・アイテムの取得、表示およびダウンロードができます。Content Integration Suiteを使用する場合は、WebSphereアプリケーション・サーバーをお薦めします。WebSphereポータル・サーバーを使用する場合は、Oracle Content Portal SuiteをContent Integration Suiteに追加することをお薦めします。
Content Integration Suiteでは、データベースのかわりに、Oracle Content Serverインスタンスに直接接続します。この直接接続により、Webサーバーでの認証ステップを回避し、開発者がユーザーの認証および認可を完全に制御できます。利点は、必要に応じて、Content Integration Suiteレイヤーでユーザーを認証できることです。アプリケーション・サーバー・レベルでLDAPサーバーと統合することも、Oracle Content Serverインスタンスにパスワードの検証を要求することもできます。
WebSphereのContent Integration SuiteおよびContent Portal Suiteとの使用の詳細は、WebSphereポートレット・サーバー、WebSphereアプリケーション・サーバー、Oracle Content Integration SuiteおよびOracle Content Portal Suite付属のドキュメントを参照してください。
Content Tracker: Content Trackerは、組み合せたときに、ユーザーが標準ブラウザを使用して、統合された一連の分析ツールを介してコンテンツの使用を追跡できるソフトウェア機能の集まりから構築されるシステムです。Oracle Content Serverインスタンスにより提供されるデータは、Webサーバー・ログ・データ、Oracle Content Serverデータおよびユーザー情報などのログ・データから導出されます。Content Trackerでは、このデータにアクセスし、データの分析を行い、説明的なレポートを作成します。LDAPディレクトリ・サーバーとContent Trackerの統合はオプションです。ただし、LDAPが使用される場合、LDAPプロバイダを作成する必要があります。
関連するデータ・リポジトリ、レポート生成、問合せの作成およびインストール手順の詳細は、『Oracle Fusion Middleware Content Serverアプリケーション管理者ガイド』を参照してください。
システム定義のJpsUserProviderでは、Oracle WebLogic Serverインスタンスに接続し、Oracle WebLogic Server認証メカニズム(基本、フォーム、シングル・サインオン、WNAなど)をサポートします。Javaプラットフォーム・セキュリティ(JPS)には、バックエンドのユーザー・ストレージ(XML、LDAP、データベース、Active Directoryなど)に関係なく、Oracle Fusion Middlewareアプリケーションからユーザーの認証および認可を行う統一インタフェースがあります。JPS APIコールは、ユーザー認証、ユーザー認可およびユーザー・メタデータ取得の実行に使用されます。
|
注意: 11g リリース1(11.1.1)以後、LDAPプロバイダ機能は、特にネストされたグループのサポートの場合などには、JpsUserProviderがかわりに使用されています。 |
JpsUserProviderコンポーネントは、Oracle Content ServerインスタンスがOracle WebLogic Serverインスタンスに対してインストールされているときに、システム・コンポーネントとしてインストールし、有効化します。これは、標準のOracle Content Serverコンポーネントとしても使用可能です。JpsUserProviderの構成は、Oracle Content Serverインスタンスの「プロバイダ」ページから編集できます。接続の構成も、アイデンティティ・ストアおよび資格証明ストアを使用するように、jps-config.xmlファイルを介して編集できます。
サイトでシステム定義のJpsUserProviderに加えてさらにJpsUserProviderが追加されることはまずありません。そのようにもう1つプロバイダを追加すると、Oracle Content Serverインストールに問題が生じる可能性があります。
JPSストアに対する認証を行う必要がある場合は、JpsUserProviderを使用すれば、Oracle WebLogic Serverインスタンス上の別のアプリケーションと同じセキュリティ記憶域を共有できます。たとえば、JpsUserProviderを使用すると、Oracle WebLogic Serverインスタンスにインストールされているイメージおよび処理マネージャ・ソフトウェアと、セキュリティ記憶域を共有できます。
この項の内容は次のとおりです。
SecurityProvidersコンポーネントは、基本の受信および送信ソケット・プロバイダに2つの新しいタイプのプロバイダを加えて拡張することで、セキュリティ強化に使用できます。
Secure Socket Layer (SSL)プロバイダ
キープアライブ・プロバイダ
セキュリティ・プロバイダを鍵および証明書とともに適切に使用すると、Oracle Content Serverインスタンスとのネットワークおよびインターネット通信のセキュリティを強化できます。SecurityProvidersコンポーネントを使用する利点には、次のものがあります。
通信の暗号化および認証を提供することにより、SSLがWeb通信のセキュリティを強化します。
セキュリティ・プロバイダにより、ソケットまたはサーバー認証に証明書を使用できます。
キープアライブおよび接続プーリング・ロジックは、SSLソケットの作成および解除の量を減らすことで、SSL費用のオーバーヘッドを避けるのに役立ちます。
SecurityProvidersコンポーネントは、デフォルトではOracle Content Serverインスタンスによりインストール(有効化)されます。
参照
SecurityProvidersコンポーネントを使用するには、ソケット・プロバイダ、セキュリティおよび認証、SSL、キープアライブ、およびネットワーク通信のその他のセキュリティ面に精通している必要があります。SecurityProvidersコンポーネントで作業する場合、次の情報ソースが役立ちます。
『Sun Java Secure Socket Extension (JSSE) Reference Guide for the Java 2 SDK, Standard Edition』
このオンライン・ドキュメントは、Sun社(www.sun.com)から入手できます。これには広範囲に及ぶ関連ドキュメント・セクションがあり、参考図書、セキュリティ基準、政府のセキュリティに関する政策および規制、暗号化およびSSLに関する書籍一覧が含まれています。
『keytool Key and Certification Management Tool』
このオンライン・ドキュメントは、Sun社(www.sun.com)から入手できます。
RSA社のPublic Key Cryptography Standards』
このオンライン・ドキュメントは、RSA社(www.rsasecurity.com)から入手可能です。
RSA社の『Cryptography FAQ』
このオンライン・ドキュメントは、RSA社(www.rsasecurity.com)から入手可能です。
『SSL Certificate FAQ』
このオンライン・ドキュメントは、Linux Documentation Project (www.tldp.org)から入手できます。
用語集
次の表では、この項で使用されるいくつかのセキュリティ用語の定義を示しています。詳細は、情報参照先のリスト、またはセキュリティおよび認証基準の情報源を参照してください。
| 用語 | 説明 |
|---|---|
| 証明書 | エンティティ(人または会社)のアイデンティティおよび公開鍵を確認するデジタル署名。証明書は、認証局または個々のエンティティで発行できます。 |
| 認証局(CA) | 他のエンティティのために証明書を発行するエンティティで、VeriSignやThawteのような、有名で信頼できる証明書の発行元として認識されています。 |
| キーストア | 認証処理に使用される鍵の情報のファイルまたはデータベース。 |
| 秘密鍵 | 発行者であるエンティティのみが知っている鍵としてパッケージ化された情報。秘密鍵は、署名生成で使用されます。 |
| 公開鍵 | エンティティに公に関連付けられた鍵としてパッケージ化された情報。公開鍵は、署名の確認に使用されます。 |
| SSL | Secure Socket Layerは、公開鍵と秘密鍵のテクノロジの組合せを使用するセキュアなネットワーク通信用のプロトコル。 |
| トラストストア | トラスト・マネージャが信頼できると判断した鍵のファイルまたはデータベース。 |
SSLソケット・プロバイダまたはキープアライブ・ソケット・プロバイダを実装する前に、セキュリティ・プロバイダをどのように使用するかを決めることをお薦めします。キープアライブおよびSSLの接続タイプを調べ、選択したセキュリティ・プロバイダを使用するために、キーストアやトラスト・ストアを作成する必要性など、追加の構成が必要かどうかを決定します。4.5.1.3.1項「セキュリティ・プロバイダ」であげた追加の情報源を参照してください。
次の項では、プロバイダ・タイプの動作を制御するために使用するJavaクラスや、必要になる可能性のある追加構成など、SSLおよびキープアライブ・プロバイダ・タイプについてより多くの情報を提供しています。
キープアライブ接続
キープアライブ機能は、永続的接続やサービス・リクエスト用のソケット接続のプーリングを可能にします。キープアライブ接続の設定は、接続の設定および解除に時間がかかる可能性のあり、そのアクティビティにかかる時間を最小限にする必要がある場合に、最も役に立ちます。SecurityProvidersコンポーネントは、受信および送信の2つのキープアライブ・ソケット・プロバイダを提供します。
キープアライブ受信ソケット・プロバイダの設定には、次のJavaクラスが使用されます。
| Javaクラス | 説明 |
|---|---|
| プロバイダ・クラス | idc.provider.ExtendedSocketIncomingProvider |
| 接続クラス | idc.provider.KeepaliveSocketIncomingConnection |
| サーバー・スレッド・クラス | idc.server.KeepaliveIdcServerThread |
キープアライブ送信ソケット・プロバイダの設定には、次のJavaクラスが使用されます。
| Javaクラス | 説明 |
|---|---|
| プロバイダ・クラス | idc.provider.KeepaliveSocketOutgomingProvider |
| 接続クラス | idc.provider.KeepaliveSocketOutgomingConnection |
| リクエスト・クラス | idc.server.KeepaliveServerRequest |
SSL接続
SSLプロバイダの設定により、キープアライブ環境でSSL接続が使用できるようになります。この設定は、SSLソケットの設定および解除のコストを最小限にするのに役立つため、単純なSSLプロバイダ設定にお薦めします。SecurityProvidersコンポーネントは、キープアライブ付きの受信および送信の2つのSSLソケット・プロバイダを提供します。
SSLキープアライブ受信ソケット・プロバイダの設定には、次のJavaクラスが使用されます。
| Javaクラス | 説明 |
|---|---|
| プロバイダ・クラス | idc.provider.ssl.SSLSocketIncomingProvider |
| 接続クラス | idc.provider.KeepaliveSocketIncomingConnection |
| サーバー・スレッド・クラス | idc.server.KeepaliveIdcServerThread |
キープアライブSSL送信ソケット・プロバイダの設定には、次のJavaクラスが使用されます。
| Javaクラス | 説明 |
|---|---|
| プロバイダ・クラス | idc.provider.KeepaliveSocketOutgoingProvider |
| 接続クラス | idc.provider.ssl.SSLSocketOutgoingConnection |
| リクエスト・クラス | idc.provider.KeepaliveServerRequest |
追加の構成
どのタイプのセキュリティ・プロバイダを選択するかに応じて、追加の構成が必要になる場合があります。
キープアライブおよびSSL送信プロバイダ: 「プロバイダの追加」ページには、プールする接続数を指定する「接続の数」フィールドがあります。
SSL受信プロバイダ: プロバイダの追加ページには2つの追加オプションがあります。
「クライアント認証をリクエスト」オプション: クライアントに能力があれば、接続を行うときに自身を認証する必要があります。
「クライアントの認証が必要」オプション: クライアントは、接続をするために、自身を認証する必要があります。
「クライアント認証をリクエスト」オプションの値、「クライアントの認証が必要」オプションの値、およびどんなタイプの認証局がこれらのオプションで処理される証明書に署名をしたかにより、SSLプロバイダでは、クライアントとサーバーの両方で、1つまたは複数のキーストアと1つのトラストストアの設定が必要になる可能性もあります。キーストアおよびトラストストアの詳細は、4.5.1.3.3項「キーストアおよびトラストストア」を参照してください。
SSLプロバイダには、複数のキーストアの使用が必要になる場合と、1つのトラストストアが必要になる場合があります。キーストアとは、SSLで使用するための公開鍵および秘密鍵の情報を保持するファイルです。トラストストアには、信頼できると判断された証明書が格納されます。サーバーおよびクライアント上で使用される証明書が、VeriSignやThawteなどの有名な認証局(CA)によって署名されている場合、デフォルトのJVMトラストストアにはこれらのCAの証明書が含まれてるため、トラストストアは不要です。トラストストアは、SSLプロバイダにより使用される証明書が自己署名または民間のCAによって署名されている場合に必要です。SSLプロバイダにキーストアとトラストストアが必要な場合、それらを作成および管理する必要があります。
次の各項では、キーストアとトラストストアの概要を説明します。
キーストアおよびトラストストアの詳細は、4.5.1.3.1項「セキュリティ・プロバイダ」のリストにある情報源を参照してください。
キーストアおよびトラストストアの使用が必要な状況
次の例は、キーストアおよびトラストストアが必要となる様々な状況と使用について示しています。
サーバーでは、SSLソケットを作成するために、署名入りSSL証明が入っているキーストアが1つ必要です。
サーバーでは、クライアント認証を要求または必要とし、これにはトラストストアが1つ必要になる場合があります。クライアントの証明書が有名なCAによって署名されていない場合、サーバーではそのCAの証明書が入っているトラストストアが必要になります。
サーバーではクライアント認証を要求または必要とし、これにはクライアントに、認証のために提示する証明書を格納するキーストアが必要になる場合があります。
サーバーでは、有名なCAによって署名されていない証明書を使用するため、クライアントにはサーバーの証明書が入っているトラストストアが必要になります。
キーストアおよびトラストストア情報の指定
キーストアおよびトラストストア情報を使用するために、SSL受信および送信プロバイダでは、sslconfig.hdaというファイルがプロバイダ・ディレクトリ(provider.hdaファイルの隣)で設定されている必要があります。sslconfig.hdaファイルには、キーストアおよびトラストストアのために指定する構成情報が含まれています。これは次の例に似たフォーマットです。セキュリティ上の理由で、このファイルの編集に便利なWebインタフェースはなく、編集はすべて、テキスト・エディタ使用して手動で行う必要があります。これまたは任意の.hdaファイルの各行の末尾に、スペースがないことを確認してください。
@Properties LocalDataTruststoreFile=/servers/idc/data/providers/ssloutgoing1/truststoreKeystoreFile=/servers/idc/data/providers/ssloutgoing1/keystore@end
| 構成名 | 値の説明 |
|---|---|
| TruststoreFile | トラストストア・ファイルへのフル・パス。 |
| KeystoreFile | キーストア・ファイルへのフルパス。 |
キーストアの生成
この項では、キーストア生成の基本プロセスを説明します。自分のSSLプロバイダ用に作成する鍵およびキーストアに、固有の要件と名前を決める必要があります。sslconfig.hdaファイルにはそのKeystoreFile構成設定のフルパスが含まれているため、キーストア・ファイルは好きなところに格納できます。ただし、キーストア・ファイルは、IntradocDir/data/providers/provider_nameディレクトリ(provider.hdaファイルおよびsslconfig.hdaファイルの隣)か、IntradocDir/config/ディレクトリに格納することをお薦めします。Oracle Content Serverインスタンスのプロバイダ・ページを使用して、エイリアスおよびパスワードを設定します。
キーストアを生成するキーツール・ユーティリティの使用方法の詳細は、Sun社(www.sun.com)からオンラインで入手可能な『keytool Key and Certification Management Tool』というタイトルのドキュメントを参照してください。
|
注意: Java keytoolユーティリティには、秘密鍵との直接の対話を防ぐ機能があります。この機能とは、キーツールを使用して生成される証明書をキーストアに貼り付けることで、そのため証明書から秘密鍵の部分を取得することはできません。逆に、キーツールで、前から存在する証明書をJavaキーストアにインポートする方法はありません。Portecle Javaキーストアを使用すると、Javaキーストアからの秘密鍵のインポートおよびエクスポートができます。詳細は、portecle.sourceforge.netを参照してください。 |
キーツールを使用するには、コマンドを入力する際に、自分のパスにそのユーティリティを持っている必要があります。
キーストアで鍵を作成します。次のコマンドラインの例は、aliasという名前の鍵のエントリを、keystoreという名前のキーストアに作成する方法を示しています。このコマンドは、キーストアのパスワード、鍵を生成するために使用される情報、および鍵自体のパスワードの入力を要求します。鍵のパスワードがキーストアのパスワードと異なる場合、鍵の取得にKeystoreAliasおよびKeystoreAliasPasswordの値が必要です。
keytool -genkey -v -alias alias -keystore keystore
証明書の署名リクエストを生成します。次のコマンドラインの例は、keystoreという名前のキーストアでaliasという名前の鍵エントリを生成し、これをcsr_fileという名前のファイルに格納する方法を示しています。このファイルは、CAに送信して署名してもらうことができます。
keytool -certreq -v -alias alias -keystore keystore -file csr_file
CAの証明書をキーストアにインポートします。キーツールが、ユーザーの証明書がインポートされると同時に、一連の信用をチェックします。証明書に有名でないCAの署名が入っていて、キーツールにそのCAに関する情報がない場合、その証明書は却下されます。したがって、有名ではないCAからの証明書はすべて、まずはキーストアにインポートし、そのユーザーの証明書が次のステップで正常にインポートされるようにする必要があります。次のコマンドラインの例は、cert_fileという名前のファイルにある証明書を、keystoreという名前のキーストアにインポートする方法を示しています。
keytool -import -v -alias ca_alias -keystore keystore -file cert_file
署名の入った証明書を元のキーストアにインポートします。証明書の署名リクエストがCAで受信され、署名の入った証明書がCAから送り返されてくると、その証明書は、エイリアスで識別されるキーストア・エントリに読み込むことができきます。次のコマンドラインの例は、署名の入った証明書をインポートする方法を示しています。
keytool -import -v -alias alias -keystore keystore_name -file csr_file
すべてがキーストアにあることを確認します。
keytool -list -v -keystore keystore_name
トラストストアの作成
この項では、トラストストア生成の基本プロセスを説明します。トラストストアは、SSLプロバイダで有名な認証局の署名のない鍵を使用する場合に必要です。トラストストアには、Oracle Content Serverインスタンス用にトラストストアの管理者(トラスト・マネージャ)によって確認された公開証明書のみが格納されています。作成するトラストストア固有の要件および名前を決める必要があります。sslconfig.hdaファイルにはTruststoreFile構成設定のフルパスが含まれているため、トラストストア・ファイルは好きなところに格納できます。ただし、トラストストア・ファイルは、IntradocDir/data/providers/provider_nameディレクトリ(provider.hdaファイルおよびsslconfig.hdaファイルの隣)か、IntradocDir/config/ディレクトリに格納することをお薦めします。
トラストストアを生成するキーツール・ユーティリティの使用方法の詳細は、Sun社(www.sun.com)からオンラインで入手可能な『keytool Key and Certification Management Tool』というタイトルのドキュメントを参照してください。
キーツールを使用するには、コマンドを入力する際に、自分のパスにそのユーティリティを持っている必要があります。
次のコマンドラインの例は、トラストストアの作成方法を示しています。
keytool -import -v -alias alias -keystore keystore -file cert_files
| 変数 | 説明 |
|---|---|
| alias | キーのエイリアス名。 |
| keystore | キーストアの名前。 |
| cert_file | 認証局の証明書へのパス。 |
プロバイダの管理には、次の作業が必要にないります。
送信プロバイダを追加するには、次のようにします。
Webブラウザを使用して、Oracle Content Serverのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「新規プロバイダの作成」表で、outgoingプロバイダ・タイプの「アクション」列の「追加」をクリックします。
送信ソケット・プロバイダ・ページが表示されます。
次の構成値を入力します。
必須のフィールド
プロバイダ名
プロバイダの説明
サーバー・ホスト名
サーバー・ポート
プロバイダ・クラス(事前定義)
オプションのフィールド
接続クラス(事前定義)
構成クラス
相対Webルート
HTTPサーバー・アドレス
インスタンス名
必要なロール
アカウント・フィルタ
オプションのチェックボックス
プロキシ
ターゲットへの通知
ユーザー
リリースされたドキュメント
「追加」をクリックします。
「プロバイダ」表に追加した新規プロバイダが入った「プロバイダ」ページが表示されます。
Oracle Content Serverインスタンスを再起動します。
データベース・プロバイダの構成は、Oracle Universal Content ManagementおよびOracle Content ServerインスタンスがOracle WebLogic Serverドメインにインストールされるときに指定されます。
|
注意: スタンドアロンOracle Content Serverシステムのデータベース接続を構成する場合、3.4.2.1項「スタンドアロン・モード用のSystemDatabaseプロバイダの構成」、3.4.2.2項「スタンドアロン・モード用のJDBCデータベース・ドライバの構成」および3.4.2.3項「スタンドアロン・モード用の外部データベース・プロバイダの構成」を参照してください。 |
データベース・プロバイダを追加するには、次のようにします。
Webブラウザを使用して、Oracle Content Serverのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「新規プロバイダの作成」セクションで、databaseプロバイダ・タイプの「アクション」列の「追加」をクリックします。
データベース・プロバイダのページが表示されます。
次の構成値を入力します。
必須のフィールド
プロバイダ名
プロバイダの説明
プロバイダ・クラス(事前定義)
データベース・タイプ
JDBCドライバ
JDBC接続文字列
問合せのテスト
オプションのフィールド
接続クラス(事前定義)
構成クラス
データ・ソース
データベース・ディレクトリ
データベース名
JDBCユーザー
JDBCパスワード
接続の数(デフォルト指定)
追加のストレージ・キー(デフォルト指定)
追加設定
オプションのチェックボックス
データ・ソースの使用
「追加」をクリックします。
「プロバイダ」表に追加した新規プロバイダが入った「プロバイダ」ページが表示されます。
Oracle Content Serverインスタンスを再起動します。
プロバイダを使用してサーバー・ソケットに接続するには、コンサルティング・サービスが必要です。
受信プロバイダを追加するには、次のようにします。
Webブラウザを使用して、Oracle Content Serverのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「新規プロバイダの作成」セクションで、incomingプロバイダ・タイプの「アクション」列の「追加」をクリックします。
受信プロバイダのページが表示されます。
次の構成値を入力します。
必須のフィールド
プロバイダ名
プロバイダの説明
サーバー・ポート
プロバイダ・クラス(事前定義)
オプションのフィールド
接続クラス(事前定義)
構成クラス
「追加」をクリックします。
「プロバイダ」表に追加した新規プロバイダが入った「プロバイダ」ページが表示されます。
Oracle Content Serverインスタンスを再起動します。
プレビュー・プロバイダの追加の手順は、『Oracle Fusion Middleware Content Serverアプリケーション管理者ガイド』を参照してください。HTMLプレビュー機能のzipファイルおよびガイドは、Oracle Technology NetworkのWebサイトからダウンロードできます。
受信セキュリティ・プロバイダを追加するには、次の手順に従います。
Webブラウザを使用して、Oracle Content Serverのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「新規プロバイダの作成」表で、keepaliveincomingまたはsslincomingプロバイダ・タイプの「アクション」列の「追加」をクリックします。keepaliveincomingプロバイダのページまたはsslincomingプロバイダのページが表示されます。
次の構成値を入力します。
必須のフィールド
プロバイダ名
プロバイダの説明
プロバイダ・クラス(事前定義)
サーバー・ポート
オプションのフィールド
接続クラス(事前定義)
構成クラス
サーバー・スレッド・クラス(事前定義)
オプションのチェックボックス(sslincomingプロバイダのみ)
クライアント認証をリクエスト
クライアントの認証が必要
「追加」をクリックします。「プロバイダ」表に追加した新規プロバイダが入った「プロバイダ」ページが表示されます。
Oracle Content Serverインスタンスを再起動します。
送信セキュリティ・プロバイダを追加するには、次の手順に従います。
Webブラウザを使用して、Oracle Content Serverのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「新規プロバイダの作成」表で、keepaliveoutgoingまたはssloutgoingプロバイダ・タイプの「アクション」列の「追加」をクリックします。keepaliveoutgoingプロバイダのページまたはssloutgoingプロバイダのページが表示されます。
次の構成値を入力します。
必須のフィールド
プロバイダ名
プロバイダの説明
プロバイダ・クラス(事前定義)
サーバー・ホスト名(事前定義)
サーバー・ポート
インスタンス名
相対Webルート
オプションのフィールド
接続クラス(事前定義)
構成クラス
リクエストのクラス(事前定義)
接続の数(事前定義)
HTTPサーバー・アドレス
必要なロール
アカウント・フィルタ
オプションのチェックボックス
プロキシ
ターゲットへの通知
ユーザー
リリースされたドキュメント
「追加」をクリックします。「プロバイダ」表に追加した新規プロバイダが入った「プロバイダ」ページが表示されます。
Oracle Content Serverインスタンスを再起動します。
Oracle JPS (Oracle WebLogic Serverインスタンス用)を統合するデフォルトのJPSユーザー・プロバイダは、Oracle Content Serverシステムをインストールすると提供されます。もう1つのJPSユーザー・プロバイダが必要になることはまずありません。ただし、ユーザー・プロバイダを1つ追加する必要がある場合は、次の手順に従います。
Webブラウザを使用して、Oracle Content Serverのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「新規プロバイダの作成」表で、jpsuserプロバイダ・タイプの「アクション」列の「追加」をクリックします。
JPSユーザー・プロバイダのページが表示されます。
次の構成値を入力します。
必須のフィールド
プロバイダ名
プロバイダの説明
プロバイダ・クラス(事前定義)
ソース・パス
オプションのフィールド
接続クラス
構成クラス
JPSコンテキスト
デフォルト・ネットワーク・ロール
属性マップを指定するには、次のようにします。
「JPS属性」リストから情報フィールドを選択します。
「ユーザー属性」リストからOracle Content Serverユーザー情報フィールドを選択します。
「追加」をクリックします。
テキスト・ボックスに、その属性マップが追加されます。
必要ならば、「属性マップ」テキスト・ボックスで属性を直接編集します。
必要ならば、デフォルト・ネットワーク・ロールを変更または追加します。
「追加」をクリックします。
「プロバイダ」表に追加した新規プロバイダが入った「プロバイダ」ページが表示されます。
Oracle Content Serverインスタンスを再起動します。
Webサーバーを再起動します。
HTTP送信プロバイダを追加するには、次のようにします。
Webブラウザを使用して、Oracle Content Serverのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「新規プロバイダの作成」表で、httpoutgoingプロバイダ・タイプの「アクション」列の「追加」をクリックします。
送信Httpプロバイダのページが表示されます。
次の構成値を入力します。
必須のフィールド
プロバイダ名
プロバイダの説明
プロバイダ・クラス(事前定義)
CGI URL
インスタンス名
相対Webルート
オプションのフィールド
接続クラス(事前定義)
構成クラス
接続パスワード名
接続パスワード
クライアントのIPフィルタ
「追加」をクリックします。
「プロバイダ」表に追加した新規プロバイダが入った「プロバイダ」ページが表示されます。
Oracle Content Serverインスタンスを再起動します。
既存のプロバイダ(デフォルトのシステム・プロバイダを除く)の情報を編集するには、次のようにします。
Webブラウザを使用して、Oracle Content Serverのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「プロバイダ」表で、編集するプロバイダの「アクション」列の「情報」をクリックします。
プロバイダ情報ページが表示されます。
「編集」をクリックします。
「プロバイダの追加/編集」ページが表示されます。
必要な変更を行います。
「更新」をクリックして変更内容を保存し、「プロバイダ」ページに戻ります。
Oracle Content Serverインスタンスを再起動します。
既存のプロバイダ(デフォルトのシステム・プロバイダを除く)を削除するには、次のようにします。
Webブラウザを使用して、Oracle Content Serverのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「プロバイダ」表で、削除するプロバイダの「アクション」列の「情報」をクリックします。
プロバイダ情報ページが表示されます。
「削除」をクリックします。
確認画面が表示されます。
「OK」をクリックします。
「プロバイダ」表からそのプロバイダが削除されます。
|
重要: 単に情報を編集するのではなく、プロバイダの削除が目的であることを確認してください。プロバイダを削除すると、プロバイダ名およびその関連情報すべてが、「プロバイダ」表から永久に削除されます。 |
