Click or drag to resize

Configuration and parameters

The behavior of Vishnu can be adjusted using various parameters. These parameters can be specified when calling Vishnu via the command line, but they can also be set via Vishnu.exe.config.user, the Environment, or the Registry. Vishnu also forwards "anonymous" parameters that are unknown to it to Jobs and Checkers, as long as they have been stored in places known to Vishnu.

Vishnu-Jobs and their elements such as Checkers can be controlled via various parameters in the JobDescription.xml. A list of parameter settings for jobs and their elements can be found further down in this chapter in Job parameters.

Vishnu parameters

Vishnu-parameters can be set in various ways, as already mentioned at the beginning. The following list shows examples of how this should be done.

  • Command line

    Parameter transfers to Vishnu via the command line always follow the scheme Vishnu [anonymous parameters] [Vishnu parameters]. The square brackets are not entered. They symbolise that the respective parameters are optional, i.e. do not have to occur.

    Example: Vishnu "something" -job="DemoJobs\CheckAll"

    Hinweis  Note

    There is also an advanced way to transfer anonymous parameters. You can set your parameters via Custom Parameter Reader control. Vishnu primarily takes a user-specific parameter reader into account when searching for parameters, whose path is defined via the parameter UserParameterReaderPath.

  • Vishnu.exe.config.user

    Vishnu.exe.config.user is the central configuration file for your own Vishnu-Settings. Here you will find some preset parameters. You can change or delete these but also add your own. You will find the Vishnu.exe.config.user after the first launch of Vishnu in the path %LOCALAPPDATA%\Vishnu\Vishnu.exe.config.user, where LOCALAPPDATA is a setting of the Windows environment and usually refers to C:\Users\<User>\AppData\Local.

    Example: <add key="Job" value="DemoJobs\CheckAll">

    HinweisNote

    The order of the parameters in Vishnu.exe.config.user is irrelevant. They only need to be within <appSettings> and </appSettings>.

  • Environment (Windows environment)

    Example: SET Job="DemoJobs\CheckAll"

  • Registry: Vishnu itself does not use the registry, but supports the storage of parameter settings in the path RegistryBasePath. RegistryBasePath is a configurable parameter and is set by default to the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Vishnu. Vishnu looks for string values below RegistryBasePath.

    Example: Key HKEY_LOCAL_MACHINE\SOFTWARE\Vishnu\Job with value "DemoJobs\CheckAll"

In the following list we have made a selection of essential Vishnu-parameters for you.

Hinweis  Note

A complete list of all Vishnu-parameters can be found on Vishnu.InterchangeAppSettings.

  • AppConfigUser

    The AppConfigUser parameter specifies the path to the Vishnu.exe.config.user file. This setting should normally not need to be changed.

    AchtungAttention

    If you ever find yourself needing to change AppConfigUser, remember that this parameter cannot be defined in Vishnu.exe.config.user itself.

  • Job

    This parameter can be used to specify the path to the job or to a zip archive that contains the job directory (then without the ".zip" extension). The path can be specified absolutely or relative to the parent job or to the Vishnu-installation directory. Valid path specifications are, for example, DemoJobs\CheckAll or c:\Users\%UserName%\AppData\Local\Apps\Vishnu\CheckAll.

  • Demo mode

    After initial installation, Vishnu is started in demo mode with a demo job. This is preset in the Vishnu.exe.config.user. To get rid of the "-DEMO-" display in the Vishnu window, you can set Demo mode to "false" or remove the parameter completely.

  • Autostart

    If Autostart is set to "true", Vishnu begins processing the jobs immediately after the program starts. This is also the default setting.

  • SingleInstance

    This parameter is set to "False" by default. This means that Vishnu can be started multiple times on one computer at the same time. If you want Vishnu to only start once on one computer, set this parameter to "True". A further attempt to start then only brings the already running Vishnu program (instance) to the foreground.

  • WorkingDirectory

    KillWorkingDirectoryAtShutdown

    WorkingDirectory is the Vishnu-Working directory. This is where Vishnu stores log files and snapshots of its status if no other storage directories have been defined for them. The default setting is %TempDirectory%\Vishnu.%MainJobName%.

    By default, Vishnu leaves the WorkingDirectory at the end of processing. If you want Vishnu to delete the working directory in a final step, you can set KillWorkingDirectoryAtShutdown to "true".

    HinweisNote

    Of course, Vishnu only deletes directories that were previously created by Vishnu.

  • DebugFile

    The DebugFile is the Vishnu-log file. Vishnu writes here all processing errors and, if configured, all of its parameters with their origins plus a list of all loaded assemblies.

    All output from any loggers you may have defined also ends up in the DebugFile.

    The Vishnu-log file is %TempDirectory%\Vishnu.%MainJobName%\Vishnu.log by default.

    HinweisNote

    Further information on loggers can be found on Vishnu actors.

  • DumpAppSettings

    DumpLoadedAssemblies

    As mentioned above, these two parameters can be used for troubleshooting. means write to the log file, with nothing is logged. The default for both parameters is .

  • RegistryBasePath

    Vishnu looks for parameters (Key) and their values (Value) in the Windows registry below RegistryBasePath. The default setting is HKEY_LOCAL_MACHINE\SOFTWARE\Vishnu.

  • UserAssemblyDirectory

    UserParameterReaderPath

    The UserAssemblyDirectory parameter can be used to specify a directory in which Vishnu will search for your own Checker DLLs, own UserControls or also your Custom Parameter Reader in addition to the respective job directories. The default name for this directory is UserAssemblies and the associated path is usually already assigned by Vishnu so that you do not have to set the UserAssemblyDirectory parameter yourself. However, any custom parameter reader you have must also be set accordingly using the UserParameterReaderPath parameter, for example to "%UserAssemblyDirectory%\DemoParameterProvider.dll".

  • SnapshotDirectory

    The SnapshotDirectory parameter can be used to set a directory in which Vishnu looks for saved snapshots of Vishnu-Jobs. The SnapshotDirectory is always relative to the current Job-Directory and is set to "...\Snapshots" by default.

    HinweisNote

    What exactly Snapshots are and how they are configured is described in a separate chapter entitled Snapshots.

