Vishnu Akteure

Der Job ist das oberste Vishnu-Element. Ein Job entspricht einem Verzeichnis mit mindestens einer Datei JobDescription.xml-Datei, in der der Job genau beschrieben wird.
Der Job enthält alles, was Vishnu benötigt, um Aufträge verarbeiten zu können.

Hinweis
Wie eine JobDescription.xml aufgebaut ist, wird unter ein einfaches Beispiel beschrieben. Weitere Job-Beispiele finden Sie u.a. unter TreeEvents und Inline SubJobs.

Jobs mit Modulen, die sich nicht im UserAssemblyDirectory befinden, enthalten diese als zuladbare DLLs in einem Unterverzeichnis Plugin, siehe die folgenden Auszüge aus dem Demo-SubJobCheckServers.

Hinweis
Vishnu kann Jobs auch gezippt verarbeiten. Der Pfad zum Zip-Archiv, welches das Job-Verzeichnis enthält muss dann ohne ".zip"-Extension angegeben werden.

Checker sind die wesentlichen Vishnu-Akteure. Sie werden von Vishnu dynamisch geladen und machen die Prüf-Arbeit. Sie müssen ein Prüfergebnis zurückliefern:

• true = alles ok

• false = es ist etwas nicht ok

• null = es kann gerade keine Entscheidung getroffen werden.

Hinweis
Neben den o.g. regulären Ergebnissen können Checker auch auf unerwartete Fehler stoßen, z.B. wenn ein angesprochener Server nicht erreichbar ist, sie beenden den aktuellen Prüflauf dann abrupt mit einer Exception. Vishnu verarbeitet auch diese Exceptions und stellt sie üblicherweise über ein Schraubenschlüssel-Symbol dar .

Zusätzlich hat jeder Checker ein öffentliches Return-Objekt, über welches ggf. beliebig komplexe Sachverhalte durch Vishnu an eigene Views weitergereicht werden können.

Aufrufparameter für Checker können Sie in der JobDescription.xml über das Element '<Parameters>' mitgeben, siehe nachfolgendes Beispiel:

...
<Checker>
  <LogicalName>Google</LogicalName>
  <PhysicalPath>Plugin\CheckServer.dll</PhysicalPath>
  <Parameters>8.8.8.8|200|3</Parameters>
  <Trigger>
    <PhysicalPath>TimerTrigger.dll</PhysicalPath>
    <Parameters>S:1|S:20</Parameters>
  </Trigger>
  <Logger>
    <Reference>FirstNamedLogger</Reference>
  </Logger>
</Checker>
...

Wichtig
Checker bekommen von Vishnu neben den von Ihnen übergebenen Parametern noch ein TreeEvent übergeben. Dieses kann diverse weitere Informationen enthalten, z.B. auch Return-Objekte anderer Checker. Weitere Details zu Checkern sind unter eigene Checker zu finden.

Trigger sorgen dafür, dass die Checker ihre Arbeit machen. Sie stoßen die Checker oder Worker in regelmäßigen Abständen oder bei bestimmten Ereignissen an.

Aufrufparameter für Trigger können wie auch bei Checkern (s.o.) in der JobDescription.xml über das Element '<Parameters>' mitgegeben werden.

Drei Trigger, mit denen die meisten Anwendungsfälle abgedeckt sein dürften, liefert Vishnu schon mit:

• TimerTrigger

  TimerTrigger rufen Checker in regelmäßigen Zeitabständen auf.

• FileWatcherTrigger

  FileWatcherTrigger starten Checker immer dann, wenn sich beobachtete Dateien ändern.

• TreeEventTrigger

  TreeEventTrigger sind Vishnu-interne Trigger, die auf Ereignisse (TreeEvents) innerhalb des Vishnu-Trees reagieren und dann Checker starten können.

  Hinweis
  Auch wenn TreeEventTriggerVishnu-interne Module sind, können sie wie andere Trigger in der JobDescription.xml konfiguriert werden. Mehr Informationen zu TreeEvents finden Sie unter TreeEvents.

Im nachfolgenden Beispiel sind verschiedene Trigger und ihre Aufrufparameter zusammengestellt.

