DevTrain Startseite SharePoint Camp ? In 5 Tagen zum SharePoint Profi!  
  
  
SUCHEN:  
ARTIKEL ONLINE: 525   

Kategorien
.NET
Datenbanken
Web
XML

Allgemein
Camp
Foren
Events
Persönliche Einstellungen
Registrieren
Prämien Shop
Kontakt
Impressum
Über DevTrain

Autoren


   Autor: Christian Pöpel Artikel Drucken
        
Event Sinks - Skripte im Hintergrund

Als erstes muss wohl geklärt werden was sind eigentlich diese Event Sinks? Event Sinks sind Ereignisempfänger.
Doch auch darunter kann man sich nur sehr abstrakt etwas vorstellen. Denn was für Ereignisse werden zu diesen Sinks gesendet, wo kann man diese Sinks finden bzw einsetzen und wie funktiert der Aufruf?

Also versuche ich ein bisschen Licht ins Dunkel zu bringen und formuliere die Antwort etwas anders...

Event Sinks sind Codeabschnitte die durch einen fest definierten Trigger (Auslöser) aktiviert werden.

Dieser Trigger kann z.B das Versenden eines Newsletters oder der Empfang einer Email sein.
Sinks können in fast jeder beliebigen Programmiersprache codiert werden. Häufig werden aber Sprachen verwendet die zum COM-Standard kompatibel sind.
Dazu zählen:
  • C / C++
  • Java (Script)
  • VB (Script)
Der Exchange 2000 von Microsoft unterstützt z.B. Ereignisempfänger für den Transport, das Protokollieren und zum Speichern.
Zudem unterscheidet man zwei Betriebsarten für Ereignisempfänger.
  • Synchroner Betrieb: Der Code wird zum Zeitpunkt des Ereignisses im Speicher ausgeführt
  • Asynchroner Betrieb: Der Code wird zu einem beliebigen Zeitpunkt nach dem auslösenden Ereignis gestartet
Das klingt ja alles schön und gut, aber wie bringt man jetzt diese Event Sinks dazu, dass sie das tun was ihre Aufgabe ist?

Diese Antwort lautet 'im System registrieren'.

Doch dazu müssen noch ein paar Grundlagen vorneweg erläutert werden.
Als erstes gilt, dass nicht zwischen Gross- und Kleinschreibung unterschieden wird (Case insensitive).
CScript.exe (siehe weiter unten) ist im Gegensatz zur WScript.exe ein auf Befehlszeilen basierender Host.
Ereignisempfänger basieren auf CDO (Collaboration Data Objects).
Das Server Extension Object (SEO)-Component Object Model (COM) managed die Verbindung zwischen der Quelle und dem Empfänger.
Um das zu ermöglichen benötigt man die weiter unten vorgestellten Scripte smtpreg.vbs / nntpreg.vbs.
Genauer möchte ich hier an dieser Stelle nicht eingehen. Da dieses Material den Rahmen dieses Artikels sprengen würde.
Wer sich darüber detailierter informieren möchte findet hier (im Devtrain) und im Internet genügend Referenzen.

Als nächstes benötigen wir Regeln, die sog. Rules.
Mit Regeln legt man fest was bei wem passieren soll. Ist doch logisch, oder? Nein? Gut, dann ein kleines Beispiel...

'...MAIL FROM=info@domain.de...' bedeutet das sich das Ereignis nur von info@domain.de aktivieren lässt. Alle anderen Absender werden ignoriert.
Man könnte das obige Beispiel auch mit Wildcarts festlegen:
'...MAIL FROM=*@domain.de...' Jetzt sind alle Absender mit @domain.de Auslöser.
'...MAIL FROM=*...' Alles und jeder ist ein Auslöser.
Zudem können mehrere Regeln, durch Semikolon getrennt, aufgelistet werden.
'...MAIL FROM=*@mydomain.de;*@yourdomain.de;RCPT TO=*@hisdomain.de;*@herdomain.de[;...]...'

RCPT? Was ist das? RCPT kümmert sich um das To-, CC- und BCC-Feld einer Emailnachricht. Es werden also diese drei Felder auf die festgelegten Regeln überprüft.

So, zurüch zum Schlagwort 'registrieren'.
Um das Ganze auch zum laufen zu bringen, muss dem System gesagt werden das es Ereignisempfänger gibt. Also setzt man Werte in der Registry. Genauer gesagt lassen wir das ein Skript erledigen. Diese Skripte gibt es schon fertig bei Microsoft. Sie sind in VB Script codiert und heissen smtpreg.vbs (für den Emailverkehr) und nntpreg.vbs (für News).
In diesen Skripten sind Funktionen definiert die verschiede Aufgaben ausführen. Z.B. das Registrieren eines Ereignisempfängers. Diesen Funktionen müssen Parameter übergeben werden

