# 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
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:
# 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
# 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
- Pin for data transfer. The designation on the Blocks is π΄π π‘π’π΅π£π€.
- 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.
- Pins differ in the types of data that are transferred between them. More about Data Types
- Pins of different types and data connections between them are visually distinct.
- 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
- There can be incoming and outgoing Pins.
- Pin for Function call
- Pins of a function call and the links between them are visually different from Pins of data transfer - βΆ.
- You cannot connect a data transfer Pin and a function call Pin.
- 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.
- Multiple links can go to the same function call pin from other functions or events.
# Scenario layout
The scenario layout is a scheme of interactions of various blocks.
A layout example:
# 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:
# 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:
# 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:
- 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.
- 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:
- Pure functions do not change the state of scenario elements in any way.
- Data blocks do not participate in data flow control and can never have function call pins.
- Most often, pure functions are used as data acquisition functions or operators.
- Pure functions are executed whenever other functions rely on their data.
Impure:
- These blocks of functions are involved in managing the data flow of scenario execution.
- Blocks of control functions are characterized by the presence of special function call pins.
- Impure functions can change the state of scenario elements and global variables.
# Variable
The user can use variables when building a scenario.
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)
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.