Objet SWbemSink

L’objet SWbemSink est implémenté par les applications clientes pour recevoir les résultats des opérations asynchrones et des notifications d’événements. Pour effectuer un appel asynchrone, vous devez créer une instance d’un objet SWbemSink et la passer en tant que paramètre ObjWbemSink . Les événements de votre implémentation de SWbemSink sont déclenchés lorsque l’État ou les résultats sont retournés, ou lorsque l’appel est terminé. L’appel de VBScript CreateObject crée cet objet.

Membres

L’objet SWbemSink possède les types de membres suivants :

Méthodes

L’objet SWbemSink a ces méthodes.

Méthode Description
Annuler Annule toutes les opérations asynchrones associées à ce récepteur.

Notes

Un rappel asynchrone permet à un utilisateur non authentifié de fournir des données au récepteur. Cela pose des risques de sécurité pour vos scripts et vos applications. Pour éliminer les risques, utilisez une communication semi-synchrone ou une communication synchrone. Pour plus d’informations, consultez appel d’une méthode.

Événements

Vous pouvez implémenter des sous-routines à appeler lorsque des événements sont déclenchés. Par exemple, si vous souhaitez traiter chaque objet retourné par un appel de requête asynchrone tel que SWbemServices. ExecQueryAsync, créez une sous-routine à l’aide du récepteur qui est spécifié dans l’appel asynchrone, comme indiqué dans l’exemple suivant.

Sub SinkName_OnObjectReady(objObject, objAsyncContext)

Utilisez le tableau suivant comme référence pour identifier les événements et les descriptions des déclencheurs.

Événement Description
OnCompleted Déclenché lorsqu’une opération asynchrone est terminée.
OnObjectPut Déclenché lorsqu’une opération put asynchrone est terminée.
OnObjectReady Déclenché lorsqu’un objet fourni par un appel asynchrone est disponible.
OnProgress Déclenché pour fournir l’état d’une opération asynchrone.

Récupération asynchrone des statistiques des journaux des événements

WMI prend en charge les scripts asynchrones et semi-synchrones. Lors de la récupération d’événements à partir des journaux des événements, les scripts asynchrones récupèrent souvent ces données beaucoup plus rapidement.

Dans un script asynchrone, une requête est émise et le contrôle est immédiatement retourné au script. La requête continue à traiter sur un thread distinct, tandis que le script commence immédiatement à agir sur les informations retournées. Les scripts asynchrones sont pilotés par les événements : chaque fois qu’un enregistrement d’événement est récupéré, l’événement OnObjectReady est déclenché. Une fois la requête terminée, l’événement OnCompleted se déclenche et le script peut continuer en fonction du fait que tous les enregistrements disponibles ont été retournés.

En revanche, dans un script semi-synchrone, une requête est émise et le script met en file d’attente une grande quantité d’informations extraites avant d’agir dessus. Pour de nombreux objets, le traitement semi-synchrone est approprié ; par exemple, lors de l’interrogation d’un lecteur de disque pour ses propriétés, il peut y avoir uniquement une seconde fractionnée entre le moment où la requête est émise et le moment où les informations sont retournées et exploitées. Cela est dû en grande partie au fait que la quantité d’informations renvoyées est relativement faible.

Toutefois, lors de l’interrogation d’un journal des événements, l’intervalle entre le moment où la requête est émise et le moment où un script semi-synchrone peut se terminer et le retour des informations peut prendre des heures. En plus de cela, le script peut manquer de mémoire et échouer de manière autonome avant de terminer.

Pour les journaux des événements avec un grand nombre d’enregistrements, la différence de temps de traitement peut être considérable. sur un ordinateur de test Windows 2000 avec 2 000 enregistrements dans le journal des événements, une requête semi-synchrone qui a récupéré tous les événements et les a affichés dans une fenêtre de commande a duré 10 minutes 45 secondes. Une requête asynchrone qui a effectué la même opération a duré une minute de 54 secondes.

Exemples

Le code VBScript suivant interroge de manière asynchrone les journaux des événements pour tous les enregistrements.

Const POPUP_DURATION = 10
Const OK_BUTTON = 0
Set objWSHShell = Wscript.CreateObject("Wscript.Shell")
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
 & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set objSink = WScript.CreateObject("WbemScripting.SWbemSink","SINK_")
objWMIService.InstancesOfAsync objSink, "Win32_NTLogEvent"
errReturn = objWshShell.Popup("Retrieving events", POPUP_DURATION, _
"Event Retrieval", OK_BUTTON)
Sub SINK_OnCompleted(iHResult, objErrorObject, objAsyncContext)
 WScript.Echo "Asynchronous operation is done."
End Sub
Sub SINK_OnObjectReady(objEvent, objAsyncContext)
 Wscript.Echo "Category: " & objEvent.Category
 Wscript.Echo "Computer Name: " & objEvent.ComputerName
 Wscript.Echo "Event Code: " & objEvent.EventCode
 Wscript.Echo "Message: " & objEvent.Message
 Wscript.Echo "Record Number: " & objEvent.RecordNumber
 Wscript.Echo "Source Name: " & objEvent.SourceName
 Wscript.Echo "Time Written: " & objEvent.TimeWritten
 Wscript.Echo "Event Type: " & objEvent.Type
 Wscript.Echo "User: " & objEvent.User
End Sub

Spécifications

Condition requise Valeur
Client minimal pris en charge
Windows Vista
Serveur minimal pris en charge
Windows Server 2008
En-tête
Wbemdisp. h
MIDL
Wbemdisp. idl
DLL
Wbemdisp.dll
CLSID
CLSID _ SWbemSink
CLSID _ SWbemSinkEvents
IID
IID _ ISWbemSink
IID _ ISWbemSinkEvents

Voir aussi

Scripts d’objets d’API