エンタープライズ検索プロトコル ハンドラ

プロトコル ハンドラは、Microsoft Office SharePoint Server 2007 でのエンタープライズ検索 が新しいコンテンツ ソースを使用できるようにすることで、検索機能を拡張します。このトピックでは、プロトコル ハンドラの概要、プロトコル ハンドラを エンタープライズ検索 アーキテクチャに適合させる方法、およびプロトコル ハンドラ インターフェイスを使用してプロトコル ハンドラによるカスタム コンテンツ ソースのクロールを実装する方法について説明します。

エンタープライズ検索インデックス システムの概要

エンタープライズ検索 インデックス システムは、次に説明する複数のコンポーネントで構成されます。

  • インデックス エンジン : 検索サービス用に構成されたコンテンツ ソースとクロール ルールを使用するコンテンツ クロール プロセスを管理します。インデックス エンジンは、クロール URL キューを管理し、コンテンツ クロール プロセス中にクロール URL をフィルタ デーモンに渡します。クロール URL キューには、コンテンツ ソースの開始アドレスが初期入力されます。

  • コンテンツ ソース : クロールするコンテンツを指定します。

  • クロール ルール : クロールから除外するコンテンツやクロールで使用する証明書を指定します。

  • フィルタ デーモン : インデックス エンジンから渡されたクロール URL 要求を、使用する適切なプロトコル ハンドラを決定することによって処理します。フィルタ デーモンは、プロトコル ハンドラを使用してコンテンツをフェッチし、テキストとプロパティの抽出と解析を行い、必要に応じて適切な IFilter を呼び出します。

  • プロトコル ハンドラ : コンテンツ ソースをネイティブ プロトコルで開き、フィルタリングされるドキュメントとその他のアイテムを公開します。

  • IFilter : ドキュメントとその他のコンテンツ ソース アイテムをネイティブ形式で開き、それらをフィルタリングして、テキストとプロパティのチャンクを抽出します。IFilter の実装は、プロトコル ハンドラ コンポーネントの一部にすることも、別個のコンポーネントにすることもできます。

プロトコル ハンドラの概要

プロトコル ハンドラは、ISearchProtocol インターフェイスを実装するスレッド フリーな COM オブジェクトです。

プロトコルハンドラは、インデックス サーバーに HKLM\Software\Microsoft\OfficeServer\12.0\Search\Setup\ProtocolHandlers で登録されます。

URL スキーム

プロトコル ハンドラの URL スキーマの書式は、scheme://hostname/path.extension です。

URL スキーマは、特定のクロール URL で使用するプロトコル ハンドラを決定するためにフィルタ デーモンによって使用されます。詳細については、「クロール プロセス」を参照してください。

プロトコル ハンドラの種類

エンタープライズ検索 は、次の 2 種類のプロトコル ハンドラをサポートします。

  • 階層型 : ファイル共有のような、スキャンする必要があるディレクトリやフォルダなどの構造を含む、構造化されたコンテンツ ソースに対して動作します。

  • リンク ベース : Web サイトのような、コンテンツ内のリンクによってソースのスキャン方法が指示されるコンテンツ ソースに対して動作します。

プロトコル ハンドラの初期化

フィルタデーモンは、登録されたすべてのプロトコル ハンドラを、プロトコル ハンドラの ISearchProtocol 実装に対する Init メソッドの呼び出しによって初期化します。フィルタ デーモンは、ISearchProtocol メソッドを使用して、インデックス エンジンから渡されたクロール URL を処理します。次のセクションで、このプロセスについて説明します。

クロール プロセス

インデックス エンジンは、コンテンツ ソースのクロールを初期化します。次の 2 種類のクロールがあります。:

  • フル クロール : すべてのコンテンツのクロール。クロール URL キューに、クロールの対象となるコンテンツ ソースの開始アドレスが供給されます。重複するエントリは、キューから削除されます。クロールが進行すると、フィルタリング処理中に見つかったクロール URL が、インデックス エンジンによってキューに追加されます。削除されたアイテムは、コンテンツ インデックスから削除されます。クロール プロセスは、クロール キューが空になるまで続行されます。

  • 増分クロール : 変更されたコンテンツのみのクロール。クロール URL キューに、開始アドレス URL と、そのコンテンツ ソースのクロール履歴内の URL が供給されます。インテックス エンジンは、フィルタ デーモンに、タイムスタンプとクロール URL を渡します。SharePoint コンテンツの場合、インデックスエンジンは、Windows SharePoint Services 3.0 の変更ログ機能に依存するので、変更ログに記録されたコンテンツだけがクロールされます。

プロトコル ハンドラの選択

フィルタ デーモンは、インデックス エンジンから渡された各クロール URL 用の適切なプロトコル ハンドラを、クロール URL と URL スキーマに基づいて決定します。たとえば、クロール URL https://www.microsoft.com/ の場合、フィルタ デーモンは、既定の HTTP プロトコルハンドラを選択します。このハンドラは、リンクベースのプロトコル ハンドラです。

クロール URL \\CentralSales\Public\ の場合、フィルタ デーモンは、既定のファイル プロトコル ハンドラを選択します。このハンドラは、階層型プロトコル ハンドラです。