Worker sind Gruppen von einem oder mehreren SubWorkern mit je einem EXE-Programm, das von Vishnu gestartet wird, wenn bestimmte, für den Worker definierte TreeEvents eintreten. Was die EXE-Programme der SubWorker tun und ob oder wie sie auf übergebene Parameter reagieren, ist allein Sache der Programme. Vishnu interessiert sich auch nicht für deren Ergebnisse (fire and forget).

Worker werden immer abhängig von einem oder mehreren TreeEvents ausgelöst. Festgelegt wird das über das Attribut <LogicalExpression> in der Form
<LogicalExpression>auslösender Knoten:TreeEvent[|TreeEvent]</LogicalExpression>/<LogicalExpression>auslösender Knoten:TreeEvent[|TreeEvent]</LogicalExpression>

(siehe auch nachfolgendes Beispiel).

Aufrufparameter für SubWorker werden, wie auch bei Checkern und Triggern, in der JobDescription.xml über das Element '<Parameters>' mitgegeben.

Wichtig

Vishnu stellt den von Ihnen definierten Aufrufparametern einen Schweregrad als Integer-Wert voran. Wenn dieser Wert negativ ist, bedeutet dass, das das oder die für den Worker auslösenden TreeEvents nicht mehr bestehen. Da die Parameter an SubWorker als Kommandozeilenparameter übergeben werden, kann hier nicht, wie bei Checkern von Vishnu neben den von Ihnen übergebenen Parametern noch ein TreeEvent übergeben werden. Deshalb kommt der Vishnu Parameter-Ersetzung bei SubWorkern eine besondere Bedeutung zu.

  ...
<Workers type="array">
  <Worker>
    <LogicalExpression>Heise:False|Exception</LogicalExpression>
    <SubWorkers type="array">
      <SubWorker>
        <PhysicalPath>VishnuMessageBox.exe</PhysicalPath>
        <Parameters>-Message="%Timestamp%: CheckServers %Event% von %Source% in %Sender%#%Exception%" -Caption="Server Fehler" -MessageNewLine=#</Parameters>
      </SubWorker>
      <SubWorker>
        <PhysicalPath>MicroMailer.exe</PhysicalPath>
        <Parameters><![CDATA[-Message="%Timestamp%:  CheckServers %Event% von %Source% in %Sender%#%Exception%." -Caption="Server Fehler!" -MailHostPort=%MailHostPort% -MailPassword=%MailPassword% -MailSender="Absender" -MailRecipients="Empfänger1[,Empfänger2,...]"]]></Parameters>
        <!-- Trigger>
          <LogicalName></LogicalName>
          <PhysicalPath>TimerTrigger.dll</PhysicalPath>
          <Parameters>M:20</Parameters>
        </Trigger -->
      </SubWorker>
    </SubWorkers>
  </Worker>
  ...
</Workers>
...

Hinweis
Im vorangehenden Beispiel sind die Aufrufparameter für den SubWorker MicroMailer nicht ausformuliert, sondern werden über das Environment übergeben. Sie sollten hier, bzw. besser an anderer Stelle oder im Environment, die Parameter Ihres E-Mail Providers eintragen.

Hinweis
SubWorker können wie im vorangehenden Beispiel beim MicroMailer (auskommentiert) auch Trigger zugeordnet bekommen. Sie lösen dann solange wiederholt aus, bis das oder die für den Worker auslösenden TreeEvents nicht mehr bestehen.

Über einen Escalator können verschiedene Worker verschiedenen Schweregraden zugeordnet werden. Ein typisches Anwendungsbeispiel ist ein unerwünschtes Ergebnis eines Checkers (i.d.R. false oder Exception), auf das hin im ersten Schritt eine Fehlermeldung auf dem Bildschirm ausgegeben wird. Erst wenn darauf nach einer gewissen Zeitspanne noch nicht reagiert wurde, folgt in einem weiteren Schritt zum Beispiel eine Mail (Eskalation).
Siehe nachfolgendes Beispiel:

Nachfolgend sehen Sie die Definition des Escalators aus dem obigen Beispiel in der JobDescrition.xml.