HinweisNote

The parameter transfer is the same for all parameter settings. You will find a corresponding description at the Beginning of this section.

Job parameters

The topmost element of a Vishnu-processing is always the Job. What the job should look like and what it should do is defined in a JobDescription.xml file.

Jobs can be nested as desired. In future we will speak of (main-)Job and SubJobs, although Vishnu treats all jobs equally, especially since a SubJob can in turn be the "main-"Job for other SubJobs.

For an example of a working JobDescription.xml, see Inline SubJobs.

HinweisNote

In the JobDescription.xml, user parameters unknown to Vishnu ("anonymous") can also be forwarded to your Checkers or Workers. You can read what this is good for and how it works in the chapter Vishnu parameter substitution.

The following list contains all essential parameters that can be set within a JobDescription.xml. This applies not only to Jobs but also to all Job-elements such as Checkers, Triggers, Workers etc.

Job parameters

Structure view

  • LogicalName

    All Jobs, Checkers, SubJobs, Snapshots and Named Triggers and Loggers have a LogicalName that Vishnu can use to process them. Additionally, Vishnu displays this LogicalName on the screen for Jobs, Snapshots, and Checkers.

    Example: <LogicalName>Check All</LogicalName>

    AchtungAttention

    This LogicalName must be the same as the name under which the node is addressed in the LogicalExpression (see below), otherwise Vishnu cannot resolve the assignment at runtime. Keep this in mind if you ever want to change a LogicalName.

    HinweisNote

    If a Job loads another as a SubJob, the SubJob receives the LogicalName with which it is named in the main job. Vishnu takes care of adjusting references in the SubJob internally if necessary.

  • LogicalExpression

    All Jobs and SubJobs are described using a LogicalExpression. You use the LogicalExpression to determine how the Job's nodes relate to each other and what structure the Job ultimately has on the screen.

    HinweisNote

    LogicalExpressions can be formulated in two slightly different ways, see the following example:

    1. <LogicalExpression>(Google AND Heise) AND (Local OR Local_Backup)</LogicalExpression>

    2. <LogicalExpression><![CDATA[(Google AND Heise) AND (Local OR Local_Backup)]]></LogicalExpression>

    The second form, in which the logical expression is additionally enclosed in "<![CDATA[" und "]]>", has the advantage that special characters may also appear in the logical expression. This makes it possible, to write Operators in their short form. Details are provided in the chapter Vishnu Logic.

  • PhysicalPath

    Each Job is found via its PhysicalPath. The PhysicalPath does not belong to the job definition itself, but must be set outside of the JobDescription.xml at the moment of loading. For a main job, this is controlled via the Vishnu parameter Job; for SubJobs, the PhysicalPath must be set in the JobDescription.xml of the loading, parent Job.

    Checkers,Triggers, Loggers, Workers and ValueModifiers are also loaded via the PhysicalPath, provided they do not reference another node or TreeEvents (see also Named Triggers and Loggers and TreeEvents).

    Example: <PhysicalPath>..\SubJob</PhysicalPath>

  • Parameters

    The Parameters section is used to store transfer-parameters for your own Checkers, Triggers, Workers or Loggers in the JobDescription.xml. Vishnu then passes these parameters to your own Checkers, Triggers, Workers or Loggers later when you call them.

    The form and syntax of the transferred parameters is not fixed. You are completely free to determine this. The only important thing is that your own element (DLL) understands the format that you have stored in the JobDescription.xml.

    HinweisNote

    As with LogicalExpression, parameters can be passed in the extended format, such as the following for a worker: <Parameters><![CDATA[Fehler|%Timestamp%: %MachineName% MyChecker %Event% of %Source% in %Sender%]]></Parameters>

  • Reference

    In special cases, Reference is used to refer to other Vishnu-elements.

    The most common use case is certainly with ValueModifiers. Here, the checker whose Result is to be modified is specified using <Reference>Checkername</Reference>. Examples of this can be found on Vishnu actors and Custom ValueModifiers.

    Another application can be found at Trigger- and Logger-assignments, which reference previously defined triggers and loggers (See also Named Triggers and Loggers).

  • StartCollapsed

    All Jobs are displayed in expanded state by default, i.e. Sub-elements such as Checkers or SubJobs are visible at first. To change this behaviour, you can set StartCollapsed to true.

    HinweisNote

    You have even more extensive options by saving the current arrangement of a Vishnu-Tree at runtime, see Vishnu Control. Incidentally, the display can be saved individually on each workstation.

  • ThreadLocked

    LockName

    Vishnu works in a highly parallel manner, i.e. all elements such as Checkers, Triggers etc. can work simultaneously. Vishnu is designed for this from the outset (threadsafe). However, a Checker-type you have created may run into problems if several similar checkers are configured in a tree and are running at the same time.

    Achtung Attention

    The errors that may then occur can be very unpleasant and difficult to detect.
    In such a situation, set the ThreadLocked switch to true at the Job-level or Checker-level. Vishnu then ensures that Checkers marked in this way are executed one after the other and not simultaneously. In order to be able to handle different Checker-types in a differentiated manner, use the optional additional attribute Lockname.
    Here is an example: <ThreadLocked LockName="ConcurrentSQL">true</ThreadLocked>

  • UserControlPath

    JobListUserControlPath

    NodeListUserControlPath

    SingleNodeUserControlPath

    ConstantNodeUserControlPath

    JobConnectorUserControlPath

    SnapshotUserControlPath

    The settings summarised here are all used to define alternative representations (Views) of Vishnu-elements. With their help you can optionally specify relative paths to your own Views (DLLs).

    The parameter UserControlPath only refers to the element, for which it is set in the JobDescription.xml. The other parameters can be set at Job-level and then apply to all subordinate elements of the type contained in the name of the parameter (JobList, NodeList, SingleNode, ConstantNode, JobConnector, Snapshot).
    The parameter SingleNodeUserControlPath also determines the appearance of ValueModifiers and NodeConnectors.

    HinweisNote

    See also A simple Example and Custom Views.

