RHEO glossary

RHEO: Seven Bridges product line concerned with automating data analyses on the Seven Bridges Platform. Consists of the RHEO Automation Development Kit (ADK) for developing automations and the RHEO API, RHEO CLI, and the RHEO GUI for managing and running automations programmatically or interactively. The word "rheo" is greek and means "flow".
Automation: Technology by which a process or procedure is performed with minimum human assistance. Source: Wikipedia.
Automation (Seven Bridges): Synonym for RHEO product line.
Automation (code): One or more Python scripts (.py files) with optional user-defined auxiliary files that programmatically define the automation execution logic. Developed with the RHEO Automation Development Kit (ADK). Automation code can be executed locally or on the cloud, after deploying them in form of a code package to the Seven Bridges Platform.
Automation (entity): Seven Bridges top-level platform entity (like a file, task, or app) consisting of a UUID, a name, a description, an owner, and automation members with access permissions. It also contains one or more code package (entities) that constitute the executable versions of this automation.
RHEO Automation Development Kit (ADK): Pair of Python libraries, Freyja and Hephaestus, that together allow automation developers to write automation code that runs on the Seven Bridges Platform.
Automation (project): Python project on the automation developer's computer containing the automation code. Needs to follow a defined file and directory structure to allow generation of valid code package file. Can be created with Freyja sub-command 'init'.
RHEO API: Part of the Seven Bridges Public API (SB API) for managing automation entities and child entities programmatically.
RHEO CLI: Part of the Seven Bridges Command Line Interface (SB CLI) for managing automation entities and child entities from the terminal. Can also be used to start new automation runs. The RHEO CLI uses the RHEO API to communicate with the platform.
RHEO GUI: Part of the Seven Bridges visual interface for managing automation runs in a Web browser. Primary means for automation users to start new automation runs.
Automation (end) user: Person who executes an automation entity using the RHEO GUI or RHEO CLI. In need of a “push button” solution to analyze data they bring to the Seven Bridges Platform.
Automation developer: Person who develops automation (code) and optionally deploys it as code package on the Seven Bridges Platform. Provides “push button” solutions for automation users. Automation developer and automation user can be the same person, but are typically distinct.
Automation member: Seven Bridges user or team assigned to an automation entity with defined access permissions (READ, WRITE, EXECUTE, or ADMIN). READ permission is required to see the automation entity. EXECUTE is required to start a new automation run. WRITE is required to update the automation entity or create and update any of its code package entities.
Code package (entity): Seven Bridges Platform entity (like a file, task, or app) consisting of a UUID, a user-defined version identifier unique within the automation entity, and an associated code package file. Belongs to one (and only one) parent automation entity.
Code package (file): A .zip file containing the automation code, optional configuration files, an entrypoint file, a requirements file, and a schema file. Additional custom files can be included as well. A code package file is created with the Freyja sub-command ‘build’ and uploaded to the Seven Bridges Platform with the Automation CLI during creation of the code package entity. Upon execution on the platform, code package files are unzipped inside a docker container, external requirements are pip-installed, and the entrypoint is called to start the execution.
Schema (file): Contains formal description of automation inputs, outputs, and settings in JSON format. Automatically inferred from the automation code with Freyja sub-command 'schema' or when creating the code package file. The generated file is named '.schema' and is located in the root directory of the automation project and code package file. The schema is used by the RHEO GUI to render automation inputs and outputs.
Settings (file): A file containing a YAML or JSON string that defines automation settings. One or more settings files are stored at a defined location (‘configs’ subdirectory), where they are automatically found and read by Freyja when the automation starts. Defined settings can be accessed from within Freyja steps via the self.config dictionary. Settings defined in settings files can be overridden at runtime by the automation user (see ‘Runtime settings’).
Configuration (file): See Settings (file).
Runtime settings: Settings specified at runtime by the automation user when the automation is started. Runtime settings take precedence over settings defined in settings files inside code packages.
Override settings: See Runtime settings.
Secret settings (runtime setting): Special form of runtime settings that remain invisible when inspecting automation run details. Secret settings can be used to pass user credentials like passwords or tokens into an automation without the risk of exposing these credentials to someone else.
Secret settings (file): Special settings file located under 'config/secrets.yaml' that defines automation settings to be ignored when generating the schema. This file must also be listed inside .packignore to exclude it from code package file.
Automation run (entity:) An entity on the Seven Bridges Platform (like a file, task, or app) that consists of a UUID, a name, automation inputs, automation outputs, runtime settings, secret settings, execution status, the automation log, and the automation state.
Automation inputs: Inputs provided by automation user when the automation is started. Automation inputs are passed on as step inputs to the Freyja main step.
Automation outputs: Final outputs of an automation run. Defined as step outputs of the Freyja main step.
Automation log (file): File containing all error, warning, info, and debug messages produced by an automation run. This includes custom messages produced by Freyja steps (using the Python logging module) as well as messages produced by the ADK itself. Primary source of information when debugging failed automation runs. Can be accessed before an automation run finished execution, in which case the log file contains entries produced up to that point in time with a possible lag of a few minutes.
Automation state (string): JSON string describing the execution state of an automation run. For each executed step, it contains information about step inputs, step outputs, and step error messages. Can be accessed via RHEO API, CLI, or GUI during runtime, i.e. while the automation is still running. The automation log can also be used to track automation progress, but the automation state provides this information in a machine-readable format, for example to visualize an execution graph.
Automation state (file): File containing the automation state (string). Produced by Freyja during local execution when the ‘--state’ option is provided.
Requirements (file): Text file named ‘requirements.txt’ defining external Python dependencies that need to be installed to successfully execute the automation code. Defined dependencies are automatically installed with pip when this automation is run on the platform.
.entrypoint (file): Text file located in automation project root directory containing name of Python main module that gets executed first when the automation code is run. Without entrypoint it would not be clear where the automation starts execution in case the automation code consists of more than one Python module.
.packignore (file): Special file containing file paths to be ignored during 'freyja build' command. Should at least mention file 'config/secrets.yaml' if this file exists in the automation project.
Freyja: General-purpose Python library that helps with writing multi-threaded Python scripts. Part of the RHEO Automation Development Kit (ADK). Python scripts that use Freyja consist of one or more interconnected Freyja steps that execute in parallel whenever possible. Freyja is backend-agnostic, which allows development of different bindings for multiple execution environments.
Hephaestus: Python library serving as Seven Bridges binding for Freyja. Part of the RHEO Automation Development Kit (ADK). It defines Freyja steps for automating common operations on the Seven Bridges Platform (for example importing files, running tasks, or copying files). Also abstraction layer on top of sevenbridges-python to ease automation development. Specific to Seven Bridges execution backend. Depends on Freyja.
Freyja step (class): Python class that inherits from type ‘freyja.Step’. Has defined step inputs, step outputs, and a step execute function. The execute function gets triggered as soon as all step input dependencies have been resolved.
Freyja step (instance): Concrete instance of a Freyja step (class). All mandatory inputs must be provided as constructor arguments. In addition, each step must be assigned a unique name using the ‘name_’ argument except if this step is the only of its type inside its parent step. Freyja steps can be instantiated inside other Freyja steps (nested steps).
Step input: Freyja step class attribute of type ‘freyja.Input’ consisting of an ID, name, description, and a data type.
Step output: Freyja step class attribute of type ‘freyja.Output’ consisting of an ID, name, description, and a data type.
sevenbridges-python: Python binding for the Seven Bridges Public API. Publicly available on GitHub.
sevenbridges-cwl: Python library to programmatically create CWL tools and workflows in Python. Publicly available on GitHub.
Local execution: Execution of the automation code on the local infrastructure (typically the automation developer’s computer) as opposed to deploying and running it on the Seven Bridges Platform. Remote service calls via Hephaestus (for example starting a task) are still handled by the Seven Bridges Platform, but the automation code itself runs locally. Local execution is the preferred execution mode during automation development when fast testing and debugging cycles are important.