Optimisation d’un fournisseur d’événements

Un fournisseur d’événements peut consacrer beaucoup de temps à la création d’événements. Si aucune application cliente n’utilise les événements créés, le fournisseur gaspillera les ressources système. En outre, WMI dépense une quantité considérable de ressources pour analyser et envoyer des requêtes complexes au fournisseur approprié. Pour éviter le gaspillage de ressources système et améliorer les performances de votre fournisseur d’événements, vous pouvez implémenter l’interface IWbemEventProviderQuerySink . IWbemEventProviderQuerySink surveille les requêtes que les applications clientes inscrivent auprès de WMI à l’aide des méthodes NewQuery et CancelQuery . En surveillant les requêtes clientes inscrites, votre fournisseur peut déterminer si des messages doivent être envoyés à WMI.

WMI appelle NewQuery sur un fournisseur d’événements lorsqu’un consommateur client inscrit une requête de filtre d’événements qui contient des références à des événements pris en charge par ce fournisseur d’événements. Ainsi, le fournisseur d’événements responsable des événements de modification instance pour la classe EmailClass peut être configuré pour générer des notifications uniquement pour l’expéditeur. Lorsque le fournisseur reçoit une requête demandant la notification des modifications apportées à la propriété objet , le fournisseur peut commencer à générer ces notifications. Dans ce scénario, WMI n’est pas tenu d’ignorer les notifications qui signalent uniquement les modifications du destinataire .

WMI appelle NewQuery sur un fournisseur d’événements lorsqu’un consommateur client inscrit une requête de filtre d’événements qui contient des références à des événements pris en charge par ce fournisseur d’événements. L’objectif de CancelQuery est que le fournisseur d’événements met à jour la liste des événements qui doivent être envoyés.