照会
Content Engine の検索で重要な部分は、SearchSQL インスタンスに含まれる SQL ステートメント、および SearchScope オブジェクトに含まれる 1 つ以上の検索対象オブジェクト・ストアです。コンテンツ検索は、SQL ステートメントの CONTAINS 演算子を使用して指定します。
SQL ステートメント
SearchSQL クラスには、SQL ステートメントの作成に役立つヘルパー・メソッドがあります。一方、SQL ステートメントを独自に作成して、それを SearchSQL インスタンスに文字列として渡すことも可能です。SQL ステートメントは、IBM® FileNet® 標準に従っている必要があります。FileNet 標準は総じて SQL-92 に準拠しており、一部 IBM FileNet 独自の構成体に拡張があります。詳細については、SQL 構文のリファレンスを参照してください。
SearchSQL ヘルパー・メソッドは、SQL ステートメントの作成を支援するために用意されていますが、独自に作成したステートメントで達成できるレベルの仕様は提供できません。ただし、開発環境では、ヘルパー・メソッドを使用して SQL ステートメントを最初に作成した後、SearchSQL.toString メソッドを使用して SQL ステートメントの文字列を取得し、手動で SQL ステートメントを洗練させることができます。
検索スコープ
SearchScope メソッドは、1 つ以上のオブジェクト・ストアに対して SQL ステートメントを実行し、オブジェクト (IndependentObject インスタンス)、データベース行 (RepositoryRow インスタンス)、またはメタデータ (ClassDescription インスタンス) を検索します。
SearchScope クラスでは、単一の照会を使用して 1 つ以上のオブジェクト・ストアを検索できます。複数のオブジェクト・ストアに関する単一の照会を作成するには、次のコード例のように、オブジェクト・ストアの配列を指定した SearchScope のコンストラクターを呼び出します。
ObjectStore[] osArray = new ObjectStore[]{os1,os2};
SearchScope objStores = new SearchScope(osArray, MergeMode.INTERSECTION);
次いで、この SearchScope インスタンスを使用して照会を実行します。照会を実行すると、オブジェクト・ストアからの結果はマージされ、単一の順序付きリストとして返されます。
例えば、2 つのオブジェクト・ストアを含むリストに対して、検索ステートメント SELECT DocumentTitle FROM Document WHERE DocumentTitle LIKE 'C%' ORDER BY DocumentTitle を実行すると、以下のような結果が (単一のコレクションとして) 得られます。
Cars
City
Concrete
Cows
Cars と Concrete は、最初のオブジェクト・ストアから提供され、City と Cows は、2 番目のオブジェクト・ストアから提供されています。異なるオブジェクト・ストアから収集される結果は、検索ステートメントの ORDER BY 節によって並べ替えられてリストに表示されることに留意してください。
クラスとプロパティーの一致
クラスとプロパティーは、各オブジェクト・ストアで定義されます。オブジェクト・ストア内のクラスまたはプロパティーが、別のオブジェクト・ストアに存在するクラスまたはプロパティーと同一であると見なされるのは、比較対象のクラスまたはプロパティーが同じ GUID を持っている場合に限られます。名前が同じでも、比較対象のクラスまたはプロパティーが同じであるとは限りません。
GUID の値は、ClassDefinition および PropertyDefinition の両方のクラスのプロパティーに保管されています。
ClassDefinition オブジェクトには、GUID である Id プロパティーと、GUID のリストである AliasIds プロパティーの両方が含まれています。Id プロパティーに含まれる GUID は、ClassDefinition オブジェクトを識別するために使用されます。 AliasId プロパティーを代わりに使用して、これらのオブジェクトを識別することもできます。2 つの異なるオブジェクト・ストアからの 2 つの ClassDefinition オブジェクトが同一であると見なされるのは、一方の ClassDefinition オブジェクトの Id プロパティーまたは AliasId プロパティーの値が、他方の ClassDefinition オブジェクトの対応するプロパティーの値と一致する場合です。
例えば、照会 SELECT * from DocSubClass を、2 つのオブジェクト・ストアを含むリストに対して実行すると、DocSubClass という名前のオブジェクトが両方のオブジェクト・ストアから戻される可能性があります。これらのオブジェクトの Id または AliasId プロパティーの値が同じでなければ、これらのオブジェクトは同一のオブジェクトであるとは見なされません。名前 DocSubClass を使用して両方のオブジェクト・ストアの照会を試みても、2 番目のオブジェクト・ストアから行は返されません。 ただし、2 番目のオブジェクト・ストア内のオブジェクト DocSubClass は、名前形式ではなく、ClassDefinition.Id プロパティーの文字列形式を使用して参照できます。
PropertyDefinition オブジェクトには、Id、PrimaryId、および AliasId の各プロパティーが含まれています。PropertyDefinition オブジェクトでは、Id プロパティーではなく、PrimaryId プロパティーを使用してオブジェクトが識別されます (PrimaryId プロパティーは、その参照先の PropertyTemplate オブジェクトの Id プロパティーと同じであることに注意してください)。2 つの異なるオブジェクト・ストアからのそれぞれの PropertyDefinition オブジェクトは、一方の PropertyDefinition オブジェクトの PrimaryId プロパティーまたは AliasId プロパティーの値が、他方の PropertyDefinition オブジェクトの対応するプロパティーの値と一致し、さらに両方の PropertyDefinition オブジェクトの ClassDefinition オブジェクトも一致する場合、同一のオブジェクトであると見なされます。
ClassDefinition オブジェクトと PropertyDefinition オブジェクトの両方の AliasId プロパティーは、累積的なプロパティーです。例えば、次の表に示すクラス ID と別名 ID の値を持つオブジェクト・ストア A、B、C、D から、4 つのオブジェクトがマージされる場合を想定します (簡潔にするため、1 桁の整数を使用します)。
オブジェクト・ストア | クラス ID | 別名 ID | クラスの ID |
---|---|---|---|
OS-A | 1 | 2 | 1, 2 |
OS-B | 2 | 3 | 1, 2, 3 |
OS-C | 3 | 4 | 1, 2, 3, 4 |
OS-D | 4 | (なし) | 1, 2, 3, 4 |
「クラスの ID」列の値は、累積的なオブジェクト GUID を示しています。これが別のオブジェクトの任意の ID または「別名 ID」と一致した場合、照会のために 2 つのオブジェクトがマージされます。そのため、表のすべてのオブジェクトには、みな同じオブジェクトとして別名が付けられます。この例は、ID がどのように一致するのかを示しています。実際のデプロイでは、この複合のクラス別名スキームはあまり使用されません。
一般的な別名割り当て方式は次のとおりです。
オブジェクト・ストア | クラス ID | 別名 ID | クラスの ID |
---|---|---|---|
OS-A | 1 | (なし) | |
OS-B | 2 | 1 | |
OS-C | 3 | 1 | |
OS-D | 3 | 1 |
別名 ID では、重複する一致は許可されません。すなわち、1 つのオブジェクトが他の複数のオブジェクトと一致することはできず、1 つのプロパティーが他の複数のプロパティーと一致することもできません。別名 ID をセットアップしたために重複する一致が発生するようになると、例外がスローされ、(重複する別名 ID を含むオブジェクトだけではなく) その組み合わせのオブジェクト・ストアに含まれるどのオブジェクトに対しても、複数のオブジェクト・ストア照会は許可されません。
通常、システム管理者はあるオブジェクト・ストアでクラスとプロパティーを作成したら、そのオブジェクト・ストアからそれらの定義をエクスポートして、オブジェクト・ストア全体の照会をサポートする必要のある他のすべてのオブジェクト・ストアにそれらの定義をインポートします。このエクスポート/インポート操作を行うことによって、各オブジェクト・ストア内でクラスとプロパティーの ID は確実に同一になります。インポートされた名前も同一になります。
オブジェクト・ストア全体の照会をサポートしなければならないオブジェクト・ストアに ID の異なる既存のオブジェクトが含まれている場合は、代わりの ID として別名 ID を使用する必要があります。この場合、システム管理者は、各オブジェクト・ストア上にある一致する目的のオブジェクトおよびプロパティーに対して、別名 ID を割り当てる必要があります。別名 ID を割り当てると、あるオブジェクト・ストア内のオブジェクトの ClassDefinition.Id プロパティーが、別のオブジェクト・ストア内のそのオブジェクトの AliasId リストに割り当てられます。また、あるオブジェクト・ストア内のプロパティーの PropertyDefinition.PrimaryId プロパティーが、別のオブジェクト・ストア内のそのプロパティーの AliasId リストに割り当てられます。
クラス名およびプロパティー名
クラスまたはプロパティーの名前を決定するときは、クラスが検出された最初のオブジェクト・ストアによってその名前が決定されます。例えば、最初のオブジェクト・ストアには「apple」という名前のオブジェクト、2 番目のオブジェクト・ストアには「orange」という名前のオブジェクトが存在しており、これらの両方のオブジェクトは Id プロパティーに同じ GUID 値を持っているものとします。両方のオブジェクト・ストアに対してオブジェクト・ストア照会を実行した場合、「apple」という名前を持つオブジェクトへの参照はすべて「apple」オブジェクトと「orange」オブジェクトの両方に一致します。「orange」という名前を持つオブジェクトへの名前参照は、すべて未定義のクラス例外をスローします。
オブジェクト・ストアの検索順序が名前ベースの照会に影響を及ぼすことがあるため、オブジェクト・ストアに対して照会を実行するときは、毎回同じオブジェクト・ストア順序を使用するようにします。そのほうが効果的です。オブジェクト・ストア A をオブジェクト・ストア B にマージしたときに生成される結果は、オブジェクト・ストア B をオブジェクト・ストア A にマージしたときの結果と同じではありません。そのため、サーバーは、順序に依存する (B に A を、および A に B を) マージされたオブジェクト・ストアのメタデータをキャッシュに入れる必要があります。ある照会の順序を次の照会で変更すると、過剰な量のメタデータがキャッシュに入れられることがあります。その結果、大量のメモリーがキャッシュに入れられたり、スラッシングが発生したりすることがあります。スラッシングは、サイズ制限のためにメタデータがキャッシュからフラッシュされ、後でそのメタデータが再構成されることによって発生します。
マージ・モード
オブジェクト・ストア全体に対する照会で指定するマージ・モードは、クラスおよびプロパティーのマージ方法に影響を及ぼします。 マージ・モードには、共通と和 (MergeMode.INTERSECTION および MergeMode.UNION) の 2 つがあります。
インターセクション・マージの場合は、すべてのオブジェクト・ストアに定義されたオブジェクトとプロパティーのみが、マージしたメタデータに提供されます。また、検索で参照できるのは、これらのオブジェクトとプロパティーに限られます。あるオブジェクト・ストアにクラスまたはプロパティーが存在しており、そのクラスまたはプロパティーがすべてのオブジェクト・ストア内で一致しない場合、それらは、マージされたメタデータから除外され、検索で使用することはできません。
ユニオン・マージの場合は、すべてのオブジェクト・ストアからのクラスとプロパティーが、マージされたメタデータにすべて提供されます。また、クラスとプロパティーは、すべて戻すことができます。
例として、以下を想定します。
- ターゲット・オブジェクト・ストアとして、OS1、OS2、および OS3 があります。
- オブジェクト「Alpha」は、これらの各オブジェクト・ストアに存在しています。
- 「Alpha」の ID は、各オブジェクト・ストア内で一致しています。
- 名前が一致していれば、「Alpha」のプロパティーの ID は一致しています。
(OS1 は、コレクション内の最初のオブジェクト・ストアであることに注意してください。)各オブジェクト・ストアの「Alpha」には、以下のカスタム・プロパティーが存在しています。
- OS1 - PropertyA、PropertyB、PropertyC
- OS2 - PropertyB、PropertyC、PropertyD
- OS3 - PropertyA、PropertyB、PropertyC、PropertyD
MergeMode.UNION を指定した場合は、以下のプロパティーが戻されます。
- PropertyA (OS1 を表します)
- PropertyB (OS1、OS2、OS3 を表します)
- PropertyC (OS1、OS2、OS3 を表します)
- PropertyD (OS2、OS3 を表します)
MergeMode.INTERSECTION を指定した場合は、以下のプロパティーが返されます。
- PropertyB
- PropertyC
PropertyA または PropertyD の選択を試みると、未定義のプロパティー例外が生成されます。
クラスは名前と GUID が同一であっても、プロパティーの GUID が異なっていて別名割り当ても行われていない場合、上の例の MergeMode.UNION は以下のプロパティーを持つことになります。
- PropertyA (OS1 を表します)
- PropertyB (OS1 を表します)
- PropertyB (OS2 を表します)
- PropertyB (OS3 を表します)
- PropertyC (OS1 を表します)
- PropertyC (OS2 を表します)
- PropertyC (OS3 を表します)
- PropertyD (OS2 を表します)
- PropertyD (OS3 を表します)
選択ステートメント「SELECT * FROM Alpha」を実行した場合は、その結果として、行を含むオブジェクト・ストアごとに、10 個の列を持つ行が得られます。返される行の各列が非 NULL になるのは、リスト内の先行するオブジェクト・ストアから行が提供される場合に限られます。
選択ステートメントが SELECT PropertyA、PropertyB、PropertyC、PropertyD FROM Alpha の場合、PropertyA は OS1 からのみ提供され、他のすべてのオブジェクト・ストアからの行では NULL になります。同様に、PropertyB は OS1 からのみ提供され、PropertyC は OS1 から、PropertyD は OS2 から提供されます。プロパティー名に基づいて OS3 から PropertyB だけを選択することはできないため、この構成は役立ちません。このことから、プロパティーに別名 ID を設定しなければならない理由 (あるいは、ID を一致させるためにオブジェクト・ストアでエクスポート/インポートしなければならない理由) がわかります。つまり、そうしなければ照会結果が無意味になる場合があるということです。
返されるオブジェクト
複数のオブジェクト・ストアにまたがる照会の場合、同じ GUID を持つプロパティーが各オブジェクト・ストア内で同じ名前を持たないときは、どのタイプのオブジェクトが返されるかによって、プロパティー名に影響が及びます。例えば、RepositoryRow オブジェクトが返されるなら、プロパティーはそのオブジェクトが定義されている最初のオブジェクト・ストアから名前を取得するので、この名前はリスト内のそれ以降のすべてのオブジェクト・ストアの行で同じになります。IndependentObject オブジェクトが返されると、プロパティーはそのプロパティーが定義されている各オブジェクト・ストアに従って命名されます。
RepositoryRow オブジェクトは、特に以下の点で IndependentObject オブジェクトと異なります。
- RepositoryRow オブジェクトは、更新では使用できません。
- 照会で結合を使用した場合、RepositoryRow オブジェクトは、複数の IndependentObject オブジェクトからのデータを持つことができます。
- RepositoryRow オブジェクトは、重複するプロパティーを持つことができます。
一例として、2 つのオブジェクト・ストアを含むリストに対してステートメント SELECT apple FROM someclass を実行するとします。ここで、最初のオブジェクト・ストアのプロパティー「apple」は、2 番目のオブジェクト・ストアのプロパティー「orange」に (GUID が) 一致します。RepositoryRow オブジェクトを返す照会は、どのオブジェクト・ストアから返されるかに関係なく、常にプロパティー「apple」を返します。しかし、IndependentObject オブジェクトを返す照会は、最初のオブジェクト・ストアからのデータについてはプロパティー名「apple」を返し、2 番目のオブジェクト・ストアから返されるデータについてはプロパティー名「orange」を返します。これに該当しない場合、2 番目のオブジェクト・ストアから返される IndependentObject オブジェクトを使用して更新を試みると、「プロパティー apple が定義されていません」というエラーが生成されます。
RepositoryRow オブジェクトが戻された場合は、プロパティー名を名前変更できます。例えば、SearchScope.fetchRows を呼び出した後、検索結果に対して SELECT Owner AS Bob FROM Document を実行します。検索結果は、各 RepositoryRow オブジェクトが「Bob」という名前のプロパティーを持ちます。AS 節を使用して IndependentObject オブジェクトを返すことはできませんが、それらのオブジェクトをそれ以後の更新で使用することは可能です。
コンテンツ検索
コンテンツ (全文) 検索では、オブジェクトのコンテンツに含まれている可能性のある照会語句、またはそれらのオブジェクトの文字列値プロパティーに含まれている可能性のある照会語句を指定します。オブジェクト内のコンテンツ、またはオブジェクトの文字列値プロパティーを検索するには、コンテンツ検索で指定するオブジェクト (およびオプションでその文字列値プロパティー) のために、コンテンツ・ベース検索 (CBR) を有効にする必要があります。CBR の有効化は、以下のオブジェクトの IsCBREnabled プロパティーのブール値によって制御されます。
- ClassDefinition
IsCBREnabled プロパティーを使用すると、クラスのコンテンツ (存在する場合) の全文検索が有効になり、全文検索用に文字列値プロパティーを有効にすることができます。
- PropertyDefinitionString
IsCBREnabled プロパティーを使用すると、コンテンツ検索に文字列値プロパティーを指定できます。
IsCBREnabled プロパティーは、Document、Annotation、CustomObject、および Folder の各オブジェクトに対してのみ有効にできます。
コンテンツ検索は、SearchSQL に含まれる SQL ステートメントの CONTAINS 演算子によって開始されます。CONTAINS 関数では、すべてのプロパティーまたは単一のプロパティー内のコンテンツを検索できます。
CONTAINS 関数の詳細については、CBR 照会を参照してください。全文情報の管理インターフェースについては、コンテンツ・ベース・リトリーブを参照してください。
保管済み検索
StoredSearch オブジェクトには 2 種類あり、保管済み検索または検索テンプレートのいずれかになります。どちらのタイプもオブジェクト・ストアで永続化され、検索を複数回実行することを目的としています。
StoredSearch オブジェクトのコンテンツは、XML 文字列形式の検索基準となります。これは Document オブジェクトからサブクラス化されるため、StoredSearch オブジェクトをインスタンス化する際には、Document オブジェクトと同じように操作することができます (保管済み検索のチェックアウト、コンテンツ設定、再チェックイン、フォルダーへのファイリング、削除など)。
StoredSearch オブジェクトは、XML 内の searchtype エレメントの値により、保管済み検索または検索テンプレートとして識別されます。StoredSearch オブジェクトにより、ドキュメント、フォルダー、またはカスタム・オブジェクトを照会できます。照会のオブジェクト・タイプは、XML objecttype 属性によって識別されます。
XML で指定できるオブジェクト・タイプ (ドキュメント、フォルダー、またはカスタム・オブジェクト) は、1 つの検索節につき 1 つのみです。各検索節は個々の照会として処理する必要があり、各検索節を実行するには個別の SearchScope 呼び出しが必要です。
保管済み検索および検索テンプレートを作成するには、Workplace XT の Search Designer を使用して、XML をオブジェクト・ストア内の StoredSearch オブジェクトに保存します。すべての保管済み検索は、保管済み検索スキーマに従う必要があります。保管済み検索を実行するには SearchScope メソッド fetchObjects および fetchRows を、それぞれの署名に StoredSearch を含めて使用します。
SearchTemplate* クラス (接頭部が「SearchTemplate」のクラス) を使用すると、StoredSearch オブジェクトで永続化されている保管済み検索または検索テンプレートの XML を実行時に変更することができます。 XML の変更は、SearchTemplateParameters インスタンス内の SearchScope 呼び出しに渡されます。
詳細については、保管済み検索を使用したオブジェクトの検索を参照してください。
保管済み検索のタイプ
保管済み検索は、1 つ以上のオブジェクト・ストアからドキュメント、フォルダー、またはカスタム・オブジェクト (またはこれらのクラスのサブクラス) を検索するための照会を事前定義したものです。検索節ごとに 1 つのオブジェクト・タイプのみを指定できます。
検索テンプレートのタイプ
検索テンプレートでは、定義する照会に対して、一部またはすべての検索基準と値を指定することができます。このテンプレートの設計では、検索を実行する前に、ユーザーは書き込み可能なプロパティーの値を変更できます。検索テンプレートによって、各フィールドの処理方法 (ユーザーが値を割り当てる必要のあるフィールド、自動的に事前割り当てされるフィールド、変更可能なフィールド、読み取り専用フィールドなど) が特定されます。
検索テンプレートでは、実行時にドキュメント、フォルダー、またはカスタム・オブジェクトを置き換えることができます。このためユーザーは、検索テンプレートの XML で指定されたものとは異なるドキュメント、フォルダー、またはカスタム・オブジェクトを選択することができます。指定されたオブジェクトは、該当する XML エレメントの itemid 属性に基づいて、個別に変更または置換されます。
バックグラウンド検索
- バックグラウンド検索を開始し、検索の実行中に他のアクティビティーを進めることができます。
- バックグラウンド検索機能が提供するレポート・フレームワークを使用して、検索結果を処理できます。
バックグラウンド検索は、CmBackgroundSearch と CmAbstractSearchResult の 2 つのインターフェースに基づいたクラスを使用します。CmBackgroundSearch インターフェースは、バックグラウンド検索を定義するサブクラスを定義するために使用される基本インターフェースです。CmAbstractSearchResult インターフェースは、バックグラウンド検索の結果として返される結果オブジェクトを定義するサブクラスを定義するために使用される基本インターフェースです。
- 検索対象のオブジェクトを識別し、結果セット・オブジェクトを生成するために使用するフィルタリングを決定します。この情報を使用して、バックグラウンド検索 SQL 式内の FROM 節および WHERE 節を作成します。
- ユーザーが検索式内に含めることを許可するバックグラウンド検索式パラメーターを決定し、それらのパラメーターを検索式に追加します。
- CmAbstractSearchResult サブクラス定義を作成します。
- バックグラウンド検索結果の中で検査対象にするプロパティー値を決定し、取得する各プロパティー値のプロパティー・テンプレートを定義します。
- 新しいプロパティー・テンプレートを使用して、CmAbstractSearchResult サブクラス定義にカスタム・プロパティーを追加します。 これらのカスタム・プロパティーは、一連の検索結果オブジェクトに返されたプロパティー値の突き合わせを行います。
- DITARenditionEngineConnection サブクラス定義を作成します。
- CmBackgroundSearch サブクラス定義の SearchExpression プロパティー定義のデフォルト値を、完成した SQL 検索式に設定します。
- SearchResults プロパティー定義の必須クラスを、前に定義した CmAbstractSearchResult サブクラスに設定します。
- 検索式内に含まれる各パラメーターのプロパティー・テンプレートを定義します。
- 新しいプロパティー・テンプレートを使用して、CmBackgroundSearch サブクラス定義にカスタム・プロパティー定義を追加します。
- 検索を表す CmBackgroundSearch サブクラスのインスタンスを作成します。
- 作成した CmBackgroundSearch オブジェクトのそれぞれのパラメーター定義カスタム・プロパティーに値を指定します。
- DITARenditionEngineConnection オブジェクトを保存します。その後、サーバーがバックグラウンド検索を自動的に開始します。
- サーバーは、バックグラウンド検索内で返される各オブジェクトに対して定義した CmAbstractSearchResult サブクラスをインスタンス化し、CmAbstractSearchResultSet オブジェクト・コレクション内に結果を保管します。このコレクションは、CmBackgroundSearch オブジェクトの SearchResults プロパティーを読み取ることによって取得できます。CmAbstractSearchResult サブクラス内で定義されたカスタム・プロパティーは、各 CmAbstractSearchResult オブジェクトの Properties コレクション内に含まれます。
- サーバーは、各 CmAbstractSearchResult オブジェクトの Properties コレクション内のカスタム・プロパティーに、バックグラウンド検索照会内で (シンボル名による突き合わせまたは AS 節によるマッピングを通じて) 選択されたカスタム・プロパティーの値を設定します。
Content Platform Engine 管理コンソールを使用することで、任意のスイープ・ジョブをモニターするのと同様に、バックグラウンド検索をモニターできます。バックグラウンド処理が進むにつれて、バックグラウンド検索結果が徐々に増えるため、CmBackgroundSearch オブジェクトの SearchResults プロパティーの列挙を調べるか、CmAbstractSearchResult オブジェクトを照会することで、処理中の結果をいつでも表示できます。 CmBackgroundSearch オブジェクトの ACL を設定することで、検索結果を表示できるかどうかを制限できます。
バックグラウンド検索式パラメーター
バックグラウンド検索パラメーターは、特定のバックグラウンド検索を定義する CmBackgroundSearch サブクラスに追加されたカスタム・プロパティーによって定義されます。サブクラスに追加されたすべてのカスタム・プロパティーをパラメーターとして使用する必要はないことに注意してください。それらは、他の目的のためにも定義できます。
- パラメーターを定義するカスタム・プロパティーを作成し、それを保存します。値が必須で、作成時にのみ設定可能なプロパティーとして、カスタム・プロパティーを指定します。カスタム・プロパティーは、任意のプロパティー・タイプ (ただし、バイナリーは除く) および任意のカーディナリティー (ただし、オブジェクトの列挙は除く) にすることができます。パラメーターの名前は、カスタム・プロパティーに割り当てられたシンボル名として定義されます。
- 必須ではありませんが、カスタム・プロパティーには、表示名と、パラメーターの使用方法を示す説明テキストを割り当てることをお勧めします。
- バックグラウンド検索を定義する CmBackgroundSearch サブクラスにカスタム・プロパティーを追加します。
- リスト: 小括弧で囲まれた個別のエレメント値から成るテキスト形式のコンマ区切りリスト。例: (1,2,3,4)。
- Singleton ブール: True または False。
- 整数: 値の自然な toString() 表現。
- 浮動小数点: 値の自然な toString() 表現。
- ID: 値の自然な toString() 表現。
- 日時: SQL 構文によって要求される yyyy-mm-ddThh:mm:ssZ 形式の値の W3C 表現。
- 文字列: 単一引用符で囲まれた文字列値。
- オブジェクト: OBJECT({参照されているオブジェクトの ID}) 形式のオブジェクト・リテラル。
カスタム検索関数
カスタム検索関数は、オブジェクト・ストアに作成し、SQL ステートメントの SELECT リストでアドホック検索とバックグラウンド検索の両方に使用できる関数です。それぞれのカスタム検索関数は、1 つ以上の入力パラメーターを受け取り、戻り値を出力します。入力パラメーターのデータ型は任意の型にすることができます。ただし、戻り値はコレクション・オブジェクト型 (リストまたは列挙のカーディナリティー) にすることはできません。
- カスタム検索関数は、fetchRows メソッドとともにのみ使用することができ、fetchObjects メソッドとともには使用できません。
カスタム検索関数は、選択リスト内でアドホック検索またはバックグラウンド検索にのみ使用できます。保管済み検索で使用することはできません。
コンテンツ・ベース・リトリーブ (CBR) 検索とデータベースに対するリレーショナル検索の両方を組み合わせた検索の場合、最初にデータベースを検索する検索では、コンテンツ検索関数を使用することができません。検索結果は「無効なノード・タイプ」エラーになります。詳細については、CBR 照会の最適化を参照してください。
カスタム検索関数をオブジェクト・ストアに追加するには、CmSearchFunctionDefinition インターフェースのインスタンスを作成します。CmSearchFunctionDefinition インターフェースは Action インターフェースのサブインターフェースであり、実行するアクションに実装するハンドラー・サブインターフェースを提供し、JavaScript コンポーネントまたは Java™ コンポーネントとしてコーディングします。CmSearchFunctionDefinition オブジェクトは、実装されたハンドラーを ProgId プロパティーを使用して識別します。JavaScript で実装されたハンドラーは ScriptText プロパティーで設定します。Java で実装されたハンドラー (JAR または class ファイル) を CodeModule オブジェクトとして Content Engine オブジェクト・ストアにチェックインすることができますが、そのためには CodeModule プロパティーが設定されている必要があります。あるいは、Java コンポーネントのロケーションをアプリケーション・サーバーのクラスパスに設定できます。Action クラスをベースにしたオブジェクトに存在するプロパティーの他に、CmSearchFunctionDefinition オブジェクトにも CmFunctionName プロパティーが含まれています。このプロパティーはサーバーによってデータが設定され、SQL 式に表示される際のカスタム検索関数の名前を指定します。検索関数名の形式は、<namespace>::<name> である必要があります。 この場合、<namespace> と <name> は両方とも、 Content Engine シンボル名規則を順守します。検索関数名は、他の検索関数名に対して一意である必要があります。カスタム検索関数によって指定されたコードは、SearchFunctionHandler インターフェースのメソッドを実装する必要があります。
SQL ステートメントでカスタム検索関数を使用するには、カスタム検索関数照会構文を参照してください。