...
  <Worker>
    <LogicalExpression>Check Escalator:False</LogicalExpression>
    <SubWorkers type="array">
      <SubWorker>
        <PhysicalPath>Escalator.exe</PhysicalPath>
        <Parameters Transport="File">
      <SubWorkers type="array">
        <SubWorker RunCounter="1">
          <PhysicalPath>VishnuMessageBox.exe</PhysicalPath>
          <Parameters>-Message="Stufe 1 (Run 1) %Timestamp%: %MachineName% %Event% von %Source% in %Sender%#Logical: %Logical% %Exception%" -Caption="Info" -MessageNewLine=#</Parameters>
        </SubWorker>
        <SubWorker RunCounter="3">
          <PhysicalPath>VishnuMessageBox.exe</PhysicalPath>
          <Parameters>-Message="Stufe 2 (Run 3) %Timestamp%: %MachineName% ACHTUNG %Event% von %Source% in %Sender%#Logical: %Logical% %Exception%" -Caption="Warnung" -MessageNewLine=#</Parameters>
        </SubWorker>
      </SubWorkers>
    </Parameters>
        <Trigger>
          <PhysicalPath>TimerTrigger.dll</PhysicalPath>
          <Parameters>S:10</Parameters>
        </Trigger>
      </SubWorker>
    </SubWorkers>
  </Worker>
...

Hinweis
Wie man sieht, ist ein Escalator genaugenommen auch nur ein besonderer Worker.

ValueModifier übernehmen Results von anderen Checkern und stellen diese in veränderter Form dar.

Im folgenden Screenshot des Demo-Jobs CheckSingleValueModifier ist zu sehen, dass das "Ergebnis" im Knoten "Tag" nur den Tag des Datums anzeigt (hier 21).
.

In der zugehörigen JobDefinition.xml kann man sehen, dass der Checker Datum nicht mal zur LogicalExpression "<IS Tag>" des Jobs gehört. Er wird aber vom Job als anonymer Knoten im Hintergrund ausgeführt und kann dann über den sichtbaren ValueModifier Tag über <Reference>Datum</Reference>/<Reference>Datum</Reference> angesprochen werden.

<?xml version="1.0" encoding="utf-8"?>
<JobDescription>
  <LogicalName>CheckSingleValueModifier</LogicalName>
  <LogicalExpression>
    IS Tag
  </LogicalExpression>
  <Checkers type="array">
    <Checker>
      <LogicalName>Datum</LogicalName>
      <PhysicalPath>CheckDate.dll</PhysicalPath>
    </Checker>
  </Checkers>
  <ValueModifiers>
    <ValueModifier>
      <LogicalName>Tag</LogicalName>
      <Reference>Datum</Reference>
      <Type>int</Type>
      <Format>{0:dd}</Format>
    </ValueModifier>
  </ValueModifiers>
</JobDescription>

Weiterhin ist zu sehen, dass der ValueModifier noch zwei zusätzliche Parameter benötigt:

• Type Der gewünschte Typ des Ergebnisses des ValueModifiers, hier int (.Net-Int32)

• Format Das Format für die Darstellung des Ergebnisses des ValueModifiers.

  Hinweis
  Bei "Format" können beliebige, passende C#-Format-Strings angegeben werden.

Der im obigen Beispiel verwendete ValueModifier ist schon in Vishnu integriert. Er bietet Konvertierungen für folgende Ergebnistypen an:

• Boolean

• Int16

• Int32

• Int64

• DateTime

• String

Wichtig
Sie können auch eigene ValueModifier erstellen. Wie das geht, wird unter eigene ValueModifier beschrieben.

Logger werden Checkern oder Jobs direkt zugeordnet. Sie können zur Nachverfolgung und Dokumentation bestimmter Zustandsänderungen im Vishnu-Tree eingesetzt werden.

Wie in der nachfolgenden JobDescription.xml des Demo-Jobs CheckServersLogging zu sehen ist, werden Logger, wie auch schon Worker, abhängig von einem oder mehreren TreeEvents ausgelöst.
Festgelegt wird das über das Attribut <Parameters> in der Form <Parameters>TreeEvent[|TreeEvent][,sonstige_Parameter]</Parameters>/<Parameters>TreeEvent[|TreeEvent][,sonstige_Parameter]</Parameters>.

