| Oracle® WebCenter Content Content Serverシステム管理者ガイド 11g リリース1 (11.1.1) B65037-02 |
|
 前 |
 次 |
この章では、コンテンツ・サーバーのシステム設定を継続的に管理するための概念および作業について説明します。内容は次のとおりです。
この項の内容は次のとおりです。
システム・プロパティはシステム全体にわたる設定で、コンテンツ・サーバー・インスタンスを特定の要件に合うように調整できます。システム・プロパティは、インストール時に設定され、ユーザーおよびコンテンツのメンテナンスのためにより定期的に使用される他の管理ツールとは異なり、通常、ときどきまたは必要に応じて更新されます。
|
重要: システム・プロパティをどの方法で変更したかに関係なく、構成の変更内容を反映するには、コンテンツ・サーバー・インスタンスを再起動する必要があります。 |
システム・プロパティとの情報のやりとりには、いくつかの方法があります。
管理サーバーを使用すると、単一のコンテンツ・サーバー・インスタンスを構成できます。システム・コンポーネントを有効または無効にすることもできます。管理サーバーには、Webブラウザを使用して、「トレイ」レイアウトまたはメニュー・バーから「管理」リンクを選択してアクセスできます。
システム・プロパティ・アプリケーションを使用すると、特定のコンテンツ・サーバー・インスタンスを、そのインスタンスがデプロイされているシステムで構成できます。システム・プロパティ・ユーティリティへのアクセスの詳細は、3.4.2項「スタンドアロン・モードでの管理アプリケーションの実行」を参照してください。
大部分のシステム・プロパティ設定は、次の構成ファイルのいずれかにある構成変数に対応しています。
IntradocDir/config/config.cfg
DomainHome/ucm/cs/bin/intradoc.cfg
IntradocDir/search/search.cfg
これらのファイルへの変更は、管理サーバーまたはシステム・プロパティ・アプリケーションを使用して、設定が正しく入力されるようにすることをお薦めします。テキスト・エディタを使用してこれらのファイルを直接編集することもできますが、誤りが生じる可能性があります。構成変数の詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。
|
注意: システム・プロパティ・ユーティリティは、Oracle WebCenter Contentドメインでコンテンツ・サーバー・インスタンス用のスタンドアロン・アプリケーションとして実行されるため、追加の構成が必要です。3.4.2.1項「スタンドアロン・モード用のシステム・データベース・プロバイダの構成」を参照してください。 |
コンテンツ・サーバー・インスタンスのパフォーマンスを最適化するには、いろいろな方法があります。あるタイプのチューニングでは、核となるコンテンツ・サーバーのパフォーマンスに影響を与えるデフォルトのパラメータやソフトウェア設定に変更が必要になります。システムの最適化やパフォーマンス・チューニングは、多くの場合、システム設定や構成変数の調整、あるいはデータベースや索引などのリソースのチューニングによって行われます。
たとえば、コンテンツ・サーバー・インスタンス内のコンテンツが増えるにつれて、使用可能な領域が不足する可能性があります。この場合、ボールト、Webレイアウトおよび検索索引ディレクトリをもっと領域のある別のドライブに移動すると、不足の問題を軽減できます。これらのディレクトリを移動するには、DomainHome/ucm/cs/bin/intradoc.cfgファイルにエントリを追加する必要があります。
システム・プロパティ・アプリケーションへのアクセスには、システム管理者としてログインする必要はありません。コンテンツ・サーバー・インスタンスがインストールされているローカル・コンピュータにアクセスするのみです。
「システム・プロパティ」: 「オプション」タブまたは「管理サーバー」: 「一般構成」ページで、一般的なオプションを設定できます。構成の変更内容を反映するには、コンテンツ・サーバー・インスタンスを再起動する必要があります。
バッチ・ローダー・ユーティリティを使用して、コンテンツ・サーバー・インスタンスで大量のファイルを同時に更新および挿入することを計画している場合は、バッチ・ロード・ファイルを作成する必要があります。バッチ・ロード・ファイルに含めることのできるオプション・パラメータの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は、定義された範囲のシーケンスです。
コンテンツ・サーバーのチャンク化機能は、データを複数のチャンクに分割し、一度に1チャンクずつ転送することにより、大量のデータ転送の失敗を防ぎます。転送に失敗した場合、失敗前にコンテンツ・サーバー・インスタンスに転送されたチャンクはすべて保存され、転送は失敗した時点から再開できます。
|
注意: チャンク化機能を使用するクライアント・セッションが、タイムアウトまたはクライアント・ブラウザを閉じることで中断された場合、転送は失敗します。 |
チャンク化機能は、アップロード・アプレットで使用できます。
アップロード・アプレットまたはHTTPプロバイダを有効にします。4.1.2項「一般オプションの構成」を参照してください。
アップロード・アプレットを有効にするには、4.1.2項「一般オプションの構成」を参照してください。
HTTPプロバイダを作成するには、5.8項「追加のコンテンツ・サーバー・セキュリティ接続」を参照してください。
「管理サーバー」: 「一般構成」ページの「追加の構成変数」ボックスで、次の構成設定を設定します。
DisableHttpUploadChunking=false AppletChunkThreshold=size in bytesAppletChunkSize=size in bytes
AppletChunkSize設定は、個々のチャンクのサイズを設定します。AppletChunkThreshold設定は、チャンク化機能を使用する最小ファイル・サイズを設定します。これらの値はどちらもデフォルトでは1Mです。
チャンク化機能をデバッグするには、ChunkedRequestTrace=trueを設定します。
この設定により、チャンク化されたリクエストを管理サーバーの出力画面で表示できます。
変更を保存します。
コンテンツ・サーバー・インスタンスを再起動します。
「システム・プロパティ」: 「コンテンツ・セキュリティ」タブまたは「管理サーバー」: コンテンツ・セキュリティのページでは、コンテンツ・サーバーのコンテンツ・セキュリティ・オプションを設定できます。
構成の変更内容を反映するには、コンテンツ・サーバー・インスタンスを再起動する必要があります。
「システム・プロパティ」: 「インターネット」タブまたは「管理サーバー」: 「インターネットの構成」ページでは、コンテンツ・サーバーのインターネット・オプションを設定できます。
構成の変更内容を反映するには、コンテンツ・サーバー・インスタンスを再起動する必要があります。
コンテンツ・サーバーのシステム・データベースには、Oracle Database 11g、Microsoft SQL Server、IBM DB2またはその他のデータベースを使用できます。サポートされているデータベースの詳細は、次のURLのOracle Technology Networkの「Oracle Fusion Middleware Supported System Configurations」ページで、自分の製品のシステム要件およびサポートされるプラットフォームのドキュメントを参照してください。
http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
コンテンツ・サーバーでは、Oracle WebLogic Serverデータ・ソースを使用して、メタデータおよびその他の情報が格納されているシステム・リレーショナル・データベースと通信します。システム・リレーショナル・データベースのデータベース接続情報の管理には、Oracle WebLogic Server管理コンソールを使用する必要があるため、JDBCユーザー名およびパスワード情報は、IntradocDir/config/config.cfgファイルには格納されず、システム・プロパティ・ユーティリティでは管理されません。
|
注意: Oracle WebLogic Serverドメインのデータベース接続情報をコンテンツ・サーバーのシステム・プロパティ・ユーティリティを使用して設定する場合、JDBCユーザー名およびパスワードは暗号化されて不特定の場所に格納されます。 |
コンテンツ・サーバーでは、Oracle Real Application Cluster(RAC)用のOracle Databaseリレーショナル・データベースへの接続で、GridLinkデータ・ソースをサポートします。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』および『Oracle Fusion Middleware管理者ガイド』を参照してください。
スタンドアロン・モードでアプリケーションを実行するコンテンツ・サーバー・インスタンスへのデータベース接続の構成の詳細は、次の項を参照してください。
IBM DB2データベース検索用のコンテンツ・サーバーの構成
IBM DB2データベースでは、検索問合せでキーワードCONTAINSがサポートされていません。コンテンツ・サーバー・インスタンスをIBM DB2検索問合せ用に正しく構成するには、フラグSSUseContains=false変数を追加する必要があります。コンテンツ・サーバー・インスタンスを構成するには、次の手順を実行します。
新規のブラウザ・ウィンドウを開き、システム管理者としてコンテンツ・サーバー・インスタンスにログインします。
「管理」→「管理サーバー」を選択します。
コンテンツ・サーバー・インスタンスのオプション・リストで、「一般構成」を選択します。
「一般構成」ページが表示されます。
「追加の構成変数」領域に次の行を追加します。
SSUseContains=false
「保存」をクリックします。
コンテンツ・サーバー・インスタンスを再起動します。
「システム・プロパティ」: 「サーバー」タブでは、コンテンツ・サーバーのオプションを設定できます。セキュリティ上の理由から、管理サーバーはこれらのオプションの構成に使用できません。コンテンツ・サーバーのオプションを構成するには、スタンドアロン・アプリケーションを使用する必要があります。スタンドアロン・アプリケーション使用の詳細は、3.4.2項「スタンドアロン・モードでの管理アプリケーションの実行」を参照してください。
一部のコンテンツ・サーバー構成オプションは、Oracle Enterprise Manager Fusion Middleware Controlを使用して設定します。詳細は、第2章「コンテンツ・サーバーを管理するためのFusion Middleware Controlの使用」を参照してください。
構成の変更内容を反映するには、コンテンツ・サーバー・インスタンスを再起動する必要があります。
|
注意: ホスト名フィルタ、IPアドレス・フィルタまたはその他のネットワークベースのセキュリティを使用しないと、コンテンツ・サーバー・インスタンスにセキュリティ・ホールが生じます。たとえば、システムについての深い知識を持つユーザーならば、ログインしなくても、他のユーザーをシステム管理者のアクセス権限を持つように作成または変更することができます。 |
ホスト名フィルタまたはIPアドレス・フィルタの値は、次のような状況でコンテンツ・サーバー・インスタンスと通信できるように設定する必要があります。
Inbound RefineryおよびPDF Converterの実行時(コンテンツ・サーバー・インスタンスと同じ物理コンピュータ上の場合でも)。
コンピュータ間でのコンテンツ・サーバー・アーカイブの転送時。
Webサーバーとコンテンツ・サーバー・インスタンスが異なるシステムにある場合の構成。
EJB拡張機能の操作。
コンテンツ・サーバー・インスタンスとは別のシステムでIdcCommandまたはIdcCommandXユーティリティの使用時。(デフォルト値を変更し、WebサーバーのIPアドレスを指定する必要があります。)
システム・プロパティ・ユーティリティの「ローカライズ」タブを使用すると、日付/時間のフォーマット、デフォルトのタイムゾーン、ソート・ゾーン、有効になっているインタフェース言語などの言語特有のアイテムを変更できます。管理ローカライゼーション画面を使用して、ユーザーが各自の「ユーザー・プロファイル」で選択するロケールを有効化または無効化できます。
デフォルトのEnglish-USロケールでは、年は2桁(yy)で表現され、1969年から2068年の間のものとして解釈されます。つまり、65は1965年ではなく、2065年とみなされます。English-USロケールで1969年より前の年が正しく解釈されるようにするには、そのロケールのデフォルトの日付フォーマットを、年が4桁(yyyy)で表されるように変更する必要があります。
この問題は、すでに年の表現に4桁を使用しているEnglish-UKロケールには当てはまりません。
デフォルトのEnglish-US日付フォーマットを変更するには、次のようにします。
システム・プロパティ・アプレットを起動します。
Windowsオペレーティング・システムの場合:
「スタート」→「プログラム」→「コンテンツ・サーバー」→「instance_name」→「ユーティリティ」→「システム・プロパティ」を選択します。
UNIXオペレーティング・システムの場合:
コンテンツ・サーバー・インストール・ディレクトリの/binサブディレクトリにあるシステム・プロパティ・ユーティリティを実行します。
SystemProperties
「ローカライズ」タブを選択します。
ロケールのリストでEnglish-USエントリを選択し、「編集」をクリックします。
「ロケールの構成」ダイアログが表示されます。
日付フォーマットを2桁(yy)ではなく4桁(yyyy)を使用して年を表すように修正します。
編集が終了したら、「OK」をクリックして「ロケールの構成」ダイアログを閉じます。
「OK」をクリックして変更を適用し、「システム・プロパティ」を終了します。
コンテンツ・サーバー・インスタンスを停止して再起動し、構成の変更内容を反映します。
コンテンツ・サーバー・システムのインタフェース言語を追加、編集、削除、有効化または無効化するには、4.1.7.1項「日付フォーマット」で説明されているのと同じ基本手順で、システム・プロパティ・ユーティリティの「ローカライズ」タブでロケールを選択し、変更を加えて、「OK」をクリックします。「ローカライズ」タブでロケールを有効化すると、管理ローカライゼーション画面でもそのロケールが有効になります。
管理者は複数のロケールを有効化して、ユーザーが各自の「ユーザー・プロファイル」から、自分のユーザー・インタフェース言語に使用するロケールを、有効化されたロケールの中から選択できるようにすることができます。ユーザーが選択できるように有効化するロケールを指定するには、コンテンツ・サーバーのメイン画面で、「管理」、「ローカライズ」と選択します。「有効なロケール」リストからチェック・ボックスを選択して言語を指定し、「更新」をクリックします。
「システム・プロパティ」: 「パス」タブでは、ヘルプ・ブラウザの場所、Javaクラスパスおよび共有ディレクトリ・パスを変更できます。セキュリティ上の理由から、管理サーバーはパス・オプションの構成に使用できません。この構成には、スタンドアロン・アプリケーションを使用する必要があります。
構成の変更内容を反映するために、コンテンツ・サーバー・インスタンスを再起動する必要があります。
この項の内容は次のとおりです。
コンテンツ・サーバー・システムは、商用検索エンジンやデータベースなどの索引付けツールと接続して一緒に機能します。使用する検索付けツールは、コンテンツ・サーバー・インスタンスが機能する目的や環境に基づいて、インストール前に選択されます。
各索引付けツールには、フルテキストの索引付けとメタデータのみの索引付け機能があります。フルテキストの索引付けでは、ファイル内のメタデータのみでなく、すべての語に索引が付けられます。フルテキストの索引付けは、メタデータの索引付けより時間がかかりますが、より包括的な結果セットが得られます。メタデータのみの索引付けでは、格納されたコンテンツ情報のすべての語に索引が付けられます。メタデータのみの索引付けは、フルテキストの索引付けよりも高速です。デフォルトでは、コンテンツ・サーバー・インスタンスは、メタデータのみの索引付けを使用するように構成されます。
|
注意: タイトル・フィールドの検索を頻繁に行い、サイトに100万件を超えるレコードがある場合に、データベース検索を使用するには、dDocTitleおよびdReleaseStateに基づいて索引を作成することをお薦めします。 |
システムが、データベースによる索引付けおよび検索機能を使用できるように設定されているとすれば、担当のシステム・インテグレータが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でサポートされているフォーマット
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 WebCenter Content Content Serverアプリケーション管理者ガイドを参照してください。
システム・プロパティでフォーマット・オーバーライド機能を有効にすれば、コントリビュータがファイルのフルテキスト索引付けをするかどうかを指定できるようにすることができます。4.1.2項「一般オプションの構成」を参照してください。
たとえば、構成マネージャの「ファイル・フォーマット」オプションを使用して、Corel WordPerfect(.wpd)ファイルをtextフォーマットが使用できるようにマップしている場合、コントリビュータがチェックイン・ページの「フォーマット」フィールドで「デフォルトの使用」オプションを選択すると、ファイルはテキストに変換され、フルテキスト索引が付けられます。コントリビュータが「Corel WordPerfectドキュメント」を選択した場合、ファイルはネイティブ・フォーマットで渡され、フルテキスト索引付けは行われません。
構成マネージャの「ファイル・フォーマット」オプションの詳細は、Oracle WebCenter Content Content Serverアプリケーション管理者ガイドを参照してください。
フルテキスト検索を使用する場合、メタデータ検索では大文字と小文字が区別され、フルテキスト検索では区別されません。ただし、コンテンツIDの場合、小文字が大文字に変換されるため、小文字では検索できません。
索引付けのエラーを防ぐために、存在しないメタデータ・フィールドを構成マネージャのDrillDownFieldsパラメータに追加しないでください。また、SDATAセクションまたはDrillDownFieldsパラメータにメモ・フィールドを追加しないでください。詳細は、Oracle WebCenter Content Content Serverアプリケーション管理者ガイドを参照してください。
すべてのデータベースにおけるメタデータのみの検索および索引付けを設定して使用するには、次の手順を実行します。
コンテンツ・サーバーをインストールし、データベースを使用するように構成します。
次のエントリをDomainHomeName/ucm/cs/config/config.cfgファイルに追加し、ファイルを保存します。
SearchIndexerEngineName=DATABASE.METADATA
コンテンツ・サーバーを再起動します。
リポジトリ・マネージャを使用して、検索索引を再構築します。
SQL ServerおよびOracle Database(サポートされているすべてのバージョン)におけるフルテキストのデータベース検索および索引付けを設定して使用するには、次の手順を実行します。
コンテンツ・サーバーをインストールし、データベースを使用するように構成します。
次のエントリをDomainHomeName/ucm/cs/config/config.cfgファイルに追加し、ファイルを保存します。
SearchIndexerEngineName=DATABASE.FULLTEXT
コンテンツ・サーバーを再起動します。
リポジトリ・マネージャを使用して、検索索引を再構築します。
OracleTextSearch(Oracle Databaseバージョン11.1.0.7以降でサポートされています)によるフルテキストの検索および索引付けを設定して使用するには、次の手順を実行します。詳細は、7.1項「OracleTextSearch」を参照してください。
コンテンツ・サーバーをインストールし、データベースを使用するように構成します。
次のエントリをDomainHomeName/ucm/cs/config/config.cfgファイルに追加し、ファイルを保存します。
SearchIndexerEngineName=DATABASE.ORACLETEXTSEARCH
コンテンツ・サーバーを再起動します。
リポジトリ・マネージャを使用して、検索索引を再構築します。
ファイル・フォーマットをネイティブ・フォーマットでPASSTHRUに定義し、そのフォーマット名に前述のリストにあるタイプの1つが含まれている場合(application/ms-excel.nativeなど)、通過するネイティブ・ファイルにはデフォルトでフルテキスト索引が作成されます。
または、構成変数を使用して、ドキュメントにフルテキスト索引を作成するかどうかを制御することもできます。特定のドキュメント・フォーマット・タイプのフルテキスト索引付けおよび検索を管理するには、IntradocDir/config/config.cfgに該当するエントリを追加し、ファイルを保存します。フルテキスト索引付け構成変数には、次のものがあります。
FormatMap構成変数は、フルテキスト検索索引に特定のフォーマットを含めるべきかどうかを制御します。これは、フルテキスト索引付けの対象となるすべてのフォーマットのカンマ区切りのリストです。ファイルに割り当てられたMIMEタイプを取得し、MIMEタイプをスラッシュ(/)またはピリオド(.)で分割し、その値がFormatMapリストにあるかどうかを調べることで決定します。
たとえば、application/vnd.mswordは、次の3項目のリストになります。
application
vnd
msword
FormatMapのリストにmswordがある場合、インデクサ・エンジンではファイルにフルテキスト索引付けが試みられ、比較テストでは大文字と小文字は区別されません。
この項の内容は次のとおりです。
リポジトリ・マネージャ・ユーティリティには、管理者が検索索引に対してアクションを実行するために使用できる「インデクサ」タブがあります。
リポジトリ・マネージャにアクセスするには、「管理」→「管理アプレット」→「リポジトリ・マネージャ」を選択します。リポジトリ・マネージャには、スタンドアロン・アプリケーションとしてアクセスすることもできます。詳細は、3.4.2項「スタンドアロン・モードでの管理アプリケーションの実行」を参照してください。
リポジトリ・マネージャ画面の「インデクサ」タブでは、管理者が次のアクションを実行できます。
検索索引の更新: 索引データベースを追加的に更新します。索引はサーバーにより約5分ごとに自動的に更新されるため、これは通常必要ありません。
コレクションの再構築: 検索索引が完全に再構築され、古い索引コレクションは新しい索引コレクションに置き換えられます。
更新または再構築の一時停止: 更新または再構築を一時的に停止します。適切な「開始」ボタンをクリックすることで、プロセスを再開できます。
検索更新の取消し: 索引の更新プロセスが終了し、その時点までに処理されたファイルのみが検索エンジンでアクセス可能になります。
コレクション再構築の取消し: 索引再構築プロセスが終了し、前の索引データベースが引き続き検索エンジンによって使用されます。
リポジトリの管理の詳細は、Oracle WebCenter Content Content Serverアプリケーション管理者ガイドを参照してください。
リポジトリ・マネージャ画面で、「インデクサ」タブをクリックします。
「コレクション再構築サイクル」領域で「開始」をクリックします。
|
注意: OracleTextSearchには高速再構築機能があり、サイトでOracleTextSearch機能を使用する場合、リポジトリ・マネージャのインデクサ機能から使用できます。詳細は、7.1.3.2項「高速再構築」を参照してください。 |
検索索引の更新またはコレクションの再構築のためのパラメータを設定するには、次のようにします。
リポジトリ・マネージャ画面で、「インデクサ」タブをクリックします。
画面の「自動更新サイクル」領域または「コレクション再構築サイクル」領域のいずれかで、「構成」をクリックします。
「自動更新サイクル」画面または「コレクション再構築サイクル」画面が表示されます。
インデクサ・バッチ当たりのコンテンツ・アイテム(ファイル)数を指定します。これは、検索索引で同時に処理されるファイルの最大数です。
チェックポイント当たりのコンテンツ・アイテム(ファイル)数を指定します。これは、関連するすべての索引付け状態を一度に通過するファイルの数です。チェックポイントごとに、複数のファイル・バッチを索引付けできます。
インデクサのデバッグ・レベルを指定します。これは、サーバー・ウィンドウで表示する各ファイルの関連情報の量です。
「OK」をクリックします。
索引付けエンジンとしてDATABASE.FULLTEXTまたはORACLETEXTSEARCHを使用するようにコンテンツ・サーバー・インスタンスを構成した場合、コンテンツ・サーバーでは、Outside Inコンテンツ・アクセス・モジュールを使用して、チェックイン時にコンテンツをテキスト・ファイルにエクスポートします。その後、テキスト・ファイルは、フルテキスト索引付けのためにフルテキスト・インデクサに渡されます。
|
注意: Outside Inコンテンツ・アクセス・モジュールでPostScriptファイルを変換する際、変換プロセスで余分な文字を含むテキストが生成されます。残念ながらこれにより、フルテキスト索引付けされてもフルテキスト検索ができないファイルが作成されます。 |
DATABASE.FULLTEXTを使用する場合、フルテキスト検索は、大きなドキュメントでは問題になる可能性があります。デフォルトでは、索引付けされる最大のドキュメント・サイズは10MBです。これは、コンテンツ・サーバー・リポジトリでMaxIndexableFileSize構成変数を設定すれば変更できます。デフォルトはMaxIndexableFileSize=10485760です。それより大きなドキュメントでフルテキスト索引付けが必要な場合は、MaxIndexableFileSizeの値を増やす必要があります。
たとえば、ファイル・スペースを節約したり、特定のコンテンツ・タイプにフルテキスト検索が不要な場合などには、フルテキスト索引付けを無効にできます。フルテキスト索引付けを無効にしても、メタデータには索引が付けられます。
特定のファイルに対してフルテキスト索引付けを無効にするには、次のようにします。
アプリケーション/索引なしという構成マネージャ画面で、フォーマットを定義します。
「チェックイン時にフォーマットの上書きを許可」設定を有効にします。4.1.2項「一般オプションの構成」を参照してください。
ユーザーは、索引付けが不要なファイルをチェックインする際、アプリケーション/索引なしフォーマットを選択する必要があります。標準ファイル、バッチ・ロードおよびアーカイブされたリビジョンがこれに当てはまります。
検索索引では、索引付けにデフォルトでWebレイアウト・ファイルを使用します。状況によっては、Webレイアウト・ファイルのかわりに、デフォルトでネイティブ・ファイルに索引を付ける方が便利な場合があります。たとえば、処理上の問題のために、変換されたPDFファイルを抽出して索引付けできない場合、ネイティブのWordドキュメントまたはかわりのタイプのドキュメントを抽出して、索引を付けることができます。あるいは、プライマリ・ファイルが.exeファイルであるために索引付けできなくても、かわりの.txtファイルがある場合、そのファイルに索引付けができます。
検索索引で、ネイティブ・ファイルをデフォルトで索引付けに使用できるようにするには、コンテンツ・サーバー・インスタンスで次のパラメータを設定します。
UseNativeFormatInIndex=true
コンテンツ・サーバーでは、電子メールおよび添付ファイル(元のファイルやzipファイルなど)の索引付けがサポートされています。電子メールのメッセージはデフォルトで索引付けされ、メッセージに添付ファイルが含まれる場合は、それも抽出され、フルテキストとして検索付けされます。検索結果で返されるものには変わりはなく、検索によりドキュメント内に情報が見つかった場合、そのドキュメントのメタデータが返されます。Outside Inテクノロジでサポートされている電子メールの添付ファイルはすべて、検索索引でサポートされます。
この項で説明する機能は、データベース検索の「次を含む」演算子機能をインストールし、有効にしてある場合にのみ使用可能です。
|
注意: この機能は、OracleTextSearchコンポーネントでは必要ありません。 |
この項の内容は次のとおりです。
データベース検索の「次を含む」演算子を使用すると、SQLサーバーおよびOracleでデータベースおよびデータベース・フルテキスト検索を実行する際、テキスト・フィールドの検索に「次を含む」検索演算子を使用できます。まず、「次を含む」検索演算子を使用して問合せができるテキスト・フィールドを有効にする必要があります。これらのテキスト・フィールドは、ゾーン・テキスト・フィールドと呼ばれます。
テキスト・フィールドがゾーン・テキスト・フィールドとして追加されると、そのフィールド内のテキストは解析され、データベースにフィールドのフルテキスト索引が作成されます。データベースにより索引作成の全作業が実行され、そのテキスト・フィールドがゾーン・テキスト・フィールドとして無効になると、索引はデータベースから削除されます。したがって、テキスト・フィールドをゾーン・テキスト・フィールドとして有効または無効にした後で、コレクションを再構築する必要はありません。
|
重要: テキスト・フィールドをゾーン・テキスト・フィールドに変更すると、非常に時間がかかる場合があります。この処理で、テキストを解析し、フルテキスト索引を作成するのに要する時間は、コンテンツ・サーバー・リポジトリにあるコンテンツ・アイテムの数と、テキスト・フィールドに格納されているテキストの量によって異なります。ただし、テキスト・フィールドに索引が付いていると、コンテンツ・アイテムの更新および追加時に、パフォーマンスが大幅に低下することはありません。 |
テキスト・フィールドがゾーン・テキスト・フィールドとして有効になっていると、「拡張検索」ページでそのテキスト・フィールドに対してCONTAINS検索演算子を使用できます。それは、そのテキスト・フィールドの隣のリストに、「語を含む」オプションとして表示されます。
コンテンツ・サーバー・インスタンスに管理者としてログインします。
「管理」トレイまたはメニュー、または「管理アプレット」ページから「ゾーン・フィールドの構成」を選択します。「ゾーン・フィールドの構成」ページが表示されます。
リストから検索エンジンを選択します。
テキスト・フィールドをゾーン・テキスト・フィールドとして有効にするには、次の手順を完了します。
「テキスト・フィールド」リストでテキスト・フィールドを選択します。キーボードの[Ctrl]キーおよび[Shift]キーを使用して、複数のフィールドを選択できます。
デフォルトでは、フィールド長が20文字以下のテキスト・フィールドは「テキスト・フィールド」リストに掲載されません。この設定を変更するには、 MinFullTextFieldLength 構成変数を変更します。詳細は、4.2.4.3項「MinTextFullFieldLength変数の変更」を参照してください。
左矢印ボタンをクリックして、テキスト・フィールドを「ゾーン・テキスト・フィールド」リストに移動します。
「更新」をクリックします。
|
重要: テキスト・フィールドをゾーン・テキスト・フィールドに変更すると、非常に時間がかかる場合があります。この処理で、テキストを解析し、フルテキスト索引を作成するのに要する時間は、コンテンツ・サーバー・リポジトリにあるコンテンツ・アイテムの数と、テキスト・フィールドに格納されているテキストの量によって異なります。ただし、テキスト・フィールドに索引が付けられている場合は、コンテンツ・アイテムを更新および追加するとき、パフォーマンスが大幅に低下することはありません。 |
ゾーン・テキスト・フィールドを無効にするには、次の手順を完了します。
「ゾーン・テキスト・フィールド」リストでゾーン・テキスト・フィールドを選択します。キーボードの[Ctrl]キーおよび[Shift]キーを使用して、複数のフィールドを選択できます。
右矢印ボタンをクリックして、テキスト・フィールドを「テキスト・フィールド」リストに移動します。
「更新」をクリックします。
ゾーン・テキスト・フィールドを有効または無効にする際、次のことを考慮してください。
リストの変更開始後に、最後に保存したリストに戻る場合は、「リセット」をクリックします。
カスタム・テキスト・フィールド(「コメント」テキスト・フィールドおよびカスタマ作成のテキスト・フィールド)がデータベース検索エンジンとデータベース・フルテキスト検索エンジンとの間で共有されるため、一方の検索エンジンでこれらのテキスト・フィールドのステータスを変更すると、その変更がもう一方の検索エンジンにも適用されます。
標準テキスト・フィールド(作成者、コンテンツID、コンテンツ・タイプ、タイトルなど)は、検索エンジンごとに有効化または無効化できます。
データベースにより索引作成の全作業が実行され、そのテキスト・フィールドがゾーン・テキスト・フィールドとして無効になると、索引はデータベースから削除されます。したがって、テキスト・フィールドをゾーン・テキスト・フィールドとして有効または無効にした後で、コレクションを再構築する必要はありません。
ゾーン・テキスト・フィールドは、無効にしなければ、構成マネージャを使用してコンテンツ・サーバー・インスタンスから削除できません。有効なテキスト・フィールドを構成マネージャを使用して削除し、「データベース設計の更新」をクリックすると、エラーが発生します。
ゾーン・テキスト・フィールドを無効にすることで、そのフィールドの索引がデータベースから削除され、フィールドをデータベースから削除できます。ゾーン・テキスト・フィールドを無効にするかわりに、データベースにログインし、フィールドの索引を削除するコマンドを発行して、フィールドを削除することもできます。
すべてのゾーン・テキスト・フィールドを無効する場合は、機能をアンインストールする前に行います。そうしないと、手動でゾーン・テキスト・フィールドを無効にするか、またはゾーン・テキスト・フィールドの索引をデータベースから削除する機能を再インストールしないかぎり、ゾーン・テキスト・フィールドをコンテンツ・サーバー・インスタンスから削除することはできません。
デフォルトでは、フィールド長が20文字以下のテキスト・フィールドは「テキスト・フィールド」リストに掲載されません。この設定を変更するには、 MinFullTextFieldLength 構成変数を変更します。この変数を変更するには、次の手順を完了します。
テキスト・エディタを使用して、IntradocDir/config/ディレクトリにあるconfig.cfgファイルを開きます。
MinFullTextFieldLength構成変数を追加し、その値を設定します(デフォルト値は21です)。例:
MinFullTextFieldLength=16
config.cfgファイルへの変更内容を保存します。
コンテンツ・サーバー・インスタンスを再起動します。
機能を無効にする前に、すべてのゾーン・テキスト・フィールドを無効にします。データベースには、有効なゾーン・テキスト・フィールドごとに索引が保存されています(索引は、ゾーン・テキスト・フィールドが無効になると削除されます)。データベースにフィールドの索引が保存されている場合、構成マネージャを使用してそのフィールドをコンテンツ・サーバー・インスタンスから削除することはできません。詳細は、4.2.4.2項「ゾーン・テキスト・フィールドの有効化および無効化」を参照してください。
機能を無効にした後で、ゾーン・テキスト・フィールドとして有効なフィールドを削除する場合は、次のいずれかの方法があります。
機能を再インストールし、ゾーン・テキスト・フィールドを無効にして、構成マネージャでフィールドを削除してから、機能をアンインストールします。
データベースにログインし、フィールドの索引を削除するコマンドを発行してから、構成マネージャを使用してフィールドを削除します。
Oracle Query Optimizerコンポーネントは、デフォルトではコンテンツ・サーバー・インスタンスによってインストール(有効化)されます。この機能は、Oracleデータベースでのみ機能します。
この項の内容は次のとおりです。
Oracleデータベースでは、一部のタイプのユーザー問合せに対して、最良の実行計画が自動的に選択されません。これに対処するため、Oracle Query Optimizerにより、Oracleデータベースで検索がより効率的に実行されるようにするヒントを問合せに追加します。
ヒントは、コンテンツ・サーバーの表データ配布およびその索引選択性の本質的な知識に基づいています。この知識を利用するために、Oracle Query Optimizerでは、事前定義のヒント・ルール表を使用して、データベース問合せを分析し、その問合せに適切なヒントを追加します。その結果、追加されたヒントにより、Oracleの検索効率が改善されます。
Oracle Query Optimizerでは、Content Serverのデータベース表でのデータ配布と、その索引選択プリファレンスを利用します。これらの特性に基づき、Oracle Query Optimizer付属のヒント・ルール表には、事前定義のルールが含まれています。この機能では、これらのルールを使用してデータベース問合せを分析し、検索効率を最適化するための1つ以上の適切なヒントを追加します。
数百万のコンテンツ・アイテムを含む非常に大きなコレクションでは、通常、コンテンツ・サーバー・ソフトウェアは、簡単な問合せを解決する場合でも、適切な最適化方法をなかなか選択できません。この問題に対処するために、Oracle Query Optimizerでは、発行された問合せを検査し、その分析に基づいて、検索プロセスを最適化する適切なヒントを追加することで、問合せを再フォーマットします。この機能では、ヒントを追加するために、コンテンツ・サーバーのヒント、ヒント・ルール表およびヒント・キャッシュが使用されます。
最適化プロセスのステージは、次の順序で完了します。
発行された問合せは、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項「再フォーマットされた問合せによる検索の最適化」を参照してください。
コンテンツ・サーバー・インスタンス内の大部分の問合せは、対象となるコンテンツ・アイテム・セットが小さいか、返す行が最大でも100行です。コンテンツ・サーバー・ソフトウェアは、簡単に数百万のコンテンツ・アイテムに対応できます。ただし、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万を超えるコンテンツ・サーバー・リポジトリの場合、この実行計画を使用して問合せを解決しようとしてもうまくいかないのは明らかです。この場合、結果を返すのに約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を共有するコンテンツ・アイテムがわずかなので、変更された問合せは即時に結果を返します。
標準的なコンテンツ・サーバー・インスタンスでは、大部分のドキュメントは、現在の日付より前の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'}
コンテンツ・サーバー問合せは、様々なリソースで定義されている静的問合せ、動的WHERE句が追加されているデータ・ソース、および臨時のまたはアーカイバなどのアプリケーションで定義されている動的問合せのいずれかです。静的問合せは、Oracleデータベースのヒントによって更新される場合があります。ただし、臨時の問合せや動的WHERE句のヒントを事前に定義することは、ほとんど不可能です。
コンテンツ・サーバーのヒントでは、同じ問合せ内で複数のヒントをサポートする、データベースを選ばないヒント構文が使用されます。コンテンツ・サーバーのヒントは、どの問合せ、データ・ソースおよびWHERE句でも使用できます。ただし、Oracleデータベースのヒントとは結合できません。1つの問合せに両方のタイプのヒントが含まれている場合、Oracle Query Optimizerでは、Oracleデータベースのヒントが保持され、コンテンツ・サーバーのヒントは無視されます。
最適化処理の各ステージで、Oracle Query Optimizerでは、両方のタイプのヒントの異なった構文を認識し、それに応じて発行された問合せを処理します。詳細は、4.2.5.2項「問合せの最適化プロセス」を参照してください。
コンテンツ・サーバーのヒントの構文は、データベースを選ばず、同じ問合せの中で複数のコンテンツ・サーバーのヒントをサポートできます。最適化プロセス中に、コンテンツ・サーバーのヒントは、評価され、最適のヒントが再フォーマットされて、元の問合せに追加されます。
最適化のプロセスでは、1つ以上のコンテンツ・サーバーのヒントを含む問合せは解析されません。コンテンツ・サーバーのヒントのみが、索引選択時に検討されます。
Oracle WebCenter 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 WebCenter 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 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時間ごとにディスクに格納され、コンテンツ・サーバー・インスタンスの起動時に再ロードされます。
ヒント・キャッシュには次の特性があります。
同じ問合せは、新しい値がヒント・ルールの条件を満たさない場合を除いて、その値に関係なく、同じキャッシュ・エントリに一致します。次の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'
ヒント・キャッシュでは、「ヒント・キャッシュ更新機能」ページを使用して、新規エントリの追加、既存エントリの編集または削除を行えます。ヒント・キャッシュ・エントリの追加または編集の際には、コンテンツ・サーバーのヒント構文を使用する必要があります。ヒント・キャッシュの管理機能は、問合せヒントの微調整に非常に役立ちます。次の例は、ヒント・キャッシュ・エントリの微調整の利点を示しています。
例: 索引のないコンテンツのバッチロード
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句およびヒントの適切な情報を入力します。
「削除」をクリックします。
フィールドに入力された情報が削除されます。問合せからの削除に成功したヒントとヒント・キャッシュの例は、この項のスクリーン・キャプチャを参照してください。
「ヒント・キャッシュ更新機能」ページで、「データ・ソースの使用」チェックボックスが選択解除になっていることを確認します。
「問合せコンバータ」ページのデータ・ソース関連のフィールドが非表示になります。
問合せおよびヒントの適切な情報を入力します。
「削除」をクリックします。
「データ・ソースの使用」チェックボックスの上に結果が表示されます。スクリーン・キャプチャでは、以前に追加されたヒントが、問合せおよびヒント・キャッシュから削除されたことに注意してください。
この項には次のトピックが含まれます:
|
注意: Oracleでは、WORMオプションが指定されたSun Storage Archive Manager(SAM-QFS)を、コンテンツ・サーバーの標準ファイル・ストア・システムの代替システムとしてサポートしています。詳細は、4.3.6項「Sun Storage Archive Manager」を参照してください。 SAM-QFSを使用するようにコンテンツ・サーバーを構成した後で、標準のファイル・ストア・システムを使用するように戻すことはできません。 |
バージョン11gリリース1の発売により、コンテンツ・サーバー・システムでは、コンテンツの格納および編成用の従来のファイル・システムにかわり、データ管理用のファイル・ストア・システムが実装されました。ファイル・ストア・プロバイダ・コンポーネントは、コンテンツ・サーバー・インタフェースでファイル・ストア機能を果たし、追加の構成オプションが可能です。たとえば、コンテンツ・サーバー・インスタンスを、ファイル・システムを使用するかわりに、バイナリ・ラージ・オブジェクト(BLOB)データ型を使用して、コンテンツをデータベースに格納するように構成できます。この機能にはいくつかの利点があります。
一貫したバックアップおよび監視プロセスのために、リポジトリ管理をデータベース管理と統合します。
ファイル・システムの方法での、ディレクトリ構造とディレクトリ当たりのファイル数に関連した制限を克服するのに役立ちます。
システム間でのコンテンツの配布をより簡単にする上で役立ち、コンテンツ・サーバー・システムの拡大縮小が容易になります。
たとえば、コンテンツ・アドレス・ストレージ・システムや、一部のビジネス用に必要な書込み専用デバイスなど、一般にファイル・システムとは関連付けられていない様々なタイプのストレージ・デバイスが使用できます。
|
注意: ファイル・ストア・プロバイダ・コンポーネントは、コンテンツ・サーバーのデプロイ時にデフォルトでインストール、有効化およびアップグレードされます。デフォルトのファイル・ストアがアップグレードされた後で、アンインストールまたは無効化を実行しないでください。詳細は、4.3.2項「ファイル・ストア・プロバイダのアップグレード」を参照してください。 コンテンツ・サーバー・ソフトウェアの旧バージョンを使用していて、デフォルトのファイル・ストアをまだアップグレードしていない場合、6.3.3.3項「コンポーネントの有効化と無効化」にある手順に従い、そのコンポーネントを無効にできます。 |
この項の内容は次のとおりです。
コンテンツ・サーバー・システムでは、電子ファイルおよびそれらの関連メタデータのストレージを追跡することにより、コンテンツを管理します。その結果、ユーザーはチェックイン・ファイル、すべての関連情報および関連レンディションの格納とアクセスが可能です。この項では、これまでコンテンツ・サーバー・システムで使用されてきたデータ管理方法と、ファイル・ストア・プロバイダ・コンポーネントでそれらにどのように対処するかについて説明します。
データ管理の前半は、コンテンツ・サーバー・リポジトリにチェックインした電子ファイルの格納です。コンテンツ・サーバー・システムでは、通常、ファイル保存は従来のファイル・システムによって行われ、電子ファイルは、ボールト・ディレクトリおよび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億を超えるような大規模システムに対応するため、コンテンツ・サーバー・システムでは、ファイル・ストアを使用するようになりました。これは、拡張性、柔軟性および管理容易性に効果を発揮します。
ファイル・ストア・プロバイダ・コンポーネントを使用すると、コンテンツ・サーバー・システムによって管理されるコンテンツの格納およびアクセスに、データ駆動型のルールを定義できます。ファイル・ストア・プロバイダには、次の機能が用意されています。
ファイルの場所を簡単に移動する機能
Web表示可能ファイルをオプションにする機能
ディレクトリの飽和状態を管理および制御する機能
サード・パーティの記憶装置を統合する機能
様々なストレージの例を使用、拡張および強化するAPI
ファイル・ストア・プロバイダにより、チェックインされたコンテンツおよび関連のメタデータは検査され、システム管理者によって設定された基準に基づきストレージ・ルールが割り当てられます。基準としてはメタデータ、プロファイルまたはその他の考慮事項が含まれます。ストレージ・ルールは、ボールト・ファイルおよびWebファイルをコンテンツ・サーバー・システムで格納する方法、およびWebサーバーによりアクセスする方法を決定します。
コンテンツ・サーバー・システム(ドキュメントなし)にはデフォルトで、ファイル・ストア・プロバイダ・コンポーネントがインストール、有効化およびアップグレードされます。アップグレードでは、ファイル・ストア・システム(DefaultFileStore)用のデフォルト値の入ったメタデータ・フィールドが作成されます。ドキュメントが含まれる既存のコンテンツ・サーバー・システムがあり、新しいバージョンのコンテンツ・サーバーにファイル・ストア・プロバイダがアップグレードされていない場合、ファイル・ストア・プロバイダのアップグレードは自動的には実行されません。
現在の設定からファイル・ストア・プロバイダをアップグレードしないようにするには、アップグレードのインストールの前に、構成変数FsAutoConfigure=falseをコンテンツ・サーバーのconfig.cfgファイルに追加する必要があります。
|
注意: コンテンツ・サーバー・インスタンスを起動して「管理サーバー」ページにアクセスし、「一般構成」画面の「追加の構成変数」フィールドで変数を設定すると、コンテンツ・サーバーにより自動的にファイル・ストア・プロバイダがアップグレードされます。 |
ドキュメントが含まれておらず、ファイル・ストア・プロバイダ・コンポーネントが自動的にアップグレードされているコンテンツ・サーバー・システムでは、次の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]
ドキュメントが含まれていて、ファイル・ストア・プロバイダ・コンポーネントのアップグレードがないコンテンツ・サーバー・システムでは、Revisions表が空ではないため、デフォルトのストレージ・ルールの分散がDefaultFileStoreに設定されていないという情報メッセージが返されます。
ファイル・ストア・システムを使用せずに、旧バージョンのコンテンツ・サーバー・システムを使用し、ファイル・ストア・プロバイダ・コンポーネントをアップグレードして実装しているサイトの場合、またはファイル・ストア・プロバイダ・コンポーネントを完全にアンインストールし、ファイル・ストア・プロバイダにより追加されたメタデータ・フィールドも削除したサイトの場合、ユーザーがドキュメントをチェックインしたとき、そのサイトには関連のストレージ・ルールがない(xStorageRuleフィールドがない)ことになります。このような状況の後でファイル・ストア・プロバイダが実装されると、ファイル・ストア・プロバイダの実装前にチェックインされたドキュメントには空のxStorageRuleフィールドが含まれます。この状況を解消するには、ユーザーはそれらのドキュメントのコンテンツ情報を更新する必要があります。ドキュメントはxStorageRuleフィールドのデフォルト値に更新され、ストレージ・ルールで指定されている場所に移されます。xStorageRuleの詳細は、4.3.3.1.2項「コンテンツ・サーバーのメタデータ・フィールド」を参照してください。
コンテンツ・サーバー・システムでは、コンテンツの格納および編成用の従来のファイル・システムのかわりに、データ管理用のファイル・ストアが使用されます。ファイル・ストア・プロバイダ・コンポーネントは、コンテンツ・サーバーのデプロイ時にデフォルトでインストールおよび有効化されます。ファイル・ストア・プロバイダ・コンポーネントでは、自動的にデフォルトのファイル・ストア(DefaultFileStore)をアップグレードし、Web、ボールトおよびWeb URLパス式の変更など、コンポーネントで公開される機能を利用できるようにします。
|
注意: コンテンツ・サーバーの実行にはパーティションは必要ありませんが、パーティションの作成前にコンテンツをチェックインしようとすると、ボールト・パス・ルートの変更や、新しい適格なストレージ・ルールの作成に失敗します。詳細は、ストレージ・ルールおよびパス構成に関する項を含む、4.3.3.3項「ファイル・ストア・プロバイダ・ストレージの原則」を参照してください。 |
|
注意: Oracle WebLogic Serverでは、作成されるパーティションごとに、Webレイアウト・ディレクトリを指す新しい仮想ディレクトおよびエイリアスを追加するように、コンテンツ・サーバー・インスタンス用のWebサーバーは構成されません。パーティションは、ボールト・ファイルに使用でき、Webファイル用にサポートされますが、デフォルトのボールトおよびWebレイアウト・ディレクトリ下にパーティション・ルートが存在している必要があります。 |
|
注意: リソース・ファイルは直接編集しないでください。リソース・ファイルの適切な変更は、コンテンツ・サーバー・ユーザー・インタフェース内で行うか、または追加のコンポーネント開発により行う必要があります。コンポーネント開発の詳細は、第6章「コンポーネントの管理」を参照してください。 |
ファイル・パスの定義および処理には、3つのリソース表が使用されます。PathMetaData表およびPathConstruction表のデフォルト値で、ほとんどのシナリオに対応できます。StorageRules表には、ストレージ・ルールの定義時に指定する値が格納されます。これら3つの表はプロバイダ固有で、そのことはdefaultfilestoreディレクトリのprovider.hdaファイルで定義されています。defaultfilestoreディレクトリは、IntradocDir/data/providersディレクトリにあります。4番目の表FileSystemFileStoreAlgorithmFilters表の変更には、Javaコードとともにコンポーネントが必要です。
この項の内容は次のとおりです。
ファイル・ストア・プロバイダ・コンポーネントは、コンテンツ・サーバー・データベース、コンテンツ・サーバー・メタデータ・フィールドおよびその他の構成ファイルに対して、いくつかの変更を加え、考えられる構成オプションを可能にします。
この項の内容は次のとおりです。
場合によっては、データベースに格納されたコンテンツを、ファイル・システム上に強制的に置くことが必要になります。その1例が、Oracle WebCenter Content: Inbound Refineryで、変換のためにファイルへのアクセス権が必要な場合です。ファイル・システム上に強制的に置かれたファイルは、一時キャッシュとみなされます。次の構成値は、一時的にキャッシュされたファイルをクリーンアップする時期を制御するために使用されます。システムでクリーンアップされるのは、FileCache表にエントリのあるファイルのみです。
| 変数 | 説明 |
|---|---|
|
最大キャッシュ・サイズをMBで指定します。デフォルト値は |
|
|
索引付けのサイクル中にキャッシュを削除するかどうかを指定します。デフォルトは、 |
|
|
各索引付けサイクルで削除するキャッシュ・ファイルの数を指定し、そのサイクルでのロードを制限します。デフォルトでは、索引付けサイクルのすべての対象キャッシュ・ファイルを削除します。 |
|
|
ファイルがキャッシュされるまでの最大保持期間を日数で指定します。デフォルト値は |
|
|
キャッシュされたファイルを削除できる最低保有期間を日数で指定します。デフォルト値は |
ファイル・ストア・プロバイダによりいくつかのコンテンツ・サーバー・メタデータ・フィールドが追加され、構成ファイルで使用する追加のオプションが利用できるようになります。
この項の内容は次のとおりです。
メタデータ・フィールドの構成
ファイル・ストア・プロバイダにより、コンテンツ・サーバー・インスタンスに次の3つのメタデータ・フィールドが追加されます。
xPartitionId: このメタデータ・フィールドは、PartitionList表とともに使用され、コンテンツ・ファイル・アイテムのrootの位置を決定します。パーティション選択アルゴリズムで値が指定されるため、このフィールドはユーザー・インタフェースで非表示にすることをお薦めします。
xWebFlag: このメタデータ・フィールドでは、コンテンツ・アイテムにWeb表示可能ファイルがあるかどうかを判断します。したがって、システムのコンテンツ・アイテムにボールト・ファイルしかない場合、このメタデータ・フィールドを削除すると、システムではWeb表示可能ファイルがあるものと予想し、システムに悪影響が生じる可能性があります。メタデータ・フィールドは、構成値WebFlagColumnによって指定できます。
xStorageRule: このメタデータ・フィールドでは、ファイルをどのように格納するかを指定します。メタデータ・フィールドは、構成値StorageRuleFieldで指定できます。
|
注意: これらのメタデータ・フィールドは、起動時にファイル・ストア・プロバイダによって追加され、削除されている場合は、コンテンツ・サーバー・インスタンスが再起動したときに再び追加されます。メタデータ・フィールドを永久に削除する必要がある場合、intradoc.cfgファイルにある構成変数 |
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
ファイル・ストア・プロバイダのデフォルト・ファイル・ストアがアップグレードされると、チェックインされたコンテンツおよび関連のメタデータが検査され、システム管理者によって設定された基準に基づきストレージ・ルールが割り当てられます。基準としてはメタデータ、プロファイルまたはその他の考慮事項が含まれます。ストレージ・ルールは、ボールト・ファイルおよびWebファイルをコンテンツ・サーバー・ソフトウェアで格納およびアクセスする方法、およびWebサーバーによりアクセスする方法を決定します。ファイルは、データベースに格納することも、1つ以上のファイル・システムまたは記憶媒体に格納することもできます。パーティションは、格納場所の管理に役立てるために作成できますが、必須ではありません。
|
注意: ファイル・ストア・プロバイダ・コンポーネントは、いったんコンテンツ・サーバーで使用されると、無効にすることはできません。 |
この項の内容は次のとおりです。
パーティションを作成すると、コンテンツ・サーバー・システムにより管理されるファイルへの追加のルート・パスを定義できますが、異なる場所や、異なるタイプの媒体への格納が必要です。パーティションは、パーティション・リスト・ページを使用して作成します。新規パーティションが作成されると、コンテンツ・サーバーにより、IntradocDir/data/filestore/config/ディレクトリにあるfsconfig.hdaファイルでPartitionListリソース表が変更されます。
|
注意: Oracle WebLogic Serverでは、作成されるパーティションごとに、Webレイアウト・ディレクトリを指す新しい仮想ディレクトおよびエイリアスを追加するように、コンテンツ・サーバー・インスタンス用のWebサーバーは構成されません。パーティションは、ボールト・ファイルに使用でき、Webファイル用にサポートされます。 |
コンテンツ・サーバー・インスタンスにパーティションを追加するには、次の手順を実行します。
コンテンツ・サーバー・インスタンスにシステム管理者としてログインします。
「管理」→「ファイル・ストアの管理」を選択します。
パーティションが定義されていない場合、「パーティションの追加」をクリックします。それ以外の場合は、「パーティションの追加/編集」ページが表示されます。
パーティション名を入力します。名前を一意にする必要があります。
パーティション・ルート、重複メソッドおよびその他の関連パラメータを変更します。詳細は、「パーティションの追加/編集」ページを参照してください。
「アクティブ」が有効であることを確認します。
「更新」をクリックします。パーティション・リスト・ページが表示されます。
ファイル・ストア・プロバイダはいつでも編集できます。プロバイダを編集するには、次の手順を実行します。
コンテンツ・サーバー・インスタンスにシステム管理者としてログインします。
「管理」→「プロバイダ」を選択します。「プロバイダ」ページが表示されます。
DefaultFileStoreプロバイダの隣にある「アクション」列の「情報」をクリックします。「ファイル・ストア・プロバイダ情報」ページが表示されます。
「編集」をクリックします。 「ファイル・ストア・プロバイダの編集」ページが表示されます。
必要な変更を加え、「更新」をクリックして、変更を送信します。「プロバイダ」ページが表示されます。
|
注意: 「更新」をクリックして変更を送信する前に、「ファイル・ストア・プロバイダの編集」ページから離れないでください。 |
コンテンツ・サーバー・インスタンスを再起動します。
|
重要: ストレージ・ルールは削除できません。各ストレージ・ルールについては、作成する前に慎重に検討してください。 |
|
注意: コンテンツがコンテンツ・サーバー・リポジトリにチェックインされた後でストレージ・ルールを変更すると、コンテンツ・サーバーでコンテンツを見失うことになる可能性があります。 |
ストレージ・ルールを追加または編集するには、次のようにします。
コンテンツ・サーバー・インスタンスにシステム管理者としてログインします。
「管理」→「プロバイダ」を選択します。「プロバイダ」ページが表示されます。
DefaultFileStoreプロバイダの隣にある「アクション」列の「情報」をクリックします。「ファイル・ストア・プロバイダ情報」ページが表示されます。
「編集」をクリックします。 「ファイル・ストア・プロバイダの編集」ページが表示されます。
「新規ルールの追加」をクリックするか、ストレージ選択リストから編集するルール名を選択し、「ルールの編集」をクリックします。「ストレージ・ルール名」ダイアログが表示されます。
ストレージ・ルールに必要な変更を加え、「OK」をクリックします。 「ファイル・ストア・プロバイダの編集」ページが表示されます。
|
注意: 編集中のストレージ・ルールに関連付けられたレコードがある場合、 |
「更新」をクリックします。「プロバイダ」ページが表示されます。
|
重要: 記憶域ルール内に定義されているWeb URLファイル・パスで使用されているWebルートが、コンテンツ・サーバーに定義されているデフォルトのweblayoutディレクトリ以外にある場合は、記憶域ルール内に使用されているWebルートのWebサーバーに別名または仮想ディレクトリを追加する必要があります。そうしない場合、コンテンツ・サーバーによりファイルへのアクセス場所が認識されません。仮想ディレクトリをWebサーバーに追加する手順の詳細は、Webサーバーに付属のドキュメントを参照してください。 |
コンテンツ・アイテムがコンテンツ・サーバーにチェックインされるとき、アイテムはメタデータ、ユーザーが選択したプライマリ・ファイルと、場合によっては代替ファイルで構成されています。代替ファイルは、ユーザーによって選択され、チェックインされる場合もあり、Web表示可能ファイルとみなされます。コンテンツ・サーバーへのファイル・システムによるアプローチでは、プライマリ・ファイルはDomainHomeディレクトリのルートにあるボールト・ディレクトリに格納され、ネイティブ・ファイルと呼ばれます。代替ファイルがチェックインされると、これもボールトに格納されますが、Webレイアウト・ディレクトリにコピーされるか、変換アプリケーション(Inbound Refineryなど)に渡されます。代替ファイルがチェックインされない場合は、ボールト・ディレクトリから2箇所に存在するWebレイアウト・ディレクトリへネイティブ・ファイルがコピーされます。代替ファイルがチェックインされず、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ファイルの両方がデータベースに格納されます。
このデータベース記憶域の例では、一貫したバックアップおよびプロセス監視のために、リポジトリ管理とデータベース管理を統合するという利点を提供し、ファイル・システムでのディレクトリ構造やディレクトリ当たりのファイル数に関連した制限の克服に役立ちます。
|
重要: 必要な場合、たとえば索引付けや変換の間、データベースに格納されたコンテンツ・アイテムを強制的にファイル・システムに置くことができます。ファイル・システム上のファイルは、一時キャッシュとして扱われ、IntradocDir/configディレクトリにあるconfig.cfgファイルで指定されているパラメータに続いて削除されます。使用されるパラメータの詳細は、4.3.4.7項「FileCache表」を参照してください。 |
例4
ストレージ・ルールは、「ストレージ・ルール名」ダイアログで「JDBCストレージ」として定義され、「レンディション」選択リストから「Webファイル」が選択されます。ここでは、ボールト・ファイルはデータベースに格納され、Webファイルはファイル・システムに永久的に格納されます。
ネイティブ・ファイルはデータベースに、Web表示可能ファイルはファイル・システムに格納するというこの混成アプローチには、前例のネイティブ・ファイルのデータベース記憶域(バックアップと監視を統合し、ファイル・システムの制限を克服)という利点があり、一方でWeb表示可能レンディションへの迅速なWebアクセスを実現します。最初の例と同様に、ファイル・システム構造が複雑すぎる場合や、ファイルの量が極端に多い場合には、この利点は少なくなる可能性があります。
コンテンツ・サーバー・システムに格納されているコンテンツへのパスは、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を取り込み、すべての適切なデリミタを使用して、標準のコンテンツ・サーバー・アカウント表現に解析する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$
この項の内容は次のとおりです。
PartitionList表では、partitionSelectionアルゴリズムに使用可能なパーティションが定義されています。表は、DomainHome/ucm/cs/data/filestore/config/ディレクトリにあるfsconfig.hdaファイルで定義されており、コンテンツ・サーバー・ユーザー・インタフェースの「パーティションの追加」/「パーティションの編集」ページを使用して変更されます。表の列は、次のように使用されます。
| 列 | 説明 |
|---|---|
|
パーティションの名前を指定します。この名前は、パス式内で参照されます。 |
|
|
partitionSelectionアルゴリズムに渡された引数。 |
|
|
パーティションが現在アクティブで、新規ファイルを受け入れるかどうかを確認します。 |
|
|
使用可能なディスク領域の確認に使用される間隔を秒単位で指定します。これは、すべてのプラットフォームで機能するわけではありません。 |
|
|
パーティションにコンテンツを格納するのに十分な領域があるかどうかを確認します。使用可能な領域が遊びバイトより少ない場合、パーティションは非アクティブになり、コントリビューションには使用されなくなります。 |
|
|
Web表示可能レンディションに変換されないネイティブ・ファイルをどのように扱うかを指定します。 コピー(デフォルト): ネイティブ・ファイルをWebパスにコピーします。 リンク: Webパスをボールトのネイティブ・ファイルに解決します。 コピーおよびリンクは、コンテンツ・サーバー・インスタンスがインストールされているオペレーティング・システムの機能に依存します。したがって、すべてのプラットフォームですべてのメソッドが使用可能というわけではありません。 |
StorageRules表では、コンテンツ・アイテムの格納に使用されるルールを定義します。ルールは、どのストレージ・クラスにどのパス式を使用するか、およびコンテンツ・アイテムをどのように格納するかを指定します。
表は、DomainHome/ucm/cs/data/providers/defaultfilestoreディレクトリにあるprovider.hdaファイルで定義されており、コンテンツ・サーバー・ユーザー・インタフェースの「ストレージ・ルール名」ダイアログを使用して変更できます。表の列は、次のように使用されます。
| 列 | 説明 |
|---|---|
|
ストレージ・ルールの名前。動的インクルードから計算され、コンテンツ・アイテムの |
|
|
ストレージの実装を指定します。 |
|
|
システムでWebレス・ファイルを使用できるかどうかの指定に使用されます。 true: デフォルトでは、新規作成されたコンテンツ・アイテムにWeb表示可能ファイルはありません。ある特定の状況では、Web表示可能ファイルにこだわる必要があります。そのような場合、呼出しコードの引数を使用して、Web表示可能ファイルを作成する必要があることを指定できます。Web表示可能ファイルがあるかどうかに関する情報は、 false: デフォルトでは、新規作成されたコンテンツ・アイテムにWeb表示可能ファイルがあります。 |
|
|
JdbcStorageにより、ファイルがデータベースのかわりにファイル・システムに格納されるかどうかを指定するために使用されます。 |
PathMetaData表では、ファイルの場所を決定するためにどのメタデータが使用されるかを定義します。メタデータは、コンテンツ・アイテムのメタデータから直接得たものか、またはアルゴリズムを使用して計算されます。PathMetaData表は、defaultfilestoreディレクトリのprovider.hdaファイルで定義されています。defaultfilestoreディレクトリは、DomainHome/ucm/cs/data/providers/ディレクトリにあります。
表の列は、次のように使用されます。
| 列 | 説明 |
|---|---|
|
パス式に表示されるフィールドの名前。 |
|
|
フィールドの値を解決または計算するために使用されるアルゴリズムを指定します。 |
|
|
どのストレージ・クラスにメタデータが必要なのかを定義します。 #all: ボールトおよびWeb表示可能の両レンディションで、メタデータが必要です。 web: Web表示可能レンディションにのみメタデータが必要です。 vault: ネイティブ・ファイル・レンディションにのみメタデータが必要です。 指定されていないすべてのレンディションでは、このフィールドはオプションです。したがって、この列が空の場合、すべてのレンディションまたはストレージ・クラスで、メタデータ・フィールドはオプションになります。アルゴリズムが指定されている場合、この値は空です。アルゴリズムでは、必要なフィールドを指定するために、ArgumentFields列で指定されている値を使用します。 |
|
|
GenerationAlgorithmフィールドで指定されているアルゴリズムに渡されるオプションの引数。 |
|
|
Arguments列で定義されている引数で必要とされ、その結果GenerationAlgorithmフィールドで指定されているアルゴリズムでも必要となるフィールドのカンマ区切りのリスト。 |
PathConstruction表では、ファイルをパスにマップします。PathConstruction表は、defaultfilestoreディレクトリのprovider.hdaファイルで定義されています。defaultfilestoreディレクトリは、DomainHome/ucm/cs/data/providers/ディレクトリにあります。詳細は、4.3.3.3.2項「パスの構成およびURLの解析」も参照してください。
|
注意: PathConstruction表で提供されているデフォルト値は、想定されるたいていの事態に機能します。このリソース・ファイルは直接編集しないでください。追加のコンポーネント開発により、適切な変更を行う必要があります。コンポーネント開発の詳細は、『Oracle WebCenter Content Content Server開発者ガイド』のコンポーネントに関する章を参照してください。 |
PathConstruction表の列は、次のように定義されています。
| 列 | 説明 |
|---|---|
|
計算されるストレージ・パスを指定します。 web: Web表示可能ファイルへのパス。 vault: ネイティブ・ファイルへのパス。 weburl: コンテンツ・サーバー・システムによって生成されます。GET_FILEになる傾向があります。 weburl.file: ブラウザでWeb表示可能レンディションにアクセスするために使用する正しい構成のURL。 dispersion: ファイル・システム上のコンテンツの分散用の変数。 FsWeblayoutDir: Webレイアウト・ディレクトリのWeb表示可能パス用の変数。 FsHttpWebRoot: Webレイアウト・ディレクトリのWeb URLファイル・パス用の変数。 |
|
|
パスを定義します。 |
|
|
作成される可能性のあるディレクトリの深さを指定します。 |
|
|
このパス構成が属するストレージ・ルールを指定します。 |
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 WebCenter Content Content Server開発者ガイド』を参照してください。 |
ファイル・ストア・プロバイダがインストールされると、FileStorage表がコンテンツ・サーバー・システムに追加されます。これは、コンテンツがデータベースに格納される場合に、JdbcStorageストレージ・タイプによって排他的に使用されます。FileStorage表には、コンテンツ・アイテムのレンディションが含まれていて、どのレンディションがどのコンテンツ・アイテムに属しているかを一意に識別するために、コンテンツ・アイテムおよびレンディションのdIDが使用されます。
この項では、例ごとに、プロバイダ定義ファイル(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表で定義する必要があります。ボールトのパス式は、すでに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$
これは次のような部分に解析されます。
| パス・セグメント | 説明 |
|---|---|
|
Webレイアウト・ディレクトリのWeb表示可能パスの変数。 |
|
|
Web URLの代替Idoc Script変数。 |
|
|
/groups/ |
文字列。 |
|
PathMetaData表により使用されます。これは必須フィールドであり、そのため呼出し側または記述子の作成者により指定される必要があります。これは、コンテンツ・アイテムのメタデータ情報の一部です。 |
|
|
これは、dDocAccountを取り込み、すべての適切なデリミタを使用して、標準のコンテンツ・サーバー・アカウント表現に解析するdocumentAccountアルゴリズムにマップされます。 |
|
|
/documents/ |
文字列。 |
|
PathMetaData表により使用されます。これは必須フィールドであり、そのため呼出し側または記述子の作成者により指定される必要があります。これは、コンテンツ・アイテムのメタデータ情報の一部です。 |
|
|
$dispersion$ |
ファイル・システム上のコンテンツの分散を実装します。 |
|
!edisp |
このマーカーが指定された箇所で分散が終了したことを示します。たとえ分散が空であっても、~edispマーカーが指定されます。 |
|
PathMetaData表により使用されます。これは必須フィールドであり、そのため呼出し側または記述子の作成者により指定される必要があります。これは、コンテンツ・アイテムのメタデータ情報の一部です。 |
|
|
これは、renditionSpecifierによって指定され、システムでサムネールなどの追加のレンディションを作成中の場合のみ必要です。それ以外の場合は、空の文字列を返します。 |
|
|
リビジョン・ラベルは、revisionLabelアルゴリズムによって指定され、コンテンツ・アイテムのステータスに応じて、パスに「~dRevLabel」が追加されます。 |
|
|
ここではextensionSeparatorアルゴリズムが使用され、デフォルトでは「.」を返します。 |
|
|
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)は、Sun Solarisオペレーティング・システムで実行される階層型ファイル・ストレージ・システムです。WORM(Write Once Read Many)オプションを指定して構成すると、ファイル・システム・データのアーカイブがサポートされ、ユーザーにはデータの読取りのみが許可されるようになります。SAM-QFS環境には、ストレージおよびアーカイブ・マネージャに加え、Sun QFSファイル・システム・ソフトウェアが含まれます。SAM-QFSは、コンテンツ・サーバー・マシンによるNFSマウントおよび追加のコンテンツ・サーバー構成で使用できます。
SAM-QFSは、次の2つの製品で構成されます。
Quick File System(QFS)は、カーネル・レベルのファイル・システムで、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が有効なストレージ・ルールでは、ネイティブ・ファイル・パスにメタデータ・フィールドを含めないように設定することをお薦めします。
SolarisシステムにSAM-QFSをインストールしてWORMを有効化する方法の詳細は、http://wikis.sun.com/display/SAMQFSDocs52/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オプション・パラメータを使用してデフォルトの保存期間を設定してください。
コンテンツ・サーバーでは、ビルトインのWebサーバーを持つOracle WebLogic Serverを使用して、Webブラウザを通してページをフィルタ処理します。ユーザー・リクエストは、Oracle WebLogic Serverユーザー・ストアにより認証され、コンテンツ・サーバー・インスタンスと通信します。
WebUrlMapPluginコンポーネントを使用すると、短縮形のURLを、マッピング用の置換スクリプトを使用して、他のURLにマップでき、これによって、長いURLを短縮形にマップすることもできます。WebUrlMapPluginコンポーネントは、デフォルトではコンテンツ・サーバー・インスタンスによりインストール(有効化)されます。
この項の内容は次のとおりです。
作成できる短縮形のURLでは、一般に次のフォーマットを使用します。
http://myhostexample.com/prefix/suffix
実際のマッピング・プロセスは、ホスト名の部分に続くURLの部分に基づきます。短縮形のURLを解決するため、コンテンツ・サーバー・インスタンスでは、接頭辞を定義済のWebUrlMapPluginエントリのリストのものと比較します。一致するものがある場合、コンテンツ・サーバー・インスタンスでは、一致する接頭辞に対応するマップ・スクリプトを使用して、該当するドキュメントまたはコンテンツ・サーバー・ページを表示します。接尾辞の詳細は、4.4.2項「参照用にサポートされている変数」を参照してください。
「Web URLマップ」画面を使用してURLマッピング・エントリを構成するには、接頭辞を確定し、対応するマップを定義する必要があります。
接頭辞
マッピング・エントリの接頭辞の部分は、特定の形のURLを識別するために使用する任意の短縮形です。たとえば、短縮形のURLでドキュメントの動的変換が返されるようにする場合、idcを自分の接頭辞として使用できます(たとえば、dynamic converterの短縮形)。
コンテンツ・サーバー・インスタンスでは、接頭辞テストの実行前に、受信したURLから最初のスラッシュが削除されるため、接頭辞を作成する際には、先頭にスラッシュ(/)文字を入力しないでください。
|
注意: URLマップの接頭辞の最後には、スラッシュ(/)を含めてください。そうしないと、マッピングが適用されるURLが増えて、標準的なコンテンツ・サーバーの操作の妨げになる可能性があります。 |
マップ
マッピング・エントリのマップの部分は、コンテンツ・サーバー・インスタンスで短縮形のURLを解決するために使用されるIdocスクリプト・コードです。マップの部分では、置換タグ(<!--$variable-->)を使用できます。次に例を示します。
<!--$cgipath-->
<!--$internetuser-->
<!--$suffix-->
これらの置換タグは、URLの該当するパラメータを参照する変数です。
単純なif構造体もサポートされています。たとえば、次のスクリプト・セグメントは、値が存在し、空でないかどうかを確認するためのテストを実行します。
<!--$if myconfigvar-->something<!--$endif-->
URLマッピング・エントリのマップ部分では、参照用の次の標準変数が使用されます。
CGIパス
これは、Oracle WebLogic Server Webサーバー・フィルタの構成済コンテンツ・サーバー・インスタンスの現在のCGIパスです。Webサーバー・フィルタは、このコンテンツ・サーバー・インスタンスのための通信とセキュリティの両方を提供するように構成されます。典型的な例は、/idcm1/idcplgです。
suffixパラメータ
接尾辞変数(<!--$suffix-->)の値は、URLで先行するマッピング接頭辞の後に続き、疑問符(?)の前にある部分から導出されます。接尾辞の先頭にあるスラッシュ(/)は、この変数に代入される前に削除されます。たとえば、次のURLでは、dcがマッピング接頭辞で、後に接尾辞が続きます。
http://myhostexample.com/dc/mydocumentname
スラッシュを削除した後、mydocumentnameが、マッピング・エントリのマップ部分で置換タグとして使用される接尾辞変数の値として使用されます。また、接尾辞変数には、CGIパラメータは含まれません。したがって、次のURLでは、mydocumentnameがそのまま接尾辞変数の値として使用されています。
http://myhostexample.com/dc/mydocumentname?a=1
接頭辞と接尾辞の間をスラッシュで強制的に区切るには、接頭辞の短縮形の最後にスラッシュを追加します。
任意のプラグイン変数
たとえば、現在ログインしているユーザーのユーザーIDと置換するために、構造体<!--$internetuser-->を使用できます。
任意のCGIパラメータ
URLマッピング・エントリを追加または編集するには、次のようにします。
「管理」→「WebUrlMapPlugin」を選択します。
「Web URLマップ」画面が表示されます。
「接頭辞」フィールドと「マップ」フィールドに適切な値を入力して、既存のマッピング・エントリを編集するか、新規のエントリを定義するか、またはその両方を行います。
「更新」をクリックします。
画面がリフレッシュされ、「接頭辞」フィールドと「マップ」フィールドの値が保存されます。表示されたすべてのフィールドに値が入っている場合、画面の再表示後に追加の「接頭辞」と「マップ」のフィールドのペアが2つ表示されます。
|
重要: WebUrlMapPlugin機能は、数百のマッピング・エントリをサポートするように設計されています。ただし、マッピング・エントリが数千に及ぶと、Webサーバーのパフォーマンスに影響が出るので注意してください。 |
既存のコンテンツ・アイテムに情報更新フォームを生成するために、短縮形のURLを作成できるようにするWeb URLマッピング・スクリプトを定義できます。ユーザーが特定のドキュメントに任意の識別変数を入力できるように、マッピング・スクリプトを作成できます。たとえば、次のフォーマットのURLがあるとします。
http://myhostexample.com/u/mydoc_parameter
このURLは、次のURLにマップできます。
http://myhostexample.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://myexamplename.com/dc/mydocumentname
このURLは、次のURLにマップできます。
http://myhostexample.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://myhostexample.com/dcp/mydocumentname?myparam=myvalue
このURLは、次のURLにマップできます。
http://myhostexample.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-->
この項の内容は次のとおりです。
プロバイダとは、コンテンツ・サーバー・インスタンスと外部エンティティ間の接続を確立するアプリケーション・プログラミング・インタフェース(API)です。これらのエンティティは、次のものが考えられます。
Oracle WebLogic Server
LDAPサーバー
データベース
サーバー・ソケット
ファイル・ストア・システム
Inbound Refinery
デフォルトでは、コンテンツ・サーバー・インスタンスには、3つのシステム・プロバイダがあります。
さらに、次のタイプのプロバイダを作成できます。
送信: 外部エンティティに対して開始された接続。このタイプを使用して、コンテンツ・サーバー・インスタンス間の通信ができます。送信プロバイダでSSLを使用する場合は、4.5.1.3項「セキュリティ・プロバイダ」で詳細を参照してください。
データベース: 接続および通信用のAPIを提供する情報リポジトリ・サーバー。これは、情報を取得し、情報をデータベースで変更できるようにします。このタイプの例は、システム・データベースです。
受信: :ブラウザまたはクライアント・アプリケーションのような、外部エンティティから開始された接続。プロバイダは、受信接続を認識するために、指定されたポート上でリスニングを行います。受信プロバイダでSSLを使用する場合は、4.5.1.3項「セキュリティ・プロバイダ」で詳細を参照してください。
LDAP: LDAP(ライトウェイト・ディレクトリ・アクセス・プロトコル)サーバーに対して開始される接続で、コンテンツ・サーバー・インスタンスに対する外部ユーザー・アクセスを管理します。このタイプのプロバイダは、Active Directory Ldapコンポーネントによってサポートされており、これはデフォルトではインストール時にインストール(無効化)されます。11g リリース1(11.1.1)以後、この機能はほとんどの場合(特にネストされたグループのサポートの場合)、JpsUserProviderがかわりに使用されています。
HTTP: HTTPプロトコルを使用して、コンテンツ・サーバー・インスタンス間の通信を可能にする接続。このタイプのプロバイダには、Proxy Credentials Extensionコンポーネントが必要で、これはデフォルトではコンテンツ・サーバー・インストール時にインストール(有効化)されます。
JpsUserProvider: Oracle WebLogic Serverインスタンスに対する接続。このプロバイダでは、Java Platform Security (JPS)を使用して、Oracle WebLogic Serverインスタンスを介したユーザー認証、ユーザー認可、およびユーザー・メタデータの取得を実行します。このタイプのプロバイダは、JpsUserProviderコンポーネントによってサポートされており、これはデフォルトではコンテンツ・サーバー・インスタンスとともにインストール(有効化)されます。
前項で説明した様々なタイプのプロバイダは、特定の状況の下で、その他の各種Oracle製品およびユーティリティを使用するために使用されます。この後の各項では、それらの状況と、各状況で使用する必要のある特定のプロバイダのタイプについて説明します。
送信プロバイダは、コンテンツ・サーバーのアーカイバ・ユーティリティおよびInbound Refineryを使用するために必要です。送信プロバイダでSSLを使用するか、キープアライブにする場合、4.5.1.3項「セキュリティ・プロバイダ」の詳細を参照してください。
アーカイバ・ユーティリティ(コンテンツ・サーバー): アーカイバは、核となるコンテンツ・サーバー・システム内のユーティリティで、システム管理者がコンテンツをコピーおよび削除し、今後の使用のために格納できるようにします。ユーザーは、コンテンツ・サーバー・インスタンスに一連のコンテンツを問い合せ、それをアーカイブにエクスポートできます。アーカイブはその他のコンテンツ・サーバー・インスタンスにインポートすることも、メタデータ・フィールドを変更した元のインスタンスにインポートすることもできます。
送信プロバイダは、ファイアウォールを越えて、あるいは1つのファイル・システムを共有していない2つのシステム間で、コンテンツをアーカイブするために使用されるアーカイバ転送機能を使用する際に必要です。転送機能、各種の転送および送信プロバイダの要件の詳細は、第8章「システム移行およびアーカイブの管理」を参照してください。
送信プロバイダおよび特定の各フィールドについての追加参照情報は、A.1.6.4項「送信ソケット・プロバイダ・ページ」を参照してください。
Inbound Refinery: Inbound Refineryサーバーでは、コンテンツ・サーバーにチェックインされたコンテンツを処理し、それを指定されたフォーマットに変換します。Inbound Refineryサーバーへの送信接続は、コンテンツ・サーバーとの通信に必要です。詳細は、『Oracle WebCenter Content Conversion管理者ガイド』を参照してください。
データベース・プロバイダは、外部データベースを使用するために必要です。デフォルトのコンテンツ・サーバー・データベースではないデータベースでデータベース問合せを実行する場合に、望ましい、または必要になることがしばしばあります。この場合、カスタマイズされたデータベース・プロバイダを作成して、データを処理しているデータベース管理システムに関係なく、任意のアプリケーションから任意のデータにアクセスできるようにすることが可能です。カスタマイズされたデータベース・プロバイダを使用して、外部データベースをコンテンツ・サーバー・システムに統合すると、1つの検索画面で検索結果を結合して表示できます。さらに、これらの外部データベース・ソースからデータをインポートできます。
管理者は、次の2つの方法のいずれかで、データベース・プロバイダを作成できます。
Oracle WebLogic Serverの管理コンソールを使用して、データベースにOracle WebLogic Serverデータ・ソースを作成し、コンテンツ・サーバー・データベース・プロバイダでそのデータ・ソースが使用できるように構成します。詳細は、Oracle Fusion Middleware Fusion Oracle Application Development Framework開発者ガイドの「WebLogicドメイン・サーバー用JDBCデータ・ソースの作成」の章を参照してください。
コンテンツ・サーバー・データベース・プロバイダを作成して、Oracle WebLogic Serverデータ・ソースを使用せずに、JDBC接続を介してデータベースに直接接続します。このモードは、構成内に事前に接続が存在するインスタンス用に提供されています。
コンテンツ・サーバー・データベース・プロバイダと特定の各フィールドに関する追加の参考情報は、A.1.6.5項「「データベース・プロバイダ」ページ」を参照してください。
受信プロバイダは、WebDAVサポートおよびコンテンツ・サーバー・アーカイバ・ユーティリティを使用するために必要です。受信プロバイダでSSLを使用するか、キープ・アライブにする場合、4.5.1.3項「セキュリティ・プロバイダ」の詳細を参照してください。
Oracle WebDAVサポート: コンテンツ・サーバーのリリース6.2では、受信プロバイダとコンテンツ・サーバーに統合されたTomcatサーブレット・エンジンを使用して、WebDAV(Webベース分散オーサリングおよびバージョニング)を実装できます。ただし、コンテンツ・サーバー・リリース7.0以上では、WebDAVのサポートはカスタム機能によって提供されるため、プロバイダおよびサーブレット・エンジンは不要になりました。
詳細は、Oracle WebCenter Content Content Serverアプリケーション管理者ガイドを参照してください。
アーカイバ・ユーティリティ(コンテンツ・サーバー): アーカイバは、核となるコンテンツ・サーバー・システム内のユーティリティで、システム管理者がコンテンツをコピーおよび削除し、今後の使用のために格納できるようにします。ユーザーは、コンテンツ・サーバー・インスタンスに一連のコンテンツを問い合せ、それを別のインスタンスにエクスポート、インポートまたはレプリケートしたり、メタデータ・フィールドを変更したりできます。システム内で最も頻繁に実行されるタスクは、情報の転送、バックアップおよび再編成です。
一般に、データまたはコンテンツ・アイテムが1つのリポジトリから別のリポジトリに移されると、アーカイバ・ユーティリティではプッシュ・テクノロジを使用してファイルを移動します。ただし、システムではファイルのプッシュよりプルが必要になることがあります。この場合、受信プロバイダを作成する必要があります。受信プロバイダと特定の各フィールドに関する追加の参考情報は、A.1.6.6項「「受信プロバイダ」ページ」を参照してください。
プレビュー・プロバイダは、HTMLプレビューおよびContent Categorizerを使用するために必要です。
HTMLプレビュー: HTMLプレビューは、公開Webサイトでユーザーのコンテンツがどのように表示されるのかのフィードバックを、即時にユーザーに提供する機能です。この機能によりユーザーは、コンテンツが実際にチェックインされる前に、元のコンテンツを変更できます。HTMLプレビューは、正しいメタデータがコンテンツに割り当てられていることをユーザーが確認するのにも役立ちます。プレビュー・プロバイダは、インストール・プロセス中に作成する必要があります。HTMLプレビューに関する追加の概要およびインストール情報は、Oracle WebCenter Content Content Serverアプリケーション管理者ガイドを参照してください。
Content Categorizer: Content Categorizerでは、コンテンツ・サーバーにチェックインするドキュメントや、メタデータを再適用する必要がある既存のドキュメントに対して、メタデータ値を提案します。Content Categorizerでドキュメントの構造上のプロパティが認識されるには、ファイルをXMLに変換する必要があります。
Content Categorizerの詳細は、Oracle WebCenter Content Content Serverアプリケーション管理者ガイドを参照してください。このマニュアルでは、必須またはオプションの追加製品の関連情報を提供しています。プレビュー・プロバイダと特定の各フィールドについての追加の参考情報は、A.1.6.7項「「プレビュー・プロバイダ」ページ」を参照してください。
Lightweight Directory Access Protocol (LDAP)は、TCP/IPで実行されるディレクトリ・サービス・プロトコルです。これは、ネットワーク内のリソース管理の高度な機能性を提供し、アプリケーションとともに使用して、セキュリティおよびユーザー認証を管理します。LDAPディレクトリ・サービス・モデルは、属性のコレクションに基づいており、情報ディレクトリに格納されている情報へのアクセスに使用されます。このように、LDAPは、ユーザー名およびパスワード資格証明のセットを認証ソースに照合して検証するために使用されます。このプロセスにより、ユーザーにはWebリソースにアクセスする権限が付与されます。
LDAPサーバーには、コンテンツ・サーバーやその他のOracle製品のモジュールなどのアプリケーションからアクセスできるユーザー関連情報のソースが1つあります。
|
注意: 11g リリース1(11.1.1)以後、コンテンツ・サーバーにはLDAPプロバイダ機能のかわりにJpsUserProviderが使用されています。コンテンツ・サーバーのユーザーおよびセキュリティ管理にコンテンツ・サーバーLDAPプロバイダを使用することはお薦めできません。4.5.1.2.6項「JpsUserProviderの使用が必要な状況」を参照してください。 |
LDAPサーバー(コンテンツ・サーバー・インスタンスと直接統合できるActive Directory以外)の使用を決定する場合、コンテンツ・サーバー・インスタンスとLDAPサーバー間の通信を設定するために、LDAPプロバイダを設定する必要があります。正しく構成されている場合、LDAPプロバイダでは、ロールの割当ておよびアカウント権限(Ldapプロバイダ・ページで定義)にリンクするマッピング・プロパティを通じて、外部ユーザーが認可されます。
LDAPプロバイダと特定の各フィールドに関する追加の参考情報は、A.1.6.8項「LDAPプロバイダ・ページ」を参照してください。
Oracle Fusion MiddlewareでサポートされるLDAPサーバーの詳細は、次のOracle Technology Networkで動作保証情報を参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
必須ではありませんが、コンサルティング・サービスを利用して、LDAPセキュリティ・モデルを作成し、LDAP統合をデプロイすることをお薦めします。詳細は、営業担当者にご連絡ください。
次のコンテンツ管理製品およびアーキテクチャでも、LDAP統合が役立つことがあります。
WebSphere上のポートレット: IBM WebSphereユーザーは、Oracle Content Integration Suiteを介してコンテンツ・サーバーにアクセスできます。このポータル・インタフェースにより、ユーザーや開発者は、フルテキストまたはメタデータ検索問合せに基づいて、コンテンツ・サーバーのコンテンツ・アイテムの取得、表示およびダウンロードができます。Content Integration Suiteを使用する場合は、WebSphereアプリケーション・サーバーをお薦めします。WebSphereポータル・サーバーを使用する場合は、Oracle Content Portal SuiteをContent Integration Suiteに追加することをお薦めします。
|
注意: WebSphere Application ServerでOracle WebCenter Contentアプリケーションを構成する場合、内部Lightweight Directory Application Protocol(LDAP)サーバーは、Oracle WebCenter Contentアプリケーションのユーザーおよびグループに対して自動的には構成されません。これらの構成タスクは、インストール後にOracle Internet Directoryなどの外部LDAPサーバーで手動で実行する必要があります。 詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。 |
Content Integration Suiteでは、データベースのかわりに、コンテンツ・サーバー・インスタンスに直接接続します。この直接接続により、Webサーバーでの認証ステップを回避し、開発者がユーザーの認証および認可を完全に制御できます。利点は、必要に応じて、Content Integration Suiteレイヤーでユーザーを認証できることです。アプリケーション・サーバー・レベルでLDAPサーバーと統合することも、コンテンツ・サーバー・インスタンスにパスワードの検証を要求することもできます。
WebSphereのContent Integration SuiteおよびContent Portal Suiteとの使用の詳細は、WebSphereポートレット・サーバー、WebSphereアプリケーション・サーバー、Oracle Content Integration SuiteおよびOracle Content Portal Suite付属のドキュメントを参照してください。
Content Tracker: Content Trackerは、組み合せたときに、ユーザーが標準ブラウザを使用して、統合された一連の分析ツールを介してコンテンツの使用を追跡できるソフトウェア機能の集まりから構築されるシステムです。コンテンツ・サーバー・インスタンスにより提供されるデータは、Webサーバー・ログ・データ、コンテンツ・サーバー・データおよびユーザー情報などのログ・データから導出されます。Content Trackerでは、このデータにアクセスし、データの分析を行い、説明的なレポートを作成します。LDAPディレクトリ・サーバーとContent Trackerの統合はオプションです。ただし、LDAPが使用される場合、LDAPプロバイダを作成する必要があります。
関連するデータ・リポジトリ、レポート生成、問合せの作成およびインストール手順の詳細は、Oracle WebCenter Content Content Serverアプリケーション管理者ガイドを参照してください。
システム定義のJpsUserProviderでは、コンテンツ・サーバー・インスタンスに接続し、Oracle WebLogic Server認証メカニズム(基本、フォーム、シングル・サインオン、WNAなど)をサポートします。Javaプラットフォーム・セキュリティ(JPS)には、バックエンドのユーザー・ストレージ(XML、LDAP、データベース、Active Directoryなど)に関係なく、Oracle WebCenterアプリケーションからユーザーの認証および認可を行う統一インタフェースがあります。JPS APIコールは、ユーザー認証、ユーザー認可およびユーザー・メタデータ取得の実行に使用されます。
|
注意: 11g リリース1(11.1.1)以後、コンテンツ・サーバー・インスタンスでは、特にネストされたグループのサポートの場合などに、JpsUserProviderが直接のLDAPプロバイダ機能のかわりに使用されています。 |
JpsUserProviderコンポーネントは、コンテンツ・サーバー・インスタンスがOracle WebLogic Serverインスタンスに対してインストールされているときに、システム・コンポーネントとしてインストールし、有効化します。JpsUserProviderは、標準のコンテンツ・サーバー・コンポーネントとしても使用可能です。
|
注意: サイトでシステム定義のJpsUserProviderに加えてさらにJpsUserProviderが追加されることはまずありません。そのように別のプロバイダを追加すると、コンテンツ・サーバーのインストールに問題が生じる可能性があります。 |
JpsUserProviderの構成は、コンテンツ・サーバー・インスタンスの「プロバイダ」ページから編集できます。接続の構成も、アイデンティティ・ストアおよび資格証明ストアを使用するように、jps-config.xmlファイルを介して編集できます。
JPSストアに対する認証を行う必要がある場合は、JpsUserProviderを使用すれば、Oracle WebLogic Serverインスタンス上の別のアプリケーションと同じセキュリティ記憶域を共有できます。たとえば、JpsUserProviderを使用すると、Oracle WebLogic Serverインスタンスにインストールされているイメージおよび処理マネージャ・ソフトウェアと、セキュリティ記憶域を共有できます。
|
注意: 11gリリース1(11.1.1.6.0)以降、Oracle WebCenter ContentではOracle Virtual Directoryライブラリ(LibOVD)機能の使用がサポートされるようになり、これにより、サイトではJpsUserProviderを通じてログイン用の複数のプロバイダおよびグループ・メンバーシップ情報を使用できるようになりました。たとえば、Oracle Internet Directory(OID)とActive Directoryの両方をユーザーおよびロール情報のソースとして使用できます。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「Oracle WebLogic Serverにおける複数LDAP構成」を参照してください。 |
JpsUserProviderを介してLDAPサービスからWebCenter Contentにカスタム・フィールドをマップする場合に、カスタム・フィールドが空であった場合のデフォルトの動作では、何のアクションも実行されません。たとえば、値123456789を持つカスタム・フィールドがあり、この値を削除すると、WebCenter Contentでは欠落している属性が無視され、通常カスタム・フィールドが空になることはないという原則に基づいて、引き続き123456789が反映されます。WebCenter Contentでカスタム・フィールドを空にするには、JpsUserProviderのprovider.hdaファイルで変数ClearMissingAttributes=trueを有効化および設定して、デフォルト動作を変更する必要があります。このファイルのデフォルトの場所は、domain_home/ucm/cs/data/providers/jpsuserprovider/provider.hdaです。ファイル内の@end行より前に変数を追加してください。例:
SourcePath=jpsuser ProviderClass=idc.provider.jps.JpsUserProvider ClearMissingAttributes=true @end
この変数の詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。
JpsUserProviderのprovider.hdaファイルで変数ProviderCredentialsMap=name_of_mapを有効化および設定して、JpsUserProviderに資格証明マップを定義できます。この変数の詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。詳細は、5.8.2項「資格証明マッピング」を参照してください。
この項の内容は次のとおりです。
セキュリティ・プロバイダ・コンポーネントは、基本の受信および送信ソケット・プロバイダに2つの新しいタイプのプロバイダを加えて拡張することで、セキュリティ強化に使用できます。
Secure Socket Layer (SSL)プロバイダ
キープアライブ・プロバイダ
セキュリティ・プロバイダを鍵および証明書とともに適切に使用すると、コンテンツ・サーバー・インスタンスとのネットワークおよびインターネット通信のセキュリティを強化できます。セキュリティ・プロバイダ・コンポーネントを使用することの利点には、次のものがあります。
通信の暗号化および認証を提供することにより、SSLがWeb通信のセキュリティを強化します。
セキュリティ・プロバイダにより、ソケットまたはサーバー認証に証明書を使用できます。
キープアライブおよび接続プーリング・ロジックは、SSLソケットの作成および解除の量を減らすことで、SSL費用のオーバーヘッドを避けるのに役立ちます。
セキュリティ・プロバイダ・コンポーネントは、デフォルトではコンテンツ・サーバー・インスタンスによりインストール(有効化)されます。
参照
セキュリティ・プロバイダ・コンポーネントを使用するには、ソケット・プロバイダ、セキュリティおよび認証、SSL、キープアライブ、およびネットワーク通信のその他のセキュリティ面に精通している必要があります。セキュリティ・プロバイダ・コンポーネントの使用については、次の情報源が役立ちます。
『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およびキープアライブ・プロバイダ・タイプについてより多くの情報を提供しています。
キープアライブ接続
キープアライブ機能は、永続的接続やサービス・リクエスト用のソケット接続のプーリングを可能にします。キープアライブ接続の設定は、接続の設定および解除に時間がかかる可能性のあり、そのアクティビティにかかる時間を最小限にする必要がある場合に、最も役に立ちます。セキュリティ・プロバイダ・コンポーネントは、受信および送信の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/ディレクトリに格納することをお薦めします。コンテンツ・サーバー・インスタンスのプロバイダ・ページを使用して、エイリアスおよびパスワードを設定します。
キーストアを生成するキーツール・ユーティリティの使用方法の詳細は、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 WebCenter 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ブラウザを使用して、コンテンツ・サーバーのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「新規プロバイダの作成」表で、outgoingプロバイダ・タイプの「アクション」列の「追加」をクリックします。
送信ソケット・プロバイダ・ページが表示されます。
次の構成値を入力します。
必須のフィールド
プロバイダ名
プロバイダの説明
サーバー・ホスト名
サーバー・ポート
プロバイダ・クラス(事前定義)
オプションのフィールド
接続クラス(事前定義)
構成クラス
相対Webルート
HTTPサーバー・アドレス
インスタンス名
必要なロール
アカウント・フィルタ
オプションのチェック・ボックス
プロキシ
ターゲットへの通知
ユーザー
リリースされたドキュメント
「追加」をクリックします。
「プロバイダ」表に追加した新規プロバイダが入った「プロバイダ」ページが表示されます。
コンテンツ・サーバー・インスタンスを再起動します。
データベース・プロバイダの構成は、Oracle WebCenter Contentおよびコンテンツ・サーバー・インスタンスがOracle WebLogic Serverドメインにインストールされるときに指定されます。
|
注意: スタンドアロン・コンテンツ・サーバー・システムのデータベース接続を構成する場合、3.4.2.1項「スタンドアロン・モード用のシステム・データベース・プロバイダの構成」、3.4.2.2項「スタンドアロン・モード用のJDBCデータベース・ドライバの構成」および3.4.2.3項「スタンドアロン・モード用の外部データベース・プロバイダの構成」を参照してください。 |
データベース・プロバイダを追加するには、次のようにします。
Webブラウザを使用して、コンテンツ・サーバーのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「新規プロバイダの作成」セクションで、databaseプロバイダ・タイプの「アクション」列の「追加」をクリックします。
データベース・プロバイダのページが表示されます。
次の構成値を入力します。
必須のフィールド
プロバイダ名
プロバイダの説明
プロバイダ・クラス(事前定義)
データベース・タイプ
JDBCドライバ
JDBC接続文字列
問合せのテスト
オプションのフィールド
接続クラス(事前定義)
構成クラス
データ・ソース
データベース・ディレクトリ
データベース名
JDBCユーザー
JDBCパスワード
接続の数(デフォルト指定)
追加のストレージ・キー(デフォルト指定)
追加設定
オプションのチェック・ボックス
データ・ソースの使用
「追加」をクリックします。
「プロバイダ」表に追加した新規プロバイダが入った「プロバイダ」ページが表示されます。
コンテンツ・サーバー・インスタンスを再起動します。
プロバイダを使用してサーバー・ソケットに接続するには、コンサルティング・サービスが必要です。
受信プロバイダを追加するには、次のようにします。
Webブラウザを使用して、コンテンツ・サーバーのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「新規プロバイダの作成」セクションで、incomingプロバイダ・タイプの「アクション」列の「追加」をクリックします。
受信プロバイダのページが表示されます。
次の構成値を入力します。
必須のフィールド
プロバイダ名
プロバイダの説明
サーバー・ポート
プロバイダ・クラス(事前定義)
オプションのフィールド
接続クラス(事前定義)
構成クラス
「追加」をクリックします。
「プロバイダ」表に追加した新規プロバイダが入った「プロバイダ」ページが表示されます。
コンテンツ・サーバー・インスタンスを再起動します。
プレビュー・プロバイダを追加する手順は、Oracle WebCenter Content Content Serverアプリケーション管理者ガイドを参照してください。HTMLプレビュー機能のzipファイルおよびガイドは、Oracle Technology NetworkのWebサイトからダウンロードできます。
受信セキュリティ・プロバイダを追加するには、次の手順に従います。
Webブラウザを使用して、コンテンツ・サーバーのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「新規プロバイダの作成」表で、keepaliveincomingまたはsslincomingプロバイダ・タイプの「アクション」列の「追加」をクリックします。keepaliveincomingプロバイダのページまたはsslincomingプロバイダのページが表示されます。
次の構成値を入力します。
必須のフィールド
プロバイダ名
プロバイダの説明
プロバイダ・クラス(事前定義)
サーバー・ポート
オプションのフィールド
接続クラス(事前定義)
構成クラス
サーバー・スレッド・クラス(事前定義)
オプションのチェックボックス(sslincomingプロバイダのみ)
クライアント認証をリクエスト
クライアントの認証が必要
「追加」をクリックします。「プロバイダ」表に追加した新規プロバイダが入った「プロバイダ」ページが表示されます。
コンテンツ・サーバー・インスタンスを再起動します。
送信セキュリティ・プロバイダを追加するには、次の手順に従います。
Webブラウザを使用して、コンテンツ・サーバーのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「新規プロバイダの作成」表で、keepaliveoutgoingまたはssloutgoingプロバイダ・タイプの「アクション」列の「追加」をクリックします。keepaliveoutgoingプロバイダのページまたはssloutgoingプロバイダのページが表示されます。
次の構成値を入力します。
必須のフィールド
プロバイダ名
プロバイダの説明
プロバイダ・クラス(事前定義)
サーバー・ホスト名(事前定義)
サーバー・ポート
インスタンス名
相対Webルート
オプションのフィールド
接続クラス(事前定義)
構成クラス
リクエストのクラス(事前定義)
接続の数(事前定義)
HTTPサーバー・アドレス
必要なロール
アカウント・フィルタ
オプションのチェック・ボックス
プロキシ
ターゲットへの通知
ユーザー
リリースされたドキュメント
「追加」をクリックします。「プロバイダ」表に追加した新規プロバイダが入った「プロバイダ」ページが表示されます。
コンテンツ・サーバー・インスタンスを再起動します。
Oracle JPS(Oracle WebLogic Serverインスタンス用)を統合するデフォルトのJPSユーザー・プロバイダは、WebCenter Contentシステムをインストールすると提供されます。もう1つのJPSユーザー・プロバイダが必要になることはまずありません。ただし、ユーザー・プロバイダを1つ追加する必要がある場合は、次の手順に従います。
Webブラウザを使用して、コンテンツ・サーバーのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「新規プロバイダの作成」表で、jpsuserプロバイダ・タイプの「アクション」列の「追加」をクリックします。
JPSユーザー・プロバイダのページが表示されます。
次の構成値を入力します。
必須のフィールド
プロバイダ名
プロバイダの説明
プロバイダ・クラス(事前定義)
ソース・パス
オプションのフィールド
接続クラス
構成クラス
JPSコンテキスト
デフォルト・ネットワーク・ロール
属性マップを指定するには、次のようにします。
「JPS属性」リストから情報フィールドを選択します。
「ユーザー属性」リストからコンテンツ・サーバーのユーザー情報フィールドを選択します。
「追加」をクリックします。
テキスト・ボックスに、その属性マップが追加されます。
必要ならば、「属性マップ」テキスト・ボックスで属性を直接編集します。
必要ならば、デフォルト・ネットワーク・ロールを変更または追加します。
「追加」をクリックします。
「プロバイダ」表に追加した新規プロバイダが入った「プロバイダ」ページが表示されます。
コンテンツ・サーバー・インスタンスを再起動します。
Webサーバーを再起動します。
HTTP送信プロバイダを追加するには、次の手順を実行します。
Webブラウザを使用して、コンテンツ・サーバーのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「新規プロバイダの作成」表で、httpoutgoingプロバイダ・タイプの「アクション」列の「追加」をクリックします。
送信Httpプロバイダのページが表示されます。
次の構成値を入力します。
必須のフィールド
プロバイダ名
プロバイダの説明
プロバイダ・クラス(事前定義)
CGI URL
インスタンス名
相対Webルート
オプションのフィールド
接続クラス(事前定義)
構成クラス
接続パスワード名
接続パスワード
クライアントのIPフィルタ
「追加」をクリックします。
「プロバイダ」表に追加した新規プロバイダが入った「プロバイダ」ページが表示されます。
コンテンツ・サーバー・インスタンスを再起動します。
既存のプロバイダ(デフォルトのシステム・プロバイダを除く)の情報を編集するには、次のようにします。
Webブラウザを使用して、コンテンツ・サーバーのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「プロバイダ」表で、編集するプロバイダの「アクション」列の「情報」をクリックします。
プロバイダ情報ページが表示されます。
「編集」をクリックします。
「プロバイダの追加/編集」ページが表示されます。
必要な変更を行います。
「更新」をクリックして変更内容を保存し、「プロバイダ」ページに戻ります。
コンテンツ・サーバー・インスタンスを再起動します。
既存のプロバイダ(デフォルトのシステム・プロバイダを除く)を削除するには、次のようにします。
Webブラウザを使用して、コンテンツ・サーバーのホームページにアクセスし、「管理」→「プロバイダ」を選択します。
「プロバイダ」ページが表示されます。
「プロバイダ」表で、削除するプロバイダの「アクション」列の「情報」をクリックします。
プロバイダ情報ページが表示されます。
「削除」をクリックします。
確認画面が表示されます。
「OK」をクリックします。
「プロバイダ」表からそのプロバイダが削除されます。
|
重要: 単に情報を編集するのではなく、プロバイダの削除が目的であることを確認してください。プロバイダを削除すると、プロバイダ名およびその関連情報すべてが、「プロバイダ」表から永久に削除されます。 |
