この章の内容は次のとおりです。
アプリケーション・フィールドは、フォームおよびページのカスタマイズに使用できるカスタム・フィールドです。アプリケーション・フィールドを使用すると、フォームに依存リストなどの機能を追加できます。また、カスタム・コンポーネント、Hypertext Content Server Page (HCSP)ファイルおよびHypertext Content Server Form (HCSF)ファイルで、アプリケーション・フィールドを使用することもできます。
デフォルトでは、アプリケーション・フィールドは標準のチェックイン・フォームおよび検索フォームには表示されませんが、カスタム・テンプレートでは使用されます。アプリケーション・フィールドは、プレースホルダとして使用したり、関連するメタデータ・フィールドを作成せずに依存リストを有効にするために、スキーマ・ビューと組み合せて使用できます。詳細は、「スキーマを使用したメタデータのカスタマイズ」を参照してください。
コンテンツ・プロファイルで、どのアプリケーション・フィールドを、標準の「チェックイン」ページおよび「検索」ページに表示するのかを指定できます。詳細は、「コンテンツ・プロファイルの管理」を参照してください。
アプリケーション・フィールドは索引付けされておらず、検索可能ではありません。アプリケーション・フィールドの変更は、データベースまたは索引に影響を与えません。
電子シグネチャ・コンポーネントを使用する場合は、電子シグネチャ・メタデータとともに使用するためのカスタム・フィールドを定義することもできます。電子シグネチャの詳細は、「コンテンツの電子署名」を参照してください。
各コンテンツ・アイテムについて、システムでは、そのコンテンツに関する一連の情報(メタデータ)がメンテナンスされます。メタデータは、図書館のカード目録にあるカードに類似しており、実際のファイルは図書館の本に類似しています。カード目録と同様に、メタデータはファイルに関する情報(タイトル、参照番号、作成者、件名、公開日、ブックの場所など)で構成されています。
システムに備えられている標準メタデータ・フィールドとは別に、独自のコンテンツやシステムの設計要件に対応するために新しいフィールドを作成できます。コンテンツ・アイテムの検索や管理を容易にするために必要な追加メタデータは、必要最低限の量のみを作成することが重要です。
カスタム・フィールドの名前を作成すると、予約名と競合しない一意の名前になるように、名前に接頭辞'x'が自動的に付加されます。同様に、カスタム・ユーザー情報(メタデータ)フィールドを作成すると、予約名と競合しない一意の名前になるよう、名前に接頭辞'u'が付加されます。
メタデータ・フィールドは、索引付けされているため検索可能です。カスタム・メタデータ・フィールドの変更は、データベース(メタデータ・フィールドに関する情報が格納される場所)または検索索引(メタデータ値が格納される場所)に影響を与える可能性があります。
この項の内容は次のとおりです。
システムには次の標準フィールドが備えられています。これらのフィールドは編集および削除できません。
フィールド・キャプション | 入力方法 | 必須 | 定義 |
---|---|---|---|
コンテンツID |
テキスト入力または自動生成 |
はい |
各コンテンツ・アイテムの一意の識別子。
OracleまたはDB2のデータベースを使用している場合、コンテンツIDはすべて自動的に大文字に変換されます。 |
タイプ |
リスト |
はい |
コンテンツのグループ化に使用する識別子。
|
タイトル |
テキスト入力 |
はい |
コンテンツ・アイテムの説明的なタイトル。
|
作成者 |
リストまたはテキスト入力 |
はい |
コンテンツ・アイテムをチェックインしたユーザー。 |
セキュリティ・グループ |
リスト |
はい |
コンテンツ・アイテムにアクセスするためにユーザーに権限が必要なセキュリティ・グループ。
|
アカウント |
リストまたはテキスト入力 |
いいえ |
コンテンツ・アイテムにアクセスするためにユーザーに権限が必要なアカウント。 このフィールドは、アカウントが有効になっている場合にのみ使用できます。 |
プライマリ・ファイル |
テキスト入力またはファイルの参照 |
はい |
チェックインするネイティブ・ファイルへの完全パス。ファイル名の最大長は、ディレクトリ・パスとファイル拡張子を含めて80文字です。ファイル拡張子の最大長は8文字です。 Foldersのインストール時には、オプションによって、ファイル名のこの最大長が255文字に変更されます。 |
代替ファイル |
テキスト入力またはファイルの参照 |
いいえ |
ネイティブ・ドキュメントの別のWeb表示可能ファイル形式へのパス名、またはWeb表示可能フォーマットに変換可能なファイル形式へのパス名。 たとえば、複数のファイルで構成されたFrameMakerまたはQuarkドキュメントをチェックインしている場合は、ネイティブ・フォーマット(プライマリ・ファイル)としてzipファイルをチェックインし、その代替ファイルとしてPostscript、PDFまたは表示可能ファイルをチェックインします。zipファイルはWeb上で表示できませんが、Inbound Refineryでは、PostscriptファイルがそのWeb表示可能フォーマットであるPDFに変換されます。 ファイル名の最大長は、ディレクトリ・パスとファイル拡張子を含めて80文字です。ファイル拡張子の最大長は8文字です。 Foldersのインストール時には、オプションによって、ファイル名のこの最大長が255文字に変更されます。 |
リビジョン |
自動生成またはテキスト入力 |
はい |
コンテンツ・アイテムがそのライフサイクルを終了した回数(リビジョン数)を表すラベル(1、2、3、...またはA、B、C、...など)。リビジョン・ラベルは、独自のリビジョン・スキームに合わせてカスタマイズできます。 |
コメント(オプション) |
ユーザーによるテキスト入力 |
いいえ |
ファイルに関する追加情報のフィールド。フィールドの最大長は255です。 このフィールドはカスタム・フィールドとみなされるため、削除できます。 |
リリース日 |
自動生成またはテキスト入力 |
はい |
ファイルがリリースされ、検索や表示に使用できるようになる日付。リリース日のデフォルトは、ファイルがチェックインされた日時です。 |
有効期限 |
テキスト入力 |
いいえ |
ファイルが検索または表示に使用できなくなる日付。現在のリビジョンの有効期限が切れると、コンテンツ・アイテムのすべてのリビジョンが有効期限切れになります。コンテンツ・アイテムの有効期限が切れた場合、リビジョンは保存されるものの、期限切れの通知を使用しないかぎり、管理者のみがリポジトリ・マネージャからアクセスできます。 |
次の表に、使用される検索エンジンに応じてデータベースの更新または検索索引の再構築が必要になるイベントを示します。
イベント | 必要になるアクション |
---|---|
メタデータ・フィールドの追加 |
データベースの更新 |
メタデータ・フィールドの編集 |
データベースの更新 |
メタデータ・フィールドの削除 |
データベースの更新 |
メタデータ・フィールドの「検索索引の有効化」の有効化または無効化 |
検索索引の再構築 |
「検索索引の有効化」が選択されているメタデータ・フィールドの追加 |
検索索引の再構築 |
データベースの再構築
データベースへの保存が必要となる変更を加えた場合は、「構成マネージャ」ページの「情報フィールド」タブの「データベース設計の更新」ボタンがアクティブになります。データベースを更新する手順は、次のとおりです。
「データベース設計の更新」をクリックします。
フィールドを保存するには、フィールド名の横にあるボックスの選択を解除します。フィールドは非表示のままですが、データベース内に存在します。
追加されたフィールドおよび編集されたフィールドは、このページを使用して削除できません。追加し、その後、削除する必要があります。
終了したら、「OK」をクリックします。
索引の再構築
検索索引の再構築が必要となる変更を加えた場合は、「構成マネージャ」ページの「情報フィールド」タブの「検索索引の再構築」ボタンがアクティブになります。検索索引を再構築する手順は、次のとおりです。
「再構築を開始しました。」
が表示された場合は、「OK」をクリックします。注意:
検索索引および使用可能なシステム・リソースのサイズによっては、検索索引再構築プロセスに数日かかることがあります。再構築が必要な場合は、システム使用率がピーク以外の時間帯に再構築を実施してください。
ユーザーが値を選択できる選択肢を示すために、カスタム・フィールドとともにリストを使用します。
リストを定義するには、次のステップに従います。
リストの作成には、ストレージ・オプションの決定が含まれます。ストレージを定義するには、オプション・リストの構成ページで、「オプション・リスト・タイプ」の横にある「詳細」をクリックします。次の情報を入力します。
ストレージ・タイプ: リスト・キーを永続的に格納するか、またはローカライズされたリストを格納するかを選択します。
複数選択オプション: 複数選択リストの外観をカスタマイズするためのオプションを選択します。
末尾のパディング: 複数選択の値のセパレータの長さをパディングします。
ストレージ・セパレータ: 値の格納に使用するセパレータを変更します。
表示セパレータ: 値の表示に使用されるセパレータを変更します。
終了したら、「OK」をクリックします。
「オプションリスト」ページを開くには、オプション・リストの構成ページで、「オプション・リストの使用」フィールドの横にある「編集」をクリックします。次の情報を入力します。
オプション・リストの値: 選択するアイテム。各値の間には改行を入力し、1行ごとに1つの値を指定する必要があります。
ソート順序(昇順または降順): リストを英数字の順序でソートします。昇順の場合は、大文字が小文字よりも前に配置されます。降順の場合、逆のことが行われます。「大文字小文字を区別しない」を選択すると、リストはソートされ、大文字小文字は無視されます。
今すぐソートする: 指定した方法(昇順など)でリストがソートされます。
ビューには、リストで使用できるアイテムが表示されます。ビューを編集するには、オプション・リストの構成ページで、「ビューの使用」フィールドの横にある「ビューの編集」をクリックします。次の選択を行います。
フィルタ: どの値がページに表示されるかを変更するためのフィルタを選択します。
列の表示: 表示する列数を制限します。
追加、編集: 現在のビュー内の値に対して、新しい値を追加または変更できるページを表示します。
削除: ビューから値を削除することについて、確認を求めます。
バッチの編集: 行エディタで値を編集するのに使用できるページを表示します。値を追加するには、適切な列にパイプ記号(|)で区切ってデータを入力します。表内の各行は、改行で区切る必要があります。
値リストを表示するカスタム・メタデータ・フィールドを作成するには、構成マネージャ・ユーティリティの「情報フィールド」タブを使用します。また、別のフィールドの値に依存する、関連付けられたリストを作成することもできます。この構成は、依存選択リスト(DCL)と呼ばれます。
たとえば、CountryおよびStateという情報フィールドがあるとします。選択した国によって、「State」リストで使用できる選択肢が決定します。
メタデータ・スキーマ・マッピングを使用してフィールド・リストを作成することもできます。メタデータ・スキーマ・マッピングを使用すると、ローカライズの要件に従って、オプション・リスト表示を簡単に調整できます。
この項では、次の項目について説明します。
スキーマは、関連するスキーマ・オブジェクトの集まりです。スキーマという用語は、コンテンツ・サーバーのメタデータ・スキーマ・マッピング機能をサポートするために作成されるデータベース構造のグラフィカル表現も指します。スキーマ階層構造は、表とその表の各列(フィールド)、データのビュー、およびデータ間のリレーションシップで構成されます。
3層の依存構造を表すために、City、RegionおよびArea Codeという情報フィールドをCountryとStateの例に追加します。
図7-1のサンプルの基本スキーマ階層では、1つの独立フィールドに2つの依存フィールドがあります。各依存フィールドにも1つの依存フィールドがあります。これらの依存関係は、親/子関係とも呼ばれます。
図7-1 基本スキーマ階層の例
この3つのレベルのスキーマ階層では、Country、State、City、RegionおよびArea Codeの5つの個別メタデータ・フィールドが生成されます。各フィールドは、固有のリストをユーザーに対して提示します。
リストの内容は、情報フィールドが依存しているかどうかによって決まります。したがって、サンプルの基本Country/State/Area Codeスキーマ階層からは、次のリストが生成されます。
「Country」リストは独立しており、選択肢は固定されています。
「State」リストで使用可能な選択肢は可変であり、ユーザーが「Country」リストで選択した国に依存します。
「City」リストで使用可能な選択肢は可変であり、ユーザーが「State」リストで選択した州に依存します。
「Region」リストで使用可能な選択肢は可変であり、ユーザーが「Country」リストで選択した国に依存します。
「Area Code」リストで使用可能な選択肢は可変であり、ユーザーが「Region」リストで選択した地域に依存します。
スキーマ表は、情報フィールド(メタデータ)のリストに表示される選択肢を格納するデータベース表です。表とその列は、構成マネージャの「表」タブを使用して作成されます。各表は複数の列を持つことができますが、依存選択リストを生成するためには少なくとも2つの列が必要です。
1つのリストと、そのリストで選択された選択肢に依存する2つ目のリスト(それぞれCountryとStateなど)の間の依存関係の作成に使用する共通の列名
メタデータ・リストの選択肢を格納する列
図7-2 スキーマ表の例
3層のスキーマ階層の地理の例(Country、State、City、Region、Area Code)を使用して、スキーマ・ツリー構造のブランチごとに表を作成する必要があります。また、依存表(子表)には、従属する表(親表)の列に対応する列を含める必要があります。これらの対応する列は、2つの表間の依存関係の作成に使用され、最終的には依存選択リストの生成に使用されます。
たとえば、図7-3 の表は、Country表とState表の各列の移入方法を示しています。各name列のデータは、リストで使用可能な選択肢を示しています。Country表とState表の対応する列(countryID)間に作成されるリレーションシップによって、Stateメタデータ・リストに表示される選択肢が決定します。
図7-3 移入済のスキーマ表
ビューは、対応する表のカスタマイズされた表現です。ビューにはデータが含まれませんが、各表からデータを導出します。ビューは、使用するデータベースを簡素化し、データを様々な観点で提示するために使用されます。
ビューは、プロパティのリストと関連付けられた表示ルールで構成されます。スキーマの各表には関連付けられたビューが必要です。ビューでは、次のアイテムに関する情報が提供されます。
スキーマに含まれる表の特定の列。選択された列は、表間の依存関係の確立に使用され、依存選択リストの生成にも使用されます。
内部および外部の列名。
ユーザー・インタフェースの表示特性。
編集およびソート順序の基準。
リレーションシップでは表間の依存関係が定義されるため、適切な依存選択リストを生成するのに不可欠です。定義したそれぞれのリレーションシップによって、親表と子表間の対応関係が確立されます。この対応関係は、親表の列に依存する子表の列を指定することで作成されます。したがって、子表の列のデータを使用して表示される選択肢は、親表の対応する列のデータの選択によって決定します。
たとえば、図7-4のCountryView (Country表)とStateView (State表)では、countryID列を使用して、親のCountryリストと子のStateリストを生成するリレーションシップが作成されています。Stateメタデータ・リストで使用可能な選択肢は、Countryメタデータ・リストでの選択に依存します。
図7-4 表と列のリレーションシップ
/weblayout/resourcesディレクトリにある3つのサブディレクトリがスキーマ機能に関連付けられています。
schema
schema.work
schema.old
schema.workディレクトリは、一時ディレクトリのため、通常は表示されません。スキーマ作成プロセスが完了すると、作業ディレクトリの名前は変更されます。このディレクトリが存在する場合は、次のいずれかを表しています。
大規模なスキーマの再構築が進行中です。
スキーマは作成されましたが、スキーマ構造に問題があります。
注意:
スキーマのファイルとディレクトリをレビューするためにディレクトリ構造内で作業する場合は、これらのファイルにアクセスしているオープン中のすべてのアプリケーションを必ず終了してください。ディレクトリの名前は、処理の完了後に変更されます。ただし、テキスト・エディタなどの外部アプリケーションによってこれらのファイルが使用されている場合は、schema.workディレクトリの名前を変更できません。
スキーマ表、ビューおよびリレーションシップを作成し、適切に確立すると、リストに適切な選択肢が表示されます。たとえば、図7-5の「Country」リストには、「United States」と「Canada」の2つの選択肢が表示されるようになりました。
図7-5 リストの例
Stateメタデータ・フィールドはCountryフィールドによって決定するため、「State」リストには「Country」リストでの選択に基づいたアイテムが含まれます。ここでは、選択肢のうち「United States」が選択された場合は、「State」リストの選択肢として「Minnesota」と「Wisconsin」が表示されます。「Canada」が選択された場合は、「State」リストに「Ontario」と「Quebec」が表示されます。
図7-6 依存リストの例
構成マネージャの「表」、「ビュー」および「リレーション」の各タブを使用してスキーマ構造を作成します。
「表」タブは、データベース表を選択または作成するために使用します。
「ビュー」タブは、スキーマで使用されるビューを操作するために使用します。
「リレーション」タブは、依存関係を操作するために使用します。
「情報フィールド」タブは、コンテンツ・サーバーのページで使用されるメタデータ・フィールドを作成するために使用します。リストを適切に表示するには、メタデータ・フィールドを表とビューに関連付ける必要があります。
新しいスキーマまたは変更されたスキーマは、スケジュールされた各パブリッシュ・サイクル時に自動的に更新されます。各パブリッシュ・サイクル間のデフォルト間隔は4時間に設定されているため、新しいスキーマまたは変更されたスキーマの結果は即座には表示されません。各パブリッシュ・サイクル間の間隔を調整するには、関連付けられた構成変数のデフォルト値を変更します。詳細は、「パブリッシュ・サイクル間隔の変更」を参照してください。
この項では、構成マネージャの該当するタブを使用してスキーマ構造を作成する簡単な手順の概要を示します。
この項では、スキーマの作成における次のステップについて説明します。
スキーマ・ビューを作成する手順は、次のとおりです。
スキーマ作成の最終フェーズは、選択した各列を使用するためにメタデータ・フィールドを設定し、作成したビューとリレーションを使用するためにそれらの列を構成することです。手順の概要は、「カスタム・フィールドの追加または編集」および「オプション・リストの定義」を参照してください。
スキーマ、ビューおよびリレーションシップを構成した後で、「構成マネージャ」ページ上のボタンをクリックしてデータベース設計を更新します。構成マネージャの「ページ」メニューで「オプション」→「スキーマのパブリッシュ」をクリックします。
スキーマの再パブリッシュ(更新)は、次の状況に基づいて自動的に実行されます。
data/schema/publishlock/publish.dat
ファイルの存在。
自動のパブリッシュ時刻の内部スケジュール。このスケジュールを変更する方法の詳細は、「パブリッシュ・サイクル間隔の変更」を参照してください。
前回スキーマのパブリッシュに要した時間。
「オプション」→「スキーマのパブリッシュ」は、新しいコンテンツ・タイプをすぐに反映する必要がある場合以外は選択しないでください。大きいリストを再パブリッシュすると、システムがオーバーロードの状態になることがあります。
新しいスキーマまたは変更されたスキーマは、スキーマの自動パブリッシュ・サイクル時に自動的に更新されます。ただし、パブリッシュ・サイクル間の間隔はデフォルトで4時間に設定されています。新しいスキーマや、既存のスキーマに加えた変更は、次回のパブリッシュ・サイクルの完了まで、対応するメニュー・リストに反映されません。パブリッシュ・サイクル間隔を調整するには、SchemaPublishInterval構成変数の値を変更します。
スキーマのパブリッシュ・サイクル間隔を変更する手順は、次のとおりです。
スキーマのパブリッシュの問合せは、最大5分間キャッシュされます。パブリッシュの頻度を高くしても、現在のキャッシュが期限切れになるまで新しい値は取得されません。
新しい値がメタデータ・フィールドに追加された場合、次回のパブリッシュ・サイクルが完了するまで、その値はコンテンツ・アイテムの「コンテンツ情報」ページに表示されません。
あるコンテンツ・アイテムがチェックインされたときにその値が動的リスト内で一意であり、2つ目のアイテムがチェックインされたときに、値は同じで大文字と小文字の区別が異なる場合は、その値はリスト内で1つの値として処理されます。大文字小文字の使用は、データベースのソート・スキームによって決まります。
動的リストの作成の詳細は、「スキーマの例: 動的リスト」を参照してください。
動的リストを作成すると、ユーザーがメタデータ・リストに値を追加できるようになります。たとえば、ある値がリストに存在している場合は、ユーザーはその値をリストから選択できます。ただし、それが新しい値の場合は、ユーザーが値をテキスト・フィールドに入力すると、次のパブリッシュ・サイクルの後にその値が選択肢の1つとして使用できるようになります。
動的リストを作成するには、最初にデータベース内の表に対するビューを作成します。リスト値は、格納されているメタデータ列から直接取得されます。コンテンツ・アイテムがチェックイン、改訂および削除されると、リスト値はそれに応じて変更または更新されます。
次のステップは、動的リストを作成する例を示しています。
このリストをテストするには、ドキュメントをチェックインし、新しい動的メタデータ・フィールドに値を入力します。このリストは最初は空ですが、これはTestMetadataフィールドにデータが格納されたドキュメントがまだチェックインされていないためです。ただし、TestMetadataに値が入力されているドキュメントがチェックインされると、指定された値がリストに追加されます。
再帰表を作成すると、データを複数のスキーマ・ツリーに使用できるようになります。
メイン・メニューを使用して、「管理」→「管理アプレット」を選択します。
「構成マネージャ」→「情報フィールド」タブをクリックします。
2つの列(id、parent
)を含むデータベース表を作成します。
「表」タブを開いて、「表の作成」をクリックします。
表table_nameの作成/編集ページで、表の名前を入力します。たとえば、TreeTest
です。
「列」ペインで、「追加」をクリックします。
列の追加/編集ページで、最初の列名(id
)とその長さを入力します。「OK」をクリックします。
2番目の列名(parent
)とその長さを入力します。「OK」をクリックします。
「OK」をクリックして表を作成します。
両方の列が含まれた表にビューを作成します。
「ビュー」タブを開いて、「追加」をクリックします。
「ビューの追加」ページ: 「表の選択」ページの「表」ペインでTreeTest
を選択し、「次へ」をクリックします。
「列」ペインで、id
とparent
のチェック・ボックスを選択し、「終了」をクリックします。
ビューの追加/編集ページで、ビュー名を入力します。たとえば、TreeTestView
です。表示、オプションおよびセキュリティの構成を必要に応じて追加します。
「表示」タブ: リレーションシップのルールを作成するために使用します。
「オプション」タブ: スキーマ内のデータのソート順序や条件を設定するために使用します。
「セキュリティ」タブ: スキーマのセキュリティ・ルールを定義するために使用します。
「OK」をクリックしてビューを作成します。
ビューにリレーションシップを作成します。
「リレーション」タブを開いて、「追加」をクリックします。
リレーションシップの追加/編集ページで、リレーションシップ名を入力します。たとえば、TreeTestRecursive
です。
「親情報」表リストから、「TreeTest
」を選択し、対応する列リストで「id
」を選択します。
「子情報」表リストから、「TreeTest
」を選択し、対応する列リストで「parent
」を選択します。
「OK」をクリックしてリレーションシップを作成します。
「情報フィールド」タブを開いて、「追加」をクリックします。
「メタデータ・フィールド名の追加」ページで、カスタム・メタデータ・フィールドの名前を入力し、「OK」をクリックします。
メタデータ・フィールドの追加/編集ページで、「オプション・リストの有効化」を選択し、 「構成」をクリックします。
オプション・リストの構成ページで、「ツリーを使用」をクリックし、「定義の編集」をクリックします。
「ツリー定義の編集」ページの作成レベル・ペイン: 「レベル1のビューを選択」リストで、「TreeTestView」を選択します。
「ツリー定義」ペインに、TreeTestViewがレベル1として入力されます。
作成レベル・ペイン: 「1と2レベル間のリレーションシップを選択」リストの「TreeTestRecursive」をクリックします。
「ツリー定義」ペインの「TreeTestView」の下に、TreeTestRecursiveが追加されます。
作成レベル・ペイン: 「レベル2のビューを選択」リストの「TreeTestView(レベル1に戻る)」をクリックします。
「ツリー定義」ペインに、「TreeTestView(レベル1に戻る)」がレベル2として入力され、「ルートの選択」ボタンが追加されます。
「ルートの選択」をクリックします。
ツリー・ルートの選択画面が開きます。