![]() | ein einfaches Beispiel |
Vishnu startet direkt nach der Erstinstallation mit einem Demo-Job. Diesen werden wir uns jetzt (in einer vereinfachten Fassung) etwas genauer betrachten.
![]() |
---|
Der Start-Job kann über Konfiguration und Parameter eingestellt werden. |
![]() |
---|
Bevor wir auf die Details des Demo-Jobs genauer eingehen ein kurzer Hinweis: Wenn Sie sich gewundert haben, wieso dieser sich von dem eingangs dargestellten Demo-Job unterscheidet, so liegt das an zwei Dingen:
|
Der Vishnu-Demo-Job wird wie jedes Element in einer XML-Konfiguration beschrieben:
<?xml version="1.0" encoding="utf-8"?> <JobDescription> <LogicalName>Check All</LogicalName> <StartCollapsed>false</StartCollapsed> <LogicalExpression>CheckServers AND CheckDiskSpace</LogicalExpression> <SubJobs type="array"> <SubJob> <LogicalName>CheckServers</LogicalName> <PhysicalPath>..\CheckServers</PhysicalPath> <StartCollapsed>false</StartCollapsed> </SubJob> <SubJob> <LogicalName>CheckDiskSpace</LogicalName> <PhysicalPath>..\CheckDiskSpace</PhysicalPath> <StartCollapsed>false</StartCollapsed> </SubJob> </SubJobs> </JobDescription>
Wie man leicht sehen kann, enthält diese JobDescription zwar die Beschreibung für den Haupt-Job Check All aber keine Details über die beiden Sub-Jobs CheckServers und CheckDiskSpace. Die beiden Sub-Jobs werden in jeweils eigenen JobDescription.xml beschrieben. Insbesondere bei größeren Jobs erhöht das deutlich die Übersichtlichkeit.
![]() |
---|
Mehrere Jobs können auch in einer einzigen JobDescription.xml zusammengefasst werden. Wie das für unser Beispiel aussehen würde, sehen Sie auf der Seite Inline SubJobs. |
Das Schlüsselwort <JobDescription>, bzw. /<JobDescription> ist immer das äußerste Element (ganz oben und ganz unten) einer Vishnu-JobDescription.xml. Ok, es beginnt genau genommen nicht ganz oben, aber die erste Zeile kennzeichnet die ganze Datei als XML-Datei und ist in jeder JobDescription.xml gleich. Wir werden sie in der weiteren Beschreibung einfach ignorieren. Auch die abschließenden Wiederholungen eines Element-Namens mit dem vorangestellten "/" (</Irgendwas>) werden wir in Zukunft nicht mehr gesondert erwähnen (sie müssen einfach immer vorhanden sein).
Die wichtigsten inneren Elemente einer <JobDescription> sind:
<LogicalName> - das ist der Job-Name der auch später von Vishnu angezeigt wird.
<LogicalExpression> - das ist die Beschreibung der Elemente des Job-Inhalts und der logischen Verknüpfung ihrer Einzelergebnisse (siehe auch Vishnu Logik).
Die ausführenden Akteure des Jobs Checker und SubJobs. Die Namen dieser Akteure werden in der LogicalExpression über logische (und weitere) Operatoren miteinander verknüpft.
![]() |
---|
Normalerweise muss jedes in der LogicalExpression eingeführte Element mit demselben Namen im Job-Inhalt als Checker oder SubJob beschrieben werden (in unserem Beispiel CheckServers und CheckDiskSpace), sonst kann Vishnu den Job später nicht verarbeiten und meldet dies als Fehler. |
Wenn ein Job wie oben korrekt beschrieben wurde, reicht das, um ihn in Vishnu ausführen und darstellen zu können. Allerdings hat man im richtigen Leben nicht viel von einem Job, der einmal gestartet wurde und dann nur noch hübsch auf dem Bildschirm rumsteht.
Um praktischen Nutzen aus Vishnu-Jobs ziehen zu können, benötigt es weitere Akteure, von denen die zwei wichtigsten hier kurz vorgestellt werden sollen:
Worker - das sind eigenständige kleine Programme, die bei definierten Veränderungen in der Verarbeitung der LogicalExpression ausgeführt werden und verschiedene Aktionen auslösen können (z.B. Meldungen, Mails, etc.).
Trigger - sie sorgen dafür, dass Checker oder SubJobs zum Beispiel nach Ablauf einer vorgegebenen Zeit erneut ausgeführt werden.
JobDescription für den Sub-Job CheckServers:
<?xml version="1.0" encoding="utf-8"?> <JobDescription> <LogicalName>CheckServers</LogicalName> <LogicalExpression>(Google AND Heise) AND (Local OR Local_Backup)</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> </Checker> <Checker> <LogicalName>Heise</LogicalName> <PhysicalPath>Plugin\CheckServer.dll</PhysicalPath> <Parameters>www.heise.de|200|3</Parameters> <Trigger> <PhysicalPath>TimerTrigger.dll</PhysicalPath> <Parameters>S:2|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:3|S:20</Parameters> </Trigger> </Checker> <Checker> <LogicalName>Local_Backup</LogicalName> <PhysicalPath>Plugin\CheckServer.dll</PhysicalPath> <Parameters>9.8.7.6|200|3</Parameters> <Trigger> <PhysicalPath>TimerTrigger.dll</PhysicalPath> <Parameters>S:4|S:20</Parameters> </Trigger> </Checker> </Checkers> </JobDescription>
Sehen wir uns nun einen Auszug aus der JobDescription für den Sub-Job CheckServers genauer an:
Hier sind die wichtigsten Elemente (von oben nach unten):
<LogicalName> - das ist der (Sub-)Job-Name der auch später von Vishnu angezeigt wird.
![]() |
---|
Der LogicalName des SubJobs (hier CheckServers) muss genau der sein, der auch in der LogicalExpression des Haup-Jobs Check All auftritt. Nur dann kann Vishnu erkennen, dass es sich im logischen Ausdruck des Haupt-Jobs um diesen SubJob handelt. |
<LogicalExpression> - das ist (wie beim Haupt-Job) die Beschreibung der Elemente des Job-Inhalts und der logischen Verknüpfung ihrer Einzelergebnisse.
Der dann folgende Checker hat auch wieder einen LogicalName. Dieser muss entsprechend wieder derselbe sein, wie im logischen Ausdruck des SubJobs.
Jeder Checker besitzt eine DLL, die die eigentliche Prüfung dessen, was Sie überwachen wollen, durchführt. Das Element PhysicalPath gibt den Pfad relativ zum (Sub-)Job-Verzeichnis plus Dateiname dieser DLL an. Vishnu sucht die DLL dann später an dieser Stelle und lädt sie dynamisch.
![]() |
---|
Eine DLL ist, vereinfacht gesagt, ein kleiner Programmteil, der eine bestimmte Aufgabe erledigen kann. Was eine DLL genau ist, müssen Sie zum jetzigen Zeitpunkt noch nicht genau wissen. Sie können vorerst mit den mitgelieferten Checker-DLLs experimentieren. Spätestens aber, wenn Sie speziellere Aufgaben mit eigenen DLLs lösen wollen, empfehlen wir Ihnen das Kapitel eigene Checker. |
In Parameters werden die Aufrufparameter für die Checker-DLL mitgegeben. In unserem Beispiel sind das:
8.8.8.8 - die IP-Adresse des Google-Servers,
200 - die Anzahl Millisekunden, die bei einem Versuch, den Server zu erreichen maximal gewartet werden soll,
3 - die maximale Anzahl Versuche, bevor ein Fehler gemeldet wird.
![]() |
---|
Die Parameter werden in unseren Beispielen in einer verkürzten Notation hintereinander, durch
|
JobDescription für den Sub-Job CheckDiskSpace:
<?xml version="1.0" encoding="utf-8"?> <JobDescription> <LogicalName>Check Disk Space</LogicalName> <LogicalExpression>Check_C AND Check_D</LogicalExpression> <StartCollapsed>false</StartCollapsed> <Checkers type="array"> <Checker> <LogicalName>Check_C</LogicalName> <PhysicalPath>Plugin\CheckDiskSpace.dll</PhysicalPath> <UserControlPath>Plugin\SingleNodeUserControl_CheckDiskSpace.dll</UserControlPath> <Parameters>c:|200000|100|3</Parameters> <Trigger> <PhysicalPath>TimerTrigger.dll</PhysicalPath> <Parameters>M:10</Parameters> </Trigger> </Checker> <Checker> <LogicalName>Check_D</LogicalName> <PhysicalPath>Plugin\CheckDiskSpace.dll</PhysicalPath> <UserControlPath>Plugin\SingleNodeUserControl_CheckDiskSpace.dll</UserControlPath> <Parameters>d:|200000|100|3</Parameters> <Trigger> <PhysicalPath>TimerTrigger.dll</PhysicalPath> <Parameters>S:1|M:10</Parameters> </Trigger> </Checker> </Checkers> </JobDescription>