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 le passer en tant que paramètre ObjWbemSink. Les événements dans 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 CreateObject VBScript crée cet objet.
Membres
L’objet SWbemSink présente les types de membres suivants :
Méthodes
L’objet SWbemSink possède 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 applications. Pour éliminer les risques, utilisez la communication semi-synchronisée ou la 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 spécifié dans l’appel asynchrone, comme illustré 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 du journal 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 d’é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 de traiter sur un thread distinct tandis que le script commence à agir immédiatement 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 alors en file d’attente une grande quantité d’informations récupérées avant d’agir sur celles-ci. Pour de nombreux objets, le traitement semi-synchrone est adéquat ; par exemple, lors de l’interrogation d’un lecteur de disque pour ses propriétés, il peut n’y avoir qu’une fraction de seconde entre le moment où la requête est émise et le moment où les informations sont retournées et prises en charge. Cela est dû en grande partie au fait que la quantité d’informations retourné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 terminer le retour et l’action sur les informations peut prendre des heures. En plus de cela, le script peut manquer de mémoire et échouer de lui-même avant de terminer.
Pour les journaux d’é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 pris 10 minutes 45 secondes. Une requête asynchrone qui a effectué la même opération a pris 1 minute 54 secondes.
Exemples
Le VBScript suivant interroge de manière asynchrone les journaux d’é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 |
|
| IDL |
|
| DLL |
|
| CLSID |
CLSID_SWbemSink CLSID_SWbemSinkEvents |
| IID |
IID_ISWbemSink IID_ISWbemSinkEvents |
Voir aussi
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour