次の方法で共有

変更のインデックスへの通知 (Windows Search)

  • [アーティクル]

通知 API コンポーネントを使用すると、アイテムが変更、移動、または削除されたことをインデクサーに通知し、インデックス作成を必要とする Windows Search インデクサーの URL キューに検索スコープを追加できます。

コンポーネントは、ストア内のデータが変更されたことを Windows Search インデクサーに通知できます。 通常は、インデクサーのスケジュールされたクロールに依存できます。 ただし、インデクサーに通知を提供すると、インデクサーが増分インデックスのストア全体をクロールしないようにすることで、パフォーマンスを向上させることができます。 たとえば、たとえば電子メール データ ストアなど、データ ストアが非常に大きい場合や、非常にビジー状態であると予想される場合に、これをお勧めします。

インデクサーで管理される通知の実装

インデクサーによって管理される通知を使用すると、データ ストアへのアクセスを制御しながら、インデックス作成プロセス全体を通じて通知キューを維持できます。 通知プロバイダーは、データ ストアへの変更を監視し、通知キューを作成する必要があります。 プロバイダーは定期的に、変更通知のバッチをインデクサーに送信します。 インデクサーが通知を受信すると、受信確認が返され、キューから項目を削除できます。 一定時間が経過しても受信確認を受け取らない場合は、通知を再送信できます。 エラーが発生した場合、インデクサーはアイテムの内部キューを再構築してクロールするか、ストアの増分クロールを実行します。

インデクサーで管理される通知を実装するには、次を実装する必要があります。

  • データ ストア内の変更を監視するためのメカニズム。
  • これらの変更に関する情報 (複数 のSEARCH_ITEM_PERSISTENT_CHANGE 構造体) をキューに格納するデータ構造。
  • ISearchPersistentItemsChangedSink インターフェイスを使用すると、インデクサーに通知を送信し、インデクサーから通知確認を取得できます。

通知キュー

インデクサーに通知として送信するには、データ ストア内のすべての変更を監視してキューに登録する必要があります。 キューに登録する通知の数とインデクサーに送信する頻度は、状況によって異なります。 おそらく、 n 個の変更ごとに通知のバッチを送信するか 、t 時間間隔 の後に、または 2 つの組み合わせを送信します。

インデクサーは、通知が SEARCH_ITEM_PERSISTENT_CHANGE 構造体の配列に含まれると想定しているため、同様にキューを実装することもできます。

ISearchPersistentItemsChangedSink

このインターフェイスにアクセスするには、まず ISearchManager オブジェクトをインスタンス化して 、ISearchCatalogManager オブジェクトにアクセスします。 その ISearchCatalogManager オブジェクトから、 ISearchPersistentItemsChangedSink オブジェクトをインスタンス化し、 OnItemsChanged メソッドを呼び出してインデクサーにデータ変更を通知します。

このメソッドの呼び出しには、報告される変更の数と 、SEARCH_ITEM_PERSISTENT_CHANGE 構造体の配列を含めます。 インデックス作成のために各 URL が受け入れられたかどうかを示す HR 入力候補コードの配列が返されます。 これは、インデクサーからの受信確認です。

プロバイダーマネージド通知の実装

プロバイダー管理の通知を使用すると、データ ストアへのアクセスを制御したり、Windows Search カタログを更新するときのインデクサーの進行状況を監視したりできます。 プロバイダーは、データ ストアへの変更を監視し、通知キューを作成する必要があります。 プロバイダーは定期的に、変更通知のバッチをインデクサーに送信します。 インデクサーは通知を受信すると、確認応答を返します。 一定時間が経過しても受信確認を受け取らない場合は、通知を再送信できます。 インデクサーは、データ ストアをクロールして Windows Search カタログを更新すると、各カタログ更新プログラムをプロバイダーに通知し、キューからアイテムを削除できます。 プロバイダーはこのプロセス全体で通知キューを維持するため、障害が発生した場合はインデクサーに通知を再送信できます。

プロバイダーマネージド通知を実装するには、次を実装する必要があります。

  • データ ストア内の変更を監視するためのメカニズム。
  • これらの変更に関する情報 (複数 のSEARCH_ITEM_CHANGE 構造体) をキューに格納するデータ構造。
  • ISearchItemsChangedSink インターフェイスを使用すると、インデクサーに通知を送信し、インデクサーから通知確認を取得できます。
  • インデックス作成の状態に関する更新プログラムを受け取る ISearchNotifyInlineSite インターフェイス。