URL アクセサを返す

ISearchProtocol インターフェイスの CreateAccessor メソッドが、各クロール URL に対して別個に呼び出されます。

注意

CreateAccessor メソッドの 1 回の呼び出しで 1 つのクロール URL だけが処理されますが、このメソッドに対する複数の呼び出しは同時に存在できます。この結果、複数のスレッドが並行して動作できます。

CreateAccessor メソッドは、フィルタ デーモンがクロール URL を処理するために使用する URLAccessor オブジェクトを返します。URLAccessor オブジェクトは、IUrlAccessor インターフェイスの中に実装されます。

コンテンツのフィルタリング

IUrlAccessor インターフェイスは、BindToFilter メソッドと BindToStream メソッドを含みます。これらのメソッドの少なくともどちらかを、各クロール URL に対して実装する必要があります。

BindToFilter

クロール URL が、標準フィルタのいずれかによって解析されるバイナリ ストリームに関連付けられていない場合は、BindToFilter メソッドを実装する必要があります。この場合は、IFilter も、URLAccessor オブジェクトの一部として実装する必要があります。

BindToFilter メソッドを実装して、コンテンツ アイテムに関連付けられたメタデータを抽出することもできます。プロトコル ハンドラは、プロパティとリンクを含むデータのチャンクを、インデックス エンジンに送信します。

クロール URL がフォルダまたはディレクトリの場合は、プロトコル ハンドラ用の BindToFilter メソッドを実装して、フォルダまたはディレクトリのコンテンツを列挙する必要があります。その後、プロトコル ハンドラは、各アイテムに対して PID_GTHR_DIRLINK_WITH_TIME プロパティを発行する必要があります。このプロパティには、アイテムの URL とタイムスタンプが格納されます。増分クロールの実行中、インデックス エンジンは、特定のアイテムの PID_GTHR_DIRLINK_WITH_TIME を受け取った後、タイムスタンプを、そのアイテムのクロール履歴に保存された値と突き合わせます。タイムスタンプが変更されていない場合、アイテムはクロールされません。ディレクトリに変更がない、または、単一のアイテムがクローラーによって渡されたタイムスタンプを変更しなかった場合、プロトコル ハンドラは、そのコンテンツ アイテムに対して PRTH_S_NOT_MODIFIED を返す必要があり、その項目のそれ以上の処理は不要になります。PRTH_S_NOT_MODIFIED の詳細については、「プロトコル ハンドラのエラー メッセージ」 を参照してください。

増分クロールでは、プロトコル ハンドラは各アイテムに個別にバインドする必要はなく、変更されたアイテムだけにバインドすればよいので、クロールは、より効率的に実行されます。

注意

プロトコル ハンドラの BindToFilter メソッドが PID_GTHR_DIRLINK_WITH_TIME の発行を実装せず、CreateAccessor メソッドが PRTH_S_NOT_MODIFIED を返すことをサポートしない場合、増分クロールは、実質的にはフル クロールと同じことを実行します。

BindToStream

テキスト、HTML、Microsoft Office フィルタなどの標準フィルタのいずれかによって解析する必要があるクロール URL に関連付けられたバイナリ ストリームがある場合は、BindToStream メソッドを実装します。BindToStream メソッドは、適切なフィルタを呼び出して、アイテムのコンテンツを抽出します。

フィルタの作成の詳細については、「How to Write a Filter for Use by SharePoint Portal Server 2003 and Other Microsoft Search-Based Products」 を参照してください。

フィルタ デーモンは、各クロール URL に対して、BindToFilter メソッドと BindToStream メソッドの両方を 1 度だけ呼び出します。クロール URL に関連付けられたコンテンツ アイテムをフィルタリングするには、どちらかのメソッドが成功する必要があります。

セキュリティ

GetSecurityDescriptor メソッドは、コンテンツ アイテムに関連付けられたセキュリティ情報 (特定のユーザーとユーザー グループに許可されたさまざまな種類のアクセス権など) を取得します。このメソッドが実装された場合、フィルタ デーモンは、コンテンツ アイテムに関するセキュリティ情報をインデックス エンジンに提供します。インデックス エンジンは、この情報を、ドキュメント コンテンツのフル テキストインデックスに組み込みます。

クエリ エンジンは、フルテキスト インデックスに対してクエリを実行するときに、検索クエリを送信したユーザーが検索結果に含まれるアイテムにアクセスできるかどうかを、セキュリティ情報を使用して決定します。この決定に基づいて、クエリ エンジンは、検索結果のセキュリティ トリミングを実行し、ユーザーがアクセスできるアイテムだけが検索結果の中に表示されるようにします。したがって、GetSecurityDescriptor メソッドを実装しない場合は、すべてのユーザーが、検索クエリ結果に含まれるアイテムのコンテンツを取得して表示できます。セキュリティ トリミングの詳細については、「エンタープライズ検索セキュリティ モデル」を参照してください。

このセクションの内容

プロトコル ハンドラの参照情報

See Also

参照

SharePoint Portal Server 2003 および Microsoft Search ベースのその他の製品が使用するフィルタを作成する方法

概念

エンタープライズ検索のアーキテクチャ

コンテンツ ソースの概要