Die Syntax für die Regstrierung ist wie folgt aufgebaut:
cscript [smtpreg | nntpreg].vbs /add instance event name id rule

Erklärung der Parameter:
/addDer Funktionsaufruf der das Registrieren durchführt.
instanceDie Nummer des Virtuellen Servers (z.B. 42)
event Bei SMTP onArrival, bei NNTP onPost, onPostFinal oder onPostEarly
nameDer Name der Bindung mit dem System. Jede Bindung sollte einen anderen Namen besitzen um Probleme zu vermeiden. Bei Namen wird zwischen Gross- und Kleinschreibung unterschieden (Case Sensitive)
idDieser Identifizierer bzw. die Klassen ID (CLSID) versucht eine Instanz der Sink COM Klasse zu erzeugen (lokaler Rechner).
rulewie oben beschrieben werden hier die Regeln aufgelistet

Bsp.: cscript smtpreg.vbs /add 42 onArrival sinkAll mySink.sinkIt "mail from=*"

Um einen Ereignisempfänger wieder zu entfernen ruft man die Funktion Remove auf.
cscript [smtpreg | nntpreg].vbs /remove instance event name
Bsp.: cscript smtpreg.vbs /remove 42 onArrival sinkAll

Ein weiterer wichtiger Punkt ist das setzen von Eigenschaften (Properties).
cscript [smtpreg | nntpreg].vbs /setprop instance event name bag_name property_name property_value

Erklärung der Parameter:
die drei Parameter die auf den Funktionsaufruf folgen sind bereits oben erklärt worden.
bag_nameEin Bezeichner der mit dem man eine Eigenschaft hinzufügen oder modifizieren kann. Mögliche Werte SOURCE und SINK
property_nameBezeichner für den zu setzenden Wert.
property_valueDer Wert für property_name

Setzt man bag_name auf SOURCE so kann man für property_name PRIORITY oder RULE verwenden bei SINK gibt man bei property_name den Pfad zum Skript an (SCRIPTNAME). Der Pfad für das Skript muss in Anführungszeichen angegeben werden.
In diesem Script könnten dann Anweisungen enthalten sein um z.B. einen Eintrag in ein Logfile zu machen, Kopien der eintreffenden Emails zu erstellen, Emails an bestimmte Konten weiterleiten etc.
Bsp.: cscript smtpreg.vbs /setprop 42 onArrival mySMTPScriptinghostSink Sink ScriptName "c:somwheremyScript.vbs"

Entfernen kann man die eben erstellte Eigenschaft mit der Funktion delprop.
Bsp.: cscript smtpreg.vbs /delprop 42 onArrival mySMTPScriptinghostSink Sink ScriptName

Die Syntax ist fast genauso aufgebaut wie beim Erstellen einer Eigenschaft. Der Unterschied liegt lediglich im Namen der Funktion und das der Eigenschaftswert nicht angegeben wird.
Die restlichen Parameter müssen aber genau mit der erstellten Eigenschaft übereinstimmen.

Eine Auflistung aller Eregnisempfänger erhält man durch den Funktionsaufruf /enum.

Um Ereignisempfänger auf enabled oder disabled zu setzen führt man folgende Zeile aus.
cscript [smtpreg | nntpreg].vbs /enable | disable instance event name

Übergeben werden also nur die Instanz, das Event und der Name.

In der Regel werden die einzelnen Anwesungen in Batchdateien gepackt um nicht jede einzelne Befehlszeile einzeln eingeben zu müssen.
So eine Batchdatei kann wie folgt aussehen:

Inhalt der Register.BAT:
cscript smtpreg.vbs /add 42 onArrival sinkAll mySink.sinkIt "mail from=*"
cscript smtpreg.vbs /setprop 42 onArrival mySMTPScriptinghostSink Sink ScriptName "c:somwheremyScript.vbs"

So das war's auch schon zum Thema 'Event Sinks'. Ich hoffe das ich einen kleinen Einblick geben konnte.

Viel Spass
Christian Pöpel

DevTrain Camp - Schneller zum .NET 3.5 Developer
 
Verwandte Artikel      Verlinkte Dokumente
    Keine verknüpften Dokumente
    Keine Links vorhanden

  Erfasst am: 20.08.2002
  Gültig bis: 19.09.2002
2 Ratings
Bewertung: 90,0%
schlecht    sehr gut  

 
© Copyright 2007 ppedv AG