Share via

Notification de l’index des modifications (Recherche Windows)

  • Article

À l’aide des API de notification, les composants peuvent informer l’indexeur qu’un élément a été modifié, déplacé ou supprimé, et peuvent ajouter des étendues de recherche à la file d’attente d’URL de l’indexeur Recherche Windows qui nécessite une indexation.

Les composants peuvent informer l’indexeur Recherche Windows que les données de leur magasin ont été modifiées. En règle générale, vous pouvez vous appuyer sur les analyses planifiées de l’indexeur. Toutefois, la fourniture de notifications à l’indexeur peut améliorer les performances en s’assurant que l’indexeur n’analyse pas l’ensemble du magasin sur des index incrémentiels. Par exemple, cela peut être recommandé si vous vous attendez à ce que votre magasin de données soit exceptionnellement volumineux et/ou particulièrement occupé, comme un magasin de données de messagerie par exemple.

Implémentation de notifications gérées par l’indexeur

Les notifications gérées par l’indexeur vous permettent de contrôler l’accès à votre magasin de données tout en vous libérant de la gestion de la file d’attente des notifications tout au long du processus d’indexation. Votre fournisseur de notifications doit surveiller les modifications apportées au magasin de données et créer une file d’attente de notifications. Régulièrement, votre fournisseur envoie un lot de notifications de modification à l’indexeur. Lorsque l’indexeur reçoit vos notifications, il retourne un accusé de réception et vous pouvez supprimer le ou les éléments de votre file d’attente. Si, après un certain temps, vous ne recevez pas d’accusé de réception, vous pouvez renvoyer les notifications. En cas de défaillance, l’indexeur reconstruit sa file d’attente interne d’éléments à analyser ou effectue une analyse incrémentielle du magasin.

Pour implémenter les notifications gérées par l’indexeur, vous devez implémenter les éléments suivants :

File d’attente des notifications

Vous devez surveiller et mettre en file d’attente chaque modification de votre magasin de données à envoyer à l’indexeur sous forme de notification. Le nombre de notifications mises en file d’attente et la fréquence à laquelle vous les envoyez à l’indexeur dépendent de votre situation. Vous envoyez peut-être un lot de notifications pour chaque n nombre de modifications ou après un intervalle de temps t , ou une combinaison des deux.

L’indexeur s’attend à ce que les notifications arrivent dans un tableau de structures SEARCH_ITEM_PERSISTENT_CHANGE . Vous pouvez donc choisir d’implémenter votre file d’attente de la même façon.

ISearchPersistentItemsChangedSink

Pour accéder à cette interface, vous devez d’abord instancier un objet ISearchManager pour accéder à un objet ISearchCatalogManager . À partir de cet objet ISearchCatalogManager , vous instanciez un objet ISearchPersistentItemsChangedSink et informez l’indexeur des modifications de données avec un appel à la méthode OnItemsChanged .

Dans l’appel à cette méthode, vous incluez le nombre de modifications signalées et un tableau de structures SEARCH_ITEM_PERSISTENT_CHANGE . Vous obtenez un tableau de codes d’achèvement RH indiquant si chaque URL a été acceptée pour l’indexation. Il s’agit de votre accusé de réception de l’indexeur.

Implémentation de notifications gérées par le fournisseur

Les notifications gérées par le fournisseur vous permettent de contrôler l’accès à votre magasin de données et de surveiller la progression de l’indexeur à mesure qu’il met à jour le catalogue Recherche Windows. Votre fournisseur doit surveiller les modifications apportées au magasin de données et créer une file d’attente de notifications. Régulièrement, votre fournisseur envoie un lot de notifications de modification à l’indexeur. Lorsque l’indexeur reçoit vos notifications, il retourne un accusé de réception. Si, après un certain temps, vous ne recevez pas d’accusé de réception, vous pouvez renvoyer les notifications. Lorsque l’indexeur analyse le magasin de données et met à jour le catalogue Windows Search, il avertit votre fournisseur de chaque mise à jour du catalogue et vous pouvez supprimer le ou les éléments de votre file d’attente. Votre fournisseur conserve sa file d’attente de notifications tout au long de ce processus afin qu’en cas d’échec, vous puissiez renvoyer des notifications à l’indexeur.

Pour implémenter les notifications gérées par le fournisseur, vous devez implémenter les éléments suivants :

File d’attente des notifications

Vous devez surveiller et mettre en file d’attente chaque modification de votre magasin de données à envoyer à l’indexeur sous forme de notification. Le nombre de notifications mises en file d’attente et la fréquence à laquelle vous les envoyez à l’indexeur dépendent de votre situation. Vous envoyez peut-être un lot de notifications pour chaque n nombre de modifications ou après un intervalle de temps t , ou une combinaison des deux.