通知キュー

インデクサーに通知として送信するには、データ ストア内のすべての変更を監視してキューに登録する必要があります。 キューに登録する通知の数とインデクサーに送信する頻度は、状況によって異なります。 おそらく、 n 個の変更ごとに通知のバッチを送信するか 、t 時間間隔 の後に、または 2 つの組み合わせを送信します。

インデクサーは、通知が SEARCH_ITEM_CHANGE 構造体の配列に含まれると想定しているため、同様に変更情報を格納することもできます。 ただし、送信する通知と、インデクサーから返された受信確認と更新を照合できる必要もあります。 また、受信確認を受け取るのにかかる時間を検出して、通知を再送信するかどうかを決定することもできます。

ISearchItemsChangedSink

このインターフェイスにアクセスするには、まず ISearchManager オブジェクトをインスタンス化して 、ISearchCatalogManager オブジェクトにアクセスします。 その ISearchCatalogManager オブジェクトから 、ISearchItemsChangedSink オブジェクトをインスタンス化し、 OnItemsChanged メソッドを呼び出してインデクサーにデータ変更を通知します。

このメソッドの呼び出しには、報告される変更の数と 、SEARCH_ITEM_CHANGE 構造体の配列を含めます。 各変更を表すインデクサー割り当て DocId の配列と、各 URL がインデックス作成に受け入れられたかどうかを示す HR 完了コードの配列が返されます。 これは、インデクサーが通知を受信し、アイテムのインデックスを作成する準備をしていることを確認します。

その時点から、インデクサーは ISearchNotifyInlineSite インターフェイスを使用して更新プログラムを送信します。

ISearchNotifyInlineSite

アイテムとカタログの両方の状態に関する更新を取得するには、 ISearchNotifyInlineSite インターフェイスをインデクサーに登録して、コールバックを送信できるようにする必要があります。 ISearchNotifyInlineSite::OnItemIndexedStatusChange を使用して送信される各更新プログラムは、アイテムを DocId、各項目の状態 (SEARCH_ITEM_INDEXING_STATUS)、およびアイテムのインデックス作成フェーズ (SEARCH_INDEXING_PHASE) によって識別します。

前述のように、各項目の状態に関する更新を受け取るだけでなく、カタログ自体の状態に関する重要な情報も取得します。 Windows Search Serviceは、エンド ユーザー、サード パーティ製アプリケーション、またはその他の障害によって中断または再起動される可能性があります。 このような場合は、インデクサーに対してどの通知を再評価するかを判断する方法が必要です。

Windows Search Serviceによって呼び出される ISearchNotifyInlineSite::OnCatalogStatusChange メソッドは、次の表に示すパラメーターを使用して、カタログの状態をクライアントに通知します。

パラメーター 説明
guidCatalogResetSignature カタログのリセットを表す GUID。 この GUID が変更された場合は、すべての通知を再送信する必要があります。
guidCheckPointSignature 復元された最後のチェックポイントを表す GUID。 この GUID が変更された場合は、最後に保存されたチェックポイント以降に累積されたすべての通知を再送信する必要があります。
dwLastCheckPointNumber 最後に保存されたチェックポイントを示す数値。

 

 

カタログ チェックポイントが発生すると、検索サービスは dwLastCheckPointNumber を更新し、そのチェックポイントの前に送信されたすべての通知は、サービス障害が発生した場合に安全かつ回復可能になります。 通知プロバイダーは、カタログの復元またはリセットの場合に、チェックポイントと repush の間で送信された通知のみを追跡する必要があります。

カタログの復元が発生した場合、検索サービスはカタログを最後に保存したチェックポイントにロールバックし、 guidCheckPointSignature を更新します。 この状況では、通知プロバイダーは、 dwLastCheckPointNumber で識別された最新の保存済みチェックポイント以降に蓄積されたすべての通知を取り消す必要があります。

カタログのリセットが発生した場合、検索サービスはカタログ全体をリセットし、 guidCatalogResetSignature を更新します。 通知プロバイダーは、クロール スコープ全体をもう一度取り戻す必要があります。

その他のリソース

概念

プロトコル ハンドラーの開発

プロトコル ハンドラーについて

アイコンとコンテキスト メニューの追加

コード サンプル: プロトコル ハンドラーのシェル拡張機能

プロトコル ハンドラーのインストールと登録

プロトコル ハンドラーの検索コネクタの作成

プロトコル ハンドラーのデバッグ