Docs

# Terms and definitions

# Scenario

Scenario is the main entity of the "Automation" module. A scenario includes:

  • An event that initiates the launch of the scenario, with its own data structure.

    The structure of the event is defined in the general pipeline of events processing.

  • One or more executable functions.
  • Various converter and data provider functions, comparison operators, API calls, variables, etc.

# Structure

Image

Local structure with its own set of properties, for assigning the Pin types to custom functions and variables.

Contains the following parameters:

  • General information
    • Structure name
    • Structure description
  • Structure properties
    • Property name
    • Type

      All existing types can be used except Exec.

# Block

A block is a graphical element of the scenario constructor, which may include a function, an event, a variable, various operators and converters.

Block example:

Image

# Block parameters

Block parameters - a panel with block settings located on the right side of the constructor, called by clicking on the block.

# Block categories

# Launch events

A block with the OnLogEvent event will be added to the scenario by default when it is created. Adding OnLogEvent blocks from the context menu is blocked.

# Local functions

Local functions include functions created within the current scenario and used only within it. In the current version, local functions are CodeFunctions. Users can create new functions as well as reuse previously declared functions for the current scenario.

# Global functions

Users has access to a list of global functions contained in the system library. List of global functions available to users.

# Variables

More about variable types

# Pin

Pin is a communication node for transferring data or initiating commands between scenario blocks.

Pins are used to determine which inputs and outputs can be connected to each other for data transfer.

# Pin categories

  1. Pin for data transfer. The designation on the Blocks is 🔴🟠🟡🟢🔵🟣🟤.
    1. There can be incoming and outgoing Pins.
      • You cannot connect 2 outgoing Pins to each other, as well as 2 incoming ones.
      • Only one connection can be established for an incoming Pin data transfer.
      • An outgoing Pin can be connected to many incoming Pins of other blocks.
      • You cannot connect Pins of one block to each other.
      • When attempting to make invalid connections, the user will be notified.
      • If a block has an incoming Pin, it can be set to a value or a link can be attached.

        In some cases, the user will be able to independently specify a value for incoming pin through the input field, without the need to attach a link to it.

    2. Pins differ in the types of data that are transferred between them. More about Data Types
    3. Pins of different types and data connections between them are visually distinct.
    4. For some universal functions, Pins of an indefinite type - Wildcard - can be declared at the stage of their creation. Learn more about the mechanics of Wildcard Pins
  2. Pin for Function call
    1. Pins of a function call and the links between them are visually different from Pins of data transfer - ▶.
    2. You cannot connect a data transfer Pin and a function call Pin.
    3. If a block has an incoming Pin of a function call, then to start it, a connection must be drawn from another function block or Event block.
      • Lack of links for Pins of a function call will not cause code build failure errors, the function just will not be executed.
      • Outgoing Pins may also have no links. This means that the scenario section will end with the execution of this function, if there is an incoming connection.
      • You cannot build multiple links from an outgoing function call pin. Image
      • Multiple links can go to the same function call pin from other functions or events. Image

# Scenario layout

The scenario layout is a scheme of interactions of various blocks.

A layout example:

Image

# Object Inspector

The Object Inspector is the right panel of the constructor used for configuring scenario blocks. Called by double clicking on the block.

Inspector example:

Image

# Object Manager

The Object Manager is the left panel of the constructor used for declaring new objects or for working with previously added ones.

Manager example:

Image

# Function

Functions are the main executable blocks of a scenario.

Functions are divided into 2 main classes:

# CodeFunction

This type of function, in addition to the basic settings, includes the ability to build a structure using the scripting programming language C# scripts.

# System functions

Comparison operators, math functions, data converters, etc. These functions are supplied by default for all systems, regardless of the composition of the products.

All functions are also divided into 2 categories:

  1. Control functions of scenario dataflow that are explicitly executed by connecting a link to a function callPin and which may themselves trigger the execution of other functions.
  2. Functions for converting data and obtaining values ​​at the output (do not have function call pins). These functions connect to incoming data pins and are automatically executed by the compiler when data is required that relies on them.

# Pure & Impure functions

Functions can be Pure and Impure

Pure:

  1. Pure functions do not change the state of scenario elements in any way.
  2. Data blocks do not participate in data flow control and can never have function call pins.
  3. Most often, pure functions are used as data acquisition functions or operators.
  4. Pure functions are executed whenever other functions rely on their data.

Impure:

  1. These blocks of functions are involved in managing the data flow of scenario execution.
  2. Blocks of control functions are characterized by the presence of special function call pins.
  3. Impure functions can change the state of scenario elements and global variables.

# Variable

The user can use variables when building a scenario.

  1. Variables are divided into:

    • Predefined standard (system) variables.
    • ID of the current scenario, Workgroup, bearer token, etc.
    • Local variables created by the user for the current scenario.
    • Global variables.
    • User-created variables (settable in the inspector, similar to the CodeFunction setting)

  2. There are 2 states for each variable: SET and GET. When added to a scenario, the user can specify the state of the variable.

# Rules for naming functions and variables

The name of a function or variable can contain:

  • letters (lowercase and uppercase).
  • underscore character ("_").
  • digits.

The name of a function or variable must start with:

  • a letter (lowercase and uppercase).
  • the underscore character ("_").
  • the "@" symbol.

The C# programming language is case sensitive: name and Name are 2 different entities.

The name of a function or variable cannot match keywords (for, if, using).

Example Valid/Invalid
myvar Permissible
Myvar14092 Permissible
_name Permissible
@variable1 Permissible
123myvar Invalid, starts with a number
my var Invalid, contains space

# Data types

Function Blocks support data transfer via Pins of the following types:

Title Possible values ​​ Ability to set a default value Validation
Boolean true/false YES -
Byte Integers from 0 to 255 YES Only non-negative integers.
Char Single Unicode character YES Prohibition to enter more than one character
Double YES
Dynamic Stores any values ​​ NO -
GUID Format value 000000000-0000-0000-0000-000000000000 YES Mask validation
Integer From -2147483648 to 2147483647 YES Whole numbers only. When entering a number less than or greater than the allowed value, the value is reduced to the minimum or maximum allowable
Integer64 From -9223372036854775808 to 9223372036854775807 YES Whole numbers only. When entering a number less than or greater than the allowed value, the value is reduced to the minimum or maximum allowable
String Unicode character string YES Any characters are allowed. There are no limits on the number of characters.
Structure NO -

Each type is color coded for easy identification.

Links can only be established between Pins of the same type.

# Automaton bot

Automaton Bot is a system user used for "depersonalizing" operations in scenarios of the "Automation" module.

  • The Automaton Bot user does not appear in the user list.
  • The Automaton Bot user cannot be changed or deleted.
  • The Automaton Bot user cannot be added to Workgroups.
  • For each "Workgroup" that owns an Automation scenario, the Automaton Bot user has a corresponding token issued.