| Oracle® Fusion Middleware Content Serverアプリケーション管理者ガイド 11g リリース1 (11.1.1) B65036-01 |
|
 前 |
 次 |
ホーム > アプリケーション管理者ガイド > リポジトリ・コンテンツの管理
| Oracle® Fusion Middleware Content Serverアプリケーション管理者ガイド 11g リリース1 (11.1.1) B65036-01 |
|
前 |
次 |
ホーム > アプリケーション管理者ガイド > リポジトリ・コンテンツの管理
この章では、リポジトリ・コンテンツの管理に関する次の項目について説明します。
ファイルは、コンテンツ・サーバーで、コンテンツ・タイプ別に指定されたディレクトリにグループ化されます。
コンテンツ・タイプは、ドキュメントがWebレイアウト・ディレクトリとボールト・ディレクトリに格納されているサブディレクトリの名前になります。
コンテンツ・タイプは、部門(ENG、MKTG、HRなど)、ドキュメント・タイプ(MEMO、FORM、SPREADSHEETなど)、または使用する他のモデルに対応付けることができます。
コンテンツ・サーバーには、複数のコンテンツ・タイプ(ドキュメント、バイナリ、デジタル・メディアなど)がデフォルトで定義されていますが、これらは編集または削除できます。
各コンテンツ・タイプにはイメージが割り当てられているため、ユーザーは検索結果ページでコンテンツ・タイプを容易に識別できます。コンテンツ・サーバーには複数のイメージが用意されていますが、独自のイメージを作成して割り当てることもできます。
作成するコンテンツ・タイプは、管理可能な数(通常は50以内)にしてください。コンテンツ・タイプの数が多すぎると、システムのメンテナンスに必要な作業量が増加し、コントリビュータによるファイルへの正しいコンテンツ・タイプの割当てが困難になります。
コンテンツ・タイプの構成時に、類似した情報をグループ化する場合は、1つのコンテンツ・タイプで同じ接頭辞を使用することを検討してください。たとえば、接頭辞MEMOは、MEMO_INT、MEMO_EXT、MEMO_EXECのコンテンツ・タイプで使用されます。
次に、コンテンツ・タイプを処理する際に使用する一般的なタスクを示します。
新しいコンテンツ・タイプを作成する手順は、次のとおりです。
構成マネージャ・アプリケーション・ページの「オプション」メニューから「コンテンツ・タイプ」を選択します。
「コンテンツ・タイプ」画面が表示されます。
「追加」をクリックします。
「名前」および「説明」を入力します。
「GIF」リストからイメージを選択します。
「OK」をクリックします。
|
注意: 新しいコンテンツ・タイプを追加した場合は、スキーマを更新してメタデータ・フィールドまたはオプション・リストの値を確認する必要があります。スキーマの詳細は、「DCLおよびメタデータ・スキーマについて」を参照してください。 |
コンテンツ・タイプを編集するには:
構成マネージャ・アプリケーション・ページの「オプション」メニューから「コンテンツ・タイプ」を選択します。
「コンテンツ・タイプ」画面が表示されます。
「編集」をクリックします。
変更を行い、「OK」をクリックします。
コンテンツ・タイプを削除するには:
削除するコンテンツ・タイプにコンテンツ・アイテムが割り当てられていないことを確認します。(削除するコンテンツ・タイプを使用しているコンテンツがまだ存在している場合、そのコンテンツ・タイプは削除できません。)
「コンテンツ・タイプ」画面で、削除するコンテンツ・タイプを選択します。
「削除」をクリックします。
確認画面が表示されます。
「はい」をクリックします。
|
注意: コンテンツ・サーバーがInbound Refineryインスタンスを処理するように構成されていない場合は、ネイティブ・ファイルの変換方法を指定する必要はありません。これらはすべて、ネイティブ・フォーマットのままWebサイトに渡されます。 |
この項には、次の項目が含まれます。
コンテンツ・サーバーがInbound Refineryインスタンス用のプロバイダとして構成されている場合は、ファイル拡張子に基づいて、変換用にリファイナリに渡すファイル・フォーマットをコンテンツ・サーバーに通知する必要があります。このことは、2つの方法で行うことができます。
「管理」トレイの「リファイナリ管理」からアクセスするファイル・フォーマット・ウィザードを使用する方法
構成マネージャ・アプレットの「ファイル・フォーマット」オプションを使用してファイル拡張子(.doc、.txtなど)をファイル・フォーマットにマップした後、リファイナリでファイル・フォーマットを変換オプションにマップする方法
2番目のオプションには、様々なファイル拡張子を様々な変換オプションにマップする柔軟性があります。
ジョブがコンテンツ・サーバーからInbound Refineryに渡された後は、リファイナリの構成によって、ネイティブ・ファイルを変換する方法およびコンテンツ・サーバーに返す方法が決定されます。
ファイル・フォーマットはインストール時に自動的に構成されますが、必要に応じて追加または変更できます。
変換の詳細は、『Oracle Fusion Middleware Conversion管理者ガイド』を参照してください。
構成マネージャを使用してファイル変換を処理する以外に、ファイル・フォーマット・ウィザードを使用できます。その機能にアクセスするには、メイン・メニューから「管理」→「リファイナリ管理」をクリックします。
新しいファイル・フォーマットには、ファイル拡張子に対応するMIME(Multipurpose Internet Mail Extensions)タイプによって名前を付けることをお薦めします(たとえば、docファイル拡張子にマップされるフォーマットはapplication/mswordになります)。
コンテンツ・アイテムがコンテンツ・サーバーにチェックインされると、そのコンテンツ・アイテムのフォーマットは、ネイティブ・ファイルのファイル拡張子にマップされているフォーマットに従って割り当てられます。ネイティブ・ファイルが変換されない場合、コンテンツ・サーバーでは、コンテンツ・アイテムをクライアントに配信する際にこのフォーマットを含めます。フォーマットにMIMEタイプを使用すると、クライアントでは、ファイルのデータのタイプや使用する必要があるヘルパー・アプリケーションなどの判断に役立ちます。
MIMEタイプは、http://www.iana.org/assignments/media-types/index.htmlにある登録済のMIMEタイプのリストを確認することで識別できます。
変換プログラムが正常に動作するように、コンテンツの変換に使用しているネイティブ・アプリケーションに対して、次の設定ステップを実行します。
| ネイティブ・アプリケーション | 要件 |
|---|---|
| MS Word
MS Project Lotus Freelance MS Excel Lotus 123 Corel WordPerfect MS PowerPoint Lotus WordPro MS Visio iGrafx Designer |
Inbound Refineryで変換用に必要な場合は、ネイティブ・アプリケーションがインストールされていることを確認します。
「ファイル・フォーマット」タブで、ファイル・タイプを変換プロセスに関連付けます。 WordおよびPowerPointアプリケーションの場合は、「ローカルInbound Refineryの構成」画面の「ネイティブ・オプション」タブを使用して、リンクを処理するかどうかを指定します。 |
| MS Publisher
FrameMaker* PhotoShop PageMaker |
ネイティブ・アプリケーションがインストールされていることを確認します。
Inbound Refineryでファイル・パスを構成します。 「ファイル・フォーマット」タブで、ファイル・タイプを変換プロセスに関連付けます。 |
| その他 | ネイティブ・アプリケーションがインストールされていることを確認します(必要な場合)。
Inbound Refineryにカスタム変換プログラムをインストールします。 Inbound Refineryでファイル・パスを構成します。 「ファイル・フォーマット」タブで、ファイル・タイプを変換プロセスに関連付けます。 |
FrameMakerブックをチェックインするには、「複数ファイルのアップロード」オプション(「システム・プロパティ」で有効にする必要があります)を使用します。
ファイル・タイプを変換プログラムに関連付ける手順は、次のとおりです。
「ファイル・フォーマット」画面の「ファイル・フォーマット」ペインで、「追加」をクリックします。
フォーマット名を変換プログラムに関連付けるための情報を入力します。変換に関する選択肢は次のとおりです。
「OK」をクリックします。
「ファイル・フォーマット」画面の「ファイル拡張子」ペインで、「追加」をクリックします。
「ファイル拡張子の追加」/「ファイル拡張子の編集」画面が表示されます。
新しい拡張子を入力し、フォーマット名にマップします。フィールドの説明は次のとおりです。
拡張子: この拡張子のファイルは、「マップ先フォーマット」フィールドで指定した変換プログラムを使用して変換されます。
マップ先フォーマット: このリストには、変換を指定した使用可能なフォーマット(ドキュメント・フォーマット・ペインで定義)が表示されます。フォーマットを直接選択すると、該当する拡張子のファイルはすべて、特定の変換プログラムに関連付けられます。
「OK」をクリックします。
作成できるカスタム・フィールドには、索引が作成されて検索が可能なメタデータ・フィールドと、コンテンツ・サーバーのフォームのカスタマイズに使用されるアプリケーション・フィールドの2つのタイプがあります。
コンテンツ・サーバー環境には、2つのタイプのカスタム・フィールドを作成できます。
アプリケーション・フィールドは、索引が作成されず検索もできませんが、コンテンツ・サーバーのフォームおよび画面のカスタマイズに使用されます。「アプリケーション・フィールドについて」を参照してください。
メタデータ・フィールドは、索引付けされているため検索可能です。「メタデータ・フィールドについて」を参照してください。
アプリケーション・フィールドは、カスタム・コンポーネント、HCSPファイルおよびHCSFファイルで使用するために作成できるカスタム・フィールドです。アプリケーション・フィールドを使用すると、依存選択リストなどのコンテンツ・サーバー機能をフォームで使用できます。デフォルトでは、これらのフィールドは標準のチェックイン・フォームおよび検索フォームには表示されませんが、カスタム・テンプレートでは使用されます。
アプリケーション・フィールドには保存済の値がないため、索引付けされていません。これらは、プレースホルダとして使用でき、関連するメタデータ・フィールドを作成せずに依存選択リストを有効にするために、スキーマ・ビューと組み合せて使用できます。スキーマの詳細は、「スキーマを使用したメタデータのカスタマイズ」を参照してください。
各コンテンツ・アイテムについて、システムでは、そのコンテンツに関する一連の情報(メタデータ)がメンテナンスされます。メタデータは、図書館のカード目録にあるカードに類似しており、実際のファイルは図書館の本に類似しています。カード目録と同様に、メタデータはファイルに関する情報(タイトル、参照番号、作成者、件名、公開日、ブックの場所など)で構成されています。
ファイルの内容全体をスキャンするフルテキスト検索に対して、メタデータ検索の実行では、メタデータのみが検索されます。
コンテンツ・サーバーには、変更または削除できない複数の標準メタデータ・フィールドが事前定義されています。これらの事前定義済フィールドとは別に、機能を拡張し、サイトの設計要件に対応するために新しいフィールドを作成できます。ファイル検索を容易にするために必要な追加メタデータ・フィールドは、必要最低限の量を作成することが重要です。
通常、メタデータは構成マネージャ・アプリケーションを使用して設定し、特定リビジョンのメタデータはリポジトリ・マネージャ・アプリケーションを使用して処理します。次の項目に関する情報は、「コンテンツ・リビジョンの管理」を参照してください。
次に、編集または削除できない事前定義済の標準フィールドを示します。
| フィールド・キャプション | 入力方法 | 必須かどうか | 定義 |
|---|---|---|---|
| コンテンツID | テキスト入力または自動生成 | Y | 各コンテンツ・アイテムの一意の識別子。
注意: OracleデータベースまたはDB2データベースを使用している場合、コンテンツIDはすべて自動的に大文字に変換されます。 |
| タイプ | オプション・リスト | Y | コンテンツのグループ化に使用する識別子。
|
| タイトル | テキスト入力 | Y | コンテンツ・アイテムの説明的なタイトル。
|
| 作成者 | オプション・リストまたはテキスト入力 | Y | コンテンツ・アイテムをチェックインしたユーザー。 |
| セキュリティ・グループ | オプション・リスト | Y | コンテンツ・アイテムにアクセスするためにユーザーに権限が必要なセキュリティ・グループ。
|
| アカウント | オプション・リストまたはテキスト入力 | N | コンテンツ・アイテムにアクセスするためにユーザーに権限が必要なアカウント。
このフィールドは、アカウントが有効になっている場合にのみ使用できます。 |
| プライマリ・ファイル | テキスト入力またはファイルの参照 | Y | チェックインするネイティブ・ファイルへの完全パス。
ファイル名の最大長は、ディレクトリ・パスとファイル拡張子を含めて80文字です。 ファイル拡張子の最大長は8文字です。 注意: Foldersのインストール時には、ファイル名のこの最大長が255文字に変更されます。 |
| 代替ファイル | テキスト入力またはファイルの参照 | N | ネイティブ・ドキュメントの別のWeb表示可能ファイル・フォーマットへのパス名、またはWeb表示可能フォーマットに変換可能なファイル・フォーマットへのパス名。
たとえば、複数のファイルで構成されたFrameMakerまたはQuarkドキュメントをチェックインしている場合は、ネイティブ・フォーマット(プライマリ・ファイル)としてzipファイルをチェックインし、その代替ファイルとしてPostscript、PDFまたは表示可能ファイルをチェックインします。zipファイルはWeb上で表示できませんが、Inbound Refineryでは、PostscriptファイルがそのWeb表示可能フォーマットであるPDFに変換されます。 ファイル名の最大長は80文字で、ファイル名の拡張子は8文字までです。 |
| リビジョン | 自動生成またはテキスト入力 | Y | コンテンツ・アイテムがそのライフサイクルを終了した回数(リビジョン数)を表すラベル(1、2、3、...またはA、B、C、...など)。リビジョン・ラベルは、独自のリビジョン・スキームにあわせてカスタマイズできます。 |
| コメント(オプション) | ユーザーによるテキスト入力 | N | ファイルに関する追加情報のフィールド。フィールドの最大長は255です。
このフィールドはカスタム・フィールドとみなされるため、削除できます。 |
| リリース日 | 自動生成またはテキスト入力 | Y | ファイルがコンテンツ・サーバーにリリースされ、検索や表示に使用できるようになる日付。リリース日のデフォルトは、ファイルがチェックインされた日時です。 |
| 有効期限 | テキスト入力 | N | ファイルがコンテンツ・サーバーで検索または表示に使用できなくなる日付。現在のリビジョンの有効期限が切れると、コンテンツ・アイテムのすべてのリビジョンが有効期限切れになります。期限が切れてもリビジョンは削除されませんが、期限切れの通知を使用しないと、リポジトリ・マネージャからアクセスできるのは管理者のみです。 |
カスタムのメタデータ・フィールドとアプリケーション・フィールドの管理に関連するタスクは類似しています。この項では、次のタスクについて説明します。
カスタム・メタデータ・フィールドの変更は、データベース(メタデータ・フィールドに関する情報が格納される場所)または検索索引(メタデータ値が格納される場所)に影響を与える可能性があることに注意してください。アプリケーション・フィールドの変更は、データベースまたは索引に影響を与えません。
|
注意: カスタム・メタデータ・フィールドを追加すると、予約名と競合しない一意の名前になるように、名前に接頭辞'x'が自動的に付加されます。同様に、カスタム・ユーザー情報(メタデータ)フィールドを定義すると、予約名と競合しない一意の名前になるよう、名前に接頭辞'u'が自動的に付加されます。カスタム・ユーザー情報フィールドの追加の詳細は、『Oracle Fusion Middleware Content Serverシステム管理者ガイド』を参照してください。 |
新しいメタデータ・フィールドを追加する手順は、次のとおりです。
構成マネージャの「情報フィールド」タブで、「追加」をクリックします。
「メタデータ・フィールド名の追加」画面が表示されます。
新しいフィールド名を入力します。重複する名前は使用できません。最大フィールド長は29文字です。次の文字は使用できません: スペース、タブ、ライン・フィード、キャリッジ・リターンおよび ; ^ ? : @ & + " # % < * ~ |
「OK」をクリックします。
フィールドのプロパティを構成し、「OK」をクリックします。
「OK」をクリックします。
必要な場合は、データベース設計を更新し、検索索引を再構築します。
メタデータ・フィールドを編集する手順は、次のとおりです。
フィールド名をダブルクリックするか、またはフィールドを選択して「編集」をクリックします。
フィールドとそのフィールドに関連するオプション・リストまたはビューを編集します。
「OK」をクリックします。
新しいアプリケーション・フィールドを追加したり、既存のアプリケーション・フィールドを編集する手順は、次のとおりです。
新しいフィールドを追加するには、構成マネージャの「アプリケーション・フィールド」タブで「追加」をクリックします。既存のフィールドを編集するには、「フィールド情報」領域でフィールドを選択し、「編集」をクリックします。「アプリケーション・フィールドの追加」/「アプリケーション・フィールドの編集」画面が表示されます。
新しいフィールド名を入力するか、以前に入力したフィールドを選択して編集します。新しい名前を入力する場合、重複する名前は使用できません。最大フィールド長は29文字です。次の文字は使用できません: スペース、タブ、ライン・フィード、キャリッジ・リターンおよび ; ^ ? : @ & + " # % < * ~ |
「OK」をクリックします。「メタデータ・フィールドの追加」/「メタデータ・フィールドの編集」画面が表示されます。
フィールドのプロパティを構成し、「OK」をクリックします。
「OK」をクリックします。
オプション・リストを定義する手順は、次のとおりです。
「メタデータ・フィールドの追加」/「メタデータ・フィールドの編集」画面または「アプリケーション・フィールドの追加」/「アプリケーション・フィールドの編集」画面から、「オプション・リストの有効化」チェック・ボックスをクリックし、「構成」をクリックします。
メニューから、使用するオプション・リストのタイプを選択します。
オプション・リストの値へのアクセス方法を選択します。リストに対する新しい値の作成、ビューからの値の使用、またはツリー階層での値の使用が可能です。
オプション・リストの依存関係を決定します。
終了したら、「OK」をクリックします。
データベースに保存する必要がある変更を加えた場合は、「データベース設計の更新」ボタンがアクティブになります。
データベースを更新する手順は、次のとおりです。
「メタデータ・フィールドの追加」/「メタデータ・フィールドの編集」画面で、「データベース設計の更新」をクリックします。
「データベース設計の更新」画面が表示されます。
フィールドを削除する場合は、削除するフィールドを選択し、「OK」をクリックします。追加したフィールドと編集したフィールドが表示されますが、選択したり、選択を解除することはできません。
「OK」をクリックします。
検索索引の再構築が必要となる変更を加えた場合は、「検索索引の再構築」ボタンがアクティブになります。
検索索引を再構築する手順は、次のとおりです。
「検索索引の再構築」をクリックします。
検索索引の再構築前にデータベース設計の更新を求めるメッセージが表示された場合は、続行する前に、「データベース設計の更新」をクリックして変更をデータベースに保存します。
メッセージ「再構築を開始しました。」が表示された場合は、「OK」をクリックします。
|
注意: 検索索引および使用可能なシステム・リソースのサイズによっては、検索索引再構築プロセスに数日かかることがあります。再構築が必要な場合は、システム使用率がピーク以外の時間帯に再構築を実施してください。 |
この項では、次の項目について説明します。
リポジトリ・マネージャは、コンテンツ・アイテムのリビジョン、サブスクリプションおよびインデクサの管理に使用する管理アプリケーションです。アプレットとしてリポジトリ・マネージャにアクセスするには、ポータル・ナビゲーション・バーの「管理」トレイ・リンクをクリックします。「管理アプレット」リンクをクリックします。表示されたアプレットから「リポジトリ・マネージャ」を選択します。
リポジトリ・マネージャは、スタンドアロン・モードで実行することもできます。詳細は、「スタンドアロン・モードでの管理アプリケーションの実行」を参照してください。
リポジトリ・マネージャの「機能」メニューを使用すると、特定のリビジョンに対して様々な管理機能を実行できます。たとえば、チェックイン、チェックアウト、メタデータの表示と更新、ワークフローでのリビジョンの承認と却下、リビジョンの削除などを実行できます。
フィルタを使用したリビジョンの表示でリビジョンを右クリックすると、「機能」メニューのすべてのオプションを含むショートカット・メニューが表示されます。
この項には、次の項目が含まれます。
管理者およびRepMan権限があるサブ管理者は、リポジトリ・マネージャでコンテンツ・アイテムのリビジョンのリストを表示できます。管理者はすべてのコンテンツ・アイテムを表示でき、RepMan権限があるサブ管理者が表示できるのは、セキュリティ・グループおよびアカウントに対する管理権限(適用可能な場合)があるコンテンツ・アイテムのみです。リビジョン・リストは、フィルタ条件としてメタデータ・フィールドおよびリビジョン・ステータスを指定することによって検索できます。
|
注意: 複数のコンテンツ・サーバー管理ツールでは、類似したコンテンツ・アイテム表示画面が使用されます。詳細は、使用しているアプリケーションのマニュアルを参照してください。 |
コンテンツ・リストをリビジョンでフィルタ処理するには、次の手順に従います。
リポジトリ・マネージャ・アプリケーションの「コンテンツ」タブで、「フィルタの使用」チェック・ボックスを選択し、「フィルタの定義」をクリックします。
「フィルタの定義」画面が表示されます。
使用するフィルタ条件のチェック・ボックスを選択します。
選択したすべてのフィールドに値を指定します。
「OK」をクリックします。
リリース日でリビジョンをフィルタ処理する手順は、次のとおりです。
リポジトリ・マネージャ・アプリケーションの「コンテンツ」タブで、「リリース日以降」チェック・ボックスを選択します。
いずれかの事前定義済日付範囲を選択します。
「OK」をクリックします。
「コンテンツ」タブに表示されている列を変更する手順は、次のとおりです。
リポジトリ・マネージャ・アプリケーションの「コンテンツ」タブで、「列の表示」チェック・ボックスを選択します。
「列の表示」画面が表示されます。
表示する列を選択します。(ユーザー定義フィールドはこのリストの下に表示されます。)
「OK」をクリックします。
リポジトリ・マネージャ・アプリケーションを起動すると、データベースに対してデフォルトの問合せが実行され、前日にリリースされたすべてのコンテンツが返されます。デフォルトでは、問合せの結果はコンテンツ・アイテムのContentIDでソートされます。
ContentIDによる順序付けは、リポジトリ・マネージャにコンテンツ・アイテムの長いリストがある場合に順序を予測できるため有益です。しかし、多数のドキュメントがある場合、ContentIDによるソートでは、問合せの結果が返されるのに時間がかかる可能性があります。したがって、予測可能な順序はなくても、問合せ結果の早い取得を優先する場合があります。
ContentIDによるソートに時間がかかりすぎる場合は、DoDocNameOrder構成設定を無効にして、順序付けを変更できます。値をデフォルト値のtrueに設定すると、コンテンツ・アイテムはContentIDでソートされます。値をfalseに設定すると、コンテンツ・アイテムはソートされません。さらに、問合せを最適化するためにソート順を変更する場合は、JDBC問合せトレースを有効にすると便利です。この結果、トレース情報がコンソール・ログに記録され、そこでデータベース問合せを表示できます。
DoDocNameOrder構成設定を無効にする手順は、次のとおりです。
テキスト・エディタで、config.cfgファイルを開きます。
IntradocDir/config/config.cfg
次の構成設定を追加します。
DoDocNameOrder=false
config.cfgファイルを保存して閉じます。
コンテンツ・サーバーを再起動します。
問合せトレース機能を有効にする手順は、次のとおりです。
コンテンツ・サーバーで、「管理」トレイの「システム監査情報」リンクをクリックします。
システム監査情報ページが表示されます。
「アクティブなコンソール出力トレースの編集**」部分の最下部までスクロールします。
「アクティブなセクション」リストから「systemdatabase」を選択します。
アクティブ・セクションのリストにsystemdatabaseが追加されます。
「更新」をクリックします。
コンテンツ・サーバーを再起動します。
レポートのトレースおよびコンテンツ・サーバーの再起動の詳細は、『Oracle Fusion Middleware Content Serverシステム管理者ガイド』を参照してください。
リポジトリ・マネージャの「機能」メニューを使用すると、特定のコンテンツ・リビジョンに対して様々な管理機能を実行できます。たとえば、チェックイン、チェックアウト、メタデータの表示と更新、ワークフローでのリビジョンの承認と却下、リビジョンの削除などを実行できます。
「リポジトリ・マネージャ」: 「コンテンツ」タブ画面でリビジョンを右クリックすると、「機能」メニューのすべてのオプションを含むショートカット・メニューが表示されます。
コンテンツの管理に関する一般的なタスクは次のとおりです。
リポジトリ・マネージャを使用して新しいコンテンツ・アイテムを追加する手順は、次のとおりです。
|
注意: ブラウザからJavaアプレットとして起動したリポジトリ・マネージャを使用して、新しいコンテンツ・アイテムを追加することはできません。スタンドアロン・アプリケーションを使用する必要があります。 |
「リポジトリ・マネージャ」: 「コンテンツ」タブ画面をスタンドアロン・モードで表示します。
「新規追加」をクリックします。
「新しいコンテンツ・アイテムの追加」画面が表示されます。
コンテンツ・アイテムの必須情報およびオプションの情報を入力します。
「OK」をクリックします。
指定したファイルが、新しいコンテンツ・アイテムとしてコンテンツ・サーバーにチェックインされます。
リポジトリ・マネージャを使用してリビジョンのメタデータを表示する手順は、次のとおりです。
「リポジトリ・マネージャ」: 「コンテンツ」タブ画面を表示します。
メタデータを表示するリビジョンを選択します。
「機能」→「情報」を選択するか、または右クリックして「情報」を選択します。
「リビジョンの承認」画面が表示されます。
「OK」をクリックして、画面を閉じます。
リポジトリ・マネージャを使用してリビジョンのメタデータを更新する手順は、次のとおりです。
「リポジトリ・マネージャ」: 「コンテンツ」タブ画面を表示します。
メタデータを更新するリビジョンを選択します。
「機能」→「更新」を選択するか、または右クリックして「更新」を選択します。
「コンテンツ情報の更新」画面が表示されます。
必要に応じて新しいメタデータを入力します。
「OK」をクリックします。
メタデータは、新しいリビジョンをチェックインせずに更新されます。
リポジトリ・マネージャから期限切れのコンテンツを確認する手順は、次のとおりです。
リポジトリ・マネージャのメイン画面を表示します。
「コンテンツ」タブから「フィルタの定義」を選択します。
「フィルタの定義」画面が表示されます。
「リビジョンのステータス」を有効にし、「期限切れ」を選択します。
期限切れのコンテンツのリストが表示されます。
期限切れのコンテンツはユーザーが確認できます。コンテンツの有効期限がまもなく切れるときに、そのコンテンツの作成者および管理者に電子メールで知らせる自動通知を作成できます。
電子メール・メッセージを自動化する手順は、次のとおりです。
テキスト・エディタでIntradocDir/config/config.cfgを編集し、次のように入力します。
EnableExpirationNotifier=1
次の各項の説明に従って、オプションの構成エントリを調整します。デフォルトでは、コンテンツが期限切れに設定される7日前の午前0時に、電子メール・メッセージが管理者に送信されます。さらに、「有効期限が切れたコンテンツ」リストが、作成者およびシステム管理者の「コンテンツ管理」トレイに追加されます。
コンテンツ・サーバーを再起動します。
NotificationQueryの設定によって、期限切れコンテンツを検索する自動問合せの条件を定義します。
NotificationQuery=<query>
<query>の値は、Idocスクリプト、URLエンコードまたはプレーン・テキストのいずれかです。
Idocスクリプト問合せは、Idocスクリプトから作成されます。たとえば、データベース索引作成を使用する場合は、次の問合せによって、7日間で期限が切れるすべてのドキュメントの電子メール通知が送信されます。
NotificationQuery=dOutDate < '<$dateCurrent(7)$>'
または、データベース索引作成を使用する場合は、次の問合せによって、すでに期限が切れたすべてのドキュメントの電子メール通知が送信されます。
NotificationQuery=dOutDate<<$formatDateDatabase(toInteger(dateCurrent()))$>
|
注意: 検索エンジンによっては、すでに期限が切れたコンテンツの電子メール通知は受信できない場合があります。まもなく期限が切れるコンテンツの電子メール通知のみ受信できます。 |
URLエンコード問合せでは、コンテンツ・サーバーで検索を実行するとき、Webブラウザのアドレス・バーに表示されるURLが使用されます。問合せを実行して、'QueryText='から始まる問合せテキストをコピーして貼り付けると、通知問合せを定義できます。たとえば、次の問合せでは、2006年8月1日をすぎると期限が切れるすべてのコンテンツが返されます。
NotificationQuery=QueryText=dOutDate+%3C+%608%2F1%2F06%60&SearchProviders= [...]
プレーン・テキスト問合せでは、プレーン・テキストを使用して検索変数を定義します。たとえば、次の問合せでは、2006年8月1日に期限が切れるすべてのコンテンツが返されます。
NotificationQuery=dOutDate=8/1/06
NotificationQueryの設定が定義されていない場合、デフォルト値は、次の7日間で期限が切れるすべてのコンテンツです。
NotificationQuery=dOutDate < '<$dateCurrent(7)$>'
NotifyExtrasの設定によって、(各コンテンツ・アイテムの作成者以外に)期限切れコンテンツのリストを受信するユーザーを定義します。
NotifyExtras=<user1>,<user2>
NotifyExtrasの設定がconfig.cfgファイルにない場合、デフォルト値はsysadminです。
NotifyExtras=sysadmin
NotifyExtrasの設定はconfig.cfgファイルにあるが、値が空白のままの場合、追加通知は送信されません。
NotificationIntervalInDaysの設定によって、通知問合せの実行頻度を定義します。
NotificationIntervalInDays=<number of days>
NotificationIntervalInDaysの設定が定義されていない場合、デフォルト値は1日です。
NotificationIntervalInDays=1
NotifyTimeの設定によって、通知問合せの実行時刻を24時間表記で定義します。
NotifyTime=<hh:mm>
たとえば、希望する時刻が午前11時30分の場合は、次のように設定します。
NotifyTime=11:30
また、希望する時刻が午後1時30分の場合は、次のように設定します。
NotifyTime=13:30
NotifyTimeの設定が定義されていない場合、デフォルト値は午前0時です。
NotifyTime=00:01
リビジョンとは、コンテンツ・アイテムの新しいバージョンまたは改訂バージョンです。デフォルトでは、リビジョンにはリビジョン1から順番に番号が付けられ、コンテンツ・アイテムがチェックアウトされ、再度チェックインされるたびに、リビジョン番号が1ずつ増加します。ファイルをチェックアウトして再度チェックインするたびに、コンテンツ・サーバーによってそのファイルの新しいリビジョンが作成されます。新しいリビジョンのコンテンツIDは前のリビジョンと同じですが、ネイティブ・ファイルとメタデータは同じ場合と異なる場合があります。以前のバージョンのファイルはシステムに保存されているため、必要に応じて確認できます。
リビジョンの管理に関する一般的なタスクは次のとおりです。
リポジトリ・マネージャを使用して既存のコンテンツ・アイテムの新しいリビジョンを追加する手順は、次のとおりです。
|
注意: ブラウザからJavaアプレットとして起動したリポジトリ・マネージャを使用して、新しいリビジョンを追加することはできません。スタンドアロン・アプリケーションを使用する必要があります。 |
「リポジトリ・マネージャ」: 「コンテンツ」タブ画面をスタンドアロン・モードで表示します。
新しいリビジョンを追加するリビジョンを選択します。
「リビジョンの追加」をクリックし、「機能」→「リビジョンの追加」を選択するか、または右クリックして「リビジョンの追加」を選択します。
新しいリビジョンの追加画面が表示されます。
リビジョンの必須情報およびオプションの情報を入力します。
「OK」をクリックします。
指定したファイルが、新しいリビジョンとしてコンテンツ・サーバーにチェックインされます。
リポジトリ・マネージャを使用してリビジョンをチェックアウトする手順は、次のとおりです。
「リポジトリ・マネージャ」: 「コンテンツ」タブ画面をスタンドアロン・モードで表示します。
チェックアウトするリビジョンを1つ以上選択します。
「機能」→「チェックアウト」を選択するか、または右クリックして「チェックアウト」を選択します。
「アイテムのチェックアウト」画面が表示されます。
リストからリビジョンを除外するには、リビジョンの横にあるチェック・ボックスの選択を解除します。
「OK」をクリックします。
選択したリビジョンがチェックアウトされます。
リポジトリ・マネージャを使用してコンテンツ・アイテムのチェックアウトを元に戻す手順は、次のとおりです。
「リポジトリ・マネージャ」: 「コンテンツ」タブ画面を表示します。
チェックアウトを元に戻すリビジョンを1つ以上選択します。
「機能」→「チェックアウトを元に戻す」を選択するか、または右クリックして「チェックアウトを元に戻す」を選択します。
「チェックアウトを元に戻す」画面が表示されます。
リストからリビジョンを除外するには、リビジョンの横にあるチェック・ボックスの選択を解除します。
「OK」をクリックします。
選択したリビジョンのチェックアウトが元に戻されます。
リポジトリ・マネージャを使用して変換のためにリビジョンをInbound Refineryに再送信する手順は、次のとおりです。
「リポジトリ・マネージャ」: 「コンテンツ」タブ画面を表示します。
変換のために再送信するリビジョンを1つ以上選択します。
「機能」→「再送信」を選択するか、または右クリックして「再送信」を選択します。
「リビジョンの再発行」画面が表示されます。
リストからリビジョンを除外するには、リビジョンの横にあるチェック・ボックスの選択を解除します。
「OK」をクリックします。
選択したリビジョンが変換のためにInbound Refineryに再送信されます。
リポジトリ・マネージャを使用して特定のリビジョンを削除する手順は、次のとおりです。
「リポジトリ・マネージャ」: 「コンテンツ」タブ画面を表示します。
削除するリビジョンを1つ以上選択します。
「リビジョンの削除」をクリックし、「機能」→「リビジョンの削除」を選択するか、または右クリックして「リビジョンの削除」を選択します。
「リビジョンの削除」画面が表示されます。
リストからリビジョンを除外するには、リビジョンの横にあるチェック・ボックスの選択を解除します。
「OK」をクリックします。
選択したリビジョンが削除されます。
リポジトリ・マネージャを使用してコンテンツ・アイテムのすべてのリビジョンを削除する手順は、次のとおりです。
「リポジトリ・マネージャ」: 「コンテンツ」タブ画面を表示します。
削除するコンテンツ・アイテムのリビジョンを1つ以上選択します。
「すべてのリビジョンを削除する」をクリックし、「機能」→「すべてのリビジョンを削除する」を選択するか、または右クリックして「すべてのリビジョンを削除する」を選択します。
「すべてのリビジョンを削除する」画面が表示されます。
リストからリビジョンを除外するには、リビジョンの横にあるチェック・ボックスの選択を解除します。
「OK」をクリックします。
選択したコンテンツ・アイテムのすべてのリビジョンが削除されます。
システムにリリースされる前のコンテンツをレビューおよび承認のためにルーティングする方法は、ワークフローで指定します。レビューするファイルがあるユーザーには、電子メールで通知されます。
ワークフローの参加者の視点から見ると、ワークフローには2つのタイプがあります。
基本ワークフローは、特定のコンテンツ・アイテムのレビュー・プロセスを定義するワークフローで、手動で開始する必要があります。
基準ワークフローでは、ファイルのメタデータが事前定義済の基準と一致すると、そのファイルがチェックイン時に自動的にワークフローに入ります。
ワークフロー・リビジョンの管理に関する一般的なタスクは次のとおりです。
リポジトリ・マネージャを使用してワークフローでリビジョンを承認する手順は、次のとおりです。
「リポジトリ・マネージャ」: 「コンテンツ」タブ画面を表示します。
承認するリビジョンを1つ以上選択します。
「機能」→「承認」を選択するか、または右クリックして「承認」を選択します。
「リビジョンの承認」画面が表示されます。
リストからリビジョンを除外するには、リビジョンの横にあるチェック・ボックスの選択を解除します。
「OK」をクリックします。
選択したリビジョンが承認されます。
リポジトリ・マネージャを使用してワークフローでリビジョンを却下する手順は、次のとおりです。
「リポジトリ・マネージャ」: 「コンテンツ」タブ画面を表示します。
却下するリビジョンを1つ以上選択します。
「機能」→「却下」を選択するか、または右クリックして「却下」を選択します。
「リビジョンの却下」画面が表示されます。
リストからリビジョンを除外するには、リビジョンの横にあるチェック・ボックスの選択を解除します。
却下の理由を説明するメッセージを入力します。
「OK」をクリックします。
リビジョンは直前のレビューア/コントリビュータ・ステップに戻り、却下通知電子メールがそのステップのレビューアに送信されます。
この項には、次の項目が含まれます。
サブスクリプションとは、特定のコンテンツ・アイテムが改訂されたときに、電子メールでユーザーに通知するコンテンツ・サーバーの機能です。
|
ヒント: サブスクリプション通知メッセージを変更するには、コンポーネント・アーキテクチャを使用して、次の内容をカスタマイズできます。
|
|
ヒント: コンテンツ・サーバーの電子メール・メッセージのバッファは20,000バイトです。多数のサブスクリプション電子メール通知が短期間にトリガーされると(たとえば、40のコンテンツ・アイテムにそれぞれ40のサブスクライバが設定されている場合)、バッファがオーバーロードの状態になる可能性があり、電子メール・メッセージが送信されません。コンテンツ・サーバー・エラー・メッセージ「ワーク・キュー・エラーです。: ワーク・キューの照合中にエラーが発生しました。(キュー'CollatedWorkQueue'に追加するメッセージが大きすぎます。)」は、バッファがオーバーロードの状態になったことを示しています。 |
この項の内容は次のとおりです。
サブスクリプションを作成するには、2つの方法があります。
ユーザーがコンテンツ・アイテムをサブスクライブするには、2つの方法があります。
オープン・サブスクリプション: ユーザーは、基本または条件サブスクリプションによって、コンテンツ・アイテムを手動でサブスクライブします。
強制サブスクリプション: 管理者が、特定のサブスクリプションにユーザーまたはエイリアス(あるいはその両方)を割り当てます。個々のユーザーが割り当てられている場合、各ユーザーは希望した場合にサブスクライブを解除できます。エイリアスが割り当てられている場合、そのエイリアス内のユーザーはサブスクライブを解除できません。
サブスクリプションの管理における一般的なタスクは次のとおりです。
条件サブスクリプションを追加する手順は、次のとおりです。
サブスクリプション条件を指定します。「サブスクリプション条件の指定」を参照してください。
ユーザーを追加します。「サブスクリプションへのユーザーの追加」を参照してください。
|
ヒント: サブスクリプションに追加したユーザーの電子メール・アドレスが正しくない場合、通知は失敗します。ワーク・キュー・ログで5つのエラーが発生するとシステムは終了し、残りのサブスクライバには通知されません。 |
サブスクリプション条件を指定する手順は、次のとおりです。
「リポジトリ・マネージャ」: 「サブスクリプション」タブを表示します。
「追加」をクリックします。
サブスクリプションの名前と説明を入力します。
「フィールド」をクリックします。
「フィールド」画面が表示されます。
このサブスクリプションに必要なフィールドを指定します。(これらのフィールドの値は、後でユーザーを追加するときに設定します。)
「OK」をクリックします。
サブスクリプションを有効にするか無効にするかを指定します。
「OK」をクリックします。
条件サブスクリプションにユーザーを追加する手順は、次のとおりです。
「リポジトリ・マネージャ」: 「サブスクリプション」タブを表示し、ユーザーを追加するサブスクリプションを選択します。
「サブスクライバ」をクリックします。
サブスクライブ者画面が表示されます。
「追加」をクリックします。
「サブスクリプションの追加」画面が表示されます。
「ユーザー」または「エイリアス」を選択します。
「選択」をクリックします。
「ユーザーの選択」画面または「エイリアスの選択」画面が表示されます。
サブスクライブの対象となるユーザーまたはエイリアスを選択します。
「OK」をクリックします。
以前に指定した条件フィールドの値を設定します。
「OK」をクリックします。
リポジトリ・マネージャを使用してコンテンツ・アイテムからユーザーまたはエイリアスのサブスクライブを解除する手順は、次のとおりです。
「リポジトリ・マネージャ」: 「サブスクリプション」タブを表示します。
ユーザーまたはエイリアスのサブスクライブを解除するリビジョンを選択します。
「機能」→「サブスクライバ」を選択するか、または右クリックして「サブスクライバ」を選択します。
「サブスクライバ」画面が表示されます。
サブスクライブを解除するユーザーまたはエイリアスを選択します。
「サブスクライブ解除」をクリックします。
確認画面が表示されます。
「OK」をクリックします。
ユーザーまたはエイリアスが「サブスクリプション」リストから削除されます。
条件サブスクリプションを編集する手順は、次のとおりです。
「リポジトリ・マネージャ」: 「サブスクリプション」タブを表示します。
サブスクリプションを選択します。
「編集」をクリックします。
必要な設定を変更し、「OK」をクリックします。
|
重要: 条件フィールドを変更すると、現在のサブスクリプションはすべて削除されます。この機能を使用する場合は注意してください。 |
「サブスクライバ」をクリックします。
サブスクライブ者画面が表示されます。
必要な設定を変更し、「OK」をクリックします。
リポジトリ・マネージャを使用してリビジョンのサブスクリプション情報を表示する手順は、次のとおりです。
「リポジトリ・マネージャ」: 「サブスクリプション」タブを表示します。
サブスクリプション情報を表示するリビジョンを選択します。
「機能」→「サブスクライバ」を選択するか、または右クリックして「サブスクライバ」を選択します。
「サブスクライバ」画面が表示されます。
サブスクリプション・リストを絞り込む手順は、次のとおりです。
「フィルタの使用」チェック・ボックスを選択します。
「フィルタの定義」をクリックします。
サブスクリプションの詳細画面が表示されます。
フィルタ条件を入力します。
「OK」をクリックします。
特定のユーザーまたはエイリアスのサブスクリプション詳細をすべて表示するには、そのユーザーまたはエイリアスを選択して「詳細の表示」をクリックします。
サブスクリプションの詳細画面が表示されます。
条件サブスクリプションを削除する手順は、次のとおりです。
「リポジトリ・マネージャ」: 「サブスクリプション」タブを表示します。
サブスクリプションを選択します。
「削除」をクリックします。
確認画面が表示されます。
「はい」をクリックします。
リンク・マネージャはコンテンツ・サーバーにバンドルされたオプションのコンポーネントで、コンテンツ・サーバーとともに自動的にインストールされます。有効な場合は、索引付けしたコンテンツ・アイテムのURLリンクを、データベース表(ManagedLinks)への格納のために抽出する前に、評価、フィルタ処理および解析します。抽出したURLリンクがManagedLinks表に移入されると、リンク・マネージャ・コンポーネントはこの表を参照し、リンク検索結果、コンテンツ情報ページ用のリンク参照リストおよびリンク情報ページ用のリソース情報を生成します。リンク・マネージャ・コンポーネントを使用すると、次のことができます。
特定の検索条件を使用したリンク・リストの表示
特定のリンクに関する詳細情報の表示
リンクを再評価して検証するための再計算とリフレッシュ
特定のコンテンツ・アイテム内にある他のコンテンツへのリンクの表示
特定のコンテンツ・アイテムに戻るリンクの表示
検索結果、リンク参照リストおよびリンク情報ページは、コンテンツの追加、変更またはリビジョン削除による影響を受けるコンテンツ・アイテムの判別に役立ちます。たとえば、コンテンツ・アイテムを削除する前に、含まれているURL参照が重要でないことを確認できます。コンテンツ・アイテムがどのように使用されているかを監視するためにも使用できます。
|
注意: リンク・マネージャ・コンポーネントによるURLリンクの抽出は、コンテンツ・サーバーの索引作成サイクル中に実行されるため、抽出されるのはリリースされたコンテンツ・アイテムのURLリンクのみです。複数のリビジョンがあるコンテンツ・アイテムの場合、データベース表にエントリが作成されるのは、最も最近リリースされたリビジョンのみです。コンテンツ・アイテムがすでにチェックインされた後でリンク・マネージャ・コンポーネントをインストールする場合は、すべてのリンクがManagedLinks表に確実に含まれるように、再構築を実行する必要があります。 |
|
注意: リンク・マネージャによる作業はすべて索引作成サイクル時に実行されるため、コンテンツ・アイテムの索引作成およびコレクションの再構築に必要な時間が増加します。再構築サイクル中にリンク・マネージャを無効にする方法は、Oracle Fusion Middleware Idocスクリプト・リファレンス・ガイドのLkDisableOnRebuildおよびLkReExtractOnRebuildに関する項を参照してください。ただし、これにかかる時間は、全体の時間の大部分がコンテンツ・アイテムのコレクションへの索引作成に費やされるため、重要ではない可能性があります。それでも、必要な時間は、関連するコンテンツ・アイテムのタイプとサイズによって決まります。つまり、ファイルの変換が必要な場合は、テキストベース(HTML)のファイルより時間がかかります。 ファイル・フォーマット、変換およびリンクの抽出の詳細は、「リンクの抽出プロセス」および「ファイル・フォーマットと変換」を参照してください。 |
この項の内容は次のとおりです。
この項の内容は次のとおりです。
リンク・マネージャは、抽出エンジンとパターン・エンジンで構成されています。抽出エンジンには変換エンジン(HtmlExport)が含まれています。変換エンジンは、抽出エンジンではテキストベースのファイル・フォーマット(HTML)にネイティブに解析できないファイルを変換するために使用されます。
リンク・マネージャでは、ファイル・フォーマットにhcs、htm、image、text、xml、jspおよびaspのいずれかの文字列が含まれているファイルの変換にHtmlExportを使用しません。これらのテキストベースのファイルは、リンク・マネージャによって処理され、変換の必要はありません。
索引作成サイクル中に、リンク・マネージャ・コンポーネントは、URLリンクを検出するために、チェックインしたコンテンツ・アイテムを検索します。これは次のように行われます。
抽出エンジンが、変換エンジンを使用してファイルを変換します(必要な場合)。
抽出エンジンは、次にパターン・エンジンを使用して、LinkManagerPatterns表に定義されているリンク評価ルールにアクセスします。
評価ルールは、コンテンツ・アイテム内の承認済URLリンクをソート、フィルタ処理、評価および解析する方法を抽出エンジンに指示します。
承認済URLリンクがManagedLinks表に挿入されるかまたは更新されます。
|
注意: このリリースのリンク・マネージャ・コンポーネントは、ファイル変換にHtmlExport 8(コンテンツ・サーバーの現在のバージョンに付属)を使用します。リンク・マネージャ・コンポーネントには、リンク抽出テンプレート・ファイルが含まれています。HtmlExport 8には、このテンプレートが必要です。このファイルは編集しないでください。 |
|
重要: 正常に実行するには、HtmlExportに仮想または物理ビデオ・インタフェース・アダプタ(VIA)のいずれかが必要です。たとえば、ほとんどのWindows環境には、フレーム・バッファへのHtmlExportアクセスを提供するグラフィック機能が備わっています。しかし、UNIXシステムには、グラフィック・カードがない場合があり、HtmlExportで使用するためのX-Windowsサーバーが稼働していません。グラフィック・カードのないシステムの場合は、仮想フレーム・バッファ(VFB)をインストールして使用できます。 |
リンクを抽出する前に、変換エンジン(HtmlExport)で変換する必要がある様々なファイル・フォーマット(Wordなど)があります。ただし、テキストベースのファイル(HTML)内のリンクは、リンク・マネージャで抽出でき、HtmlExportで変換する必要はありません。したがって、リンク・マネージャでは、ファイル・フォーマットにhcs、htm、image、text、xml、jspおよびaspのいずれかの文字列が含まれているファイルの変換にHtmlExportを使用しません。
さらに、リンク・マネージャでは、これらのファイル・フォーマットのすべてのバリエーションが処理されます。たとえば、hcs文字列は、動的サーバー・ページ文字列のhcst、hcspおよびhcsfと一致します。また、image文字列は、image/gif、image/jpeg、image/rgb、image/tiffなど、類似のすべてのバリエーションと一致しており、さらに、変換する必要がない他のファイル・タイプがある可能性もあります。この場合は、構成変数を使用して、これらの変換が行われないようにできます。詳細は、Oracle Fusion Middleware Idocスクリプト・リファレンス・ガイドのLkDisallowConversionFormatsに関する項を参照してください。
リンク・マネージャでは、次のファイル・フォーマットでリンクが認識されます。
テキストベースのフォーマット(txt、html、xml、jsp、asp、csv、hcst、hcsfおよびhcsp)
電子メール(msgおよびeml)
Microsoft Word
Microsoft Excel
OpenOffice Writer
OpenOffice Calc
新しいリンクと既存のリンクはすべて、索引作成サイクル中に管理されます。コンテンツ・アイテムがチェックインされると、これらのコンテンツ・アイテム内の承認済リンクはManagedLinks表に追加されるか、更新されます。さらに、既存のリンクは、コンテンツ・アイテムのチェックインまたは削除による変更に対して評価されます。リンクが追加または監視されると、そのリンクには有効または無効のマークが付けられます。
システム内のあるコンテンツ・アイテムがシステム内の別のコンテンツ・アイテムを参照している場合、結果のリンクには有効のマークが付けられます。既存のリンクが削除されたコンテンツ・アイテムを参照している場合、そのリンクは再評価され、ステータスが有効から無効に変わります。ステータスは、ManagedLinks表のdLkState列にY(有効)またはN(無効)として記録され、ユーザーに対しては、リンク情報ページの「状態」列に、「有効」または「無効」として表示されます。リンク情報ページの詳細は、『Oracle Fusion Middleware Content Serverユーザーズ・ガイド』を参照してください。
次のリンク・マネージャ構成変数は、IntradocDir/config/config.cfgファイルで指定できます。
AllowForceDeleteを使用すると、他のコンテンツ・アイテムが参照(または使用)しているコンテンツ・アイテムをコンテンツ・サーバーで削除できます。
AllowForceDelete=trueの場合は、リンクとして参照されているコンテンツ・アイテムを削除できるようにコンテンツ・サーバーが構成されます。他のコンテンツ・アイテムが参照しているコンテンツ・アイテムを削除すると、そのリンクは無効化されます。値をtrueに設定していない場合、参照されているコンテンツ・アイテムの削除リクエストは失敗します。
AllowForceDelete=falseの場合は、リンクとして参照されているコンテンツ・アイテムの削除リクエストを拒否するようにコンテンツ・サーバーが構成されます。これはデフォルトの設定です。
Site Studioがインストールされている場合は、HasSiteStudioを使用して、パターン・エンジン用のフレンドリURLを解析するためのSite Studio固有のリンク・パターンを有効化できます。Site Studioとリンク・マネージャの現在の統合に関する詳細は、「Site Studioの統合」を参照してください。
HasSiteStudio=trueの場合は、Site Studio固有のリンク・パターンが有効化されます。
HasSiteStudio=falseの場合は、Site Studio固有のリンク・パターンが無効化されます。これはデフォルトの設定です。
LkRefreshBatchSizeを使用すると、リフレッシュ・プロセス時にSite Studioに発行されるリンクの数を制御できます。デフォルトでは、バッチ・サイズの値は100に設定されています。
LkRefreshBatchSize構成変数の値によっては、リフレッシュ・プロセスで中止リクエストがより受け入れられる(またはより受け入れられない)ようにできます。たとえば、値を小さくするほど、現在のリフレッシュ・プロセスに関して、リフレッシュ・アクティビティの中止がより受け入れられるようになります。
また、LkRefreshErrorsAllowedの計算は、各バッチ・プロセス中ではなく各バッチ・プロセス後に完了します。したがって、LkRefreshBatchSizeの値が小さいほど、許容エラー数をより早く超えるようになるため、リフレッシュ・アクティビティの即時中止が発生しやすくなります。
LkRefreshBatchSize=<number>
リンク・マネージャで使用可能なリフレッシュ・プロセスの詳細は、「管理されたリンクの管理ページ」を参照してください。
|
注意: Site Studioを使用している場合は、LkRefreshBatchSizeを使用すると、LkRefreshErrorPercentとLkRefreshErrorThresholdの設定を組み合せて使用するより、リフレッシュ中止オプションを制御しやすくなります。たとえば、パーセント値を5に設定し、しきい値を20に設定した場合は、最初のエラー発生後にリフレッシュ・アクティビティが中止すると予測します。しかし実際には、リンク・マネージャによって複数のエラーが中止前に処理される可能性があります。 |
これは、リフレッシュ・アクティビティ時に、Site Studioリンク(Site Studioの処理が必要なリンク)として認識されたリンクがすべてグループ化され、1つのバッチとしてSite Studioに送信されるためです。結果的に、リフレッシュはより効率的ですが、中止リクエストは、Site Studioで中止および合計エラー数が認識されないため、この時点では応答がありません。
ただし、Site Studioでは、現在のバッチで発生したエラー数は認識されます。このため、リンク・マネージャの中止計算はすべての状況で行うことはできず、エラー構成値(パーセントおよびしきい値)は、中止する必要がある時期をリンク・マネージャに提示するのみです。しかし、LkRefreshBatchSizeを使用すると、Site Studioリンク・バッチを含むリフレッシュ・アクティビティ時に、中止の受入れをより正確に制御できます。
LkRefreshErrorsAllowedを使用すると、リフレッシュ・プロセスの絶対エラー数を設定できます。設定したエラー数に達すると、リフレッシュ・アクティビティは中止されます。デフォルトでは、この構成設定は使用されません。
LkRefreshErrorsAllowed=<number>
リンク・マネージャで使用可能なリフレッシュ・プロセスの詳細は、「管理されたリンクの管理ページ」を参照してください。
LkRefreshErrorsAllowed構成設定の値を設定すると、しきい(LkRefreshErrorThreshold)とパーセント(LkRefreshErrorPercent)の値の組合せを上書きする可能性があります。たとえば、LkRefreshErrorsAllowedの値が、リンク/エラーに対する計算されたしきい/パーセント値より小さい場合、処理されたリンク数がしきい制限を超えていない場合でも、リフレッシュ・アクティビティが中止される可能性があります。したがって、LkRefreshErrorsAllowed構成設定、またはLkRefreshErrorThreshold構成設定とLkRefreshErrorPercent構成設定の組合せのいずれかを使用することをお薦めします。
この値は、リフレッシュ・アクティビティを中止する必要があるかどうかを計算するために、LkRefreshErrorThresholdとともに使用されます。リフレッシュ・アクティビティでしきい値を超える数のリンクが処理されると、リンク・マネージャではエラーの割合が計算されます。エラー数がパーセント値を超えると、リフレッシュ・アクティビティは中止されます。たとえば、しきい値が300でパーセント値が20の場合、300を超えるリンクを処理した後で60のエラーが発生していると、リフレッシュ・アクティビティは中止されます。デフォルトでは、パーセント値は10に設定されています。
LkRefreshErrorPercent=<number>
リンク・マネージャで使用可能なリフレッシュ・プロセスの詳細は、「管理されたリンクの管理ページ」を参照してください。
LkRefreshErrorsAllowed構成設定の値を設定すると、しきい(LkRefreshErrorThreshold)とパーセント(LkRefreshErrorPercent)の値の組合せを上書きする可能性があります。たとえば、LkRefreshErrorsAllowedの値が、リンク/エラーに対する計算されたしきい/パーセント値より小さい場合、処理されたリンク数がしきい制限を超えていない場合でも、リフレッシュ・アクティビティが中止される可能性があります。したがって、LkRefreshErrorsAllowed構成設定、またはLkRefreshErrorThreshold構成設定とLkRefreshErrorPercent構成設定の組合せのいずれかを使用することをお薦めします。
この値は、リフレッシュ・アクティビティを中止する必要があるかどうかを計算するために、LkRefreshErrorPercentとともに使用されます。LkRefreshErrorThreshold値は、エラーの割合を計算する前に処理する必要があるリンクの数を示します。検出されるエラーの割合によっては、リフレッシュ・アクティビティを中止する必要がある場合があります。たとえば、しきい値が300でパーセント値が20の場合、300を超えるリンクを処理した後で60のエラーが発生していると、リフレッシュ・アクティビティは中止されます。デフォルトでは、パーセント値は10に設定されています。デフォルトでは、しきい値は100に設定されています。
LkRefreshErrorThreshold=<number>
リンク・マネージャで使用可能なリフレッシュ・プロセスの詳細は、「管理されたリンクの管理ページ」を参照してください。
LkRefreshErrorsAllowed構成設定の値を設定すると、しきい(LkRefreshErrorThreshold)とパーセント(LkRefreshErrorPercent)の値の組合せを上書きする可能性があります。たとえば、LkRefreshErrorsAllowedの値が、リンク/エラーに対する計算されたしきい/パーセント値より小さい場合、処理されたリンク数がしきい制限を超えていない場合でも、リフレッシュ・アクティビティが中止される可能性があります。したがって、LkRefreshErrorsAllowed構成設定、またはLkRefreshErrorThreshold構成設定とLkRefreshErrorPercent構成設定の組合せのいずれかを使用することをお薦めします。
LkDisableOnRebuildを使用すると、索引作成の再構築サイクル時にリンクの抽出を制御できます。
LkDisableOnRebuild=trueの場合、索引作成の再構築サイクル時にリンク・マネージャではリンクが抽出されません。
LkDisableOnRebuild=falseの場合は、索引作成の再構築サイクル時にリンクを抽出するようにリンク・マネージャが構成されます。これはデフォルトの設定です。
リンク・マネージャによる作業はすべて索引作成サイクル時に実行されるため、ドキュメントの索引作成およびコレクションの再構築に必要な時間が増加します。ただし、これにかかる時間は、全体の時間の大部分がドキュメントのコレクションへの索引作成に費やされるため、重要ではない可能性があります。それでも、必要な時間は、関連するドキュメントのタイプとサイズによって決まります。つまり、ファイルの変換が必要な場合は、テキストベース(HTML)のファイルより時間がかかります。
ファイル・フォーマット、変換およびリンクの抽出の詳細は、「リンクの抽出プロセス」および「ファイル・フォーマットと変換」を参照してください。
LkDisallowConversionFormatsを使用すると、リンク抽出用に処理される前に、(HtmlExportを使用して)変換されないファイル・フォーマットのリストを指定できます。リンクを抽出する前に、HtmlExportで変換する必要がある様々なファイル・フォーマット(Wordなど)があります。ただし、テキストベースのファイル・フォーマット(HTML)内のリンクは、リンク・マネージャで抽出でき、HtmlExportで変換する必要はありません。
たとえば、実際にはテキストベースであるPHPファイル(または他のカスタム・フォーマットのファイル)があるとします。このようなファイルでは、リンク・マネージャでのリンク抽出処理の前に、HtmlExportによる変換が不要な場合があります。この構成変数には、このようなフォーマットをリストできます。
LkDisallowConversionFormats=<format>,...,<format>
<format>はMIMEタイプです。
例1
LkDisallowConversionFormats=application/msword,audio/wav,video/avi
この例では、完全なMIMEタイプ・フォーマットを指定すると、リストされたタイプの中で除外されるバリエーションが限定されます。たとえば、application/mswordとリストすると、application/vnd.mswordなどのバリエーションは除外されません。この場合は、除外する各特定MIMEタイプのバリエーションをリストに含める必要があります。
例2
LkDisallowConversionFormats=msword,wav,avi
この例では、リストの各MIMEタイプのバリエーションがすべて除外されます。MIMEタイプの短縮フォーマットを使用すると、柔軟性を高めることができるためさらに有益です。
リンク・マネージャでは、ファイル・フォーマットにhcs、htm、image、text、xml、jspおよびaspのいずれかの文字列が含まれているファイルの変換にHtmlExportを使用しません。これらのファイルは、リンク・マネージャによって処理され、変換の必要はありません。システムの現在のファイル・フォーマットおよび拡張マッピングを確認するには、構成マネージャで「ファイル・フォーマット」ウィンドウを使用します。
LkReExtractOnRebuildを使用すると、再構築時に、以前に索引付けされたドキュメントからのリンクの抽出を制御できます。
LkReExtractOnRebuild=trueの場合、リンク・マネージャは、再構築時にリンクをシステムに索引付ける際に、そのリンクをドキュメントから抽出するように構成されます。これはデフォルトの設定です。
LkReExtractOnRebuild=falseの場合、リンク・マネージャでは、再構築時にリンクをシステムに索引付けする際に、そのリンクをキュメントから抽出しません。
|
注意: リンク・マネージャによる作業はすべて索引作成サイクル時に実行されるため、ドキュメントの索引作成およびコレクションの再構築に必要な時間が増加します。「LkDisableOnRebuild」も参照してください。ただし、これにかかる時間は、全体の時間の大部分がドキュメントのコレクションへの索引作成に費やされるため、重要ではない可能性があります。それでも、必要な時間は、関連するドキュメントのタイプとサイズによって決まります。つまり、ファイルの変換が必要な場合は、テキストベース(HTML)のファイルより時間がかかります。 |
ファイル・フォーマット、変換およびリンクの抽出の詳細は、「リンクの抽出プロセス」および「ファイル・フォーマットと変換」を参照してください。
LkIsSecureSearchを使用すると、リンク検索時の非管理ユーザーに対するセキュリティ制限チェックを管理できます。セキュリティ・チェックを実装するために、リンク・マネージャでは、Revisions表とManagedLinks表の内部結合が実行され、セキュリティ・グループとアカウントを使用して標準のコンテンツ・サーバー・セキュリティが適用されます。
|
注意: LkIsSecureSearch構成変数を使用したセキュリティ・チェックは限定的であり、ユーザーが検索にSite Studio固有のフィールドを使用している場合はバイパスできます。 |
LkIsSecureSearch=trueの場合は、管理されたリンクの検索実装時に、非管理ユーザーに対するセキュリティ・チェックを実行するようにリンク・マネージャが構成されます。これはデフォルトの設定です。
LkIsSecureSearch=falseの場合は、管理されたリンクの検索実装時に、リンク・マネージャによって非管理ユーザーに対するセキュリティ・チェックは実行されません。
例
リンク元のドキュメントがセキュアであり、リンク先のドキュメントがパブリックの場合、セキュアに対する権限のないユーザーは、「リンクの検索」結果で、リンクを含んでいるドキュメントを検索できません。
リンク元のドキュメントがパブリックであり、リンク先のドキュメントがセキュアの場合、リンクを含んでいるドキュメントは「リンクの検索」結果で検索されますが、同じユーザーがそのリンク(つまり、セキュアなドキュメントのWeb表示可能情報またはドキュメント情報へのリンクの場合)を使用することはできません。
リンク・マネージャ・コンポーネントでは、リソース表(LinkManagerPatterns)に定義されたリンク・パターンを参照する抽出エンジンが使用されます。これらのリンク・パターンは、様々なリンクのソート方法、フィルタ処理で除外するリンク、受け入れるリンク、および詳細情報を取得するためにリンクを解析する方法を抽出エンジンに指示するルールです。
|
注意: LinkManagerPatterns表は、他のコンポーネントから簡単にアクセスできるhda表です。LinkManagerPatterns表は次のファイル内にあります。UCM_ORACLE_HOME/ucm/idc/components/LinkManager8/resources/linkmanager_resource.htm |
この項の内容は次のとおりです。
LinkManagerPatterns表には、次の列があります。
リンク・マネージャ・コンポーネントには、コンポーネント・リソース表(LinkManagerPatterns)が含まれています。リンク評価ルールの例は、この表を参照してください。この表は、UCM_ORACLE_HOME/ucm/idc/components/LinkManager8/resources/linkmanager_resource.htmファイルにあります。表は、新しいルールを追加するか、既存のデフォルト・ルールを編集することによってカスタマイズできます。LinkManagerPatterns表のカスタマイズには、標準のコンポーネント・アーキテクチャを使用します。
この項の内容は次のとおりです。
|
重要: 問合せ実行パフォーマンスを改善するために、標準索引がManagedLinks表のdDocName列とdLkResource列に追加されています。システム管理者は、様々なシステム環境で、特定のデータベース・チューニング要件にあわせてこれらの索引を調整する必要があります。 |
パターン・エンジンでリンクの処理に成功し、リンクが承認可能と判断されると、そのリンクはManagedLinks表に格納されます。表内の各リンクには一意のクラスID(dLkClassId)が割り当てられ、表内の各行には一意のGUID(dLkGUID)があります。1つのリンクが複数のリソースで定義され、各リソースが単独でリンクを破棄できる場合、そのリンクは、表内の複数の行で構成されている可能性があります。
これは特に、1つのリンクがノードとコンテンツ・アイテムの両方で定義される可能性があるSite Studioリンクの場合に当てはまります。ノードが見つからない場合、そのリンクは破棄されます。コンテンツ・アイテムが見つからない場合、そのリンクは破棄されます。この場合、相互に依存しない2つのリソースがあり、それぞれがリンクを破棄できます。したがって、各リソースはManagedLinks表で別々に管理されます。Site Studioリンクの詳細は、「Site Studioの統合」を参照してください。
|
注意: コンテンツ・アイテムがチェックインされ、リンクでそのコンテンツ・アイテムが参照される場合、そのリンクには有効のマークが付けられます。削除したンテンツ・アイテムがリンクで参照される場合、そのリンクには無効のマークが付けられます。dLkState列には、リンクのステータスがY(有効)またはN(無効)として示されることに注意してください。 |
リンク・マネージャ・コンポーネントには、パターン・エンジンの部品用に、いくつかの非常に特殊な動作をカスタマイズできるフィルタが用意されています。一般に、パターン・エンジンのルールは、変更されることがよくあります。ただし、特定の状況では、リンク・マネージャによって、標準の動作を拡張するためのフィルタが明示的に作成および使用されます。
この項の内容は次のとおりです。
extractLinksフィルタは、抽出エンジンで承認済URLリンクが解析されるとき、リンク抽出プロセス中に使用されます。リンクが抽出されると、リンク・マネージャによって特定のHTMLタグが検索されます。ただし、他のHTMLタグにも関連リンクを含めることがあります。この場合は、このフィルタを使用して、これらの追加リンクを抽出できます。
タグは、キーHtmlTagとともに、キャッシュされたオブジェクトとしてフィルタに渡されます。値(つまりリンク)は、キーHtmlValueとともに解析に戻されます。フィルタによって追加情報が抽出された場合、渡されたバインダは、パターン・エンジンに渡される前にフラッシュされることに注意する必要があります。service.setCachedObjectおよびservice.getCachedOjectメソッドで、それぞれ追加情報を渡し、取得する必要があります。
|
注意: デフォルトでは、<a>、<link>、<iframe>、<img>、<script>および<frame>のHTMLタグが検索されます。 |
linkParseServiceフィルタは、パターン・エンジンでリンクが評価されるとき、リンク抽出プロセス中に使用されます。特に、IdcServiceパラメータを使用するために識別されるリンクの場合です。評価後、リンク・バインダとサービスがlinkParseServiceフィルタに提供されます。
サービスには、解析済のURLと情報マップのバインダが含まれています。特定のパラメータを調整して、解析済URLバインダの値をカスタマイズすることもできます。また、(parseServiceメソッドに対して、URLバインダから抽出するパラメータや、データをリソース・タイプにマップする方法を指示する)情報マップをカスタマイズすることもできます。
sortAndDecodeLinksフィルタは、リフレッシュ・オプションからのみ使用できます。つまり、ユーザーがリンクをリフレッシュしているときにのみコールされます。リンク・マネージャのリフレッシュ・オプションの詳細は、「管理されたリンクの管理ページ」を参照してください。サービスには、ManagedLinks表に格納されているリンクのソート済リストを含むLinkSetMapが含まれています。リフレッシュでは、Site Studioのリンク、およびdocリソースを参照するすべてのリンクの存在が検証されます。ただし、標準の検証を拡張するコンポーネントを作成することもできます。
Site Studioとともに機能するように構成されると、リンク・マネージャでは、Site Studioで識別されたリンクの解析を直接リクエストすることによって、Site Studioからリンクが取得されます。かわりに、Site Studioからリンクの状態やコンポーネントに関する情報が提供されます。特に、Site Studioからは、ノード/セクション、コンテンツ・アイテムが使用されるかどうか、コンテンツ・アイテムの状態、リンクのタイプ(フレンドリ、ページまたはノード)、およびリンクが有効かどうかに関する情報が提供されます。
|
重要: Site Studioを使用している場合は、HasSiteStudio構成変数値をtrueに設定する必要があります。この変数によって、パターン・エンジン用のフレンドリURLを解析するためのSite Studio固有のパターンが有効化されます。HasSiteStudio編集の詳細は、Oracle Fusion Middleware Idocスクリプト・リファレンス・ガイドを参照してください。 |
|
注意: Site Studioでは、スタンドアロン・アプリケーションの起動時に、プロジェクト情報がロードされません。したがって、スタンドアロン・アプリケーションによって再構築または索引更新サイクルが開始および完了される場合、Site Studioリンクは正しく評価されません。 |
ユーザーがSite Studio Designerを使用してリンクを変更すると、リンク・マネージャによってフィルタ・イベントがリスニングされます。その結果、ノードが削除された場合は、リンク・マネージャによって、削除されたノードを使用するすべてのリンクに無効のマークが付けられます。これは、ノードIDを直接参照するリンクがリンク・マネージャで正常に管理されていることを意味します。さらに、Site Studioから提供される情報によって、リンク・マネージャではリンクの状態を正確に判断できます。
ただし、フレンドリURL(つまり、ノードIDまたはdDocNameを参照しないリンク)は、管理および正確さの保証がより困難です。ノードのプロパティが変わると、リンク・マネージャによって、このノードを使用するすべてのフレンドリ・リンクに無効および破棄のマークが付けられます。これには、絶対リンクと相対リンクの両方が含まれます。実際にはこのような状況でない場合でも、リンク・マネージャでは、リンクの変更された部分、その修正の方法、または実際に破棄されているかどうかを判断するために、親のチェーンを再トレースできません。
Site Studioでは、2つのタイプの管理されたリンクが使用されます。
SS_GET_PAGE IdcServiceを使用するすべてのリンク。
次のものを含むノードへのリンク:
javascript:nodelink(ノード、サイト)
javascript:nodelink(ノード)
ssNodeLink(ノード、サイト)
ssNodeLink(ノード)
ssNODELINK/サイト/ノード
ssNODELINK/ノード
次のものを含むページへのリンク:
javascript:link(ドキュメント、ノード、サイト)
javascript:link(ドキュメント、ノード)
javascript:link(ドキュメント)
ssLink(ドキュメント、ノード、サイト)
ssLink(ドキュメント、ノード)
ssLink(ドキュメント)
ssLINK/サイト/ノード/ドキュメント
ssLINK/ノード/ドキュメント
ssLINK/ドキュメント
暫定的に管理されたリンク: 次のSite Studioリンクは、Site Studioノードの変更に至るまで管理されます。リンクの状態は、管理されたリンクの管理ページからリフレッシュ・オプションを使用することによって判断できます。リンクの大部分がこの形式で、ノードが大幅に変化した場合は、リンクをリフレッシュまたは再計算することをお薦めします。
絶対(または完全URL): http://site/node/doc.htm
ノードへのフレンドリ・リンク
<!--$ssServerRelativeSiteRoot-->dir/dir/index.htm
[!--$ssServerRelativeSiteRoot--]dir/dir/index.htm
<%=ssServerRelativeSiteRoot%>dir/dir/index.htm
ページへのフレンドリ・リンク
<!--$ssServerRelativeSiteRoot-->dir/dir/doc.htm
[!--$ssServerRelativeSiteRoot--]dir/dir/doc.htm
<%=ssServerRelativeSiteRoot%>dir/dir/doc.htm
この項の内容は次のとおりです。
管理されたリンクの管理ページを使用すると、リフレッシュ・アクティビティを実行して、ManagedLinks表とLinkReferenceCount表を更新できます。管理されたリンクの管理ページにアクセスするには、「管理」トレイで「管理されたリンクの管理」リンクをクリックします。
| 要素 | 説明 |
|---|---|
| ステータス | ステータスは、コンテンツ・サーバーがリフレッシュ・アクティビティを実行中かどうかを示します。アイドルの場合、ステータスは「準備完了」です。それ以外の場合、ステータスには、実行中のリフレッシュのタイプ、処理されたリンクの数、および発生したエラーの数が表示されます。ページを(たとえば、[F5]を使用して)リフレッシュすると、ステータス・メッセージがリフレッシュされます。リフレッシュ・ステータス情報の例は、「リフレッシュ・アクティビティのステータス」を参照してください。 |
| 「リンクの再計算」オプション | このリフレッシュ・アクティビティは、ManagedLinks表の各リンクを取得して、パターン・エンジンに再送信します。リンクは、パターン・ルールに従って評価され、表内で更新されます。リンクは、有効または無効になったパターンに応じて、別のタイプのリンクとして再分類される場合があります。このオプションは、パターン・ルールが変更された場合に使用します。 |
| 「リンクのリフレッシュ」オプション | このリフレッシュ・アクティビティは、ManagedLinks表の各リンクを取得して、リンクが有効かどうかを判断します。Site Studioリンクの特別な場合では、リンクはSite Studioのデコード・メソッドに送信されます。これによって、リンクで使用されるノードおよびコンテンツ・アイテムが判断されます。リンクが有効かどうか、確かにSite Studioリンクかどうかも判断されます。
このオプションは、Site Studioのノード/セクションのプロパティに多数の変更があった場合に使用します。リンク・マネージャでは、Site Studioのフレンドリ・リンクに対する変更を完全に追跡できません。リンクをリフレッシュするか、強制的に検証を実行することによって、リンク・マネージャでは、破棄されているリンクおよび有効なリンクをより正確に判断できます。 |
| 「参照カウントのリフレッシュ」オプション | このリフレッシュ・アクティビティは、LinkReferenceCount表をフラッシュして、ManagedLinks表にコンテンツ・アイテム参照を問い合せます。表の再計算と表のリフレッシュのアクティビティは両方とも、LinkReferenceCount表をメンテナンスしようとします。しかし、場合によって、この表は同期がとれなくなることがあるため、このオプションを静止したシステムで使用すると、表が再構築されます。 |
| 「リフレッシュ・アクティビティの中止」オプション | このオプションは、現在のリフレッシュ・アクティビティを中止します。一度にアクティブにできるリフレッシュ・アクティビティは1つのみです。 |
管理されたリンクの管理ページで使用可能なリフレッシュ・アクティビティ以外に、ManagedLinks表とLinkReferenceCount表の更新に使用できる代替の方法もあります。
リポジトリ・マネージャを使用して、コレクションの再構築を実行します。このプロセスでは、検索索引全体が再構築され、再構築が正常に完了すると古い索引コレクションが新しい索引コレクションに置き換えられます。
リポジトリ・マネージャをスタンドアロン・アプリケーションとして開いている場合、この代替リフレッシュ方法を使用できるのは、HasSiteStudio構成変数が有効化されていないときのみです。Site Studioから情報がリクエストされ、リポジトリ・マネージャがスタンドアロン・モードである場合、Site Studioは完全に初期化されず、正確な情報が返されません。これは、リポジトリ・マネージャ・アプレットを開いている場合、問題ではありません。
コンテンツがシステム内にある間にカスタム・フィールドが追加された場合は、「検索索引の再構築」ボタンが有効であるため、構成マネージャを使用して更新を実行できます。この結果、検索索引全体が再構築されます。
ManagedLinks表のリンクを再評価する手順は、次のとおりです。
「管理」トレイの「管理されたリンクの管理」リンクをクリックします。管理されたリンクの管理ページが表示されます。
「リンクの再計算」オプションの横にある「実行」をクリックします。「ステータス」領域には、処理されたリンクの数、および発生したエラーの数が表示されます。
|
注意: 一度にアクティブにできるリフレッシュ・アクティビティは1つのみです。別のリフレッシュ・アクティビティを試行するには、リフレッシュ・アクティビティが完了し、「準備完了」ステータスが表示されるまで待機する必要があります。 |
ManagedLinks表のリンクを更新する手順は、次のとおりです。
「管理」トレイの「管理されたリンクの管理」リンクをクリックします。管理されたリンクの管理ページが表示されます。
「リンクのリフレッシュ」オプションの横にある「実行」をクリックします。「ステータス」領域には、処理されたリンクの数、および発生したエラーの数が表示されます。
|
注意: 一度にアクティブにできるリフレッシュ・アクティビティは1つのみです。別のリフレッシュ・アクティビティを試行するには、リフレッシュ・アクティビティが完了し、「準備完了」ステータスが表示されるまで待機する必要があります。 |
LinkReferenceCount表のリンクを更新する手順は、次のとおりです。
「管理」トレイの「管理されたリンクの管理」リンクをクリックします。管理されたリンクの管理ページが表示されます。
「参照カウントのリフレッシュ」オプションの横にある「実行」をクリックします。「ステータス」領域には、処理されたリンクの数、および発生したエラーの数が表示されます。
|
注意: 一度にアクティブにできるリフレッシュ・アクティビティは1つのみです。別のリフレッシュ・アクティビティを試行するには、リフレッシュ・アクティビティが完了し、「準備完了」ステータスが表示されるまで待機する必要があります。 |