Job
    LogicalName
    LogicalExpression
    PhysicalPath
    StartCollapsed
    ThreadLocked
        LockName
    JobTrigger
        Reference
        PhysicalPath
        Parameters
    JobSnapshotTrigger
        Parameters
        Reference
        PhysicalPath
    JobLogger
        Reference
        PhysicalPath
        Parameters
    UserControlPath
    JobListUserControlPath
    SnapshotUserControlPath
    NodeListUserControlPath
    JobConnectorUserControlPath
    SingleNodeUserControlPath
    ConstantNodeUserControlPath
    Checkers
        Checker
            LogicalName
            PhysicalPath
            Parameters
            IsMirror
            Trigger
                Reference
                PhysicalPath
                Parameters
            Logger
                Reference
                PhysicalPath
                Parameters
            UserControlPath
            SingleNodeUserControlPath
            ThreadLocked
                LockName
            IsGlobal
            CanRunDllPath
    ValueModifiers
        ValueModifier
            LogicalName
            Reference
            PhysicalPath
            Format
            Type
            IsGlobal
            UserControlPath
            SingleNodeUserControlPath
    Triggers
        Trigger
            LogicalName
            Reference
            PhysicalPath
            Parameters
    Loggers
        Logger
            LogicalName
            PhysicalPath
            Parameters
    Workers
        Worker
            LogicalExpression
            SubWorkers    
                SubWorker
                    PhysicalPath
                    Parameters
                    Trigger
                        Reference
                        PhysicalPath
                        Parameters
    SubJobs
        SubJob
            LogicalName
            PhysicalPath
            StartCollapsed
            (Recursion job)            
    Snapshots
        Snapshot
            LogicalName
            PhysicalPath
            StartCollapsed

see also