L’indexeur s’attend à ce que les notifications arrivent dans un tableau de structures SEARCH_ITEM_CHANGE . Vous pouvez donc choisir de stocker les informations de modification de la même façon. Toutefois, vous devez également être en mesure de faire correspondre les notifications que vous envoyez avec les accusés de réception et les mises à jour retournés par l’indexeur. Vous pouvez également être en mesure de détecter le temps nécessaire pour obtenir des accusés de réception, afin de décider si/quand renvoyer des notifications.

ISearchItemsChangedSink

Pour accéder à cette interface, vous devez d’abord instancier un objet ISearchManager pour accéder à un objet ISearchCatalogManager . À partir de cet objet ISearchCatalogManager , vous instanciez un objet ISearchItemsChangedSink et informez l’indexeur des modifications de données avec un appel à la méthode OnItemsChanged .

Dans l’appel à cette méthode, vous incluez le nombre de modifications signalées et un tableau de structures SEARCH_ITEM_CHANGE . Vous obtenez un tableau de DocIds attribués à l’indexeur qui représentent chaque modification, ainsi qu’un tableau de codes d’achèvement HR indiquant si chaque URL a été acceptée pour l’indexation. Il s’agit de votre accusé de réception par l’indexeur qu’il a reçu vos notifications et qu’il se prépare à indexer les éléments.

À partir de ce point, l’indexeur envoie les mises à jour à l’aide de l’interface ISearchNotifyInlineSite .

ISearchNotifyInlineSite

Pour obtenir des mises à jour sur la status de vos éléments et du catalogue, vous devez inscrire votre interface ISearchNotifyInlineSite auprès de l’indexeur afin qu’elle puisse vous envoyer des rappels. Chaque mise à jour envoyée à l’aide de ISearchNotifyInlineSite::OnItemIndexedStatusChange identifie les éléments par DocId, le status de chaque élément (SEARCH_ITEM_INDEXING_STATUS) et la phase d’indexation (SEARCH_INDEXING_PHASE) dans laquelle les éléments se trouvent.

Non seulement vous recevez des mises à jour sur la status de chaque élément, comme décrit précédemment, mais vous obtenez également des informations importantes sur la status du catalogue lui-même. L’service Search Windows peut être interrompu ou redémarré par l’utilisateur final, une application tierce ou toute autre défaillance. Dans ce cas, vous avez besoin d’un moyen de déterminer les notifications à envoyer à l’indexeur.

La méthode ISearchNotifyInlineSite::OnCatalogStatusChange, appelée par le service Search Windows, informe les clients de l’status du catalogue à l’aide des paramètres décrits dans le tableau suivant.

Paramètre Description
guidCatalogResetSignature GUID représentant la réinitialisation du catalogue. Si ce GUID change, toutes les notifications doivent être envoyées de nouveau.
guidCheckPointSignature GUID représentant le dernier point de contrôle restauré. Si ce GUID change, toutes les notifications accumulées depuis le dernier point de contrôle enregistré doivent être envoyées de nouveau.
dwLastCheckPointNumber Nombre indiquant le dernier point de contrôle enregistré.

 

 

Lorsqu’un point de contrôle de catalogue se produit, le service de recherche met à jour dwLastCheckPointNumber, et toutes les notifications envoyées avant ce point de contrôle sont sécurisées et récupérables en cas de défaillance du service. Les fournisseurs de notifications doivent suivre uniquement les notifications envoyées entre les points de contrôle et les repush en cas de restauration ou de réinitialisation du catalogue.

Si une restauration de catalogue se produit, le service de recherche restaure le catalogue au dernier point de contrôle enregistré et met à jour guidCheckPointSignature. Dans ce cas, les fournisseurs de notifications doivent effacer toutes les notifications accumulées depuis le point de contrôle enregistré le plus récent, tel qu’identifié par le dwLastCheckPointNumber.

Si une réinitialisation du catalogue doit se produire, le service de recherche réinitialise l’ensemble du catalogue et met à jour guidCatalogResetSignature. Le fournisseur de notifications doit ressusuter l’ensemble de son étendue d’analyse.

Ressources supplémentaires

Conceptuel

Développement de gestionnaires de protocoles

Présentation des gestionnaires de protocoles

Ajout d’icônes et de menus contextuels

Exemple de code : Extensions d’interpréteur de commandes pour les gestionnaires de protocole

Installation et inscription de gestionnaires de protocole

Création d’un connecteur de recherche pour un gestionnaire de protocole

Gestionnaires de protocole de débogage