<?xml version="1.0" encoding="utf-8"?>
<JobDescription>
  <LogicalName>CheckServersLogging</LogicalName>
  <LogicalExpression>
    <![CDATA[(Google AND Heise) & (Local OR NotPresent)]]>
  </LogicalExpression>
  <SingleNodeUserControlPath>Plugin\SingleNodeUserControl_CheckServer.dll</SingleNodeUserControlPath>
  <Checkers type="array">
    <Checker>
      <LogicalName>Google</LogicalName>
      <PhysicalPath>Plugin\CheckServer.dll</PhysicalPath>
      <Parameters>8.8.8.8|200|3</Parameters>
      <Trigger>
        <PhysicalPath>TimerTrigger.dll</PhysicalPath>
        <Parameters>S:1|S:20</Parameters>
      </Trigger>
      <Logger>
        <PhysicalPath>TextFileLogger.dll</PhysicalPath>
        <Parameters>Exception|LogicalResultChanged</Parameters>
      </Logger>
    </Checker>
    <Checker>
      <LogicalName>Heise</LogicalName>
      <PhysicalPath>Plugin\CheckServer.dll</PhysicalPath>
      <Parameters>www.heise.de|200|3</Parameters>
      <Trigger>
        <PhysicalPath>TimerTrigger.dll</PhysicalPath>
        <Parameters>S:3|S:20</Parameters>
      </Trigger>
    </Checker>
    <Checker>
      <LogicalName>Local</LogicalName>
      <PhysicalPath>Plugin\CheckServer.dll</PhysicalPath>
      <Parameters>Localhost|1000|3</Parameters>
      <Trigger>
        <PhysicalPath>TimerTrigger.dll</PhysicalPath>
        <Parameters>S:20|S:300</Parameters>
      </Trigger>
    </Checker>
    <Checker>
      <LogicalName>NotPresent</LogicalName>
      <PhysicalPath>Plugin\CheckServer.dll</PhysicalPath>
      <Parameters>9.8.7.6|200|3</Parameters>
      <Trigger>
        <PhysicalPath>TimerTrigger.dll</PhysicalPath>
        <Parameters>S:2|S:20</Parameters>
      </Trigger>
      <Logger>
        <PhysicalPath>TextFileLogger.dll</PhysicalPath>
        <Parameters>Exception|LogicalResultChanged,%TempDirectory%\xyz.log</Parameters>
      </Logger>
    </Checker>
  </Checkers>
</JobDescription>

Der erste der beiden im obigen Demo-Job definierten Logger schreibt per Default in das Vishnu-Logfile, der zweite Logger schreibt in ein eigenes Logfile %TempDirectory%\xyz.log.
Zur Erinnerung: das Vishnu-Logfile ist per Voreinstellung %TempDirectory%\Vishnu.%MainJobName%\Vishnu.log.

Die Logger erzeugen folgende Ergebnisse:

...
2020.01.24 09:23:03,952339 Event: LogicalResultChanged
        Knoten: Google|Google, Logical: True, Quelle: Google
        AnyServer, Thread: 0020/08904, Tree: Tree 1
        AND(CheckServersLogging)/AND(Internal_1)/Google, Status: Done
        WorkingDirectory: C:\Users\<user>\AppData\Local\Temp\Vishnu.CheckServersLogging\20544
...

2020.01.24 09:23:05,963918 Event: LogicalResultChanged
        Knoten: NotPresent|NotPresent, Logical: False, Quelle: NotPresent
        AnyServer, Thread: 0022/19564, Tree: Tree 1
        AND(CheckServersLogging)/OR(Internal_2)/NotPresent, Status: Done
        WorkingDirectory: C:\Users\<user>\AppData\Local\Temp\Vishnu.CheckServersLogging\20544

Wichtig

Bei der TextFileLogger.dll handelt es sich um eine einfache Demo-DLL, die Vishnu schon mitliefert. Inhalt und Form der Logging-Ausgabe sind hierbei in der TextFileLogger.dll fest verdrahtet. Um Inhalt und Form der Logger-Ausgabe zu bestimmen, können Sie auch eigene Logger erstellen. Wie das geht, wird unter eigene Logger beschrieben. Eigene Logger könnten dann auch weitere Übergabeparameter interpretieren, welche das Ausgabeformat steuern. Welche Parameter Sie dem Logger zusätzlich hinter dem Komma übergeben, ist Ihnen überlassen. Vishnu reicht diese einfach an Ihren Logger weiter.

Hinweis
Übrigens: die TextFileLogger.dll wird von Vishnu gefunden, obwohl sie sich nicht im Plugin-Verzeichnis des Demo-Jobs befindet. Grund dafür ist, dass die DLL sich im UserAssemblyDirectory befindet.