{"componentChunkName":"component---src-templates-default-template-tsx","path":"/ki-syntax/definitions/variables/","result":{"data":{"asciidoc":{"id":"5cdb1fbe-348c-5765-bcc1-d7a45038d481","html":"
\n
Table of Contents
\n\n
\n
\n

Variable Introduction

\n
\n
\n\n\n\n\n\n
\n\n\n
\n

Variable names are limited by the underlying tokenizer to contain:

\n
\n
\n
    \n
  • \n

    Alphanumerical characters A-Z, a-z, 1234567890

    \n
    • \n
  • \n

    Underscore _

    \n
    • \n
  • \n

    Slash /

    \n
    • \n
\n
\n
\n
\n
\n

HIRO variables are largely defined by the users. Variables are\ndesigned to be reused throughout the entire HIRO installation.\nDefined variables are stored in the database and are available for\n(re)use for all users. Typically (with the exception of temporary/local\nvariables) each variable is defined during initial creation to contain a\nspecific type of data e.g.:

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Table 1. Variable Examples
VariableDescriptionContentExample

IPv4Address

Contains an IPv4 address.

IPv4 address as string.

192.168.0.1,
\n 192.168.0.2,
\n 192.168.0.3

Interface

Contains a Network interface name.

Interface name as\nstring.

eth0,
\neth1

\n
\n\n\n\n\n\n
\n\n\n
\n

Variable definitions are immutable once defined, therefore great care\nshould be taken when defining new variables. This should be a process\ninvolving key staff from all groups of HIRO users. Customers can\nand should define their best practice naming and definition standards\nfor HIRO variables during the initial rollout process.

\n
\n
\n
\n
\n\n\n\n\n\n
\n\n\nMake sure to define all variables you wish to use\nbefore their first occurrence in an Issue.\n
\n
\n
\n
\n

Todo Variables

\n
\n

Each Issue must contain at least one \"Todo\"-Variable otherwise it will\nautomatically be marked as \"resolved\" without any actual processing. The\nuser can define variables with a special \"Todo\" flag that are\nexclusively used to track progress. HIRO will use \"Todo\"-Variables\nto track if a task has been completed. Issues will remain in processing\nuntil all values from all \"Todo\" variables in this Issue have been\nremoved.

\n
\n
\n

The user can create a variable HostIsDown to which a list of hostnames\nthat should be reachable is stored. The variable can contain a list of\nvalues like:

\n
\n
\n
\n
HostIsDown = [\"192.168.1.100\",\"192.168.1.101\",\"192.168.1.102\"]
\n
\n
\n
\n

Now a set of Knowledge Items are triggered by the existence of\nHostIsDown and start taking measures to restore service for these\nhostnames. Once they are confirmed to be available again the respective\nhostname is deleted from the list of values in HostIsDown. Once all\n\"Todo\"-Variables have been emptied, the Issue is considered to be\nfinished and will be \"resolved\". As long as there are any values present\nin any of the \"Todo\"-Variables, the Issue will remain in processing\nuntil Knowledge Items have removed all values, the Issue was resolved\nmanually or ejected by other means.

\n
\n
\n
\n
\n

Special Variables

\n
\n

There are a few variables that have special meaning and contain information\nabout the issue processing.

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
VariableDescription

ogit/_id

The graph ID of the vertex, often referred to as \"issue ID\"

ogit/_created-on

Timestamp of issue creation in ms since epoch

ogit/_modified-on

Timestamp of last issue modification in ms since epoch

ogit/subject

Human readable issue subject shown in frontend UI

ogit/status

Current state of the issue

ogit/Automation/originNode

ID of the vertex the issue was originally created on

ogit/Automation/processingNode

ID of the vertex the issue is currently attached to

ogit/Automation/processingTimestamp

Timestamp value of the last processed KI (ms). It is updated with each KI execution and displayed in the task content

ogit/Automation/deployStatus

Deployment status of issue in engine

\n
\n

With the exception of ogit/subject, these variables should be regarded as \"read-only\"\nfor KI processing.

\n
\n
\n

[[Self-generated Variables]]\n=== Self-generated Variables

\n
\n
\n

These are variables that are self-generated in the moment that one of the components: Issue, Node or KI exists.

\n
\n
\n

IID – it is ogit/_id of an Issue that comes into HIRO

\n
\n
\n

NodeID – it is ogit/_id of a vertex/Node from the semantic graph

\n
\n
\n

KIID – It is ogit/_id of a KI

\n
\n
\n

These values are auto imported and explicit matching in conditions.

\n
\n
\n
\n
do\n  Taskid = IID
\n
\n
\n
\n
\n

Virtual Variables

\n
\n

There are variables that will be available only within KI processing context and are not\nactually stored or visible in the graph representation of the issue.

\n
\n
\n

ExecIdle

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
VariableDescription

ExecIdle

Seconds since last KI execution. It is dinamically calculated from the ´ogit/Automation/processingTimestamp´

\n
\n

A simple example that would make use of the ExecIdle variable to trigger a KI only after\nno other KI could be executed for about 5 minutes (only minimal WHEN and DO sections shown):

\n
\n
\n
\n
when\n  ExecIdle > 300\ndo\n  log(\"Issue has been idle for 5 minutes\")
\n
\n
\n
\n

Let’s illustrate the relationship between ExecIdle and processingTimestamp using the Sleep function. The Sleep function pauses the engine from searching KIs for 10 seconds. During this pause, ExecIdle will be 0 with the last KI execution and will increase over time. Meanwhile, ogit/Automation/processingTimestamp will store the timestamp of the last executed KI. After the 10-second pause, ExecIdle will be 10, and the task will resume, searching for KIs that can complete it.

\n
\n
\n
\n\"ExecIdleProcessingTimestamp.png\"\n
\n
\n
\n
\n
\n
","document":{"main":"2.Variables","title":"2.Variables","subtitle":""},"fields":{"toc":true,"location":["ki-syntax","definitions","variables"]}},"sidebarYaml":{"id":"6f28bdca-d703-5e79-ae00-b0508f8ee82a","showIndex":true}},"pageContext":{"id":"5cdb1fbe-348c-5765-bcc1-d7a45038d481","parent":"ki-syntax"}},"staticQueryHashes":["1010459453","1010459453","2356112386","2356112386","2603905930","2603905930","3026652197","3026652197","3167850324","3167850324","63159454","63159454"]}