Vishnu actors

Here you will find details on various Vishnu-elements. In addition to general function descriptions, parameterisation and return values are also addressed and illustrated using XML examples.

Job

Job is the topmost Vishnu-element. A job corresponds to a directory with at least one JobDescription.xml-file in which the Job is described in detail.
The job contains everything that Vishnu requires to be able to process orders.

Note
How a JobDescription.xml is structured is described in A simple Example. You can find further Job-Examples on TreeEvents and Inline SubJobs, among others.

Jobs with modules that are not located the UserAssemblyDirectory search these as loadable DLLs in a subdirectory "Plugin" (see the following excerpts from the Demo-SubJob CheckServers).

Note
Vishnu can also process zipped jobs. The path to the zip archive containing the job directory must then be specified without the ".zip" extension.

Checker

Checkers are the essential Vishnu-players. They are loaded dynamically by Vishnu and do the testing work. They must return a test result:

true = everything is ok
false = something is not ok
null = no decision can be made at the moment.

Note
In addition to the regular results mentioned above, Checkers can also encounter unexpected errors, e.g. if a server addressed is not available. They then abruptly terminate the current run with an Exception. Vishnu also processes these Exceptions and displays them using a wrench symbol .

In addition, each Checker has a public Return object, which can be used if necessary. Any complex issues can be passed on to your Custom Views by Vishnu.

You can specify call parameters for Checkers in the JobDescription.xml using the '<Parameters>' element, see the following example:

Call parameters for checkers and triggers

Copy

...
<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>
   ...

Important
In addition to the parameters you pass, Checkers receive a TreeEvent from Vishnu. This can contain various other information, e.g. Return objects from other Checkers. Further details about Checkers can be found on Custom Checkers.

Important

In addition to the parameters you pass, Checkers receive a TreeEvent from Vishnu. This can contain various other information, e.g. Return objects from other Checkers.

Further details about Checkers can be found on Custom Checkers.

Trigger

Triggers ensure that the Checkers do their work. They trigger the Checkers or Workers at regular intervals or when certain events occur.

As with Checkers (see above), call-parameters for Triggers can be specified in the JobDescription.xml using the '<Parameters>' element.

Vishnu already provides three types of Triggers that should cover most use cases:

TimerTrigger
TimerTriggers call Checkers at regular intervals.
FileWatcherTrigger
FileWatcherTriggers call Checkers whenever observed files change.

TreeEventTrigger

TreeEventTriggers are Vishnu-internal triggers that react to events (TreeEvents) within the Vishnu-Tree and then can start Checkers.

Note
Even though TreeEventTriggers are Vishnu internal modules, they can be configured in the JobDescription.xml like other triggers. For more information see TreeEvents.

The following example shows various Triggers and their call parameters.

Worker

Workers are groups of one or more SubWorkers each with an EXE-program, which is started by Vishnu when certain TreeEvents defined for the Worker occur. What the EXE-programs of the SubWorkers do and whether or how they react to passed parameters, is entirely up to the programs. Vishnu is not interested in their results (fire and forget).

Workers are always triggered depending on one or more TreeEvents. This is determined via the attribute <LogicalExpression> in the form
<LogicalExpression>triggering node:TreeEvent[|TreeEvent]</LogicalExpression>
(see also the example below).

As with Checkers and Triggers, call-parameters for SubWorkers are passed in the JobDescription.xml using the '<Parameters>' element.

Important
Vishnu prepends a severity level as an integer value to the call-parameters you define. If this value is negative, it means that the TreeEvent(s) triggering the worker no longer exist. Since the parameters are passed to SubWorkers via the command line, no additional TreeEvent can be passed as it is possible with Checkers. That's why the Vishnu parameter substitution is particularly important for SubWorkers.

Important

Vishnu prepends a severity level as an integer value to the call-parameters you define. If this value is negative, it means that the TreeEvent(s) triggering the worker no longer exist.

Since the parameters are passed to SubWorkers via the command line, no additional TreeEvent can be passed as it is possible with Checkers.
That's why the Vishnu parameter substitution is particularly important for SubWorkers.

Definition and parameters of workers

Copy

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

Note
In the previous example, the call parameters for the SubWorker "MicroMailer" are not formulated, but are transferred via the environment. You should enter the parameters of your e-mail provider here, or rather elsewhere, eg. in the environment.

Note
SubWorkers can also have Triggers assigned to them, as in the previous example with the "MicroMailer" (commented out). These then fire repeatedly until the TreeEvent(s) triggering the Worker no longer exist.

Escalator

An Escalator can be used to assign different Workers to different levels of severity. A typical application example is an undesirable result from a Checker (usually false or exception), which is responded to by an error message on the screen in the first step. Only if there is no response after a certain period of time does a further step follow, for example an email (escalation).
See the following example:

