Sirveo Glossary
This is a reference for all Sirveo-specific terminology. It also serves as an index of the documentation.
General
Terms generally used in our documentation.
Server
Unless otherwise specified, server means the Sirveo server process.
Outbound integration
Means any interaction with external systems, services and APIs which is initiated by flows in a server. Outbound integrations are created by using specific nodes in flows, like HTTP client nodes and DNS query nodes.
Inbound integration
Means any external systems and services which initiates interaction with a server.
This includes any HTTP requests made to webhooks on a server, as well as direct integration with a server’s management API. Browsers interaction with web flows (via links) is also considered as form of inbound integration.
Composition
Composition is a process by which simpler tasks are composed into more complex ones. See the composition guide.
Reusability
Reusability is a feature that which prevents or minimizes duplication, and which is necessary for composition. See the composition guide.
Flows
Terms related to flows.
Flow
A flow is the basic automation construct in a Sirveo server. There are different flow modes to support different kinds of automation scenarios.
Node
A node refers to single task in a flow. A server provides different node types for different tasks and operations in flows. Technically, a node is a general abstraction of an input-output construct. A node may receive input data, and may produce output data, on one or more node channels. Nodes usually have configuration options to modify their operation.
Flow mode
A flow mode refers to a kind of flow. There are three flow modes; graph flows, task flows and web flows.
While all flows contain nodes, each flow mode has additional internal constructs which are specific to, and convenient for the automation scenario it is designed to handle.
Flow engine
The flow engine is the internal component that executes flows in a server. All flow modes are run by the same flow engine.
Flow editor
The flow editor is used for creating and testing flows in Sirveo’s user interface.
Active flow
An active flow is flow that is accessible by webhooks (for task flows) and links (for web flows). A flow is activated in the flow editor. When a flow is activated, the server creates a snapshot of its definition, with a revision number. Webhooks and links only have access to the current active revision of a flow. Making changes to an active flow does not affect the active snapshot. This allows flows to be changed and tested before re-activating them.
Flow variable
A flow variable is a configuration within a flow that makes a value available under a specific key in that flow’s data store. See flow variables.
External key
An external key is a feature of a flow variable, which allows a server variable to be used within a flow using a different internal key.
Graph flows
Terms related to graph flows.
Graph flow
A graph flow is used for modeling data-driven automation tasks. A graph flow can express any process that resembles a directed acyclic graph. However, the flow engine permits loops in graph flows, with limited cycles.
Channel
See node channel.
Node channel
A node channel is a logical location on a node, where that node may receive or produce data. By design, every node in Sirveo has an input and an output channel.
Most nodes which may produce errors have error channels. Some nodes have additional channels. Node channels are visible in graph flows, and when testing flows using the flow editor.
Connection
In a graph flow, a connection is an edge that connects to nodes. The flow engine uses connections to route data when it executes a graph flow.
Technically, a connection represents data flow between the two node channels of the connection’s source and target nodes.
Head node
A head node is the node that executes first in a graph flow. A graph flow must contain exactly one head node. A head node is technically identified as the node which has zero incoming connections.
Task flows
Terms related to task flows.
Task flow
A task flow is used for modeling automation scenarios which are task-driven. A task flow uses a particular execution construct called task levels. The basic mental model (and execution model) of a task flow looks like this:
Task level 1 [ node 1.1 node 1.2 ]Task level 2 [ node 2.1 node 2.2 node 2.X ]Task level Y [ node Y.X ]This represents a task flow with three task levels (1, 2, Y), each containing nodes (1.1 to Y.X).
The flow engine executes a task flow like this:
- Task levels are run from top-to-bottom
- For serial task levels, it’s nodes are run left-to-right
- For parallel task levels, it’s nodes are run concurrently
- Once every node in the first task level has run, the next task level is run.
- When a task level has a condition, that condition must evaluate to true, otherwise the task level is skipped
- When a task level is configured as stop-on-match, flow execution stops once it’s nodes are finished.
Task level
A task level is a logical phase of execution in a task flow. Every task level in a task flow must contain at least one node. A task level is serial by default, which means that the nodes it contains are executed from left to right, as those nodes appear in the task level. Parallel execution can be enabled on a task level, in which case it’s nodes run concurrently.
Serial task level
A serial task level in a task flow executes it’s nodes one at a time. This is the default behaviour. Serial task level can be changed to a parallel task level, and vice versa.
Parallel task level
A parallel task level in a task flow executes it’s nodes concurrently. A parallel task levels can be changed to a serial task level, and vice versa.
Task level condition
A task level condition is a javascript expression which may be added to a task level. This causes the task level to only run when it’s condition evaluates to true, or a truthy value, otherwise the task level is skipped, and the flow engine executes the next task level (if any).
Pass-through
Task levels use pass-through mode by default. When the flow engine has run the nodes of a task level in pass-through mode, it continues to the next task level (if any).
Stop-on-match
Task levels can be changed from pass-through mode to stop-on-match mode. When the flow engine has run the nodes of a task level in stop-on-match mode, it stops the flow execution.
This mode is typically used in combination with task level conditions.
Web flows
Terms related to web flows.
Web flow
A web flow is used for creating flows that interact with People in a browser. In addition to nodes, web flows use steps, blocks and handler configuration to automatically generate the appropriate UI.
Step
A step in a web flow is a particular view that is available in a web flow. Each step has optional handlers which determine how that step initializes, and moves forward or backward to other steps.
Step block
A step block are configuration items on steps in a web flow. The blocks in a step determine it’s content when displayed to user interacting with the flow. Blocks exist for markdown content, and common form elements to obtain user input data.
Step handler
Step handlers are configured on steps. A step’s handlers determine what happens when:
- a step initializes
- a user clicks the back button
- a user clicks the next button
Step handlers can do one of three things; run a node, go to a different step, or redirect a user to any valid URL.
All step handlers are processed by the server, not in the browser.
Initialization handler
Initialization handlers are step handlers which are processed before a step is displayed in a web flow. Often used alongside conditions to change to a different steps.
Back handler
Back handlers are step handlers that determines step behaviour when a user clicks the back button on a web flow step.
Next handler
Next handlers are step handlers that determine step behaviour when a user clicks the next button on a web flow step.
Step handler condition
Step handler conditions, or simply conditions in the context of web flows, are javascript expressions which can be attached to step handlers. When a step handler has an associated condition, it only runs when it’s condition evaluates to a true value.
Step progress
Step progress is an optional step setting that shows a progress bar on a particular step in a web flow.
Flow stores
Terms related to flow stores.
Flow store
A flow store is data which is available to access within flows. Some stores may be modified by a flow. See the stores guide and the store reference for details.
Metadata store
See the store reference.
Input store
See the store reference.
Input metadata store
See the store reference.
Output store
See the store reference.
Data store
See the store reference.
Variable store
See the store reference.
Server capabilities
Terms related to capabilities and features of a server.
Server variable
See the store reference.
Webhook
See the webhook guide.
Link
See the links guide.
Telemetry
See the telemetry reference.
Telemetry mode
Telemetry mode is a server configuration option that controls telemetry behaviour. See the telemetry reference.
Triggers
Terms related to the server’s trigger capabilities.
Trigger
A trigger is a server capability that executes flows. The server provides event triggers and schedule triggers.
Event trigger
Event triggers are used to run one or more flows when the server receives a specific event type. See the event trigger guide.
Schedule trigger
A schedule trigger is used to execute a flow at a regular interval, or once at a future time. See the schedule trigger guide.
Cron schedule trigger
A cron schedule trigger is configured in the UI, to run a flow periodically. See the schedule trigger guide.
Once-off schedule trigger
A once-off schedule trigger is created within a flow, using the schedule node, to schedule the execution of another flow at a future time. See the schedule trigger guide.
Events
Terms related to the event system.
Event
Events are the core of Sirveo’s event system. See the event trigger guide.
Event data
Event data refers to the data payloads within events.
Event type
Every event has a type, used to uniquely describe what an event represents. The type of an event is used in the configuration of event triggers.
Persistent event
Persistent events are stored in the server’s database. Not all events may be persistent.
Transient event
Transient events are processed by the event system, without being stored in the server’s database.
System event
A system event is created by the server, instead of user events which are generated by flows. See the system event reference for a complete list.
User event
A user event is created by the Event node within flows.
Event processor
The event processor is an internal server subsystem that processes events. It is responsible for storing persistent events, executing event triggers and enforcing event loop protection rules.
Event browser
The event browser is a UI feature for inspecting persistent events in the server’s database.
Event retention
Event retention refers to whether, and how long the server keeps events in it’s database. The default behaviour is determined by the server’s event retention period. Individual user events may have custom retention periods.
Event loop protection
An event-related server capability that prevents loops from occurring in event triggers. See the [event loop protection reference] for details and specific rules.
KV Store
Terms related to the server’s KV store facility.
KV Store
A server capability which allows flows to store arbitrary data in the server’s key-value store. See the KV store guide for details.
Note that the KV store is unrelated to flow stores
Store browser
The store browser is a UI feature for inspecting persistent items in the server’s KV store.
Licensing
Terms related to licenses and server licensing.
Restricted mode
A server enters restricted mode without a valid license, which means it does not execute flows. See the licensing reference for details.
Configuration
Terms related to server configuration.
Default system user
Server configuration that determines if and how a server creates a new administrative user account, when it starts up with no user accounts in the database. See configuration / default system user.
Network isolation
Network isolation is a security-related server capability to make Sirveo handle flow URL’s on a secondary HTTP port without the management API/UI. See Network Isolation for details.
Admin URL
A server setting that affects URL generation in the UI. See configuration / networking.
Inbound URL
A server setting that affects URL generation in the UI. See configuration / networking.
Admin port
A server setting that determines the HTTP port a server uses for it’s management API, UI and flow URLs. See Network Isolation for details.
Inbound port
A server setting that determines the HTTP port a server uses for flow URLs, without the management API, and UI. See Network Isolation for details.
Schedule retention period
A server setting that determines how long the server keeps completed once-off schedule triggers. See configuration / data retention.
Event retention period
A server setting that determines how long the server keeps event data. See configuration / data retention.