![]() | A simple Example |
Vishnu starts directly after the initial installation with a demo job. We will now take a look at this (in a simplified version) more closely.
![]() |
---|
The start job can be set via Configuration and parameters. |
![]() |
---|
Before we go into the details of the demo job, a quick note: If you were wondering why this differs from the demo job shown at the beginning, this is due to two things:
|
The Vishnu-demo job is described in an XML configuration (as every element):
<?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>
As you can easily see, this JobDescription contains the description for the main job Check All but no details about the two sub-jobs CheckServers and CheckDiskSpace. The two sub-jobs are each organised in their own JobDescription.xml. This significantly increases clarity, especially for larger jobs.
![]() |
---|
Several jobs can also be combined in a single JobDescription.xml. You can see what this would look like for our example on the page Inline SubJobs. |
The key word <JobDescription>or </JobDescription> is always the outermost element (right at the top and right at the bottom) of a Vishnu-JobDescription.xml. Ok, it doesn't actually start at the top, but the first line identifies the whole file as an XML file and is in every JobDescription.xml the same. We will continue to simply ignore this. The final repetitions of an element name with the preceding "/" (</something>) will no longer be mentioned separately in future (they simply must always be present).
The most important internal elements of a <JobDescription> are:
<LogicalName> - This is the job name that will also be displayed later by Vishnu.
<LogicalExpression> - This is the description of the elements of the job content and the logical linking of their individual results (see also Vishnu Logic).
The actors performing the job Checker and SubJobs. The names of these actors are linked together in the LogicalExpression via logical (and other) operators.
![]() |
---|
Each element introduced in the LogicalExpression, must be described with the same name as a Checker or SubJob in the job content (in our example CheckServers and CheckDiskSpace), otherwise Vishnu will not be able to process the job later and will report this as an error. |
If a job has been correctly defined, as described above, that is sufficient to be executed and displayed by Vishnu. However, in real life, you don't get much out of a job that has been started once and then just sits there pretty on the screen.
In order to derive practical benefits from Vishnu-Jobs, other actors are needed. The two most important ones are briefly presented here:
Workers - These are independent small programs that are executed, when certain states are reached during the processing of the LogicalExpression. Those can perform various actions (e.g. messages, mails, etc.).
Triggers - they ensure that Checkers or SubJobs are executed repeatedly, for example, after a specified period of time.
JobDescription for the 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>P:2|P:20</Parameters> </Trigger> </Checker> <Checker> <LogicalName>Local</LogicalName> <PhysicalPath>Plugin\CheckServer.dll</PhysicalPath> <Parameters>Localhost|1000|3</Parameters> <Trigger> <PhysicalPath>TimerTrigger.dll</PhysicalPath> <Parameters>P:3|P: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>P:4|P:20</Parameters> </Trigger> </Checker> </Checkers> </JobDescription>
Let's now take a closer look at an excerpt from the JobDescription for the CheckServers subjob:
Here are the most important elements (from top to bottom):
<LogicalName> - This is the (sub)job name that will later be displayed by Vishnu.
![]() |
---|
The LogicalName of the Subjob (here CheckServers) must be exactly the same as the one that appears in the LogicalExpression of the main job Check All. Only then can Vishnu recognize that the logical expression of the main job refers to this SubJob. |
<LogicalExpression> - this is (as with the main job) the description of the elements of the job content and the logical linking of their individual results.
The following Checker also has another LogicalName. This must be the same as in the logical expression of the SubJob.
Each checker owns a DLL that performs the actual check of what you want to monitor. The element PhysicalPath gives the path relative to the (sub)job directory plus the file name of this DLL. Vishnu then searches for the DLL later at this point and loads it dynamically.
![]() |
---|
A DLL is, in simple terms, a small program part that performs a specific task. You don't need to know exactly what a DLL is at this point. You can experiment with the included checker DLLs for now. But if you want to solve more specific tasks with your own DLLs, we recommend reading the chapter Custom Checkers. |
In Parameters the call-parameters for the Checker DLL are given. In our example, these are:
8.8.8.8 - the IP address of the Google server,
200 - the maximum number of milliseconds to wait when attempting to reach the server,
3 - the maximum number of attempts before an error is reported.
![]() |
---|
In our examples, the parameters are passed one after the other in a shortened notation, separated by "|". In principle, you can specify the format of your own parameters however you like, as long as they can be passed as text (string) and your recipients (checkers, workers, etc.) can process the format. |
JobDescription for the 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>