Below you can see the definition of the Escalator from the above example in the JobDescrition.xml.

Definition and parameters of the escalator

Copy

...
  <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="Stage 1 (Run 1) %Timestamp%: %MachineName% %Event% from %Source% in %Sender%#Logical: %Logical% %Exception%" -Caption="Info" -MessageNewLine=#</Parameters>
        </SubWorker>
        <SubWorker RunCounter="3">
          <PhysicalPath>VishnuMessageBox.exe</PhysicalPath>
          <Parameters>-Message="Stage 2 (Run 3) %Timestamp%: %MachineName% ATTENTION %Event% from %Source% in %Sender%#Logical: %Logical% %Exception%" -Caption="Warning" -MessageNewLine=#</Parameters>
        </SubWorker>
      </SubWorkers>
    </Parameters>
        <Trigger>
          <PhysicalPath>TimerTrigger.dll</PhysicalPath>
          <Parameters>S:10</Parameters>
        </Trigger>
      </SubWorker>
    </SubWorkers>
  </Worker>
...

Note
As you can see, the Escalator acts like a Worker.

ValueModifier

ValueModifiers take over Results from other Checkers and present them in a modified form.

In the following screenshot of the demo job CheckSingleValueModifier can be seen, that the "Result" in the "Day" node only shows the day of the date (here 21).
Check Single Value Modifier .

In the associated JobDefinition.xml you can see that the Checker date does not even belong to the LogicalExpression <IS Tag> of the Job. However, it is executed by the Job as an anonymous node in the background and can then be accessed via the visible ValueModifier Day by <Reference>Date</Reference>.

ValueModifier

Copy

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

Furthermore, it can be seen that the ValueModifier needs two additional parameters:

Type The desired result type of the ValueModifier, here int (.Net-Int32)
Format The format for displaying the result of the ValueModifier.
Note
For "Format" you can specify any suitable C# format string.

Note
For "Format" you can specify any suitable C# format string.

The ValueModifier shown above is already provided by Vishnu. It offers conversions for the following result types:

Boolean
Int16
Int32
Int64
DateTime
String

Important
You can also create your own ValueModifiers. How to do this is described on Custom ValueModifiers.

Logger

Loggers are assigned directly to checkers or jobs. They can be used to track and document certain state changes in the Vishnu-tree. As shown in the following JobDescription.xml of the demo job CheckServersLogging, Loggers, like Workers, are triggered depending on one or more TreeEvents. This is determined using the <Parameters> attribute in the form <Parameters>TreeEvent[|TreeEvent][,other_parameters]</Parameters>.

Definition of loggers

Copy

<?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>P:3|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:20|P: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>P:2|P:20</Parameters>
      </Trigger>
      <Logger>
        <PhysicalPath>TextFileLogger.dll</PhysicalPath>
        <Parameters>Exception|LogicalResultChanged,%TempDirectory%\xyz.log</Parameters>
      </Logger>
    </Checker>
  </Checkers>
</JobDescription>

The first of the two Loggers defined in the demo job above writes to the Vishnu-log file by default, the second logger writes to its own log file %TempDirectory%\xyz.log.
As a reminder: the Vishnu-log file is %TempDirectory%\Vishnu.%MainJobName%\Vishnu.log by default.

The Logger produces the following results:

Output of the TextFileLogger.dll in the Vishnu log file

Copy

...
2020.01.24 09:23:03,952339 Event: LogicalResultChanged
        Node: Google|Google, Logical: True, Source: 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
...

Output of the TextFileLogger.dll in the log file '%TempDirectory%\xyz.log'

Copy

2020.01.24 09:23:05,963918 Event: LogicalResultChanged
        Node: NotPresent|NotPresent, Logical: False, Source: 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

Important
The TextFileLogger.dll is a simple demo DLL that Vishnu already supplies. The content and form of the logging output are hard-wired into the TextFileLogger.dll. To determine the content and form of the logger output, you can also create your own Loggers. How to do this is described on Custom Loggers. Your own Loggers can then also interpret additional transfer parameters that control the output format. It is up to you which parameters you pass to the logger after the comma. Vishnu simply passes these on to your logger.

Important

The TextFileLogger.dll is a simple demo DLL that Vishnu already supplies. The content and form of the logging output are hard-wired into the TextFileLogger.dll. To determine the content and form of the logger output, you can also create your own Loggers. How to do this is described on Custom Loggers.

Your own Loggers can then also interpret additional transfer parameters that control the output format. It is up to you which parameters you pass to the logger after the comma. Vishnu simply passes these on to your logger.

Note
By the way: the TextFileLogger.dll is found by Vishnu, even though it is not in the Plugin-directory of the demo job. The reason for this is that the DLL is in the UserAssemblyDirectory.